[03:10] <brlin> Does anyone know which package provides the `buildlivefs` command that is called in the lpbuildd/livefs.py file in launchpad-buildd?
[03:11] <brlin> The package search reveals no results :-/
[03:26] <wgrant> brlin: It's not actually its own command. See the dispatch logic in lpbuildd/target/cli.py
[03:26] <brlin> @wgrant Thanks for the pointers.
[03:40] <brlin> I wonder if anyone have tried to docker/snap Launchpad, in a microk8s fashion or something.
[03:43] <wgrant> brlin: No, since it's very rarely necessary to run it locally. What are you trying to do?
[03:45] <brlin> @wgrant Debug the builders, etc.
[03:46] <wgrant> brlin: It's approximately unheard of for a user to have to do that.
[03:50] <brlin> Also I would like to simulate most of the details of building a Live image in Ubuntu, which appears to be building on Launchpad.
[03:55] <wgrant> brlin: Most of the details of that are in livecd-rootfs
[03:55] <wgrant> launchpad-buildd is just the glue and is very rarely interesting except to Launchpad developers.
[03:56] <brlin> Helpful as always, thanks!
[04:12] <wgrant> LP's about to go down for a few minutes for the PostgreSQL 10 upgrade.
[04:26] <wgrant> Everything should be back to normal.
[04:30] <brlin> <3
[04:37] <brlin> I wonder what is the proper value for the `Source snap channels for automatic builds` field in the snap package edit page?  It seems to always stuck to `stable/launchpad-buildd`
[04:47] <wgrant> brlin: What do you mean by "proper value"?
[04:48] <brlin> @wgrant I mean "format" to be exact
[04:48] <wgrant> brlin: It's a normal snap channel name
[04:48] <wgrant> In this case, the launchpad-buildd branch of the stable risk of the latest track
[04:56] <brlin> Thanks, I file a bug then: https://bugs.launchpad.net/launchpad/+bug/1822939
[04:56] <ubot5`> Ubuntu bug 1822939 in Launchpad itself "core/snapcraft channel selection doesn't apply in snap build" [Undecided,New]
[05:03] <wgrant> brlin: How did you trigger the build?
[05:04] <brlin> Both manual and source changes.
[05:04] <wgrant> It's expected that the channel settings aren't respected for manual builds (https://bugs.launchpad.net/launchpad/+bug/1791265)
[05:04] <ubot5`> Ubuntu bug 1791265 in Launchpad itself "Manual snap builds don't allow for snapcraft/snapd channel selection" [High,Triaged]
[05:04] <wgrant> And https://bugs.launchpad.net/launchpad/+bug/1791269
[05:04] <ubot5`> Ubuntu bug 1791269 in Launchpad itself "Options for automatic builds could be defaults for all builds in a snap" [High,Triaged]
[05:05] <wgrant> Do you have an example of a build that was triggered automatically and didn't respect the channel configuration for automatic builds?
[05:07] <brlin> I've triggered it again, just for verification.
[05:08] <brlin> s/'ve/ just/
[05:26] <brlin> @wgrant Yep it's a duplicate of #1791265
[05:27] <wgrant> Great


[00:44] <guiverc> Bashing-om, suggested 'also' be removed, and adding a Xubuntu release announcement to gdoc; I've not finished readthru yet though
[00:45] <Bashing-om> guiverc: K; will edit/add later when you have completed the read.
[00:46] <guiverc> do "Release notes" qualify as release announcement?  (Ubuntu-Mate)
[00:46] <guiverc> I'll add, you can decide (looks okay to me)
[00:48] <Bashing-om> guiverc: :D
[00:49] <guiverc> ubu-budgie, I'm finding two (one for 19.10 & one for 18.04) ??
[00:50] <guiverc> :)  nope found them too
[00:50] <guiverc> !flavors
[01:13] <guiverc> Sorry Bashing-om I didn't like hub summary (sorry for not noticing earlier), I've provided an alternative but i've changed it too much.. you can decide/apply your magic..
[01:15] <Bashing-om> guiverc: I too was pretty addle brained when writting up - I was susre could do better - but gald to get done what I coule - polish is good :P
[01:39] <guiverc> wiki read thru:  should LTS updates stated instead of "End of Life: April 2025" (for 20.04), "End of Standard Support:" instead, though it'll mean more work as currently all releases are treated equally (19.10 has no esm)...  just a thought
[01:40] <Bashing-om> guiverc: "end of standard support" is a good thought :P
[01:41] <guiverc> we could just change script to say "End of Standard Support" for all; it just happens to be EOL for interim releases too as no extended
[01:45] <Bashing-om> guiverc: Oh we could just edit the issue template for the change to "End of Standard Support" will not take ne but a few minutes.
[01:45] <Bashing-om> ne/me*
[01:46] <guiverc> yep. It won't matter at all to most end-users, but it's more Canonical friendly (ESM wise)
[01:49] <Bashing-om> guiverc: Yup - agreed - shoudda thought of that one myself :P Make it so - "End of Standard Support".
[02:38] <guiverc> looks good Bashing-om
[02:39] <Bashing-om> guiverc: Outstanding on us :D Will see before the push for any additional changes .
[06:20] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Blog: WSLConf: Sessions Part 2 – DevOps on WSL and more @ https://ubuntu.com/blog/wslconf-sessions-part-2-devops
[09:15] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Blog: Work smart, not hard – fun applications to help you do less in your day @ https://ubuntu.com/blog/work-smart-not-hard-fun-applications-to-help-you-do-less-in-your-day
[12:03] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: Get-set, Go: Ubuntu 20.10 Development Officially Begins @ https://www.omgubuntu.co.uk/?p=175073 (by Joey Sneddon)
[16:33] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: Lenovo is Bringing Fedora Linux to its ThinkPad Laptops @ https://www.omgubuntu.co.uk/?p=174626 (by Joey Sneddon)
[19:41] <Bashing-om> UWN: No further edits known; pulling "WIP" - time to push 20:00 GMT.
[20:00] <Bashing-om> UWN: news@lists is away - doing the Forum post next.
[20:05] <Bashing-om> Forun post done, Fridge will have "'H' format wrapped in unpack .. line 77" to deal with. Doing the re-directs next.
[20:13] <Bashing-om> Re-directs done - pending are the social medias. Fridge will have ^ issue.
[20:52] -BottyMcBotFace:#ubuntu-news- ::Planet:: Stuart Langridge: Remote Applause @ https://www.kryogenix.org/days/2020/04/27/remote-applause/
[23:15] <guiverc> Bashing-om, okay to push 628 to fridge?
[23:25] <Bashing-om> guiverc: Yup - but got the "'H' format wrapped in unpack issue to work around.
[23:25] <guiverc> yeah I got that too, fridge output looks fine, only Lyz's big iron one didn't open; fixed manually
[23:26] <guiverc> http://fridge.ubuntu.com/2020/04/27/ubuntu-weekly-newsletter-issue-628/
[23:29] <Bashing-om> Fridge: spot check checks good.
[23:31] <guiverc> :)  & thanks, I'd been distracted elsewhere.. tweet done now
[23:32] <Bashing-om> guiverc: Clear now to wipe Gdoc ?
[23:32] <guiverc> yep.
[23:36] <guiverc> fb posted too
[23:42] <Bashing-om> guiverc: An Uh OH ! "Ubuntu Portugal Podcast: S01E87 - Festa Confinada" has the link wrong ! Gots to fix. s/b https://podcastubuntuportugal.org/e87/ :(
[23:44] <guiverc> sorry, I'm looking
[23:44] <guiverc> is that in the wiki wrong?  (don't see it on fridge)
[23:45] <guiverc> okay see it.. didn't notice that sorry
[23:48] <Bashing-om> guiverc: The wiki was wrong - fixing the WIKI amd the forum. No Idea how I could have screwed that up :(
[23:51] <guiverc> distracted by call/voice/knock-on-door|window/bird-call-out-window/.... or thousands of things.. it happens
[23:53] <Bashing-om> guiverc: Anyway - WIKI and Forum fixed :D
[23:54] <guiverc> Yep, and thanks  (I'd noticed the wiki was corrected)
[23:55] <Bashing-om> We do UWN629 :D


[00:48] <ScottK> FYI cjwatson, slangasek, etc: I've reviewed ubuntu-sugar-remix-meta and it's fine to go in.  I'm leaving it in queue in case you need a build to stimulate a publisher run.
[00:49] <ScottK> lfaraone: ^^^ - Don't panic.  We'll get it in before release.
[00:49] <lfaraone> ScottK: no worries.
[01:10] <micahg> ScottK: if there is a sync that looks like it should go in, is it still worth trying (potential data loss)
[01:10] <micahg> or better to SRU
[02:05] <ScottK> micahg: Seeded or unseeded?
[02:05] <ScottK> micahg: What package?
[02:05] <micahg> ScottK: zoneminder, unseeded, RC bug
[02:05] <micahg> actually, needs a merge
[02:06] <micahg> debian 497107
[02:06] <ubot4> Debian bug 497107 in zoneminder "uninstallation deletes MySQL database with no warning" [Serious,Fixed] http://bugs.debian.org/497107
[02:06] <ScottK> Sounds reasonable to try and fix.
[02:07] <micahg> ScottK: should I try to get a merge done then?
[02:07] <ScottK> micahg: Yes.
[02:08] <micahg> ScottK: thanks
[03:08] <wgrant> When is the release pocket expected to permafreeze?
[03:25] <ScottK> wgrant: Depends on what you mean by that.
[03:26] <ScottK> I think ~noon UTC Thursday was what we said though.
[03:26] <ScottK> barring last minute respins ...
[03:27] <wgrant> We need to do some stuff at the Soyuz end to completely rid the indices of sparc and ia64.
[03:27] <ScottK> Actually I think a day after that.
[03:27] <ScottK> We said noon UTC on 10/9 in the mail to u-d-a, but I think that was a mistake.
[03:28] <micahg> Noon UTC Sat was in the original mail
[03:28] <wgrant> Although given what happened last time, I guess we can't really make any assumptions that there won't be 11th hour respins.
[03:28] <ScottK> Yeah.  I think that's wrong though.
[03:28] <ScottK> Yep.
[03:29] <ScottK> cjwatson: The "Final Freeze timeline for unseeded packages in Universe/Multiverse" said Noon UTC on 10/9, but I think we really wanted 10/8 for hard freeze in Universe.
[03:29] <ScottK> Unfortunately I'll be away again tomorrow, so I'd appreciate it if someone else in the release team would look at that and re-announce as needed.
[03:30] <ScottK> Noon UTC would be 36 hours to the end of 10/10 and IIRC we were aiming for 36 hours to the start of 10/10.
[03:37] <slangasek> smoser: ec2 candidates posted to the tracker
[03:38] <slangasek> NCommander: Portland, or Portland, ME? :)
[03:49] <ScottK> micahg: Is it on purpose we don't ship the unversioned .so in  libfxscintilla-dev?
[03:49] <micahg> ScottK: idk, I just tried to follow what was done before in teh package, did I miss something?
[03:50] <ScottK> OK.  Let me look at the old one.
[03:50] <micahg> ScottK: you'll have to go back to karmic
[03:51] <ScottK> Nice.  That's an empty package.
[03:52] <ScottK> So this one is at worst less useless.
[03:55] <micahg> ScottK: zoneminder works locally, but fails in pbuilder, should I try pushing to PPA to see if it works?
[03:55] <ScottK> What's the error?
[03:55] <micahg> oh, right :)
[03:56] <micahg> ScottK: idk, I can't see what the error is, I get a line of undefined references
[03:56] <ScottK> What's the first one?
[03:56] <micahg> zm_comms.cpp:(.text+0x1d89): undefined reference to `std::set<CommsBase*, std::less<CommsBase*>, std::allocator<CommsBase*> >::set()'
[03:56] <ScottK> micahg: Why don't we take this to #ubuntu-motu?
[03:56] <micahg> ScottK: k
[04:34] <NCommander> slangasek: Portland, OR :-)
[04:36] <slangasek> NCommander: ah, then, welcome!
[05:11] <NCommander> slangasek: thanks :-). I don't move here full time htough until November.
[05:18] <RAOF> Hm.  I think bug #656037 should be release-critical for the netbook images.  Can I get a second opinion on that?
[05:18] <ubot4> Launchpad bug 656037 in ubiquity (Ubuntu) "Software sources not selected (affects: 2) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/656037
[05:33] <slangasek> RAOF: confirmed; that's a rather significant bug to have at install time
[05:33] <slangasek> RAOF: are you or someone else working on a fix?
[05:34] <RAOF> I am not at this point; I'm not familiar with the ubiquity code.
[05:34] <RAOF> And I've only just hit it.
[05:45] <slangasek> cjwatson, ev, skaet: ^^ installing UNE gives only security enabled in sources.list; looks critical to me, no straightforward way to fix it post-release
[06:14] <RAOF> Ah, ok.  I think I know what's wrong there.
[06:18] <skaet> slangasek, RAOF, thanks for the head's up.
[06:19] <RAOF> skaet: I've updated the bug with my findings so far; shall I leave that up to you, and go and try to break further iso images? :)
[06:20] <skaet> ROAF, :),  just read the update.   Thanks.
[06:22] <skaet> we'll discuss it here first thing this morning (when the rest wake up )... please go and try to break more iso images ;)
[06:49] <micahg> can we still get a sync in for a CVE?
[06:50] <micahg> oh, hmm..has lots of rdepends, maybe better not
[07:25] <ara> morning all!
[08:39] <didrocks> hey, FYI, this version fix an upgrade issue ^^
[09:10] <ara> skaet, are you around?
[09:14] <ara> morning ttx, robbiew
[09:15] <robbiew> ara: morning
[09:15] <ttx> ara: hey
[09:15] <ttx> ara: skaet is not here yet
[09:22] <ara> marjo, robbiew, cjwatson: the installation in English when French selected seems to be a side effect of bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/656037
[09:22] <ubot4> Launchpad bug 656037 in ubiquity (Ubuntu Maverick) (and 1 other project) "Software sources not selected (affects: 2) (heat: 14)" [High,Confirmed]
[09:22] <robbiew> ara: ack
[09:22] <robbiew> ev: ^^^
[09:23] <ev> indeed, I have a pile of these things I'm trying to sort through.  Looking at bug 655893 now.
[09:23] <ubot4> Launchpad bug 655893 in ubiquity (Ubuntu Maverick) (and 1 other project) "Free Software option still enables restricted repos (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/655893
[09:24] <robbiew> ev: ack
[09:26] <cjwatson> stgraber: your DVD builds are up (actually last night, but I couldn't get net access to post them)
[09:27] <cjwatson> ScottK: urgh, it seems late notice to potentially delete a day from developers' schedules is the thing
[09:28] <cjwatson> ara: looking at that shortly, just finishing catching up
[09:28] <ara> sure thing
[09:39] <cjwatson> doko: can you upload it so that we have flexibility to accept it if possible?
[09:43]  * ara is looking forward to the release so she can format her laptop and have a fresh installation
[09:44] <cjwatson> currently have five bugs on the respin-candidate whiteboard list here
[09:45] <cjwatson> (1) lsb-release not updated (2) grub broken on some servers (3) bug 656037 (4) bug 655893 (5) libc strstr broken on some SSE2/SSE3 machines on some inputs
[09:45] <ubot4> Launchpad bug 656037 in choose-mirror (Ubuntu Maverick) (and 1 other project) "Software sources not selected (affects: 2) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/656037
[09:45] <ubot4> Launchpad bug 655893 in ubiquity (Ubuntu Maverick) (and 1 other project) "Free Software option still enables restricted repos (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/655893
[09:46] <doko> cjwatson: uploaded
[09:46] <SpamapS> cjwatson: is one of those to fix the release tag?
[09:46] <cjwatson> SpamapS: (1)
[09:46] <SpamapS> ah ok. :)
[09:48] <cjwatson> doko: hm, robbie says it was broken on lucid too
[09:48] <doko> yes, it is
[09:48] <doko> sru is uploaded too
[09:49] <cjwatson> just trying to weigh whether we should cram into maverick release given that, or push to updates
[09:49] <cjwatson> mind you it's looking like we have to respin everything anyway
[09:50] <doko> that's why I was asking, I'm fine with either decision. it's the build time on armel which maybe is a blocker
[09:51] <doko> 5h
[09:52] <ttx> base-files fix uploaded
[09:52]  * ara is trying to find motivation to keep testing when she knows that the probability of respin tends to 100%
[09:53] <cjwatson> the more things we catch in one go, the more chance there is that we can keep it to one respin
[09:58] <cjwatson> doko: the question is fairly finely balanced, but I think the consensus here is that we should push this to -proposed
[09:58] <cjwatson> basically as risk management
[09:58] <Daviey> I just noticed that mythbuntu is oversized.
[09:58] <cjwatson> Daviey: yes, amd64 only
[09:59] <cjwatson> can you do anything aboutit?
[09:59] <cjwatson> (that's really really safe)
[09:59] <Daviey> cjwatson: happy to poke.
[09:59] <doko> cjwatson: ok, rejected
[10:01] <cjwatson> so for 656037, I think I would like to try to fix this on live filesystems rather than changing ubiquity for it
[10:01] <cjwatson> by adding the appropriate /etc/default-release file
[10:02] <cjwatson> still considering though
[10:02] <robbiew> ara: take a break ;)
[10:02] <cjwatson> basically because if I change choose-mirror then I have to rebuild d-i too
[10:03] <cjwatson> and also because mirror/suite is a force-override, and /etc/default-release is what's generally supposed to be used as I read the code history
[10:03] <cjwatson> OTOH, hmm, customisers will be caught out
[10:04] <ara> robbiew, mmm, coffee... :)
[10:04] <cjwatson> sigh, I'll change choose-mirror, it's the simplest fix
[10:04] <robbiew> cjwatson: ack
[10:06] <cjwatson> testing
[10:06] <ara> nice thing 11-11-11 is a Friday
[10:06] <cjwatson> oh don't even go there. :)
[10:13] <cjwatson> so after base-files lands we can spin arm omap and none of the pending bugs seem to affect that
[10:13] <cjwatson> well, 650703 might, not sure
[10:18] <pitti> I take it it's too late for a tzdata sync into maverick?
[10:19] <pitti> ah, nevermind; I just saw that there aren't urgent changes in 2010m
[10:19] <cjwatson> which country's sky is falling and when?
[10:19] <cjwatson> ok :)
[10:19] <pitti> Vostok Station on the South Pole
[10:20] <pitti> like anyone there would are about an hour off during a half-year night :)
[10:20] <pitti> "care"
[10:22] <pitti> urgh, quite a few packages still in the queue for maverick
[10:22] <cjwatson> universe is still ok but please don't accept stuff on CDs without coordination
[10:23] <pitti> no, I won't accept anything on my own at this point
[10:23] <pitti> just took a look at it while I'm doing SRUs
[10:24] <marjo> pitti: yes, thanks
[10:26] <pitti> didrocks: I think ubuntu-netbook-default-settings can become an SRU (which is fine for upgrading from lucid)
[10:27] <didrocks> pitti: sure, it's just it seems we will have to respin right? so, it was just in case :)
[10:27] <didrocks> but as it's just affecting upgrades, a 0-day SRU will do it
[10:27] <pitti> cjwatson: urgent SRUs can already be accepted tomorrow (or whenever we are reasonably sure that we won't respin), right?
[10:27] <pitti> didrocks: you mean "in case we have to respin netbook", or "we already need to anyway"?
[10:28] <didrocks> pitti: I was thinking looking at bug #656037 that a respin will be necessary
[10:28] <ubot4> Launchpad bug 656037 in choose-mirror (Ubuntu Maverick) (and 1 other project) "Software sources not selected (affects: 2) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/656037
[10:28] <pitti> ah, yes
[10:32] <didrocks> pitti: but your choice, if it's a 0-day SRU, I think it's fine as well
[10:33] <pitti> cjwatson: ok to accept ubuntu-netbook-default-settings, since it seems we're going to respin that anyway?
[10:33] <pitti> (trivial and obvious patch)
[10:34] <cjwatson> yes
[10:37] <didrocks> thanks cjwatson, pitti :)
[10:39] <ara> just installed xubuntu i386 and the TERM env var is not set by default, is that known?
[10:40] <ara> also, the plymouth splash shows Ubuntu 10.10
[10:41] <cjwatson> splash> known bug, wontfix for maverick I think
[10:41] <cjwatson> TERM> bug 621927?
[10:41] <ubot4> Launchpad bug 621927 in xfce4-terminal (Ubuntu) (and 8 other projects) "Embedded Terminal Emulator isn't giving a TERM variable (affects: 72) (dups: 17) (heat: 386)" [Undecided,Confirmed] https://launchpad.net/bugs/621927
[10:42] <ara> yes, it looks like it. Thanks cjwatson!
[10:43] <cjwatson> a dup of it was originally filed on man-db or something like that, so it happened to be in my browser history
[10:43] <ara> don't be so modest :)
[10:45] <cjwatson> *cough* er, yes, of course, I've memorised the Launchpad bug database
[10:45] <cjwatson> very handy during downtime
[10:46] <pitti> me too; for example, I still know exactly what #1, #10000, and #100000 are about
[10:47] <ara> cjwatson, you could go to a talent show where they'd pick a bug number and you'd tell them the description and tasks
[10:51] <cjwatson> I used to be able to tell you the maintainer for a very sizeable number of Debian packages off the top of my head, but that was when I was RM and hassling people regularly :)
[10:53] <mvo> term> I will sponsor the fix
[10:53] <cjwatson> choose-mirror uploaded for 656037, will need d-i and ubiquity uploads to incorporate it though
[10:55] <mvo> pitti: vte (bug #621927) - do you prefer maverick or maverick-proposed?
[10:55] <ubot4> Launchpad bug 621927 in xfce4-terminal (Ubuntu Maverick) (and 14 other projects) "Embedded Terminal Emulator isn't giving a TERM variable (affects: 72) (dups: 17) (heat: 386)" [Undecided,Confirmed] https://launchpad.net/bugs/621927
[10:56] <pitti> mvo: default answer is "proposed" now; please coordinate with cjwatson and skaet for maverick uploads, but just if we need to respin anyway
[10:56] <pitti> it sounds very far away from an installation breaker
[10:56] <mvo> yeah, proposed it is then
[10:56] <pitti> right
[10:57] <mvo> I guess I need to reupload some other ones to proposed as well, namely gconf and ubuntu-artwork
[10:57] <pitti> *nod*
[10:57]  * mvo will do that now
[10:57] <skaet> mvo, sounds about right.   I've flagged it to release note issue though (feel free to come up with the wording ;) )
[10:57] <pitti> mvo: gconf sounds like SRU, I'll reject the upload
[10:58] <pitti> mvo: I think I can process SRUs tomorrow, so that they are ready for testing at release time
[10:58] <mvo> skaet: heh :) you know that I'm founding member of https://edge.launchpad.net/~blatant-and-awkward
[10:58] <pitti> mvo: same for jockey, I think?
[10:58] <mvo> yeah
[10:58] <pitti> lol
[10:58] <skaet> mvo, LOL.   I maybe should join...
[11:07] <ara> pitti, I am getting this when trying to shutdown xubuntu:
[11:07] <ara> Method "Shutdown" with signature "" on interface "org.freedesktop.Hal.Device.SystemPowerManagement" doesn't exist
[11:07] <pitti> mvo: rejecting jockey as well; in the bug you also said "proposed", I think it's too late (would require respinning everything)
[11:07] <pitti> ara: right, our current XFCE still tries to talk to hal until it falls back to other shutdown methods
[11:07] <mvo> pitti: sure, that is fine
[11:07] <pitti> ara: it's just cosmetical (hal isn't supposed to be there)
[11:07] <pitti> a bit of a wart, though
[11:08] <pitti> ara: I think that's fixed in the xubuntu-dev PPA (i. e. newer upstream version); I came across it during an oem project
[11:08] <ara> pitti, but I can't shutdown, it goes back to gdm
[11:08] <pitti> oh
[11:08] <ara> it didn't happen with the first xubuntu installation I did today
[11:09] <pitti> ara: oh, hmm; I have a patch for this; is there a bug about it? we could SRU it
[11:10] <ara> pitti, google didn't come up with any result in launchpad, I'll file one, which package?
[11:10] <pitti> ara: I'm not allowed to publish the OEM bug, but I'm happy to attach the bug to a public one and nomiate for SRU
[11:10] <pitti> ara: xfce4-session
[11:10] <ara> pitti, sure thing, let me file the bug
[11:14]  * cjwatson slooowly tries to construct a reproduction case for bug 650703
[11:14] <ubot4> Launchpad bug 650703 in ubiquity (Ubuntu Maverick) (and 1 other project) "OEM config appears to work but user setup is not run after reboot (affects: 2) (heat: 10)" [High,Incomplete] https://launchpad.net/bugs/650703
[11:14] <cjwatson> can somebody review choose-mirror?
[11:15] <pitti> cjwatson: I was just about to ask whether you want me to accept
[11:15] <pitti> I just reviewed it
[11:15] <pitti> done
[11:15] <ara> pitti, there was one bug already, bug 496423
[11:15] <ubot4> Launchpad bug 496423 in xfce4-session (Ubuntu) (and 1 other project) "XFCE4-Session doesn't use the ConsoleKit interface to shutdown or reboot (affects: 3) (dups: 1) (heat: 22)" [Medium,Triaged] https://launchpad.net/bugs/496423
[11:15] <pitti> splendid
[11:16] <ara> pitti, I commented it and marked as affecting me
[11:17] <pitti> ara: responded with patch
[11:23] <pitti> uh, wow -- whatever the LP guys did with the buildd system, let's keep it that way
[11:23] <pitti> it's as responsive and snappy as it used to be a long time ago
[11:24] <wgrant> Yep.
[11:24] <wgrant> jelmer fixed everything.
[11:24] <wgrant> Did you see the blog post about it?
[11:24] <wgrant> Latency should be down from ~20 minutes to <5 seconds.
[11:25] <wgrant> http://blog.launchpad.net/cool-new-stuff/more-build-farm-improvements has a pretty graph.
[11:27] <pitti> wgrant: right; and chroot upgrading seems to be faster, too
[11:28] <wgrant> That hasn't changed. But the log updating has.
[11:28] <wgrant> It's now updated a few times a minute.
[11:28] <wgrant> So it just looks like it's going faster.
[11:51] <cjwatson> 650703 unreproducible here
[11:51] <cjwatson> will try again on real hw with amd64
[12:10] <pitti> erk, seems I misread the oversize number of xubuntu yesterday
[12:10] <pitti> seeds fixed harder now
[12:16] <hggdh> I cannot see 'reinstall grub' as an option under the Rescue on the server ISO. Is this correct or a bug?
[12:17] <cjwatson> it would be a bug, I haven't had a chance to look it up yet
[12:17] <cjwatson> (not rc though)
[12:18] <hggdh> cjwatson: I will open one then
[12:18] <cjwatson> do you have a separate /boot?
[12:18] <hggdh> not on the test machines, no
[12:19] <cjwatson> and grub is definitely installed on the partition you selected to rescue?
[12:19] <cjwatson> the test is fairly simple - [ -f /target/boot/grub/menu.lst ] || [ -f /target/boot/grub/grub.cfg ]
[12:19] <hggdh> er, actually, I found that on a KVM test, single disk, standard partitioning
[12:19] <hggdh> an yes, grub is installed
[12:20] <cjwatson> ok, I can try to reproduce that here
[12:21] <cjwatson> hggdh: lvm or not?
[12:21] <hggdh> LVM
[12:21] <cjwatson> ok
[12:22] <cjwatson> IIRC that creates a separate /boot.
[12:22] <cjwatson> I'm pretty sure that will be why.  rescue-mode doesn't currently mount any other partitions other than the one you select.
[12:23] <cjwatson> hggdh: bug 320183
[12:23] <ubot4> Launchpad bug 320183 in rescue (Ubuntu) "When using "Recover a broken system" from the Server CD boot menu, /boot is not mounted (heat: 5)" [Low,Triaged] https://launchpad.net/bugs/320183
[12:23] <hggdh> then this is a bind, is it not? All rescue asks is where is the root
[12:23] <hggdh> ah there, OK
[12:23] <cjwatson> not really, you just have to use the shell instead
[12:24] <cjwatson> it's a lack of provision of shiny neatness, rather than making it impossible to rescue
[12:24] <hggdh> indeed :-)
[12:25] <hggdh> cjwatson: thank you
[12:27] <ara> ev, one question, before the new ubiquity architecture, where it starts installing in the background while the user keeps answering questions, was the installation process cancelable (?) without losing any data once you had selected the partition schema?
[12:27] <ara> ooh
[12:27] <ara> no, ev
[12:27] <ara> OK, I'll wait :)
[12:29] <cjwatson> ara: you could cancel at any point before pressing "Install" on the summary screen
[12:30] <ara> cjwatson, thanks, then there's a problem now, as soon as you click next after partman, you cannot cancel it anymore, which is OK, but not if we don't tell the user :(
[12:30] <ara> the user does not receive any warning (when selecting full disk)
[12:30] <ara> only when resizing
[12:34] <cjwatson> you'lll need ev for that
[12:34] <cjwatson> -l
[12:35] <ara> OK, I'll tell him when he's back
[12:53]  * ara -> lunch
[13:18] <cjwatson> fader: I'm very confused about doubah.  it appears to be running Xen, which should mean that nothing should go anywhere near grub2.  are you actually doing the cert installs within Xen, or is that a red herring?
[13:18] <fader> cjwatson: No, it does shared duty as a PPA build system, so when we're not testing it it gets wiped and reinstalled
[13:19] <fader> I'm not aware of what's used after that but Xen would be a likely candidate
[13:20] <fader> cjwatson: For reference, we do a PXE boot and then a straight install off of the daily server image.  I can send you the preseed we use if that's of use as well.
[13:36] <cjwatson> fader: aha.  so can I consider the Xen installation that's currently there to be wipable?
[13:36] <cjwatson> fader: and am I likely to be able to do a USB install and achieve similar results?
[13:37] <fader> cjwatson: Absolutely... feel free to blow it away.
[13:37] <cjwatson> ok
[13:37] <fader> cjwatson: I certainly hope the USB install shows the same results, otherwise this bug is even weirder :/
[13:38] <ev> ara: that's by design
[13:38] <ev> thus why the button is labelled 'Install Now' - it will immediately write to your disk
[13:38]  * cjwatson wheels this maverick-desktop-i386.iso USB stick over there then
[13:40] <ev> And if we are forced in a later release to be more explicit, lets do it in the button label, not in a warning dialog.
[13:40] <ev> it warning you when resizing is actually a bug.  I forgot to suppress that message.
[13:42] <stgraber> cjwatson: cool, highvoltage will start testing them
[13:51] <ara> ev, OK, thanks
[13:56] <Riddell> while I support not having an extra dialogue I do wonder how many people won't read the button text and won't expect the formatting to start at that stage
[13:57] <ara> Riddell, I agree, I think the next, next, next, next, makes you think that the labeling of that one is "Next" without reading
[13:57] <cjwatson> fader: hmm.  so I did a desktop install on doubah (as that was quickest), and it booted fine
[13:58] <fader> cjwatson: I have only reproduced the issue with server installs
[13:58] <cjwatson> oh, you tried a desktop install?
[13:58] <fader> I will give a desktop install a shot on one of the other affected systems and see what's up
[13:58] <fader> cjwatson: Not yet :)
[13:58] <cjwatson> I can try a server install ... don't see why that would differ particularly though
[13:59] <fader> Sorry, ambiguous phrasing
[13:59] <fader> It's possible that it's environmental somehow, but I don't know why it would be consistently reproduceable with maverick only on these systems but never hitting others.  Curiouser and curiouser.
[14:01] <cjwatson> I'll try amd64 as well rather than i386
[14:01] <cjwatson> which arch were you using?
[14:01] <fader> I was using amd64
[14:03] <cjwatson> ok, suppose that's a possible source of trouble
[14:03] <cjwatson> usb-creatoring server-amd64 now
[14:03] <cjwatson> (usb-creating?)
[14:04] <fader> Yeah, lacks the simplicity of 'burning' :)
[14:05] <ara> cjwatson, do we have an ETA for the respin?
[14:07] <cjwatson> ara: will discuss with skaet when she gets back (should be shortly)
[14:08] <ara> OK
[14:08] <cjwatson> would like to know more about fader's grub bug though
[14:09] <fader> I've got an i386 desktop install going right now
[14:11] <cjwatson> fader: what partitioning do you use?
[14:11] <fader> cjwatson: Default full disk
[14:12] <cjwatson> LVM?
[14:12] <cjwatson> (which is default on servers)
[14:12] <fader> Yes, 90% sure, let me check the preseed though
[14:12]  * ogra_ac would appreciate an armel respin to test the omap4 changes
[14:13] <fader> cjwatson: Yep
[14:13] <cjwatson> ogra_ac: does the omap image contain ubiquity?
[14:14] <ogra_ac> cjwatson, well, as oem-config, yes
[14:14] <cjwatson> in that case I think it would be best to wait until this ubiquity lands so we don't have to respin again straight afterwards?
[14:14] <cjwatson> unless that's a serious problem
[14:14] <charlie-tca> pitti: mr_pouit said you downsized my 64bit desktop image. It still shows oversized by way too much for a cd. Is this going to be downsized and rebuilt?
[14:15] <ogra_ac> not really, all bits were tested separately already
[14:15] <cjwatson> but I'll hand back to skaet now and go back to debugging this server box
[14:15] <ogra_ac> just not in an image yet
[14:15] <fader> cjwatson: http://pastebin.ubuntu.com/507997/   -- the preseed I'm using (for reference)
[14:15] <pitti> charlie-tca: I already fixed the seeds, so the next respin (when ubiquity is finished) should be okay
[14:16] <charlie-tca> So we will need a respin for testing
[14:21] <lfaraone> There's a package in Universe that is new in Maverick, that is currently broken to an external API change. The version in Ubuntu is a git snapshot pre-release version. I've tested the new version for a few days and have found no problems with it.
[14:21] <cjwatson> fader: just to double-confirm, your preseed in fact says regular, not lvm
[14:22] <lfaraone> I'm the maintainer of it in Debian. Could it be possible to get the new version in Ubuntu, since there's zero regression potential, and it doesn't work at all at current.
[14:22] <cjwatson> fader: you have 'd-i partman-lvm/confirm boolean true' and such, but the operative bit is 'd-i partman-auto/method string regular' - is that definitely right?
[14:23] <fader> cjwatson: Hmm, sorry -- the preseed is right; I thought that the 'auto' bit implied default.  The preseed should be believed over me wherever we differ
[14:23] <fader> As that's what is actually being run
[14:24] <cjwatson> fader: hm, and you're using GRUB_TERMINAL=serial - is there definitely something listening to serial?
[14:24] <cjwatson> (that would be an obvious difference between this and a non-preseeded lucid install!)
[14:24] <fader> cjwatson: Definitely; there's a serial console connected to the system
[14:25] <cjwatson> ok - well, I can try it without that and see what happens, and then bring my laptop over and serial it up
[14:25] <fader> Though that's the case on all of the server systems, and only some of them exhibit this behavior
[14:25] <cjwatson> just seemed like an obvious source of skew
[14:28] <fader> My i386 desktop install is complete and appears to have the same symptoms as the amd64 server installs
[14:29] <cjwatson> similar preseeding?
[14:29] <cjwatson> is it possible that some of the serial consoles are set to different speeds?
[14:30] <fader> Similar preseeding, yes; I can pastebin the preseed for that if it's of use to you
[14:30] <cjwatson> sure, might be
[14:30] <fader> All the serial consoles should be set to the same speed... all the preseeds are generated from a single template and the systems are all connected to a serial console multiplexer of some description
[14:32] <cjwatson> I'm not sure what grub's defaults for serial config are
[14:33] <fader> Argh, sorry -- I goofed the desktop install and ended up with a server install after all; redoing this
[14:33] <cjwatson> doubah boots fine with grub on the console
[14:36] <cjwatson> default serial config is 9600 baud, no parity, 8 data, 1 stop
[14:36] <cjwatson> I'll check with IS
[14:38] <fader> cjwatson: Same -- 9600 8,n,1
[14:38] <fader> What we're using, I mean
[14:54] <cjwatson> fader: this is working fine over serial here
[14:54] <cjwatson> plugged my laptop in and used picocom
[14:55] <cjwatson> remind me of how I can look at another machine that's currently in the cert lab?  maybe I can compare and contrast somehow
[14:55] <cjwatson> (a failing machine)
[14:56] <ara> ttx, any reason why UEC tests are not in the tracker?
[14:57] <ttx> ara: no, they should be
[14:57] <ttx> smosrer asked for them to be added at the same time as the EC2 ones
[14:57] <ttx> smoser, even
[14:57] <ara> smoser, I can add them for you, can you tell me the build number?
[14:58] <ttx> hggdh: what version did you test with ?
[14:58] <ttx> better use that one :)
[14:59] <hggdh> ttx: I tested 20101006.1
[14:59] <ttx> ara: ^ that's the one that should be there
[14:59] <ara> on it
[15:00] <hggdh> if we are respinning, shouldn't we close the QA tracker meanwhile?
[15:00] <ara> on it
[15:00] <ara> sorry, done
[15:00] <ara> :D
[15:00] <hggdh> holy ara...
[15:01] <ara> (the UEC posting, not the closing)
[15:03] <hggdh> still :-)
[15:03] <hggdh> ttx: UEC instance tests marked executed
[15:04] <fader> cjwatson: I /msg'd you some connection info
[15:07] <ttx> hggdh: we are *not* respinning yet.
[15:12] <victorp> fader - ping
[15:14] <fader> victorp: pong
[15:14] <victorp> fader - just talking to marjo and colin about the server bug
[15:14] <victorp> fader - can I ask some questions?
[15:15] <victorp> fader - the servers that are failing , are they related? i.e. same rack, make, ... something?
[15:15]  * cjwatson is also asking fader some of these questions in /msg :-)
[15:15] <fader> :)
[15:15] <cjwatson> confirmed that a 10.04 cert-preseeded install succeeds
[15:15] <fader> victorp: They seem to be HP systems
[15:15] <fader> But not every HP system is affected
[15:16] <victorp> fader - are they passing for 10.4 on exactly the same test set-up
[15:16] <fader> victorp: Yes, they work just fine in 10.04
[15:17]  * victorp is having it in the open :)
[15:17] <victorp> fader: ok...
[15:17] <victorp> cjwatson - seems like a real issue then and not a lab issue
[15:18] <cjwatson> it does, but if only it were reproducible here ...
[15:18] <cjwatson> I realise the differentials point to a 10.10 bug
[15:19] <victorp> cjwatson - we will need to send you there then :)
[15:19] <cjwatson> not necessarily ... let's see
[15:19] <victorp> fader - is there another way to try to install 10.10 on the failing servers on the lab that is more manual
[15:19] <cjwatson> yes, fader and I are working on that
[15:20] <victorp> ok - let me know how it goes
[15:24] <cjwatson> (I'm sshed into the serial multiplexor)
[15:26] <cjwatson> smoser: do you have any examples of this grub problem affecting UEC?
[15:27] <cjwatson> smoser: if not, then currently, I don't think you should wait for it
[15:27] <smoser> i've never seen it affect uec. and hggdh has run probably on the order of thousands of instances.  as far as I know, we've never seen a grub related failure.
[15:28] <smoser> (and ec2 doesn't load with grub-pc, it loads with pv-grub provided by amazon)
[15:28] <smoser> so, i'll start the build
[15:28] <skaet> smoser,  you'll need to rebuild though it appears to pick up the lsb-release change, we think?
[15:28] <smoser> yes. i definitely do not have the lsb-release change.
[15:29] <hggdh> difficult to say -- if we have a grub failure in the tests, I can only find it if something is written to the console (we dump the console log on failed tests)
[15:29] <skaet> heh.   I type too slow. ;)
[15:29] <ttx> I'd respin the cloud images only if we respin the server ISOs, for consistency
[15:29] <hggdh> I never saw any grub failures there, though
[15:29] <marjo> hggdh: good to know
[15:29] <ttx> skaet: how sure are we that we'll respin the server ISOs ?
[15:29] <skaet> we're respinning the server ISOs as soon as ubiquity drops.
[15:29] <ttx> smoser: ok, then you can
[15:30] <skaet> or at least that's the belief.
[15:31] <Riddell> what does ubiquity have to do with the server CDs?
[15:31] <marjo> victorp, fader, cjwatson: different vendors, different racks and different serial console servers
[15:31] <marjo> skaet: ^^^ re: failing servers
[15:32] <skaet> Riddell, cjwatson's double checking, but the working hypothesis right now is we need it.
[15:32] <smoser> alright . maverick server build started. it will appear as http://uec-images.ubuntu.com/server/maverick/20101007.1 probably about 18:30 UTC
[15:33] <smoser> If we need to get hggdh or someone early access to that, the .tar.gz files are available probably inside a half hour.
[15:33] <skaet> Riddell,  we need to get the servers rebuilt to pick up some other changes at this point.   (lsb_release)
[15:34] <cjwatson> Riddell: oem-config
[15:35] <cjwatson> it has a debconf frontend
[15:40] <cjwatson> fader: I'm not sure I'm getting the mirror config right here - getting the same "failed to download a file from the mirror" message.  how did you do this by hand?
[15:42] <fader> cjwatson: Should be the mirror and path info that you have.  <IP_ADDRESS> and the path /enablement/cdimage.ubuntu.com/ubuntu-server/daily/current/maverick-server-amd64
[15:42] <JamesPage> skaet: I picked up bug 656173 this morning; its a change in functionality between lucid->maverick (by design) but may catch some libvirt users out; does it need to be added to release notes for maverick?
[15:42] <ubot4> Launchpad bug 656173 in libvirt (Ubuntu) "virt-aa-helper generates incomplete apparmor profiles with chained backing files (affects: 1) (heat: 8)" [Undecided,Won't fix] https://launchpad.net/bugs/656173
[15:43] <fader> cjwatson: Let me walk through it on another machine
[15:45] <skaet> JamesPage, go ahead and add a note please.   I'd rather make sure its clear, than deal with alot of bugs that will get answered "working as designed"... :(
[15:45] <jdstrand> skaet: it is an uncommon configuration I think
[15:45] <fader> cjwatson: Wait, I see the issue... can I reboot that system on you?
[15:45] <jdstrand> skaet: chained backing stores are not by any means the default
[15:46] <skaet> jdstrand,  JamesPage,  will go discuss with robbiew, and get his experience on this then.  ;)
[15:47] <cjwatson> fader: sure, what was the problem?
[15:47] <cjwatson> I had resorted to set -x'ing my way through net-retriever ...
[15:47] <jdstrand> skaet: fyi-- soon there will be a USN to discuss all of it as well, for a lucid security update
[15:47] <fader> cjwatson: I munged the TFTP setup when manually editing it to remove the preseed, so you were in a weird inconsistent state -- booting from the 10.04 image and then trying to install 10.10 :[
[15:47] <cjwatson> aha!
[15:48] <cjwatson> that would have done it
[15:48] <robbiew> jdstrand: skaet: documenting is fine...it's not much of an added effort ;)
[15:49] <jdstrand> no it isn't, and I'm not opposed to it. I just wanted to put it in perspective
[15:49] <ttx> robbiew: cheap way to show that we care about a consistent user experience
[15:50] <jdstrand> euca uses raw (and no backing stores), virtinst/virt-manager use storage pools, and you should specify the disk format appropriately
[15:50] <jdstrand> s/and you/and they/
[15:50] <cjwatson> fader: so assuming that I can reproduce it, will I be able to do things like install a parallel 10.04 install, chroot into 10.10, fiddle with its grub, experimentally reboot to that, then switch back to 10.04 if it fails, rinse and repeat?
[15:51] <fader> cjwatson: Yes, you should be able to.  I can set up the install for 10.04 if/when you need it
[15:51] <cjwatson> if I can do that, I may have some hope
[15:51] <cjwatson> ok
[15:55] <cjwatson> fader: does it matter which disk I use?  is sda OK?
[15:56] <fader> cjwatson: sda is what I've been using
[15:56] <fader> I did try sdb on another system with multiple disks but it didn't have any noticeable effect
[15:56] <cjwatson> "Logical volume(s) to be removed: thorium-disk, thorium-diskcow, thorium-swap, thorium-swapcow"; "Volume group(s) to be removed: PPA"; "Physical volume(s) to be removed: /dev/sda6"
[15:57] <cjwatson> is that ok?
[15:57] <fader> Makes sense as it had been doing PPA duty
[15:57] <fader> Yes, our SOP is to blow everything away
[15:57] <fader> They are totally wiped when set up for testing and then again when put into the PPA pool
[15:57] <cjwatson> right
[16:19] <cjwatson> fader: ok, can I have a reboot to the 10.04 install?
[16:19] <cjwatson> (manual for preference?
[16:22] <fader> cjwatson: Sure, one moment
[16:24] <fader> cjwatson: mirror is /enablement/releases.ubuntu.com/lucid/ubuntu-10.04-server-amd64
[16:25] <fader> You should be rebooting
[16:25] <cjwatson> yep
[16:25] <cjwatson> how can I deal with the reboots back and forward after this is done?  it would be ideal not to have to bother you every time
[16:26] <cjwatson> presumably I'd need to use some kind of rescue system to reinstall the 10.04 grub
[16:27] <fader> cjwatson: I will whip up a quick script for you if you can give me ~10m (I'm in a meeting atm)
[16:27] <cjwatson> it'll take that long to do the 10.04 install
[16:27] <fader> Yep :)
[16:31] <slangasek> skaet: so bug #649917 would be easy enough to address in SRU to make the warning message go away, but this wouldn't actually make the system behave any more smoothly; anyone seeing the message is experiencing some other bug with plymouth, because if plymouth is working right you're never supposed to be in text mode to /see/ this message
[16:31] <ubot4> Launchpad bug 649917 in plymouth (Ubuntu Maverick) (and 2 other projects) "GLIb-WARNING **: getpwid_r(): failed due to unknown user id (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/649917
[16:33] <slangasek> skaet: it may be worth fixing the bug about the spurious warning message just to eliminate the bug report noise about it, but I'm not sure it actually gets us closer to how we want plymouth to work - what do you think?
[16:34] <cjwatson> fader: so where does pxelinux come from in this setup?
[16:35] <cjwatson> for example how is the version determined?
[16:35]  * ara needs to step out for some errands. She will be back in about 1 hour
[16:35] <fader> cjwatson: It's generated by a set of scripts that cr3 wrote, based on a templating system... he has templates for e.g. "maverick server" or "lucid alternate desktop" and drops in the necessary bits like IP addresses
[16:36] <cjwatson> fader: I guess what I mean is, under what circumstances will we use lucid's pxelinux vs. maverick's pxelinux?
[16:38] <fader> cjwatson: Under normal conditions it's based on which image was updated... if a new maverick ISO shows up on cdimage, it sets up and uses the maverick pxelinux.  In this case, I'm invoking that by hand, so it's using lucid's pxelinux when doing a lucid install and maverick for a maverick install
[16:39] <cjwatson> so after you did the side-by-side install of lucid, it would have switched to using a lucid pxelinux?
[16:39] <fader> Yes, definitely
[16:39] <fader> For the install -- it boots from the local disk after install and does not PXE
[16:39] <fader> s/does/should/
[16:40] <robbiew> slangasek: fyi - skaet is in "HR training"
[16:40] <slangasek> I wonder what that's a euphemism for
[16:41] <slangasek> :)
[16:41] <robbiew> well...you know how in-depth our HR training is :P
[16:42]  * cjwatson starts off (Ubuntu netbook omap) and (Ubuntu alternate; Ubuntu desktop) in parallel
[16:42] <cjwatson> since ubiquity's in place
[16:42] <robbiew> \o/
[16:43] <cjwatson> fader: observationally, it goes through pxelinux before booting from the local disk
[16:43] <cjwatson> according to the messages on the serial console
[16:43] <fader> cjwatson: Hmm, it should attempt to PXE but fail and boot from the disk, if that's what you mean
[16:44] <cjwatson> in my book that's going through pxelinux :-)
[16:44] <cjwatson> pxelinux has an opportunity to change state ...
[16:44] <cjwatson> it definitely hits pxelinux, not just the pxe bios
[16:44] <fader> I had thought that was in firmware on the system though rather than being affected by whatever was installed on the disk
[16:44] <fader> Ah
[16:44] <cjwatson> at least I think that's what it said, I no longer have the scrollback
[16:45] <fader> Ah, I see what you mean
[16:46] <fader> So we can remove the PXE path from the dhcpd conf if that is worth trying
[16:47] <cjwatson> later yes, though let's pursue the current path first
[16:47] <fader> Roger
[16:48] <cjwatson> if that gets us a way to complete certification, it may well be a win
[16:52] <cjwatson> fader: http://syslinux.zytor.com/archives/2010-August/015076.html and thread is also suggestive, and I wonder if 'chain.c32 hd0' would help
[16:52] <cjwatson> might well be better than trusting the PXE stack to do it
[16:53] <cjwatson> (prefixed with COM32, I think)
[16:56] <fader> cjwatson: Indeed, reading that thread now
[16:56] <fader> cjwatson: And I'll take your word for that, as I'm over my head at this point :)
[16:58] <highvoltage> images being rebuilt?
[16:58] <highvoltage> I get "You can't post or edit your result on an archived build or a build being currently rebuilt." on the iso tracker
[16:58] <cjwatson> yes
[16:59] <highvoltage> ok
[16:59] <highvoltage> I guess this means I can go out and get lunch at least :)
[17:00] <cjwatson> Ubuntu alternate reposted
[17:18]  * skaet started off ubuntu-server now
[17:21] <ttx> skaet: yay !
[17:24] <skaet> slangasek,  good points.  fixing the spurious warnings seems like the right thing.  Do you think it will improve the signal to noise ratio on the bugs being reported against plymouth (ie seeing out what the real problems are)?
[17:26] <slangasek> skaet: well, some users for whom plymouth is not currently working as intended will no longer see it so because they won't care about a black screen between the splash and gdm but they do care about an error message; but we don't currently have anyone working on these issues anyway
[17:30] <ogasawara> skaet, cjwatson, robbiew: for the day 0 kernel upload, would you prefer I upload it ahead of time (ie tomorrow or sat) so that it's ready and in the queue?
[17:32] <cjwatson> I think so, yes
[17:33] <cjwatson> ubuntu-netbook omap build failed
[17:36]  * skaet published ubuntu-server;  kubuntu started...
[17:38] <ScottK> cjwatson: Re the unseeded final freeze deadline, I'm OK with not moving it as long as everyone is aware on this end that we've accepted a narrower margin than we'd originally intended.
[17:38] <cjwatson> skaet: arm omap4 failed because ubiquity was out of date - should have known
[17:42] <GrueMaster> skaet: Ping me when you get omap* built.  I am onsite at TI, and we are waiting with bated breath.  :P
[17:42] <GrueMaster> The ubuntu-preinstalled-netbook images.
[17:43] <cjwatson> have to wait for ubiquity_2.4.8_armel.deb to show up on http://ports.ubuntu.com/ubuntu-ports/pool/main/u/ubiquity/
[17:43] <cjwatson> it hopefully shouldn't be *too* much longer since it's on cocoplum
[18:08] <ara> my alternate installation failed, due to some uninstallable packages
[18:13] <ara> no panic, wrong image
[18:33] <hggdh> fader: interesting. One of the machines did not boot. Grub issues?
[18:33] <fader> hggdh: One of the machines you are testing?
[18:34] <hggdh> fader: yes, (the UEC test rig)
[18:34] <fader> hggdh: The bug I was seeing turned out to be a bug in pxelinux rather than grub... how are you booting that system?
[18:35] <hggdh> fader: install is via PXE
[18:35] <hggdh> then then it boots from local drive
[18:35] <fader> hggdh: Where is it failing?  And does it load pxelinux before booting from the local drive?
[18:36] <fader> (Which is where cjwatson determined my bug was coming in)
[18:36] <hggdh> fader: this one failed when it was set to boot from the local drive (PXE boot returned "no action")
[18:37] <hggdh> ok, disregard -- I power-cycled it, and it booted normally
[18:37] <fader> Hmm, gremlins
[18:40] <hggdh> aye
[18:41] <ttx> ara: could you make the 20101007.1 uec-images the candidates for cloud images ?
[18:41] <skaet> GrueMaster, ack.  just reshuffled the builds around a bit.  omap building now.
[18:41] <ara> ttx, sure, on it
[18:41] <ttx> "Ubuntu Server UEC {i386,amd64}"
[18:42] <ara> ttx, done
[18:42] <ttx> thx
[18:44] <cjwatson> hggdh: for the record, the workaround was to use 'com32 chain.c32 hd0' rather than 'localboot 0' (with chain.c32 copied from /usr/lib/syslinux/chain.c32 in maverick's syslinux-common, into the tftp directory
[18:45] <hggdh> cjwatson: thank you
[19:00] <GrueMaster> skaet: thanks.
[20:48] <smoser> cjwatson, slangasek, or anyone else with ability, could you please populate tracker with 20101007.1 for uec images and ec2 . http://uec-images.ubuntu.com/server/maverick/20101007.1/published-ec2-daily.txt
[20:48] <slangasek> grabbing
[20:48] <slangasek> smoser: posted
[20:49] <smoser> gracias
[20:51] <GrueMaster> is omap4 image still generating?
[20:52] <GrueMaster> skaet: ^^^
[20:54] <slangasek> GrueMaster: yes
[20:54] <slangasek> looks like it's in the last stage, actually
[20:54] <GrueMaster> Ok.
[20:57] <skaet> GrueMaster, as soon as its finished,  will post a note here  ;)
[20:57] <GrueMaster> Thanks much.
[20:58] <GrueMaster> Although we *may* have to respin omap4.  (note - I am not the athorative figure in this decision).
[20:58] <slangasek> GrueMaster: what are the variables underlying that "may"?
[20:59] <GrueMaster> We're onsite at TI.  Possible graphics issue *may* be xloader related, and also an issue in jasper on blaze.
[21:00] <ara> bug 656165 is still happening to me in the latest builds
[21:00] <GrueMaster> Jasp[er is an easy fix.
[21:00] <ubot4> Launchpad bug 656165 in ubiquity (Ubuntu) "Language support incomplete after installation (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/656165
[21:07] <skaet> GrueMaster, ack.    Let us know what you find out,  be good to have the images tested out though, as much as possible in case other bugs lurking....
[21:08] <GrueMaster> For the most part, it already has been.  I have been testing the images with updates every day.
[21:08] <GrueMaster> This should just incorporate all the latest updates i have been testing.
[21:09] <skaet> ara, if cjwatson gets back on line tonight,  please let him know.
[21:09] <GrueMaster> Problem has been hardware accessability.  We just got our blaze working today.
[21:09]  * GrueMaster head hurts
[21:10] <skaet> GrueMaster, Glad you've got your board now.   Only able to use it onsite at TI?
[21:10] <GrueMaster> Yes.  Hotel doesn't have HDMI monitor.
[21:12] <slangasek> GrueMaster, skaet: omap is built
[21:13] <GrueMaster> Thanks.  Pulling now.
[21:45] <skaet> slangasek,  still in the build queue is mythbuntu, edubuntu, ubuntu-dvd, kubuntu-dvd, ubuntu-server-ports, ubuntu(powerpc), kubuntu(powerpc), kubuntu(armel+omap), kubuntu-mobile(armel+omap); xubuntu(powerpc)
[21:46] <skaet> can you please upload them to the tracker, etc. as they emerge?
[21:53] <GrueMaster> Also, need to add testcases on iso.qa for ubuntu-preinstalled-netbook images.  The tasks are there, just no testcases.
[22:12]  * skaet leaving the building now...  heading back to hotel... and zzzz.
[22:17] <slangasek> skaet: yep, will do
[22:18] <GrueMaster> slangasek: Can you update iso.qa with the omap testcases please?
[22:21] <slangasek> GrueMaster: erm - why are these test cases not already there?  Do you mean to tell me that there are new test requirements showing up post-RC?
[22:22] <slangasek> or do you mean that the builds haven't been posted?
[22:23] <GrueMaster> Please look at http://iso.qa.ubuntu.com.  They just haven't been added properly for this release.
[22:26] <marjo> GrueMaster, slangasek: Is it really critical to add these to iso.qa.ubuntu.com so close to release day?
[22:27] <slangasek> how does this question only arise *now*?  How did these images pass RC validation without test cases?
[22:29] <GrueMaster> We had testcases for RC.
[22:30] <slangasek> found the problem
[22:30] <slangasek> Ubuntu ARM preinstalled, not Ubuntu Netbook
[22:30] <slangasek> GrueMaster: there, fixed
[22:31] <GrueMaster> Thanks
[22:31] <ScottK> slangasek (since you appear to have the baton for the release team at the moment), I have a couple of packages I'm accepting now, but I'm leaving you ubuntu-sugar-remix-meta in case you need to stimulate a publisher run later tonight.  I've reviewed it and it's fine.
[22:31] <slangasek> ScottK: ack, thanks
[22:51] <jcastro> is there a guideline to determine if a bug is release note worthy or do we just use best judgement, assign it as affecting the team and hope for the best?
[22:52] <jcastro> I'm looking at bug #636311
[22:52] <ubot4> Launchpad bug 636311 in xserver-xorg-input-evdev (Ubuntu) "Keyboard special keys interfere with mouse (affects: 11) (dups: 1) (heat: 64)" [Undecided,Confirmed] https://launchpad.net/bugs/636311
[22:53] <highvoltage> jcastro: I updated the theme on http://www.youtube.com/user/ubuntudevelopers , let me know if it's ok or if there's something you'd like changed
[22:54] <highvoltage> (oops, I thought I was on another channel)
[22:55] <slangasek> jcastro: best judgement, open a task on the ubuntu-release-notes project
[22:57] <jcastro> ugh, launchpad, it just opened another task on -evdev
[22:58] <micahg> slangasek: is it worth finding merges/syncs/one-off unseeded RC bug fixes tonight still?
[23:00] <slangasek> micahg: up to the deadline, sure
[23:00] <micahg> slangasek: cool, thanks
[23:52] <slangasek> edubuntu, mythbuntu posted


[10:51] <bluesabre> micahg, Unit193: reviewed the greeter packaging again, fixed some paths.  Will follow debian and install the base template in /usr, will migrate existing config to /etc
[10:51] <ochosi> hi bluesabre
[10:51] <bluesabre> debian to ubuntu: http://paste.ubuntu.com/11718760/
[10:51] <bluesabre> ubuntu to ubuntu: http://paste.ubuntu.com/11718764/
[10:51] <bluesabre> this should be good to roll tonight
[10:52] <bluesabre> hey ochosi
[10:53] <ochosi> any plans for when to schedule the next meeting?
[10:55] <bluesabre> I'll schedule it tonight for what looks to be the weekend
[10:56] <ochosi> mhm, ok
[10:59] <bluesabre> http://doodle.com/vmzrybyw9r9929wt#table
[10:59] <bluesabre> there's a few common times that work for a several people
[11:02] <ochosi> right
[11:03] <ochosi> btw, you didn't distinguish sat/sun
[11:03] <ochosi> might make a diff, but anyway, we'll have to see
[11:05] <bluesabre> knome did it
[11:05] <bluesabre> :D
[11:05] <bluesabre> probably because we didn't want 168 options
[11:06] <ochosi> yeah, the times are fairly granular
[11:28] <knome> ochosi, didn't the poll description say you can write further comments/exceptions to comments :P
[11:34] <bluesabre> "read poll description?! pah!"
[11:34] <knome> yeah, why cares about instructions
[11:34] <knome> before it's too late anyway :)
[11:35] <knome> think: you buy a new gaming console, do you read the manual or boot it and start playing?
[11:35] <bluesabre> when I was a kid...
[11:36] <bluesabre> the manual for games or consoles was the best part about the drive home
[11:36] <knome> haha
[11:36] <knome> yeah...
[11:36] <bluesabre> "32-bit graphics, O.M.G."
[11:36] <knome> back when they had manuals that actually included something else than the safety precautions and a note to go online for support
[11:37] <knome> i remember reading the transport tycoon manual so much it started wearing - before i could even get to play it
[11:37] <bluesabre> :D
[11:37] <bluesabre> the golden year
[11:37] <bluesabre> s
[11:37] <knome> yep...
[12:48] <ochosi> just installed LO 5.0
[12:48] <ochosi> meh icon changes :/
[12:50] <knome> heh
[12:52] <ochosi> well it's still b3, i hope not much else changes
[12:52] <ochosi> but new items in the toolbars
[12:53] <ochosi> geez, "insert footnote" and "insert endnote"
[12:53] <knome> :)
[12:53] <ochosi> how in the world can someone do a meaningful distinction on 24x24
[12:53]  * knome shrugs
[12:54] <knome> maybe one can't, but who cares?
[12:54] <ochosi> if we could modify the items shown by default in those toolbars, that one would go
[12:55] <knome> i likely would vote against that
[12:55] <knome> because really, people are clingy
[12:56] <knome> especially non-high-tech-level ones
[12:56] <knome> you simply don't touch their defaults :)
[12:56] <ochosi> i don't think we can influence those defaults
[12:56] <knome> no, but even if we could, i wouldn't want to do it
[12:56] <ochosi> unless there's an rc file or something we can ship which defines a default there
[12:56] <ochosi> but i don't suppose so
[12:56] <knome> but anyway, i'm off
[12:57] <ochosi> hf then
[12:57] <knome> will be back late in the evening
[12:57] <knome> i'll try to :P
[12:57] <knome> ttyl
[18:07] <drc> clear
[19:31] <Unit193> https://packages.qa.debian.org/f/file-roller/news/20150615T132305Z.html ;D
[19:32] <ochosi> lol, nice one
[19:32] <ochosi> gotta love that changelog
[21:37] <bluesabre> :D
[21:37] <bluesabre> ochosi: well... we can probably modify defaults in LO, but probably should not
[21:38] <bluesabre> at the same time, really both footnote and endnote in the toolbar? D: