<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>i thought the "is" was triggering its memory thing <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 <sprang>I might have messed something up by running "system reconfigure" as root <mark_weaver>sprang: "guix system reconfigure" must be run as root <mark_weaver>it's almost the only thing that ever needs to be done as root, once you're installed. <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. <civodul>mark_weaver: i think it's the eval-when in file-systems.scm <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 <sprang>I have latest pointing at my git repository <mark_weaver>oh, but this error is not happening from the initrd, is it? <sprang>I could try reverting that and see what happens <mark_weaver>this error is happening during "guix system reconfigure", right? <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 <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>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 :-) <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. <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 <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 setup.py <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? <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/ ? <lfam>I'm not sure how to tell the package where to look besides editing it's setup.py, which is not optimal but the best I can come up with while debugging so far. Here is the relevant line of setup.py: http://paste.lisp.org/+3AYP <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. <lfam>But, the solution can't be to hardcode a store path into setup.py <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' setup.py 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 setup.py will take a search path from the environment <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>(you might be able to reuse something that we've already built) <mark_weaver>see 'set-path-environment-variable' in guix/build/utils.scm <lfam>Well, when I hardcoded the path into setup.py, 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 <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>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>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> (setenv "ATTIC_OPENSSL_PREFIX" (assoc-ref inputs "openssl")) <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. <sbidin>I want to start the ssh server, but don't know how. <sbidin>Is there something like a "deco list"? <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 ***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>mark_weaver: so you got a fancy server ARM board? <nextstep>ok, so you will compile there, or there's some cross-compilation <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 <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 <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) <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 <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 <francis7>some newer intel chipsets are also supported in libreboot <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>I'm also nearly finished porting the R500 to libreboot <nextstep>cool, thanks for proving me wrong francis7 <francis7>nextstep, libreboot.org 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. <mark_weaver>so intel seems to be a dead end for us, so we need to focus on other options <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. <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. <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 <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 <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 <antiatom>I would just like to put my time into development of distributions that are 100% FSDG compliant <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 <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. <jsgrant>ACTION really wants to pick up a lowRISC to play with, when it releases. :^) <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) <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? <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>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. <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>"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. <mark_weaver>it's an interesting conversation, but I'm afraid I have to go afk for a while.. ttyl! <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 :)