[10:27] <xnox> interesting, who uploaded that =)
[11:25] <zequence> Would anyone like to help sponsor this package, please? Bug: 946591
[11:25] <ubot2`> Launchpad bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
[14:14] <zequence> infinity: Not having much luck finding a sponsor yet. The source should be easy to review. Most of the changes I've done are naming, and removal of files I don't need (just now, anyway). bug: 946591
[14:14] <ubot2`> Launchpad bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
[14:28] <zequence> infinity: What I just wrote makes sense if you know it's a fork of edubuntu-live, but that of course becomes apparent once you have a look at the source
[16:58] <rbasak> I'm still working on fixing zeroc-ice (universe), which is the last package holding the php5 transition in trusty-proposed. It's got stuff hardcoded, hence the delay, and a test build takes forever. So it might not be until tomorrow. Is this an issue for feature freeze?
[17:00] <cjwatson> rbasak: I wouldn't worry too much about FF for that
[17:00] <cjwatson> Don't rush for it :)
[17:00] <cjwatson> Esp if it's nearly done
[17:00] <rbasak> OK. Thanks. Although I've just noticed. doko: you've done it?
[17:00] <cjwatson> I expect we'll be spending a lot of time going through the -proposed backlog after FF
[20:04] <jamespage> if there are any SRU team folk around - please could the NEW packag for bug 1262225 be reviewed for acceptance into precise-proposed
[20:04] <ubot2`> Launchpad bug 1262225 in openvswitch (Ubuntu Precise) "openvswitch 1.4.6 is not compatible with the 3.11 saucy HWE kernel" [High,Triaged] https://launchpad.net/bugs/1262225
[20:35] <Sarvatt> for the mesa thats in NEW would it be possible to put the new package (libvdpau1-drivers-mesa) in universe?
[20:35] <jamespage> infinity, slangasek, bdmurray: any chance one of you guys could review my request above?
[20:48] <bdmurray> jamespage: I'll have a look at it
[20:49] <jamespage> bdmurray, thanks
[21:00] <slangasek> jamespage, bdmurray: accepted
[21:00] <slangasek> (sorry, had queued it up for looking while on a call)
[21:52] <bdmurray> slangasek: do you know why openvswitch seems to be in -updates and -proposed?
[21:52] <bdmurray> https://launchpad.net/ubuntu/+source/openvswitch/1.4.6-0ubuntu1.12.10.2
[21:54] <arges> bdmurray: not sure why it tried to sync and blamed me
[21:59] <infinity> bdmurray: Things don't get automatically removed from -proposed when they're copied to updates, we clean them up manually, based on the output on pending-sru.html
[22:00] <infinity> bdmurray: I'll tidy right now.
[22:01] <bdmurray> infinity: okay, any idea why there is a synaptiks sync request in the precise-proposed queue? I just released that version for precise
[22:01] <bdmurray> arges: did you run sru-release?
[22:02] <infinity> bdmurray: Blame arges, it's his queue item. :P
[22:02] <infinity> bdmurray: Anyhow, just reject it.  Looks like someone messed up. :P
[22:03] <infinity> Same for the openvswitch sync in there.
[22:03] <infinity> Also done by arges...
[22:03] <bdmurray> infinity: well if he was using sru-release perhaps it should behave differently
[22:03] <infinity> arges: If you're doing copies to -updates, please stop. :)
[22:03] <bdmurray> infinity: he's working with me to be an SRU team member
[22:03] <infinity> bdmurray: It behaves just fine.  It performs a copy.  And if you don't have the permissions to auto-approve, it'll land in the queue.
[22:04] <infinity> bdmurray: Oh, if you're training him up for SRU, cool.  But until I add him to the team, he has no queue admin permissions.
[22:04] <bdmurray> but why should it land in the queue?
[22:05] <arges> infinity: i'm not
[22:05] <infinity> bdmurray: Nothing wrong with the tool there, or LP, they're working as designed.  So, while training, you can get him to run sru-release and then you can manually accept his syncs.
[22:05] <stgraber_> bdmurray: that's what happens if anyone attemps a direct copy to -updates
[22:05] <bdmurray> infinity: okay
[22:05] <infinity> bdmurray: Anything uploaded by someone who can't auto-approve will land in the queue.
[22:05] <arges> infinity: oh so if I run the tool locally it actually modified things?
[22:05] <arges> i thought it errored out because of permissions
[22:06] <infinity> arges: No, you have the permissions to do the copy, just not to ACCEPT the copy.
[22:06] <arges> ah
[22:06] <infinity> A subtle, but important difference.
[22:07] <stgraber> infinity: if you have a minute, mind going through those lxc binNEWs? I'd hate for another distro to beat us to having LXC 1.0 in the archive ;)
[22:07] <arges> infinity: got it. I'll work with bdmurray to do this properly. I'll run that tool with -n to start.
[22:07] <arges> sorry about that
[22:08] <infinity> stgraber: Haven't you heard?  We're removing LXC from the archive because Lennart thinks it's the wrong approach.
[22:09] <infinity> (And someone else must have just done the binNEW review...)
[22:10] <stgraber> infinity: well, then I guess we can just wait for him to merge a kernel and libc in systemd, then we can just do: rm -Rf /srv/ftpmaster.internal/ubuntu/pool/*/*/[!systemd]/*
[22:11] <stgraber> all those packages and dependencies and upstreams, it's so complicated when we can just merge everything into a single git tree and release one massive blob every once in a while ;)
[22:12] <infinity> stgraber: I look forward to changing glibc's SONAME from libc.so.6 to systemd-libc.so.1
[22:13] <stgraber> infinity: he'd probably go with something like bionic just because that's different and looks cooler ;)
[22:14] <stgraber> (who needs a fully working libc anyway...)
[22:14] <infinity> stgraber: I'd be surprised if systemd didn't have a hard dep on glibc features.
[22:17] <seb128> can we get arm64 builders?!
[22:18] <infinity> seb128: Some day. :(
[22:18] <seb128> everything is delayed by hours on arm64 today
[22:18] <infinity> Yeah, the feature freeze flood hurt.
[22:18] <infinity> Oh, also, twombly is sick.  Let me fix that.
[22:18] <seb128> thanks
[22:20] <infinity> ... after I remember which PDU it's connected to.
[22:27] <infinity> seb128: Alright, twombly's back, queue should clear soonish.
[22:27] <seb128> infinity, thanks