[01:16] <pac1> pac1 reads the irclog.
[06:52] <ppisati> moin
[06:58] <tjaalton> hmm, the 3.4 kernel in quantal/precise backport doesn't have any drm modules?
[06:59] <tjaalton> mainline build is fine, drm-next is broken as well
[07:02] <ppisati> wow... we just had another earthquake...
[07:11] <bryceh> o_O
[07:11] <soren> ppisati: Where?
[07:12] <smb> quite a few of them lately
[07:13] <soren> smb: Where?
[07:13] <smb> soren, I meant over there in Italy
[07:13] <ppisati> Italy
[07:13] <soren> O_o
[07:13] <smb> morning, btw
[07:25] <tjaalton> ok, so drm drivers are now in -extra..
[07:35]  * apw yawns ...
[07:43] <apw> tjaalton, for the normal flavours (in quantal) we are experimenting with a split packge; the idea is for the regular flavours you need both, then they can be shared with -virtual
[07:44] <apw> (which only uses the first one)
[07:45] <tjaalton> apw: yeah, only noticed it now :)
[07:45] <tjaalton> so that was the reason why ivb was hanging, it doesn't like vesafb that much
[07:46] <apw> tjaalton, ahh ... yes we more expect people to be using the meta packages
[07:46] <apw> which if they are right pull in both
[07:47] <tjaalton> right, I'm used to installing mainline kernels directly, so tried the same with the quantal one. lesson learned :)
[07:47] <apw> oh interesting, are we generating the extras from mainline, thats lucky :)
[07:48] <tjaalton> no mainline kernels are still fine
[07:48] <tjaalton> aka. monolithic
[07:49] <apw> hmmm that supprises me :)
[07:49] <tjaalton> well, drm-next wasnt' :)
[07:49] <tjaalton> it's split the same way
[07:49] <tjaalton> oh, quantal mainline is split
[07:49] <apw> oh yeah they have split haven't they ... i had better document that :)
[07:53] <apw> done
[07:55] <smb> apw, I think that also causes the cloud images to fail boot on ec2 (well, not the split but the merging of virtual into generic)
[07:55] <apw> smb, ok ... any idea why ?
[07:55] <smb> They used to only add -virtual kernels to the pvgrub. Which now leaves them with... none
[07:55] <apw> oh that is so very ... something
[07:55] <apw> special
[07:56] <smb> heh, yeah, usual fallout
[07:57] <apw> smb, is that something we manage, the -virtual adding thing
[07:58] <smb> apw, Yes, need to talk to scott or ben about it
[07:58] <smb> There is a bug, to which I added a comment
[08:00] <apw> ok cool, sounds under control
[08:01] <smb> yeah should be
[08:02] <smb> saw that bug just yesterday but then did not look closer that to wonder why on earth they tried to boot memtest on a pv guest
[08:10] <apw> its a mystery how that could be any use at alll indeed
[08:11] <smb> apw, he cannot hear us
[08:12] <smb> la la la
[08:12] <apw> i know ... *screams*
[08:13] <smb> apw, killing pulseaudio softly...
[09:38] <jMCg> softly?
[09:40] <smb> Just making it into a reference to a song... normally you then have to kill it harder (pulseaudio -k, killall pulsaudio,...)
[09:51] <jMCg> Please don't use killall, you'll shoot yourself in the foot if you ever move away from Linux ;)
[10:07] <ppisati> brb
[10:15] <pgraner> apw, can you look into this for me: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005832
[10:15] <ubot2> Launchpad bug 1005832 in linux "Intel wifi frequent disconnects" [Undecided,Confirmed]
[10:16] <apw> pgraner, if we have to kill and restart wpa-supplicant to fix it i'd be suspicious of that in the first instance
[10:17] <apw> cyphermox, any insight on the above ^^ 
[10:18] <apw> pgraner, i note that they other reporter has different wifi h/w, so i guess if its kernel its generic
[10:19] <apw> pgraner, what channel are these APs on
[10:20] <apw> pgraner, and have you told your machine you are in .hk ?
[10:23] <apw> pgraner, try "iw reg set HK" .. you may have to remove your iwl driver before it will let you of course
[10:28] <apw> pgraner, added informaion to the bug
[10:30] <pgraner> apw, not seeing anything in the bug
[10:30] <Daviey> Hey, do we know why kexec doesn't work on arm?
[10:35] <ogra_> Daviey, it works at times 
[10:36] <ogra_> an on some arches ... but it always broke after some rebases, version changes etc ... its not completely broken but not very reliable 
[10:36] <apw> pgraner, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1005832/comments/3
[10:36] <ubot2> Launchpad bug 1005832 in linux "Intel wifi frequent disconnects" [Undecided,Confirmed]
[10:38] <ppisati> Daviey: it works UP, broken SMP (last time i tried)
[10:38] <Daviey> ogra_: doesn't seem to work for Panda for me?
[10:38] <ppisati> Daviey: upstream had patches for it, but they just fixed part of it
[10:38] <ppisati> Daviey: didn't try with latest 3.4.x BTW
[10:40] <ogra_> Daviey, eah that underlines what i said :) i know it worked in one (or even more) past releases
[10:41] <Daviey> ogra_ / ppisati : What can be done to make it reliable ?  (nothing at this stage, is OK :
[10:42] <ogra_> Daviey, well, someone would have to constantly test it, someone else would have to constantly fix it if its broken 
[10:42] <ogra_> read: maintenance and testing 
[10:42] <ogra_> :)
[10:43] <ppisati> Daviey: which kernel are you testing?
[10:46]  * ppisati -> run to the kebab...
[10:48] <Daviey> ppisati: tried 3.0 (oneiric), linaro's Oneric and Precise.
[11:17] <ogra_> Daviey, how about the ubuntu precise ?
[11:29] <ppisati> ogra_: up = ok, smp = broken
[11:29] <ppisati> ogra_: they started fixing it in... 3.3? iirc
[11:29] <ppisati> ogra_: i don't know if it's sound in 3.4 either
[11:29] <ogra_> yeah
[11:29] <ogra_> well, UP is at least something :)
[11:30]  * ppisati -> goes to recompile all kernels/flavours UP-only! :)
[11:30] <ppisati> Daviey: do you need O for some particular reason?
[12:16] <smb> apw, Just out of curiosity, when you upgraded your router from lucid to precise, did you also have to use -d with do-release-upgrade? Oh I guess that is part of the "wait a bit until gently pushing people towards the next lts" thing...
[12:16] <apw> smb, yeah you have to override with -d as its not 'ready' yet ... and indeed it isn't :)
[12:17] <smb> apw, Meh, those small issues with dhcp...
[12:17] <ogra_> that will only be switcvhed for the .1 release 
[12:17] <ogra_> (as with all LTS'es)
[12:17] <apw> ogra_, right ... and me doing mine now early is to find the kind of dhcp issue i hit, before the masses do it 
[12:17] <smb> ogra_, That kind of occurred to me the second I typed in the question... :)
[12:17] <ogra_> apw, yeah ++ for that :) 
[12:43] <Benkinooby> hi, here is my story in short: want to turn off laptop backlight for use in bright sun; asked in ubunut, debian, xorg, gentoo, ubunut-devel and now here (in that order); tried the commands 'xset dpms ...'; read https://wiki.kubuntu.org/Kernel/Debugging/Backlight ; inspected file /proc/acpi/video/GFX0/DD04/brightness and found out that my lowest level is 20 (but i guess i want 0); read on at http://powersave.sourceforge.net/powersave/
[12:43] <Benkinooby> DSDT.html ; link th "find a DSDT for your laptop" return 404; now asking here;
[12:44] <Benkinooby> th -> to
[12:44] <Benkinooby> any ideas, help or useful RTFMs?
[12:45] <Daviey> ppisati: no, don't need O.. it was just referencing that i tried it on that.
[12:48] <Benkinooby> ok found "how to fix a buggy DSDT file" http://ubuntuforums.org/showthread.php?t=1036051 ; is it possible to just add a "0" to the supported levels?
[12:51] <ppisati> Daviey: btw, is broken all the way up to 3.4, included
[12:51] <Daviey> nice.
[12:56] <soren> Benkinooby: Turn off backtop for use in bright sun? Seriously?
[12:57] <soren> Er.r..
[12:57] <soren> *backlight
[12:58] <soren> Benkinooby: In your experience, does the screen become easier to read as the brightness increases or as it decreases?
[13:11] <Benkinooby> soren, what i want to do is to use the reflection of the sun as my "backlight"
[13:12] <ogra_> and that works for you ?
[13:12] <apw> Benkinooby, that never worked for me
[13:12] <ogra_> same here 
[13:13] <Benkinooby> ogra_, apw as i understood it some laptops actively employ that mechanism... i don't know if it will work for me, but i'd like to try
[13:14] <apw> Benkinooby, well it should work nearly as well witht eh backlight at its lowest setting
[13:14] <ogra_> yeah
[13:14] <ogra_> 20 should already work then
[13:14] <Benkinooby> ogra_, hm
[13:14] <apw> Benkinooby, and i have never seen one actually made which does that, people have claimed it would be a good idea, and they would do it, but i've never seen one, else i'd own one
[13:15] <ogra_> it might work if you could split the lid in two, so that the back of the LCD gets transparent and light could actually get through
[13:15] <Benkinooby> apw, afaik the OLPC-laptop are capable of doing that... googling for proof on that right now
[13:15] <apw> Benkinooby, i think they said they would do it for the next version, not sure if they did it in any you can get
[13:16] <Benkinooby> http://laptop.org/en/laptop/hardware/specs.shtml
[13:16] <apw> Benkinooby, but even so, even if they did, i know of nothing big enough for my fingers which does it
[13:17] <ogra_> "reflective sunlight-readable monochrome mode"
[13:17] <ogra_> that means it comes with a special black/white mode for use in bright sunlight
[13:18] <ogra_> like an old calculator or LCD wrist watch
[13:18] <ogra_> i doubt there are any normal displays with such a mode on the parket 
[13:18] <ogra_> *market
[13:18] <Benkinooby> ogra_, yeah might be...
[13:18] <Benkinooby> but i was wondering how it would work out for my display
[13:19] <apw> indeed, the co behind the olpc were going to commercialise them, i assume making large ones is too expensice
[13:19] <Benkinooby> to turn off the backlight and see if it will be usable in sunlight
[13:19] <ogra_> it wont, but try yourself with the 20 setting 
[13:19] <apw> Benkinooby, its a differnet technology, the backlight doesn't reduce the displays abilit to use reflected light
[13:19] <ogra_> getting it to 0 will only make it worse
[13:19] <apw> indeed
[13:19] <Benkinooby> ok
[13:19] <Benkinooby> then i'll stick with that
[13:19] <Benkinooby> but for the record:
[13:20] <ogra_> (or get an OLPC) ;)
[13:20] <Benkinooby> do you know if i could disassmebly the DSDT, add "0" to the suported levels and then use the modified one? 
[13:21] <Benkinooby> or hast there to be done further work?
[13:21] <Benkinooby> or maybe for getting it to a lower brightness like 10
[13:22] <Benkinooby> (don't worry i'll stick with the 20 as lowest level - i'm just nosey
[13:25] <Benkinooby> apw
[13:26] <Benkinooby> Benkinooby> do you know if i could disassmebly the DSDT, add "0" to the suported levels and then use the modified one? 
 or hast there to be done further work?
 or maybe for getting it to a lower brightness like 10
 (don't worry i'll stick with the 20 as lowest level - i'm just nosey
[13:26] <Benkinooby> after you left
[13:26] <apw> no changing the DSDT is such a high risk strategy that we do not enable any support for that
[13:26] <apw> you can fry your machine fiddling with it
[13:28] <Benkinooby> ouh... i don't want taht
[13:28] <Benkinooby> *that
[13:31] <ogra_> apw, tsk, you take all the excitement out of computing !
[13:31] <Benkinooby> ogra_, i'm also for excitement in computing... but not on my only productive system :D
[13:32] <ogra_> pffft, no risk, no fun 
[13:37] <Benkinooby> WARNING: This might mess up your operating system. Even if you have zero errors after fixing the DSDT, it may still cause you to not be able to boot your OS. It will not harm your PC or hardware.
[13:37] <Benkinooby> says http://ubuntuforums.org/showthread.php?t=1036051
[13:37] <Benkinooby> it's from 2009 though...
[13:37] <Benkinooby> anyway
[13:37] <Benkinooby> thank you all for your input
[13:37] <Benkinooby> appreciate that
[13:37] <Benkinooby> and say you saved me some "excitement"
[13:37] <apw> heh yeah
[13:37] <Benkinooby> so thanks for that too :D
[13:37] <ogra_> yeah, that warning apparently didnt help so it was disabled in the code 
[13:38] <Benkinooby> what code?
[13:38] <ogra_> whatever was used in the past to upgrade the DSDT
[13:38] <ogra_> iirc there was some code in the initrd
[13:38] <apw> yep, but its been gone since i think before dapper
[13:39] <Benkinooby> UPDATE: The kernel dev's will no longer use the patch to enable custom DSDT files for Karmic 9.10 and beyond. Jaunty 9.04 is the last version this will work on. You are urged to file a bug report for DSDT errors.
[13:39] <Benkinooby> just saw that now
[13:48] <cking> Benkinooby, if you really want to do it (and take the risk if it goes wrong), consult Documentation/acpi/dsdt-override.txt and also http://www.lesswatts.org/projects/acpi/overridingDSDT.php
[13:49] <cking> but we don't support this ;-)
[13:49] <Benkinooby> cking, thank you but i don't think i'll take the risk...
[13:51] <Benkinooby> cking, but sending me these links is like giving a lolly-pop to a child telling it not to eat it XD - maybe i'll find myself an old laptop for toying around with that... so that i can proudly say "i managed to turn off the backlight!"
[13:51] <Benkinooby> cking, thanks for the links :)
[13:52]  * cking still wonders why turning *off* the backlight to work in the sunshine is going to help...
[13:53] <ogra_> cking, wrong assumptions 
[13:53] <Benkinooby> cking, i was already told that it is not of much use ('cept for power save)
[13:53] <ogra_> the referred LCD has an actual monochrome LCD mode that seems to get activated 
[13:53] <Benkinooby> ah, there we go :D
[13:53] <cking> ogra_, first rule of anything with computers is "assume nothing" ;-)
[13:54] <ogra_> indeed :) 
[13:54] <Benkinooby> ogra_, defender of the backlight, destroyer of all excitement
[13:54] <Benkinooby> hehe
[13:54] <ogra_> heh
[13:55] <Benkinooby> ogra_, did you actually do it?
[13:55] <ogra_> did what ?
[13:55] <Benkinooby> turn off the backlight
[13:55] <mjg59> What hardware is this?
[13:56] <ogra_> mjg59, OLPC
[13:56] <Benkinooby> mjg59, http://laptop.org/en/laptop/hardware/specs.shtml
[13:56] <ogra_> http://laptop.org/en/laptop/hardware/specs.shtml talks about "reflective sunlight-readable monochrome mode"
[13:56] <mjg59> The OLPC backlight interface already lets you turn off the screen, doesn't it?
[13:56] <ogra_> so it switches modes to old style backlight-less LCD it seems
[13:57] <Benkinooby> probably
[13:57] <mjg59> Sigh now you've made me actually plug mine in
[13:57] <ogra_> heh
[13:57] <Benkinooby> but i guess in the OLPC case they use that stuff merely for powersave than working in sunlight (although that)
[13:57]  * apw hands mjg59 a pencil sharpener for his fingers
[13:57] <Benkinooby> * that's a nnice sideffect
[13:57] <mjg59> Benkinooby: Both
[13:58] <mjg59> Benkinooby: So you're saying that you have an OLPC that won't let you turn off the backlight?
[13:58] <ogra_> no
[13:58] <ogra_> he has a laptop where he wanted the LCD monochrome mode by setting backlight to 0
[13:58] <ogra_> as i said above, assumptions :) 
[13:59] <mjg59> Oh, I see
[13:59] <Benkinooby> mjg59, just wanted to see the effect... thought it might be something cool (and not dangerous) to do
[13:59] <mjg59> Yeah unless it actually has transflective support, that's not going to work
[13:59] <mjg59> Front lighting will give you nothing on a display that's only designed to be backlit
[13:59] <ogra_> its surely not dangerous to set your backlight to 0 
[14:00] <ogra_> having to hack your DSDT to get from 20 to 0 is dangerous though :) 
[14:00] <cking> well, it's a do-able experiment
[14:01] <Benkinooby> cking, on a non-productive system - which i don't have for now
[14:01] <Benkinooby> also at the moment i lack the sunshine :(
[14:01] <ogra_> why waste time on experiments where you know the outcome in advance ?
[14:01] <cking> ogra_, because you learn 5 other things en-route to discovering it was pointless in the first place
[14:01] <ogra_> heh
[14:02] <Benkinooby> first thing would be possible: listen to those folks on irc
[14:02] <Benkinooby> :P
[14:02] <Benkinooby> second: dammm... my backup is older than 2 months?
[14:03] <Benkinooby> anyway, i'd say case closed
[14:03] <Benkinooby> thank you all (for the third time or so :P )
[14:27] <noOtherOne> Hello, I'm trying to build a 3.4 kernel from vanilla sources (downloaded on kernel.org) and I'm searching for the patches that are applied on the sources for the official Ubuntu kernel (quantal). I searched in the git, but couldn't find any debian/patches directory or something like that. I guess there must be some patches involved, but where can I find them ? thanks in advance for any help !
[14:30] <bjf> noOtherOne: if you just clone our Quantal tree you would get the upstream 3.4 kernel with our patches and our debian directory
[14:31] <cyphermox> apw: pgraner: I'd love to see wpasupplicant debug logs... with what I see in the logs right now, the microcode error and all, I'd be tempted to say it's indeed something with the driver, but the fact that there are many high-signal APs around to roam through probably doesn't help
[14:31] <apw> cyphermox, yeah we always have trouble in these environements
[14:31] <apw> s/these/such
[14:33]  * cyphermox still looking at the syslog
[14:33] <noOtherOne> thanks bjf. I did clone the quantal tree and the debian and debian.master directory are there, but no patches subdirectory. Sorry if I'm stupid here, but does this mean the patches already are applied ?
[14:33] <bjf> noOtherOne: yes the patches are already applied
[14:34] <cyphermox> I should check all the disconnect reason codes there, maybe there's something, but the timeouts sending auth and associating are unusual and not really NM or wpasupplicant so much, I think
[14:35] <noOtherOne> okay, sorry to have bother you with such a silly question ;o) I'm kindy new to this. I guess I'll play with some diff to checkout what has been changed. Thanks again !
[14:36] <cyphermox> apw: I wonder if there aren't too few APs for the number of people, and if this is really showing up a lot more in say, plenaries :)
[14:41] <apw> cyphermox, dunno hard to be sure, i am worried as they are in HK which has differnet and more channels than they can normally use those US peeps
[14:41] <cyphermox> apw: I don't think so, and anyway you won't have much control over it, since this is iwlwifi
[14:41] <cyphermox> the channels used are listed in the bug too
[14:42] <cyphermox> hmm. looks like I'll need to look things up in the standard again :P
[14:43]  * ogasawara back in 20
[14:44] <apw> cyphermox, the channels allowed are listed yes, they are in world domain arn't they?  and i'd expect more channels to be avilable over there
[14:44] <cyphermox> err, I haven't checked if the channels matched the world domain, but I expect they do
[14:44] <sforshee> apw, according to crda the range for HK is slightly broader than that for US
[14:44] <sforshee> but iwlwifi uses it's own internal world domain that seems to cover everything in the HK domain, for 2GHz at least
[14:45] <cyphermox> but if more channels are available, if they're not used it doesn't affect this particular issue
[14:45] <apw> sforshee, right ... thats my worry.  i have the smae problem with one of my laptops which thinks its a US model even though it isn't and we have more channels than the US in the UK
[14:45] <apw> cyphermox, yeah and thats the bit i wasn't sure of, what channels are they using for their APs
[14:45] <sforshee> yeah but that was brcmsmac which has a totally flubbed up regulatory implementation
[14:45] <sforshee> apw, ^
[14:46] <apw> sforshee, yeah there is that, but hey ... who is to say these all have not similar issues
[14:46] <sforshee> if there are APs on frequencies not used by the driver though then the machine just won't see them anyway
[14:46] <sforshee> so the only issue might be overcrowding on those on the other frequencies
[14:47] <sforshee> apw, brcmsmac is special in this regard
[14:47] <apw> "special" :)
[14:47] <sforshee> I'm working on fixing it, so I'm intimately familiar with the details
[14:47] <apw> yeah
[14:48] <sforshee> apw, in dmesg there are "world regulatory domain updated" messages and what follows is a dump of the rules actually being used
[14:48] <sforshee> what I see overlaps nicely with what crda defines for HK
[14:50] <cyphermox> apw: sforshee: I updated pgraner's but with my observations
[14:51] <cyphermox> and if we want even more debug output, maybe NM's wifi debug info could help too; it would say when it's trying to roam and "why"
[14:51] <sforshee> cyphermox, what I've been wondering about is why preauth isn't happening/working
[14:52] <cyphermox> sforshee: re: disconnect reason 2? :)
[14:52] <sforshee> cyphermox, yep. I wonder why that's happening
[14:53] <cyphermox> I wonder if it's not just how WPA works -- you pass it a preshared key, but in reality there has to be some kind of handshaking being done to decide what the real key would be, and changing it every once in a while
[14:53] <cyphermox> if in roaming wpasupplicant tries to pass this key again (since it's the same ESSID), then that will explode.
[14:54] <sforshee> I was thinking though that a STA could remain associated with one AP but go off-channel and get authorized with a different one before disconnecting
[14:54] <cyphermox> maybe it's not wpasupplicant but NM, but AFAIK all NM does is write a config for wpasupplicant with the preshared key
[14:54] <cyphermox> sforshee: I guess it could, but it's not being done?
[14:55] <cyphermox> I'm not familiar enough with the wpasupplicant code to be able to say whether that's implemented without looking
[14:55] <sforshee> cyphermox, me neither. I need to make sure my understanding of preauth is correct, then look at the code to see what it does
[14:56] <cyphermox> sforshee: maybe try with just wpasupplicant to see how well that works
[14:56] <cyphermox> (obviously, that will require moving around more)
[14:57] <sforshee> cyphermox, I don't have an ESS set up in my house though. I may try to reconfigure my equipment later to set one up
[14:57] <cyphermox> ah, I thought you were at linaroconnect
[14:57] <sforshee> but I may not see the same problem since I don't have hundreds of people trying to use my wireless :)
[14:57] <sforshee> cyphermox, nope
[15:04] <apw> tgardner, after a bunch of poking at the pciids it turns out that actually after an upstream merge we will be in sync with debian and the latest ids
[15:05] <tgardner> apw, you're talking about pci-utils ?
[15:05] <apw> pciutils yes
[15:05] <tgardner> ok
[15:06] <tgardner> apw, I usually update it periodically throughout the dev cycle 'cause we stop syncing with upstream
[15:06] <tgardner> about once a month
[15:06] <apw> tgardner, yeah and we'll gain a delta again as soon as we do
[15:07] <tgardner> apw, which is no big deal
[15:07] <apw> indeed
[15:20]  * cking wades through a pile of powertop C++
[15:23] <apw> tgardner, well that was great experience, an hour doing a merge which proved i should do a syncpackage, at least I know how now
[15:24] <tgardner> apw, more lore for the kdev wiki ?
[15:24] <apw> its all so unstructured right now, i am slightly unsure whnat to call it
[15:25] <tgardner> apw, +1 maintenance notes ?
[15:25] <apw> tgardner, hmmm perhaps
[15:25] <cking> packing futzing
[15:25] <cking> oops. packaging
[15:31] <vanhoof> bjf: apw: couple weeks back you mentioned having a smaller team being used for hwe kernels, armadaxp, highbank, at present
[15:31] <vanhoof> bjf: apw: working through a few things release process wise (a checklist
[15:31] <vanhoof> would you prefer a trimmed down team with ike and others who are dealing w/ maintenance on our end?
[15:32] <apw> vanhoof, i don't think we care who is on it, we just want a team as that team will get tasks assigned to them
[15:32] <apw> bjf, ^^
[15:33] <bjf> vanhoof: what apw said
[15:33] <vanhoof> bjf: apw: what team do you guys use now
[15:33] <bjf> vanhoof: looking
[15:33] <vanhoof> i'll make one and keep it tied to the same naming convention (if there is one)
[15:34] <bjf> vanhoof: looks like "ubuntu-armel-kernel" team
[15:34] <bjf> https://launchpad.net/~ubuntu-armel-kernel
[15:34] <vanhoof> bjf: how about ~hwe-arm-kernel
[15:35] <bjf> vanhoof: don't really care
[15:35] <vanhoof> suppose I could use ~canonical-hwe-arm-kernel to keep it tied to our usual names
[15:35] <vanhoof> bjf: ok ~assign-all-work-to-bjf
[15:36]  * vanhoof makes team
[15:38] <vanhoof> bjf: apw: done https://launchpad.net/~canonical-hwe-arm-kernel
[15:50] <bjf> vanhoof, bug 1004556
[15:50] <ubot2> Launchpad bug 1004556 in linux-armadaxp "linux-armadaxp: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1004556
[16:11]  * cking grabs some food
[16:27] <vanhoof> bjf: kick ass, thanks!
[16:37] <smb> ogasawara, tgardner Do you remember whether we announced the going away of -virtual as a kernel binary package somewhere else than the blueprint/spec or maybe our mailing list?
[16:38] <tgardner> smb, are we pissing off the server dudes ?
[16:38] <smb> tgardner, just mildly :)
[16:38] <ogasawara> smb: there were discussions on the kt-ml but no official announcement, no
[16:38] <smb> ok, I guess then I write up something to spread a bit more
[16:39] <ogasawara> smb: however, assuming they were properly using the meta packages, they shouldn't have noticed
[16:39] <apw> smb, and clearly they would send someone to the kernel sessiosn cause they care ... right?
[16:39] <smb> ogasawara, They noticed because preparing the cloud-images involves creating a pvgrub config
[16:40] <smb> apw, Actually I believe I told them, but you know the thing about the two weeks boundary... ;)
[16:41] <smb> ogasawara, and for the pvgrub config only -virtual kernels in /boot were used
[16:46] <ogasawara> smb: I can write up something more official if it'll help and spam it to ubuntu-devel
[16:46] <ogasawara> smb: I'll need to write up a blurb anyways for the Alpha-1 tech overview anyways
[16:47] <smb> ogasawara, Ah, well that works for me too. I was about to write it and send it to you and tgardner for fixing my incoherent thoughts anyway
[16:48] <ogasawara> smb: any other lists you want me to CC?
[16:48] <smb> ogasawara, ubuntu-devel and ubuntu-server probably
[16:48] <ogasawara> smb: ack
[17:12]  * apw moves to his laptop
[17:12]  * henrix will be back in ~30mins
[17:38] <bryceh> tgardner, ogasawara, apw X lts+ pkgs are up
[17:38] <tgardner> bryceh, yep, saw that. ned to do some testing I guess.
[17:38] <apw> bryceh, expect screaming shortly then :)
[17:38] <ogasawara> bryceh: yep, saw it.  am planning to test here shortly.
[17:39] <tgardner> I've got a fungible laptop
[17:51]  * herton -> errand, back in 1h-2h
[20:11]  * tgardner -> EOD
[20:16] <kees> okay, how do I do a git bisect and retain a portion of the tree (like debian or debian.master)?
[20:21] <sforshee> kees, the only thing I see that *might* help is --no-checkout, then I assume you could manually checkout everything else at each step
[20:21] <sforshee> cumbersome, but it might work
[20:22] <kees> sforshee: yeah, hm. I think I might just manually blow away and restore what I need.
[20:22] <sforshee> that's another option :)
[20:22] <kees> the "git bisect run" docs seem to think that's not a totally crazy way to do it
[20:22] <kees> I was wondering if there was a general "pin" mechanism in git, but I can't find it.
[20:22] <sforshee> I'm not aware of anything
[20:23] <ogasawara> kees: maybe git reset <sha1> -- <path> ?
[20:36] <kees> ogasawara: hrm, yeah, I'll try that.
[20:37] <ogasawara> kees: I don't think it'll work, or rather needs some additional options maybe.  I just tried it here and it didn't do what I expected.
[20:39] <kees> ogasawara: okay, noted.
[20:39] <kees> I think I'm going to try to try some kind of hybrid bisect
[20:40] <kees> or just do it by hand. do de do
[20:40] <ogasawara> kees:  what are you bisecting, the mainline kernel but want the debian bits?
[20:41] <kees> ogasawara: I'm bisecting a chromeos kernel, which is almost identical to the ubuntu build system.
[20:41] <kees> the chromeos kernel guys are being slow to respond to my questions. ;)
[20:42] <ogasawara> ah
[20:43] <kees> worst-case, I think I need to identify where the split of mainline happened, keep that series and incrementally apply it to a mainline bisection. trouble is... it'll be like porting the patch sets 50 times. wheee