IRC channel logs

<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)

<kristofer>I should be using %binutils-static?

<ng0>I'm not sure.. but with all I've tried now, I don't know if I can pass the setenv of NCURSES_ to the perl build

<ng0>or I can, and the problem is in the detail

<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

<kristofer>lfam, I'll give it a try

<lfam>kristofer: I'll provide the patch series

<lfam>This is a newer version than the one on guix-devel. This is really the version we should work on

<lfam>kristofer: https://github.com/lfam/guix/tree/contrib-maps

<lfam>Depending on your hardware, it will take at least one hour to build gnome-maps' dependencies

<lfam>gnome-maps itself takes <1 minute on my machine, thankfully

<lfam>There is another branch, contrib-maps-3.18, which corresponds to what I sent to guix-devel. That gnome-maps *does run* on GNOME

<lfam>But it lacks some awesome features, such as OpenStreetMap editing

<lfam>Warning: javascript ;)

<kristofer>lfam, what does (wrap-program ...) do?

<lfam>It moves the executable to something like .foo-real and creates a script named 'gnome-maps' that sets those environment variables before invoking .foo-real

<lfam>So, it wraps the executable with some more environment variables.

<kristofer>aha

<kristofer>okay

<lfam>In this case setting LD_LIBRARY_PATH and GI_TYPELIB_PATH

<lfam>Lots of our packages do this "under the hood", courtesy of the build system. Check any python package, for example

<kristofer>lfam, I'm trying to package opencog atomspace, and I believe the issue I'm running into is related to LD not knowing where to look for the libboost_*.so

<lfam>What language is opencog atomspace written in?

<kristofer>c++/guile

<kristofer>it uses the cmake-build-system

<lfam>It should be possible to pass the paths of libboost to cmake at build time rather than wrapping the executable

<lfam>Not sure how it will work with the Guile parts

<lfam>I thought it would be possible to do similar for gnome-maps since it has a ./configure script, but it seems that passing the paths at configure time has no effect.

<lfam>JavaScript and ./configure. Go figure

<kristofer> http://paste.lisp.org/display/318389

<lfam>#:validate-runpath will tell you when you have "real problems" :)

<lfam>Did it complain the program had references to /usr?

<lfam>I'm not very familiar with cmake and boost but those flags look sensible

<lfam>You could try setting LD_LIBRARY_PATH just to see if it works, and if so, go back and figure out what needs to happen at build time

<kristofer>I'm gonna try it :)

<lfam>Do all Github projects offer an 'archive/master.zip' file? Or just these?

<lfam>It seems like that file would change over time, making it less useful as a URI

<lfam>And I would re-enable the runpath validator, since something is really broken if you can't finish the build with it enabled

<lfam>kristofer: I didn't read the code but this comment does not bode well for you ;) https://github.com/opencog/cogutils/blob/master/CMakeLists.txt#L223

<lfam>As if that's a major portability issue that requires special handling...

<lfam>But, I don't know cmake to judge the approach

<lfam>Hopefully the cmake-build-system can handle it

<kristofer>lfam, yes, I'll need to specify the commit.. just trying to get it to build currently

<lfam>I bit the bullet and mailed maps-list@gnome.org

<lfam>There seems to be zero discussion on irc.gnome.org

<lfam> https://mail.gnome.org/archives/maps-list/2016-June/msg00000.html

<pksadiq>lfam: can you try something like GTK_DEBUG=all gnome-maps in commandline?

<lfam>Yes, I can try that :)

<pksadiq>lfam: The log may be really big. There may be even better value for GTK_DEBUG, but I don't know :). This log *may* help find gnome-maps devs to find where the problem lies.

<lfam>pksadiq: Wow, you aren't kidding :) It also opened a debug window of some type

<pksadiq>lfam: That window is actually for debugging UI glitches only (called gtk inspector).

<pksadiq>lfam: I see a permission dinied error for dri driver too. If you have a free, compatible driver installed, can you try running gnome-maps as root too?

