[01:38] <mwhudson> is it possible to have patches in a 3.0 (quilt) source package if the upstream source has dos line endings?
[01:38] <mwhudson> or should i repack the source to get rid of them
[01:42] <dobey> i'm pretty sure i've done that before
[01:43] <dobey> (used 3.0 quilt with upstream source that has CRLF)
[01:47] <mwhudson> dobey: hmm
[01:47] <mwhudson> dpkg-source: info: building python-py using existing ./python-py_1.4.34.orig.tar.gz
[01:47] <mwhudson> (Stripping trailing CRs from patch; use --binary to disable.)
[01:47] <mwhudson> patching file testing/code/test_assertion.py
[01:47] <mwhudson> Hunk #1 FAILED at 143 (different line endings).
[01:47] <mwhudson> dobey: i get that ^
[01:48] <dobey> trailing CRs? sounds like Mac format
[01:49] <dobey> or sounds like the patch was made using an editor that didn't deal with line endings properly
[01:50] <dobey> i think i hit a similar issue a long time ago once, with stuff in bzr, due to some editor wanting to screw with line endings rather than using what the file already has. iirc, fix was use an editor that didn't screw with the line endings
[01:51] <mwhudson> the patch was downloaded from github (with unix line endings) and then hit with unix2dos to try to match the tarball
[01:54] <mwhudson> heh so if i remove the ^Ms from the patch directives in the file but leave them in the content it works...
[01:54] <mwhudson> which is pretty gross
[01:58] <dobey> yeah
[01:59] <dobey> the directives have to be LF only
[02:00] <dobey> cheers
[02:06] <mwhudson> dobey: thanks
=== giraffe is now known as Guest89848
[02:25] <mwhudson> does anyone (wgrant maybe?) have tips for debugging builds that fail on lp but succeed in a schroot locally?
[02:25] <mwhudson> my current bear is this one: https://launchpad.net/ubuntu/+source/python-argcomplete/1.8.1-1/+build/12554534
[02:29] <wgrant> mwhudson: Have you looked at what info you could convince it to print that might be useful?
[02:29] <wgrant> Also are you testing on Linux 4.4 locally?
[02:30] <cjwatson> That looks like the sort of failure that might be sensitive to whether the build's stdin is connected to a terminal.
[02:31] <cjwatson> Maybe.
[02:31] <mwhudson> cjwatson: hmm could be
[02:31] <mwhudson> cjwatson: sbuild < /dev/null ?
[02:31] <cjwatson> Worth a try.
[02:31] <mwhudson> ok
[02:31] <mwhudson> wgrant: yes i'm on 4.4
[02:32] <cjwatson> Though surely sbuild does that for itself.
[02:32] <cjwatson> Maybe also try TERM=unknown
[02:32] <cjwatson> (or unsetting TERM)
[02:35] <cjwatson> If you get desperate you could try juju deploying cs:launchpad/launchpad-buildd with the adjustments in http://bazaar.launchpad.net/~cjwatson/launchpad-buildd/charm/view/head:/charm/README.md to set up a pretty close simulation of an actual buildd, though that's still a bit of hassle ...
[02:36] <cjwatson> (Doesn't handle the LP end, so you either have to set that up too or manually send it RPC commands as per https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally)
[02:37] <mwhudson> hmm not that desperate yet
[02:38] <mwhudson> cjwatson: TERM=unkown seems to have done it
[02:39] <mwhudson> yep
[02:41] <cjwatson> out of interest does unset TERM behave the same way as TERM=unknown?
[02:43] <mwhudson> cjwatson: don't know
[02:44] <mwhudson> trying now but need to run away fairly soon
[09:01] <mwhudson> cjwatson: unset TERM seems to pass fwiw
[09:30] <juliank> Travis is celebrating: "Trusty is soon to become the default." Oh well
=== maclin1 is now known as maclin
[09:49] <ogra_> juliank, well, its not to hard to simply use a chroot for your tests in travis ;)
[09:49]  * juliank uses a docker container
[09:49] <ogra_> or that
[09:50] <juliank> But still, being excited about shipping 3 year old software is weird
=== maclin1 is now known as maclin
[09:50] <ogra_> well, it is fresh for another two :)
[10:11] <mwhudson> doko: is idle-python3.6 being in universe a new thing?
[10:12] <cjwatson> mwhudson: Interesting.  I've left that as a comment on https://code.launchpad.net/~cjwatson/launchpad-buildd/sbuild-schroot/+merge/327634
[10:12] <mwhudson> doko: i guess idle3 needs demoting too?
[10:13] <mwhudson> cjwatson: well i've fixed argcomplete the other way now
[10:15] <mwhudson> ah yeah idle-python3.5 is in main
[10:40] <doko> mwhudson: it get's pulled by the default idle-python
[15:12] <cpaelzer> two times the last 20 minutes - Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/i18n/Translation-en  Hash Sum mismatch
[15:12] <cpaelzer> anything going on, I thought we were out of that mismatches
[15:15] <cpaelzer> hmm not reproducible anymore it seems - I'll come back if it keeps showing up
[15:40] <tsimonq2> xnox: Hey there! So I was glancing at the Universe section of merges.ubuntu.com and I see your name on quite a large amount of packages towards the bottom. Mind if I work on merging those things from Debian, or would that be duplicating work?
[15:42] <xnox> tsimonq2, no, as most of those will be force sync.
[15:42] <xnox> tsimonq2, as that is debian copying the ocaml trasition that I have already completed in ubuntu.
[15:42] <xnox> tsimonq2, most of these shoud drop off, with no merge required.
[15:43] <tsimonq2> xnox: Ah ok, I didn't look into those much, I just took a rather preliminary glance.
[15:45] <tsimonq2> xnox: So I should leave those packages alone or would you be OK with me requesting force syncs (by filing bug reports, I have no archive access...)?
[15:45] <xnox> i'm going through the list now, and will force sync things =/
[15:45] <tsimonq2> Ok, cool.
[15:45] <tsimonq2> xnox: Thanks!
[15:45] <xnox> if you want to steal my merges, feel free to steal _old_ merges, not 0-day merges =)
[15:46] <tsimonq2> Sure :)
[16:58] <bdmurray> cpaelzer: If you are not in a hurry with releasing the fix for bug 1593907 maybe we should wait another week?
[16:58] <ubottu> bug 1593907 in ntp (Ubuntu Zesty) "ntpdate startup routine prevents ntp service from launching up on Ubuntu 16.04 server on system boot; manually starting ntp service works: [FIX in DESCRIPTION], just need to apply it and release a new version" [High,Fix committed] https://launchpad.net/bugs/1593907
[17:21] <cpaelzer> bdmurray: I'm ok waiting
[17:26] <bdmurray> cpaelzer: copy that
[17:29] <bdmurray> cpaelzer: Also why did you say next week in bug 1644507? Its good by my math for time in proposed.
[17:29] <ubottu> bug 1644507 in libvirt (Ubuntu Zesty) "[SRU] virt-aa-helper denied access to qcow2 backing file running nova in a snap" [Medium,Fix committed] https://launchpad.net/bugs/1644507
=== catbus is now known as catbus-afk
=== catbus-afk is now known as catbus
[20:37] <Unit193> mdeslaur: Howdy.  Someone mentioned you were out thus may not have seen my query the other day.  Not sure if you've got the Irssi update prepped or not, but I had done https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/8039406/+listing-archive-extra so if that "helps".
[21:59] <mwhudson> people who run linters in their test suite really are just asking for trouble
[22:00] <Unit193> Yes.
[22:01] <mwhudson> (says the person who uploaded a new pylint last week)
[22:02] <Unit193> mwhudson: Had a chance to look into that golang package again? :>
[22:02] <Unit193> At least pandas is up!
[22:02] <mwhudson> Unit193: i probably would have if i hadn't completely forgotten about it
[22:02] <mwhudson> Unit193: which one was it?
[22:03] <mwhudson> and yeah, glad pandas started working
[22:04] <Unit193> golang-github-jacobsa-crypto
[22:07] <mwhudson> oh this was the one with the insane build tags, right?
[22:08] <Unit193> Yep!
[22:08] <Unit193> "Nice" regressions: https://launchpad.net/ubuntu/+source/golang-github-jacobsa-crypto
[22:09] <Unit193> Affecting gocryptfs, which ftbfs on a couple arches with that, but the version not in -proposed builds fine.
[22:17] <mwhudson> doh, uploaded a fix to my ppa but of course it only builds on amd64 :)
[22:18]  * mwhudson changes it to arch: any temporarily
[22:23] <mdeslaur> Unit193: hi! you're looking for someone to sponsor your merge?
[22:23] <mdeslaur> Unit193: I can do it tomorrow
[22:24] <Unit193> mdeslaur: Generally yes, though it's one that fixes a CVE so wondered if it was on your radar or if you'd already done it.
[22:24] <Unit193> CVE-2017-10965 CVE-2017-10966 Debian #867598
[22:24] <ubottu> Debian bug 867598 in src:irssi "irssi: CVE-2017-10965 CVE-2017-10966" [Important,Fixed] http://bugs.debian.org/867598
[22:24] <ubottu> An issue was discovered in Irssi before 1.0.4. When receiving messages with invalid time stamps, Irssi would try to dereference a NULL pointer. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10965)
[22:24] <ubottu> An issue was discovered in Irssi before 1.0.4. While updating the internal nick list, Irssi could incorrectly use the GHashTable interface and free the nick while updating it. This would then result in use-after-free conditions on each access of the hash table. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10966)
[22:25] <mdeslaur> we rated those CVEs as "low", so we won't fix them until the next round of more urgent CVEs come out
[22:25] <mdeslaur> but I will sponsor your merge
[22:25] <mdeslaur> thanks
[22:25] <Unit193> OK, sounds fair.  Then thanks!
[22:27] <mwhudson> Unit193: golang-github-jacobsa-crypto uploaded
[22:28] <mwhudson> Unit193: i guess you might want to steal the patch back to debian if it works
[22:28]  * mwhudson goes to do a bit more dd new member process work
[22:29] <Unit193> mwhudson: Fantastic!  Thanks a bunch.
[22:30] <Unit193> mwhudson: Do you happen to know if 'go install -ldflags=...' resets Debian build flags?
[22:30] <mwhudson> Unit193: i don't think debian build flags are respected in the slightest by the go tool
[22:31] <mwhudson> i have a half-forgotten action item somewhere to maybe change that
[22:31] <Unit193> I thought not, just making sure the patch I submitted was sane.  I prefer not to touch golang. :3
[22:31] <mwhudson> or at least consider making PIE the default
[22:34] <Unit193> (For reference: Debian 868070_
[22:34] <ubottu> Debian bug 868070 in gocryptfs "gocryptfs: '--version' option is useless, containing only 'gocryptfs'" [Normal,Open] http://bugs.debian.org/868070
[22:34] <Unit193> )
[23:27] <mwhudson> "pytest 3.1.3-1ubuntu1 stuck in artful-proposed for 1 day" oh man it's going to be there a lot longer than that
[23:28] <tsimonq2> hehehe