[00:04] <persia> I don't know best practices for kernel rename (kernel packaging confuses me), but I believe you'd want to rename your headers, your -meta, etc. to match, as well as all the relationships.  There may be some packaging helper scripts that need adjustment.
[00:07] <bankix> Uh.
[00:08] <bankix> That sounds heavy
[00:08] <bankix> I thought I could get away with a simple "provides: linux-*"
[00:09] <persia> That's risky, because your meta will depend on the highest version of linux-*, and versioned provides don't work, and so when then next ABI change happens, you'll be offered an upgrade anyway.
[00:09] <persia> Plus, your headers may not match, which could break building modules.
[00:10] <bankix> OK, no renaming.
[00:11] <bankix> But how to avoid updates?
[00:12] <bankix> setting it to "hold" in the package database?
[00:13] <persia> won't prevent offers
[00:14] <bankix> Then I'm helpless.
[00:18] <bankix> But thanks for your help
[00:19] <bankix> I think the safest but hardest way would be to rename the package. This would prevent all offers and updates, except I offer an update myself.
[00:20] <persia> Yes.
[00:21] <bankix> OK, something to do next week :-)
[00:26] <bankix> And I'll set up a quad-core tomorrow to get that compile batch done ...
[00:28] <bankix> Thanks again and good night.
[00:31] <bryceh> bjf, apw, JFo: new lpltk 0.4.2 uploaded to natty
[01:13] <bryceh> ugh, my natty desktop is running into some kernel BUG - bug #716811
[01:13] <ubot2> Launchpad bug 716811 in linux "[SandyBridge] kernel BUG at /build/buildd/linux-2.6.38/fs/nfsd/nfs4state.c:3132!" [Undecided,New] https://launchpad.net/bugs/716811
[01:14] <bryceh> JFo, ^^ let me know if there's any more info I could gather that would be of help diagnosing it
[01:17] <jk-> wow, that looks like a bogus BUG_ON
[01:19]  * jk- fetches newer git tree
[01:26] <jk-> ah, the bogusness has been fixed
[01:46] <bryceh> JFo, #713864 may be worth adding to the kernel team's list to track; while it doesn't yet have a patch worth pulling it looks like they're narrowing in on one.
[01:47] <bryceh> JFo, dang it, I meant bug #711591 there.
[01:47] <ubot2> Launchpad bug 711591 in nouveau "does not detect resolution correctly(xserver-xorg-video-nouveau causes graphic corruption were you cant do anything)" [Critical,Confirmed] https://launchpad.net/bugs/711591
[08:54] <al-maisan> Hello, upgraded to the 2.6.38-3.30 kernel this morning and laptop (thinkpad t410) froze twice on resume from suspend (nothing in /var/log/syslog) .. is this a known issue?
[08:54] <al-maisan> FWIW the 2.6.38-2.29 kernel does not exhibit this problem
[08:55] <al-maisan> the following upstream kernel change might be the "culprit": drm/i915/lvds: Restore dithering on native modes for gen2/3
[08:58] <smb> al-maisan, Given that the kernel was uploaded only yesterday there may not be "known" too much. But I don't follow those things not that closely. I could potentially build you a kernel with that one patch removed to test this for sure
[08:58] <apw> al-maisan, no it is not known
[08:59] <apw> smb, i don't think that commit is very likely
[08:59] <al-maisan> smb: ah, I see .. well, if you make such a kernel available I would certainly give it a try.
[08:59] <apw> it changes a dithering order bit in the GPU ... removing some banding
[08:59] <apw> al-maisan, why do u pick that one commit as likely ?
[08:59] <apw> the word restore in that commit is not related to resume from suspend
[09:00] <al-maisan> apw: I am just guessing .. I had i915 related resume freezes with the maverick kernels .. burnt child syndrome :P
[09:00] <apw> hmmm 
[09:01] <apw> al-maisan, can you confirm that this is repeatable, that it is every resume with the new kernel ?
[09:01] <al-maisan> it occurred twice this morning .. let me reboot into 2.6.38-3.30 and try it one more time
[09:01] <al-maisan> biab
[09:40] <al-maisan> apw: ok .. the resume freeze is "reliable" and repeatable .. tried it two more times in a row .. froze both times
[09:40] <al-maisan> nothing in /var/log/syslog
[09:41] <al-maisan> resumes with the 2.6.38-2.29 kernel still work fine
[09:44] <apw> al-maisan, hmmm
[09:44] <apw> i'd ask you to file a bug, but ... launchpad is in a heap
[09:45] <al-maisan> ouch ;)
[09:45] <apw> al-maisan, assume this is an x86 of some sort
[09:45] <al-maisan> x86_64
[09:48] <apw> ok i have a 64bit install on the -3.30 kernel which is ok ... hmmm
[09:49] <apw> al-maisan, what graphics do you have ?
[09:49] <al-maisan> I have an integrated i915 and a discrete nvidia chip (which I turned off via the bios)
[09:57] <apw> 831d52b x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm
[10:02] <apw> al-maisan, you have 64 bit yes?  if i do you a test kernel you available to test it ?
[10:02] <al-maisan> apw: yes and yes
[11:15] <apw> almaisan-away, sorry for the delay ... i lost the first build: http://people.canonical.com/~apw/amd64-resume-natty/
[11:16] <apw> almaisan-away, could you test that and report back please
[12:28] <apw_> almaisan-away: did you get a chance to test? lost my scrollback
[13:13] <al-maisan> apw: will do!
[13:30] <apw> al-maisan, hows it lookin
[13:31] <al-maisan> apw: I need to finish a piece of work .. will let you know in 20 minutes .. sorry for the delay.
[13:31] <apw> al-maisan, heh no worries, just impatient like all techies :)
[13:32]  * al-maisan knows the feeling ;)
[13:35] <al-maisan> apw: booting into the kernel you prepared now ..
[13:45] <tgardner> sconklin-gone, why aren't my linux-fsl-imx51 kernels getting pocket copied from the c-k-t PPA ?
[13:46] <rsajdok> Where is correct link to a git repository contains this patch?
[13:46] <rsajdok> http://kernel.ubuntu.com/git?p=manjo/ubuntu-maverick.git;a=commitdiff;h=refs/heads/lp712174
[13:47] <apw> rsajdok, git://kernel.ubuntu.com/manjo/ubuntu-maverick.git i believe
[13:48] <al-maisan> apw: that kernel behaved the same unfortunately .. freeze on resume .. not a single peep in /var/log/syslog
[13:48] <apw> al-maisan, well thats perplexing
[13:49] <al-maisan> yeah
[13:49] <apw> al-maisan, can you test the v2.6.38-rc4 mainline build please
[13:50] <apw> if its in mainline then i can start a bisect on it
[13:50] <al-maisan> apw: where would I find that kernel?
[13:50] <al-maisan> the mainline one
[13:50] <apw> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.38-rc4-natty/
[13:50] <apw> that is in theory the same as the -3 you tested but without the ubuntu sauce
[13:51] <apw> if that fails (and i would expect it to then we can bisect -rc3 -> -rc4
[13:51] <jpds> Would anyone happen to know what could be causing bug #709457 ? The dkms.log file isn't really helpful.
[13:51] <ubot2> Launchpad bug 709457 in oss4 "package oss4-dkms 4.2-build2002-2 failed to install/upgrade: oss4 kernel module failed to build" [Undecided,Confirmed] https://launchpad.net/bugs/709457
[13:53] <apw> jpds, nothing there to work with is there
[13:53] <apw> jpds, i think you can run the build by hand with like dkms build (and a few version options)
[13:53] <apw> and it'll give you the make command it uses
[13:53] <apw> there may also be a longer log in the output directory somewhere
[13:55] <apw> jpds, look in /var/lib/dkms for output directories
[13:55] <jpds> apw: More than http://paste.ubuntu.com/565862/ ?
[13:55] <apw> jpds yea
[13:56] <apw> /var/lib/dkms/bcmwl/5.100.82.38+bdcom/2.6.37-12-generic/i686/log/make.log
[13:56] <apw> as an example i have that in mine for a wireless module, and it has the output of the actual make
[13:56] <apw> note your output even tells you to looki at that file
[13:56] <apw> Consult the make.log in the build directory 
[13:57] <apw> /var/lib/dkms/oss4/4.2-build2002/build/ for more information. 
[13:57] <apw> even telling you where to find it
[13:57] <jpds> I looked at /var/lib/dkms/oss4/4.2-build2002/build/main.log, I'll check make.log.
[14:00] <jpds> apw: Actually, http://paste.ubuntu.com/565870/ is the entire contents of make.log.
[14:01] <apw> not much use is it
[14:01] <jpds> Not really.
[14:02] <apw> jpds which kernel are you using ?
[14:03] <apw> jpds, can you paste cat /proc/version_signature
[14:03] <apw> and can you also paste ls -l /lib/modules/2.6.32-28-generic/source/include/linux/limits.h
[14:04] <jpds> apw: 2.6.32-28-generic
[14:06] <apw> jpds, and the other two
[14:08] <rsajdok> apw: After that: git log --grep="Manoj"
[14:08] <rsajdok> apw: I cannot see this patch: http://kernel.ubuntu.com/git?p=manjo/ubuntu-maverick.git;a=commitdiff;h=refs/heads/lp712174
[14:11] <apw> jpds, ok i've updated the bug
[14:11] <apw> jpds, i am suspicious that the file will not exist ...
[14:12] <jpds> apw: Excellent, thanks.
[14:13] <apw> jpds, perhaps you could also check they have the headers installed for their kernel
[14:14] <jpds> apw: I believe that they're also using VirtualBox with DKMS.
[14:14] <apw> could easily be a bad assumption in this dkms package
[14:15] <apw> al-maisan, oh could you file a bug with ubuntu-bug linux when running the -3 kernel ... and let me know the bug number
[14:15] <al-maisan> apw: will do.
[14:16] <al-maisan> apw: when running the ubuntu variety of the -3 kernel. Right?
[14:16] <apw> yeah if you could, then it'll put the right version inforamtion on the bug
[14:18] <al-maisan> no problem, will do.
[14:35] <rsajdok> apw: any sugestions?
[14:43] <tgardner> ogra, what is the appropriate list to send ARM kernel upload announcements? ubuntu-mobile has bounced for me.
[14:43] <ogra> we usually use ubuntu-devel, but i guess -kernel would work as well, given that all people interested in kernel uploads of the arm team are subscribed there
[14:44] <apw> ogra, ok they are going there anyhow
[14:44] <tgardner> ogra, works for me
[14:44] <apw> (kernel-team@)
[14:44] <ogra> right, i dont think we need separate notification
[14:46] <apw> rsajdok, looking myself
[14:47] <apw> rsajdok, worked for me
[14:47] <apw> either git clone that URL or add it as a new remote in a maverick tree
[14:47] <apw> then you should have like origin/lp712174 in there which is the same as that patch
[14:48] <apw> apw@dm$ git show manjo/lp712174
[14:48] <apw> commit 58835356c5542d623a1110ed40a089e83388f4ab
[14:48] <apw> Author: Jens Taprogge <jens.taprogge@taprogge.org>
[14:48] <apw> Date:   Mon Aug 9 23:48:22 2010 -0300
[14:48] <apw>     thinkpad-acpi: Add KEY_CAMERA (Fn-F6) for Lenovo keyboards
[14:51] <al-maisan> apw: could not report the bug "ubuntu-bug linux" says "This is not a genuine Ubuntu package" :/
[14:51] <al-maisan> apw: the mainline kernel exhibits the same behaviour FWIW .. freeze upon resume
[14:52] <apw> al-maisan, ok thanks, just file a bug against any old runnable kernel then ... sigh
[14:53] <al-maisan> oh, the command is right because I am running "2.6.38-3-generic #30amd64resume201102111045" right now.
[14:53] <apw> ahhh damn yes
[14:53] <al-maisan> I think the original -3 ubuntu kernel has been overwritten
[14:53]  * al-maisan looks for it
[14:53] <apw> just use +filebug, and don't worry about apport info
[14:54] <al-maisan> ok
[14:54] <apw> its me who will whine at your for no apport info, and i'll tell me not to
[14:54] <al-maisan> hmmm :)
[15:05]  * smb grumbles about annoying LP features
[15:06] <smb> tgardner, could you get my own nomination accepted on https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/717177
[15:06] <ubot2> Launchpad bug 717177 in linux-ec2 "Import missing stable update changes into Lucid-ec2" [Medium,In progress]
[15:06] <tgardner> smb, done
[15:06] <smb> tgardner, ta
[15:23] <al-maisan> apw: please see bug #717189
[15:23] <ubot2> Launchpad bug 717189 in linux "thinkpad t410 freezes reproducibly upon resume from suspend" [Undecided,New] https://launchpad.net/bugs/717189
[15:23] <al-maisan> apw: I managed to make "ubuntu-bug linux" by reinstalling the ubuntu -3 kernel i.e. you should have full info there.
[15:49] <tgardner> apw, jjohansen: why are we considering disabling filename encryption in Natty if long filename support doesn't land in time? IMHO we're no worse off then we've been for Lucid/Maverick.
[15:53] <apw> tgardner, i don't think we should be, but people in the peanut gallary were shouting and screaming about how bad it is if you use evolution or something something else
[15:54] <apw> tgardner, so i take the view that we should review it in the open with the release team.  my recommendation is status quo
[15:54] <tgardner> apw, frankly, it would be a total regression if we disabled the feature.
[15:54] <apw> kirkland i think was of the same mind, others differed
[15:54] <apw> tgardner, it would have to be for new installs only indeed, else my shit would break
[15:55] <tgardner> absolutely
[15:55] <apw> so i don't think its trivial, or indeed sensible to regress, but it was reuqested, and that decision is above my head
[15:55] <apw> kate can figure it out :)
[15:55] <tgardner> apw, perhaps we could make it an installer option?
[15:55] <tgardner> I'd be OK with that.
[15:56] <jdstrand> I think what was discussed was new installs would not have it, but upgrades would not change
[15:56] <apw> i think to do so we'd need some engineering to mke it optional, jj would know if that exists already
[15:56] <jdstrand> it is hard to know what is going to fail
[15:56] <tgardner> apw, FNEK is already optional, its part of the mount command
[15:57] <apw> tgardner, oh ok thats good intel
[15:57] <jdstrand> for example, launchpad scripts die and so I have symlinked out of my encrypted home some launchpad dot directories
[15:57] <apw> jsalisbury, i assume you are a proponent of turning it off
[15:57] <tgardner> jdstrand, I feel your pain.
[15:57] <apw> jdstrand, even
[15:57] <jdstrand> tgardner: it is, but there is no way to adjust it via pam and the tools, aiui
[15:57] <jdstrand> and once you have it, there is really no easy way to turn back
[15:57] <apw> so basically it would be a foundations effort to make it optional
[15:57] <tgardner> jdstrand, no indeed. its a one way street
[15:58] <apw> jdstrand, i guessi a cp -rp could be used to fix it
[15:58] <tgardner> apw, yeah, its not really a kernel bug per se
[15:58] <jdstrand> apw: sure, that is what you need to do. use a pivot copy
[15:58] <apw> a "make new; cp contents, unmount old, mount new'
[15:58] <apw> ok ... so if we can fix it, then thats good, but i think someone needs to decide
[15:58] <jdstrand> but that is a pretty scary operation to automate for people
[15:58] <apw> what the if we can't fix it in time fall back is
[15:59] <tgardner> apw, jjohansen already has it working.
[15:59] <apw> 1) do nothing, 2) disable by default, 3) disable by default and offer migration back
[15:59] <jsalisbury> apw, :-)  bad tab completion 
[15:59] <tgardner> at least on xattr enabled file systems
[15:59] <apw> jsalisbury, sorry i hate tab completion :)
[15:59] <jdstrand> I was always very, very surprised it was on by default with no pam/tools configurability
[15:59] <apw> tgardner, the last version i saw still had limitations in the face of long name hard links
[15:59] <jsalisbury> apw, I'm a proponent for turning off bad tab completion lol
[16:00] <apw> jdstrand, you'd have to talk to kirkland about the default i recon
[16:00] <jdstrand> apw: I already did
[16:00] <apw> and what did he say :)
[16:00] <apw> pthththth ?
[16:00] <jdstrand> apw: you do see the current default, no?
[16:00] <jdstrand> :)
[16:00] <jdstrand> tbh, I don't think the problems were known at the time the default was set
[16:00] <tgardner> apw, even with the hard link limitation, we'd better off then we are now
[16:01] <jdstrand> I mean, the limit was known, but not the affect on the users
[16:01] <apw> tgardner, though until its upstream we are risking generating incompatible on disk stuff that we have to live with
[16:01] <apw> so we need to be really sure what he is doing will go upstream with the same on disk format, before we enable it
[16:01] <tgardner> apw, true enough
[16:02] <jdstrand> ideally, I would see filename encryption as opt in and configurable via pam. default off in the installer (without an option in the installer). when filename encryption works right, we can default to on in the installer. upgrades don't change
[16:02] <apw> release meeting ... gah
[16:02] <jdstrand> s/via pam/via pam and the tools/
[16:27] <jdstrand> apw: not sure you saw my opinion above wrt ecryptfs ^
[16:27] <apw> jdstrand, yep see it now ...
[16:27] <jdstrand> apw: on a totally unrelated note, I noticed this change in the other-n-security-apparmor bp:
[16:27] <jdstrand> - Work items:
[16:28] <jdstrand> + Work items for ubuntu-11.04:
[16:28] <jdstrand> apw: may I ask why you did that?
[16:28] <jdstrand> (ie, should we be doing something differently?)
[16:28] <apw> jdstrand, cause the blueprint didn't have a milestone and nor did the items themselves
[16:29] <apw> so they fall in the none bucket ... which is bad ... 
[16:29] <apw> you can fix either by setting them in the main blueprint, or as i did therre
[16:29] <apw> but if you do the former someone can just change that and you loose any idea where they were before
[16:29] <apw> and all your planning is affected
[16:29] <jdstrand> ah
[16:29] <apw> so ... i generallyu move them to the release milestone
[16:30] <jdstrand> I see it is accepted for natty as the series, but yes, no milestone target
[16:30] <apw> and hope that the owner will notice and fix :)
[16:30] <jdstrand> apw: ok, thanks for the info
[16:30] <apw> those burny charts cause me loads of pain :)
[16:31] <apw> sorry if i freaked you out 
[16:31] <jdstrand> apw: our team tries our best to do the right things wrt to those, but since we only commit to essential bps, we don't live and die by the burndowns and we may miss process updates, etc
[16:31] <jdstrand> apw: please feel free to call me on it if you are messing you up
[16:32] <jdstrand> hehe
[16:32] <jdstrand> if we* are messing you up :)
[16:32] <apw> :)
[17:38] <apw> JFo, hey ... can you drop the 'kernel-tracking-bug' bugs from the tag search ... they are no use to the stable team so lets drop them
[17:38] <JFo> on it
[17:38]  * apw realises he has been talking to you on mumble ... without you being therre
[17:39] <bjf> JFo, i'm looking at "run-hotlist.sh", it would be nice if there was a comment above each line which indicated who asked for that tag to be tracked and what the tag means
[17:39] <JFo> apw, heh sorry :-/
[17:40] <JFo> bjf, apw, do you guys still want the revert and reapply tagged bugs there?
[17:40] <JFo> or no?
[17:40] <JFo> bjf, ok
[17:41] <bjf> sconklin, ^ thoughts ?
[17:41] <bjf> JFo, there should be very few of them, and i think it would be nice to see, so i guess keep them
[17:41] <sconklin> thinking
[17:42] <JFo> k
[17:42] <sconklin> I think we can leave them, although I don't think we'll do anything automated with them any time soon
[17:45] <JFo> ok
[17:51] <bjf> jjohansen, you having problems with the mumble server ?
[17:52] <jjohansen> bjf: I have been kicked a few times, and sometime it doesn't log in for a while (say 10+ min)
[17:52] <jjohansen> so yeah
[17:52] <bjf> jjohansen, same here
[17:53] <tgardner> must be something between the states and Canonical
[17:58] <jpds> An ocean?
[18:08] <bjf> JFo, there appears to be a problem with the script that is generating the report, the timestamp is 17:11 which is roughly 45 minutes ago
[18:08] <bjf> JFo, i see that a new hostlist was generated
[18:08] <bjf> s/hostlist/hotlist/
[18:10] <JFo> bjf, it runs every hour
[18:10] <bjf> JFo, ah! that explains it, was thinking it was every 15 minutes
[18:10] <JFo> heh :)
[18:20] <bjf> jfo, still a problem, in "run-hotlist.sh" you are still cat-ing the SRU_TRACKING_BUGS file into HOTBUGS even though you are not updating SRU_TRACKING_BUGS and the old one still exists
[18:21] <JFo> ah, forgot that bit
[18:21] <JFo> fixing now
[18:22] <JFo> fixed
[18:23] <bjf> JFo, can you run the scripts by hand so we get a new report ?
[18:23] <JFo> sure
[18:24] <bjf> thanks
[18:25] <JFo> my pleasure :)
[18:26] <apw> bjf, it takes like 15 mins to run
[18:29] <bjf> apw, do we want it to run faster or are we ok with it taking that long
[18:37] <JFo> bjf, it is up now
[18:37] <bjf> JFo, thanks, that cut 14 off the list
[18:39] <JFo> np
[18:40] <JFo> <-food
[18:57]  * tgardner --> lunch
[19:28]  * bjf -> lunch
[19:42] <JFo> smb, you still around?
[20:53] <apw> bjf, well personally i hate anything that inefficient ... i fyou can think of tricks to speed it up ... then go for it
[20:57] <bjf> apw, if we're happy running it once an hour and if it takes 15 minutes then there are plenty of other things to work on, i've not really looked at it to see if there is anything obvious
[21:07] <JFo> I could see about running it every 30 minutes if you think that is better
[21:09] <bjf> JFo, if the length of time it was taking to run was keeping us from running more frequently or doing more of what we wanted i'd look at it
[21:10] <bjf> JFo, however, if we're happy with it the way it is (and i'm not saying i'm not) then i have no problem just ignoring it
[21:11] <JFo> heh, ok
[21:11] <JFo> I'm good either way