<civodul>i'm running a subset of Savane to extract the news items from Savannah <paroneayea>(sorry, I guess that doesn't raise your spirits!) <civodul>i invite you to browse the news section of the site :-) <civodul>i'm sure there's room for improvement, but that's already so much better <paroneayea>civodul: news releases with guix will be much nicer now. <civodul>paroneayea: yes we'll use the syntax highlighting thingie <civodul>but here i just imported everything as-is <civodul>but Haunt 0.2 doesn't have that, does it? <civodul>oh i didn't rewrite links to news entries <Common_Era>How can I generate a GPG key in GuixSD without a GUI? I'm being given a no pinentry message. I've looked it up, but none of it applies here. <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>looks like Emacs 25.1 with xwidgets leaks memory. According to htop my Emacs uses 20.6 percent of my memory, leaving only very little for my massive browser session. <rekado>gotta try what will become 25.2, which uses webkit2gtk+ <htgoebel1>I can't find thunderbird in guix thus assume it is still missing, Or does it have a different name? ***htgoebel1 is now known as htgoebel
<efraim>I don't think anyones worked on it yet <rekado>htgoebel: I don't know if anyone is working on Thunderbird. AFAIK nobody has called dibs on it :) <ng0>can we packageit though? <ng0>there was a reason why ice-whatever-for-thunderburd existed <ng0>one I can imagine is the mozilla store, present in all(?) mozilla products <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. <civodul>it's unsual to expect *users* to add 'extern "C"' <civodul>good practice is to add #ifdef __cplusplus extern "C" { #endif <rekado>I guess now I can fix shogun 4.1.0 as well. It also uses swig to generate bindings to R. <htgoebel>ng0, rekado: Sounds like for thunderbird one needs to have dee knowledge about internals ans gotchas?! <ng0>is the ice-variant now a) obsolete or b) no longer developed? <ng0>the only problem I see for guix is mozilla store, that's all <ng0>icedove was the name <ng0>one of those tripped-out animal logos <ng0>icedove-45.4.0-1 .. looks active? <htgoebel>I think to remember some message that debian is discontinue icecat and reverts back to firefox, since copyright issues are now solved. <ng0>no, that's just an exception for debian <ng0>doesn't apply to other systems <ng0>from what I understand <ng0>iceweasel was discontinued and they use now firefox. icecat is a different project. and icedove is still in debian as they have an open bug on it <civodul>htgoebel: it's not a copyright issue but a trademark issue <civodul>but yeah, ISTR that Mozilla's trademark policy has changed in the right direction since then <htgoebel>This is irritating: debian has firefox again, but thunderbird is still icedove <ng0>read the bottom of the page, it's just a matter of fixing the bugticket <ng0>I already closed the page, but there was something about "future considerations: move to official branding" or something like that <ng0>with a link to a bug ticket <htgoebel>so we are going with thunderbird and thunderbird-esr? <marusich>civodul, how is it that the operating system configs defined in gnu/tests/install.scm get run? <marusich>Hi there. I've got patches ready for the 'guix system' stuff, but no tests. <civodul>marusich: they are run via 'make check-system' <marusich>I mean, what runs them when you run make check-system? <civodul>'check-system' starts a tiny script, build-aux/run-system-tests.scm <marusich>I grepped for the defined variables, but found nothing, so probably there's something fancier than I expected collecting them and running them? <civodul>and the script automatically discovers public variables that match 'system-test?' <civodul>with <system-test> being defined in (gnu tests) <marusich>Are all the tests supposed to pass? Two of them fail - the nss-mdns and the encrypted-root-os. <marusich>I get the feeling like they've never passed on my system <thomasd>after running `guix gc` fonts in emacs are not anti-aliased anymore. I also get a "Fontconfig error: cannot load default config file". Any ideas? <htgoebel>I'm still stuggling with "guix system vm". This build the vm and gives me a script, but <htgoebel>a) how to access the ssh server running in there? <htgoebel>b) it seems to be a read-only vm, since the lsh-random-seed is generated on each boot. How do i easily get a vm which keeps this state? <htgoebel>I volunteer for updating teh manual once I have it running :-) <ng0>it was suggested to me to copy the vm out of the store <ng0>I went on to test what I write on a system I do not need <ng0>way easier than figuring out what is broken for me <ng0>well not broken but something which behaves differently than qemu on other systems <htgoebel>ng0: copying out of the store is what the manual says. <htgoebel>You need to copy some image and adopt the script :-( <htgoebel>If I'd be more used to this guile stuff, I'd write a patch, So I can only write a bash or python script for myself :-( <ng0>it takes time to get used to and learn it.. system-services are where I am slow now. I thought by now I'd be finished with all 3 of the services I write <ng0>if you can figure out how to make the "system vm" more convinient, that would be great :) <wingo>i never had video conferencing work on this guixsd laptop -- icecat and meet.jit.si never worked, obviously no hangouts, etc <Petter>wingo: Have you tried appear.in with IceCat 38? This always crashed for me. Haven't tried IceCat 45 though. <htgoebel>Hard to understand, hard to implement for average users <htgoebel>Hmm, even after copying the vm-image out of the store, lsh wants a random-seed on every boot. <marusich>civodul, I've sent the patches. I might try adding system tests later. I'm pretty tired, so I'm gonna go to sleep now. Goodnight! <marusich>htgoebel, what are the command line flags you're passing to the vm? <marusich>the -snapshot flag will make it so that any changes you make will be lost, so if that's being used, that's the problem. <htgoebel>maurisch: none. Just those in the script <marusich>Maybe it's the disk image? You could inspect it with qemu-img <ng0>civodul: regarding pypi-uri in import pypi: there was a patch series in october of 2015 by cyril roelandt, I'm not sure if it got merged <ng0>starting with: [ 32: Cyril Roelandt ] [PATCH 00/12] Tons of patches to run "guix-tox" on python-keystoneclient! <htgoebel>civodul: The the manual "guix system" is hidden in section 7.2.13, while all other utilities are listed in 6.x. Any reason for this? Otherwise I'd make 7.2.13 to 6.x, too. <civodul>htgoebel: it's because it's under "GNU Distribution", which talks about GuixSD <civodul>there was a proposal to move everything under "GNU Distribution" one level up <rekado>I told Guix in my arm VM to "guix environment gcj" and it now compiles binutils-cross-boot0-2.25.1 <rekado>why would it need the cross binutils for building gcj? ***Gottox_ is now known as Gottox
<civodul>rekado: it's "cross-boot0", the "fake cross-binutils" used for bootstrapping <civodul>that said, it shouldn't depend on it, or that'd means that %final-inputs indirectly do <civodul>or does everyone ignore XML name spaces in practice? <davexunit>civodul: I don't know that much about Atom, but if it's better to have the xmlns in the <feed> tag then I think it would be a good idea to include it. <davexunit>civodul: but wait, does this mean that the guix site is using haunt now? <civodul>which also means you'll have to make a release ;-) <davexunit>alright, so there's a few things to patch in haunt right now, then a release is in order. <davexunit>I think paroneayea also mentioned my guile-syntax-highlight project at some point <civodul>ah yes, i thought it was part of Haunt master <davexunit>no it's separate since it's a general-purpose thiong <davexunit>so far it works well enough to highlight everything on my own blog <davexunit>yeah I think it will make the Scheme snippets in the Guix news posts more appealing <rekado>civodul: thanks for converting the news page! It's so much prettier now. <civodul>anyone knows of an news reader or someting to check whether the links in the feed are valid? <civodul>i'd like to make sure before giving the new URL to the planets <paroneayea>civodul: liferea is a nice feed reader; there's also elfeed for emacs, which I think is already packaged <davexunit>civodul: I just opened my feeds in icecat to test them out <davexunit>and they worked fine there, but maybe testing with more readers will reveal problems <davexunit>now, is that just a simple mistake or a haunt bug... <thomasd>civodul: feeds also work fine in "feedly" <rekado>I remember that there's a bug in haunt relating to feeds. <rekado>something about my atom feeds on elephly.net was wrong. <rekado>there's a TODO item in my org files about this I think <rekado>it's a bug db that's part of your repo <davexunit>rekado: I guess I was hoping for something web-based <civodul>davexunit: your feed has the xmlns thing, mine doesn't <civodul>davexunit: maybe there's a fix in Haunt master? <rekado>I used Haunt from what was then the latest commit in master <civodul>it's able to read the atom without xmlns <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?) <paroneayea>civodul: I've been meaning to set up elfeed here. <atheia>elfeed's very nice. And pretty damn fast! <rekado>katco: we have continuous integration with hydra. Packages that fail their build can be seen there. <rekado>then we have people who check this list and see if they can do something to fix this. <rekado>arguably there are not enough people who do this <katco>rekado: ah ok, ty for the context :) <katco>rekado: so, the issue with calibre is (obviously) known, but no one has been available to fix it? <rekado>in the case of calibre it's not a problem with calibre itself, but with a larger change in a dependency <katco>rekado: wait... i thought this was the entire point of guix? shouldn't the calibre package be pinned to a certain version of the lib.? <rekado>katco: I started packaging the missing component, but it's big and has quite a few dependencies, and it's competing with other things for my attention <rekado>if you had an older version of calibre it should still work <rekado>i.e. installed before the change <rekado>we usually don't pin things because breakage is relatively rare <rekado>in this case it's a little difficult to undo the change because it's largely positive <katco>so in this case, would the quick path forward be to just update calibre to pin the lib to the old working dep? <htgoebel>civodul: Remember my patch a view days ago changing the cmake build system? When should I commit this and where? <rekado>more context: Qt comes with a web browser widget, and that widget bundles chromium. <rekado>and chromium bundles uncountable libraries <rekado>which means: lots of potential security vulnerabilities <rekado>to fix this obvious problem for the distribution we disabled that widget <civodul>htgoebel: i forgot the details of the patch, but it seems it should go to 'staging' (which you would create) <rekado>katco: we also split up Qt into separate modules <civodul>htgoebel: however i'd prefer to do that once we've merge core-updates <katco>rekado: ahhh ok this begins to make sense to me :) <rekado>katco: now to fix this it's better to just package the needed module separately and only add it where it's really needed <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. <katco>davexunit: can you explain why? <davexunit>whether or not to keep multiple versions of a package around is done on a case by case basis. <katco>no i meant, not a general rule to keep old versions around :) <davexunit>the places where we have multiple versions are exceptions to that rule <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>katco: you can do this as a user <katco>davexunit: i thought grafts were useful for this? <katco>i don't doubt it :) i have not delved very deep into guix. i mainly use it passively <davexunit>the benefit you're talking about is multiple users (or a single with many profiles) being able to manage software environments independently without interfering with each other <katco>ah so i'm at the wrong level of abstraction <davexunit>in guix itself, each package doesn't have a completely separate dependency graph. that would be unmaintainable. <davexunit>a complete combinatorial explosion of madness. <davexunit>if you look at any given package recipe. it will reference variables defined in other modules that are bound to package objects. <davexunit>thus, if you change the package that is bound to that variable, it in turn changes the things that use it. <katco>so in that sense it's not dynamically coupled, it's "statically" coupled <davexunit>I don't know the distinction you're trying to make <katco>i think i'm on the same page, just not expressing it well <davexunit>think of each change made as a new version of guix <katco>yeah, i misunderstood the goal of guix itself <rekado>"statically coupled" is actually not a bad expression: the binaries really do retain static references to their dependencies <rekado>this is what allows you to keep multiple versions of any package around <rekado>(and have installed software remain unchanged no matter what you do) <davexunit>right, even if the version of guix you are using no longer describes the software you have installed, it's still there and you can still use it. <rekado>so in principle you *could* use a version of Guix from before the change to Qt and install Calibre from that point. <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 <katco>rekado: so wondering how to mitigate that <davexunit>katco: generally we check the number of rebuilds that will occur when updating a package <rekado>katco: with the patch provided by thomasd :) <davexunit>if the number is large, we typically put the patch in a special branch and have the CI system build it <rekado>it would be nice if we had the capacity to keep updates separate from additions. <davexunit>and merge it once everything is rebuilt and there is a good success/failure ratio <davexunit>but right now it's more important to keep pressing forward <rekado>both in terms of developer power and in backporting patches <katco>glad to see level heads have considered all of this :D <davexunit>at my job we use guix on some servers. I rarely update the version of guix we use to ensure stability. <rekado>level heads are the natural result of bumping into these problems repeatedly :) <katco>do you have to update guix to get new grafts? <katco>i.e. how do you manage cves? <rekado>as a sysadmin I guarantee availability of all software we need, so I update whenever all of our packages are available <rekado>the work I do here for our site is very much like what a stable branch would be like <katco>davexunit: so you fall out of guix to do security patches? <katco>davexunit: sorry: you don't use guix to manage cves <davexunit>guix devs update packages in response to CVEs <rekado>katco: we never patch software in the store manually, if that's what you meant <katco>davexunit: sorry: i use guix to keep my guix-deployed software secure: e.g.: guix pull; guix package -u <rekado>instead we'd backport changes to package definitions <katco>davexunit: it sounds like you manage cves without invoking guix? <davexunit>yeah backporting is one way to do it. in the future an official guix stable branch will be the answer. <rekado>katco: most of us run Guix from a git checkout. <davexunit>my dependency graph is small enough that I don't have to update for much. <rekado>katco: there we can update individual package definitions and update the packages we have installed. <katco>rekado: davexunit: ty both for your patient explanations <rekado>so... I have python-jupyter now. But I don't know what to do with it... <rekado>I cut corners by not upgrading to ipython 5.x; this is still at ipython 4.0.0 <rekado>the r-* failures look like they are fixed on master <rekado>mostly bioconductor stuff with unstable URLs :-/ <rekado>both ardour and mod-host fail to find -lfftw3f_threads <rekado>I'll try to reproduce this later <htgoebel>rekardo: I suggest naming the package just "jupyter" now, since it is no longer specific to python. <kyamashita>Has anyone here packaged software with the program files written in DOS format? <kyamashita>My patches won't apply, and I was wondering if there was a way around it. <lfam>Does anyone know a fast way to test an update to libwebp? <lfam>I mean, what's a cheap way to see if the new updated + patched libwebp works as expected? <lfam>Did you notice we both updating btrfs-progs? :p <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 <lfam>It makes me wonder what we missed! <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>At least that's my understanding <nckx>lfam: But through master, right? (For non-rebuild-intensive packages.) <lfam>nckx: Yes, and that's what I should have done for btrfs-progs <lfam>And what I just did do for several things <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? <lfam>python-seaborn's tests fail because it can't find a graphical display