IRC channel logs
2016-03-02.log
back to list of logs
<paron_remote> File "/gnu/store/h38982xp00s1g95nzr6lws31w8q8njb3-python-virtualenv-13.1.2/lib/python3.4/site-packages/virtualenv-13.1.2-py3.4.egg/virtualenv_support/pip-7.1.2-py2.py3-none-any.whl/pip/_vendor/distlib/compat.py", line 66, in <module> <NiAsterisk>if I have something.6 and it cotains the manual page of a software, what do I grep for, where to put it in a self written install replacement? <NiAsterisk>I'll submit the patch to devel if this builds now, and comment on the unclear sections there. good night <paron_remote>my suspicion is that if it weren't for the fact that openssl *removed* a huge chunk of their codebase <paron_remote>and in many other cases, it would be less of an ABI compatibility issue <mark_weaver>well, I'll start a non-graft rebuild in the meantime <lfam>mark_weaver: Maybe Fedora had already stopped building their Python with SSLv2 <lfam>Today's OpenSSL update removed SSLv2 from the default build <lfam>But it looks like some other packages still want to use SSLv2 via Python, so now they are broken. <Jookia>interesting, and grafting broke this? <lfam>Perhaps. Grafting is more appropriate for ABI compatible updates, and this wasn't one of those. I'm currently rebuilding Python against the new OpenSSL to see what happens <Jookia>So Parabola is the second distro to package Guix, after ... Guix <Jookia>lfam: Well, now we know grafting works <lfam>paron_remote: Since you have a lot of Python packages, you might have an opinion about this. We currently package pytest-2.6.1, but pytest-2.9.0 is available, and I'd like to update it. I'll read the changelog and commit log for warnings about incompatibilities, but do you have any objections? <paron_remote>lfam: I know of no problems.. I say update it, if it turns into a problem, I can package a derivative for the old version <lfam>2.6.1 is a from August 2014 <paron_remote>lfam: people in mediagoblin-land have been testing things lately, and over the last few weeks have been fine with newest pytest <paron_remote>so unless something really new came out and broke things <Jookia>paron_remote brought this up on the mailing list, but are grafts composable? Can we graft grafts to make grafts? <Jookia>It'd be useful to compose grafts for things where applications are statically linked or we need to do something more serious <Jookia>Graft theory feels a lot like Darcs patch theory <paron_remote>hey, where's the link to civodul's talks repository about guix? I know there's something somewhere <Jookia>I think it's on the developer page under maintenance stuff <lfam>paron_remote: I can 'import ssl' in python-3 built against the new openssl. Building python-2 now <lfam>paron_remote: python-2 works too <iyzsong>There is a typo (ilmbase-fix-texts.patch) in gnu-system.am <lfam>civodul *did* say the duration of the grafting is proportional to the size of the package ;) Do we have a package with a larger output? <paron_remote>what on earth is *in* texlive-texmf that makes it so huge anyway? <lfam>"all the major TeX-related programs, macro packages, and fonts that are free software, including support for many languages around the world" <lfam>I think it's been discussed... you can search guix-devel <lfam>That's what spurred me to look at pytest <paron_remote>davexunit: how did you install the metropolis theme for beamer? <paron_remote>I'm considering whether I should package it or just dump it in $SOME_PATH <lfam>This pytest upgrade is getting complicated <lfam>Extra complicated by the unpredictable effect of grafting the new openssl onto python <davexunit>paron_remote: I just dumped it somewhere in my home directory that happened to work <mark_weaver>lfam: fyi, I recreated the 'security-updates' branch again with 'openssl' updated to 1.0.2g without grafting <lfam>Why does python-hypothesis propagate python-flake8? The string 'flake8' does not appear in the hypothesis source code, and flake8 FTBFS now <lfam>mark_weaver: I saw that, and I'm doing my work on that branch now <lfam>Well, since *I* added python-hypothesis, it's pretty lame that I don't know why I put flake8 in there :( <mark_weaver>lfam: oh, too bad I didn't see that before I started hydra on the rebuild <mark_weaver>yeah, let's save it for the next time, or for core-updates <mark_weaver>it takes hydra a long time (around 3 hours) to create new evaluations, during which time no other builds can happen (due to its poor performance), and it's already spent over 2 hours on it <lfam>Lame. Looking forward to the replacement <lfam>Thankfully most security updates don't break ABI so severely <lfam>This was really a special case <lfam>To figure out what needs to be rebuilt when rebuilding the world <lfam>So that we can move past the graft <mark_weaver>no, 3 hours for hydra to create a new evaluation, which means the time it takes for it to build a new version of guix from git and queue new+changed jobs to rebuild. <lfam>Building guix from git has to be a small part of those 3 hours, no? <lfam>Although, I did notice that the test suite took *much* longer than I remembered when I ran it earlier today <lfam>That will be painful to bisect <mark_weaver>it's not built in the usual way. the building of guix itself is, I think, interspersed with creating descriptions of the jobs to be built in a way that hydra can understand <lfam>I've been asked to comment on behalf of Guix <lfam>Not just proofread, but give some feedback <lfam>That's first draft, I haven't rewritten yet <lfam>I've been communicating pretty closely with that upstream about packaging their software and related software, so I do have a stake in the relationship <lfam>I can probably skip the part about RSS / email. It's irrelevant and liable to start a flamewar <Jookia>lfam: Non-deterministic tests are a good thing that I plan to package in my software. Perhaps Guix could deterministically seed it <lfam>Most test suites that need "random" data already package seeds <lfam>I can mention that when I suggest he move the fuzzer outside of this test suite <Jookia>It'd probably be best if Guix takes a hash of something and uses that as a seed, that way it can also find issues <lfam>I mean... are upstream distributions going to start asking us to do AFL runs while building?! <Jookia>What if tests end up consisting entirely of fuzz testing? <lfam>Fuzz testing catches a different sort of bug <lfam>That would be an incomplete test suite IMO <Jookia>I use fuzz testing exclusively in my software, will you not run my tests? <lfam>You never do tests where you check that the output of a function is what you expect? <lfam>I think most of the test suites we run are incomplete. But if they make the build fail half the time, what's the point? <lfam>Fair enough, I'm going off the thing I wrote the response to, where that is suggested as a reason to not run tests <Jookia>I just worry a bit that you won't run tests because they rely on fuzzing to show correctness, like in Xmonad <lfam>I don't inspect tests before I decide whether or not to run them. <lfam>I always just write package definitions with tests enabled. I only inspect the tests if something fails <Jookia>They should probably... fix their fuzzing tests? <Jookia>If the tests fail, it's a bug by definition <lfam>I think I misunderstood their point, and you helped me realize it. Now my understanding is that they don't want us to help find encoding bugs? <lfam>I don't really get it TBH <Jookia>I think they think that tests failing isn't a big deal for shipping software <Jookia>Unless they think their tests are buggy. But that's still a bug, just with tests <lfam>I'd need to understand more about what kind of test they are referring to. Maybe if that test is expected to fail "safely", it shouldn't cause the whole suite to fail <lfam>This person is really serious about quality from what I've seen, so I really don't understand this email <lfam>Or github thing, whatever it's called <lfam>Abusing the bug tracker as a message board <lfam>That message wan't to you koz_ :) <Jookia>"Automatic test generation is a really powerful tool for finding encoding-related bugs, but it also means that tests may randomly fail." <- tests failing is a bug by definition, even if it's a bug in the test suite. so i guess they think a buggy test suite isn't reason to stop shipping, or that we can't disable broken tests <koz_>I was complaining at the awful Internet at my uni. <koz_>I'm just trying to install GuixSD. <koz_>And am hitting giant tracedumps on boot. <Jookia>"In other words, it's not just for finding bugs in vdirsyncer, but also elsewhere. Why would vdirsyncer-packagers care if a server introduced a bug that makes the tests fail?" <- again, aren't the tests meant to show issues <lfam>That's why I gave examples of upstream releasing broken things as "stable" <Jookia>I think what they're saying is that their tests are for development <lfam>koz_: I don't know... stick around until someone more knowledgeable shows up <Jookia>"Older pytest, hypothesis or Radicale versions may fail with bizzarre errors." this is very worrying and i don't see why they don't just set their dependencies properly- unless, again, they don't know wtf they're doing with their test suite <lfam>It's inconsistent from right before where they talk about setting minimum versions! <koz_>lfam: I'll try - if this internet ever behaves. <Jookia>"a simple vdirsyncer --help catches 80% of errors" how broken can your code be <koz_>I can't do this off-site, which somewhat limits my hours at present. <Jookia>koz_: I'll find the args in the minute <lfam>Jookia: That's the thing, their stuff seems pretty good. I see them fixing bugs in other projects left and right <lfam>Even doing development in related projects <lfam>Jookia: Okay, but what about the tone? I want to be respectful and non-confrontational, but also clear and persuasive <Jookia>lfam: Aside from my ranting, I think your email is okay but it seems that they don't want tests to find bugs if it's outside development. perhaps this is because they have nonsense bugs or low-priority bugs, or a wonky test suite. either way this is a problem upstream and they should probably fix this but also work with packagers to ignore tests that are known to break <koz_>Alrighty, Parabola/Guix it is. <lfam>kox_: Building Guix on parabola might give you some tools for debugging, such as `guix system vm`. <lfam>koz_: Did you seem my message about `guix system vm`? <koz_>However, this machine seems to force UEFI. <koz_>Which is probably why I was getting huge tracedumps. <lfam>Ah, that won't be reproduced in the VM I think <koz_>Which means I'll probably do Guix/Debian instead, since I can't deal with UEFI in Parabola. <koz_>(even their iso won't boot properly in UEFI...) <lfam>I'm glad to have avoided that for now. Sounds like a big PITA <koz_>lfam: If I had control over my hardware, I'd avoid it. <koz_>Basically, UEFI is a giant shitpile that I have *no* desire to make sense of... ever, <koz_>Unfortunately, this is the standard-issue computer here - at least I can change the OS. <lfam>Well, at least Debian can boot on it? <koz_>lfam: I *think* so. Trisquel worked, so Debian should work too. <koz_>(Debian meaning 'without contrib and nonfree' obviously) <koz_>I'd use Trisquel, but it's got too much stuff in it I won't need. <lfam>Hopefully Debian 'main' supports your hardware fully <koz_>Also, if I'm gonna be using Guix, will I actually have to run both apt and guix to update everything? <lfam>koz_: My primary workstation is Debian testing with Guix. I install most of the user-facing software with Guix. Some core stuff gets installed by both since disk space is cheap and I'm lazy. You'd better update through both systems <koz_>lfam: Is there a way to 'hollow out' Debian gradually by replacing more apt-overseen stuff with guix-overseen stuff instead? <lfam>koz_: Sure. Just install it from Guix, see if it works, and then uninstall it from Debian, and see if anything else breaks :) <koz_>That sounds ... dangerous. <lfam>koz_: I'm not suggesting you try to replace the Debian libc with one from Guix! <Jookia>koz_: Let's see what you can pass <koz_>lfam: That's probably gonna lead to hilarious ABI issues. <lfam>But you can't really break Debian just by removing an end-user application <koz_>lfam: Yeah, I get the user-end stuff. I'm curious how much hollowing-out Debian would tolerate. <Jookia>koz_: Are you on the same network as it, and is it wired to that network through Ethernet? Your machine can be on wifi <lfam>I'd be surprised if apt would let you do it, but with apt everyone is suffering stockholm syndrome so we treat it carefully <koz_>Jookia: I'm not sure about the 'same network' thing. <Jookia>koz_: Can you ping it if it's in Debian <koz_>I dunno how they deal with wifi vs. Ethernet stuff. <koz_>Jookia: Let me boot into it first. :P <lfam>koz_: I know at least one Guix developer installed GuixSD for the first *over* a pre-existing Linux distro. <koz_>lfam: Well, I'm still gonna need Debian to magic away the UEFI stuff. But I guess space *is* cheap, so yeah. <koz_>Plus, I'll likely install as small a Debian as I can initially. <koz_>ACTION wants his guile-wm. <lfam>Yeah, I usually install the "server" option with xorg added <lfam>Although I think the server release of Jessie kind of half-assed the systemd integration <koz_>lfam: I might not even get the Xorg part. Could I grab that via guix? <koz_>I'd basically like *the* most minimal, hollow Debian I can get, so I can have Guix manage as much as possible. <koz_>Jookia: So I still need X on the Debian side? <Jookia>GuixSD doesn't integrate with Debian's systemd, so probably <Jookia>lfam: Reading that github post again, it seems they think packaging is about putting files in the right places, not testing to make sure it works in the distro <lfam>Jookia: I'm giving them the benefit of the doubt. All my interactions with them so far have been very positive. And the fact that they actually reached out to us speaks volumes <koz_>Jookia: Alrighty, I'll do that. <koz_>Am I gonna have to do juggling between systemd and shepherd? <Jookia>koz_: If you want- I don't think Guix is more than a package manager, GuixSD would have all the shepherd configs <lfam>Guix (not GuixSD) doesn't use Shepherd out of the box. You can use it if you want. <lfam>It could be a fun experiment to not use `systemctl --user` and instead use the shepherd. <Jookia>lfam: It'd probably best to explain that packaging also includes testing to make sure the software works in its new home- one thing --help wouldn't test is where it gets is data from, in this case it might assume /usr/share, not /gnu/store .... <lfam>Yeah, that's what I was thinking about when I mentioned portability bugs (might not have been in that draft) <Jookia>"Want to back this issue? Post a bounty on it! We accept bounties via Bountysource." is this an ad <lfam>It *does* have a "critical mass" and is useful in that sense.\\ <Jookia>lfam: Either way, be super nice and enthusiastic about their project, that always helps <lfam>Jookia: Believe me, I have been :) It's a really nice tool <Jookia>Does that bleed in to your message? <lfam>I wouldn't be replying (or have been asked to reply) if I hadn't demonstrated my support already <koz_>I'm guessing that GuixSD will have UEFI stuff before it hits 1.0? <lfam>Yes, I altered the introduction to say that running tests widely helps improve upstream quality <Jookia>koz_: Hmm, depends if there's someone with an UEFI machine that wants to help work on it <koz_>lfam: No thanks. I hate UEFI enough as a user. <Jookia>Heh, it might be a better decision to get UEFI in a VM and work on it that way <lfam>I guess I'm in for a world of hurt the next time I want a new machine <lfam>Jookia: That is an option <Jookia>I say this typing from an ARM board and debugging my vaporware Guix patch on a Libreboot machine <Jookia>I've never owned a computer with UEFI <lfam>I haven't started thinking of it as vaporware yet :) Some patches have been months in the making <Jookia>Oh cool. It's mainly due to my bad Guile skills- a lot of the code I write seems to not work in certain configs <koz_>lfam: Yeah - take it from me, UEFI-only machines make me vomit. <lfam>I really wish the best options were not old or underdeveloped hardware. Holding out hope for new architectures or implementations. <koz_>Luckily for me, I'm soon to get a nice Libreboot machine. <koz_>(on which I will put GuixSD for sure) <paron_remote>davexunit: what's the name of the virtualenv-like system for ruby? <paron_remote>gems are the package, so the local hacking environment is...? <koz_>Also, what languages does Guix support? I know that Ruby, Python, R and C are all OK. <koz_>Haskell too, apparently? <lfam>We actually support any language, but for some languages we have a nice abstraction over their standard build system <koz_>lfam: That's what I meant. <lfam>There is a Go build system part-way there <koz_>I heard about that. Not so for JS, I also heard. <koz_>Because apparently dependencies are maddening in that language. <koz_>paron_remote: Yup, that too. <lfam>JS is a PITA since the ecosystem apparently doesn't care what version of what dependency they use <koz_>lfam: So basically, this is gonna be a helluva time. <iyzsong>running 'guix size emacs', it start downloading emacs.. is this deriserd? <koz_>paron_remote: Hihi! I'm a big GNU lover. <lfam>paron_remote is interesting in JS packaging I bet <lfam>izysong: There must be no substitute available. <lfam>I think `guix size` asks Hydra to measure the size of the substitutes <paron_remote>I'm afraid to stare into the abyss that would be working on that problem though :) <lfam>iyzsong: Oh no! Have I been reading it incorrectly all this time?! <koz_>I'm attending Auckland University of Technology, *clearly*. <lfam>You should apply for a job in their IT department. I think they need the help ;) <koz_>lfam: They need a lot more help than this. <koz_>Trust me, I've had to deal with them. <koz_>They still can't get me proper *email credentials*. <lfam>"Don't worry, we'll email you your password" ;) <lfam>"Just log in to retrieve it" <koz_>Lol, wouldn't surprise me. <koz_>But yeah, currently defenestrating this machine they gave me. <koz_>*Luckily*, it doesn't need any blobs. <koz_>(Haswell CPU, thankfully) <lfam>Can somebody recommend a large package I could build to test my Perl graft? <lfam>paron_remote: Trying to update pytest opened a huge can of worms <lfam>I decided to `git branch -D` and come back soon <lfam>pytest-runner stopped building. So I tried updating its whole graph. Then, python-mock has had a ton of changes, and a circular dependency with pbr, which it now depends on (that must be why mock is not updated) <lfam>I saw we have a pbr bootstrap package, but it's too much for now <mark_weaver>paron_remote: as it turns out, the openssl breakage is not specific to Guix <lfam>Yeah, I figured it was due to ABI change <lfam>The last security update had multiple releases due to broken symlinks in the tarball, and in the end they settled on a tarball that still had broken links <Jookia>guix is one of the distros that would be immune to that bug <Jookia>had we not used imperative grafts <lfam>But never changed the release tag, so there are multiple tarballs of the same version with different hashes that are all supposed to be authentic <mark_weaver>although grafts are not quite imperative. you can still roll back <Jookia>This is true, and even better :) Roll back to have a working system rather than panic <lfam>I'm not sure how they could have removed an entire protocol without some breakage though <mark_weaver>well, they are and they aren't, depending on how you look at it, I suppose <Jookia>All good tools have a ying yang vibe <Jookia>They changed the ABI in a SECURITY update? Not a major version bump? <mark_weaver>they are imperative in the same sense that almost all of our builds are imperative: an imperative process is used to create the build products <Jookia>If there's an ABI change, shouldn't they bump it to 1.1.0? Or at least 1.0.3? <Jookia>Or was this a mistaken ABI change <lfam>I wonder how they could have handled this better? Given the nature of the change? <mark_weaver>I wonder if this could be fixed by adding enable-ssl2 to the ./config flags <lfam>mark_weaver: Yes I believe it could, but as you said earlier, it's probably not the right thing to do <mark_weaver>it turns out that even if you add that, ssl2 is still disabled by default, according to the NEWS <lfam>Really?! How can you reenable it? <Jookia>lfam: Deprecate it and warn people that it's going to be removed? <lfam>Jookia: It's been deprecated for many years <Jookia>They deprecate things without plans to actually remove it? <mark_weaver>lfam: the relevant commit is 9dfd2be8a1761fffd152a92d8f1b356ad667eea7 in the upstream openssl repo <lfam>Jookia: This new attack seems to represent a qualitative change in the weakness of the protocol <mark_weaver>the commit log says: Even if "enable-ssl2" is used, users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will need to explicitly call either of: SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); or SSL_clear_options(ssl, SSL_OP_NO_SSLv2); <lfam>So, all users of the library would need to be patched? <Jookia>lfam: Ideally OpenSSL people would say 'SSLv2 is deprecated, we're removing it in a month' and make sure packagers hear it <mark_weaver>it's a custom configure script, and "enable-ssl2" (with no "--") is passed to ./config <lfam>It's been deprecated since 2011 <Jookia>Well, 'we're removing it in 5 years' <Jookia>'mark your calender, SSLv2 is removed in 2016' <mark_weaver>lfam: I think it's *good* that even if "enable-ssl2" is passed to ./config, it will be disabled by default at the run-time-option level <mark_weaver>that gives me more confidence that enabling would not be as likely to "undo" this mitigation <mark_weaver> "enable-ssl2" is used, users who want to negotiate SSLv2 via the <mark_weaver> version-flexible SSLv23_method() will need to explicitly call either <Jookia>Well, looks like we have some patching to do. Time to grep ALL OF OPENSSL DEPENDENTS <lfam>It's so broken. I'd rather take a couple days of this than re-enable it <Jookia>mark_weaver: Well, what else is there to do if the behaviour is going to be removed? <lfam>Jookia: We just rebuild packages that use openssl against the new version <mark_weaver>it's not clear that we need to remove the SSLv2 code, as long as it's disabled by default <Jookia>Oh, I thought the issue was that SSLv2 was removed <mark_weaver>I'm sorry, I don't have time to explain it further right now <lfam>Okay. Is the ABI issue really a long-term thing? I rebuilt both pythons against the new openssl and they seem to work fine <Jookia>Seems like it's just ABI and not API <mark_weaver>lfam: yeah, I think it will be fine on the security-updates branch. I built offlineimap from that branch, and it worked. <mark_weaver>(the grafted offlineimap failed for some of us, including me) <lfam>I imported the ssl module from the Python REPL <lfam>I attempted a graft of Perl and it failed. I sent mail to the list <Jookia>Today is the day I submit the patch after a few more tests since i finally figured out why my code was broken <Jookia>Unless it takes longer than 5 hours and I need to sleep :P <mark_weaver>adding enable-ssl2 fixed the graft for me with offlineimap <Jookia>If it unbreaks the ABI that might be a good idea <Jookia>It can't be worse than the existing graft? :P <lfam>I'd hate for applications that use openssl to update their code and keep using the interface. I guess they tried to make it safer by removed the weak ciphers. How about a timeline for disabling it later on? <Jookia>lfam: I have a feeling other distros might figure this out <Jookia>Since I imagine this will break a lot of proprietary applications <Jookia>Though I can see people using this as an argument for bundling <ecraven>so, say I have a vm-ware instance somewhere, and want to put guixSD on it. what is my best option? boot it from a virtual usb thumb drive, copy my configuration, install that? <Jookia>Sounds like a good idea, though you could also (I think) use the existing image and reconfigure over it. You could also use QEMU instead of vmware ;) <ecraven>Jookia: this is a commercial server run by the uni, unfortunately I cannot influence their technology decisions at this level <ecraven>but maybe I can convert them from puppet to guix :p <ecraven>puppet is ok, but it is a real hassle that it never removes anything, so old config files stay around, changing everything <ecraven>how do guix users deal with applications polluting ~ with directories and files? <Jookia>I don't think they do yet. My 'solution' that I may try some day is to build a /home/jookia from a bunch of files and reset it every boot <ecraven>I've got most things in a local .git, but I still have accumulated so much useless cruft :-/ <ecraven>Jookia: hehe, at least with the unwanted state <ecraven>using guix system disk-image, I could generate an image that has my own system default configurations, right? <ecraven>or is there a simpler way to just add a new my-config.scm file besides bare-bones.scm and desktop.scm? <Jookia>ecraven: You could do that, yeah <ecraven>hm.. how would I specify a configuration for httpd to use in my config file? <ecraven>coming from NixOS, there's a lot of parameters, but web.scm doesn't seem to have anything for httpd <ecraven>Jookia: how is this usually handled in guix? <Jookia>You build your own Guix that supports it then use that <Jookia>For a specific example, check out gnu/services/xorg.scm <ecraven>Jookia: why not add parameters to the httpd that comes with guix? <ecraven>not in web.scm, would it be somewhere else? <Jookia>There's nginx configuration in web.scm <Jookia>It's possible nobody's added httpd support <Jookia>Perhaps you could change that ;) <roelj>Is there a way to group multiple packages so they can be installed in a single guix package -i <group-name> (or an equivalent for groups..)? <ecraven>Jookia: hm.. I can't see any configuration for nginx in web.scm, where is that? <ecraven>it just seems to have build instructions <ecraven>so I'll need a service, I'll look into that. thanks! <Jookia>ecraven: If you make one, make sure to share it with us all. :) <ecraven>I just don't know enough about guix to be comfortable with adding things yet, not sure how things are done normally <Jookia>roelj: Hmm, I'm not sure about with a -i, but with config.scm there are some variables <ecraven>but I'll investigate the other services :)( <Jookia>ecraven: We'll certainly help you out, it's not that hard. Just clone Guix from git and use that <roelj>Jookia: Ok. I'll look into there. Thanks :) <ecraven>basically, I'd love to configure all my vhosts and apache stuff in config.scm for guixSD :) <Jookia>roelj: Ah-ha! The 'xfce' package does exactly this- it just propagates some inputs <Jookia>roelj: Check gnu/packages/xfce.scm at the bottom <roelj>I also see 'gnome' doing this :) <Jookia>ecraven: That sounds awesome. :) Are you a web developer? <roelj>Jookia: Yes, thanks :) 'gnome' and 'xfce' look similar <roelj>Jookia: Do you know why they mkdir something? <ecraven>Jookia: yea/no :) I do a lot of everything, including system administration, development, support, .. <ecraven>so I'm very interested in automating things :) <Jookia>roelj: Xfce is making an executable and they're putting it in $out/bin. So they have to make the bin <Jookia>ecraven: nice! What made you choose Guix over another solution? <ecraven>Jookia: I've used nixos, but would prefer Guile over nixlang any day :) <roelj>I have a package that provides over 20 programs in a bin/ directory. What's the best way to copy them to the package output? <roelj>(The build process has no install target) <Jookia>roelj: Add a new phase and copy the files :P <roelj>Jookia: :P Well yeah, obviously. Any loop-example? <Jookia>roelj: I don't have one off the top of my head but I can search if you want <Jookia>roelj: Found one! 'guix edit bedtools' should show you <roelj>Jookia: Damn you're quick :) Thanks <Jookia>The advantage of having git grep and Guix checked out :P <ecraven>is hydra slow? guix keeps updating all substitutes, and normally my internet connection is fast enough :-/ <Jookia>Yeah, it's underpowered though there are mirrors now <Jookia>civodul: Grafts work well enough to replicate a distro-breaking OpenSSL bug :) <ecraven>hm.. I'd like to install just the rxvt-unicode terminfo, so that ssh'ing into the server works, but this pulls in all of Xorg :-/ <ecraven>so I'd have to create a new derivation rxvt-unicode-terminfo? <Jookia>Hmm, I'd suppose so. What's so interesting about it? <ecraven>it's my terminal, right now ssh'ing into the guix server makes backspace and delete break <ecraven>so I'd like to fix this :) which I normally do by installing the terminfo into ~ <Jookia>Is this a problem with all distros? <Jookia>Is this a problem with your setup on all distros? <ecraven>normally just some colours don't work <ecraven>I've never seen backspace/delete break <Jookia>Hmm, I wonder what's up with that in GuixSD <ecraven>installing rxvt-unicode at some point said to use: export TERMINFO_DIRS="/home/nex/.guix-profile/share/terminfo" <ecraven>after adding this to my .bash_profile and relogging, things seem to work <Jookia>I'm not sure, but it's evidently not in the global profile by default <ecraven>I just too bare-bones.scm and changed the host name <Jookia>I don't see much in Guix about terminfo <ecraven>can I tell guix to not update the list of substitutes every time I run guix package -i, but only every few hours or so? <Jookia>Hmm, I'm not sure what's up with that or if it updates the list of ALL substitutes <ecraven>which takes a few minutes each time, *and* produces unnecessary load on hydra <Jookia>Hydra's already overloaded I think, not sure if it's getting more substitutes for its list or redownloading existing ones <Jookia>My *guess* is that it'd take a few hours to evaluate all subsitutes so it only finds substitutes when new ones are evaluated <civodul>Jookia: you were referring to the Python SSLv2 thing? <Jookia>civodul: Kinda- the SSLv2 ABI change broke Gentoo <Jookia>And also Guix! :) So we have the ability to break things now <ecraven>civodul: how do I globally change the substitute url for my guixsd instance? <Jookia>ecraven: guix-configuration has the use-substitutes? and substitute-urls list of mirrors <civodul>ecraven: on GuixSD, do as Jookia writes; otherwise just pass --substitute-urls to guix-daemon <Jookia>civodul: My patches are almost fully tested so I'll post them with a cover letter explaining some (possible) bugs and talk about what needs to be improved to start discussion <ecraven>ah, I thought lsh might somehow include scp too :) thanks! <ecraven>does that interoperate with openssh lcp? <Jookia>I wonder why it's used over openssh <ecraven>hm.. herd status: error: connect: /home/nex/.config/shepherd/run/socket: No such file or directory <ecraven>shouldn't herd always be running automatically? <civodul>ecraven: it's trying to connect to your per-user instance, which doesn't exist <civodul>you probably want to do "sudo herd status" instead <Jookia>I think my patches broke some error handling :| Yay more testing <ecraven>civodul: how do I change guix-configuration? it seems to be a part of %base-services, if I add it to services, I get "service 'guix-daemon' provided more than once" <Jookia>ecraven: Take a look at %base-services and make your own set of services <ecraven>Jookia: I'd prefer to just adjust this one parameter, not completely roll my own :-/ <Jookia>Aww yeah my patch introduces a regression fantastic <roelj>Can I refer to the (only) tarball that contains the source of the package I'm describing? <roelj>Oh, simply "source" seems to work :) <civodul>roelj: "guix build -S the-package" should do <roelj>civodul: I meant from Scheme. But thanks :) <Jookia>civodul: I think I'm on my (last) bug. But I say that every time. It's probably the last time I'm going to be so lazy with testing and understanding code structure and what exactly happens, side effects, etc. Dynamic languages are hard. <civodul>ACTION investigates the test failures <phant0mas>if a package has multiple licences (different files - different licences) which one should put in the license field? <roelj>You can use a list for that (list license:gpl2+ license:bsd-3) <phant0mas>hey davexunit give me some time and I will tell you what I have in mind for avr-gcc <phant0mas>davexunit: but in short we have to do something like the cross-toolchain in cross-base <phant0mas>like ricardo's arm-crosstoolchain, which from what I am aware of he still hasn't sent to the ml <rekado>phant0mas: yes, he still hasn't :-/ <rekado>phant0mas: still need to fix some issues with it, but I don't really know how. <rekado>I might post it to the ml marking it as work-in-progress. <rekado>it doesn't use the glibc but the newlib and so some of the assumptions of our cross-gcc procedures are invalid <rekado>it still produces binaries that don't quite work right. <phant0mas>send it to the ml so I can test it as well and we will work out the issues <civodul>arf, 'git push' again stalled while "Sending notification emails to: guix-commits@gnu.org" <davexunit>will be nice to be able to program AVRs from the comfort of GuixSD sometime. :) <roelj>The Git commit says MIT, but I don't see any reference to it otherwise. <roelj>davexunit: Can I use license:expat for this one then? <davexunit>provided that license really is accurate for the codebase. <civodul>ACTION prepares blog article about grafts <mark_weaver>civodul: I notice that "guix build -S openssl" gives me the source for openssl-1.0.2f. shouldn't it give me the replacement source? <mark_weaver>btw, thanks very much for getting grafts working, this is really wonderful! <rain1>I don't have guix mode in emacs it seems? but i am on guixsd <mark_weaver>rain1: did you follow section 4.1 (Initial Setup) in the Guix manual? <rain1>I misunderstood it, I thought it says because im on guixsd i don't hav eto do anything <rain1>I could suggest a change to the documentation " So if that is what you’re using, you can happily skip this section and read about the fun stuff. " <rain1>instead of skip this section it could say: Install geiser magit and guix <paron_remote>yay, I'm "glad" that our grafts reproduced the same bug everyone else was having :) <rekado>how odd: "guix build -K" no longer seems to keep the output directory for me. <civodul>mark_weaver: indeed, the "guix build -S" thing is a bug, lemme see <mark_weaver>paron_remote: openssh was updated. that's independent of the openssl ABI fix <paron_remote>ACTION drops --substitute-urls and sees what happens then <rain1>guix-ui-read-profile: Symbol's value as variable is void: guix-current-profile <rain1>i didn't have any of this when i was using guix emasc mode in my previous install of guixsd <mark_weaver>actually, I'm not even sure it refers to multiple CVEs. maybe it only refers to CVE-2016-0800 <mark_weaver>however, CVE-2016-0703 and CVE-2016-0704 exacerbate DROWN <civodul>and thank you & paron_remote & davexunit for the quick review :-) <civodul>but beware of the collusion detection thing ;-) <paron_remote>title: Guix gets grafts: timely delivery of security updates <fhmgufs>Guix doesn't want to do anything. 100 % file system inodes in use. :( <fhmgufs>Are the .drv files in the store needed? <rain1>maybe guix gc will remove something? <fhmgufs>I have 732958 inodes in use and 2 available. With a normal ext4 file system I thought I have much more. <fhmgufs>Again: Could I remove all the .drv files? <paron_remote>I am getting a lot of harsh criticism from asheesh in #userops for us not checking signatures on a "guix pull" <mark_weaver>I agree, and that's part of the reason that i've *never* run "guix pull" and spend a lot of time recommending that people run guix from git instead <mark_weaver>however, civodul made a valid point that fetching git is not secure either. <mark_weaver>the closest thing to a "right thing" that I know of is for us to start signing our git commits. <paron_remote>mark_weaver: yeah, I just submitted a bug about it with some ideas <mark_weaver>but that's not a silver bullet either. it would effectively require users to end up trusting signed commits for anyone who has commit privileges <mark_weaver>and that's only as strong as the weakest committer key <davexunit>paron_remote: just tell asheesh we're well aware that it sucks and want to improve. <mark_weaver>paron_remote: and maybe also mention that "guix pull" is not the only way to do things, and some of us don't use it at all, ever. <paron_remote>mark_weaver: true (though do you have to have ssh access to get a secure pull from savannah?) <paron_remote>and right now even if we get that probably it's "the CAs git trusts" <paron_remote>some CAs even sell MITM'ability to large companies for "internal use" <mark_weaver>the sad truth is that the NSA can probably get almost any signing key they want from our developer community <mark_weaver>even without authentication, using git has a nice feature <mark_weaver>git will call attention if the pull isn't just new commits added to the old <mark_weaver>and that combined with the fact that commits are cryptographically secure hashes of the entire history that we pass around and refer to, makes it rather impractical to give people bad stuff without someone eventually noticing <mark_weaver>(yeah, it's too bad that git is tied to sha1, with apparently no migration plan to other hashes) <paron_remote>(it's very strange to me that git used sha1 at the time it was launched, considering the next generation of hash functions existed at that time iirc) <paron_remote>mark_weaver: I think we need to work out a good system, and document it <paron_remote>we could *start* with every new commit from this point forward must be gpg signed <mark_weaver>one thing that makes me nervous is that I have no confidence that I can keep my private signing key secret. <mark_weaver>well, the thing is, I could be held legally accountable for something signed by my key. <wingo>mark_weaver: you could always claim the nsa signed it :) <mark_weaver>my current GPG private key has never left my Lemote Yeeloong laptop <paron_remote>mark_weaver: you're almost certainly doing better than the rest of us ;) <mark_weaver>which never runs a modern web browser, and has not run any binary not built from source on it for the last 5 years <fhmgufs>rekado: Yes. The problem is looming since a couple of days. But can I delete the .drv files? <mark_weaver>but the tradeoff is that it's not where I do most of my work lately, so it's not convenient for me to sign things with that key <rekado>fhmgufs: I don't think you can delete them (but I'm really tired now, so don't trust me) <mark_weaver>far too inconvenient for me to sign every git commit with it <rekado>mark_weaver: I've got the same problem. <mark_weaver>so I'd need to make another less secure key for purposes of signing git commits <mark_weaver>rekado: ah, interesting! it's good to have company :) <rekado>I don't want to put my private key on my workstation. I'd have to generate another key, but then it wouldn't come with the trust associated with my regular key. <mark_weaver>the fundamental problem is that when I start to sign things, then it becomes easier to be held accountable and be blamed if my machine or key gets compromised, and I have very little confidence in the security of my development system, however hard I try (and I do try) <mark_weaver>computer security is a very depressing topic for me. I'm low on hope. <paron_remote>the grafts stuff is a huge improvement for security in guix <paron_remote>and I think more stuff will probably happen with running things in isolation <paron_remote>by running things in more sandboxed ways, many security issues mitigated before they can spread out easily <paron_remote>and I think Guix is likely to go more in this direction too; davexunit's container work is a step in the right direction <efraim>ACTION realizes his gpg key expires tomorrow <wingo>just as i start to understand cgroups, i realize they just landed cgroupv2 in linux 4.5. <mark_weaver>bah, I almost forgot that icecat (and firefox) bundles graphite :-( <mark_weaver>civodul: grafting a graphite2 update into icecat, I see this: <mark_weaver>grafting '/gnu/store/0v6cr53b0924agxaddx427pjzjxi01vq-gtk+-2.24.28' -> '/gnu/store/v0rw34x8wg78kwa0p436s563rz0cqzg4-gtk+-2.24.28'... <mark_weaver>grafting '/gnu/store/0v6cr53b0924agxaddx427pjzjxi01vq-gtk+-2.24.28' -> '/gnu/store/lz0rk46g5kaqbdlv2g8qk6c0zc9li7gh-gtk+-2.24.28'... <mark_weaver>(same original store item grafted into two outputs with different hashes) <mark_weaver>and the two outputs are different, according to "guix hash -r /gnu/store/...-gtk+-2.24.28" <mark_weaver>bah, the rate of these security updates are overwhelming :-( <paron_remote>. o O (was it always this bad, or did I never notice before because I wasn't on a functional distribution?) <mark_weaver>and the new nss release fails to build. *more grump* <wingo>ACTION grumbles in solidarity <davexunit>I think iyzsong and wingo did a good chunk of that work. :) <mark_weaver>nss-3.22.2 is tagged in their repo and the tarball exists, but it's not actually announced on their web page. 3.21.1 has the same fix I want, so I'll try that instead. <wingo>ACTION still struggling with elogind and sessions but that's going to be fixed soon <davexunit>you got the elogind ball rolling. that was a biggie. <suitsmeveryfine>I wouldn't mind some more features, e.g. the tweak tool, but please keep it light weight <davexunit>I guess it has decent hardware accelerated graphics <davexunit>suitsmeveryfine: I tried packaging the tweak tool. <mark_weaver>yeah, I think our gnome-shell performs better on this old X60 than when I tried it in Debian long ago <mark_weaver>maybe just because we've got more updated software, i guess <davexunit>I need to make a mailing list post about it or something. it's really weird and has me stumped. <davexunit>mark_weaver: yes. there was already a wrapper. <davexunit>the biggest blocker for me is that suspend is totally borked when I run gnome-shell <davexunit>and there's another weird issue where my applications menu has less stuff than XFCE. <suitsmeveryfine>yeah, that's funny. By the way, I don't need "Web". How can I remove it considering it's part of the gnome meta package? <mark_weaver>davexunit: yeah, I started hitting that suspend loop problem as well. strangely, it didn't happen for a while, and now it does. <mark_weaver>or, if you're running guix from git, you can modify your copy of the gnome metapackage to exclude it <suitsmeveryfine>mark_weaver: yes, guess I should do that so that I could contribute more easily. You explained to me once how to do it but I forgot. <mark_weaver>davexunit: it doesn't list icecat because icecat doesn't install a .desktop file in share/applications <mark_weaver>suitsmeveryfine: read the "Contributing" section of our manual. just one thing that's not mentioned there: make sure to pass --localstatedir=/var to configure <lfam>Is that what they're for? <suitsmeveryfine>I *could* use it with ratpoison too, but this is more convenient. I don't have working touchpad you see. <davexunit>we've had XFCE for awhile which is another option. <paron_remote>guess I need to boot into debian to deal with these forms I was emailed... <mark_weaver>the amount of time it takes just to unpack the icecat source, patch it, and repack it, is quite substantial <lfam>I think an upstream fix is forthcoming. At least, they are working on it <lfam>Hm, do we need to update our package? <mark_weaver>vigra has never built on i686, so I'm out of luck on the X60 also <paron_remote>I have important forms I need to sign today, so I guesss I'll just reboot into Debian <paron_remote>good thing I've got both Debian and GuixSD running on this machine while we're moving towards being a grown up distro :) <mark_weaver>our libreoffice package also needs to be updated for a security fix, but that update was postponed since we couldn't test the build due to lack of working vigra <CompanionCube>ACTION should read more about GuixSD and installing it into a spare partition <CompanionCube>also, would GuixSD be the first distribution to use GNOME3 without systemd? <lfam>vigra is a computer vision library? Interesting that libreoffice requires that. <rekado>paron_remote: for signing forms I use xournal. <mark_weaver>I meant to push my not-yet-fully-tested updates for nss and icecat to a wip-* branch, but made a mistake and they went to master instead. hopefully they will build.. <mark_weaver>iirc, on mips, the build phase takes less than 30 minutes, but the tests take on the order of 30-40 hours <mark_weaver>(I guess that mostly shows that the crypto code is not well optimized for mips) <lfam>mark_weaver: For grafted updates, do you plan rebuild without the graft on e.g. security-updates and then remove the graft? Like, we're trying not to "carry" the grafts for a long time, right? <lfam>Just wondering how you plan to use this new tool <mark_weaver>lfam: good question. partly it has to do with how often these rebuilds are called for and the limitations of our build farm. <lfam>Yeah, we can't be rebuilding the world for each grafted update if this is the pace <mark_weaver>I'm actually toying with the idea of postponing the full rebuilds of these recent updates until the next core-updates cycle <mark_weaver>given the core-updates cycles has waited a lot longer than usual on account of this recent barrage of core security updates <mark_weaver>the thing is, the state of armhf and mips binary substitutes has been quite bad for several weeks now <mark_weaver>our build slaves on those architectures simply haven't been able to keep up with all these massive rebuilds <lfam>I think we should use grafts to let us do updates that we actually *want* to do <lfam>Hopefully there isn't too much confusion regarding the fact that grafted updates must keep the name of the ungrafted package <civodul>paron_remote: thanks for promoting the link BTW, even though there weren't too many upvotes ;-) <civodul>paron_remote, mark_weaver: re Git signing, the only serious use of it that i've seen is Qubes <civodul>so yes, we should do something about it, but i think there are very few people doing the right thing :-) <paron_remote>rekado: doesn't help when they send you .doc and .xls files :) <paron_remote>(it's for applying for an apartment, I can't very easily make the "free your documents argument" here...) <paron_remote>or I need to try writing something similar, maybe using guile-ssh? <civodul>mark_weaver: WDYT about the #:allowed-references patch for OpenSSL by lfam? where should it go? :-) <mark_weaver>I don't know, I'm open to suggestions, but substitutes for armhf and mips are so far behind, and have been for so long, that I'm inclined to let current master build out some more before unnecessary rebuilds <wingo>where are the bordeaux servers :) <mark_weaver>although, to be fair, even if libreboot were all set today, there would still be a lot of work to do to set it up <lfam>civodul: So it's normal that I had to import the gcc module in order to set up the #:allowed-references? I wasn't sure if that was right or not. <suitsmeveryfine>I'll try to reconfigure the system from a git checkout. Is it enough that I'm inside the <suitsmeveryfine>also, can it reach an OS definition that I have saved outside of that directory? <civodul>lfam: yes, but it's not great; that's another reason why #:disallowed-references would be better <civodul>wingo: apparently the libreboot-based servers are not fully baked yet <lfam>suitsmeveryfine: You don't need `guix environment guix` I think. Instead, I think you want `./pre-inst-env guix system reconfigure foo` where foo is the path to your definiton <lfam>That will reconfigure against the git repo <lfam>`guix environment foo` is used to provide a build environment for foo <mark_weaver>suitsmeveryfine: you need "guix environment guix" while building guix, and you need ./pre-inst-env when running that copy of guix <lfam>suitsmeveryfine: Sorry for the confusion, I missed that. <suitsmeveryfine>I'm not sure I understand: I need to be inside the environment to run system reconfigure? <mark_weaver>suitsmeveryfine: it shouldn't be needed, but it won't hurt either <lfam>./pre-inst-env will set up an environment, just for that command line, that will ensure you use the Guix you've built in the git checkout <mark_weaver>or just run ./pre-inst-env guix system reconfigure as root from that directory <suitsmeveryfine>thank you. Does this mean that everything will be built from source? <mark_weaver>when you ./pre-inst-env, it doesn't matter whether you've ever run "guix pull" or not <suitsmeveryfine>OK. I just get a lot of messages that the source files are newser than the compiled packages. <mark_weaver>and substitutes can be used when hydra has built the same thing you try to build. it doesn't matter whether you run guix from git or not <suitsmeveryfine>That the synaptics driver should simply be listed before the generic touchpad driver <suitsmeveryfine>mark_weaver: after this reconfiguration, will the new version show up in GRUB just like the others? <wingo>i think probably we should remove synaptics and evdev <wingo>and then just use the libinput driver <wingo>i think that's what fedora does but i could be wrong <wingo>afaiu libinput's xorg conf snippets are lower priority relative to other xorg input drivers <wingo>i guess to keep legacy systems working like they were <suitsmeveryfine>My problem is that there is a conflict between the synaptics and evdev driver <wingo>$ ls /gnu/store/vcrh9blgggbaj4xlz8vb3y3dkxrfl4yk-xorg.conf.d <wingo>10-evdev.conf 50-synaptics.conf 90-libinput.conf <wingo>i think this means that evdev will register itself first <wingo>suitsmeveryfine: this is all assuming you are running git from within a week ago or so <wingo>if you are on older git this is a different story <suitsmeveryfine>wingo: I modified gnu/services/xorg.scm by moving synaptics befor evdev <wingo>suitsmeveryfine: you could try to just remove mentions of evdev from gnu/services/xorg.scm. i don't think moving lines around in that file will help fwiw <wingo>remove evdev from %default-xorg-modules, and the corresponding ModulePath line <wingo>if that works we can consider making that change globally but we'll need some more testing <wingo>ACTION would like two-finger scrolling :P <wingo>suitsmeveryfine: i have heard of some people that use it somehow :) <davexunit>and left/right/middle buttons you can hit with your thumbs <wingo>but the mechanics changed recently with xorg 1.18 <wingo>so maybe they are adrift too <wingo>ACTION wonders who will do wayland on guixsd :) <suitsmeveryfine>when I try to build from source I see mostly certificates being tested. Is this normal? <mark_weaver>suitsmeveryfine: I just updated the 'nss' package, and presumably you are building it and running its (quite lengthy) test suite <mark_weaver>if you want to avoid that for now, you could roll back a few commits <suitsmeveryfine>I see. Well, I've already run it since that past hour. Maybe it will finish soon. Is it big? <mark_weaver>d47ad0890c0cfbc7114a28ccd768f6cb0933cb84 might be a good commit to build for now <mark_weaver>well, I don't have time to teach you git right now, and it's probably best for you to get those updates anyway, so maybe you should just restart the build :) <Jookia>suitsmeveryfine: What change do you want to apply for your local machine? Are you just wanting to load an old commit? <mark_weaver>Jookia: I suggested that he roll back a few commits to avoid building 'nss' and 'icecat' locally <mark_weaver>but he already has uncommitted changes to test in his working dir <suitsmeveryfine>I can checkout the older commit and apply the change there of course <Jookia>suitsmeveryfine: Run 'git add -u', 'git stash', 'git checkout d47ad0890' then 'git stash pop' <mark_weaver>civodul: grafts seem to have a strange effect on hydra. evaluator.log contains a build log of graphite2, which I just added a graft for. <civodul>mark_weaver: that's because currently grafts can cause things to be built early <civodul>though i would expect hydra to already have a copy of the origin graphite2 <mark_weaver>civodul: it already had a copy of the original graphite2, but the build log for the replacement is in evaluator.log <mark_weaver>oh, I wouldn't be surprised if the original graphite build wasn't done yet for mips <civodul>oh, i'll fix gnu-system.scm to not build grafts on Hydra 