[00:00] <Keybuk> svu: the general idea is that you give *us* the log - and we look for things ;)
[00:00] <svu> Keybuk, :) ok. I provided pastbin url :)
[00:00] <Keybuk> oh, missed that
[00:03] <Keybuk> slangasek: you know what I *don't* spy in that boot.log ?
[00:03] <slangasek> Keybuk: udev?
[00:03] <Keybuk> udev
[00:04] <svu> I would be surprised if you find something there. it looks so empty
[00:04] <slangasek> so udev is *running*, but not under control of upstart
[00:04] <W3ird_N3rd> cjwatson,  kernel [nnnn.nnnnnn] eth2: interrupt(s) dropped! < bloody hell
[00:04] <Keybuk> slangasek: but why isn't upstart even trying to start it?
[00:04] <Keybuk> you should see, at least, an attempt to start udev
[00:04] <cjwatson> W3ird_N3rd: sorry, I don't know anything about that, I doubt it's installer-specific
[00:04] <slangasek> svu: can you pastebin /etc/init/udev.conf, please?
[00:05] <svu> sure
[00:05] <svu> http://pastebin.com/9m2GArqB
[00:06] <slangasek> interesting
[00:06] <W3ird_N3rd> I'll just wait for mini.iso rebuilding 14 april and try again. I'm going to sleep now
[00:06] <slangasek> Keybuk: I got nothin'
[00:06] <W3ird_N3rd> had enough :P
[00:06] <Keybuk> upstart must think it's already running
[00:06] <Keybuk> *but that makes no sense*
[00:06] <Keybuk> svu: what does "status udev" say?
[00:07] <svu> udev start/running, process 393
[00:07] <Keybuk> err
[00:07] <kirkland> lool: no problem ... let me know how it goes.  it's extremely timely for me to reproduce it as i don't have a ports mirror, etc.
[00:07] <svu> Keybuk, or should I do "status udev" when in manual recovery mode?
[00:07] <lool> I don't have enough space to try to reproduce myself either
[00:08] <Keybuk> please
[00:09] <svu> Keybuk, ok, 2 mins, another reboot
[00:10] <Sarvatt> hmm so the -dbgsym packages are correct but -dbg has the wrong CRC
[00:15] <kees> Sarvatt: I'd noticed that too, but never investigated since -dbgsym works so well
[00:15] <svu> Keybuk, udev start/running, process 401
[00:15] <kees> Sarvatt: they also crash libbfd sometimes :)
[00:16] <kees> Sarvatt: if you could open a bug report, I can confirm it.  I'd never gotten the time to really dig into that.
[00:17] <Keybuk> svu: can you pastebin a ps at this point
[00:17] <Sarvatt> kees: will do, I was just insure where to file it. pkg-create-dbgsym?
[00:18] <svu> Keybuk, arrgh. I wish you had asked a bit earlier :) ok
[00:18] <slangasek> Keybuk: btw, thinking about it some more I know my fix for the deadlock is still racy, because "process incoming events until the queue is empty; write our request" is not atomic
[00:18] <slangasek> but I don't think I'll have time to fully fix this
[00:19] <Keybuk> right, I was thinking we should just call poll() in the loop
[00:21] <slangasek> Keybuk: in which loop?  to fully fix it, ply_write() has to be interruptable, neh?
[00:22] <IntuitiveNipple> Is there a way to force update-manager to offer a restart?
[00:22] <lifeless> persia: wow, quite eloquent
[00:22] <Keybuk> in the loop in that function
[00:22] <slangasek> kirkland: are you still seeing bug #540091?  Because bug #559582 claims to still have the problem, and that was filed after 540091 was fixed
[00:22] <kees> Sarvatt: no, dbgsym is fine.  it's the -dgb infrastructure from debian that is broken
[00:22] <slangasek> Keybuk: ah
[00:22] <Keybuk> that'll mean it'll call read when it can, call write when it can
[00:22] <Keybuk> etc.
[00:22] <slangasek> right
[00:24] <persia> lifeless: thanks :)
[00:24] <lifeless> persia: I don't think I achieved your eloquence, but I think you're rather better known than I:P
[00:25] <bryceh> persia, btw I got X up on your little displaylink device
[00:25] <persia> lifeless: I think the key bit for any nomination of me is probably "he seems to be around a lot".  No eloquence required :)
[00:25] <persia> bryceh: With the xsfbs build?
[00:26] <svu> Keybuk, http://pastebin.com/k2yHLzsA
[00:26] <bryceh> persia, well it also needed another library libdlo
[00:26] <bryceh> which I just installed manually, it'll still have to be packaged I guess
[00:26] <bryceh> persia, good news is I now understand what it'd take to make this thing work
[00:26] <persia> bryceh: What did you do that needed that?  I had it working in February without it.
[00:27] <persia> bryceh: By "work" do you mean "autodetect and have GUI config interface"?
[00:27] <bryceh> persia, but bad news is it looks like it'll only work with Xinerama
[00:27] <bryceh> no I mean be able to get X running on it with an xterm
[00:28] <persia> bryceh: Did you try the xorg.conf in the README?  That mostly just worked for me with no extra libraires.
[00:28] <bryceh> persia, yep, after installing the lib and verifying that worked I put the xorg.conf changes in and verified that worked.  again though, it requires Xinerama if you want to fire up both the display and your regular monitor
[00:28] <persia> bryceh: So, what does the xinerama limitation mean?  What needs to happen to make it work the desired way?
[00:28] <bryceh> so that's only feasible with -nvidia for now
[00:29] <slangasek> Keybuk: triaged bug #559761 for the "mountall needs to flush" issue; I think we should fix this for final, is this something you'll be able to get to?
[00:29] <persia> I really had it working with -intel without the library :)  I'll fiddle with it more after UDS, when I have hardware again.
[00:29] <Keybuk> slangasek: it's just adding that same flush function call into emit_event right?
[00:29] <slangasek> Keybuk: I dunno, haven't looked at the code :)
[00:29] <Keybuk> svu: at this maintenance shell, do you have lvm working?
[00:29] <Keybuk> slangasek: can't see any reason why it would be harder than that
[00:30] <Keybuk> though it'd be a good idea to fix flush first ;)
[00:30] <persia> bryceh: So, on a more general note: what does the xsdfbs bit bring to the package?
[00:30] <svu> Keybuk, at that shell I can do "vgchange -a y" - and continue booting. otherwise I cannot boot
[00:30] <Keybuk> svu: that's not what I asked
[00:30] <persia> bryceh: I noticed the extra Provides and dependency on the right base X lib, but that seemed to be two lines from the bundle of stuff.
[00:30] <svu> Keybuk, well, perhaps I did not understand your question.
[00:31] <svu> how do you mean "lvm working" - do you mean lvm binary?
[00:31] <bryceh> persia, it means the driver needs to support xrandr (and will require upstream to support multiple video devices (bug #316514))
[00:31] <Keybuk> svu: can you reboot
[00:31] <Keybuk> get back to that maintenance shell
[00:31] <Keybuk> and then gather some information for me
[00:31] <bryceh> persia, that's the packaging system debian uses, so if we want them to eventually adopt the package it has to have that packaging system
[00:31] <Keybuk> (without running vgchange or anything yourself)
[00:32] <svu> ok
[00:32] <svu> what commands should I run, what info to collect?
[00:32] <Keybuk> do you not have a second machine to IRC from?
[00:32] <persia> bryceh: Did you plan to bring it to XSF for adoption?  I had thought I'd just toss it in as an arbitrary optional extra package post-squeeze, but I'm happy if someone else wants to maintain (or team maintain) it.
[00:32] <bryceh> persia, I have no such plans
[00:33] <svu> Keybuk, ghm. I will check if my 2nd mac has any irc client...
[00:33] <Keybuk> svu: I guess a useful answer would be whether you have a /dev/.udev.log file at that maintenance shell
[00:33] <bryceh> persia, in fact I think it looks like the work to get this supported is well beyond my scope and time availability
[00:33] <Keybuk> if you do, what is the output of "lvm vgs" and "lvm pvs"
[00:33] <Keybuk> are there device nodes in /dev/mapper?
[00:33] <Keybuk> ls -l /dev/mapper
[00:33] <Keybuk> include owner/group stuff
[00:33] <Keybuk> (even just of control)
[00:33] <snow_ru> hi
[00:34] <persia> bryceh: Fair enough.  If you have time, I'd appreciate a write-up of what you think needs doing, and I'll recollect the device and fiddle with it some more myself.
[00:34] <bryceh> persia, anyway, I'll return the device to you at UDS
[00:34] <svu> Keybuk, I know for sure I have /dev/.udev.log !
[00:34] <Keybuk> svu: at that maintenance shell?
[00:34] <svu> yes
[00:34] <Keybuk> and it has contents?
[00:34] <snow_ru> is there any project that needs a volunteer ?
[00:34] <persia> bryceh: Sounds good.  Thanks for confirming it still worked after the changes to the package.
[00:34] <bryceh> persia, when you got it working before, did you get the full desktop session up and everything?
[00:35] <svu> Keybuk, yes. IIRC I copied it yesterday here (pastebin)
[00:35] <Keybuk> ok
[00:35] <Keybuk> the answers to the other questions would be nice to have
[00:35] <bryceh> persia, and was that with only the usb monitor enabled or did you have two monitors going?
[00:35] <Keybuk> oh
[00:35] <Keybuk> output of "cat /proc/self/mountinfo" there too
[00:35] <persia> bryceh: I didn't try that far, as I only had about three days with the device, and was otherwise occupied at the time.  I got X running in it with metacity and terminator though.
[00:36]  * persia mostly found it happened to still be in the laptop bag when the SiS USB devices were being bandied about.
[00:37] <bryceh> well I didn't get to those either
[00:38] <svu_> ok, another me
[00:38] <Keybuk> yay, clones
[00:38] <svu> :)
[00:38] <persia> heh.  No worries.  A quick search found a fix for XRandR that was reported to work in Jaunty.  I'll see if I can't get it to work more sensibly for maverick.  Do you think that the USB probing might hit X so that it would be autodiscovered, or still need an xorg.conf.
[00:39] <Keybuk> svu_: ok, let's start with the basics
[00:39] <bryceh> persia, to be honest I haven't dug into the usb probing to know if there's been work on that upstream
[00:39] <Keybuk> reboot the other box, and get it to that maintenance shell
[00:40] <persia> snow_ru: There's heaps of stuff that needs volunteers, but here in Ubuntu we tend to focus on everything, rather than specific things.  If you want to work on a specific thing, I recommend finding a bit of software you like, and chasing it to fix all the bugs (bugs.launchpad.net/ubuntu/+source/${PACKAGE}/+bugs is a good place to start.
[00:40] <bryceh> persia, well, I should say I scanned through the xorg-devel mailing list but didn't find anything there
[00:40] <bryceh> persia, but that was a few weeks ago
[00:40] <persia> bryceh: Is USB probing something you're likely to be able to investigate in maverick?
[00:40] <svu_> yes, there is /dev/.udev.info
[00:40] <svu_> a lot of stuff inside
[00:40] <bryceh> persia, no I won't be working on X in meerkat
[00:40] <Keybuk> svu_: no /dev/.udev.log
[00:40] <svu_> sorry I meant udev.log
[00:40] <svu_> of course
[00:41] <Keybuk> svu_: ok, can you get me the output of /proc/self/mountinfo ?
[00:41] <Keybuk> cat /proc/self/mountinfo I mean
[00:41] <persia> bryceh: Ah, in that case, no worries.  I'll file a bug if I run into a solution.
[00:41] <svu_> ghm.... smbmount does not work :(
[00:41] <Keybuk> svu_: ? I didn't ask you to run smbmount
[00:41] <svu_> how would I copy that stuff here?
[00:42] <svu_> on second machine?
[00:42] <svu_> Or just save it into different location and provide you after I boot successfully?
[00:42] <svu_> or copy to usb flash?
[00:43] <Keybuk> svu_: can you not take a photo of the screen?
[00:43] <svu_> ghm. ok :)
[00:46] <Keybuk> we're trying to debug a failure to mount a filesystem
[00:46] <Keybuk> going around mounting filesystems is *going to change the result* :p
[00:47] <svu_> indeed. ok, I got some shot using my mobile...
[00:48] <svu_> Keybuk, is rapidshare good enough?
[00:49] <slangasek> svu_: you could just post it to the bug report?
[00:49] <svu_> slangasek, right:)
[00:51] <svu_> added to bug report
[00:52] <svu_> http://launchpadlibrarian.net/44204574/Image0021.jpg
[00:53] <svu_> anything else?
[00:54] <snow_ru> ok
[00:54] <snow_ru> bye
[00:56] <Keybuk> svu_: ok, well that all looks right
[00:56] <Keybuk> hmm
[00:56] <Keybuk> ls -l /dev/mapper/control
[00:56] <Keybuk> what's the permissions and ownership?
[00:56] <svu_> root:root
[00:56] <svu_> crw-rw----
[00:57] <Keybuk> ok
[00:57] <slangasek> Keybuk: didn't tseliot say he had a bzr branch for part of this i18n fix?  I can't find it now
[00:57] <Keybuk> svu_: ls -l /dev/tty1
[00:57] <Keybuk> same question
[00:57] <svu_> root:tty
[00:58] <Keybuk> ok
[00:58] <Keybuk> so udev is working
[00:58] <svu_> crw--w----
[00:58] <Keybuk> what does "lvm vgs" say?
[00:59] <svu_> it shows VG1
[00:59] <svu_> PV 1 LV 3 Attr wz--n-
[00:59] <svu_> BUT
[00:59] <svu_> there is one thing
[00:59] <svu_> suspicious
[00:59] <svu_> many commands say File descriptor 8 leaked
[01:00] <svu_> I noticed that before many times
[01:00] <svu_> does it matter?
[01:00] <Keybuk> that's just the shell ;-)
[01:00] <svu_> ok
[01:01] <svu_> I felt I have to let you know :)
[01:01]  * kees wonders if watershed is iin the intramfs
[01:01]  * svu_ feels soon he will have to tell the superuser passwd and IP address :)
[01:03]  * ScottK gets a pencil.
[01:04] <svu_> ScottK, nothing interesting on that system. Just old power g5...
[01:05] <ScottK> ;-)
[01:06] <psusi> well that was interesting... updated my system which included an update to grub and a new kernel, and it decides not to add the initrd line to the new boot stanza.. add it myself and it boots.... grub-update again and it does it right this time.... I have a feeling there's a race condition somewheres.. ugh...
[01:07] <svu_> Keybuk, anything else to check?
[01:08] <Keybuk> well
[01:08] <Keybuk> I'm stuck
[01:08] <Keybuk> lvm knows about your vgs
[01:08] <Keybuk> no idea why it hasn't activated them
[01:09] <Keybuk> I think udev has run lvm
[01:09] <svu_> how would I check that in .udev.log ?
[01:09] <svu_> how could I debug udev activities on boot?
[01:10] <IntuitiveNipple> Keybuk: Excuse me, I've not seen the bug you're working on but mentioning the LVM not mounted issue reminded me I've seen that here too, but always just gone into maintenance mode
[01:10] <Keybuk> that's harder
[01:10] <Keybuk> modify udev.conf to start with --debug
[01:10] <svu_> IntuitiveNipple, and what did you do in the maint mode?
[01:10] <IntuitiveNipple> Keybuk: strangely what I found was that whilst I was at the prompt thinking what to do, the missing device 'appeared' after a delay
[01:10] <IntuitiveNipple> so I just exit M mode and the system continues to start correctly
[01:11] <psusi> svu_, the volumes don't belong to another machine or instance do they?  unless they have been set up or imported they won't be automatically activated
[01:11] <IntuitiveNipple> I assumed a race condition in mountall or similar
[01:11] <svu_> psusi, all same machine, SATA drive
[01:12] <svu_> Keybuk, why is that harder?
[01:20] <Keybuk> svu_: well, you have to do something ;-)
[01:21] <svu_> Keybuk, :) I just did. interesting change in behaviour after reboot
[01:22] <svu_> When I ask 'vgchange -a y' - I am getting error about missing mapper in /proc/misc
[01:22] <svu_> !!!
[01:22] <Keybuk> slowed it down enough to make it work?
[01:22] <svu_> But
[01:22] <Keybuk> oh, that's kinda interesting
[01:22] <svu_> after some while
[01:22] <svu_> and several attempts
[01:22] <svu_> it worked
[01:22] <svu_> and ... I think I had to make udevadm trigger as well
[01:22] <svu_> yes
[01:23] <svu_> and I see device-mapper in /proc/misc - all the time!
[01:26] <svu_> actually!
[01:26] <svu_> device-mapper is not there initially
[01:26] <svu_> indeed
[01:26] <svu_> not in /proc/misc
[01:27] <kees> that's odd
[01:28] <svu_> even after udevadm trigger
[01:29] <svu_> suddenly (timeout??) I see a lot of output on console
[01:29] <Keybuk> I thought we built that in
[01:29] <svu_> and voila - device-mapper in /proc/misc
[01:30] <psusi> sounds like the driver isn't being loaded before the tools try to use it
[01:30] <svu_> it seems there was some delay
[01:30] <svu_> and --debug made that delay even bigger
[01:30] <cjwatson> ./config.common.ports:289:CONFIG_BLK_DEV_DM=m
[01:30] <cjwatson> ./config.common.ubuntu:375:CONFIG_BLK_DEV_DM=y
[01:30] <cjwatson> so on svu_'s powerpc box it won't be built-in
[01:30] <svu_> ports!!!!!!!!
[01:30] <Keybuk> oh, that's kinda fun
[01:30] <Keybuk> so when the underlying block device shows up ...
[01:30] <Keybuk> lvm is run ...
[01:30] <cjwatson> silly ports split
[01:30] <Keybuk> but device-mapper isn't loaded
[01:30] <Keybuk> so boom
[01:31]  * persia filed a bug about that recently, and hunts up the number
[01:31] <svu_> boom
[01:31] <svu_> baga boom
[01:31] <persia> bug #560717
[01:31] <Keybuk> cjwatson: well done
[01:31] <Keybuk> shall I try and bread roll a kernel dev?
[01:32] <persia> svu_: Please confirm and mark as affecting you :)
[01:33] <cjwatson> Keybuk: might not hurt, I don't know if they have time for another upload / were planning one anyway
[01:33] <cjwatson> slangasek: so that mountall typo I noticed above - do you think we can squeeze in a fix for it?
[01:34] <svu_> persia, I marked "affects me too"
[01:34] <cjwatson> it's sitting there on the screen for some time and I'd rather not have a typo there
[01:34] <persia> svu_: Thanks.  If we can get all the powerpc LVM users to do that, maybe we can get an SRU, even if we can't get a prerelease upload :)
[01:34] <slangasek> cjwatson: we're getting mountall string changes anyway today (unfortunately) to fix an untranslatable string, so yes
[01:34] <slangasek> (just as soon as I verify the upgrade path on mountall+plymouth)
[01:35] <cjwatson> ok
[01:35] <cjwatson> will commit in a sec
[01:35] <svu_> persia, ok. Thanks a bunch, I would love to get that fixed. Otherwise the boot process does not look nice :)
[01:35] <psusi> Keybuk, say... what sort of tools should I look at to investigate a blocktrace during boot?  I got e2defrag to pack all the files ureadahead wants at the start of the disk and oddly, the peak throughput went down slightly though total time in ureadahead also went down by a few seconds
[01:35] <svu_> thank you all lads for you help
[01:36] <asac> directhex: hola
[01:36] <asac> directhex: why do you tink that having minVersion 1.9 is right?
[01:37] <asac> in gluezilla
[01:37] <directhex> asac, because it works (although not with 1.9.3 according to micahg), whereas the previous hard-coding caused more issues than it solved
[01:38] <asac> directhex: its not a good idea to just keep it fully open
[01:38] <Keybuk> psusi: blktrace ;)
[01:38] <asac> directhex: so definitly minVersion needs to be 1.9.2
[01:38] <psusi> lol... of course ;)
[01:38] <asac> directhex: there is no guarantee that standalone glue works with something lower than what it was linked from
[01:39] <asac> directhex: for higher versions we would need to review what xpcom components it uses. if those are all frozen its fine to keep 1.9.*
[01:39] <asac> as maxversion
[01:39] <asac> but 9.9 is definitly wrong ;)
[01:40] <micahg> I'll push my working patch up to the ffox36 transition PPA to test
[01:41] <kees> Keybuk: udev starts before modules are loaded...
[01:41] <directhex> asac, frankly, i'm sick to death of the package. do whatever, i really don't care as it only affects people running system.windows.forms apps with embedded browser controls (i.e. nothing in the archive). do what you like with it, use http://www.java2s.com/Code/CSharp/GUI-Windows-Form/WebBrowserinaction.htm to test it
[01:41] <kees> init-top, then module loads, etc.
[01:41] <Keybuk> kees: well, yes
[01:41] <Keybuk> udev *loads* modules
[01:41] <asac> directhex: kk
[01:41] <kees> since ide is builtin, the vgchange triggers before device-mapper is loaded
[01:42] <persia> Keybuk: Ought udev be loading dm_mod in this case then?
[01:42]  * kees is fighting tmobile's network
[01:42] <asac> directhex: sorry about that :(
[01:42] <Keybuk> persia: no
[01:42] <asac> will take care
[01:42] <Keybuk> dm_mod is one of those modules that can't be auto-loaded
[01:42] <Keybuk> which is WHY IT'S BUILT IN! :p
[01:42] <persia> aha! (except it's not) :)
[01:42] <Keybuk> well, that's the bug
[01:42] <persia> Right.
[01:42] <directhex> asac, also try shana on gimpnet #mono, within portugese working hours
[01:43] <persia> But now I understand it, rather than it just being a mysterious failure which I knew how to make go away :)
[01:43] <directhex> asac, at the very least, -2 works, -1 segfaulted, so it could be worse
[01:43] <asac> heh ;) thanks alot
[01:43] <psusi> well, it could be auto loaded... if udev tested for and loaded it if not already before invoking the tools that depend on it... or better yet, the tools could do that... I don't see why libdevmapper doesn't do that already
[01:43] <directhex> or @sh4na on twitter
[01:45] <Keybuk> psusi: because libdevmapper can be invoked by users
[01:45] <kees> Keybuk: so, bug on the kernel then?  won't make rc1...
[01:45] <Keybuk> kees: I think so
[01:46] <Keybuk> psusi: users can't load modules
[01:46] <kees> Keybuk: yeah, looks like it's built-in in karmic.
[01:46] <asac> directhex: ok. makes some sense. the currently disabled patch forced the load of xulrunner 1.9.1. so yeah. that crashes :)
[01:46] <Keybuk> kees: yeah, it's like unix, ppp, fuse, etc.
[01:46] <Keybuk> it makes no sense to be a module
[01:46] <directhex> asac, forcing 1.9.2 didn't work for me on one machine, just had a grey screen
[01:46] <Keybuk> it has to be loaded by hand to work
[01:46] <directhex> asac, so be sure to test changes
[01:46] <Keybuk> etc.
[01:47] <Keybuk> so just build the thing in
[01:47] <persia> kees: I can confirm it was built-in for powerpc/amd64 in karmic and amd64 in lucid (but not powerpc).
[01:47] <asac> directhex: yes, dont bother. we will check this out
[01:47] <kees> hrm. only I don't see it ... ah! not built-in in ppc!
[01:47] <asac> directhex: will let you know
[01:47] <persia> kees: RIght, or, for that matter, on sparc/ia64.  armel is messy enough I don't even want to look.
[01:48] <kees> we could make the initramfs hook for dmsetup fail if dm_mod isn't built-in...
[01:48] <psusi> Keybuk, they can't use libdevmapper either
[01:48] <Keybuk> psusi: sure they can
[01:48] <cjwatson> psusi: is this discussion anything other than academic?  things clearly work better if it's built-in, so build it in.  the only downside is a small increase in core kernel size, which really is not that much of an issue on Ubuntu.
[01:48] <persia> Could we make the initramfs hook for dmsetup attempt to load dm_mod if it's not present?
[01:48] <Keybuk> then you just move the bug to requiring an initramfs
[01:48] <Keybuk> seriously
[01:48] <Keybuk> just build the module in
[01:49] <cjwatson> there's no point bikeshedding when there's precious little upside to making it be a module
[01:49] <Keybuk> lots of things stop working if you go around changing random =y to =m
[01:49] <kees> persia: it does already.  it's just after udev starts
[01:49] <psusi> Keybuk, crw-rw---- 1 root root 10, 59 2010-04-14 20:02 /dev/mapper/control
[01:49] <Keybuk> psusi: chmod id
[01:49] <psusi> cjohnston, true
[01:49] <persia> Anyway, my bug calls for it to be a built-in.  Let's hear from a kernel dev.
[01:49] <Keybuk> psusi: you're allowed to do that
[01:49] <Keybuk> persia: the kernel dev who walked past on his way to get a nexus one said it's ok to build it in on ports
[01:49] <Keybuk> since it is in common ;)
[01:49] <kees> persia: which bug #, btw, I'm a bit lost on scrollback
[01:50] <kees> heh
[01:50] <persia> kees: bug #560717
[01:50] <psusi> Keybuk, think the kernel checks for CAP_SYS_ADMIN anyhow ;)
[01:50] <asac> directhex: oh. what was the best way to test?
[01:50] <Keybuk> psusi: for devmapper? it shouldn't
[01:51] <directhex> asac, paste the code from http://www.java2s.com/Code/CSharp/GUI-Windows-Form/WebBrowserinaction.htm into a .cs file, run gmcs -pkg:dotnet foo.cs; mono foo.exe
[01:51] <kees> psusi: SYS_ADMIN for what operation?
[01:51] <directhex> asac, that's a reasonably minimal example SWF browswer
[01:52] <slangasek> Keybuk: tested out the low-color icons, I think I'm ready to upload - any objections?
[01:52] <Keybuk> slangasek: none
[01:52] <Keybuk> does it look at least 5% less crappy?
[01:53] <slangasek> it looks pretty crisp
[01:53] <psusi> kees, the ioctls to manipulate the device mapper tables
[01:53] <asac> directhex: it wants dotnet.pc
[01:53]  * asac esarches
[01:54] <directhex> asac, mono-devel
[01:54] <kirkland> slangasek: i haven't tried a karmic -> lucid upgrade in a while
[01:54] <asac> oh .. thats a lot of stuff
[01:54] <slangasek> kirkland: did you test one after I uploaded the change?
[01:55]  * psusi wonders what the HELL could be confusing parted about what fs type is on partition 1 after creating it while partition 2 is mounted... yet unmounting partition 2 OR reformatting partition 1 from within parted fixes it
[01:55] <kirkland> slangasek: what's the date of that?
[01:55] <kees> psusi: ah, yeah
[01:55] <kirkland> slangasek: i can background one in a vm, if you like
[01:55] <slangasek> kirkland: 30 Mar
[01:55] <slangasek> kirkland: a test would be helpful
[01:55] <kirkland> slangasek: i probably have not
[01:55] <kirkland> slangasek: i'll do that now
[01:57] <Keybuk> psusi: blkid
[01:57] <Keybuk> touching things would result in blkid running again from udev
[01:57] <kirkland> slangasek: via do-release-upgrade -d ?
[01:57] <MattJ> Is there a default user group for admins?
[01:57] <slangasek> kirkland: however it was reproduced before
[01:57] <slangasek> kirkland: and/or however that bug says it's reproducible
[01:58] <MattJ> I'm making a package, and debating what permissions to put on the config folder in /etc
[01:58] <kirkland> MattJ: there is an admin group
[01:58] <MattJ> Do you know if that's an Ubuntu-only thing, or Debian too?
[01:58] <psusi> Keybuk, yea... and blkid recognizes the partition type just fine... but even rescanning/restarting parted and it still doesn't
[01:59] <kirkland> MattJ: i'm pretty sure admin is consistent across Ubuntu and Debian
[01:59] <kirkland> slangasek: upgrade underway, against local mirror
[01:59] <kirkland> slangasek: give it a few minutes, i'll check back
[02:00] <psusi> partition 1 exists, is readable, writable, mountable, yet parted won't detect the fs type... it's so weird....
[02:04] <Keybuk> right
[02:04] <Keybuk> party
[02:04] <bcurtiswx> how long do the builders wait with no buildlog changes before they fail out?
[02:04] <persia> bcurtiswx: 150 minutes
[02:05] <bcurtiswx> persia: yikes, openjdk is immobile right now
[02:05] <persia> which arch?
[02:06] <MattJ> I think it's been like that a bit longer than 150 minutes :/
[02:06] <bcurtiswx> persia: i386
[02:07] <bcurtiswx> persia: https://edge.launchpad.net/ubuntu/+source/openjdk-6/6b18-1.8-0ubuntu1/+build/1691250
[02:07] <persia> bcurtiswx: How long do you think it's been sitting at "Error: com/sun/jdi/BacktraceFieldTest.java"?
[02:08] <bcurtiswx> Persia: honestly, no idea, saw the backlog of i386 packages waiting to build, thought maybe there was one package holding a few back.. looked at openjdk and saw it was stuck
[02:08] <kirkland> slangasek: i did get an error with mountall
[02:08] <kirkland> slangasek: is this logged to a file somewhere I can pastebin or attach to that bug?
[02:09] <bcurtiswx> persia: plus it was started 14 hours ago
[02:10] <persia> bcurtiswx: That's never a safe indication: the prior upload took 15 hours, 37 minutes, 55.9 seconds to build on i386.
[02:11] <bcurtiswx> persia: nice.. good to know
[02:11] <persia> See https://launchpad.net/~ubuntu-security/+archive/ppa/+build/1625847
[02:11] <kirkland> slangasek: nevermind; i'm running again, tee'ing output
[02:12] <MattJ> Oh yay, the PPA build queue seems to be moving, thanks for that whoever :)
[02:13] <bcurtiswx> persia: hey, it moved!
[02:13] <bcurtiswx> persia: thanks for your help :)
[02:14] <persia> bcurtiswx: Happy to share how things work to avoid confusion :)
[02:16] <kirkland> slangasek: http://paste.ubuntu.com/414635/
[02:17] <kirkland> slangasek: let me know if there are more detailed logs somewhere else
[02:24] <slangasek> kirkland: no more verbose logs unless you pass apt some debugging options; can you follow up with mvo on this?
[02:40] <ryanakca> Hmmm... can anybody confirm having difficulty unlocking a disk at boot with plymouth?
[02:40] <ryanakca> At first I thought it was my imagination, but it is happening often enough for me to think there's an issue. I can usually unlock a disk on the first try if I boot in rescue mode (and enter my passphrase without it going through a plymouth theme). But if I boot normally, it takes me 6-7 tries.
[02:41] <ryanakca> This happens even if I type in each character, one by one. I don't think it's a keyboard issue because I can type perfectly once the netbook starts up
[02:42] <ryanakca> One thing that I've noticed is that sometimes when I enter a character, it doesn't show up in the passphrase box.
[02:46] <slangasek> ryanakca: there's a bug open on plymouth about this, but I can't reproduce it here
[02:48] <ryanakca> slangasek: Has the bug been confirmed? If not and you have the bug number handy, I can confirm and add whatever lacking information there may be...
[02:51] <slangasek> ryanakca: sorry, don't have time to look for it right now; it should stand out in the list though, it has a pretty clear title
[02:57] <ajmitch> everything's icy now?
[02:57] <spm> ice ice baby
[02:58]  * TheMuso shivers.
[02:59] <JontheEchidna> whew, uploaded with only seconds to spare
[03:21]  * TheMuso notes that powerpc is not taking jobs.
[03:24] <ScottK> TheMuso: IA64 and Sparc neither.  It's been reported.
[03:25] <TheMuso> ScottK: ok thanks.
[04:59]  * ccheney notes reading through 1,132 tax forms is not fun
[06:45] <pitti> micahg: I'm open to improving the strings in maverick; would you mind opening a bug about it?
[06:45] <pitti> Good morning
[06:45] <micahg> pitti: good morning, can I resurrect the one that was marked invalid or file new?
[06:45] <pitti> micahg: resurrecting sounds fine
[06:46] <micahg> pitti: k, on another note, is Monday too late to drop xul191?
[06:47] <pitti> micahg: no, we should really get rid of it IMHO
[06:48] <micahg> pitti: actually, I'll talk to asac, the last thing that uses it AFAICT is gjs and that uses an older version that is in archive so maybe tomorrow :)
[06:51] <micahg> pitti: could I trouble you for an FFe to fix the vlc FTBFS against xulrunner-1.9.2 (bug 558981)
[06:53] <pitti> micahg: this isn't an FFE, just a bug fix, so please go ahead
[06:54] <micahg> pitti: even though there are 7 patches added?
[06:54] <pitti> micahg: they don't add new features, change strings, etc.
[06:55] <micahg> pitti: no, ok, thanks
[06:57] <micahg> pitti: actually, OJI is disabled in xul192, so that's a small change
[06:58] <robert_ancell> asac, how do you use libntrack?
[07:51] <dholbach> good morning
[07:51] <imbrandon> moins dholbach
[07:52] <dholbach> hi imbrandon
[07:52] <MattJ> Mornings
[07:52] <baptistemm> good morning
[07:53] <MattJ> I have a package for a new upstream bugfix version of a package in Lucid
[07:53] <MattJ> The new upstream isn't in Debian (yet)
[07:54] <MattJ> But it fixes some important issues, so should I file a bug and attach my .diff.gz?
[07:54] <MattJ> or would it be fine to wait for Debian and request a sync? (not sure what's best, regarding the freeze)
[07:55] <micahg> MattJ: what package?
[07:55] <MattJ> prosody
[07:55] <micahg> MattJ: I think you have this next week to get a sync from debian for that
[07:56] <micahg> MattJ: if it's bug fix only
[07:56] <MattJ> Ok, thanks, I'll give a shove in that direction :)
[07:56] <MattJ> It is bugfix only, including one that allows a DoS against connected clients from remote ones
[07:58] <robert_ancell> pitti, I'm trying to use the libntrack package but I get linking errors, when I rebuild the deb locally it works fine.  Does it make sense the archive should recompile it?  If so, what is the best way to do that (just bump the version number?)
[08:01] <pitti> robert_ancell: if it demonstrably helps, a 006-1build1 is fine; but it would be good to find out what broke in particular (ABI change in dependent library?)
[08:02] <robert_ancell> pitti, it seems like an internal symbol, and I can't work out why that would be
[08:15] <pitti> robert_ancell: well, at this point, if a rebuild helps just upload it
[08:16] <_minerva> hi
[08:36] <robert_ancell> pitti, can you give ntrack a kick, it's waiting for approval (are we in final freeze now?)
[08:36] <pitti> oh, we are?
[08:36] <pitti> sure
[09:01] <mdz> is anyone else finding that their desktop runs out of memory when left idle overnight
[09:05] <mvo> pitti: could you please have a look at the u-m upload? just a trivial frbfs fix
[09:05] <ogra> hrm, so fsck does not respect the e2fsck.conf file ...
[09:05] <pitti> mvo: sure, approved, thanks
[09:05]  * ogra wonders why we have fsck *and* e2fsck ...
[09:06] <RAOF> mdz: Evolution seems to be consuming an unreasonable and increasing amount of memory here; maybe that's a part of it?
[09:06] <mdz> RAOF: yes, that's consistent with my symptoms as well
[09:06] <mdz> usually evolution-data-server and chromium fight over who gets OOMed
[09:06] <mdz> once swap is exhausted
[09:07]  * ogra sighs ... so there is no way to boot a system that has no RTC battery unless i edit both fstabs
[09:07] <mvo> thanks pitti
[09:07] <ogra> thats really bad
[09:07]  * ogra waits for Keybuk
[09:09] <mdz> it's not happening every day, but it's happening most days
[09:12] <superm1> pitti, could you have a glance at the casper upload too?  would ideally like to get today's dailies unbroken for early commands if possible
[09:13] <pitti> superm1: done
[09:13]  * pitti also accepts command-not-found
[09:13] <superm1> thanks, most appreciate
[09:13] <superm1> d
[09:23]  * ogra files bug 563618 in the hope we can somehow get that fixed for release
[10:37] <mdz> I'm seeing an issue on mbark's laptop where plymouth is flickering rapidly during fsck, and never makes progress
[10:39] <mdz> it doesn't seem like bug 554737
[10:39] <ogra> mdz, is his clock wrong ?
[10:39] <mdz> ogra, I doubt it, but I didn't check
[10:40] <mdz> it's flickering between two different messages, one of which shows fsck progress and "F to fix, I to ignore, M for manual" or similar
[10:40] <ogra> mountall doesnt seem to respect fsck returning nonzero in severeal cases
[10:41] <ogra> i have such an issue on the beagle which renders it unbootable (no rtc battery so the clock is always reset)
[10:41] <mdz> ah, sounds like bug 538433
[10:46] <al-maisan> Hello, where would I get plymouth 0.8.2-1 from? On my "fully patched" lucid box I currently have plymouth Version: 0.8.1-4ubuntu1
[10:49] <james_w> do we still use xsplash at all?
[10:50] <dholbach> james_w: it's in universe fwiw
[10:51] <james_w> al-maisan: it hasn't built yet
[10:51] <al-maisan> james_w: ah, I see, thanks!
[10:53] <mdz> also bug 501801
[10:58] <ogra> mdz, Bug 563618 too
[10:59] <ogra> (i think i pointed to at least one of the above in the report)
[11:00] <mdz> ogra, are you saying you think the root cause is the same?
[11:00] <mdz> 563618 doesn't say what symptoms you actually see when this goes wrong
[11:00] <ogra> mdz, yes, we dont seem to get to a maintenance shell in either case
[11:01] <Laney> Could https://launchpad.net/ubuntu/+source/highlighting-kate/<IP_ADDRESS>-1/+build/1689855 be rescored, please?
[11:01] <ogra> mdz, "that behavior together with a mountall bug which does not give the user a maintenance shell when fsck exits but makes it go into an endless loop renders many ARM platforms we support unbootable"
[11:01] <slangasek> al-maisan: ah, looks like it hasn't built yet, sorry - too many other last-minute uploads in the queue, I suppose
[11:02] <al-maisan> slangasek: no problem -- I will test when it becomes available.
[11:15] <asac> robert_ancell: re: libntrack: in the source there are examples in common/tests glib/tests gobject/tests etc.
[11:15] <asac> robert_ancell: i have patches for empathy and weather applet in my ppa
[11:16] <robert_ancell> asac, thanks got it to work.  The problem was the lucid version fails to link. if I rebuild it it works.  Could you check if that's the case for you?
[11:16] <robert_ancell> I've bumped the version number so it rebuilds but I don't know why it had the problem
[11:16] <asac> robert_ancell: you mean the package doesnt build?
[11:17] <robert_ancell> asac, I mean if you compile a hello world -lntrack it fails to find some internal symbols
[11:19] <asac> robert_ancell: with an empty test.c it doesnt happen here
[11:19] <asac> robert_ancell: can you paste what you got ;)?
[11:19] <robert_ancell> asac, it's in an email I sent you
[11:19] <asac> ah
[11:19] <robert_ancell> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libntrack.so: undefined reference to `_ntrack_arch_new'
[11:19] <robert_ancell> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libntrack.so: undefined reference to `_ntrack_arch_get_rfds'
[11:19] <robert_ancell> /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/libntrack.so: undefined reference to `_ntrack_arch_process_data'
[11:19] <asac> interesting
[11:20] <asac> will check it out after getting coffe
[11:20] <robert_ancell> asac, thanks
[11:22] <robert_ancell> asac, off now, good luck!
[11:23] <Riddell> ev: did you manage to recreate the kubuntu oem issue?
[11:28] <ev> Riddell: indeed, working on it as we speak
[11:38] <nosse1> is there a link to the armel build queue somewhere?
[11:39] <nosse1> oh, sorry. wrong channel
[11:39] <jpds> nosse1: https://launchpad.net/ubuntu/lucid/+builds?build_text=&build_state=building&arch_tag=armel
[11:51] <slangasek> dpm: ping
[11:51] <dpm> hey slangasek
[11:52] <slangasek> dpm: hiya - so, I've just pushed through the queue the last change to fix bug #553954, which is good news and bad news
[11:52] <dpm> first the bad news
[11:53] <slangasek> dpm: good news because it means the fsck interaction is translatable, bad news because it means there's another string for everyone to translate
[11:53] <dpm> slangasek, ah, untranslatable strings becoming translatable are never bad news :)
[11:53] <slangasek> dpm: can you rouse the translation teams to see if we can get that translated a few places before the langpack deadline next week? :)
[11:54] <slangasek> dpm: I also accepted a change from cjwatson to fix a typo in another mountall string, so translations will need to be un-fuzzied in LP however that's done...
[11:55] <dpm> slangasek, sure, thanks for the heads up. Do you know if the now translatable string appears in different templates, or is it just mountall?
[11:55] <slangasek> dpm: just in mountall
[11:55] <dpm> ok, cool
[11:56] <slangasek> hmm, I was going to see what translations are currently out there for the unfuzzied string, but I fail at navigating rosetta
[11:56] <dpm> slangasek, let me see...
[11:57] <slangasek> LP doesn't know about mountall as an upstream project, only as an Ubuntu package...
[11:57] <LaserJock> anybody seen any "hard drive suddenly becomes read-only and I can't reboot" sort of bugs in the last day or so?
[11:57] <slangasek> aha, https://translations.launchpad.net/ubuntu/lucid/+source/mountall
[11:57] <dpm> slangasek, that's the one
[11:58] <slangasek> so, 16 existing translations
[11:58] <slangasek> oh
[11:59] <dpm> slangasek, actually, there are more, there was another bug in mountall
[11:59] <dpm> and the imports queue has been quite slow lately
[11:59] <slangasek> in fact, since the .pot file in the package was out of date, maybe nobody has translated the pre-fuzzy string, either
[11:59] <dpm> slangasek, that could well be. I had to manually upload an updated template a couple of days ago exactly because of that, but it hasn't been imported yet
[11:59] <dpm> https://translations.edge.launchpad.net/ubuntu/lucid/+source/mountall/+imports
[12:00] <slangasek> dpm: ok - so we should have an up-to-date pot now once it gets processed, and I don't have to feel bad about fuzzying anyone's translations
[12:00] <LaserJock> I guess I'll take that as a "no" :(
[12:01] <slangasek> LaserJock: I have not
[12:02] <LaserJock> hmm, not good, not good at all
[12:02] <LaserJock> well, good for Ubuntu, not good for me
[12:03] <dpm> slangasek, yeah, if the typo fix was on a string not having yet been exposed in LP for translation, we should be good to go, no ugly unfuzzying :). And just for reference, actually the fix for the outdated POT file was on the same upload (bug 559997)
[12:03] <slangasek> yep
[13:09] <james_w> zul: is your mysql-cluster upload going to fix this too? http://people.canonical.com/~ubuntu-archive/NBS/mysql-cluster-common
[13:10] <zul> james_w: it should
[13:10] <james_w> good
[13:13] <james_w> doko_: will a rebuild of visualvm move it off libnb-platform10-java?
[13:14] <doko_> james_w: no, it needs a the new minor upstream version, but part of the sources are not yet released, and I did fail to pick them up out of the netbeans repo. may become a sru
[13:14] <james_w> ok
[13:14] <james_w> it's NBS, so what's the best way to proceed?
[13:15] <james_w> you're keeping an eye on it?
[13:15] <doko_> yes
[13:16] <james_w> ghreat
[13:51] <debfx> could someone from the release team please have a look at bug #563771
[13:53] <dholbach> pitti: HAPPY BELATED BIRTHDAY! :)
[13:53] <pitti> dholbach: *hug*, thank you!
[13:53]  * dholbach hugs pitti
[13:53]  * dholbach hugs pitti
[13:53]  * dholbach hugs pitti
[13:53] <mdz> pitti!
[13:54] <mdz> when was it?
[13:55] <slangasek> debfx: looking, though there's nothing there that looks like it needs the release team?
[13:55] <dholbach> mdz: yesterday
[13:55] <slangasek> (just someone with upload rights?)
[13:55] <didrocks> oh late birthday greetings pitti (hadn't match this with your evening) :)
[13:56] <primes2h> pitti: Oh... happy belated birthday from me too :-)
[13:56] <slangasek> pitti: happy birthday :)
[13:56] <mvo> happy birthday pitti!
[13:56] <ev> happy birthday pitti!
[13:56] <pitti> wohoo!
[13:56] <pitti> thanks a lot, guys
[13:56] <pitti> it was yesterday, the big three-o
[13:57]  * pitti blogged some thoughts on http://www.piware.de/, but sorry, German
[13:57] <pitti> at least it has a nice photo of the cake :)
[13:57] <debfx> slangasek: I thought uploads need release team ack in final freeze
[13:57] <dholbach> pitti: Jungspund!
[13:57] <slangasek> debfx: they need an ack, but they don't need approval prior to upload
[13:58] <pitti> dholbach: pah
[14:05] <debfx> slangasek: ok sorry, I misunderstood the process
[14:06] <sebner> pitti: congratulations from me too! :) I didn't know that you are still _that_ young. Looking forward to your next list in 2020 :)
[14:06] <pitti> sebner: thanks
[14:10] <Daviey> slangasek: bug 563785, i think is a dupe of bug 423667 - which i thought had been fixed.
[14:11] <Daviey> (it hasn't been included in main, but is that just waiting on an AA?)
[14:11] <slangasek> debfx: 563771 - fix uploaded, thanks!
[14:12] <slangasek> Daviey: ah, that bug has no task on the package, making it entirely search-proof
[14:12] <slangasek> Daviey: thanks, will close this out
[14:12] <Daviey> ahh.. good point.. TBH, i prepaired an upload of this yesterday, thinking it was main :S
[14:43] <jdstrand> slangasek: hi!
[14:43] <jdstrand> slangasek: I have a profile change to fix bug #517714 which I, *ahem*, reintroduced just before freeze. ok to upload?
[14:44] <apw> jdstrand, not sure if steve is still awake, might ask on #u-release
[14:45] <jdstrand> apw: thanks
[14:59] <genii> Getting version mismatches between initramfs-tools and initramfs-tools-bin ..paste here: http://pastebin.com/p17rMcLi ... needs ver 73 of initramfs-tools-bin or ver 72 of initramfs-tools
[15:01] <persia> genii: You're clearly not running i386: arch skew: wait a bit :)
[15:01] <genii> Will do :)
[15:02] <persia> genii: When https://launchpad.net/ubuntu/+source/initramfs-tools/0.92bubuntu73 shows your arch to have been built, you should be able to upgrade within about an hour or so.
[15:02] <cjwatson> I'd score that amd64 build up, but it's going to start in 25 minutes anyway so not much point
[15:03] <cjwatson> Riddell: I probably ought to change gfxboot's background colour to match the new Kubuntu background image, yes?
[15:03] <amitk> ogra: so do you know why I don't see initramfs output on the serial console? Or rather - why only on tty0?
[15:04] <cjwatson> Riddell: do you want the foreground colour changed too, and if so to what?  While *I* can read light-blueish on slightly-darker-blueish, those with impaired colour vision may have rather more difficulty
[15:04] <starshiptrooper> pitti: do you happen to have time to look at bug 560659
[15:05] <pitti> starshiptrooper: I don't know about kpackagekit, I'm afraid
[15:05] <cjwatson> Riddell: http://people.canonical.com/~cjwatson/tmp/kubuntu-boot-screen.png
[15:05] <starshiptrooper> pitti: needs SRU :)
[15:06] <pitti> ah, ok
[15:06]  * starshiptrooper is wondering whether he uploaded that though
[15:06] <apachelogger> ^^
[15:08] <pitti> apachelogger: looks fine, please go ahead and upload
[15:09] <apachelogger> pitti: Successfully uploaded packages.
[15:09] <pitti> apachelogger: is there any chance to prevent that from a different place as well? I'm not sure how many people install those updates in a timely manner
[15:09] <pitti> ok, I'll do an SRU round later on then
[15:09] <apachelogger> pitti: unfortunately not
[15:09]  * apachelogger actually complained about that in december but didnt file a report and forgot to fix it :/
[15:11] <genii> Also on the dist-upgrade just before that it got stuck trying to install ttf-indic-fonts or ttf-indic-fonts-core (no conffile to remove, error in line 19 of preinst, etc) since I don't think I was using any Indian fonts anyhow, removed it so things could progress
[15:12] <Pici> genii: Someone in u+1 reported that earlier.  I don't know if they filed a bug though.
[15:13] <dholbach> .
[15:14] <jdstrand> slangasek: nm (taken care of)
[15:29] <ogra> amitk, because the first console option is kernel only .... if you only have one console= setting it will show output on serial
[15:38] <ccheney> NCommander: seems to be working so far, still building after 17hr on arm
[15:49] <mathiaz> slangasek: hi - is the concept of runlevel still correct in the upstart world? see bug 561779
[16:03] <james_w> I'm starting a packaging training session on using bzr for Ubuntu development now in #ubuntu-classroom
[16:04] <psusi> son of a... according to this blktrace  the kernel merges readahead with the original request, thus delaying the completion of the original request, and leaving the disk idle until user mode issues the next request
[16:10] <doko_> smoser: 562787, is this something to be fixed for lucid?
[16:20] <ScottK> genii: The ttf-indic-fonts bug is fixed.  You should have an updated package shortly.
[16:20] <genii> ScottK: Thanks :)
[16:22] <genii> I see the 64bit initramfs is also built now, will update shortly
[16:28] <bdrung> debfx: bug #563933
[16:29] <genii> Looks like it hasn't propogated yet, I'll try again later (initramfs-tools-bin). The ttf-indic-fonts reinstalled fine though.
[16:29] <persia> genii: You need to wait for the publisher run to complete, which takes unfortunately long.  Try again at the top of the hour.
[16:31] <debfx> bdrung: that's one of the many duplicates of bug #563771
[16:31] <ScottK> bdrung: It was the old version still trying to unpack
[16:32] <bdrung> marked as dup
[16:32] <bdrung> i should have searched the fixed bugs
[16:33] <genii> persia: OK, thanks
[16:34] <Sarvatt> kees:  about the -dbg/-dbgsym problems with xorg-server and mesa - https://bugs.edge.launchpad.net/ubuntu/+source/pkg-create-dbgsym/+bug/562418
[16:57]  * ogra sighs about the armel buildfarm ... 5 active builders and all are busy with the 5 biggest packages we have
[16:57] <ogra> we'll never clear the queue
[16:58] <amitk> ogra: send them off to mdeb.org
[16:58] <amitk> they've got 35
[16:58] <ogra> yeah
[16:59] <ogra> and probably icecc or distcc to trunk several of them together on demand
[17:00] <ogra> our queue needs to get more intelligent ... allowing oo.o, firefox, TB, mesa and openjdk at the same time should simply not be possible on armel
[17:01] <ScottK> ogra: There's a gcc-snapshot in queue too.
[17:02] <ogra> oh, fun
[17:04] <MarkieMark1> hi, is it #ubuntu-app-devel for indicator-applet-session / indicator-applet?
[17:09] <pitti> starshiptrooper: I reject the older one of your two kpackagekit uploads, so don't get scared of the rejection message
[17:09] <davmor2> Guys empathy is only using the simple account manager now which means you can't setup an irc account is this known?
[17:10] <davmor2> seb128, pitti ^
[17:11] <pitti> davmor2: hm, seems to work here?
[17:11] <seb128> you can't during initial config
[17:11] <seb128> you can after
[17:11] <seb128> there is a bug about it yes
[17:11] <seb128> it's an upstream decision
[17:11] <starshiptrooper> pitti: right, thanks :)
[17:12] <dholbach> asac: did you get any reports about thunderbird not starting anymore?
[17:13] <davmor2> pitti, seb128: I'm only getting the simple account manger here all the time
[17:13] <seb128> ?
[17:13] <seb128> oh you mean you don't want to configure any non IRC account
[17:13] <seb128> not even a local avahi one
[17:14] <seb128> it works after having configured one account
[17:14] <davmor2> I did the avahi one and then closed empathy
[17:14] <seb128> empathy is an IM client not an IRC client
[17:14] <seb128> the main aim is not to do IRC
[17:14] <seb128> well in the account dialog you should be able to add any account now
[17:14] <davmor2> I ten open empathy and hit F4 and get the simple account setup still
[17:15] <seb128> ok, so you need to configure a real account
[17:16] <davmor2> yes so I just added my FB account and now I can gain access to the proper account manager
[17:17] <kees> slangasek: I believe lvm2 for bug 358654 is a false-positive, as it depends on dmsetup, which depends on initramfs-tools.  am i misunderstanding some element of dark magic that requires I have a depends on initramfs-tools for lvm2 also?
[17:19] <pitti> jdstrand: was the "CVE-2010-XXXX" in the sudo changelog deliberate?
[17:20] <jdstrand> pitti: yes
[17:20] <jdstrand> pitti: to be filled in later (it is not assigned yet)
[17:20] <davmor2> seb128: thanks I'll file a bug against it
[17:21] <seb128> davmor2, there is a bug aobut it already as said before
[17:21] <davmor2> oh sorry miss read
[17:24] <pitti> ogra: uboot-envtools> is that actually used/useful on non-arm arches?
[17:24] <kirkland> mvo: slangasek: hi, i'm at a point where i can do-release-upgrade -d from a karmic vm to lucid, to reproduce that problem;  how do i introduce more debugging?
[17:28] <ogra> pitti, not at all unless someone implements uboot as bootloader on !arm
[17:29] <pitti> ogra: I just wondered because it's arch:any
[17:29] <ogra> well, i dont know if there is any HW way to use NAND on a different arch or some such i couldnt imagine one though
[17:30] <ogra> but it might be possible to create binary images that you can dd to NAND
[17:30] <ogra> so in that case you would want to use it on x86
[17:31] <ogra> generally thats just a corner case though
[17:31] <micahg> I've got a problem with a package that did something it shouldn't, but non-desctructive, and I want to display a message on upgrade to this new version what the fix is, is PKG.listchanges the way to do that?
[17:32] <pitti> ogra: ok, done
[17:32]  * ogra hugs pitti
[17:32] <pitti> ogra: please seed/depend on
[17:32]  * pitti hugs back ogra, np
[17:32] <ogra> pitti, you just made omap work ! :)
[17:32] <mvo> kirkland: hello, what problem? 559582 ?
[17:32] <ogra> that was the last missing piece in the puzzle
[17:32] <pitti> ogra: no I won't come to the mobile team :) OEM got me first
[17:32] <ogra> haha
[17:32] <ogra> pitti, OEM ?
[17:32] <ogra> you move ?
[17:33] <pitti> ogra: rotation, starts in about two weeks
[17:33] <ogra> ah
[17:33] <pitti> for once, I'll earn my wages :)
[17:33] <ogra> heh
[17:33] <ogra> you already do by giving them a foundation :)
[17:34]  * ogra wonders off for some early dinner
[17:35] <micahg> what's the proper way to display a message on how to fix something on install
[17:35] <kirkland> bug 559582
[17:35] <kirkland> mvo: yeah, that one
[17:37] <micahg> zul: can you help me, how did you get the notice to show in the apache package on install?
[17:37] <zul> micahg: what?
[17:38] <micahg> zul: about the changes that affect the user
[17:38] <mvo> kirkland: do you can reproduce it already? does it fail like this?
[17:38] <zul> micahg: i dont know what you are talking about
[17:38] <micahg> zul: I have a package where I need to display a message to the user on install, I noticed apache2 did this recently
[17:39] <zul> micahg: you probably want to do it in the postinst
[17:44] <kirkland> mvo: i'm bzipping a kvm disk image
[17:44] <kirkland> mvo: it's an up-to-date default 9.10 server install
[17:44] <mvo> kirkland: thanks, /var/lib/dpkg/status + etc/apt/sources.list should be enough I think
[17:44] <kirkland> mvo: you and fire it up in kvm, and see for yourself
[17:44] <mvo> kirkland: cool
[17:45] <kirkland> mvo: i'll pastebin those two in the mean time
[17:45] <mvo> kirkland: thanks, it is/was on my list for today, but a initramfs-toolls / initramfs-tools-bin mismatch prevented further debugging today
[17:45] <smoser> doko_, the only way to fix that upgrade path would be to have glibc remove that file if it existed.
[17:46] <kirkland> mvo: http://paste.ubuntu.com/415052
[17:46] <mvo> smoser: hi, did you had a chance to re-run the upgrade with --sandbox?
[17:46] <kirkland> mvo: http://paste.ubuntu.com/415053
[17:47] <smoser> doku_, its a very unlikely path to be cared about.  the reason for that is that a.) we've only published "instance-store" instances of hardy and b.) instance store instances cannot change the kernel . thus there is no way to reboot after you did an upgrade (unless we wanted to support hardy kernel lucid user space, which i dont think is desired)
[17:47] <mvo> thanks kirkland
[17:47] <smoser> mvo, i haven't. i can easily test that though if you want me to
[17:48] <mvo> smoser: not urgent, but the fix for this is in the archive now
[17:48] <mvo> smoser: not sure how well aufs is doing these days with that particular workload, but I would be interessted
[17:48] <smoser> yeah, i had seen that.
[17:48] <mvo> but be careful, don't try it on a producation server just yet
[17:48] <smoser> mvo, yeah, andin this case its not "these days" that you'd be interested in, but "hardy days"
[17:49] <mvo> heh :) indeed
[17:50] <mvo> kirkland: hrm, I just tried to reproduce with the state file in the bugreport, no luck
[17:50] <mvo> kirkland: I wait for your vm image I think
[17:52] <hacksaw> I'm looking for a pointer to docs on the best way to create a deb which contains additions to /etc/apt/sources.list.d
[17:53] <kirkland> mvo: uploading now... i'm heading to lunch.  should be here in ~25 minutes:  http://people.canonical.com/~kirkland/karmic-server.img.orig.bz2
[17:54] <kirkland> mvo: ubuntu/ubuntu is user/pass;  bunzip it  and then you can just run:  testdrive-kvm karmic-server.img.orig
[17:54] <kirkland> mvo: or kvm with your own parameters
[17:54] <doko_> smoser: unconditionally?
[17:55] <smoser> doko_, ?
[17:55] <smoser> the only case where upgrade from a "Official Ubuntu Image" of is possible is really just a test case.
[17:55] <doko_> smoser: well, attach a patch, what you think needs to be done
[17:56] <mpt> persia, do you use IBus?
[17:56] <persia> mpt: Yes.
[17:56] <persia> mpt: ibus-anthy to be specific.
[17:57] <smoser> doko_, ok. i'll see if i can come up with something.  its really edge case that it would matter. and definitely would not affect anyone running one of our published images.
[17:57] <mpt> persia, I'm wondering how much of a problem it is that in Lucid it doesn't show the icon of the current input method in the panel
[17:58] <persia> mpt: For me, none at all, because I never switch (ibus-anthy allows entry of ローマ字 without switching).  For folks in places that don't do that, it makes it impossible to know what one will type.
[17:58] <mvo> kirkland: thanks!
[17:59] <mpt> persia, that's what I feared
[17:59] <snow_ru> haha
[18:01] <persia> mpt: I believe it should be painful for anyone who isn't using a Japanese or Korean keyboard, since I believe these are the only sorts that have dedicated keys to control the IME (which are used by the various ibus backends), to give you an idea of scope.
[18:04] <mpt> jcastro, ^^^
[18:04] <asac> dholbach: hop into -mozillateam ... i am not really on top of all the recent regressions
[18:04] <asac> dholbach: one reason might be that you have some extension that has .xpt files
[18:05] <asac> but i think we cherry-picked that patch to tbird too
[18:05] <dholbach> asac: thanks discussed it there
[18:05] <asac> but check with micahg and chrisccoulson ... actually both are here ;)
[18:05] <asac> ah
[18:05] <asac> ok
[18:05] <tjaalton> slangasek: rpc.gssd no longer accepts options from /etc/default/nfs-common...
[18:08] <jcastro> persia: ok, what did the icon do in 9.10? (for ibus)
[18:09] <seb128> bug #563893
[18:10] <persia> jcastro: I don't remember.  Sadly, I'm not an affected user (because my keyboard has the extra key, and my ibus backend supports it)
[18:10] <seb128> ^ for information
[18:10] <seb128> binaries will be blocked from download due to this bug
[18:10] <seb128> could people let that know to users in due forums, irc channels, etc?
[18:10] <jcastro> mpt: ok we need to figure out what it's supposed to do.
[18:11] <jcastro> mpt: also the engineering resources that did the work are not around anymore, so we're going to need to figure out a course of action quickly
[18:11] <mpt> jcastro, I'm not a packaging expert, but I expect it's just removing 05_appindicator.dpatch
[18:12] <jcastro> mpt: oh so you're saying just revert the whole thing?
[18:12] <persia> mpt: In which package is the patch?  I can test that.
[18:12] <tjaalton> slangasek: and with active directory I need to feed at least '-n'
[18:12] <seb128> jcastro, persia: what should be displayed in the indicator and what is displayed now?
[18:13] <mpt> persia, ibus, afaict
[18:13] <persia> seb128: I think the icon for the backend should be displayed, so folks know what they wlill type.  RIght now, there's just an unchanging keyboard icon.
[18:13] <jcastro> now it just displays a keyboard
[18:13] <persia> mpt: I'll test that quickly then.
[18:13] <seb128> it's an icon right? because indicators don't do labels for now
[18:13] <mpt> thanks persia
[18:13] <jcastro> mpt: I could have sworn at some point we decided to show a 3 letter country code or something?
[18:14] <seb128> jcastro, indicators don't do labels...
[18:14] <seb128> jcastro, that's why we reverted the keyboard indicator one
[18:14] <persia> jcastro: That wouldn't be a good choice, because some countries have multiple sane input methods.
[18:14] <jcastro> ok so basically we don't really have a choice, we have to revert it.
[18:15] <mpt> seb128, jcastro, persia: I've reported bug 564034 with all I know
[18:15] <jcastro> we neither have the person to fix it and we're out of time for the cycle
[18:17] <smoser> mvo, so, i just tested --sandbox
[18:17] <seb128> jcastro, mpt: I would recommend just dropping the indicator port if we can't fix it
[18:17]  * persia is testing that now
[18:17] <jcastro> right
[18:17] <smoser> i got to the first prompt, it said do you want to continue.  I thought "i should run this in screen" so I hit 'N'.  then reran it.  it says failed to setup aufs.
[18:18] <jcastro> and even if we did fix it we wouldn't have time to test. ibus has had the old tray support for years so this seems the least risky option.
[18:18] <doko_> seb128: any idea about #528892 ? just removed the wrong directory by pasting ... I know we had this kind of bug before, but it was fixed for karmic
[18:18] <seb128> bug #528892
[18:19] <mpt> seb128, I was just in a meeting where we were discussing the menus in general, and tedg mentioned that custom bitmap icons currently aren't possible at all. So yeah, I don't think it's easily fixable except by reverting. :-/
[18:19] <seb128> doko_, no sorry, first time I read about it and mvo does vte usually
[18:19] <seb128> mpt, I set a lucid task and assign the our team now
[18:19] <mpt> Thank you seb128
[18:20] <jcastro> thanks seb
[18:20] <seb128> it's weird that nobody reported the issue in months though
[18:20] <jcastro>  yeah that's worrying to me
[18:20] <seb128> how come we have so few testing in that area?
[18:20] <doko_> mvo: ^^^
[18:21] <seb128> I'm reluctant to set the bug to high based on statement from one person there
[18:21] <seb128> persia, do you know if that has been discussed by some user communities in launchpad or forums or lists?
[18:21] <mpt> jcastro, seb128: One possibility is that most of the people affected don't know English. Another is that it doesn't actually affect that many people, because most people are using a single input method that covers all the characters they need to use.
[18:22] <seb128> jcastro, bug #563893 on an another topic
[18:23] <seb128> jcastro, we had to block binaries of this version in lucid, can you make the word being said around so users know about what is going on?
[18:23] <jcastro> seb128: I'll update the platform twitter feed
[18:23] <seb128> jcastro, thanks
[18:23] <seb128> jcastro, can you let me when it's done?
[18:24] <persia> seb128: mpt's highlight was the first I've heard of it.  I'm not affected, for complex reasons.
[18:24] <jcastro> seb128: yep, one sec
[18:24] <seb128> persia, are you in touch with communities or people who are affected by the issue or did you read anything about it?
[18:25] <persia> mpt: We may also have a low number of lucid testers from affected locales.
[18:25] <mpt> yes
[18:25] <persia> seb128: No, sorry.  The ibus-using communities with which I'm in contact are also users of keyboards with dedicated switch buttons.
[18:26]  * ScottK loves it when filing the bugs afterwards takes longer than doing the actual New review.
[18:26] <mpt> jcastro, seb128: Also, the change has been in for only a month.
[18:28] <seb128> mpt, still we should get feedback about such issues
[18:28] <persia> mpt: I removed the patch, rebuild the packages, installed the results, logged out, logged in, and see no behaviour change.
[18:29] <mpt> persia, so it hasn't moved back to the notification area?
[18:32] <persia> No.  It was there for a few days last week for some reason though.
[18:34] <pitti> micahg, chrisccoulson: can you please ping me once the upload is done? I'll care about reviewing/accepting from the queue and jumping the buildd queue
[18:34] <mpt> Well, I don't know.
[18:34] <chrisccoulson> pitti - ok, will do
[18:35] <mvo> kirkland: I get a 403 on the file
[18:36] <kirkland> mvo: try now
[18:36] <kirkland> mvo: it's perm'd 444, you might have to chmod it 644 after you get it local
[18:36] <mpt> the Ubuntu China forums seem to be all "uninstall ibus, install fcitx"
[18:36] <mpt> which isn't that helpful
[18:36] <mvo> kirkland: thanks, downloading now
[18:37] <mvo> smoser: aha, thanks. sort of known, it now created the overlay, so running it normally should have the same effect (double check with mount please)
[18:38] <mvo> seb128: that is the issue with vte (sorry, missed context)?
[18:38] <smoser> mvo, well, i opened 564053
[18:38] <smoser> bug 564053
[18:38] <smoser> which describes it.
[18:38] <persia> mpt: Only to be expected.  Let's consider this a failed test, and maybe someone who knows what needs doing can fiddle the bug.
[18:38] <mvo> thanks smoser
[18:38] <smoser> its "fixable" with 'sudo umount /var/cache/apt/archives'
[18:39] <mpt> thanks for trying persia
[18:40] <mvo> doko_: hi, interesstinging. i never saw that and I use gnome-terminal and copy/paste all the time
[18:45] <ogra> Keybuk, which fsck does mountall use exactly ?
[18:45] <Keybuk> ogra: the big red one
[18:46] <ogra> can a buildd admin bump initramfs-tools on armel please ?
[18:46] <Keybuk> it usually has the keys in the ignition
[18:46] <Keybuk> and mountall likes to go *fast*
[18:46] <ogra> Keybuk, i mean, does it use the util-linux one or the one from e2fsprogs ?
[18:46] <ogra> (fsck vs e2fsck)
[18:46] <Keybuk> I think you're confused ;)
[18:46] <ogra> i found the e2fsck.conf setting does nothing
[18:47] <pitti> fsck is just the wrapper, which calls e2fsck, fsck.vfat, etc
[18:47] <ogra> am i ?
[18:47] <Keybuk> the util-linux fsck (which was stolen from e2fsprogs originally anyway) is just a wrapper
[18:47] <Keybuk> it calls fsck.<type>
[18:47] <Keybuk> so when you fsck an e2fs filesystem, fsck calls fsck.ext4 for example
[18:47] <Keybuk> which is e2fsprogs
[18:47] <ogra> hmm, the manpage is confusing then
[18:47] <Keybuk> "the manpage" ?
[18:47] <ogra> of fsck
[18:48] <pitti> ogra: i-t bumped
[18:48] <ogra> pitti, merci beaucoup
[18:48] <pitti> ogra: de rien
[18:48] <Keybuk> the manpage attempts to describe the common options
[18:48] <Keybuk> just as the mount manpage does
[18:49] <Keybuk>        In  actuality,  fsck  is simply a front-end for the various file system
[18:49] <Keybuk>        checkers (fsck.fstype) available under Linux.  The file system-specific
[18:49] <Keybuk>        checker  is  searched for in /sbin first, then in /etc/fs and /etc, and
[18:49] <Keybuk>        finally in the directories listed in  the  PATH  environment  variable.
[18:49] <Keybuk>        Please  see  the  file system-specific checker manual pages for further
[18:49] <Keybuk>        details.
[18:49] <Keybuk> that's the key page
[18:49] <ogra> right, i didnt think fsck.ext{2,3,4} would be identical to e2fsck
[18:49] <ogra> and since the config file is ignored that seemed to prove my point
[18:50] <ogra> i even shoveled into the initramfs
[18:50] <ogra> +it
[18:51] <ogra> though i just saw rcn-ee's comment on bug 563618
[18:51] <ogra> might be that broken_system_clock = true simply doesnt suffice here
[18:52] <ogra> though rcn just mailed me and told me he still has to bear a fsck on every first boot
[18:53] <ogra> but thats at least better than infinite rebooting
[18:54] <psusi> ogra: huh?  what config file is ignored?  fsck.ext[234] are just hard links to e2fsck
[18:55] <ogra> psusi, read the bug :)
[18:55] <ogra>  /etc/e2fsck.conf
[18:57] <W3ird_N3rd> cjwatson, to let you know, I just burned the 15-04 netboot ISO and it did detect the Xircom, get DHCP and am trying to install right now..
[19:00]  * psusi goes back to blktraceing
[19:00] <W3ird_N3rd> for..why... :'(
[19:01] <W3ird_N3rd> debootstrap warning: couldn't download package locales
[19:01] <Keybuk> ogra: sorry, not following
[19:01] <W3ird_N3rd> something somewhere is seriously wrong, I just wonder if it's the netboot ISO or this laptop..
[19:02] <Keybuk> you're saying that fsck fails even with that config option?
[19:02] <ogra> Keybuk, right
[19:02] <ogra> and mountall goes into an endless loop still
[19:04] <Keybuk> ogra: the bug is unclear
[19:04] <Keybuk> frankly, I don't believe you that this fails
[19:04] <Keybuk> because Robert has pasted an e2fsck.conf that he says works
[19:04] <Keybuk> that's basically identical to what I suggested
[19:04] <ogra> Keybuk, you suggested broken_system_clock = true ... that definately doesnt change behavior
[19:05] <Keybuk> ok, well, that's a bug
[19:05] <ogra> i havent tried his option yet
[19:05] <Keybuk> does the config snippet robert pasted work for you?
[19:05] <Keybuk> (broken_system_clock = true is simply a shorthand for the exact config robert pasted)
[19:05] <ogra> will try now, i just saw it after i pinged you
[19:05] <ogra> yes, i thought that too
[19:05] <ogra> though his might be a bit more detailed
[19:06] <Keybuk>                 if ((code == PR_0_FUTURE_SB_LAST_MOUNT) ||
[19:06] <Keybuk>                     (code == PR_0_FUTURE_SB_LAST_WRITE)) {
[19:06] <Keybuk>                         profile_get_boolean(ctx->profile, "options",
[19:06] <Keybuk>                                             "broken_system_clock", 0, 0,
[19:06] <Keybuk>                                             &broken_system_clock);
[19:06] <Keybuk>                         if (broken_system_clock)
[19:06] <Keybuk>                                 ptr->flags |= PR_PREEN_OK;
[19:07] <Keybuk>                 }
[19:07] <ogra> hmm, the difference might be that one is in [options] while the other is in [problems]
[19:07] <Keybuk> see above, that's quite correct
[19:07] <ogra> where does [problems] get catched ?
[19:07] <Keybuk> later down
[19:07] <ogra> hmm, then options should overrule
[19:08] <Keybuk> no, options sets the default
[19:08]  * ogra reboots his beagle
[19:09] <ogra> awesome !
[19:10] <ogra> so there is a discrepancy between [problems] and [options] i think
[19:11]  * ogra tries with powering off the board
[19:12] <Keybuk> well, problems is detailed, complex, overrides
[19:12] <Keybuk> options is short-hand
[19:12] <Keybuk> but the code above seems to suggest that the options should get processed
[19:12] <pitti> chrisccoulson: I see the tbird upload, reviewing now
[19:12] <Keybuk> I wonder whether this bug is that it sets PR_PREEN_OK
[19:12] <pitti> it would help if my keyboard would work
[19:13] <Keybuk> but then unsets it when parsing the non-existing problems
[19:13] <pitti> it stopped after current dist-upgrade
[19:13] <ogra> hmm, might be
[19:13] <Keybuk> ogra: don't suppose you can gdb e2fsck? :p
[19:13] <ogra> hard to do if it fails ...
[19:14] <ogra> my board is in an infinite reboot loop now :/
[19:14] <ogra> powering off the board gives me the same behavior as with "broken_system_clock"
[19:14] <ogra> it was just that i only rebooted which kept power on the clock
[19:16] <Keybuk> hard to do?
[19:16] <Keybuk> just open a root shell on another vt :p
[19:16] <ogra> if the board constantly reboots ?
[19:17] <ogra> i dont get to a shell
[19:17] <ogra> i see the splash for a short moment and then it resets hard
[19:17] <Keybuk> ogra: upstart.ubuntu.com/wiki/OMGBroken
[19:17] <Keybuk> ohhhhhh
[19:17] <Keybuk> I just worked this out
[19:17] <Keybuk> broken_system_clock=true is clearly working
[19:17] <pitti> chrisccoulson: tbird accepted and bumped build score; i386 building now
[19:18] <chrisccoulson> pitti - excellent, thanks
[19:18] <chrisccoulson> pitti - i'm just drafting the mail to u-d-a now
[19:18] <chrisccoulson> will be done in a couple of minutes
[19:18] <Keybuk> ogra: sorry, I'm just going to bang my head into a window for a while
[19:19] <Keybuk> you don't get a maintenance shell, do you?
[19:19] <Keybuk> your system *reboots*
[19:19] <ogra> no, it reboots
[19:19] <Keybuk> so it's boot ... fsck ... reboot ... fsck ... reboot ... fsck ... reboot ... fsck ?
[19:19] <ogra> but formerly the same bug showed the fsck message endlessly on the screen
[19:19] <ogra> right
[19:19] <Keybuk> riiiight
[19:19] <Keybuk> ok
[19:19] <Keybuk> err
[19:19] <pitti> chrisccoulson: I first need to fix my system anyway before I can get back to real productivity
[19:20] <Keybuk> ogra: I can't fix this
[19:20] <ogra> Keybuk, who can ? :)
[19:20] <Keybuk> ogra: nobody
[19:20] <Keybuk> fsck is working
[19:20] <ogra> why ?
[19:20] <Keybuk> it corrected a problem with your root filesystem (timestamps all wrong)
[19:20] <Keybuk> and, therefore WE HAVE TO REBOOT
[19:20] <Keybuk> we just raw edited a mounted filesystem
[19:20] <Keybuk> we can't continue
[19:20] <ogra> thats fine ...
[19:20] <Keybuk> so reboot
[19:21] <ogra> oh, but the clock is reset again
[19:21] <Keybuk> and of course, reboot kills your hardware clock again
[19:21] <Keybuk> so your timestamps are wrong
[19:21] <ogra> yes
[19:21] <Keybuk> so fsck has to run again
[19:21] <Keybuk> and corrects the problem again
[19:21] <Keybuk> and changes the root filesystem
[19:21] <Keybuk> SO WE HAVE TO REBOOT
[19:21] <ogra> indeed
[19:21] <Keybuk> and that kills your hardware clock again
[19:21] <psusi> lol
[19:21] <Keybuk> the only way to "fix" this would be to run fsck from inside the initramfs
[19:21] <Keybuk> before mounting the root filesystem
[19:21] <ogra> what about the version where it doesnt reboot but wants to give you a maintenance shell and doesnt ?
[19:21] <Keybuk> that way the raw change doesn't require a reboot
[19:21] <psusi> why is fsck modifying the fs in the first place?
[19:22] <Keybuk> ogra: that I haven't heard of
[19:22] <Keybuk> that would be a different bug
[19:22] <Keybuk> psusi: because the hardware clock is wrong
[19:22] <Keybuk> all of the filesystem timestamps are wrong
[19:22] <psusi> if you know you can't trust the clock then you shouldn't be updating the fs timestamps
[19:22] <Keybuk> ext3/4 are JOURNALLED FILESYSTEMS
[19:22] <ogra> i had that before i successfully mounted the rootfs for the first time (by editing both fstabs)
[19:22] <Keybuk> the timestamp is IMPORTANT
[19:22] <Keybuk> they have to go in one direction ;)
[19:22] <ogra> and amitk sees it too
[19:22] <ogra> as well as asac
[19:22] <Keybuk> ogra: then those people need to supply mountall --debug output for me
[19:22] <ogra> its the same but without rebooting
[19:23] <Keybuk> journalled filesystems can't have timestamps suddenly jump backwards
[19:23] <chrisccoulson> pitti - ok, mail sent to u-d-a now
[19:23] <ogra> its scrolls so fast you nearly cant read it
[19:23] <Keybuk> "I had a write pending at 14:00, and another at 14:05, and another at 08:00"
[19:23] <Keybuk> WTF
[19:23] <Keybuk> that's an inconsistent journal
[19:23] <Keybuk> that's bad
[19:23] <ogra> indeed
[19:23] <ogra> i understand what you say
[19:23] <Keybuk> so that's why we have to fix the timestamps if your hardware clock is broken
[19:23] <psusi> the timestamps in the journal have to go in one direction?  sure, but once the journal is empty what difference does it make that the clock is at the epoch?
[19:24]  * ogra notes that epoch != epoch :)
[19:24] <ogra> the board we talk about sets the time to april 1st 2000 by default :)
[19:25] <ogra> Keybuk, the thing is that it worked before we changed mountall ...
[19:25] <ogra> pre-karmic or so
[19:25] <Keybuk> psusi: if you want to write your own filesystem, please feel free to not include this constraint ;)
[19:25] <Keybuk> ogra: the fact it worked is probably a bug ;)
[19:25] <ogra> heh, might be
[19:25] <pitti> chrisccoulson: moderated
[19:25] <Keybuk> any change to the root fs needs to result in a reboot
[19:25] <psusi> Keybuk: I'm just trying to understand what the constraint is... what does it care about timestamps when the journal is empty for?
[19:26] <psusi> i.e. what is it that you are "fixing"?
[19:26] <ogra> but i think it only told you to reboot and didnt do it automatically
[19:26] <Keybuk> psusi: ask a filesystem engineer
[19:26] <Keybuk> this is a constraint they have engineered into it
[19:26] <ogra> that way you could call hwclock from the maintenance shell
[19:26] <ogra> and as long as you dont power off the board the rtcd is correct
[19:26] <Keybuk> ogra: yeah, but you still technically had to reboot
[19:26] <ogra> right
[19:26] <ogra> but less harmfull
[19:27] <pitti> ok, so what part of the  dist-upgrade messed up my /etc/default/console-setup
[19:27] <ogra> s/rtcd/rtc/
[19:27] <psusi> here's an idea.. how about have the initramfs read the last unmount time from the fs and set the clock to that before calling fsck ;)
[19:27] <Keybuk> psusi: hides potentially dangerous problems
[19:27] <ogra> Keybuk, as ignoring the clock completely does
[19:28] <ogra> but psusi's hack could make it work for me while ignoring the clock apparently doesnt
[19:29] <ogra> though it would add slowdown to the boot
[19:29] <psusi> also you can change the clock backwards while the system is running... why does that not screw up the journal?  the answer to that probably could form a basis for what to do when the clock is broken
[19:29] <Keybuk> psusi: because the kernel uses a monotonic clock
[19:30] <Keybuk> anyway,
[19:30] <Keybuk> I'm done with this bug
[19:30] <Keybuk> I've updated the notes and marked it as Triaged ;-)
[19:30] <Keybuk> someone else can worry about fixing it
[19:30]  * Keybuk will look into the mountall infinite loop on fsck failure bug if someone provides him --debug output
[19:31] <ogra> Keybuk, i'll try to get it for you with the next install (waiting for the next image though which might take a biit until the queue clears out)
[19:32] <ogra> it definately shows up on brandnew installs
[19:32] <ogra> and turns into the reboot thing once you mounted successfully
[19:32] <Keybuk> that's an odd one, mountall should just exit() if it gets an fsck failure
[19:32] <ogra> which i can only achive by editing fstab
[19:32] <ogra> (both of them)
[19:36] <ogra> Keybuk, aha, i reset the system to original state (removing e2fsck.conf and resetting the fstabs) now i get bug 501801
[19:36]  * ogra drops splash and tries again
[19:36] <Keybuk> ok
[19:37] <Keybuk> I have a --debug from matty barker
[19:37] <Keybuk> if you could supply one too, that would be k-rad-appreciated
[19:38] <ogra> right .. without splash: "last mount time is in the future, run fsck manually" infinitely
[19:39]  * ogra edits init/mountall.conf
[19:39] <Keybuk> slangasek: I asked a question on bug #553290  (you're not subscribed?)
[19:44] <ogra> Keybuk, err, tricky indeed it doesnt write to /vat/log/boot.log if it cant mount
[19:44] <Keybuk> ogra: that's ok
[19:44] <Keybuk> now do the mount
[19:44] <Keybuk> and then plymouth will flush it out
[19:45] <Keybuk> you could even just pop a tmpfs there
[19:45] <Keybuk> and call plymouth --sysinit
[19:45] <ogra> hmm ?
[19:45] <ogra> i edited init/mountall.conf
[19:45] <ogra> which indeed gets me a lot on the screen but i cant capture it
[19:45]  * ogra tires serial console
[19:48] <ogra> argh
[19:48] <ogra> plymouth sucks !!!
[19:48] <mvo> kirkland: that is very odd, image is here, unzips fine, shows boot grub prompt very briefly and then just a cursor
[19:48] <Keybuk> ogra: why?
[19:49] <ogra> Keybuk, even with console=ttyS2,115200n8 plymouth ignores me and writes to tty0 (there is no other console option in the cmdline, the kernel shouldnt know about tty0)
[19:49] <ogra> [   70.382324] sd 0:0:0:0: [sda] Assuming drive cache: write through
[19:49] <ogra> [   70.406768] sd 0:0:0:0: [sda] Assuming drive cache: write through
[19:49] <ogra> [   70.658721] sd 0:0:0:0: [sda] Assuming drive cache: write through
[19:49] <ogra> init: ureadahead main process (142) termi
[19:49] <Keybuk> err
[19:49] <Keybuk> tty0 is ttyS2
[19:49] <ogra> thats where the serial output ends on ttyS2
[19:49] <Keybuk> yes
[19:49] <Keybuk> I don't follow
[19:49] <ogra> the rest goes to the display
[19:49] <Keybuk> plymouth will pick up console= and put a "details output" on that
[19:50] <Keybuk> oh
[19:50] <Keybuk> that's odd
[19:50] <ogra> console=ttyS2,115200n8 root=UUID=d088bcbb-ba37-4f21-914b-886eeb6863cc ro quiet vram=12M omapfb.mode=dvi:1280x720MR-16@60
[19:50] <Keybuk> that's probably a bug
[19:50] <ogra> thats my bootargs
[19:50] <ogra> there is an fbcon indeed
[19:50] <ogra> but no console attached to it
[19:50] <Keybuk> right, that should result in plymouth using ttyS2
[19:50] <ogra> and the output on the screen is garbled
[19:50] <Keybuk> and not displaying anything on the main display
[19:50] <ogra> right
[19:51] <Keybuk> sounds like a bug
[19:51] <ogra> might be a kernel bug though
[19:51] <Keybuk> yeah could well be a kernel bug
[19:51] <ogra> i dont really trust the omap fb code
[19:51] <ogra> it has issues everywhere so that wouldnt be a surprise
[19:51] <ogra> hmm, how do i solve that so i can get you a proper log
[19:52] <qense> If reportbug exits with the message "Please install an MTA on this system if you want to use sendmail!" does that mean it has just thrown away your bug report?
[19:52] <qense> That would be quite annoying.
[19:53] <mvo> kirkland: sorry, gtg for the evening, if you could check if the file is correct and send a quick mail I work on it tomorrow (my) moring
[19:54] <ogra> Keybuk, is there any way to omit plymouth completely ?
[19:55] <ogra> hmm, i guess i'll need to follow http://upstart.ubuntu.com/wiki/OMGBroken
[19:55]  * ogra tries that
[19:55] <Keybuk> no
[19:55] <Keybuk> you need plymouth to get the boot log I need anyway ;)
[19:59] <ogra> hmm
[19:59] <ogra> so how do i get that for you
[19:59] <ogra> (i'm in a sulogin console now)
[20:00] <ogra> heh
[20:42]  * ccheney just found out his internet connection speed supposedly doubled recently, now to reconfigure my qos so i can use the extra
[20:42] <joaopinto> is there a page describing how to debug boot problems ?
[20:46] <tormod> joaopinto, how far into the boot?
[20:47] <joaopinto> tormod, I don't have a problem myself but I see several people asking for help with such issues and I couldn't find instructions to guide them
[20:48] <joaopinto> I know a boot related problem can be related to many components, but there should be some checklist
[20:49] <tormod> there are some kernel docs, hang on
[20:50] <tormod> joaopinto, some stuff here: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Problems%20in%20capturing%20information
[20:54] <joaopinto> hum, that one is kernel oriented
[20:54] <joaopinto> I don't see any reference to boot.log there :)
[21:08] <hunger_> What is up with gwibber? It does no longer start:-(
[21:09] <hunger_> Looks like desktopcouch python module fails to load.
[21:30] <ccheney> slangasek: i think openoffice.org-l10n is marked as NEW due to some upgrade packages
[21:31] <jcastro> rickspencer3: robbiew: https://blueprints.edge.launchpad.net/sprints/uds-m
[21:31] <jcastro> I think we should enforce "$track-m" for the naming convention
[21:32] <jcastro> otherwise the session names get too long and look bad on the schedule
[21:32] <jcastro> so like "desktop-m-monoflamewar" instead of "desktop-maverick-monoflamewar"
[21:33] <robbiew> jcastro: sure
[21:37] <seb128> jcastro, can't you just strip <track>-maverick on the schedule display?
[21:37] <seb128> jcastro, or change those to <track>-name?
[21:37] <jcastro> seb128: The scheduling system runs on hope and dreams, not going to touch it
[21:37] <seb128> jcastro, oh come on
[21:37] <jcastro> I'm being dead serious
[21:43] <ScottK> It took a full time developer and a barrel full of hamsters running on their wheels as fast as they could to keep it going last time.
[21:46]  * ccheney bbs, checking his router to see if it is bottleneck
[21:53] <tormod> ScottK, you noticed you posted comment to the wrong bug? 45768
[21:54] <ScottK> tormod: I did.  I also got the right one.  Thanks.
[22:04] <ccheney> it appears my old linksys wrt54g is slowing down my internet connection :-\
[22:06] <amalthea> hello
[22:15] <micahg> ccheney: I'm assuming OO.o is supposed to be using 5MB less of space
[22:16] <ccheney> micahg: hmm?
[22:16] <ccheney> micahg: if it got smaller thats good i think :)
[22:17] <micahg> ccheney: pdfimport, report builder bin, and core totalling about 5MB
[22:17] <ccheney> micahg: one of the things i fixed in the recent upload was reduced duplication in usr/share/doc some more, i don't know how much it helped the cd but definitely would help in full install
[22:17] <ccheney> er full install of OOo (including stuff not on cd)
[22:18] <ccheney> micahg: the symlinking of those dirs might be what you see in the size reduction
[22:19] <slangasek> mathiaz: sure, runlevels still exist; I don't think that's a case we can handle right now w/ upstart, though, since a runlevel change doesn't assure us that the network is up
[22:19] <slangasek> kees: 358654> nope, if there's a transitive dep, then that's enough
[22:19] <micahg> ccheney: apt double counts the file size?
[22:20]  * micahg is not getting along with symlinks today
[22:20] <kees> slangasek: okay, I set it invalid :)
[22:20] <ccheney> micahg: no, i mean they used to be real files but got changed over to just symlinking to the uno-libs3 doc dir
[22:21] <micahg> ccheney: ah, ok, cool
[22:21] <slangasek> tjaalton: rpc.gssd> /etc/init/gssd.conf is a conffile which you can edit directly
[22:21] <ccheney> micahg: as new packages are added i sometimes forget to add them to the symlink list so i went through and updated it for this past upload
[22:21] <micahg> ccheney: awesome
[22:22] <slangasek> Keybuk: bug #553290> replied
[22:24] <ogra> Keybuk, i'd like to schedule a session at UDS to discuss the "clock fights fsck" issue, would you participate ?
[22:24] <ogra> Keybuk, given we will hit that issue a lot with ARM partners
[22:25]  * ccheney kicks comcast, the problem isn't really my router its a lack of them being able to sustain a stable rate period
[22:26] <Keybuk> ogra: I don't see the point of discussing it at UDS
[22:26] <Keybuk> are you going to invite the ext4 or btrfs filesystem authors?
[22:26] <Keybuk> if not, what's the point?
[22:27] <ogra> Keybuk, well, we need to find some kind of solution for that
[22:27] <Keybuk> ogra: the solution is to change the filesystem design to not need reliable timestamps
[22:27] <ogra> how about attacking it at the clock side instead ?
[22:28] <Keybuk> if you can persuade Ted, you can probably fix it for ext5 - but knowing Ted, he will think it's your problem
[22:28] <ogra> heh
[22:28] <Keybuk> the btrfs author may be more receptive and it's not stable yet
[22:29] <ogra> well, i'm not sure either of them will be there
[22:29] <ogra> and we will also likely use other filesystems like ubifs in the future
[22:29] <ogra> and i dont even know if that issue would be an issue on such filesystems
[22:30] <Keybuk> so if we don't have filesystem authors, no point discussing it
[22:30] <Keybuk> this is a problem with the filesystem design
[22:30] <ogra> well, depends on your POV
[22:30] <ogra> i'd call it a problem with the hardware design probably ;)
[22:31] <ogra> and software should be able to overcome issues in bad HW design imho
[22:31] <Keybuk> yeah, but the problem is the filesystem needs timestamps
[22:31] <ogra> even if its a (temporary) workaround
[22:31] <Keybuk> if we change them in fsck, we have to reboot because the filesystem is MOUNTED
[22:31] <Keybuk> like I said
[22:31] <Keybuk> you can work around this by doing the fsck before mounting the root filesystem in the initramfs
[22:32] <ogra> right, so store a timestamp somewhere to set the clock
[22:32] <ogra> would be one possible workaround ...
[22:32] <Keybuk> that's another option, set the clock from the last mount time of the filesystem
[22:32] <ogra> right
[22:32] <Keybuk> but again, never going to do that in the standard distro
[22:32] <seb128> ogra: why can't you fix the hardware clock?
[22:32] <Keybuk> seb128: because he's too cheap to buy a battery <g>
[22:32] <ogra> seb128, because there is no battery ... as soon as you remove power the clock is zeroed
[22:33] <seb128> you get what you deserve there? ;-)
[22:34] <Keybuk> ogra: there will be pins to which you can attach a battery
[22:35] <ogra> Keybuk, sure
[22:35] <Keybuk> so do that ;)
[22:35] <ogra> no :)
[22:36] <ogra> i'm working with the HW as it comes from the vendor
[22:42] <seb128> ogra: just set the clock on boot to what you had as a value before...
[22:42] <ogra> right or even to the timestamp you read from the fs
[22:48] <jdong> ccheney: I thought it was widely understood that at best those things can route at somewhere around 15 mbit/s just due to NAT overhead.
[22:48] <jdong> err wow irssi scrolling fail.
[22:48] <jdong> stale comment
[23:23] <bluefoxicy> okay
[23:23] <bluefoxicy> who the fuck am I supposed to cut
[23:23] <persia> !ohmy
[23:23]  * bluefoxicy wonders what moron decided to move the control boxto the LEFT side ofthe windows
[23:23] <kklimonda> seriously? now you are wondering?
[23:24] <slangasek> Keybuk: did you want that mountall --debug output with or without the bustification patch applied?
[23:24] <Tm_T> bluefoxicy: something else we can help you with?
[23:24] <kklimonda> bluefoxicy: the change has been made on the request from design team some time ago
[23:24] <bluefoxicy> kklimonda:  My close/minimize buttons are top left in lucid, never mind thunderbird eating infinite memory trying to open any e-mail message
[23:24] <bluefoxicy> kklimonda:  right, didn't see that one.  Filing a bug on the control box placement thing.
[23:25] <kklimonda> bluefoxicy: no point - it's not a bug, it's theme-dependant and there is already a lengthy discussion on the LP about it
[23:25] <ion> I wasn’t happy with the close button not being in the window corner, but that annoyance has been fixed and i’m happy with the layout now.
[23:25] <ion> s/the window corner/a window corner/
[23:25] <bluefoxicy> kklimonda:  really?  Because I'm not using the default theme, I'm using glossy.  And in Appearance Preferences it shows the control box in the top right...
[23:27]  * bluefoxicy switches back and forth between themes a few times and the whole thing goes away, even in human.  Huh.
[23:27] <Keybuk> slangasek: I want to see it fail, obviously ;-)
[23:28] <slangasek> Keybuk: I'll have to think if I can even accomplish that; the only way I've been able to recover is with break=init and manually mounting the filesystems *before* mountall runs
[23:28] <bluefoxicy> kklimonda:  out of curiosity, what prompted the rearrangement of the UI?  Is someone on the design team left handed?  An Apple fanboy?  Trying to be different from Windows?  Sick in the head?
[23:29] <slangasek> Keybuk: I suppose I could mount / rw, tweak the upstart job to log to the rootfs, and let it go
[23:29] <bluefoxicy> top-right is functionally easier for right-handed people, though top-left is for left handed people
[23:31] <W3ird_N3rd> bluefoxicy, it is said canonical has plans to but different functionality top-right
[23:31] <kklimonda> bluefoxicy: really, such remarks about developers are improper and this isn't really channel to discuss whys of this particular decision - I'm pretty sure that all has already been said about it on various blogs, forums and mailing lists and if you are really interested in it you can just do some research.
[23:31] <W3ird_N3rd> which would lead us to guess to have already moved the controls so users get used to it being there
[23:32] <W3ird_N3rd> *but=put
[23:32] <W3ird_N3rd> and totally with kklimonda
[23:32] <bluefoxicy> this is akin to moving the accelerator pedal to the left of the brake pedal in a car.
[23:32] <W3ird_N3rd> don't worry though, I heard you can put them back where they used to be
[23:33] <ion> bluefoxicy: Sound good to me.
[23:33] <ion> s
[23:33] <bluefoxicy> yeah, I touched the appearances box and that particular change disappeared forever.  TO the point that I can't find a way to get it back.
[23:33] <bluefoxicy> I'm amused that a broken idea is implemented broken.
[23:33] <W3ird_N3rd> bluefoxicy, don't go on about it, not here. Move the buttons back if you want to, discuss it on a blog, I would guess there is a thread on ubuntuforums, maybe launchpad or the idea-site (what was it called), but this is not the place
[23:34] <W3ird_N3rd> it is not broken, it is not what you are used to, and if you want to change it do some research on how to change it back - you are not alone and there is no-doubt a good guide on restoring the buttonlocation
[23:35] <bluefoxicy> "broken" has a different definition in UI design than in engineering.
[23:35] <bluefoxicy> Anyway I have other things to worry about now
[23:36] <ion> A Windows user who was visiting me used my computer for a while and *immediately* found the close button without asking. Based on this usability study with 1 sample, the layout is intuitive. ;-)
[23:38] <kirkland> slangasek: Keybuk: does this look familiar?  http://pastebin.ubuntu.com/415224/
[23:38] <bluefoxicy> oh, I saw it, I can hit it, but I don't have the twitch muscle memory to hit it fast enough when i.e. thunderbird is rapidly allocating memory because it's currently incapable of functioning.
[23:38] <TheMuso> Anyone on the release team/release queue, please reject the ubuntustudio-meta upload as it was adjusted incorrectly.
[23:39] <joaopinto> is there a formal announcement for the final freeze ?
[23:39] <W3ird_N3rd> other than https://wiki.ubuntu.com/LucidReleaseSchedule ?
[23:40] <slangasek> bryceh: hum, what's xorg-server-1.7.6/debian/patches/index.html?id=3083c5d0c4386cdd7083b7a83ac72
[23:40] <slangasek> bryce ...fdad2f1e61e ?
[23:40] <jpds> bluefoxicy: Try turning off the global indexing feature in Edit → Prefs → Advance.
[23:40] <joaopinto> that's the schedule, not an announcement :)
[23:40] <bluefoxicy> jpds:  you're faster than google :| or I suck at this.
[23:40] <Keybuk> kirkland: that's the lucid release schedule?
[23:41] <bryceh> slangasek, sorry that's cruft that should be removed
[23:41] <W3ird_N3rd> bluefoxicy, train your mucles to hit alt+f4, always faster than moving your mouse :P
[23:41] <kirkland> Keybuk: huh?
[23:41] <bluefoxicy> jpds:  and unfortunately that doesn't help...
[23:41] <bryceh> slangasek, should I re-upload with that deleted?
[23:41] <ion> I wonder what creates boot.log? :-)
[23:41] <slangasek> bryceh: seems to be a duplicate of debian/patches/115_xext_fix_cursor_ref_counting.patch - will it cause a build failure from the duplication?
[23:41] <slangasek> bryceh: I just want to know if it's build-tested before I throw it at the buildds
[23:41] <bryceh> slangasek, nope, only patches listed in series gets applied
[23:41] <slangasek> bryceh: ok
[23:41] <bryceh> slangasek, yes it is build tested
[23:42] <TheMuso> disregard my above request
[23:42] <slangasek> bryceh: great, accepted - thanks!
[23:42] <kirkland> Keybuk: http://pastebin.ubuntu.com/415224/ is a boot log
[23:42] <slangasek> TheMuso: disregard> so you *do* want us to accept it? :)
[23:43] <bluefoxicy> jpds:  more interesting was when i first tried to start thunderbird it didn't work... the upgrade process moved ~/.thunderbird to ~/.thunderbird.upstream and made ~/.thunderbird a symlink to .thunderbird
[23:43] <jpds> bluefoxicy: bug #563893.
[23:44] <bluefoxicy> jpds:  Yep.
[23:44] <slangasek> kirkland: 'Skipping mounting / since Plymouth is not available" - I guess that will look familiar to Keybuk, but I don't know why plymouth is breaking for you
[23:44] <slangasek> whee, mismatched quotes
[23:44] <bluefoxicy> jpds:  i'm trying to find a bug/workaround/whatever for the infinite memory usagething though.  It happens when it tries to load a message, so as long as I don't click the main tab I'm good.
[23:45] <TheMuso> slangasek: bdrung updated the package without updating the seeds. I dare say it can slide for now, but I have told him about the seeds bzr repo for the future.
[23:45] <Keybuk> slangasek: that's one of those error messages like "beg for mercy" from the kernel when the module list changes
[23:45] <Keybuk> in fact
[23:45] <Keybuk> I may add it
[23:45] <Keybuk> "Skipping mounting / since Plymouth is not available.  BEG FOR MERCY!"
[23:46] <slangasek> Keybuk: the logic seems flawed to me, though - why should mountall refuse to even *try* to mount just because plymouth died?  shouldn't it wait until interaction is needed before giving up?
[23:47] <bluefoxicy> Huh.  the solution for the memory problem ... is to create a .thunderbird.upstream folder.  I symlinked it from .thunderbird and thunderbird moved it.  Without .thunderbird.upstream, it... immediately allocates infinite memory, wtf?
[23:47]  * bluefoxicy isn't sure how you even write an application with a bug like that!
[23:47] <slangasek> "I can't interrupt this stupid fsck that takes too long" > "I can't boot at all because plymouth is broken"
[23:47] <kirkland> slangasek: Keybuk: is there a compelling reason to use plymouth at all in a cloud image?
[23:47] <Keybuk> slangasek: it didn't try
[23:47] <Keybuk> it got bored
[23:48] <Keybuk> that was the interaction that was needed ;-)
[23:51] <slangasek> kirkland: yes, because it's part of the base system and an integral part of the boot design and it's hard enough to support *one* model for the boot system without having to worry about making a completely separate design work because of people trying to rip a core component out every time there's a bug
[23:51] <slangasek> Keybuk: by "interaction" I mean "input" - what input is required from the user?
[23:52] <kirkland> slangasek: alrighty
[23:52] <Keybuk> slangasek: "/ hasn't showed up, want to skip it or get a maintenance shell?"
[23:56] <mathiaz> slangasek: how often is run fsck?
[23:56] <slangasek> Keybuk: ah, so it only does that when mnt->error is set, ok... it's a bug then that we're hitting the boredom timer?
[23:56] <mathiaz> slangasek: after a specific number of times it has been mounted or is it time based (last 30 days)?
[23:57] <slangasek> mathiaz: ext3 has settings for both
[23:57] <slangasek> mathiaz: I haven't looked at ext4
[23:57] <mathiaz> smoser: are the lucid images using ext3 or ext4?
[23:57] <Keybuk> slangasek: well, it might not be a bug
[23:57] <Keybuk> who knows
[23:57] <Keybuk> but yeah
[23:58] <slangasek> Keybuk: either a bug that the boredom timer is hit, or a bug that mountall isn't able to see the filesystem
[23:58] <Keybuk> maybe yeah