[00:13] <manjo> JFo, can you regenerate your top 50 list ?
[00:14] <manjo> JFo, I did a bunch of work but it does not reflect on that list, if You can refresh it, I can see what else I need to look at 
[00:15] <manjo> bjf, in case JFo is out for the day... is this something you have access to ?
[00:17] <ogasawara> manjo: I might be able to run in locally and post the html page, gimme a sec
[00:17] <bjf> manjo, nope
[00:19] <manjo> ogasawara, thanks
[00:19] <manjo> bjf, np
[00:31] <ogasawara> manjo: http://qa.ubuntu.com/reports/ogasawara/tmp/kernel-buglist-top50.html
[00:31] <manjo> ogasawara, thanks
[00:32] <ogasawara> manjo: let me know if that doesn't look correct
[00:32] <manjo> ogasawara, looks good thanks 
[00:50] <JFo> fwiw, it runs every hour
[00:50] <JFo> so it will refresh every hour
[03:13] <fbond> Hi, the linux-input maintainer is ignoring my patch. Does Ubuntu have any interest in it? https://patchwork.kernel.org/patch/102708/
[03:14] <fbond> I'm not sure if there's something more appropriate for me to do with it.  If there is, I'd appreciate advice.
[03:14] <fbond> E-mailing Linus seems like a rocky proposition. ;)
[03:15] <fbond> The patch may very well be bone-headed.  I'm just trying to get it submitted to help out folks with that hardware.
[03:15] <fbond> It seems that no good deed goes unpunished.
[03:19] <RAOF> Hm.  That looks like you've pinged at appropriate intervals.
[03:20] <RAOF> I'm not familiar with the input side of the kernel, though, so I'm not sure what secret handshakes, if any, are expected.
[03:21] <fbond> RAOF: Yeah, I've never dealt with linux-input before.
[03:40] <fbond> RAOF: I'm not sure if perhaps the issue is that I mentioned that the device manufacturer recommends the fix; perhaps
[03:40] <fbond> that introduces copyright concerns?
[03:40] <RAOF> No.  That patch is too small to be copyrightable.
[03:40] <fbond> That's what I figured.
[03:41] <fbond> RAOF: Is it something I should submit to ubuntu-kernel?
[03:41] <fbond> Or is that useless given upstream's disposition?
[03:42] <RAOF> You could bring it to the list.  I don't think that we're likely to apply it without some indication that it'll go upstream, but perhaps someone on the ML will know the secret handshake.
[03:43] <fbond> RAOF: Okay, thanks.
[04:28] <achiang> fbond: dmitry can be... unresponsive at time
[04:28] <achiang> s
[04:28] <achiang> fbond: did you cc him directly?
[04:29] <fbond> achiang: Yes, my last message was sent directly to him.
[04:30] <achiang> fbond: yeah, i've had a really hard time in the past getting dmitry to respond. i'd say ping again, direct mail + public list Ccs?
[04:30] <achiang> fbond: sorry, not very helpful, i know
[04:32] <fbond> achiang: Oh, wait ... I sent it to Jiri.
[04:32] <fbond> Who's dmitry?
[04:32] <achiang> fbond: dmitry torokhov is the input maintainer
[04:32] <achiang> erm, not sure i got the spelling right
[04:33] <fbond> achiang: Jiri is listed as the HID CORE LAYER maintainer.
[04:33] <fbond> I guess hid-input.c changes should go to dmitry?
[04:33]  * achiang reads patch again
[04:35] <achiang> fbond: sorry, you are right, i saw "input" and thought dmitry. jkosina is indeed the correct maintainer
[04:35] <fbond> achiang: No problem.  Any help is welcome.
[04:35] <achiang> fbond: pinging jiri on irc now, give me a sec
[04:36] <fbond> achiang: Oh, thanks.
[04:36] <achiang> fbond: it's entirely possible that he's on holiday too. how long did you wait between the mails?
[04:36] <achiang> oh wow
[04:36] <achiang> a long time
[04:36] <fbond> Yeah. ;)
[04:36] <achiang> well, between 7/8 and today is only 4 days
[04:36] <fbond> Although I only sent mail to him directly once.
[04:36] <fbond> True.
[04:37] <achiang> you know europeans, with their 26 weeks of holiday per year... ;)
[04:38] <fbond> achiang: Ah, yes, I've heard of this before. ;)
[08:15] <smb> morning
[08:19] <cooloney> smb: morning, man
[08:19] <cooloney> i've pinged GrueMaster to test the security updates for fsl-imx51
[08:19] <smb> cooloney, Ok, cool
[08:20] <cooloney> smb: will you bring beer to prague this time? haha
[08:21] <smb> cooloney, I generally just send the mails your and ericm|ubuntu 's way as sort of fsl and mvl authorities. Sorry man, I am flying. :-P
[08:21] <smb> Anyway it would be wasted anyway. Theirs is good and cheap
[08:22] <ericm|ubuntu> smb, ok
[08:28] <cooloney> smb: no problem, German beer is always good
[09:09] <kraut> moin
[10:07] <smb> RAOF, Are you around?
[10:50] <TeTeT> smb: might you be available for some help with building a kernel in a PPA tomorrow? I've tried now several times and always failed with the ABI. I now copied older ABIs to the most recent kernel name and wonder if that helps. Just in case it doesn't, would you be available?
[10:52] <smb> TeTeT, I guess I should be available. Give me a sec, maybe we got a page that is helpful
[10:52] <TeTeT> smb: I found the kernel for idiots page already :)
[10:53] <TeTeT> smb: it has been very helpful so far
[10:53] <smb> TeTeT, That is good. but there is one where we documented abi check avoidance
[10:53] <maxb> TeTeT: kernel for idiots? link please? :-)
[10:53] <smb> https://wiki.ubuntu.com/KernelTeam/KernelForIdiots
[10:54] <TeTeT> maxb: ^
[10:54] <TeTeT> thx smb
[10:54]  * maxb bookmarks
[10:54] <smb> TeTeT, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI
[10:55] <smb> TeTeT, I would think option 2. for ABI and modules would be what you want
[10:56] <TeTeT> smb: ok, if my new build fails I'll try it tomorrow
[10:57] <TeTeT> smb: problem is I'm on the road and only have UMTS for new uploads, otherwise I'd parallelize it
[10:57] <smb> TeTeT, I will be around. If you can have things in a place I can access them
[10:57] <TeTeT> smb: I'll place the needed patch on chinstrap if need be, thanks
[10:58] <smb> TeTeT, It might be worth having your repo pushed to zinc and do the upload and packaging there
[10:59] <TeTeT> smb: it's really only a patch, for the Esprimo E bug, 586325
[10:59] <smb> bug 586325
[10:59] <ubot2> Launchpad bug 586325 in linux (Ubuntu) (and 1 other project) "[i965q] Fujitsu Siemens Esprimo E: changing resolution results in non working X (affects: 1) (heat: 88)" [Medium,Confirmed] https://launchpad.net/bugs/586325
[10:59] <TeTeT> smb: customer wants a production kernel before the SRU lands, so they can do their roll out in time
[11:00] <smb> TeTeT, Ok, They just should be aware to be careful with updates until a fix is really in updates
[11:03] <TeTeT> smb: agreed, but they run their own repo - I'll tell them to not sync kernel updates until the patch made it into mainline
[11:04] <smb> TeTeT, Ok then
[11:04] <ShapeShifter499> hi
[11:04] <ShapeShifter499> I'm tryin to install the e100 driver with no luck via the "make install" command any help?
[11:08] <apw> ShapeShifter499, as in modifying an ubuntu version?
[11:10] <ShapeShifter499> well I don't know....I'm trying to get my ethernet port working, currently wifi is only working
[11:10] <apw> so where are you getting the source code you are trying to install from
[11:10] <ShapeShifter499> I'm getting the source from intel's website
[11:11] <apw> ShapeShifter499, which release kernel are you trying to add it to
[11:14] <ShapeShifter499> no wait....
[11:14] <ShapeShifter499> e100 is all ready on my system
[11:14] <ShapeShifter499> it just wasn't being loaded for some reason
[11:15] <ShapeShifter499> just got it up and running via modprobe 
[11:15] <ShapeShifter499> brb just need to test the port
[11:28] <ShapeShifter499> eh its not working
[11:28] <ShapeShifter499> but I g2g bye
[12:48] <TeTeT> smb-afk: my PPA will fail again, see https://pastebin.canonical.com/34554/ and https://pastebin.canonical.com/34555/ for the contents of the abi directory. I'll send you the patch now
[13:41] <smb> TeTeT, Is it possible for you to have a differently name PPA or are there other packages already there that require you to keep it? I am asking because you started to upload with a incremented ABI number which I rather would avoid. But I you have to stick to that PPA we cannot go back
[13:42] <TeTeT> smb: I can simply erase all packages there, no problem. or even delete the PPA and start from scratch
[13:43] <smb> TeTeT, I believe deleting the packages does not help against needing incremental numbers. But if you can use a different PPA I can create a src package for you with the numbering being better (at least IMO)
[13:45] <TeTeT> smb: that would be great. I called the first package I tried 2.6.32-24~lvm0, but it did not build. Can you simply put any PPA in place and upload the src there so it builds? I really only need the resulting PAE package and headers, not much else
[13:46] <apw> smb, i think if you delete and then wait 'long enough' a ppa can at least have stuff which is only newer than the archive
[13:46] <smb> TeTeT, i would place a srcpkg on zinc for you to sign. You can copy it and then use debsign -r for that and then upload from zinc
[13:47] <smb> apw, Hm ok. In most cases I did not wait long enough then
[13:47] <TeTeT> smb: do I have access to zinc?
[13:47] <smb> TeTeT, The version number you used seems to miss the upload number so that would not work
[13:47] <smb> TeTeT, Hm maybe not. Maybe upload from chinstrap works the same
[13:48] <TeTeT> smb: ok, I guess I did something wrong
[13:52] <smb> TeTeT, I would usually use a version number like 2.6.32-24.38+xxx
[13:56] <apw> smb, know anything about WPA/WPA2 support ... and whether there is card support required for them ?
[13:57] <smb> apw, Not really much. I think you would need card support for it done in hw but the wpa_supplicant would do it otherwise. But that might be wrong
[13:58] <TeTeT> smb: the + to make it newer? So far I used ~ to make it smaller
[13:59] <smb> TeTeT, Yeah, depends what you base version is. As I base the package on 2.6.32-24.38 it is sort of newer. If I'd use 2.6.32-24.39 it would need to be smaller
[14:41] <smb> apw, tgardner 15m until TB meeting
[14:42] <tgardner> smb, ack
[14:45] <tgardner> apw, did anyone ever take a serious stab at getting psurbhi's async rootfs/boot patches upstream?
[14:45] <psurbhi> apw, have you sent your patch upstream?
[14:46] <apw> tgardner, psurbhi, that is on my list of things to do ... i noticed they have a couple of warnings which need cleaning up in them
[14:46] <apw> perhaps i'll do that at sprint, as we'll be off the grid
[14:47] <psurbhi> apw, thanks :)
[14:47] <apw> psurbhi, yeah they need to go as a set as they don't make sense without so i'll do them together if that works for you ... obviously your signoffs are on your ones
[14:47] <psurbhi> apw, yes sure it does :)
[15:01] <hrw> hi
[15:01] <hrw> apw: any suggestions to patch from bug 603087 (stage1 support)?
[15:01] <ubot2> Launchpad bug 603087 in linux (Ubuntu) "Allow to build just linux-libc-dev (affects: 1) (heat: 12)" [Wishlist,In progress] https://launchpad.net/bugs/603087
[15:14]  * ogra wonders if tgardner's recent ureadahead fix in lucid might be the magical fix for Bug 600359 ... somehow smells related
[15:14] <ubot2> Launchpad bug 600359 in ureadahead (Ubuntu Maverick) (and 1 other project) "ureadahead generating oom messages during boot. (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/600359
[16:03] <bjf> ##
[16:03] <bjf> ## Kernel team meeting in two hours
[16:03] <bjf> ##
[16:06]  * abogani waves After Zinc upgrade I receive this error (http://paste.ubuntu.com/462958/) pushing new stuff into my git tress. Is it something which I should care?
[16:06] <apw> abogani, you need to mark that as a bare repo on zinc ... bare = true in config
[16:07] <tgardner> abogani, the new git version complains if you don't have a bare repository.
[16:07] <smb> Depending whether it is a bare repo
[16:07] <smb> You also could have one with a working tree, and then would need to set that config mentioned
[16:11] <manjo> sconklin, iirc you made a presentation about video at one of the sprints, where can I start learning about video?
[16:11] <manjo> sconklin, if you can point me in the right dir ... very much appreciated 
[16:12] <sconklin> manjo: let me look. That was based on the years I spent writing device drivers, I'm not sure where you could get a good overview of the whole pipeline.
[16:15] <abogani> apw, tgardner, smb: Thanks!
[16:15] <manjo> sconklin, thanks. wish I had made notes that day :)
[16:15] <achiang> fbond: just pinged jiri; our theory that he was on holiday was correct
[16:15] <achiang> fbond: he said he'll get around to processing his backlog "soonish" after responding to his inbox
[16:15] <fbond> achiang: Ah, okay, thanks.
[16:16] <sconklin> manjo: all the stuff I talked about is interesting, but mostly not related to the parts of the linux drivers that cause the most pain. Still, it's useful to know in general how things work
[16:24] <smb> TeTeT, Ok, source package parts are now in my home dir on chinstrap for you to copy, resign and upload. I believe with the right config there you can directly upload from there
[16:28] <manjo> tgardner, I think its bzr launchpad-login
[16:31] <TeTeT> smb: thanks, let me see how far I get
[16:35] <TeTeT> smb: would you happen to know how resign the packages on chinstrap? debsign is not installed on chinstrap
[16:36] <smb> TeTeT, You likely want to use debsign -r from you local machine
[16:36] <smb> That downloads only the .dsc and changes
[16:36] <smb> TeTeT, debsign -k<yourkey> -r <host>/<dir>/*.changes
[16:37] <TeTeT> smb: ok, giving it a try
[16:38] <smb> TeTeT, Actually debsign -k<yourkey> -r <host>:<dir>/*.changes
[16:43] <tgardner> apw, bzr: ERROR: Cannot lock LockDir(lp-70455952:///~scott/ureadahead/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
[16:45] <ogra> tgardner, its owned by Keybuk accroding to the URL
[16:45] <ogra> i'd create my oen branch and file a merge request
[16:45] <ogra> *own
[16:46] <ogra> if there isnt an ubuntu-core-dev one
[16:47] <tgardner> ogra, yeah, I've just followed that route
[16:48] <ogra> though i wonder, is that the branch thats mentioned in debian/control ? 
[16:48] <ogra> it should point to a public one
[16:51] <tgardner> ogra, its a bit weird because ureadahead is the upstream repository and is not a debian package
[16:52] <ogra> yeah
[16:52] <ogra> the branch should be ubuntu-core-dev owned 
[16:52] <apw> ogra, isn't that the packaging branch .... which should be
[16:52] <apw> including the debian directory
[16:52] <ogra> looking at debian/copyright and debian/control it doesnt even mention any upstream location
[16:53] <ogra> bad bad Keybuk !
[16:53] <ogra> apw, we dont separate upstream development and debian branches anymore for native ubuntu packages
[16:54] <apw> ogra, what about packages which arn't just native ubuntu packages
[16:54] <ogra> things like casper, livecd-rootfs etc that are native ubuntu stuff usually have the debian dir included
[16:54] <apw> ie ones like upstart which are in debian as well but not sync'd
[16:54] <ogra> for these you usually have two branches, yeah
[16:55] <apw> so i think thats what he has here, an ubuntu packaging one, which he merges this one into
[16:55] <ogra> either way copyright and/or control should mention the actual upstream location
[16:55] <apw> i think ... not htat i have a clue how you'd find it should you need to update it if he was away
[16:55] <apw> indeeed
[16:56] <ogra> ogra@osiris:~/Devel/branches/jasper-initramfs$ grep Bzr debian/*
[16:56] <ogra> debian/control:Vcs-Bzr: lp:jasper-initramfs
[16:56] <ogra> thats the usual way to point to an upstream source
[16:56] <apw> ogra, yep but which one, the upstream upstream, or the one with the debian packaging
[16:56] <ogra> depends 
[16:57] <apw> see and therein lies the uslessness of the thing ... we cannot ever find the right branch even if its listed
[16:57] <ogra> jasper for example carries the debian dir in it 
[16:57] <ogra> (my above example)
[16:57] <ogra> it isnt usable without images built in the ubuntu infrastructure
[16:58] <ogra> for rootstock where i'm upstream upstream i have a separate packaging branch, and no Vcs-Bzr: in control, but the location of the upstream branch in copyright
[16:59] <apw> ogra, i wonder if it is allowed to have two in there, that would make some sense
[16:59] <apw> pointing to both the packaing and the code branches
[16:59] <ogra> sure
[16:59] <ogra> you can do that, i think they are different Vcs-Bzr tags 
[17:04] <TeTeT> smb: uploaded the sources to a new PPA, thanks! fought a little bit with dput on chinstrap :) will report to you tomorrow if the build run well, going to the hotel now
[17:18] <ogasawara> JFo: I just realized you have an ubuntu dev week session tomorrow on kernel triage
[17:18] <JFo> yep
[17:18] <JFo> :)
[17:19] <apw> jfo what time is that going on ?
[17:19] <smb> JFo, And there is a kernel bug day?
[17:19] <JFo> planned to go over the new tagging scheme etc
[17:19] <JFo> smb, indeed
[17:19] <smb> JFo, Btw, can you add that to kernel-team calendar?
[17:19] <JFo> smb, I can indeed
[17:19] <apw> JFo, presenting the "triage levels 1-3" ?
[17:19]  * JFo digs the time up for apw
[17:19] <smb> JFo, Thanks :)
[17:19]  * apw cracks the whip
[17:20] <JFo> apw, looks like 9PM your time
[17:20] <apw> gah
[17:20] <JFo> it is 4PM EST
[17:20]  * JFo adds the triage session to the kernel cal
[17:20] <smb> Definitely beer o clock my time
[17:21] <apw> JFo, then you'll have to hastle other kernel peeps to keep you company!
[17:21] <JFo> no sweat apw
[17:22] <JFo> I hadn't actually planned to pester you guys
[17:22] <JFo> I think I have more than enough to discuss :)
[17:22] <JFo> plus I gave an intro to the kernel on Saturday
[17:22] <JFo> for Ubuntu User Days
[17:23] <JFo> k smb, it should be there now
[17:25] <smb> JFo, The triage session is. Though I am sorry to have been unclear (that one is good too) but there was aksing to have the kernel team bug day effort there as well to remind people
[17:25] <JFo> oh hah! :)
[17:25] <JFo> I'll add that too :)
[17:25] <smb> JFo, Many thank yous :)
[17:26] <JFo> my pleasure
[17:27] <bjf> JFo, when do you take off for prague?
[17:28] <bjf> ##
[17:28] <bjf> ## Kernel team meeting in 30 minutes
[17:28] <bjf> ##
[17:28] <JFo> I'm leaving Thursday morning for Dallas to hit a meeting, then leaving Friday for Prague
[17:28] <smb> poor meeting
[17:29] <ogasawara> heh
[17:29] <JFo> ogasawara, is the kernel bug day showing up right for you on the cal?
[17:29] <JFo> smb :-P
[17:29] <smb> JFo, Its showing on mine. Thanks
[17:29] <JFo> should be 8 AM
[17:29] <JFo> cool sm
[17:29] <JFo> err smb
[17:29] <bjf> JFo, so you get into prague Saturday and have a intro to the kernel meeting that day
[17:29] <ogasawara> JFo: yep, showing 8am-11am for me
[17:29]  * smb feels a bit sm
[17:29] <JFo> no, the intro was this past sat bjf, sorry for the confusion
[17:29] <JFo> ogasawara, cool
[17:30] <JFo> smb, heh :)
[17:30] <bjf> JFo, was thinking you were more insane than usual
[17:30] <JFo> oh no, no more... no less
[17:30] <JFo> :-D
[17:30] <JFo> heading to CLT tomorrow since my flight on Thursday is early
[17:44] <simar> JFo, Hi i have been working on triaging bugs related to touchpad xserver-xorg-input-synaptics. I have folowed your class in Ubuntu OPen week but now don't know where to start. I know how to package but where should i start and what should i do now??
[17:44] <JFo> simar, have you read the wiki documentation we have so far on bug triage?
[17:44]  * JFo gets the link
[17:45] <JFo> simar, these pages https://wiki.ubuntu.com/Kernel/BugTriage ?
[17:45] <JFo> keep in mind that they are being reworked so they may not be complete as yet
[17:45] <simar> JFo, I have not but i will that by tomorrow ..
[17:45] <JFo> cool
[17:45] <JFo> let me know if yo uhave questions as you read :)
[17:46] <JFo> or if something makes no sense
[17:46] <JFo> I want to get them as clear as possible
[17:46] <JFo> thanks simar :)
[17:46] <simar> JFo, Ok
[17:47] <JFo> simar, we are about to have our weekly meeting in #ubuntu-meeting. You are welcome to join us and see what all we discuss in these meetings
[17:47] <JFo> if you are interested, that is
[17:48] <simar> JFo, Now i can really see a way to contribute ... I hope so :)
[17:48] <JFo> I hope so too :)
[17:50] <simar> JFo, one general question. Is there any diagnose tool that can display information right from touchpad ie from the kernel driver in 'as is' form , when i produce events like touch .. currently what i know of is evtest?
[17:51] <JFo> simar, the best person to talk to would be cnd, but I don't know off the top of my head :)
[17:53] <simar> JFo, ok, so should i ask him now?
[17:53] <simar> JFo, i think he's online
[17:53] <JFo> well, it is entirely likely that he is busy
[17:53] <JFo> as he does a lot of hardware work
[17:53] <JFo> it may be a better idea to send an e-mail to the kernel list and ask there.
[17:54] <JFo> that way he can answer as he gets the time
[17:54] <sconklin> severe tstorms here, if I drop that's why
[17:54] <JFo> k, keep the grounding rod handy sconklin :)
[17:56] <simar> JFo, thanks i see some more ways ..
[17:56] <JFo> cool :)
[17:56] <simar> JFo, I 'm already joined the kernel mailing list ..
[17:56] <simar> :P
[17:56] <JFo> excellent! :)
[17:57] <simar> JFo, thanks.. 
[17:57] <JFo> my pleasure
[17:57] <cnd> simar, I can answer here
[17:58] <simar> cnd thanks
[17:58] <bjf> ##
[17:58] <bjf> ## Meeting about to start
[17:58] <bjf> ##
[17:59] <simar> cnd  Is there any diagnose tool that can display information right from touchpad ie from the kernel driver in 'as is' form , when i produce events like touch .. currently what i know of is evtest?
[17:59] <cnd> simar, yes, I use evtest for that purpose
[18:00] <simar> cnd but it doesn't do it in a live manner .. like xev do for x drivers
[18:00] <cnd> simar, I'm not sure what you mean
[18:00] <cnd> when I use it, I touch on the touchpad and I get events spit out
[18:03] <simar> cnd actually i get some properties and in the end theres a message Testing ... (interrupt to exit) . I want to use it for touchpad ..
[18:03] <cnd> simar, what kind of device is it?
[18:04] <cnd> some of the x drivers lock the evdev interface from the kernel
[18:04] <cnd> if you jump to another VT you should be able to see events for those devices
[18:05] <simar> cnd, sorry i dinn't get VT
[18:05] <simar> cnd synaptics touchpad .. I want to fix the multitouch support which is not recognised by kernel . it shows SYnaptics Capabilities 10100 ..
[18:06] <simar> cnd though it is multitouch capable . There are a lot of bugs filed about this always ...
[18:07] <cnd> simar, to switch to a different VT, use ctrl+alt+<number>
[18:07] <cnd> X normally resides on VT 7
[18:07] <ogra> depends how insane your distro is :)
[18:08] <ogra> (some use vt1 nowadays )
[18:08]  * cnd hopes simar isn't trapped in another VT and can't find his way back :)
[18:09] <ogra> maps.google.com ;)
[18:11] <simar> cnd is still dinn't get it. Seems to be something new for me . I will google it . You could resume with your imp work and thanks for your generous support ...
[18:11] <cnd> simar, np
[18:13] <simar> cnd, thanks again
[18:18]  * JFo goes to grab grub.
[18:31] <bjf> lag, if you'd use "*" instead of "-" for your status, i'd appreciate it, that makes it a straight cut and paste for me
[18:32] <smb> bjf, Maybe I should convert to that too
[18:32] <bjf> smb, there is no hope for your status :-)
[18:33] <smb> :-P
[18:33] <bjf> smb, if you can make it look reasonable in moin that would be fantastic, but don't go to any great effort
[18:33] <smb> Lets see for next time
[18:34] <apw> bjf do you have a table conversion in your scripting ?
[18:34] <apw> smb's stuff is essentially a table, but || ppo || bar || is very ugly
[18:34] <bjf> apw, been working on one, so yes, partial
[18:34] <apw> though i guess as long as he spaces it out nicely it would look ok on here
[18:34] <smb> Well I should be able to make it directly into one
[18:35] <apw> || karmic          || v2.6.32-rc1       || 5 pending ||
[18:35] <bjf> apw, right, needs to look sane in text, convertible to moin and convertible again to html (for blog)
[18:35] <apw> gah ... bibble, to hard
[18:36] <bjf> the sane in text is just for the meeting, if you've noticed the email i send out it's straight moin and I don't care how it looks :-)
[18:37] <bjf> so if you can make it moin, that doesn't look too bad in the meeting, that's fantastic for me
[18:37] <apw> yeah i recon a moin table, but with the internal spacing so it lines up in IRC
[18:42] <lag> bjf: No problem
[18:42] <bjf> lag, thanks
[18:43]  * manjo getting lunch will be back soon
[18:54] <NCommander> Ping, is there anyone around who can help sort out kernels with marvell? I need to upload the latest SRU kernel to maverick to use as a base
[19:03] <NCommander> pgraner: ping, do you have any objections if we copy the lucid SRU kernel to maverick?
[19:11] <ripps> The wacom driver in the kernel is out of date. I made a dkms package that builds a new wacom module from upstream using dkms, but when I tried to submit the package to debian, they said that I was just working around the kernel development process. Does anybody know how I can patch the kernel wacom source to new version?
[19:11] <ripps> The new module is needed for the Wacom Bamboo Pen & Touch models to work.
[19:14] <apw> NCommander, which kernel what ?
[19:14] <apw> smb, ^^
[19:15] <smb> apw, Don't know what is in Maverick (mlv-dove wise)
[19:16] <NCommander> apw: smb: lucid release kernel :-/
[19:19] <apw> NCommander, you proposing a pocket copy ?
[19:19] <NCommander> apw: yeah, from lucid-updates -> maverick
[19:20] <apw> NCommander, are we expecting a kernel update for mvl-dove before release ?
[19:20] <apw> as .32 is damn far behind userspace
[19:21] <apw> NCommander, as we already have a .32 kernel in maverick and the one you are proposing to copy is at least better security wise it doens't seem like a bad idea.  i don't think we can make any guarentees about it working with maverick userspace though
[19:21] <smb> As the current mvl-dove for Maverick is a pocket-copy either, I cannot see much harm
[19:22] <NCommander> apw: that's fine, I'll hold onto both pieces should they break in two
[19:22] <NCommander> :-)
[19:22] <apw> NCommander, but tell me there is a plan to update the kernel
[19:22] <NCommander> apw: there is a plan being planned
[20:00] <apw> jjohansen, yo ... did that AA push go out
[20:02] <jjohansen> not yet been doing the server team meeting
[20:02] <apw> ahhh doh :)
[20:12] <apw> smb, http://people.canonical.com/~apw/misc/fbcon-handoff2.ogv
[20:14] <smb> apw, Looks quite smooth and a nice addon effect seems to be to retain messages on the vt that were there on boot
[20:14] <apw> right, as they really are there on the VT its just not updated
[20:15] <apw> and that is why they dissappear ... cause we switch to VT7 which doesn't have them
[20:15] <smb> right
[20:29] <jjohansen> -> Lunch with kids
[20:29] <JFo> enjoy :)
[20:34]  * ogasawara lunch
[20:34] <JFo> ^^ with kid ;)
[20:47] <manjo> JFo, can you add the bug mumble tomorrow to our calendar ?
[20:48] <JFo> bug mumble?
[20:48] <manjo> bug review that we are supposed to have tomorrow morning ?
[20:52] <JFo> oh, it isn't a bug review
[20:52] <JFo> and it is already on the calendar
[20:52] <JFo> it is a Team bug day
[20:52] <JFo> for about 3 hours in the channel here
[23:37] <kees> ogasawara: are you back this week?
[23:37] <ogasawara> kees: yep
[23:39] <kees> ogasawara: cool.  I sent https://lists.ubuntu.com/archives/kernel-team/2010-July/011633.html earlier today, but I've since added another patch on top of those for another bug.  Should I send a separate pull request, or will you pull everything since 78e9e77809943546ba9db28bfacce07ecfaecfe0 in that tree anyway?
[23:40] <ogasawara> kees: I can just pull everything since 78e9e77
[23:41] <ogasawara> kees: I'd actually already pulled the first two patches, so I'll just pull the last one you've added
[23:41] <kees> ogasawara: okay, cool, sounds good.  I'll leave that tree alone now.  ah, perfect, thanks.