<lfam>sneek: later tell rekado: I successfully built that Guile derivation that's failing for you on x86_64 <lfam>fr33domlover: What do you mean? <lfam>Like, using Guix to install X on a foreign distro? I know some people use it like that <fr33domlover>lfam, I installed xorg-server and xinit as my user (not root); when I run startx, I can en error about the X program not being found at a certain path <fr33domlover>startx looks for /gnu/store/somethinggggg-xinit-1.3.4/bin/X <fr33domlover>but there is no such thing, xorg-server doesn't get installed to that dir <lfam>Have you recently run `guix gc`? <lfam>fr33domlover: Does the bad path at least refer to the right store item? Like, is the hash right? <fr33domlover>lfam, i didn't check the hash but that dir only as two executables, xinit and startx (as expected) <fr33domlover>the X executabele probably comes from xorg-server, so why would it be under xinit's bin dir? <fr33domlover>I don't really care much about fixing this, just curious <lfam>It sounds like a packaging bug <Apteryx>Suppose I boot from another install/live usb, would I be able to chroot into my GuixSD install and do things from there? <Apteryx>I imagine I'd have to run a guix command to initialize all the environment variables correctly? <lfam>I'm not sure, I've never tried that :) <Apteryx>Also, I'm thinking moving from my 10 GB partition to a bigger one, what process would be advisable here? Tar backup of everything? Rsync? Something else? <Apteryx>ACTION looks at the manual to see what kind of command would initialize the GUix system <lfam>Not sure about migrating. LVM would be ideal but we don't support it yet <Apteryx>lfam: But... doesn't this one "installs" stuff as well? <lfam>Yes, it installs the system that you request <Apteryx>lfam: OK. So if the /gnu/store already contains all the items it shouldn't take long? <lfam>Right, if you request something that's already in the store, and you are using the same localstatedir (typically /var/guix), then you will re-use pre-existing items <atw>is there a way to browse the source of an installed package? <Apteryx>atw: I know there is guix download to download the tar or archive which was used to build the package <lfam>atw, Apteryx: `guix build --source foo` will show you the path of the package's source code <Apteryx>atw: Forget what I said about `guix download`. It looks like you have to manually give it an URL. <Apteryx>lfam: Thanks! Didn't know that :). Will it just show the path, or also initiate a "build"? <lfam>Well, it has to "build" the source in order to show the filesystem path. This could involve downloading and patching <lfam>But the package itself will not be built <lfam>However, if you need some software to "build" the source, that software must also come from somewhere. So there's a chance that some other packages will be built or downloaded <lfam>Like, maybe you need Git to get the source of some package that is distributed from a Git repo <atw>lfam: makes sense. I was just wondering if there was an easier way than the standard visit project page and clone/download tarball <atw>I mean, I guess guix will still help me if I do that and then guix environment <Apteryx>Uh oh. "guix package: error: build failed: setting synchronous mode: unable to open database file". Did I do something wrong? <Apteryx>My system really thinks it's out of memory, even getting message on the command line. But df -h reports 74% usage. How strange! <Apteryx>Could hard links cause something like that? <amz3>where do guix people publish their gpg key? <amz3>Aptertyx, maybe you reached the max number of inode... <sneek>Welcome back rekado, you have 1 message. <sneek>rekado, lfam says: I successfully built that Guile derivation that's failing for you on x86_64 <rekado>sneek: later tell lfam Thanks for trying to build that Guile derivation. Maybe the test fails because the store is on NFS…? <Sleep_Walker>it seems that I somehow diverged and my glib is being recompiled each time - can I somehow find why I diverged? what dependency is different from the one on hydra? <Sleep_Walker>it wouldn't be that bad but glib compilation fails for me on test phase on timeout on 642026 test <Sleep_Walker>I want to prepare GuixSD from openSUSE through guix system init once again <efraim>hmm, i'm not sure what could cause that <Sleep_Walker>I need 1] subtree of dependencies and 2] be able to say which hash is available on hydra <janneke>i would certainly like to have that feature: dependency x has changed from y to z <rekado>Sleep_Walker: are you using Guix from git on openSUSE? <Sleep_Walker>I have daemon from the release (installed as package), I'm running from git but I also run `guix pull' <efraim>i switch my systemd daemon from exec'ing /gnu/store/...guix-0.11/bin/guix-daemon to /root/.guix-profile/bin/guix-daemon <efraim>that way I can add `guix pull && guix package -u` to root's cron <rekado>ACTION still compiles gcj in an arm VM ***Digitteknohippie is now known as Digit
***dootniz is now known as kragniz
<rekado>marusich: it’s because it includes *all* TeX packages on CTAN. <rekado>marusich: apparently it’s hard to split this up and install to separate directories without breaking it. <marusich>I see. Well, it's not too bad. Takes less time to download than to build some things :) <efraim>i think i need to hit binutils for my symbol redirection thing, I've been staring at gcc and glibc and nothing's popping out at me <Sleep_Walker>I altered source code of the test under the hands of build daemon <Sleep_Walker>so I finally passed glib build \\o/ (and haven't altered hash) <efraim>if i'm right this time, then my symbol redirection problem would've been solved if i was working against core-updates like i'm supposed to, since it has a more recent binutils <bavier1>does anyone know what might cause "assertion 'GDK_IS_PIXBUF (pixbuf)' failed"? <ng0>this icecat is very unstable.. nothing I ever used has crashed so often in one month <Apteryx>Wooh. Migrated from my small 10 GB to a 30 GB partition using rsync. <Apteryx>I didn't figure how to chroot into Guix (being mounted at /mnt/guix made the symlinks/hardlinks point to the wrong absolute locations). <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, rekado says: Thanks for trying to build that Guile derivation. Maybe the test fails because the store is on NFS…? <Apteryx>Since I had only changed partition and label name I could pause grub, edit the boot parameters (basically just change from my old partition label to the new one), and it worked! <lfam>sneek: later tell rekado: I actually built it on btrfs and then installed it onto ext4. Heh, maybe you *can* blame it all on NFS ;) <lfam>Apteryx: Tricky maneuver :) <lfam>ng0: I've heard that complaint from several other people. I wonder why it's crashing... <Apteryx>Yes, I'm glad I didn't enable luks encryption. Was tempted too, but this would have made things more complicated. <ng0>lfam: maybe it's just that firefox revision <lfam>GuixSD needs an LVM / LUKS champion <lfam>ng0: Maybe... but I wonder what's going wrong? Is the crash some remotely exploitable bug? <ng0>bugzilla of mozilla would know <lfam>Another maybe... I get the sense that Mozilla is nursing their core bugs from the early days... No time to nurture new bugs <lfam>I see open bugs from more than 10 years ago on their bugzilla. Bugs that I found because I'm still suffering from them <Apteryx>If I run "guix system reconfigure", will my user profile be preserved? Or I will need to re-install (re-link) the packages I had manually installed there? <lfam>Apteryx: It won't effect your user profile at all <lfam>Except in the sense that packages from your user profile might be interacting with some "system packages", so it's possible to see different behavior <lfam>For example, if one of your packages depends on some kernel feature that changes <lfam>I can't predict the size of the deal. In practice, it's a big improvement over the old-school "mutate /usr" method <lfam>Plus you can rollback if something goes wrong <Apteryx>In that sense it's quite a big deal! <lfam>Agreed, it's why I was inspired to get involved <Apteryx>So I'll update my partition information in my /etc/config.scm and run "guix system reconfigure". This should update my grub on disk, rigth? <Apteryx>lfam: Thanks for helping making this a reality! <lfam>I got involved well after it was already a reality. Now we polish and grow :) <ng0>imagine you are in the middle of an update and power goes out. won't even bother the system update, just start again <Apteryx>I'm attracted to GNU Hurd recently. I'd like to start working on it shortly. It will be a great companion to Guix. <lfam>Right, update the bootloader (and possibly the file-systems) section of your configuration and then reconfigure. Make sure it's right... GRUB is how we achieve system rollback so things will be difficult if it breaks <lfam>ng0: And you might even have some of the updated packages still cached in /gnu/store! <ng0>Apteryx: actually hurd is being worked on <Apteryx>ng0: I know, they are quite active in Debian Hurd for example. <Apteryx>I saw guix was already Hurd compatible. <ng0>if it is, this is very recent. I did not read the last updates manolis(?) gave <lfam>phant0mas is the person to ask :) <Apteryx>ng0: There's a page on Phoronix, see "GNU Guix Package Manager Ported to GNU Hurd" <phant0mas>Apteryx: yes we can cross-build packages for the Hurd and we can build packages on the Hurd <phant0mas>but because of ongoing work on both projects, things tend to break now and then <ng0>Apteryx: i don't read phoronix. i saw the last emails on our mailinglist, that's all <lfam>We need some Hurd system tests in our test suite :) <phant0mas>and there are some hacks included in order to make it work nicely:-( <phant0mas>for example with the latest hurdish glibc, the cross-toolchain broke again <phant0mas>I can help you setup guix on debian/hurd if you are interested but prepare to get your hands dirty :-) <Apteryx>phant0mas: OK. I just recently moved over to Guix so I'll still need some days to set my system up, but I'll ping you when I'm there! <Apteryx>I had already boot a recent image of Debian Hurd with Qemu, so that part should be easy at least. <phant0mas>yes this should be easy, and the latest versions of Debian Hurd are the most stable in ages! <phant0mas>the Hurd developers are doing an awesome job on improving the system <phant0mas>Apteryx: ping me when you are ready to join the dark side :-) <Apteryx>Have to head to work for now... later, guix! <lfam>I wonder if we should try packaging tcc from the Git repo. They haven't released in 3 years but development is very active <lfam>Hm, building HEAD of the development "mob" branch, it fails almost immediately due to conflicting type definitions <ng0>i have a branch with this but ran into problems <ng0>so, yes I agree we should <ng0>or at least package it, and preserve the old one, keep two versions around <ng0>"ran into problems" so no, been a while since I tried :) <ng0>I think I didn't use the mob branch though <ng0>i mean, mob is a branch on the very active repo <ng0>i used the stable head i think.. or <ng0>i should search for it <ng0>(commit "c948732efaf823f36d05608fe716bfcc4a98b70c")) <lfam>That's on the "mob" branch <ng0>I called it tcc-next and inherited tcc <lfam>I guess that somebody will work on the tcc package if they care about it. I read the mailing list for a while and it seems chaotic <ng0>yep.. I didn't fix this up because it's one of those packages I do not care about, one of the community-service packages I have <ng0>i hope mob gets back into stable at some point, used to happen before <lfam>efraim: Marius sent an update to the list. We could apply it ourselves if you feel impatient :) <lfam>No harm in applying it, I think. I'll do it now <efraim>i've been staring at my other screen all day, trying to get aarch64 working :) <efraim>LFS doesn't seem so scary anymore, and I find myself yelling at debian patches more than I should <lfam>efraim: I pushed the django update <janneke>that must have been a lot of work... <lfam>janneke: What do you mean? :) <lfam>I *have* thought about rotating the Monty Python cast through the American presidency... <janneke>i guess i'm just showing my history of 10+ years eloving+pushing python and losing interest in python, moving to guile <lfam>Everything is a lot of work, right? Otherwise you are just standing on some giant's shoulders :) <ng0>I wished the sample editor included in milkytracker was anything like renoise one <bavier1>not interested in helping with a "beta toy" <paroneayea>trying to figure out where to try hosting an image that I build here from first <bavier1>not terrible, but clear that they don't appreciate anyone wanting to play with their software internals <bavier1>I approached this package wanting to help clean some things, but now I'm a bit shaken up actually <paroneayea>bavier1: that was a pretty rude response from that person, disappointing <sneek>rekado, lfam says: I actually built it on btrfs and then installed it onto ext4. Heh, maybe you *can* blame it all on NFS ;) <rekado>I always forget that many free software projects are really hostile <paroneayea>I guess I ought to be looking at something openstack based still, probably <janneke>mark_weaver: as you reviewed my mingw v9 patch series and had significant input that lead to v10, i assume you are the most probable suspect to apply them <paroneayea>probably the best way to be able to generate an image that can be used. <janneke>mark_weaver: i try to be patient and respect the fact you're terribly busy...but it's been a while (8 weeks?) and i'm getting a bit anxious <ng0>handbrake sounds like your average, sad community. <ng0>yeah I've read their log <davexunit>I asked j45 not to disparage people and to be more welcoming, they insisted that calling someone's project a "toy" and not "real" weren't insulting, and everyone agreed. <davexunit>I don't think we'll get any handbrake devs using guixsd any time soon, sorry. <davexunit>I've very well burnt that bridge, but I'm just sick of this being the norm in free software. <efraim>it finally clicked with me that gcc-boot0 shouldn't try to call /gnu/store/eeeeeeeeeeeeeeeeeeee/bin/bash when checking for egrep <efraim>thats what i've been saying every time it goes by the screen <ng0>davexunit: no loss.. <ng0>thanks for trying :) <efraim>it looks like gcc checks for grep and for egrep <rekado>davexunit: gah, what the … I know I won’t be using handbrake. What a terrible developer community. <efraim>are we covered against the tar CVE? <davexunit>"so if you want to keep fucking around with it, j45 isn't gonna keep helping you." <davexunit>"i suggest you use a *real* *stable* linux distro instead of this Guix "beta" toy" <rekado>I’m having a problem building GNU pascal (WIP). It’s a boring “permission denied” error but I can’t seem to reproduce it in an environment. <davexunit>rekado: is it reproducible when that environment is in a container? <rekado>make[4]: Entering directory '/tmp/guix-build-gnu-pascal-4.3.5-1.c0231319f.drv-0/gcc-4.3.5/gcc/p/rts' <rekado>m4 ./make-acconfig-h.m4 "configure.in" > acconfig.h || { rm -f acconfig.h; false; } <rekado>/gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/bash: acconfig.h: Permission denied <rekado>I haven’t tried a container yet. <bavier1>yeah, I'm torn between dropping the handbrake patch or making it work despite it all <rekado>when I run that m4 command in the specified directory on the remains of “guix build -K” I get no error. <ng0>bavier1: sooner or later we come to realize how all other distros happen to carry around aptches which never made it upstream.. I don't know what the problem with handbrake here is right now, buit I think patches are okay. <lfam>So, besides trouble with Hydra itself, is there anything left to do for this core-updates cycle? Does anyone care about the remaining failures? <rekado>there are failures for ardour and mod-host relating to fftwf <rekado>they cannot find a library that should be provided by fftwf <rekado>I cannot take a look at this right now, but I’ll try to debug this soon. <rekado>but I don’t think we should delay merging core-updates for this <lfam>rekado: Does the problem persist when you revert the recent fftw update? <lfam>Or is fftw not the same thing... <lfam>It would be great to release with all of our big graphical applications working but I agree that it shouldn't block it if everything else is ready <lfam>Maybe we should try applying the dozens of QEMU bug fix patches that have accumulated, too. <lfam>Especially since we use QEMU to build the release <lfam>I wonder if anyone else has tried upgrading their systems to core-updates? Seems like a good way to get motivated to fix things :) <lfam>It would have caught that annoying glibc locale issue that we released 0.11.0 with... <rekado>I really need to take time to back up everything, repartition and then reinstall. <lfam>That issue actually led me to run my GuixSD system with a different glibc since 0.11.0. <lfam>Looking forward to using substitutes again <ng0>otoh, what could go wrong.. I'll boot the test computer which already runs from git <rekado>ironic that using LLVM on this machine turned out to be so inflexible <rekado>I’ll copy my stuff to an external disk tonight and try to reinstall tomorrow. <ng0>i'll take a break from wathcing movies & cutting beats, and build the system from core-updates <lfam>rekado: Ah... that *is* ironic! Not what I would have expected <lfam>Thanks ng0! Almost everything has substitutes at this point. I'm just hoping to motivate people to fix the last remaining failing leaf applications. <efraim>i tested that everything I have installed builds on core-updates ;) <lfam>I recommend `guix package -u .` :) <lfam>I've been running all my Guix and GuixSD installations on it for a few days now. Seems fine so far! <lfam>Ah, the recent cups-minimal update requires many rebuilds <lfam>I started a new evaluation <efraim>I always loved bzless to read the logfiles of the builds, i JUST learned about bzgrep <lfam>My Vim opens the compressed log files transparently, very nice :) <lfam>Does the Guix Vim lack this feature? <lfam>Hm, it would have been worth it to merge master -> core-updates before starting the new evaluation. I wonder if I can cancel it <efraim>it'll also cancel everything from previous evaluations that is carried into the current evaluation <lfam>Hm... well, it's just the "leaves" of the graph. No big deal <lfam>No big deal to not have merged, that is <ng0>I wonder what the impact of blobs in average consumer hardware is. I mean, linux-libre. I wonder wether I want to use linux-libre (and therefore sticking to my goal of using as much of guixsd as possible) or linux for a system for people to use where ever they go. What's important is wifi and gpu. I experienced on desktop systems that gpu can be difficult, but laptops worked so far. incompatible wifi can be <ng0>theoeretically fixed with a wifi usb dongle (which is unfortunate, but should work).. but I'm still not entirely convinced to pick a side, on the hardware support in all corners of the world list.. <ng0>why does this always fail recently: <ng0>guix system: error: build failed: some substitutes for the outputs of derivation `/gnu/store/f582fw51y6mm2jwavb4njzr7saz49ikm-module-import-compiled.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source <lfam>ng0: I believe those files are not created deterministically. Is there another message about a hash mismatch? <lfam>In any case, it always works for me when I use --fallback <ng0>fallback is what I use here too <efraim>we also got one for bind ~45 minutes ago on oss-sec <lfam>I can do the bind update now <lfam>The tar update will be annoying if we have to graft it... <efraim>tar sounds like it would go nicely with a "bump tar and ungraft everything" branch <civodul>tar is a core thing so that would be the next core-updates <civodul>the timeline shown in the report on oss-sec was kinda scary <civodul>the bug had been discovered at the beginning of the year IIRC <lfam>Sigh... so many core projects don't get the attention they deserve. I think it's a clear example of what economists call a "market failure" <civodul>though i can understand the viewpoint of the tar maintainer <civodul>after all, this bug hurts only if you're taking risks already <lfam>Yes, I understand too. But I wish the advisory would be publicized sooner <lfam>Yeah, what the heck is going on with icecat? Everybody is complaining and we still don't know what the problem is :/ <lfam>It seems like it crashes so often that one could trace it <lfam>The trace might not end up being too big <davexunit>so reproducing it is hard... it might take minutes or a couple of hours for it to happen <ng0>sometimes it's okay for days here <lfam>Yeah, but I think it could be worth it... <lfam>Especially in such a sensitive application <rekado>I can reliably crash it on a twitter feed with embedded gifs <lfam>My naive choice would be strace <lfam>Great, sounds like an easy reproducer <davexunit>I don't know if strace will reveal the issue <ng0>it happens with videoplayback here, or with images <rekado>(or do I need to build the closure with debug symbols?) <lfam>I view Twitter Debian's Firefox and it's stable <lfam>...Twitter with Debian's.... <rekado>yeah, Fedora’s Firefox is stable too. <davexunit>if it seems to be video and images, perhaps there's a bad call into a library <ng0>but do they unbundle what we unbundle? <lfam>My worry is there is some bug that could be exploited remotely with enough effort <davexunit>we're actually safer because we can't reliably use the web <lfam>I pushed the BIND update, thanks for the tip efraim <lfam>I think of each bit of strange behaviour as an invitation for bad people <davexunit>good luck hacking me, my browser will crash first! <lfam>A common argument for bundling is "we fixed bugs in the library and upstream hasn't released the fix yet" <lfam>davexunit: You do see my point, right? :) <lfam>It's hard to tell on the internet <lfam>I remember reading commentary on that terrifying libarchive analysis a few months ago, and FreeBSD users were talking about how often the system update component that uses libarchive used to crash... <ng0>lfam: second question: and if we unbundle comparable, how do our libraries differ from debian/etc <lfam>Speaking of which, why are we still doing `guix pull` over HTTP? I don't remember if there was a good reason that Savannah's Git repos still aren't served with TLS <lfam>ng0: A tedious task to compare bundled libraries <lfam>I better re-read the "Trustable guix pull" thread <ng0>so far core-updates reconfigure just builds fine <lfam>Yay. There should be substitutes for everything affected by the cups-minimal update within several hours <efraim>lfam: don't forget the bind in isc-dhcp <lfam>efraim: Actually, I have to AFK in a few minutes. Can you do it? Or somebody else? <lfam>Maybe we should update isc-dhcp too? <civodul>amz3: the libgit2 bindings seem to be making good progress, no? :-) <lfam>Okay. Somebody else will do it, or I'll do it in some hours :) <rekado>trying to crash icecat to debug it but it simply won’t comply. <rekado>does anyone have a URL that reliably crashes icecat? Mine won’t work. <ng0>spend some time on youtube or other video streaming sites <ng0>or some infinite scroling website <ng0>now the recomnfigure seems stuck <ng0>I do it via ssh, so it could still be going.. <ng0>udisks2 is making no progress in download anymore <rekado>finally got it to crash, but lacking debug info I still don’t know what’s going on :) <rekado>hoped it would be a little more obvious. <rekado>the error seems to be triggered by cairo. <ng0>hm... newest firefox brings in an optional experimental cairo(?) replacement, if I remember it correctly. cairo is 2d rendering, right? i think it won't help us for some more versions though <rekado>in the code there’s an ifdef to use either the internal cairo or system cairo. <rekado>when you search for “cairo” in about:config it should return two keys: “gfx.canvas.azure.backends” and “gfx.content.azure.backends”. <rekado>I set both of them to “skia” instead of “cairo” just now and a page that crashed Icecat twice in the last 10 minutes no longer does so. <ng0>yeah that was it. skia is in ff49.x an option <ng0>I don't know how well it's supported in 45 <ng0>gentoo started providing this new use-flag, that's how i noticed last month on the other system