<lfam>4.7M of debug

<lfam>I don't know if I have a driver available or not. That machine is a thinkpad x200s

<pksadiq>lfam: may be lsmod | grep i915

<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 help-guix@gnu.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: It's building

<pksadiq>lfam: see the possible gtk debug options: https://developer.gnome.org/gtk3/stable/gtk-running.html#GTK-Debug-Options

<lfam>I just mailed the GTK_DEBUG=all log to the thread I started on maps-list@gnome.org

<lfam>I wonder if I should put all the first-level dependencies in GTK_PATH?

<pksadiq>lfam: as the warnings are mostly from glib, surely there is something else to debug. They shall help you better in that case. :)

<lfam>What do you mean? Should I be looking at something else?

<pksadiq>lfam: there is also env vars like G_DEBUG, gjs debug etc. you don't need to waste time running. Let the GNOME developers say

<pksadiq>lfam: what about totem?

<lfam>pksadiq: I got a test failure in gst-plugins-good, so I can't build totem until I deal with that

<pksadiq>lfam: Oh. Well, wait some time untill the irc is alive.

<lfam>Is it ever busy?

<pksadiq>lfam: Of course. It's alive mostly in US timezone (Also right now a gtk+ hackfest is going on. May be some are there.)

<lfam>The failing gst-plugins-good test is tests/check/elements/rtprtx.c, which seems to be related to audio

<pksadiq>lfam: do you have link to xz compressed log?

<lfam>pksadiq: Log of what?

<pksadiq>lfam: gnome-maps

<lfam>The debug log?

<pksadiq>yeah

<lfam>I'll make it

<pksadiq>lfam: I seems like there is only gtk related errors in that log.

<lfam> https://famulari.name/misc/20c9994101be4f0876bf432a9733fc17/debug.log.xz

<lfam>I did make it with GTK_DEBUG=all

<pksadiq>lfam: do you get any errors with gnome-maps --g-fatal-warnings ?

<lfam>Yes, the libGL errors from before, and also "GLib-GObject-WARNING **: cannot register existing type 'GkdPixbuf'

<lfam>pksadiq ^

<lfam>That's a handy argument :)

<pksadiq>lfam: Your debug log seems almost equivalent to my log. Do you wish to waste some time with me? (I'm never an expert with gtk+) ☺

<lfam>pksadiq: What are you working on?

<lfam>I'm not even a novice at gtk+ ;)

<pksadiq>lfam: I wish to debug your gnome-maps :)

<lfam>Ah, I thought you had a debug log from some other program :)

<pksadiq>lfam: I was comparing your log with the log produced in mine. Do you have gnome-documents package in guix?

<lfam>It's a work in progress but it hasn't been merged yet

<pksadiq>or gnome-weather?

<lfam>No. We have gnome-calendar. Would that work?

<pksadiq>that's written in C. I wish to know if there is any problem with javascript apps. By the way, is gnome-calendar working well?

<pksadiq>polari is too written in js. Is that present?

<lfam>No polari

<lfam>I can try running gnome-calendar

<pksadiq>ok

<lfam>gnome-calendar runs

<lfam>Based on those fatal errors, I wonder if I should provide gdkpixbuf to the gnome-maps package?

<lfam>And then look into the libGL errors?

<lfam>ACTION tries it

<lfam>pksadiq: Are you familiar with how gnome javascript applications work? How are they supposed to find their dependencies when they run?

<lfam>Do they just look in the environment or can the paths be provided when building?

<pksadiq>lfam: No. Sorry

<pksadiq>lfam: This is the dependency tree on my system for gnome-maps: http://paste.debian.net/739300/

<lfam>Hm, nothing stands out to me

<lfam>I'm trying to learn exactly what is meant by "glib-gobject-warning cannot register existing type [...]"

<pksadiq>lfam: are you sure you have gdk-pixbuf package?

