[03:08] <kees> apw: I've finished the 3-phase old kernel bug tracker sync stuff now. I've done a bunch of status and description updates as well.
[03:09] <kees> apw: there are a few more corner cases I ran into, but I've been documenting it in the uct README file. of most note is how to add and remove SHAs from the bug descriptions.
[07:27]  * smb -> BOD
[08:39]  * apw yawns
[08:41]  * smb waves
[08:43]  * abogani waves back to all
[08:56] <tjaalton> were there some scripts to aid debugging when suspend fails to work?
[08:56] <tjaalton> my snb desktop hangs while trying that on oneiric
[08:57] <smb> Not sure how much Colin built into fwts, but he also had some system tap scripts somewhere
[08:58] <smb> But there also was some bug (I fail to remember atm) that system tap in oneiric was broken..
[08:58] <tjaalton> ah
[08:58] <tjaalton> i'll try fwts
[08:59] <smb> bug 815944
[08:59] <ubot2> Launchpad bug 815944 in systemtap "systemtap on Oneiric breaks because of kernel commit 449a66fd1fa75d36dca917704827c40c8f416bca" [High,Confirmed] https://launchpad.net/bugs/815944
[09:00] <tjaalton> thanks
[09:02] <apw> smb, i suspect that systemtap needs to change to follow, it is its lot (to break ceaslesly)
[09:04] <smb> apw, Yeah, I don't think we want to follow a road of changing back the kernel, when the upstream path is to have it removed.
[12:30] <marcoceppi> Do I need to do anything special in order to create a deb source of the kernel that LP can build?
[12:30] <marcoceppi> Maybe a magic wiki article that I missed?
[12:33] <smb> !kernel
[12:33] <ubot2> The core of Ubuntu is the Linux kernel: see https://help.ubuntu.com/community/Kernel - You shouldn't have to compile your own, and if you need to troubleshoot issues, you can try a !Mainline kernel instead, but if you insist, see https://help.ubuntu.com/community/Kernel/Compile (see also !Stages)
[12:33] <smb> marcoceppi, Something like that?
[12:33] <smb> !kernel-faq
[12:33] <ubot2> A list of common questions about the Ubuntu Kernel can be found in http://wiki.ubuntu.com/Kernel/FAQ
[12:33] <apw> marcoceppi, how did it fail ?  we covered clean yesterday i think
[12:36] <marcoceppi> Yeah, here is the last line from the build line
[12:38] <marcoceppi> enable deprecated sysfs features which may confuse old userspace tools (SYSFS_DEPRECATED_V2) [Y/?] y
[12:38] <marcoceppi> make deprecated sysfs layout dynamically (SYSFS_DEPRECATED_DYN) [Y/n/?] (NEW) aborted!
[12:38] <marcoceppi> Console input/output is redirected. Run 'make oldconfig' to update configuration.
[12:38] <marcoceppi> make[5]: *** [silentoldconfig] Error 1
[12:38] <marcoceppi> make[4]: *** [silentoldconfig] Error 2
[12:38] <marcoceppi> make[3]: *** [sub-make] Error 2
[12:38] <marcoceppi> make[2]: *** [silentoldconfig] Error 2
[12:38] <marcoceppi> make[1]: *** [sub-make] Error 2
[12:38] <marcoceppi> make[1]: Leaving directory `/build/buildd/linux-2.6.32-33.72'
[12:38] <marcoceppi> make: *** [/build/buildd/linux-2.6.32-33.72/debian/stamps/stamp-prepare-tree-generic] Error 2
[12:38] <marcoceppi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
[12:38] <marcoceppi> The source was built properly, lp build spit this back. I ran make oldconfig in my source tree and it built the .config without an issue. So I wonder if it's not getting my saved config somehow
[12:39] <apw> you seem to have an out of date config
[12:40] <apw> fakeroot debian/rules updateconfigs
[12:43] <marcoceppi> So running that seems to produce check-config errors. I assume that I'll need to do something about that.
[12:44] <marcoceppi> ls
[12:46] <smb> herton, That new lucid kernel upload, I guess that means I should prepare an ec2 tree. Though I cannot remember having seen any bot or person bugging me about that...
[12:49] <herton> smb: the new lucid kernel was just a respin to revert 2 changes for bug 811745. We should be creating new tracking bugs for you, but this isn't ready yet
[12:49] <ubot2> Launchpad bug 811745 in linux "Whole system freeze after safely remove external usb drive" [High,Fix committed] https://launchpad.net/bugs/811745
[12:49] <herton> smb: not a respin, but a new update I mean just for that bug
[12:51] <smb> herton, Ah, ok. So I better wait until you are ready. I was just wondering whether I missed something there
[12:51] <smb> Unplugging an external usb drive in the cloud is difficult anyways...
[12:52] <herton> hehe
[12:52] <apw> smb, does it not have usb emulation ?
[12:54] <smb> apw, Not the normal usage. There could be ide or scsi emulation but actually only the virtual block devices are used as the are quicker
[13:58] <marcoceppi> Thanks for your help thus far. I'm getting closer. The build servers are telling me that the source isn't clean and that I need to make mrproper - however, when I run that in my local source it removes a lot of the debian control items.
[13:58] <apw> marcoceppi, you need to "rmdir include/config" normally to fix that
[14:00] <marcoceppi> Ah, I'll give that a try. Thank you
[14:24]  * ogasawara back in 20
[14:30] <bjf> ##
[14:30] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:30] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[14:30] <bjf> ##
[16:00] <bjf> ##
[16:00] <bjf> ## Kernel team meeting in one hour
[16:00] <bjf> ##
[16:13] <ogasawara> bjf: I noticed bug 819632 from the daily bug report
[16:13] <ubot2> Launchpad bug 819632 in linux "WARNING: at /build/buildd/linux-2.6.31/net/sched/sch_generic.c:246 dev_watchdog 0x1f6/0x210()" [Undecided,New] https://launchpad.net/bugs/819632
[16:13] <ogasawara> bjf: it's against a karmic kernel (which your scripts correctly detected)
[16:14] <ogasawara> bjf: just curious if you'd want to auto close it rather than have it appear on the report?
[16:14] <bjf> ogasawara, yes, but it didn't get the right tag (and it's an unsupported series)
[16:14] <bjf> ogasawara, i'll look into it
[16:25] <ohsix> herton: i just got an unrelated panic (in the wifi stack) on wakeup with -9, so i'm running -11 now and i'll get a screen asap
[16:30] <herton> ohsix: ok
[16:55] <marcoceppi> Hum, so I removed include/config and I'm still getting mrproper error during the build. Is there anything else I might need to do?
[16:55] <BenC> marcoceppi: make mrproper
[16:55] <apw> marcoceppi, well the tree should be made clean, so checkin anything you have changed
[16:56] <apw> then git clean -f -x -d, note this will DELETE any files not tracked by git
[16:56] <apw> then fakeroot debian/rules clean, then package it
[16:56] <marcoceppi> mrproper removes all the debian/ files - so I won't be able to run debuild
[16:56] <BenC> marcoceppi: mv debian ../debian.orig; make mrproper; mv ../debian.orig debian
[16:57] <marcoceppi> Ah, makes sense. Let me try that
[16:58] <marcoceppi> Shuould I rape mrproper in fakeroot?
[16:58] <marcoceppi> WRAP*
[16:58] <apw> don't think so
[17:01] <bjf> ##
[17:01] <bjf> ## Meeting starting now
[17:01] <bjf> ##
[17:11] <apw> bdmurray, i'd be interested in more details of the changes if you able to send them out
[17:13] <bdmurray> apw: the changes already made or what I think should happen now?
[17:14] <apw> bdmurray, right, but of what we might find different
[17:19] <alfmatos> hi
[17:20] <alfmatos> just reported bug #819925
[17:20] <ubot2> Launchpad bug 819925 in linux "iwlwifi driver exports all packets through netlink" [Undecided,New] https://launchpad.net/bugs/819925
[17:20] <apw> ogasawara, ^^ that sounds like something to put on your config-review list
[17:21]  * ogasawara looks
[17:21]  * ogasawara adds a work item
[17:21] <alfmatos> :)
[17:21] <alfmatos> that should default to N i would assume =)
[17:22] <bjf> apw, hah! you beat the script
[17:22] <apw> bjf, yeah stop the spam
[17:23] <alfmatos> well, that's all i got, thanks guys =)
[17:23] <ogasawara> alfmatos: I'll get it flipped to N and it'll be in the next upload after Alpha3
[17:24] <alfmatos> cool
[17:29] <cprofitt> hell all...
[17:29] <cprofitt> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/776999
[17:29] <ubot2> Ubuntu bug 776999 in linux "[Lenovo W520] laptop freezes on ACPI-related actions" [Undecided,Confirmed]
[17:30] <cprofitt> was looking for a little bit of advice on how to move this from confirmed to triage
[17:30] <cprofitt> I have a W520 and could assist gather some information
[17:35] <marcoceppi> I seem to be getting a lot closer to it actually compiling. The seemingly last hurdle is that 7 configuration values fail check-config. Should I just remove those? Is it maybe they no longer exist in this version of the kernel and are just old?
[17:47] <apw> marcoceppi, what version of the kernel is the config from and what is the version of the kerenl
[17:53] <marcoceppi> apw I have the latest from ubuntu-lucid.git -33.72 I copied the config from a lucid VM with the latest installed from the repo
[17:54] <apw> marcoceppi, then no i would not exect the config to change at all
[17:55] <ogasawara> bjf: pastebin me the minutes, I'll shove em to voices
[17:55] <apw> bjf, i say don't bother to publish them
[17:56] <apw> its not a high priority for us apparently
[17:56] <marcoceppi> apw: The build fails at these 7 entries: http://paste.ubuntu.com/657368/
[17:56] <apw> marcoceppi, but the config for a lucid kernle would have those set
[17:56] <bjf> apw, ogasawara i've been assured that this will be fixed today, if not i will send email to pgraner that we will no longer be blogging our meeting minutes
[17:56] <apw> and set correctly else the same failure would have prevented the kernel you have from building in the first place
[17:56] <ogasawara> bjf: ack
[17:58] <marcoceppi> apw: Makes sense. I'll try to figure out where I went wrong. I may try re-copying the configurations over and running updateconfig again
[17:58] <bjf> ogasawara, http://pastebin.ubuntu.com/657372/ (thanks)
[17:58] <apw> why not use the config which is in the tree?  given it is for the same kernel
[17:59] <marcoceppi> I was just following the instructions from https://wiki.ubuntu.com/KernelTeam/GitKernelBuild I may have gotten confused and copied when I shouldn't have.
[18:02] <marcoceppi> So should I just checkout the configuration files from the last clean commit in the ubuntu-lucid.git? I assume it's in debian/build/ directory?
[18:02] <bjf> marcoceppi, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel is a good, basic starting point
[18:04] <marcoceppi> bjf: Thanks, I was linked to it yesterday - I'll probably just start from their this time
[18:05] <jjohansen> marcoceppi: ping me if you run into problems
[18:08] <marcoceppi> I'm trying to avoid starting from scratch. It took me about 5 hours to patch the kernel. Soo, let me see if I can back up until right after I patched
[18:16] <marcoceppi> Okay, I think I've gotten to a point where I can try to perform a clean build. Would it be beneficial to build the kernel locally before trying to get LP to build it? 
[18:20] <apw> marcoceppi, depends how fast your local build is
[18:25] <marcoceppi> It's still failing at those configurations. I wonder if it's because I patched v2.6.32 in the git line, then merged down the changes up to 2.6.32-33.72
[18:25]  * tgardner --> lunch
[18:25]  * smb -Y eod
[18:25] <marcoceppi> If I remove those values, I assume it would make me re-enter them if it really needed it, right?
[18:26] <apw> marcoceppi, nope, it will then not have things set you need in order to boot most likely
[18:26] <apw> if you mean removing them from the config check
[18:26] <marcoceppi> I mean removing them from the build's .config
[18:26] <apw> it will ask you to set thme yes on updateconfigs
[18:27] <marcoceppi> Then what would be causing check-config to throw the error? Could it be expecting a different value?
[18:28] <apw> what values do the config options have in your config ... git grep FOO debian.master/config
[18:28] <marcoceppi> When I search the debian/build/build-generic/.config file those keys don't exist
[18:28] <apw> if you got the configs and the enforcer file from the same or nearly the same version of the kernel then they should match
[18:29] <apw> marcoceppi, thats generated during the build and not interesting as much as the master for them
[18:29] <marcoceppi> Let me check the master
[18:31] <marcoceppi> All of these keys and values exist in config/enforce config/config.common.ubunut and config/config.common.ports
[18:33] <marcoceppi> So, I should run debian/control updateconfigs then try again?
[18:33] <marcoceppi> rules*
[18:34] <apw> if you do a fakeroot debian/rules prepare-generic (or whatver falvour you care about)
[18:34] <apw> you can see if the built cdonfig has what you need in it
[18:35] <marcoceppi> It built, but failed with the same 7 check-config errors like before
[18:36] <apw> you said they were present and correct in the config master files yes ?
[18:36] <apw> so then the question is what patches have you applied
[18:36] <marcoceppi> I applied the OpenVZ patch
[18:37] <marcoceppi> for 2.6.32
[18:37] <apw> so perhaps they prevent those options being set, and you are in a world of hurt
[18:37] <apw> does the openvz patch set include any configuration (Kconfig) file updates, add any additional depends ?
[18:38] <marcoceppi> It changes a few kconfigs. It doesn't add any external dependencies that I know of
[18:38] <apw> well if an option is in the master configs and not in the resultant built .config in debian/build
[18:38] <apw> then there must be a configuration dependancy that is stopping them
[18:39] <apw> so you need to pick one and validate its pre-requisites
[18:39] <apw> and find out why its now off/difffernet
[18:39]  * apw eyes the beer on his desk ... you are mine
[18:40] <marcoceppi> I see, so it's it's time to chase down "why"?
[18:40] <apw> yep sadly so
[18:41] <marcoceppi> Well the majority is related to SELINUX and APPARMOR which I know does not work with OpenVZ
[18:41] <apw> then that would explain why they go missing
[18:41] <apw> if they are incompatible
[18:41] <marcoceppi> So, updating the enforce file would be...the solution?
[18:41] <apw> then you need to remove the enforcement for them, as they can never be set
[18:41] <apw> and pay the consequences if userspace needs them
[18:42] <marcoceppi> Well, I'll chase down the others to make sure it's something that is supposed to be missing. Thanks for your help apw enjoy your beer :)
[18:43] <apw> *glug&
[18:51] <marcoceppi> Awesome, OpenVZ doesn't support DEVTMPFS as well. This is going to be a pain now that I look at it.
[18:56] <apw> now that is going to be a tricky one
[18:56] <apw> upstart may cope
[18:58] <marcoceppi> I hope so
[18:59] <marcoceppi> I mean, if people are able to use the linus 2.6.32 kernel on 10.04 I *should* be able to use 2.6.32-33.72 with the patch? right?
[18:59] <marcoceppi> well _maybe_
[19:00] <apw> except that that supports devtmpfs
[19:01] <marcoceppi> what I mean was 2.6.32 with the OpenVZ patch (which it was created for)
[19:02] <apw> if the openvz patch is known to work on ubuntu then yours should, is what i think you are saying
[19:07] <kees> apw: how did yesterday's bug status sync look to you?
[19:10] <marcoceppi> apw: Yes, only I didn't articulate it very well.
[19:13] <apw> kees, didn't see anything out of order
[19:13] <kees> apw: excellent
[19:13] <apw> wil keep a weather eye
[19:14] <kees> herton: do you know who is doing the publication of the maverick linux package? it seems to have only hit -updates...
[19:14] <herton> kees: no idea
[19:14] <kees> herton: okay, thanks
[19:56] <herton> kees: sconklin is looking into it, he was told slangasek did the publishing
[19:56] <sconklin> kees: it's being worked
[19:59] <marcoceppi> bjf apw:  Thanks for your help. I'm able to get past the configuration issues from earlier - now I just need to fix the code errors!
[20:00] <kees> sconklin: thanks!
[20:18]  * tgardner -> EOD
[20:20]  * jjohansen -> lunch
[20:27] <kees> apw, sconklin: do either of you know the status of ti-omap4 for maverick?
[20:27] <sconklin> kees: no
[20:28] <kees> sconklin: what's needed to make it show up on http://people.canonical.com/~kernel/reports/sru-report.html ? just open bugs?
[20:28] <sconklin> a tracking bug that's in process
[20:29] <kees> sconklin: hm, okay. I guess I don't know what takes stuff from http://people.canonical.com/~apw/cve/pkg/ALL-linux.html in "pending" to showing up on http://people.canonical.com/~kernel/reports/sru-report.html
[20:29] <kees> I'll ping apw tomorrow
[20:29] <sconklin> kees: is this helpful? http://people.canonical.com/~kernel/reports/versions.html
[20:29] <sconklin> probably not
[20:30] <kees> sconklin: I think that just shows me that there isn't something in the PPA waiting for workflow progress
[20:30] <sconklin> that's right, and nothing in -proposed
[20:33] <kees> sconklin: oh, what about linux-lts-backport-maverick? it seems to be missing a tracking bug?
[20:35] <sconklin> kees: looking
[20:37] <herton> sconklin, kees: for linux-lts-backport-maverick it's bug 811215, but it doesn't show on sru-report
[20:37] <ubot2> Launchpad bug 811215 in kernel-sru-workflow "linux-lts-backport-maverick: 2.6.35-30.56~lucid1 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/811215
[20:37] <kees> herton: ah, thanks.
[20:37] <sconklin> herton: thanks, I was waiting for git to fetch
[20:38] <sconklin> we'll figure out why that's not in the report
[20:44] <bjf> sconklin, i'm looking at the kernel-sru-worflow and the tracking bug shows there, heading to the sru-report
[20:44] <sconklin> bjf: thanks!
[20:47] <herton> yep, the sru-report is the one which misses it
[21:49] <medberry> cnd, the recent 10.04.3 kernel update "broke" my clickpad in Lucid. I've got an HP ProBook 4320s and stayed on Lucid as Maverick forward don't work properly with the clickpad.
[21:49] <medberry> now that forward problem has come back to haunt me.
[21:49] <medberry> Any suggestions?
[21:50] <cnd> medberry, can you provide more details on what's wrong?
[21:52] <medberry> the left center right areas are treated as one area cnd.
[21:52] <medberry> and it's also really "touchy". Making it much more difficult to click and drag now.
[21:52] <medberry> I suspect the 10.04.3 kernel SRU pulled in some mouse/input changes (similar to what were in Mav and Nat all along.)
[21:53] <cnd> medberry, can you describe the layout of your trackpad? what do you mean by left center right areas?
[21:54] <medberry> sure: the clickpad has a "T" shape overlay on the bottom 20% where the middle of the T is in center bottom.
[21:55] <medberry> representing "left" and "right" mouse buttons. Moreover, the bar of the "T" functioned as a middle click.
[21:55] <medberry> Now, I'm back to the whole area representing a left click (irrespective of the markings.)
[21:57] <cnd> medberry, I'm guessing there was a kernel patch that was in lucid that was not upstream to handle these trackpads
[21:57] <medberry> so "left" is more less the bottom 20-25% and the left 40%, center is the bottom 20-25% and the middle 20% and right is the right most 40% of the bottom 20-25%. I can send a picture if it helps.
[21:58] <cnd> based on a vague memory of what's happened in this area
[21:58] <cnd> sconklin, do you remember any changes in drivers/input/mouse/synaptics.c that went into the latest lucid kernel updates?
[21:59] <sconklin> cnd: no but it's really easy for me to check
[21:59] <cnd> medberry, I'll add that upstream still doesn't have a great solution for this, IIRC
[21:59] <medberry> cnd, to clarify, afaict, this is still broken/crippled in M/N/O-alpha as well.
[21:59] <cnd> yeah
[21:59] <medberry> cnd, yes, I think that's the issue.
[21:59] <cnd> the kernel should provide the raw coordinates, which is what occurs in M/N/O/etc.
[22:00] <medberry> did lucid release with a kernel that didn't have the pointer stuff "in kernel". That's my understanding (or misunderstanding)
[22:00] <cnd> but xserver-xorg-input-synaptics needs to handle clickpads properly
[22:00] <cnd> which it doesn't right now
[22:00] <medberry> okay.
[22:00] <sconklin> cnd: I don't see any recent changes to that at all
[22:01] <sconklin> i.e. last patch was in April 2010
[22:01] <medberry> I'm going to double check my assumption that it was a kernel change that made the difference. Please disregard until I've completely verified that is the delta.
[22:01] <cnd> medberry, can you check to see what events are emitted by the kernel in the good and bad kernels?
[22:01] <cnd> you can use evtest to see the events
[22:01] <medberry> sure.
[22:01] <medberry> I'll do that and get back to you. Thanks.
[22:01] <cnd> the "good" kernel probably is emitting BTN_LEFT, BTN_RIGHT, and BTN_MIDDLE
[22:02] <cnd> whereas the "bad" kernel is probably only emitting BTN_LEFT
[22:02] <medberry> nod.
[22:10] <sconklin> cnd: I may have found what happened with input
[22:10] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.32/+bug/814186
[22:10] <ubot2> Ubuntu bug 814186 in linux-backports-modules-2.6.32 "linux-backports-modules-wwan and -input packaged incorrectly" [Medium,Fix committed]
[22:11] <sconklin> previously the input driver from lbm wasn't getting loaded, and apparently now it is
[22:12] <cnd> medberry, do you have linux-backports-modules-synaptics installed?
[22:12] <cnd> sconklin, I'm not sure that works out though
[22:12] <cnd> so if lbm is installed, the synaptics module may be the server version
[22:13] <cnd> and so it would fail to load
[22:13] <cnd> but then you'd end up without any input modules loaded
[22:13] <sconklin> yeah, it only applies if lbm is installed
[22:13] <cnd> actually, that might work out
[22:13] <cnd> I dunno :)
[22:13] <sconklin> well, the kernel also has some input drivers without lbm, so I believe you would just get a different driver
[22:13] <cnd> yeah
[22:14] <cnd> it could be picking up a static standard PS2 driver instead
[22:14] <cnd> and I wouldn't be too surprised if these clickpads worked better in PS2 mode than in full synaptics mode :)
[22:17] <sconklin> cnd: a bug with collected info would be helpful. And is this from -proposed? because that change hasn't been released yet
[22:17] <sconklin> medberry: are you running -proposed?
[22:17] <cnd> sconklin, meet medberry :)
[22:19] <sconklin> medberry: the most helpful thing now is to run 'ubuntu-bug linux' and get all your info into a bug
[22:21] <medberry> sconklin, cnd, nod.
[22:22] <medberry> sconklin, dpkg -l linux-backport\* reports nothing 
[22:22] <jwi> note that several touchpad "regressions" have been reported after the update to -33.70; 811420, 811753, 811962, 815357
[22:40] <bjf> jwi, bug 811753 is against .32-32.62 where the other three are .32-33.70
[22:40] <ubot2> Launchpad bug 811753 in linux "Synaptics Touchpad keys stoped working" [Undecided,Confirmed] https://launchpad.net/bugs/811753
[22:41] <medberry> sconklin, my experience is similar to 811753. cnd: evtest reported  can't get version: Inappropriate ioctl for device (no matter which mouse dev I chose.)
[22:41] <cnd> gah, the stupid evdev protocol version issue
[22:42] <cnd> medberry, get the oneiric evtest package and install it
[22:42] <bjf> jwi, how do you happen to be tracking those bugs, are you watching input bugs or lucid regressions or ... ?
[22:42] <cnd> it should work just fine
[22:42] <medberry> nod, will do.
[22:42] <bjf> ogasawara, ping (just if you happen to be around right now)
[23:00] <medberry> cnd, oneiric evtest behaved the same: Inappropriate ioctl for device
[23:00] <medberry> I then ran "xinput test ##" with my device on both
[23:01] <medberry> the new kernel reports only button 1 events (and they occur anywhere on the clickpad). The old kernel reports all three buttons but only in the lower 20-25% of the screen.
[23:01] <medberry> Both report movement but the old kernel only reports mouse motion in the top 75-80% of the clickpad. The new kernel reports all over. So it's just one giant button/mouse in its behavior.
[23:02] <medberry> (which as I understand accurately reflects the hardware--software heuristics are required to get the B1, B2, B3 and to distinguish between the "mouse" and "button" areas.)
[23:03] <medberry> my work around for now is to use the 2.6.32-32 kernel
[23:06] <jwi> bjf: incoming regressions, mostly. re 811753: note the user's description, I guess it was reported from the old/working kernel
[23:07] <bjf> jwi, i was looking at the bootdmesg
[23:08] <medberry> jwi, bjf : if you need a guinea pig for these issues let me know. My issue most closely resembles 811753.
[23:19] <bjf> medberry, i have nothing to offer right now
[23:21] <medberry> no worries. Thanks guys.
[23:31] <cnd> sconklin, bjf: where's the code for the workflow mgr bot?
[23:31] <bjf> cnd kteam-tools
[23:31] <cnd> ok
[23:33] <bjf> cnd, it's kind of complicated because it's trying to manage a specific workflow, but it wouldn't be bad to start with, gut it and do your own
[23:33] <cnd> yeah
[23:33] <cnd> bjf, how do you develop? what's your testbed?
[23:33] <bjf> cnd, unfortunately the best thing to use is the qastaging server
[23:34] <bjf> cnd, if you look at the code, there is a --staging command line flag that you can use
[23:34] <cnd> what's the qastaging server?
[23:34] <cnd> is it some semi-permanent instance?
[23:34] <bjf> cnd, you can create any bugs over on that server/service (a testing LP instance)
[23:35] <bjf> cnd, it's got a snapshot of the DB, so any changes you make there are not seen on the production server
[23:36] <cnd> ahh, cool
[23:37] <bjf> cnd, the problem with it is that it isn't real stable
[23:37] <cnd> oh..
[23:37]  * cnd just hit an error
[23:38] <cnd> bjf, I assume things are wiped every so often?
[23:38] <bjf> cnd, yes, something like weekly
[23:38] <cnd> ok
[23:39] <bjf> cnd, https://bugs.qastaging.launchpad.net/ubuntu/+source/evolution/+bug/777777
[23:39] <ubot2> Ubuntu bug 777777 in evolution "Mark read / unread only works once in message window" [Low,New]
[23:39] <bjf> cnd that worked for me
[23:39] <cnd> bjf, where's the documentation for the launchpad api?
[23:40] <bjf> https://edge.launchpad.net/+apidoc/
[23:40] <bjf> cnd the bot uses the LPLTK which is a slick on top of the LP api
[23:40] <cnd> ok
[23:46] <bjf> cnd bzr+ssh://bazaar.launchpad.net/~arsenal-devel/arsenal/python-launchpadlib-toolkit/
[23:50] <bjf> cnd https://launchpad.net/~arsenal-devel/+archive/ppa