infinityOh look.  Linux 3.10.00:50
infinityapw: ^-- I'm assuming no one minds if we don't let that migrate until after the alpha?00:51
bjfc'mon, what could go wrong?00:51
infinitybjf: Nothing, the kernel team is perfect, and a beacon of light and hope to the world.00:52
bjfinfinity, exactly, we exhaustively tested it, there are no bugs in it00:52
infinitybjf: Oh, if there are no bugs, then that's cool.00:53
bjfbut then, i only care about stable :-)00:57
didrocksthanks a lot infinity :)06:20
apwit seems rtg's upload yesterday missed the fix for the autopkgtest definitin07:58
apwdefinition, should i fix and re-upload or shall we 'ignore' it as previously07:58
infinityapw: That's okay, I wasn't planning on letting it migrate anyway, unless you really want to disrupt alpha1 with a brand new upstream.07:59
apwinfinity, heh no indeed07:59
infinityapw: So, you have until thursday/friday to upload a new one if you want, no rush.07:59
apwinfinity, may as well upload a new one then, to confirm that autopkgtest sorts itself out08:00
apwinfinity, though i guess i don't want to ram the buildds ...08:00
infinityapw: Meh, the buildds are fine, as long as you don't upload 8 kernels in an hour for 5-character fixes.08:01
apwinfinity, this will be one in an hour for a 10 character fix, sigh08:05
infinityapw: You keep strange time.  Tim's upload was ~12h ago.08:05
apwinfinity, :)08:06
xnoxinfinity: didrocks: that unity raring SRU have version numbers higher than saucy: libgrip, libcompizconfig0, libdecoration, compiz, g-c-c-u, ..... E.g. saucy has 0.3.6daily13.06.10-0ubuntu1, while raring-proposed now has 0.3.6daily13.06.19~13.04-0ubuntu109:07
* xnox goes to figure out why my saucy box has raring-proposed enabled....09:08
didrocksxnox: hum, that's a good point, I thought about same release day release and thus, this appending of ~13.04…09:08
didrocksbut yeah, there is a versionning issue in that case, I need to think about it09:09
xnoxdidrocks: I mean the quick solution is to force release/bump version numbers in saucy.09:09
didrocksxnox: well, we are going to have a release today once the tests failing are fixed09:09
xnoxdidrocks: or have saucy bump "upstream" version number, with each ubuntu series.09:09
seb128didrocks, including compiz?09:10
didrocksxnox: bump it's difficult when you have 90 components to have upstream bumping their version and all them agrees :)09:10
didrocksseb128: not today, but in the coming week normally09:10
didrocksthere is one regression with compiz trunk they need to fix09:10
didrocks(Qt apps behind the top panel)09:10
seb128I was not sure how much that one was on the "it works, don't touch it" state09:10
xnoxdidrocks: hehe. Always encode "13.10" before date?09:10
seb128yeah for even longer version number?09:11
didrocksseb128: seems that would be the road…09:11
didrocksxnox: thanks for the pointer, noting it and will deal with it09:11
xnoxdidrocks: no worries, it's hardly the end of the world. We will have daily release before saucy goes out the door ;-) to make saucy higher again.09:12
seb128didrocks, yeah, sort of make sense ... if we want shorter versions we should just drop the "<upstream>daily" part, but that's another "battle"09:12
didrocksif only upstream fixed their tests everyday or their FTBFS, we won't have this issue09:12
didrocksxnox: yep, I just want to avoid that issue if possible ^09:12
didrocksseb128: I tried starting that one :)09:12
didrocksseb128: but it's a very very long term plan :p09:13
infinitydidrocks: Well, unless the code in 0.3.6daily13.06.10-0ubuntu1 and 0.3.6daily13.06.19~13.04-0ubuntu1 somewhat match, those versions are meaningless anyway without an upstream bump of some sort on a new series.09:13
didrocksinfinity: they don't match, but that's why for SRUs you have ~13.0409:13
didrocksso that you don't have in raring and saucy 2 0.3.6daily13.06.19-0ubuntu109:13
didrockswith different content09:13
infinityBut that's not what ~foo means.  It doesn't mean "this is completely different, but the same version". :P09:13
infinityAt least, not to most people.09:14
didrocksinfinity: well, suggestions welcomed :)09:14
infinityI expect my 1.2.3-4 and 1.2.3-4~foo to be basically the same thing.09:14
didrocksto cope with autobumping, upstream merger, and all those use case, with transitionning, having the same version in both saucy and raring09:14
infinityIf they're two different upstream branches, the upstream versions should really reflect that better.09:14
didrockswhile keeping when upstream doesn't bump to have raring > saucy09:14
didrocksoupss <09:15
didrocksinfinity: go convince for those 90 components :p09:15
infinityI don't see how that's hard...09:15
infinitySurely, they're all versioned simply enough that one can bump at least a minor/micro or something.09:15
didrocksinfinity: please open a discussion with PS, I already tried it…09:15
infinityThey used to bump versions on new series before this daily landing stuff...09:16
infinityWe got a new unity with every series.09:16
didrocksinfinity: unity, yeah, not for all components09:16
seb128they should probably just do "serie.date"09:16
infinityYeah, if they don't care about strict and sane branch-based versioning, just using the series number would work.09:17
didrocksseb128: well, you know I've already proposed that09:18
seb128didrocks, right, that's why I wrote "that's another battle" ;-)09:19
didrockswe could do the other way around, but the issue to do with <version>.<series> is that sometimes, they add a micro version (so an extra digit)09:19
seb128didrocks, but eventually we will get there09:19
didrocksseb128: I completely hope so :)09:19
infinitydidrocks: So, why is it <upstream>daily<date>~series intead of <upstream>daily<series>~date?09:20
infinitydidrocks: That wouldn't make me happy as far as versions being not-crack, but it would solve the ordering problem.  Cause saucy would always be >> raring.09:21
didrocksinfinity: because <series> wasn't thought at first, and you were complaining about version too long already :)09:21
didrocksinfinity: so that's why I only added it once we entered maintainance mode09:21
infinitydidrocks: Yeah, the versions are insane (and the "daily" string is redundant).09:21
* xnox thinks we are now past the point of caring of how long it is ;-)09:22
seb128I think we all agree here on that09:22
infinitydidrocks: Heck, the date part itself might be pointless.09:22
didrocksinfinity: again, will be pleased with a solution dealing with upstream's realities09:22
infinitydidrocks: It could just be <upstream>+<series>.<int> where <int> is an integer that increments on every upload.  The date is encoded in the changelog, it doesn't need to be in the version.09:22
xnoxwhere int, is bzr revno09:23
infinityxnox: Or that.09:23
didrocksxnox: I prefer date, it's more meanfull, especially with feature branch that are running in parallel09:23
didrocksxnox: otherwise, we won't be able to remerge09:23
xnoxinfinity: the date does give _some_ alignment though - e.g. everything is up to date.09:23
didrocksinfinity: so you do expect that <upstream>+<series> to be different upstream content than <upstream>+<series+1>09:24
infinityxnox: And that would be relevant, if the other 6000 packages on your system also showed the date in dpkg -l09:24
infinitydidrocks: No, I still think it's crack for upstream to not rev their versions, but as you say, I can't control that.09:24
xnoxinfinity: touche09:24
infinitydidrocks: But it's saner for YOU to do <upstream>+<series> instead of <upstream>+<date> and tack series on as an afterthought, cause mine sorts correctly. :P09:25
infinitySadly, this probably can't be changed for raring now (though, dpkg --compare-versions may tell me otherwise, let's see...)09:26
didrocksinfinity: I tried with dpkg --compare-versions and it seems fine09:26
infinityOh, wait.  Yay.09:26
infinity(base)adconrad@cthulhu:~$ dpkg --compare-versions 0.3.2+13.04 gt 0.3.2daily13.06 && echo Yes09:26
infinitySo, yeah.  That could work quite nicely.09:27
didrocksinfinity: ok, I'll implement that then09:27
didrockslet me try some other cases09:27
didrockswith features branch in particular09:27
didrocks(which have another versionning to deliver in a ppa, while still being compatible with distro once merged back)09:27
infinityI don't envy your life.09:28
didrocksisn't it? :)09:28
didrocksif it works, I'll handle the transition the sanest possible way09:28
didrocksthis means that upstream shouldn't use + in the upstream versionning09:28
infinityAlso, I'd pay good money to stop having useless changelog entries that say "automatic snapshot".  Which could go away if the revno was in the version. :P09:28
didrockswhich isn't unreasonable to ask :)09:28
didrocksinfinity: well, we can add the revno in the version, but that would be in addition to the date09:28
didrocksso I don't think you want it :p09:29
infinityI was thinking instead of the date.09:29
infinityBut yeah, I don't want both.09:29
didrocksnot possible again because of feature branch09:29
infinityCuase I think date.date is CONFUSING.09:29
didrockshaving different revision meaning other things09:29
infinityWell, if you use datestamps instead of dates-as-versions, it's a bit less confusing.09:29
didrocksinfinity: what about 0.3.2+13.04+13.06.03 for instance? (two +, but at least, more readable)09:30
infinityLike, 0.3.6+13.04.20130627 is less confusing than 0.3.6+ where we have a repeating thirteen dot oh something.09:30
didrocksyeah, that as well09:31
didrocksthen still .1, .2, .309:31
didrocksif we rerelease the same day?09:31
infinitySure, yeah.  Same as we date stamp ISOs.09:31
didrocksI'm good with this schema09:31
didrockslet me ensure all corner cases are tackled09:31
didrocksand I'll work on this this week09:31
infinityI hate to bikeshed abot versions, but yeah, the current ones are wrong from sort order perspective, and just plain ugly. :)09:32
infinityAnd the "daily" thing is off-putting, especially for SRUs.09:32
infinityNothing instills confidence in your stable updates like a daily snapshot. :)09:33
didrocksinfinity: well, at least, happy that we can come up with a better situation :) (the maintenance/SRU case was expected to be looked at in 14.04 TBH because of rolling)09:33
didrocksinfinity: well, on the contrary, we never had that much confidence thanks all the testing that is done automatically on a daily basis :)09:33
* didrocks wonders if there is a tool somewhere to convert a code name is stable release series version09:34
infinitydidrocks: I'm not saying that internally it's not better, just that externally, "daily" and/or "snapshot" are scary words. :)09:35
didrocksyeah, I understand :)09:36
mlankhorstdidrocks: I failed to parse that sentence..09:37
infinitydidrocks: I don't know of a codename<->version converter, you might suggest to bdrung that distro-info could grow some arguments to do that, since it has the tables anyway.09:38
infinitydidrocks: Of course, you could write one with distro-info-data.09:39
infinitydidrocks: /usr/share/distro-info/ubuntu.csv has what you're after.09:39
didrocksinfinity: ah, excellent, yeah, will use that one, better than querying launchpad for that :)09:40
cjwatsonRiddell,ScottK: There seems to be no migration block yet?09:41
cjwatsonOr is somebody else doing it?09:42
Riddellcjwatson: I'm wondering the best way to do it09:42
Riddellcjwatson: i.e. best way to find the list09:42
Riddellcjwatson: is getting the source packages from the germinate output the best?09:42
cjwatsonScottK has done it in the past, I think.  I don't recall exactly what he did09:42
cjwatsonMight be a case of trawling through IRC logs ...09:42
Riddellah yes, the .sources files would be easier09:45
cjwatsonHas what's actually a better option09:46
cjwatsonTake .manifest and .list from images, munge until you get a list of binary packages, map to corresponding source packages09:46
infinity(You probably want to wait for the new kde4libs to finish and get through)09:47
infinityThough, I guess you can unblock just that version after doing the generic block.09:47
Riddellthat was my next question, there's a bunch of things still needing to get in, does an unblock override a block?09:48
cjwatsonbzr di -c58 lp:~ubuntu-release/britney/hints-ubuntu   if you want the list for raring beta-109:51
=== doko_ is now known as doko
Riddellcjwatson: that should be the block in place09:56
cjwatsonthat was quick, thanks :)09:58
cjwatsonI'll watch it actually work once before starting auto-sync09:58
Riddellcjwatson: what does it mean if an autopkgtest is running?10:07
Riddelle.g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-baseapps says autopkgtest for pango1.0 1.32.5-5ubuntu1: RUNNING10:07
cjwatsonvast confusion because I haven't worked it out yet10:07
Riddellwhy does a test for pango affect kde-baseapps?10:07
cjwatsonI think it's a known problem with excessive following of virtual packages10:09
cjwatsonlibpango1.0-doc Depends: www-browser, konqueror Provides: www-browser10:09
cjwatsonjibel mentioned that as a known issue when fixing the converse problem (deps on virtual packages not being noticed at all)10:10
cjwatsonlooks like it might actually genuinely have been running and so should clear soon10:11
cjwatsonperhaps I should make force imply force-autopkgtest10:11
LaneyIt was non-genuinely RUNNING but jibel was looking into that10:13
Laneymaybe this new run will clear it out indeed10:13
cjwatsonthere was a run recently enough that it's plausible10:14
cjwatsonAnyway, force implies force-autopkgtest now10:14
cjwatsonRiddell: Could you please add versions to all your unblocks?  The syntax is "unblock SRC/VER"10:48
Riddellcjwatson: ah gotcha10:48
cjwatsonunfortunately the bad syntax crashes proposed-migration - I should fix that10:48
Riddelloops sorry10:53
cjwatsonI think I've fixed the crash now10:54
bdrungdidrocks: it would make sense to enhance distro-info to convert codenames into version and vice versa11:02
didrocksbdrung: agreed, but in fact, it's independant of my problematic for dailies, thinking about it. I need to be able, when saucy is frozen to still daily release what will become t* content, but in the "next" ppa on saucy11:03
didrockscjwatson: btw, read the technical board meeting about name. It's great to have this "next" as a name proposal. However, I'm disappointed now to have use that name for this transitional between 2 release ppa (ubuntu-unity/next), as they are close by usage and we'll get confusion ;)11:04
bdrungdidrocks: distro-info needs to learn the freeze date for this use case11:05
didrocksbdrung: yeah, that may be a possibility and having the target in debian/changelog (saucy or t* deduced from the version + freeze/release date)11:06
cjwatsondidrocks: mail technical-board@ please11:06
cjwatsonI will forget11:07
didrockscjwatson: not sure it worths mentionning TBH, an external ppa shouldn't infer the TB decision for distro11:10
Riddellinfinity: you're a genius, kde4libs compiled11:14
cjwatsonI'm retrying some associated failed builds now11:15
Riddellinfinity: what kind of storage does that pandaboard have?  I tried on mine and it ran out of disk space (4GB SD card)11:16
StevenKRiddell: I think they build onto USB drives11:20
didrocksinfinity: xnox: seb128: and here we go! http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/33011:23
didrocksI'll deploy that today11:23
cjwatsonschedule amended to move DIF to week 13; mail sent to ubuntu-release@; auto-sync running11:26
=== ara is now known as Guest5314
cjwatson[Updating] requests (1.2.0-2 [Ubuntu] < 1.2.3-1 [Debian])11:34
cjwatsonoops, echan11:34
Riddellhmm, arm fail https://launchpadlibrarian.net/143356647/buildlog_ubuntu-saucy-armhf.kamera_4%3A4.10.80-0ubuntu1_CHROOTWAIT.txt.gz11:44
cjwatsonbetter to link to the +build, then we can tell which builder it is11:44
cjwatsonreported to ops11:45
cjwatsonand heka on manual11:45
cjwatsonI've retried all heka's failures11:48
cjwatsonAnyone fancy processing click-package in NEW?12:52
mlankhorstcjwatson: can you wipe xorg-server from raring unaccepted?12:52
=== mmrazik is now known as mmrazik|afk
cjwatsonmlankhorst: I'll have to give a reason, so if you can give me one, that'd be good12:56
mlankhorstwill regress12:56
mlankhorstit needs another fix because a regression was found when it was uploaded to saucy, sec let me get bug #12:56
mlankhorsthm doesn't seem to be one, but it broke nvidia prime support, unless another patch was also applied on top12:57
seb128cjwatson, let me have a look12:58
cjwatson$ queue -s raring-proposed -Q unapproved reject -m 'requested by mlankhorst; breaks nvidia-prime support' xorg-server12:59
cjwatsonwill do well enough12:59
=== mmrazik|afk is now known as mmrazik
=== mapreri_ is now known as mapreri
skaetstgraber,  cjwatson, infinity - my freenode password appears to need a reset - could one of you please edit the #ubuntu-release topic to indicate we're working towards Alpha 1 this week?14:02
=== cjwatson changed the topic of #ubuntu-release to: Ubuntu 13.04 and 12.04.2 released | Preparing Alpha 1 | Archive: open | Saucy Salamander Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
skaetThanks cjwatson :-)14:03
seb128cjwatson, click-package NEWed (sorry for the delay, still debugging gtk at the same time)14:09
=== soren_ is now known as soren
ogra_clickedy click ...14:10
=== LordOfTime is now known as LordOfTime|EC2
=== holmes.freenode.net changed the topic of #ubuntu-release to: Ubuntu 13.04 and 12.04.2 released | Archive: open | Saucy Salamander Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
cjwatsonseb128: cool, thanks14:17
skaetstgraber, my understanding from yesterday is you wanted to test the iso tracker will automatically create the milestone when the runs are triggered.   If that's not the case,  please let me know and I'll go in and add them now.14:22
* skaet figures that some of the flavors want to start testing14:23
stgraberskaet: nope, what I said yesterday is that I'll create the milestone when the first flavour needs it14:23
stgraberskaet: and so far nobody asked for their first alpha1 spin14:23
skaetstgraber, ah, my misunderstanding.14:23
stgraberskaet: also, can you provide me with a list of all products participating in the alpha1 so I can populate the manifest? currently all I have is a list of flavours14:23
skaetstgraber,  assume the same products as are produced in the dailies for the flavors for now.    We've heard back from kubuntu, lubuntu, ubuntukylin, ubuntu gnome14:27
skaetstgraber,  based on input from Riddell,  Kubuntu will just be desktop i386 and amd64 ( no active or other architectures this time around)14:55
stgraberskaet: ok14:56
skaetstgraber,  I'm worried that the process of requesting a build isn't well understood with the flavors right now,  the MilestoneProcess page still has reference to an initial set being produced, and then a mail out.14:57
xnoxstgraber: skaet: given that kde4libs on armhf got fixed, I thought there can be kubuntu+armhf something, unless we don't have any armhf kernel & X stacks left for a desktopy build.14:57
xnoxRiddell: ^14:58
skaetRiddell, ^^ you14:58
stgraberskaet: well, I quite clearly mentioned the new process as a reply to your e-mail to all flavour leads...14:58
skaets/you/you want ?/14:58
stgraberskaet: and mentioned it here a few times too (and in #ubuntu-quality), so if people haven't read any of that, ... their bad14:59
skaetstgraber,  yes. but given its Tuesday, and no requests have come in,  time to figure out the glitch14:59
Riddellxnox: yeah but it's pretty low priority for alpha 114:59
Riddellxnox: also it won't work same as it didn't for 13.04, ubiquity don't work in that mode for some reason I'm yet to debug15:00
skaetRiddell, are you waiting for anything, or do you want stgraber to kick the first set of builds off for your now?15:01
=== mmrazik is now known as mmrazik|afk
cjwatsonxnox: the armhf stack is still mid-build15:02
cjwatsonThough, admittedly, it should be sorted out by end of day or so15:03
Riddellskaet: I think lots of kde bits still need to get into -release15:08
skaetRiddell,  ack.15:09
Riddellskaet: calligra, kate, kde-baseapps, kde-workspace, kmix, ktp-text-ui, pykde4, rekonq15:11
phillwstgraber: has the fix for bug 1193526 hit the build area yet?15:33
ubot2Launchpad bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released] https://launchpad.net/bugs/119352615:33
gemaslangasek, cjwatson: hangout?15:34
cjwatsonyep, we're just finishing off a 1+!15:35
gemacjwatson: ack15:36
=== micahg_ is now known as micahg
stgraberphillw: I'm only doing builds and publishing for this alpha1, so you'll have to track bugs and package version yourself this time around15:56
stgraberphillw: (though I did take a look at that one and the answer is no, it's not in the release pocket yet)15:56
cjwatsonstgraber: ubiquity should have landed recently16:13
cjwatsonYep, looks like last publisher run16:13
cjwatsonSeveral additions of python3-* I've noticed in binary NEW lately :)16:14
=== mapreri is now known as Guest1288
phillwstgraber: hi, I'm sorry, you will have to be patient with me. I'm still learning (and my email system is currently down). We had the cron for lubuntu turned off last night. Can the images currently in 'daily' be copied over to 'alpha 1'. I'm not 100% sure if the ubiquity bug from the LiveCD warrants a re-spin of an alpha 1 for lubuntu, I'll ask the other testers this evening (we have a lubuntu meeting tonight). If it does, I'll mark the desktop16:25
cjwatsonphillw: I would say it probably does - it means you can't start the live installer from the desktop, which is pretty confusing16:28
stgraberphillw: copied16:29
phillwcjwatson: that is a moot point, as we have recently included ZRam to reduce the memory size of a desktop install from the CD. Launching a live session and then installing does seem counter intuitive. But, I'm the new boy here and will go with your recommendation.16:30
cjwatsonzram doesn't really seem related to me.  One thing I've learned is that, even if it seems counterintuitive to me, if the facility's provided then people will try it :)16:31
cjwatson(I do think it's a useful facility; it lets you try the desktop out for a bit before deciding whether you want to install it.  That's why it's there)16:31
phillwokies, then stgraber can you respin desktop & upgrade and just copy over the alternate images.16:32
stgraberphillw: as I said earlier, I already copied everything. Please just mark those you want respin on the tracker16:32
phillwthanks, will do :)16:32
phillwstgraber: the upgrade ones aren't on there... are they handled differently?16:33
cjwatsonupgrade isn't a "respin" FWIW16:34
cjwatsonno spin involved :)16:34
phillwstgraber: status updated16:35
cjwatsonit's just a marker every so often for people to submit upgrade tests16:35
seb128could somebody let gnome-session migrate from proposed to release?16:42
seb128the current release version segfaults if one of the autostart services fails to start which is letting some users without a working session16:43
seb128the fix is a one liner, it would be good to get it in today rather than after a116:43
cjwatsonit should happen automatically16:43
Laneyyeah, it's not blocked; see excuses16:43
cjwatsonI don't particularly know why it isn't frozen (Riddell, aren't we releasing Ubuntu GNOME on Thursday?), but it isn't16:44
seb128ok, I was not sure how much is blocked with e.g Ubuntu GNOME16:44
cjwatsonRiddell: which images did you take as input for the block?16:44
stgrabercjwatson: hmm, could it be that our lock file under /srv/cdimage.ubuntu.com/etc/.lock-build-image-set isn't per-architecture?16:44
cjwatsonstgraber: It's not meant to be16:44
cjwatsonOh, I'm thinking of sem-16:45
LaneyI thought Riddell's block was just for Kubuntu16:45
cjwatsonwish that had been clear!16:45
cjwatsonRiddell: I thought you were acting for the release team and not just for Kubuntu16:45
knomeskaet, stgraber, cjwatson: if the xubuntu installer bug is fixed, we're in for A116:45
skaetthanks knome16:45
Laneyr188 commit message confirms that16:46
cjwatsonstgraber: I think it probably isn't per-architecture, no.  I didn't really expect that people would be building different arches for the same thing in parallel16:46
cjwatsonSigh.  Can somebody get a block generated and in place ASAP before there's further interaction with auto-sync?16:46
cjwatsonknome: If you mean bug 1193526, it should be16:47
ubot2Launchpad bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released] https://launchpad.net/bugs/119352616:47
knomecjwatson, i've no idea (i was just told there was some critical one), but i suppose it's that :)16:47
stgrabercjwatson: so my code isn't terribly clever in that regard. I basically pull builds from the rebuild queue, get one per architecture, build that and start again, which means that I always set ARCHES=<single arch> even if I'm building the same product for multiple arches at the same time16:48
cjwatsonstgraber: Hm, that's not the expected model and it will be rather less efficient - is there any way you could aggregate instead?16:48
skaetknome,  https://launchpad.net/bugs/1193526 is the one that Lubuntu was waiting on.16:48
ubot2Ubuntu bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released]16:48
cjwatsonstgraber: That also means all the different architectures get different build IDs but the later ones will copy the earlier ones over - in fact, since they're published to the same directory, that's why lock-build-image-set *can't* be per-architecture16:49
cjwatsonstgraber: I think you need to fix this, sorry :)16:49
knomeskaet, ok :) that sounds "correct"16:49
jbichaubuntu-gnome doesn't have its own packageset yet if that's what you're using to figure out the blocks16:49
cjwatsonjbicha: the procedure was to grab .manifest and .list, collect binary packages, map to source packages16:49
cjwatsonso based on images not packagesets16:50
stgrabercjwatson: hmm, yeah, ok, I'll have that be per-project then, will be less efficient from a buildd usage point of view though16:50
cjwatsonYou don't need to go as coarse-grained as that - it can be per-project/series/image-type combination16:51
cjwatsonWhich often winds up distributing fairly well since ARM often has different image-types16:51
cjwatson$ bzr ci -m 'Make ubuntu/saucy/daily-live and ubuntu-server/saucy/daily current symlinks trigger-controlled on amd64 and i386.'17:01
cjwatsonplars: ^-17:01
cjwatsonHopefully that should work as of the next run ...17:01
plarscjwatson: awesome :)17:01
cjwatsonOh, glib2.0 is blocked, that would need to be unblocked for gnome-session17:02
cjwatsonstgraber: Do you think unblocking glib2.0 is OK?17:03
cjwatsonwith respect to builds in progress17:03
cjwatsonchangelog looks reasonable though I haven't checked what's in the new upstream17:03
Laneyshould be alright17:04
stgrabercjwatson: there's currently no build in progress, I'm changing my script17:04
LaneyI wouldn't say I'm confident that my new autopkgtest will pass though :-)17:04
cjwatsonHm, it's unfortunate that autopkgtests aren't run for blocked packages17:06
jbichaI'd really like to have the new libsignon-glib for Ubuntu GNOME Alpha1; it's seeded by almost every flavor though17:06
* cjwatson unblocks17:07
Laneygreat, that means I don't have to figure out why gtk+3.0 claims to be blocked on glib2.017:08
cjwatsonPresumably bumped shlibs?17:08
Laneyit's symbols and the deps don't seem to be versioned17:09
Laneyobviously missing something17:09
knomeskaet, FYI, elfy/hobgoblin is now the xubuntu QA lead and also part of the xubuntu release team, so feel free to turn to him if i'm not around17:11
knome^ same goes for all release team, but i think most of you know that already17:11
stgraberrunning: http://paste.ubuntu.com/5799101/17:12
stgrabercjwatson: so my code is very very stupid at the moment, it groups by project+build-type, builds the first, the goes to the next. I'll need to teach it about being able to run non-live builds in parallel and find cases where we have no arch overlap between two sets and so can be parallelized (I could also just start everything and not care, leaving the locks deal with the mess)17:14
cjwatsonYou can start live builds in parallel too, if you like - they'll just block17:16
cjwatsonI think I've made proposed-migration start autopkgtests even for blocked packages now ...17:17
skaetstgraber,  re your paste,   I thought Edubuntu wasn't participating.   Has this changed?17:25
stgraberskaet: no, still not participating. Doesn't prevent us from triggering rebuilds through the tracker17:26
cjwatsonkde-workspace seems to have a real build failure on armhf17:27
cjwatson(double vs. qreal, at a very brief glance?)17:27
stgrabercjwatson: I think I'll update my code to go with the "just start everything in parallel and wait for things to settle", that's the most efficient thing I can do without having to add a ton of logic.17:28
cjwatsonGood, autopkgtests for packages that are only ineligible due to blocks seem to be working now17:28
cjwatsonstgraber: I think that was what I expected you to do :)17:28
* Laney just got an ENOSPC from jenkins when converting the image17:29
slangasek"converting the image"?17:30
Laneywell, whatever it's doing when it says qemu-img: /dev/shm/adt/saucy-amd64-glib2.0-20130625_172110.nMTaJv.img: error while creating qcow2: No space left on device17:30
slangasekis it Laney's fault that I'm receiving adt failure mails with ENOSPC?17:30
LaneyThat can't be my fault :P17:30
cjwatsonGlad somebody's receiving them17:31
skaetstgraber, ack.17:31
cjwatsonHmm.  I wonder if failed autopkgtests are not being remembered properly17:31
cjwatson16:08:48.log:I: [Tue Jun 25 16:13:44 2013] - Requested autopkgtest for software-properties_0.92.2117:32
cjwatson16:08:48.log:I: [Tue Jun 25 16:14:07 2013] - Collected autopkgtest status for software-properties_0.92.21: RUNNING17:32
cjwatson17:09:16.log:I: [Tue Jun 25 17:12:53 2013] - Collected autopkgtest status for software-properties_0.92.21: FAIL17:32
cjwatsonBut now no mention of it17:32
slangasekjibel, retoaded: ^^ what's going on with space on jenkins?17:35
slangaseke.g., https://jenkins.qa.ubuntu.com/job/saucy-adt-pango1.0/29/ARCH=amd64,label=adt/console17:35
* Laney has generated a massive block17:35
cjwatsonjibel: Am I meant to store pass/fail results retrieved from adt-britney collect and map them onto the requesting package myself?17:35
cjwatsonI think I must be.  I do have all the state ...17:36
cjwatsonLaney: No way I'm reviewing that :)17:37
cjwatsonDo sort it though, please17:37
LaneyThat's ubuntu-gnome lubuntu xubuntu. Did I miss any?17:37
skaetkylin is participating17:42
Laneyok, here goes17:42
retoadedslangasek, it's not an issue with space on jenkins but in the shared memory on albali (where the job is being run).17:49
slangasekretoaded: hmm, alright.  So is this being worked on, and can we expect these jobs to start running normally again soon?17:58
=== mapreri_ is now known as mapreri
retoadedslangasek, there is a build currently running on the jenkins node albali that is consuming a large portion of the memory. It started an hour and 40 minutes ago with no estimated time of completion.18:00
retoadedWhen it completes the memory should be freed up.18:01
slangasekwill the adt jobs be retried automatically?18:01
retoadedthat would be more of a jibel question.18:02
retoadedfwiw, i plan on heading over to 1SS later this afternoon and it might help this situation of I shut down albali and add more memory (it's on my list of to do's anyway)18:03
jibelcjwatson, no, collect is supposed to do that18:07
jibelslangasek, retoaded I'll take care of albali, jobs will be retried.18:08
slangasekjibel: ok, thanks18:09
slangasekjibel: is this a problem that we have to worry about recurring in the future?18:09
retoadedjibel, do you want me to add another 32GB RAM to albali when I head over later today?18:09
cjwatsonjibel: I think what I mean is, is collect supposed to keep them around?  At the moment it seems to archive them once it considers the job done, but proposed-migration is going to keep trying as long as the triggering package is a candidate18:09
jibelslangasek, no it's because I increased disk size of the VMs for libreoffice to the limit of what can be supported, I'll reduce it to again and do something specific for LO18:11
rtg_can the Nexus kernels be promoted ? I don't think they'll have an impact on any alpha milestones. linux-{grouper,maguro,mako,manta}18:55
infinityrtg_: They don't have any blocks, AFAIK, they should auto-promote fine once they're all build and such.18:55
rtg_infinity, k18:55
jbichacan libsignon-glib be unblocked?19:22
stgrabercjwatson: just landed an update to the self-rebuild code, we now have different status codes for: requested, queued, building, built, published and canceled (instead of just requested, building, published and canceled)19:26
stgrabercjwatson: so the plan is for my script to run every couple of minutes, take anything in requested state moved them to queued and spawn the rebuild commands, then have the build code move it to building when it actually starts, built when its done building and the tracker will move to published once post-qa is done for the whole set.19:27
stgraberthat should give us proper per-product state and timing instead of the current rather vague "it's building" status which may take several hours depending on what else is going on on nusakan19:28
* stgraber gets back to adding the required code for the building and built status handling19:29
=== mapreri_ is now known as mapreri
=== vanhoof_ is now known as vanhoof
=== seb128_ is now known as seb128
stgraberto anyone who'll be getting the failure e-mail, yes I broke nusakan, fix in progress21:31
=== seb128_ is now known as seb128
* Laney force-autopkgtests glib21:36
stgraberlooks like I fixed it or at least changed it in a way that takes longer to fail21:36
LaneyI'll finish packaging the proper test runner and upload that again some point soon21:36
=== seb128_ is now known as seb128
infinitystgraber: "... or at least changed it in a way that takes longer to fail"21:43
infinitystgraber: Reminds me of every time I cheered while porting glibc 2.16/2.17 to freebsd and I thought I'd won.21:44
cjwatsonI see uninstallables are down to a happier level.21:44
=== seb128_ is now known as seb128
infinitycjwatson: I'm assuming making kde4libs build on armhf helped that a little.21:45
cjwatsonIt took a stack above that too, but yes21:47
xnoxcjwatson: britney now handling removals as well? "Removing packages left in testing for smooth updates (2):"21:49
cjwatsonxnox: It thinks it does, but they don't actually get removed21:50
cjwatsonNot worth disabling the analysis step :)21:50
xnoxAh... joy =)21:51
* cjwatson makes http://people.canonical.com/~ubuntu-archive/proposed-migration/log/ exist, for possibly easier debugging in some cases23:58
stgrabercdimage people: I have now added the self-builds to cron, every 5min nusakan will look for new build requests and process them. If you see something going wrong, please disable from cron and ping me about it.23:59
cjwatson(I don't recommend you stare at it unless you're debugging britney itself, or maybe hints or auto-package-testing - for ordinary package handling the update_excuses and update_output files should be enough23:59
cjwatsonstgraber: *shiver* :)23:59

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