<lfam>I have it but I don't think gnome-maps is finding it

<lfam>About the libGL errors, maybe it needs something from mesa

<pksadiq>lfam: That way not me vital though

<lfam>pksadiq: You think that is not the real problem?

<pksadiq>lfam: I think the glib-object-warning is the problem.

<pksadiq>but I'm not sure.

<lfam>Okay. I'll try providing it with LD_LIBRARY_PATH

<pksadiq>lfam: do you get any reference to pixbuf this way: ldconfig -v | grep -i pixbuf

<lfam>Hm, what provides ldconfig?

<pksadiq>lfam: it should be there. probably with the build system.

<pksadiq>what about locate ldconfig ?

<lfam>Will ldconfig look in the right places? Guix doesn't have /usr, /lib, etc

<pksadiq>lfam: Oh, I don't how guix deals with those.

<lfam>I definitely have gdk-pixbuf on the system.

<pksadiq>lfam: Let's wait for gnome devs. I can't try much as I'm not on guixSD.

<lfam>pksadiq: It runs! :)

<lfam>I put gdk-pixbuf on LD_LIBRARY_PATH and it runs

<pksadiq>Hm... That's great ☺

<lfam>I am so happy

<lfam>I have been doing this all day

<lfam>And I first started it a couple of months ago before getting distracted

<lfam>The beautiful earth on my computer screen :)

<yoosty>lol, congratulations!

<lfam>Now, the question is "how is it supposed to be packaged?" I don't think that abusing LD_LIBRARY_PATH in this way is correct ;)

<lfam>pksadiq: Thank you very much for helping me!

<pksadiq>lfam: yw :)

<pksadiq>lfam: Is gnome-shell usable in guix?

<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

<lfam>We are learning as we go :)

<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. :)

<pksadiq>s/to OS/two OS/

<lfam>I use the GuixSD USB installer image as a read-only live system. But, we make that USB installer with `guix system disk-image`, so you could easily make your own rescue system

<pksadiq>lfam: I shall try it. Let me find some place where I can get some free bandwidth :)

<lfam>On the USB installer, you can install packages like normal, but they are just in RAM. Very convenient

<lfam>Yes, I hope you find some free bandwidth!

<lfam>I think I will stop for the night. pksadiq, I'll see you around!

<pksadiq>lfam: I shall try. It's day for me :)

<lfam>Both time zones are showing on gnome-maps ;)

<ozzloy>when i run emacs installed via guix, i get http://paste.lisp.org/display/318398 i'm guessing installing libcanberra will fix it (doing so now). would this be considered a bug worth reporting to bug-guix?

***exio4 is now known as hacker

***hacker is now known as exio4

<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

<ozzloy>ah, interesting

<ozzloy>or point emacs at the 64-bit version

<ozzloy>the emacs that comes with debian doesn't do this

<ozzloy>so it can be done

<pksadiq>ozzloy: mostly java things

<ozzloy>er... the debian emacs doesn't give these errors, so it seems possible it's using the 64bit version

<pksadiq>but that doesn't mean architecture problems are the only thing that causes this bug. :)

<ozzloy>yoosty, oh, sorry, i skipped your message in here. emacs opens

<ozzloy>yoosty, it runs and i so far don't see any problem

<yoosty>ozzloy, np :)

<pksadiq>Will guixSD 0.11 be released soon? I wish to test guixSD

<ozzloy>oh, actually when i build emacs from source on debian, i also don't get this error

<ozzloy>like, building from source outside of guix

<yoosty>hmm, the "GLib-GIO-Message" part looks more like an informational message than a warning/error ?

<ozzloy>the "Your settings will not be saved or shared with other applications." sounds bad

<ozzloy>sounds like a feature went missing

<pksadiq>ozzloy: But I haven't ever saved my emacs settings in gsettings settings. They are mostly saved in ~/.emacs.d.

<ozzloy>that's fine. and i agree, i save all my settings in ~/.emacs.d. but that's really besides the point.

