[00:56] <bluesabre> Hello release team, it looks like menulibre and lightdm-gtk-greeter packages have not made it to trusty-proposed... is anybody available to accept them into proposed?
[00:57] <bluesabre> https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=
[02:05] <ScottK> bluesabre: There's quite a queue for review of SRUs (and you want the SRU team, not the release team)
[02:13] <bluesabre> ScottK, ah, my mistake. Thanks
[02:17] <bluesabre> ScottK, as part of the SRU team, would you mind moving these packages into trusty-proposed?  Or should I check with RAOF/arges tomorrow?
[02:20] <bluesabre> if at all possible, we'd like to deliver fixed packages with the 14.04.1 release... particularly for menulibre since some of the bugs are fairly severe. The members of the xubuntu qa team are willing to help with the SRU verification once these packages are available to test
[02:32] <RAOF> bluesabre: Sure. I always like to know which SRUs people are particularly interested in.
[02:33] <bluesabre> RAOF, thanks.
[02:34] <bluesabre> also, I have searched around but have not found any details, is there a freeze for the 14.04.1 release?
[02:34] <bluesabre> since its release date is the 24th
[09:08] <jibel> psivaa, do you know what's going on with utopic smoke tests? last promotion to current was May 22nd for i386 and May 20th for amd64
[09:08] <jibel> for desktop ^
[09:11] <jibel> psivaa, where is the branch containing iso_static_validation.py ?
[09:25] <psivaa> jibel: plars is leading the effort on the desktop utopic issues
[09:25] <psivaa> jibel: i'll forward the email on that to you
[09:25] <psivaa> jibel: for iso testing: http://bazaar.launchpad.net/~utah/utah/dev/files/head:/utah/isotest/
[09:25] <jibel> psivaa, thanks, I found it.
[09:36] <bluesabre> SRU Team, RAOF, Please let me know if you need anything from me to get the menulibre and lightdm-gtk-greeter packages from https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text= to trusty-proposed :)
[11:46] <mdeslaur> why is libav still stuck in utopic-proposed? the excuses page says it's a valid candidate...
[11:47] <seb128> mdeslaur, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[11:49] <seb128> mdeslaur, seems like it makes vlc audacious and some things not installable still
[11:49] <mdeslaur> seb128: hrm, interesting....can you give me a hint what to look for in that report? I don't quite know how to interpret it
[11:49] <cjwatson> I'm going to have another look at libav soon, but sil2100 was working on libaudclient packaging to improve matters
[11:49] <seb128> mdeslaur, http://people.canonical.com/~ubuntu-archive/transitions/html/libav10.html as well I guess
[11:50] <cjwatson> I wouldn't suggest more people piling in at this point - you'll spend as much time trying to interpret the complex transition ...
[11:50] <mdeslaur> ok, thanks seb128, cjwatson
[11:50] <cjwatson> sil2100: did you get any further with the next iteration of libaudclient?
[11:50] <cjwatson> oh, I see something in NEW
[11:51] <sil2100> cjwatson: yeah, I pushed a fixed version and then fixed the fixed version
[11:51] <sil2100> cjwatson: I have some rebuilds using this libaudclient also ready as source packages, waiting for libaudclient
[11:51] <cjwatson> Yeah, I must have missed the queuebot notification
[11:51] <cjwatson> Will look
[11:51] <sil2100> Thanks o/
[11:52] <sil2100> I'm doing some patch piloting of some universe packages right now
[11:54] <cjwatson> sil2100: thanks, accepted the second one
[11:54] <sil2100> \o/
[11:54] <sil2100> cjwatson: let me push some of the rebuilds I have then
[11:54] <sil2100> Thank you
[11:55] <cjwatson> sil2100: probably best to wait until the binaries are built, through NEW, and published
[11:55] <sil2100> Right, indeed :)
[11:55] <cjwatson> mdeslaur: https://wiki.ubuntu.com/ProposedMigration has interpretation advice BTW
[11:55] <mdeslaur> cjwatson: ah! excellent, thanks
[12:04] <arges> RAOF: hello! I sponsored compiz/precise and I was wondering if you could look at it in the queue for accepting it into -proposed. Thanks
[12:05]  * arges since you're the other sru-team member on duty : )
[13:47] <rbasak> Any chance an SRU team member can take a look at juju-core and juju-quickstart in the Trusty queue, please?
[13:48] <rbasak> arges maybe please? It's a blueprint item for me.
[13:49] <arges> rbasak: yup today is my day for that. i'll look at it in a second
[13:49] <rbasak> Thanks!
[14:04] <Laney> has anyone been looking at gnutls28?
[14:05] <Laney> oh yes I see a tracker
[14:06] <Laney> looks like it's nbs-in-proposed
[14:06] <cjwatson> Laney: It's entangled with libav
[14:06] <cjwatson> AFAIK all the stuff around gnutls28 itself is done
[14:06] <Laney> currently stuck at excuses
[14:06] <cjwatson> I know roughly what else needs to be done now
[14:07] <Laney> mkay
[14:48] <arges> rbasak: so for juju-quickstart, you cherry-pick a ton of fixes, iff 1.3.2 is a bugfix only release would it make sense to just do a bugfix only update?
[14:53] <arges> rbasak: in juju-core i noticed this in the diff: Binary files /tmp/JKvwNCjIVg/juju-core-1.18.1/pkg/linux_amd64/github.com/errgo/errgo.a and /tmp/ZqPilWjyt4/juju-core-1.18.4/pkg/linux_amd64/github.com/errgo/errgo.a differ
[14:58] <arges> also I think net-tools LP: #1251563 is ready for sru-review; but I sponsored it/hacked it a bit, so if somebody else can review/accept into proposed that might be better.
[15:22] <rbasak> arges: for juju-quickstart, doing SRU verification for each individual fix seemed a little onerous and unnecessary
[15:22] <rbasak> arges: so I focused on the high-impact one
[15:22] <rbasak> ones
[15:22] <rbasak> Looking at juju-core now
[15:22] <arges> rbasak: ok didn't know how many fixes there were relvative to what you cherry-picked : )
[15:23] <rbasak> arges: I'm working closely with the upstreams on this, so we synced on what they felt they needed in Trusty. And they wrote up most of the SRU paperwork for me :)
[15:24] <arges> rbasak: ok ok. i'll re-review that. Let me know about juju-core
[15:27] <rbasak> arges: confirmed juju-core binary in source tree. That looks like an upstream bug to me, I'm consulting withi them.
[15:28] <rbasak> arges: it's not present in juju-core 1.20. I suspect it's not used/needed. Assuming that's the case, how should we proceed with the SRU?
[15:28] <arges> rbasak: i can reject it, and you can reupload. What you can do is check the previous version to see if that file is there
[15:30] <rbasak> arges: upstream confirm it appeared in the 1.18.4 release, and can be safely removed. I don't see it in the 1.18.1 upstream tarball.
[15:30] <rbasak> arges: do you want me to re-upload with that file manually removed, then? I can make a note in README.source, +dsfg in the version, etc.
[15:31] <arges> rbasak: ok well might want to add an appropriate .*ignore; how big is the file btw?
[15:31] <rbasak> arges: 99K
[15:32] <rbasak> arges: what's .*ignore, please?
[15:32] <rbasak> arges: I can re-upload - just want to clarify exactly what I should do to drop this.
[15:33] <arges> rbasak: well for now just remove the file, but waht I'm saying is perhaps its some ignore rule like .gitignore that needs to be added to ensure that file doesn't appear accidently in the future
[15:34] <rbasak> arges: ah, I see. sinzui has fixed it properly upstream, AIUI.
[15:34] <arges> cool
[15:34] <arges> rbasak: ok i'll reject... one second
[15:35] <rbasak> arges: I guess I should add a README.source and put a dfsg in the version number to make it clear what happened.
[15:35] <arges> rbasak: ok re-upload when ready.
[15:40] <rbasak> Working on it. It occurs to me that I should fix Utopic also.
[16:14] <rbasak> arges: re-uploaded ^^
[16:14] <arges> rbasak: k
[16:14] <rbasak> (I uploaded the same fix to Utopic a little while ago too)
[16:40]  * ScottK cheers progress on the SRU queue.
[16:58] <cjwatson> Laney: agh, I see what you mean about gnutls28 NBS.  Fixing
[17:00] <Laney> Tah
[17:38] <xnox> Although not actually critical for 14.04.1, I was hoping upstart trusty SRU to be accepted into proposed and hopefully publish into updates before the point release. It's a trivial SRU.
[18:08] <seb128> xnox, try nagging slangasek for a review maybe? ;-)
[18:11] <xnox> seb128: my nagging balance with slangasek is negative atm, so I think I have more luck with arges maybe?! =)
[18:11] <seb128> the poor arges is the one reviewing most of the SRUs nowadays it feels like
[18:11] <arges> 'the poor arges' : ) haha
[18:12] <seb128> well, bdmurray is active as well
[18:12] <arges> xnox: i'll look at upstart
[18:15] <arges> xnox: looks like LP: #1174272 might affect 12.04... do any of the other bugs also affect precise?
[18:16] <slangasek> +  * debian/upstart.cron.daily: Specify full path to initctl.
[18:16] <slangasek> erm?
[18:16] <slangasek> how is that SRU-worthy?
[18:18] <xnox> slangasek: i think that was staged in trusty branch, before trusty got release.....
[18:19] <xnox> arges: no, reboot now reverting to maintainance mode does not affect precise. As rebootcommand was only introduced post-precise.
[18:21] <slangasek> xnox: ok; I don't think that's even a correct change to make to the script in question (hard-coding of paths should be discouraged), and I certainly don't think it should've been queued for trusty without a bug reference
[18:22] <slangasek> xnox: but the regression potential is also approximately nil, so I won't insist on a reupload
[18:23] <xnox> slangasek: ok. noted for the future. the "reboot now" is the one i'm pushing for though, because $clients.
[18:23] <slangasek> yep
[19:34] <ScottK> cjwatson: What's the test for "it works" for the dput changes (I figure I'll test out dput-ng)?
[22:49] <cjwatson> ScottK: (a) old-style dput ppa:foo/bar still works; (b) new-style dput ppa:foo/ubuntu/bar now works
[22:59] <cjwatson> infinity: Did you get any further with sorting out what's wrong with the -lts-saucy packages in precise that's causing image build failures?
[22:59] <cjwatson>  linux-signed-generic-lts-saucy : Depends: linux-signed-image-generic-lts-saucy but it is not going to be installed
[23:15] <infinity> cjwatson: All that's wrong is that seeds need fixing, but since I also need to switch to lts-trusty in this cyle, I hadn't fixed yet.
[23:16] <cjwatson> Oh, what's the seed fix?
[23:17] <infinity> cjwatson: Erm, assuming you meant the server ISOs, the seed issue is just that d-i and seeds don't match.
[23:17] <infinity> cjwatson: If you mean livefses are failing too, that's shiny and new, but also not worth fixing until we swap to lts-trusty.
[23:17] <cjwatson> livefses have been failing for a while
[23:18] <infinity> Oh, fun.
[23:18] <cjwatson> Maybe a week or so?
[23:18] <infinity> Kay, let's switch to lts-trusty in the livefses, then if it's still failing, figure out WTF.
[23:18] <infinity> cjwatson: I'll tackle that this afternoovening.
[23:18] <cjwatson> brilliant, thanks
[23:19] <infinity> cjwatson: (ie: some nonspecific time before now and sleep)
[23:19] <infinity> s/before/between/
[23:19] <infinity> My fingers suck.
[23:27] <cjwatson> Riddell,ScottK,shadeslayer: Any chance somebody Kubuntuish could please look into the calligra and plasma-nm build failures reasonably urgently?  They're blocking the libav/gnutls28/openconnect/blahblahblah megatransition which is using up way too many of my mental resources trying to disentangle ...
[23:27] <cjwatson> .../audacious/exiv2/...