[02:13] <infinity> cjwatson: The more I think about it, the more I'm confused by the britney-copies-dont-preserve-overrides bug.  Given that when I do an sru-release of a kernel (for instance), which I overrode from universe to main in -proposed, it doesn't revert on copy to -updates.
[02:13] <infinity> cjwatson: Is that because britney's somehow copying differently, or is it that there's an inheritance issue from proposed to release that isn't a problem for proposed to updates?
[07:39] <infinity> superm1: I think you wanted -0ubuntu2, not -0ubuntu1build1 :P
[07:39] <infinity> superm1: The -NbuildN postfix is for rebuilding otherwise-unchanged Debian sources.
[07:42] <infinity> superm1: That said, I'm not sure this bug makes sense.
[07:43] <infinity> superm1: libmyth-0.25-0 on quantal already depends on libx264-123.
[07:43] <infinity> superm1: A rebuild won't change anything.
[07:52] <infinity> superm1: Oh, right, I see the bug now.  Yeah, rebuild away, but please use a sane version number (-0ubuntu2)
[07:53] <infinity> slangasek: Copying forward from precise-updates to quantal-updates might not be the sanest idea. :/
[07:54] <infinity> slangasek: (see mythtv, which had binary depends that were satisfiable in precise but not quantal)
[08:00] <infinity> superm1: Reuploading your upload with a sane version and accepting it.
[08:05] <infinity> superm1: Glad we had this talk.  You're awfully chatty today. :P
[09:20] <cjwatson> infinity: My guess is that it's something to do with the source also being newly-copied, which isn't generally the case for stable kernel copies.  That's just a guess, though, and I'd need to reproduce it in the test suite to make sure of it.
[09:22] <psivaa> cjwatson: Just noticed that precise desktop images have stopped building since 20121116.1.
[09:27] <cjwatson> Give me a minute, still recovering from overnight server reboot
[09:31] <psivaa> cjwatson: ack, no urgency
=== mmrazik is now known as mmrazik|otp
[09:36] <cjwatson> psivaa: No indication of why in the logs.  Trying by hand.
[09:36] <psivaa> cjwatson: thank you
=== mmrazik is now known as mmrazik|otp
[09:54] <cjwatson> psivaa: Well, no indication of why it failed, but that build worked.
[09:54] <cjwatson> *failed before
[09:55] <psivaa> cjwatson: ack, thanks
=== mmrazik|otp is now known as mmrazik
=== mmrazik is now known as mmrazik|lunch
=== doko_ is now known as doko
=== mmrazik|lunch is now known as mmrazik
[11:48] <ogra_> hmm, do we use LB_TASKS or LB_PACKAGE_LISTS in our live-build invocation ?
[11:48] <ogra_> cjwatson, do you know ?
[11:49] <ogra_> i need to preseed linux-firmware-nexus7 but looking at live-build/scripts/build/lb_chroot_preseed it seems to only process preseed files that are named after tasks in either LB_TASKS or LB_PACKAGE_LISTS
[11:49] <ogra_> http://paste.ubuntu.com/1369851/ i think this should work, but it doesnt look like live-build/scripts/build/lb_chroot_preseed would pick up the file at all with that name
[11:51] <ogra_> (the documentaion doesnt actually mention that the name needs to be in either of the vars)
[11:54] <cjwatson> I think you have an out-of-date version of live-build there - LB_PACKAGE_LISTS no longer exists
[11:54] <ogra_> oh
[11:54] <ogra_> that might well be
[11:55] <cjwatson> And I suspect if you look at the current version you won't see this problem :)
[11:55] <cjwatson> Your patch looks fine to me
[11:56] <ogra_> oh, yeah, the current version does what i'D expect
[11:56] <ogra_> thanks ! didnt strike me to check the version :)
[12:30] <apw> sbsigntool here is being backported to 10.04 as part of the 12.04.02 prep work for secure boot
[12:34] <cjwatson> LGtM
=== mmrazik is now known as mmrazik|otp
=== mmrazik|otp is now known as mmrazik
[14:38] <zequence> Hi, Ubuntu Studio dev here. We have our blueprints for 13.04 here https://blueprints.launchpad.net/ubuntu/+spec/topic-raring-flavor-ubuntustudio. What's the deal with blueprints? Do we register them somewhere? Like, how do they end up showing here http://status.ubuntu.com/ubuntu-raring/?
[14:38] <tumbleweed> https://wiki.ubuntu.com/WorkItemsHowto ?
[14:39] <knome> tumbleweed, that's not the question
[14:39] <knome> tumbleweed, the topic blueprints aren't showing up for ubuntu studio and xubuntu.
[14:39] <stgraber> zequence: you need all your blueprints to be accepted for raring
[14:39] <knome> otoh, the FDF being the 22nd, i'm not worried yet
[14:40] <knome> stgraber, do you have the powers? ;)
[14:40] <stgraber> knome: yes
[14:40] <knome> stgraber, can you go and accept anything under https://blueprints.launchpad.net/ubuntu/+spec/topic-raring-flavor-xubuntu ? :)
[14:41] <knome> i'll make sure they are all proposed in a sec.
[14:41] <knome> done.
[14:42]  * ogra_ grumbles 
[14:42] <ogra_> seems i just missed the publisher in my last build attempt
[14:44] <stgraber> knome: should be done, they'll show up next time status.u.c updates
[14:44] <knome> stgraber, cheers!
[14:45] <smartboyhw> zequence, are you asking stgraber to approve them?
[14:45] <knome> stgraber, ^ you might want to help the studio guys too :)
[14:45] <scott-work> thank you stgraber  :)
[14:45] <smartboyhw> Thx stgraber :D
[14:48] <stgraber> scott-work, smartboyhw: most of them aren't even targeted to raring yet
[14:48] <smartboyhw> stgraber, tell zequence that:P
[14:48] <smartboyhw> zequence, ^^
[14:49] <scott-work> stgraber: smartboyhw : we will take care of this this week
[14:49] <stgraber> ok, let me know once they are actually ready for approval
[14:50] <zequence> stgraber: Our blueprints (Ubuntu Studio) are about as ready as can be
[14:50] <stgraber> I also have the feeling that your blueprints will make the work item tracker significantly slower than it already is... You seem to have a lot of blueprints for a fairly small team. Regrouping some of them should make things easier to track and less of a pain to review and then for the tracker to parse.
[14:51] <stgraber> zequence: 80% of them weren't proposed for raring when I looked a minute ago
[14:51] <smartboyhw> zequence, put series goal as raring for ALL our blueprints..
[14:52] <zequence> stgraber: Er, yea. We don't have a strict system for that yet. I guess we could divide into raring blueprints vs non-release blueprints
[14:53] <zequence> Some of the blueprints may or may not be finished for raring..
[14:54] <zequence> stgraber: I'll see about making them easier to review then. bb, when it's done
=== mmrazik is now known as mmrazik|otp
=== mmrazik|otp is now known as mmrazik
[16:43] <slangasek> infinity: accepting packages into precise-updates with a newer version than quantal is also not the sanest idea; already discussed this one with superm1, who said he was going to upload the no-change fix?
[16:44] <superm1> slangasek: yeah i uploaded the no change fix, infinity said not to use 'build1' appended to it, but rather SRU style versioning
[16:50] <ScottK> superm1: ubuntu1build1 is never right.  Just use ubuntu2.
[16:50] <ScottK> Build1 is only useful for packages unchanged from Debian.
[17:31] <infinity> ScottK: ubuntu2 in this case wasn't right either, since it had been used in raring, but I reuploaded with something vaguely sane.
[17:31] <infinity> superm1: You did notice my upload and not upload again, right? :)
[17:32] <ScottK> Right.  Good point.
[17:32] <superm1> infinity: yeah thanks
=== yofel_ is now known as yofel
[19:25] <superm1> what sort of witch craft has to be done for packages that are fully built to migrate from proposed to the archive in raring?  it seem all architectures have built and there are no NEW binaries left, but https://launchpad.net/ubuntu/+source/mythtv/2:0.26.0+fixes.20121118.340b5d4-0ubuntu1 is still sitting only in proposed
[19:28] <infinity> superm1: You seem to have enormously confused it by going back in time with your library SOVER. :P
[19:28]  * infinity twiddles.
[19:28] <superm1> back in time?
[19:29] <infinity> superm1: From libmyth-0.27-0 to libmyth-0.26-0
[19:29] <superm1> infinity: oh that last upload wasn't supposed to happen, but it never migrated either
[19:29] <superm1> so it must have been confused for some time?
[19:29] <infinity> No, different confusions.
[19:30] <superm1> oh
[19:30] <infinity> Anyhow, I'll fix that one, and we'll see how it falls out.
[19:30] <superm1> kk, thanks
[20:10] <zequence> stgraber: Should be a lot less to review now (Something else depends on the raring blueprint now, but that's only for our internal planning) https://blueprints.launchpad.net/ubuntu/+spec/topic-raring-flavor-ubuntustudio
[20:10] <stgraber> zequence: ok, I'll take a look in a minute
=== robbiew is now known as robbiew-afk
[20:38] <superm1> infinity: is it still unhappy?  I came across http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and it's claiming something else now
[20:44] <infinity> superm1: It might need a bit of a manual shove.
[20:46] <infinity> superm1: Or, I need to remove some more cruft from -proposed.  Doing that.
[20:46] <infinity> Ursinha: Did you make any headway on making a -proposed-aware nbs-report?
[20:52] <cjwatson> Yeah, if you have more than one change of binary package name set between migrations from -proposed then it needs some manual cleanup.
[21:12] <infinity> cjwatson: In this case, I don't think it helped that there was also an NBS version of the old SONAME in proposed still.  I tidied that to see if the automagic bits will kick in now.
[21:13] <infinity> Oh, and indeed, it's now gone valid.
[21:45] <stgraber> zequence: done, I think I got them all
[22:07] <zequence> stgraber: Thanks!
[23:14] <cjwatson> infinity: Right, that's exactly what I mean - change the set of binary names more than once and you can end up with NBS.  If you only change them once, the packages that would be NBS are only in raring and not in raring-proposed.
[23:15] <cjwatson> I didn't predict this situation in advance but it makes sense in retrospect.