<pksadiq>ozzloy: but this could surely be a problem for other gtk+ packages.

<ozzloy>my goal is to get emacs to run without any error output. i don't want to get used to ignoring output, i want to fix it

<pksadiq>sure. That would be nice.

<ozzloy>though right now i actually don't care enough about it to keep focusing on it. i was hoping there was a 5 minute solution, but it's been more than that and i have to move on

<ozzloy>something i'm spending more time on is getting to the point where i can build skribilo. i want a (video ...) form for html output

<ozzloy>i guess i should confirm my assumption: i can use guix to create an environment where i can hack on skribilo, right?

<ozzloy>i figure it builds skribilo from source, so surely i can use it to build source i modify

<yoosty>ozzly: one of the touted features is 'guix environment' - https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-environment.html

<yoosty>not much experience with it myself but sounds like what you might be looking for

<yoosty>er.. s/ozzly/ozzloy/ :)

<ozzloy>yoosty, cool

<ozzloy>i actually just got skribilo working outside guix

<ozzloy>so i'm gonna use that until i can get guix working

<rekado_>ACTION works on a new build phase for icedtea to build a keystore from nss-certs

<rekado_>error messages in Guix/Guile are a bit frustrating

<rekado_>when you add a new package and there's probably a loop somewhere and then you get errors like this:

<rekado_>guix build: warning: failed to load '(gnu packages abiword)':

<rekado_>ERROR: In procedure module-lookup: Unbound variable: nss

<rekado_>...

<ozzloy>oh dear

<ozzloy>i have unintentionally built a hybrid skribilo install. i need to have guix skribilo installed to run my /usr/local/bin/skribilo

<ozzloy>i guess i'll be looking into how to modify skribilo's build after all

<rekado_>does anyone know why adding #:use-module (gnu packages certs) to the java module would cause a loop?

<rekado_>I need the nss-certs package in java.scm, but as soon as I add it I get these unhelpful errors indicative of a loop

<efraim>i've never looked in java.scm

<efraim>what about this line? #:use-module (gnu packages gnuzilla) ;nss

<efraim>there's an nss in gnuzilla, so if there's one in certs too then there's too many in java

<efraim>maybe

<rekado_>there's nss-certs in certs.scm

<rekado_>and it inherits from "nss" in gnuzilla.

<rekado_>java.scm uses "nss" from gnuzilla, and now I'd like to also use "nss-certs"

<rekado_>there's no conflict.

<rekado_>the error looks like a module loop

<rekado_>because all of a sudden unrelated modules like abiword can no longer be loaded

<efraim>did you check your parenthesis?

<rekado_>yes

<rekado_>things break when I uncomment the use-module line

<rekado_>when I add the package definition in the REPL it's also fine, further suggesting that there's a loop somewhere.

<civodul>Hello Guix!

<efraim>hi!

<efraim>rekado_: you have local-build? twice in guix/hg-download.scm

<rekado_>efraim: oh, thanks for noticing.

<rekado_>I adapted this from git-download

<rekado_>it has the same defect

<rekado_>ACTION fixed it localy

<rekado_>*locally

<rekado_>I was surprised to see that git-download isn't documented in the manual.

<rekado_>it appears in an example but we have no list of available download methods

<civodul>rekado_: that would be a useful addition

<emyles>Mornin', does anyone know how I can deploy a python (pyramid) app

