[00:40] <infinity> wgrant: Hrm, no can accept libreoffice.  Irksome.
[00:45] <slangasek> was there any specific reason to leave the language-pack-kde uploads in the queue, or should I flush them?
[00:51] <wgrant> infinity: A timeout?
[00:51] <infinity> wgrant: Sadly, yeah.
[00:52] <wgrant> I believe it's illegal in most jurisdictions to mention a timeout with its OOPS ID
[00:52] <wgrant> s/with/without/
[00:52] <wgrant> We may be able to bump the timeout enough
[00:52] <infinity> https://oops.canonical.com/oops/?oopsid=OOPS-bc3d500f772ea9e03cb98de14e919500
[00:52] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=bc3d500f772ea9e03cb98de14e919500
[00:53] <wgrant> Thanks
[00:53] <infinity> ubot2: That was pretty wildly unhelpful.
[00:53] <ubot2> infinity: Error: I am only a bot, please don't think I'm intelligent :)
[00:53] <wgrant> Does libreoffice still have hundreds of langpack packages?
[00:53] <infinity> wgrant: It does, yeah.  Does/should that matter for a source accept?
[00:53] <wgrant> Oh, source, no
[00:53] <wgrant> Hm
[00:53] <wgrant> Did you retry that?
[00:53] <wgrant> The timeout doesn't make very much sense
[00:54] <wgrant> There's this rather suspicious 8.5s gap in the SQL log
[00:54] <wgrant> Which looks like a one-off
[00:55] <infinity> I tried once from the web UI, twice from the CLI.
[00:55] <wgrant> Another OOPS ID would be helpful
[00:56] <infinity> Sure, I'll do it again!
[00:56] <wgrant> Heh
[00:56] <infinity> ...
[00:56] <infinity> And now it works.
[00:56] <infinity> Mechanic's syndrome.
[00:57] <wgrant> As long as you're unblocked :)
[00:57] <wgrant> We'll see the OOPSes in tomorrows reports
[00:57] <wgrant> I wonder if that 9s delay is consistent
[00:57] <infinity> To prove I'm not full of it, another OOPS for the same timeout was:
[00:57] <infinity> https://oops.canonical.com/oops/?oopsid=OOPS-bc3d500f772ea9e03cb98de14e919500
[00:57] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=bc3d500f772ea9e03cb98de14e919500
[00:57] <wgrant> It's really really odd
[00:57] <wgrant> Aha, thanks
[00:57] <infinity> Wait, that's the same one.
[00:57] <infinity> Wut?
[00:57] <wgrant> Yes, yes it is
[00:58] <infinity> On two different runs of the API tool, though.
[00:58] <infinity> My scrollback doesn't lie...
[00:58] <wgrant> Nope
[00:58] <wgrant> It does lie
[00:58] <wgrant> https://oops.canonical.com/oops/?oopsid=OOPS-eddb1503e8421232ad7713cdada76c44 is another one
[00:58] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=eddb1503e8421232ad7713cdada76c44
[00:59] <wgrant> Hmmm
[00:59] <infinity> Unless I'm blind...
[00:59] <infinity> http://paste.ubuntu.com/1263001/
[00:59] <wgrant> A 6s hole between those two queries this time
[00:59] <wgrant> wat
[00:59] <infinity> I swear that has the same OOPS twice.
[00:59] <infinity> Are async jobs re-entrant? :P
[00:59] <infinity> Okay, no, I'm blind.
[01:00] <wgrant> Search for x-lazr-oopsid
[01:00] <wgrant> There are two
[01:00] <infinity> THere's the other OOPS.
[01:00] <infinity> Evidently, scrolling through raw XML makes me go cross-eyed.
[01:00] <wgrant> Yeah
[01:00] <wgrant> So, all three OOPSes show the same thing, and none of them make much sense at all
[01:01] <wgrant> Oh
[01:01] <wgrant> Hmm
[01:01] <wgrant> That's about the time it would parse P-a-s
[01:01] <wgrant> But last I heard the appservers didn't have P-a-s.
[01:02] <wgrant> But I wonder if it's retrieving the source's binary history
[01:02] <wgrant> Which is quite a few binaries, IIRC
[01:02] <infinity> It's a lot of everything.
[01:02] <infinity> I think it's one of those source pages that times out, too.
[01:03] <wgrant> It's also the only source package that regularly ENOSPCs our builders
[01:03] <infinity> Only the PPAs, but yes.
[01:03] <wgrant> Hm
[01:03] <wgrant> The hole is right where it shells out to dpkg-architecture
[01:04] <infinity> That makes no sense.
[01:04] <infinity> Cause that call wouldn't be package-dependant.
[01:04] <wgrant> No, and it could be something that's just nearby
[01:04] <wgrant> Exactly
[01:06] <wgrant> But there's indeed no P-a-s specified
[01:14] <wgrant> And surely the scheduler doesn't hate us that much
[01:15] <wgrant> infinity: I think Launchpad just really really doesn't like you
[01:15] <infinity> wgrant: I'm not inclined to disagree with your analysis.
[01:15] <wgrant> It probably saw your blueprint change this morning
[01:25] <wgrant> infinity: Bug #1062638
[01:25] <ubot2> Launchpad bug 1062638 in launchpad "Queue accepts occasionally time out due to huge non-SQL time in createMissingBuilds" [Critical,Triaged] https://launchpad.net/bugs/1062638
[04:08] <tjaalton> anyone available to ack the precise-proposed upload for bug 966744?
[04:08] <ubot2> Launchpad bug 966744 in xserver-xorg-video-intel "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,In progress] https://launchpad.net/bugs/966744
[04:11] <infinity> tjaalton: I can look at it.
[04:11] <tjaalton> infinity: thanks
[04:11] <tjaalton> updating the sru header atm
[04:12] <infinity> tjaalton: You seem to be lacking bugs for the other patches?
[04:12] <tjaalton> infinity: that's the info I added there :)
[04:12] <infinity> Added... Where?
[04:13] <tjaalton> to the bug above
[04:13] <infinity> Oh, are you implying that all three patches address the same bug?
[04:13] <tjaalton> [regression potential]
[04:13] <tjaalton> yes
[04:13] <tjaalton> well, the first one was a by-product
[04:13] <tjaalton> when trying to reproduce it
[04:14] <tjaalton> hmm or maybe not
[04:18] <tjaalton> sigh, can't confirm it either way, since I added it to the branch late-august
[04:18] <infinity> tjaalton: Yeah.  I mean, they all sound like valid and useful bugfixes, but the compiz/resume thing doesn't seem to relate to the output-attach/resume issue?
[04:19] <infinity> tjaalton: There's no bug for the 106 patch?
[04:19] <tjaalton> upstream bugs yes
[04:19] <tjaalton> I'll check lp
[04:19] <tjaalton> pretty hard to match them..
[04:22] <infinity> tjaalton: Well, if there's no bug, there's no way to have a testcase to make sure it's fixing the bug, etc.  Sounds like the sort of thing we'd like to make sure is verified.
[04:25] <tjaalton> woohoo, bug 992391 should match fdo 50078
[04:25] <ubot2> Launchpad bug 992391 in xserver-xorg-video-intel "[i915] xserver freeze on switching VGA1/LVDS1" [Undecided,Confirmed] https://launchpad.net/bugs/992391
[04:26] <infinity> Ahh, so it doesn't need to be on suspend, it can be triggered manually with display switching?
[04:26] <infinity> Much easier to verify.
[04:26] <infinity> And also a much worse bug. :P
[04:26] <infinity> Can you give me a fresh upload with a bug closure in the changelog?
[04:28] <tjaalton> yes
[04:28] <tjaalton> seems like this was filed upstream too and then marked as closed, will check again if it really is the other bug..
[04:29] <infinity> Sure.  You may have a third bug on your hands.  Worth checking before uploading.
[04:29] <infinity> Cause these all sound like vaguely nasty behaviours.
[04:29] <tjaalton> heh
[04:30] <tjaalton> and actually, fdo 50100 references the commit in 50078 so I'll just add the bug closure there and ping the bug so they'll test it once it hits proposed
[04:33] <tjaalton> infinity: uploaded, but I wonder if it works with the same version number?
[04:33] <infinity> tjaalton: It does.
[04:34] <infinity> tjaalton: The queue doesn't care, only the archive.  I'll just reject one.
[04:34] <tjaalton> ah, cool
[04:36] <infinity> tjaalton: Okay, that changelog looks better.  I'll double-check the diff when it comes through and you should be good to go if you didn't just introduce weird cruft or replace an X driver with a copy of frozen-bubble.
[04:37] <tjaalton> heh, no the branch looks clean
[04:37] <infinity> Yes, but it's my job to not believe you. :)
[04:37] <tjaalton> of course :)
[04:39] <infinity> Oops, no precise task for that second bug.
[04:39]  * infinity fixes that.
[04:40] <tjaalton> i can do that
[04:40] <infinity> tjaalton: I don't care if there's all the SRU headers on that one, but do me a favour and make sure there's a clear test case somewhere.
[04:40] <infinity> tjaalton: I already set up the task. :P
[04:41] <tjaalton> heh, thanks
[04:41] <tjaalton> ok I'll see if the test case works here
[04:42] <infinity> Yeah.  The bug description itself IS a pretty good test-case, assuming it actually reproducibly crashes the server.
[04:42] <tjaalton> right, _should_ be easy to hit
[12:12] <Laney> ScottK: popey: anyone else: https://ubuntuone.com/1oBE6gcsZopYjcldngBqkr
[12:12] <Laney> I had to do one additional fix, but it looks good to me now.
[12:12] <Laney> I'm going to upload it to the queue.
[12:12] <popey> what was the fix?
[12:12] <Laney> same fix as Mirv did to Ubuntu-M but for Ubuntu-MI
[12:13] <Laney> otherwise Ubuntu Light Italic comes out as Ubuntu Medium Italic
[12:14] <popey> tested that fudged font on other platforms? (i.e. LO and other apps on Windows?
[12:14] <Laney> no
[12:14] <Laney> but I'm not going to upload it to windows :P
[12:14] <popey> sure, but we don't want different binary versions of the font for different platforms really do we?
[12:15] <Laney> if Windows is broken but Ubuntu is not then I wouldn't be too unhappy with a fork
[12:15] <Laney> it's this or rustle up DM to do the fix with their real tools
[12:16] <Laney> Qt is working as far as I can see too :-)
[12:17] <popey> forking our own font because our own apps don't work with it seems sub-optimal to me.
[12:19] <cjwatson> We're willing to patch our own non-font packages if need be
[12:24] <Riddell> Laney: got packages to test?
[12:24] <Laney> Riddell: queuebot will update you in 3...
[12:24] <Laney> 2...
[12:25] <Laney> 1 ...
[12:25] <Laney> :(
[12:25] <Laney> anyway, it is in the queue. Build that and try it out.
[12:27] <Laney> I'll leave it up to others to decide whether to accept now or reject/accept on Monday
[12:27] <Laney> out for a little while, bye
[12:28] <popey> thanks Laney
[12:56] <Riddell> Laney: fonts working good in Kubuntu for me
[12:56] <Riddell> ScottK: ^^
[13:48] <skaet> ^ Based on the fonts working ok for Riddell,  have accepted it.
[15:34] <ScottK> Riddell: Thanks.
[16:32] <cjwatson> so I know in outline what's wrong with aptdaemon, I think, but I have to get ready to go out for dinner
[16:32] <cjwatson> I'll finish fixing it when I get back
[16:32] <cjwatson> (just to save anyone else duplicating work on it)


[02:02] <mwhudson> hm
[02:03] <mwhudson> why hasn't golang-1.6 migrated from -proposed to -updates in trusty yet?
[02:03] <mwhudson> i thought it would happen after a week
[02:03] <mwhudson> (and the bug was verification-done)
[02:07] <roaksoax> mwhudson: http://people.canonical.com/~ubuntu-archive/pending-sru.html -> seems green, but its probably because there's no golang-1.6 in trusty main
[02:07] <roaksoax> mwhudson: so might need manual push
[02:07] <roaksoax> w
[02:07] <mwhudson> roaksoax: ah ok
[02:15] <infinity> It's always manual.
[02:15] <infinity> It needs a human to say "yep, let's do that".
[02:16] <infinity> And we don't tend to release on weekends.
[02:16] <infinity> Though, for a NEW package, it can't hurt.
[02:16] <infinity> mwhudson: Released.
[02:16] <mwhudson> infinity: what is this weekend you speak of
[02:16] <mwhudson> infinity: thanks
[02:17] <infinity> mwhudson: The weekend is the time when a large number of our developers shockingly aren't glued to their keyboards and would prefer not to deal with the flood of bug reports a bad SRU can cause.
[02:17] <infinity> mwhudson: Weird, I know.  Since some of us have brain uplinks.
[02:18] <mwhudson> infinity: it's already monday afternoon though!
[02:18] <infinity> (Well, it's both about developer response time, and about not breaking corporate users with unattended-upgrades and a similar 5-day schedule)
[02:18] <infinity> mwhudson: Not in the correct part of the world!
[02:18] <lifeless> infinity: 'correct'!
[02:18] <infinity> lifeless: You heard me.
[02:19] <lifeless> I see stockholm has its claws into you
[02:19] <infinity> I lived in the future for five years.  It didn't agree with me.
[02:20] <infinity> Granted, not your little bit.
[02:20] <lifeless> :)
[03:59] <mwhudson> woo fun running the go runtime tests can kill the kernel on s390x
[03:59] <mwhudson> i guess i should report that to someone...
[04:01] <lifeless> mwhudson: !
[04:02] <mwhudson> actually an ibm person mentioned this too
[04:02] <mwhudson> so /hopefully/ i'm just running an out of date kernel
[04:26] <cpaelzer> good morning
[06:07] <pitti> Good morning
[06:07] <pitti> jdstrand: thanks, I'll look into the udev crash now
[06:11] <pitti> dannf, infinity: adt-run always sets LANG=C.UTF-8 by default; something changed there since the new glibc, can you reproduce this with that command?
[06:11] <pitti> dannf: lxd currently seems broken on my xenial, I'll look into that now and file a bug
[06:27] <dholbach> good morning
[07:18] <mwhudson> yay https://launchpad.net/ubuntu/+source/docker.io/1.10.3-0ubuntu4
[09:38] <mardy> Mirv: hi! ping ping :-)
[09:52] <Mirv> mardy: pong pong
[09:52] <mardy> Mirv: red alert :-) Do you think we can get this fixed by 16.04? bug 1564767
[09:53] <mardy> Mirv: I've attached a patch, generated with quilt on top of the existing debian/patches
[09:53] <Mirv> mardy: thanks, sure it should be possible. can you submit it to https://launchpadlibrarian.net/251636878/xcb_fix_parent_screen_of_embedded_windows.patch ASAP? we shouldn't carry a patch if it's not approved by upstream.
[09:54] <mardy> Mirv: sorry, to where?
[09:55] <Mirv> mardy: hah, https://codereview.qt-project.org/ I was meaning to paste
[09:55] <Mirv> mardy: maybe look through http://code.qt.io/cgit/qt/qtbase.git/log/src/plugins/platforms/xcb/qxcbwindow.cpp too if there's something to backport instead of your patch
[09:56] <mardy> Mirv: but are they still interested in Qt 5.5?
[09:57] <Mirv> mardy: no, they'd be interested in 5.6 though if it's affected by the same bug
[09:58] <Mirv> mardy: and most likely 5.6 branch is the best place to offer a fix too in, they merge from there to 5.7 and dev.
[09:58] <mardy> Mirv: I'll now test 5.6, but looking at their code, I believe they've already fixed it
[09:58] <mardy> Mirv: the problem is, it's not just one patch to backport, but many
[09:59] <Mirv> mardy: ok, to me it'd look like the line of code in question is still unchanged, just a variable name changed. but maybe it was fixed elsewhere?
[10:00] <Mirv> mardy: we actually have a lot of XCB fixes already in, in order to try to fix multi-monitor issues that plagued 5.5 still (and maybe even 5.6 still too).
[10:00] <Mirv> mardy: but at this point I'd tend to agree that if it's yet another multiple patches, it would be better to take your two-liner patch instead
[10:02] <mardy> Mirv: yes, that function is still there in Qt 5.6, but handleConfigureNotifyEvent() doesn't call that method anymore :-)
[10:03] <mardy> Mirv: but let's see, I'm installing 5.6 and I'll let you know
[10:03] <Mirv> ok!
[10:19] <GunnarHj> pitti: Hi Martin, Time to look at the FFe request at bug #1556457 (fontconfig 2.11.1 -> 2.11.94)?
[10:36] <mardy> Mirv: yes, 5.6 works! :-)
[10:37] <mardy> Mirv: but given how deep are the chanegs in teh XCB plugin between 5.5 and 5.6, I think it's quite risky to try a backport (also because we already have quite a few debian/patches touching XCB)
[10:37] <Mirv> mardy: ok! :) then you don't need to submit anything to upstream since indeed they've forgotten about 5.5 by now (because 5.6 is LTS). so it may be your patch is simply the best way.
[10:38] <Mirv> mardy: I agree, unless some of the already backported patches form a baseline on top of which one more could be cherry-picked, but I somehow doubt that too
[10:38] <Mirv> mardy: it just happened I got my previous qtbase xenial upload done so I'll start preparing the next one but not with what I had on my mind earlier (not so important) but your patch instead
[10:39] <mardy> Mirv: excellent, thanks a lot!
[10:54] <rbasak> tseliot: thank you for fixing bug 1565436 so quickly. I wasn't expecting that!
[10:55] <tseliot> rbasak: I think I did a while ago. I need to find some time to backport the fix
[10:55] <rbasak> Ah, OK
[11:04] <rbasak> infinity: opinion on https://bugs.launchpad.net/ubuntu/+source/myodbc/+bug/1564856/comments/1 please?
[11:04] <rbasak> Presumably repackaging for cmake shouldn't be insurmountable and we should just do it?
[11:05] <Skuggen> rbasak: But the main issue hasn't been fixed upstream
[11:06] <rbasak> Skuggen: how hard would it be to fix it and patch it in distro and then send that upstream?
[11:06] <rbasak> (in that I'm asking the question - I don't mean that rhetorically)
[11:08] <Skuggen> The developers are working on a fix, which we would then apply to the newest released version, but I don't know the code, so I don't really know how big a task this is
[11:11] <pitti> GunnarHj: followed up; I don't think I have enough information/experience with fontconfig to answer this right away, but I asked some questions there
[12:00] <tsimonq2> Greetings, regarding bug 1530323, I don't know what to do next, and it's affecting Lubuntu, could somebody please take a look at this bug report and my comments and judge whether it's fixed yet or not? I can't really tell...
[12:01] <GunnarHj> pitti: Added an answer to bug #1556457. If you don't have enough fontconfig experience, who has ;)
[12:11] <GunnarHj> Hi Laney, any chance you have some good advice re. the bug #1556457 FFe?
[12:42] <Bluefoxicy> bluez-gstreamer wine1.6 gnome-media need recompile against gstreamer 1.0; they depend on gstreamer 0.10 in Xenial o.o
[12:42] <Bluefoxicy> not sure if that's fixable at this stage though
[12:43] <Bluefoxicy> (also bah the Wine team, they didn't get Wine 1.8 in Xenial even though it's been out since before Wily)
[14:16] <_hc> we (Android Tools Debian team) finally got all of our current packages into Debian/testing.  xenial is mostly in sync, but there are two packages with packaging fixes that have not been fixed: android-platfrom-system-core and android-platform-tools-base
[14:16] <_hc> oops, have not been synced
[14:39] <_hc> should I do requestsync?
[14:40] <ginggs> _hc: yes please
[14:41] <_hc> ok will do
[14:41] <_hc> seamlik: do you want to try the requestsync, or shall I?
[14:42] <seamlik> I'm not familiar with that ...
[14:42] <_hc> ok, I can do it, its basically a webform in launchpad
[14:42] <teward> _hc: i'd be happy to run 'requestsync' for you if you need
[14:43] <teward> then give you the bug # to make your comments ;)
[14:43] <teward> this close to final freeze, though, how critical are the package updates :P
[14:43] <seamlik> Hmm I would wait for some time
[14:43] <teward> s/final freeze/final release/
[14:44] <_hc> I think they are essential, and these are new packages that nothing else depends on, so they are low risk changes
[14:44] <_hc> the new packages do depend on each other
[14:44] <_hc> for example, one change is a typoed package name in depends
[14:44] <seamlik> Do we have any deadlines?
[14:45] <_hc> yeah, final release is very soon
[14:45] <teward> final freeze is next week I think
[14:45]  * teward pulls the Xenial schedule up
[14:45] <seamlik> April 14?
[14:45] <teward> https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
[14:45] <teward> Final Freeze on April 14
[14:45] <teward> and we're way past FeatureFreeze
[14:46] <_hc> these are all bug fixes in the packaging
[14:46] <teward> so you'll need to follow https://wiki.ubuntu.com/FreezeExceptionProcess to get it reviewable for FFe
[14:46] <seamlik> OK, fire at will ;)
[14:47] <teward> seamlik: android-platfrom-system-core and android-platform-tools-base ?
[14:47] <teward> seamlik: and from Debian Testing?
[14:48] <_hc> teward: the first package is https://packages.debian.org/source/sid/android-platform-system-core
[14:48] <teward> and from Testing or Unstable?
[14:48] <_hc> hold off on -tools-base
[14:48] <teward> (where do you want the sync req. to come from)
[14:48] <_hc> unstable and testing should be the same, it just happened, but unstable to be safe
[14:49] <teward> hmm
[14:49] <teward> !info android-platform-system-core xenial
[14:49] <teward> hate the bot
[14:49] <seamlik> Oh, android-platform-build
[14:49] <teward> source packages are better ;)
[14:49] <teward> okay, so...
[14:50] <ginggs> teward, _hc: android-platform-system-core package already sync'd
[14:50] <teward> yep
[14:50] <teward> i was going to say that
[14:50] <teward> E:Versions match
[14:50] <teward> :P
[14:50] <_hc> ah, ok, I guess I should look at the ubuntu tools rather than the debian tools here :)
[14:50] <teward> ginggs: though, rmadison shows a delta between sid and xenial/universe
[14:50] <teward> are we absolutely certain they're in sync?
[14:51] <ginggs> sync'd 5 minutes ago
[14:51] <seamlik> Thank you!
[14:51] <teward> ah, nice, so rmadison isn't updated :)
[14:51]  * teward goes back to figuring out why his boxes are deady
[14:51] <teward> dead*
[14:51] <ginggs> sponsored by LocutusOfBorg for Mapreri
[14:51] <teward> even better :)
[14:52] <seamlik> Mapreri helped a lot during the migration
[14:52] <ginggs> _hc: what was the other one?
[14:52] <_hc> android-platform-build
[14:53] <teward> i get the same notice about version match for that too
[14:53] <teward> ginggs: ^
[14:53] <_hc> the android-platform-tools-base update requires a new package to xenial, so that's probably not feasible
[14:53] <_hc> liblombok-ast-java
[14:53] <teward> my squid proxy on my net is dead, so... I can't check easily
[14:54] <teward> as of a couple minutes ago 'cause i broke it :/
[14:54] <ginggs> android-platform-build was also sync'd already
[14:54] <_hc> 8 minutes ago, it looks like :)
[14:54] <ginggs> you can see https://launchpad.net/ubuntu/+source/android-platform-build and https://launchpad.net/ubuntu/+source/android-platform-system-core
[14:54] <_hc> I think we're good then unless seamlik has something to add
[14:54] <ogra_> did anyone contact the phone team about these packages (since they maintain their own patched versions of i.e. adb, adbd and fastboot)
[14:55] <_hc> I think we've had some contact.  these packages don't touch the original android-tools source package, which is what Ubuntu uses for adb, adbd, and fastboot
[14:55] <ogra_> ok
[14:55] <_hc> Ubuntu already has its own android-tools anyway, for a while now
[14:56] <ogra_> we tried to sync it at one point
[14:57] <seamlik> well, that's all we need for now :)
[14:59] <_hc> it would be great to move adb and fastboot out of the android-tools package.  We have more up-to-date adb and fastboot building in the Android Tools Team packages, but they only build on amd64 and i386.  So someone would need to port things to all the other archs to fully replace the android-tools source package
[15:00] <ogra_> you would have to pull in the patches to the udev rules
[15:00] <ogra_> (that are added to support ubuntu devices)
[15:01] <ogra_> (beyond that fastboot and adb binaries shoudl be fine to use vanilla ... adbd not though  ... taklk to the guys in #ubuntu-touch)
[15:17] <Mirv> mardy: bug #1564767 fix is now built at https://requests.ci-train.ubuntu.com/#/ticket/1215 - you can mark it as Lander Signoff Approved when ready, although no hurry since qtbase is and will be blocked in xenial-proposed because of mysql-5.7 transition it seems
[15:25] <rbasak> What happened to bzr-fastimport? Looks like it disappeared since Wily.
[15:25] <rbasak> "(From Debian) RoQA; orphaned, unmaintained upstream, rc-buggy; Debian bug #742416"
[15:47] <barry> doko: configglue (even upstream bzr) is still not python3.5 compatible, thus the ftbfs
[15:47] <barry> doko: LP: #1504288
[15:48] <barry> doko: i will spend a *little* time looking at an upstream
[15:59] <rbasak> xnox: around? Please could you comment on https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1557830/comments/10 please?
[15:59] <rbasak> xnox: I'm happy to do whatever you and the release team prefer.
[16:05] <xnox> rbasak, and why do you ask me? I'm not a release team =)
[16:05] <rbasak> xnox: because you have reason to care :)
[16:05] <xnox> also what juju upstream supports should not matter what ubuntu archive compiles.
[16:05] <rbasak> Yeah
[16:05] <xnox> rbasak, e.g. it should be totally valid to have a client on 32bit controlling 64bit deployments....
[16:06] <rbasak> I think I should change it to "any".
[16:06] <rbasak> If it FTBFS on some archs, then the release team can decide whether to let that in or not.
[16:06] <rbasak> It doesn't seem right to just turn it off on an arch, since I understand that makes life hard for porters who want a particular arch to work well across the archive.
[16:15] <doko> stokachu, looking at bignum: please don't use bash as the shebang when plain sh is good enough
[16:15] <stokachu> doko: bignum?
[16:16] <doko> stokachu, you uploaded that to NEW. or can it be removed?
[16:16] <stokachu> doko: you talking bout bigdata?
[16:16] <doko> ahh
[16:16] <doko> yes
[16:17] <stokachu> doko: i can fix the bash string if you want
[16:17] <doko> stokachu, just for your next upload
[16:18] <stokachu> doko: thanks, fixed here https://github.com/Ubuntu-Solutions-Engineering/bigdata-deb/commit/fce9d383a8011e9b31cca01022128dc412afca87 so it'll make it into next upload
[16:20] <doko> stokachu, debian/copyright is missing 2016, in conjure as well
[16:20] <doko> stokachu, conjure: why all the pre-built egg files in conjure/dist?
[16:21] <stokachu> doko: hmm
[16:22] <stokachu> doko: i need to remove those, not sure why they are there
[16:23] <stokachu> doko: i fixed it and the copyright, anything else? otherwise i can upload a new package
[16:23] <doko> stokachu, ok, I'll reject that one. also ubuntui/*.py doesn't have any copyright notices. there might be more of these
[16:23] <stokachu> ok ill add those files to copyright
[16:24] <doko> stokachu, the question is, if these files should contain the copyright, as the other files have it
[16:25] <stokachu> doko: yea some are LGPL and AGPL
[16:26] <doko> stokachu, well, then the debian/copyright is wrong. it only mentions the MIT license
[16:26] <stokachu> doko: yep fixing that now
[16:28] <doko> stgraber, golang-gopkg-inconshreveable-log15.v2-2.11+git20150921.0.b105bd3 debian/copyright is missing the copyright for the term subdir
[16:33] <stgraber> doko: thanks, will fix
[16:41] <doko> stokachu, the update conjure: is it intended that the toplevel files are still covered by the MIT license?
[16:41] <stokachu> doko: yea
[16:42] <stokachu> aside from those directories i defined
[17:47] <doko> tjaalton, updated https://bugs.launchpad.net/ubuntu/+source/libset-scalar-perl/+bug/1558820
[18:18] <tjaalton> doko: cool, thanks
[18:27] <Pharaoh_Atem> nacc: I'm having trouble actually building php-fshl locally
[18:27] <Pharaoh_Atem> it keeps throwing errors
[18:31] <nacc> Pharaoh_Atem: paste?
[18:47] <Pharaoh_Atem> nacc: http://fpaste.org/349497/45979560/
[18:57] <elbrus> infinity: any progress with debugging fpc FTBFS on powerpc yet?
[18:57] <elbrus> ginggs: ^^ I don't assume you know more already?
[18:58] <ginggs> elbrus: i know nothing!
[18:58] <elbrus> :)
[18:59] <nacc> Pharaoh_Atem: hrm, rebuilt fine here
[18:59] <nacc> Pharaoh_Atem: oh, in debian, though
[18:59] <nacc> let me check that
[18:59] <infinity> elbrus: I didn't have time over the weekend to dig deeper.  It's on my "free time" TODO this week.
[19:00] <elbrus> ack
[19:04] <stgraber> mterry: sorry for those late MIRs took forever for those 3 packages to be accepted into xenial (went unreviewed between December and a couple of hours ago...)
[19:05] <doko> stgraber, lxc team == you?
[19:05] <nacc> Pharaoh_Atem: hrm, built fine in a sid schroot too
[19:06] <stgraber> doko: lxc team is hallyn, mmcc, tych0 and I
[19:06] <stgraber> doko: jgrimm is also in the team so he can get the rest of the server team up to speed on bugs if we miss any
[19:06] <doko> stgraber, was the team accepted as a bug subscriber in the past?
[19:06] <stgraber> doko: and the server team is also subscribed to those packages separately (jgrimm was working on it now-ish)
[19:06] <doko> ahh, ok
[19:06] <stgraber> doko: yeah, we are the MIR subscribe team for a dozen packages
[19:07] <jgrimm> stgraber, doko: should be done already even
[19:07] <stgraber> doko: https://bugs.launchpad.net/~ubuntu-lxc/+packagebugs those are all the packages that are in main for which the ubuntu-lxc team is the main contact point
[19:07] <doko> stgraber, mterry: I just did the NEW review, so I'll propose to promote these. just waiting on your feedback
[19:08] <doko> mterry's feedback
[19:08] <stgraber> cool. I poked mterry because he's been handling all our other go-related MIRs this cycle but I'm not picky as to what MIR team member gives the go ahead :)
[19:09] <stgraber> I refreshed the go-lxc one with a new snapshot an hour ago to pick up the bugfixes needed for LXC 2.0, the other two looks to be perfectly functional so no reason to update to new upstream snapshots
[19:28] <jdstrand> superm1: hey, fyi bug #1565963
[19:28] <jdstrand> seb128: fyi, ^
[19:30] <superm1> thanks, i'll take a look
[19:50] <nacc> slangasek: does LP: #1565097 need to be re-uploaded?
[19:50] <nacc> slangasek: i don't see it changed yet
[19:51] <slangasek> nacc: quite possibly! let's see
[19:52] <nacc> slangasek: jgrimm: i believe i'm down to the last 9 packages that need updating, fyi; a few will be in a broken state (e.g., drupal7 pending drupal8 or drupal7 updates) and i'm still contacting upstreams for a few to see if they have php7 versions we can pull down
[19:52] <nacc> slangasek: but i think we'll be in a position to remove src:php5 soon, if you want, with minimal breakage to the archive, afaict
[19:52] <jgrimm> nacc, great!
[19:53] <slangasek> nacc: my count of remaining affected packages Friday was higher than yours; was your count including or excluding things that were still awaiting sponsorship at the time?
[19:53] <TJ-> nacc: are any of the php5/php7 changes you've been shepherding in any way capable of removing a user from the sudo group? specifically anything related to libapache2-mod-php5 and/or a2enmod ?
[19:53] <TJ-> nacc: I'm thinking .postinst mostly
[19:55] <nacc> slangasek: including those things still awaiting sponsorship. My count was more of what is left to touch list; the official reverse-depends count is 30 right now, but i submitted a bunch today and some are false-positives due to php5 | php
[19:55] <nacc> TJ-: hrm, in general, i've not changed any fucntionality in the postints, beyond calling the right command (for php5enmod -> phpenmod) or right parameter (a2endmod php5 -> a2endmod php)
[19:56] <nacc> TJ-: so I'd be surprised if that happened, but I'm not going to make any guaranteed; do you have a specific package in mind?
[19:56] <nacc> or a bug, i guess? :)
[19:56] <slangasek> nacc: ok.  my count as of Friday was 56, and a couple of those are already on the removals list (php-imap, php-mcrypt) but we should reconcile these counts soonish :)
[19:56] <TJ-> nacc: maybe you could run your eyes over the following pastebin? A user in #ubuntu+1 reported it and I did some 'live' debugging and we couldn't figure it out, so not even sure it is a bug, and the user re-added themselves so the issue is now dead. http://pastebin.ubuntu.com/15585996/
[19:58] <nacc> slangasek: yep, let's plan on syncing this afternoon?
[19:58] <slangasek> nacc: +1
[19:59] <nacc> TJ-: looking; but fwiw, i've not actually touched the src:php5 itself, which is a bit out of sync with debian probably
[19:59] <nacc> TJ-: it's goign to be removed
[19:59] <nacc> TJ-: so i'd just suggest to that user they need to migrate asap :)
[19:59] <nacc> TJ-: and/or reproduce it with php7
[20:00] <TJ-> nacc: right... I just wanted to do a heads up since we're so close to release... the trigger might have been a2enmod rather than the package install; hard to know but would be awful for that to escape into the wild
[20:00] <nacc> TJ-: yep, i'll try and reproduce it here in a bit?
[20:01] <tkamppeter> infinity, hi
[20:01] <TJ-> nacc: well no great pressure, as I said, the user re-added themselves from a recovery boot and I couldn't find any other mentions of similar stuff. It was a fresh clean install of 16.04 about 45 minutes before it happened, though.
[20:02] <nacc> TJ-: ok, np; but first, lunch! :)
[20:02] <TJ-> nacc: supper :)
[20:03] <infinity> tkamppeter: Hi.
[20:06] <tkamppeter> infinity, because of cups-filters. I do not know whether you know that I have made use of the fact that one could run LSB-compliant packages on Ubuntu.
[20:06] <tkamppeter> infinity, for this there was an "lsb" package. Debian pulled this feature out, very shortly before our FF, not letting me a chance to introduce a new package.
[20:08] <tkamppeter> infinity, so as LSB compatibility was actually only used by us to allow manufacturers to supply printer drivers, I have simply re-introduced the LSB compatibility by taking the stuff which was taken out of the lsb package into cups-filters.
[20:09] <tkamppeter> infinity, only that I forgot the postinst  in the first place and got a bug report because of this and added it today to complete my work.
[20:09] <infinity> tkamppeter: Yes, I followed your bug report to see what you were doing.  cups should not, in any way, be responsible for providing ld.so links, however.
[20:10] <tkamppeter> infinity, so does this mean that I should say LSB driver support is skipped on the LTS or forever?
[20:11] <infinity> tkamppeter: No, it means you should probably talk to Foundations people before deciding to hack around something like this in a printer driver package. :P
[20:12] <slangasek> nacc: zend-framework> the prior-version argument to dpkg-maintscript-helper mv_conffile is strongly recommended
[20:12] <infinity> If we decide LSB ld.so links belong anywhere, it should be something reasonably low-level, either a re-introduction of some lsb thing, or in glibc itself.
[20:12] <slangasek> nacc: (not blocking this upload on it, but you really want that there so that things eventually clean up)
[20:12] <infinity> tkamppeter: Surely, you see how your method would immediately go sideways if someone else also decides they need that functionality.
[20:14] <tkamppeter> infinity, so what I could perhaps do then is to recover the lsb-source package to its old state, of before Debian took everything out and sync cups-filters with Debian to remove all LSB stuff from it. OK?
[20:16] <infinity> tkamppeter: I don't think reverting lsb is sane either.  But leave it to slangasek and I to sort out the best way to solve this one.  cups-filters definitely shouldn't have an lsb package, though.
[20:16] <jdstrand> superm1: I added some more info to the description of the bugs. the secret keys didn't get migrated
[20:20] <tkamppeter> infinity, slangasek, so please check and tell me what is the best solution for that.
[20:23] <tkamppeter> infinity, slangasek, the solution can be a short-term solution for 16.04 only. On the OpenPrinting Summit I will tell manufacturers that the LSB is dead for printing as one of the two principal distro families left the LSB.
[20:24] <slangasek> tkamppeter: an LTS in not "short term"; anything deployed here has to be supported on upgrade for 2 years, so needs to be designed carefully. I'm fairly certain the right answer is to put the symlinks in glibc, but I'll leave that to infinity to confirm
[20:26] <tkamppeter> infinity, slangasek, the package in which the symlinks where before was lsb-core, coming from the lsb source package.
[20:26] <slangasek> we're aware
[20:26] <Pharaoh_Atem> nacc: I'm not quite sure, but I think all of these debian package build tools hate me :/
[20:27] <slangasek> nacc: why does yubikey-ksm call phpenmod in its postinst for a module it does not ship?
[20:27] <slangasek> nacc: (not a regression, not blocking the upload, but ugh)
[20:31] <slangasek> nacc: mv_conffile, same thing for wikidiff2
[20:42] <nacc> slangasek: oh sorry, i rusehd that!
[20:42] <nacc> slangasek: will post updated shortly
[20:50] <tjaalton> should unattended updates show install progress on shutdown?
[20:55] <nacc> slangasek: updated in both
[21:13] <slangasek> nacc: 'tcpdf' - that's the Transmission Control Protocolortable Document Format, right?
[21:13] <rbasak> slangasek: I'm not sure what you mean by "Robie (the uploader of the version (re?)introducing the recommends" in bug 801244 but I think that's moot now?
[21:13] <rbasak> AFAICT, I've never uploaded a vblade-persist.
[21:13] <mwhudson> anyone know what "main::scan_file() called too early to check prototype at /usr/bin/aclocal-1.11 line 644." means?
[21:13] <mwhudson> https://launchpadlibrarian.net/251176532/buildlog_ubuntu-xenial-amd64.google-perftools_2.4-0ubuntu4_BUILDING.txt.gz
[21:13] <slangasek> rbasak: you sponsored the upload that reintroduced the recommends: on vblade-persist from vblade
[21:13] <rbasak> Ah
[21:14] <mwhudson> is it code for running autoreconf or something?
[21:15] <rbasak> slangasek: ah yes, I remember now. Sorry! Yeah cpaelzer is right. That was to bring vblade closer to sync with Debian so we can stop caring for it in universe next cycle. So no MIR any more so no further action I think.
[21:15] <rbasak> (the conffile move needs a delta but that can go > Xenial)
[21:15] <slangasek> rbasak: did vblade get uploaded to drop the MIR?  (I haven't looked at any of this, was just poking the bug via component-mismatches)
[21:16] <rbasak> slangasek: I wasn't aware of the MIR at the time. It was in MoM as needing a merge. We looked, decided we didn't want to maintain a delta, so merged it dropping most of the delta for a graceful removal next cycle.
[21:17] <slangasek> rbasak: ok, you can't just drop the delta.  It's a component-mismatch; packages in main need to not recommend packages in universe
[21:18] <slangasek> it was confusing to have an MIR bug still around from before vblade was promoted, but this still needs to be dealt with
[21:18] <rbasak> slangasek: sorry, I missed that.
[21:19] <slangasek> rbasak: my recommendation, given the goal of minimizing delta, is to change that Recommends back to a Suggests in vblade; the alternative is to try to make vblade-persist work without ruinit
[21:19] <slangasek> sorry, "runit" ;P
[21:19] <rbasak> slangasek: I think we might be able to drop vblade from server-ship and get it into universe.
[21:19] <slangasek> rbasak: also wfm :)
[21:19] <slangasek> but that's a server product decision I guess, --> SEP
[21:21] <nacc> slangasek: heh, i who knows why they named it that way; it appears to be a fork of fpdf, also their website claims "Started in 2002, TCPDF is now one of the world's most active Open Source projects"
[21:21] <slangasek> radioactive? bioactive?
[21:28] <nacc> Pharaoh_Atem: can you help me check something; if you install php-pecl-http and neable it, do you see a complaint if you just run `php`?
[21:28] <Pharaoh_Atem> nacc: how do I enable it?
[21:29] <rbasak> slangasek: SEP?
[21:29] <nacc> Pharaoh_Atem: actually, i think it will be enabled on install
[21:29] <slangasek> rbasak: "somebody else's problem" ;)
[21:29] <nacc> Pharaoh_Atem: alternatively, phpenmod http?
[21:29] <rbasak> slangasek: ah :)
[21:29] <rbasak> slangasek: I'll take care of it
[21:29] <Pharaoh_Atem> nacc: is this what you want to see? PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/http.so' - /usr/lib/php/20151012/http.so: undefined symbol: php_resource_factory_init in Unknown on line 0
[21:29] <nacc> yeah
[21:29] <nacc> it seems like something is not putting in the lib dependency
[21:29] <nacc> that symbol is from raphf
[21:30] <nacc> but `ldd` indicates http.so doesn't load raphf.so, which seems like a mistake
[21:30] <nacc> trying to figure out what's mssing
[21:31] <sarnold> see also dlopen()
[21:32] <slangasek> raphf.so, implies it's not a library but a plugin of its own; so linking to it is likely wrong
[21:32] <Pharaoh_Atem> yeah
[21:32] <nacc> sarnold: true; but not called in this library, and not linked against libdl
[21:32] <Pharaoh_Atem> which means it's a runtime dependency
[21:32] <slangasek> http.so probably assumes this symbol is resolvable through the parent
[21:32] <slangasek> by raphf.so being loaded first
[21:32] <nacc> slangasek: so maybe it's an ordering thing
[21:32] <slangasek> could be
[21:32] <nacc> istr something about the order of names does matter
[21:32] <nacc> let me see if i can find it
[21:33] <Pharaoh_Atem> is it being linked with -Wl,--no-undefined?
[21:33] <slangasek> could also be a scoping issue with the options php itself passes to dlopen()
[21:33] <slangasek> Pharaoh_Atem: that would fail at build time if it were
[21:33] <Pharaoh_Atem> right
[21:34] <rbasak> slangasek: I've passed to kirkland/jgrimm for an ack. If they say yes, I'll unseed it.
[21:35] <Pharaoh_Atem> so.... this just happened? http://fpaste.org/349595/59805700/
[21:35] <Pharaoh_Atem> anyone know why usb-modeswitch 2.3.0 isn't available?
[21:35] <slangasek> Pharaoh_Atem: because don't try to dist-upgrade to -proposed
[21:36] <Pharaoh_Atem> slangasek: I've been living on -proposed for over two months because php things :/
[21:36] <slangasek> Pharaoh_Atem: xenial-proposed is not for human consumption
[21:36] <Pharaoh_Atem> I guess I'm not human :)
[21:37] <slangasek> you should be doing that in a chroot, not on a desktop root
[21:37] <jgrimm> rbasak, ack from me (and kirkland gave an email ack to that on Feb 4, as well as, for munin)
[21:37] <Pharaoh_Atem> slangasek: eh, it's a VM
[21:37] <kirkland> rbasak: vblade?
[21:37] <kirkland> rbasak: ack, +1 please drop from main.  vblade (aoe) was needed for eucalyptus, many moons ago
[21:38] <jgrimm> virtual AoE blade emulator
[21:38] <jgrimm> yep
[21:42] <rbasak> jgrimm, kirkland: thanks. Seed changed.
[21:42] <jgrimm> rbasak, munin too?
[21:45] <slangasek> nacc: wikidiff2, zend-framework, please provide incremental debdiffs since the previous are already uploaded
[21:47] <rbasak> jgrimm: no but done now, thanks.
[21:47] <jgrimm> rbasak, thanks!
[21:48] <slangasek> nacc: are packages with build-deps but no runtime deps on php5 on your list?  (e.g. jscribble)
[21:50] <nacc> slangasek: hrm, I thought I did ?
[21:50] <nacc> slangasek: and no, not build-deps yet, that is next on my list
[21:50] <nacc> slangasek: i just checked both bugs and the last attachment in each is an incremental debdiff?
[21:51] <slangasek> nacc: hurrr ok apparently I didn't read it right :)
[21:52] <slangasek> nacc: core-dev endorsement: "he writes correct code that I subsequently don't read; give him upload rights"
[21:52] <nacc> slangasek: heh
[21:54] <rbasak> pitti: is there an easy way without cgmanager to get myself a shell that is running in its own cgroup?
[21:54] <rbasak> I asked hallyn, he suggested I ask you :)
[21:54] <slangasek> nacc: wrt php-mongo,php-horde-mongo - there are an awful lot of packages depending on php-horde-mongo, all of which will be broken by this; are we ok with that?
[21:55] <hallyn> rbasak: which controllers are you intersted in?
[21:55] <slangasek> nacc: oh - nope, these are all recommends, ignore me
[21:55] <nacc> slangasek: right, it should all be recommends
[21:55] <nacc> i should have noted that, but did see that before suggesting its removal
[21:55] <rbasak> hallyn: I want to limit CPU and memory. I'm told that limiting memory will stop my entire cache from being dropped if I do something big in there.
[21:56] <rbasak> Ideally I want "run-in-cgroup --memory=X --cpu=X /bin/bash"
[21:56] <rbasak> (unprivileged)
[21:56] <hallyn> you want cpu not cpuset right?
[21:56] <rbasak> I'm not sure.
[21:57] <hallyn> anyway memory you can do with no privilege with or without cgm;  cpu you'd need to edit /etc/pam.d/common-session to add ",cpu" to the libpam-cgfs line
[21:57] <hallyn> so in the meantime i'd recommend yeah use cgm.  I think we should come up wiht a good systemd based answer and put that into the server guide
[21:58] <rbasak> hallyn: OK, thanks
[21:58]  * rbasak reads up
[21:58] <nacc> Pharaoh_Atem: slangasek: may have found the pecl-http issue, typo -- checking to see if it fixes it
[22:00] <infinity> rbasak: Who's taking ownership of evaluating the removal of the block-proposed tag from https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1473691 ?
[22:00] <rbasak> jgrimm: ^^
[22:00] <rbasak> Or rharper maybe?
[22:00] <infinity> rbasak: We're probably approaching a point where we're not going to find any more bugs without inflicting it on users.
[22:00] <rbasak> I've seen activity, but I'm not sure who's holding the baton right now.
[22:01] <rharper> last I saw was a 1ubuntu4 upload with some fixes from slangasek on the maint scripts;
[22:01] <infinity> And another from me, yes.
[22:01] <rharper> I can give the proposed package a test; but since it was maint stuff, I don't it to modify the functionality w.r.t universe packages we were testing
[22:02] <rharper> rbasak: I didn't get any time to test additional rdepends on squid3 from universe yet;
[22:02] <rharper> we did want to maybe see about maas and squid3
[22:02] <infinity> Well, we're running out of time to "see about" anything.
[22:02] <rharper> I don't see any reason to hold back
[22:03] <rharper> better to get the hurt ASAP
[22:03] <rbasak> rharper: any known issues with what is in -proposed currently?
[22:03] <infinity> That was sort of my thinking.
[22:03] <rbasak> Sorry, I haven't really been following along.
[22:03] <rharper> rbasak: none that I'm aware of
[22:03] <infinity> I'm sure we missed some bugs, but I've fixed the ones *I* run into.
[22:03] <infinity> So, I need other people to find more. :P
[22:03] <rbasak> OK, let's drop the tag as I don't hear any objections.
[22:03]  * rharper nods
[22:03] <slangasek> unless we want to risk keeping squid3 out-of-date for another LTS, we should let 'er rip
[22:03] <rharper> heh
[22:03] <rharper> not after all of this trouble
[22:03] <infinity> And someone might want to merge the new upstream after we let this one through.
[22:03] <infinity> Because more bugs.
[22:03] <rharper> 3.5.15 (new stable IIRC)
[22:04] <slangasek> yes there may be some knock-on effects, but we need to find them before we can sort them out, and at this point we need it in xenial before we're likely to find them
[22:04] <rharper> yep
[22:04] <rbasak> I saw activity on bug 1448149. I think that probably doesn't affect Xenial?
[22:04]  * infinity removes the tag.
[22:04] <rbasak> (in fact it would be fixed by Xenial?)
[22:04] <rharper> rbasak: yes
[22:04] <rharper> fixed
[22:04] <rbasak> Lovely. Thanks!
[22:04] <rharper> at least with the trivial test case kick1nz setup
[22:09] <Pharaoh_Atem> nacc: cool
[22:10] <nacc> Pharaoh_Atem: nm, didnt' fix it (but is a real bugfix :)
[22:11] <slangasek> nacc: netmrg is dep-wait on all archs
[22:11] <slangasek> looks like an outdated build-dep on libmysqlclient15-dev?
[22:12] <rbasak> slangasek: I have that on my list to fix.
[22:12] <nacc> slangasek: i believe it's due to the pending migration
[22:12] <rbasak> Right
[22:12] <slangasek> what's pending that's causing it to dep-wait?
[22:13] <rbasak> Is https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mysql-5.7/+sourcepub/6249018/+listing-archive-extra helpful?
[22:13] <rbasak> That's our test build.
[22:13] <jgrimm> rharper, do you know if maas got any testing done on squid3 proposed?  they said they'd have to make changes in maas.
[22:13] <slangasek> $ apt-cache showpkg libmysqlclient15-dev
[22:13] <slangasek> N: Unable to locate package libmysqlclient15-dev
[22:13] <slangasek> $
[22:13] <nacc> slangasek: sorry, i mean the deps need to be updated, but that the sql migration is going to fix it (or needs to)
[22:13] <rbasak> slangasek: s/libmysqlclient15-dev/libmysqlclient-dev/. They're equivalent. We dropped the virtual package from MySQL 5.7 that's in proposed.
[22:14] <slangasek> nacc, rbasak: right, so netmgr should get reuploaded with the fixed build-dep and afaics that doesn't need to wait for anything else
[22:14] <slangasek> (then once built, will block in -proposed as part of the mysql-5.7 transition - but should get done sooner than late so as to not itself block mysql-5.7?)
[22:14] <nacc> slangasek: good point; rbasak want me to submit the debdiff?
[22:15] <jgrimm> roaksoax,  squid3 block-proposed just removed, so it'll migrate assuming no failures.
[22:15] <rbasak> No need, I have it local.
[22:15] <rbasak> (already done, just not uploaded)
[22:15] <nacc> rbasak: ok, thanks
[22:15] <slangasek> nacc: and is lasso on your todo list?
[22:15] <infinity> jgrimm: Already has migrated, in fact.
[22:15] <rbasak> slangasek: it's in my queue of uploads for the transition.
[22:16] <jgrimm> infinity, ah..
[22:16] <rbasak> (netmrg that is)
[22:16] <rbasak> slangasek: I was holding back in case we decided to not do the transition.
[22:16] <infinity> rbasak: I think we're past the point of turning back.
[22:16] <rbasak> I was going to talk to infinity about it.
[22:17] <infinity> rbasak: Worst case scenario, we drop mysql-proxy and myodbc, and the rest of the world looked okay, right?
[22:17] <rbasak> infinity: OK. I'll begin tomorrow morning :)
[22:17] <rbasak> infinity: AFAICT, yes.
[22:17] <infinity> rbasak: Yeah.  Let's do it, then.
[22:17] <slangasek> rbasak: ah, k
[22:17] <nacc> slangasek: urgh, that doesn't show up in `reverse-depends` ... how strange
[22:17] <nacc> slangasek: oh wait, it will
[22:17] <rbasak> infinity: ack
[22:17] <infinity> rbasak: I can demote those to -proposed when the rest is looking alright, and we can outright remove them from the archive when we're sure that's the right thing to do.
[22:17] <slangasek> rbasak, infinity: oh, er, myodbc is already broken in the archive, if you didn't know
[22:17] <nacc> slangasek: yes, on my list
[22:17] <infinity> slangasek: It is?
[22:18] <slangasek> infinity: yes, it built and then had undefined symbols and I decided I had better things to do with my life
[22:18] <infinity> slangasek: Awesome.
[22:18] <slangasek> https://bugs.launchpad.net/ubuntu/+source/myodbc/+bug/1010044
[22:18] <rbasak> slangasek: upstream are working on fixing up myodbc for us. We can land that late I guess, since there's no risk of regression then.
[22:18] <infinity> slangasek: File a removal in Debian and yank it from Ubuntu and wash your hands of it? :P
[22:18] <rbasak> Skuggen: ^^ FYI.
[22:18] <slangasek> infinity: that says it's been broken for 4 years, hth
[22:19] <rbasak> slangasek: well that certainly makes life easier. Thanks :)
[22:19] <infinity> slangasek: I feel a little less bad about some of my underloved Debian packages now.  At least mine run.
[22:20] <slangasek> infinity: trade you upstreams
[22:20] <infinity> slangasek: Though, I suppose yours is quite secure.
[22:20] <slangasek> nacc: ok.  How about libkolab? Its runtime dep is on phpapi-20131226, not on php5-*
[22:20] <slangasek> infinity: unbreakably secure
[22:21] <nacc> slangasek: yes, it shows up due the build-dep
[22:21] <slangasek> nacc: ok
[22:21] <nacc> slangasek: i haven't fixed any build-deps on src:php5
[22:21] <nacc> or very few
[22:21] <slangasek> nacc: fwiw here's my current watchlist: (grep-dctrl -n -sSource:Package -FDepends php5 -o -FDepends phpapi-20131226 /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*binary-amd64_Packages; grep-dctrl -n -sPackage -FBuild-Depends,Build-Depends-Indep php5 /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*Sources)   | sort -u
[22:21] <infinity> Huh.  How is it 16:21 already?  I guess I should go find breakfast or lunch or whatever.
[22:21] <nacc> slangasek: ok, thanks ... that's handy to have
[22:22] <Pharaoh_Atem> the day just flies by, doesn't it?
[22:22] <slangasek> nacc: NB that only looks at release pocket, not -proposed, so season to taste
[22:22] <nacc> slangasek: right
[22:30] <slangasek> pitti: wow, watershed demoted!