[08:15]  * apw yawns
[08:53]  * smb crawls out of the first bath in new email.
[08:54] <apw> smb, heh fun
[11:31] <smallfoot-> im using ubuntu 10.10 "maverick", does the 2.6.38-999 kernel from the kernel-ppa work?
[12:29] <ogra> apw, around ?
[12:30] <ogra> did you drop linux-headers-2.6.32-410-dove from the archive (my images fail to build not finding that package, if you removed it the meta needs to go too)
[13:28] <smb> ogra, apw had to leave for some plumbing emergency. It will be a bit till he is back
[13:30] <ogra> smb, hmm, do you know anything about the dove kernels by chance ?
[13:30] <tgardner> ogra, didn't GrueMaster test both of the recent dove uploads?
[13:31] <smb> ogra, I have not followed closely. tgardner did you do stuff there by chance? Otherwise I can try to check on the status
[13:31] <ogra> tgardner, there shouldnt be any dove uploads in natty
[13:31] <tgardner> ogra, true. in fact I've requested that dove be removed from the archive for natty
[13:31] <ogra> tgardner, the point is that apparently the dove headers are gone from the archive 
[13:31] <ogra> tgardner, but the meta seems to be still there
[13:32] <tgardner> ogra, ok, I'll see that the meta gets removed as well
[13:32] <ogra> all header metas get installed during image builds on arm and the unwanted onse get removed at the end 
[13:33] <ogra> so one broken meta breaks all images 
[13:33] <tgardner> that seems an odd way of doing things. however, there is a bug open to remove the kernels, so I'll just add the meta package to it
[13:34] <tgardner> back in a a sec...
[13:34] <ogra> its a "bug/feature" of the seed management
[13:34] <ogra> tasks and seeds dont understand subarches, thesy can only operate on toplevel (i.e. armel but not armel+omap)
[13:43] <smb> tgardner, cking Maybe you are better at remembering things than me. I just stumbled indirectly over those acpi_skip_timer_override quirks that manjo had been  submitted for Maverick. Were those not intended to go upstream?
[13:44] <yodog> !ops
[13:44] <ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
[13:44] <yodog> !ops
[13:44] <yodog> !join #xubuntu
[13:44] <ubot2> Factoid 'join #xubuntu' not found
[13:46] <yodog> !ops
[13:46] <ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
[13:46] <yodog> !ops
[13:47] <cking> smb, dunno - were they upstream worthy?
[13:47] <mjg59> smb: The ones for the Lenovos? The problem got root-caused.
[13:47] <smb> mjg59, Ah, yes. Those I guess
[13:48] <yodog> !opsnigga nigga 
[13:48] <ubot2> Factoid 'opsnigga nigga' not found
[13:48] <yodog> !ops
[13:48] <ubot2> Help! lamont, zul, T-Bone, mdz, or jdub
[13:48] <tsimpson> eh..
[13:49] <smb> mjg59, Now, sorry for possibly being dense. Does 'root-caused' mean solved better or something else?
[13:49] <tsimpson> though he has a dynamic IP, so probably won't last long
[13:50] <mjg59> smb: The problem turned out to be that the apic timer was marked with the wrong polarity
[13:50] <smb> mjg59, Ahhhh, that ring s a bell
[13:50] <mjg59> smb: So the initial interrupt got missed. The skip_timer_override quirk just resulted in it being tied to a pin with the right polarity, so it worked
[13:50] <mjg59> smb: But checking the polarity is a more generic fix than just hardcoding some model names, so that's what upstream went with
[13:51] <smb> So we actually should get that fix in then we should be able to revert the other quirks from Maverick
[13:51] <mjg59> Right, though it may be a bit more intrusive?
[13:53] <smb> That could be (have to check for the other patch). Just looked at someone asking for yet another model added to the quirks, so the question is what is the lesser evil
[13:53] <mjg59> Ah, ok
[13:55] <cking> mjg59, is the wrong polarity marked on APIC timers a configuration bug in the firmware?
[13:56] <mjg59> cking: Yeah, though my recollection is that Windows never uses this configuration
[13:56] <mjg59> So it'd be easy to miss
[13:56] <cking> but easy to test for?
[13:56] <mjg59> cking: There's some details in the thread on lkml
[13:56] <cking> ok - me will look
[13:56]  * tgardner detects another test for fwts in the making
[13:57] <cking> yep - when I get time.
[13:57] <cking> another "your firmware is broken.. it should be fixed, but the kernel works around it" kind of report.
[14:00] <loftwyr> I have a USB3 dock that would not work until I changed CONFIG_USB_GADGET_VBUS_DRAW to 500 from the minimum of 2.  Is there a need for it to be 2 or can that be changed for future kernels?
[14:01] <loftwyr> I'm using Natty
[14:05] <tgardner> loftwyr, seems that 2 is the kconfig default. I assume its a safe choice.
[14:06] <loftwyr> Safe, perhaps, but can it be changed without a problem?  
[14:07] <tgardner> loftwyr, not without some advice from the upstream developers. They likely chose 2 for a reason.
[14:07] <loftwyr> Where would the best place be to ask them?
[14:07] <tgardner> seems like there ought to be a sysfs interface for changing it
[14:08] <tgardner> loftwyr, from the MAINTAINERS file:
[14:08] <tgardner> USB GADGET/PERIPHERAL SUBSYSTEM
[14:08] <tgardner> M:      David Brownell <dbrownell@users.sourceforge.net>
[14:08] <tgardner> L:      linux-usb@vger.kernel.org
[14:08] <tgardner> W:      http://www.linux-usb.org/gadget
[14:09] <loftwyr> I'll send him a note.  Thanks!
[14:14] <smb> mjg59, If I look at the right thread, this ended with "I will submit a patch asap". Jan-28. Maybe that is long enough to carefully ask what time frame this translates into. :)
[14:14] <sforshee> loftwyr, tgardner: I only caught the last half of the conversation, is this about vbus power usage?
[14:14] <tgardner> sforshee, yeah, gadget current limits
[14:14] <mjg59> smb: Ha :)
[14:15] <loftwyr> and the default in the kernel
[14:15] <sforshee> loftwyr, tgardner: the spec allows drawing up to 500 mA, I've always been curious why the default is 2
[14:15] <sforshee> I've always used 500 mA in projects I've worked on
[14:16] <loftwyr> That's what I want to find out, is it 2 for a reason or is that a legacy setting?
[14:16] <sforshee> yeah, I don't know the answer to that
[14:16] <sforshee> if you find out I'd be interested to hear :)
[14:16] <tgardner> sforshee, you've worked on known HW, though, right? The x86 world is quite that stable.
[14:16] <tgardner> isn't*
[14:17] <sforshee> tgardner, I _think_ that is the value that gets reported upstream (to the hub or the host)
[14:17] <sforshee> so you need to know what you're hardware's actually going to try and draw so you can report the correct value
[14:17] <sforshee> how many x86 devices are used as usb gadgets anyway?
[14:18] <sforshee> you're right though, seems like there should be a sysfs interface
[14:18] <loftwyr> Well, my Vantec dock wouldn't work until I upped the minimum gadget draw so I'm assuming that it doesn't report it's needs enough or uses the wrong interface.  
[14:18] <loftwyr> I can't seem to find a sysfs setting but I'm still looking
[14:19] <sforshee> loftwyr, yeah, the hub might cut you off if you're trying to draw more than you report you will
[14:20] <loftwyr> As it's a USB3 device, it may be reporting something strange that the subsystem doesn't recognize
[14:20] <sforshee> loftwyr, I don't know about USB3, but USB2 was backwards-compatable
[14:20] <sforshee> devices had to identify as USB2, and if they didn't they would fall back to USB1
[14:21] <sforshee> I'd suspect USB3 is the same
[14:22] <loftwyr> It does if the USB3 hub has a USB2 into it.  It all falls to USB2.  It's reporting as USB3 though according to the logs, just doesn't work using the kernel defaults (writes don't get written, etc.)
[14:23] <sforshee> and it all works if you change the vbus draw?
[14:23] <loftwyr> Yep.  The drivers (JMicron) were already enabled as modules so I assume it's just a power draw issue
[14:24] <sforshee> my initial guess is that the hub is suspending the device because it's drawing more power than what it said it will draw
[14:24] <loftwyr> Likely true. That would make sense that when I set the default higher, it doesn't cut it off.
[14:27] <sforshee> hitting up David Brownell will probably get you the best answers about it though
[14:29] <loftwyr> I've sent off the question, I'll let you all know the answer if/when I get it.
[14:33] <tgardner> ogra, natty linux-meta-mvl-dove is gone
[14:34] <ogra> tgardner, awesome, thanks
[14:50] <JFo> smb, mind having a look at a bug?
[14:50] <JFo> :)
[14:50] <smb> JFo, Not if I only have to *look* at it. :)
[14:50] <JFo> heh
[14:51] <smb> But I guess you want some comment too
[14:51] <JFo> only if you see that one is needed
[14:51] <JFo> bug 711544
[14:51] <ubot2> JFo: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/711544)
[14:51] <smb> Doh! :)
[14:51] <JFo> ah right, private :-/
[14:51] <JFo> sorry about that
[14:51] <JFo> but that is the bug number
[14:51] <smb> But I should be able to look
[14:52] <JFo> yes
[14:52] <smb> JFo, Yup
[14:52]  * smb looks
[14:52] <JFo> thanks amb :-)
[14:52] <JFo> sigh*
[14:52] <JFo> I fail today
[14:52] <JFo> smb that is
[15:34]  * apw returns ... but he has to have a shower
[15:34] <smb> sounds ugly
[15:34] <JFo> indeed
[15:35]  * JFo uses a stick to slide the soap toward apw
[15:35]  * tgardner imagines apw smeared with sewage
[15:35] <JFo> :-{
[15:43] <apw> tgardner, i didn't need to imagine
[15:44] <tgardner> apw, I suspected as much
[15:55] <apw> i think i need a strong dring
[15:55] <apw> drink
[15:56] <sforshee> apw, i don't know, looks like your speech is already slurred
[15:57] <apw> heheh
[16:04] <apw> JFo, our key list seems to be empty ?
[16:04] <JFo> !
[16:04]  * JFo looks
[16:07] <apw> JFo, its a newish thing cause they were there this morning
[16:07] <JFo> apw, I am running some tests
[16:08] <JFo> taking a while... apparently there is some lag on the line
[16:08] <apw> bjf yep
[16:11] <JFo> well, the buglists are generating, so the problem isn't there
[16:12] <JFo> I'm doing a run by hand to see if I get any errors
[16:12] <JFo> but there is nothing so far
[16:12] <JFo> and the list for yesterday is populated
[16:13] <JFo> so it has worked over the weekend
[16:13] <JFo> as shown here http://reports.qa.ubuntu.com/reports/jfo/kernel-buglist-by-team-archive/kernel-buglist-by-team-2011-02-13.html
[16:21] <apw> JFo, as i say it was working this morning for me, so approx 4-5 hours ago
[16:23] <JFo> odd that
[16:24] <apw> Can't look up definition in another url (https://api.launchpad.net/1.0/#bug)
[16:24] <apw> i get that from the second phase
[16:24] <JFo> sigh*
[16:25] <apw> JFo, any idea what it means?
[16:25] <JFo> not at all
[16:37]  * sforshee -> reboot
[17:04] <sconklin> JFo: From launchpad updates: API scripts talking to the edge cluster are broken with a NotImplementedError. We are investigating to resolve the issue quickly
[17:11] <JFo> apw, one sec... otp
[17:14] <JFo> sconklin, yeah, been trying to figure out WTF
[17:14] <JFo> sconklin, here is the latest: <leonardr> apw, JFo: the breakage was a mistake that's being fixed. edge will continue to work, but you should stop using it or one day this will happen for real
[17:20] <JFo> sconklin, :-/
[17:50] <apw> tgardner, i'll have a go at scrubbing lbm for upload for natty 
[17:51] <tgardner> apw, dkms'ing some of those packages is an interesting approach. about the only thing that might not work for are some of the OEM platforms.
[17:51] <apw> yeah they do throw the old spanner in the works
[17:52] <apw> i wonder if we could use dkms to make them somehow ... like using it to produce static binaries
[17:53] <tgardner> yeah, if we could drop LBM altogether. what a time saver.
[17:53] <apw> tgardner, yeah there must be a way, i think it would make a good 'OO' project
[17:54] <tgardner> indeed. perhaps we should float the idea at UDS ?
[17:54] <apw> as i think we can make a wrapper round them to 'freeze' them on a buildd for those systems which are too slow to really dkms
[17:54] <apw> tgardner,ea
[17:54] <apw> tgardner, yeah concur
[17:54] <loftwyr> Just circling round from this morning.  I sent an e-mail to linux-usb about the USB vbus draw and got this reply: http://ubuntuforums.org/showpost.php?p=10458053&postcount=7.  It seems I have to poke Vantec
[17:56] <ohsix> lbm?
[17:56] <tgardner> loftwyr, perhaps you should convince them to implement a sysfs interface for controlling draw.
[17:56] <apw> linux-backport-modules
[17:57] <apw> linux-backports-modules
[17:57] <ohsix> ah
[17:57] <loftwyr> That's an interesting idea tgardner, I'll ask about it.
[17:58] <tgardner> loftwyr, or failing that, a module parameter.
[17:58] <tgardner> Kconfig options are so static.
[18:00] <apw> they are so last year
[18:00] <tgardner> loftwyr, there may well already be a module param. I just haven't looked.
[18:00] <loftwyr> Let's see what they say.
[18:01] <loftwyr> A sysfs would be so much better as you could tune it on the fly andget the setting that most works
[18:19] <JFo> wow, just had some really odd sound inticator flashiness... not the good kind
[18:26] <loftwyr> Getting a fast reply from the USB-linux group (Felix Balbi to be precise).  He says no to an out of kernel control to avoid people melting their USB by setting the draw too high.  "Generally we don't mess too much with things related to power
[18:26] <loftwyr> consumption, it's quite a mess to lie to the USB host and things can go bad easily. Hope it helps."
[18:39]  * tgardner --> lunch
[19:09] <JFo> <-lunch
[19:27] <tgardner> bjf, did you or sconklin-lunch write anything down in the wiki about how master-next is to be used?
[19:27] <bjf> tgardner, i don't think so but i've got to look
[19:28] <tgardner> bjf, the wonderful search facilities returned no match on master-next
[19:53] <tgardner> jjohansen, when you get a moment, please review "Lucid/Maverick SRU, NFS: fix the return value of nfs_file_fsync()" on the k-t list
[20:51]  * jjohansen -> lunch
[20:59]  * sforshee -> reboot
[21:24] <jjohansen> anyone else noticed problems with gitk lately?
[21:26] <apw> jjohansen, what you seeing?
[21:27] <jjohansen> it keeps failing to provide diffs of commits, it will do a few and then it just stops
[21:27] <jjohansen> restart it and click on the commit it failed on before and it works, but a few more and it fails again
[21:27] <apw> how many approx ?
[21:28] <jjohansen> seems to be approx 3-4
[21:28] <jjohansen> it isn't always the same for me
[21:29] <apw> just looked at the top 30 or so without issue, on my natty tree
[21:29] <jjohansen> apw: okay thanks
[21:30] <apw> jjohansen, that was on a natty box
[21:30] <apw> jjohansen, OH i did limit history .. gitk HEAD ^v2.6.36
[21:30] <apw> could you be runnign out of memory for 'all' history
[21:31] <jjohansen> apw: well maybe but I haven't ulimited it and I seem to have more than a gig free
[21:31] <jjohansen> I'll mess around with it a bit more
[21:33] <apw> tends to kill my machine completely
[21:35] <jjohansen> yeah pruning it down does help
[21:40] <bjf> apw, bug #677021
[21:40] <ubot2> Launchpad bug 677021 in linux "Maverick: 2.6.35-23.40 -proposed tracker" [Medium,Fix committed] https://launchpad.net/bugs/677021
[21:42] <apw> bjf ?
[21:43] <apw> bjf, oh interesting
[21:43] <bjf> apw, was that what you were thinking ?
[21:46] <apw> bjf, that looks like what pete was suggesting ... didn't know you could do that
[21:46] <bjf> apw, it's using some LP terms/ideas in ways they are not intended, but i think it would work
[21:47] <apw> i assume that the 'phases' are series ?
[21:47] <bjf> apw, yes
[21:48] <bjf> apw, so each phase/series could be independently assigned and it's status changed
[21:48] <bjf> apw, they could also be worked on in parallel (if possible)
[21:49] <apw> bjf, could you have used packages witin 'kernel workflow' for the phases too?
[21:49] <bjf> apw, not sure, bug maybe
[21:49] <apw> i ask cause this way they can't apply to the in the same way to ubuntu series
[21:49] <apw> and wonder if that might be something we might want
[21:50] <bjf> apw, not sure i'm tracking why you'd want to do them as packages
[21:57] <apw> bjf, i am assuming that you can only have one set of series for a project
[21:58] <apw> so if for example we wanted to have one bug for 'this round of uploads'
[21:58] <apw> then we'd want 'upload-it' to have series for each series we have live
[21:58] <apw> so i was just musing if we used packages in your new project to represent the
[21:59] <apw> phases, we could also have a task in each phase for each series (maverieck, lucid etc)
[21:59] <apw> musing is we were backing self into a corner by using series for phases if it can be either
[21:59] <apw> bjf, ^^
[21:59] <bjf> apw, every uploaded package get's it's own tracking bug
[22:00] <apw> yeah it does currently so it currently makes no difference indeed
[22:00] <apw> just wondering if we might want to both at some point
[22:00] <bjf> apw, nothing cast in stone at this point, it's just an experiment for now
[22:01] <apw> yeah assumed so, just a thought nothing more, wondering wondering
[22:05] <apw> bjf, i can see that working either way pretty well
[22:15]  * sforshee -> reboot