<emyles>in "development mode" ( http://bit.ly/1Ptn1mv ) i.e. so I can

<emyles>still tinker with it and the changes are picked up without having

<emyles>to reinstall?

<emyles>The standard way would be:

<emyles>"pip install -e" OR "python3 setup.py develop"

<emyles>Would it need an extension to python-build-system?

<civodul>emyles: i don't know about pip's development mode, but does 'guix environment' help?

<civodul>or does it lack something?

<emyles>hi civodul

<emyles>ACTION goes to read docs again

<emyles>yes that should work, I'll have go at it, I think I'll need to make a package to install the files that setup.py develop would

<emyles>I was hoping someone else would have already worked it out.

<efraim>if you know which ones you'll need you can do `guix environment --ad-hoc python-foo python-bar python-baz git'

<emyles>yes the ones I need are defined in setup.py as requires=[..]

<emyles>The problem is there are two things I don't really understand and I am trying to get one of them to behave like the other.

<emyles>Think I just need to build a .egg and add a couple of links, modify sys.path...

<civodul>emyles: Steap worked on guix-tox, which uses 'guix environment' as a backend for Tox, dunno if that would be helpful here

<civodul>mark_weaver: did you abort the jobs on core-updates?

<emyles>civodul: I'll have a look, thanks

<thomasd>Hi Guix,

<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>no archive.org link?

<ng0>sometimes they manage to pull archives

***pastaf is now known as Pastaf

<ng0>is it offline?

<ng0>bsdports shows me:

<ng0> http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/util/sorc/wgrib2.cd/grib2/

<ng0>from https://www.freshports.org/misc/gctpc/

<ng0>thomasd: ^

<thomasd>ng0: thanks! Seems the package originates from usgs.gov, but they don't offer it anymore.

<ng0>civodul: thanks for spotting the perl package description failure... I think no sleep makes one not check every last line sometimes :)

***kete_ is now known as kete`

***kete` is now known as kete_

<davexunit>civodul: is there a reliable way to test if a given public key has been authorized via 'guix archive'?

<civodul>yes!

<civodul>see (guix pki) :-)

<davexunit>thanks

<davexunit>ACTION is writing a Chef recipe for installing Guix

<davexunit>;)

<civodul>namely 'authorized-key?'

<civodul>heh, fun :-)

<davexunit>civodul: thanks!

<civodul>you should make a Habitat automation foobar for Guix, while you're at it

<davexunit>I have no idea how to use it :)

<civodul>that way, it'll be encrypted at the artefact level

<davexunit>hahaha

<civodul>:-)

<davexunit>I laughed a lot when I read the backlog earlier

<civodul>heheh :-)

<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

<rekado_>ng0: pkg-config?

<ng0>ayyyy

<ng0>x.x thanks

<bavier>ng0: ACLOCAL_PATH maybe?

<ng0>no, that's existing.. pkg-config was the obvious elephant i did not see

***kete_ is now known as kete

<ng0>what difference 2 core vs 4 and more makes... so fast build times compared to the laptop

<ng0>libgcrypt-1.7.1 was just released. I'll send in a patch for it later today, it might be better to have that directly in core-updates than 1.7.0

<paroneayea>ACTION deletes months of old generations and gc's

<paroneayea>so satisfying

<davexunit>hehe yeah that's fun to do periodically

<efraim>i have my cutoff at one month

<efraim>if it doesn't work and it hasn't worked for the last month and I haven't noticed then I dont need it

<kyamashita>efraim: Similar tactic here.

<lfam>What about all the http -> https patches on the mailing list? Does anybody want to test them?

<ng0>there was one I paused.

<lfam>We really just need to test that the URLs will work, since a URL change won't cause rebuilds

<ng0>the one which accidentally changed the headers, so i asked gnu about it

<lfam>Right

<lfam>I have the patches for haskell.scm, xorg.scm, and emacs.scm in my inbox. Should I archive those and wait for another round?

<lfam>Btw, testing these patches sounds like a good use of Cuirass, mthl's CI tool :)

<efraim>they "changed their address" from physical to online, if they're at https now I don't think we need to wait for them to update their recommended headers but

