[10:48] <apachelogger> slangasek, ScottK: I think kubuntu-settings-desktop (providing etc/default/grub.d/05_kubuntu.cfg) needs to pre-depend grub-pc ... grub-pc.postinst looks for etc/default/grub OR etc/default/grub.d/* and if found it will try to read the grub_default_cmdline from there, however since 05_kubuntu does not define the cmdline it ends up empty (as seen on the kubuntu iso's default/grub)
[10:49] <apachelogger> grub-installer then runs update-grub on /target and only afterwards injects "quiet splash" as default without re-running update-grub, hence why after grub-installer ran the config appears in order on the target system but the grub.cfg does not
=== jbicha is now known as Guest90087
=== Guest90087 is now known as jbicha_
[12:13] <cjwatson> apachelogger: Depending on a specific grub platform package at all is wrong, and a Pre-Depends is probably even more wrong
[12:13] <cjwatson> apachelogger: If you depend on grub-pc you make it impossible to do e.g. EFI installs
[12:14] <cjwatson> apachelogger: In any case, grub-pc.postinst reads /etc/default/grub *and* /etc/default/grub.d/*, not *or*
[12:15] <cjwatson> apachelogger: Also, grub-installer does re-run update-grub after injecting "quiet splash"
[12:16] <cjwatson> Maybe I should do a Kubuntu install myself to investigate this, since I don't fully understand the problem
[12:59] <apachelogger> cjwatson: I only see one update-grub run and that is before injection
[13:00] <apachelogger> IIRC it would rerun if user-params wasn't null, except it is
[13:04] <cjwatson> Ah, right - would be better to fix that in grub-installer then
[13:05] <cjwatson> I don't get why it isn't sufficient for kubuntu-settings-desktop to just be in the desktop task, though, which it is
=== mmrazik is now known as mmrazik|afk
=== Ursinha-afk is now known as Ursinha
=== barry` is now known as barry_
=== barry_ is now known as barry
[16:49] <cjwatson> ogra_: disregard any kubuntu-active/raring/daily-live failure you see - I c'n'ped the wrong crontab line
[16:50] <ogra_> oops, ok
[16:55] <bdmurray> cjwatson: is there a new release tasks wiki page?
[16:56] <cjwatson> I didn't create one, was just prodding NewReleaseCycleProcess
[16:56] <cjwatson> so it's possible there are dead links now
[16:56] <cjwatson> (if you mean my edit to ReleaseTeam/FeatureStatus)
[16:57] <cjwatson> https://wiki.ubuntu.com/SaucySalamander/ReleaseTaskSignup does appear to exist
[16:58] <bdmurray> I wonder where to add tasks for updating meta-release-development for the new release, uploading ubuntu-release-upgrader for the new release and uploading python-apt for the new release
[17:00] <cjwatson> bottom of NewReleaseCycleProcess
[17:01] <cjwatson> At least some of those are there already
[17:07] <cjwatson> ogra_: Oh, apparently I should have set ARCHES or something (why is this out of sync with default-arches?)
[17:07] <cjwatson> ogra_: Can you advise?
[17:08] <ogra_> we never built that image officially ... there was one single testbuiuld and it kind of got lost until shortly before release
[17:08] <ogra_> i wanted to have a successful testbuild before adding it
[17:09] <cjwatson> OK.  What's the right ARCHES for me to use?
[17:09] <ogra_> ARCHES=armhf+nexus7
[17:09] <ogra_> my command should be in cdimages shell history
[17:09] <cjwatson> Running, thanks
[17:25] <infinity> bdmurray / cjwatson: There's a small typo in meta-release*, an extra space in the Quantal 'Name' stanza.
[17:25] <infinity> (Almost certainly a non-issue for the parser(s) that look at it)
[17:33] <bdmurray> infinity: I'll fix it in bzr and on the server sometime
[17:33] <cjwatson> doing now
[17:34] <infinity> bdmurray: Also, pgraner's getting a non-upgrade upgrade scenario with ubuntu-release-upgrader.  Want to come yell at his laptop?
[17:34] <cjwatson> done
[17:35] <bdmurray> infinity: where is it?
[17:35] <pgraner> bdmurray, qa room
[17:35] <cjwatson> infinity: a friend of mine noticed this morning that nothing ever clears /var/lib/ubuntu-release-upgrader/release-upgrade-available after upgrade
[17:35] <infinity> bdmurray: 2nd floor, 210/211
[17:35] <cjwatson> could be the same thing
[17:35] <bdmurray> cjwatson: that is bug 1173209
[17:35] <ubot2> Launchpad bug 1173209 in ubuntu-release-upgrader (Ubuntu) "Prompted about New Release for 13.04 again after dist-upgrade and a restart" [Low,Triaged] https://launchpad.net/bugs/1173209
[17:35] <infinity> cjwatson: Would that cause it to uselessly upgrade from raring to raring?
[17:35] <cjwatson> not sure, it would cause motd noise at least
[17:35] <infinity> (Which is what he's seeing)
[17:35] <cjwatson> bdmurray: ta
[17:36] <infinity> bdmurray: Oh, so saucy.tar upgrades to raring. :P
[17:36] <infinity> bdmurray: That might be a problem.
[17:36] <infinity> bdmurray: Fix is obvious, I'll fix it here.
[17:36] <infinity> data/DistUpgrade.cfg:To=raring
[17:36] <bdmurray> infinity: okay, thanks.  I'll stay put then
[17:38] <adam_g> zul, why are these saucy/havana branches going into grizzly branches? https://code.launchpad.net/~zulcss/keystone/keystone-saucy-ftbfs/+merge/161606
[17:40] <zul> adam_g:  launchpad being launchpad...not sure
[17:40] <adam_g> zul, huh?
[17:40] <zul> adam_g:  im not sure
[17:42] <cjwatson> ogra_: http://cdimage.ubuntu.com/kubuntu-active/raring/daily-preinstalled/20130430.1/ is there now, though not visible from conference wifi yet
[17:42] <cjwatson> ScottK: ^-
[17:54] <infinity> bdmurray: I take it back, maybe I won't fix it.  Building this source package from bzr is some sort of rocket voodoo.
[17:56] <bdmurray> infinity: okay, I can do it then
[17:56] <cjwatson> did you try bzr bd -S?
[17:57] <bdmurray> I think the pre-build.sh requires a few things
[17:57] <infinity> cjwatson: I did.
[17:57] <infinity> And it does.
[17:57] <infinity> And I supposedly installed everything it wants.
[17:58]  * infinity tries a bit harder
[17:58] <bdmurray> okay, just let me know
[17:58] <infinity> Does it rely on itself being installed too?  Seems like.
=== cjohnston_ is now known as cjohnston
=== mmrazik|afk is now known as mmrazik
=== Ursinha is now known as Ursinha-afk
=== vibhav is now known as Guest20326
[20:06] <ScottK> cjwatson: Thanks.
[20:12] <yofel> ScottK: ^
[20:12] <ScottK> yofel: I saw.
[20:12] <ScottK> Thanks.
[20:12] <yofel> ok, thanks for looking
=== Ursinha-afk is now known as Ursinha
[20:16] <ScottK> yofel: ^^^
[20:20] <yofel> :)
=== mapreri is now known as ajshfskjbdhgbhrb
=== ajshfskjbdhgbhrb is now known as mapreri
=== mapreri is now known as jfgnkljshdfghesl
=== jfgnkljshdfghesl is now known as mapreri
[20:44] <Daviey> If a package is the same version in precise, quantal and raring.  Does 3 different SRU versions make sense, or should it be done on precise - then binaries copied forward?
[20:44] <cjwatson> Separate uploads, please
[20:45] <Daviey> Specifically, bug 1174797
[20:45] <ubot2> Launchpad bug 1174797 in debmirror (Ubuntu Precise) "Canonical repos with Suite!=Codename cannot be mirrored" [Medium,Triaged] https://launchpad.net/bugs/1174797
[20:45] <cjwatson> For that package it'll be quicker to just do the uploads than debate it :-)
[20:45] <Daviey> cjwatson: Ok, thanks - What is the justification ?
[20:45] <Daviey> cjwatson: yah
[20:45] <cjwatson> In general, we want to see independent testing on each release anyway, so it doesn't really buy us anything to carefully try to avoid multiple uploads
[20:46] <cjwatson> Sure, in this specific case it might be possible to avoid that, but it's easier to just have a consistent message
[20:46] <Daviey> Yeah, ok - thank you.
[20:56] <ScottK> For Universe/Main we apply DFSG #8 (License Must Not Be Specific to Debian) as License Must Not Be Specific to Ubuntu, right?
[21:16] <cjwatson> ScottK: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-ulp
[21:16] <ScottK> cjwatson: Perfect.  Thanks.
[21:18] <Daviey> I see.
[21:37] <infinity> Daviey: Dude, upgrade your ubuntu-dev-tools.
[21:37] <Laney> let me guess: synced into release?
[21:37] <infinity> Laney: Yup.
[21:37] <infinity> Daviey: Syncing to the release pocket is a no-no.
[21:38] <infinity> Daviey: As an added bonus, you synced something with a new build-dep that needs an MIR.  Please to file/
[21:39] <Daviey> infinity: no, publishing the same binary in multiple -proposed and (pending verification) -updates pocket is what i was suggesting.
[21:39] <Daviey> Oh!
[21:39] <infinity> Daviey: ...
[21:39] <infinity> Daviey: python-testtools
[21:39] <infinity> Daviey: No idea what you're on about.
[21:40] <Daviey> I see, multiple threads
[21:41] <Daviey> infinity: revno 1387
[21:41] <Daviey> :/
[21:42] <infinity> Daviey: Erm, well, that's not the syncpackage you used, is it?
[21:42] <Daviey> 2013-04-30 19:59:45  syncpackage -d experimental -r saucy -f python-testtool .. manpage for -r suggests "Specify target Ubuntu release"
[21:43] <infinity> Daviey: Or you explicitly targetted "-r saucy" instead of just letting it do the right thing.
[21:43] <infinity> Daviey: Yeah, don't do that.
[21:43] <infinity> Daviey: If you omit "-r", it will go to "-proposed" for the current devel release.
[21:43] <infinity> Daviey: Alternately, target it yourself.
[21:43] <infinity> Daviey: Archive admins get to copy to -release, so we have to be careful not to.
[21:44] <Daviey> infinity: Ok, noted - I assumed it DTRT for syncpackage to gate into -proposed.
[21:45] <infinity> Daviey: If you explicitly tell it where to go, it does what you ask it.
[21:50] <cjwatson> Yes, it DTRT unless you override :)
[21:51] <cjwatson> (I made a similar mistake earlier this release, though using copy-package ...)
=== jibel_ is now known as jibel
[22:19] <ScottK> cjwatson: I noticed we're short the alpha/beta bug milestones for saucy like we had for raring.  Could those be added?
[22:34] <infinity> ScottK: I guess month-based ones aren't quite good enough due to not lining up with the scheduled A/B milestones?
[22:35] <infinity> ScottK: Could we maybe just fudge the schedule a bit so the month-based milestones are "good enough", and we don't have a messy set of not-quite-matching milestones?
[22:38] <infinity> ScottK: If we ditched A3, and shuffled A1/A2/B1 a tiny bit, we could just align them with end-of-months, ish.
[23:19] <ScottK> infinity: Personally, I'd find that very confusing.  The A/B milestones worked very well for us last cycle and I'd like to stick with what's working.