[04:30] <alkisg> arges, good morning, may I ping you to put the SRU'ed x11-utils (LP: #1463663) to precise-updates? I've done the verification-done step. Thank you.
[04:50] <pitti> Good morning
[04:51] <pitti> smoser: oh, please do ping about these, I need to know what's blocking us
[04:57] <pitti> doko: I usually override them after checking, but I didn't see it yet in the queue
[04:58] <pitti> (doing in some minutes)
[05:57] <pitti> doko: landed now
[06:43] <dholbach> good morning
[07:59] <jamespage> if there are any archive-admins around I have a few binary only main promotions I need to unblock FTBFS in proposed:
[07:59] <jamespage> python-oslo.middleware python3-oslo.middleware python3-oslo.concurrency python-oslo.config python-oslo.vmware
[08:00] <infinity> jamespage: On it.
[08:00] <jamespage> infinity, thankyou
[08:00] <jamespage> infinity, trying to unpick all of the oslo reshuffling :-)
[08:10] <infinity> jamespage: Yeah, it's been a pain.
[08:27] <lifeless> jamespage: pip it all up :)
[08:29] <infinity> lifeless: Not sure how pip helps here.
[08:30] <lifeless> infinity: it doesn't
[08:30] <lifeless> I was trolling
[08:31] <infinity> lifeless: And you used to be such a nice boy.
[08:31] <lifeless> infinity: your memory is failing in your old age :)
[08:32] <jamespage> lifeless, lol
[08:32] <infinity> lifeless: I prefer to think of it not as failure, but rather the success of only remembering the good times.
[08:32] <infinity> lifeless: Which, for you, is basically just your beard.
[08:32] <lifeless> infinity: :) nice
[08:33] <lifeless> infinity: I see you've joined the grey club
[08:33] <lifeless> infinity: I managed to convince Lynne to stop plucking mine.
[08:33] <lifeless> so I'm not bald
[08:34] <infinity> It's the little victories.
[08:34] <infinity> lifeless: And yes, I'm greying a tad, though it's pretty slow going, given my age, so I can't complain too much.
[08:35] <infinity> lifeless: My brother was about 50/50 by this age, and my mother was white in her early 30s.
[08:35] <lifeless> wow
[08:35] <lifeless> genetics huh
[08:35] <lifeless> [as in, you beat the odds in your family]
[08:38] <infinity> lifeless: My brother's also 6 inches taller, so I think he's still winning. :P
[08:39] <lifeless> infinity: I could make a terrible joke here.
[08:39] <infinity> lifeless: Code.  Of.  Conduct.
[08:46] <infinity> jamespage: Fixed up python3-tempest-lib too, looks like a bunch of things were waiting on that.
[08:47] <jamespage> infinity, quite likely - we've got alot of py3 enablement coming in from work in Debian
[08:47] <jamespage> infinity, component-mismatches-proposed is just confusing me right now - it looks wrong
[08:47] <infinity> jamespage: Needs another couple of publisher cycles to sort that, then keystoneclient should be buildable, which a few other bits are waiting on.
[08:47] <infinity> jamespage: And yeah, c-m is a mess.  I need to try to attack it a bit tomorrow and see if I can unmess it.
[08:48] <infinity> jamespage: I think it's getting confused by the sheer volume of breakage we brought in this cycle.
[08:48] <jamespage> infinity, well I fixed junit4 two days ago, which was causing the maven explosion - which should have removed alot
[08:48] <jamespage> but that is still showing for some reason
[08:48] <infinity> jamespage: Ahh, nice.  Thanks.  Every time maven tries to promote, the world goes to crap.
[08:49] <infinity> Erk.  And someone made ltsp depend on MATE, which is blowing up the world too.
[08:49] <jamespage> lol
[08:50] <infinity> stgraber: ltsp depends on MATE now?  Halp.  Is that intentional?  Is it time to drop ltsp out of main?
[08:51] <infinity> stgraber: Or do we just need to swap the gnome-session/mate-desktop-env deps?
[09:16] <rbasak> infinity: hey. Can we chat about some dpdk packaging that smb is doing? Involving weird upstream arrangements about sonames, sovers, optimisation levels and how to package it all.
[09:16] <rbasak> infinity: I think I have an idea about how we should be packaging it but I'd like to make sure what I'm suggesting is sane and there isn't a better way.
[09:17] <rbasak> infinity: can we mumble with smb later today please?
[09:17] <smb> rbasak, infinity, slight caveat today is my EOD at 1500UTC
[09:18] <rbasak> I'm free from around 1300 to 1500 UTC
[09:18] <rbasak> I have to pop out for an eye test in an hour or so. Not sure exactly how long it'll take or when I'll be back.
[09:18] <rbasak> (by 1300 UTC I imagine)
[09:19] <infinity> rbasak: Hrm.  1300 UTC is 7am for me.  Not positive I'll be alive, but maaaaybe?
[09:20] <infinity> rbasak: "Weird upstream arrangements about sonames" scares me a bit, though. :P
[09:20] <rbasak> infinity, smb: how about I ping when I'm back and we'll see if infinity is awake? Will probably be before 1300 - just not sure exactly when.
[09:20] <smb> rbasak, Would work for me though there seems to be a higher chance of awakeness when planning for 1400 utc
[09:22] <infinity> jamespage: Aaaand, now we get to python3-requests-mock.  Irksome that c-m is breaking right now, or it would have told me all of this in one shot. :/
[09:22] <smb> infinity, could rather be phrased "weird upstream ideas about ..."
[09:22] <infinity> jamespage: Another round, and away we go.
[09:22] <rbasak> smb: infinity's awakeness? I thought that went down from 1300 to 1400, rather than up?
[09:22] <jamespage> infinity, yeah - feel kinda blind without that report :-)
[09:23] <infinity> rbasak: I'm more likely to be awake at 8am than 7am.  Though both seem slim, given it's currently 3:22.
[09:23] <rbasak> Oh, OK.
[09:23] <jamespage> rbasak, you would enjoy the use of unversioned so names in liberasurecode :-)
[09:23] <rbasak> Well, I'll ping, and you can catch it when you're up, and we'll see?
[09:23] <infinity> rbasak: We could chat nowish/soonish instead.
[09:23] <rbasak> infinity, smb: that works too. Mumble now?
[09:24] <smb> rbasak, not that I would even speculate about thinking to understand the awake/sleep cycles of infinity
[09:24] <infinity> rbasak: For some value of "now" that allows me to grab a bucket of ice water and a smoke first.
[09:24] <smb> rbasak, Sure
[09:24] <infinity> So, in like 5m.
[09:24] <rbasak> OK. See you on mumble in 5m.
[09:25] <mitya57> infinity, stgraber: I think ltsp should still work fine with GNOME (Flashback), but that's also in universe…
[09:26] <infinity> mitya57: It's entirely possible that ltsp-in-main is just an artifact of "all flavours used to be in main, and edubuntu seed ltsp", and it never dropped out because it was never a problem before.  Perhaps worth revisiting.
[09:26] <infinity> s/seed/seeds/
[09:26] <mitya57> Yes
[09:26] <infinity> Well, I guess it would be in an Ubuntu seed, not an edubuntu seed, but for edubuntuish reasons.
[09:39] <tseliot> infinity: can you check if mesa-lts-vivid is available in trusty-proposed on ppc64el, please?
[09:58] <wgrant> tseliot: https://launchpad.net/ubuntu/trusty/ppc64el/libgl1-mesa-dri-lts-vivid?
[09:59] <tseliot> wgrant: right, I saw that, but one of my contacts showed me that the specific package couldn't be found
[09:59] <wgrant> tseliot: Which specific package?
[09:59] <wgrant> mesa-lts-vivid isn't a binary package.
[10:00] <tseliot> wgrant: sorry, it's libegl1-mesa-drivers-lts-vivid
[10:01] <tseliot> or is it a transitional package?
[10:02] <wgrant> tseliot: That doesn't exist on any architecture.
[10:02] <wgrant> https://launchpadlibrarian.net/206323600/mesa-lts-vivid_10.5.2-0ubuntu1~trusty1_i386.changes
[10:03] <tseliot> wgrant: the instructions here (still for lts-utopic though) mention this: apt-get install --install-recommends linux-generic-lts-utopic xserver-xorg-lts-utopic libgl1-mesa-glx-lts-utopic libegl1-mesa-drivers-lts-utopic
[10:04] <tseliot> replace utopic with vivid, and that should work, except libegl1-mesa-drivers-lts-vivid is not available
[10:04] <tseliot> https://wiki.ubuntu.com/Kernel/LTSEnablementStack
[10:04] <wgrant> That sounds to me like the documentation needs to be updated.
[10:05] <tseliot> tjaalton: ^^
[10:05] <wgrant> libegl1-mesa-drivers is a transitional package.
[10:05] <tseliot> right, let's see what Timo says about it
[10:07] <tjaalton> desktop packages on ppc64el?
[10:07] <tseliot> ah, so there aren't any then
[10:07] <wgrant> Is the ppc64elness relevant?
[10:07] <tjaalton> i mean, who'd need to install those :)
[10:07] <tjaalton> no
[10:07] <tjaalton> the data is old
[10:07] <wgrant> I don't think there's anything arch-specific here, apart from the q
[10:08] <tjaalton> thing is that vivid stack isn't in updates yet
[10:08] <tseliot> -proposed is ok for now
[10:08] <tjaalton> so just drop the packages that don't exist from the apt-get line
[10:09] <tseliot> ok, thanks
[10:09] <tjaalton> that page won't get updated before .3 is released I think
[10:10] <tseliot> yes, and that's reasonable
[12:44] <micahg> hi Laney, I saw you working on libproj transition, here's the story with that: postgis seems to be a false positive on the ben tracker (migration seems happy enough with it), zygrib has issues with qwt 6.1.1 even with 7.0, mapnik needs its own transition and I think that we should just copy back the older version since the transition seems involved (discussed this one with infinity, to be done only once the rest of the transition is ready), and
[12:44] <micahg>  pyspatialite has its own mini transition as well, but that one might be easily solvable
[12:45] <micahg> I saw the libwps got entangled and tried to dig a little into zygrib last night without success
[12:48] <Laney> hi micahg
[12:49] <micahg> hi, I'm only here for a few minutes
[12:50] <Laney> I saw that postgis had a dep on libproj0
[12:50] <Laney> didn't get much further than seeing that zygrib doesn't build
[12:50] <micahg> orly?  that's very weird, I rebuilt it twice
[12:50] <Laney> ya, look in the build log
[12:51] <micahg> and confirmed in my local build logs (and I thought on LP as well) that it was libproj9
[12:52] <Laney> do you have a path out of the jungle?
[12:52] <Laney> I mainly started caring when it got involved with poppler and wps
[12:54] <micahg> at this point, I was planning to fix spatialite, do the switcharoo with mapnik and probably remove the binaries for zygrib  unless I could find a fix soonish
[12:54] <micahg> that should release everything
[12:59] <Laney> micahg: I don't see the spatialite thing, seems happy enough to go in from what I can see
[12:59] <micahg> tilelite?
[13:00] <micahg> hrm
[13:00] <micahg> oh, haha, that's part of mapnik transition
[13:01] <micahg> yay, so maybe just remove binaries for zygrib + copy back the rebuild I did with the old mapnik
[13:03] <ari-tczew> cyphermox: hi, have you got any plans for merge of network-manager in wily cycle?
[13:18] <ari-tczew> mvo: I just needed to stole your merge of ust. It's needed by another packages in universe. bug 1468345
[13:25] <mvo> ari-tczew: thanks!
[13:28] <ari-tczew> You're welcome.
[13:53] <cyphermox> ari-tczew: I'd like to, but I'm busy with other stuff... and I think awe and others might want us to wait and test that phone things aren't broken by merging 1.0 or later.
[13:54] <ogra_> well, wily is already broken on the phone since the last upload it seems (not sure if NM is at fault, but i think that was the only non siloed upload yet)
[13:54] <awe> cyphermox, I have a standup in a few minutes, but at some point we should discuss plans for moving to 1.x
[13:54] <awe> ogra_, indeed... because we're not doing *any* testing on wily
[13:54] <cyphermox> awe: let's do that tomorrow or something
[13:54] <awe> cyphermox, ack
[13:55] <ogra_> awe, well, uploads should be siloed and self-tested ...
[13:55] <ogra_> but yeah, there is no further QA
[16:53] <jibel> ogra_, awe it's true that there is very little manual QA during the release cycle of the devel release but there are integration test executed automatically when the package is uploaded. In the case of network-manager tests have been failing for nearly 2 weeks. Maybe it's the place to start https://jenkins.qa.ubuntu.com/view/Wily/view/AutoPkgTest/job/wily-adt-network-manager/
[16:54] <ogra_> jibel, well, the last two NM uploads were simple dputs to the archive
[16:55] <awe> so far... none of my NM changes for the phone have landed in wily
[16:55] <ogra_> no idea if either of them have been tested at all ( i assume the first one hasnt because that was the initial sync fromm vivid)
[16:55] <awe> cyphermox and I will work this out
[16:55] <awe> but I've done *zero* testing on wily
[16:55] <awe> to-date
[16:55] <awe> the ofono changes land in both places from a single tree
[16:55] <awe> NM, not so much
[16:56] <ogra_> awe, well, and you shouldnt invest to much into it
[16:56] <awe> I haven't
[16:56] <ogra_> a simple self test and langind through a silo should be enough
[16:56] <ogra_> i suspect neither happened for the two versions wily has
[16:56] <awe> yet now there's an open bug about mobile-data being broken on wily, and some very bizarre results.  I suspect the device tarballs for mako aren't in very good shape
[16:57] <ogra_> (actually the first one wasnt the sync i thought, it was a security fix in the ofono plugin)
[16:57] <awe> also, it only looks like there's been one update
[16:57] <awe> 4ubuntu16
[16:58] <ogra_> 0.9.10.0-4ubuntu15.1
[16:58] <ogra_> thats the first one i see on -changes
[16:58] <ogra_> synced from vivid-security
[16:58] <awe> ok
[16:59] <cyphermox> Tomorrow we can make sure your nm code got landed in the packaging branch and do the testing in a silo, it's not complicated
[16:59] <awe> 16 has the changes for routing which pmcgowan had reported broken?
[16:59] <ogra_> bug 1436330
[16:59] <ogra_> thats the bug mentioned in the changelog
[16:59] <cyphermox> Routing changes in wily don't break the phone, but they don't completely fix that bug either
[17:00] <awe> no pmcgowan and mdeslaur both reported that the change didn't fix the problem for them on desktop
[17:00] <Laney> Is that meant to be in wily?
[17:00] <awe> so this probably shouldn't have landed in wily
[17:00] <cyphermox> Right, that's what I'm saying
[17:00] <Laney> because it is definitely not fixed if so :)
[17:00] <awe> +1
[17:01] <cyphermox> The fix isn't complete, but it does improve a bit
[17:01] <Laney> I have to fettle when I want to go to/from wired
[17:01] <cyphermox> Metric for network routes is correct now, but it's missing it for the default route
[17:02] <awe> could you update the bug?
[17:02] <Laney> awe: are you doing something with https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1445134 btw?
[17:02] <Laney> I see the assignee ;)
[17:02] <cyphermox> I'm pretty sure it already was updated
[17:03] <awe> it was marked FixReleased, as an upload was done and it's in vivid-proposed, and then a bunch of folks reported it didn't fix the problem
[17:03] <awe> so maybe you could add a note about what remains to be fixed?
[17:04] <cyphermox> Well I won't be able to do that now, I'm not home, it's a national holiday so I'm away and using my phone
[17:04] <awe> Laney, I will be looking at the scanning bug, but I have one more phone bug stacked up ahead of it.   That said, I may try and do some testing this week
[17:04] <cyphermox> Awe: could you do the update?
[17:04] <awe> Laney, what device are you seeing this on?
[17:04] <Laney> my laptop, assuming it is the same bug and not another one with same symptoms
[17:05] <Laney> I posted what happend in comment #4
[17:05] <Laney> got to go now, sorry
[17:05] <awe> Laney, ok.  I'm not sure if it's the same or not.  I'll try and take a look this week
[17:05] <awe> Laney, np
[17:06] <awe> cyphermox, I don't fully understand the bug and/or how it was patched.  So you're saying what remain is to backport additional logic from 1.x that sets the route metric for the default routes?
[17:06] <Laney> if you can create an AP e.g with an android phone then it should be easy to recreate what happened to me
[17:06] <Laney> see you
[17:06] <awe> yea, I think I should be able to handle that Laney!  ;)-
[17:06] <cyphermox> Awe: yes. Backport being an oversimplification of the work that needs to be done
[17:07] <awe> sure, but the gist of it is that the metrics aren't being set for the default routes
[17:07] <awe> I'll update it
[17:07] <awe> are you still on vacation?
[17:08] <cyphermox> No, but off today
[17:08] <awe> k
[17:08] <awe> I have to head out to grab some lunch now, but will update it when I get back
[17:08] <cyphermox> If I was on vacation I wouldn't touch irc at all :-)
[17:08] <awe> good
[17:08] <awe> now enjoy the rest of your day off, and I'll catch up with you tomorrow
[17:09] <cyphermox> So let's take care of this tomorrow we should be able to completely fix this all
[18:03] <infinity> stgraber: *nudge*
[18:04] <infinity> stgraber: Did you see my whining about ltsp vs main vs mate last night?
[18:08] <stgraber> infinity: yeah, ltsp shouldn't depend on mate, let me take a look
[18:09] <highvoltage> that's really odd
[18:09] <ogra_> yeah
[18:12] <infinity> stgraber: It's in your merge.
[18:12] <infinity> -  gnome-session | x-session-manager | x-window-manager,
[18:12] <infinity> +  mate-desktop-environment | gnome-session | x-session-manager | x-window-manager,
[18:12] <infinity> (in two spots)
[18:13] <infinity> stgraber: Wasn't sure if you wanted to drop that, or change the order, or just move ltsp out of main and stay closer in sync with Debian.
[18:23] <stgraber> infinity: we have some magic in debian/control in Debian to spit out different recommends/depends on Ubuntu than on Debian, I'll bug vagrantc to get this resolved
[18:26] <stgraber> infinity: that's just spamming c-m right, nothing more urgent than that? (otherwise I can just cowboy the fix in Ubuntu and then merge again whenever vagrantc fixes it in Debian)
[18:27] <infinity> stgraber: Yeah, just a lot of spam.
[20:17] <infinity> stgraber: Do you have any insight into the lxc autopkgtest regression?
[20:18] <infinity> stgraber: Is that just a "we need to fix network access" thing, or something else?
[20:18] <stgraber> infinity: my guess is that it's network related, yes
[20:20] <infinity> cyphermox: How about you?  Any ideas on the network-manager adt regression?
[20:26] <cyphermox> infinity: I think there has been a change in something on the system running the tests, if it's still that wpa error
[20:26] <infinity> cyphermox: It's that, yes.
[20:27] <infinity> cyphermox: So, if you're sure it's a testbed problem, I'll let the world skip it for now, and we can sort it with pitti.
[20:27] <cyphermox> Yeah, feel free to ignore it I'd say.
[20:27] <cyphermox> Nm hasn't exploded here, in any case
[20:27] <infinity> cyphermox: Well, I assume you also don't run proposed.
[20:28] <cyphermox> No, but I'm not sure what would break things that badly.
[20:28] <cyphermox> Is there a new wpa in proposed?
[20:28] <infinity> cyphermox: New wpa for security issues, but that came a day after the test started failing.
[20:29] <infinity> cyphermox: The only obvious change I can see around when it started failing was a dnsmasq rebuild against a newer libnettle.
[20:29] <infinity> cyphermox: If dnsmasq exploding could cause those sorts of errors, that could be it.  If not, then it's probably the testbed.
[20:29] <cyphermox> That wouldn't break wifi
[20:29]  * infinity nods.
[20:31] <cyphermox> It seemed more like some hostapd issue with the hardware on the system, so maybe the kernel / hwsim module changed enough to break things, or there really is a wifi device on the test system now and things are confused
[20:32] <cyphermox> infinity: I already have other things for NM in to-do for tomorrow, so I will debug this too
[20:32] <infinity> stgraber: Okay, from looking at your tests and where this appears to time out, I concur it's probably network sadness.  Would be nice if your tests failed more verbosely, mind you. :)
[20:33] <infinity> stgraber: When pitti moves all of this, I think I can get the right holes punched to let these tests work instead of neutering your testsuite, FWIW.
[20:33] <stgraber> infinity: typically it's gpg getting stuck on no-network and it never seems to timeout for some reason
[20:34] <infinity> stgraber: Might be worth a skeleton "test-host-port" function that you can reuse to bang every host/port combo you intend to abuse and die early if they're broken with a useful error.
[20:34] <stgraber> indeed
[20:38] <infinity> stgraber: Alright, I'm going to badtest lxc for now.  It's a lie, but it's the best lie I can come up with.
[20:39] <infinity> cyphermox: Ditto for n-m.
[20:40] <cyphermox> OK
[22:14] <Unit193> cjwatson: Sorry to bother again, but got any estimate on the newer openssh entering Debian/Ubuntu?
[22:18] <cjwatson> Unit193: you mean 6.8p1?
[22:19] <Unit193> Yes sir.
[22:20] <cjwatson> Unit193: I'm in the middle of the very very complicated rebase of the gssapi patch
[22:20] <Unit193> Oi, sorry about that. :3
[22:21] <cjwatson> Unit193: once that's done it should be straightforward, but I don't yet have a time estimate; I'm on holiday this weekend so it won't be then
[22:22] <Unit193> cjwatson: Sure that's fine, and understandable on both accounts.
[22:23] <Unit193> Thanks for the information!