[08:12] <xnox> i've synced db6.0 twice now. so the older one can be dropped. but i'd like the ^ one to be accepted please =)
[08:13] <cjwatson> xnox: done
[08:13] <jamespage> Daviey, how would the SRU team feel about backporting the 1.9.0 openvswitch from raring to 12.04 to support the lts-raring enablement kernel?
[08:14] <xnox> cjwatson: cheers!
[08:14] <jamespage> it supports 3.8 natively and I feel its actually much lower risk and trying to backport the multitude of cherry-picks that don't apply cleanly to the 1.4.x codebase we have in 12.04
[08:18] <Daviey> jamespage: Hmm, a dedicated NEW versioned package name (like linux), or bumping the version?
[08:21] <jamespage> Daviey, hmm
[08:23] <jamespage> Daviey, I was thinking a straight backport to updates
[08:23] <Daviey> jamespage: Dual supporting both is more favourable IMO, but lack of dynamic dependencies makes this kinda hellish..  I can't think of a good user experience fix for handling this gracefully
[08:23] <jamespage> Daviey, the other option which is not ideal is to provide 1.9.0 via precise-backports
[08:23] <jamespage> so that 1.4.0 continues to exist for those that want to stick with 3.2
[08:24] <jamespage> but lts-raring users have to use the backports version....
[08:24] <jamespage> I'd need to run that past the backports team obviously
[08:25] <Daviey> jamespage: Probably a good idea to bring this to the TB mailing list, outlining the issue and possible solutions
[08:25] <jamespage> actually that might work better - I suspect that for the saucy enablement kernel I'll need to backport 1.10 which drops the brcompat module
[08:25] <jamespage> Daviey, OK - I'll send something this morning
[08:26] <Daviey> jamespage: Well, straight backports cannot really solve this, can it?  Unless you still do the compat work in the current openvswitch package?
[08:26] <jamespage> Daviey, ?
[08:26] <jamespage> its already backwards compatible
[08:27] <jamespage> i.e. 1.10 works on the 3.2 kernel
[08:27] <Daviey> jamespage: Current ovs in precise works with current lts kernel, but not raring backport?
[08:27] <Daviey> Oh!
[08:27] <jamespage> Daviey, yes
[08:27] <jamespage> The version we have in precise is good up to the quantal hwe kernel
[08:27] <jamespage> but that was painful and we have to carry a large number of patches
[08:28] <jamespage> (and I got it wrong first go)
[08:29] <Daviey> jamespage: Right.. and you want to avoid that again... and I agree the regression potential of trying to cherry pick that much is a problem.
[08:29] <Daviey> So what i am saying is, making use of backports will mean that  -updates doesn't work with the most recent HWE kernel.
[08:31] <Daviey> jamespage: AND, we ned to move quite quickly... 12.04.3, scheduled for next Thursday (is that still correct?).. will not work with openvswitch as it has the raring kernel, right?
[08:31] <jamespage> Daviey, no
[08:32] <Daviey> I'm wrong?
[08:40] <Daviey> jamespage: Am i wrong?
[08:41] <jamespage> Daviey, the version of openvswitch in 12.04 will not work with the raring HWE kernel
[08:41] <jamespage> well the user space tools might with the native kernel module
[08:41] <jamespage> but the openvswitch-datapath-dkms module which is the one everyting uses will not
[08:42] <Daviey> jamespage: Right.. the native support doesn't have GRE support, right?
[08:42] <jamespage> Daviey, thats correct
[08:43] <jamespage> Daviey, hmm - I wonder whether we can skew the userspace tools against the dkms module version
[08:43] <jamespage> Daviey, that way we could provide a versioned openvswitch-datapath-dkms-lts-raring package only
[08:44] <Daviey> Yeah, I think that is what I was thinking earlier.. but create a good user experience as we cannot do dynamic depends
[08:44] <Daviey> err, creates a poor*
[08:52] <jamespage> Daviey, well we have todo an explicit install of the dkms package anyway
[08:52] <jamespage> Daviey, so its not that much different
[08:54] <Daviey> jamespage: true.. Yeah, I think that is the best balance
[08:55] <jamespage> Daviey, just testing that now
[08:55] <Daviey> We get raring-hwe compatibility, with no risk of current users.
[08:55] <Daviey> I'd also say that it is a manageable workflow in the future
[08:57] <Mirv> could an archive admin add "poppler-qml-plugin" to the whitelist of source packages coming from cu2d? maybe cjwatson? both didrocks and seb128 are away today.
[09:08] <Daviey> Mirv: Sorry, I would help.. but I do not know how cu2d works, and I have been unable to find any docs.
[09:08] <jamespage> Daviey, userspace tools for 12.04 appear to be functional with newer dkms versions!
[09:10] <Mirv> Daviey: yeah the slight problem here is that I don't know where/what the whitelist didrocks touches is, but cyphermox told it's on the archive machines and not part of cu2d system (https://wiki.ubuntu.com/DailyRelease) as such
[09:10] <Daviey> jamespage: Super, that is good news.  I'd be happy processing this approach myself, unless anyone else objects.
[09:11] <jamespage> Daviey, great - I'll not bother emailing the TB as we have a low risk approach now
[09:11] <jamespage> marvellous
[09:11]  * jamespage thinks its good to talk these things through!
[09:13] <Daviey> Mirv: Yeah, I'm not even sure I can do that.. I'd rather not poke around, and risk getting it wrong.  Sorry. :(
[09:15] <Mirv> Daviey: I totally understand, that's why the idea of getting that Thing documented is a good one :)
[09:20] <Laney> It's something that gets committed to bzr and then pulled on lillypilly
[09:20]  * Laney waves hands and flails
[09:43] <sil2100> Daviey: hi! Maybe you could help us in some other way! Do you have a minute? :)
[09:44] <sil2100> Daviey: in the daily-release process, we have a requirement that whenever there is a packaging change in a package that is ready for releasing, we need and archive-admin-or-similar to ACK the change - so that no 'risky' packaging change gets released into Ubuntu
[09:44] <sil2100> Daviey: normally didrocks or seb128 do those, but now they're both gone
[09:46] <sil2100> Daviey: we have one thing like this now, it's really a one-liner that we already acknowledged, but we still need some core-dev to ACK it as well
[09:47] <sil2100> Daviey: I know it's hard to ACK something when you don't know the code, but it's just to make sure nothing unwanted gets into the archive
[09:47] <sil2100> Daviey: https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libusermetrics_1.1.1+13.10.20130816-0ubuntu1.diff
[09:47] <sil2100> Could you take a look? ;)
=== tkamppeter_ is now known as tkamppeter
[09:55] <jamespage> Daviey, I've emailed upstream just to validate the approach we discussed
[09:55] <jamespage> I might be missing something re userspace/kernel module compatibility
[09:56] <Daviey> sil2100: Well, reviewing the packaging diff represented there - it looks like something i'd be happy sponsoring.
[09:57] <sil2100> Daviey: !
[09:57] <sil2100> Daviey: thank you!
[09:57] <sil2100> Mirv: puublish!
[09:57] <Daviey> jamespage: well.. this base approach gives us some known compatibility.. in the worsed case, we'd need to also add a raring-hwe user space tools - right?
[09:57]  * sil2100 goes into slow-motion
[09:57] <jamespage> Daviey, yes
[09:58] <sil2100> Mirv: noooooow~!
[09:59] <sil2100> Daviey: thanks!
[09:59] <Mirv> sil2100: oh, you were shouting here :)
[10:00] <sil2100> ;)
[10:19] <cjwatson> Mirv: I'm at DebConf and I don't know much about cu2d anyway, sorry.
[10:20] <cjwatson> sil2100: This process should involve verification by somebody with upload privileges, not by an archive admin (a much smaller and much more contended set of individuals)
[10:20] <cjwatson> For the record
[10:31] <Daviey> cjwatson: Yeah, i almost said that - but i think sil2100 knew that, as he quantified with "need some core-dev to ACK it" .. I assume it's not in a pkg set.
[10:59] <Mirv> cjwatson: ok thanks anyway, and happy debconfing. and yes, the thing sil2100 asked for requires just core-dev.
[10:59] <Mirv> it's good that didrocks is away for a small while before real vacation, so that we notice these beforehand :)
[11:15] <sil2100> Indeed :)
[11:15] <sil2100> Actually, once again we need a core-dev to ACK another packaging change
[11:15] <sil2100> A quick one again
[11:39] <Laney> core-devs> #ubuntu-devel
[13:38] <sil2100> ogra_: hi! Are you still around?
[13:38] <sil2100> ogra_: we have another near-deadline packaging ACK that needs ACKing, maybe you could help this time as well ;) ?
[13:39] <sil2100> ogra_: https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libunity_7.0.11+13.10.20130816.2-0ubuntu1.diff
[13:41] <ogra_> sil2100, i assume this has been tested (cant really judge the sed lines so i need to truset a testrun you did )
[13:41] <ogra_> *trust
[13:42] <sil2100> ogra_: it passed our testing (failures in the acceptance threshold)
[13:42] <ogra_> sil2100, fine, then, go ahead
[13:42] <sil2100> ogra_: thanks! You're a life saver
[13:45] <jamespage> Daviey, ^^ updated iscsitarget for lts raring hwe kernel
[13:49] <Daviey> jamespage: reviewed and ^
[13:49] <jamespage> Daviey, thanks muchly!
=== rtg_ is now known as Guest11042
[14:52] <tkamppeter> jdstrand, hi
[15:00] <jdstrand> tkamppeter: hey
[15:22] <cyphermox> sil2100: Mirv: when you need a core-dev to review things before upload, that I or kenvandine can do
[15:22] <cyphermox> so, for the cu2d magic that apparently is needed on lillypilly
[15:22] <sil2100> \o/
[15:23] <cyphermox> seems like that would be just a matter of a bzr pull for the cupstream2distro-config branch somewhere on the machine
[15:23] <sil2100> cyphermox: first of all, do you have a moment for a quick pkg ACK? See #ubuntu-desktop ;)
[15:23] <sil2100> cyphermox: awesome
[15:23] <cyphermox> cron should be able to say exactly where, but I don't know how didrocks did it, and I don't have that kind of god powers
[15:23] <Laney> needs documenting for bus factor reasons
[15:23] <sil2100> Ok
[15:24] <sil2100> Laney, cyphermox: https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack this documents some parts probably
[15:25] <cyphermox> right
[15:25] <cyphermox> it is documented, just in a non-obvious way
[15:26] <cyphermox> I totally read over that without noticing >.<
[15:35] <sil2100> hehe
[15:35] <sil2100> Right, it's not being explicitly mentioned anywhere
[16:10] <tkamppeter> jdstrand, did you have a look into the openjpeg MIR, bug 711061?
[16:10] <ubot2`> Launchpad bug 711061 in openjpeg (Ubuntu) "[MIR] libopenjpeg2" [High,Confirmed] https://launchpad.net/bugs/711061
[16:12] <cyphermox> Laney: so, is that wiki page enough information?
[16:12] <Laney> dunno
[16:12] <Laney> I don't even know what is being requested. :P
[16:13] <jdstrand> tkamppeter: no. let me see if I can get someone else to do it
[16:17] <Laney> cyphermox: that branch is on 608 but trunk is 655
[16:39] <tkamppeter> jdstrand, OK.
[17:07] <cyphermox> Laney: if you could bzr pull on that branch I suspect it will be enough
[17:07] <Laney> I don't know what it means and so I'm reluctant to do so
=== bjf is now known as bjf[afk]
[21:00] <Sarvatt> anyone know whats up with x11-utils migration? autopkgtest for gvfs 1.17.2-0ubuntu6: RUNNING but it looks like it succeeded in jenkins unless i'm misunderstanding it