IRC channel logs


back to list of logs

<quiliro> there a configuration to install guix with emacs to develop for guix?
<quiliro>i received a macbook air A1304
<quiliro>is it possible to use that machine with free software?
<jonsger>quiliro: of course but not exclusively :P
<quiliro>what do you suggest? return it?
<apteryx[m]>What do people do to setup a build environment on a non Guix machine? I used to think installing tons of dependencies on Ubuntu globally was OK, but after using Guix, it feels very crude to mutate my system like that!
<quiliro>i had problems with the parabola live usb
<quiliro>slow mouse and no wifi
<quiliro>then i tried triquel 7.0 and guixsd 0.11...they would not boot
<jonsger>quiliro: slow mouse seems to be like not well configured but no wifi is "normal" if you only use free software
<quiliro>jonsger: i would like to use it as a true hacker...with Emacs
<quiliro>and no pretty window manager but a functional one
<quiliro>i have heard of i3
<jonsger>then you don't need a mouse :)
<jonsger>ACTION use i3
<quiliro>but i must learn then
<quiliro>jonsger: there is i3 on GuixSD?
<jonsger>yes. guix package -i i3-wm i3status dmenu
<k`>quiliro: FWIW, I don't see any Macbook Air entries on
<quiliro>jonsger: would you pass me your config.scm and the packages installed on your user?
<quiliro>h-node has 9400m video card as not compatible
<jonsger>quiliro: I haven't one I use LinuxMint :( I use guix just as package manager
<quiliro>jonsger: what packages have you installed, just i3-wm i3status dmenu?
<jonsger>for using i3 yes. and then you have to "enable" i3 in your config.scm
<quiliro>how about viewing videos on youtube and using spreadsheet?
<jonsger>just use icecat, it's a "gnu version" of firefox
<ng0>humph. someone around with more insight in qemu-kvm servers and grub errors?
<ng0>I get embeding error warnings
<ng0>it could've been easy.. if the hoster support has no idea, I'll send them the server to dd
<ng0>basically this:
<ng0>yeah, I'm at the point where when I log out now I know the server won't let me back in, damage done. Sent the hoster a notice for further questions.
<ng0>The joy of being early testers :)
<ng0>good night
<methalo_>failed to produce output path /gnu/store/..-pcre-8.40-bin', if I remove the (outputs '("out" "bin" "doc")) finish with success!
<methalo_>may be i need associate the output
<quiliro>can anyone see that video?
<quiliro>impressive...32 packages more in guix in a week or two
<quiliro>that means 1500 additional packages per year
<Apteryx>Are some build tasks done directly under /gnu/store?
<Apteryx>I put triggered a failure at the end of the build of gimp, and found out in the log that some operations such as generation of manpages were conducted straight under a /gnu/store/...-gimp-... location.
<Apteryx>Oh, sorry that's false. The manpages are generated during the build phase. It's just some extra symlinks creation which happens later creates things in the store; normal as it's part of the install process.
<civodul>Hello Guix!
<quiliro>hello civodul
<quiliro>can someone see this ?
<quiliro>i could not boot guixsd usb on a macbook air
<quiliro>could it be because of uEfi?
<quiliro>civodul: is it good that root is in charge of nginx web server for a mirror of guix?
<quiliro>all packages
<civodul>quiliro: for the video, i'd use "mpv https://..."
<civodul>quiliro: re nginx, nginx has the ability to drop privileges
<civodul>strongly recommended :-)
<civodul>for instance, "user nginx;" in the nginx config file will have it switch to the "nginx" user
<quiliro>civodul: cool! thanks
<quiliro>civodul: do you use emacs?
<quiliro>why does mpv need to download the whole video before starting...i will read the manual to see what to do about it
<quiliro>civodul: wow! new uefi image!
<rekado>quiliro: AFAIK it does not download the whole video. I have been using mpv to stream videos without having to wait for a complete download.
<quiliro>civodul: i will test with other videos then
<quiliro>civodul: it would be nice to have something like this for Guix
<Petter>I'm curious to try the Icecat 52.0.2-gnu1 patch by Mark. But I fail at grabbing the patch without broken lines etc. How do you do this?
<Petter>I don't have the e-mail in my inbox, just this web page.
<Petter>Guess that suddenly answered how most other people do it.
<civodul>Petter: i think Mailman also exports raw mbox files, but yeah, that's inconvenient
<civodul>otherwise you could use a news client with
<Petter>I'll poke around a little, thanks!
<snape>does anyone experience this warning while running git?
<snape>I can't git fetch guix repo
<snape>fatal: read error: Connection reset by peer
<civodul>snape: indeed, terribly slow right now
<civodul>wingo: did you eventually manage to push?
<wingo>civodul: i was able to push to guile-web an hour ago or so but not guile
<wingo>or rather, right now i have a guile push that is hanging
<wingo>could be worse, we could be using cvs :)
<wingo>ACTION had to touch the beast today already
<efraim>i'm getting error 502 from the repo
<efraim>mbakke: i'm still getting the 'Unexpected pages_huge()' error
<efraim>when I checked `cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages` i got 0
<efraim>to clarify, i tried with the --disable-thp configure flag
<efraim>interesting, 'thp' in the configure printout says 0
<efraim>so it may be a bug in the test
<snape>ACTION is building Icecat 52
<efraim>i was going to try to bump moreutils, but 0.61 came out ~19 hours ago and debian hasn't packaged it yet
<Petter>snape: Did you have any problems applying the Icecat patch?
<Petter>Once you have a patch, it should just be running `git apply icecat.patch`. Right?
<Petter>This is what I get:
<mekeor>Petter: maybe the patch was made based on a different commit than you have checked out?
<mekeor>Petter: did you try to git-pull?
<Petter>Could be. I haven't been able to update yet. I get 502 responses when I try.
<mekeor>Petter: what update?
<Petter>Git pull.
<brendyn>Anyone know where I can get a vps I can setup guixsd on, and pay for with bitcoin?
<Petter>mekeor: You're right. I had quickly compared the file with the patch, and it looked ok. Looking again I see some changes. Thanks!
<efraim>brendyn: people have had relatively good success converting existing VMs to guixsd VMs
<amz3>I have 502 "Bad Gateway" when running 'guix pull', is it just me?
<buenouanq>same here
<buenouanq>those thursday morning server updates man
<ng0>uh. maintenance at the git host of savannah? all repositories are unreachable on all channels
<civodul>yeah, problems
<civodul>no info at
<civodul>it's early morning in Boston though
<ng0>yeah.. maybe best leave a message after the beep :)
<ng0>unfortunate time for me, setting up a server.. but it can wait
<alezost>if anyone is interested, Emacs-Guix has the html version of the manual now:
<ng0>oh. we can set the sourceurl for pull, so I can temporarily pull from my own master, right?
<ng0>is there some generic way to address cgit for the tarball of master?
<ng0>append "snapshot/master.tar.gz" to the cgit url, if the feature is enabled
<ng0>only problem, certificate issues. I'll just wait until savannah comes back
<civodul>sneek: later tell alezost thanks for the online manual! could you update doc/htmlxref.cnf in Guix to point to it?
<snape>Petter: yes, the patch does not apply, there are three lines to add to (icu4c CVEs) and end-of-line comments in gnuzilla.scm.
<snape>*that should be removed, so the patch applies
<civodul>rekado: do you have plans to look at the Conda patch set? :-)
<wingo>civodul: any thoughts re: guile 2.2.1? i guess we just push an update when git recovers/
<wingo>once that lands i can prep a proper potluck patch pull-please (phew!)
<efraim>mbakke: without the --disable-thp config flag jemalloc thinks my aarch64 machine does have thp
<civodul>wingo: thoughts on what?
<civodul>2.2.1 is in Guix already :-)
<wingo>updating guile package to 2.2.21
<wingo>heh, ok :)
<wingo>ACTION having trouble git pulling :)
<civodul>oh right
<civodul>i pushed it yesterday
<wingo>no probs then i guess?
<wingo>it was a somewhat hasty release
<civodul>yeah it works fine, at least on x86_64
<civodul>wingo: the 'thunk?' optimization worked as expected, BTW
<civodul>i no longer see elf.scm in the profile \\o/
<wingo>ah that's good :)
<wingo>v good, v good.
<civodul>and the example from now runs in 1.9 seconds (was 2.2)
<civodul>isn't that awesome?
<wingo>neat :)
<wingo>i still feel like we should be able to improve that
<snape>Petter: Actually, Icecat patch applies when guix repo is up to date :) It's just.. I could not fetch a few hours ago
<wingo>like what would it take to get to 200ms
<wingo>would need guix changes obviously
<wingo>but if we could do it, it would feel magical
<civodul>wingo: i agree!
<civodul>caching is what we should focus on in Guix
<civodul>that's where we spend most time currently
<civodul>because we use equal?/hash caching (!) for packages
<civodul>instead of eq?/hashq
<civodul>but that's still faster than eq?/hashq
<civodul>it's complicated, but there's room for improvement!
<civodul>the other thing that takes time is 'write', which is called when writing derivations
<wingo>so loading up all the package modules isn't a significant part?
<wingo>i guess your test didn't include that
<wingo>b/c the all-packages hash was already created
<civodul>i don't think so, because it's a promise
<civodul>so it does include that
<wingo>well yeah but it loads like hundreds of modules
<wingo>i guess if you measure from a fresh repl
<wingo>then you do include it
<wingo>ACTION nod
<wingo>in that case you could measure the cost of that by diffing between the first guix-build and the second
<wingo>if i could ever get git to pull :P
<civodul>not really, because the second one is instantaneous due to memoization
<civodul>to benchmark module loading, we can just do a 'fold-packages' call in a fresh process
<wingo>ACTION nod
<Petter>snape: I haven't been able to pull from git either. But now I have Icecat building anyways. Thanks!
<snape>np :)
<thomasd>Hi #guix
<civodul>hello thomasd!
<ng0>i think boston is back, or at least there is now a timeout instead of an error
<ng0>I guess it will be an timeout
<thomasd>do we support cross-references in package descriptions? (like “x relies on @command{y} provided by package @pxref{z}”)
<wingo>that would be neat :)
<wingo>@pxref includes "see " tho
<thomasd>ah, yes, I'm a texinfo newbie and can't remember the proper ref commands yet :)
<civodul>that would be fun indeed
<civodul>how this is rendered would depend on the UI though
<civodul>what would you do in a terminal? :-)
<thomasd>it's probably a rarely needed feature, usually such dependencies would just be inputs
<thomasd>in a terminal you could just type the package name?
<thomasd>err write the package name
<thomasd>anyway, I'll take that as a no(-t yet) ;-)
<wingo>probably you just want to mark a package as being a package
<wingo>then figure out what presentation you would like depending on the medium
<wingo>i guess texinfo macros could do that
<ng0>It would be great if texinfo would have translation support one day
<ng0>like for documentation generation
<wingo>what does that mean
<ng0>I'm not there yet with my documentation fixes, but I'm not aware of any way to have more than one language output to files from an full documentation "book"
<ng0>unless texinfo can do something similar to sphinx with rst
<thomasd>wingo: yes, we could just mark packages with “@package{...}”. Maybe I'll experiment with it at some time.
<wingo>probably you'll have to add some hack to the texinfo parser, but that's not that bad
<wingo>i think it might not know anything about macros but i could be wrong there
<wingo>anyway a scheme parser not knowing about macros is unforgiveable :)
<thomasd>and semi-related: some projects use a lower case name on purpose, but the guix package lint does not accept that. I suppose an exception is ok in such case?
<wingo>ACTION is more of a victim of lint than an authority on it :)
<civodul>we could make the texinfo parser extensible, such that we can define "texinfo macros" in Scheme
<civodul>thomasd: it does not accept that at the beginning of the description, right?
<thomasd>civodul: right
<civodul>you could do @command{foo} if that's appropriate
<anthk_1>hello, can the GuixSD image be burn on a DVD?
<civodul>or otherwise, just ignore the warning
<ng0>anthk_1: not yet
<ng0>but there are people working towards an iso
<civodul>anthk_1: currently the image is meant to be stored on a USB stick
<anthk_1>oh :\\
<thomasd>ok :) indeed, sometimes the name of the package/project is not the name of a command, but still written in lower case.
<anthk_1>can it be bootstraped from another distro?
<anthk_1>I am at parabola
<ng0>in theory. some systems work, like minimal Debian
<anthk_1>I mean, fully, from a live CD
<ng0>what do you mean?
<anthk_1>in example, booting from systemrescueCD and install GuixSD from here
<ng0>recently wingo documented an Debian -> GuixSD process on the mailinglist for digitalocean cloud server
<efraim>Do we have any plans to depreciate mysql in favor of mariadb?
<efraim>It should work, I'd use the binary install as a guide to getting it and the guixsd install guide for actually installing, but being familiar with the install process first should be helpful
<ng0>and also what needs to be cleaned up, etc
<efraim>wingo: did you try making a swapfile before you started? I get a lot more bang for my $5 droplet with a 1 GB swap file
<wingo>efraim: no but i did that later, and it is much better!
<wingo>i did it manually tho; do you have a guixsd snippet for that?
<ng0>doesn't exist (yet) :)
<wingo>when i reboot i will have to turn it on again manually i think
<ng0>oh.. you can specify it in the config
<wingo>yeah that is what i was looking for, something to specify in the .scm
<civodul>how do we deal with cmake not adding $out/lib to RUNPATH again?
<ng0> (swap-devices '("/cryptoswap"))
<civodul>rekado: does that ring a bell? ↑
<ng0>is cURL okay this time, no immediate bug smashing release in sight?
<civodul>oh found an example in ao-cad
<ng0>guess I'll do the fork release then.
<ng0>ACTION curses to no automation
<civodul> is back, isn't it?
<ng0>my server hasn't catched up.
<ng0>it's still 502 in iceland
<wingo>still hanging for me
<wingo>git is back in the house
<wingo>i get an error downloading
<wingo>hmm, maybe not...
<wingo>ACTION should switch to guix pull, this guix environment guix stuff is madness
<ng0>okay, done. I'll send the gnurl guix patch soon
<ng0>washing machine calls
<Petter>ACTION is running Icecat 52
<Apteryx>wingo: I had that yesterday!
<Apteryx>(the error downloading gmp). Seems the nar was corrupted.
<amz3>does anyone has a "howto" for building a guix rootfs for an lxc ?
<amz3>I think it's just a matter of put'ing together a os configuration and building the image and unpacking that image to a directory
<anthk_1>where could I set up grub boot options? as video=1990x400
<efraim>new qemu release
<lfam>ng0: What certificate problem did you have with `guix pull`?
<lfam>efraim: Are you testing the new QEMU? If not, I'll do it
<lfam>efraim: I've been tracking the release candidates and fixed bugs, so I have a commit message if you just needed that
<efraim>Sounds like you're more on top of it than me. I just noticed that they tagged 2.9.0
<ng0>lfam: guix pull --url= with an LetsEncrypt url of my master.targ.gz of guix, but this was mostly 0.12 release, I'm past that now and bootstrapping my way to GuixSD
<efraim>You can get it, I'm still working on jemalloc for aarch64
<lfam>ng0: Okay, I think that's expected with the 0.12.0 release unless you set an environment variable to help Guix find your local certificate store
<mbakke>efraim: thanks for checking. if it builds --without-thp, I guess we can just pass it to all non-intel arches
<efraim>It builds --without-thp, and neovim and mariadb both built successfully with --without-thp and tests disabled
<mbakke>great! one further step towards ceph on aarch64 ;)
<mbakke>ceph has a strange test failure on x86_64 though.. are the hardware specs of current build slaves available?
<civodul>the results Should Not Depend on Hardware Details :-)
<lfam>Should not, but sometimes do :)
<civodul>in theory, the model matches reality ;-)
<lfam>Indeed :)
<efraim>i seem to have gone into an endless loop trying to get a substitute for lrdf:
<mbakke>it looks as if the compiler thinks SSE3 is available, but the test can't find it in /proc/cpuinfo
<mbakke>all 64-bit intel cpus have sse3, but the very first 64-bit AMDs did not have it
<mbakke>I'll try to hard disable SSE3 instructions for ceph
<civodul>efraim: could you try to capture details about this?
<civodul>that URL is 404
<civodul>but is not
<efraim>the full cycle is 4 lines:
<efraim>@ substituter-started /gnu/store/whq5fsb6sdyxj8vycmw2kwgs38p7mpxx-lrdf-0.5.0 /gnu/store/2y1jx6lq4w61gz3ys8a29r6zxyajr0xm-guix-0.12.0-8.d72b/libexec/guix/substitute
<efraim>Downloading (84KiB installed)...
<efraim>guix substitute: error: download from '' failed: 404, "Not Found"
<efraim>@ substituter-failed /gnu/store/whq5fsb6sdyxj8vycmw2kwgs38p7mpxx-lrdf-0.5.0 256 fetching path `/gnu/store/whq5fsb6sdyxj8vycmw2kwgs38p7mpxx-lrdf-0.5.0' failed with exit code 1
<efraim>also re sse3, in qt some flags are -no-ssse3 and some -no-sse3, we should probably chose one or the other
<mbakke>we should probably disable both for maximum compatibility
<efraim>civodul: when I went to restart it it correctly started building it locally after failing the substitute
<efraim>from qtbase configure: Enabled ones are still subject to runtime detection.
<civodul>efraim: so it keeps restarting the substituter on that one?
<civodul>also with --no-grafts?
<Gareth422>Hey. I was wondering if burning the USB image to a DVD will work.
<efraim>i didn't try --no-grafts, after I stopped it and restarted it it worked as exptected, failed and then fellback to local compilation
<mbakke>efraim: In that case I'd guess it's okay. As long as it doesn't pass -msse3 to the compiler.
<mbakke>Gareth422: I don't think so. But there is some discussion currently about generating an ISO image which should work.
<Gareth422>I have an infinite stack of DVDs and pretty much no flash drives.
<lfam>The staging jobset queue is decreasing rapidly :)
<mbakke>Gareth422: See this thread for some information on what is needed:
<mbakke>lfam: Yay :)
<lfam>So far, no failures except for libressl, which is fixed on master
<lfam>And also tuxpaint
<efraim>i should test mesa from staging on aarch64 to make sure it builds fine
<Gareth422>Ah, man, I can't do any of that right now, since I'm on Windows.
<mbakke>efraim, civodul: I just hit an infinite download loop too, for "sdl-union".
<mbakke>lfam: tuxpaint fails the same way on "master"
<lfam>Okay, "good" ;)
<bavier>lfam: I wonder if '#:parallel-build #f' would help tuxpaint
<mbakke>bavier: indeed it does
<mbakke>I pushed it.
<lfam>Find orphaned patch files:
<lfam>for patch in gnu/packages/patches/*; do result=$(grep -rI ${patch##*/}) && test ${result%%:*} != "gnu/" || echo $patch; done
<mbakke>is there anything inherently tying nss-certs to the nss package?
<mbakke>AFAICT updating them independently works fine
<lfam>From what I can tell, you're right
<lfam>It would be nice to confirm that and really decouple them. I don't like the default certificate store depending on the flaky NSS build
<mbakke>I'll reconfigure my system on the nss-certs update to be sure.
<lfam>We should probably ask the NSS maintainers about it (or find some documentation), just to be sae
<mbakke>since nss-certs only contain x509 certificates, and the nss ABI is guaranteed to be stable, I can't see what the relation should be
<mbakke>the rare case would be if a new cert requires some new crypto primitives in nss
<mbakke>but then we'd probably have problems with other TLS libraries too
<lfam>Right, that's my understanding, too
<mbakke>from following nss a while, it looks like new releases update either code or certs, so it makes sense to update them invidually
<mbakke>I'll push the update. Geronimo :)
<lfam>bavier: <> added some patches that weren't used, for hypre.
<lfam>bavier: Can you take a look and decide what to do about these stray patch files?
<bavier>lfam: oh, good catch.
<bavier>lfam: I can remove them. I think the patches were used for a previous version that I had originally packaged, but I bumped the version before pusing
<lfam>Cool, let's reduce that `guix pull` snapshot size :)
<civodul>mbakke: if that's not too late, could you try to gather strace or whatever of the substitute loop?
<bavier>might be fun to add a test that checks that all dist_patch_DATA patches are actually used in packages :)
<lfam>bavier: Yeah, and I don't want to do it with POSIX shell!
<bavier>lfam: haha
<lfam>So tedious building up lists and processing them there
<civodul>Steap actually did that looooong ago as a shell script (i think?)
<Steap>oh yeah
<lfam>I punted with my script, to be honest. It only works because grep seems to check in 'gnu/packages/' before 'gnu/'
<bavier>shouldn't be to hard?: diff `guile -e '...'` `echo $(dist_patch_DATA) | sed 's/ */\\n/'`
<lfam>Ah, but you're cheating with guile, right? ;)
<bavier>we do like to use it everywhere ;)
<civodul>bavier: looks like you're ready for the challenge! :-)
<Steap>let me find this :)
<bavier>oh, are we talking POSIX shell so that we could add it as a git hook?
<lfam>No, I just did it with POSIX because that's what I know
<lfam>I haven't bothered to learn any shell-specific scripting features
<bavier>ah, ok
<Steap>lfam: ^
<Steap> <- the patch is on the mailing list btw
<lfam>Oh well, it gave me something to do while I waited for a build to finish :)
<mbakke>civodul: unfortunately it's long gone. will do if/when it reoccurs
<rekado>civodul: I’ll take a look at the conda stuff soon.
<rekado>ACTION apologizes for the late reply; parts of rekado are on holidays
<mbakke>lfam: is it possible to cancel pending evaluations on Hydra? It would be good to have the nss fix in first.
<civodul>rekado: awesome, thank you
<civodul>rekado: enjoy your holidays!
<civodul>next week for me...
<mbakke>although, there is probably little overlap between ffmpeg+qemu and nss
<mbakke>in more positive news, the "qtbase" package is reproducible across three different machines
<bavier>mbakke: cool!
<reggggieee>long question: i'm having trouble using 'guild compile <file>' with guix's guile. it runs fine, except that it puts the compiled file in "$HOME/.cache/guile/ccache/2.2-LE-8-3.9/<the path to the scm file>.go", and I don't know what to assign GUILE_LOAD_COMPILED_PATH since it changes for every file I want to compile
<reggggieee>it's on a foreign distro
<lfam>mbakke: I don't think I can do it, but I did ask for something similar a little while ago on guix-sysadmin, so maybe somebody will take care of it :)
<thomassgn>daviid: Hi, thanks for pointers a few days ago! Didn't check back in till now, forgot :)
<didi>Can I install guix in /opt?
<bavier>didi: yes, but you will not be able to take advantage of binary substitutes
<didi>bavier: I am sorry, what is a binary substitute?
<bavier>didi: a copy of a packages build result served from our build farm
<bavier>didi: so, you'd need to build packages locally
<Gareth422>I'm getting a 404 installing Flex, even after pulling. I'm trying to install GuixSD.
<didi>bavier: oic Fair enough. I imagine because the paths are hardcoded.
<bavier>didi: indeed, yes
<didi>bavier: Thank you.
<bavier>np, let us know if you have other questions
<snape>didi: what do you mean by "installing guix in /opt"?
<lfam>Gareth422: A 404 for what resource?
<Gareth422>What should I do to fix this? I tried using --fallback, but when I did that, it tried to install the entire thing from source.
<Gareth422>lfam: I'm not sure.
<bavier>snape: presumbably `./configure --prefix=/opt --storedir=/opt/store` or similar
<lfam>It should print a URL that is returning 404. Can you summarize the URL?
<didi>snape: I mean, not creating a /gnu directory.
<didi>bavier: Indeed.
<Gareth422>, a long hash, flex-2.6.1
<snape>Got it. Thanks :)
<lfam>Gareth422: I think you'll have to build flex from source with --fallback :/
<Gareth422>When I did that, it went for like an hour, building all of the packages from source. I eventually cancelled it.
<lfam>Gareth422: Hmm... let me check if we still have the substitutes for 0.12.0. I'd hoped we would
<Gareth422>How do I make it build just Flex?
<lfam>Gareth422: If you use --fallback to workaround this issue with flex, you will still use binary substitutes for whatever else they are available for
<Gareth422>Huh. Alright.
<Gareth422>Is it 404ing because it's been replaced by a newer package?
<Gareth422>Is it possible to just install the newest packages, instead?
<lfam>--fallback only takes effect when Guix expects to get a substitute but the substitution process fails. If Guix doesn't expect to get a substitute at all, then it will build from source
<Gareth422>Okay. I'll just run with it, then.
<buenouanq>I have to use --fallback all the time - Is this a problem with the Guix repo server?
<lfam>buenouanq: Yes it's a problem, please report it :)
<buenouanq>I visited the FSF once and saw the old Guix laptop - I think y'all have a different one now though.
<lfam>Gareth422: I can successfully download the flex-2.6.1 substitute from ''. AFAICT, this corresponds to the flex-2.6.1 package in the release-0.12.0 build
<snape>didi, bavier: I think there is some work going on to allow Guix to be installed in non-privileged places. There was a talk about it at Fosdem.
<lfam>Gareth422: Does that hash match the one that's failing for you?
<Gareth422>Oh man. It's fallen into the framebuffer void. I'm not sure.
<bavier>snape: yes, it's a WIP
<civodul>ACTION rolls back to Guile 2.2.0 :(
<catonano>civodul: why are youuu rollingg back to guile 2.2.0 ?
<sneek>Welcome back catonano, you have 1 message.
<sneek>catonano, efraim says: only the older macbooks support libreboot. x32 is a hybrid/pseudo architecture of 64 bit kernel and 32 bit memory, in general improvements across the board if you are limited to under 4 GB of RAM
<lfam>Gareth422: Sometimes you end up building everything from source becaues the name service cache daemon caches a lookup failure for It's similar in spirit to <>. So, you might double-check that you can reach and, if not, `herd restart networking`
<catonano>sneek later tell efraim thanks for explaining the old macbooks sense to me !
<sneek>Will do.
<lfam>Gareth422: Sometimes you end up building everything from source becaues the name service cache daemon caches a lookup failure for It's similar in spirit to <>. So, you might double-check that you can reach and, if not, `herd restart networking`
<Gareth422>I can ping it.
<Gareth422>It's weird. It downloads the first few packages, and only starts building after the first failure.
<Gareth422>I think.
<bavier>Gareth422: that's expected behavior
<lfam>Ideally, later packages would not need to be built if substitutes were available
<Gareth422>Why does it build everything, and not just the one package?
<lfam>My understanding is that Guix can't find a substitute
<Gareth422>I see.
<Gareth422>So, Guix uses standard compile flags, so you end up with the same binary by building or downloading, right? It's not like Gentoo?
<civodul>catonano: an obscure issue with "syntax objects" and my expectations about them
<civodul>we'll see investigate later with wingo :-)
<lfam>Gareth422: The idea behind offering "binary substitutes" is that because we account for the full dependency graph when building a package, we can be relatively confident that a package built on our build farm will be bit-identical to what you'd build yourself.
<Gareth422>I see
<Gareth422>Is it possible to pass your own CFLAGS for packages?
<bavier>Gareth422: it takes a bit of work
<lfam>Sure, but not too much ;)
<bavier>Gareth422: you'd need to create your own custom packages that override the CFLAGS used.
<Gareth422>Ah, I see.
<Gareth422>And anything that depends on it, too?
<bavier>Gareth422: not necessarily, depends on what you want.
<bavier>Gareth422: see e.g.
<Gareth422>march=native, in case I wanted AVX for something. Other than that, I can't imagine any situations.
<bavier>Gareth422: you'd probably want to recursively patch higher-level packages to refer to those optimized packages. The package-input-rewriting procedure in (guix packages) can help with that
<Gareth422>Ooh, homoiconicity strikes again!
<Gareth422>The magic of Lisp...
<catonano>civodul: thanks