[00:50] Oh look. Linux 3.10. [00:51] apw: ^-- I'm assuming no one minds if we don't let that migrate until after the alpha? [00:51] c'mon, what could go wrong? [00:52] bjf: Nothing, the kernel team is perfect, and a beacon of light and hope to the world. [00:52] infinity, exactly, we exhaustively tested it, there are no bugs in it [00:53] bjf: Oh, if there are no bugs, then that's cool. [00:57] but then, i only care about stable :-) [06:20] thanks a lot infinity :) [07:58] it seems rtg's upload yesterday missed the fix for the autopkgtest definitin [07:58] definition, should i fix and re-upload or shall we 'ignore' it as previously [07:59] apw: 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] infinity, heh no indeed [07:59] apw: So, you have until thursday/friday to upload a new one if you want, no rush. [08:00] infinity, may as well upload a new one then, to confirm that autopkgtest sorts itself out [08:00] infinity, though i guess i don't want to ram the buildds ... [08:01] apw: Meh, the buildds are fine, as long as you don't upload 8 kernels in an hour for 5-character fixes. [08:05] infinity, this will be one in an hour for a 10 character fix, sigh [08:05] apw: You keep strange time. Tim's upload was ~12h ago. [08:06] infinity, :) [09:07] infinity: 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-0ubuntu1 [09:08] * xnox goes to figure out why my saucy box has raring-proposed enabled.... [09:08] xnox: hum, that's a good point, I thought about same release day release and thus, this appending of ~13.04… [09:09] but yeah, there is a versionning issue in that case, I need to think about it [09:09] didrocks: I mean the quick solution is to force release/bump version numbers in saucy. [09:09] xnox: well, we are going to have a release today once the tests failing are fixed [09:09] didrocks: or have saucy bump "upstream" version number, with each ubuntu series. [09:10] didrocks, including compiz? [09:10] xnox: bump it's difficult when you have 90 components to have upstream bumping their version and all them agrees :) [09:10] seb128: not today, but in the coming week normally [09:10] cool [09:10] there is one regression with compiz trunk they need to fix [09:10] (Qt apps behind the top panel) [09:10] I was not sure how much that one was on the "it works, don't touch it" state [09:10] ;-) [09:10] didrocks: hehe. Always encode "13.10" before date? [09:11] yeah for even longer version number? [09:11] seb128: seems that would be the road… [09:11] xnox: thanks for the pointer, noting it and will deal with it [09:12] didrocks: 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] didrocks, yeah, sort of make sense ... if we want shorter versions we should just drop the "daily" part, but that's another "battle" [09:12] if only upstream fixed their tests everyday or their FTBFS, we won't have this issue [09:12] xnox: yep, I just want to avoid that issue if possible ^ [09:12] seb128: I tried starting that one :) [09:13] seb128: but it's a very very long term plan :p [09:13] didrocks: 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] infinity: they don't match, but that's why for SRUs you have ~13.04 [09:13] so that you don't have in raring and saucy 2 0.3.6daily13.06.19-0ubuntu1 [09:13] with different content [09:13] But that's not what ~foo means. It doesn't mean "this is completely different, but the same version". :P [09:14] At least, not to most people. [09:14] infinity: well, suggestions welcomed :) [09:14] I expect my 1.2.3-4 and 1.2.3-4~foo to be basically the same thing. [09:14] to cope with autobumping, upstream merger, and all those use case, with transitionning, having the same version in both saucy and raring [09:14] If they're two different upstream branches, the upstream versions should really reflect that better. [09:14] while keeping when upstream doesn't bump to have raring > saucy [09:15] oupss < [09:15] infinity: go convince for those 90 components :p [09:15] I don't see how that's hard... [09:15] Surely, they're all versioned simply enough that one can bump at least a minor/micro or something. [09:15] infinity: please open a discussion with PS, I already tried it… [09:16] They used to bump versions on new series before this daily landing stuff... [09:16] We got a new unity with every series. [09:16] infinity: unity, yeah, not for all components [09:16] they should probably just do "serie.date" [09:16] 13.10.06.25 [09:17] Yeah, if they don't care about strict and sane branch-based versioning, just using the series number would work. [09:18] seb128: well, you know I've already proposed that [09:19] didrocks, right, that's why I wrote "that's another battle" ;-) [09:19] we could do the other way around, but the issue to do with . is that sometimes, they add a micro version (so an extra digit) [09:19] didrocks, but eventually we will get there [09:19] seb128: I completely hope so :) [09:20] didrocks: So, why is it daily~series intead of daily~date? [09:21] didrocks: 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] infinity: because wasn't thought at first, and you were complaining about version too long already :) [09:21] infinity: so that's why I only added it once we entered maintainance mode [09:21] didrocks: Yeah, the versions are insane (and the "daily" string is redundant). [09:22] * xnox thinks we are now past the point of caring of how long it is ;-) [09:22] I think we all agree here on that [09:22] didrocks: Heck, the date part itself might be pointless. [09:22] infinity: again, will be pleased with a solution dealing with upstream's realities [09:22] didrocks: It could just be +. where 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:23] where int, is bzr revno [09:23] xnox: Or that. [09:23] xnox: I prefer date, it's more meanfull, especially with feature branch that are running in parallel [09:23] xnox: otherwise, we won't be able to remerge [09:23] infinity: the date does give _some_ alignment though - e.g. everything is up to date. [09:24] infinity: so you do expect that + to be different upstream content than + [09:24] xnox: And that would be relevant, if the other 6000 packages on your system also showed the date in dpkg -l [09:24] didrocks: 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] infinity: touche [09:25] didrocks: But it's saner for YOU to do + instead of + and tack series on as an afterthought, cause mine sorts correctly. :P [09:26] Sadly, this probably can't be changed for raring now (though, dpkg --compare-versions may tell me otherwise, let's see...) [09:26] infinity: I tried with dpkg --compare-versions and it seems fine [09:26] Oh, wait. Yay. [09:26] (base)adconrad@cthulhu:~$ dpkg --compare-versions 0.3.2+13.04 gt 0.3.2daily13.06 && echo Yes [09:27] Yes [09:27] So, yeah. That could work quite nicely. [09:27] infinity: ok, I'll implement that then [09:27] let me try some other cases [09:27] with features branch in particular [09:27] (which have another versionning to deliver in a ppa, while still being compatible with distro once merged back) [09:27] Fun. [09:28] I don't envy your life. [09:28] isn't it? :) [09:28] ahah [09:28] if it works, I'll handle the transition the sanest possible way [09:28] this means that upstream shouldn't use + in the upstream versionning [09:28] Also, 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. :P [09:28] which isn't unreasonable to ask :) [09:28] infinity: well, we can add the revno in the version, but that would be in addition to the date [09:29] so I don't think you want it :p [09:29] I was thinking instead of the date. [09:29] But yeah, I don't want both. [09:29] not possible again because of feature branch [09:29] Cuase I think date.date is CONFUSING. [09:29] having different revision meaning other things [09:29] Well, if you use datestamps instead of dates-as-versions, it's a bit less confusing. [09:30] datestamps? [09:30] infinity: what about 0.3.2+13.04+13.06.03 for instance? (two +, but at least, more readable) [09:30] Like, 0.3.6+13.04.20130627 is less confusing than 0.3.6+13.04.13.06.27 where we have a repeating thirteen dot oh something. [09:31] yeah, that as well [09:31] then still .1, .2, .3 [09:31] if we rerelease the same day? [09:31] Sure, yeah. Same as we date stamp ISOs. [09:31] I'm good with this schema [09:31] let me ensure all corner cases are tackled [09:31] and I'll work on this this week [09:32] I hate to bikeshed abot versions, but yeah, the current ones are wrong from sort order perspective, and just plain ugly. :) [09:32] And the "daily" thing is off-putting, especially for SRUs. [09:33] Nothing instills confidence in your stable updates like a daily snapshot. :) [09:33] infinity: 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] infinity: well, on the contrary, we never had that much confidence thanks all the testing that is done automatically on a daily basis :) [09:34] * didrocks wonders if there is a tool somewhere to convert a code name is stable release series version [09:35] didrocks: I'm not saying that internally it's not better, just that externally, "daily" and/or "snapshot" are scary words. :) [09:36] yeah, I understand :) [09:37] didrocks: I failed to parse that sentence.. [09:38] didrocks: 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:39] didrocks: Of course, you could write one with distro-info-data. [09:39] didrocks: /usr/share/distro-info/ubuntu.csv has what you're after. [09:40] infinity: ah, excellent, yeah, will use that one, better than querying launchpad for that :) [09:41] Riddell,ScottK: There seems to be no migration block yet? [09:42] Or is somebody else doing it? [09:42] cjwatson: I'm wondering the best way to do it [09:42] cjwatson: i.e. best way to find the list [09:42] cjwatson: is getting the source packages from the germinate output the best? [09:42] ScottK has done it in the past, I think. I don't recall exactly what he did [09:42] Might be a case of trawling through IRC logs ... [09:44] http://irclogs.ubuntu.com/2012/12/05/%23ubuntu-release.html [09:45] ah yes, the .sources files would be easier [09:46] http://irclogs.ubuntu.com/2012/12/05/%23ubuntu-release.html#t14:04 [09:46] Has what's actually a better option [09:46] Take .manifest and .list from images, munge until you get a list of binary packages, map to corresponding source packages [09:47] (You probably want to wait for the new kde4libs to finish and get through) [09:47] Though, I guess you can unblock just that version after doing the generic block. [09:48] that was my next question, there's a bunch of things still needing to get in, does an unblock override a block? [09:48] Yes. [09:51] bzr di -c58 lp:~ubuntu-release/britney/hints-ubuntu if you want the list for raring beta-1 === doko_ is now known as doko [09:56] cjwatson: that should be the block in place [09:58] that was quick, thanks :) [09:58] I'll watch it actually work once before starting auto-sync [10:07] cjwatson: what does it mean if an autopkgtest is running? [10:07] e.g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-baseapps says autopkgtest for pango1.0 1.32.5-5ubuntu1: RUNNING [10:07] vast confusion because I haven't worked it out yet [10:07] why does a test for pango affect kde-baseapps? [10:09] I think it's a known problem with excessive following of virtual packages [10:09] libpango1.0-doc Depends: www-browser, konqueror Provides: www-browser [10:10] jibel mentioned that as a known issue when fixing the converse problem (deps on virtual packages not being noticed at all) [10:11] looks like it might actually genuinely have been running and so should clear soon [10:11] perhaps I should make force imply force-autopkgtest [10:13] It was non-genuinely RUNNING but jibel was looking into that [10:13] maybe this new run will clear it out indeed [10:14] there was a run recently enough that it's plausible [10:14] Anyway, force implies force-autopkgtest now [10:48] Riddell: Could you please add versions to all your unblocks? The syntax is "unblock SRC/VER" [10:48] cjwatson: ah gotcha [10:48] unfortunately the bad syntax crashes proposed-migration - I should fix that [10:53] oops sorry [10:54] I think I've fixed the crash now [11:02] didrocks: it would make sense to enhance distro-info to convert codenames into version and vice versa [11:03] bdrung: 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 saucy [11:04] cjwatson: 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:05] didrocks: distro-info needs to learn the freeze date for this use case [11:06] bdrung: 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] didrocks: mail technical-board@ please [11:07] I will forget [11:10] cjwatson: not sure it worths mentionning TBH, an external ppa shouldn't infer the TB decision for distro [11:11] s/infer/impact/ [11:14] infinity: you're a genius, kde4libs compiled [11:15] I'm retrying some associated failed builds now [11:15] thanks [11:16] infinity: what kind of storage does that pandaboard have? I tried on mine and it ran out of disk space (4GB SD card) [11:20] Riddell: I think they build onto USB drives [11:23] infinity: xnox: seb128: and here we go! http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/330 [11:23] I'll deploy that today [11:26] schedule amended to move DIF to week 13; mail sent to ubuntu-release@; auto-sync running === ara is now known as Guest5314 [11:34] [Updating] requests (1.2.0-2 [Ubuntu] < 1.2.3-1 [Debian]) [11:34] oops, echan [11:44] hmm, arm fail https://launchpadlibrarian.net/143356647/buildlog_ubuntu-saucy-armhf.kamera_4%3A4.10.80-0ubuntu1_CHROOTWAIT.txt.gz [11:44] better to link to the +build, then we can tell which builder it is [11:45] heka [11:45] reported to ops [11:45] and heka on manual [11:48] I've retried all heka's failures [12:52] Anyone fancy processing click-package in NEW? [12:52] cjwatson: can you wipe xorg-server from raring unaccepted? === mmrazik is now known as mmrazik|afk [12:56] mlankhorst: I'll have to give a reason, so if you can give me one, that'd be good [12:56] will regress [12:56] it needs another fix because a regression was found when it was uploaded to saucy, sec let me get bug # [12:57] hm doesn't seem to be one, but it broke nvidia prime support, unless another patch was also applied on top [12:58] cjwatson, let me have a look [12:59] $ queue -s raring-proposed -Q unapproved reject -m 'requested by mlankhorst; breaks nvidia-prime support' xorg-server [12:59] will do well enough [13:00] (done) [13:00] thanks === mmrazik|afk is now known as mmrazik === mapreri_ is now known as mapreri [14:02] stgraber, 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? === 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 [14:03] there [14:03] Thanks cjwatson :-) [14:09] cjwatson, click-package NEWed (sorry for the delay, still debugging gtk at the same time) === soren_ is now known as soren [14:10] clickedy click ... === 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 [14:17] seb128: cool, thanks [14:22] stgraber, 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:23] * skaet figures that some of the flavors want to start testing [14:23] skaet: nope, what I said yesterday is that I'll create the milestone when the first flavour needs it [14:23] skaet: and so far nobody asked for their first alpha1 spin [14:23] stgraber, ah, my misunderstanding. [14:23] skaet: 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 flavours [14:27] stgraber, assume the same products as are produced in the dailies for the flavors for now. We've heard back from kubuntu, lubuntu, ubuntukylin, ubuntu gnome [14:55] stgraber, based on input from Riddell, Kubuntu will just be desktop i386 and amd64 ( no active or other architectures this time around) [14:56] skaet: ok [14:57] stgraber, 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] stgraber: 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:58] Riddell: ^ [14:58] Riddell, ^^ you [14:58] skaet: well, I quite clearly mentioned the new process as a reply to your e-mail to all flavour leads... [14:58] s/you/you want ?/ [14:59] skaet: and mentioned it here a few times too (and in #ubuntu-quality), so if people haven't read any of that, ... their bad [14:59] stgraber, yes. but given its Tuesday, and no requests have come in, time to figure out the glitch [14:59] xnox: yeah but it's pretty low priority for alpha 1 [15:00] xnox: 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 debug [15:00] ack [15:01] Riddell, are you waiting for anything, or do you want stgraber to kick the first set of builds off for your now? === mmrazik is now known as mmrazik|afk [15:02] xnox: the armhf stack is still mid-build [15:03] Though, admittedly, it should be sorted out by end of day or so [15:08] skaet: I think lots of kde bits still need to get into -release [15:09] Riddell, ack. [15:11] skaet: calligra, kate, kde-baseapps, kde-workspace, kmix, ktp-text-ui, pykde4, rekonq [15:12] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [15:13] thanks [15:33] stgraber: has the fix for bug 1193526 hit the build area yet? [15:33] Launchpad bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released] https://launchpad.net/bugs/1193526 [15:34] slangasek, cjwatson: hangout? [15:35] yep, we're just finishing off a 1+! [15:35] 1+1 [15:36] cjwatson: ack === micahg_ is now known as micahg [15:56] phillw: I'm only doing builds and publishing for this alpha1, so you'll have to track bugs and package version yourself this time around [15:56] phillw: (though I did take a look at that one and the answer is no, it's not in the release pocket yet) [16:13] stgraber: ubiquity should have landed recently [16:13] Yep, looks like last publisher run [16:14] Several additions of python3-* I've noticed in binary NEW lately :) === mapreri is now known as Guest1288 [16:25] stgraber: 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 desktop [16:28] phillw: I would say it probably does - it means you can't start the live installer from the desktop, which is pretty confusing [16:29] phillw: copied [16:30] cjwatson: 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:31] zram 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] (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:32] okies, then stgraber can you respin desktop & upgrade and just copy over the alternate images. [16:32] phillw: as I said earlier, I already copied everything. Please just mark those you want respin on the tracker [16:32] thanks, will do :) [16:33] stgraber: the upgrade ones aren't on there... are they handled differently? [16:34] upgrade isn't a "respin" FWIW [16:34] no spin involved :) [16:34] thanks. [16:35] stgraber: status updated [16:35] it's just a marker every so often for people to submit upgrade tests [16:42] could somebody let gnome-session migrate from proposed to release? [16:43] the current release version segfaults if one of the autostart services fails to start which is letting some users without a working session [16:43] the fix is a one liner, it would be good to get it in today rather than after a1 [16:43] it should happen automatically [16:43] yeah, it's not blocked; see excuses [16:44] I don't particularly know why it isn't frozen (Riddell, aren't we releasing Ubuntu GNOME on Thursday?), but it isn't [16:44] ok, I was not sure how much is blocked with e.g Ubuntu GNOME [16:44] Riddell: which images did you take as input for the block? [16:44] cjwatson: hmm, could it be that our lock file under /srv/cdimage.ubuntu.com/etc/.lock-build-image-set isn't per-architecture? [16:44] stgraber: It's not meant to be [16:45] Oh, I'm thinking of sem- [16:45] I thought Riddell's block was just for Kubuntu [16:45] argh [16:45] wish that had been clear! [16:45] Riddell: I thought you were acting for the release team and not just for Kubuntu [16:45] skaet, stgraber, cjwatson: if the xubuntu installer bug is fixed, we're in for A1 [16:45] thanks knome [16:46] r188 commit message confirms that [16:46] stgraber: 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 parallel [16:46] Sigh. Can somebody get a block generated and in place ASAP before there's further interaction with auto-sync? [16:47] knome: If you mean bug 1193526, it should be [16:47] Launchpad bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released] https://launchpad.net/bugs/1193526 [16:47] cjwatson, i've no idea (i was just told there was some critical one), but i suppose it's that :) [16:48] cjwatson: 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= even if I'm building the same product for multiple arches at the same time [16:48] stgraber: Hm, that's not the expected model and it will be rather less efficient - is there any way you could aggregate instead? [16:48] knome, https://launchpad.net/bugs/1193526 is the one that Lubuntu was waiting on. [16:48] Ubuntu bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released] [16:49] stgraber: 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-architecture [16:49] stgraber: I think you need to fix this, sorry :) [16:49] skaet, ok :) that sounds "correct" [16:49] ubuntu-gnome doesn't have its own packageset yet if that's what you're using to figure out the blocks [16:49] jbicha: the procedure was to grab .manifest and .list, collect binary packages, map to source packages [16:50] so based on images not packagesets [16:50] cjwatson: hmm, yeah, ok, I'll have that be per-project then, will be less efficient from a buildd usage point of view though [16:51] You don't need to go as coarse-grained as that - it can be per-project/series/image-type combination [16:51] Which often winds up distributing fairly well since ARM often has different image-types [17:01] $ bzr ci -m 'Make ubuntu/saucy/daily-live and ubuntu-server/saucy/daily current symlinks trigger-controlled on amd64 and i386.' [17:01] plars: ^- [17:01] Hopefully that should work as of the next run ... [17:01] cjwatson: awesome :) [17:02] Oh, glib2.0 is blocked, that would need to be unblocked for gnome-session [17:03] stgraber: Do you think unblocking glib2.0 is OK? [17:03] with respect to builds in progress [17:03] changelog looks reasonable though I haven't checked what's in the new upstream [17:04] should be alright [17:04] cjwatson: there's currently no build in progress, I'm changing my script [17:04] I wouldn't say I'm confident that my new autopkgtest will pass though :-) [17:06] Hm, it's unfortunate that autopkgtests aren't run for blocked packages [17:06] I'd really like to have the new libsignon-glib for Ubuntu GNOME Alpha1; it's seeded by almost every flavor though [17:07] * cjwatson unblocks [17:07] (glib2.0) [17:08] great, that means I don't have to figure out why gtk+3.0 claims to be blocked on glib2.0 [17:08] Presumably bumped shlibs? [17:09] it's symbols and the deps don't seem to be versioned [17:09] obviously missing something [17:11] skaet, 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 around [17:11] ^ same goes for all release team, but i think most of you know that already [17:12] running: http://paste.ubuntu.com/5799101/ [17:14] cjwatson: 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:16] You can start live builds in parallel too, if you like - they'll just block [17:17] I think I've made proposed-migration start autopkgtests even for blocked packages now ... [17:25] stgraber, re your paste, I thought Edubuntu wasn't participating. Has this changed? [17:26] skaet: no, still not participating. Doesn't prevent us from triggering rebuilds through the tracker [17:27] kde-workspace seems to have a real build failure on armhf [17:27] (double vs. qreal, at a very brief glance?) [17:28] cjwatson: 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] Good, autopkgtests for packages that are only ineligible due to blocks seem to be working now [17:28] stgraber: I think that was what I expected you to do :) [17:29] * Laney just got an ENOSPC from jenkins when converting the image [17:30] "converting the image"? [17:30] well, 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 device [17:30] is it Laney's fault that I'm receiving adt failure mails with ENOSPC? [17:30] That can't be my fault :P [17:31] Glad somebody's receiving them [17:31] stgraber, ack. [17:31] Hmm. I wonder if failed autopkgtests are not being remembered properly [17:32] 16:08:48.log:I: [Tue Jun 25 16:13:44 2013] - Requested autopkgtest for software-properties_0.92.21 [17:32] 16:08:48.log:I: [Tue Jun 25 16:14:07 2013] - Collected autopkgtest status for software-properties_0.92.21: RUNNING [17:32] 17:09:16.log:I: [Tue Jun 25 17:12:53 2013] - Collected autopkgtest status for software-properties_0.92.21: FAIL [17:32] But now no mention of it [17:35] jibel, retoaded: ^^ what's going on with space on jenkins? [17:35] e.g., https://jenkins.qa.ubuntu.com/job/saucy-adt-pango1.0/29/ARCH=amd64,label=adt/console [17:35] * Laney has generated a massive block [17:35] jibel: Am I meant to store pass/fail results retrieved from adt-britney collect and map them onto the requesting package myself? [17:36] http://paste.ubuntu.com/5799165/ [17:36] I think I must be. I do have all the state ... [17:37] Laney: No way I'm reviewing that :) [17:37] Do sort it though, please [17:37] ok [17:37] That's ubuntu-gnome lubuntu xubuntu. Did I miss any? [17:37] kylin? [17:42] kylin is participating [17:42] ok, here goes [17:49] slangasek, it's not an issue with space on jenkins but in the shared memory on albali (where the job is being run). [17:58] retoaded: hmm, alright. So is this being worked on, and can we expect these jobs to start running normally again soon? === mapreri_ is now known as mapreri [18:00] slangasek, 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:01] When it completes the memory should be freed up. [18:01] hmm [18:01] will the adt jobs be retried automatically? [18:02] that would be more of a jibel question. [18:03] fwiw, 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:07] cjwatson, no, collect is supposed to do that [18:08] slangasek, retoaded I'll take care of albali, jobs will be retried. [18:09] jibel: ok, thanks [18:09] jibel: is this a problem that we have to worry about recurring in the future? [18:09] jibel, do you want me to add another 32GB RAM to albali when I head over later today? [18:09] jibel: 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 candidate [18:11] slangasek, 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 LO [18:11] ok [18:55] 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] rtg_: They don't have any blocks, AFAIK, they should auto-promote fine once they're all build and such. [18:55] s/build/built/ [18:55]