=== Ursinha is now known as Ursinha-afk
[02:52] <rustx> hi all
[03:04] <rustx> any update concerning https://bugs.launchpad.net/bugs/1173265 ?
[03:04] <ubot2> Launchpad bug 1173265 in facter (Ubuntu) "facter fails to run from rebuilt source package" [High,Triaged]
[03:04] <rustx> relied to https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1170325 ?
[03:04] <ubot2> Launchpad bug 1170325 in facter (Ubuntu) "Facter 1.6.X not considering Qemu/KVM virtual type" [Undecided,New]
[03:04] <rustx> ?
[06:41] <Mirv> hello. please accept the following raring unapproved syncs: unity-lens-video nux compiz unity-lens-applications unity bamf
[06:42] <Mirv> this is the first time I'm asking for these daily-build syncs so I'm unsure how it works, but to be sure I've checked also the latest builds, not only the ones mentioned in the queue (13.05.08)
[06:42] <infinity> I'm not sure that asking will make it happen much faster.  They're a pain to review. :/
[06:43] <infinity> In fact, they're impossible to review, since they're no longer in the PPA.
[06:43] <infinity> \o/
[06:43] <Mirv> ok, no problem there. mentioning just in case there is any questions about those.
[06:44] <Mirv> ok, so that's why it was useful to ask :) didrocks ^ any idea on how we should handle those in general, ie. stuff getting removed before the syncs are removed?
[06:44] <Mirv> s/removed/reviewed/ to the last one
[06:44] <infinity> I'm not sure that syncs are going to be the best way to do your SRUs...
[06:45] <Mirv> leveraging the daily build system has been a goal, but it needs to be in a way that works best for everyone
[06:45] <infinity> Or works at all.
[06:45] <Mirv> that's the first step :)
[06:46] <infinity> wgrant: Are these old versions still cleverly hidden in LP somewhere where I can get at them?
[06:46] <didrocks> Mirv: infinity: it's still in the ppa
[06:47] <didrocks> if you search for the superseeded ones
[06:47] <infinity> didrocks: Oh, right.
[06:47] <Mirv> they are, for example in https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4559066 , but I'm not sure what's the best way to fetch them
[06:47] <infinity> This is about the most annoying workflow ever.
[06:47] <infinity> Not shocking that I haven't reviewed any of these. :/
[06:49] <didrocks> infinity: I thought that cjwatson exposed a new API to be able to review them in a easier way
[06:50] <didrocks> infinity: btw, you should have the same issue with the new kernels? how is it handled?
[06:50] <cjwatson> Doesn't 'queue fetch
[06:50] <infinity> didrocks: I review new kernels in their PPA, but they don't land a new build every day to obscure old ones.
[06:50] <infinity> cjwatson: Oh, did you make queue fetch actually follow all of this?
[06:51] <cjwatson> ' work?  Make sure you have a current queue.
[06:51] <cjwatson> Laney did.
[06:51]  * infinity tries.
[06:51] <infinity> Hey, that works.
[06:51] <infinity> Okay, still more annoying than my kernel workflow, but not world-endingly so.
[06:52] <infinity> Oh dear lord, but it's downloading all the binaries too.
[06:52] <infinity> Of course.
[06:52] <infinity> Cause the queue item is a binary copy.
[06:52]  * infinity head->desk.
[06:52] <infinity> That's going to really hurt when it includes ddebs in a few weeks.
[06:53]  * infinity goes back to reviewing kernels.
[06:53] <didrocks> yeah, would be good to find something easier, but still getting the same sustainability in term of quality that brings of testing the stack before pushing even for SRUs
[06:53] <StevenK> infinity: You're welcome.
[06:54] <infinity> If there's an easy (or even remotely possible) way to trace from a PCJ to an SPR, we could just grab the source with queue.
[06:54] <infinity> That might be nice. :P
[06:55] <wgrant> infinity: You can get old versions from a PPA by switching the Published filter on +packages to Superseded
[06:55] <infinity> wgrant: Yeah, didrocks covered that.
[06:55] <StevenK> infinity: We talked about linking a PCJ to a SPR at the sprint
[06:56] <infinity> wgrant: Not that that's convenient for this particular usecase.  queue fetch is a bit better, except that it's getting the whole PCJ.
[06:56] <cjwatson> infinity: On my list, but needs a DB change.
[06:56] <StevenK> Then we got distracted by ev wanting ddebs two weeks ago.
[06:56] <infinity> StevenK: I'm sure we did.  That was ages ago.  I can't brain that long. :)
[06:56] <cjwatson> queue show-urls or whatever might help for now.
[06:57] <cjwatson> Or hack fetch to igmore binaroes.
[06:57] <wgrant> infinity: Grab dsc URL, then get
[06:57] <wgrant> dget
[06:57] <cjwatson> With spelling.
[06:57] <infinity> Or that.
[06:57] <infinity> I just need the URL to feed to dget and I'm happy.
[06:58] <cjwatson> That's why queue has a subcommand for that ...
[06:58] <infinity> Ah-ha.
[07:00] <infinity> Wait, it does? :P
[07:00] <infinity> I guess it doesn't work on PCJs.
[07:02] <cjwatson> Leave an example in the queue and I'll have a look in a bit.
[07:03] <infinity> cjwatson: Leaving them all there right now, I'm busy with emergency kernel SRUs.
[07:03] <StevenK> cjwatson: I've got one -- http://pastebin.ubuntu.com/5666760/
[07:43] <rustx> hi all
[07:44] <rustx> do you have any update concerning https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1170325 ? relied to https://bugs.launchpad.net/ubuntu/+source/facter/+bug/1173265 ?
[07:44] <ubot2> Launchpad bug 1170325 in facter (Ubuntu) "Facter 1.6.X not considering Qemu/KVM virtual type" [Undecided,New]
[07:44] <ubot2> Launchpad bug 1173265 in facter (Ubuntu) "facter fails to run from rebuilt source package" [High,Triaged]
[07:45] <infinity> rustx: You might want to talk to rbasak (who is posting patches to the bugs).  This channel isn't for bringing up your pet bugs.
[07:45] <infinity> rbasak: PS, if you need a sponsor for things like that, you know where to find me. :P
[07:46] <rustx> infinity : pet bugs ?
[07:47] <rustx> if you call a SRU update a pet bugs .. well, maybe I don't exactly get what you mean
[07:47] <infinity> rustx: Perhaps that was a bit too harsh, but the sentiment stands.  This channel is for release co-ordination, and occasionally severely critical bugs come into that, but most bugs (SRU bugs or otherwise) are just noise here.  If every bug had someone championing it in this channel, we'd not be able to speak.
[07:48] <rustx> ok. good way to make people help fixing bugs
[07:48] <rustx> doesn't matter
[07:48] <rustx> on my side, everything was fixed. We are just using LTS on production .. huhuhu
[07:49] <rustx> be sure i won't track any bug with you guy, and will fix those on my sides at the end.
[07:49] <infinity> rustx: My message opened with suggesting who you might want to talk to.
[07:49] <rustx> infinity
[07:50] <rustx> infinity: yes i got it, but the way you reply does not sounds like a 'Open Source community'. You should go and work with russians at mandriva
[07:50] <rustx> anyway, doesnt matter; rbasak is sometimes here, and this is thanks to this channel i icould go on with that bug
[07:51] <infinity> rbasak is also in #ubuntu-devel, which would be a better place to discuss bugfixes.
[07:51] <cjwatson> Bug tracking is gteat, but it does get tough when everythimg'smirrored onto IRC in coordonation channels
[07:52] <rustx> no trouble
[07:52] <rustx> i will quit the channel, and will not disturb you any more
[07:52] <rustx> thank you !
[07:52] <cjwatson> sigh, apparently not so good at typing in connectbot
[07:52] <infinity> And, to be fair, the reason I knew he was involved in the bugs was because I looked them up the last time you asked about them.
[07:52] <infinity> cjwatson: Nobody is.
=== doko_ is now known as doko
[07:53] <rustx> infinity: thank you anyway, i don't get upset for this. sorry for disturbing
[07:55] <rustx> it's just when you have LTs on production, and when it's not stable, it's not good. That's all
[07:55] <rustx> bye bye
[07:58] <rbasak> rustx: I can update you in #ubuntu-devel. This channel is not the appropriate place.
[08:01] <rbasak> rustx: but I can only do that if you actually join #ubuntu-devel :)
[08:09] <rbasak> Do we run dep8 tests during rebuild tests, OOI?
[08:09] <cjwatson> No.
[08:09] <cjwatson> They're just package rebuilds.
[08:10] <cjwatson> But DEP-8 tests often involve partial rebuilds anyway ...
[08:10] <Laney> queue fetch downloading binaries> easy to turn this off or make it a flag - it's a separate API call anyway
[08:10] <rbasak> This facter bug is an example where if we'd had a dep8 test and it had run during a rebuild test then we'd have picked it up. But it only causes a delay fixing the issue in an SRU, rather than causing an actual regression in the archive.
[08:10] <Daviey> rbasak: Separately, i've been interested in running dep-8 tests accusingly
[08:11] <Daviey> occasionally
[08:11] <rbasak> fixing other issues in SRUs, rather
[08:13] <cjwatson> In this case wouldn't it have been sufficient to have a suitable package-build-time test?  Doesn't seem to require autopkgtest.
[08:14] <cjwatson> autopkgtest also often winds up rebuilding the package anyway, depending on configuration, so a rebuild test might well be redundant.
[08:15] <infinity> cjwatson: Actually, in this case, a build-time test wouldn't show the issue.
[08:15] <infinity> cjwatson: Cause build-deps allow it to work, but run-time deps are wrong.
[08:15] <rbasak> That may work, but I'm not confident in the general case. There seems to be some Ruby voodoo with generating the shebang that I don't like. I'm not confident that the generated (or supplied) Depends: line will match (or not match) with the shebang the same way in the build environment and after the package is properly installed.
[08:15] <Daviey> cjwatson: Unless i am mistaken, there isn't an upstream unit test on this package - which would mean introducing one - and dep8 seems to be a reasonable test for this issue?
[08:16] <infinity> Anyhow, doing dep-8 with our rebuild tests could prove difficult, since we don't publish the binary results of rebuild tests anywhere.
[08:17] <infinity> But I'm sure it could be done by someone sufficiently interested enough in making it happen.
[08:17] <Daviey> cjwatson: Generally, we were lookng to get greater dep8 coverage this cycle.. With some things being a simple "$binary --help" to check it exists 0 and didn't have an error starting.
[08:30] <rbasak> Just a thought for the future. It sounds like it's too much effort to be worth doing right now.
[08:33] <ogra_> stgraber, the current saucy image doesnt have the android bits (armel+$subarch), so it only advertises the rootfs (armhf) ... "ubuntu-touch" is what we will go with, "*-preview" will die when we stop rolling raring
[08:34] <cjwatson> Well, OK.  But AIUI a DEP-8 test that rebuilt the package would do the job here.
[08:35] <infinity> cjwatson: Not if the build-deps remain installed when the test is run.
[08:35] <infinity> cjwatson: The problem is that it ends up build-depending on ruby1.9.1 but runtime depending on ruby1.8 (oops).
[08:35] <cjwatson> They don't.  autopkgtest uses different chroots.
[08:36] <infinity> Maybe I'm misunderstandig what sort of test you meant.
[08:39] <ogra_> hmm, does britney have a hiccup ?
[08:39] <ogra_> The following packages have unmet dependencies:
[08:39] <ogra_>  unity-webapps-common : Depends: gjs but it is not installable
[08:39] <ogra_> E: Unable to correct problems, you have held broken packages.
[08:39] <infinity> ogra_: That's not britney's fault.
[08:40] <ogra_> broken dependency ?
[08:40] <seb128> ogra_, gjs is in universe, we just got an upload in to fix that
[08:40] <infinity> ogra_: That's just you only having main in sources.list and unity-webapps-common growing a universe dep.  It's being fixed.
[08:40] <ogra_> (in any case it breaks all desktop images today)
[08:40] <infinity> (Well, it's sort of britney's fault, in that it doesn't take components into account, but that's a known misfeature)
[08:40] <ogra_> k
[08:52] <cjwatson> infinity: I'd have thought a simple DEP-8 --help test or similar would do it, as long as it's run/restricted/whatever such that it builds the package first and then tests the rebuilt one.  When autopkgtest tests a package, regardless of whether it's rebuilt it first, it takes care to install it in a chroot with only declared dependencies and to run the tests there.
[08:55] <infinity> cjwatson: Ahh, kay.
[08:55] <infinity> cjwatson: That last bit was the missing piece for me.
[08:59] <Daviey> nothing currently autopkgtest's suitable SRU's right?
[09:00] <infinity> There's very little automated anything for SRUs.  This is on the TODO list.
[09:00] <infinity> First step is sorting out how to bring britney into play for SRUs, then it can tie into autopkgtest the same way we plan to for development releases.
[09:04] <Daviey> infinity: sounds good
=== tkamppeter_ is now known as tkamppeter
[10:46] <tkamppeter> Someone around who is in charge of SRUs? When will the proposed CUPS package for Quantal, bug 1086019, get approved?
[10:46] <ubot2> Launchpad bug 1086019 in cups (Ubuntu Quantal) "cupsd crashes regularly (daily)" [High,In progress] https://launchpad.net/bugs/1086019
[10:47] <tkamppeter> infinity, RAOF, SpamapS, bdmurray, slangasek, ScottK: ^^
[10:53] <tkamppeter> Thanks.
[10:53] <infinity> NP.
=== greyback is now known as greyback|lunch
=== mmrazik is now known as mmrazik|afk
=== cyphermox_ is now known as cyphermox
[12:46] <chrisccoulson> jdstrand, or anyone else, could you please approve that? ^^
[12:46] <jdstrand> sure
[12:47] <jdstrand> chrisccoulson: done. it will build in -proposed now. ping me when it is ready and I'll copy to partner release
[12:47] <chrisccoulson> jdstrand, cool, thanks. i've got uploads for the other 2 releases too. i'll upload those now
[12:48] <chrisccoulson> ok, those should appear any second now
=== greyback|lunch is now known as greyback
[12:51] <chrisccoulson> jdstrand ^^ :)
[12:53] <jdstrand> chrisccoulson: done
[12:54] <chrisccoulson> jdstrand, cool, thanks
[13:06] <stgraber> ogra_: ok, any ETA on that (stop building raring)?
[13:06] <ogra_> stgraber, i am still researching the container flip
[13:06] <ogra_> we want to have that done before switching to saucy (though it doesnt look good atm)
[13:07] <stgraber> ok
[13:08] <stgraber> I'll just support both project names for now then and we'll drop -preview once we're done switching to saucy
=== mmrazik|afk is now known as mmrazik
=== dannf` is now known as dannf
=== Ursinha-afk is now known as Ursinha
[14:09] <davmor2> cjwatson: hey dude.  I just hit an interesting issue upgrading my Raring box to Saucy.  From UEFI/Secureboot comes the message Ubuntu has been blocked by the current security policy :(
[14:17] <cjwatson> davmor2: unlikely to be able to look during UDS sorry
[14:19] <davmor2> cjwatson: yeap no worries I disabled secure boot for now and it is working and I can easily reinstall a secure booted raring on it and upgrade again next week, I just thought I would highlight it as it just happened.
=== bladernr` is now known as bladernr
=== blitzkrieg3 is now known as jmleddy
[16:47] <cjwatson> infinity: 'queue show-urls' now works on copies, and you can use the --source or --binary options to limit which items the 'fetch' and 'show-urls' subcommands operate on
[16:47] <cjwatson> infinity: so e.g. 'queue fetch -s raring-proposed -Q unapproved --source nux'
=== mmrazik is now known as mmrazik|afk
[17:52] <tumbleweed> apologies. got a friend's birthday do, I'll miss the release-ish sessions
[17:53] <tumbleweed> don't decide anything too crazy :)
[17:54] <stgraber> tumbleweed: will try to be reasonable, we'll just assign all the work items to you ;)
[17:54] <tumbleweed> good
[17:57] <Laney> seems perfectly reasonable to me
[17:57]  * iulian nods.
=== blitzkrieg3 is now known as jmleddy
=== mmrazik|afk is now known as mmrazik
[18:54] <Laney> so I can't really make this session but my opinion is that the later feature freeze worked well and we should stick with it
[18:54] <Laney> bonne nuit
[19:03] <stgraber> Laney: ok, we'll share the work items with tumbleweed then ;) have a good evening
[19:07] <stgraber> infinity: ping
[19:07] <cjwatson> infinity: are you around for the release schedule discussion?
[19:07] <cjwatson> ah, snap
[19:18] <infinity> stgraber / cjwatson: Gah.  Late night kernels broke me.  Just woke up.
[19:59] <cjwatson> infinity: 20:51 <knome> can you also mail the flavor devel lists?
[20:00] <infinity> knome: Sure.
[20:03] <knome> infinity, thanks
[20:03] <knome> infinity, hmm, only now i connected your nick and name. did you use to use some other nick previously?
[20:03] <infinity> knome: I've been infinity for decades. ;)
[20:04] <knome> infinity, okay.. i thought adconrad or something.
[20:04] <knome> oh wait, that's your username - that makes sense :)
[20:04] <infinity> knome: Oh, I'm adconrad in launchpad, and generally as a UNIX login.
[20:04] <infinity> knome: Yeah.
=== pgraner` is now known as pgraner