[00:30] <micahg> can I actually get someone to reject the z88 upload?  I didn't mean to modify the CMakeLIsts.txt file in debian/
[00:49] <micahg> thanks, I uploaded a second version that's fixed now
[04:04] <superm1> skaet, i've just gotten back and uploaded a bunch of fixes that will need to be there for mythbuntu b1 ubiquity to work since Daviey didn't get them done last week
[04:05] <superm1> they're in the approval queue right now
[05:25] <pitti> good morning
[05:36] <pitti> uh, LibO/armel _still_ building .. /me feeds the hamster
[07:12] <pitti> NCommander: bug 820621 is still open, that means that omap is still screwed for b1?
[07:12] <ubot4> Launchpad bug 820621 in flash-kernel (Ubuntu) "netinstall fails to make omap system bootable during install (affects: 2) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/820621
[08:09] <pitti> tracker set up, cron disabled, missing images building now
[08:09] <pitti> still waiting with mythbuntu for above packages, and with ubuntu for missing ubuntuone-installer (incomplete main promotion/-meta rebuild)
[08:52] <pitti> jibel: we have images for ubuntu-server armel+ac100; can we add a product for this to the tracker?
[08:54] <jibel> pitti, I'll add it.
[08:54] <pitti> jibel: merci
[08:54] <Daviey> There is also armel cloud images, but they should not be tracked for b1.
[08:54] <Daviey> (New this sub-cyle)
[08:54] <pitti> I'm not quite sure whether I'm supposed to add the server EC2 images
[08:55] <pitti> Daviey: do you know?
[08:55] <pitti> jibel: ^ or you?
[08:55] <Daviey> pitti: This was disuccsed before, and there was uncertainity.  I thought the outcome was 'yes'.. but not sure
[08:55] <pitti> someone else than me used to add these to the tracker with the correct version number
[08:56] <pitti> Daviey: I meant the normal i386/amd64 ones
[08:56] <Daviey> TBH, the testing has 100% jenkins coverage, not sure there is really /that/ much beneift of it being in the tracker
[08:56] <pitti> there is a post-amis-to-iso-tracker.py script, but I've never used it
[08:56] <pitti> so, education appreciated
[08:56] <pitti> Daviey: fair enough
[09:03] <Daviey> Does the tracker have an API for posting pass/fail?
[09:03] <pitti> I don't know
[09:05] <pitti> jibel, Daviey: do you know about the "Ubuntu Server UEC i386/amd64" images in the tracker? are they a special mode of the normal Ubuntu server images, or similar to the EC2 ones?
[09:06] <Daviey> pitti: Well we test the images against Amazon for the automated stuff, then we also do some smoke testing against Ubuntu Cloud.  So yes, they are different.. it's more testing that they work on a different platform.
[09:07] <pitti> Daviey: so should they be added with the versino of the ubuntu server images, or with the EC2 images?
[09:07] <Daviey> You've probably noticed that this isn't clearly defined.
[09:07] <Daviey> pitti: I'm not really sure it makes much difference where they are shown.. probably under EC2 images, as it isn't an ISO.
[09:09] <pitti> ok, thanks
[09:09] <jibel> pitti, for ec2 skaet runs a script, but never used it myself.
[09:09] <jibel> Daviey, no API, hggdh and jamespage review the results and update the tracker.
[09:10] <Daviey> jibel: Seems kinda man time intensive for something that could be reasonably automated.
[09:10] <jibel> Daviey, updating the tracker is useful because there is one single place for the full status of the release.
[09:10] <Daviey> jibel: Yeah, I certainly want to bring the cloud images more centralised into the release process.
[09:11] <jibel> Daviey, indeed and that easy to automate but has always been low priority
[09:11] <Daviey> pitti: If post-amis-to-iso-tracker.py doesn't contain anything sensitive, could you pastebinit please?
[09:11] <pitti> Daviey: oh, want me to run it?
[09:11] <jibel> Daviey, its in ubuntu-archive-tools
[09:11] <Daviey> jibel: ah!
[09:12] <Daviey> pitti: As jibel says, it does make sense for the cloud images to be on there.. But it seems like a waste of time for hggdh and jamespage to go and review each one.
[09:17] <doko> please accept binutils-h8300-hms and gcc-h8300-hms
[09:24] <Daviey> jibel: Hah, it provides a HTTP 'API' .. You have to steal a cookie from your browser.
[09:29] <jibel> Daviey, heh, if you call 'posting an HTML form with a script' an API, sure there is an one ;-)
[09:30] <jibel> s/an //
[09:31] <Daviey> ;)
[09:47] <doko> pitti: I would like to address bug #831410, have packages prepared in a PPA which I would like to copy into oneiric. includes gnat-4.4, gcj-4.4 and gcc-4.4
[09:47] <ubot4> Launchpad bug 831410 in gnat-4.4 (Ubuntu Oneiric) (and 1 other project) "gnat-4.4 version 4.4.6-1ubuntu1 failed to build in oneiric (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/831410
[09:48] <pitti> doko: gnat sounds fine, does it b-dep on the updated gcc/gcj?
[09:48] <pitti> doko: what changes in gcc/gcj?
[09:49] <doko> pitti: the multiarch fixes, which are already in 4.5 and 4.6
[09:49] <doko> there's nothing which lands on the images
[09:49] <pitti> right, but we probably still need some package updates for the b1 CDs
[09:49] <pitti> i. e. need to build packages
[09:50] <doko> pitti, that is the reason, copying the binaries too, such that the packages don't end up in a broken state
[09:50] <pitti> doko: so what changes in gcc? is that more or less just a rebuild, or new version etc/
[09:50] <pitti> ?
[09:51] <doko>   * Re-work the multiarch patches.
[09:51] <doko>   * Break older gcj-4.4, gnat-4.4, gdc-4.4 versions, changed gcc_lib_dir.
[09:51] <doko>   * Fix [ARM] PR target/50090: aliases in libgcc.a with default visibility,
[09:51] <doko>     taken from the trunk.
[09:51] <doko>   * Taken from the gnat-4.6 package: debian/patches/ada-symbolic-tracebacks.diff
[09:51] <doko>     (src/gcc/ada/gcc-interface/Makefile.in): pass -iquote instead of -I-
[09:51] <doko>     to gnatgcc; fixes FTBFS on i386 and closes: #637418.
[09:51] <doko>   * Fix libgnat* multiarch installation.
[09:52] <pitti> doko: ah, thanks
[09:52] <pitti> doko: so if you know that the "Re-work the multiarch patches." part doesn't break existing package builds, please go ahead
[09:52] <doko> pitti, I would know, as it's already in 4.5 and 4.6 in the archive
[09:52] <doko> ok, thanks
[10:12] <jibel> ogra_, GrueMaster , pitti : server ac100 is posted with same test case than omap and linked to this image http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/oneiric-preinstalled-server-armel+ac100.tar.gz
[10:13] <ogra_> jibel, ac100 wopnt be released with this milestone on release-team request
[10:13] <jibel> ogra_, GrueMaster tell me if it is not correct and want to update something.
[10:13] <ogra_> just ignore it
[10:13] <pitti> jibel: nice, thanks
[10:13] <pitti> ah, ok; will do that then
[10:13] <pitti> removed
[10:14] <jibel> ogra_, ok :)
[10:14] <ogra_> server builds a lot quicker, we currently only enable that build to easier be ablet to do testbuilds
[10:14] <jibel> pitti, thanks, it will be ready for next time.
[10:14] <pitti> right, so it wasn't in vain :)
[10:14] <ogra_> (desktop fails 60% of the time due to archive skew)
[10:15] <ogra_> jibel, pitti, same goes for mx5 btw
[10:31] <pitti> ogra_: we'll just support omap and omap4 for b1, right? anything else, like dove?
[10:31] <ogra_> nope, only TI stuff this time
[10:32] <ogra_> (omap3/4)
[11:20] <doko> fyi, I'm accepting a NEW gcc-mingw-w64-bootstrap package to bootstrap the mingw64 packages, then will remove it again. will save IS manual interaction
[11:42] <ogra_> pitti, i could need an omap4 testbuild ( i can do it myself if you want, but usually keep my fingers out of antimony during milestone freezes to not add confusion)
[11:43] <ogra_> server should be fine for that and build fastest
[11:43]  * ogra_ just needs to check bootability
[11:43] <pitti> ogra_: sure, will rebuild; does it hurt to rebuild omap, too?
[11:44] <ogra_> no
[11:44] <ogra_> i dont think anyone is testing yet anyway
[11:45] <pitti> started
[11:45] <ogra_> thanks
[12:31] <pitti> ubuntu desktops posted
[12:32] <pitti> building DVDs now; rebuilding alternates
[12:35]  * ScottK waves.
[12:36]  * ScottK has no power due to the hurricane that hit the US (working from a restaurant ATM), so please don't block anything on hearing from me.
[12:41] <pitti> hey ScottK, everything alright with you?
[12:41] <pitti> the news here sound pretty scary
[12:42] <ScottK> We were just on the fringe of it.
[12:42] <ScottK> Other than no power, one fallen tree (didn't hit anything), and some branches to clean up, no problems.
[12:47] <Daviey> Can swift and glance be accepted from unapproved please?
[13:00] <pitti> ogra_: http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110829.1/ done for testin
[13:00] <pitti> g
[13:02] <pitti> cjwatson: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/oneiric/daily-20110829.1.log complains about "Missing debootstrap-required gcc-4.4-base"
[13:02] <pitti> started says it needs to move to optional
[13:02] <pitti> WTH, paste failure
[13:02] <pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt says to move that to optional
[13:03] <pitti> that sounds fine; confirm, please?
[13:03] <stgraber> Morning
[13:04] <ogra_> pitti, thanks, rsycing
[13:05] <pitti> Daviey: ah, these didn't come with linked RC bug reports and looked quite intrusive
[13:05] <pitti> Daviey: they are required/wanted for beta-1?
[13:06] <pitti> Daviey: alos, at least glance seems to introduce a new build dep on python-kombu, i. e. it'll just depwait as it is in universe
[13:06] <Daviey> pitti: Yes.. I mentioned that I wanted a standing FFe for swift, nova & glance as the release cycles perfectly align.
[13:07] <Daviey> They shipped their beta in time for our beta, rather than a snapshot.
[13:07] <cjwatson> pitti: confirm
[13:07] <pitti> cjwatson: cheers
[13:07] <Daviey> pitti: there is a MIR for kombu
[13:07] <cjwatson> (note bank holiday today, not necessarily around)
[13:07] <pitti> Daviey: ok, your call
[13:07] <Daviey> pitti: rocking, thanks.
[13:08] <Daviey> cjwatson: bah, wish someone told me. :)
[13:08] <pitti> Daviey: kombu MIR hasn't been checked/approved yet, so glance won't build
[13:08] <pitti> Daviey: do you want the new swift in anyway?
[13:09] <Daviey> pitti: meh, yeah.  I hoped that it might help give it more attention.
[13:09] <Daviey> Would /really/ like to ship upstrea beta for our beta, rather than a snapshot.
[13:54]  * skaet waves
[14:01] <jibel> morning skaet
[14:02] <skaet> good afternoon jibel
[14:02] <skaet> :)
[14:04] <pitti> skaet: FYI, current status: ubuntu alternates blocked on fixing a priority-mismatch, will rebuild in ~ 1 h; ubuntu DVD failed due to an NBS package, fixed seeds, rebuild pending
[14:04] <pitti> skaet: omap4 images fail due to boot loader reorg, ogra is on it
[14:04] <pitti> skaet: and ubuntu desktops need rebuild because of ubiquity FTBFS
[14:05] <pitti> skaet: I updated https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview , but not complete yet
[14:10] <skaet> pitti,  thanks for the summary (and starting updates to TechOverview)!
[14:27] <charlie-tca> jibel: don't know yet if accessible will work this milestone.
[14:54] <ScottK> ^^^ kalzium fixes installability for the Kubuntu dvd livefs, so I'd appreciate someone review/accept it.
[14:57] <pitti> oh, nice, thanks
[14:58] <iulian> Shouldn't that be -0ubuntu3?
[14:59] <ScottK> No.  ubuntu3 was uploaded.
[14:59] <ScottK> Dunno why the bot thinks it's ubuntu2 -> 4.
[15:00] <ogra_> pitti, skaet, so that u-boot-linaro upload had an unannounced change in it that broke all omap4 builds, jcrigby or rsalveti will upload a new package soon, please let it through as fast as possible
[15:00] <skaet> ogra_, ack
[15:01] <iulian> ScottK: Oh OK. Something's wrong with the bot then.
[15:03] <cjwatson> the bot works off what rmadison says
[15:03] <cjwatson> $ rmadison -s oneiric -a source kalzium
[15:03] <cjwatson>    kalzium | 4:4.7.0-0ubuntu2 |       oneiric | source
[15:04] <ScottK> So just rmadison being laggy.
[15:04] <ScottK> (i.e. not unusual)
[15:04] <cjwatson> right
[15:04] <cjwatson> though laggier than usual
[15:04] <cjwatson> I'd investigate if I were actually at work today
[15:05] <ScottK> Heh.
[15:07] <ScottK> pitti: I dropped a lang pack on Kubuntu live amd64 for size purposes, so we'll probably want a respin of Kubuntu live regardless of if Ubiquity gets fixed.
[15:07] <ScottK> i386 is at 701, which, IIRC, we decided was OK now.
[15:08] <ScottK> BTW, http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html seems confused since avogadro doesn't build armel binaries, but it show them as uninstallable.
[15:12] <cjwatson> but they're still in the archive and in that case probably need to be removed
[15:12] <pitti> ScottK: ah, I'll remove them then
[15:12] <ScottK> Ah.  Yes.  Please.  They are unbuildable on armel due to Qt GL/GLES stuff.
[15:12] <ScottK> Thanks.
[15:14] <pitti> *zap*
[15:15] <pitti> ScottK: is someone working on the kde-runtime-active uninstallability?
[15:15] <pitti>  kde-runtime-active : Depends: plasma-scriptengine-javascript-active (= 4:4.7.0a-0ubuntu2) but it is not going to be installed
[15:16] <ScottK> pitti: Yes.
[15:16] <pitti>                       Conflicts: kde-runtime but 4:4.7.0a-0ubuntu2 is to be installed
[15:16] <pitti> cool
[15:16] <ScottK> It doesn't affect any images, so I think it's not essential for beta 1 though.
[15:16] <pitti> ok, gcc-4.4-base priority fixed; /me rebuilds ubuntu alternates
[15:19] <pitti> I'm not quite sure whether kubuntu-debug-installer is beta-1 critical
[15:20] <pitti> libreoffice-style-andromeda task fixed as well, starting DVD build
[15:20] <cjwatson> making progress on the ubiquity test suite; I expect we should be able to upload something today
[15:20] <pitti> (won't be the final one due to ubiquity, but I'd like to get a working build at least, as it hasn't built for a while)
[15:20] <cjwatson> aye
[15:20] <pitti> cjwatson: yay you; moved the free day to tomorrow then?
[15:21] <cjwatson> no, I might have a word with Steve about some kind of swap when I next see him
[15:21] <cjwatson> I haven't actually had explicit confirmation that the new-style DVD images work properly as yet
[15:23] <pitti> I'm eager to get a booting version as well, and tryin git
[15:23] <pitti> s/ g/g /
[15:23] <pitti> (I've tried git quite enough, FWIW)
[15:25] <ScottK> pitti: AIUI the kubuntu-debug-installer is not beta1 critical.
[15:39] <pitti> http://cdimage.ubuntu.com/daily/20110829.2/report.html
[15:39] <pitti> yippie
[15:40] <pitti> jibel: alternate ubuntu added to tracker
[15:48] <pitti> skaet: I need to leave in about 15 mins for Taekwondo/EOD
[15:48] <pitti> skaet: alternate posted, DVD building <- if that's done, could you add it to the tracker, please?
[15:48] <skaet> pitti,  sure.   will do.
[15:48] <pitti> skaet: and if ubiquity hits the queue, we'll need to let it through and re-trigger desktops/DVDs
[15:49] <pitti> skaet: I'm fine to do that tomorrow morning, but if you get around to it, it might help speed things up
[15:49] <pitti> ogra_: I'll read backscroll, just leave stuff here if you want me (or skaet) to trigger new armel builds
[15:50] <skaet> pitti,  ok.   will keep eye for ubiquity update landing.
[15:50] <ogra_> pitti, we need the new u-boot built first
[15:51] <ogra_> before re-builds dont make sense
[15:51] <pitti> ah, bug 836727 got fixed, that'll need a mythbuntu respin; but let's wait with that until ubiquity lands
[15:51] <ubot4> Launchpad bug 836727 in casper (Ubuntu) "custom lightdm.conf including commented out autologin-user fails to be setup for live session (affects: 1) (heat: 6)" [Undecided,Fix released] https://launchpad.net/bugs/836727
[15:51] <skaet> pitti,  who's putting out the ubiquity update?
[15:52] <pitti> skaet: cjwatson | making progress on the ubiquity test suite; I expect we should be able to upload something today
[15:53] <skaet> pitti,  ah,  I see it now in backscroll.  (and thanks cjwatson!)
[16:00]  * infinity puts the publisher on manual so he can shove the u-boot fix in a tiny bit faster and get some testing today.
[16:00] <jibel> hm, natty upgrade is still a failed bug 836798
[16:00] <ubot4> Launchpad bug 836798 in pyatspi (Ubuntu Oneiric) (and 1 other project) "natty to oneiric upgrade failed: Could not perform immediate configuration on 'python-pyatspi2' (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/836798
[16:09] <skaet> jibel,  thanks for flagging.
[16:09] <charlie-tca> Still getting the onconf and jockey-backend crashes on Xubuntu alternate
[16:34]  * stgraber hopes the fiber connection gets back online soon, kind of want to test the new ubiquity... (currently on a fallback DSL connection and 3G, but that won't do for ISO images...)
[16:38] <NCommander> pitti: I have to touch f-k for the u-boot transition before B1 so I should be able to fix it today/tomorrow
[16:38] <cjwatson> skaet: ^- ubiquity upload for you now
[16:39] <cjwatson> 156-line diff, should be rather easily reviewable
[16:44] <infinity> skaet: New live-build upload incoming to fix bug #836810
[16:44] <ubot4> Launchpad bug 836810 in live-build (Ubuntu) "live-build uses wrong inode size for speedy preinstalled image resizing (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/836810
[16:44] <infinity> skaet: Localised fix, will only affect ext* images (ie: armel preinstalled stuff)
[16:47] <skaet> cjwatson,  thanks.  :)  slangasek will do the review.    Desktops/DVDs for all flavors to be rebuilt when it lands?
[16:50] <micahg> skaet: is it worth getting firefox/thunderbird on powerpc for beta 1?  I think Debian has a fix for them
[16:51] <infinity> micahg: Build time for mozilla.org sources is pretty insanely high, it'll delay testing by a fair bit.
[16:51] <skaet> micahg,  prefer to wait until after beta 1.
[16:51] <micahg> skaet: ok, I'll hold off then
[16:51] <skaet> micahg,  thanks!
[16:52] <infinity> skaet: Can I accept my two-line armel-only live-build change, or should I get someone else to review it first? :)
[16:52] <charlie-tca> jibel, that upgrade bug for pyatspi wouldn't cause my upgrade to core dump on screen, right?
[16:52] <cjwatson> I'll review it for you
[16:52] <infinity> cjwatson: \o/
[16:53] <infinity> cjwatson: It's just a dirty harcoded hack right now (cargo-culted from the known-working livecd.sh implementation) since live-build's ext* handling seemed to be based on the assumption that people would be doing livecds with ext*, not preinstalled images.  Will revisit making it a tunable option later.
[16:54] <cjwatson> ugh, but ok
[16:54] <cjwatson> accepted for now
[16:54] <infinity> cjwatson: Agreed on the ugh, but the ext stuff kinda needs a rewrite to not assume "this is going on a read-only CD".
[16:54] <cjwatson> yep
[16:55] <cjwatson> the ugh isn't an immediate problem since we have no actual ext* live CDs
[16:55] <cjwatson> skaet: rebuilt> yes
[16:55] <cjwatson> skaet: is slangasek actually around?  I haven't heard from him today
[16:55] <slangasek> yes, I am
[16:55] <cjwatson> aha, ok
[16:56] <infinity> slangasek: Are you sure? :)
[17:02] <cjwatson> there's another problem in ubiquity, superm1 is working on a fix
[17:02] <cjwatson> not a regression in 2.7.19 but breakage on the webcam page that will affect real-hardware installations
[17:02] <cjwatson> (the page hangs, apparently)
[17:02] <slangasek> 2.7.19 accepted, in the meantime
[17:03] <stgraber> oh, too bad I don't have a fake webcam in my VM, would have fixed it yesterday otherwise... I guess I actually should use USB passthrough to test that page :)
[17:09] <ara> skaet, ping
[17:10] <skaet> ara, what's up?
[17:18] <skaet> jibel,  Ubuntu DVD posted from build pitti started,  but doesn't have ubiquity change it in.   Do you want to do some sniff testing on it,  or wait until the version with ubiquity updates shows up?
[18:02] <cjwatson> superm1: thanks, ubiquity 2.7.20 looks good
[18:02]  * cjwatson accepts
[18:04]  * skaet drums fingers waiting for it to go through the publishing.....
[18:04] <skaet> :)
[18:15] <jibel> skaet, yes I'll do some sniff testing. This is the 1rst 1.5GB DVDs and I know which bugs to avoid in current ubiquity.
[18:15] <skaet> thanks jibel
[18:20] <jibel> gilir, about bug 835961 an expert eye is required, but I think it's a problem the the seed not debian-installer.
[18:20] <ubot4> Launchpad bug 835961 in debian-installer (Ubuntu) "Lubuntu oneiric alternate CD install fails to install lubuntu-desktop (affects: 4) (heat: 22)" [Undecided,Confirmed] https://launchpad.net/bugs/835961
[18:25] <gilir> jibel, maybe, I copied the seed from the ubuntu one, but maybe I forgot something
[18:26] <gilir> there is also reports about uninstallable packages on http://cdimage.ubuntu.com/lubuntu/daily/current/report.html but maybe it's not related
[18:35] <NCommander> gilir: looks distinctly like a seed problem. Its been awhile since I dug into how the alternate installer decides which taskes to install. That being said, looking at tasksel on an oneiric machine, I only see 'Lubuntu minimal installation' and 'Lubuntu LiveCD'
[18:37] <micahg> the ship seed is used for the alternate install
[18:38] <micahg> gilir: take a look at line 39 in the lubuntu ship seed
[18:39] <micahg> gilir: nevermind, shouldn't make a difference
[18:41] <NCommander> micahg: what's the bzr path for lubuntu's seed so I take a look?
[18:41] <doko> please could somebody have a look at new unapproved queue, universe packages?
[18:41] <micahg> NCommander: http://bazaar.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.oneiric
[18:42] <NCommander> ah
[18:42] <NCommander> so the desktop seed is exported in tasksel, it just has a weird name
[18:43] <NCommander> mcasadevall@daybreak:~/Documents$ sudo apt-get install lubuntu-desktop^
[18:43] <NCommander> that works, so the seed properly being exported from LP
[18:43] <NCommander> I think the structure file might be wrong if I remember how tihs all goes together
[18:44] <infinity> Yeah, the task works.  Though, I'm curious why "lubuntu-desktop" (the package) isn't being seeded into desktop. :P
[18:45] <NCommander> Yeah, looks like the structure is wrong,
[18:45] <NCommander> desktop: core
[18:45] <infinity> That's fine.
[18:45] <NCommander> and core is defined a core: standard, so that would only be ubuntu-standard+minimal (i.e., cli system only) which explains why d-i installed the wrong files
[18:45] <infinity> The STRUCTURE is fine.
[18:46]  * NCommander bows down to infinity's knowledge in this area
[18:47] <infinity> NCommander: If comparing to the ubuntu seeds, s/core/desktop-common/ and it will make some sense.
[18:47] <Daviey> Can we pre ubuntu-mir ack promote kombu?  I'd really like glane approved, to get on tomorrows daily.  Glance introduces it as a new dep.. and there is no doubt in my mind that it needs to be accepted.  The MIR in this case is to mostly look for issues, which can surely be done with it already in main.
[18:47] <Daviey> I know pre-promoting caused upset before.. :/
[18:48] <Daviey> thoughts?
[18:48] <NCommander> infinity: I was looking at xubuntu's seed for comparsion, and that one doesn't even define desktop-common :-/
[18:49] <gilir> is the order in the STRUCTURE important ? core is defined after desktop, maybe it's important ?
[18:49] <infinity> NCommander: There's more than one way to do it. :)
[18:50] <NCommander> infinity: seeds cause me brainpain whenever I work with them :-/
[18:50] <infinity> gilir: This may not be a seed issue at all.  I mean, your tasks seem to be written correctly, right?
[18:50] <infinity> gilir: And your metapackages generate correctly?
[18:51] <gilir> infinity, meta-packages are OK yes
[18:51] <infinity> gilir: It looks to me like d-i just plain doesn't know to install lubuntu-desktop.
[18:51] <Daviey> NCommander: Yeah, it's not really that easy to check what you have done before committing. germinate doesn't help *that* much.
[18:51] <infinity> gilir: Though, to nitpick, the lubuntu-desktop package *should* be in your desktop seed.
[18:51] <infinity> gilir: So that "apt-get install lubuntu-desktop^" does the same tihng as "apt-get install lubuntu-desktop"
[18:52] <infinity> gilir: (Currently, installing the task won't install the metapackage)
[18:53] <gilir> infinity, ah right, the other seeds do this
[18:53] <NCommander> Seems to me that d-i simply isn't selecting the task during the Install Packages Phase
[18:53] <infinity> That would seem to be the case, yeah.
[18:54] <infinity> But the task is obviously "there".
[18:54] <infinity> So blaming the seeds seems a bit wrong.
[18:54] <infinity> I mean, the seeds might be suboptimal, but if the task exists, even broken, it should try to install it. :)
[18:54] <infinity> (And other than the above missing metapackage, the seeds seem vaguely fine anyway)
[18:55] <infinity> I've never implemented a new -desktop flavour in d-i/alternate land.  What sort of mangling is required?
[18:55]  * NCommander feels like we need a voodoo witchdoctor
[18:55] <infinity> Perhaps someone just missed a critical "tell this CD it's a lubuntu-desktop CD" step.
[18:55]  * NCommander pokes around on antimony
[18:56] <infinity> data/oneiric/preseed/lubuntu/lubuntu.seed:tasksel	tasksel/first	multiselect lubuntu-desktop
[18:56] <infinity> That would seem to be the bit there. :/
[18:57] <NCommander> hrm
[18:57]  * NCommander wonders if the Task: data is ending up on the CD's pool
[18:58] <NCommander> since the dists files are regenerated by d-cd, its possible its not including the task metadata when it runs apt-ftparchive through everything
[18:58] <infinity> More curiously, I wonder if the installer has universe enabled at that point, and perhaps it's just filtering out the task.
[18:59] <infinity> Oh, but xubuntu is universe too, so that should be a solved problem.
[18:59] <infinity> NCommander: But yes, if it's not pulling the lubuntu seeds on the debian-cd germinate run, that would do it.
[18:59] <infinity> NCommander: Which seems entirely likely with them being in a non-standard location.
[19:00] <NCommander> Well, we build xubuntu images with universe so that codepath should work fine (else xubuntu alternates would be foobared)
[19:00]  * NCommander downloads a lubuntu alternate and pokes its pool
[19:00] <jdstrand> ScottK: is it ok if I do a sync of otrs2 and phpmyadmin for security fixes? no ubuntu delta on either
[19:02] <infinity> NCommander: Hrm, cdimage pulls seeds from people/~ubuntu-archive/seeds/, which does include lubuntu.  So, task generation should be working...
[19:02] <infinity> In theory.
[19:02] <NCommander> might just need to run through the install and see what the task selector debug output is :-/
[19:03] <gilir> hum, lubuntu-desktop binary doesn't seems to be in the alternate pool/
[19:03] <infinity> gilir: Because you didn't seed it.
[19:03] <infinity> gilir: See above for my complaint on that score. :)
[19:04] <infinity> That said, while that's a definite bug on your part, d-i installs via tasks, not packages, so it should still be working.
[19:04] <infinity> Just missing the metapackage.
[19:05] <gilir> ok thanks :) I pushed the fix for this at least
[19:06] <infinity> NCommander: Tasks in /srv/cdimage.ubuntu.com/scratch/lubuntu/daily/tasks/oneiric seem fine to me.
[19:06] <infinity> (Or, at least, seem to be there, with some packages included in lubuntu-desktop)
[19:08] <infinity> NCommander: And Packages files in /srv/cdimage.ubuntu.com/scratch/lubuntu/daily/tmp/oneiric-amd64/CD1/dists/oneiric also look sane.
[19:08]  * infinity puzzles.
[19:10] <infinity> I see no functional differences between this and a xubuntu CD. :/
[19:16] <NCommander> infinity: all the tasks are correct on the CD ...lubuntu-desktop, lubuntu-core, standard and minimal are all present
[19:17] <NCommander> # Install the Lubuntu desktop.
[19:17] <NCommander> tasksel	tasksel/first	multiselect lubuntu-desktop
[19:17] <NCommander> as is the preseed file
[19:22] <NCommander> hrm
[19:22]  * NCommander has an idea
[19:26] <infinity> Wait, wait, wait.
[19:26] <infinity> Why is lubuntu-core a task at all?
[19:28] <infinity> That means that you almost certainly can't install lubuntu-desktop^ without lubuntu-core^...
[19:29] <gilir> infinity, including lubuntu-core package in lubuntu-desktop task is not enough ?
[19:30] <infinity> gilir: To be honest, I'm not even sure why you have lubuntu-core.
[19:31] <NCommander> infinity: trying to install lubuntu-desktop with only the CD is impossible (uninstallable packages)
[19:31] <infinity> gilir: But if you insist on having it, having the dependencies correct in STRUCTURE (as you do) would get core's packages in the desktop task, if it wasn't for the fact that you made core a task.
[19:31] <gilir> infinity, to be able to generate a lubuntu-core metapackage
[19:31] <infinity> gilir: Sure, same question.  Why do you want a metapackage with 5 packages in it?
[19:31] <NCommander> I thought d-i was supposed to explode if packages were uninstallable, right?
[19:32] <infinity> gilir: The only reason for "desktop-common" is to have a commin base for kubuntu and ubuntu.  They don't have a desktop-common metapackage or task.
[19:35] <infinity> NCommander: Ideally, things should explode long before d-i...
[19:35] <infinity> NCommander: Like, during the image build, perhaps.
[19:40] <NCommander> infinity: d-cd will still build an alternate with uninstallable packages :-/
[19:41] <infinity> NCommander: Irksome.
[19:41] <infinity> NCommander: So, it may not be an infrastruture issue at all, just broken packages?  That doesn't bug me. :P
[19:41] <infinity> gilir: ^
[19:42] <infinity> gilir: I'd still say that having lubuntu-core (both as a metapackage and a task) seems wrong, BTW.
[19:43] <gilir> infinity, well, I only need it as a metapackage :) I'm fine to remove it as a task if it's possible
[19:43] <slangasek> why do you need it as a metapackage either?
[19:45] <infinity> ^
[19:46] <gilir> slangasek, to have an easy way to install a basic / minimal system
[19:46] <infinity> gilir: Not to be dense, but the tiny package set makes no sense to me anyway.  Who would want it without desktop?
[19:47] <gilir> well it was useful before ISO was available with the official build system
[19:47] <infinity> gilir: Sure, but times change. :)
[19:47] <infinity> gilir: Anyhow, metapackages without tasks are easy.  Remove the task headers from the seed, keep building the metapackage in lubuntu-meta.  The two don't relate at all.
[19:48] <gilir> infinity, sure :) I could probably make the same by playing with the desktop seed
[19:48] <infinity> gilir: (But I'd probably argue that all the stuff in core just belongs in desktop)
[19:49] <infinity> Or, if you're trying intentionally to keep core ~= platform/desktop-common (which could have semantic uses), I'd still argue for removing the task headers, removing the metapackage, and just letting the STRUCTURE deps pull core into desktop.
[19:49] <infinity> (Which is what happens with desktop-common for ubuntu/kubuntu)
[20:25] <jibel> text installer vanished from DVDs ?
[20:27] <doko> infinity, please could you accept timbl?
[20:32] <stgraber> is it just me or do we have publisher/archive problems? I still don't see ubiquity 2.7.20 here and it built 2.5 hours ago...
[20:33] <stgraber> (I still get ubiquity 2.7.17)
[20:33] <skaet> stgraber,  its still not published.
[20:33] <skaet> arm builds finished about an hour ago
[20:34] <skaet> we're waiting for current publisher run to pick it up.
[20:34] <stgraber> oh, arm, that'd explain it indeed :)
[20:47] <skaet> ok,  looks like ubiquity's landed in the archive.
[20:47] <skaet> kicking off the desktop, dvd rebuilds
[21:04] <doko> what is the story behind usplash?
[21:05] <slangasek> doko: kill all traces of it
[21:06] <doko> slangasek, I'll assign to ubuntu-archive ;-P
[21:06] <slangasek> jibel: yes, per discussions at UDS we're replacing the full 4.4GB DVD image with a smaller 1.5GB USB stick
[21:06] <slangasek> it will still be called a "DVD" image, but it will be smaller and more practical for other uses
[21:06] <slangasek> doko: isn't it already gone from the archive though? :
[21:07] <slangasek> doko: also, subscribe rather than assign please, if you want it to show up on the right list :)
[21:07] <doko> slangasek, but not dependencies, see http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html for the packages starting with usplash*
[21:07] <slangasek> ah, sure
[21:08] <slangasek> those should definitely all go away; plymouth is non-optional, usplash conflicts with plymouth
[21:08] <doko> infinity, slangasek please accept transgui mathgl flphoto, all fixing ftpfs
[21:22] <gilir> infinity, NCommander I think I found a problem, libavcodec* is excluded from the "ship" seed, which block several packages to be installed
[21:23] <gilir> is ffmpeg / libavcodec still banned from the CD, or can I safely add it ?
[21:25] <slangasek> it is still banned from the CD.
[21:29] <doko> please accept opennebula
[21:33] <jibel> slangasek, from the discussion on ubuntu-devel I was not sure that it meant dropping the text installer from the new DVDs. Thanks.
[21:38] <skaet> Ubuntu desktop images (20110829.1) with ubiquity update now posted on iso tracker.
[21:41] <NCommander> d-i/armel is built, pending publication. omap3 netboot images will likely be unusable due to an issue with ethernet on omap3
[21:41] <NCommander> ^- skaet
[21:42] <skaet> Ncommander,  understood.   Is there someone looking at the omap3/ethernet issue?  bug number?
[21:51] <Daviey> Please can python-carrot be promoted (MIR ack'd) and glance be accepted from unappoved.  Thanks.
[21:54] <cjwatson> jibel: removed specifically from the Ubuntu DVD; others haven't changed
[21:55] <cjwatson> anything I can be looking at given a spare half-hour or so before I go to bed?
[22:03] <Daviey> doko: What was  https://launchpad.net/ubuntu/+source/php5/5.3.6-13ubuntu3.1 for?
[22:05] <doko> Daviey, accident. but the accident did succeed for armel and powerpc. can you fix the amd64 one?
[22:05] <Daviey> doko: I was lazy and just fired a rebuild to see if it is a real issue.
[22:06] <doko> Daviey, fine, then it's your problem now ;-P
[22:06] <doko> slangasek, ^^^ he volunteered
[22:06] <Daviey> aww crap.
[22:07] <cjwatson> gilir: anything that requires libavcodec would cause such a problem, yes, if you still have the blacklist entry.  although Ubuntu Studio images have had libavcodec on them for ages and we agreed that was OK, so I don't see why we couldn't do the same for Lubuntu, really
[22:08] <Daviey> doko: This wasn't an issue when you did the rebuild last time, was it?
[22:08] <cjwatson> the TB resolution principally applied to CD images that we were pressing and shipping; for images we just offer for download, I don't see why they need to be treated any differently from packages we offer for download in the archive
[22:08] <doko> Daviey, I don't know, and slangasek couldn't reproduce this one either :-(
[22:11] <skaet> cjwatson,  looks like we're seeing issues with the newest images (with new ubiquity, though not sure if related),  can you switch to #u-testing?
[22:17] <doko> skaet, I'd like to ask lamont tomorrow to give back failed builds on amd64 and i386 and powerpc. the buildds are idle, and should be fine to handle the load
[22:18] <skaet> doko,  hold off on that please.   We've got too much breakage, and a possibly security update about to land.
[22:20] <Daviey> doko: looks like it's purging.. gah.
[22:21] <doko> skaet, can we work around it be up-scoring needed builds?
[22:21] <Daviey> doko / skaet: If the failed builds were given back, if they succeed they'll be jailed in unapproved so wouldn't endager the archive stability, right?
[22:21] <infinity> Daviey: No.
[22:21] <infinity> Daviey: Only sources get shunted to unapproved.
[22:22] <skaet> doko, what does it hurt to wait 1-2 days?
[22:22] <Daviey> Hmm, I thought binary was aswell.
[22:22] <doko> skaet, because the buildds will be loaded after the thaw
[22:24] <cjwatson> Daviey: never
[22:24] <doko> Daviey, php5 failed as usual on amd64
[22:25] <Daviey> doko: yeah
[22:25] <skaet> doko, if things look better this time tomorrow, we can see about it, but right now priority is getting beta 1 out.
[22:25] <doko> skaet, we have now five i386 buildds, and three amd64 buildds, that should be fine. ok, I'll ask you again tomorrow
[22:26] <cjwatson> giving back individual shortish builds isn't a problem (even now IMO), but a mass give-back risks a situation where all available buildds are building something multi-hour
[22:27] <doko> I would agree, if we only had two buildds/arch
[22:27] <cjwatson> I've seen that situation with >2
[22:30] <infinity> Daviey, doko : A quick guess (I can test this), but changing the autoconf build-dep to autoconf2.13 might make it happy.
[22:31] <Daviey> infinity: it would have used that, no?
[22:31] <doko> infinity, cool, have a try, and take the issue
[22:32] <Daviey> infinity: can i assing bug 837049 to you?
[22:32] <ubot4> Launchpad bug 837049 in php5 (Ubuntu Oneiric) (and 1 other project) "php5 FTBFS (amd64 only) (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/837049
[22:32]  * infinity scowls.
[22:32] <infinity> I'll test and let you know. :P
[22:33] <skaet> slangasek,  anyone around that can look into the upgrade issues that they're seeing from natty -> oneiric?
[22:33] <cjwatson> skaet: #ubuntu-devel indicates that TheMuso is looking into it ...
[22:34] <slangasek> skaet: which upgrade issues are these?
[22:34] <jibel> slangasek, bug 836798
[22:34] <ubot4> Launchpad bug 836798 in pyatspi (Ubuntu Oneiric) (and 1 other project) "natty to oneiric upgrade failed: Could not perform immediate configuration on 'python-pyatspi2' (affects: 2) (heat: 12)" [Critical,Confirmed] https://launchpad.net/bugs/836798
[22:35] <skaet> cjwatson, jibel,   are they the same?  it sounded different from the channel discussion.
[22:36] <cjwatson> that's the exact bug TheMuso said he was working on
[22:36] <cjwatson> so what's the other thing you mention as "they"?
[22:37] <jibel> skaet, it is the critical upgrade issue, the other one I was mentioning is far behind this one in term of importance.
[22:37] <cjwatson> if you mean the freezes Charlie reported, as I said, a system freeze is always a kernel bug
[22:38] <jibel> slangasek, the upgrader fails to calculate a correct upgrade path to transition from at-spi1 to at-spi2
[22:38] <skaet> cjwatson, sorry,  "they" are the bugs - system freeze,  screen dump, pyatspi upgrade.
[22:38] <cjwatson> I think we all need to try to be quite precise :)
[22:38] <skaet> :)
[22:38] <skaet> agreed!
[22:38] <charlie-tca> Let's not count mine until I see if it can be reproduced
[22:39] <cjwatson> I'm not desperately worried about an upgrade freeze for the purposes of oneiric beta, because by definition it must be a bug in the *natty* kernel
[22:39] <cjwatson> if it happened to everyone we'd need to see about some kind of workaround; although we might also expect that something like that that happened to everyone would have been fairly prominent in the stable fix queue by now
[22:40] <cjwatson> the pyatspi upgrade is more of a concern because that's clearly a logical flaw we can and should fix
[22:40] <cjwatson> no possibility of it being hardware-specific or whatever
[22:52] <ScottL> cjwatson, bug #837000
[22:52] <ubot4> Launchpad bug 837000 in usplash-theme-ubuntustudio (Ubuntu Oneiric) (and 9 other projects) "usplash cruft removal (affects: 2) (dups: 1) (heat: 16)" [High,Confirmed] https://launchpad.net/bugs/837000
[22:53] <ScottL> cjwatson, how would i fix this?  apparently i need to address removing the ubuntustudio usplash package from oneiric
[22:53] <skaet> Ubuntu DVD 20110829.1 posted
[22:54] <slangasek> ScottL: there's no action needed by you for that bug; the archive admins will remove it from the archive
[22:56] <cjwatson> yep
[22:56] <cjwatson> plymouth-theme-ubuntustudio already exists
[23:01] <ScottL> cjwatson, i know about plymouth-theme-ubuntustudio...i made it ;)
[23:01] <ScottL> heh, probably the only package
[23:01] <ScottL> slangasek, cjwatson thank you very much :-)
[23:01] <cjwatson> indeed, I was just emphasising that you don't even need to work on a replacement since you already have one
[23:02] <cjwatson> infinity: https://launchpadlibrarian.net/76130771/buildlog_ubuntu-oneiric-armel.mrpt_1%3A0.9.4-1ubuntu2_FAILEDTOBUILD.txt.gz - do you think anyone would mind if I removed mrpt's binaries on armel?
[23:02] <cjwatson> "virtual memory exhausted: Cannot allocate memory" doesn't look exactly promising
[23:03] <cjwatson> no rdepends
[23:03] <cjwatson> I suppose I could lob it back and see if a different buildd randomly succeeds, but it takes a day to build
[23:14] <infinity> cjwatson: A different machine with more swap might like it better.  If there are stale old binaries you want to ditch, though, go nuts.  I doubt anyone will care.
[23:22] <skaet> Xubuntu daily-live 20110829.1 (posted)
[23:22] <charlie-tca> Thank you
[23:29] <doko> infinity, please accept gcc-m68hc1x libavg ckermit
[23:29] <doko> or somebody else
[23:46] <Daviey> Please can python-carrot be promoted (MIR ack'd), glance be accepted, cobbler be accepted and openstack-dashboard be rejected. Thanks.
[23:47] <Daviey> Oh, and kombu promoted. (MIR also ack'd)
[23:50] <Daviey> not quite sure why python-novaclient was allowed into unapproved it is no change (including version), from what is in the archive
[23:51] <Daviey> Suprised that wasn't rejected straight away
[23:53] <cjwatson> doko: the gcc-m68hc1x change is wrong.  O_TRUNC and O_CREAT belong in the flags argument; mode should be a permissions word like 0644 or something
[23:53] <cjwatson> doko: I'm rejecting that, can you please upload a correct fix instead?
[23:53] <doko> cjwatson, ok
[23:54]  * doko grumbles about old toolchain stuff and kees default changes
[23:55] <cjwatson> ckermit accepted; libavg is mine so can't accept that
[23:55] <doko> anyway, things will have to wait until tomorrow, afk now
[23:55] <cjwatson> yeah, me too
[23:56] <kees> doko: old? the defaults are wonderful :)
[23:56] <doko> kees, I like pie on my plate only