<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>
<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
<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
<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.
<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.
<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_>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 :)
<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>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
<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>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>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.
<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)
<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.
<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