| === chris-qBT_ is now known as chris-qBT | ||
| === TheMuso` is now known as TheMuso | ||
| lamont | so if I have an SMP box and I want a process and all of its children to run on one processor (and pretend that we are uni-processor), is there anyway short of booting a non-smp kernel or firing up a kvm guest with one processor? | 00:20 |
|---|---|---|
| stgraber | lamont: "echo 0 > /sys/devices/system/cpu/cpu1/online" will turn of cpu1 (at least it do here) | 00:24 |
| lamont | ah.well... it'd be nice to leave the other processors running, to handle the rest of the machine... | 00:25 |
| stgraber | right, maybe cgroups can do that | 00:25 |
| lamont | but if I must, I suppose that'll do - trying to figure out if something is really non-smp safe or not... seems to work just fine on a UP hardy box, not so well on a SMP karmic box | 00:25 |
| lamont | though if it actually finishes on the hardy vm, I'll just smash it against a karmic uniproc (32-bit) box, and see if that works too | 00:26 |
| lamont | hrm... I wonder... is 6GB of RAM and 4cores a bit overkill for a firewall box? | 00:27 |
| stgraber | it tends to be ;) | 00:28 |
| lamont | it was available, dammit | 00:29 |
| stgraber | (says the one using a Q6600 as his firewall + router at home ... ;)) | 00:29 |
| lamont | actually, just pulled 2 of the 2GB sticks from it (dropping it to 6GB) due to single bit ECC errors | 00:29 |
| lamont | nothing quite like a binary search in memtest | 00:29 |
| === corp186_ is now known as corp186 | ||
| === Hellow_ is now known as Hellow | ||
| === asac_ is now known as asac | ||
| === mjg59` is now known as mjg59 | ||
| === fddfoo is now known as fdd | ||
| slytherin | apw: can you please take a look at bug 506546 when you get time. | 07:26 |
| ubot3 | Malone bug 506546 in linux-ports-meta "Bump version for karmic-security" [High,Confirmed] https://launchpad.net/bugs/506546 | 07:26 |
| csurbhi | smb, hello ! | 08:32 |
| smb | morning csurbhi | 08:33 |
| slytherin | smb: can you please take look at the bug I mentioned? | 08:34 |
| csurbhi | smb, did you get a chance to look at the 2.6.31.10 stable update mail ? | 08:35 |
| csurbhi | do you think it looks good ? | 08:35 |
| csurbhi | (apart from the buglink rtg mentioned about ?) | 08:35 |
| smb | csurbhi, I will do when looking through your post. I have not get gotten there as I was hit by some problems on the Lucid update | 08:35 |
| csurbhi | or is there anything i should do better ? | 08:35 |
| csurbhi | ok.. | 08:35 |
| smb | Please give me time :) I am just one old man ;-P | 08:35 |
| csurbhi | smb, hey... u are doing too much :) besides i am hogging your time :) | 08:36 |
| csurbhi | smb, just for letting you know.. as you suggested.. i have added the buglink to the sru tracing bug and signed the patches | 08:36 |
| csurbhi | but not acked them.. i thought that they should be acked after the review ? | 08:37 |
| csurbhi | i hope that was right :) | 08:37 |
| smb | Ah, its ok. Ok, cool, sure. I'll go through your mail immediately and see how it looks. | 08:37 |
| csurbhi | ok.. thanks a lot :) | 08:38 |
| smb | csurbhi, Right one question. As Tim noted, the links in the bug are malformed. Did you put in all manually? | 08:39 |
| csurbhi | actually no.. i did not | 08:39 |
| csurbhi | i just right clicked and pasted them.. but i did that late at night... maybe sleep disoriented my sense :( | 08:40 |
| smb | Hm, then there is a case that the script should catch | 08:40 |
| smb | Oh, wait | 08:40 |
| csurbhi | the link in the patch.. i added through the maintool.. | 08:40 |
| csurbhi | but in the email.. by right clicking | 08:40 |
| csurbhi | and then i sent the email | 08:40 |
| csurbhi | is there any tool for doing that too ? | 08:41 |
| smb | Hm, but look there http://kernel.ubuntu.com/git?p=surbhi/ubuntu-karmic.git;a=commit;h=0d2fb5a37a483f422186ba028d93f0985cc5bf40 | 08:41 |
| smb | Seems it is wrong in the patches | 08:41 |
| smb | Which means you found something the script should not do | 08:41 |
| smb | Do you remember how you called it to get that result? | 08:42 |
| smb | Ah, seems "maint-modify-patch --bug =<nr> file" is handled incorrectly | 08:45 |
| csurbhi | oh ! | 08:47 |
| smb | I need to fix that. The script should either throw an error or remove the = in that case. | 08:48 |
| csurbhi | hmmm.. | 08:48 |
| csurbhi | so what do i do now ? | 08:48 |
| smb | The simplest way (maybe only for me) would be to export the patches again from your tree, then do some sed magic to fix the buglink and ten re-import them after resetting the head. Then you can replace your repo with "git push origin +master" | 08:50 |
| smb | Err, replace +master with +<your branch name> | 08:51 |
| smb | csurbhi, Oh, an another thing: that repo you have. Is that a separate working tree with your private repo as origin? | 08:52 |
| csurbhi | i pushed from my machine yes | 08:53 |
| smb | Just one "trick" one can but does not need to use. You could have our main tree and then add your repo as a remote. This allows you to fetch the current stuff and easily push it to your repo. | 08:55 |
| smb | So instead of "git push origin <branch>" you would say "git push <myrepo> <branch>" | 08:56 |
| csurbhi | it push surbhi@kernel.ubuntu.com:/srv/kernel.ubuntu.com/git/surbhi/ubuntu-karmic.git <my branch> | 09:00 |
| csurbhi | s/it/I did this:/ | 09:00 |
| csurbhi | smb, i will do this today again | 09:03 |
| csurbhi | and should i resend the email again then ? | 09:03 |
| csurbhi | smb, I invoked the script as follows: | 09:04 |
| smb | csurbhi, try this: "git add remote myrepo surbhi@kernel.ubuntu.com:/srv/kernel.ubuntu.com/git/surbhi/ubuntu-karmic.git" | 09:04 |
| csurbhi | ./maintools -b = <bugnumber> * | 09:04 |
| smb | then you can next time do a "git push myrepo +mybranch" | 09:05 |
| csurbhi | the directory only had patches in it | 09:05 |
| smb | No need to send the email again (if there is not other things) | 09:05 |
| csurbhi | ok | 09:05 |
| csurbhi | will do that :) | 09:05 |
| csurbhi | thanks again :) | 09:06 |
| smb | np :) | 09:07 |
| apw | smb, so once you got booted did you mmc card survive the suspend? | 09:30 |
| smb | apw, You logged off a second to early yesterday. :) I was about to tell you that I cannot suspend anymore with a sd/mmc card mounted. On the positive side the card is not damaged in the process and it is the same with the -10 kernel. | 09:32 |
| apw | smb, oh so somthing userspace has changed to prevent it | 09:32 |
| apw | or just you never can now | 09:32 |
| apw | hrm | 09:32 |
| smb | apw, Probably that or the other, though I was too tired to bother to get to the bottom of it yesterday. | 09:33 |
| smb | Have you had a run on your system? | 09:33 |
| smb | apw, btw, S on boot hangs the same | 09:33 |
| apw | yeah am running on it here, seems ok | 09:33 |
| apw | smb, hrm, sounds like it needs a bug then | 09:34 |
| smb | Yeah, we need something. Just idling around forever is not very intuitive | 09:36 |
| slytherin | apw: Can you please sponsor this upload - bug 506546 | 09:41 |
| ubot3 | Malone bug 506546 in linux-ports-meta "Bump version for karmic-security" [High,Confirmed] https://launchpad.net/bugs/506546 | 09:41 |
| apw | slytherin, looking ... | 09:46 |
| apw | TheMuso, any reason we haven't bumped linux-ports-meta there? | 09:58 |
| apw | (for karmic) | 10:03 |
| slytherin | apw: the version has not been bumped for any updates in karmic. It should be bumped at least for -security. | 10:15 |
| apw | slytherin, yep it should indeed. trying to figure out what has gone wrong to prevent it happening again as much as anything | 10:15 |
| smb | apw, Ok, so you say the linux-image packages for ports are created at the same time as the normal ones? | 10:25 |
| apw | for karmic and lucid yes they are in the main repository, we just worry less about them failing to build | 10:25 |
| apw | and its that that means we want the meta source separate to allow them to remain at a working build | 10:26 |
| slytherin | and that is the reason why meta package is separate for ports | 10:26 |
| apw | yep | 10:26 |
| apw | but there is a procedural whole when we prepare a -security update in particular where that does not get pushed as part of the set. fail. | 10:26 |
| smb | So pulling the meta sources completely back into meta would be bad. But at least as a branch. Still this requires someone to know to check the ports builds and only upload the meta for those when everything is ok | 10:28 |
| slytherin | I can take up that job as keep watch on powerpc builds. My primary machine is a iBook G4. | 10:29 |
| smb | The problem likely is that all the ports meta packages are created from one ports-meta source package (if it works like for the main meta) | 10:30 |
| smb | So its a all good or nothing issue | 10:30 |
| apw | smb, yep. though generally we assume if they build they are good enough for distro architectures | 10:31 |
| * slytherin will be back after sometime. | 10:32 | |
| smb | apw, Yeah, I think this is mostly a procedural issue. When we document that abi bumps on the kernel also require a bump for ports-meta, then we less likely forget to add them to the security upload and get the sec-team to notify us should the ports have failed | 10:34 |
| apw | smb, except right now we don't necessarily have the source to update | 10:34 |
| smb | apw, Which is the problem to solve first | 10:35 |
| apw | am workign on that right now | 10:35 |
| smb | apw, tried "apt-get source linux-ports-meta"? | 10:36 |
| apw | yeah obviously we can get that. trying to find lukes repo | 10:36 |
| apw | smb, think i have them | 10:37 |
| smb | ok | 10:37 |
| apw | smb, ok i've dropped an email onto kernel-team to start some discussions, i suspect you as a stable maintainer can add some detail on how things work and how it affect your end | 10:43 |
| smb | apw, Ok, tahnks. I try to get to it later today. | 10:44 |
| apw | no rush ... | 10:45 |
| * slytherin is back | 11:06 | |
| apw | smb, what did you think to putting the ALPS patch into lucid | 11:17 |
| smb | I wanted to spend a little more time to read over it. but with the feedback from Ben and given the implications it probably even makes sense to have it in Karmic. | 11:19 |
| smb | For Lucid you might try to wait waht Greg decides | 11:19 |
| apw | yeah it being in debian already, and it does sound like stable may take it | 11:19 |
| apw | well it being in karmic, and not lucid puts us in regression territory | 11:19 |
| apw | and it affects some common platforms i think ... a tricky one | 11:19 |
| apw | and at this stage in the cycle its easier to shove it into lucid to test on non-affected h/w to give karmic some feedback perhaps | 11:20 |
| smb | Definitely yes. Especially being so highe | 11:20 |
| smb | hughe | 11:20 |
| apw | so i think it makes sense to shove it into lucid in the next upload and see what happens then | 11:20 |
| smb | This sounds reasonable. And would also be the usual SRU policy | 11:20 |
| apw | ok ... i'll do that and see how we get on | 11:21 |
| smb | Ok, ta | 11:21 |
| vish | ogasawara: apw: hi... upstream has marked http://bugzilla.kernel.org/show_bug.cgi?id=15047 as something to be handled by desktop/userspace feature ? so i would have to reassign Bug #503286 to which package? | 11:22 |
| ubot3 | Malone bug 503286 in linux "Bluetooth killswitch does not remember previous session state" [Unknown,Confirmed] https://launchpad.net/bugs/503286 | 11:22 |
| ubot3 | bugzilla.kernel.org bug 15047 in Bluetooth "Bluetooth killswitch does not remember previous session state" [Normal,Resolved: invalid] | 11:22 |
| slytherin | vish: bluez package probably | 11:23 |
| apw | hrm ... that is a good question ... yeah perhaps bluez | 11:23 |
| vish | ok.. reassigning .. thanks guys | 11:24 |
| vish | slytherin/ apw could someone comment on the bug ? for the bluez devs ? | 11:24 |
| slytherin | vish: You can add a comment yourself pointing that upstream has closed the bug as invalid. | 11:25 |
| vish | that was my last alternative. ;) but sure thanks | 11:26 |
| csurbhi | smb, I wanted to change the kernel config option.. | 12:49 |
| csurbhi | i have changed it from debian.master/config/<file> | 12:49 |
| csurbhi | manual change | 12:49 |
| csurbhi | is that alright ? | 12:49 |
| smb | csurbhi, I believe it was only set there. But to be sure run "fdr updateconfigs" to check whether the result remains the same | 12:50 |
| csurbhi | alright :) thanks! | 12:51 |
| smb | welcome :) | 12:51 |
| === yofel_ is now known as yofel | ||
| === bjf-afk is now known as bjf | ||
| smb | csurbhi, I hope I covered everything in my reply mail. All in all I thing there are the two bugs where to either add or remove bug links and then also adding the patch that gets dropped with .11. Plus putting .11 patches on top of it all (referencing the one tracking bug) | 14:14 |
| csurbhi | smb, ok.. thanks for the review.. i am going through it once again :) | 14:15 |
| smb | csurbhi, It _is_ a treadmill, I am afraid. :) | 14:15 |
| csurbhi | smb, i agree totally :) | 14:16 |
| csurbhi | smb, there is also a comment about ABI bump | 14:18 |
| csurbhi | for a ipv6 patch | 14:18 |
| csurbhi | how do we deal with tat one ? | 14:18 |
| smb | I think it might. But in the end, its only found out by compiling without and then see | 14:18 |
| csurbhi | ok | 14:18 |
| smb | If the build fails without an abi bump we need one | 14:19 |
| csurbhi | and also about the s/390 ? | 14:19 |
| csurbhi | smb, ya.. so the next step is to try to build karmic with the update ? | 14:19 |
| smb | Don't worry too much about that. Its just as I worked on that. :) | 14:19 |
| csurbhi | ok :) | 14:19 |
| csurbhi | so i need to remove the lp buglink from your patch | 14:20 |
| smb | csurbhi, Right. Take your branch and test build it on at least amd64 and i386 | 14:20 |
| csurbhi | and then redo everything again | 14:20 |
| csurbhi | ya.. i will do that :) | 14:20 |
| smb | Maybe the simplest way is a export all, modify as needed then pull them in again approach | 14:21 |
| smb | that way you could also squeeze in the one patch dropped , to be reverted by .11 | 14:21 |
| csurbhi | ok | 14:21 |
| csurbhi | right.. so we apply the patch that needs to be reverted as a part of .11 ? | 14:22 |
| csurbhi | and do all this together ? | 14:22 |
| smb | Yeah, I think thats the best approach. The patch itself should then actually not even show up in the changelog and we got the same sequence as upstream | 14:23 |
| csurbhi | ok.. cool.. i will do that .. | 14:23 |
| smb | Just make a note on the tracking bug (that it includes both) and also reply to your own mail to update that we chose to take both in one go | 14:24 |
| csurbhi | alright | 14:24 |
| rtg | smb, is there a more elegant way of determining host type without asking bash? 'set|grep HOSTTYPE' | 14:25 |
| smb | rtg, hm is uname -m what you want? | 14:25 |
| rtg | smb, ah, how could I have forgotten that ? | 14:25 |
| smb | rtg, It is actually not the same result | 14:26 |
| csurbhi | uname -m | 14:26 |
| rtg | smb, no, but it at least tells me the arch | 14:26 |
| smb | rtg, Otherwise "dpkg-architecture -qDEB_HOST_ARCH" | 14:27 |
| csurbhi | uname -m and echo $HOSTTYPE.. print differnt vals ? | 14:27 |
| rtg | smb, that requires dpkg-dev | 14:27 |
| rtg | csurbhi, i386 vs i686 | 14:27 |
| csurbhi | hmm.. | 14:27 |
| smb | or i486 vs i686 on my netbook | 14:28 |
| rtg | right | 14:28 |
| rtg | mostly I'm interested in it _not_ being x86_64 | 14:28 |
| smb | Ok, so uname -m is usable for that | 14:29 |
| === BenC1 is now known as BenC | ||
| === slytherin1 is now known as slytherin | ||
| csurbhi | smb, one question | 15:13 |
| smb | hmm | 15:13 |
| csurbhi | while reverting a commit.. do we note the revert in the tracking bug ? | 15:15 |
| smb | I don't think we did... Though you might check on the other tracking bugs | 15:16 |
| smb | But probably it is a good idea to make at least a comment there. | 15:17 |
| smb | csurbhi, So lets do it this time and onwards. Just add a comment with the subject of the patch and note that this replaced one we already carried. | 15:19 |
| csurbhi | ok.. cool :) | 15:20 |
| csurbhi | smb, do you think i should make a new git branch as the name 2.6.31.10 for the two updates 2.6.31.10 and 11 will be misleading ? | 15:41 |
| smb | csurbhi, I usually avoid that problem by calling my branch "proposed" or something similar unspecific. In the end its for the purpose of review only. | 15:43 |
| csurbhi | i will keep that in mind now | 15:44 |
| smb | Its just a minor detail and you can freely be creative with the name of your branch | 15:45 |
| smb | as long as you tell the name when sending emails | 15:45 |
| rackerhacker | jjohansen: sorry for bugging you, but did you happen to find time to review that initrd memory freed issue in linux-ec2? | 17:29 |
| jjohansen | rackerhacker: I poked at it briefly but haven't had time actually figure out what is happening | 17:31 |
| rackerhacker | that's okay... would it help at all if i snagged some details and made a proper bug report/ | 17:31 |
| rackerhacker | or would that just be annoying ;-) | 17:31 |
| jjohansen | rackerhacker: by all means go ahead and provide as much detail as you can | 17:33 |
| rackerhacker | jjohansen: will do - thanks much... this build is quite helpful | 17:33 |
| rackerhacker | i ran into a lot of trouble with getting karmic to boot in a domu using 2.6.24 kernels from hardy | 17:35 |
| rackerhacker | i stumbled across some documentation that said upstart required 2.6.27+ | 17:36 |
| jjohansen | rackerhacker: well it would certainly be a good idea, I have booted a domu on less but I wouldn't call it reliable | 17:39 |
| rackerhacker | the 2.6.24-59 group of kernels from hardy seem to work well on all of the distros we run with the exception of karmic | 17:40 |
| rackerhacker | there was a switch in the release candidate that required a later kernel for upstart to function | 17:41 |
| rackerhacker | it caused much head-pounding-on-desk ;) | 17:41 |
| rackerhacker | jjohansen: i logged the bug, but i wasn't sure which details would be relevant (https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/510243) | 17:51 |
| ubot3 | Malone bug 510243 in linux-ec2 "linux-ec2 x86_64 memory calculation incorrect" [Undecided,New] | 17:51 |
| rackerhacker | well that's fancy | 17:52 |
| jjohansen | rackerhacker: okay thanks, I'll look at it in a bit | 17:52 |
| rackerhacker | no problem, thanks! | 17:53 |
| === akgraner is now known as akgraner_ | ||
| === akgraner_ is now known as akgraner | ||
| rackerhacker | jjohansen: i'd love it if we could eventually get an upstream fix for the save/restore bug in domu's :/ | 18:06 |
| rackerhacker | i know fitzhardinge has a patch or two | 18:07 |
| jjohansen | rackerhacker: interesting | 18:10 |
| rackerhacker | have you run into that bug before? | 18:12 |
| rackerhacker | i know it's an upstream issue, so i didn't want to waste your time with it | 18:12 |
| rackerhacker | the xm save hangs, and you end up with this in the domU's dmesg -> http://pastie.org/786816 | 18:13 |
| rackerhacker | i was able to make a build of jeremy's xen.git repository, and the save eventually worked, but i ran into other issues | 18:15 |
| jjohansen | rackerhacker: no I haven't but I was aware there were some issues | 18:21 |
| rackerhacker | it's not the best time to be a xen vps provider with the pv_ops shenanigans ;) | 18:24 |
| sconklin | ogasawara: do you know which git repo Greg queues his patches for stable in? | 20:26 |
| ogasawara | sconklin: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.31.y.git | 20:27 |
| sconklin | AH! he applied it to the 32 tree and it probably also should go to .31, I'll take care of it | 20:30 |
| sconklin | thanks | 20:30 |
| TheMuso | apw: Haven't got to it, will take care of it this morning. | 21:12 |
| TheMuso | apw: If you mean lucid that is. | 21:12 |
| === BenC1 is now known as BenC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!