=== Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [08:44] good morning - please could the NEW binary package for maven-hpi-plugin be accepted into oneiric - then jenkins will build! - thanks [09:42] so seeing that the image builds fail since days because ubuntuone-client-gnome doesnt exist anymore in the archive, could we unseed it so we get working images again ? [09:59] hummm.... [09:59] and why doesnt it affect x86 and amd64 at all [10:08] cjwatson, i'm not sure i'm reading it wrong, but this log http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/current/livecd-20110811.1-i386.out looks seriously strange, it seems to install a good bunch of things from universe and i see things like thunar and mythbuntu packages being installed [10:16] hmm, looking closer i even see multiverse packages [10:25] ogra_, it affects alternate too, I filed bug 824418 [10:25] Launchpad bug 824418 in ubuntuone-client (Ubuntu Oneiric) (and 3 other projects) "oneiric alternate fails to install: ubuntu-desktop Recommends ubuntuone-client-gnome which is not installable (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/824418 [10:26] jibel, well, thats not as worrying as the x86 buildlog ... that one seems totally confused [10:26] will look in a bit, I have FF work ahead of this [10:26] on ubuntu live filesyswtems universe and multiverse are usually disabled [10:27] yes, I assume somebody has broken livecd-rootfs [10:27] jibel, i will unseed the pffending package temporary (since my FF work is blocked by unbuildable images atm) [10:27] cjwatson, well, i only added bits to the armel subarch check, that shouldnt affect x86 at all [10:28] * ogra_ re-checks his commits [10:28] or perhaps live-build I guess [10:29] though that seems less likely [10:30] I will concede that this is pretty odd ... [10:31] http://paste.ubuntu.com/663319/ is all i added [10:31] and thats all under the armel subarch check, i dont see how it could affect x86 [10:33] there is one followup commit by infinity but that doesnt seem to have been uploaded yet (and it doesnt touch the components) [10:33] quite so [10:34] and intrestingly all ports arches do look ok (modulo the build failure due to ubuntuone-client-gnome) [10:36] (i also think if my change was the offending one we wouldnt see multiverse in the log ... i dont enable it) [10:36] yeah, it doesn't look related to your change. [10:40] this broke between the 20110808.1 and 20110809 builds [10:41] oh, that predates all my work actually [10:42] yep [10:42] no live-build changes then either [10:42] yeah [10:45] was antimony upgraded ... so that an external app could have changed ? [10:46] livefs builds don't happen on antimony [10:46] they run in a chroot of the relevant release on dedicated buildds [10:46] the communication channel with antimony is very narrow [10:48] well, they are triggered by debian-cd [10:50] I am aware [10:50] (actually they're not, but that's terminology) [10:50] I'd rather investigate most plausible things first. [10:51] right, what i mean is that cdimage and debian-cd use bits and pieces from antimony to assemble the cmdlines [10:51] and i dont see a single commit either in debian-cd, the seeds or cdimage around the timeframe it broke [10:51] debian-cd is not itself involved *at all* in livefs building [10:52] it consumes the output, that's all [10:52] yeah, only post processing, i know ... [10:52] seeds are irrelevant [10:52] I agree there's nothing obvious in cdimage [10:52] and if the antimony side was broken, I expect that we would see even more obvious signs in the log [10:52] I really don't think this can be a problem on antimony, honestly [10:53] I am not going to investigate that [10:53] true [10:53] (unless I exhaust everything else) [11:08] lamont: are you around? I could use some debugging on the livefs buildds (if you aren't around, I'll just upload livecd-rootfs with debugging code in it, but would prefer not to) [11:09] cjwatson: here [11:10] please state the nature of the disfunction we are debugging [11:10] lamont: universe and multiverse showing up in Ubuntu livefs build logs, and I can't see whwy [11:10] interesting [11:11] lamont: could I have 'set -x' in /usr/share/livecd-rootfs/live-build/auto/config in cardamom's oneiric chroot, temporarily? [11:11] i386 being representative? [11:11] yep [11:11] there is more, it also doesnt seem to proceed the seeds correctly, i.e. unity-2d doesnt show up at all [11:11] ogra_: yeah, but one at a time. [11:11] sure :) [11:11] standard debugging practice, debug the first chronological failure first [11:11] otherwise you waste time [11:11] * ogra_ keeps quiet and lets you do the work then :) [11:13] jamespage: maven-hpi-plugin binaries accepted [11:13] livecd-rootfs isn't installed in the oneiric-live chroot... [11:13] wow [11:13] hah [11:13] live-build is [11:13] cjwatson: thankyou! [11:14] the only auto/config in live-build: /usr/share/live/build/examples/auto/config [11:14] lamont: how about in build-oneiric-live/chroot-oneiric? [11:14] that's where I'm looking [11:14] huh [11:15] can you tell when livecd-rootfs was removed? [11:15] I wonder if it got taken out by the apt transition [11:16] cjwatson: paste.ubuntu.com/663341 [11:17] haha [11:17] well played, apt [11:17] so python-apt was temporarily broken and we lost [11:17] I'm going to put a bit of extra safety into BuildLiveCD [11:17] +1 [11:17] in the meantime, can we have livecd-rootfs back in all the chroots? [11:17] well... ok [11:18] what about germinate? [11:18] livecd-rootfs will bring it all back [11:19] this will certainly explain seed processing problems, and it will also explain why the livefs outputs weren't in a place where antimony could grab them [11:20] haha. [11:20] heh [11:20] so... did the arm livecd builds fail, or work? [11:20] arm is fine [11:20] i got proper error logs [11:20] livecd-rootfs restored on i386,amd64,powerpc [11:20] arm had it already [11:20] livecd-rootfs 2.22 uploaded with the relevant fix [11:20] ppc looked fine too actually [11:20] regarding the logs at least [11:21] cjwatson: spare me the pain and point me at a copy of BuildLiveCD to blat out? [11:21] I was just going to RT it [11:22] sure [11:22] vanguard this week, yay me. [11:22] attach the file in the RT? [11:23] I did :) [11:23] https://rt.admin.canonical.com/Ticket/Display.html?id=47318 [11:24] maybe I should sleep in more. :( [11:24] thanks [11:24] diff should be http://paste.ubuntu.com/663350/ [11:25] +27000 [11:25] It is currently 15th in the queue of tickets assigned to the Vanguard. [11:25] and with that, afk for a few [11:26] thanks for the help [11:26] * cjwatson kicks off Ubuntu desktop livefs builds [11:27] could somebody process ntfs-3g through NEW? [11:52] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/20110811.2/livecd-20110811.2-i386.out more sensible failure now [11:54] yep, that looks like the usual error [11:55] i just uploaded a new meta that works around this [11:55] ok [12:46] Can you kick new xubuntu builds too for the desktop? No desktop images have built for Ubuntu or Xubuntu since monday [12:49] done === seb128_ is now known as seb128 === doko_ is now known as doko [13:59] The following packages have unmet dependencies: [13:59] ubuntuone-client-gnome : Depends: ubuntuone-client (= 1.7.0-0ubuntu2) but 1.7.1-0ubuntu1 is to be installed [13:59] RAAAH ! [13:59] * ogra_ checks rdepends [14:00] remember it installs the task, give it an hour or two to settle [14:00] well, meta was uploaded 3h ago [14:01] i missed and had to wait two publisher runs [14:02] err, 2h ago [14:03] That same package is causing Kubuntu PPC builds to fail. [14:03] * ScottK has no idea how it even gets involved. [14:03] well, on ubuntu it was seeded [14:03] ScottK: that's very likely due to the general insanity fixed this morning [14:03] I wouldn't worry about *that* part [14:04] i dropped it now, but something still seems to keep it there, i might have been to careful with my seed change [14:04] cjwatson: Good news. Thanks. [14:04] its Task field does seem to be gone [14:04] which build log were you quoting? [14:05] 11.1 from ac100 [14:05] ubuntu-ac100 [14:07] i'll wait 20min and try again [14:08] ah, ubuntuone-client-gnome still has Task: ubuntu-desktop on armel [14:08] perhaps because ubuntu-meta was slower to build [14:08] how can that be if i dropped it from desktop ? [14:08] ah [14:08] because it has to wait for ... right [14:08] i thought there is a secret arch related seed i dont know about ;) [14:09] ubuntu-desktop is in the desktop seed so its dependencies are pulled into the task [14:09] right [14:09] ports has the new ubuntu-desktop package already though [14:10] i specifically waited until it showed up in the pool, i would expect the same publisher run to clean the task, isnt that the case ? [14:10] yes, but it just missed the last publisher run, and task changes take an extra publisher run to settle. [14:10] ah [14:10] because there is hysteresis in the way that cron.publish-ftpmaster and cron.germinate are currently arranged [14:10] the germinate run at the end of a publisher run feeds into the next publisher run [14:10] right, i wasnt aware of that bit [14:10] it's a long-standing bug [14:11] (and the next publisher run has to have some work to do) [14:11] it'll be OK after the current publisher run completes, so for safety, say 30m [14:11] k [14:12] * ogra_ crosses fingers that nobody uploads unity or nux now :) [14:13] ogra_, cjwatson, ScottK, slangasek, pitti - heh, on that note, just a head's up that didrocks may miss the FF by a couple of hours due to the fact he's traveling today, and may not have enough connectivity en-route to get it uploaded. He's expecting to finish uploads as soon as he's home. [14:14] skaet: I'd suggest then moving the milestone back a few hours to match his requirements so others can keep working too. [14:14] given that I'm trying to test ubuntu-defaults-image with this syslinux-themes-ubuntu packaging, I'm not averse to a stable archive either just now [14:14] * cjwatson goes for a walk while it sits and churns [14:15] skaet, then i pray that his train is late ... to get the ac100 images working i need at least one output from the live builder, implementing it is a matter of 1-3h of work but to get to that point i already spend the third day fighting the archive skews [14:16] can't you build a reduced livefs for testing purposes? [14:16] say, just ubuntu-standard. that would be enough to do the scripting work [14:18] you could start that right away. [14:18] standard is recognized as a flavour ? [14:18] i tried -core yesterday but that isnt really designed to carry a kernel etc [14:18] * ogra_ checks [14:19] you could use ubuntu-server (= minimal + standard), and then just mangle things into place [14:19] or base which is like ubuntu-server without the preinstalled pool stuff [14:20] that will take longer than desktop to build with the new pool we ship on server [14:20] base then [14:20] i'll try base [14:20] cjwatson, ogra_, to keep the churn down (and improve the testing I suspect ;) ) do we want to ask him to do the drop tomorrow instead? That would give us an overnight set of builds before unity/nux hits, and give some breathing room on that dimension of churn? [14:20] and it shouldn't be about build time, it should be about probability of failure [14:20] skaet: I don't have an opinion on that [14:20] skaet, well, i expect to get a livefs today one way or the other [14:21] i dont want to block anyone, i'm trying with ubuntu-base now [14:21] cjwatson, ogra_ - ok. [14:21] hmm.... [14:22] ScottK, will get more details from didrocks and then look at adding a few more hours on. [14:25] skaet, didrocks is travelling still [14:26] skaet, he's on holiday starting tomorrow evening though, it might be better to still have him around for a day after the upload [14:26] seb128, agreed. As soon as he's in connectivity range, will get a revised ETA from him. [14:27] skaet, i.e if he uploads unity today and get issues he can fix those tomorrow, if he uploads tomorrow and that breaks it's likely nobody will be around during the w.e from dx to sort it and then somebody else from desktop will have to figure what didrocks and dx did [14:27] (yeah, I don't like uploads on fridays :p) [14:28] * ogra_ doesnt like uploads at all :P [14:39] why not just grant an exception for this upload? [14:39] Laney, because that would delay the upload until after didiers vacation i guess [14:42] I mean I don't get why we need to delay indefinitely [14:43] ?? [14:43] because didrocks is traveling and cant upload ... there is no other delay [14:43] delay the freeze [14:43] if it's just for one specific thing, just say that it is alright to do that [14:43] it os delayed ? [14:43] *is [14:44] that was the discussion [14:44] its not 18:00UTC yet :) [14:44] we can tell at 18:01 if it is i guess ;) [14:58] I don't know if anyone knows it, the respins all failed on the desktop images [14:59] Ubuntu has errors like [14:59] W: Unable to read /srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/apt/oneiric-amd64/apt/preferences.d/ - FileExists (2: No such file or directory) [14:59] and xubuntu has hash sum mismatches [14:59] that's a warning not an error [15:00] I'm afraid I don't have time to push images up the hill right now [15:00] Sorry, I guess the error really is [15:00] mv: cannot stat `/srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/tmp/oneiric-amd64/CD1/casper/filesystem.kernel-generic': No such file or directory [15:00] make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/tmp/oneiric-amd64/bootable-stamp] Error 1 [15:01] Okay, I will wait to request them again [15:01] ah, but thats alternate, 11.1 of xubuntu live built fine [15:01] no [15:01] actually, daily-live 11.1 failed to build [15:01] That was Ubuntu error [15:01] oh, sorry, i'm looking at the livefs build [15:02] Xubuntu shows W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-amd64/Packages.bz2 Hash Sum mismatch [15:02] many times for different files through the log [15:02] Oh, warnings again [15:03] that one probably does add up to a real error. [15:03] but there's nothing I can do short of repeatedly retrying it. [15:03] (which as I said I'm not going to do now, perhaps somebody else can) [15:03] Yeah, we can wait, since it will probably eventually fail for the same thing Ubuntu is failing for. [15:04] right, its apt-update thats failing according to the log [15:46] hmm, more reports about hash sum mistmatches with the archive [15:56] ScottK, have connected with didrocks. Consider the Feature Freeze time adjusted to 2100 UTC. [15:57] skaet: I think you should write to u-d-a. [15:57] Thanks. [15:58] ScottK, makes sense, will do. [15:58] Great. [16:20] pitti: I'm uploading fglrx-updates, nvidia-$flavour-updates and nvidia-settings-updates right now [16:44] I have now changed the driver for all stable releases to ubuntu-release, and verified that this does not regress the ability of a core-dev to target tasks to a stable release [16:46] skaet: my external memory in the form of bug 174375 and https://bugs.launchpad.net/launchpad/+bug/703002/comments/3 says that the next step is to add ~canonical-qa to ~ubuntu-release so that they can manage bug nominations without being in ubuntu-drivers. Are you OK with me making that change? [16:46] Launchpad bug 174375 in ubuntu-community (and 1 other project) "Distribution drivers permissions may need redesign (affects: 2) (dups: 1) (heat: 7)" [Medium,Confirmed] https://launchpad.net/bugs/174375 [16:46] cjwatson: Error: Bug #703002 is private. [16:47] * skaet looking [16:52] pitti: are you still around? [16:52] probably not.. [16:55] cjwatson, slangasek: can either of you approve my sources in NEW, please? nvidia-graphics-drivers-96-updates nvidia-graphics-drivers-173-updates, nvidia-graphics-drivers-updates, nvidia-settings-updates and fglrx-installer-updates [16:59] cjwatson, go ahead, it seems the most pragmatic approach for now. Lets see how it works out, and revisit if there are issues later. [17:02] tseliot: having a look, sure [17:02] slangasek: thanks [17:10] * ScottK wonders how we are doing to document "Members of ubuntu-release who are not members of the release team"? [17:11] is it an issue? I'm having a hard time imagining canonical-qa people having the time to do bogus freeze exception approvals [17:11] (I know this is a sledgehammer, BTW - it's just a smaller sledgehammer than the awful mess that is the ubuntu-drivers team) [17:16] tseliot: what's the logic of having these as separate source packages from the existing non-"updates" ones? [17:17] slangasek: so, according to what we decided at UDS, we're going to keep the -updates flavours updated during the stable release cycle, until the next Ubuntu release [17:18] As a general practice I think that the actual teams in LP should match the roles/authority in the project. [17:18] this way users can decide whether to stick with the stable drivers or to try updated drivers [17:18] tseliot: ah, ok - so these will receive SRUs updating them to the new upstream version within each driver series? [17:19] I agree it's unlikely to be problematic, but it's not ideal. [17:19] (tseliot: and that's been preapproved by the SRU team?) [17:19] slangasek: we were thinking more of a permanent ack on the -updates packages, as for the module backports, I guess [17:19] tseliot: right, but that's still an SRU, preapproved or otherwise [17:19] slangasek: so, yes that's the plan. pitti can confirm that [17:20] slangasek: ah, ok, I've never deal with one myself [17:20] a preapproved one, that is [17:20] tseliot: right, provided that pitti has said this is ok, it's ok with me - accepting [17:20] slangasek: thanks a lot [17:21] slangasek: so now we'll have to approve the binaries too, right? [17:22] tseliot: yes; that's trivial [17:22] when they're built, that is [17:22] ok [17:27] slangasek: have you approved fglrx-installer-updates too? [17:27] tseliot: now I have :) [17:27] slangasek: excellent. Thanks again, Steve [17:32] ScottK: is your benevolence going to extend to bind9 getting in this evening? (gonna be killing a couple hours in an airport later today, plus airtime, I expect I'll be wanting to upload bind9 and postfix around 2330 pacific) [17:32] lamont: I think it sounds reasonable. [17:33] I wouldn't want to be the one that had to explain to kees where there was no DNSSEC in oneiric. [17:33] right [17:33] and I'd prefer to not bail on current work tasks to finish it up [17:33] because writing exception documents can be so much fun, and all that [17:34] well considering I have the same gripe as kees about bind9 not supporting DNSSEC, I think a FFe review can be arranged :P [17:34] slangasek: you gonna bitch if I make it 9.8.0 instead of 9.7.3? [17:34] it wants to be at least 9.7.3.dfsg.P1 [17:34] not if it's done today [17:34] cool [17:35] it just won't make the 2100 UTC deadline [17:35] * slangasek nods [17:35] I still need to roll a couple security releases into the git tree, too :( [17:36] ScottK: acknowledged; I just really want to finish breaking down the ubuntu-drivers problem, since it's been dragging on for years [17:36] cjwatson: I'm not objecting to doing this. [17:36] I'd just like to see it further refined in the future. [17:36] I think we're in agreement there ... [17:37] Last I checked (it's been awhile) ubuntu-sru had similar issues. [17:40] ubuntu-sru seems to have a reasonable membership list at the moment [17:41] Agreed. [17:42] I think thought it used to have canonical-qa in it, but it does seem fine now. [17:43] ev: are you uploading ubiquity today to land the timezone reorg work? [18:04] pitti: syslinux-themes-ubuntu is in NEW for you now [18:05] pitti: I don't know how you want to handle dependencies of ubuntu-defaults-image; it will need syslinux-themes-ubuntu and gfxboot-theme-ubuntu installed === Ursinha` is now known as Ursinha === micahg_ is now known as micahg [21:09] anyone got a handy URL showing outstanding FFe requests that need tending to? [21:11] Laney: How about https://bugs.launchpad.net/~ubuntu-release [21:12] if that will remain the link, sure [21:13] That's the one I usually use. [21:14] ScottK, Laney - was working through some of the pages, and came across https://wiki.ubuntu.com/StandingFeatureFreeze, there are some things we've known are going to need an exception, and am wondering if it makes sense to revive this page? thoughts? [21:14] I guess filtering it to New will be enough later [21:15] skaet: yes, probably. Is the standing FFe policy documented elsewhere? [21:15] skaet: Yes. If we need them, I think it's a good idea to document them. [21:15] Last cycle we just had FFe bugs that were left open. [21:15] I think that's OK too. [21:15] Spotted the links from: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_upstream_versions [21:16] but that's the reference I've seen so far. [21:16] For some reason I thought they needed two acks, but I don't know why [21:16] Laney: That was once true for motu-release. [21:16] ah [21:18] So you could either track through that wiki page, or by leaving bugs open (possibly with a tag). Perhaps using LP is more sensible, as it'll be more current and searchable. [21:25] Would prefer to have one way, and if custom is the leaving the bugs open, that may be the right solution, and updating the process page may be appropriate. [21:26] yep. [21:26] cjwatson, pitti, slangasek, other release team members, ^^ any preferences? background info? [21:27] having a tag may be useful as you can then get a list of all that are in effect [21:28] Laney: that would require modifying the current tools like requestsync as well to add the tag (or have a script like bdmurray does for needs-packaging) [21:28] micahg: no tools deal with standing FFes now anyway [21:28] (and RT members could easily just add any tag when approving such) [21:28] Laney: oh, this is post-approval, nevermind [21:32] We've done both wiki page and via bug. [21:41] skaet: certainly I think ~ubuntu-release bugs is the lightest-weight, most scalable approach [21:53] slangasek, ScottK, Laney, ok will make a note to update that process page to remove the reference to the stale exceptions page. We'll standardize on the bugs this time around. [21:55] Now that we are processing exceptions for new features and not all new upstream versions, I think that they will be less necessary (e.g. I expect KDE 4.7.1 will be bugfix only). [22:26] in general through the end of the cycle, do we still want multiarch changes from Debian?