<lfam>sneek: later tell Common_Era: Assuming you are using GnuPG 2.1, you need to install a pinentry program (probably pinentry-tty) and then give the path to your pinentry program as the value of 'pinentry-program' in ~/.gnupg/gpg-agent.conf. Or, use an older version of GnuPG that doesn't require the gpg-agent / pinentry
<rekado>just by defining NO_C_HEADERS before including the R headers.
<rekado>the NEWS file says that the manual always said that R headers should not be included from within an extern "C" block. All applications that are broken because of this 3.3.0 change ignored this advise.
<rekado>looks like it's SWIG that produced the wrong code.
<katco>rekado: hey, sorry just catching up on your message yesterday re. calibre
<katco>rekado: i am interested in a more general question about guix: how do we maintain package quality? shouldn't failing packages be rolled back to the prior revision or removed from the public offering?
<katco>rekado: and shouldn't there be some kind of gating process for landing new revisions? (or is there?)
<htgoebel>civodul: So I'm still postponing it until we have `staging`.
<katco>rekado: ty for taking the time to explain, this makes sense
<davexunit>katco: you touch upon a common misunderstanding with guix. if you use the *same* version of guix, you get the same results. but when we update a package in guix, that new version of guix includes new version of the packages that are affected by the change.
<rekado>I'll get more memory for my laptop tomorrow, so I hope I'll be able to build Qt components soon without my machine locking up
<civodul>htgoebel: yes, this admittedly isn't a great situation :-/
<thomasd>(FYI I just submitted a qtwebkits package, couldn't this solve the Calibre problem?)
<katco>davexunit: but a version of guix can have multiple versions of packages, so it's still possible to pin a package to another isn't it?
<davexunit>katco: sure, but in general that is undesirable.
<davexunit>using the latest stable releases as often as possible is important for maintainability and security.
<katco>so this confuses me a bit, because to me one of the great benefits of guix is i can update things independently w/o affecting other packages... but if the goal is dep uniformity, how is that goal met?
<rekado>thomasd: this might be enough, actually. I can't really review any patches until next week, though.
<rekado>(unfortunately you won't get any binaries from hydra because space is finite)
<katco>rekado: i tend to go directly to the most base questions i can think of, and to usability/ease. in this case, new users won't have all this context and will only know that calibre is broken in guix
<rekado>in other news: I'm nearing the end of my quest to upgrade ipython + notebooks + jupyter
<lfam>Hm, it seems that for beautifulsoup4, the Python 2 package should be the "primary" package, and the Python 3 variant should be tacked on. The reverse of what we normally do. Beautifulsoup4 is still developed in Python 2, and distributors are expected to use a provided conversion script to build with Python 3
<lfam>How can I "clear" the (arguments) of the python2-variant of beautifulsoup4, which inherits from python-beautifulsoup4?
<lfam>Giving an empty list to (arguments) in python2-beautifulsoup4 does not work. It even causes Python 3 to be involved for some reason!~
<lfam>Everything seems to work when I manually specify `(#:python ,python2) in the arguments of python2-beautifulsoup4, but that doesn't seem like it should be necessary
<nckx>Your guix-commits notification arrived a day or so late (I need to yell at my mail host again), I remember thinking ‘huh, lfam cherry-picking my patch to core-updates. Weird.’ and promptly forgot about it.
<nckx>Didn't realise it was a dupe until just now.
<lfam>I should have made the commit on master anyways. I was just thinking of it as a core-updates build failure fix, but there's no reason not to have done it on master
<nckx>That said, I don't think btrfs-progs needs to go to core-updates. Not that it would usually matter, of course.
<lfam>At this point, we are merging master into core-updates frequently, to get ready for the new release. That's why it should end up on core-updates
<lfam>I'm working through all the Python test suites that we never ran before. I wouldn't mind some help :)
<lfam>I've made the ugly choice of simply disabling them in the cases where it's not easy to run them. I figure this is okay since we weren't running them previously. Those who depend on the packages can pick up the slack :)
<lfam>Does anyone understand the python-sqlalchemy-utils failure on core-udpates?