[00:42] <ayan_> is tangerine down?
[00:42] <bjf> ayan: yes
[00:43] <bjf> ayan: more like, it's unreachable at this time
[00:43] <ayan> heh.  okay.
[00:43]  * ayan will retry later.
[00:43] <bjf> ayan: we think it's a networking issue and since most of IS is in oakland now ...
[00:43] <ayan> oh!
[00:44] <bjf> ayan: yup, not likely to get fixed anytime soon
[00:44] <ayan> okay -- i need to build kerel with some firewire patches from upstream.
[00:44]  * ayan will slum it and use his own machine.
[08:07]  * apw yawns
[08:17]  * xnox passes a cup of Dolce Gusto Grande coffee to apw 
[08:17] <apw> hmmm that sounds rather nice
[08:18] <ohsix> lots of sugar coffee
[08:18] <apw> hasn't been through a cat has it ?
[09:43] <cking> apw, i've got this in my sources.list: http://ppa.launchpad.net/webupd8team/java/ubuntu
[11:56] <apw> dileks, thanks for the emails with the testing results, that is good feedback thanks
[12:02] <dileks> apw: yeah. unfortunately, testcase scripts are rare for overlayfs. but the one from jordi I liked very much
[12:03] <dileks> maybe, I should mention that squashfs-tools are required
[12:07] <dileks> apw: will you send your inode_only_permissions stuff (again) plus 3.4 fixes as a series to miklos and linuxfs-devel ML?
[12:07] <apw> dileks, thats the plan indeed, want to do that today
[12:07] <dileks> good
[12:08] <dileks> you can give me a pointer to ubuntus live-system framework?
[12:08] <apw> tgardner, ogasawara, am looking at the quantal build failure
[12:08] <tgardner> apw, didn't know there was one yet.
[12:09] <apw> lacking a build depend on flex by the looks of it
[12:09] <dileks> maybe I tease dba on #debian-live with overlayfs
[12:10] <apw> dileks, i beliebe we use live-builder for most of it
[12:11] <dileks> OK
[12:30] <apw> tgardner, resolve_symbol_wait() implies we waited for the module init
[12:30] <apw>                 printk(KERN_WARNING "%s: gave up waiting for init of module %s.\n",
[12:31] <tgardner> apw, yeah, was just looking at kernel/module.c
[12:33] <apw> tgardner, in init_module we call do_mod_ctors() which looks to be where the module inits are called, then we call wake_up(&module_wq) only after we have done that and marked it live, so i think module_init(xx) has been called
[12:33] <tgardner> apw, actually, that only makes sense. it just about _has_ to be that way, else nothing would work.
[12:34] <apw> cirtainly it would be hard to write anything which initialised anything ... so i tend to concur it has to be intended
[12:37] <tgardner> apw, I don't think do_mod_ctors(mod) calls the module init function. it looks like that is the job of do_one_initcall() 'cause thats the only place that an error return is recognized.
[12:42] <apw> tgardner, yeah same logical place either way
[12:43] <tgardner> apw, right.
[12:43] <tgardner> apw, its like they've implemented the ability to call C++ constructors, but not used it anywhere.
[12:43] <tgardner> there must be some other kind of constructor
[12:46] <apw> tgardner, its do_one_initcall, as apparently there can only be one initcall per module
[12:46] <tgardner> apw, that is also correct, lest you incur a linker error
[13:05] <ogasawara> apw: thanks for fixing up the build failures, am curious why the test builds didn't see the same error
[13:05] <ogasawara> apw: will get it uploaded
[13:06] <apw> ogasawara, already uploaded and building
[13:06] <ogasawara> apw: ah cool, thanks
[13:06] <apw> ogasawara, we install the builddeps at chroot build time
[13:07] <apw> and so we never see this kind of thing, its something we need to think about probabally
[13:07] <apw> how to best do it and still be quick, perhaps have some virgin chroots which we can use
[13:07] <apw> for that
[13:10] <apw> ogasawara, bah the archive is inconsistant for i386 right now, somethign wrong with docbook-utils ... i suspect we need to wait a bit and retry it
[13:10] <ogasawara> apw: ack
[13:10] <apw> given that part of your build was ok i think, if not then we'll want to disable docs for a bit
[13:11] <apw> ogasawara, just confirmed your 1.1 got past this, so it may be transitional ...
[13:11] <ogasawara> apw: yep, it would appear so
[13:14] <tgardner> ogasawara, apw: shouldn't we be uploading to -proposed ? that way we can get all of the components built, then just pocket copy.
[13:15] <apw> as far as i know that is only safe in freezes
[13:15] <tgardner> apw, actually, I think its meant to be policy for Quantal.
[13:16] <tgardner> prolly should ask cjw
[13:17] <ogasawara> tgardner: I'll follow up with the release team
[13:19] <tgardner> ogasawara, Rick has proposed that the release pocket always be installable. given our upload order we rarely have issues with that, but it might be simpler to just upload to -proposed and get everything built.
[13:19] <ogasawara> tgardner: yep, it was easier with proposed as we'd just shove all the packages up at the same time
[13:22]  * tgardner notes the combination of mumble+pulseaudio consumes 55% of the CPU whilst doing absolutely nothing.
[13:26] <ogasawara> tgardner: cjwatson confirmed that for now while the archive is still settling it doesn't matter much if we upload to the release pocket or -proposed
[13:27] <ogasawara> tgardner: once it does settle though, we should go the route of uploading to -proposed first
[13:27] <tgardner> ogasawara, ack
[14:20] <dileks> apw: its live-build not -builder. dunno if (3.0~a24-1ubuntu1) is recent enough
[14:20] <dileks> debian/sid has live-build (3.0~a47-1) 
[14:28] <dileks> is there a repo containing higher versions of live-build/live-boot?
[14:30] <dileks> http://nopaste.snit.ch/136914
[14:36]  * ogasawara back in 20
[14:57] <cking> tgardner, here are some notes I crufted up yesterday: http://zinc.canonical.com/~cking/fs-tests/ureadahead-notes.txt
[14:57] <tgardner> cking, thanks
[14:59]  * cking slips off early today, started at 7am...
[16:28] <apw> bjf, yes things going well on that front
[16:28] <apw> bjf, but i've bust my machine here :/
[16:29] <apw> i can hear you but the load on my machine is over 20, so i am not going to be talking to you for a bit
[16:29] <apw> till i work out what the hell i did
[16:30] <bdmurray> could somebody look at bug 922647 and the ata error messages there?  are those indicative of a hardware problem or maybe a driver?
[16:37] <tgardner> bug #922647
[16:41] <bdmurray> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/992647
[16:41] <ubot2> Launchpad bug 992647 in ubiquity "Problema ao instalar ubunto no HD" [Undecided,New]
[16:42] <apw> bjf, recovered, recursive ssh runes are ... BAD
[16:42] <tgardner> apw, doh !
[16:42] <bjf> heh
[16:43] <apw> load hit 48 before i got it under control, perhaps 20m of paging like a pig
[16:49] <tgardner> bdmurray, what little I've discovered indicates it is a drive issue: http://shadowm.rewound.net/blog/archives/206-Giving-Debian-Wheezy-another-whirl,-and-an-unpleasant-surprise-from-Reicore.html
[16:52] <bdmurray> tgardner: I don't see any media errors in this bug report which is typical for drive issues
[16:52] <tgardner> bdmurray, hell if I know. I'm not skilled at parsing ATA noise
[16:53] <bdmurray> https://ata.wiki.kernel.org/articles/l/i/b/Libata_error_messages.html
[16:55] <tgardner> bdmurray, repeated instances of 'failed command: READ FPDMA QUEUED' followed by 'hard resetting link' don't seem too healthy to me.
[16:55] <bdmurray> tgardner: sure but it continues to report DRDY
[16:56] <bdmurray> the wiki pages mentions 'try booting with 'pci=nomsi' or 'acpi=off' or 'noapic'' for timeouts
[16:56] <bdmurray> maybe I'll have them try that
[16:57] <tgardner> bdmurray, works for me.
[17:13] <JanC> somebody should write a tool to interpret kernel/driver/hardware errors like that...  ;)
[17:14] <JanC> tgardner: I had a drive issuing such "hard resetting link" messages for some time, now it's (almost) dead (but strange enough, SMART never reported anything wrong...)
[17:19] <greearb> It seems that if you have a USB stick in the machine when booting the live-cd, it will not mount that USB stick untill you remove it and re-install it.  Anyone know if there is some tool/script that can cause it to mount w/out physically unplugging/plugging the USB key?
[17:22] <JanC> greearb: you could probably run "sudo udevadm trigger"
[17:22] <JanC> or use mount, udisks, GParted or the udisks GUI frontend
[17:23] <apw> greearb, udisks probabally
[17:23] <greearb> thanks..will try that
[17:23] <JanC> also depending on how you wnat it mounted
[17:23] <greearb> just want it to show up in /media/
[17:25] <JanC> I think the udevadm command will cause the same events as if it were unplugged & replugged
[17:25] <JanC> at least from the GUI apps PoV
[17:37] <greearb> no luck
[19:31] <slangasek> apw: ping
[19:32] <apw> slangasek, hi
[19:32] <slangasek> apw: hey there!  ogasawara was just telling me that aufs was re-enabled in the kernel for precise at the last minute?
[19:33] <slangasek> apw: was the plan for us to use that as the unionfs in precise for the liveCDs?  Because we didn't
[19:33] <apw> slangasek, it was around the betas indeed.  there was concern from the lxc people that they wanted a fallback if they couldn't cope with overlayfs
[19:33] <slangasek> ok
[19:33] <apw> slangasek, we had used overlayfs for all the tested CDs so no not intended that we'd change
[19:33] <slangasek> ah, ok then
[19:34] <apw> as far as i know noone is using aufs for anything
[19:34] <slangasek> so I shouldn't be fretting over this and trying to change it for .1 ;)
[19:34] <apw> i don't think so no
[19:34] <slangasek> ok
[19:34] <slangasek> any chance of overlayfs getting fixed to stop claiming it supports inotify, btw?
[19:34] <slangasek> (wouldn't fix all our liveCD bugs, but it would fix some of them)
[19:35] <apw> slangasek, i made a version which claimed it didn't, userspace didn't like it much vomitting errors everywhere
[19:35] <slangasek> oh, neat
[19:35] <slangasek> so much for that then
[19:35] <apw> overlayfs may get some support for inotify if i get time, but it won't fix anything which uses fstat on already open files
[19:35] <apw> such as tail does
[19:36] <slangasek> mm?  tail prefers to use inotify
[19:36] <slangasek> or is fstat() separately broken?
[19:37] <apw> yes, but it uses a specific combination which doesnt work out
[19:37] <apw> it opens the file, asks for inotify, we tell it the file changed, it fstats the old file, sees the notify was a 'lie' and does nothing
[19:38] <apw> a side effect of the known posix violation that overlayfs has which makes it simple and performant
[19:39] <apw> so none of the calls are broken per-see just the meaning is subtle altereed,  if tail used 'stat' on the pathname it would work just fine with my patches
[19:40] <slangasek> right
[19:40] <apw> obviously not without any working inotify as we have now
[19:40] <apw> i n
[19:40] <slangasek> performance over posix - grr
[19:40] <slangasek> :)
[19:41] <apw> well its less performance and more simpliciyt.  aufs and vfs-union-mounts are massive as a result of having the entire posix implementation
[19:41] <apw> and they can't get into the kernel, somethinig small enough to be acceptable seems to be
[19:41] <apw> fialing cause its not complete enough, its ... a problem
[19:42]  * slangasek nods
[19:43] <apw> if upstream was more helpful in guiding direction rather than just being "ick vile no" to everything we might make some more progress
[19:43] <slangasek> but then you'd be contributing upstream... and we can't have that now can we ;)
[19:59] <apw> slangasek, tsk
[19:59] <apw> slangasek, its a good job the 5 patches i pushed today don't count (at least when we are measured_
[19:59] <slangasek> :-)
[20:24] <bdmurray> jsalisbury: I was looking at ubuntu bugs with the same title by the same reporter the other day
[20:25] <bdmurray> jsalisbury: eg bug 820031 and bug 820040
[20:25] <ubot2> Launchpad bug 820031 in linux "WARNING: at /build/buildd/linux-2.6.38/net/mac80211/rx.c:2881 ieee80211_rx+0xad/0x1d0 [mac80211]()" [Undecided,Incomplete] https://launchpad.net/bugs/820031
[20:25] <ubot2> Launchpad bug 820040 in linux "WARNING: at /build/buildd/linux-2.6.38/net/mac80211/rx.c:2881 ieee80211_rx+0xad/0x1d0 [mac80211]()" [Undecided,Incomplete] https://launchpad.net/bugs/820040
[20:50]  * tgardner -> EOD
[22:12] <bjf> ogasawara: supposedly gomesia is back
[22:13] <bjf> s/gomesia/gomeisa/