IRC channel logs


back to list of logs

<civodul>rekado: i think i'm done with NEWS on version-0.16.0
<reepca>Hm, where could I find documentation for bournish?
<civodul>reepca: there's none!
<civodul>but there's also very little to know about it
*civodul -> zZz
<apteryx>lfam: hahah, I think the problem was that my arguments list was not backquoted but quoted...
<apteryx>I'm silly.
<lfam>I'm glad you figured it out :)
<apteryx>soon I can finally observed the schematic of my thinkpad ;-)
<apteryx>Hmm; now I get runtime errors such as: DEBUG: Failed loading cannot open shared object file: No such file or directory
<apteryx>or DEBUG: Failed loading cannot open shared object file: No such file or directory
<apteryx>and ERROR: Cannot show open file dialog: no GTK library available.
<apteryx>My program has been wrappend using glib-or-gtk-system-build's glib-or-gtk-wrap wrap-all-programs... Any ideas?
<lfam>apteryx: I usually run the program with `strace -f` to see where it's looking
<apteryx>good idea
<apteryx>lfam: I'm puzzled; I don't see anything when using: strace -f -e open openboardview
<apteryx>I'd expect the .so libraries to be opened when loaded
<apteryx>(at least see an attempt to!)
<lfam>Hm, off the top of my head I don't remember which syscall would be used. I just do `strace -f foo` and look for what I need
<apteryx>yeah, it just outputs continuous stream of output which makes it near impossible to investigate. I'll try spitting it to a file.
<apteryx>lfam: it's using and SDL method to load the library: lib = SDL_LoadObject("");
<lfam>apteryx: Hm... I guess you have to figure out how that method works and why it's not looking in the right place. Or, maybe you can patch the source code to an absolute path
<apteryx>lfam: yep, I'm investigating through the sources
<lfam>Also would be worth checking the mailing list archives to see if this has been mentioned before
<apteryx>trying to figure out how to get ggtags allow me to follow symbols coming from headers in $C_INCLUDE_PATH
<apteryx>will do. Thanks again for your help
<apteryx>regarding my question about GNU Global header files navigation (ggtags mode in Emacs), I found that I could simply link the entry in my C_INCLUDE_PATH to my project dir, and run gtags in the project dir to pick those symbols. It's detailed in the GNU Global manual.
<apteryx>OK, I've found that in sdl2 the SDL_LoadObject function is defined in the file ./src/loadso/dlopen/SDL_sysloadso.c...
<apteryx>it just hands off the request to dlopen
<apteryx>i.e., handle = dlopen(sofile, RTLD_NOW|RTLD_LOCAL);, where sofile is a string such as "".
<apteryx>hmm... The ELF binary has a RUNPATH defined, which is searched by dlopen, but it doesn't seem to include GTK: objdump -x /gnu/store/gpwds7haa6hd8n5sc18gybikjx5klbma-openboardview-7.3/bin/.openboardview-real | grep -i runpath | grep -i gtk
<emacsomancer>hello guix, I know I've asked about this before, but I'm having trouble again on a foreign distro with the "failed to install locale" issue, even after installing "glibc-locales"
<brendyyn>im getting that now even on guixsd
<brendyyn>its madness
<emacsomancer>brendyyn: but it does create issues in some cases, so I'd like to resolve it
<brendyyn>I'm not sure when it fails
<brendyyn>emacsomancer: ok so the first thing is to check is if you have your .bash_profile configured correctly
<brendyyn>Are you using a DE like KDE?
<emacsomancer> brendyyn: yes, I'm using KDE
<brendyyn>ok i also have kde on arch with guix
<emacsomancer>brendyyn: I have a pure GuixSD machine, but no KDE there
<brendyyn>I had thought id fixed this error myself but im getting it again too
<emacsomancer>I've put the export GUIX_LOCPATH line into ~/.bashrc ~/.bash_profile ~/.profile
<emacsomancer>and run it in bash itself, but the message is still there
<brendyyn>maybe you just need to update?
<emacsomancer>brendyyn: I'll try that
<brendyyn>guix pull; guix package -u .
***langdon_ is now known as langdon
<emacsomancer>brendyyn: updated everything, but still the message persists
<lfam>emacsomancer: Is this with GuixSD?
<emacsomancer>lfam: no, on a foreign distro
<lfam>Okay, you need to update the packages of the user from whom you are seeing the messages, make sure to relogin so that your environment is setup correctly, and update and restart guix-daemon as well
<emacsomancer>lfam: ah, I'll try the restarting the daemon
<brendyyn>update as root too
<emacsomancer>brendyyn: ok, I'll do that as well
<lfam>The messages either mean that GUIX_LOCPATH isn't set up at all, is setup incorrectly, or that it's different for your user and for guix-daemon. The root issue is that locales are not compatible between different versions of glibc, which just got updated
<lfam>On GuixSD you can ease the transition by using the locale-libcs field in config.scm
<emacsomancer>lfam: presumably it's the updating issue
<brendyyn>lfam: do you recommend guixsd users set that?
<lfam>brendyyn: No, it's set automatically on GuixSD
<brendyyn>oh ok
<lfam>It only gets tricky if the system and user profiles have different libcs
<lfam>Then you need to use locale-libcs
<brendyyn>my system definiton is a random mash of things i've copy-pasted in
<necrophcodr>I know this is hardly supported, but I'd like to have some help on what is going on, and how to resolve this issue
<necrophcodr>I'm running Gentoo, and I've been installing/uninstalling Guix on/off for about 2 years now.
<necrophcodr>I realize that this may or may not be the best of ways, but it's the way I've done it
<necrophcodr>And now I'm missing a per-user profile. Is there any way to get this back?
<necrophcodr>ie in /var/guix/profiles/per-user/necrophcodr there's no content at all
<necrophcodr>oh wow, nevermind. should've spent five seconds doing something instead. after having updated it to the latest release, reloaded the guix daemon, and updating packages, and reloading the guix daemon again, it seems to have come back.
<necrophcodr>sorry for the disturbance!
<civodul>hey there!
<cbaines>morning civodul :)
<puoxond>Hello Guix!
<puoxond>I am getting a backtrace when I run `guix system roll-back'
<civodul>hello puoxond
<civodul>puoxond: this looks like a genuine bug
<civodul>could you please email it to
<civodul>make sure to specify the version of Guix you're using
<tune>getting some weird locale-related messages trying to update user or root profile. also the mono package is failing to build
<tune>I recall seeing this before on a foreign distro with guix installed, but this is on GuixSD and I don't recall making any changes lately
<tune>this machine has 18 days of uptime, so I may reboot in a little bit to rule out any weirdness from that
<civodul>did you do what the messages suggest? :-)
<tune>well updates are failing so I obviously haven't installed any new packages
<tune>I have put the export line in my .zshrc now, but it won't do much good just yet
<civodul>updates are failing?
<tune>yeah, mono fails to build so I can't do a system profile update
<tune>I've put glib-locales in my package list in /etc/config.scm now, but until I get past the mono build failure that won't be sorted out
<civodul>right, but you can also install glibc-utf8-locales as a user in the meantime, as the message suggests
<tune>I suppose, but I'd rather not do that
<tune>especialy with guix package -i, as I have never installed anything via that method
<tune>I like it all to be in a neat list, whether that be config.scm or manifest.scm
<civodul>ah sure, you could do that via a manifest as well
<civodul>anyway i guess we need to fix mono!
<civodul>actually mono has substitutes as of a8fdca11d85296b4df1b60a0c8ce4e33c92759af
<civodul>/gnu/store/45lr0cx9xw37ih5qybhjr7aa5xllcqx3-mono- (on x86_64)
<tune>Interesting. Perhaps this is just an awkward time to update. I had attempted again and it failed on ncmpcpp instead of mono this time.
<tune>I was gonna try to do a reconfigure to sort out that locale thing (I usually do pull and reconfigure together, so I didn't realize I had this option at first)
<tune>but then I get build failed for python-ipython-5.5.0
<tune>I'm on "guix (GNU Guix) 3a2627b83cd18ae2a1f60d45cc726e9077b44fbd"
***rekado_ is now known as rekado
<rekado>there’s an open bug report for ncmpcpp (fails because of boost)
<tune>alright, I'll just try to update again at a later time and hope things get sorted out
<puoxond>civodul: I have sent a bug report.
<janneke>Hello Guix!
<civodul>hi janneke!
<civodul>thanks puoxond
<emacsomancer> hi janneke
<emacsomancer>brendyyn / lfam: updating (repeatedly) both user and root ended up working for getting rid of the locale complaint. cheers!
<apteryx>Is it normal than gtk+ libraries are not made availabel in the RUNPATH of binaries?
<rekado>apteryx: all libraries should be in the RUNPATH.
<rekado>apteryx: but some libraries are dlopened
<rekado>in those cases we need to patch the sources to pass the full path
<apteryx>I have an issue with dlopen failing to find
<rekado>have you tried patching the sources/
<apteryx>gtk+ is an input to my package, but gtk+-3.22.30 is not added to its RUNPATH.
<apteryx>dlopen looks in the RUNPATH
<apteryx>rekado: in what ways? it's just doing something like dlopen("", RTLD_NOW)
<apteryx>and exists as gnu/store/m2a5bvissgi3bxfgmwyxdmyhvwzf4n6z-gtk+-3.22.30/lib/
<apteryx>ah do you mean I should patch it to use an absolute path? That would probably work, but I'd like to understand why the gtk+ input is not added to the RUNPATH in the first place (if it was, I'd expect it to just work :-)
<rekado>apteryx: we sometimes patch “dlopen("libgtk” to be “(string-append "dlopen(\"" (assoc-ref inputs "gtk+") "/lib/libgtk"”
<apteryx>OK; this shouldn't be necessary if gtk was in our RUNPATH, according to 'man dlopen'
<rekado>maybe the build system of the package you’re working on messes with the RUNPATH?
<apteryx>I'm using the cmake-build-system, which is mostly like the gnu-build-system
<apteryx>who is reponsible to populate the runpath? GCC?
<rekado>have you checked if something funky is going on in CMakeLists.txt?
<rekado>because this generally works for other packages AFAICT
<apteryx>rekado: it seems to work for every other inputs I've specified for that package, except for gtk+ :-o
<apteryx> RUNPATH
<apteryx>this is for the package defined as:
<apteryx>rekado: I guess if the CMakeLists.txt(s) don't make it explicit that gtk should be linked in, GCC might not record the dependency in its RUNPATH?
<apteryx>(the binary's runpath, that is)
<iyzsong>yes! the 'ld-wragger' inspect the -L flags, add rpaths accordingly.
<apteryx>rekado: maybe this explains it:
<janneke>hi emacsomancer :)
*janneke is multi-too-tasking
<vagrantc>did the substitutes start happening for aarch64 yet (at least for the set used for "guix pull") ? hear it was in the works
<civodul>vagrantc: yup!
<civodul>you have to use
<vagrantc>should i abandon hydra in my configurations?
<civodul>yeah, or you can keep it as a fallback
<civodul>(that's what i do)
<civodul>substitute status for 'guix pull' is visible at
<civodul>i had it enabled for armhf but there were still too many core binaries missing
<civodul>i'll try reenabling it later
<g_bor>hello guix!
<apteryx>g_bor: o/
<apteryx>how can I see the output of a build while doing a 'guix package -u .' ?
<apteryx>guix package --verbose -u . doesn't seem to help
<demotri>apteryx: I don't know _during_, but you can do a guix build package && guix package -u package
<g_bor>apteryx: we currently don't have this as far as I know
<g_bor>you can do what demotri recommended
<g_bor>the current user interface is new, and the verbosity options have not been aligned with it yet
<apteryx>demotri, g_bor thanks
<apteryx>isn't it problematic to have GUIX_PROFILE in export PATH=\
<apteryx>which is in ~/.config/guix/current/etc/profile ?
<apteryx>especially, when wanting to add both Guix and your Guix installed packages to your PATH, one has to care to not set GUIX_PROFILE before sourcing ~/.config/guix/current/etc/profile.
<lfam>Is anyone able to access the HTML attachment from this bug report? <>
<bavier`>lfam: the request hangs for me
<lfam>Hm :/
<lfam>Well, Boost seems to be bit-reproducible now so I am going to close the report
<bavier`>lfam: sounds good to me
<lfam>I can only imagine the clattering of hard drive platters that we have caused
<g_bor>lfam: you can download the mbox link and extract the html attachment locally
<lfam>I see, thanks
<g_bor>looking at this openjdk compilation does not seem productive any more... Going to sleep :)
<rekado>lfam: you can access the HTML here:
<lfam>Thanks, yeah, I found it there too :)
<civodul>mumi rocks
<civodul>rekado: why am i now known as "ludo" on the web ui? :-)
<rekado>we switched to guile-email, which is stricter about the From header
<rekado>you’re using a non-standard way for your display name
<civodul>oh, am i?
<rekado>that’s a legacy option for message mode, though not marked as such :)
<civodul>oh like: (Hi There!)
<civodul>is that deprecated?
<rekado>it looks like it’s not mentioned in the relevant standards
<civodul>oh really?
<rekado>at least not for specifying names
<rekado>it’s used as a comment, which may be ignored
<civodul>i always thought the relevant RFC specified both ways
<rekado>message-from-style controls this.
<civodul>the good thing about email is that you're never done learning :-)
<civodul>so my message-from-style is 'default
<civodul>funny thing is that the docstring doesn't specify 'default as a valid value
<rekado>in the manual it says this about 'default: “Look like ‘angles’ if that doesn’t require quoting, and ‘parens’ if it does. If even ‘parens’ requires quoting, use ‘angles’ anyway.”
<civodul>anyway if i set to 'angles, it should be better
*civodul tries
<rekado>for existing messages Arun implemented support for names in header comments, so with the next update to mumi it should look fine again.
<civodul>in other news "make release" seems to be close to completion!
<civodul>second time i run it because i realized substitute keys were not properly registered on GuixSD...
<rekado>I’m still upgrading GNOME; the new gvfs needs libnfs, and to my surprise we don’t have a package for it.
<rekado>Am I just looking for the wrong thing? Is this included in another package?
<civodul>hmm never heard of libnfs
<janneke>rekado: thanks for sending my patch :-/
<rekado>janneke: meanwhile the project has been renamed and they moved the bug tracker… :)
<janneke>oh, crap :)
<rekado>I’m trying to build the latest version (the updater missed it in the past due to the name change) and will send them a new version of the patch if it is still needed.
<janneke>thank you
*janneke just built mescc-tools, mes, and tcc without `bootstrap-binaries'; so only bootstrap-guile, bootstrap-gash, bootstrap-mescc, bootstrap-mes
<janneke>oh and make-mesboot0 too; next up would be either gzip or bash
<ng0>civodul: well every good email client does not break on it, so bar@baz.tld (Foo) is still recognized by the good clients.
<civodul>ng0: yes, but what's news to me is that email clients can also choose to ignore what's in parentheses
<cbaines>I think I saw an email about a hash mismatch... I think I've just hit one with ruby-sass-spec from
<civodul>cbaines: could you send it to bug-guix?
<j3kyl_>hey, guix-install-sh fail at start: [1544047231.159]: [ FAIL ] Missing OpenPGP public key. Fetch it with this command:
<j3kyl_>then I enter gpg by myself as instructed then
<j3kyl_>gpg: key 090B11993D9AEBB5: 124 signatures not checked due to missing keys
<j3kyl_>debian / t430
<civodul>j3kyl_: that's ok, as long as it fetched the key
<j3kyl_>civodul: oh, indeed. now its running...ty
<civodul>rekado: we have a problem: the i686 ISO image has i/o errors here and there ("access beyond end of device")
<civodul>i'm trying to rebuild it to see
<civodul>but, i wonder what to do in case it doesn't work
<civodul>i'm tempted to just release 0.16.0 without the i686 GuixSD install image
<civodul>and then once we've fixed it, release 0.16.1 or 1.0.0 with i686 again
<j3kyl_>another error: line 277: /root/.config/guix/current/etc/profile: No such file or directory
<j3kyl_>running it again, it says now: [1544047912.310]: [ FAIL ] A previous Guix installation was found. Refusing to overwrite.
<civodul>where did you fetch the script?
<civodul>you should use as linked from
<j3kyl_>thats the one
<civodul>with the "?id=..." part?
<j3kyl_>civodul: LOL...
<civodul>i think you might have gotten the latest version of the script, which doesn't work with 0.15.0
<civodul>that's why i'm asking
<j3kyl_>hey civodul should it verify if a binary file is already downloaded and not skip donwloading all over again?
<j3kyl_>yep, no success: [ FAIL ] A previous Guix installation was found. Refusing to overwrite.
<j3kyl_>anyway to unninstall it and try it all again from scratch?
<rekado>civodul: hmm, that’s weird. I only ever saw that on real hardware when a disk failed.
<j3kyl_>it fails exactly at : Linking the root user's profile
<rekado>“A previous Guix installation was found.” – this means that you previously ran (and or aborted) the script.
<rekado>the script won’t overwrite an existing Guix installation, even if it’s just partially done.
<rekado>make sure to remove /gnu and /var/guix when you want to start from scratch.
<j3kyl_>rekado: thats it...
<j3kyl_>[ PASS ] Guix has successfully been installed!
<j3kyl_>you guys rock!
<j3kyl_>/s/guys/people :D
*rekado –> zzZ
<civodul>rekado: that's the iso image itself; i retried and /var/guix/db/db.sqlite has i/o errors
<j3kyl_>hey, a few months ago I tried to enter in contact with local translation team, no answer... I am still up to translate guix :D...