| apw | JFo, the buglist is showing permissions errors | 00:45 |
|---|---|---|
| === bjf[afk] is now known as bjf | ||
| bjf | apw, LP had some downtime, could be due to that | 00:48 |
| bjf | apw, seems like it's back up, could be we need the next crontab refresh | 00:49 |
| bjf | apw, hmm, it's launchpad authentication. i want to see if it has the same error, next cron iteration | 00:53 |
| JFo | fixed | 00:54 |
| JFo | that was it bjf | 00:54 |
| JFo | failure due to LP being down | 00:54 |
| bjf | JFo, that was what i was thinking, thanks for dbl checking | 00:56 |
| JFo | no sweat | 00:56 |
| bryceh | apw, bjf, JFo, I've just written a script to check if launchpad is up, readonly, in maintenance, unexpectedly down, or about to go down for scheduled maintenance | 01:40 |
| bryceh | http://bazaar.launchpad.net/~arsenal-devel/arsenal/python-launchpadlib-toolkit/view/head:/scripts/launchpad-service-status | 01:41 |
| bryceh | I'm going to cron that to poll launchpad to see if it's up or not or expected down soon, and avoid running other cronjobs | 01:42 |
| gaurav_pawaskar | Hi All, This is Gaurav. I am new to Ubuntu development. I want to contribute to Ubuntu kernel. Can anyone mentor me through initial stages? | 03:56 |
| apw | bryceh, that is most excellent | 08:25 |
| === smb` is now known as smb | ||
| smb | apw, Morning | 08:32 |
| apw | morning | 08:39 |
| RAOF | Heidi ho, apw. | 08:43 |
| smb | RAOF, He is called Andy not Heide. :) | 08:44 |
| RAOF | :) | 08:44 |
| apw | heheh | 08:45 |
| apw | evening RAOF | 08:45 |
| apw | hi-de-ho right ? | 08:48 |
| RAOF | Tragically unhip squares might right that as hi-de-ho, yes :) | 08:52 |
| apw | ahh i am that indeed | 08:53 |
| apw | RAOF, pushed a nice shiney new kernel in last night, more drm updates of course | 08:55 |
| RAOF | I wonder how many eDP systems *that* breaks :) | 08:56 |
| apw | oh all of them :) | 08:56 |
| RAOF | ANd when e6510 systems will reliably work :) | 08:58 |
| apw | RAOF, do you have any of those E6{4,5}10 systems ? i have loads of 'critical' bugs on that and no responces to testing request | 08:59 |
| RAOF | apw: I don't, but I know that we've got at least one e6410 at Lexington, and I think there's an e6510 somewhere around, too. | 09:00 |
| apw | RAOF, i believe its them fileing the bugs, but they don't read them ... sigh | 09:00 |
| apw | i am tempted to downgrade any critical bug to wish list after 7 days of ignoring my requests | 09:01 |
| RAOF | :( | 09:13 |
| smb | apw, http://www.hdmi.org/manufacturer/hdmi_1_4/hec.aspx | 09:13 |
| diwic | apw, I'm trying to trace bug #708521. It's present as SHA 19593875 in ubuntu-natty.git, and so I assume it should be in the latest Natty upload, but the bug was not updated. | 11:14 |
| ubot2 | Launchpad bug 708521 in linux "Microphone not working on Lenovo Edge 13" [Undecided,In progress] https://launchpad.net/bugs/708521 | 11:14 |
| apw | diwic, trying to trace the fix for that bug yes ? | 11:15 |
| diwic | apw, yes | 11:15 |
| apw | AHH it came down from upstream | 11:16 |
| diwic | apw, when you update from say 2.6.38-rc3 to 2.6.38-rc4, do you care about the buglinks between those? | 11:17 |
| apw | on the development branch that doesn't work right ... hrm ... let me fiddle and see if can detect those and fix them automatically | 11:17 |
| apw | i should care about them, but i suspect the way the tooling works its missing them | 11:17 |
| apw | i should be taking account and am not. will look at how to add that to my proceedures and will write something to close them out | 11:17 |
| apw | so please leave that one as an exmaple | 11:18 |
| diwic | apw, exmaple it is sir! | 11:18 |
| apw | diwic, thanks for pointing it out | 11:18 |
| diwic | apw, can I assume that since "git log" shows 2.6.38-3.30 as the latest commit, and that one is released per https://launchpad.net/ubuntu/+source/linux , that bug is actually Fix Released? | 11:20 |
| apw | yes it should be, i can see i am missing a lot of bugs, in this process and it is trivial to detect | 11:21 |
| apw | - LP: #701271 | 11:21 |
| apw | - LP: #708521 | 11:21 |
| apw | those for the -rc3 to -rc4 update | 11:21 |
| apw | i'll get something together to sort these out | 11:21 |
| diwic | apw, thanks | 11:22 |
| apw | its so obvious that this could occur, and its a one liner to get the information in the right format to add to the changelog which would have done them automatically ... sigh | 11:23 |
| Guest80998 | can anyone tell me from where can i learn kernel programming??? | 11:48 |
| apw | that is a very wide area, if you have good C skills and some assembly skills you should not find it hard | 11:49 |
| apw | there are books about the kernel to give you overviews, but they are mostly out of date | 11:50 |
| apw | i learned by doing | 11:50 |
| Guest80998 | apw: yes i do know C..and assembly i know very few commands... | 11:51 |
| apw | then i'd recommend looking for a book about the kernel, and then pick a small area, something which interests you, and try and read and understand that bit of the kerenel | 11:52 |
| apw | and work from there | 11:52 |
| diwic | Guest80998, have you looked at http://kernelnewbies.org/ ? | 11:52 |
| diwic | there's some resources as well | 11:52 |
| diwic | s/'s/are | 11:52 |
| apw | diwic, good point indeed, a handy leaping off point, and hints as to where to find like minded people | 11:53 |
| diwic | apw, never tried that route myself though, more "here, fix this! ... Uhm, ok" | 11:53 |
| diwic | ;-) | 11:53 |
| Guest80998 | apw: ok..basically i want to learn about networking and scheduling issues in kernel programming | 11:54 |
| apw | diwic, me too, i started before it existed too ... but the "this i bust figure it out approach" worked well for me | 11:54 |
| Guest80998 | diwic: yes i am going through that link..thanks...:) | 11:54 |
| Guest80998 | diwic: i wanted to learn about kernel networking and scheduling.. | 11:58 |
| diwic | Guest80998, when you have learned scheduling, please teach me :-) | 11:58 |
| Guest80998 | diwic: sure..i will...:) | 11:59 |
| diwic | apw, seems you succeeded, got fix-released emails already | 12:08 |
| === yofel_ is now known as yofel | ||
| apw | diwic, manual based on the automated list, but yes done now | 12:37 |
| diwic | apw, maybe I'm the first one sending buglinks to upstreams to a larger extent | 12:38 |
| diwic | upstream linux i e | 12:38 |
| apw | diwic, i found a fair number of my own as well ... just an oversite in thinking on how the link detector works | 12:39 |
| === herton is now known as herton_lunch | ||
| apw | JFo, pushed a couple more changes to lp:~apw/canonical-qa-tracking/cleanup | 14:00 |
| apw | JFo, one keeps closed bugs for 20 days before expiring them | 14:00 |
| apw | JFo, second marks new and stale entries in the tables | 14:00 |
| apw | example of the output is here: http://people.canonical.com/~apw/XXX.html | 14:01 |
| apw | smb, i wonder if Fix Committed bugs are really in the same category as incomplete bugs 'pending' or something | 14:02 |
| smb | apw, Hm, would think not really. | 14:04 |
| smb | Though pending and fix commited could be. Do we have pending? | 14:04 |
| apw | well what i am saying is Incomplete and Fix Committed are both the same in the sense they both mean we are waiting on someone else and not much is needed done with them | 14:06 |
| smb | Hm well. Both are waiting states true. Though one has less work pending while incomplete is sort of not deterministic on its further way | 14:08 |
| === Quintasan_ is now known as Quintasan | ||
| apw | smb, yeah i was wondering if Fix Committed should wander down to the bottom somewhere as they are really 'done' as far as most of us are concerned | 14:10 |
| smb | Yes, that would feel better at least to me | 14:10 |
| apw | so then the question is to move them to 'Closed' which they arn't ... or down with the Incomplete ones; calling that section 'Pending' or 'Waiting on someone else' or somethign like that | 14:11 |
| smb | Personally I'd put them together with the closed ones and maybe call it "completed" or so | 14:13 |
| apw | ok sounds like something we need to discuss wider and get a decision on | 14:13 |
| apw | what do you think of the *NEW* markers etc, and of having some of the old ones on there, as in the XXX page above | 14:13 |
| smb | Think it is a good idea. Maybe they could be colourized (eg. be red), that would at least help me to catch attention... | 14:16 |
| apw | smb, i am sure they can, hmmm | 14:17 |
| apw | smb, you know we could actually colorise the bug number with this information intead | 14:27 |
| apw | or add the 'marker' in that column anyhow, as they are links changing the colour is prolly hard | 14:27 |
| apw | oh but the background is changable | 14:28 |
| smb | Yeah, I guess background would work. And surely it does not need to be in the tags section. | 14:29 |
| smb | At least for me color is quicker to catch than looking at the tags | 14:29 |
| tgardner | apw, did you catch my note yesterday that 2.6.38-3.30 withstood stress for an hour on my hoover? | 14:29 |
| apw | tgardner, yeah did, used that as the last bit of ack and uploaded it | 14:30 |
| apw | and thanks for that | 14:30 |
| tgardner | guess I ought to move those platforms out to the shop and turn 'em on full time. | 14:31 |
| apw | could be | 14:31 |
| tgardner | apw, I need to figure out a PXE boot setup so's we can test different kernels. | 14:31 |
| apw | yeah that'd be nice, thoguh without remote console we are constrained | 14:32 |
| tgardner | apw, well, I can pipe 'em both through serial | 14:32 |
| apw | smb, how about that ... if the marks are in the tags field | 14:34 |
| smb | apw, The new works for me. The stale comes in a color that is harder to catch for me | 14:36 |
| apw | any ideas of better colours? | 14:36 |
| smb | apw, Depends a bit. Bright yellow for a background would be ok. For text red would be better contrast on white but I guess you wanted to avoid red for stale | 14:39 |
| apw | yeah, let me try colouring the background on the left | 14:39 |
| === herton_lunch is now known as herton | ||
| apw | smb, what about that ... red == new, yellow == stale | 14:53 |
| apw | (in the bug column) | 14:54 |
| apw | i think i should use the green actually for that | 14:54 |
| smb | Hmmm | 14:54 |
| * smb sees less than before | 14:55 | |
| apw | yes its only 20 bugs, to get output faster | 14:55 |
| smb | ah ok | 14:55 |
| * apw regens with new colours | 14:56 | |
| smb | Is it just my monitor or is this yellow quite lame | 14:56 |
| apw | its limp | 14:57 |
| === sconklin-gone is now known as sconklin | ||
| apw | sconklin, hey what do you think to this new colorisation of the bug number, green for fresh bugs (< week old) and yellow for stale bugs (no activity for >14 days) | 14:59 |
| apw | http://people.canonical.com/~apw/XXX.html | 14:59 |
| apw | smb, sconklin, thats the full page updated | 15:11 |
| sconklin | yes, it's nice having an indication of whether bugs are old and incomplete vs new and incomplete | 15:12 |
| smb | Indeed. The only issue is that this wimpy yellow won't draw my attention. But maybe id does not need to. :) | 15:13 |
| apw | we can argue about colour, i used that more to be consistent with tone in the rest of the page, not cause i care about the specific ones | 15:14 |
| smb | apw, Sure. And I am not the best person to decide on color. I'd be a bit extreme. :) | 15:16 |
| apw | heh :) indeed | 15:16 |
| herton | I think it could have a improvement, move bugs with status 'Fix commited' to a new section, what do you think? | 15:18 |
| apw | herton, yeah we have been wondering about merging them into a renamed section with the incomplete ones, or right out with the fixed ones | 15:19 |
| sconklin | https://wiki.ubuntu.com/NattyReleaseInterlock | 15:22 |
| herton | apw, ah right I seen discussion above now, well I agree, yeah they fall on incomplete case too, pending/waiting for feedback, but I personally prefer fix commmited be in a separated section as it's is pending work from our side not user/reporter, but any way should be fine | 15:24 |
| janimo | apw, hello, as mentioned briefly at the rally, bug 715113 | 15:24 |
| ubot2 | Launchpad bug 715113 in linux "Drop versatile support" [Undecided,New] https://launchpad.net/bugs/715113 | 15:24 |
| apw | janimo, do we have the new qemu packages already ? | 15:25 |
| janimo | apw, yes, called qemu-linaro | 15:26 |
| apw | janimo, where are those going to be made available? will there be backports to lucid etc ? | 15:26 |
| janimo | apw, AFAIK Linaro will have PPAs | 15:27 |
| janimo | apw, is dropping only worth it if done across all supported series? | 15:27 |
| persia | Could we not drop the support for older releases? There's too much transition pain for users. For natty, everyone ought be happy. | 15:27 |
| apw | lucid is a consideration because of its LTS status | 15:28 |
| JFo | apw, here now. Apparently the power flickered last night and the backup battery for my alarm is dead. :-/ | 15:28 |
| JFo | pulled the changes and looking at them now | 15:28 |
| persia | apw, https://wiki.ubuntu.com/LucidLynx/ReleaseManifest doesn't have any ARM products listed as LTS, if that makes any difference. | 15:29 |
| persia | Nor any versatile products, for that matter :) | 15:29 |
| apw | persia, no i was most thinking of people using older releases as build infrastructure which is where this kind of thing is used | 15:30 |
| apw | janimo, thanks for the heads up, i'll start some discussion with the main consumers of that flavour and see what they care about | 15:31 |
| persia | To make sure we're not already in agreement: I'd like to keep versatile for lucid so that folks running lucid qemu/versatile don't need to change anything. | 15:31 |
| apw | we'd not change somethign like that on lucid after release | 15:32 |
| apw | this is for natty | 15:32 |
| persia | Ah, OK. I'm all in favour of dropping for natty and future :) | 15:33 |
| janimo | apw, PPA from Linaro https://launchpad.net/~linaro-maintainers/+archive/tools/ | 15:34 |
| janimo | apw, so both lucid and maverick are there | 15:34 |
| janimo | apw, right, I only meant natty .As far as the ARM team is concerned we don't care about versatile in this cycle and I understood dropping it helps with build time | 15:35 |
| apw | janimo, ok just talking with our arm folks and they are going to think about it, do some testing and update the bug | 15:36 |
| janimo | apw, thanks | 15:37 |
| janimo | apw, out of curiosity is it a public channel this talking to arm folks going on? | 15:38 |
| apw | janimo, oh yeah, over on #ubuntu-arm | 15:38 |
| apw | nothing behind the curtain :) | 15:38 |
| * janimo slaps forehead and looks at backscroll in #ubuntu-arm | 15:39 | |
| * janimo is one of our arm folks :) | 15:41 | |
| persia | But as with all things, it's best to ensure least surprise. | 15:42 |
| janimo | persia, true but I'd thought I file this sooner than later, to give time to process the bug and save a few hours on as many kernel builds as possible | 15:43 |
| persia | Indeed. Filing bugs is good. Should be done early and often :) | 15:43 |
| === herton is now known as herton_away | ||
| sforshee | mjg59, I haven't seen this patch appear in any public trees yet, did it get forgotten? | 15:53 |
| sforshee | http://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg01088.html | 15:53 |
| mjg59 | sforshee: Ah, sorry. I'll grab that | 15:54 |
| sforshee | mjg59, np, thanks | 15:54 |
| tgardner | bjf, I found a machine that looks like it supports dapper. its so old that it won't detect a USB keyboard at boot. | 16:20 |
| bjf | tgardner, heh | 16:20 |
| cking | is it steam powered? | 16:23 |
| bjf | cking, http://www.flickr.com/photos/jwhilde/sets/72157618502033063/ | 16:24 |
| tgardner | cking, AMD athlon single core | 16:25 |
| bjf | tgardner, cking, yes it is steam powered: http://www.flickr.com/photos/jwhilde/3551780793/in/set-72157618502033063/ | 16:25 |
| cking | LOL | 16:26 |
| tgardner | someone has _way_ too much time on their hands | 16:27 |
| * smb just discovered an amd slot-a board in his cupboard of ancient technology that even has an isa slot... | 16:33 | |
| * amitk just threw out a creative labs isa soundblaster while making space for HW a few weeks ago, scary how big it was... | 16:34 | |
| smb | Indeed, did not even remember how large the isa slot was. :) | 16:35 |
| === herton_away is now known as herton | ||
| apw | heh ... hardware reminicing | 16:44 |
| apw | i have have voodoo-1 card somewhere | 16:44 |
| apw | JFo, about ? | 16:45 |
| JFo | apw, yep | 16:45 |
| apw | chat time ? | 16:45 |
| JFo | sure, one sec... | 16:45 |
| apw | JFo, balcony me when you get there | 16:46 |
| JFo | ok | 16:46 |
| JFo | my desktop just froze | 16:46 |
| apw | heh | 16:46 |
| apw | good old natty | 16:46 |
| JFo | yup | 16:46 |
| JFo | huh, and then rebooted | 16:47 |
| apw | la la la can't hear you ... literally | 16:47 |
| JFo | heh | 16:47 |
| amitk | JFo: my desktop freezes and bring me back to the gdm prompt about 3 times a day, its fun. | 16:49 |
| JFo | amitk, I feel for you. I hope this doesn't start a trend for me :-/ | 16:49 |
| apw | kees, about ? wondering if you could test your bug #712075 ... | 16:58 |
| ubot2 | Launchpad bug 712075 in linux "[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid" [High,Incomplete] https://launchpad.net/bugs/712075 | 16:58 |
| apw | kees, if i get some testing i can then ack the upstream patch too :) | 16:59 |
| JFo | apw, ready to try again? | 17:00 |
| JFo | I think I have it fixed now | 17:00 |
| sconklin | http://freegeographytools.com/2011/how-the-fcc-plans-to-destroy-gps-a-simple-explanation | 17:02 |
| apw | hey bryceh when you did lp type things did you ever work out how to find out if a bug is Incomplete with response etc ? | 17:49 |
| bryceh | apw, I didn't look at that bit of code directly, but what I think it does is compare the date that the bug went Incomplete with the date of the last comment | 17:56 |
| apw | bryceh, any idea how i'd find the first date ? | 17:57 |
| bryceh | apw, yeah there's several dates exposed in the api, let's see | 17:58 |
| bryceh | (browsing through https://launchpad.net/+apidoc/devel.html) | 17:58 |
| bryceh | ok, looking at https://launchpad.net/+apidoc/devel.html#bug_task there is date_created which is the first date when it was created, and date_incomplete when it was marked incomplete | 17:59 |
| bryceh | you can get a list of all the comments from the bug object (for comment in my_bug_task.bug.messages:) | 18:00 |
| * apw looks | 18:00 | |
| bryceh | then each comment has a date... comment.date_created | 18:00 |
| apw | well there is a date_last_message which is the other half, so i am good there | 18:01 |
| apw | i don't have a date_incomplete on the lpltk interface | 18:01 |
| bjf | apw, the lpltk can get you a python collection of the comments and each one has a date_created property | 18:01 |
| apw | bjf i think i have that date already on the bug, which has a date_last_message | 18:03 |
| bjf | apw, yes | 18:03 |
| apw | and i've just added a date_incomplete to the lpltk task and that seems to work | 18:04 |
| apw | and i think the delta of those two is what bryceh was saying the search uses to compare ... | 18:04 |
| apw | who maintains lpltk ?? | 18:04 |
| bjf | apw, bryce and i do for the most part | 18:05 |
| apw | ahh ok ... then i'll let you know if this works :) | 18:05 |
| kees | apw: I'll give it a shot; .38 was oopsing left and right for me earlier. | 18:05 |
| apw | bjf, ok that matches what launchpad says ... thanks bryceh ... | 18:06 |
| bryceh | apw, sure | 18:06 |
| apw | i will get you a merge request up shortly with the new lpltk accessor we need, but otherwise its easy :) | 18:07 |
| bryceh | awesome :-) | 18:09 |
| apw | as it seems to expose all of the dates for each state, it is entirly possible we could work out the previous state from that | 18:12 |
| apw | and put it back :) | 18:12 |
| bryceh | :-) | 18:13 |
| bryceh | apw, that's a functionality I've wanted to have myself... auto-reset back to Incomplete without response, when the person(s) commenting aren't relevant people | 18:14 |
| bryceh | if that's what you're aiming for implementing, I say yay! | 18:15 |
| apw | heh not, but i would also love that | 18:15 |
| bryceh | troublingly, I just noticed I'm on .38-1, need to reboot to .38-2. brb | 18:15 |
| apw | hmmm, not good | 18:16 |
| cking | check this out: http://www.ubuntu.com/certification/catalog | 18:27 |
| * tgardner --> lunch | 18:39 | |
| apw | bryceh, ok the branch is here: https://code.launchpad.net/~apw/arsenal/python-launchpadlib-toolkit-task_date_accessors/+merge/49272 | 18:56 |
| apw | (well the merge for it) | 18:56 |
| bryceh | apw, got it, looking now | 18:57 |
| apw | bryceh, if you are preferring to be more minimal, i only _need_ date_incomplete | 18:57 |
| apw | and i can respin it with just that if you prefer | 18:57 |
| bryceh | yep, looks good | 18:58 |
| bryceh | nah this is fine | 18:58 |
| apw | http://people.canonical.com/~apw/XXX.html <-- JFo that now has incomplete with in the open section and without in the incomplete section | 18:58 |
| JFo | nice :) | 18:59 |
| apw | bryceh, i expect i'll be using the other ones pretty soon :) | 18:59 |
| JFo | so only 6 incomplete waiting for us | 18:59 |
| JFo | cool | 18:59 |
| bryceh | something's effed up with the diff though - https://code.launchpad.net/~apw/arsenal/python-launchpadlib-toolkit-task_date_accessors/+merge/49272/+preview-diff/+files/preview.diff | 19:00 |
| bryceh | but no biggie, I'll just use the commit diff | 19:00 |
| apw | JFo, you'll need to update your lpltk once bryce has sucked up my fixes ... then you'll want the changes from: https://code.launchpad.net/~apw/canonical-qa-tracking/cleanup | 19:01 |
| JFo | ok | 19:01 |
| JFo | will fix | 19:01 |
| apw | we need a new date accessor from lpltk to find out if there is a comment since incomplete | 19:02 |
| JFo | ugh, I made too much for lunch | 19:02 |
| bryceh | fixes sucked up | 19:02 |
| JFo | k | 19:02 |
| * apw suggests a fridge portion and a you portion | 19:02 | |
| bryceh | apw is being quite helpful this morning! | 19:02 |
| apw | heh ... don't get used to it :) | 19:02 |
| bryceh | solving all sorts of problems :-) | 19:03 |
| bryceh | hang on I got a sheaf of bug reports... | 19:03 |
| bryceh | ;-) | 19:03 |
| JFo | k, pulled new lplib-tk | 19:04 |
| JFo | grabbing cleanup | 19:04 |
| JFo | k, changes pushed | 19:07 |
| JFo | going to fixup cranberry | 19:07 |
| apw | JFo, its likely running right now | 19:08 |
| apw | JFo, we need to stop the 'upstream tersting and latest devel testing' for bugs with 'kernel-tracking-bug' and 'kernel-cve-tracker' its just noise | 19:09 |
| JFo | yep | 19:10 |
| JFo | it should be stopped | 19:10 |
| JFo | I added those tags to the -new script | 19:10 |
| JFo | and I have added that to the flow diagram | 19:10 |
| JFo | so it shouldn't be an issue anymore | 19:11 |
| apw | ok cool | 19:11 |
| JFo | but your mileage may vary :P | 19:11 |
| apw | get that on your status report :) | 19:11 |
| JFo | heh, ok | 19:11 |
| apw | JFo, once we have gone through all of the regression-proposed bugs and dispositioned them, we need to go through all the Undecided ones and set a priority ... | 19:12 |
| JFo | ok | 19:12 |
| * JFo adds to the TODO | 19:12 | |
| apw | bjf, sconklin, do we have a standard prio for all of your tracking bugs? wishlist or a real prio ? | 19:13 |
| bjf | apw, i've not been putting a prio on any of them | 19:13 |
| sconklin | prio shouldn't matter - they are simply process trackers | 19:14 |
| bjf | apw, at least not the release tracking ones | 19:14 |
| bjf | apw, for the CVEs i've just been putting "low" | 19:14 |
| apw | yeah i know, normal triage says 'take all undeicded and give them appropriate prio' which is confusing as there is none | 19:14 |
| apw | bjf, for cves i think they should match the prio of the cve | 19:14 |
| bjf | apw, probably | 19:14 |
| apw | so perhaps trackers are just wishlist or something | 19:15 |
| bjf | apw, but i'm fixing them, the are being committed, the bug is really just a tracker as i create the patch so prio doesn't really matter | 19:15 |
| apw | bjf, indeed, but how does a nieve triager know that those ones should be ignored | 19:16 |
| apw | we are making process which requires a lot of knowledge increasing barrier to entry | 19:16 |
| bjf | apw, ah! the mythical "helpful community triager" | 19:17 |
| JFo | heh | 19:17 |
| apw | well i've spun the list three times and had to ignore yours specifically each time | 19:17 |
| apw | JFo, ok the concensus is that 'tracking bugs for stable' should be Medium priority if they don't have priority | 19:20 |
| JFo | ok | 19:21 |
| apw | for when you do that run through | 19:21 |
| * JFo makes a note | 19:21 | |
| JFo | k, the report has run and is up to date with the changes | 19:25 |
| bjf | apw, tracking bugs: i'm marking status to "in progress", importance to "medium" and assigning them to the "Canonical Kernel Team" | 19:26 |
| bjf | sconklin, JFo, ^ | 19:27 |
| JFo | bjf , k | 19:28 |
| JFo | makes sense to me | 19:28 |
| bdmurray | hallyn: is there a reason bug 689974 is fix committed instead of fix released? | 20:07 |
| ubot2 | Launchpad bug 689974 in linux "frequent failure to boot with 2.6.37-9-generic #22-Ubuntu" [High,Fix committed] https://launchpad.net/bugs/689974 | 20:07 |
| bdmurray | oh I think I get it now - you'll set to FR after testing later? | 20:09 |
| apw | bdmurray, no i think its probabally lost | 20:11 |
| apw | i don't think there is any chance of it moving as the change is clearly already out if he no longer has the problem on 2.6.37-12.26 | 20:12 |
| apw | bdmurray, i've asked serge to check on it and move it so | 20:13 |
| bdmurray | apw: thanks | 20:13 |
| bdmurray | apw: a while ago didn't you move all the linux-meta bugs to linux? I've run across some being filed about linux-meta again and was thinking we could just automate that. | 20:14 |
| komputes | Hi JFo, mainline kernel tested on X31, still no battery recognized (see recent attachment) - http://pad.lv/701561 | 20:22 |
| apw | JFo, is the arsenal linux-meta to linux | 20:28 |
| apw | mover no longer running ? | 20:28 |
| apw | see bdmurray comment above | 20:29 |
| JFo | for some reason I think I see something running as you occasionally | 20:31 |
| JFo | do you have one going? | 20:31 |
| JFo | I don't run one that I know of | 20:31 |
| apw | nope doesn't run as me | 20:31 |
| JFo | hmmm | 20:31 |
| JFo | I know we have something | 20:31 |
| apw | only in the bad old days before i gave it to you | 20:31 |
| JFo | ah | 20:32 |
| JFo | maybe that is what I am thinking of | 20:32 |
| apw | its one of the ones in the main arseel run script as far as i know | 20:32 |
| JFo | I will look | 20:32 |
| JFo | ok | 20:32 |
| apw | this whole thing needs review, as we should be running the main passes at least every day | 20:33 |
| JFo | yup | 20:33 |
| JFo | that is the end goal I hope to have going soon-ish | 20:33 |
| apw | well i am a little confused as some months ago it was reported we were now running them daily, and 'no longer as jfo' but as the kernel-janitor | 20:35 |
| apw | so what happened to stop them | 20:35 |
| JFo | we were | 20:35 |
| JFo | I noticed broken logic in them | 20:35 |
| JFo | so I stopped running them | 20:35 |
| JFo | hence the items in the blueprint to determine what they are doing and fix them | 20:36 |
| JFo | it is just taking forever to get done along with everything else</excuse> | 20:36 |
| apw | well i suspect that its starting to show we're not doing those basics | 20:36 |
| JFo | yes, it is | 20:36 |
| JFo | and it has been for some time | 20:37 |
| apw | so perhaps we need to get together and review and restart at least the basic ones like that one | 20:37 |
| JFo | we are well behind where we need to be | 20:37 |
| JFo | ok | 20:37 |
| apw | that cannot be broken as its so trivial | 20:37 |
| JFo | I don't think I've ever run that one | 20:37 |
| JFo | so that has never been getting run by me | 20:37 |
| apw | it was in the 'runall.sh' or whatever it was called | 20:37 |
| JFo | hmmm | 20:37 |
| apw | so it should have been running | 20:37 |
| JFo | I don't see it | 20:39 |
| JFo | still looking | 20:40 |
| apw | JFo, ok in my copy of arsenal, there is a RUN ... which has as its 4th line 'retarget-new-bugs.py' | 20:40 |
| apw | thats the one which does it | 20:41 |
| JFo | ah | 20:41 |
| JFo | yep, I recall that now | 20:41 |
| JFo | can I get a new brain with bigger memory? kthxbai | 20:42 |
| JFo | that is even in my crontab and I missed it | 20:42 |
| JFo | sigh, now I have the hiccups | 20:43 |
| JFo | :-/ | 20:43 |
| JFo | brb, gotta do something about these | 20:45 |
| cking | that's all folks! | 21:00 |
| * jjohansen -> lunch | 21:10 | |
| komputes | herton_: you da man! | 21:26 |
| herton_ | komputes: ? :) | 21:26 |
| komputes | herton_: re:acpi=off | 21:32 |
| komputes | good call ;) | 21:32 |
| herton_ | komputes: ah yes, you reported the bug, or just looking at it? | 21:32 |
| komputes | herton_: working with the reporter | 21:33 |
| bjf | JFo, for assigning a bug to the team, i see that both "canonical-kernel-team" and "ubuntu-kernel-team" have been used, do we have a preference ? | 21:48 |
| tgardner | bjf, ubuntu-kernel-team is public | 21:49 |
| JFo | I personally don't have one, I guess it depends on who we want to have getting e-mail on them | 21:49 |
| JFo | and tgardner is, of course, right | 21:49 |
| JFo | I prefer Canonical- | 21:49 |
| JFo | if I were to prefer one | 21:49 |
| tgardner | JFo, but that severley restricts the audience | 21:50 |
| JFo | true, but that goes back to my 'depends who you want to have mail from it' statement | 21:51 |
| JFo | :) | 21:51 |
| * JFo splits hairs | 21:51 | |
| tgardner | JFo, for public bugs it ought to be anyone who's subscribed to the ubuntu-kernel team | 21:51 |
| tgardner | if they don't like the email, then they can unsubscribe | 21:52 |
| JFo | :) | 21:52 |
| bjf | there are 52 active members in u-k-t and 29 in c-k-t | 21:52 |
| * tgardner --> outta here | 21:55 | |
| bladernr_ | anyone around who can answer what's probably a simple question about cpuinfo and sysfs? | 22:06 |
| hyperair | !ask | 22:07 |
| ubot2 | Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) | 22:07 |
| JFo | lol bladernr_ | 22:07 |
| bladernr_ | the question is: where does the data in /proc/cpuinfo and /sys/devices/cpu/cpuX come from? same souce or do they get their data in different ways? | 22:07 |
| bladernr_ | sorry, was actually trying to phrase and type the question but hyperair beat me to it | 22:08 |
| hyperair | bladernr_: use the source, luke ;-) | 22:09 |
| * bladernr_ isn't smart enough to understand kernel source | 22:09 | |
| bladernr_ | otherwise I wouldn't have asked :) | 22:09 |
| hyperair | heh | 22:10 |
| hyperair | nor am i, so i can't answer ;-) | 22:10 |
| bladernr_ | and sadly, a google search with the phrase /proc/cpuinfo yields a lot of noise | 22:11 |
| hyperair | bladernr_: actually, what do you want to know? | 22:12 |
| bladernr_ | Well, I want to know if the data in cpuinfo and /sys/devices/cpu/cpu* comes from the same place, or if they each get data from the CPU directly using different mechanisms | 22:13 |
| hyperair | er sorry, my brain slipped | 22:13 |
| bladernr_ | Is it worth my time writing code that will pull the data from each location and then compare core and physical package IDs to ensure they map 1:1 (as a test case) | 22:13 |
| hyperair | i meant why | 22:13 |
| hyperair | no it's not worth your time | 22:13 |
| bladernr_ | ok... that makes life easier :) | 22:14 |
| hyperair | =p | 22:14 |
| hyperair | at the very least, the CPU IDs are fixed | 22:14 |
| hyperair | across the kernel | 22:14 |
| hyperair | including the process affinity stuff | 22:14 |
| bladernr_ | ok. Cool. | 22:15 |
| bladernr_ | Thanks | 22:15 |
| bladernr_ | :) | 22:15 |
| hyperair | :) | 22:15 |
| hyperair | now then, my left-right hand coordination is suffering, so i think i should head to bed | 22:16 |
| * hyperair has to leave for work in 3 hours. how wonderful ¬_¬ | 22:16 | |
| JFo | bladernr_, I think it depends on what you are hoping to accomplish | 22:20 |
| JFo | if you are just trying to determine that they are different, then no | 22:21 |
| apw | bladernr_, they are basically different expressions of the same data ... /proc being the older | 22:34 |
| bladernr_ | apw: ack... heh... this was an example of me mindlessly solving a non-existant problem ;-) then realizing it later | 22:35 |
| hallyn | bdmurray: changed the status per apw's comment. just wasnt sure whether it would come back :) | 23:08 |
| bankix | Good morning. | 23:25 |
| bankix | I need some help building an own kernel package for ubuntu | 23:25 |
| bankix | I need a special patch in the kernel and would like to go the usual way by creating a new kernel package. | 23:26 |
| bankix | Therefore I applied the patch, then updated the debian.master/changelog. | 23:26 |
| bankix | The main problem is the version string for my package | 23:27 |
| bankix | In the changelog, I used "linux (2.6.32-28-ctbankix1)". | 23:28 |
| bjf | bankix, yes, that would be a problem | 23:29 |
| bankix | With that version string, the version detection will fail and the constant LINUX_VERSION_CODE is empty in include/linux/version.h -- which will stop building the kernel with a compiler error. | 23:30 |
| bjf | bankix, you could change the "-ctbankix1" to ".<some build number>~ctbankix1" | 23:30 |
| bankix | Ah, tilde instead of dash? | 23:30 |
| bjf | bankix, yes | 23:30 |
| bankix | ... stupid me... | 23:31 |
| bjf | bankix, but it probably wants the build number in there as well (don't know for sure) | 23:31 |
| bankix | OK, so I just add "~ctbanix1" to the present version string in the changelog? | 23:32 |
| bjf | bankix, for example: "2.6.32-28.86~mine" | 23:33 |
| bankix | Thanks, I'll try right away :-) | 23:33 |
| bjf | bankix, there is nothing special about the tilde, however period and hyphen *do* have special meaning, that's what you stumbled into | 23:34 |
| persia | '~' also has a special meaning. | 23:35 |
| bankix | I was using a dash up to now to change the version in other ubuntu packages. | 23:36 |
| bankix | Should I generally switch to the tilde? | 23:36 |
| persia | '~' sorts *before* nothing, which means that if 2.6.32-28.86 is installed, 2.6.32-28.86~mine will be perceived as a downgrade. | 23:36 |
| persia | 2.6.32-28.86mine or 2.6.32-28.86+mine are both probably safer. | 23:37 |
| bankix | Hm. | 23:37 |
| bankix | So plus? Or no seperator? | 23:38 |
| persia | bjf, Is '+' treated specially by the kernel versioning scripts? | 23:38 |
| bankix | What should i choose? | 23:38 |
| bjf | persia, don't know, i've not looked at them for how versions are treated | 23:39 |
| persia | Heh. | 23:39 |
| persia | bankix, Keep trying different things until you find something that works :) | 23:39 |
| bankix | I could just give the + a try :-) | 23:39 |
| bjf | persia, i'd gotten in the habit of using a ~ but didn't know about the *before* | 23:40 |
| persia | Yeah, '~' has a special meaning, so that one can do "just before" versioning, which is useful for stuff like backports. | 23:40 |
| persia | e.g. 1.2.3-4 is an upgrade from 1.2.3-4~backport, so that users get pushed over ABI transition boundaries, etc. | 23:40 |
| persia | Because it was popular for backports, someone added it to some documentation on how to make a new version, but not quite (so you could revise again before release, if you like), targeting developers. | 23:41 |
| persia | And that documentation ended up being spread widely, unfortunately. Some has been fixed to recommend working on 1.2-3+mine rather than 1.2-4~mine for an upgrade from 1.2-3, but lots hasn't, and you likely got caught by one of the old ones (you are very much not alone) | 23:42 |
| persia | Err, that should read "for a private upgrade from 1.2-3" | 23:42 |
| bankix | OK, another question: I don't want my kernel being replaced by a newer version. Up to now I used apt-pining for this, pining the version and giving it a pin-priority of 1001. | 23:42 |
| persia | That's the safest way. | 23:42 |
| bankix | But that doesn't work, I'm offered updated kernels anyway. | 23:43 |
| bankix | (the kernel just can't be replaced due to a readonly filesystem, so any update will exit with errors) | 23:44 |
| bankix | Any idea how to "pin down" my own kernel properly? | 23:47 |
| persia | pinning should offer you new kernels, but never install them unless you explicitly install it. If that isn't working, file a bug against your package manager. | 23:48 |
| bankix | Oh, it asks for permission. | 23:48 |
| bankix | But I don't want the offer at all. | 23:48 |
| bankix | Maybe I should rename tha package? | 23:48 |
| persia | That's another option, although it raises different complications. | 23:49 |
| bankix | e.g. to "ctbankix-linux-*" and add a "Provides" line to the package file? | 23:49 |
| === sconklin is now known as sconklin-gone | ||
| bankix | What complications would I have to face probably if I rename it? | 23:50 |
| === bjf is now known as bjf[ack] | ||
| bankix | or how would you solve this? | 23:52 |
| bankix | I'm open for any advices :-) | 23:52 |
| bankix | btw: the + seems to solve my versioning problem, thanks a lot! | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!