[00:00] <slangasek> bdrung: we generally expect the archive to be in sync with the ISOs during RC validation, so either you'd need to get sign-off from the responsible listed on https://wiki.ubuntu.com/LucidLynx/ReleaseManifest for a respin this late, or it waits until after RC
[00:01] <bdrung> ok, waiting is the solution. i just wanted to make sure that it hits the final release
[00:01] <bdrung> slangasek: thanks for the information
[00:03] <ScottK> bdrung: Is upstream planning to accept those changes or are the potientially permanent Ubuntu diff?
[00:03] <bdrung> ScottK: they want to adopt the icon - two patches are cherry-picked from upstream
[00:03] <ScottK> OK.
[00:04] <bdrung> no permanent ubuntu diff
[00:12] <slangasek> ScottK: opendkim in
[00:21] <slangasek> just sponsored python-virtualenv, would appreciate a review
[00:21] <slangasek> (when it lands in, say, 5 min)
[00:27] <ScottK> The means you have time to review opendkim, right?
[00:27] <slangasek> ScottK: already did it
[00:27] <ScottK> Nevermind
[00:27] <ScottK> Just noticed.
[00:28] <ScottK> Don't see virtualenv yet
[00:30] <slangasek> oh, because I failed to build with -sa
[00:30]  * slangasek tries again
[00:31] <doko__> slangasek, lamont: what about the glib2.0 update (fixing the sparc build). lamont, or did you have some kind of hack in mind?
[00:32] <ScottK> It would be nice to start sooner rather than later on all the retries that would follow that fix.
[00:34] <slangasek> doko__: not accepting it during RC validation; I realize that's going to set us back on retries, but I need the board clear for now
[00:38] <slangasek> doko__: oh, but do please upload it if you have the fix - I thought the glib2.0 in the queue was the one you meant, but that's pitti's dbgsym fix
[00:52] <slangasek> edubuntu rebuild started
[00:52] <slangasek> is there anyone around who can do wubi testing?
[00:54] <slangasek> charlie-tca and davmor2 both reported that wubi was "not present" on the Xubuntu desktop ISOs; but I can definitely see it on the ISO, and don't have Windows around to test with
[01:01] <slangasek> ^^ there we go
[01:02] <doko__> lamont, slangasek: glib2.0 uploaded
[01:03] <slangasek> doko__: thanks
[01:18] <sbeattie> slangasek: what did they mean by doesn't appear? I have an old win2k8 server prerelease instance that sees the wubi autorun instance with the iso inserted.
[01:19] <slangasek> 15:52 < charlie-tca> When you try to install using wubi, it does not appear in any menu
[01:19] <slangasek> 15:53 < charlie-tca> I put the desktop cd in the drive, there is no wubi to select
[01:19]  * cody-somerville wonders if xscreensaver's 'New Login' feature being broken is a good enough bug to do an upload.
[01:24] <slangasek> sbeattie: so if you're seeing the wubi menu, your guess is as good as mine
[01:24] <slangasek> cody-somerville: are you asking, or just wondering? :)
[01:24] <sbeattie> slangasek: has xubuntu been respun since then?
[01:25] <slangasek> sbeattie: 20100419 is the latest
[01:25] <cody-somerville> slangasek, Wondering with the hope someone might suggest if it is or not. I've tried asking mr_pouit a few times but he hasn't gotten back to me.
[01:25] <slangasek> no respins because I haven't seen anything I could fix by respinning
[01:25] <sbeattie> slangasek: oh, okay, I was going to try with 20100418
[01:26] <cody-somerville> slangasek, http://bazaar.launchpad.net/~ubuntu-desktop/xscreensaver/ubuntu/revision/16 is the change to fix it
[01:26] <slangasek> cody-somerville: oh, well, it's a bugfix so the release team wouldn't block it, but I think it's for you guys to decide if it's worth the upload
[01:57] <ScottK> slangasek: virtualenv accepted.
[02:00] <slangasek> thanks :)
[02:06] <sbeattie> slangasek: I get wubi with 20100418 xubuntu daily-live i386 cd as well.
[02:06] <slangasek> sbeattie: ok; we'll have to wait for them to resurface and give more detail, thanks for double-checking
[02:45] <slangasek> ogra: omap netbook respun, finally; spent too long waiting for acorn to get its act together
[03:23] <ScottK> slangasek: Some additional Unverse syncs for you if you have a moment: http://paste.debian.net/69990/
[03:30] <ScottK> slangasek: Additional binary removals due to the lack of Python2.5: autodocktools mgltools-opengltk
[03:44] <ScottK> slangasek: revised list: http://paste.debian.net/69994/
[05:30] <slangasek> ScottK: syncs running
[05:30] <slangasek> ScottK: autodocktools, mgltools-opengltk removed
[05:38] <ScottK> Excellent.
[05:38] <ScottK> The two recent Universe uploads in queue are mine if you could have a look ....
[05:38] <ScottK> No rush.
[05:39]  * slangasek gets a FTBFS mail for OOo/armel and screams
[05:39] <slangasek> Session terminated, killing shell...make: *** [debian/stampdir/binary-arch] Terminated
[05:39] <slangasek>  ...killed.
[05:39] <slangasek> Build killed with signal 15 after 150 minutes of inactivity
[05:40] <slangasek> lamont: ^^ why did satinash screw us over?
[07:17] <ttx> Good morning
[07:28] <ara> morning ttx
[08:09] <ttx> slangasek: you don't have any plans to respin the server ISO, we can safely work on test coverage ?
[08:36] <slangasek> ttx: no plans to respin
[08:36] <ttx> slangasek: ok
[09:59] <ev> slangasek: I've replied to your comment in bug 558488, but I'd like to get feedback on my suggestion before I go ahead and make that change.
[10:02] <slangasek> ev: hmm, sounds risky to me, precisely because other things may parse it
[10:02] <ev> unfortunately I think all we have are risky options, but I'm open to further suggestions
[10:02] <ev> I guess we could hardcode it for just this release
[10:03] <slangasek> I think that would be least risky, yes
[10:04] <ev> right, I'll work on patches to ubiquity and casper that do just that
[10:04] <slangasek> also, I don't think anything sets DISTRIB_ID for flavors, does it?
[10:04] <slangasek> (if it does, that's buggy, because this is a conffile)
[10:04] <slangasek> before we entirely rule out editing of DEBVERSION, I guess I'd like to have cjwatson's take on it
[10:05] <ev> okay
[10:05] <ev> DISTRIB_ID> ah, my mistake for assuming that it was set for flavors.
[10:06] <slangasek> really, the only place you can distinguish is in the install media; once you've installed, it becomes muddled
[10:06] <slangasek> but .disk/info also includes the lavor name, doesn't it?
[10:06] <ev> ah, wow
[10:06] <ev> -ENOTENOUGHTEA
[10:06] <ev> or something like that
[10:07] <ev> way too many characters
[10:07] <ev> anyway, yeah, we can just check the first field of .disk/info
[10:08]  * slangasek puts mountall to the rack.  TELL ME YOUR SECRETS
[10:09] <ev> lol
[10:09] <cjwatson> my worry about doing it in ubiquity etc. is that it's hard to tell between LTS and non-LTS flavours there
[10:10] <cjwatson> checking DISTRIB_ID seems ... likely to be messy
[10:10] <cjwatson> and yeah, what slangasek said above
[10:10] <cjwatson> in that case what I mean is "checking .disk/info for the flavour name seems ... likely to be messy"
[10:11] <cjwatson> I think I'd be more comfortable with a flavour-specific change to DEBVERSION, THB
[10:11] <cjwatson> TBH
[10:12] <cjwatson> so, um - do CD-based upgrades from hardy actually work right now?
[10:12] <cjwatson>   hardy)
[10:12] <cjwatson>     export PREV_CODENAME=dapper # need to support upgrades from previous LTS
[10:12] <cjwatson>   lucid)
[10:12] <cjwatson>     export PREV_CODENAME=karmic
[10:12] <cjwatson>     export CODENAME=hardy
[10:12] <cjwatson>     export CODENAME=lucid
[10:13] <cjwatson> hmm, maybe that doesn't matter since there's no release-upgrader-* in either hardy-backports or karmic-backports
[10:15] <sbeattie> cjwatson: erm? I haven't done a hardy->lucid cd only upgrade yet for rc, but at least for the ubuntu-server amd64 iso, I know it's worked for the last two betas.
[10:16]  * sbeattie has an amd64 machine that has a NIC that hardy's kernel doesn't recognize.
[10:18] <ev> cjwatson: ubiquity> So to be clear, you think that we're okay to risk breaking tools that parse .disk/info over just hardcoding a check for ubiquity and kubuntu like so for a single release? http://paste.ubuntu.com/419733/ http://paste.ubuntu.com/419736/
[10:19] <ev> err ubuntu and kubuntu
[10:19] <cjwatson> sbeattie: 10:13 <cjwatson> hmm, maybe that doesn't matter since there's no release-upgrader-* in either hardy-backports or karmic-backports
[10:19] <cjwatson> sbeattie: accounts for this working
[10:22] <cjwatson> ev: the only thing I know of that actually *parses* .disk/info is wubi; otherwise, I believe parsing it to be very rare.  Can you think of anything else?
[10:22] <cjwatson> that said wubi would actually break if we inserted LTS there right now, but the regex is easy to fix
[10:23] <cjwatson> most things just display its contents or similar
[10:23] <cjwatson> or log them
[10:23] <cjwatson> so yeah, I think my personal preference would be to change .disk/info and fix wubi's regex
[10:24] <ev> well, and ubiquity and casper, but yeah, I can't think of anything else that would
[10:24] <ev> okay
[10:24] <cjwatson> do they parse it?
[10:24] <ev> ubiquity does
[10:24] <cjwatson> mm, casper does some minimal parsing
[10:24] <cjwatson> ./scripts/casper-bottom/10adduser:55:RELEASE="$(cut -d' ' -f1-2 /root/cdrom/.disk/info 2>/dev/null)" || RELEASE=""
[10:25] <ev> indeed
[10:25] <cjwatson> that wouldn't break, but it probably ought to be changed, since we want that to show LTS as well
[10:26] <cjwatson> and same in ubiquity/ubiquity/misc.py
[10:26] <cjwatson> on the flip side, changing .disk/info would mean that we wouldn't have to change things like cdrom-detect
[10:30] <cjwatson> in wubi, http://paste.ubuntu.com/419742/ looks sufficient; I've checked all the callers and it doesn't display the version anywhere, it's just checking it against isolist.ini, so as long as we leave version in isolist.ini alone, we can just ignore "LTS ", I think
[10:30] <cjwatson> (actually, http://paste.ubuntu.com/419743/ is clearer isn't it)
[10:31] <ev> How does this look for ubiquity: http://paste.ubuntu.com/419744/
[10:31] <ev> wubi> looks good
[10:32] <cjwatson> don't you want the assignments outside the parens?
[10:32] <ev> err wow, I'm way off the mark today
[10:32] <ev> yeah
[10:33] <cjwatson> >>> test('Ubuntu 10.04 "Lucid Lynx" - Release Candidate i386 (20100419.1)')
[10:33] <cjwatson> 'Ubuntu 10.04'
[10:33] <cjwatson> >>> test('Ubuntu 10.04 LTS "Lucid Lynx" - Release Candidate i386 (20100419.1)')
[10:33] <cjwatson> 'Ubuntu 10.04 LTS'
[10:33] <cjwatson> looks fine to me with that syntactic correction
[10:34] <ev> okay
[10:36] <cjwatson> wubi change committed - can you publish an updated wubi.exe at some point?
[10:36] <ev> I'll do it now
[10:38] <ev> done
[10:39] <cjwatson> BTW, one reason I prefer it this way is that it's really quick to revert things just in cdimage if it goes wrong
[10:40] <slangasek> true
[10:44] <cjwatson> which admittedly would put us out of compliance with branding, but that's probably true with just about any failure mode here ...
[10:44]  * slangasek nods
[10:47] <cjwatson> grr, I didn't realise the translation import queue was quite so far behind
[10:48] <slangasek> dpm mentioned it was slow; how bad is it now?
[10:48] <doko_> slangasek: is there a buildlog left from the OOo build?
[10:48] <cjwatson> "1-50 of 19038 results"
[10:48] <cjwatson> it's backed up to the 16th
[10:48] <slangasek> doko_: no, I restarted the build because the log was useless - it just hung after outputting openoffice.org-core
[10:49] <slangasek> doko_: so the only relevant output is what I quoted in scrollback
[10:49] <cjwatson> though it is catching up; it's up to late on the 16th, and it was only up to sometime on the 15th last night, so that's rather more than one hour per hour
[10:50] <ogra> slangasek, hrm, seems acorn didnt have the new livecd-rootfs or my fix didnt work, there is no vmlinuz file in /boot
[10:50] <slangasek> cjwatson: I don't follow all the implications - is that going to impact the ability to export langpacks in a timely manner this week?
[10:51] <slangasek> ogra: the actual build was on clementine, acorn stiffed me
[10:51] <ogra> lamont, can you check the livecd-rootfs version on clementine ?
[10:51] <ogra> slangasek, ok
[10:51] <slangasek> ogra: as for not having the new one - perhaps I wrongly assumed that the 'buildlive base; build-livecd-base' cronjob helped with this
[10:51] <slangasek> I can retry it, clementine isn't doing anything else
[10:52] <slangasek> (and lamont won't be around for a few hours, I'm sure)
[10:52] <ogra> slangasek, i thought so too, but it might actually be a cronjob
[10:52] <slangasek> ogra: hah - build-livecd-base doesn't know about armel
[10:53] <slangasek> blast, and I just restarted the build on clementine
[10:53] <ogra> heh, ok
[10:56] <slangasek> well, that doesn't really seem to do anything useful on the buildds anyway... maybe this second build on clementine will work
[10:57] <ogra> i'll check once there is an image
[11:07] <cjwatson> slangasek: I *think* imports and exports are largely independent
[11:07] <slangasek> but it may impact the up-to-dateness of the langpacks we export?
[11:07] <cjwatson> the reason I care was that I was hoping to get a last-minute installer translation fix in, which is dependent on an import of d-i translations - but not the end of the world if it doesn't
[11:07]  * slangasek nods
[11:07] <cjwatson> maybe for the odd few upstream translations cycling through, although I noticed a huge pile of kde-i18n being imported
[11:08] <cjwatson> I'd expect it to catch up fairly quickly when it hits the freeze
[11:09] <cjwatson> but just a guess
[11:59] <lamont> slangasek: acorn had multiple remaining issues, which I believe are all fixed, one of your livecd runs is now going, the other I killed since it was a dup
[11:59] <slangasek> lamont: ok - how about logfile visibility?
[12:00] <lamont> which machine and what url are you trying and not succeeding with?
[12:00] <lamont> from which ...
[12:00] <slangasek> lamont: antimony; was getting 404s before?
[12:01] <lamont> and sample URL?
[12:01] <slangasek> http://acorn.buildd/~buildd/LiveCD/
[12:03] <lamont> try now?
[12:06] <slangasek> lamont: there we go - thanks
[12:06] <ogra> lamont, is livecd-rootfs 1.114 currently installed on either of  the amrel livefs builders
[12:06] <ogra> *armel
[12:07] <ogra> else we dont need to bother to rebuild omap yet
[12:07] <lamont> ogra: both - acorn had 1.112 until moments ago
[12:07] <lamont> omap is building with 1.114
[12:07] <ogra> sweet, thanks :)
[12:20] <slangasek> lamont: on which buildd is it building with 1.114?
[12:28] <lamont> acorn
[12:30] <slangasek> right, thanks
[12:50] <lamont> wtf is up with oo.o/armel?
[12:50] <lamont> I refuse to believe that it took > 2.5 hrs to do:  dpkg-deb: building package `openoffice.org-core' in `../openoffice.org-core_3.2.0-7ubuntu3_armel.deb'.
[12:51] <hyperair> it might have =p
[12:51] <hyperair> wait, 28M is kinda small..
[12:52] <lamont> hyperair: if so, pushing it back to the top of the hill for another 2-day run at the problem probably isn't the answer
[12:52] <hyperair> 2 days huh
[12:52] <hyperair> that sounds painful
[12:53] <lamont> yeah - it's a good thing they modularized the build so that it's not one big monolithic takes-forever pile, eh?
[12:53] <lamont> oh wait.  that was just from my dreams
[12:58] <slangasek> man, dreams about OOo, that's really taking your work home with you
[13:16] <ogra> oh, come on, its not two days ... only 40h or so :P
[13:16] <stgraber> ;)
[13:25] <mvo> lamont: and the funny thing is that we may need another OOo upload before final
[13:26] <mvo> (maybe not so funny)
[13:27] <ogra> mvo, what ?!?
[13:28] <mvo> bug #566584 and bug #516727
[13:29] <mvo> the alternative is to remove ooo-evolution and ooo-filter-binfilter during the upgrade (well, before it starts)
[13:30] <ogra> bah, sigh
[13:32] <lamont> WTF does oo.o pre-depends something?
[13:32] <lamont> well, other than the obvious, I suppose. but still SHEESH
[13:32] <mvo> lamont: it pre-depends on TEH WORLD
[13:32] <lamont> mvo: it IS the world.
[13:32] <mvo> lamont: like -core, that needs the full gstreamer, all of gnome etc
[13:32]  * ogra is happy we dont use it in any armel images anymore
[13:33] <lamont> I'd really like to see the size of that beast treated as an RC bug for lucid+1
[13:33] <mvo> lamont: don't ask why, I still have bad dreams from looking at it
[13:33] <mvo> lamont: I *hope* that I found a solution, _rene_ helped a lot to explain me why certain stuff is needed (or done in the way its done)
[13:33] <mvo> buy him a beer if you see him
[13:34] <lamont> oh, goodl
[13:38] <slangasek> lamont: is acorn still going?
[13:39] <slangasek> Unable to fetch squashfs sort list; using a blank list.
[13:39] <slangasek> but no output from mksquashfs after that
[13:39] <lamont> mksquashfs
[13:39] <ogra> didnt we quietenm that down ?
[13:39] <stgraber> slangasek: do you have the URL to what will be the release announcement and release notes for RC ?
[13:39] <lamont> the Unable... is normal
[13:39] <slangasek> lamont: yes, the lack of output afterwards is not
[13:40] <slangasek> stgraber: announcement: https://wiki.ubuntu.com/LucidLynx/RCAnnouncement; release notes: https://wiki.ubuntu.com/LucidLynx/ReleaseNotes; tech overview (which may have been what you meant by release notes): https://wiki.ubuntu.com/LucidLynx/TechnicalOverview
[13:41] <ogra> slangasek, yeah, there should at least be two additional lines
[13:41] <stgraber> slangasek: thanks
[13:41] <ogra> i think the progressbar will only be shown after it finished though
[13:42] <lamont> http://paste.ubuntu.com/419834/ <-- slangasek: thoughts?
[13:42] <slangasek> lamont: 22min without further output - so is that build still doing something, or did it die a mangled death?
[13:42] <slangasek> lamont: is that the mksquashfs?
[13:42] <lamont> root      6663 92.4 50.3 308968 241044 ?       Sl   13:20  20:28          \_ mksquashfs /build/chroot-livecd/ livecd.ubuntu-netbook-omap.squashfs -sort livecd.ubuntu-netb
[13:42] <lamont> yes
[13:43] <lamont> and the right side of my terminal window for the *snip*
[13:43] <slangasek> doesn't look very healthy to me :/
[13:43] <slangasek> well, let's let it run for another .5h or so
[13:43] <ogra> probably use a bucket with water if the alarm clock doesnt suffice :/
[13:43] <lamont> slangasek: about to run kids to school, will be afk for closer to 1.25h
[13:43] <ogra> i really wonder what kind fo boards they sent you ...
[13:44] <lamont> figure ~7am pacifc
[13:44] <slangasek> ok
[13:44] <ogra> why dont we see all these issues on our dev boards
[13:44] <lamont> ogra: run livecd-rootfs in a lucid chroot on lucid on your boards?
[13:44] <lamont> do you, that is
[13:44] <ogra> lamont, i did that once, yes
[13:45] <lamont> ogra: slangasek does it all the time.
[13:45] <ogra> not atm, since i'm focused on omap, but for getting a squashfs to play with i do such stuff
[13:45] <ogra> lamont, but on your silicon
[13:45] <ogra> i dont get why you see these many issues on these new bbg3's
[13:45] <lamont> maybe we're just lucky?
[13:45] <lamont> dunno
[13:46] <lamont> anyway, afk kids->school
[13:50] <slangasek> hah; so I fix plymouth so that it will actually send mountall a 'c' when the user wants to cancel a fsck
[13:50] <slangasek> which uncovers a crasher bug in mountall
[13:51] <slangasek> apparently I'm the first person to ever hit this code path
[14:07] <cjwatson> slangasek: FYI the beta-2-relnoted bug regarding RAID arrays larger than 2TB still exists
[14:08] <slangasek> cjwatson: argh?  I thought I saw that the bug was closed - not so much?
[14:08] <cjwatson> looks like I need to rebuild a generated file; in the meantime, I'm restoring the technicaloverview note
[14:08] <slangasek> ah, you've just reopened, ok
[14:09] <cjwatson> discovered as part of attempting to disentangle the hopelessly unintelligible dogpiled bug 527401
[14:14] <slangasek> lamont: ah, must've been buffering or something; omap build finished successfully now
[14:22] <stgraber> slangasek: updated the release announcement for edubuntu. We still have some annoying bugs, I'll release note them and an updated edubuntu-artwork package should be uploaded soonish (so we can test that extensively post-RC).
[14:23] <ogra> slangasek, \o/
[14:24] <slangasek> stgraber: could you please consolidate that into 4 paragraphs or fewer?
[14:33] <ev> I imagine it's too late for Lucid, but can we get upgrade tests for wubi in 10.10?
[14:33] <ev> in the iso testing tracker, that is
[14:34] <ev> ara: ^
[14:34] <ara> ev, noted
[14:34] <ev> thanks!
[14:35] <ara> are ubuntu studio cds always that big???
[14:35] <ara> that does not fit in a CD, that's for sure
[14:37] <slangasek> yes, it's meant to be a DVD image
[14:37] <ara> slangasek, ok :)
[14:37] <ara> slangasek, thanks
[14:49] <lamont> slangasek: yeah - I think it does some serious processing, and doesn't bother to flush stdout
[15:00] <ogra> slangasek, i'm happy to report that 21.2 has vmlinuz in /boot :)
[15:00] <slangasek> yay
[15:01]  * ogra now hopes there are not other bugs he didnt find yet
[15:01] <ogra> running an install now ... i'll know more in ~2h
[15:01] <ogra> yay for speedy HW
[15:07] <cr3> hi folks, I would appreciate if someone could have a look at bug #567568 in case it might be considered release critical
[16:20] <ogra> in-target: Read error on /dev/mtd2: Cannot allocate memory
[16:20]  * ogra cries
[16:21] <ara> network-manager is not being included in ubuntustudio's cd
[16:23] <ara> no worries, it is there
[16:30] <jdstrand> are server ISOs scheduled for a respin or can I go ahead with my testing on http://cdimage.ubuntu.com/ubuntu-server/daily/20100419.1/lucid-server-amd64.iso
[16:30] <jdstrand> ?
[16:35]  * ara wonders how not installing network-manager is seen as an improvement (http://ubuntustudio.org/KarmicKoala)
[16:35] <jdstrand> slangasek: ^ (regarding server isos)
[16:38] <pitti> ara: urgh, we had n-m on server ISOs before? that sounds kinda wrong..
[16:38] <ara> pitti, I am talking about ubuntu studio
[16:38] <pitti> ah
[16:38] <ara> pitti, :)
[16:39] <pitti> ara: ah, I misread jdstrand's comment :)
[16:39] <jdstrand> heh, sorry
[16:42] <jdstrand> ttx: do you know if the server isos need a respin? I want to test 20100419.1 but don't want to waste testing on it if it is going away
[16:43] <slangasek> jdstrand: there are no respins planned
[16:43] <jdstrand> ok cool
[16:44] <slangasek> in general, respins will be marked on http://iso.qa.ubuntu.com/qatracker/build/all as such
[16:44] <jdstrand> slangasek: excellent, that was my next question :)
[16:49] <ogra> slangasek, so i guess omap has to skip netbook for RC ... i seem to hit that http://paste.ubuntu.com/419902/ and have no idea why
[16:50] <ogra> funnily it works flawless in d-i
[19:54] <highvoltage> slangasek: sorry to do it again, I uploaded another edubuntu-artwork package. this one should be the last one.
[21:34] <mvo> slangasek: if you could have a look at https://code.edge.launchpad.net/~mvo/openoffice/3.2.0-lucid/+merge/23875 that would be much appreciated, this should solve two OOo upgrade issues. I did some testing already and will continue tomorrow with more
[21:35] <sbeattie> slangasek: crap, live images are missing xfs and jfs utilities: bug 568024
[21:36] <cjwatson> er, wot
[21:36] <cjwatson> how'd we screw that one up?
[21:37] <sbeattie> Dunno, I thought we hit that in the alphas, but got it fixed.
[21:38] <cjwatson> looks like it may have been broken by the live-common seed split
[21:38] <cjwatson> 'cept I don't entirely see why
[21:38] <cjwatson> Package: xfsprogs
[21:38] <cjwatson> Task: kubuntu-live, kubuntu-netbook-live, xubuntu-live, mythbuntu-live, netbook-live
[21:38] <cjwatson> same for jfsutils
[21:38] <sbeattie> cjwatson: what's the difference between casper/filesystem.manifest and casper/filesystem.manifest-desktop?
[21:39] <cjwatson> ubiquity removes anything in the former but not in the latter after copying the filesystem to the live system
[21:39] <cjwatson> er, to the installed system
[21:39] <cjwatson> the difference between those two sets includes such things as the installer itself
[21:40] <cjwatson> ah, I see the seed bug - slangasek, unfortunately the archive has to be told explicitly when a task spans multiple seeds like this
[21:41] <cjwatson> there's a Task-Seeds field
[21:41] <mvo> sbeattie: I uploaded https://edge.launchpad.net/~mvo/+archive/openoffice/+packages with the fixes we talked about. you can help by installing it once the ppa2 version is build (probably in +7h or so :/)
[21:41] <sbeattie> ah, okay. xubuntu may be somewhat okay, as on it's livecd the former includes xfs-progs|jfsutils, but not the latter.
[21:41] <cjwatson> yes, kubuntu kubuntu-netbook xubuntu mythbuntu (ubuntu-)netbook are all unaffected, per the Task line above
[21:43] <cjwatson> affects ubuntu and edubuntu
[21:43]  * mvo just noticed that ooo actually only took 3,5h to build, not bad
[21:46] <cjwatson> I imagine this will increase livefs size a bit
[21:47] <cjwatson> seeds fixed
[23:53] <slangasek> highvoltage: do you mean that you want a respin of edubuntu for the new artwork upload for RC?
[23:53] <slangasek> stgraber: ^^
[23:55] <slangasek> cjwatson: Task-Seeds> sigh :/