[09:37] <seb128> could somebody review the indicator-printers SRU in the artful queue? It has been waiting for a while
[09:45] <seb128> doko, hey, do you think you could SRU the glibc fix for bug #1719004 to 17.1O? (https://sourceware.org/git/?p=glibc.git;a=commit;h=fe05e1cb)
[10:03] <infinity> seb128: Doko it probably not who you're looking for.
[10:04] <infinity> s/it/is/
[10:08] <seb128> infinity, you might be interested to upload that as a SRU then? ;-)
[10:09] <infinity> seb128: I'd been watching the bug, yeah.  Poked azanella to CP to the 2.26 branch, but if he doesn't do so, I'll just CP to Ubuntu/Debian.
[10:09] <seb128> infinity, thanks
[10:13] <infinity> seb128: I'm about 137% sure I don't want to cripple the autopkgtest infra any harder with a glibc upload before the weekend, but this one's on my TODO for next week.
[10:14] <doko> mozilla currently doing the crippling ...
[10:14] <infinity> doko: autopkgtest, not buildds.
[10:15] <infinity> http://autopkgtest.ubuntu.com/running <-- Check those queue depths and weep.
[11:27] <andreas> hi there, if somebody has a moment, I could use a sponsorship for https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1721272
[11:27] <andreas> for bionic
[11:35] <doko> jbicha: on MoM you commented for deborphan: can't be synced. Why?
[11:44] <infinity> doko: Can't be synced until the upstream version bumps.
[11:44] <doko> infinity: so no reason to do a fakesync
[11:45] <infinity> doko: Well, we're in sync, do no reason indeed.
[11:46] <infinity> doko: But yeah, our version is higher than Debian's because it's natively versioned, but some doofus in Debian did non-native-versioned NMUs, so 1.7.28.8-0.3 sorts lower than 1.7.28.8ubuntuX
[11:46] <infinity> It'll resolve when 1.7.28.9 happens.  If it happens.
[11:47] <doko> I felt like I needed more pain, addressing the oldest merges
[11:47] <infinity> Hasn't has a maintainer upload since oldoldoldstable, someone should probably just roll up a bunch of pending fixes, convert to dh(1) and do a not-so-friendly upload. :P
[11:47] <infinity> doko: I'm curious why MoM even shows that one, since our version is higher.  Weird.
[11:49] <infinity> cjwatson: ^-- 'sup with that?
[11:49] <infinity> cjwatson: Is MoM not using dpkg --compare-versions to determine these things?
[11:51] <infinity> I wonder if I could fool it by just repacking that as 1.7.28.8.0-0.3
[11:51] <cjwatson> let's not
[11:51] <cjwatson> hm, you're going to make me remember how any of this works
[11:52] <infinity> cjwatson: I apologize for any trauma.
[11:53] <infinity> I find it slightly ironic that deborphan appears to be defacto orphaned but without a formal orphan bug.
[11:56] <cjwatson> I think I see what's going on, ish
[11:56] <cjwatson> momlib.py:get_nearest_source
[11:57] <cjwatson> so it walks through sources trying to find a base
[11:57] <infinity> cjwatson: I had an IRC bug report from someone else about get_nearest_source going haywire too (generating a 20MB diff against something from ancient history), but I'm trying to remember the circumstances of that one now.
[11:58] <infinity> cjwatson: Oh, that one had to do with epochs differing, and MoM not just saying "hahaha, I have no idea" (which would have made more sense).
[11:58] <cjwatson> get_base finds the base version that it's operating on, and it does that by just stripping off suffixes
[11:58] <cjwatson> and then if get_nearest_source finds an exact match, it returns that immediately without bothering with the version sort
[11:58] <infinity> cjwatson: So, sure, yes.  I get how it thinks 1.7.28.8 is the base.  What I don't get is why it's trying at all when Ubuntu has a newer version, sort-order-wise.
[11:59] <infinity> cjwatson: Oh, I see, it just does them in the wrong order.
[11:59] <cjwatson> I'm not saying it's correct; I'm explaining how the code gets there
[11:59] <cjwatson> (I've never touched this code *at all*, so I'm a bit reluctant to just change it straight off)
[11:59] <cjwatson> it probably wants to be finding the newest possible base less than the Ubuntu version
[11:59] <cjwatson> <= maybe
[12:00] <infinity> cjwatson: Where does this live, BTW?  I've wanted to waste some time on it here and there for my pet peeves (like the changelog reflowing that adds *&^!^ newlines at the end of "incorrect" changelogs).
[12:00] <cjwatson> lp:merge-o-matic
[12:00] <infinity> Of course.
[12:00] <cjwatson> you are very welcome to it :)
[12:00] <infinity> I don't want it.
[12:00] <infinity> Unless I discover it's in Perl, C, or shell.
[12:01] <infinity> But it's going to be python.
[12:01] <infinity> It sure is.
[12:01] <cjwatson> I've my own to-do list for it which is probably disjoint to yours ...
[12:01] <infinity> Well, the proper TODO list involves making git merges not insane and scrapping MoM.
[12:01] <cjwatson> there is that
[12:01] <cjwatson> though something still needs to report on it
[12:01] <infinity> But as I've said once already today, let's not let future pie-in-the-sky projects by our perfect blocking our good.
[12:02] <cjwatson> we could ditch the "produce attempted merge" bits and keep the reporting
[12:02] <cjwatson> once git merging is ready and working across the board
[12:02] <infinity> LP itself does reporting too, though not in the most friendly way.
[12:02] <cjwatson> yeah, that's a bit of a disaster area
[12:03] <cjwatson> derived distributions /o\
[12:03] <infinity> But yes, tempted to "fix" the deborphan problem by NMUing 1.7.28.8.1 to Ubuntu with some fixes for high prio bugs in the BTS, and then syncing.
[12:03] <infinity> Cause it's actually an RC bug that the package has non-native versioning. :P
[12:04] <infinity> (Or, would be as soon as someone tried to rebuild it)
[12:04] <infinity> s/to Ubuntu/to Debian/
[12:04] <infinity> Brain not braining right now.
[12:05] <infinity> Oh, maybe it's not an RC bug because it's also v1 format.
[12:06]  * infinity tried to remember if the strict dpkg version:format checks are v3-only.
[12:06] <infinity> s/tried/tries/
[14:38] <doko> cjwatson: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880644 you are listed as the maintainer in Ubuntu. Maybe remove that package and discard the Ubuntu delta?
[14:41] <doko> wondering about the origin of that package libvideo-frequencies-perl
[14:42] <cjwatson> doko: I am?  AFAIK I've only ever touched it for transitions.  Do what you want.
[14:43] <cjwatson> doko: The patch originated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880644
[14:43] <cjwatson> err
[14:43] <cjwatson> doko: The patch originated in https://bugs.launchpad.net/ubuntu/+source/libvideo-frequencies-perl/+bug/223815
[14:45] <cjwatson> doko: So I don't have a problem with removing libvideo-frequencies-perl and dropping the delta in libvideo-capture-v4l-perl, but it's going to need Breaks/Replaces in libvideo-capture-v4l-perl until after bionic, and it'll need a scan for reverse-deps of course
[14:52] <doko> cjwatson: ok, ta. will do that
[15:06] <sil2100> doko: I removed some of the deprecated touch packages and published the fix for dbus-cpp
[15:06] <sil2100> doko: next I'll be looking at trust-store for the boost transition
[15:06] <sil2100> (also FTBFS on bionic)
[15:07] <jbicha> sil2100: see LP: #1728188
[15:12] <sil2100> Yeah, I don't mean to remove it or anything
[15:13] <sil2100> Just mentioning looking at the FTBFS
[15:20] <doko> jamespage: https://bugs.launchpad.net/ubuntu/+source/bareos has problems with our ceph version
[15:25] <infinity> sil2100: I think jbicha's point was that rather than fixing it, you should nag people to get pulse to a state where we can remove it. :)
[15:25] <infinity> sil2100: boost transition rebuilds are non-blocking, so there's no real urgency to fix everything Right Now.
[21:39] <dmj_s76> andrewsh: Why is python-xlib so old (.14 when .20 is newest)?
[21:40] <dmj_s76> I noticed just now because I got hit by a bug that was fixed six years ago upstream.
[22:22] <nacc> dmj_s76: it's in sync from debian? seems like a questio for debian :)
[22:25] <nacc> dmj_s76: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855205
[22:26] <nacc> dmj_s76: it is strange that there was an upload to unstable and testing in nthe past few months of a versio nthat is years old
[22:26] <nacc> dmj_s76: it would appear the upstream moved, and perhaps the srcpkg has not been updated
[23:34] <juliank> cpaelzer: are you around? I have an upload for qemu to fix proposed apt in qemu-user chroots (http://paste.ubuntu.com/25882938/, making it return EINVAL for seccomp prctl calls, picked from upstream submission), but you seem very invested in that package, so it would be great to have an ack. And if not, you'll at least know about it :)
[23:35] <juliank> That's bug 1726394
[23:37] <nacc> juliank: i doubt he's aroundn (germany tz)
[23:37] <nacc> juliank: i can ping him on it on monday, though
[23:39] <juliank> nacc: Well, I guess he knows now / when he's reading it. The patch is trivial, so I'll just upload it now, and then invest apt autopkgtest failures over the weekend :)
[23:39] <nacc> juliank: sounds good :)
[23:41] <juliank> There are some really weird autopkgtest failures.
[23:43] <juliank> Is there a postgresql transition going on? -  Removing autopkgtest-satdep:armhf because I can't find postgresql-10-debversion:armhf
[23:43] <sarnold> there is
[23:44] <juliank> OK, good.
[23:44]  * juliank likes that apt timed out on s390x