<efraim>or get a list and `cat list | xargs guix build -S --no-substitutes'

<ng0>i'm not sure, lfam. I'll have another look, but I think only one of them changed headers, the other 2 were alright

<lfam>efraim: Sure, but that's less fun ;)

<ng0>efraim: could you comment on the thread of it where someone with an @gnu.org addres (forgot the name) responded

<ng0>I'm not sure about the headers.

<ng0>and if anything, we want to update all the headers everywhere.. would make more sense than this byproduct of an accident

<ng0>be consistent..

<lfam>ng0: Did you get a response from GNU?

<ng0>not yet

<lfam>I see that x.org saved their domain. That's good

<ng0>my description for perl-net-psyc turned out rather long with an enumerated list of 12 items.. is there a list item which does not include 1 free line between list items?

<ng0>or rather, if 12 items are necessary, is this considered appropriate?

<ng0>I can't make it shorter in content

<lfam>I don't think it's a problem

<lfam>If there are 12 things, there are 12 things

<civodul>yeah, but OTOH, "Descriptions should take between five and ten lines." says https://www.gnu.org/software/guix/manual/html_node/Synopses-and-Descriptions.html :-)

<civodul>ng0: ↑

<lfam>Oh :p

<lfam>civodul: For the gnome-maps module, how about (gnu packages geo) instead of (gnu packages maps)? More things can fit in that category

<ng0>but there are 12 applications.. should I just fall back to a long text or pointing to the website, civodul ?

<civodul>lfam: sure, sounds good as well

<civodul>ng0: mention the main points of the package; it's not necessary to be exhaustive, it's not a manual

<ng0>I'll try to come up with something short

<ng0>how do I correctly do @uref ... is there only @uref{thing.tld, THING} or is what i end up without "," also correct: `http://thing.tld THING` ?

<ng0>civodul: what about ao?

<ng0>that's 18 lines

<davexunit>exception rather than the rule

<ng0>i corrected the description of my package to a minimum

<ng0>is core-updates already frozen, or can I still get libgcrypt-1.7.1 in for the current one? I guess it'll be around midnight UTC today or before that when i can send a patch

<ng0>forget the question about uref, got it fixed.

<kyamashita>Small question, do Guix maintainers prefer gzip or bzip2 tarballs?

<lfam>My own preference is to use the smallest one

<civodul>yeah, same for me

<kyamashita>I was thinking the same, but I wanted to be sure. Bzip2 is the smallest in this case. Any Warzone2100 or Chromium B.S.U. players?

<lfam>Is Chromium B.S.U. a web browser? ;)

