IRC channel logs


back to list of logs

<phant0mas>good morning guix
<atheia>Good morning all!
<sriharsha>Hello Guix!
<zerwas>Hey sriharsha
<sriharsha>I have been out for a while. How are the prospects for a release now that we have migrated to /gnu/store and have some important bug fixes to core-updates.
<mark_weaver>sriharsha: I think we're fairly close, just a handful of issues to be fixed first.
<mark_weaver>sriharsha: btw, I wanted to mention that I would indeed like to get you shell access to a MIPS machine where you can debug the GNUnet problem, it's just that I've been overwhelmed with other things such as the recent Guile release(s).
<sriharsha>Thanks! It can wait until you are free :-)
<mark_weaver>what do you think is the best way to get your ssh public key to me in such a way that I have some confidence it is really yours?
<mark_weaver>(and not from a MitM)
<sriharsha>I can send it to you via email signed with my GPG key:
<sriharsha>I haven't actually met any of the Guix devs in person yet, but if you trust RMS and CA cert, you should be willing to trust that key is mine :)
<mark_weaver>ah good, your GPG key is signed by some people I know. that will be fine, thanks!
<mark_weaver>is it RMS's new key?
<sriharsha>I don't think so, I met him in 2012 and he has been using that for a while by then
<mark_weaver>oh, his old key. well, it's good enough. there is some basis for trust here anyway :)
<mark_weaver>I've received RMS's key fingerprints from his own hand.
<davexunit>after this weekend's libreplanet, I've decided that I need to really dedicate some time to learning to use GPG, tor, etc.
<davexunit>someone at the Tor booth recommended that I generate my master GPG key on a machine that is never connected to a network. did any of you do that?
<sriharsha>while you are there, do checkout this too: &
<davexunit>sriharsha: they were selling smart cards, but I didn't buy one.
<davexunit>I donated $20 before I realized they had anything for sale.
<sriharsha>oh, you should have; that could have saved you some shipping
<davexunit>yeah :(
<davexunit>sriharsha: would I need both of those things or just one?
<sriharsha>just one
<davexunit>the smart card looks cool, with the con that I also need a reader to go along with it.
<sriharsha>the crypto stick is more convenient. It is a smartcard with a built in smart card reader.
<davexunit>okay. I might go that route.
*mark_weaver goes afk for a long while...
<davexunit>bye mark_weaver
<mark_weaver>(it's my nephew's 3rd birthday)
<mark_weaver>happy hacking!
<davexunit>happy birthday to the little guy!
<sriharsha>The cryptostick it a bit expensive and their supply is limited. I bought a smart card and a used smart card reader for 5 euros from ebay.
<davexunit>yeah they are out of stock.
<davexunit>I guess I'll go the smart card route.
<sriharsha>you should also try to do what is suggested for generating GPG master key from an unplugged computer.
<davexunit>regarding actually generating a GPG key: I need to be reasonably sure that I generate it on a machine that isn't compromised in some fashion.
<davexunit>so my thinkpad won't do because it's been online on many occasions, of course.
<sriharsha>The main problem here is how predictable the entropy on your thinkpad is going to be since it last went online
<davexunit>I currently don't have any machines that remain offline.
<sriharsha>so, if you were to do some work offline for sometime (may be > hour ?), you should be fine I guess.
<sriharsha>The real problem is where you store your master key
<davexunit>I also have a desktop computer that I could leave offline for awhile.
<davexunit>yes, good point.
<sriharsha>Ideally, one would generate and leave the master key on a computer that would never be hooked to the grid. Message encryption and signing are then done through subkeys which are added to the master key.
<davexunit>hmm, I don't where to store that safely.
<davexunit>maybe I should buy one of those gluglug x60 computers to store it.
<sriharsha>you can take a print out of the encrypted master key. See
<davexunit>would you recommend this approach over storing it on an off-the-grid computer?
<sriharsha>yes, you will anyway have to store in another medium lest your off-the-grid computer gives up its ghost
<davexunit>okay. thank you.
<davexunit>I know way less than I should about crypto.
<davexunit>thanks for helping me start to correct that.
<sriharsha>you're welcome :-)
<civodul>Hello Guix!
<sriharsha>Hello civodul
<civodul>an embarrassing bug that mark_weaver found ;-)
<sriharsha>civodul, is there is guix download method to pull from SVN?
<civodul>sriharsha: not yet
<civodul>it should be easy to add though
<sriharsha>OK, would it be similar to git-download.scm?
<mark_weaver>civodul: I intend to produce a patch for union.scm in the next couple of days, that implements the optimization ideas I outlined and also fixes the bug.
<mark_weaver>and yes, I'll make sure to keep it purely-functional and readable.
*mark_weaver goes afk
<civodul>mark_weaver: excellent, thanks for working on it!
<mark_weaver>every time I run "guix package -i" I find new motivation :)
<civodul>heh :-)
<mark_weaver>sriharsha: fwiw, I also need a guix download method for SVN, to get the latest Bitlbee. If no one else does it, I'll get around to it at some point.
<sriharsha>mark_weaver, I am doing it as I need it like yesterday
<sriharsha>I will send the patches soon :)
<mark_weaver>sriharsha: btw, I have a question: when I download from the GNUnet SVN repo, how do I know that the code wasn't modified in transit? also, if someone broke into the repo and modified it, how would that be detected?
<phant0mas>civodul: after a talk I had with David Michael, who is building his own hurd system from source I found that I shouldn't run autoreconf inside libpthread but just rerun it in the base glibc folder after I place the libpthread folder in it
<mark_weaver>sriharsha: excellent, thanks!
<civodul>phant0mas: oh, that's useful info, indeed
<phant0mas>trying his suggestion now
<mark_weaver>sriharsha: GIT has a nice property that the commits are referenced by cryptographic hashes, and things are done in such a way that if the repo was changed, devs would likely notice it when pulling.
<sriharsha>mark_weaver, you have to rely on trusting the https connection to
<civodul>phant0mas: oh yeah so libpthread/configure just sets $libc_add_on_*, right?
<mark_weaver>sriharsha: i.e. any CA in my trust store could forge the cert and enable a MitM attack, right?
<sriharsha>mark_weaver, there is a gnunet-svn mailing list where you can alerts for every commit
<civodul>maybe tags or commits are signed?
<mark_weaver>sriharsha: yeah, but if the repo was compromises, I suspect changes could be made without adding a revision, no?
<sriharsha>also, when we do an svn-fetch we stick to a commit and its hash; so we can be sure that we get what we wanted
<sriharsha>mark_weaver, oh, yes. True.
<mark_weaver>sriharsha: I guess what I'm suggesting is that GNUnet should switch to GIT for security reasons.
<mark_weaver>the security properties of GIT are far superior to any other VCS I know of.
<sriharsha>I agree, but Christian has his own reasons for sticking to svn, main one being able to enforce all devs commits are streamlined..
<phant0mas>civodul: David is using the same glibc branch I use in my recipe
<phant0mas>I am now checking the one used in libpthread in his packages
<mark_weaver>"streamlined"? what does that mean?
<sriharsha>as is it forces all developers to commit to the one and only one repo.
<sriharsha>no branches and merges.
<mark_weaver>git supports hooks to enforce flexible policies.
<mark_weaver>I suppose I should make my case to grothoff himself :)
<sriharsha>OK, this git vs. svn has been debated time and again on #gnunet
<mark_weaver>I wonder if the security problems of SVN have been raised.
<sriharsha>hmm, I don't reckon so. May be this point can win the long debated argument. :)
<mark_weaver>sriharsha: what is grothoff's nick?
<sriharsha>grothoff and sometimes grothoffhome; he is on holiday till next Monday
<sriharsha>best is to leave a message on
<mark_weaver>okay, thanks
<civodul>mark_weaver: i think i'm giving up on putting glibc's bash in libexec for this time
<civodul>so i would be OK for merging core-updates
<civodul>well i still need to see what Hydra thinks, of course
<mark_weaver>civodul: okay, either way. it looks like 2ed6aa9e398b99296144dca364012f41764a8e89 will force me to rebuild everything anyway, which is fine :)
<mark_weaver>the issues I know about in core-updates so far are: (1) the libffi thing, (2) 'shadow' is missing upstream source, (3) parted fails to compile (maybe broken by the readline upgrade?)
<civodul>mark_weaver: yeah i know, but this had to be done
<civodul>shadow and Parted can eb fixed anytime
<mark_weaver>agreed. libffi is the only important one left.
<phant0mas>civodul: glibc needs a specific version of autoconf, 2.68
<phant0mas>should I just make a patch bypassing that?
<mark_weaver>civodul: am I correct in guessing that changes to union.scm don't force a rebuild, and can be done at any time in master?
*civodul checks
<civodul>mark_weaver: yes, it's only used for profiles
<civodul>phant0mas: yes, either that or add the version that it needs
<sriharsha>civodul, so I added the svn-fetch. How can I be sure that when a package uses svn-fetch, subversion is already installed in store? Should I include subversion as build dependency somewhere or will the derivation treats it as one automagically?
<mark_weaver>civodul: okay, well, I plan to get the union.scm changes done in the next two days. but if you'd like to apply a workaround to libffi.scm in the meantime and merge core-updates to master, that's fine too.
<civodul>sriharsha: yes, make subversion an input of the derivation, just like git is made an input in git-download.scm
<civodul>and it'll just work
<civodul>mark_weaver: i think i'll leave libffi as is, then
<phant0mas>in aclocal.m4 files it says that it requires that everyone use exactly the same Autoconf version so that the internal functions defined and used by the main configure script match those expected by the fragments.
<civodul>phant0mas: then see texinfo.scm for an example of how to define a secondary version
<civodul>and add something similar to autoconf.scm
<mark_weaver>civodul: is there any reason why a symlink inside the store would point to something outside of the store, or could that be considered an error?
<civodul>mark_weaver: for union-build, it's an error
<civodul>that never happens normally
<mark_weaver>okay, thanks.
<phant0mas>civodul: I created autoconf-2.68 recipe but I am using the autoconf-wrapper in my glibc recipe
<phant0mas>should I create an autoconf-wrapper-2.68 as well? There I will only change the input to use the autoconf-2.68
<civodul>phant0mas: yes, you need that too
<civodul>so i suggest turning autoconf-wrapper into a procedure that takes 'autoconf' as its argument
<civodul>so you don't need to duplicate it
*civodul has to go
<phant0mas>mark_weaver: I am getting a "autom4te: cannot open configure: Permission denied" when running (system* "autoreconf" "-vif") in the glibc source folder
<mark_weaver>phant0mas: I guess that you're using a source directory directly from the immutable store directory that was checked out from git. you need to copy the source directory and use the copy.
***civodul changes topic to 'GNU Guix --- --- 0.6 is in the works, and you can help!'
*mark_weaver is working on union.scm now
<phant0mas>civodul: I sent the autotools patch
<civodul>phant0mas: cool, will look at it before going to sleep
<zacts>so I've just discovered that apple disallows gplv3 software in the apple 'app store'.
<zacts>gosh, their loss.
<zacts>let's make guix so cool that in house apple devs will be begging the CEO of apple to let them use it.
<civodul>let's make it so cool that they'll realize they'd better leave that company and share the software, even
<zacts>civodul: indeed
<zacts>anyway, apple scares me. on the topic of guix, are there any easy high priority projects I can work on?
<civodul>there's packaging, there's
<civodul>and also, try out "guix system vm" and fiddle with it
<zacts>neat I'll check it out
<phant0mas>going to sleep, see you tomorrow