IRC channel logs
2016-07-31.log
back to list of logs
<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>option (2) has the advantage that it would also enable things like 'tor' to be used for downloads from the very beginning. <civodul>i thought about out-of-band downloads too <civodul>re Scheme implementation, TLS 1.3 is said to be clean and relatively "easy" to implement <civodul>short-term maybe we could have a gnutls-minimal, and/or gnutls-bootstrap too <mark_weaver>TLS 1.3 might not be enough. it would need to be enough to successfully download everything needed by gnutls. <wgreenhouse>ng0: nod; I'm willing to use system tor for the daemon, if that removes the libevent dependency <ng0>i don't know. my build process is different from what guix will be able to do, guix will be more flexible :) <civodul>ng0: "out-of-band" as in download is performed on the host side rather than as a derivation <ng0>ah, i think i understand it <mark_weaver>civodul: fwiw, I suspect that the "out-of-band" approach is the best one. <mark_weaver>at some point, we'll want to radically reduce the set of bootstrap binaries, and fitting the needed networking support in there will be problematic. <mark_weaver>and some people will want to use things like 'tor', which is a moving target. <mark_weaver>well, I don't have strong feelings about it... just a thought :) <mark_weaver>it also seems likely that the software needed to successfully download files from the network is likely to change. <mark_weaver>and if we try to include that code in the bootstrap binaries, the bootstrap binaries will need to change more often than I'd like. <mark_weaver>as new crypto suites become popular and older ones are deemed insecure <ng0>your reasons against including it in bootstraping are good <civodul>mark_weaver: agreed, i think it's the most viable solution <civodul>mostly because it sidesteps the bootstrapping issue entirely <civodul>it has its own set of challenges though, mostly in terms of performance <mark_weaver>civodul: I wouldn't have guessed that there'd be a performance impact. can you help me understand why? <mark_weaver>well, that's optional. I don't need to know, just curious :) <mark_weaver>oh, it's late where you are. don't answer tonight :) <mark_weaver>20 hours is no longer enough time for nss to complete its test suite on mips :-( <civodul>mark_weaver: if we download things on the "host side", we must have a local cache, avoid repeated add-to-store RPCs, and all that must be fast <civodul>not insurmountable, but requires some care <civodul>the idea would be to put it on the home page <civodul>i hadn't realized this was possible when i initially asked you <mark_weaver>nah, I'll do it now. should be there within a couple of minutes... <civodul>does Theora work in all relevant browsers or is WebM preferred? <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. <mark_weaver>ACTION just killed the 'update-package-list' process on hydra, since the load was at 22 <civodul>much smaller and the quality seems as good <mark_weaver>civodul: oh yes, that webm video looks good to me too.. I'll upload it. <civodul>surprising that it's 4 times smaller than that ogv <mark_weaver>civodul: the original file was encoded at a higher quality level than was needed. <mark_weaver>it's not that ogv is inherently that much worse than webm <civodul>i used the same command line though, except for the file name extension <mark_weaver>it probably has to do with the codec-specific default settings of whatever tool you used to encode those videos. <ng0>conversion is tricky magic tricks, with one file okay, batch conversion with multiple qualitys, codecs etc is harder. I dropped my attempt to batch conversion all -> webm <ng0>blame new layout. and it's late. good night <mark_weaver>the internet *is* the real world. it's becoming important to spread that idea. <ng0>we might have an xfce keyboard layout bug. at least with neo2, i could not switch out of the 6th level again with the help of more regular users of the layout. <ng0>then again, it is 4 keys at the same time so i'll try again when i know more about switching out of it <ng0>is there some special procedure involved when packaging gnome stuff? I'd like to have libgnomekbd <Sleep_Walker>Vincent Legoll is probably not present on this channel, right? <civodul>mark_weaver: the webm video i encoded yesterday doesn't work in browsers because of a wrong codec <ng0>so libgnomekbd was the easiest thing i packaged <mark_weaver>ACTION works to update his i686 and mips systems to core-updates <civodul>i thought you'd be asleep and would process later ;-) <civodul>mark_weaver: what should i look at on i686? <civodul>i'd like to help improve the situation today, for core-updates <mark_weaver>civodul: actually, on i686 we're in pretty good shape now. I just updated my system, with a moderate but managable amount to compile myself. <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 <civodul>we need to see what's missing for a merge <mark_weaver>I'll now try updating my user profile, which includes icecat <civodul>i've upgraded my system (on x86_64) but not my user profile yet <mark_weaver>ACTION is now using emacs-no-x from core-updates on mips <ng0>and even the drawings are not good... but it works <mark_weaver>looks like there's still too many missing substitutes on i686 for me to update my user profile yet. <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? <civodul>or click on "Restart aborted builds"? <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? <civodul>mark_weaver: i would think that Hydra can recreate everything that is current, since we have all the current .drv <civodul>i don't know, maybe i'm missing something <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>any idea what fraction of the packages did not get rebuilt? <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 <ng0>i can get half the sentence myself, rest idk. IT in both languages wasn't my prime focus. <ng0>contributing something to upstream <Sleep_Walker>mark_weaver: it would be enough to be able to add debug output to package from commandline (if possible) <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. <mark_weaver>Sleep_Walker: of course that's not going to be very helpful without debugging information <mark_weaver>see section 7.3 (Installing Debugging Files) in the Guix manual for more on that <kyamashita>Hi all. I am planning on writing a patch to include dmidecode as a guix package, but I don't know if I should include it in linux.scm or in it's own dmidecode.scm file. Any opinions? <suitsmeveryfine>Hi! I have trouble building guixsd from git. I get this error message: ice-9/eval.scm:386:9: Throw to key `match-error' with args `("match" "no matching pattern" ())'. <alezost>suitsmeveryfine: hm, did you maybe try different versions of guile (2.0, 2.2)? <alezost>I vaguely recall I had something similar and it happened because I used guile 2.2, while in my GUILE_LOAD_COMPILED_PATH I had some dirs for guile 2.0 <suitsmeveryfine>alezost: Thanks, but I found the problem. I had to run the clean command first. <ng0>someone pointed out the lack of gnunet-gtk.desktop, i'm fixing that right now. thanks <kyamashita>What is the difference between the alist-delete and delete procedures? <civodul>kyamashita: 'delete' removes an element from a list; 'alist-delete' removes a key/value pair from an alist <kyamashita>It's the only phase I'm modifying (besides #:tests #f) in this case. <a_e>kyamashita: No, the first way is the "modern style". The second one was the previous way of doing things, and not all packages have been modified yet. <ng0>a_e: huh. this is just for delete, not for add etc, like in (alist-add) etc? <ng0>example might be off. <ng0>maniüpulating phases i mean <a_e>ng0: No, everything is done with modify-phases now. Have a look at other packages. <ng0>i was irritated as I do it usually like in the previous submitted gnunet-svn <ng0>add-after / add-before instead of alist-add alist-delete <ng0>i can point out the patches we just forgot when i'm done with tagging next month. there are updates and new packages in there. <civodul>a_e: thanks for all the fixlets on core-updates! <ng0>that#s just the last 6 or 8 months though.. if i'd download archives mbox files and go through that (with a script then) I'd discover some more zombies i think <ng0>what happened to gnumach? i only find gnumach-headers in the current master. is it still on the wip-hurd? <civodul>ng0: i forgot, but phant0mas would know :-) <ng0>hope this highlighting was enough. otherwise i'll leave a note <ng0>jessica worked on "pass". are they in here, or should I just add it to the general list of thread(names) / packages i will point out? <phant0mas>hey ng0 let me catch up with the conversation <ng0>php7 and php-fpm also never got any discussion, at least from my [PATCH] limited search <ng0>hi. i'm tagging emails and marking some as wip i do not see merged <ng0>gnumach was not in master, only -headers <ng0>this was in february <phant0mas>ng0: yes this is true, we hadn't decide how we will package it <phant0mas>civodul suggested that gnumach-headers should inherit from gnumach <phant0mas>as gnumach-headers should exist before gnumach <ng0>i automatically assume due to the nature of email that several months no reaction - people forgot it <ng0>this tagging / indexing is showing me how much email sucks <ng0>at least having an email based workflow without a clear second alternative <phant0mas>ng0: thanks for reminding me, I will take care of it <Sleep_Walker>$ zcat /gnu/store/*-gcc-toolchain-6.1.0/share/man/man1/gcc.1.gz <suitsmeveryfine>Hi! Is this commit message alright: gnu: openttd: Update to 1.6.1\\n\\n* gnu/packages/games.scm <suitsmeveryfine>or should the last line be "* gnu/packages/games.scm (openttd): Update to 1.6.1. <ng0>gnu: openttd: Update to 1.6.1. second line: * gnu/packages/games.scm (openttd): Update to 1.6.1. <suitsmeveryfine>also, I've made a slight modification to the package description. Should I include this on one line also perhaps? <Sleep_Walker>ng0: btw any progress with neomutt? I miss my sidebar patches <es_CO>ng0: Spanish for the description you mentioned earlier: Herramientas gráficas de usuario para GNUnet, la red anónima y resistente a la censura. <ng0>not really working on it, the last state is in the thread the last patch i submitted this?last? week <ng0>thanks :) i'll update the patch for gnunet. <ng0>Sleep_Walker: feel free to take over. i don't need neomutt <ng0>priority is elsewhere atm <a_e>civodul: Funny failures in core-updates! The nice thing that comparing it to master, there are only about 70 failed packages. So it looks like a feasible task to start working on them. <ng0>basically you need to coredump and look at it <ng0>never needed a coredump, so that's why i was stuck with it <a_e>Maybe we could do another evaluation of core-updates once the current one is finished on x86_64 and i686. <rekado>even with a 4GB swap file the build of elixir fails for me *most* of the time. <rekado>this makes working on it really challenging. <ng0>es_CO: do you want me to point out that you want you name in the notes for contributions? <ng0>dunno how translations are handled since they use the translation project <es_CO>ng0: Nah. Go ahead and say you did the translation :) <ng0>i won't say it's my work, but i'll add it. thanks :) I should really find time to refresh my spanish and french :/ <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>so gnunet-fs-gtk.desktop is wrong <es_CO>I think it's ok to report a bug. <es_CO>ngo: Where are the .po files so I can take a look later? <ng0>thanks for discovering the bug :) <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>that's from the tp web site <es_CO>I'll take a look, and contact the translator. <ng0>ah, that's good. i tought i'd do it, but it's better if you feel like doing it because you spot errors where i don't :) <es_CO>ng0: but I can't find that string (P2P segurizado GNUnet) in the translations listed on that page (0.9.5, 0.10.1). <ng0>i do use HEAD 37273 or what it was, not 0.10.1 <ng0>but i think not much work happned in the .desktop files <ng0>sorry, HEAD, not revision 37273 <ng0>i'll wait for replies and discussion in #gnunet <ng0>thanks for looking into it <sovs_>ng0: does guixSD have any installer? <sovs_>ng0: as far as i know there was no cli and no gui installer <sovs_>to stop off-topic on other channels. yes <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>GUI installer is on the roadmap maybe <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>unrelated to your question, sovs_. <ng0>i think others can answer that easier, i'm occupied with other things :) <rekado>ng0: I’m working on something with mu-guile. <rekado>the workflow would be: subscribe a bot to the ML, download email with offlineimap or similar, run mu on the maildir, run queries on the mu db to find patch emails and interpret commands <rekado>with the results from that we can use Guile’s HTTP server to render a pretty overview page. <ng0>so similar to nmbug? <rekado>phrases like “Pushed [to <branch>] as <commit hash>” would be considered commands to move the thread to the archive. <ng0>i don't believe email is a solution, we need to get away from primiary email based, but a fix for the time between now and *thesolution* is already an improvement <ng0>nmbug is the thing notmuch uses <ng0>primary email based .. i mean emai lhas no way to provide organization, things get lost. if we have something with more than just one way to work that's what i mean <rekado>as long as there’s no commonly used replacement for email I think it’s the best way to contribute as it offers the least barriers. <ng0>webserver interface, email, commandline <rekado>ng0: it wouldn’t be lost with what I’m working on. <ng0>would you convert the whole history of the lists? <ng0>i did read your sentences again, i understand what you aim for. my reply was a bit beyond that <rekado>it wouldn’t convert as much as process the archive once. <ng0>ah, you have it all in maildir? or is there a way to retrieve maildir from mailman i don't know? mbox is the only visible way <rekado>I don’t know if mailman offers a way to get all mail in a maildir, but it’s not hard to convert from mbox to maildir once. <ng0>i only know how to convert from nnml to maildir. but i guess mbox to maildir is also easy <ng0>i'll finish analyzing the emails i still have (some got deleted already at some point) and post the results to the list <ng0>i need to do it anyway because i need structure in the tag <ng0>what you do is likely easier. <ng0>*i think what you do is for our situation easier <ng0>thanks for working on this <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 <civodul>itorres: 'guix system' accepts --fallback <civodul>but yeah, i'm afraid you'll have to build a bunch of packages from source <civodul>this is because 0.10.0 binaries have vanished from our servers :-/ <itorres>when adding --fallback I erased the target without noticing, sorry for the noisce :) <civodul>mark_weaver: i'm starting a new core-updates evaluation