***pksadiq` is now known as pksadiq

<kyamashita>Nope. It's a top-down shmup video game.

<kyamashita>I don't do Chromium browser or its forks. :-)

<lfam>I haven't tried those games. If they are free software you should add them to Guix

<kyamashita>They're free software, alright. The package I'm working on now is a dependency of them both.

<davexunit>I'd really like to see a Xonotic package

<davexunit>fun arena shooter

<ng0>yep

<ng0>me too

<kyamashita>I may work on that one some time this summer.

<lfam>So, is it expected that GNOME is very slow on the x200 / x200s laptop? Or have I configured something incorrectly?

<kyamashita>lfam: It was normal speed on mine when I used it.

<lfam>Normal speed being "usable"?

<davexunit>I have an x220 and it's nice and snappy

<kyamashita>Oh definitely. Pretty smooth as long as I wasn't processing a lot.

<lfam>It takes seconds for keypresses to even show up in the terminal. I have the high contrast accessibility view on, maybe that's the issue.

<lfam>gnome-shell is using a full core all the time. No significant I/O waiting and some free RAM

<davexunit>perhaps there is a graphics processing issue

<lfam>Well, at least know I know it can be made to work!

<lfam>now I know

<ng0>i had this on the desktop computer where I had to exchange ati cards for a nvidia one, due to gpu requiring blobs not present in linux-libre

<kyamashita>I didn't use the high contrast mode (I was mostly in a high contrast terminal anyway), so that might be something.

<ng0>ACTION starts building libgrcrypt-1.7.1

<ng0>build output looks good to me

<lfam>Can you try building gnupg and using that gnupg to verify the signature of the libgrypt tarball?

<ng0>okay. I'm just afk for a while to do something

<ng0>should be finished soon

<ng0>well.. this is going to take a while, with the whole graph of gnupg.

<lfam>ng0: If it's not practical, just send the patch to the list and other people will test it

<lfam>I don't know the status of the core-updates build, so I don't know if the patch can be applied to core-updates or not

<lfam>Please try gnome-maps :)

<ng0>it's only building the entire toolchain, but the computer is fast enough

<ng0>eh.. sorry. wrong word

<ng0>it's building the entire graph

<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

<ozzloy>guix has cool functions

<ozzloy>like keeping track of the generations

<ozzloy>thanks for all the work you've all put in on it

<kyamashita>ozzloy: You're welcome! We hope that we can build it to help empower users in their computing freedom.

<ng0>sneek: later tell lfam: it worked(gnupg+libgcrypt-1.7.1). https://ptpb.pw/k6oU

<sneek>Got it.

<davexunit>hmmm I'm having some issues with 'guix substitute' on a new machine http://paste.lisp.org/display/318444

<davexunit>using the 0.10 binary tarball

<efraim>did you try guix pull first?

<davexunit>that won't make a different

<davexunit>difference*

<davexunit>and won't work anyway because it will try to use 'guix substitute'

<davexunit>from what I can tell, there's something wrong with the 0.10 binary tarball

<efraim>the content-addressed-mirrors were added since 0.10

<davexunit>I don't follow.

<davexunit>seems completely orthogonal to this problem

<efraim>that's the first thing that came to mind for what might've changed with the substitutes between 0.10 and now

<davexunit>but I'm using 0.10, so what has changed doesn't matter

<davexunit>because I'm not using a newer version

<davexunit>I need 0.10 to work before I can do anything further

<davexunit>has anyone used the 0.10 binary tarball here?

<davexunit>seems to be a load path issue or something

<civodul>davexunit: are you fetching substitutes over https?

<civodul>what's the --substitute-urls?

<ozzloy>i have a suggestion. guix could use substitutes to install, then when the computer isn't in use, could build from source and verify packages, maybe randomly, maybe publishing its findings

<ng0>"publish its findings"?

<efraim>run `guix challenge' in the background and hook into `guix publish'

<efraim>or output to a log file for the user to deal with

<ozzloy>configurable, but by default guix challenge and publish

<ozzloy>but of course, the user can say "just put it in a log file and i'll deal with it"

<ng0>ozzloy: you might be thinking of something similar to the gnunet publish/diustribute goal on the roadmap

<ozzloy>i might be

<ozzloy>i knew using gnunet was a goal

<ozzloy>i didn't know randomly checking and challenging and publishing findings was

<ozzloy>what i read made it sound like using gnunet for distributing the packages was a goal

<ng0>once you have the base, this can be made optional.

<ng0>if desired

<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.

<sneek>So noted.

<ng0>sneek: no

<ozzloy>ng0, cool

<ozzloy>ng0, hope it happens

<ng0>yeah. we have only been discussing shortly about it, but technically from gnunets side it is easy

<ng0>challenge will be guile and to actually wrap my/our head around guix enough to get it from idea to action

<ozzloy>found a typo in the docs: Another example where propagated-inputs is useful is for languages that lack a facility to record the run-time search path akin to the RUNPATHof ELF files

<ozzloy>no space between RUNPATHof

<ozzloy>this is on https://www.gnu.org/software/guix/manual/guix.html

<davexunit>I'm also managing to kill guix-daemon somehow

<davexunit>ugh

<civodul>ozzloy: fixed, thanks :-)

<civodul>davexunit: weird

<civodul>like it dies for no apparent reason?

<davexunit>yeah

<davexunit>but after I restart the daemon things seem OK

<efraim>ACTION heads off to bed

<civodul>davexunit: the #f error makes me thing of an invalid URI passed as --substitute-urls, something like that

<civodul>would be great if you could isolate it