<civodul>rekado: i think i'm done with NEWS on version-0.16.0 <reepca>Hm, where could I find documentation for bournish? <civodul>but there's also very little to know about it <apteryx>lfam: hahah, I think the problem was that my arguments list was not backquoted but quoted... <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 libgtk-3.so.0: libgtk-3.so.0: cannot open shared object file: No such file or directory <apteryx>or DEBUG: Failed loading libgtk-x11-2.0.so.0: libgtk-x11-2.0.so.0: 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>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 <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("libgtk-3.so.0"); <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>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 "libgtk-3.so.0". <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" <emacsomancer>brendyyn: but it does create issues in some cases, so I'd like to resolve it <brendyyn>emacsomancer: ok so the first thing is to check is if you have your .bash_profile configured correctly <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 ***langdon_ is now known as langdon
<emacsomancer>brendyyn: updated everything, but still the message persists <lfam>emacsomancer: Is this with GuixSD? <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 <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 <brendyyn>lfam: do you recommend guixsd users set that? <lfam>brendyyn: No, it's set automatically on GuixSD <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. <puoxond>I am getting a backtrace when I run `guix system roll-back' <civodul>puoxond: this looks like a genuine bug <civodul>could you please email it to bug-guix@gnu.org? <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 <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>actually mono 4.4.1.0 has substitutes as of a8fdca11d85296b4df1b60a0c8ce4e33c92759af <civodul>/gnu/store/45lr0cx9xw37ih5qybhjr7aa5xllcqx3-mono-4.4.1.0 (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 <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 libgtk-3.so.0. <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>rekado: in what ways? it's just doing something like dlopen("libgtk-3.so.0", RTLD_NOW) <apteryx>and libgtk-3.so.0 exists as gnu/store/m2a5bvissgi3bxfgmwyxdmyhvwzf4n6z-gtk+-3.22.30/lib/libgtk-3.so.0 <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>/gnu/store/gpwds7haa6hd8n5sc18gybikjx5klbma-openboardview-7.3/lib:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib:/gnu/store/1c3hywwcpgah5gr10lmhqbzd96k65qv9-imgui-1.49/lib:/gnu/store/fxiwj2wpp11sif613axdax7gmwzsg6kp-zlib-1.2.11/lib:/gnu/store/nrsjkmnh5gqpsyap9pz4hkmmdxxryhdh-sqlite-3.23.0/lib:/gnu/store/3wmjdyi8hpkakj5jfmgldlal3izxglmj-fo <apteryx>ntconfig-2.13.0/lib:/gnu/store/ap7f3ak574a4vq18grrpak0dlkg5nfdc-freetype-2.9/lib:/gnu/store/3ssf3m33v9ll62s74qx2gcd3cjqfvmp2-sdl2-2.0.9/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../.. <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? <iyzsong>yes! the 'ld-wragger' inspect the -L flags, add rpaths accordingly. *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 <vagrantc>should i abandon hydra in my configurations? <civodul>yeah, or you can keep it as a fallback <civodul>i had it enabled for armhf but there were still too many core binaries missing <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>isn't it problematic to have GUIX_PROFILE in export PATH=\ <apteryx>"${GUIX_PROFILE:-/gnu/store/a2xi0g5nj7d5bbwlgnicnp807pd6y2xs-profile}/bin${PATH:+:}$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>Well, Boost seems to be bit-reproducible now so I am going to close the report <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 <g_bor>looking at this openjdk compilation does not seem productive any more... Going to sleep :) <lfam>Thanks, yeah, I found it there too :) <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 <rekado>that’s a legacy option for message mode, though not marked as such :) <rekado>it looks like it’s not mentioned in the relevant standards <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 <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? <janneke>rekado: thanks for sending my patch :-/ <rekado>janneke: meanwhile the project has been renamed and they moved the bug tracker… :) <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 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 mirror.hydra.gnu.org <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 <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>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: guix-install.sh: 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>i think you might have gotten the latest version of the script, which doesn't work with 0.15.0 <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_>[ PASS ] Guix has successfully been installed! <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...