[07:09]  * smb mornings
[07:17] <ppisati> moin
[07:33] <jMCg> whoowhoo! I just saw my favourite bug is being "confirmed" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/613273
[07:33] <ubot2> Ubuntu bug 613273 in udev "run-init: nuking initramfs contents: directory not empty" [Undecided,Confirmed]
[07:34] <jMCg> I mean, good morning.
[09:03] <apw> $purge_build_directory = 'successful';
[09:03] <apw> $purge_session = 'successful';
[10:27] <ppisati> pristine O/omap4 armel installation on a pandaes, lightdm instead of showing up shows a black screen with a blinking pointer/arrow... xdm works ok...
[10:28] <ppisati> either i forgot to install something (it was a server installation), or lightdm in O/omap4 was broken, or $something else...
[10:28] <ppisati> btw wmaker rocks on it! :)
[10:29] <ppisati> brb
[10:32] <henrix> ppisati: wmaker rocks everywhere :)
[11:32] <ogra_> ppisati, how did you install the desktop parts (it should be impossible to "forget" something, dependencies should care)
[11:54] <ppisati> ogra_: i didn't install ubuntu-desktop
[11:54] <ppisati> ogra_: just some components (xorg, light, wmaker, etcetc)
[11:54] <ogra_> well, that might make you end up without a greeter 
[11:54] <ppisati> i've a greeter
[11:54] <ogra_> which one ?
[11:55] <ppisati> gtk
[11:55] <ogra_> note that there are also prototype greeters as packages
[11:55] <ogra_> but gtk should be ok
[12:45] <tgardner> henrix, pushed lts-backport-natty
[12:45] <henrix> tgardner: ack, thanks
[13:05]  * apw lunches
[13:14] <henrix> tgardner: i've just uploaded the pkg into zinc:~henrix/for-signing
[13:15] <rick1121> Hello. I'm trying to install the broadcom-sta driver module, but it doesn't come with dkms in precise. Can anyone point me in the right direction? Note that bcmwl-kernel-source provides an earlier version of this driver (and it's not what I want). https://launchpad.net/ubuntu/+source/broadcom-sta
[13:16] <tgardner> henrix, rtg@zinc:~/for-signing
[13:16] <henrix> tgardner: cool, thanks
[13:31] <rick1121> How do I go about adding a module that does not have dkms?
[14:35] <pgraner> bjf, sconklin_, the PO for your hw has been acked, being ordered today
[14:36] <sconklin_> \o/
[14:38] <bjf> pgraner: thanks
[14:55]  * ogasawara back in 20
[14:55] <cking> sconklin_, was that the one with the fluke aligator clips?
[14:57] <cking> pgraner, i believe there was a PO outstanding for some fluke multimeter kit that was put in as a request ~7+ months ago. is it possible to get that moving?
[16:16]  * ppisati -> gym
[16:27]  * cking kicks the AP
[16:40] <infinity> apw: Hey, remember when we had conversation over beer that perhaps 3.x.x-ABI-flavour should be replaced with 3.x.x-BUILD-flavour?  Did anything ever come of that when sober?
[16:41] <infinity> apw: Probably needs to happen in tandem with me fixing autoremovals, so we don't bloat machines even worse than we already do, but I have often feared that my running kernel would be replaced with something ABI-compatible-but-non-bootable, and I'd, of course, no longer have a "known-good-kernel" to reboot into.
[16:45] <apw> infinity, yeah, though your stuff should be keeping the old kernels x3 which we should try and make ones we have successfully booted, i wonder if we know that
[16:46] <apw> infinity, though nothing further was reall discussed on it no
[16:46] <infinity> apw: Well, sure, my stuff would, by default, have something older than your running kernel too.  But imagine the fresh install case.
[16:47] <infinity> apw: I do a fresh install, and the next SRU kernel is ABI-compatible, but doesn't work on my hardware.  I have no fallback, cause we just overwrote it.
[16:47] <apw> infinity, we always bump the abi for the first kernel, its is never abi compatible even if it is
[16:47] <apw> for this very reason, that the CD kernel clearly worked, so you always need to keep that one
[16:47] <infinity> apw: Is that true of the first SRU after a point-release too?
[16:48] <apw> infinity, hmmm, now that is a good question, i would say its probabally not in our proceedures but should be
[16:48] <infinity> Still, that sounds like a hackish workflow just to avoid the problem, rather than solving it.
[16:48] <infinity> I'd argue that overwriting kernels is probably never the right answer.  Not now that dkms DTRT for modules, etc, so it's less hassle.
[16:48] <apw> bjf, herton ^^ ... infinity points out that the first kernel update after a point release in an LTS should _also_ be a manditory ABI bump just as the first SRU after release is ... 
[16:49] <apw> infinity, i cannot deny that indeed
[16:49] <apw> ogasawara, we should put discussing this abi issue on our agenda
[16:49] <bjf> apw, i agree and i think that has always been the case. am i mistaken ?
[16:50] <bjf> apw, missed the point, i understand and agree
[16:50] <infinity> bjf: You may not be mistaken, it just came up in idle conversation.
[16:50] <apw> bjf, i don't recall seeing the ABI bump after a .1 release being indicated separatly, but if you interpret the current rule to mean that then all is good for now
[16:50] <bjf> infinity: was thinking of the first sru post release, you are making the point this should be after point releases as well
[16:50] <bjf> and i agree
[16:50] <apw> infinity, ok so lets assume documentation will be updated and proceedures too to do that, and i'll get this discussed when we are together
[16:51] <infinity> bjf: Yeah.  Since what we're trying to avoid is overwriting the kernel that came from installation media.
[16:51] <bjf> roger roger
[16:51] <apw> thanks
[16:51] <bjf> ^ herton, henrix, sconklin
[16:51] <herton> ack
[16:51]  * ogasawara throws it on the agenda
[17:04] <apw> ogasawara, thanks ...
[21:05]  * tgardner -> EOD
[21:28] <manjo> jjohansen, around? do you know how I can build kernel dbgsyms package ? 
[21:32] <manjo> jjohansen, nm got it