/srv/irclogs.ubuntu.com/2010/11/15/#ubuntu-kernel.txt

jk-m4t: shouldn't do01:04
sangeethI heard the right step to hack the linux kernel is to begin with Linux 0.01 kernel... I could get a hand on the source code, but couldn't get any guide... PLEASE HELP ME...01:14
=== bjf[afk] is now known as bjf
=== bjf is now known as bjf[afk]
rlpbCan anyone help with debugging acpi? I'm running acpiexec but not getting the same battery status as reported in /proc/acpi/battery/... . How does acpiexec emulate actual hardware?02:02
=== ayan_ is now known as ayan
kusanagihi, i am running lucid. How can i install latest kernel? or at least 2.16.36?04:45
RAOFThe lucid-maverick-backport kernel is in the archives now I think.  Either that, or it's in the kernel team PPA.04:54
kusanagiRAOF, I have backports activated in lucid, but nothing proposed. Do i have to add the ppa to get it proposed?04:58
RAOFHm, maybe.05:03
RAOFI can't see it in the lucid archives.05:03
kusanagimm ok i have added the ppa05:03
kusanagihow do i install the kernel now?05:03
kusanagiit is not proposed if i do an update && upgrade05:04
RAOFIt looks like you'd want to install the linux-meta-lts-backport-natty package05:05
kusanagicant find that package :S05:05
kusanagiwhats the difference between meta and not meta?05:06
RAOFDunno, sorry.05:06
kusanagiok, it found it without meta05:07
kusanagithanks RAOF i think i can take it from here on ;D05:07
kusanagimmm it seems there is only headers and source packages :S05:08
kusanagi:(05:08
apwman its quiet today ...10:50
smbNow you broke it. :)10:50
* apw prepares the flood gates ...10:52
apwsmb, did you sort out that bundle?  it seems you can treat filename as a remote, git ls-remote and git fetch <file> <branch>:<branch2> style things work on it10:53
smbapw, No, could not really be bothered10:54
apwanyone remember who it was who was doing cross-compilation and finding x86 binaries in the header files ?10:56
apwand indeed remember the bug number?10:57
* apw finds a multi-iso stick in his kit ... damn these are good11:17
loolSomeone knows kettgordon at gmail.com?11:47
loolalternatively, is there an admin for the Ubuntu kernel-team mailing-list around?  :-)11:47
looleveryone posting to kernel-team@ gets a message to confirm emails going to this subscriber11:48
apwlool, what do you need ?11:48
apwoh thats a lot crap11:48
loolapw: I think we should unsubscribe this guy and write him to not subscribe to mailing-list with this address11:48
apwheh welll if i write to him and it asks me to confirm, i won't bother, so they won't find out11:49
lool(He's probably subscribed with an @boxbe.com address, but the autoreplier mentions the kettgordon at gmail.com as a contract address)11:49
loolapw: Fair enough  :-)  I suppose the kettgordon gmail.com one isn't filtered though11:49
apwlool can you fwd me the autoreply ??  i don't seem to get them11:54
loolapw: done11:54
loolapw: Maybe he whitelisted @ubuntu.com, @canonical.com, but not @linaro.org (or anyone possibly posting to the list)11:54
apwlool, maybe so... seems he needs a poke for sure12:03
apwlool, ok i have sent a whining email to him on your behalf12:09
loolapw: Thanks;12:10
loolI could have done the latter part myself I realize, I went straight to listmasters because I don't want other subscribers to be annoyed :)12:10
apwyep, well you also wouldn't know whether we were all being spammed which we don't, and it sounds more appropriate coming from a list person, so it seems right12:24
krautmoin13:22
dokoapw, tgardner: any idea about  bug #673073 ?14:39
ubot2Launchpad bug 673073 in linux (Ubuntu) (and 1 other project) "<net/if.h> and <linux/if.h> are incompatible (affects: 3) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/67307314:39
tgardnerdoko, looks like an upstream issue. we'll work on it.14:40
dokothanks!14:40
apwtgardner, i wonder if its a simple case of _kernel_ round that include14:46
tgardnerapw, doko, I think this was introduced by eglibc. include/linux/if.h has not changed significantly for over a year14:47
apwtgardner, i think the file that has changed is rtnetlink.h14:48
apwwhich is triggering an include of if.h indirectly now14:48
apwcommit 24824a09e35402b8d58dcc5be803a5ad3937bdba14:48
apwAuthor: Eric Dumazet <eric.dumazet@gmail.com>14:48
apwDate:   Sat Oct 2 06:11:55 2010 +000014:48
apw    net: dynamic ingress_queue allocation14:48
tgardnerapw, ah, hadn't drilled down to that yet14:48
apwthat one brought a new include of netdevice.h to that header14:49
dokotgardner: are you sure? eglibc isn't yet updated ...14:51
tgardnerdoko, no, I'm not sure. apw pointed out changes in rtnetlink which are the likely culprit14:51
apwdoko, do you have some code which triggers this error on compilation, somethign short?14:53
tgardnerapw, the bug report does. we could just hack the local chroot copy of rtnrtlink to see if its a workaround14:54
apwtgardner, yeah going to try tha14:54
dokoapw: in the bug report, bug description14:54
apwtgardner, ok it seems that putting that include in an __KERNEL__ at least lets the example compile14:57
apwnot sure if that would be enough for elibc ....14:57
apwdoko, if i spin a test kernel with that change can you test it against your eglibc build ?14:57
tgardnerapw, you should probably send a note to Duzamet and Miller.14:58
dokoapw: sure14:58
apwtgardner, for sure14:58
=== cking is now known as cking-afk
lagdiwic: Where is your 'self help' Wiki page?15:23
diwiclag, what do you need help with?15:27
lagMy 'friend' has audio issues15:27
lagDidn't you have some scripts that was used for debugging?15:28
diwiclag, https://wiki.ubuntu.com/DebuggingSoundProblems ?15:28
diwicalthough I don't really recommend everything there, some of it is outdated15:29
lagWhat was the script I ran, which churned out lots of debug?15:29
diwichttps://wiki.ubuntu.com/Audio/AlsaInfo15:30
lagI think that's it15:30
lagIs that still in date?15:30
diwicyes15:30
lagGreat, thanks15:30
=== bjf[afk] is now known as bjf
apwdoko, could you see if the versions of linux-libc-dev fix your issue: http://people.canonical.com/~apw/rtnetlink-netdevice-include-natty/15:50
apw(i think they should)15:50
beaver74hey15:52
beaver74i have only a small question, is it possible running the AMD SB850 SATA controller in AHCI mode with 2.6.35 kernel?15:53
dokoapw: will do, my remote machine is currently not reachable ... will update the bug report15:54
apwdoko, i take it this is a blocker on you16:07
=== cking-afk is now known as cking
apwtgardner, i've copied you on the patch i've send upstream for this one16:17
tgardnerapw, ack16:20
tgardnerapw, we should just commit that for natty for now regardless of whether upstream takes it.16:21
bjftgardner, apw, http://ireport.cnn.com/docs/DOC-518781?hpt=C2   16:26
tgardnertoo weird...16:27
kamalbjf, sconklin: guess that ^^ is the same as we saw the kids playing in Cambridge then?  still seems to me that the broomsticks are superfluous here.  ;-)16:30
bjfkamal, ack, tgardner and apw and I saw another group "flying" around boston common on Sat.16:30
kamalguess they were gearing up for the 'big match' ;-)16:31
=== yofel_ is now known as yofel
dokoapw: yes, the patch works16:40
smbapw, ogasawara Could you have a quick look at https://wiki.ubuntu.com/Kernel/Dev/KernelDriverDeviations to see whether my "reason"s sounds reasonable to you as well?16:46
ogasawarasmb: sure16:47
ogasawarasmb: looks fine to me16:49
smbogasawara, ok, cheers. then we can tick that off the list16:50
=== cking is now known as cking-afk
ogasawarasconklin: just fyi re: bug 672964.  determined to not be a kernel issue and is getting resolved via udev.17:24
ubot2Launchpad bug 672964 in udev (Ubuntu Maverick) (and 2 other projects) "2.6.32-26 unbootable: does not find root file system (affects: 1) (heat: 732)" [High,Fix committed] https://launchpad.net/bugs/67296417:24
sconklinogasawara: sweet, a nice first bit of news for the day17:25
smbsconklin, Then I could add that I still got network when updating on an acer aspire one, so the other report is probably something special as well17:25
sconklinsmb: great! Should I log off now before the law of averages catches up?17:26
bjfsconklin, where are we "in the process" right now?17:27
smbsconklin, There is always something broken somewhere. Trying to escape is futile :)17:27
sconklinbjf: Today is the day we revert all unverified fixes. We'll need to actually look at each bug first, of course. I don't think we have a good tool yet to remove the buglinks from reverted patches, so we'll probably have to manually edit the changelogs after insertchanges. Sound right to you?17:28
smbsconklin, Doh! And the OS installed Maverick now. So much for reproducing...17:29
smbEh no, it was another guy on the bug 17:29
bjfsconklin, yes, sounds right, have you started17:30
sconklinbjf: no, I just sat down. Haven't even looked at the status yet17:30
ogasawarasconklin: let us know if you want help.  I'm also fixing up some build failures for the CVE's at the moment and will move on to some quick smoke testing and regression tests after that.  will send you, bjf, and smb an email with results.17:30
sconklinogasawara: thanks. I think it makes sense for bjf and I to each take a release - Maverick and Lucid are the ones to be done. What you're doing is great. I'll write some boilerplate for the bugs first, so we have consistent text.17:32
mildoehi17:33
sconklinThe number of verified fixes in lucid is disappointing17:33
mildoewhat is the major difference between RHEL and the ubuntu kernel?17:33
mildoesimilar?17:33
ogasawaramildoe: depends which version of RHEL and Ubuntu you're referring to.  and even then, I'm not sure who on this channel follows the RHEL kernel closely enough to give you a good comparison.17:35
mildoerather arent most distro kernels the same?17:36
mildoejust minor differences here and there for services and such17:36
jjohansen1mildoe: yes and no, they all derive from upstream, but will include some different sauce patches and configuration differences17:36
bjfsconklin, i'm reviewing the "verification-needed" bugs for maverick17:37
apwmildoe, RHEL is aimed at very long term stability, and therefore is most comparible with Lucid (our LTS release), otherwise our normal releases are more like Fedora releases, aimed at the latest versions of everything17:37
sconklinbjf: then I'll take lucid17:37
mildoeah17:38
mildoeso rhel and ubuntu is almost similar in most cases?17:38
mildoeok thats what i thought17:38
apwmildoe, in a very simplistic sense yes17:41
sconklinogasawara, bjf: Hmm, we haven't exactly defined the steps to take to have a fix reconsidered. How about this text in the wiki:17:49
sconklinWhen fixes are reverted due to lack of verification, they may be proposed for reconsideration by performing the following:17:49
sconklin * update the bug with a firm commitment to verify the fix during the next stable kernel release cycle (usually this will begin one week after the fix is reverted).17:49
sconklin * Send a request to the Ubuntu Kernel mailing list request reconsideration of the fix. Include the bug number, and if possible, reply to the original SRU request that was made for the fix.17:49
bjfi thought we were going to just reapply then for the next cycle?17:49
sconklinbjf: not without some commitment to test17:49
bjfwe talked about many options and i'm not exactly sure what we are doing at this point17:49
sconklinthat was my memory17:50
sconklinOriginally we were going to close wontfix, and require a whole new SRU request, but we changed to just incomplete, and now it's unclear 17:50
sconklinWe can change what doesn't work - but for this cycle, there are bugs that have not gotten any response from multiple requests to test, so I have no faith that we won't be in the same position next week as we are now if we simply reapply them17:52
ogasawarasconklin: do we really need them/us to send an email to the Ubuntu kernel team mailing list?  I suspect most users are not subscribed and it'll just add noise to the list.17:52
tgardnersconklin, regardless if they send an email they at least need to update the LP bug with some commitments17:53
ogasawarasconklin: I'd just be fine with the first bullet point and then maybe tagging the bug with kernel-patch-reapply or something17:53
sconklinogasawara: maybe your work flow is different, but if they simply reply to the bug, it'll get lost in noise for me. It won't be in the pending SRU tracking any more, and we have to way to track this class of bugs now17:53
ogasawarasconklin: indeed, hence the need for the tag17:54
sconklinogasawara: yeah, how about this:17:54
bjfogasawara, tgardner i'm with sconklin (as far as I can tell) how do we know which bugs to add without email to the list?17:54
sconklinwhen we revert we tag with stable-reverted, and when the commitment to test is added, they tag with stable-reapply17:54
ogasawarasconklin: I like that17:55
apwasking them to remove tags has generally been our way17:55
apwas they are less likley to spell the tag wrong that way17:55
sconklinit would be up to the edn user to add tags. Can anyone edit tags, or does it require special privs?17:55
sconklinend user17:55
ogasawarasconklin: unfortunately anyone can add/remove tags17:55
sconklinI've assumed all along that anyone could do it17:55
bjfsconklin, it's your call but I think doing it via tags is going to be a mess17:55
apwis not the current process tag driven though, with needs-verification etc ?17:56
sconklinbjf: what's your alternative? email to the list?17:56
ogasawarabjf: I think having to track multiple emails would be just as messy17:56
bjfsconklin, yes, email to the list just like any other patch request17:56
bjfogasawara, so we have to continuously scan bugs for the right "stable-reapply" tag? yes it can be done but it's yet another process.17:57
sconklintgardner, apw, smb, (and everyone) ^^ thoughts? Tags are a bit messy but list email subjects the entire kernel team to a bit of stable process that not everyone is interested in17:58
tgardnersconklin, I think we should use LP as the basis for our process, and that means tagging.17:58
tgardneremail is abit ad-hoc17:58
bjftgardner, trying to not be a complete ass here, but why do we ask for the inital email to the mailing list when we could just accept a "please-pull" tag on LP bugs instead?17:59
sconklinI think that the barrier for reapplication should be pretty low - i.e. someone says they'll test. So since we have two acks for the patch already, we don't need the number of eyes that we get from email18:00
tgardnerI guess because the list is lower volume then LP ?18:00
sconklinbjf: for the acks18:00
bjfsconklin, you can do the acks in the lp bug as well18:00
sconklinbut acks come from the entire kernel team, and reapplying is a part of a process that only the few team members dealing with stable process care about18:01
smbi guess the email process seemed to be more open to people not looking at specific bug reports and quicker to work with in general (for the acks)18:02
smbJust from gut feeling it seems better to work the process itself with lp and tags. Just as it seems simpler to query and process that programatically18:03
sconklinsmb: I think I agree, although we're continuing to really abuse launchpad as a process tool it was never intended to be. But it's the only tool we have.18:05
sconklinSo I think the vote is for tags. If it was a tie, I'm happy with being the tiebreaker for tags18:06
sconklinnext question - 18:06
sconklinWhen we reapply, do we revert the revert?18:06
sconklinor reapply18:06
tgardnersconklin, nah, just apply18:06
ogasawara+118:07
tgardnerit might be a different patch by then anyways18:07
sconklintgardner: doing that has the advantage of getting the correct entry in the changelog, which is important18:07
sconklinok, decided.18:07
tgardnersconklin, apw was working on a tool to futz the changelogs when a patch is reverted18:08
* manjo getting lunch will be back soon 18:08
sconklintgardner: yes, I'm aware of that - for today we'll manually deal with it18:08
sconklinbjf, ogasawara: should we make the tags release-specific i.e. "stable-reverted-lucid", as some of these bugs are against multiple releases?18:12
bjfsconklin, i guess so18:13
ogasawarasconklin: makes sense18:13
sconklincheck me on this https://wiki.ubuntu.com/Kernel/StableReleaseCadence18:15
bjfsconklin, so how much discretion are we giving ourselves in deciding the keep a non-verified patch versus reverting it?18:23
ogasawarasconklin: looks good.  I know you're going to do this, but I'd add a blurb to Details section that along with setting the bug to Incomplete for unverified patches, a comment will be posted to the bug for how they can request re-application of the patch pending their commitment to test.18:23
bjfsconklin, i have a one line quirk which fixes 7 LP bugs but didn't get verified18:24
sconklinogasawara: good point, I'll do it now18:24
sconklinbjf: who's responsible for testing18:24
sconklin?18:24
bjfsconklin, so you'd revert it18:24
bjf?18:24
mildoeapw: ok18:26
* apw doesn't think this is going to get sorted out in one pass, i think we need a solid proposal to test-execute and critique18:26
bjfsconklin, also, if a patch has 7 buglinks, do they all have to verify it fixed or is any single good enough?18:27
sconklinbjf: In general yes. If there was any sort of explanation from someone about why it wasn't testable and was safe or something, I might consider taking it, but it would be a hard call. Remember that the verification requirement is actually part of the archive admin process, and not something we can just be free about. In this case, try asking pitti what he thinks18:27
sconklinbjf: that's a very good question, and I'd take it. If it was a patch with many model numbers in the quirks, it gets harder, but still and especially for audio, if we assume that (for example) the mapping of codecs to model numbers is right, it should be OK18:28
bjfsconklin, this is essentially new process. i understand what you are saying that it is part of the archive admin process. however, since we've are just now starting to implement it, i consider it new18:28
sconklinbjf: agreed, and we are making it up as we go along . . .18:28
sconklinthe details, anyway18:29
ogasawaraif a patch fixed 7 bugs, I'd think they would all be marked as dups with one master bug?  And you then have 7x the possibility of it being verified.18:29
bjfogasawara, so the one master must be verified as fixed18:30
=== _LibertyZero is now known as LibertyZero
sconklinbjf: in that case, yeah, which is another unenforced policy step18:31
ogasawarabjf: right, you'd just pick one of the 7 to be the master, dupe the other 6 to it, and lp tells the other 6 to add comments to the master bug rather than continue using the duped bug18:31
bjfogasawara, yes, if the users have done what they are supposed to do and created a master bug18:32
ogasawarabjf: the user doesn't have to create a master bug, you as the triager/developer just choose which one you want to be the master18:33
ogasawarabjf: that's how duplicate bugs have always been handled18:33
sconklinand if they are all separate in the pending SRU for a -proposed release, you may have to individually set them all to verified18:34
bjfogasawara, i understand what you are saying, but i am not necessarily the triager and not all triagers are going to do the right thing18:34
apwtgardner, did that fixy to the rtnetlink.h make sense to you?  i am thinking if we are happy i should upload it sooner rather than later18:36
loolapw: If you upload to fix linux-libc-dev, would you mind including https://patchwork.kernel.org/patch/320712/ ?18:36
tgardnerapw, yep18:36
apwlool, that is the second patch of a pair from its commentary?  are both needed ?18:38
bjfsconklin, are we the beginning of the first week of a new cycle? if not then i assume next monday is the first week of a new cycle (it seems we are several weeks into this cycle when did it officially start?)18:41
sconklinNext week will not be the beginning of a new cycle unless a miracle happens. Once we revert, we're in a hold until testing happens, and the definition of "what's good enough" for that for the first pass will have to be made with input from QA, Cert, and the release manager.18:43
sconklinI think that most likely, we will end up running out through the next two weeks, and effectively skip a cycle18:44
tgardnersconklin, any test results from cert's dry-run ?18:44
loolapw: It's not; it's a fix for commits which are already in the Ubuntu tree18:44
sconklintgardner: in a word, no18:45
apwsconklin, who are we interfaced with over in QA for this18:45
sconklinthere were some results, but they were not all useful18:45
sconklinapw: Victor18:45
vanhoofsconklin: i'd vote heavily towards skipping a cycle ;)18:47
* vanhoof prays each night for .37 in -proposed to release :D18:47
sconklinvanhoof: it's not really up for a vote, but fwiw I hear you18:47
=== cking-afk is now known as cking
ckingoops, not been away for hours, my fail19:07
bjfsconklin, for maverick it looks like 3 reverts19:07
bjfsconklin, 8 lp bugs affected 19:08
sconklinbjf: for lucid, it's eight bugs, haven't counted how many reverts that maps to yet19:08
sconklinsome of them (most?) are the same bugs as maverick19:08
bjfyes :-)19:08
bjfsconklin, i'm going to start reverting patches, updating trees and doing builds19:17
sconklinbjf: exactly where I am. I just fetched.19:17
* tgardner lunches19:18
bjfsconklin, so we need to "startnewrelease", revert, "finish-release", then upload19:21
bjfsconklin, with building and boot testing mixed in there as well19:22
sconklinyeah, but is it insertchanges instead of "finish-release"? (along with manually editing changelog to remove buglinks on the reverted original patches19:23
bjfsconklin, there is no "finish-release", yes I meant "insertchanges" + any other final details before uploading19:24
sconklinbjf: whew19:24
* jjohansen1 -> lunch20:37
smosersmb, can you poke bug 659084 ? or jjohansen1 so we can get it on future maverick kernel udpate.20:41
ubot2Launchpad bug 659084 in linux-meta (Ubuntu) "2.6.35-22-virtual is missing nfs modules (affects: 10) (dups: 1) (heat: 145)" [Medium,Confirmed] https://launchpad.net/bugs/65908420:41
* tgardner breaks for a few hours21:12
=== tgardner is now known as tgardner-afk
bjfapw, someone going to report out status for you in tomorrows meeting?21:27
sconklinhttp://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gpu-instances/23:35
bjfsconklin, well that's just special23:36
sconklinyeah, he was attacking deprecated SHA1s but still . . .23:37
jjohansen1yeah, the cloud can make massive compute power available to anyone23:38
jjohansen1and that can be scarry, sure he was just attacking sha1 but the same thing could be applied to stuff that isn't deprecated.  How many people really have good pass phrases on things23:40

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!