***jonsger1 is now known as jonsger
<tune>I'm wondering if it's related to having it installed in config.scm in the past and then moving it to a manifest file <bavier>tune: seems like it can't find jpeg symbols? <tune>bavier: what does this mean? <bavier>tune: could you install "libjpeg" and try again? <tune>yes, thanks for the tip. I'll try that <tune>some unrelated package is building for some reason even though I'm reinstalling from manifest without guix pulling again... but when it's done I'll let you know if it works <brendyyn>does building guile-fibers hang for anyone else here? <brendyyn>ok maybe im just impatient. one of the tests finished after a few minutes <tune>so I ran updates, rebooted, added one thing to my manifest and tried to update again (without guix pull) and now it's building cataclysm-dda <bavier>brendyyn: same here, one of the tests took almost 5 minutes to complete <brendyyn>I'm getting warnings about many things failing to compile <brendyyn> ;;; WARNING: compilation of /gnu/store/1mr5izrbxwd7cbq8m1xrqm45rzkibpsj-guile-2.2.3/bin/guild failed: <brendyyn>;;; WARNING: compilation of /tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0/./tests/channels.scm failed: <bavier>brendyyn: from auto-completion, I'm wondering if guile is trying to write to $HOME/.cache/guile/ccache <bavier>in the build container, $HOME doesn't exist <bavier>right, s/completion/compilation/ <bavier>probably harmless, but not ideal <brendyyn>does it mean everything is being intepreted from scheme code, or it doesnt make a difference? <bavier>it seems at least the test code might be running interpreted <bavier>well, no, it's still being compiled, just not cached <brendyyn>is that intentional as a part of the test or a bug? <bavier>oh, and then it segfaults in tests/speedup.scm ... :( <brendyyn>i accently Ctrl-C'd my build so i started again. ill see if it happens <brendyyn>You should post your log as a bug report <brendyyn>is there a way i can get guile-readline with guile-next? ***dfsg is now known as resttime
<tune>bavier: okay, libjpeg should be installed now and zathura is still broken <davidl>I have a program I want to package that lists libzip-dev as a dependency, and guix already has libzip, but not libzip-dev on hydra. What's the difference? and would libzip be enough instead of libzip-dev? <brendyyn>I think -dev packages are a distinction from debian which splits out header files <janneke>hey civodul! on my core-updates-next, i have guix build --system=i686-linux bootstrap-tarballs <janneke>i am now testing a newer version with a debug command removed but did not want to push yet, we could also make that correction later <civodul>please let me know when you'd like me to proceed <civodul>then i can build them independently and we'll see whether we get the same result <civodul>note that we should force the system type when on x86_64, using #:system "i686-linux" where appropriate <janneke>ah, right i didn't look at that bit for the bootstrap tarballs -- i'll keep you posted <janneke>i may need some help with sprinkling of the #:system force, but will have a look <Tirifto>Does someone know whether or not there's is a script (or a guide) to uninstall Guix? <Tirifto>I have a broken lingering installation because of which the installation script will terminate shortly after start. <g_bor>diffoscope fails on core-updates for me, with this test failure :tests/comparators/test_berkeley_db.py:33: AssertionError <brendyyn>Tirifto: basically there are a couple directories you need to delete, that's all <Tirifto>brendyyn: Oh. Is there a complete list, or can I reliably deduce one from the installation guide? <brendyyn>and in your home directory there might be .guix-profile and .config/guix <brendyyn>It's only a small list, i'm not sure anyones gone and written it down <brendyyn>I'm having trouble with `guix offload test`. It keeps telling me my GUILE_LOAD_PATH is unset. it doesn't seem to evaluate my .bashrc <ng0>there might also be an uninstallation procedure if you installed it with a different PM <ng0>for example portage would do emerge -p --depcheck guix and then emerge -c guix iirc <civodul>g_bor: are there more details available? <efraim>bavier: in regards to yesterday's question about go and armhf-linux, go@1.4 supports armhf and not aarch64, but the ThunderX doesn't do armhf <efraim>we have a couple of packages that rely on armhf for their aarch64 variants, java one of them, if it ever builds on armhf <rekado>FYI: I’m without internet until at least next Tuesday. <janneke>rekado: whoa, spoken as a true wizard! ;-) *civodul investigates the NSS test failure on core-updates <OriansJ>rekado: enjoy the peace and silence, it is far too rare these days <rekado>OriansJ: I doubt there’ll be silence in the time in between connections. Boxes need unpacking :) <rekado>but the end game is peace, of course :) <OriansJ>rekado: silence is never more than a 80db ear protection away if you plan correctly ^_^ <janas>Does "guix package --show=" list all available versions for a package? And if not, where would I go to find older versions of packages? <Laalf>can you mount debugfs under guixsd? <Laalf>i cant see it without root. i am an idiot <ng0>janas: older versions are usually discarded in guix, only to be retrieved by going back in the git history <ng0>so package --show= lists all currently available versions of a package <ng0>which usually is just "current"/latest release/some version control commit in some cases and in other cases more than 1 version and variant <janas>ng0: Thanks for the info, i went to savannah and I was able to find what I was looking for (qt 5.9.x). <nly>How can i tell my guix to search for pkgs in a /store in some directory other than /gnu/store, i thought --load-path=/mnt/gnu/store should do it? <brendyyn>nly. --load-path is for loading scheme definitions for packages <pkill9>nly: best way is to bind-mount /gnu/store onto whatever directory you want the store in <brendyyn>nly I think you might not be able to do the thing you want. guix is only able to use /gnu/store, but i think it's possible to import packages that are outside it <nly>I already have a /gnu/store(x64 linux) on a different hdd that has packages i want, in booting a different (x64 linux) system can i use it instead of downloading everything again <brendyyn>wow fsf.org has a popup donation window noow -.- <nly> it makes sense though to not allow ad hoc /store for the strong reproducible guarantee :-) <roptat>nly: a bind mount looks like a good idea though <roptat>(if that's another hdd in the same computer) <nly>Thanks i shall try that <nly>It is in the same computer <efraim>i'm getting a core dump when building swig on aarch64 on core-updates <mbakke>Uff, it seems our Python2 package is missing a library on core-updates. <mbakke>Hm, why does python2 depend on python3. <efraim>i think it's from python-minimal in xorg.scm <ng0>guix is able to use other locations <ng0>gnu/store is in some of our patches, but that's it <ng0>if you use some other location that /gnu/store you lose the guix-specific central substitutes.. so that's "impossible" depending on your view <ng0>you could still build your own substitutes. you just can't use /gnu/store substitutes anymore. there's multiple reasons which become obvious after reading the source for a while <mbakke>bavier: The LLVM change caused ~1127 rebuilds. <mbakke>I wonder if we should revert it and stop Hydra. <mbakke>Any objections to reverting the LLVM commit? I hope users who pulled it don't have to build LLVM and Mesa just to "guix pull" again. <mbakke>It could be worth saving some of the build jobs in the latter case. <civodul>1127 rebuilds for each architecture or total? <mbakke>civodul: Sorry to interrupt your Saturday! :) <mbakke>civodul: Yes, and x2 for core-updates. <civodul>is there an easy way to get Mesa use the previous LLVM? <civodul>maybe we can add llvm-without-rtti and have mesa use it? <mbakke>civodul: Good idea, I'll try that. <civodul>we'll still have to cancel most of these builds but we'd sorta have our cake and eat it too <Laalf>so i created a custom libvirt for not quite my needs you can see here: https://yourpart.eu/p/XErk7Lmpoe . this creates /run/current-system/profile/etc/libvirt/qemu.conf. this does not work though since libvirt probably expects the config file to be in /etc/libvirt. can someone help me with that? <civodul>it takes care of generating the libvirt config file <Laalf>civodul: no. this does not create /etc/libvirt/qemu.conf <civodul>in the meantime you can extend etc-service-type to create that file <Laalf>i have that problem for months. a simple service doesnt work, an etc service doesnt work and that package doesnt work <civodul>i guess we'd need to discuss in detail what doesn't work <civodul>was it discussed on the mailing list already? <Laalf>civodul: etc service will link to /etc/libvirt which exists already. it has been kinda discussed on the mailing list 2 months ago or something <civodul>my guess is that we should fix the libvirt service to create that file <civodul>i'm no libvirt expert though, so that's something that should be mailed to bug-guix IMO <Laalf>"nvram = /run/current-system/profile/share/firmware/ovmf_x64.bin \n user='1000'" should be the contents of /etc/libvirt/qemu.conf. nix uses qemuverbatimconf or something. <Laalf>i will see if i can find the mail in the mailing list ***D4RK|R4Z0R|Z|| is now known as D4RK|R4Z0R|Z
<civodul>could you follow-up on that? (on the list)