IRC channel logs


back to list of logs

<paron_remote>bad news
<paron_remote>virtualenv does not work :(
<paron_remote>with the ssl grafting
<paron_remote>I suspect python needs to be rebuilt
<paron_remote>steps to reproduce:
<paron_remote>$ guix environment --ad-hoc python-virtualenv
<paron_remote>$ virtualenv /tmp/try-virtualenv
<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/", line 66, in <module>
<paron_remote>ImportError: cannot import name 'HTTPSHandler'
<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
<mark_weaver>paron_remote: bah, well, this has been an education
<paron_remote>I submitted a bug, but I sent it to
<paron_remote> :)
<paron_remote>sent the corrected version
<paron_remote>I'm actually amazed at how much *does* work!
<paron_remote>my suspicion is that if it weren't for the fact that openssl *removed* a huge chunk of their codebase
<paron_remote>things would work
<mark_weaver>ACTION looks at what Fedora did
<paron_remote>and in many other cases, it would be less of an ABI compatibility issue
<mark_weaver>it's not clear to me how fedora avoided this
<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> ;) look what i talked parabola in to
<lfam>Nice :)
<paron_remote>Jookia: !!!!
<paron_remote>Jookia: amazing!
<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>ok, definitely update it :)
<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
<paron_remote>should be a-ok
<Jookia>paron_remote brought this up on the mailing list, but are grafts composable? Can we graft grafts to make grafts?
<paron_remote>Jookia: I don't know
<paron_remote>you weren't asking me, you were referencing me :)
<Jookia>It's okay, I don't know either
<Jookia>It'd be useful to compose grafts for things where applications are statically linked or we need to do something more serious
<paron_remote>I'm not sure how hard it is to reason about
<paron_remote>if a thing uses two grafted packages
<paron_remote>will it be smart about it?
<paron_remote>we're all new to graft theory ;)
<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
<paron_remote> ah yeah there we go
<lfam>paron_remote: I can 'import ssl' in python-3 built against the new openssl. Building python-2 now
<paron_remote>lfam: woo!
<lfam>paron_remote: python-2 works too
<paron_remote>lfam: :D
<iyzsong>There is a typo (ilmbase-fix-texts.patch) in
<lfam>izysong: :(
<paron_remote>texlive-texmf grafting sure takes its time
<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>I would be amazed if we did!
<paron_remote>firefox isn't 3.62 GB :)
<paron_remote>what on earth is *in* texlive-texmf that makes it so huge anyway?
<paron_remote>is it like, every tex package possible?
<paron_remote>hi davexunit !
<lfam>"all the major TeX-related programs, macro packages, and fonts that are free software, including support for many languages around the world"
<Jookia>The secret ingredient is TeX
<paron_remote>someone needs to break that thing up :)
<paron_remote>(not it!)
<lfam>I think it's been discussed... you can search guix-devel
<lfam>I've been working pretty closely with this upstream. Interesting discussion to join:
<lfam>That's what spurred me to look at pytest
<davexunit>hey paron_remote
<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
<davexunit>in my haste to prepare a presentation
<mark_weaver>lfam: fyi, I recreated the 'security-updates' branch again with 'openssl' updated to 1.0.2g without grafting
<pizzaiolo>I made this very crude page with the hopes that someone more knowledgeable will be able to improve it as they see fit
<paron_remote>davexunit: got it :)
<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
<Jookia>pizzaiolo: nice!
<lfam>mark_weaver: I don't think this is worth interrupting a 'security-updates' rebuild if it is already going, but something to keep in mind for the next cycle:
<lfam>Well, since *I* added python-hypothesis, it's pretty lame that I don't know why I put flake8 in there :(
<davexunit>paron_remote: weeee
<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
<mark_weaver>yeah, me too
<lfam>Thankfully most security updates don't break ABI so severely
<lfam>This was really a special case
<Jookia>is this 3 hours to do a graft?
<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.
<Jookia>ah ok
<lfam>Building guix from git has to be a small part of those 3 hours, no?
<mark_weaver>I'm not sure to be honest
<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>If it's even a bug
<lfam>I see
<lfam>Can somebody proofread my response to this:
<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?
<Jookia>I generate the expected output
<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?
<Jookia>They shouldn't fail at all
<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.
<Jookia>But you do here :P
<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
<koz_>I'm trying to install GuixSD using the method here: . However, when I boot into the USB, I get a kernel panic and a giant tracedump. I can only intercept it at this point: . Could someone please suggest what I can do to intercept it sooner (or make some sense out of this)?
<lfam>Abusing the bug tracker as a message board
<lfam>That message wan't to you koz_ :)
<koz_>lfam: I know.
<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
<Jookia>lfam: tone looks good to me
<koz_>Alrighty, Parabola/Guix it is.
<lfam>kox_: Building Guix on parabola might give you some tools for debugging, such as `guix system vm`.
<koz_>This internet. Wow.
<lfam>koz_: Did you seem my message about `guix system vm`?
<koz_>lfam: I did, thanks.
<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_>Like, seriously.
<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
<lfam>Yeah, don't do it!
<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
<koz_>Yes and no.
<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.
<Jookia>That'd be hard without GuixSD
<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_>That's the other thing.
<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.
<koz_>Ah, OK.
<koz_>That makes it easier.
<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
<Jookia>Does github have ads now
<lfam>Blech github
<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
<Jookia>Ah I see
<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
<lfam>koz_: Help Wanted :)
<koz_>lfam: No thanks. I hate UEFI enough as a user.
<lfam>Ha, okay
<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
<Jookia>lfam: Libreboot or an ARM board
<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
<Jookia>It's really confusing
<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_>They are not fun.
<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...?
<paron_remote>might be!
<lfam>Okay sending this mail
<koz_>Also, what languages does Guix support? I know that Ruby, Python, R and C are all OK.
<koz_>Haskell too, apparently?
<koz_>Any others I missed?
<koz_>lfam: Oh, ok.
<koz_>Well, and Guile, obv.
<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.
<paron_remote>emacs lisp!
<koz_>Because apparently dependencies are maddening in that language.
<koz_>paron_remote: Yup, that too.
<paron_remote>koz_: indeed they are
<lfam>JS is a PITA since the ecosystem apparently doesn't care what version of what dependency they use
<paron_remote>also, welcome koz_ :)
<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.
<paron_remote>I'm very interested in it being done :)
<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 :)
<iyzsong>lfam: you mistyped my nick ;)
<lfam>iyzsong: Oh no! Have I been reading it incorrectly all this time?!
<Jookia>best internet ever
<koz_>Jookia: Yup.
<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?
<paron_remote>lfam: git? :)
<lfam>paron_remote: Trying to update pytest opened a huge can of worms
<lfam>I decided to `git branch -D` and come back soon
<paron_remote>heh :)
<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
<mark_weaver>bah, what a botch
<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>oh the irony
<Jookia>guix is one of the distros that would be immune to that bug
<Jookia>had we not used imperative grafts
<mark_weaver>indeed, good point!
<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
<lfam>Recipe for disaster
<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
<mark_weaver>but roll back works, anyway :)
<Jookia>All good tools have a ying yang vibe
<mark_weaver>store items are not modified
<lfam>That is the key ^
<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
<mark_weaver>Jookia: the ABI changed between 1.0.2f and 1.0.2g
<Jookia>If there's an ABI change, shouldn't they bump it to 1.1.0? Or at least 1.0.3?
<mark_weaver>by removing some SSLv2 exports
<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?
<mark_weaver>maybe, I need to look into it more careful
<Jookia>lfam: Deprecate it and warn people that it's going to be removed?
<Jookia>Or did they do that
<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
<mark_weaver>lfam: no
<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>which is my main concern
<mark_weaver>Even if
<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
<mark_weaver> of:
<mark_weaver> SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
<mark_weaver> or
<mark_weaver>(bah, sorry)
<Jookia>Well, looks like we have some patching to do. Time to grep ALL OF OPENSSL DEPENDENTS
<mark_weaver>Jookia: why?
<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>and that would address the ABI issue
<mark_weaver>I'm sorry, I don't have time to explain it further right now
<mark_weaver>but I'll work on it
<Jookia>That's cool
<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
<Jookia>Okay, final patch fixed
<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>I didn't try virtualenv
<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>ooh interesting
<mark_weaver>I tempted to push this
<Jookia>If it unbreaks the ABI that might be a good idea
<Jookia>It can't be worse than the existing graft? :P
<mark_weaver>yeah, I think it's fine. I'll push it soon
<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>(Please let this affect Skype)
<Jookia>Though I can see people using this as an argument for bundling
<mark_weaver>I verified that it also fixes all the problems mentioned in
<Jookia> Would this fix lfam's issue?
<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
<Jookia>That'd be cool
<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
<Jookia>Unless I symlink them
<ecraven>I've got most things in a local .git, but I still have accumulated so much useless cruft :-/
<Jookia>Down with the state
<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
<Jookia>Time to add some then? ;)
<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?
<Jookia>Is there a httpd service?
<ecraven>not in web.scm, would it be somewhere else?
<ecraven>shouldn't there be one? :)
<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
<Jookia>ecraven: gnu/services/web.scm
<ecraven>ah, services, not packages
<ecraven>thank you!
<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>of course :)
<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>Jookia: that's what I'm looking at
<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?
<roelj>Jookia: Ok, thanks.
<ecraven>Jookia: I've used nixos, but would prefer Guile over nixlang any day :)
<Jookia>Oh neat
<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
<civodul>Hello Guix!
<Jookia>civodul: o/
<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>control doesn't work either
<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
<Jookia>Sounds like a bug
<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
<ecraven>is terminfo installed by default?
<Jookia>I'm not sure, but it's evidently not in the global profile by default
<Jookia>s/global/system config/
<ecraven>it probably should be :)
<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>it says: substitute: updating list of substitutes from ''... 46.8%
<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>ecraven: please try --substitute-urls=
<civodul>Jookia: you were referring to the Python SSLv2 thing?
<Jookia>civodul: Kinda- the SSLv2 ABI change broke Gentoo
<Jookia>And Fedora
<Jookia>And also Guix! :) So we have the ability to break things now
<ecraven>civodul: thanks
<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>Jookia: glad you like it! ;-)
<civodul>ecraven: on GuixSD, do as Jookia writes; otherwise just pass --substitute-urls to guix-daemon
<ecraven>Jookia: thanks!
<ecraven>how do I get an scp executable?
<civodul>guix package -i openssh :-)
<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!
<civodul>lsh has 'lcp' though
<ecraven>does that interoperate with openssh lcp?
<Jookia>what is lsh
<ecraven>Jookia: guixsd's default sshd
<Jookia>I hadn't heard of it
<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
<civodul>that will connect to PID 1
<ecraven>ah, thanks
<ecraven>sorry for all these questions :)
<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>Oh it seems you can modify it
<Jookia>(modify-services %base-services
<Jookia>It's in the manual
<ecraven>ah, page 100 in the pdf from git :)
<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
<civodul>or did you mean from Scheme?
<roelj>civodul: I meant from Scheme. But thanks :)
<roelj>I've got it now
<civodul>cool :-)
<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.
<Jookia>s/dynamic/not statically typed/
<Jookia>Butr I'm learning it :)
<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>phant0mas: All of them?
<roelj>You can use a list for that (list license:gpl2+ license:bsd-3)
<davexunit>hey phant0mas
<phant0mas>hey davexunit give me some time and I will tell you what I have in mind for avr-gcc
<phant0mas>I am at work right now
<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.
<phant0mas>rekado: what issues? :-)
<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
<rekado>phant0mas: yay, will do :)
<civodul>arf, 'git push' again stalled while "Sending notification emails to:"
<davexunit>phant0mas: sounds good :)
<davexunit>will be nice to be able to program AVRs from the comfort of GuixSD sometime. :)
<roelj>What license is this:
<davexunit>roelj: looks like expat
<roelj>The Git commit says MIT, but I don't see any reference to it otherwise.
<davexunit>it's the Expat license
<roelj>davexunit: Can I use license:expat for this one then?
<roelj>Thanks :)
<davexunit>provided that license really is accurate for the codebase.
<roelj>Of course..
<roelj>That's always the question
<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 :)
<paron_remote>re: abi incompatibility
<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: did my fix work for you?
<paron_remote>mark_weaver: I'm still updating :)
<paron_remote>curiously it recompiled openssl!
<mark_weaver>paron_remote: openssh was updated. that's independent of the openssl ABI fix
<paron_remote>ok then :)
<paron_remote>oh well it's recompiling openssl too
<paron_remote>ACTION drops --substitute-urls and sees what happens then
<rain1>hm :(
<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
<civodul>mark_weaver: looking at it's seems that "DROWN" designates several of the CVEs, but not all of them, no?
<paron_remote>civodul: that's also my understanding...
<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>oh well
<civodul>new news!
<paron_remote>civodul: horray! I'll promote it
<mark_weaver>great stuff :)
<mark_weaver>thank you, civodul!
<civodul>and thank you & paron_remote & davexunit for the quick review :-)
<paron_remote> on HN, upboat from newest page
<civodul>but beware of the collusion detection thing ;-)
<paron_remote>how's this for slashdot:
<paron_remote>title: Guix gets grafts: timely delivery of security updates
<paron_remote><a href="">GNU Guix</a>, the functional package manager (and with GuixSD, distribution) got a nice feature yesterday: <a href="">timely delivery of security updates with grafts</a>. Guix's new grafts feature recursively produces re-linked packages as dependencies without waiting for all to compile when a time-sensitive security upgrade is an issue.
<paron_remote>This came just in time for <a href="">this week's OpenSSL security issues</a>, and has been successfully tested by the community. It worked so well that it was able to reproduce the <a href="">ABI break issue</a> that other <a href="">traditional</a> <a
<paron_remote> href="">distributions</a> experienced also!
<paron_remote>look ok?
<paron_remote>also now on reddit:
<paron_remote>no comments here, so
<paron_remote> upboat here
<paron_remote>mark_weaver: confirmed your commit fixed things for me
<mark_weaver>excellent, thanks for the confirmation!
<paron_remote>mark_weaver: thank *you* for the fix!
<mark_weaver>np :)
<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?
<rain1>and free up space/inodes
<fhmgufs>No, it isn't.
<fhmgufs>I already gc-ed. :(
<fhmgufs>Space is there.
<fhmgufs>But no inodes.
<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"
<paron_remote>it's a pretty valid criticism
<paron_remote>with linked
<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
<paron_remote>mark_weaver: that's still a lot of improvement.
<mark_weaver>I agree
<paron_remote>that's about as strong as debian, etc probably, right?
<davexunit>paron_remote: just tell asheesh we're well aware that it sucks and want to improve.
<mark_weaver>I don't know enough about how they do things
<davexunit>"Rome wasn't built in a day"
<rekado>fhmgufs: did you try a reboot?
<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?)
<mark_weaver>that's true
<paron_remote>ie does savannah have https at least?
<mark_weaver>unfortunately not :-(
<paron_remote>and right now even if we get that probably it's "the CAs git trusts"
<paron_remote>which unfortunately can and are MITM'ed
<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>without much difficulty
<mark_weaver>the exceptions are few and far between
<mark_weaver>this stuff keeps me up at night
<paron_remote>mark_weaver: NSA isn't the only attacker though
<paron_remote>and the more work towards this it is
<paron_remote>the more expensive it becomes to attack
<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
<paron_remote>ACTION collides some sha1 commits :)
<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>all the more reason to gpg sign our stuff
<mark_weaver>well, I agree that we should start doing that
<mark_weaver>so much to do
<paron_remote>mark_weaver: I think we need to work out a good system, and document it
<paron_remote>in the info manual
<paron_remote>we could *start* with every new commit from this point forward must be gpg signed
<paron_remote>and then also put together a list of trusted gpg keys
<paron_remote>and work our way forward slowly.
<wingo>that's really gnarly tho
<mark_weaver>one thing that makes me nervous is that I have no confidence that I can keep my private signing key secret.
<paron_remote>wingo: workflow-wise?
<wingo>workflow-wise yeah
<paron_remote>mark_weaver: well there's only so much you can do.
<paron_remote>wingo: it will probably make rebasing into hell :)
<mark_weaver>well, the thing is, I could be held legally accountable for something signed by my key.
<mark_weaver>makes me very nervous
<wingo>mark_weaver: you could always claim the nsa signed it :)
<wingo>ACTION terrible
<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
<fhmgufs>rekado: Ok. :(
<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>we just gotta do the best we can, and keep on going
<paron_remote>things are already improving
<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>I don't agree with all sandstorm infrastructure decisions, but is pretty impressive
<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
<paron_remote>I'm more optimistic than mark_weaver :)
<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>ACTION prepares a graft for graphite2
<mark_weaver>"Unspecified security fixes"
<paron_remote>graft a graphite
<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>same thing for gtk+-2.24.28-doc
<mark_weaver>and the two outputs are different, according to "guix hash -r /gnu/store/...-gtk+-2.24.28"
<mark_weaver>any idea what's going on there?
<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?)
<paron_remote>(and actively contributing to it)
<mark_weaver>and the new nss release fails to build. *more grump*
<wingo>ACTION grumbles in solidarity
<mark_weaver>heh, thanks wingo :)
<mark_weaver>I think I have it under control now.
<suitsmeveryfine>Hi! I want to say THANK YOU FOR GNOME 3!
<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>mostly not-me :)
<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.
<mark_weaver>yeah, elogind was a great contribution :)
<suitsmeveryfine>For some reason Gnome 3 doesn't lag at all on this old computer.
<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.
<davexunit>but there are problems.
<suitsmeveryfine>Oh? What are the problems?
<mark_weaver>yeah, I think our gnome-shell performs better on this old X60 than when I tried it in Debian long ago
<davexunit>python module problems
<mark_weaver>maybe just because we've got more updated software, i guess
<suitsmeveryfine>I notice that it's light because it lagged a lot in Trisquel
<davexunit>I need to make a mailing list post about it or something. it's really weird and has me stumped.
<mark_weaver>davexunit: did you try making a wrapper for it?
<mark_weaver>that set the python path environment variables?
<davexunit>mark_weaver: yes. there was already a wrapper.
<mark_weaver>ACTION ignorant of python
<davexunit>it's much more unusual than that
<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.
<davexunit>it doesn't even list icecat
<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>I'm at a bit of a loss of how to debug it
<mark_weaver>suitsmeveryfine: don't use the gnome metapackage :)
<mark_weaver>or, if you're running guix from git, you can modify your copy of the gnome metapackage to exclude it
<mark_weaver>(or make your own variant of that metapackage)
<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
<suitsmeveryfine>yes, that's what you told me last time as well. Thanks!
<suitsmeveryfine>With GNOME 3 I can actually use the computer to do stuff!
<paron_remote>it's good when you can use computers for that :)
<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>hm, libreoffice is not building :(
<suitsmeveryfine>davexunit: yes, but it doesn't work well without a mouse.
<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
<paron_remote>ah, looks like the vigra not building thing is known
<lfam>I think an upstream fix is forthcoming. At least, they are working on it
<paron_remote>it looks like it's fixed
<lfam>Hm, do we need to update our package?
<mark_weaver> and
<mark_weaver>maybe those bug reports should be merged
<mark_weaver>vigra has never built on i686, so I'm out of luck on the X60 also
<mark_weaver>if someone wants to fix this, I'd be grateful :)
<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.
<rekado>allows you to annotate pdfs
<lfam>mark_weaver: Regarding different output hashes when grafting, civodul had this to say yesterday:
<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>so far so good on my machine anyway
<mark_weaver>the nss test suite takes an eternity :)
<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>but I'm open to suggestions :)
<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
<mark_weaver>sure, it's a reasonable thought, dunno!
<mark_weaver>I have to go afk for a while.. ttyl!
<suitsmeveryfine>mark_weaver: if you're still there...
<suitsmeveryfine>to which command should I pass --localstatedir=/var
<suitsmeveryfine>I don't see "configure" mentioned
<mark_weaver>see the manual
<mark_weaver>sorry, gotta go
<suitsmeveryfine>I am looking at it now :)
<suitsmeveryfine>ok, bye
<mark_weaver>you need to run ./bootstrap first
<mark_weaver>to create ./configure
<suitsmeveryfine>I see. Thanks
<suitsmeveryfine>Have a good time AFK :)
<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>and it's tricky
<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>xournal is great though!
<paron_remote>dang, I either need to fix assword
<paron_remote>assword is fine
<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>civodul: maybe core-updates?
<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
<mark_weaver>grafts change this game a *lot* :)
<wingo>where are the bordeaux servers :)
<mark_weaver>waiting on a libreboot issue
<mark_weaver>(same as my own server)
<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>'env' prompt
<lfam>What env is that?
<suitsmeveryfine>lfam: guix environment guix, run inside the cloned git repo
<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
<suitsmeveryfine>I followed mark_weavers instructions
<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?
<suitsmeveryfine>and that's what I should do.... Or should I run ./pre-inst...?
<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>but you definitely need the ./pre-inst-env
<mark_weaver>so: sudo ./pre-inst-env guix system reconfigure ...
<mark_weaver>(if you like sudo, which I don't :)
<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?
<suitsmeveryfine>hmm, maybe I should have run guix pull first...
<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
<mark_weaver>those are harmless
<suitsmeveryfine>OK, that's good to know.
<suitsmeveryfine>I'm building it now with civodul's suggested touchpad fix
<suitsmeveryfine>That the synaptics driver should simply be listed before the generic touchpad driver
<mark_weaver>sounds worth a try!
<suitsmeveryfine>mark_weaver: after this reconfiguration, will the new version show up in GRUB just like the others?
<suitsmeveryfine>on top of the others?
<suitsmeveryfine>Then I don't need to reflash libreboot
<suitsmeveryfine>and in the future I run "git pull" instead of "guix pull"?
<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
<wingo>not sure tho
<suitsmeveryfine>wingo: I could try what you suggest
<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
<mark_weaver>makes sense
<suitsmeveryfine>wingo: I just cloned
<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
<suitsmeveryfine>OK! I will try that next then.
<suitsmeveryfine>If this doesn't help that is.
<wingo>remove evdev from %default-xorg-modules, and the corresponding ModulePath line
<wingo>good luck ;)
<wingo>if that works we can consider making that change globally but we'll need some more testing
<wingo>afaiu anyway
<suitsmeveryfine>I could test on a few different machines
<suitsmeveryfine> just moving the hard drive around
<wingo>ACTION would like two-finger scrolling :P
<suitsmeveryfine>wingo: So nobody can use the synaptics driver currently!
<davexunit>I hate touch pads.
<Jookia>Me too
<davexunit>wish my thinkpad didn't have one
<davexunit>the nub mouse is way nicer
<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
<suitsmeveryfine>the cursor is good for pasting text
<suitsmeveryfine>three finger tapping on the touch pad
<suitsmeveryfine>I prefer to use the keyboard, but sometimes the rat is convenient
<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?
<suitsmeveryfine>or rather, is the test suite extremely lengthy?
<mark_weaver>it is quite lengthy, yes
<suitsmeveryfine>OK then, so I abort
<mark_weaver>d47ad0890c0cfbc7114a28ccd768f6cb0933cb84 might be a good commit to build for now
<mark_weaver>that's just before the nss update
<suitsmeveryfine>will I need to run git add, git commit to apply my change?
<suitsmeveryfine>for my local machine?
<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 :)
<mark_weaver>(I improperly assumed that you knew git)
<mark_weaver>or read up on git
<suitsmeveryfine>Well I use git a lot
<suitsmeveryfine>but guixSD is so weird :)
<suitsmeveryfine>I guess I don't know it well enough
<Jookia>suitsmeveryfine: What change do you want to apply for your local machine? Are you just wanting to load an old commit?
<suitsmeveryfine>Jookia: I want to make a chance in xorg services
<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
<Jookia>mark_weaver: I see
<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>Jookia: thanks!
<Jookia>No problem :)
<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.
<mark_weaver>can you take a look?
<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>the one I see at the end is for mips
<civodul>ah ok
<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
<civodul>that wasn't intended
<mark_weaver>great, thanks!