<ng0>hm.. could someone who will review d4n1's patch also add that html mail is not really good for readin patches? I think it's good now, have not tested it, but I can't apply a html patch. I'm still tryin to get Curses to build.
<kristofer>what do ya'll make of this? /gnu/store/...-binutils-2.25.1/bin/ld: warning: libboost_filesystem.so.1.60.0, needed by /gnu/store/...-cogutil-ver/lib/libcogutil.so, not found (try using -rpath or -rpath-link)
<lfam>I wrapped the executable for version gnome-maps-3.20.1 with LD_LIBRARY_PATH providing the paths to gnome-online-accounts, geoclue, and webkitgtk. Here is the console output when I run it: http://paste.lisp.org/+6TO4
<lfam>It doesn't exit, it just waits without opening a window. *But* it does start the location service. I see the location icon appear in GNOME's menu bar
<lfam>I used LD_LIBRARY_PATH after having no luck with LDFLAGS and CFLAGS in #:configure-flags
<lfam>GNOME is basically unusable, but I can see gnome-maps-3.18.2 working slooooowly
<lfam>There does appear to be a i915 driver according to the output of lsmod
<cehteh>gnome unuseable? .. i thought they declared that as feature years ago
<lfam>It certainly looks nice. It's just very slow on that old machine
<pksadiq>lfam: I have being tracking guix since it's beginning. But I haven't yet tried it. :)
<cehteh>i got rid of any gnome remains on all the machines here
<lfam>pksadiq: It's not very disruptive to an existing GNU / Linux system.
<pksadiq>lfam: I don't have enough bandwidth to update the packages each day.
<pksadiq>lfam: By the way, does it boot completely on ram? (So that I can remove the boot device after loading). Does it have grub-install (So that I can fix grub boot errors). Does it have chroot64 and chroot32?
<lfam>pksadiq: Running gnome-maps as root, it fails immediately due to not finding org.gnome.desktop.interface. That's within my user's GNOME session
<pksadiq>lfam: hm. Is totem packaged in guix? does it works?
<lfam>pksadiq: I'm not sure about those questions. You should ask on firstname.lastname@example.org
<lfam>We have a totem package. I've never tried it
<pksadiq>lfam: can you try that? I think totem too uses graphics capablities.
<lfam>pksadiq: We added it about 6 months ago, so it's still a little rough around the edges. But, it's being improved all the time. Unfortunately I only use it for testing GNOME packages like gnome-maps since my GuixSD machine is too slow with GNOME. Soon I will convert my workstation to GuixSD and then GNOME will be a real option for me
<lfam>I guess that gnome-shell itself is fine. It's the whole GNOME system that is a little rough
<pksadiq>lfam: I shall then switch to guix after some time. :) I hope guile-gnome will be ready for gtk3 soon.
<lfam>pksadiq: If you can install Guix on another distro, you can try GuixSD in QEMU with the command `guix system vm-image --image-size=10G config.scm`, where config.scm is a GuixSD operating system configuration file. Of course --image-size could be anything bigger than ~1G
<lfam>I can actually run GNOME on GuixSD faster in QEMU on my workstation than on the x200s I was testing on today
<lfam>You can also make a disk image with `guix system disk-image` and a read-only VM with `guix system vm`
<lfam>I didn't know about guile-gnome. That sounds like it will be fun for some Guix GUI hacker
<pksadiq>lfam: First I wish it to test as rescue distribution. That's why I did ask you some questions before. I don't have a good enough system to run to OS at a time. :)
<ozzloy>nope, still get that even after installing libcanberra
<yoosty>let's do a bit more digging before reporting to bug-guix..
<ozzloy>i tried just libcanberra, libcanberra-gtk2, and both
<yoosty>so nothing happens after you run "emacs"? You're just returned to a shell prompt?
<pksadiq>ozzloy: libcanberra deals with sound notifications only. Do you miss that?
<ozzloy>pksadiq, i see what you're saying. yes, i can live without that. as far as i know, emacs is running fine right now. however, to me that sounds like saying "it only smells a little bit in here. do we really need to clean?"
<ozzloy>i suppose we don't _have_ to, but i'd like to
<ozzloy>as for the GLib-GIO-Message part of the error, i still get that after guix package --install dconf
<pksadiq>ozzloy: I have seen this warning several times (in other OSs). Mostly in 64 bit packages, where it was required to install 32 bit version of libcanberra
<thomasd>Are shared libraries preferred? A library I'm packaging only builds static libraries by default. Should I patch the build so it builds shared objects?
<davexunit>thomasd: in general, yes. shared libraries are much better.
<thomasd>davexunit: looks like I'll have a little more work then :)
<thomasd>another issue is that this library bundles the "General Cartographic Transformation Package". It would be cleaner to package GCTP separately, but the official source for that library is offline
<ng0>going back to guixsd, what am i missing when I can't bootstrap in the git checkout and get "configure.ac:68: error: possibly undefined macro: PKG_CHECK_MODULES"? i have everything needed in my profile and added the exports to bashrc and sourced /etc/profile again
<lfam>libgcrypt is a relatively low-level package for Guix
<ng0>i think a gnupg outpout where the versions used are shown + the succesfully checked signature are enough to add in addition to the patch?
<lfam>I'm not sure what you mean. I just suggested that as a way to test the new libgcrypt in the context of Guix
<ng0>right. I will add some output which shows that 1.7.1 was used to the patch, but that's not necessary as it will be run by someone else and at least hydra too.
<lfam>Yes, I will test the patch and confirm the tarball's signatures when reviewing the patch
<ng0>okay, this is probably going to take some hours minimum, worst case 12-24 hours from what i know of gentoo building such long dependency graphs.. I'll sent the patch once it is done. going to watch star trek now while the computer has to be turned on :)
<efraim>on my netbook its only about 10 hours from bootstrap to python
<davexunit>civodul: the issue seemed to stem from the fact that module-ref returned #f when trying to retrieve the 'guix-substitute' procedure
<davexunit>strangely, the error is difficult to reproduce. I restarted the daemon and don't have the problem anymore.
<ng0>ozzloy: I hope that aiming at getting the distribution done by next year's summer is not too high. i have looked at where to logically shift priorities, and hope this can be done with some other people outside of guix. or at least have something working by then. system service for gnunet will be first very soon.