<mark_weaver>civodul: one very common problem that has been turning up lately is websites increasingly redirecting http to https. I think we're going to need a way to download over https that's independent of gnutls
<mark_weaver>it's only a matter of time before one of the packages that gnutls depends on requires an https download, assuming that we're not already there.
<mark_weaver>I confess that since the hydra disk failure, I've been freely populating hydra's store with many source tarballs and other downloads that are either not longer there, or require https.
<ng0>wgreenhouse: i can paste the patch i put on the mailinglist somewhere else if it is unreadable with mailman.
<mark_weaver>I wonder how hard it would be to implement insecure https support in pure guile, i.e. it would not actually check certs or check authenticity, since the hash is checked later anyway.
<mark_weaver>other possible approaches include: (1) add gnutls to the bootstrap binaries, and (2) handle downloads using an external hook, that can use software not included in Guix.
<ng0>wgreenhouse: building torbrowser from source, the way i do it takes ~1 hour 22 minutes with as much unbundling as possible (system libevent unbundling (in gentoo, for me) is problematic because i use libressl)
<mark_weaver>doing good conversions is a bit tricky. unfortunately, I don't do it often enough to remember all the magic flags to ffmpeg
<mark_weaver>but the key ideas are that you want "constant quality", which is usually not the default, and a quite high maximum bitrate, or else the quality will very noticeably degrade at every key frame and then gradually get better in the frames after that, which is quite distracting I find.
<ng0>"Libgnomekbd is a dead man walking – the only useful thing is the keyboard drawing widget, that should be incorporated into gnome-control-center in 3.8." so should I just point out that what I obviously see, that it can draw keyboard layouts? that's what i wanted it for
<mark_weaver>which I don't remember seeing in the "queued" or "newly failed" jobs on hydra, so I suspect this is a case where it was built and then lost with the disk failures
<mark_weaver>civodul: I discovered a way to fix problems like this: make a new jobset on hydra. this will cause new builds to be created, instead of using the old cached ones, and thus actually force a rebuild
<mark_weaver>civodul: I propose that we create a new jobset to evaluate core-updates, to force these missing builds to be populated. what do you think?
<civodul>mark_weaver: can't we just clear build failures and evaluate anew?
<mark_weaver>civodul: "Restart aborted builds" won't work, because the builds have 'buildstatus' that indices they are successfully built, but I agree that there are better ways to do this.
<mark_weaver>I'm not sure it can be done with a postgresql query, though.
<mark_weaver>civodul: here's the thing. I know how to create a new jobset right now, but even after thinking about it for several minutes, I'm still not sure how to go about rebuilding all of these jobs whose outputs are missing from Hydra's store.
<mark_weaver>one issue is that I remember cases where the .drv files in the existing 'build' table is no longer in Hydra's store, and is different from what is currently being generated by Guix, due to all the URL updates.
<mark_weaver>so I'm not sure off hand if the postgresql database contains enough information to restart these builds
<mark_weaver>I guess the way I would go about it is to extract all the 'drvpath's of the builds in the desired evaluation, read them to extract the outputs, check to see if they are all valid paths in the store, and if not, set the build status to indicate "queued", and hope that the 'drvpath' still exists in the store
<mark_weaver>civodul: if you'd like to repopulate Hydra's store in a better way, that's fine of course, and I'm of course open to suggestions, but if not, I'm inclined to just create another jobset. wdyt?
<mark_weaver>civodul: when creating an evalution, in cases where a cached build already exists (based on matching the output file names), I don't think it updates the 'drvpath' field of the relevant build.
<mark_weaver>so, the old 'drvpath' is retained, even if it doesn't exist any more in the store. I've seen many cases of this since Hydra's disks died.
<civodul>or did you notice important packages that were not rebuilt?
<civodul>we could try to start with specific examples first
<mark_weaver>however, I looked at Hydra's evaluation page to see what packages were not yet built, and it seemed that everything I needed was built. but then when I tried to actually update my profile, it was a *lot* of stuff to build.
<mark_weaver>gcc-6.1.0.i686 is one example that popped out at me, since it's a big build.
<mark_weaver>civodul: http://paste.lisp.org/+6WA5 is a list of what I would have to build locally to update my profile. most of those things are recorded in the postgresql database as being successfully built.
<mark_weaver>a few of those are due to my local modifications, e.g. using emacs-25.1-rc1
<mark_weaver>I guess for most systems this would be reasonable, but in this hot weather my X60 is prone to overheating.
<Sleep_Walker>I'm bug hunting terminology bugs and I'm adjusting all the package definitions of its dependencies to contain debug output to be able to open debug information in GDB
<Sleep_Walker>(and surprise surprise, I need to build packages locally as well :/ )
<mark_weaver>Sleep_Walker: we should probably build "debug" outputs for more of our libraries, maybe in the next core-updates cycle
<ng0>can someone give me the french and spanish translation for: "Graphical front-end tools for GNUnet, the anonymous and censorship resistant network" ? I lack daily usage of those languages so they are pretty weak at the moment
<Sleep_Walker>leaving -ggdb aside, I still think that adding debug output shouldn't change the hash and should be done from command line
<mark_weaver>Sleep_Walker: the problem is, adding a "debug" output changes the derivation, and thus the corresponding library has a different output path, etc, and that won't be the same library that programs are actually linked to.
<mark_weaver>unless we actually add "debug" outputs in the core libraries that are actually built against in Guix by default.
<ng0>hm.. the short description.. P2P segurizado GNUnet if i want to append ( Graphical front-end tools ), it would be something like ( Herramientas gráficas de usuario ) but this feels incorrect for what i remember, grammar definitely wrong, but "de usuario" also needs something added?
<es_CO>The short description is "P2P segurizado GNUnet"? That's not Spanish :)
<ng0>oh. it would be great if you could look at the gnunet-gtk (maybe even gnunet) translations files when you have time to parse if there are mixups between languages similar to spanish. or i'll just open a bug about "double check spanish translations for correctness"
<ng0>this new .desktop files is based on an older, already translated file i think
<ng0>"If you've found a translation mistake in one of the messages of gnunet-gtk, please report it to the email address that is given on the relevant language page." so maybe get in contact with this translator first i guess?
<ng0>there is an installer, through the way outlined in the documentation, which is pretty strightforward when you read it. but if there are problems in the documentation, we are open for suggestions and fixes
<ng0>i just download 3 years of mbox archives. when i have figured out how, i will process and compare with what's in master and certain keywords, and see how many [PATCH] etc are still open right now i'm doing 6 months manually.
<sovs_>does it also support LUKS by default like the debian netinstaller?
<ng0>for me right now search: tag:guix AND pushed NOT tag:guix::patch:done works for 1200 of the 5000 messages in patches.
<ng0>should map -unread +guix::patch:done to a key.
<itorres>hi everyone, I am trying to install GuixSD but when running "guix system init /mnt/etc/config.scm /mnt" the install fails while trying to download NetworkManager-1.0.10.tar.xz with a 410 http status. Is building from source with '--falback' the only workaround?
<itorres>ah, funny, the --fallback is not a parameter for guix system so I am stuck