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:48 |
---|---|---|
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 | 10:49 |
=== jbicha is now known as Guest90087 | ||
=== Guest90087 is now known as jbicha_ | ||
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:13 |
cjwatson | apachelogger: In any case, grub-pc.postinst reads /etc/default/grub *and* /etc/default/grub.d/*, not *or* | 12:14 |
cjwatson | apachelogger: Also, grub-installer does re-run update-grub after injecting "quiet splash" | 12:15 |
cjwatson | Maybe I should do a Kubuntu install myself to investigate this, since I don't fully understand the problem | 12:16 |
apachelogger | cjwatson: I only see one update-grub run and that is before injection | 12:59 |
apachelogger | IIRC it would rerun if user-params wasn't null, except it is | 13:00 |
cjwatson | Ah, right - would be better to fix that in grub-installer then | 13:04 |
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 | 13:05 |
=== 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 | ||
cjwatson | ogra_: disregard any kubuntu-active/raring/daily-live failure you see - I c'n'ped the wrong crontab line | 16:49 |
ogra_ | oops, ok | 16:50 |
bdmurray | cjwatson: is there a new release tasks wiki page? | 16:55 |
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:56 |
cjwatson | https://wiki.ubuntu.com/SaucySalamander/ReleaseTaskSignup does appear to exist | 16:57 |
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 | 16:58 |
cjwatson | bottom of NewReleaseCycleProcess | 17:00 |
cjwatson | At least some of those are there already | 17:01 |
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:07 |
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:08 |
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:09 |
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:25 |
bdmurray | infinity: I'll fix it in bzr and on the server sometime | 17:33 |
cjwatson | doing now | 17:33 |
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:34 |
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:35 |
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:36 |
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:38 |
zul | adam_g: launchpad being launchpad...not sure | 17:40 |
adam_g | zul, huh? | 17:40 |
zul | adam_g: im not sure | 17:40 |
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:42 |
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:54 |
bdmurray | infinity: okay, I can do it then | 17:56 |
cjwatson | did you try bzr bd -S? | 17:56 |
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:57 |
* 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. | 17:58 |
=== 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 | ||
ScottK | cjwatson: Thanks. | 20:06 |
yofel | ScottK: ^ | 20:12 |
ScottK | yofel: I saw. | 20:12 |
ScottK | Thanks. | 20:12 |
yofel | ok, thanks for looking | 20:12 |
=== Ursinha-afk is now known as Ursinha | ||
ScottK | yofel: ^^^ | 20:16 |
yofel | :) | 20:20 |
=== mapreri is now known as ajshfskjbdhgbhrb | ||
=== ajshfskjbdhgbhrb is now known as mapreri | ||
=== mapreri is now known as jfgnkljshdfghesl | ||
=== jfgnkljshdfghesl is now known as mapreri | ||
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:44 |
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:45 |
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:46 |
ScottK | For Universe/Main we apply DFSG #8 (License Must Not Be Specific to Debian) as License Must Not Be Specific to Ubuntu, right? | 20:56 |
cjwatson | ScottK: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-ulp | 21:16 |
ScottK | cjwatson: Perfect. Thanks. | 21:16 |
Daviey | I see. | 21:18 |
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:37 |
infinity | Daviey: As an added bonus, you synced something with a new build-dep that needs an MIR. Please to file/ | 21:38 |
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:39 |
Daviey | I see, multiple threads | 21:40 |
Daviey | infinity: revno 1387 | 21:41 |
Daviey | :/ | 21:41 |
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:42 |
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:43 |
Daviey | infinity: Ok, noted - I assumed it DTRT for syncpackage to gate into -proposed. | 21:44 |
infinity | Daviey: If you explicitly tell it where to go, it does what you ask it. | 21:45 |
cjwatson | Yes, it DTRT unless you override :) | 21:50 |
cjwatson | (I made a similar mistake earlier this release, though using copy-package ...) | 21:51 |
=== jibel_ is now known as jibel | ||
ScottK | cjwatson: I noticed we're short the alpha/beta bug milestones for saucy like we had for raring. Could those be added? | 22:19 |
infinity | ScottK: I guess month-based ones aren't quite good enough due to not lining up with the scheduled A/B milestones? | 22:34 |
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:35 |
infinity | ScottK: If we ditched A3, and shuffled A1/A2/B1 a tiny bit, we could just align them with end-of-months, ish. | 22:38 |
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. | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!