IRC channel logs


back to list of logs

<bavier1>I wonder if I should just push a bunch of my ghc packages, and then rebase the difference of Siniša's xmonad patches on top
<civodul>i guess either way is fine, as long as that doesn't involve an additional round-trip for Siniša
<civodul>sneek: ?
<civodul>sneek: what's fine?
<civodul>i thought the "is" was triggering its memory thing
<civodul>forgot how it works
<civodul>anyways :-)
<bavier1>I'll try something out
<bavier1>I may need to push a few unrelated packages, but I'll be pushing those soon anyhow
<sprang>civodul: not sure I follow, still a bit of a guix/guile newb
<civodul>sprang: actually i just tried and i can't reproduce the issue
<civodul>so my hypothesis was probably wrong
<civodul>could you post your OS config?
<sprang>sure, it's very simple:
<sprang>I might have messed something up by running "system reconfigure" as root
<mark_weaver>sneek: forget i guess either way
<mark_weaver>sneek: botsnack
<mark_weaver>sprang: "guix system reconfigure" must be run as root
<sprang>oh, well, that's good then :)
<mark_weaver>it's almost the only thing that ever needs to be done as root, once you're installed.
<mark_weaver>s/thing/guix command/
<sprang>earlier I was doing "sudo ..."
<mark_weaver>civodul, sprang: I've seen several people report this same issue, about not being able to find the syscalls module, but I'm clueless.
<mark_weaver>and I've never been able to reproduce it myself
<mark_weaver>I was hoping that civodul would save the day :)
<civodul>mark_weaver: i think it's the eval-when in file-systems.scm
<civodul>but i'd like to reproduce it
<mark_weaver>civodul: do you have a guess as to why that 'eval-when' might cause a problem?
<civodul>that somehow it would try to load (guix build syscalls) just because 'mount' is undefined
<civodul>but in the initrd, we know mount will be provided by the guile binary itself
<civodul>but i can't think of a clear scenario :-/
<civodul>sprang: is it after a recent 'guix pull'?
<mark_weaver>suppose it does try to load it. why can't it find it?
<civodul>because we don't add (guix build syscalls) to the initrd since it's not needed
<mark_weaver>ah, I see
<sprang>I have latest pointing at my git repository
<mark_weaver>oh, but this error is not happening from the initrd, is it?
<sprang>which is up-to-date
<sprang>I could try reverting that and see what happens
<mark_weaver>this error is happening during "guix system reconfigure", right?
<mark_weaver>where the initrd is not being used (yet)
<mark_weaver>but maybe it's not available in the build environment, in this case?
<mark_weaver>sprang: is /root/.config/guix/latest also pointing to that git repository?
<sprang>oh, hmmm, I'm missing the "guix" in my root's path
<mark_weaver>ah, so it was a broken symlink?
<mark_weaver>that could explain it
<sprang>I fixed it, let me retry
<civodul>this happens when compiling the 'init' file of the initrd
<civodul>in build/linux-initrd.scm, compile-to-cache
<civodul>an issue i see is that the environment that compiles 'init' has a different set of modules
<civodul>so this may help:
<civodul>sprang: could you try this patch and report back?
<civodul>i need some sleep now, but i'm interested in a followup by email or whatever :-)
<mark_weaver>okay, sleep well!
<sprang>civodul: will do, but it might be resolved after fixing that symlink... still downloading a bunch of stuff
<mark_weaver>using an old version of guix when running "guix system reconfigure", because "guix pull" doesn't affect the 'guix' run by root, seems to be a common error.
<mark_weaver>maybe the docs need to be more clear on this.
<civodul>yes, probably
<sprang>oh, my installation succeeded
<sprang>with the fixed symlink
<mark_weaver>woohoo! :)
<sprang>I guess I should try rebooting now :)
<sprang_>it boots! and I my kernel is upgraded :)
<civodul>so i was investigating in the wrong direction
<civodul>i prefer it this way :-)
<civodul>good night!
<sprang_>thanks for the help
<bavier1>I wonder if the perl-pod-simple build failed on hydra because mirrors aren't all caught up (the version pushed was just released today)
<bavier1>does 'guix system vm' not work with disk partitions?
<davexunit>bavier1: you need to use the --share and --expose options for that
***sprang_ is now known as sprang
<bavier1>davexunit: I see, thanks, I had missed that.
<bavier1>I suppose the image creator wouldn't know how to create any other partitions besides the root
<bavier1>I was trying to create a vm from an augmented version of my standard system config
<bavier1>which includes a separate file-system for /home
<lfam>I am trying to create a package for a python program that wants the openssl dev libraries (libssl-dev in the Debian repos).
<lfam>But of course it's not working or I wouldn't be writing this.
<lfam> raise Exception('Unable to find OpenSSL >= 1.0 headers. (Looked here: {})'.format(', '.join(possible_openssl_prefixes)))
<lfam>Exception: Unable to find OpenSSL >= 1.0 headers. (Looked here: /usr, /usr/local, /usr/local/opt/openssl, /usr/local/ssl, /usr/local/openssl, /usr/local/attic, /opt/local, /gnu/store/1c96zwwg6lnh6v9n3m0q30pg0x2m0v5c-openssl-1.0.2d/include)
<lfam>I desparately hard-coded that last bit into
<lfam>I can't tell if the guix openssl package offers these libraries? I don't see a separate output for them. Just wondering what the status of that is?
<lfam>Here is the package definition that is calling openssl:
<bavier1>lfam: that package could go in gnu/packages/backup.scm
<bavier1>re openssl: is the package looking for the headers in the correct subdirectory?
<bavier1>lfam: notably, the package might need to look in $openssl/include/openssl
<lfam>I assume that $openssl is short for /gnu/store/[...]-openssl/ ?
<bavier1>lfam: correct
<lfam>I'm not sure how to tell the package where to look besides editing it's, which is not optimal but the best I can come up with while debugging so far. Here is the relevant line of
<mark_weaver>lfam: based on the list of directories where it said it looked for openssl, I think you should remove "/include" from the end fo the file name you added.
<mark_weaver>(the other file names didn't have "/include" at the end)
<lfam>Wow, I could have sworn I started with that. Now it fails on an undeclared dependency on acl but I can fix that.
<mark_weaver>ah, good!
<lfam>But, the solution can't be to hardcode a store path into
<mark_weaver>sometimes we have to do things like that. the trick is to patch it within a phase added after 'unpack', which uses 'substitute*'.
<lfam>I guess I will look at some other (working) packages' and see how they find their dependencies
<mark_weaver>in that case, you should remove the other places where it looks, and replace the entire value of 'possible_openssl_prefixes' with a list containing just one element.
<mark_weaver>should be easy with a regexp, assuming it's all on one line.
<lfam>Actually, it looks like this will take a search path from the environment
<mark_weaver>ah, okay, that would be nicer of course
<lfam>So I guess my question is, can we generate that search path while building?
<mark_weaver>yes, certainly. we already do it for many other variables like PATH and CPATH and LIBRARY_PATH, etc, and have a handy procedure to help.
<mark_weaver>what does the search path have to look like?
<mark_weaver>(you might be able to reuse something that we've already built)
<mark_weaver>see 'set-path-environment-variable' in guix/build/utils.scm
<mark_weaver>that module is available in build phases by default
<lfam>Well, when I hardcoded the path into, it was just the absolute path to the openssl package in /gnu/store
<lfam>I'm going to take a look at how other packages use set-path-environment-variable
<mark_weaver>it's almost never needed
<lfam>Yes, I only see it twice in gnu/packages
<mark_weaver>if you just need things like /gnu/store/...-openssl-N then there's no need for that procedure
<mark_weaver>if you can describe to me what you need, I can help.
<lfam>starting at line 69 of this, you can see where it starts to look for the openssl libraries:
<lfam>The program needs the libraries from openssl >= 1.0.0
<mark_weaver>looks like you could do (setenv "ATTIC_OPENSSL_PREFIX" (assoc-ref inputs "openssl"))
<mark_weaver>in a phase added before the build phase.
<mark_weaver>so something like: (modify-phases %standard-phases (add-before 'build 'set-openssl-prefix (lambda* (#:key inputs #:allow-other-keys) (setenv "ATTIC_OPENSSL_PREFIX" (assoc-ref inputs "openssl")) #t)))
<lfam>Oh I see, something just like that in perl-net-ssleay
<mark_weaver>so something like:
<mark_weaver>(modify-phases %standard-phases
<mark_weaver> (add-before
<mark_weaver> 'build 'set-openssl-prefix
<mark_weaver> (lambda* (#:key inputs #:allow-other-keys)
<mark_weaver> (setenv "ATTIC_OPENSSL_PREFIX" (assoc-ref inputs "openssl"))
<mark_weaver> #t)))
<mark_weaver>lfam: yes
<mark_weaver>although python-build-system has no configure phase, so you'll need to add it before 'build' instead.
<lfam>Okay, thanks for helping me with this! I want to get this working tonight but I have to take a break.
<mark_weaver>okay, sleep well!
<mark_weaver>(or rest well, as the case may be)
<lfam>ACTION zzz
<sbidin>I want to start the ssh server, but don't know how.
<sbidin>Is there something like a "deco list"?
<sbidin>Ah, found it: deco status dmd
<taylanub>this doesn't seem quite right :\\
<mark_weaver>no, it doesn't!
<mark_weaver>you're running from a git checkout?
<taylanub>yes, newly updated master
<taylanub>ah wait, this might be my fault
<taylanub>yup, sorry for the wrong alarm, I need to remember that I can't expect to use guix normally when I'm in the middle of making changes to the source
<taylanub>when $config/guix/latest is linked to the repo, that is
<mark_weaver>indeed :)
<zacts>hi guix
***davi_ is now known as Guest52101
***davi_ is now known as Guest41354
<nextstep>hello, i was wondering if there's a plan to provide ARM binaries
<mark_weaver>nextstep: yes, we should have them within a couple of weeks.
<nextstep>as explained here, there are some great cheap laptops getting ported to coreboot
<nextstep>oh, thats fantastic!
<mark_weaver>nextstep: yes, I heard about that. very exciting!
<nextstep>its very exciting indeed
<nextstep>mostly open hardware
<nextstep>mark_weaver: so you got a fancy server ARM board?
<mark_weaver>I have a Novena board
<nextstep>ok, so you will compile there, or there's some cross-compilation
<nextstep>in the guix hydra
<mark_weaver>so, it will all be natively compiled
<nextstep>there's also this pyra phone/tablet coming
<nextstep>so it's maybe possible to run guix on that as well
<mark_weaver>I'll make an official announcement when it's all set up
<nextstep>cool cool
<mark_weaver>(and thank the two generous donors who donated arm hardware for our build farm)
<nextstep>mark_weaver: definitely, its a hard to come by hardware
<nextstep>actually nix won't be supporting ARM
<mark_weaver>ah, I didn't know that, and find it surprising
<mark_weaver>supporting non-intel hardware is a high priority for me
<mark_weaver>(I ported Guix to both MIPS (Loongson) and ARM, and am currently working on supporting GuixSD on non-Intel systems)
<mark_weaver>(starting with the Lemote Yeeloong 8101B)
<nextstep>davexunit: i asked them explicitly
<nextstep>they mentioned lack of hardware
<nextstep>mark_weaver: i'm glad non-intel is a priority
<nextstep>as most semi/free hw is not intel these days, sadly
<nextstep>i think those rockchips could be a killer app for guix
<nextstep>very cheap, easy to buy
<mark_weaver>right, modern intel systems won't run without megabytes of non-free software, and I have little hope they were ever again make hardware suitable for us.
<nextstep>yeah, those x60 or early santarosa macbooks
<nextstep>are the last we got from them i think
<francis7>nextstep, wrong
<francis7>some newer intel chipsets are also supported in libreboot
<nextstep>on laptops?
<francis7>gm45/ich9 - on thinkpads, those are: X200, T400, T500, R400
<mark_weaver>AMT in particular is rather frightening, and we haven't figured out how to run any Intel laptop newer than a Thinkpad X200 without including AMT
<francis7>all of the above laptops mentioned are supported in libreboot
<francis7>AMT/ME is completely removed.
<francis7>I'm also nearly finished porting the R500 to libreboot
<nextstep>cool, thanks for proving me wrong francis7
<francis7>nextstep, has links to compatibility lists
<mark_weaver>still, there's little hope that we'll be able to liberate anything from intel newer than those.
<francis7>yes, that is probably the case
<nextstep>it sucks
<francis7>intel does suck
<mark_weaver>so intel seems to be a dead end for us, so we need to focus on other options
<francis7> even says so
<mark_weaver>early on, GNU recognized the importance of portability, to avoid being tied to a single manufacturer
<mark_weaver>but I'm sorry to say that today, many (most?) free software developers seem to test only on Intel systems, and it requires a lot of effort from a small number of distributions who support non-Intel to get things working again on other systems.
<mark_weaver>well, I guess ARM is also a big focus, so at least that's something.
<daviid>mark_weaver: what other option? is there even hope of a manufacturer that will not enter the drm's 'fashion'
<mark_weaver>well, there's somewhat more hope in the ARM world, because ARM itself doesn't manufacture chips. they license hardware designs which are modified and produced by a large number of other manufacturers, so there's much more diversity there.
<mark_weaver>but in the long term, we really need free CPU designs, one of which is LowRISC.
<mark_weaver>Bunnie Huang is on their advisory board, and they say they have a plan to produce real silicon and inexpensive development boards, so that's all quite hopeful.
<mark_weaver>there are some other projects as well
<daviid>very nice
<antiatom>francis7: You are a Libreboot developer? I am really interested in the GS45 chipset working with the low voltage CPU found in X200s and some X200 tablets and the X301
<antiatom>Also a Guix question... what if a system requires non-libre firmware blobs to function that uses Guix?
<mark_weaver>antiatom: francis7 is the original and principal Libreboot developer.
<antiatom>Oh that is nice
<mark_weaver>antiatom: we don't provide any non-free blobs in GuixSD, and I would encourage you to use hardware that doesn't need blobs.
<mark_weaver>that said, Guix is user-hackable, and it's easy to run modified versions.
<antiatom>I support that, and I bought an X200 to install Libreboot with ath9k card. Right now I have Parabola GNU/Linux-libre installed, but Guix interests me even tho I have not tried it
<mark_weaver>Excellent! I run GuixSD on a Libreboot X200, fwiw.
<antiatom>The reason I ask about firmware blobs is because Devuan community seems to think they can not be 100% FSDG libre
<antiatom>I was writing a new draft of the Devuan Constitution to make it 100% FSDG compliant, but got negative response so far
<antiatom>The reason was some people need firmware blobs for their hardware
<mark_weaver>that's disappointing. thanks for trying.
<antiatom>Devuan is trying to be the replacement for Debian without systemd, but I think it needs something else to stand out
<antiatom>Maybe Guix can offer that something else
<jsgrant>ACTION still finds it odd that there is people out there (not saying antiatom , but I've heard many people elude to the following claim) that as if GNU is actively trying to implement some sort of OEM-like system that will actively ban non-free software, and one is somehow not able to edit/turn off, etc. 
<jsgrant>It's an ethical imperative to for free-software, not to run non-free, but that doesn't mean actively limiting a user's freedom to make what some would call "bad choices" and all that.
<antiatom>jsgrant: I am not saying GNU bans non-libre software, in fact I am really enthusiastic about Guix including only libre packages and being very explicit the license of each package
<mark_weaver>yes, of course
<davexunit>you just void your warranty ;)
<francis7>who needs warranties?
<antiatom>I would just like to put my time into development of distributions that are 100% FSDG compliant
<antiatom>...but I also wanted to support Devuan
<antiatom>So I am not sure what to do
<jsgrant>antiatom: Yeah, that's why I put that disclaimer probably ruling you out of this of this club -- it's just sadly not that rare of a view, and I don't get where people get this impression from.
<nextstep>I think it's sometimes acceptable to run proprietary firmware, as a temporary solution
<nextstep>if you don't control the hardware that gets purchased
<nextstep>things suck
<mark_weaver>there need to be pushback against that, or else nothing will change
<jsgrant>ACTION is hopeful for Risc-V, but due to non-free microcode ... aren't somefactor of "all systems" non-free at the processor level atm though?
<jsgrant>ACTION is very uneducated on this topic.
<nextstep>that's usually
<mark_weaver>jsgrant: lowRISC uses the RISC-V instruction set
<nextstep>not considered a blob?
<jsgrant>ACTION really wants to pick up a lowRISC to play with, when it releases. :^)
<mark_weaver>me too
<jsgrant>mark_weaver: Building Guix and related depends will likely be painful though (I heard it's aprox Raspberry Pi level of performance), though iirc you built a fair amount on MIPS via a Yeelong? If true, I'm sure that wasn't trivial.
<mark_weaver>the Novena is *vastly* faster and more powerful than an RPi (which is also terrible from a freedom standpoint, btw)
<mark_weaver>it's faster than my Loongson based machines as well
<dmarinoj>When do you think people will be able to print there own chips?
<jsgrant>dmarinoj: To what level of performance? Like to be able to compete with mass-production, or at a hobby-level?
<jsgrant>ACTION will likely brb.
<dmarinoj>The former
<dmarinoj>jsgrant: compete with mass-production
<mark_weaver>probably never
<mark_weaver>but it could be good enough
<dmarinoj>enough to use a desktop environment comfortably?
<mark_weaver>specifically, it could be good enough that many people would choose a slower chip that they can trust over a faster chip that's obeying somebody else.
<mark_weaver>one can hope, anyway.
<mark_weaver>oh, it will surely be many years at least, and people's expectations in a comfortable desktop environment will also change during that same time.
<mark_weaver>I certainly can't answer that question with any confidence.
<mark_weaver>I suppose "universal assemblers" from molecular nanotechnology could change the game fundamentally, but it's really unclear what policy will be adopted around things like that.
<jsgrant>mark_weaver: Do you think people with side with the safer, more ethically sound option if we are still confined to producing "Free-Hardware" on Silicone while the big companies are doing something like quantum tech that is like 1000x faster (making a lot of assumptions here obviously).
<mark_weaver>and the entire world seems to be moving toward plutocracy
<mark_weaver>anything could happen. I think life as we know it is going to change radically as I result of our new technical capabilities and the evolving political situation, and probably not for the better.
<mark_weaver>s/as I/as a/
<sprang>once we have molecular manufacturing, all of the issues we now have with software will apply to anything physically assembled
<sprang>how do you trust the assembler, licensing of designs, etc.
<mark_weaver>and also, it's unlikely that the current powers will let such technology fall into the hands of ordinary people like us.
<mark_weaver>at least not willingly
<mark_weaver>"they'd be able to print guns, missiles, fighter jets!"
<mark_weaver>already we are seeing regulations that things like wireless routers must be locked down, to prevent unauthorized use of the radio spectrum.
<jsgrant>I'd imagine that once 3d printers and related tech, once it get sufficiently advanced, there will be a push for licenses to authorize use of such things in fear for such things.
<jsgrant>I'm not exactly how I feel about that, assuming that does happen/gets pushed eventually.
<jsgrant>sure how I feel*
<mark_weaver>it's an interesting conversation, but I'm afraid I have to go afk for a while.. ttyl!
<jsgrant>mark_weaver: Peace. o/
<jsgrant>ACTION gets back to reading.
<dmarinoj>mark_weaver: bye
<remi`bd>is there possible to write a package recipe that fetches a specific revision from a SVN repo?
<sneek>Welcome back remi`bd, you have 1 message.
<sneek>remi`bd, mark_weaver says: guix/publish.scm might be a good place
<taylanub>remi`bd: yeah, using '(method svn-fetch)' ... you can grep the gnu/packages/ directory for that to find some examples
<taylanub>it seems you need to import the module (guix svn-download) for it to be available
<remi`bd>thanks! couldn’t find it in the manual :)