IRC channel logs


back to list of logs

***jonsger1 is now known as jonsger
<tune>I'm having some problems with zathura.
<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
<tune>what's up with that
<tune>I just added libjpeg
<bavier>tune that seems strange
<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
<brendyyn>you mean compilation?
<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>bavier: mine built successfully
<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
<tune> here are errors for both a pdf and an epub, although I think it's all basically the same as before
<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>davidl: it should be enough.
<brendyyn>I think -dev packages are a distinction from debian which splits out header files
<davidl>brendyyn: ok, thx.
<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>hey janneke!
<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>Hello all!
<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.
<brendyyn>Do you mean guix on a foreign distro?
<g_bor>hello guix!
<g_bor>diffoscope fails on core-updates for me, with this test failure :tests/comparators/ AssertionError
<g_bor>any idea?
<Tirifto>brendyyn: Yes; I am on Parabola.
<brendyyn>Tirifto: basically there are a couple directories you need to delete, that's all
<brendyyn> like /gnu and /var/guix
<Tirifto>brendyyn: Oh. Is there a complete list, or can I reliably deduce one from the installation guide?
<brendyyn>from the installation guide i guess.
<brendyyn>There might also be a systemd file
<brendyyn>and in your home directory there might be .guix-profile and .config/guix
<brendyyn>and /etc/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
<janneke>hope you'll be back online soone
<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>Hi guix
<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
<pkill9>if that's what you're asking
<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>You might want to look at guix archive
<brendyyn>wow 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
<nly>Thanks all :-)
<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
<efraim>from xcb
<ng0>brendyyn: no
<ng0>guix is able to use other locations
<brendyyn>oh ok, sorry nly
<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
<brendyyn>why do you lose substitutes?
<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>civodul: You around?
<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>mbakke: hi!
<civodul>1127 rebuilds for each architecture or total?
<mbakke>civodul: Sorry to interrupt your Saturday! :)
<civodul>heheh :-)
<civodul>for each architecture it seems
<mbakke>civodul: Yes, and x2 for core-updates.
<civodul>that was 24h ago?
<civodul>well yes, i guess we should revert
<civodul>at least for mesa
<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: . 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>Laalf: would the libvirt service be helpful to you?
<civodul>it takes care of generating the libvirt config file
<Laalf>civodul: no. this does not create /etc/libvirt/qemu.conf
<civodul>maybe we should fix that?
<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>oh ok
<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
<Laalf>civodul: i found it, not much happened there and i didnt want to necrobump it then. . the patches are not a problem for me anymore.
<mbakke>civodul: Fix pushed!
<civodul>mbakke: awesome, thanks!
<civodul>that was fast!
<civodul>so lemme see hydra
<civodul>Laalf: doesn't tell whether the 'simple-service' suggestion work
<civodul>could you follow-up on that? (on the list)