[00:05] lamont: acorn appears to not be helping [00:08] cjwatson: ok [00:43] lamont: can you tell me what's going on with acorn? I've killed off the livefs attempts after 5h+ with no response [01:55] uploaded a gcc-4.5 build to the devirtualized ubuntu-toolchain-r ppa, please kill it, if it blocks other builds (should only happen for powerpc, sparc and ia64) [01:59] slangasek: lock file removed. [01:59] go me [01:59] and typo fixed in the @reboot crontab entry that should have done that [02:00] lamont: oh, bah [02:00] ok [02:00] lamont: well, that's much better than the alternative scenarios, then :) will switch back to acorn for the next builds [02:01] * ScottK got a couple of armel livefs build failure mails for Kubuntu Netbook, but no logs attached. Anything I need to worry about? [02:01] slangasek: did you want the existing builds killed? [02:01] lamont: doesn't matter [02:01] ScottK: nope [02:01] OK [02:01] /bin/bash /home/buildd/bin/BuildLiveCD -s dove -d lucid kubuntu-netbook [02:01] slangasek: ^^ that one is running now, I killed the other one. [02:02] ScottK: that was me killing off the builds on acorn to move them back to clementine - should have kubuntu-netbook/armel posted in a couple of hours [02:02] OK [02:02] mostly I'm curious how long it takes [02:02] I'd appreciate it if someone would binary New libcatalyst-perl. It's my upload so I shouldn't. It's got another possible sync request behind it depening on how a depwait resovles itself. [02:03] lamont: less than an hour would be nice :) [02:03] ScottK: looking [02:03] Thanks. [02:03] slangasek: lets see how we do [02:03] Should be clear enough, perl module sync'ed from Debian. [02:04] ScottK: done [02:04] Thanks. [02:04] * ScottK hopes before the publisher started... [02:04] * ScottK looks [02:05] Nope, after. [02:05] No biggie. [02:12] Would it be possible to respin just Kubuntu ia64 live and alternate? They were built with obsolete packages because ia64 was behind. It's caught up now. [02:20] hrm.. that reminds me, I should burn ia64 install media and see how it does [02:23] I know that port has at least one actual user because I've seen a bug filed specifically mentioning it was with the ia64 version of a package. [02:23] lamont: any idea on the glib2.0 issue on sparc? [02:25] ScottK: sure - I actually haven't done any ports spins yet except for kubuntu-netbook, I can fire that one off now [02:27] OK, powerpc then too. [02:27] I've got actual testers lined up for that one. [02:29] doko__: none at all. go ahead and kill faure with it, just make sure you're capturing output off-machine [02:30] * lamont updates the chroot [02:32] lamont: I only have a remote machine for testing, so I'd like to play safe. Would you mind an upload not running the testsuite on sparc? [02:33] doko__: try a testbuild of that on faure? [02:34] lamont: just with the disabled testsuite? [02:34] yeah [02:34] doing ... [02:34] slangasek: if you kick ia64 media, I'll go test that tonight, too [02:34] doko__: dist-upgrade is still running, I'll install the build-deps when that finishes [02:35] lamont: I'll try on my local machine first [02:37] slangasek: A few more Universe syncs if you have a moment: http://paste.debian.net/69817/ [02:42] Also a stack of binary removals (I can put this in a bug if you want a paper trail, but it's in the spirit of the supportable binaries spec: http://paste.debian.net/69818/ [02:49] BEGIN fdupes <-- slangasek [02:49] :-( [02:50] doko__: build-deps all there on faure, fwiw [02:51] doko__: if you get one that builds ok on faure, and I'm asleep/afk, feel free to have a GSA make the semi obvious change around 'glib2.0' in /usr/share/launchpad-buildd/slavebin/sbuild-package on one of the sparc buildds [03:07] slangasek: well... the mksquashfs run _started_ before the hour was up... [03:09] hmm :) [03:10] well, at least it's parallel :) [03:10] 2-3 minutes before, mind you [03:10] one core. [03:11] lamont: well, there's http://cdimage.ubuntu.com/kubuntu/ports/daily/current/ if you want to test some ia64 [03:11] (liveCD still building) [03:12] ScottK: syncs running; looking at the binary removals now, no bug, I'll just point at you by name in the removal message ;) [03:13] slangasek: OK. Please just mention python2.5 being needed in there somewhere. [03:13] yep [03:14] done [03:14] slangasek: I was thinking more ubuntu-server [03:14] ia64 desktop seems "just wrong"™ [03:15] last night's daily server make any sense to play with? [03:15] you didn't specify ;) [03:15] let me get you a fresh one, < 30min [03:15] coolorino [03:17] you know, if we didn't squash it so hard, it'd squash faster [03:20] spend a penny to save a penny [03:24] very true, 'dat [03:28] slangasek: 83 minutes. just fyi [03:30] not too bad then [03:31] ScottK: kubuntu-netbook/armel finished [03:31] slangasek: THanks. [03:59] So that worked. The followon build to libcatalyst-perl succeeded. [04:08] lamont: ubuntu-server/ia64 done [04:11] ta [06:55] morning [07:38] Good morning [07:41] morning pitti [07:41] * slangasek waves [08:03] slangasek, generic tests are not in the tracker for a good reason? [08:11] ara: sheer forgetfulness on my part about their existence; posted nowv [08:11] slangasek, ok, thanks [08:11] * slangasek looks over the build set list to make sure he hasn't missed anything else [08:12] I think that's it [10:17] * pitti reviews the current universe packages [10:18] pitti: mind that audacious is on ubuntustudio [10:18] right, I have the x/myth/studio manifest files here for comparing [10:19] pitti: https://launchpad.net/ubuntu/lucid/+queue?queue_state=1 helps, sets are marked [10:20] slangasek: ah, nice; is that reliable enough to not having to consult the x/myth/studio CD lists? [10:21] dunno [10:21] cjwatson: ^^ is it? :) [10:21] well, I think at this point I check them anyway [10:21] seems the only candidate is mpich2 [10:33] I would double-check the CD lists if I were you [10:33] treat it as a guide ... [10:42] cjwatson: *nod* [10:45] It's as reliable as the information LP is given... [10:51] wgrant: yes, I know - I'm the one giving it the information :-) [10:51] so I know how (un)reliable that is as yet [10:52] Ah, right. === ogra_ is now known as ogra [11:36] ev: bug #543032 is still marked as "fix committed"; is this resolved in the wubi we currently have on the RC images? [11:36] Launchpad bug 543032 in wubi "Selecting reboot doesn't reboot" [Undecided,Fix committed] https://launchpad.net/bugs/543032 [11:37] slangasek: I just set it to Fix Released. It's fixed on the RC images. [11:37] ta [11:41] slangasek, i just hit a prob with a missing option in livecd-rootfs on omap. STRIP_VMLINUZ is not set to no so we dont have vmilnuz in the /target during install, http://paste.ubuntu.com/419134/ would fix that (and also clean up the ugly separate if statement) [11:43] ogra: what do you mean, "wouldn't save any space"? [11:44] ? [11:44] your comment in the patch [11:44] its not my comment [11:44] oh [11:44] i just copied it 20 lines up [11:44] right [11:44] so we can use the case statement instead of adding a complicated if [11:45] makes no sense to handle it separately [11:45] http://paste.ubuntu.com/419136/ has the full case statement after my change for better understanding [11:48] save any space: uImage is created additionally, either for use in flash or for use in /boot (fi /boot can be ext2 like in dove) stripping vmlinuz actually breaks the install (ubiquity tries to copy it from casper/ to not also have it in the squashfs) [11:49] in dove or omap images casper only carries uImage not vmlinuz so it wouldnt "save any space" to remove a nonexisting duplicated file [11:49] (that comment is super silly formulated not sure who wrote it) [11:50] right - it's not that it doesn't save space, it's that it breaks the install :) [11:50] * ogra fixes the last sentence to make it clearer [11:50] yeah [11:51] http://paste.ubuntu.com/419150/ [12:06] slangasek: Just pushed a qemu-kvm fixing the qemu-$arch and qemu-system-$arch man pages; do you think it is reasonnable to include between RC and final or shall I move to a SRU bug? [12:08] lool: well, doko wanted an update of this package anyway for the static binaries to rebuild against current glibc (which includes code fixes); if we get actual fixes of known bugs in the process, that's better [12:09] lool: but, since were revving anyway, please fix the qemu-kvm-extras-static postinst to not call 'start' directly as this isn't chroot-safe - it should use invoke-rc.d instead [12:09] slangasek: http://paste.ubuntu.com/419170/ is the debdiff I uploaded [12:09] (there was a discussion on #ubuntu-devel about this a few hours ago) [12:10] slangasek: that gives out warnings though [12:11] lool: not when called from a maintainer script [12:11] slangasek: Re-upload ubuntu7 or ubuntu8? [12:12] whichever you prefer [12:12] I'll go for ubuntu8 for bzr imports then [12:12] slangasek, so would it be ok to upload livecd-rootfs with http://paste.ubuntu.com/419150/ to fix omap netbook images ? (only touches dove and omap) [12:14] ogra: is that the part that has to get uploaded, or the part that lamont has to pull from bzr? I never remember [12:14] In theory this part is pulled daily [12:14] i think lamont syncs the package to the live builder [12:14] or perhaps even updated before builds, I'm not sure [12:15] and that happens daily [12:15] the part which required manual interaction in the past was the wrapper which calls the real script [12:15] (IIRC etc.) [12:15] the BuildLiveCD sample wrapper [12:15] yes [12:15] ogra: yes, please upload [12:15] thanks :) [12:16] I imagine we need omap respun after this is published [12:16] slangasek: is ubuntu7 -> ubuntu8 http://paste.ubuntu.com/419174/ [12:17] lool: looks good to me [12:17] kirkland, doko_: FYI couple of qemu-kvm uploads in unapproved [12:17] BuildLiveCD comes from outside the chroot and is a manual propagation [12:18] ogra: ^^ [12:18] lool: mine was just a rebuild [12:19] doko_: does this mean that satinash is getting close on oo.o? [12:19] Started 1 day, 1 hour, 17 minutes, 8.6 seconds ago. [12:19] I've managed to reproduce bug 558382 [12:19] Launchpad bug 558382 in partman-base "Partitioner throws "Unable to satisfy all constraints" when trying to use previously created partitions" [High,In progress] https://launchpad.net/bugs/558382 [12:20] it looks as though it's something to do with maximising extended partitions [12:20] which is nasty - it suggests that there's a possibility of problems any time you have free space around your set of logical partitions [12:21] e.g. during auto-resize [12:21] I'm working on gathering more information now that I have a saved kvm snapshot that reproduces it [12:21] for what it's worth, michaelforrest just ran into that and I'll have logs just as soon as he's done with an install, if you need them. [12:22] lamont: the last succeeding one was 1d 19h ... [12:23] slangasek, uploaded, there is another one char typo fix from lamont in the debdiff he didnt upload yet, hope thats ok [12:24] ev: I think I'm good, thanks [12:24] okay, cool [13:38] ev: hmm, usb-creator-gtk gives a wholly non-obvious error message when it doesn't have permissions to read the source .iso... is that worth a bug report? [13:38] ("doesn't have permissions" -- NFS) [13:42] slangasek: yes please [14:45] * Riddell cries over bug 567243 [14:45] Launchpad bug 567243 in ubiquity "error during OEM setup in French" [Undecided,New] https://launchpad.net/bugs/567243 [14:50] slangasek: fyi, i'm looking at ttx's rackspace package renames [14:58] Riddell: oh in ainm Dé, not another one [15:01] ainm D? [15:01] * slangasek happily absorbs the Irish [15:03] kirkland: ack [15:04] sounds similar to "nomen dei" -> "in god's name"? [15:05] yep [15:20] yes [15:21] D e-fada (e-acute) for the Unicode-impaired [15:27] slangasek: right, I've figured out the partitioning problem [15:28] the bug is an overenthusiastic application of optimal alignment to extended partitions in partman-base (it's only needed for partitions that directly contain filesystems) [15:28] when we try to create a new logical partition next to existing logicals, partman maximises the extended partition to make room, and then minimises it again around the new set of logical partitions [15:29] I was incorrectly constraining the maximised extended partition to optimal alignment (which is normally a 1MiB grain) [15:30] cjwatson: heh, nice! errata for RC, or is this horrid enough to warrant a respin? [15:30] this meant that if the extended partition was non-optimally-aligned at the end (e.g. cylinder-aligned from all sorts of possible older installations), we tried to maximise it, but sometimes actually ended up rounding *down* the end position [15:30] which meant that maximising the extended partition failed, so there was no room to create new logical partitions inside it [15:30] heh [15:30] horrid enough> so that's more or less my question [15:31] it will fail rather than corrupt data, I think, and it's not new - at least beta-2 had the same problem and I think beta-1 as well. OTOH I don't think we can release with partman this way, and in some ways I'd rather test it in the RC [15:31] but I'm open to either [15:32] the diff is http://paste.ubuntu.com/419280/ [15:33] and for the record it would require respinning everything [15:33] so if that's too much of a headache, we can put it off [15:34] I'm not sure how to errata it short of "the partitioner might just not work" [15:34] * charlie-tca thought it was just my equipment failing at times [15:35] after hitting the failure, is there any way to recover, other than waiting for an ISO with the fix? [15:36] based on what I've seen of the ISO testing timeline for the betas, I think a broad-spectrum respin today would push us to Friday on the RC, unfortunately [15:37] unless we mustered a lot of extra testing support quickly, and that would probably expend our reserves for next week [15:37] For me, the only way out has been to run the liveCD, delete the partitions, then run the install again [15:39] I'm ok with an erratum of "the partitioner might just not work, and spit ; if you hit this you can delete the partitions by hand, or wait for the final release next week" [15:42] there might be fiddly technical ways to recover, such as manually resizing your existing logical partitions to slightly different boundaries [15:43] deleting partitions wouldn't be a good recommendation since they'll be people's existing partitions [15:43] ah [15:43] "wait for an ISO with the fix" is probably the sanest recommendation by some way [15:43] right [15:43] ok, so I can drop this into the archive and we can land it last thing Thursday, or something [15:44] sounds good to me [15:46] it should have occurred to me to just try manually laying out a disk matching the reported partman log, and then I'd have found it more quickly [15:46] but hindsight is 20/20 [15:58] slangasek: okay, rackspace stuff looks okay, i'm going to approve them from the new queue [15:58] slangasek: do i also need to remove the old ones from the archive? [15:59] kirkland: the old ones need removed from the archive, yes [16:03] slangasek: k [16:06] slangasek: done [16:06] kirkland: thanks - bugs reports closed? [16:06] slangasek: i'll blacklist too [16:06] ok [16:06] slangasek: changelog mentioned the bug number; i'll double check === seb128_ is now known as seb128 [16:49] is it too late to upload byobu with a newly merged set of translations? [17:00] kirkland: but they would just get stripped anyway? [17:00] pitti: ? [17:00] kirkland: you might upload the new .po files directly to LP, to shortcut their import? [17:03] kirkland: packages in main don't ship translations (*.mo) anyway [17:20] pitti: oh? okay. where do their *.mo's go then? [17:20] pitti: how do they get sucked up? [17:21] kirkland: https://wiki.ubuntu.com/Translations/TranslationLifecycle explains the whole process in detail [17:21] kirkland: in short, the .mo files are stripped, the po files imported into LP, merged with translation updates, and re-exported into language-pack-* [17:22] slangasek: I have an apparmor profile change to address bug #566207 [17:22] Launchpad bug 566207 in evince "apparmor blocks evince from /usr/bin/dbus-launch" [High,Triaged] https://launchpad.net/bugs/566207 [17:23] slangasek: I'd like to add an abstraction to apparmor (already in trunk), and then update evince to use the new abstraction. if this is not appropriate, I can just adjust evince for lucid and make said changes in maverick [17:23] pitti: okay, i'm just realizing i haven't merged translations into byobu in several months, got some complaints from people who contributed translations and weren't seeing them in the package [17:23] slangasek: what do you think? [17:24] kirkland: they don't need to be [17:25] pitti: okay, thanks [17:26] jdstrand: I think it's appropriate to make the change for lucid, but I'm inclined to defer to SRU - from the bug log, it seems to me that this bug only affects certain remote-display configurations? [17:26] slangasek: presumably, yes [17:26] slangasek: I can adjust the bug accordingly for SRU [17:26] and AIUI doesn't block use of evince, just throws some errors [17:27] so yeah, I think SRU is best [17:27] slangasek: no, it blocks evince on a remote display. but there may be an unrelated issue that makes that not work anyway [17:27] ah [17:27] still, --> SRU please [17:27] * jdstrand nods [17:28] jdstrand, in the case the user subscribes there you dont have any session dbus running [17:28] so evince has nothing to connect to [17:29] s/subscribes/describes/ [17:29] even fixing apparmor will not get him running evince [17:29] ogra: right, so it tries to start one with dbus-launch (which fails due to apparmor) [17:29] ogra: so it isn't possible to get evince running on a remote display? [17:30] well, you need a session dubs running first [17:30] *dbus [17:30] ah right, I see what you are saying [17:30] gnome-session does that automatically, if you log in via ssh that doesnt happen [17:31] still, the profile should be adjusted, it is then up to the user to get the session bus going [17:31] indeed [17:31] the apparmor issue is definately valid but will likely not fix the issue for the user [17:32] ogra: thanks [17:54] slangasek: ping [18:55] slangasek: I'd like to upload gcj-4.4 for lucid, fixing stack-unwinding on armel, followed by an ecj upload. currently testing on jocote. ok, or sru? [18:56] Wubi isn't being pulled in on Xubuntu cd's [19:00] That wouldn't require complete retesting, but we do have users that use it [19:14] slangasek: Quick status update on Edubuntu, we're still waiting on the final artwork, for now we reverted on the old one and I'll try to call Iain Farrell tomorrow morning (just noticed I had written his office and cell numbers ;)). highvoltage is working on a small change in our scripts that will be uploaded in a few hours (I hope), we'll then need a respin to include these changes. [19:57] slangasek: package uploaded [20:49] doko__: any progress on glib2.0 vs sparc? [20:51] lamont: no, can look at it tonight. would disabling the testsuite work for an upload? I fear, my machine will be not accessible as well [21:03] doko__: put together a source package with the test suite disabled for sparc, toss that (signed) on faure, and start the build. I'll check it later and see how it did and then pester slangasek about upload perms. sound good? [21:05] lamont: ok [21:27] I fixed a bug in checkbox which might be release critical, how can I assess whether it's really release critical or whether it should be an sru? [21:28] seb128: while trying to build glib2.0 [21:28] fakeroot debian/rules clean [21:28] /usr/share/gnome-pkg-tools/1/rules/check-dist.mk:19: Unknown distribution: lucid [21:28] what does depend on that? [21:29] doko__, don't bother about that one [21:29] doko__, it's an hook to avoid experimental source upload to unstable in debian [21:29] doko__, it just displays warning in other scenarios [21:30] ok [21:55] lamont: faure:~doko/tmp [22:13] Unless I'm just really unlucky, Bug 567536 may be important and no mvo. [22:13] Launchpad bug 567536 in update-manager "Upgrade failed due to OOo predepends problem" [Undecided,New] https://launchpad.net/bugs/567536 [23:16] Also, the pending opendkim upload is mine, so I'd apprecaite it if someone would accept it. The only non-bugfix bit is a build system change that defaults off. [23:26] stgraber: pong [23:26] doko__: gcj-4.4, ecj> SRU, I'm afraid [23:27] ok [23:27] stgraber, highvoltage: ok; so you want a respin for RC with the edubuntu-artwork upload? [23:28] slangasek: that would be very nice thanks [23:28] ScottK: 567536> looks like a duplicate of the one mvo has already been working on? [23:29] slangasek: OK. ccheney wasn't sure if it was still a work in progress or a fix had already been 'done'. [23:29] (which I found out after I pinged here) [23:30] BTW, I used Ubuntu for the first time today. The failed upgrade is a new Dell laptop that arrived today with Ubuntu preinstalled. [23:30] oh no, mvo was struggling with it all day today - I'm quite sure the fix isn't done [23:31] OK [23:33] highvoltage: so this upload is the rollback to the previous artwork? [23:34] slangasek: eek, no, unless I did something horribly wrong [23:34] highvoltage: oh, all debdiff is showing me is that there are different logos; I was trying to understand what's going on based on stgraber's comments [23:34] highvoltage: is this the /final/ artwork, then? [23:36] slangasek: we still don't have anything from Canonical, so I decided to replace the place-holders with the old Edubuntu logo, since we don't have any word on when it will be ready [23:36] highvoltage: ok :/ [23:36] slangasek: and I'm concerned that the archive might go into deep freeze with a bunch of "New Edubuntu Logo Here" messages in place [23:37] edubuntu-artwork accepted [23:37] thanks again [23:38] my dream is that one there will be an artwork team as efficient as the release team :) [23:38] s/one/one day/g [23:50] can someone let audacious in? [23:57] edubuntu-artwork publishing, ISO trigger set [23:58] bdrung: it's seeded on the ubuntustudio images, so that would break the RC freeze? [23:58] ups [23:59] slangasek: what's the process for seeded packages in the RC freeze?