IRC channel logs


back to list of logs

<mark_weaver>bah, "guix pull" is not getting the glibc security update because is giving us a rather old tree
<mark_weaver>nully: ^^
<mark_weaver>more precisely, that snapshot is from commit 1c7f1fb13351703aa9b6b6da8005481e93ee95c7, the one just before the glibc security update :-(
<a_e>mark_weaver: Should it not be created dynamically?
<mark_weaver>I don't know how it works
<mark_weaver>probably it makes sense for them to update it when things are pushed
<mark_weaver>on the theory that there may be many more downloads than there are commits
<mark_weaver>but I really don't know
<a_e>I see. It might be a post-commit hook with git, actually. Sending e-mails and creating the tarball.
<paroneayea>mark_weaver: I think it may be because of the coreutils issue maybe?
<paroneayea>oh or because of that
<roelj>Is there a label for nonfree licenses in Guix? (Yes, I know they cannot be part of GNU Guix officially)?
<davexunit>roelj: no
<mark_weaver>paroneayea: what coreutils issue?
<davexunit>the git server is messed up in general.
<paroneayea>I'll push my coreutils patch to the list, even though there's no way for me to verify it because I can't build it since my guix package --upgrade didn't finish before I hopped on the train
<paroneayea>mark_weaver: coreutils can't be built right now
<paroneayea>because the patch is unavailable
<paroneayea>so I made a local commit where the patch is put in place
<paroneayea>I'll send a followup to the list with my patch, someone can verify if it works for me
<paroneayea>I won't be able to until tomorrow, most likely
<mark_weaver>paroneayea: I had to change "patch/?id" to "patch?id" (i.e. remove the "/"), but after doing that it works for me.
<mark_weaver>I guess there was some change to savannah
<paroneayea>ah hm
<mark_weaver>hmm, but the hash doesn't match :-(
<paroneayea>sent my patch ot the list anyway, but maybe not needed
<mark_weaver>oh sorry, the hash *does* match. I made a mistake
<mark_weaver>I'll respond.
<Jookia>Woo one more patch still I submit my improved Libreboot patchset
<paroneayea>Jookia: woo woo!
<Jookia>Pretty lucky I still have a machine to use or test these patches- Almost lost my Novena and T400 to rain while I was asleep (left the windows open on a hot day that turned to pour rain)
<Jookia>My plexiglass case is not waterproof so I'm extremely lucky with the Novena. :P
<mark_weaver>hmm. in order to test a proposed workaround for the stale master.tar.gz file that savannah is serving, I'm running "guix pull" for the first time. I find that it wants to build, from source: two different gzip's, two different tar's, libsigsegv, lzip, ed, bzip2, xz, file, diffutils, patch, sed, findutils, gawk, and coreutils. apparently substitutes are not available for these things.
<mark_weaver>I'm very confused
<mark_weaver>I wish civodul were around to explain why this is.
<Jookia>Maybe civodul is playing games with us
<Jookia>Or maybe it's a test
<mark_weaver>oh damn.
<Jookia>You figured it out?
<mark_weaver>it's not because of guix pull, it's because of the "fix" I pushed for the coreutils patch URI fix
<Jookia>Oh gosh
<mark_weaver>time to revert :)
<paroneayea>mark_weaver: uhoh was it my fault?
<paroneayea>I did warn I didn't get to test it yet!
<paroneayea>rebuilds :)
<codemac>figured out my libgmp problem. libgmp is compiled with AVX instructions, and the intel celeron 3205U I have doesn't support them. In this case it's the mulx instruction
<codemac>What are the requirements to run the x86_64 guix port? My gut feeling is that avx should not be required, but that's based on almost exclusively selfish reasons
<Jookia>paroneayea: Looks like Crawl isn't in Guix ... yet
<paroneayea>Jookia: yeah
<paroneayea>Jookia: it's going to be danberous for me once it is!
<Jookia>Heh, I still have to figure out why it's so slow on the Novena
<paroneayea>crawl is slow on the novena?
<paroneayea>.o O (what could be slow about crawl?)
<Jookia>Yeah, I don't know- even in a terminal it seems to lag during autoexplore
<paroneayea>Jookia: there's also this, which is pretty nice, though the default one is opengl accelerated, and i think a lot of the content is nonfree
<Jookia>The nonfree content is bothersome to me, but more importantly I'm kinda stuck with Crawl since it's the only roguelike I can get in to
<paroneayea>but the core software is free at least, and I thiiiink the non-art/graphics content is
<paroneayea>Jookia: crawl is definitely great
<paroneayea>I ascended last year!
<paroneayea>as a gargoyle warrior I think?
<paroneayea>gargoyles are pretty easy tho
<paroneayea>and if you get them loaded up with armor they're nearly impenetrable tanks
<paroneayea>get a good god and you can even get some decent longrange attacks
<Jookia>I've been playing as MiFi, I think I managed to get two runes before I died in the snake pits
<Jookia>Ever since then I've been on a bad spree :P
<paroneayea>Jookia: a chaotic spriggan?
<paroneayea>oh wait bad spree ;)
<Jookia>Haha, nah. One odd thing on NixOS is that installing crawl and crawl-tiles creates conflicts from copying files to /share
<mark_weaver>codemac: can you send mail to about it? the x86_64 port should work on any x86_64 machine, I think.
<mark_weaver>codemac: I'm actually surprised to hear it, because at least a few GuixSD users run it on the Thinkpad X200 with Core 2 Duo processors, which don't support AVX, but maybe we just never used any functions that used the AVX instructions?
<mark_weaver>but I see that you ran into the problem when running "guix pull", so I guess it's unlikely that the X200 users never ran that.
<mark_weaver>so this is puzzling
<Jookia>guix pull, root of all evil? /s
<codemac>mark_weaver: it's a specific gmp function, and I found a thread on their ML about skylake processors specifically not reporting features correctly in gmp.. so it may be that my 3205U somehow tricks the .so to call into a different function than it should. Any suggestions on how to test theories without rebuilding everything? I was thinking about finding a gmp build log, then running the commands manually
<codemac>locally to build gmp + guile out of guix, then see if I can repro + potentially fix
<codemac>I will send a summary to bug-guix
<codemac>mark_weaver: yeah, it looks like archlinux doesn't do --enable-fat for this specific reason:
<codemac>Will file a bug, thanks for the hint about old processors working :)
<lfam>Since fbc5b815cce85a (gem updater) I can't use `guix refresh`: 'guix: refresh: command not found'. Bug filed
<falseking>I do not know how to install boot loader on guix, grub can not be installed, it give me an error
<jamesaxl1>I am falseking
<jamesaxl1>if you have an answer i will be happy
<jamesaxl1>I am falseking
***jamesaxl1 is now known as falseking
<iyzsong>falseking: whats the error? please paste it, also the type of partion table and filesystems will help.
<falseking>iyzsong: I can not, it is on VM, anyway the error is about blocklist and partition type is ext4
<iyzsong>falseking: if it's "can't embed" then, you may use the wrong value (/dev/sdaX) for 'grub-device'. the right one should be '/dev/sda'.
***francis7 is now known as francis
***francis is now known as fchmmr
***fchmmr is now known as francis7
***jamesaxl1 is now known as falseking
<janneke>i'm getting KVM: permission denied when building vm-image
<janneke>using guix on debian
<janneke> solved...
***jamesaxl4 is now known as falseking
<nee`>Hello, I just wanted to note that lua5.1 does not get listed by pkg-config in a guix environment. lua5.2 works fine
<efraim>thanks. I remember leo was working on that a while ago
<Daneel_Olivaw>Is it possible to disable guile auto compile with guix system init safely. If so how. It goes for hours then errors.
<Daneel_Olivaw>The builds always fail. Every single one and it just keeps going.
<Daneel_Olivaw>I just don't want to wait for hours and have it not work like I did last night.
<efraim>did you run guix pull before guix system init?
<Daneel_Olivaw>Didn't think that was necessary for a fresh install. Will try.
<Daneel_Olivaw>I literally downloaded this yesterday so it didn't feel like that was needed.
<efraim>the 0.9.0 tarball might be old enough that the substitutes from hydra may have been garbage-collected
<pizzaiolo>you know what would be cool
<pizzaiolo>if guix used color coding
<pizzaiolo>to highlight the actual package name, distinguishing it from the hash
<pizzaiolo>when updating or installing packages for instance
<pizzaiolo>in the terminal
<pizzaiolo>it would make it visually easier to spot things
<pizzaiolo>davexunit mark_weaver: does that sound doable?
<davexunit>coloring has come up before, and I think the consensus was that we're not going to add colors.
<Jookia>Hmm, why's that
<rekado>we have lots of pretty colours in shell-mode when "guix-build-log-minor-mode" is enabled.
<rekado>and with guix-prettify-mode you no longer see the hashes
<efraim>there's still those of us who don't use emacs though
<petter>and rekado just gave two reasons right there to pick up emacs ;)
<a_e>petter: I think I know now why my encrypted root, unencrypted boot did not work yesterday.
<a_e>I should have set the needed-for-boot? parameter of the file system to #t; it defaults to #f.
<a_e>Something to test next time!
<petter>a_e: ah
<a_e>Reading the documentation enhances our intelligence!
<Jookia>a_e: Will that copy files
<a_e>Jookia: What do you mean?
<Jookia>a_e: I think it'd need to copy your kernel and initrd to decrypted boot
<a_e>I think it would have simply made the /boot partition available.
<a_e>Well, they would already be installed during "guix system init/reconfigure" to /boot.
<Jookia>I think guix system just symlinks them? Unsure
<a_e>There are no symlinks. I think it all happens in /boot/grub/grub.cfg.
<Jookia>Ah, I see. So it'll copy the store to /boot ?
<a_e>No. The grub.cfg contains text that links to /gnu/store/...
<a_e>There is only grub data on /boot, and kernel modules (and fonts and locale data).
<Jookia>But if /gnu is encrypted, how will it access the kernel/initramfs
<a_e>That is the same problem then as with everything encrypted. Apparently grub will be able to ask for the passphrase and to decrypt.
<a_e>But I know nothing about it, so it is all speculation; petter should know better.
<Jookia>Doesn't look like there's code for decryption yet
<Jookia>Would be worth adding
<petter>a_e: i don't have any experience installing on anything other than a Libreboot system
***francis7 is now known as vimuser
***vimuser is now known as fakeuser
***fakeuser is now known as vimuser
<lfam>So, the web page of our git repo <> isn't getting updated.
<lfam>I assume that is related to the `guix pull` staleness problem
<Jookia>mark_weaver: Is there a reason 'guix utils' isn't part of the build chroot environment
<wingo>any objection to me landing the https freedesktop patch/
<wingo>ACTION doesn't remember how code review works in guix
<lfam>wingo: I thought you already had!
<lfam>I assume you've been doing work based on it, and that it's working for you
<wingo>i haven't pushed it, it does work for me tho
<mark_weaver>wingo: no objection, I think it's fine to just push
<lfam>The guidelines for code review are in HACKING
<wingo>k, tx
<mark_weaver>thank you!
<wingo>i have a similar patch for icu4c
<wingo>its downloader redirects from the original url to sourceforge which redirects to https
<wingo>the patch switches it to use mirror://sourceforce
<lfam>wingo: Would it be better update our sourceforge mirror?
<wingo>i don't know how to know if icu4c is a package for which a change like this would be uncontroversial, so if you have thoughts on it they are welcome :)
<wingo>otherwise i mail the list i reckon
<lfam>wingo: You can check what it would affect with `guix refresh -l icu4c`
<lfam>It has 829 dependent packages
<wingo>Building the following 339 packages would ensure 828 dependent packages are rebuilt: ...
<lfam>Can you apply it locally and see if it triggers a rebuild?
<wingo>i have it applied locally, i needed it to do my big local rebuild
<Jookia>Is there a reason that 'guix utils' isn't available in 'guix build'? There's lots of useful stuff
<lfam>I haven't internalized what parts of (source ...) can be changed without triggering a rebuild, especially since that coreutils patch change did trigger rebuilds
<lfam>mark_weaver: If you have a minute, I wouldn't mind some clarification on that
<wingo>ACTION spelunks to see
<lfam>Jookia: Not sure
<wingo>hoo, it quickly goes over my head. not sure where hashing is done!
<lfam>wingo: If you share the diff I can try it out "manually"
<lfam>We might be in trouble if it goes over *your* head ;)
<wingo>my middle name is "you lost me at 'monad'" ;-)
<lfam>Your method of creating the version string is not Guix-idiomatic ;)
<lfam>I applied it to a WIP branch where I just added icu4c to a package and rebuilt. That package and icu4c do not get rebuilt with the patch applied.
<lfam>To clarify, the package actually uses icu4c. I didn't just add icu4c to some random package
<lfam>Let me try a couple more to be sure
<wingo>is it the indentation?
<wingo>that is not idiomatic
<lfam>No, the string-map line. Don't worry, I'm still a Scheme newbie. My judgment means very little
<lfam>Well anyways, with and without the patch the output is the same. I think it's safe. Perhaps send it to the list to be sure
<roelj>Sorry to interrupt, but has anyone run Guix on a raspberry pi? My guix segfautls there..
<wingo>yeah, i just preserved what was there
<wingo>mark_weaver: what do you think the process is for the xorg updates? should it go to core-updates or something?
<Jookia>roelj: Which board?
<roelj>Jookia: raspberry pi model B (the first edition)
<Jookia>GuixSD only supports the rPi2 I think
<roelj>Jookia: And regular Guix? :(
<Jookia>Oh woops s/GuixSD/Guix/
<Jookia>Let me find the reason
<roelj>Here's the backtrace
<roelj>It seems it just cannot even load
<Jookia>roelj: I can't find the reason, but ARMv6 is not supported at all
<Jookia>You're running binaries for a different CPU type
<roelj>Ah, too bad.
<roelj>But it will work with a rpi2?
<Jookia>Guix will, yes
<roelj>Alright. Thanks :) Then I won't have to look further into it.
<Jookia>You should probably use a better SoC than that if you plan on buying one
<Jookia>Since it's likely GuixSD won't run on the rpi2 when it gets an ARM port
<roelj>Which board would you recommend?
<Jookia> Lists a few good ones, though it depends on what you want to do
<lfam>The Allwinner A20 is pretty well-supported in mainline Linux at this point. <>
<lfam>roelj ^
<Jookia>Though, the company that makes those chips actively violate the GPL
<lfam>A lot of people don't like Allwinner though
<Jookia>I'm biased as I use an i.MX6
<lfam>On the other hand, Olimex makes some nice stuff with their chips, and that is open hardware
<Jookia>Free GPU drivers on ARM is an interesting situation
<Jookia>I'll have to try etnaviv when I have time
<roelj>I'd rather avoid Allwinner at this point
<roelj>because of the attitude towards GPL software
<Jookia>the costly i.MX6 is somewhat powerful enough and free enough to use as a computer
<Jookia>Though if you're just going for a server you could just a beagleboard or something
<lfam>I think the beagleboard x15 is interesting. Not sure how it scores on these issues
<lfam>It's also not released yet
<Jookia>It uses PowerVR like all the other beagleboards, so the GPU isn't going to be fun
<Jookia>Would be a good server though
<wingo>lfam: given that the icu4c thing is a build fix that won't cause rebuilds, i push it, just to get it off my plate.
<lfam>Okay, thank you :)
<lfam>Jookia: True. I never think about the GPU since I don't generally use them
<lfam>Many components for signals processing and real-time stuff
<wingo>ACTION gets nervous with many pending patches
<roelj>Jookia: Thanks for the advice.
<roelj>The beagleboard x15 looks interesting.. At this point I'm not using the GPU for anything..
<lfam>I did hear from Olimex that the Beagleboard community was completely unhelpful when Olimex was trying to create a Sitara board. That's a shame, I wish they'd cooperate. But I don't know the full story.
<lfam>Sometimes it's just a matter of not having the (hu)manpower
<lfam>The x15 is also in a different price range. I think the price is estimated to be >$200
<lfam>So, comparable to the Wandboards
<Jookia>around that price range you could get an i.MX6 (wandboard/novena/solidrun) :D
<lfam>Indeed. Although the x15 has the best connectivity that I've seen. Dual GBe, 3xUSB3, eSATA, analog audio i/o, etc
<lfam>mSATA as well
<lfam>Plus all the special coprocessors
<Jookia>USB3 is nonfree IIRC
<lfam>I'd buy it even though I don't have a use for the coprocessors
<lfam>In general or just on Sitara?
<Jookia>I think in general
<lfam>That's too bad
<Jookia>don't know the exact details
<Jookia>ARM is kind of the opposite of x86 in that you can work your way from an open CPU out to the peripherals
<lfam>For now. We'll see what happens when they have the resources of Intel and AMD
<lfam>I'd like to see Trustzone implemented in a way that end-users can sign firmware
<lfam>I believe the USB Armory supports that
<lfam>"The secure boot feature allows users to fuse verification keys that ensure only trusted firmware can be ever executed on a specific USB armory board."
<lfam>I'd like to see trusted computing *for* users
<a_e>wingo: Changing a url does not trigger a rebuild as long as the tarball hash does not change.
<lfam>a_e: I wonder why yesterday's coreutils patch did trigger rebuilds?
<a_e>I did not look at it.
<lfam>Only the URL of a patch in (source) was changed. The hash of the patch did not change.
<lfam>The problem is that for now, users can't build coreutils from source with our package definition
<wingo>maybe the hash is from before the patch
<wingo>ah, patches have hashes too. hum
<a_e>The patches have no hash. They become part of our source code.
<a_e>Sorry, I need to look at it again.
<lfam>In this case, the patch is fetched while building, so it does have a hash in our system. But for some reason, the changed URI is also being accounted for.
<lfam>I wonder if that is desired, or if it's a bug we should fix?
<a_e>The coreutils patch is special, as it is directly fetched upstream. Which makes it different from the patches in out git repository.
<a_e>Strange. So it should behave exactly as a package source.
<lfam>I wonder if users could workaround this by using `guix download` on the patch
<a_e>I have no explanation for this.
<a_e>Especially since a file-name is also given.
<lfam>It looks the issue has resolved itself on savannah. The old URL works again.
<lfam>a_e: But do you think I should file a bug about the patch URL change triggering a rebuild?
<a_e>I am not sure. I would rather expect that I am lacking understanding :-)
<lfam>Me too :)
<lfam>It seems wrong to me. I'd expect a source file of the same hash to be treated the same way.
<a_e>And of the same name.
<lfam>Otherwise, the system is finding state that is not contained in the hash
<lfam>And that must be a bug, right?
<a_e>Maybe you could ask on the mailing list if someone has an explanation.
***jamesaxl3 is now known as falseking