[00:01] so... someone's throwing back armel build failures until they stick? [00:01] slangasek: lamont threw back the entire stack last night. [00:01] lamont did a mass give-back las... yeah [00:01] it's been more than once [00:01] I've gotten two mails each for all my failed uploads in the past two days [00:02] Hmmm. I don't think so. [00:02] I only got one. [00:02] ah; then maybe a subset [00:03] One for the original failure and another for the give back or two extras? [00:03] the original failure was months ago - I got two build attempts of, e.g., 'imview' in the past two days [00:03] slangasek: Would you please source accept ibid from New. The LP U/I is being unhelpful. [00:03] looking [00:04] is it unhappy because 'ibid' is a substring of 'python-pyfribidi'? [00:04] I don't think so. [00:04] accepted [00:04] I get a "you are not allowed here" error. [00:04] doh [00:04] It happens every now and then, usually for reasons that aren't clear. [00:05] One known cause is if a package I try to accept fixes a private bug I don't have access too, but that's not he case ehre. [00:05] here even [00:06] heh, wacky [00:12] slangasek: now uploaded all packages which are statically linked according to the package name/description [00:13] ah [00:18] slangasek: A couple more syncs when you have a moment: http://paste.debian.net/69637/ We also want the new ipplan (0.92a), but I think it's still in incoming (see 565781) [00:18] we'll see how many of those we get to; I'll definitely be leaving some space in the build queue for emergency blocker builds [00:18] ScottK: ok, will look [00:28] slangasek: yes, both gfxboot-theme-ubuntu and d-i I think [00:29] * cjwatson goes for a late-night poke at those [00:29] ta [00:29] "There are 142 file requests on the export queue". Hmm [00:30] tomorrow morning would be inconvenient, right? [00:31] yeah. can you give me instructions I could follow to do it myself tonight? [00:33] nah, I'll just stay up a bit [00:33] not quite sleepy yet anyway [00:33] my scripts are a bit finicky ... [00:34] ok [00:35] have been up late looking over the rather ... unusual state of UK politics at the moment :) [00:38] xserver-xorg-video-geode reviewed, follow-up question sent to Q-FUNK [00:38] oh? what's the unusual part? [00:38] third party (the one I happen to support) surging by something like 15% in at least some polls [00:39] oh, huh [00:39] less in others but it appears to be statistically significant across the board [00:39] interesting times ahead given that we have an election right before UDS :) [00:39] hurray for free TV exposure [00:39] which I'll have to proxy-vote in, boo [00:40] ah, here come the translation tarball mails [00:40] haven't made any traction yet on sbeattie's worrying partitioning bug, btw - I'll have to attack that tomorrow and possibly fix it post-rc :-/ [00:41] I followed through all the maths in the code and couldn't find an error [00:41] * slangasek nods [00:41] oh, meep, and I promised Mark I'd change the CD boot splash branding [00:42] so I mentioned in the release meeting that the design team had asked to blank the splash screen, as they were upset about the distortion evident on some systems (gfxboot doesn't know about widescreen etc.) [00:42] I was alarmed about getting rid of the bottom icons (the rebus for "press a key") and clarified with Mark on Friday evening [00:43] "blank the splash screen" - urk, hadn't understood that from the meeting [00:43] he wants the logo gone from the CD boot splash (i.e. gfxboot - plymouth stays as it is) but is fine with the icons remaining [00:43] ok [00:44] I'll mail ubuntu-doc, they're bound to have screenshotted it but it should be very easy to redo [00:44] yes, with gimp and the rectangle tool ;) [00:44] not really happy about this being announced two weweks out, but at least it is easy to deal with [00:45] ooh, cute transliteration of Xubuntu in Bulgarian [00:45] -msgstr "^Инсталиране на Xubuntu" [00:45] +msgstr "^Инсталиране на Ксубунту" [00:45] Ksubuntu! [00:45] nice digraph [00:46] they could've just gone with Chubuntu... :) [00:46] You could ask Mark to review the time zone map again if you're short on last minute crises. [00:46] ;-) [00:46] argh [00:47] * cjwatson remembers he needs to update the d-i translations first, *then* regenerate gfxboot-theme-ubuntu's font [00:47] ordering ... [00:47] one of these days I'll document all this [00:49] * cjwatson wonders if he should remove the Kubuntu splash too [00:49] I'm thinking just the one that was explicitly requested, i.e. Ubuntu [00:50] but that requires a g-t-u code change [00:51] There's an open bug about updating it for Kubuntu to match the new branding, so going away would solve that. [00:59] Riddell already dealt with that bug though [01:01] Oh, OK. [01:05] cjwatson: the Kubuntu splash is different though because we still have the menu items showing [01:06] oh that's right, you aren't using the hidden-timeout mode [01:06] Mythbuntu is though [01:07] I can probably come up with a plan [01:08] consulting on hidden-timeout with seele is still on my todo, guess it'll roll over to UDS [01:10] no rush from my end [01:22] ok, that worked fine [01:29] Riddell: to some extent, making it not a crazy hack for maverick is on hold until I decide whether to throw the whole lot away and move to grub [01:43] slangasek: I've uploaded all the translation changes etc.; I've also committed and deployed the debian-cd changes for the CD splash thing on the basis that they're a no-op without gfxboot-theme-ubuntu 0.9.9 [01:44] slangasek: I'm going to go to bed shortly, so if you need to back anything out or fix anything or whatever, everything's in bzr [01:45] * cjwatson looks at his mirror job and wonders idly if mrpt-doc is really useful enough to justify its enormous size [01:46] sort of looks like a "Debian maintainer has too much bandwidth" case [01:49] anyone know what happened to language-pack-gv{,-base}, and why the gnome language packs for gv exist without them? [01:49] not in NEW ... [01:50] nope - just pinged ArneGoetje and pitti on -devel about it [02:21] cjwatson: what do these build/Makefile changes have to do with amd64/netboot-xen? looks like a miscommit to me... [02:22] cjwatson: n/m, found [02:27] slangasek: Edubuntu is failing to build due to issues with the -gv langpacks. Poked ArneGoetje about it and it seems like the language pack itself was removed from the archive but not the -gnome and -support with both still depending on the langpack and so making our build to fail. [02:28] (as we install all -gnome, -kde, -base and -support in the live environment) [02:28] stgraber: already sorted on #ubuntu-devel; next builds will succeed [02:28] ok ;) I guess my laptop isn't up to date then as it still shows -support and -gnome in the archive :) [02:29] slangasek: can you trigger a rebuild once the archive is clean, either later tonight or tomorrow as our 20100419 build already failed ? [02:30] -gnome was removed 20 minutes ago, so the change won't be published for another hour; -support only suggests: the language pack, not depends [02:30] "later tonight", yes - I'll be starting the RC mastering tonight [02:30] great [02:32] I guess langpacks really were the biggest source of build failure for Edubuntu this cycle (though shortly followed by my LTSP live environment ;)). Seems like it's hard to have all the langpacks installed at the same time ... [02:35] slangasek: Next layer of perl MIR bugs is done. Would you please pre-promote libexception-class-perl libb-keywords-per perltidy libreadonly-perl libreadonly-xs-perl libpod-spell-perl libfile-which-perl libstring-format-perl libfile-homedir-perl [02:36] ScottK: done [02:36] Thanks. [02:37] We'll know in ~70 minutes if that was it. [02:37] Every single one of that batch had an existing MIR that just had to be resurrected. [02:38] convenient [02:38] Yep [04:30] slangasek: Two more under that stuck. MIRs resurrected for libclass-data-inheritable-perl libdevel-stacktrace-perl - would you please pre-promote those too? [04:30] done [04:30] Thanks. With that, I think I'm off to bed. [04:31] ok, 'night [04:56] doko__: are syncs to the partner repo actually possible? [07:13] ScottK: ugh, so many new perl MIRs? the fun thing is, you submitted a ton of MIRs which aren't necessary according to http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, but c-m has two perl modules which don't have MIRs.. [07:14] morning all [07:17] hey ara, how are you? [07:17] hey pitti, a bit sleepy, but doing fine :-) [07:17] pitti, yourself? [07:18] ara: I'm great, thanks; had a really nice weekend [07:18] pitti, nice :) [07:18] go-kart race and big party on Saturday, and enjoying the nice sun yesterday [07:19] pitti, wow, it sounds like a really nice weekend [07:21] pitti: they're all necessary, component-mismatches just doesn't show them because I've been pre-promoting in order to get builds done [07:21] slangasek: ah, thanks [07:21] and it looks like we're *still* missing two more, for libperl-critic-perl build-deps, sigh [07:22] slangasek: I just added tasks for them [07:22] cheers [07:22] I'll review them together with the other bunch [07:25] ScottK: did you find out what we're meant to do with kde-l10n-sv? [07:26] FWIW, ISO mastering will be ready to start after the next publishing cycle (had to fix a d-i FTBFS on i386, I had demoted -generic-pae udebs because of component-mismatches, oops) [07:28] slangasek: the -gv langpacks are sorted out now? [07:28] yep, seems they were empty - removed at ArneGoetje's request [07:30] we really ought to have a mountall upload for bug #553290 before RC, but a) we need to back out the change for bug #559761 from bzr unless Keybuk has come up with a fix for the bug in my plymouth patch that this tickles, b) I don't know if he's gotten any other feedback on his ppa test except for mine, or if he's expecting any [07:30] Launchpad bug 553290 in mountall "Loops on mount failure when Plymouth not running" [High,Fix committed] https://launchpad.net/bugs/553290 [07:30] Launchpad bug 559761 in mountall "mountall needs to flush plymouth message queue before emitting upstart events" [High,Fix committed] https://launchpad.net/bugs/559761 [07:42] pitti: what's your gut feeling on taking ttf-takao-pgothic in for RC? I can have it uploaded within the hour, if you're willing to push it through NEW [07:43] slangasek: I thought that would also require a package split in ttf-vlgothic? [07:43] slangasek: I'm fine for a quick NEWing if you still want to push it through [07:44] pitti: ttf-vlgothic is a different font; takao-gothic is the new one that ArneGoetje says we should be using in its place [07:44] ah, right [07:45] slangasek: that'd be great, this would complete this bug/spec [07:55] pitti: ttf-takao uploaded [07:58] slangasek: ok, should hit the queue in 2 mins, will review then [08:06] if we do take the ttf-takao switch, that means another round of metapackage uploads, which "buys" us another publishing cycle before ISO mastering begins [08:06] so I'm going to look at getting mountall fixed in that window [08:08] pitti: and the vlgothic -> takao-pgothic switch saves us 600k packed, 1.5M unpacked; which appears to be enough to let us seed ttf-khmeros-core (220k), and fully complete the spec. Is that ok with you? [08:13] * ogra wonders why his ubiquity changes dont show up in the changelog for 2.2.18 [08:15] ugh, they dont even show up in http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/changes [08:15] * ogra wonders why ... i'm sure i pushed [08:17] argh ... /me glares at https://code.edge.launchpad.net/~ogra/ubiquity/trunk and curses [08:17] oh noes ... i pushed to an old branch [08:18] slangasek, i'm ashamed to ask, but is there any chance to get http://bazaar.launchpad.net/~ogra/ubiquity/trunk/revision/4081 merged before release ? [08:18] slangasek: absolutely, yes [08:18] * ogra feels really dumb now [08:19] slangasek: ttf-takao source-NEWed [08:19] ogra: ehm, so current ubiquity can't actually install omap? [08:19] * pitti will watch builds and binary-NEW [08:19] slangasek, yes, d-i should be able to though since the last rebuild [08:19] (havent tested yet) [08:19] ogra: ok; please commit that change to the right branch, and upload it now [08:20] slangasek, thanks a lot ... thats really embarassing [08:20] "now" meaning "within the next 20 minutes" [08:20] yes, ding it now [08:20] *doing [08:22] sigh, if LP would stop timing out on me that would help [08:23] pitti: thanks for the source NEW - I've also uploaded mountall, the changes are Keybuk's and I've already reviewed and tested them myself, but I would prefer another set of eyeballs if you don't mind [08:23] slangasek, meh, i know why my branch setup was wrong, i apparently cant upload to ubiquity trunk (though i'm in the installer team for d-i casper etc) [08:24] ah [08:24] * ogra wonders ifg cjwatson is awake to approve him for the right team [08:24] in the meantime, please upload [08:24] and push a merge request in parallel [08:25] ok, i need to fiddles with the changelog first, one sec. [08:25] -s [08:28] crap ... there is an additional change from ev in the trunk branch [08:28] for bug #563309 apparently [08:28] Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [High,Fix committed] https://launchpad.net/bugs/563309 [08:29] i guess i need to talk to ev first :/ [08:29] looks safe but i dont want to upload without his approval [08:30] please just upload your fix, then [08:30] slangasek: takao binNEWed (to main) [08:30] we can sort out the paperwork afterwards [08:30] pitti: thanks [08:30] ok [08:36] slangasek: heh, you beat me to committing the seed change by a couple of secs :) [08:37] whoo I won \o/ [08:39] ok, afk for a bit [08:45] slangasek, uploaded [08:58] pitti: do you think you can review mountall? [08:58] I have the publisher on manual so we can grab the rest of these fixes in a single publisher run [09:16] slangasek: I don't quite understand the "Don't run fsck while there's an uncleared error on the filesystem" part [09:16] are those uncleared errors only set by fsck itself? (i. e. it runs the first time, but then avoids a loop) [09:17] i. e. would an unclean shutdown not count as an "uncleared error"? [09:17] https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/501801/comments/8 is the explanation, I believe [09:17] Launchpad bug 501801 in mountall "Infinite-loops in fsck when booting with damaged /" [High,Fix committed] [09:17] pitti, slangasek: I've uploaded a fix for bug 563309 as ubiquity 2.2.19 in case we have enough time to squeeze it in. [09:17] Launchpad bug 563309 in ubiquity "ubiquity crashes on manual disc setup" [High,Fix committed] https://launchpad.net/bugs/563309 [09:18] ev: midair collision - ogra already uploaded a 2.2.19 containing the changes to support armel+omap, but he didn't have commit rights on the branch and wasn't sure enough of your change to upload it himself [09:18] ev: can you merge and reupload as .20? [09:18] slangasek: will do [09:19] blah, metapackage updates take too long [09:21] slangasek: Why? because the task changes take two cycles to propogate? [09:21] slangasek: so if you are sure about the fsck thing, it looks fine to me otherwise [09:22] wgrant: because downloading package files from the canonical source takes too long [09:22] pitti: I haven't personally vetted that code, but Keybuk is confident in it, and user feedback indicates that it fixes the worst problems... [09:22] ok, thanks [09:23] slangasek: I can take a -meta update/upload if you want me to? [09:23] slangasek: which one are you currently building? [09:24] pitti: I have all but one of them done now [09:24] (also, I'm hand-hacking a bit since ttf-takao-pgothic binaries aren't really in the archive yet) [09:24] * pitti thought ttf-takao would need to get published first [09:24] ah, heh :) [09:25] slangasek: done [09:26] slangasek: for the "disable file a bug menu entry", "disable apport" and "disable kerneloops" changes, should we do them after RC? or for RC? (in the past we did them right after) [09:28] pitti: I seem to always be eager to change apport before you, both disabling and enabling. :) I'm ok with doing it after RC if you think that's best [09:30] slangasek: oh, I'm fine with doing the uploads now [09:30] we have enough crash reports now, anyway :) [09:30] in fact I'd prefer disabling it in the RC as well [09:31] slangasek: launchpad-integration change is uploaded now; having that in the RC would be nice [09:31] ok [09:32] I'll review that and ubiquity, you can review *-meta :) [09:32] since that's the first time that we do that change [09:32] ack [09:32] * pitti prepares apport and kerneloops uploads [09:36] slangasek: apport and kerneloops uploaded [09:37] pitti: you say this lpi change isn't one we've made previously at release? Do we have to worry about this invalidating documentations? [09:37] -s [09:37] * pitti checks with mdke [09:37] thanks! [09:38] netbook-meta is the last [09:38] I'm at it [09:39] I'm on a-a duty today, what is it worth me looking at? [09:40] oh, NBS already looks quite good [09:40] james_w: if you have some minutes, getting that to 0 would be awesome [09:40] james_w: there are some sourceful new packages that I guess need to be decided [09:40] pitti: doko says he is watching the java one, and I can't get a sensible answer on how to handle sugar [09:41] james_w: and components-mismatches still has some stuff that needs hunted down & beaten with the MIR-stick [09:41] do we want any syncs today? [09:41] james_w: it looks like sugar is at 0.88 now? [09:42] pitti: yeah, but due to something to do with xpcom they couldn't upload the 0.88 browser, so that's stuck at 0.86 [09:43] so what's the current vs. desired state of ubiquity? [09:43] * cjwatson has read scrollback [09:43] equal [09:43] at least AFAIK :) [09:43] ah, I missed the bit where ev uploaded [09:43] good [09:44] ev: except bzr doesn't reflect this yet ... missing debcommit -r push? [09:44] cjwatson: fixed [09:46] slangasek: so, after the ubiquity/meta/apport/etc. bits are in, we'll build images for testing; after that, should we review/accept further safe and small fixes for tomorrow's dailies, or do you plan that today's images are the RC ones? (barring critical installer fixes, etc.) [09:46] hmm, seems that ubuntu-docs normally takes >2h to build, boo [09:47] in that case, we should do a publisher run as soon as the -meta builds are up, then another when ubuntu-docs is up [09:47] let's hope that the current security build isn't OO.o :) [09:47] pitti: I prefer that today's be the RC ones, barring critical fixes [09:47] slangasek: ack; so should we discourage people from uploading stuff now? [09:47] there's still a bunch of fixes; some of them might go in right after RC, of course [09:48] * pitti refers to the recent dbusmenu/indicator uploads, and similar [09:48] cf. my last message on #-devel [09:48] ah [09:48] I certainly prefer that anything we *know* is going in be done before RC [09:49] and we have time for these, they'll still get done building before ubuntu-docs AFAICS [09:49] I'm reviewing indicator-messages, if you or cjwatson wants to take libdbusmenu [09:49] what are the chances for getting software-center 2.0.2 in ? a small change, but helps performance a lot [09:49] ups [09:49] mvo: 100% ;) [09:49] mail old, nevermind, its in already [09:49] lalala [09:49] slangasek: taking libdbusmenu [09:49] * mvo takes a cup of tea [09:50] http://paste.ubuntu.com/418478/ are todays syncs. the only one to main is the first, which apparently brings a ftbfs fix, ok to sync? (they all have ffe approval) [09:52] james_w: hm, libgda4 is 4.0.4 -> 4.0.8 [09:53] libgda4 isn't on the CD images, but certainly on the DVD [09:53] and apparently builds a gir package now [09:53] james_w: was that the "would be nice to get back in sync" category, or does it fix critical bugs? [09:54] bug 537379 [09:54] Launchpad bug 537379 in libgda4 "Sync libgda4 4.0.8-1 (main) from Debian unstable (main)" [High,New] https://launchpad.net/bugs/537379 [09:54] claims that it is important [09:55] oh, I've just seen the instruction to wait :-/ [09:57] and pychecker was actually in main before it was removed [10:06] ^ jockey was a trivial and obvious patch, accepted [10:07] hmm, think I beat you to that one :) [10:07] slangasek: ah, seems you did :) [10:07] ev, cjwatson sorry for the mess, i wasnt aware i had no commit rights to ubiquity/trunk and didnt check where my bzr push went last week [10:08] ogra: no worries at all [10:08] i was under the assumption that being allowed to push to d-i would also allow me to push to ubiquity ... but that seem to be different teams [10:08] (and i forgot that i had set up the ubiquity branch differently last year) [10:09] yeah, d-i is maintained by core-dev [10:09] right [10:09] at any rate, you're in ~ubuntu-installer now :) [10:09] i'll do better next time, now that i know that :) [10:09] yeah, thaks a lot :) [10:09] *thanks too [10:09] sure thing [10:09] might be useful if someone could bump build scores on xubuntu-meta [10:09] doing [10:17] well, that took a bit longer than intended, but metapackages should all be accepted in ~10 min (for amd64/armel/i386), then I'll fire off the publisher [10:26] publisher running [10:42] slangasek: yes, cjwatson did sync it last time [10:43] doko__: I thought that when he synced it, he broke the archive... :) [10:43] cjwatson: ^^ does syncing to partner work now? [10:46] err, I had to file several bugs as a result and it was generally a right mess [10:46] we sort of got it working eventually [10:46] I think at least some of the bugs have been fixed [10:46] but I would not recommend trying it outside of a relaxed environment, i.e. not 1.5 weeks before release :) [10:46] best just upload the same source package [10:50] ok, I'll upload it manually [10:56] slangasek, bug 563618 has properly tested code now that actually sets the rtc/system clock on boot to work around the infinite reboots with no rtc battery [10:56] Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618 [10:57] ogra: ok; I'll take a look later today [10:57] sweet, thanks [10:58] indeed you can only set the clock to rubbish anyway, but with that script we set it to at least usable rubbish :) [10:59] ted tso agreed to fix fsck for us to completely ignore timestamps if teh e2fsck.conf override is set but that will surely take until maverick or maverick+1 [11:16] *-meta published. Waiting for synaptic to build before publishing the tasks and starting the ISOs [11:17] as well as ubiquity/armel, it seems [11:17] sweet ! [11:17] * ogra is just testing netinst d-i ... bein very excited [11:17] *being [11:37] aah! why did the OOo/armel build just restart? [11:38] lamont: is OOo killing armel buildds? [11:38] the buildd? [11:38] now on satinash; but I thought that's where it was before, too [11:38] slangasek: crabapple was not the build [11:39] hubbard is another question [11:41] * ogra sees a lot of 404's for security.ubuntu.com in his installation test log, isnt it time we enable that ? [11:42] ogra: they should have existed for months [11:42] and in fact they did [11:42] (with empty Packages.gz, of course) [11:42] weird, probably not for armel [11:43] right, just i386/amd64 [11:43] ah [11:43] http://security.ubuntu.com/ubuntu/dists/lucid-security/main/ [11:43] ogra: seems they are on http://ports.ubuntu.com/dists/lucid-security/main/ [11:43] for armel [11:44] ouch [11:44] then our sources.lists are wrong [11:45] probably on all arches, i havent done any non-omap tests for about four weeks now [11:45] slangasek: hubbard was last seen building wordnet 1:3.0-22 [11:47] pitti: ehm, that seems pretty critical to have fixed for RC [11:47] pretty sure that apt-setup selects ports.ubuntu.com on non-x86 architectures [11:47] for security [11:48] if it doesn't, I need an installation log with DEBCONF_DEBUG=developer [11:48] ogra: ^- [11:49] cjwatson, will do one after i fifnshed this install test (and actually check what ends up in the installed system) [11:49] *finished [11:58] slangasek: got a minute? Bug #564506 [11:58] Launchpad bug 564506 in banshee-community-extensions "libappindicator-cil-dev's .pc file points to the wrong place" [Undecided,Fix released] https://launchpad.net/bugs/564506 [11:59] it's got a binary rename, but it's pretty low-impact, considering the only rdep of the renamed binary currently FTBFS, and is waiting for the new name. [12:00] not to mention that the current version of the said binary package in the archive is broken pretty spectacularly. [12:03] hyperair: why do the -cil and -cil-dev packages not have consistent names? [12:07] any reason not to accept llvm-gcc-4.2? only builds on i386/amd64, 20min build time [12:09] hyperair: and why was the banshee-community-extensions package uploaded to build-depend on packages that haven't been accepted yet for lucid and might yet not be...? [12:09] doko__: no specific reason, just haven't looked yet [12:09] slangasek: because the previous version didn't build either. [12:10] slangasek: and because the previous version of indicator-application was broken pretty spectacularly [12:10] slangasek: as for the naming, the -cil version contains the ABI version, the -cil-dev contains the API version [12:11] slangasek: it's standard across all the CLI libraries in the archive. [12:11] well, blah [12:11] it's also not, AFAICS, relevant to the problem that's supposed to be getting solved in that bug [12:11] slangasek: er. the bug wasn't complete -- there were more problems than i realized. [12:12] slangasek: one of the duplicates complains about the library not getting into the GAC, for example. [12:12] the package may have problems, but I don't see how the package renames have anything to do with fixing the critical issues [12:13] slangasek: well it was a CLI policy violation. [12:13] slangasek: directhex decided to fix everything altogether in the patch. [12:14] moo? [12:14] yay directhex [12:17] hyperair, directhex: I'd like to see an indicator-application upload with just the minimal changes necessary to make the package functional; at this stage I could care less about whether it conforms with policies on package names [12:17] that will mean another upload of banshee-community-extensions to fix the build-deps back [12:17] * hyperair sighs [12:17] fine [12:18] slangasek: but is there a reason to be this resistant about a binary rename of a package that has no other rdeps? [12:19] hyperair: because packages from this source are on the CDs, and the window for changes to those packages is much smaller than for universe [12:20] ah right. the CDs. i forgot. [12:21] ogra@beagle:~$ cat /etc/apt/sources.list|grep security|grep main [12:21] deb http://security.ubuntu.com/ubuntu lucid-security main restricted [12:21] deb-src http://security.ubuntu.com/ubuntu lucid-security main restricted [12:21] hmm [12:22] * ogra does an install with DEBCONF_DEBUG=developer [12:22] there are 4 major bugs in the package, ignoring the policy problems - everything in debian/rules , and the pcfile patch [12:22] obviously the values in the patch i sent would need to be reverted back to incorrect locations, if the package naming is ruled out [12:24] directhex: do you think the risk is greater if making those location reverts? [12:25] slangasek, i think the tying together of API, ABI, install location and package names, within policy, was as a direct result of pain elsewhere when dealing with partial changes, and leading to big long painful Conflicts: and Replaces: dances [12:26] slangasek, my personal stance with canonical's bindings has been to go for unstable api/abi packaging, which is simpler & unversioned throughout, and a "safer" option for libs in flux. but i was overruled with libu1, and i simply play the hand i'm dealt [12:27] slangasek, the only changes which really have any potential to impact the packages on the CD are the changes to debian/rules, and those need to happen ANYWAY [12:28] (hint: as i understand CDBS, the one bit which *does* change the CD contents is the DEB_DH_MAKESHLIBS_ARGS_libappindicator0 which should really be there anyway) [12:28] directhex: OTOH, your patch *adds* the Conflicts/Replaces, which should be a one-time thing and shouldn't be any easier or harder if we do it now, or in maverick [12:29] true. question is whether it's ever likely to need backporting [12:29] since backporting from valid to invalid policy will add burden [12:31] the shlibdeps change may fix a bug, I don't know; if so, it's not a particularly serious bug, but I'll allow that change either way because the impact of getting it wrong is also roughly 0 [12:34] makeshlibs, not shlibdeps [12:35] yes [12:38] wohoo ... flash-kernel works in d-i [12:40] hyperair, do you have time to strip out the renames from my debdiff? i need to pop to the bank [12:41] directhex, hyperair: alternatively, if you've extensively tested this out-of-archive and can assure me that there will be *zero* need for further uploads of indicator-application for lucid, I can see my way to taking the rename [12:44] i'm not sure about *zero* need for further uploads.. we'd have to ask tedg about whether he has any further issues. [12:46] i tested the lib installed and could be built against as expected, i didn't rebuild b-c-e but can do that now [12:56] hm... Depends: banshee (>= 1.6.0), banshee-extensions-common (= 1.6.0-1ubuntu4), libappindicator0.0-cil (>= 0.0.19), libglib2.0-cil (>= 2.12.9), libgtk2.0-cil (>= 2.12.9), libmono-addins0.2-cil (>= 0.4), libmono-corlib2.0-cil (>= 1.2.2.1), libnotify0.4-cil (>= 0.4.0~r2998) [12:56] there we go, picking up the dependencies properly now, that's a good thing [12:57] yep, appindicator in banshee, working fine. just how nature intended [12:58] directhex, hyperair: so you're happy that if I accept this, any new issues that turn up are ones we'll be able to live with for release? [12:58] slangasek: yes. [13:00] if so, please get it uploaded and I'll accept it after RC [13:02] seb128: ^^ [13:02] hang on, i just want to double-check apt's handling of the conflicts [13:04] yep, looks fine [13:07] cjwatson, pitti: so my rune for triggering ISO builds contingent on a package publishing has been properly scriptified now - cdimage/bin/wait-for-package [13:08] (could use better documentation, still...) [13:08] ah, wait-for-package _ [13:08] sweet, thanks [13:11] yeah, it really just passes that to zgrep [13:13] slangasek: did you trigger that new edubuntu build ? [13:14] slangasek: neat [13:15] stgraber: I'm doing the big batch of ISO builds now; it'll be a few hours yet before it reaches edubuntu in the queue [13:17] slangasek: could do with mirroring build-image-set's semaphore handling around anonftpsync though - as it is it looks unsafe against parallel builds [13:18] maybe even just bail out if it ever notices that another build is running [13:18] hmm [13:18] isn't that a problem in anonftpsync itself, then? [13:19] depends where you think the locking ought to live :) [13:19] right :) [13:19]