<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>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 <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? <roelj>Is there a label for nonfree licenses in Guix? (Yes, I know they cannot be part of GNU Guix officially)? <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>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 <mark_weaver>paroneayea: I had to change "patch/?id" to "patch?id" (i.e. remove the "/"), but after doing that it works for me. <paroneayea>sent my patch ot the list anyway, but maybe not needed <Jookia>Woo one more patch still I submit my improved Libreboot patchset <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. <Jookia>Maybe civodul is playing games with us <mark_weaver>it's not because of guix pull, it's because of the "fix" I pushed for the coreutils patch URI fix <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: 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 <Jookia>Yeah, I don't know- even in a terminal it seems to lag during autoexplore <paroneayea>Jookia: http://te4.org/ 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>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 <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 bug-guix@gnu.org 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. <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>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 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 ***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>to highlight the actual package name, distinguishing it from the hash <pizzaiolo>when updating or installing packages for instance <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. <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! <a_e>Reading the documentation enhances our intelligence! <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 <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>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 <lfam>The guidelines for code review are in HACKING <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>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 <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? <roelj>Jookia: raspberry pi model B (the first edition) <Jookia>GuixSD only supports the rPi2 I think <roelj>Jookia: And regular Guix? :( <roelj>It seems it just cannot even load ld-linux-armhf.so.3 <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>But it will work with a rpi2? <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>Though, the company that makes those chips actively violate the GPL <lfam>A lot of people don't like Allwinner though <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 <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>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>Plus all the special coprocessors <lfam>I'd buy it even though I don't have a use for the coprocessors <lfam>In general or just on Sitara? <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>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