=== jbicha is now known as Guest34968 === Guest34968 is now known as jbicha_ [04:26] We're doing all library transitions in -proposed now? [04:29] ScottK: The archive certainly doesn't seem to be aware of this. [04:29] ScottK: But yeah, especially for seeded packages, transitioning in proposed sure ends up a nicer experience for users and testers. [04:30] ScottK: I'm looking into britney automagic migration stuff this week and next. With any luck, we can just switch to proposed for all uploads and be done with it. [04:30] Just call it unstable. [04:31] Then alias the release pocket to testing. [04:34] * xnox doesn't want people to accidently upload to wrong distro though if pockets match names in debian & ubuntu [04:36] ScottK: Yeah, not gonna happen. :P [04:37] ScottK: Also, it's instant migration, so not quite the same deal. [04:37] The window is narrower, but you can still have interlocked transitions due to archive skew. [04:38] Well, yes. [04:38] But given that we also don't have a strict concept of package ownership, the answer to that problem is "fix it, then". [04:38] I will be surprised though if eventually someone doesn't say, "You know, we really ought to test these packages before they migrate". [04:38] Much as it currently is when our release pocket sucks. [04:39] When autopkgtest stuff gets more coverage, I wouldn't be at all unhappy with slowing the migration down a bit to force testing. [04:39] But we'll see. [04:39] True, but 'instant' can suddenly get a lot longer when your little library transition has to wait for a Qt build to finish on armel. [04:39] That will be an entirely different debate on velocity versus quality, etc. [04:39] ScottK: Yes, but we want things in sync on arches. [04:40] Yes we do. [04:40] ScottK: (And much like Debian, we may blacklist non-supported arches) [04:40] ScottK: Though, I don't intend to do that except as a last resort (like the current armel/mono breakage) [04:40] Speaking of non-supported architectures ... [04:41] Would you have a moment to look at clamav in lucid-backports. [04:41] It FTBFS from a test failure I've seen once on other archs, but is 100% after about 5 tries on ppc. [04:41] (on lucid - fine on other releases) [04:42] I was going to suggest trying a different kernel, but that was on a precise kernel even. [04:43] And I assume previous failures weren't all on ross? [04:51] I didn't think to check. [04:53] infinity: Can you retry it again and make sure it hits !ross? [04:54] ScottK: Done. [04:54] Thanks. I guess we wait now. [05:10] ScottK: Not sure if it relates, but while it's compiling testsuites, there's a char->uint conversion warning thrown by the compiler. [05:11] Actually, there are a fair few of those... [05:11] Though, I can't see how that would make it fail on only one release. [05:28] infinity: I'll let robert_ancell ask what needs AA attention. [05:28] robert_ancell: Answer fast, I have a midnight date with a patio and a cold beer. [07:48] https://lists.ubuntu.com/archives/ubuntu-archive/2012-June/045233.html - new change-override tool [08:02] slangasek: you volunteered, I don't think it is so much for you to do it, but for you to help us find who should be doing it, or pointing us to the test cases, or get started somehow [08:17] http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html is in Pub Time mode =) [08:17] And so it should be! :-) [08:33] * cjwatson fires his LP branch to remove change-override.py off to EC2 [08:36] * xnox 'cjwatson and LP Archive Admin days with your favourite Core Dev characters available now in the software centre as part of the Humble Indie Bundle in the Ubuntu Software centre" [08:37] * xnox 'cjwatson and the LP Archive Admin days with your favourite Core Dev characters available now as a part of the Humble Indie Bundle in the Ubuntu Software Centre" [08:37] odd chap [08:37] * xnox tries to be funny and fails at spelling and grammar [08:42] Now, I wonder what to do with security-kernel-overrides. It's kind of broken anyway due to something funky with indices, but maybe I should fix that anyway ... [08:42] Or maybe it's time to fix LP so that binaries default to the same component as their source [08:43] cjwatson: +1, that would solve my remaining override issues :) [08:45] (Bug 192076) [08:45] Launchpad bug 192076 in launchpad "component of new binary packages should default to source component" [Critical,Triaged] https://launchpad.net/bugs/192076 [08:53] cjwatson: That's a wonderfully old bug. [08:53] cjwatson: Would love it fixed. [08:54] cjwatson: Though, security-kernel-overrides still had a place for hardy kernels, where some bits are in universe. [08:54] (Not that I ever use the script, I don't trust it, I just eyeball madison output and make it match) [08:56] cjwatson: Of course, if it was fixed to actually look at listed components and DTRT, I think the hardy kernel would probably Just Work. [08:56] (And if not, we could fit it to do so) [08:57] security-kernel-overrides just plain didn't work last I checked, because the written-out overrides in indices were horribly incomplete. [08:57] I probably ought to investigate that [09:02] can you respin ubuntu desktop ? ubiquity on the image is 2.11.5 but 2.11.6 in the squashfs [09:04] it breaks oem-config [09:21] That's freaky. .list should always be >= .manifest, if anything. [09:22] Oh, it was built in parallel with something else apparently so it didn't sync the mirror. [09:22] I wonder what. [09:24] jibel: I'm investigating this rather than blindly respinning. [09:24] cjwatson, ok, thank you [09:30] There was a semaphore set that should have been clear. [09:30] So it always thought it was doing a parallel build even though it wasn't. [09:30] Apparently this situation has persisted since an Ubuntu daily-live build was killed on 20120606. [09:31] It must have been killed extremely unceremoniously; normally build-image-set cleans up the semaphore on exit. [09:32] I've cleaned this up and kicked off another build. However this time it actually *was* in parallel with a server build, which suffered from the same problem, so I'll wait for that to finish and then try yet again. [09:32] I'm surprised that nobody noticed that all the server packages date from 2012-06-06. [09:34] cjwatson: More evidence that no one tests between milestones? :P [09:35] cjwatson: (Since the Alpha-1 server build was pretty much on that date) [09:39] cjwatson: Regarding the new change-override. Remember how the LP script gave a visual clue what it was overriding? That was actually kinda helpful. [09:39] infinity: Example? [09:39] cjwatson: Yours says "universe/utils/optional -> main", I'd expect "UNIVERSE/utils/optional -> MAIN" [09:40] It upper-cased the chunk of the override stanza that was being overridden. [09:40] No it didn't. [09:40] Did too. [09:40] It upper-cased the priority. [09:40] Unconditionally. [09:40] 2012-06-14 18:22:46 INFO Override Component to: 'universe' [09:40] 2012-06-14 18:22:46 INFO 'libboost-graph1.46-dev-1.46.1-7ubuntu3/main/libdevel/OPTIONAL' binary overridden in quantal/amd64 [09:40] And I have history to prove it. [09:40] Huh. I swear I've seen it do the other thing. [09:40] * infinity scratches his head. [09:40] And that was just a side-effect of priorities being DB enumerated types. [09:41] I lower-cased it because that always annoyed me. :-) [09:41] If you want to upper-case as a hint, that sounds cool, it's just not because change-override.py always did it. :-) [09:41] Maybe I only noticed it when I was doing priorities... [09:41] But maybe only upper-case on the LHS. [09:42] I do now wonder how my brain saw that differently all these years. [09:42] Maybe I need a new one. [09:43] can i have the old one? [09:44] I thought I might keep in a jar and figure out how to talk to myself. [09:44] bah. still no brain-eating :( [09:44] oops [09:44] :) === yofel_ is now known as yofel [11:51] jibel: Should be happier now. [12:36] infinity: Thanks. [13:44] stgraber, looking yt your edubuntu omap buildlog you need some tweaks to tell livecd-rootfs to use universe i think [13:44] *at [13:46] ogra_: ah? the build failure I got looked fine, epoptes depends on a package that never built on armhf... [13:47] stgraber, oh, i thought it was a package in universe :) [13:47] yeah, if it didnt build thats an "okayish" error indeed [13:49] well, it also happens to be in universe but so was epoptes, so that part seems to work :) [13:49] I thought alkis fixed that issue by making epoptes conditionally depend on ssvnc which is also supported and built on armhf but apparently not [13:50] trivial fix then [13:50] unless you can convince him to fix xvnc4viewer on arm ;) [13:51] hehe, I actually tried that then when I saw the packaging of that thing I gave up and started writting my own vnc client ;) [13:51] xvnc4viewer's source is basically an old version of the vnc source + a copy of an old version of the X server + a bunch of patches [13:52] yeah, i know ... iirc doko was the last person looking at it for arm and gave up ... but that was like 2-3years ago :) [13:53] well, I guess nothing changed, it still looked like a terrible mess when I looked at it a couple of months ago ;) [13:53] yeah [13:53] IIRC the actual source of the FTBFS is in the X code, not in the vnc code, so we'd need to find the fix in the upstream X code and backport it to whatever old version is bundled in vnc4... [13:54] well ... could ... yes ... indeed ... [13:55] but for now I'm mostly of the opinion of just letting that package die ;) and trying to get as far away of it as possible for Edubuntu. [13:56] hehe, yeah, thats surely the better move ... [14:09] gema: ok - I'm going to point you at stgraber then [14:11] slangasek: context? :) [14:12] stgraber: work item to provide test cases for ipv6 [14:13] slangasek: ok [14:34] I should fix my procmail rules to do deduplication... this thread being cross-posted to -devel and -release is getting annoying [14:37] Laney: deduplication? you're actually getting duplicates? in my case it looks like mailman is being clever and doesn't send me duplicates, but I end up having 50% of the thread on one list and 50% on the other :) [14:38] yeah I get allo f them on both [14:38] stgraber: Exactly why I hate deduplication [14:39] that could get annoying, yeah. Would have to be made deterministic somehow. [14:40] it'd be fine if the To field would always be in the same order as the first match will move the e-mail, but apparently it's quite random, making them get into both folders... [14:40] I guess I could write a script that sorts the To field, then uses that for filtering :) === bjf[afk] is now known as bjf [15:29] cdimage@nusakan:~$ ARCHES=armel+omap4 buildlive ubuntu daily-live && ARCHES=armel+omap4 for-project ubuntu cron.daily-live [15:29] ubuntu-armel-omap4 on annonaceae.buildd starting at 2012-06-21 15:28:58 [15:29] ssh: connect to host annonaceae.buildd port 22: No route to host [15:29] heh [15:31] nice way to tell me: "screw you we dont build armel images anymore, fix y ogra_: shouldn't that be celbalrai.buildd ? [15:32] stgraber, well, for arm*el* it should be nothing :) [15:32] ogra_: heh, right :) [15:32] my fingers just didnt leanr that yet [15:32] *learn [15:33] ogra_: I'll be ready to kick another edubuntu test build after the publisher finishes its job, will check that you aren't already running a build before triggering it :) [15:34] oh, i can run armhf+omap instaed [15:34] no problem [15:36] ogra_: that'd be great, hopefully my default-arches config works now and it'll indeed only build for omap4 :) [15:37] running armhf+omap --- but i'm not sure infinity is done with switching his load balancing stuff back on again [15:38] so i might or might not block you atm, seems my build also starts on celbalrai [15:41] well, I'd usually have both omap and omap4 running on celbalrai at the same time, so I assumed it's fine as long as it's not the exact same "arch" building twice [15:41] the buildds block while they build for one arch [15:42] and a build usually takes 90min [15:42] ok, that explains why it looks like they're both starting building at the same time, but the second one takes double the time [16:28] ogra_: looks like your build just finished (well, failed), so I'm starting an Edubuntu build now [16:28] yep, i got what i want (logs) [16:30] my live build finished properly though :) [16:33] gah, where did we hardcode ext4 ... i thought we had bound that to preinstalled [16:36] hmm, obviously not in buildlive [17:57] stgraber, looks like you are done ? [17:59] stgraber, i'm firing off another attempt and will leave for the evening afterwards [18:00] (so celbalrai is free for you afterwards if you want to do more testbuilds) [18:01] ogra_: yep, my build worked (only did livefs) [18:35] NCommander: moar snipping please :-) [18:36] Laney: I think we have a proposal that works all [18:38] well, if you reply again I'd rather not have to page down for 15 minutes :P [18:42] NCommander: your proposal basically means that freezes will work as they do currently :) [18:42] NCommander: as Edubuntu won't be able to move to the new milestone-less stuff and edubuntu is a superset of Ubuntu (and we're introducing a server version this cycle) [18:42] stgraber: whch is what Kubuntu wants. Ubuntu doesn't wish to be part of those freezes so we can simply remove them [18:42] so that'd mean that all packages in Ubuntu would still have to be frozen as Edubuntu will still need the freeze [18:43] stgraber: please respond to Robbie's email then [18:44] I'm not sure I've seen much support from the RT for the idea of dropping freezes anyway [18:45] yeah, I mentioned it very early in the thread but my point of view is that we're already doing signifcant improvements to the way the archive works this cycle and that I'd really prefer we don't mess with our release process on top of that :) [18:46] we can always discuss doing that kind of change at next UDS after we've had a cycle (or part of anyway) of using -proposed and extended automated testing [18:47] NCommander: I'll respond to Robbie with Edubuntu's view once I confirmed that my view matches that of the rest of the Edubuntu release team (that being highvoltage) [18:47] stgraber: excellent [18:47] I think that for this cycle we should just have the community team do their additional milestones when we're not doing official ones. [18:47] Then we'll have some data at UDS as to how it goes, without having to potentially mess stuff up. [18:48] yep, I certainly have no problem whatsoever with more people testing the dailies and that'd let us easily review things at next UDS [18:48] like "was the archive working enough to let this happen?" "were the results useful?" [18:53] Laney: I recommend you post in the thread [18:53] it seems too big to be productive already [18:53] I'd rather discuss it at the meeting and see if we can come to a position as the release team [18:55] +1 [18:57] skaet: can/should we put it on the agenda? [18:59] NCommander, btw next time can you refrain to create issues for anyone and crosspost when not needed? [19:02] stgraber: I'm kind of annoyed at Jono's post and I'm tempted to reply [19:03] stgraber: but I don't want to delute any official message you'll be sending on the topic [19:04] highvoltage: I think the beginning of my message may also apply to your concern. [19:04] stgraber: just started to read your message, your first paragraph is almost exactly what I was already typing :) [19:05] highvoltage: hehe, I remember we discussed it with skaet at UDS and said we need to fix our documentation and "people" to stop saying derivatives when they mean flavours [19:05] stgraber: just finished reading it. perfect. not sure I would've been so nice so I'm glad you sent it. [19:05] :) [19:12] * skaet has a workitem to talk to the webops about cleaning up derivatives... [19:14] Laney, if you want to bring it up as a topic for discussion tomorrow, fine. Maybe start a new thread on ubuntu-release first, so folks who haven't been following the ubuntu-devel thread in all its glory can understand the issue? [19:14] Really? :( [19:14] stgraber: I still want to reply to jono's mail [19:14] I don't want to risk starting another discussion / fragmenting the existing one [19:15] Laney: Does it need discussing as an actionable item, really? While I (unlike many) am on the "hey, we should probably drop milestones" side of the fence, I don't think we should JFDI and see what explodes. [19:15] I think I'll send it to him as a private mail. [19:15] * ScottK looks up. [19:15] Laney: The only sane way forward is to increase testing, change the culture, and make milestones irrelevant. And if that works, then drop them. [19:16] Laney: I suspect it'll take two sentences and about 30 seconds to get concensus that we can't even consider B without first doing A. [19:16] I'm just asking for a conversation within the release team. [19:16] then we can give our position to those pushing for whatever change is being considered now. [19:16] infinity: Depends on how many managers are in the room. [19:16] if it's 30 seconds, all the better. [19:16] ScottK: I'm happy to phone a few up and get them to agree to the above position statement too. :P [19:17] Laney: This means I need to actually attend the release meeting, doesn't it? Since I'm one of the few RMs that seems to hold a strong opposing view here. [19:18] Laney: (Well, an opposing view with a cautious approach, though) [19:18] Laney, I'm fine with it just being a conversation then. Was just worried that some weren't following ubuntu-devel thread [19:18] It would certainly be nice if all interested were there [19:19] maybe we could just draft some thing on the pad though [19:19] Laney, lets see who's there tomorrow, and if its quorum talk about it. If not, I'll set up something else next week for us to get together with the release team and talk about it. [19:19] infinity: FWIW I'm not saying we should keep milestones forever, but I'm clearly of the opinion that doing a change of this magnitued in the middle of a release cycle is a bad idea and that any change shuld be done incrementally, in the right order and evaluated after each step. [19:20] skaet: ok then [19:20] +1 to that [19:20] infinity: but the current proposal sounded a lot like JFDI to me and I'm clearly opposed to that [19:23] stgraber: The original proposal didn't even talk about dropping milestones, just relaxing/dropping freezes (which we kinda already did for A1) [19:23] stgraber: It morphed into dropping milestones (which, yes, there's been a lot of discussion about), but no one thinks we can JFDI without making sure it's sane. [19:24] stgraber: Anyhow. I'll show to the meeting tomorrow and give my 2c. [19:24] infinity: I think the conclusion was that you can't really drop freezes and keep the milestones. [19:24] So you have to pick one. [19:25] ScottK: That depends on how you define milestones. [19:25] ScottK: If it's just a rallying point where people decide to test harder, target features, etc, you don't need a freeze. [19:26] ScottK: If it's to produce a release-quality image, you do need a freeze, but if that's the point, we always fail anyway. [19:26] Even for Alpha 1 (where there was no attempt to produce release quality images) we still freeze and need it. [19:26] ScottK: Hence why I included the anonymous "well, all the bugs we know about are kinda crap, but they'll be fixed in tomorrow's daily anyway" quote in the thread. [19:26] ScottK: We don't even pretend milestones are release-quality, so why put all the effort into trying to make them so? [19:27] I think a graduated set of goals would make sense. [19:27] Informally we generally consider Alpha 1 a win if you can install something and it boots. [19:28] We could lay out the release criteria for each milestone so that we aren't over-engineering early on. [19:28] For Beta 2, I think we should be aiming for release quality images (at least for all the installer components). [19:28] That would shorten the needed freezes without switching entirely away from our existing system. [19:28] We certainly want to achieve higher quality as we go, yes. [19:29] Though, one of the goals of PlusOne is to keep quality as high as we can. [19:29] Which was why I suggested a cultural shift to PlusOneQA to go with PlusOneMaint. ie: stop pretending only milestones matter, essentially. [19:29] Yes, but I think it's be useful to have a defined point to say "It's good enough, move on" for the early ones. [19:29] It does make the whole machine operate much more smoothly if "everything sucks for 3 weeks and then we freeze to test and fix it" isn't the status quo. [19:30] Agreed. [19:30] I think a general shift towards the idea that things should generally not be crap is very good. [19:30] Aaanyhow. I haz to work. But I'll come to the release meeting tomorrow and be the voice of insanity to balance against everyone's reason. ;) [19:35] ScottK, agreed, we've been informally turning up the quality as we go along, gettting the expectations for what happens at alphas/betas written down, was something I was thinking was overdue [19:37] seb128: (sorry, was on the phone). would you please ellibrate to what issues? (as for cross-posting, given the topic involved release tasks, it was just as revelant on u-release as it is on u-devel) [19:41] NCommander, I would assume that the release team members care enough about Ubuntu to be subscribed to -devel and I saw at least 5 people today complain about your crossposting making it hard to follow the discussion [19:42] NCommander, like you didn't add any value by crossposting but you make job harder for list admin, people commenting and people following [19:42] NCommander, several people replied on one of the two list only as well splitting the discussion thanks to you [19:42] seb128: ah, I shall stop [19:42] I apologize for the headache I caused [19:42] nw, but crossposting just sucks [19:43] nw? [19:43] no worry [19:43] sorry ;-) [19:43] seb128: guess I'm used to mutt handling it sanely [19:43] what's sanely? [19:43] * NCommander crawls under the bed in fear of the listadmins [19:43] If the message id matches, it shows it once, with two From: lines [19:43] the people who commented there today said they have half of the discussion landing on their -devel folder and the other half on -release [19:43] (though that might have been some procmail/muttrc magic I did) [19:45] I have them going to the same folder, so it was just hitting the delete key. [19:50] * NCommander decides to don a fake beard, get a Mexican Passport, and flees before the listadmins come to rm me out of existance === robbiew1 is now known as robbiew [20:38] hey, LP's Debian import really /did/ get faster :-) [20:39] Date: Thu, 21 Jun 2012 13:52:05 +0000 Subject: zeitgeist-sharp_0.8.0.0-3_amd64.changes ACCEPTED into unstable [20:39] syncpackage: Source zeitgeist-sharp -> quantal/Release: current version 0.8.0.0-2, new version 0.8.0.0-3 [20:55] Oh? Does this mean I can sync my uploads? [20:55] * infinity looks. [20:55] Evidently not. [20:56] Laney: Thanks for the false hope.