/srv/irclogs.ubuntu.com/2012/06/21/#ubuntu-release.txt

=== jbicha is now known as Guest34968
=== Guest34968 is now known as jbicha_
ScottKWe're doing all library transitions in -proposed now?04:26
infinityScottK: The archive certainly doesn't seem to be aware of this.04:29
infinityScottK: But yeah, especially for seeded packages, transitioning in proposed sure ends up a nicer experience for users and testers.04:29
infinityScottK: 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
ScottKJust call it unstable.04:30
ScottKThen alias the release pocket to testing.04:31
* xnox doesn't want people to accidently upload to wrong distro though if pockets match names in debian & ubuntu04:34
infinityScottK: Yeah, not gonna happen. :P04:36
infinityScottK: Also, it's instant migration, so not quite the same deal.04:37
ScottKThe window is narrower, but you can still have interlocked transitions due to archive skew.04:37
infinityWell, yes.04:38
infinityBut given that we also don't have a strict concept of package ownership, the answer to that problem is "fix it, then".04:38
ScottKI will be surprised though if eventually someone doesn't say, "You know, we really ought to test these packages before they migrate".04:38
infinityMuch as it currently is when our release pocket sucks.04:38
infinityWhen autopkgtest stuff gets more coverage, I wouldn't be at all unhappy with slowing the migration down a bit to force testing.04:39
infinityBut we'll see.04:39
ScottKTrue, 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
infinityThat will be an entirely different debate on velocity versus quality, etc.04:39
infinityScottK: Yes, but we want things in sync on arches.04:39
ScottKYes we do.04:40
infinityScottK: (And much like Debian, we may blacklist non-supported arches)04:40
infinityScottK: Though, I don't intend to do that except as a last resort (like the current armel/mono breakage)04:40
ScottKSpeaking of non-supported  architectures ...04:40
ScottKWould you have a moment to look at clamav in lucid-backports.04:41
ScottKIt FTBFS from a test failure I've seen once on other archs, but is 100% after about 5 tries on ppc.04:41
ScottK(on lucid - fine on other releases)04:41
infinityI was going to suggest trying a different kernel, but that was on a precise kernel even.04:42
infinityAnd I assume previous failures weren't all on ross?04:43
ScottKI didn't think to check.04:51
ScottKinfinity: Can you retry it again and make sure it hits !ross?04:53
infinityScottK: Done.04:54
ScottKThanks.  I guess we wait now.04:54
infinityScottK: Not sure if it relates, but while it's compiling testsuites, there's a char->uint conversion warning thrown by the compiler.05:10
infinityActually, there are a fair few of those...05:11
infinityThough, I can't see how that would make it fail on only one release.05:11
RAOFinfinity: I'll let robert_ancell ask what needs AA attention.05:28
infinityrobert_ancell: Answer fast, I have a midnight date with a patio and a cold beer.05:28
cjwatsonhttps://lists.ubuntu.com/archives/ubuntu-archive/2012-June/045233.html - new change-override tool07:48
gemaslangasek: 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 somehow08:02
xnoxhttp://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html is in Pub Time mode =)08:17
cjwatsonAnd so it should be! :-)08:17
* cjwatson fires his LP branch to remove change-override.py off to EC208:33
* 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:36
* 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
cjwatsonodd chap08:37
* xnox tries to be funny and fails at spelling and grammar08:37
cjwatsonNow, 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
cjwatsonOr maybe it's time to fix LP so that binaries default to the same component as their source08:42
micahgcjwatson: +1, that would solve my remaining override issues :)08:43
cjwatson(Bug 192076)08:45
ubot2Launchpad bug 192076 in launchpad "component of new binary packages should default to source component" [Critical,Triaged] https://launchpad.net/bugs/19207608:45
infinitycjwatson: That's a wonderfully old bug.08:53
infinitycjwatson: Would love it fixed.08:53
infinitycjwatson: Though, security-kernel-overrides still had a place for hardy kernels, where some bits are in universe.08:54
infinity(Not that I ever use the script, I don't trust it, I just eyeball madison output and make it match)08:54
infinitycjwatson: 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
infinity(And if not, we could fit it to do so)08:56
cjwatsonsecurity-kernel-overrides just plain didn't work last I checked, because the written-out overrides in indices were horribly incomplete.08:57
cjwatsonI probably ought to investigate that08:57
jibelcan you respin ubuntu desktop ? ubiquity on the image is 2.11.5 but 2.11.6 in the squashfs09:02
jibelit breaks oem-config09:04
cjwatsonThat's freaky.  .list should always be >= .manifest, if anything.09:21
cjwatsonOh, it was built in parallel with something else apparently so it didn't sync the mirror.09:22
cjwatsonI wonder what.09:22
cjwatsonjibel: I'm investigating this rather than blindly respinning.09:24
jibelcjwatson, ok, thank you09:24
cjwatsonThere was a semaphore set that should have been clear.09:30
cjwatsonSo it always thought it was doing a parallel build even though it wasn't.09:30
cjwatsonApparently this situation has persisted since an Ubuntu daily-live build was killed on 20120606.09:30
cjwatsonIt must have been killed extremely unceremoniously; normally build-image-set cleans up the semaphore on exit.09:31
cjwatsonI'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
cjwatsonI'm surprised that nobody noticed that all the server packages date from 2012-06-06.09:32
infinitycjwatson: More evidence that no one tests between milestones? :P09:34
infinitycjwatson: (Since the Alpha-1 server build was pretty much on that date)09:35
infinitycjwatson: 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
cjwatsoninfinity: Example?09:39
infinitycjwatson: Yours says "universe/utils/optional -> main", I'd expect "UNIVERSE/utils/optional -> MAIN"09:39
infinityIt upper-cased the chunk of the override stanza that was being overridden.09:40
cjwatsonNo it didn't.09:40
infinityDid too.09:40
cjwatsonIt upper-cased the priority.09:40
cjwatsonUnconditionally.09:40
cjwatson2012-06-14 18:22:46 INFO    Override Component to: 'universe'09:40
cjwatson2012-06-14 18:22:46 INFO    'libboost-graph1.46-dev-1.46.1-7ubuntu3/main/libdevel/OPTIONAL' binary overridden in quantal/amd6409:40
cjwatsonAnd I have history to prove it.09:40
infinityHuh.  I swear I've seen it do the other thing.09:40
* infinity scratches his head.09:40
cjwatsonAnd that was just a side-effect of priorities being DB enumerated types.09:40
cjwatsonI lower-cased it because that always annoyed me. :-)09:41
cjwatsonIf you want to upper-case as a hint, that sounds cool, it's just not because change-override.py always did it. :-)09:41
infinityMaybe I only noticed it when I was doing priorities...09:41
cjwatsonBut maybe only upper-case on the LHS.09:41
infinityI do now wonder how my brain saw that differently all these years.09:42
infinityMaybe I need a new one.09:42
knomecan i have the old one?09:43
infinityI thought I might keep in a jar and figure out how to talk to myself.09:44
knomebah. still no brain-eating :(09:44
knomeoops09:44
knome:)09:44
=== yofel_ is now known as yofel
cjwatsonjibel: Should be happier now.11:51
ScottKinfinity: Thanks.12:36
ogra_stgraber, looking yt your edubuntu omap buildlog you need some tweaks to tell livecd-rootfs to use universe i think13:44
ogra_*at13:44
stgraberogra_: ah? the build failure I got looked fine, epoptes depends on a package that never built on armhf...13:46
ogra_stgraber, oh, i thought it was a package in universe :)13:47
ogra_yeah, if it didnt build thats an "okayish" error indeed13:47
stgraberwell, it also happens to be in universe but so was epoptes, so that part seems to work :)13:49
stgraberI thought alkis fixed that issue by making epoptes conditionally depend on ssvnc which is also supported and built on armhf but apparently not13:49
ogra_trivial fix then13:50
ogra_unless you can convince him to fix xvnc4viewer on arm ;)13:50
stgraberhehe, 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
stgraberxvnc4viewer's source is basically an old version of the vnc source + a copy of an old version of the X server + a bunch of patches13:51
ogra_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:52
stgraberwell, I guess nothing changed, it still looked like a terrible mess when I looked at it a couple of months ago ;)13:53
ogra_yeah13:53
stgraberIIRC 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:53
ogra_well ... could ... yes ... indeed ...13:54
stgraberbut 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:55
ogra_hehe, yeah, thats surely the better move ...13:56
slangasekgema: ok - I'm going to point you at stgraber then14:09
stgraberslangasek: context? :)14:11
slangasekstgraber: work item to provide test cases for ipv614:12
stgraberslangasek: ok14:13
LaneyI should fix my procmail rules to do deduplication... this thread being cross-posted to -devel and -release is getting annoying14:34
stgraberLaney: 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:37
Laneyyeah I get allo f them on both14:38
cjwatsonstgraber: Exactly why I hate deduplication14:38
Laneythat could get annoying, yeah. Would have to be made deterministic somehow.14:39
stgraberit'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
stgraberI guess I could write a script that sorts the To field, then uses that for filtering :)14:40
=== bjf[afk] is now known as bjf
ogra_cdimage@nusakan:~$ ARCHES=armel+omap4 buildlive ubuntu daily-live &&  ARCHES=armel+omap4 for-project ubuntu cron.daily-live15:29
ogra_ubuntu-armel-omap4 on annonaceae.buildd starting at 2012-06-21 15:28:5815:29
ogra_ssh: connect to host annonaceae.buildd port 22: No route to host15:29
ogra_heh15:29
ogra_nice way to tell me: "screw you we dont build armel images anymore, fix y<our finger memory, damned !!!"15:31
stgraberogra_: shouldn't that be celbalrai.buildd ?15:31
ogra_stgraber, well, for arm*el* it should be nothing :)15:32
stgraberogra_: heh, right :)15:32
ogra_my fingers just didnt leanr that yet15:32
ogra_*learn15:32
stgraberogra_: 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:33
ogra_oh, i can run armhf+omap instaed15:34
ogra_no problem15:34
stgraberogra_: that'd be great, hopefully my default-arches config works now and it'll indeed only build for omap4 :)15:36
ogra_running armhf+omap --- but i'm not sure infinity is done with switching his load balancing stuff back on again15:37
ogra_so i might or might not block you atm, seems my build also starts on celbalrai15:38
stgraberwell, 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 twice15:41
ogra_the buildds block while they build for one arch15:41
ogra_and a build usually takes 90min15:42
stgraberok, that explains why it looks like they're both starting building at the same time, but the second one takes double the time15:42
stgraberogra_: looks like your build just finished (well, failed), so I'm starting an Edubuntu build now16:28
ogra_yep, i got what i want (logs)16:28
ogra_my live build finished properly though :)16:30
ogra_gah, where did we hardcode ext4 ... i thought we had bound that to preinstalled16:33
ogra_hmm, obviously not in buildlive16:36
ogra_stgraber, looks like you are done ?17:57
ogra_stgraber, i'm firing off another attempt and will leave for the evening afterwards17:59
ogra_(so celbalrai is free for you afterwards if you want to do more testbuilds)18:00
stgraberogra_: yep, my build worked (only did livefs)18:01
LaneyNCommander: moar snipping please :-)18:35
NCommanderLaney: I think we have a proposal that works all18:36
Laneywell, if you reply again I'd rather not have to page down for 15 minutes :P18:38
stgraberNCommander: your proposal basically means that freezes will work as they do currently :)18:42
stgraberNCommander: 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
NCommanderstgraber: whch is what Kubuntu wants. Ubuntu doesn't wish to be part of those freezes so we can simply remove them18:42
stgraberso that'd mean that all packages in Ubuntu would still have to be frozen as Edubuntu will still need the freeze18:42
NCommanderstgraber: please respond to Robbie's email then18:43
LaneyI'm not sure I've seen much support from the RT for the idea of dropping freezes anyway18:44
stgraberyeah, 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:45
stgraberwe 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 testing18:46
stgraberNCommander: 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
NCommanderstgraber: excellent18:47
LaneyI 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
LaneyThen we'll have some data at UDS as to how it goes, without having to potentially mess stuff up.18:47
stgraberyep, I certainly have no problem whatsoever with more people testing the dailies and that'd let us easily review things at next UDS18:48
Laneylike "was the archive working enough to let this happen?" "were the results useful?"18:48
NCommanderLaney: I recommend you post in the thread18:53
Laneyit seems too big to be productive already18:53
LaneyI'd rather discuss it at the meeting and see if we can come to a position as the release team18:53
stgraber+118:55
Laneyskaet: can/should we put it on the agenda?18:57
seb128NCommander, btw next time can you refrain to create issues for anyone and crosspost when not needed?18:59
highvoltagestgraber: I'm kind of annoyed at Jono's post and I'm tempted to reply19:02
highvoltagestgraber: but I don't want to delute any official message you'll be sending on the topic19:03
stgraberhighvoltage: I think the beginning of my message may also apply to your concern.19:04
highvoltagestgraber: just started to read your message, your first paragraph is almost exactly what I was already typing :)19:04
stgraberhighvoltage: 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 flavours19:05
highvoltagestgraber: just finished reading it. perfect. not sure I would've been so nice so I'm glad you sent it.19:05
stgraber:)19:05
* skaet has a workitem to talk to the webops about cleaning up derivatives...19:12
skaetLaney,  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
LaneyReally? :(19:14
highvoltagestgraber: I still want to reply to jono's mail19:14
LaneyI don't want to risk starting another discussion / fragmenting the existing one19:14
infinityLaney: 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
highvoltageI think I'll send it to him as a private mail.19:15
* ScottK looks up.19:15
infinityLaney: The only sane way forward is to increase testing, change the culture, and make milestones irrelevant.  And if that works, then drop them.19:15
infinityLaney: 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
LaneyI'm just asking for a conversation within the release team.19:16
Laneythen we can give our position to those pushing for whatever change is being considered now.19:16
ScottKinfinity: Depends on how many managers are in the room.19:16
Laneyif it's 30 seconds, all the better.19:16
infinityScottK: I'm happy to phone a few up and get them to agree to the above position statement too. :P19:16
infinityLaney: 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:17
infinityLaney: (Well, an opposing view with a cautious approach, though)19:18
skaetLaney,  I'm fine with it just being a conversation then.   Was just worried that some weren't following ubuntu-devel thread19:18
LaneyIt would certainly be nice if all interested were there19:18
Laneymaybe we could just draft some thing on the pad though19:19
skaetLaney,  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
stgraberinfinity: 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:19
Laneyskaet: ok then19:20
highvoltage+1 to that19:20
stgraberinfinity: but the current proposal sounded a lot like JFDI to me and I'm clearly opposed to that19:20
infinitystgraber: The original proposal didn't even talk about dropping milestones, just relaxing/dropping freezes (which we kinda already did for A1)19:23
infinitystgraber: 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:23
infinitystgraber: Anyhow.   I'll show to the meeting tomorrow and give my 2c.19:24
ScottKinfinity: I think the conclusion was that you can't really drop freezes and keep the milestones.19:24
ScottKSo you have to pick one.19:24
infinityScottK: That depends on how you define milestones.19:25
infinityScottK: If it's just a rallying point where people decide to test harder, target features, etc, you don't need a freeze.19:25
infinityScottK: 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
ScottKEven for Alpha 1 (where there was no attempt to produce release quality images) we still freeze and need it.19:26
infinityScottK: 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
infinityScottK: We don't even pretend milestones are release-quality, so why put all the effort into trying to make them so?19:26
ScottKI think a graduated set of goals would make sense.19:27
ScottKInformally we generally consider Alpha 1 a win if you can install something and it boots.19:27
ScottKWe could lay out the release criteria for each milestone so that we aren't over-engineering early on.19:28
ScottKFor Beta 2, I think we should be aiming for release quality images (at least for all the installer components).19:28
ScottKThat would shorten the needed freezes without switching entirely away from our existing system.19:28
infinityWe certainly want to achieve higher quality as we go, yes.19:28
infinityThough, one of the goals of PlusOne is to keep quality as high as we can.19:29
infinityWhich was why I suggested a cultural shift to PlusOneQA to go with PlusOneMaint.  ie: stop pretending only milestones matter, essentially.19:29
ScottKYes, 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
infinityIt 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:29
ScottKAgreed.19:30
ScottKI think a general shift towards the idea that things should generally not be crap is very good.19:30
infinityAaanyhow.  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:30
skaetScottK,  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 overdue19:35
NCommanderseb128: (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:37
seb128NCommander, 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 discussion19:41
seb128NCommander, like you didn't add any value by crossposting but you make job harder for list admin, people commenting and people following19:42
seb128NCommander, several people replied on one of the two list only as well splitting the discussion thanks to you19:42
NCommanderseb128: ah, I shall stop19:42
NCommanderI apologize for the headache I caused19:42
seb128nw, but crossposting just sucks19:42
NCommandernw?19:43
seb128no worry19:43
seb128sorry ;-)19:43
NCommanderseb128: guess I'm used to mutt handling it sanely19:43
seb128what's sanely?19:43
* NCommander crawls under the bed in fear of the listadmins19:43
NCommanderIf the message id matches, it shows it once, with two From: lines19:43
seb128the people who commented there today said they have half of the discussion landing on their -devel folder and the other half on -release19:43
NCommander(though that might have been some procmail/muttrc magic I did)19:43
ScottKI have them going to the same folder, so it was just hitting the delete key.19:45
* NCommander decides to don a fake beard, get a Mexican Passport, and flees before the listadmins come to rm me out of existance19:50
=== robbiew1 is now known as robbiew
Laneyhey, LP's Debian import really /did/ get faster :-)20:38
LaneyDate: Thu, 21 Jun 2012 13:52:05 +0000 Subject: zeitgeist-sharp_0.8.0.0-3_amd64.changes ACCEPTED into unstable20:39
Laneysyncpackage: Source zeitgeist-sharp -> quantal/Release: current version 0.8.0.0-2, new version 0.8.0.0-320:39
infinityOh?  Does this mean I can sync my uploads?20:55
* infinity looks.20:55
infinityEvidently not.20:55
infinityLaney: Thanks for the false hope.20:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!