[00:10] <ScottK> james_w: Thanks for the syncs.
[00:10] <ScottK> james_w and slangasek: Still a lot of removals need processing.
[00:10] <james_w> ScottK: np, I'll be around for a few minutes tomorrow morning, so I'll see if I have time to get to them. I'll have time to do it before release, but the sooner the better.
[00:11] <ScottK> OK.  Great.  Have a good night.
=== dmb is now known as NullPointerExcep
[03:13] <ScottK> The  libgettext-ruby in queue should fix the current package FTBFS.  It's my upload, so please review and accept.
[03:18] <ScottK> Ah.  There it is.
[04:57] <ScottK> kirkland: My condolences on #ubuntu-devel.
[05:04] <kirkland> ScottK: thanks
[05:04] <kirkland> ScottK: that was a frustrating conversation
[05:04] <ScottK> Yeah, it was frustrating even to watch.
[05:07] <kirkland> ScottK: i'm emailing ubuntu-server@ now, asking if anyone else can reproduce it
[05:07] <kirkland> ScottK: it's the most basic RAID1 install, and it fails entirely
[05:08] <ScottK> Fortunately the general advice for LTS - LTS upgrades is to wait for .1, so hopefully that gives us some time for most server upgrades.
[05:10] <kirkland> ScottK: right
[05:10] <kirkland> ScottK: thanks for shoulder to lean on; i'm out for the night ;-)
[05:12] <ScottK> Ooops.  Meant to have that conversation in -server.
[05:27]  * cjwatson accepts plymouth
[05:36] <ScottK> cjwatson: Would you please accept libticalcs.  We unscrewed some package naming confusion between Debian and Ubuntu earlier today and got a bit of a library transition to do as a result.  That one needs to go in first.
[05:39] <cjwatson> done
[05:46] <Keybuk> cjwatson: if slangasek should look at that lvm upload, be sure someone holds his jaw up - it could injure him if it hits the floor too hard
[05:46] <Keybuk> it turns out that the reason we've been having lvm issues on boot is ...
[05:46] <Keybuk> ... because devmapper was *ignoring* devices on boot
[05:47] <ScottK> cjwatson: Thanks.
[06:32] <pitti> slangasek, ScottK: so, clamav passes our rather extensive qa-regression-testing check (with a local build), and I couldn't see anything obviously bad, so I had a leap of faith and accepted it last night; just run the tests again on the final lucid .debs, works fine
[06:32] <pitti> s/just run/I just ran/
[06:32] <ScottK> pitti: Someone accepted it.  I assume slangasek.
[06:32] <slangasek> Keybuk: you have failed to adequately account for jet lag and I now have a double dislocation of the mandible without even the pleasure of eating a wicked cheeseburger
[06:33] <Keybuk> the burger from the Park Plaza room service is pretty passable actually
[06:33] <ScottK> pitti: Unfortunately, sgran found a problem yesterday, so I have my first SRU (it's not a regression from this last upload, so accepting it was still progress)
[06:33] <slangasek> Keybuk: however, before accepting, I'm going to look at the package history to see what idiot, as you put it, did think this was a good idea
[06:33] <Keybuk> slangasek: oh, I know now
[06:33] <Keybuk> upstream
[06:34] <Keybuk> akg
[06:34] <Keybuk> err, agk
[06:34] <Keybuk> akg make headphones
[06:34] <Keybuk> nice ones
[06:35] <pitti> my wife loves her AKG headphones indeed :)
[06:38] <slangasek> Keybuk: alright - so what gave them the idea?
[06:38] <Keybuk> so
[06:38] <Keybuk> the way devmapper works is that you always get an "add /block/dm-0" event first
[06:38] <Keybuk> that creates the device, and you need the device to load the table into it
[06:38] <Keybuk> so after loading the table, you then get a "change /block/dm-0" event
[06:38] <Keybuk> and that's the point at which it might actually have a filesystem
[06:39] <Keybuk> so it sounds very logical that you'd always ignore the add events
[06:39] <Keybuk> except "add" events are what "udevadm trigger" (ie. coldplug) generates
[06:40] <slangasek> right, that explains why we need it, but why did upstream ever think it was ok to ignore these events?
[06:40] <pitti> Keybuk: so our hotplugging doesn't have STARTUP==1 any more?
[06:40] <pitti> that's what the comment above seems to suggest
[06:40] <Keybuk> pitti: it never has
[06:40] <pitti> perhaps it does have in Debian?
[06:41] <Keybuk> in fact, it's pretty much nearly impossible to get that into the environment ;)
[06:41] <Keybuk> no, it doesn't in Debian either
[06:41] <Keybuk> ENV{} is limited to the environment from the kernel
[06:41] <Keybuk> by design in udev
[06:41] <Keybuk> so, err, you'd need the kernel to somehow know you were running udevadm ;)
[06:41] <Keybuk> from what I can tell
[06:41] <Keybuk> reading through the history
[06:41] <Keybuk> they thought udev should add this STARTUP thing
[06:41] <Keybuk> then they could ignore "add"
[06:41] <Keybuk> and then they got as far as talking to kay who explained they were wrong
[06:41] <Keybuk> and then they backed it out again
[06:42] <Keybuk> (it's not in the current git, which is why I felt safe removing it again)
[06:42] <pitti> so, I don't see a rule which doesn't look idempotent at first sight
[06:42] <Keybuk> pitti: I don't understand what you mean
[06:42] <pitti> Keybuk: like, causing bad effects when you run them twice
[06:42] <pitti> except for creating the symlinks much earlier
[06:43] <pitti> but we (hopefully) don't have anything during boot which watches for symlinks to appear; we use the uevents either way
[06:43] <Keybuk> http://sources.redhat.com/git/gitweb.cgi?p=lvm2.git;a=commitdiff;h=2c0df9552fd46bbf44c10d8fcfba3c4ce1f7d828#patch3
[06:43] <Keybuk> right, I think agk just thought "we don't need to process add events", and made a release
[06:43] <Keybuk> and then they learned that they did, and undid it
[06:43] <Keybuk> and the bad release was the one that we merged
[06:44] <pitti> mountall looks fine, accepting
[06:44] <pitti> (yay for being able to cancel fsck again!)
[06:45] <slangasek> pitti: modulo my comment in the bottom of that bug log :)
[06:45] <ara> good morning
[06:46] <ara> happy release week everyone
[06:46] <Keybuk> slangasek: which bug# is that?
[06:46] <pitti> bug 562811?
[06:46] <ubottu> Launchpad bug 562811 in plymouth "[Lucid] fsck cannot be cancelled in Plymouth" [High,Fix released] https://launchpad.net/bugs/562811
[06:46] <slangasek> which I haven't had a chance to debug yet, I only just found that issue after landing in London and it may have been a bug introduced by one or more of the changes in the latest uploads - though if that's the only bug we have, it's not a regression since cancelling didn't work before either
[06:46] <slangasek> Keybuk: ^^ that one, yes
[06:47] <Keybuk> which comment?
[06:47] <slangasek> oh
[06:47] <slangasek> not that bug, no
[06:47] <slangasek> 'sec
[06:47] <Keybuk> k, I can grep
[06:47] <slangasek> bug #559761
[06:48] <ubottu> Launchpad bug 559761 in plymouth "mountall needs to flush plymouth message queue before emitting upstart events" [High,Fix released] https://launchpad.net/bugs/559761
[06:48] <slangasek> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/559761/comments/26
[06:48] <ubottu> Ubuntu bug 559761 in plymouth "mountall needs to flush plymouth message queue before emitting upstart events" [High,Fix released]
[06:48] <slangasek> (I don't remember seeing the bug prior to making the last change to plymouth)
[06:49]  * slangasek waves to ara 
[06:49] <Keybuk> hmm
[06:50] <slangasek> Keybuk: in more detail: when I hit 'C', the first two fscks appear to already be running, and exit with code 32, which mountall handles gracefully.  The other two fscks, which I never actually see running, exit with code 8 (from memory), which mountall does *not* handle gracefully; then I'm given the error prompt, then I'm given the *second* error prompt, then mountall stops talking to me
[06:50] <ScottK> Whoever has been accepting my uploads, tiemu ^^^ finishes getting us through the libticables transition we didn't know we were stuck in the middle of until yesterday.
[06:50] <Keybuk> shouldn't they all end with status == SIGTERM ?
[06:50] <slangasek> (or to plymouth)
[06:52] <Keybuk> le sigh
[06:53] <slangasek> Keybuk: unless you think that particular bug affects more than just the fsck cancelling case, I think the fix should be deferred to SRU
[06:53] <Keybuk> who will do the SRU?
[06:54] <slangasek> whoever?
[06:54] <Keybuk> we're all hard at work on completely different things next cycle ;)
[06:55] <slangasek> and I don't think that's a counterargument for the need to defer it to post-release; candidate images need to start rolling today
[06:55] <Keybuk> sure ;)
[06:55] <Keybuk> rather, is this a bug you think we could live with for the forseeable future?
[06:55] <slangasek> I could.  I'm not sure if all our users will.
[06:56] <Keybuk> then we should at least debug it this week
[06:56] <Keybuk> and queue as a zero-day fix if it's obvious
[06:56] <slangasek> agreed
[06:57] <slangasek> sorry, by "SRU" I certainly didn't mean to imply "let's wait 'til next week"
[06:58] <Keybuk> so, just to confirm
[06:58] <pitti> (-proposed is open for uploads; there's a bunch of them already)
[06:58] <slangasek> ok, accepting lvm2; I agree that looks safe, though I'll regression-test today once it's in the archive
[06:58] <Keybuk> you have three fscks running
[06:58] <Keybuk> you press C
[06:58] <slangasek> Keybuk: four
[06:58] <Keybuk> one of them is cancelled
[06:58] <slangasek> two
[06:58] <Keybuk> an error appears for the other
[06:58] <slangasek> :)
[06:58] <Keybuk> and pressing I on that doesn't update plymouth with the third?
[06:59] <slangasek> pressing I *does* update plymouth with the fourth
[06:59] <Keybuk> oh
[06:59] <slangasek> pressing I at the prompt for the *fourth* does nothing
[06:59] <Keybuk> so what's the bug then?
[06:59] <Keybuk> oh
[06:59] <Keybuk> I bet I can see it
[06:59] <Keybuk>                 if ((mnt->error != ERROR_FSCK_FAILED)
[06:59] <Keybuk>                     && (mnt->error == ERROR_FSCK_FAILED_HARD))
[06:59] <Keybuk>                         break;
[06:59] <Keybuk> la la la
[06:59] <Keybuk> I bet that second one should be != ;-)
[07:00] <slangasek> two bugs - one clearly a mountall bug, that it thinks there were "serious errors" when there shouldn't have been (log never even shows fsck started for these two fses), and the other I'm not sure whose fault it is, that mountall sends a message to plymouth and doesn't act on the answer
[07:00] <slangasek> heh, probably? :)
[07:00] <Keybuk> yeah
[07:00] <Keybuk> that's why it doesn't act on the answer
[07:00] <Keybuk> as to "serious errors", that means e2fsck is returning the wrong error code
[07:01] <Keybuk> e2fsck(8) claims it will return 32 if cancelled, not 8 ;-)
[07:01] <Keybuk> I wonder whether it's because it's killed when not "in progress"
[07:01] <Keybuk> maybe we should ignore those
[07:04] <Keybuk> yeah, confirmed from the e2fsck source
[07:07] <pitti> ScottK: tiemu> accepted
[07:07] <ScottK> pitti: Thanks.
[07:10] <Keybuk> slangasek: SRU candidate just uploaded to my PPA, please test once built ;P
[07:15] <mantiena> Hi all
[07:21] <Mirv> for understanding bug priorization, I'd like to know if 8.04 LTS update-manager will start to offer 10.04 LTS upgrades only in 10.04.1 timeframe, or earlier?
[07:29] <slangasek> Keybuk: you've empirically confirmed that swapping the == for a != fixes the failure to handle 'I'?  if not, I'll want to test that part separately, so that it's not hidden by your fix for the fsck return codes
[07:30] <Keybuk> slangasek: well, it's clearly wrong
[07:30] <slangasek> (I'll feel better if there's hard confirmation that this isn't a regression I caused)
[07:30] <Keybuk> I never put != && == in the same if statement
[07:30] <Keybuk> either they're both supposed to be == or they're both supposed to be !=
[07:30] <slangasek> sure... :)
[07:30] <Keybuk> and I know they're both supposed to be !=
[07:31] <slangasek> I still want to confirm that fixing this actually fixes the code path where multiple fses have 'serious errors'
[07:31] <Keybuk> cause I know what that if is guarding against
[07:31] <Keybuk> oh, sure
[07:31] <Keybuk> that's why I asked you to test ;P
[07:31] <slangasek> does your ppa upload not also include the fix for the fsck return codes?
[07:31] <slangasek> if it does, I'll have to think up another way to cook up a test case
[07:32] <Keybuk> it does
[07:32] <slangasek> ok
[07:32] <Keybuk> you can always just checkout the rev before and build it yourself
[07:32] <slangasek> I'll probably do a local build first to test the one change , yeah
[07:32] <mantiena> Maybe someone could tell me when new daily image will be uploaded into cdimage.ubuntu.com ? There are ~150 updated packages since release candidate image (build on April 19), including ubiquity-casper, ubiquity installer, libc and other important packages, it would be nice to have an ability to test these improvements
[07:33] <slangasek> mantiena: today
[07:33] <slangasek> (but not for a couple of hours, yet)
[07:34] <mantiena> slangasek: thanks
[07:34] <slangasek> mvo: do you know the answer to Mirv's question above?  Has any decision been taken wrt when we'll turn on LTS->LTS upgrades by default?
[07:35] <mvo> slangasek: last I talked about this with robbiew was that we will turn it on around the .1 time
[07:35] <Keybuk> slangasek: but the code was wrong
[07:35] <Keybuk> now the code is right ;)
[07:35] <Keybuk> I feel the improved harmony in the universe
[07:35] <Keybuk> it's like a sixth sense
[07:35] <Keybuk> <g>
[07:41] <slangasek> Mirv: see mvo's comment above for the answer
[07:41] <slangasek> Keybuk: heh - hopefully in addition to the code being right, the bugs go away ;)
[07:42] <Keybuk> the bugs just move
[07:42] <Keybuk> but they only move when you're not looking at them
[07:42] <Keybuk> changing the code just takes away their home
[07:42] <Keybuk> they soon find a new home
[07:59] <Mirv> slangasek: thanks, then 8.04->10.04 upgrade problem is not that critical at this point yet
[08:00] <mvo> Mirv: what upgrade problem is that?
[08:00] <Mirv> mvo: well the openoffice.org-voikko, bug #562948 - dependency cycle
[08:00] <ubottu> Launchpad bug 562948 in update-manager "Upgrade 8.04 LTS -> 10.04 LTS fails at circular dependency with openoffice.org-voikko" [Undecided,New] https://launchpad.net/bugs/562948
[08:00] <Mirv> mvo: you might have an idea what should be done, since you fixed the extensions bundled in OOo source package
[08:00] <mvo> Mirv: let me have a look
[08:01] <mvo> Mirv: yeah, I wonder if we can use something similar here
[08:01] <Mirv> nice thing is cleanly failing out and restoring system state
[08:26] <ogra> pitti, hmm, the util-linux task should have stayed open (or moved to e2fsprogs), the actual bug isnt fixed with the initramfs-tools/flash-kernel workaround, thanks for closing flash-kernel manually though
[08:27] <ogra> (talking about bug 563618)
[08:27] <ubottu> Launchpad bug 563618 in initramfs-tools "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Fix released] https://launchpad.net/bugs/563618
[08:31] <Keybuk> right, should be e2fsprogs
[08:31] <ogra> Keybuk, !! back in UK ?
[08:31] <Keybuk> I talked with Ted at LFC and he seemed persuaded that broken_system_clock=true should ignore the timestamps, rather than try and fix them
[08:31] <Keybuk> ogra: no, in SF still
[08:31] <Keybuk> (just about to go to bed)
[08:31] <ogra> ah, i was wondering ybout the time :)
[08:31] <ogra> *about
[08:32] <Keybuk> midnight here ;)
[08:32]  * ogra creates an upstream task for the bug
[08:51] <stgraber> slangasek: just found an issue with LTSP install on Edubuntu. I have a tentative fix for it and am testing it now. If it works, I'll upload edubuntu-artwork again and then will need a respin of the DVD image.
[08:52] <pitti> ogra: ah, please reopen then
[08:52] <stgraber> (yeah, I switched timezone yesterday and am now in Europe until after UDS)
[08:52] <ogra> pitti, already sorted, i opened a proper upstream task etc
[09:33] <Jeeves_> Hi all
[09:34] <Jeeves_> The jigdo images for Lucid on the releases mirrors seem to be broken
[09:37] <pitti> Jeeves_: I suppose many of the RC debs just disappeared as they were replaced by newer versions of packages
[09:38] <stgraber> ^ that one fixes an Edubuntu-only issue, not critical but good to have for release (guest accounts for Live-ltsp were using /bin/sh instead of /bin/bash as default shell)
[09:43] <pitti> cjwatson: I suppose this ubiquity upload really needs to go onto the next images? (slangasek seemed eager to start image building now)
[09:43] <slangasek> stgraber: why does edubuntu-artwork need another upload for the LTSP issue?
[09:44] <stgraber> because the edubuntu-dvd specific scripts are in -artwork for now ... (will be split in another package in maverick)
[09:45] <slangasek> pitti: accepted, yes
[09:45] <cjwatson> pitti: Steve's on it
[09:45] <pitti> ah, thanks
[09:45] <pitti> I guess the two of you are sitting side by side now? :-)
[09:45] <slangasek> across, yes
[09:45]  * pitti waves to London
[09:46] <slangasek> stgraber: so there's a corresponding script change that has to be made, in addition to the ltsp change?  If so, I'd like to see that in parallel for review
[09:46] <slangasek> (the ltsp change itself seems reasonable, as /bin/sh isn't really a sane login shell)
[09:48] <stgraber> slangasek: it's not the same issue. The ltsp change is for the live-ltsp shell for generated accounts. The edubuntu-artwork change is for our ltsp install script (launched post-install through a launcher on the desktop) where ssh isn't properly started and so the calls to ssh-keyscan made by ltsp-update-sshkeys fail (making ltsp useless after reboot).
[09:49] <stgraber> anyway, test install should be done in 30min or so, I'll have the upload done just after that if it worked
[09:53] <slangasek> stgraber: ah, ok; accepting ltsp now
[09:55] <Jeeves_> pitti: Maybe, yes.
[09:55] <Jeeves_> But now the jigdo files are unusable?
[09:55] <cjwatson> yep
[09:55] <pitti> Jeeves_: yes, that's an unfortunate consequence
[09:56] <pitti> Jeeves_: it'll be better on the final version, since those packages don't disappeare
[09:56] <cjwatson> nothing we can do about this without much tighter integration between cdimage and archive; it's been on the wishlist forever, unlikely to change any time soon
[09:56] <cjwatson> (I think some ... intellectually challenged triager may have closed the bug, but whatever)
[09:57] <Jeeves_> ok, so the conclusion is that jigdo is unusable? (Fine by me, but than I can also say that on #ubuntu-mirrors, in case people ask)
[09:57] <cjwatson> that is an overreaching conclusion
[09:57] <pitti> Jeeves_: no, jigdo itself is awesome; just the jigdo files for beta/RC are
[09:57] <cjwatson> the RC jigdo files are unusable at this point
[09:57] <cjwatson> daily-build jigdo files work fine
[09:57] <Jeeves_> okidoki.
[09:57] <Jeeves_> Thanks!
[10:00] <slangasek> "unusable" - well, I guess you could use them as a basis for rsyncing or zsyncing
[10:03] <Jeeves_> slangasek: Not if the files it mentions don't exist :)
[10:03] <slangasek> Jeeves_: it won't be able to fully piece together an image, but it will get much of the way there
[10:05] <Jeeves_> probably yes.
[10:05] <Jeeves_> i've never seen the upside of creating your own images :)
[10:05] <Jeeves_> long live .iso! :)
[10:06] <stgraber> well, it's useful when you already have a local package mirror and don't want a cdimage mirror as well (though I usually rsync/zsync the .iso instead of playing with jigdo)
[10:12] <pitti> the best part is that you can scan /var/cache/apt/archives, and other CD images for missing pieces
[10:12] <slangasek> or, as I said, you can just let it scan what it can, and then use the resulting partial image as a basis for rsync/zsync
[10:13] <slangasek> which does give improved results when you have a local mirror and a majority of packages are still available
[10:14] <Jeeves_> I guess I'm just to spoiled with gigabit links and 20mbit dsl :)
[10:15] <pitti> Jeeves_: yes; jigdo is too much hassle for bandwidth like that :)
[10:15] <Jeeves_> :)
[10:35] <stgraber> slangasek: New ETA for the Edubuntu test install, should be tested in a bit more than 30 minutes. That ssh key bug needed two files to be tweaked because for some reason /etc/init.d/ssh stop in the live environment doesn't stop ssh ... only "stop ssh" does.
[10:38] <cjwatson> yup
[10:38] <cjwatson> because /etc/init.d/ssh had to be kept around for chroots, and isn't just a link to upstart-job
[10:43] <Jeeves_> btw, a similar bug is in rsyslogd
[10:43] <Jeeves_> /etc/default/rsyslogd exists, but isn't used
[10:45] <cjwatson> that's not a similar bug, it's an entirely different bug
[10:45] <cjwatson> unless "vaguely related to init" means similar :)
[10:46] <slangasek> stgraber: ok - I've set the trigger already for the candidate builds, I believe the edubuntu packages will all be published before the edubuntu builds start :)
[10:47] <Jeeves_> cjwatson: It's similar'ish :)
[10:47] <Jeeves_> And should be easy to fix
[10:48] <cjwatson> it's not similarish
[10:48] <cjwatson> it's also at least in part by design.  upstart jobs are making reduced use of /etc/default/ since they're much easier to edit and maintain directly
[10:49] <cjwatson> anyway, let's please not have this on #-release
[10:49] <Jeeves_> cjwatson: I agree. But if you migrate to upstart (which is a good thing), it would be nice if people clean up /etc/default, which is causing confusino
[10:50] <Jeeves_> I was trying not to :)
[11:22] <ogra> hmm, was there a mass give-back for universe on the 18th ?
[11:22] <ogra> looking at the FTBFS logs they all have at least a timestamp from the 18th
[11:33] <slangasek> stgraber: how's it coming?
[11:35] <stgraber> slangasek: slowly ... grabbing some lunch now, should have the result by the time I get back. Previous test failed but I don't know if it's my change that didn't work or just because I poked at the environment before the install, so I'm doing one more, then will run the ltsp bit step by step afterwards to make sure everything works as expected. If it's the case, I'll upload, if not, I'll fix and upload :)
[11:52] <slangasek> stgraber: ok
[11:53] <ttx> slangasek: got time to review FFe/upstart script on bug 533029 ?
[11:53] <ubottu> Launchpad bug 533029 in autofs5 "[FFE] autofs5-ldap doesn't work immediately after bootup" [High,Triaged] https://launchpad.net/bugs/533029
[12:17] <slangasek> lamont: please kill any currently running livefs jobs
[12:33] <lamont> slangasek: any particular arch?
[12:34] <cjwatson> all of them, Steve said he forgot to bump CONF.sh in debian-cd
[12:34] <lamont> right
[12:37] <lamont> no more livecd rootfs builds going on.  logs may look like someone did a killall apt-get dpkg debootstrap. :-D
[12:54] <slangasek> lamont: thanks :)
[12:54] <slangasek> new run started
[13:27] <stgraber> slangasek: sorry for the delay but it seems like I can't get two installs to do the same thing ... starting yet another one now
[13:27] <slangasek> stgraber: heh, ok
[13:39] <mvo> bdmurray: hi, I tried to reproduce #569941, when you are around, could you give me some more infos on it?
=== barry` is now known as barry_
[14:52] <stgraber> slangasek: I've got to run in 10 minutes, I hope I understood what's going wrong so I'll upload a new edubuntu-artwork that should fix the issue and hope that'll do the trick.
=== barry_ is now known as barry
[15:00] <slangasek> stgraber: ok :)
[15:07] <ScottK> slangasek: I'm travelling to California today and so don't assume I'm avaialble for anything from nowish to ~14 hours from now.
[15:08] <ScottK> slangasek: I'm still expecting a seamonkey upload.  The diff will be huge, but we need to get to a version that mozilla supports.  There should be a lightning upload too, but I asked to have asac or someone appropriate sign off on that since it will make sunbird go away.
[15:09] <slangasek> ScottK: ok - have a good trip, then
[15:11] <ScottK> Thanks.
[15:15] <slangasek> cjwatson: does bug #569900 look like a dupe of 542210?
[15:15] <ubottu> Launchpad bug 569900 in mdadm "mount: mounting /dev/md0 on /root/ failed: Invalid argument" [High,New] https://launchpad.net/bugs/569900
[15:43] <cjwatson> mdadm> my instinct is not
[15:44] <cjwatson> 542210 triggers when you run any of raid/lvm/crypto configuration in partman after having set up a raid volume (or inherited one from a previous installation)
[15:46] <cjwatson> if you only do one pass through the raid configuration tool in the partitioner, and you didn't inherit anything from a previous installation, then it isn't 542210
[15:52] <slangasek> stgraber: I'm pretty concerned about this "umount in lazy mode and force a sync" change
[15:52] <slangasek> stgraber: can we talk about what problem you were seeing?
[16:00] <cjwatson> bug 569317
[16:00] <ubottu> Launchpad bug 569317 in initramfs-tools "compcache/ramzswap support in initrd broken due to typo in /usr/share/initramfs-tools/hooks/compcache:74" [Undecided,Confirmed] https://launchpad.net/bugs/569317
=== bjf is now known as bjf[afk]
[16:51] <pitti> argh oversized
[16:52] <pitti> le sigh, 6 MB growth since RC?
[17:00] <slangasek> pitti: xfsprogs, jfsutils were missing from RC, which accounts for some; langpacks may account for some more; fix is already in hand, just waiting for some other bits before respinning
[17:01] <slangasek> cf. bug #569317 in initramfs-tools
[17:01] <pitti> fix> dropping a langpack, I suppose?
[17:01] <ubottu> Launchpad bug 569317 in initramfs-tools "compcache/ramzswap support in initrd broken due to typo in /usr/share/initramfs-tools/hooks/compcache:74" [High,Fix committed] https://launchpad.net/bugs/569317
[17:01] <slangasek> pitti: yep - Hindi, Bengali
[17:01] <slangasek> (one on each arch)
[17:06] <micahg> are we too late to sync a change in universe from Debian?
[17:06] <pitti> micahg: technically not, but practically we'll only accept release critical and safe changes
[17:06] <pitti> such as a two-line change to fix FTBFS, and the like
[17:06] <slangasek> micahg: I will assume here you're talking about seamonkey, though
[17:07] <pitti> the universe cutoff point is tomorrow
[17:07] <micahg> pitti: k
[17:07] <micahg> slangasek: no
[17:07] <slangasek> oh
[17:07] <slangasek> then, meh
[17:07] <micahg> phpmyadmin had a feature turned on in Debian that should have been turned on before (logging changes made through the web)
[17:08] <micahg> slangasek: Seamonkey I think is ready and chrisccoulson is reviewing
[17:08] <slangasek> alright
[17:09]  * micahg takes it as a 'no' for phpmyadmin
[17:09] <slangasek> unless there's a reason to consider this critical... that's a no
[17:10] <micahg> slangasek: k
[17:13] <slangasek> lamont: can I get another livefs kill please?
[17:13] <lamont> sigh
[17:13] <slangasek> if you'd like to work out what we need to do to our scripts to let Ctrl-C work right... :)
[17:15] <stgraber> slangasek: turned out that moving to lazy umount didn't solve the issue, so I'm back to trying to have the same issue two times in a row so I can fix it ...
[17:15] <slangasek> stgraber: right; I'm glad that didn't fix it ;)
[17:15] <lamont> slangasek: so, um, all zero outstanding killed
[17:15] <slangasek> lamont: "zero outstanding"?
[17:15] <lamont> yeah - didn't kill anything
[17:15] <slangasek> lamont: should have been some DVD builds queued?
[17:15] <lamont> none running
[17:16] <slangasek> hmm
[17:16] <lamont> ah, why so there are
[17:16] <lamont> moment
[17:16] <slangasek> ok :)
[17:17] <bdmurray> mvo: I'm trying it again
[17:18] <stgraber> slangasek: well, when one install you get a bunch of files and the next you don't, you start to wonder if there's something wrong with that partition you were supposed to umount 10s before ;) but yeah, good that it didn't fix it :)
[17:19] <slangasek> stgraber: the other thing is, if a lazy mount had any effect at all, it's not guaranteed that the final umount would DTRT either
[17:19] <slangasek> actually... I don't think it works at all because the kernel gives you a "not mounted" whinge
[17:20] <lamont> slangasek: shiny.  kick it in the head
[17:20] <stgraber> slangasek: yeah, I forgot to drop that final umount, it shouldn't have been there.
[17:20] <slangasek> stgraber: right - and furthermore, anything that *was* holding the mount point open could still be writing...
[17:21] <slangasek> lamont: thankee :)
=== bjf[afk] is now known as bjf
[17:22] <slangasek> stgraber: so - rejected the previous upload from the queue
[17:26] <stgraber> slangasek: thanks
[17:30] <cjwatson> jarnos: https://wiki.ubuntu.com/LucidLynx/TechnicalOverview is the central page
[17:30] <slangasek> jarnos: how are you definining "release notes", then?  there are several possible definitions, I don't know which Xubuntu uses
[17:39] <jarnos> slangasek: me neither ;) But I think the information on  https://wiki.ubuntu.com/LucidLynx/TechnicalOverview is a good starting point. The challenge is to know which is common with Xubuntu.
[17:40] <charlie-tca> jarnos: this is a very good starting point - https://wiki.ubuntu.com/Xubuntu/LucidLynx/Beta2
[17:41] <cjwatson> possible definitions include: a release announcement; a summary of major changes in this release (top of TechnicalOverview); errata (bottom of TechnicalOverview)
[17:42] <jarnos> charlie-tca: But it is very limited. It does not cover e.g. the "New default open source driver for nVidia hardware" which is available at https://wiki.ubuntu.com/LucidLynx/TechnicalOverview .
[17:43] <charlie-tca> Did we not link to those notes?
[17:43] <cjwatson> the Xubuntu notes should really only cover the Xubuntu-specific elements
[17:43] <charlie-tca> Normally, as a dirivative, we link directly to the Ubuntu release notes and technical overview, so we do not have to repeat them
[17:44] <jarnos> charlie-tca: we did, but there is the challenge to know what is Ubuntu specific in Ubuntu's release notes.
[17:44] <cjwatson> "what's new" would be better as a separate entity, since it reduces confusion all round; neither Steve nor I are particularly settled either way on where the errata belong
[17:44] <charlie-tca> We allow users to read all of it anyway
[17:46] <charlie-tca> The right place to ask what's new in xubuntu might be #xubuntu-devel, though
[17:46] <jarnos> I'll have to go now; will be back probably in 2.5 hours or tomorrow.
[20:43] <jarnos> charlie-tca: Yes we allow users to read all Ubuntu's release notes, but it would be better, if Ubuntu derivatives had Ubuntu specific information separated/removed.
[20:45] <jarnos> Maybe this kind of separation could be done in Ubuntu release notes. It would be good for official Ubuntu derivatives, like Kubuntu, too.
[20:46] <jarnos> cjwatson: what do you think about the above?
[21:06] <lamont> slangasek: dunno if acorn is just really really really busy and ignoring the monitoring, or if you pushed it into a box of scissors.
[21:06] <lamont> you might want to run whatever livefs build you think you're doing on clementine
[21:52] <charlie-tca> Ubuntu and Xubuntu upgrade from 8.04, the network manager and volume control applets disappear
[21:55] <slangasek> lamont: gar, ok; will twiddle the scripts before launching builds, thanks for the heads-up
[22:23] <stgraber> slangasek: still around ?
[22:24] <stgraber> seems like I finally have an edubuntu-artwork package that does what it's supposed to :)
[22:26] <stgraber> it's uploading now, should be in the queue in a few minutes. I'm running a third test-install to make sure it always work but I'm quite confident it should :)
[22:49] <jarnos> slangasek, cjwatson : now there exist a draft for Xubuntu release notes: https://wiki.ubuntu.com/Xubuntu/LucidLynx/Final/Draft
[23:06] <stgraber> slangasek: second install confirmed that edubuntu-artwork now works, feel free to respin once it's in the archive (0.1.0-71).
[23:30] <kirkland> slangasek: around?