| === yofel_ is now known as yofel | ||
| * apw yawns | 07:09 | |
| === smb` is now known as smb | ||
| * smb slurps coffee | 07:22 | |
| apw | #define __RAW_SPIN_LOCK_INITIALIZER(lockname) \ | 07:52 |
|---|---|---|
| apw | { \ | 07:52 |
| apw | .raw_lock = __ARCH_SPIN_LOCK_UNLOCKED, \ | 07:53 |
| apw | SPIN_DEBUG_INIT(lockname) \ | 07:53 |
| apw | SPIN_DEP_MAP_INIT(lockname) } | 07:53 |
| * ppisati waits for gitweb on kernel.ubuntu.com to spit something useful... | 09:01 | |
| apw | ppisati, its not the fastest thing in the world | 09:02 |
| ppisati | nope... | 09:02 |
| ppisati | i already asked but, can i have a faster kernel.ubuntu.com for christmas? | 09:03 |
| apw | only if you give up the puppy | 09:04 |
| ppisati | uhmm... ok, i keep the puppy then :) | 09:04 |
| apw | smb, did we get a lot with the extra printies ? | 09:20 |
| smb | apw, currently pulling the dump | 09:20 |
| smb | Though I actually expect not that much... | 09:21 |
| apw | smb, i assume thats a xen side thing ? snapshotting the memory | 09:21 |
| smb | apw, right | 09:21 |
| smb | apw, So as we already expected, the replacement takes place much before the module is loaded/init is called... | 09:23 |
| smb | Makes it even stranger | 09:23 |
| smb | I will have to have a close look at the disassembly of that module | 09:23 |
| apw | well remember it is being patched at load time for paravirt things | 09:24 |
| apw | i wonder if the kernel itself is not being patched correctly | 09:24 |
| apw | so it is in fact not using the new ones | 09:24 |
| smb | Right, what I want to check is whether lock and unlock seem to be patch sites | 09:25 |
| apw | 9 .parainstructions 0000001c 0000000000000000 0000000000000000 0000ac88 2**3 | 09:25 |
| apw | my floppy.ko does have some form of paravirt ops | 09:25 |
| apw | alternative_instructions seems to be where we apply_paravirt for the main kernel | 09:28 |
| apw | smb, could you perhaps put a message in alternative_instructions to make sure it has been run | 09:31 |
| smb | apw, probably... | 09:31 |
| apw | as if the kernel never switched over cause of a bug, then we may well find that floppy is the first thing to use them in this case | 09:32 |
| apw | which would match the stats you have too, so worth checking | 09:32 |
| smb | Just wondering why lock seems to use one way while unlock the other | 09:33 |
| apw | well we do appear to be patching things as we go for paravirt operations of some sort | 09:34 |
| apw | smb, i wonder what compiler your other tester is using | 09:34 |
| apw | we are using a bleeding edge 4.6 right ? | 09:34 |
| smb | apw, Just in the assembly there seems to be a PVop for unlock but a raw call for lock... | 09:35 |
| smb | apw, bleeding o-edge | 09:35 |
| smb | which is 4.6 | 09:35 |
| apw | smb, can you put up the asm dump so i can see too pls | 09:35 |
| apw | smb, i assume you are looking at the kernel there yes? | 09:35 |
| smb | apw, probably you would be able to look yourself on gomeisa | 09:35 |
| smb | no at the unstripped ko | 09:36 |
| apw | smb, and how are you getting the asm | 09:36 |
| smb | my home and oneiric-amd64/... | 09:36 |
| smb | apw, objdump -SD | 09:36 |
| === Quintasan_ is now known as Quintasan | ||
| apw | smb, i think you dumped at the return address, ie in the middle fo the function, could you redump perhaps 32 bytes back for me | 10:42 |
| smb | apw, Oh, right, likely did... sure, a sec | 10:42 |
| * ppisati -> lunch | 10:47 | |
| smb | apw, Should be now replaced. Btw, it feels a bit inconsistent which CONFIG_INLINE_SPIN options are set and which are not... | 10:49 |
| apw | smb, which are inconsistent? i think you can mark them separatly | 10:50 |
| smb | apw, Looks like only unlock and unlock_irq are... everything else is not | 10:51 |
| * smb needs food... | 10:52 | |
| apw | so we'd not see the lock then in thec ode, we'd expect to see a jump out somewhere | 10:52 |
| smb | apw, Would it be possible then that lock calls are called up in the kernel, which has been patched once before the pointers were replaced, but unlock gets patched on module load cause it is inlined? | 10:58 |
| apw | i think that would mean we should replace one lot via the smp_alternatives if things are working right | 10:59 |
| apw | and the other via the paravirt thingy, is why i'd like to see those instrumented in module.c to see which are actuall applied | 11:00 |
| smb | its next on the list... | 11:00 |
| apw | smb, can you tell me what crash things is at FFFFFFFF815FD174 | 11:22 |
| smb | apw ffffffff815fd174 (T) _raw_write_lock_irqsave+36 /home/smb/oneiric-amd64/ubuntu-2.6/arch/x86/include/asm/spinlock.h: 260 | 11:31 |
| apw | smb, sorry make that FFFFFFFF815FD17B | 11:31 |
| smb | ffffffff815fd17b (T) _raw_write_lock_irqsave+43 /home/smb/oneiric-amd64/ubuntu-2.6/kernel/spinlock.c: 290 | 11:32 |
| apw | ok so i think i have the lock, and it is here | 11:32 |
| apw | and what is FFFFFFFF8100913B | 11:33 |
| apw | smb ^ | 11:33 |
| smb | ffffffff8100913b (t) check_zero+27 /home/smb/oneiric-amd64/ubuntu-2.6/arch/x86/xen/spinlock.c: 54 | 11:33 |
| apw | smb and FFFFFFFF815FD180 | 11:35 |
| smb | ffffffff815fd180 (T) _raw_spin_lock_irq /home/smb/oneiric-amd64/ubuntu-2.6/kernel/spinlock.c: 152 | 11:35 |
| apw | and ths FFFFFFFF81009140 | 11:36 |
| apw | smb, ^ | 11:36 |
| smb | ffffffff81009140 (t) xen_spin_unlock /home/smb/oneiric-amd64/ubuntu-2.6/arch/x86/xen/spinlock.c: 325 | 11:36 |
| apw | and dissasemble _raw_spin_lock_irq | 11:36 |
| apw | whats that got in it | 11:37 |
| smb | apw, in pm | 11:38 |
| apw | ok so _raw_spin_lock_irq is the ticket version, which is the out of line version | 11:38 |
| apw | the inline unlock has been correctly replaced | 11:38 |
| apw | so it looks like the alternatives are not being done right on the main kernel | 11:39 |
| smb | apw, which would match my suspician | 11:39 |
| apw | very much so indeed | 11:39 |
| apw | but i have the proof here now | 11:39 |
| smb | apw, Pretty certain that the non-inline versions are patched once, before xen init replaces the vectors in the struct | 11:39 |
| apw | so i think the kernels out of line code is non-paravirt | 11:39 |
| apw | yeah ... so when those pointers are changed we need to reapply the paravirt ops to the kernel don't we ? | 11:40 |
| smb | apw, Right either this or the replacement would need to be done before the first patching... | 11:41 |
| apw | so ... what defines ordering of the patching against the alternatives being applied | 11:41 |
| apw | per | 11:41 |
| smb | For that I need to check the code more carefully. It seemed to be a struct of pointers contained in another and then applied... but need to understand it better first | 11:43 |
| apw | so i assume if we were all inline or all out of line we would never see this, simply we would get away with it | 11:46 |
| apw | OH ... and i think we _know_ all of the kernel is broken and using ticket, because it does not blow up | 11:46 |
| apw | so we know all of the alternatives in the kernel are pointing to ticket as it would have inline unlocks too | 11:46 |
| smb | apw, Well yes, ticket is the default pv_lock_ops | 11:47 |
| apw | right ... what i mean is, the timeing of the bang and the stats tell us that its everything in the kernel which is the "other way" | 11:47 |
| apw | and tells us its the alternatives application which has gone awry | 11:48 |
| smb | But I would assume if one could satisfy all being inlined it would be good. because the kernel would keep using ticket and modules both pv ones | 11:48 |
| smb | ... with a strange way of good | 11:48 |
| apw | yes as long as they didn't share any locks | 11:48 |
| smb | yeah | 11:49 |
| apw | ie no modules reach out and use kernel locks, then bad poop would happen | 11:49 |
| apw | now .. how the heck has upstream not hit this, are we inlining in a non-standard way ? | 11:49 |
| apw | i'd expect us to be taking the normal defaults | 11:49 |
| smb | apw, Or maybe they test with all needed stuff built-in... | 11:50 |
| apw | smb, right i have the real code decoded and the proof we are calling unmatched lock/unlock here, is there a bug i should shove it in, or ? | 11:50 |
| smb | apw, Not yet... need to create one | 11:50 |
| apw | smb, yeah perhaps so, its definatly only modules which can hit this | 11:50 |
| smb | things keep breaking quicker than I would be able to operate lp | 11:51 |
| smb | or rather I should first report things and then look into them but I tend to do it the otehr way | 11:51 |
| apw | get me the number when its done, and i'll put all this crap in the bug so it doesn't get lost | 11:51 |
| smb | ack | 11:52 |
| apw | is cool as the dump has the rewritten post alternatives code, so we can confirm your theory is spot on | 11:52 |
| smb | apw, Sounds perferct. At least I can say its on the kernel side now. The other issues turned out to be in the xen hypervisor | 11:53 |
| apw | yeah, it looks to be a pretty obvious bug really, needing to apply the right locks to everything | 11:54 |
| apw | its amazing its lasted this long without being noticed | 11:54 |
| cking | apw, this will confirm your observation that boarding planes has always been inefficient: http://www.bbc.co.uk/news/science-environment-14717695 | 11:55 |
| === ehw is now known as ehw|asdf | ||
| === ehw|asdf is now known as ehw | ||
| smb | apw, bug 838026 | 12:01 |
| ubot2` | Launchpad bug 838026 in linux "Running Oneiric kernel as Xen HVM guest with pvlocks hangs on boot" [High,In progress] https://launchpad.net/bugs/838026 | 12:01 |
| apw | smb bits are in | 12:08 |
| smb | apw, cool. thanks | 12:09 |
| lynxman | Hey guys o/ we're having quite heavy issues with Oneric Server and HP DL380 proliant servers, we raised bug #818177 about it | 12:27 |
| ubot2` | Launchpad bug 818177 in linux "HP DL380G5 does not see disks after upgrade to Oneiric" [Undecided,Confirmed] https://launchpad.net/bugs/818177 | 12:27 |
| lynxman | This looks like quite a serious race bug, considering that Proliant is one of the common servers on the market can we give this bug some fire? :) | 12:28 |
| tgardner | lynxman, seems like you have 2 issues, one of which is bnx2 firmware (again). | 12:29 |
| apw | lynxman, i see you are able to boot it one in N, it might be good to get it up and update the kernel | 12:30 |
| apw | as you appear to have a -7.x kernel | 12:31 |
| apw | tgardner, have those 'tards changed the firware name _again_ | 12:31 |
| lynxman | apw: I reproduced the same just now with the latest oneric release | 12:31 |
| lynxman | apw: Both through PXE install from last Friday's daily release and from the natty -> oneiric upgrade route as well | 12:31 |
| lynxman | apw: same result :( | 12:32 |
| smb | lynxman, isn't that the disk? | 12:32 |
| smb | cciss 0000:06:00.0: cciss0: <0x3230> at PCI 0000:06:00.0 IRQ 66 using DAC | 12:32 |
| smb | [ 1.849298] cciss/c0d0: p1 p2 < p5 > | 12:32 |
| tgardner | apw, they may have | 12:32 |
| lynxman | smb: yessir | 12:32 |
| lynxman | smb: I can try reinstalling again in natty and going the natty -> oneiric route modifying also grub.conf and fstab | 12:33 |
| smb | So it seems there.... | 12:33 |
| apw | lynxman, i assume the bug report is from one of your good boots ? | 12:33 |
| smb | Are you having a uuid or devname in fstab? | 12:33 |
| lynxman | apw: its from TREllis trying the same in the same set of servers | 12:33 |
| smb | ah forget it... lvm | 12:33 |
| lynxman | apw: right now the most I have is iLO access through a java *shrieks* interface | 12:33 |
| lynxman | apw: but yeah its from one of the good boots | 12:35 |
| smb | lynxman, Though it was oneiric already... Would you be able to collect a log from a bad one over serial over lan ? | 12:35 |
| apw | yeah if we could get a dmesg from a failed boot, then we can compare | 12:36 |
| lynxman | smb: apw: unfortunately not, I can take jpeg screenshots of the bad dmesg though | 12:36 |
| apw | better than nothing | 12:37 |
| smb | yep | 12:37 |
| lynxman | alright, doing that :) | 12:37 |
| smb | lynxman, Just wondering if you can use that java thing... then why ipmi sol activate would not work... Of course you need to define a serial interface in bios first... | 12:38 |
| Daviey | lynxman: iLo should have serial support? | 12:38 |
| lynxman | Daviey: oh yes, it should, if you buy the extra SVP module, which is just a software update | 12:39 |
| lynxman | Daviey: HP at its best, showing no mercy for sysadmins | 12:39 |
| Daviey | bah. | 12:40 |
| ppisati | herton: it seems you had a sleepless night, did you? :) | 12:41 |
| === nickde is now known as Guest17730 | ||
| herton | ppisati: it was my bot personality in action :) | 12:42 |
| apw | smb, lynxman, seems they (hp) have changed much of the board reset code since .38, so they have probabally borked it | 12:43 |
| herton | (shank bot is running in a cron job here) | 12:43 |
| ogra_ | herton, sleep-walker^Wchatter ? | 12:43 |
| apw | smb, i meant to ask just how early do we figure out we are switching to pvlocks | 12:44 |
| smb | apw, err wouldn't that mean neither older kernels would boot now? | 12:44 |
| ppisati | herton: really? | 12:44 |
| lynxman | smb: apw: natty kernels boot without any issues though | 12:44 |
| ppisati | herton: i thought it was you, doh! | 12:44 |
| apw | smb, lynxman, right i am saying .38 has completly different reset code | 12:44 |
| herton | ppisati: yep :) | 12:44 |
| apw | so its possible that natty would work and oneiric not | 12:45 |
| smb | apw, The normal rewrite of code seems to be done from check_bugs() / somewhere from start_kernel (== quite early) | 12:45 |
| apw | smb, yeah, and the pvlocks one ? | 12:46 |
| smb | apw, later (not really time to follow that chain, yet) | 12:46 |
| apw | smb, i thought you'd put a print in, wondered where that had fallen | 12:46 |
| smb | apw, right after the bringup of cpu#0 where you have the spinlock irq message in the log I sent | 12:47 |
| smb | apw, Hm.... If I am not looking wrongly... the xen spinlock ptrs are set from init_arch which comes before check_bugs in start_kernel... | 12:53 |
| * apw shouts incoherantly at his screen | 12:55 | |
| apw | noreplace_paravirt <-- smb what value does that have in the dump | 12:56 |
| apw | and ... when does it change | 12:56 |
| smb | noreplace_paravirt = $8 = 0 | 12:57 |
| smb | apw, And for when it would change I would need a new kernel... | 12:57 |
| apw | smb, well the code seems to init it to 0 and then only change it =1, so i think its always been 0 | 12:58 |
| apw | smb, i have a worry that the real bug is that the kernel locks are not taking into account PARAVIRT_SPINLOCK at at | 13:05 |
| apw | smb, ignore that ... sigh | 13:06 |
| smb | apw, Actually, I think I was wrong before... Currently its done in smp_prepare_cpus() which is called from kernel_inti which comes after the check_bugs | 13:06 |
| apw | smb, so that ... would explain it | 13:07 |
| smb | Yeah... luckily... | 13:07 |
| apw | you could try shoving the same check directly in check_bugs before and see if it fixes things | 13:07 |
| smb | apw, I had been moving it into some place which should have been before (not sure I did it right though) and that was... quite bad | 13:08 |
| smb | apw, Unfortunately crash is quite useless if the badness is before the init task runs... :/ | 13:09 |
| apw | well you could try calling the alternative_instructions again where we have just changed the pointers | 13:09 |
| apw | and see what happens, i suspect the kernel will shitola itself in all new interesting ways | 13:09 |
| smb | I will try that now... | 13:10 |
| apw | Kernel modules: hpsa, cciss | 13:11 |
| apw | smb, ^^ that looks bad to my eye | 13:11 |
| apw | (for the disky thing) | 13:11 |
| smb | apw, There was something that they do some funny things to which driver handles what... | 13:12 |
| smb | apw, messing around with names and acting differently when its a cdrom or disk or so... | 13:12 |
| apw | smb, looking at it they took all that out and "made sure we don't have overlapping ids" | 13:12 |
| apw | i suspect its bust _again_ | 13:12 |
| lynxman | getting your pics :) it's a painstakingful operation | 13:17 |
| apw | lynxman, heh thanks, and if you can get an lspci | 13:17 |
| apw | lynxman, just the page with the sas controller would be enough | 13:18 |
| lynxman | apw: doing that too | 13:18 |
| apw | lynxman, do you by any chance have an lspci for this machine/similar machine on a natty kernel | 13:31 |
| lynxman | apw: nope since I already upgraded it on oneiric | 13:31 |
| lynxman | apw: just 3 mins until I finish photoshopping this :) | 13:32 |
| apw | bah people who can affort photoshop | 13:33 |
| lynxman | apw: it's one of those unlimited demo copies :) | 13:34 |
| lynxman | apw: screenshots in place :) | 13:35 |
| apw | lynxman, so where is your root disk? c0d0 or c0d1 ? | 13:38 |
| lynxman | apw: c0d0 | 13:39 |
| apw | well this dmesg shows c0d0 being found and mounted | 13:39 |
| lynxman | apw: yes,but then it goes into "filesystem is read only" | 13:39 |
| apw | it does show an "unknown partition table" error for c0d1 | 13:40 |
| apw | which seemed to work in the good boot | 13:40 |
| lynxman | apw: so looks like it finds it at rootfs moment but when it needs to jump to the appropriate initlevel it breaks | 13:40 |
| lynxman | apw: it's the same machine reinstalled again and again | 13:40 |
| apw | whats on c0d1p1 / | 13:40 |
| apw | ? | 13:40 |
| lynxman | apw: posting screenshot just now | 13:40 |
| apw | [ 1.850587] cciss/c0d1: p1 | 13:40 |
| apw | as on the good boot we get the ^^ above | 13:41 |
| lynxman | apw: I reckon it's safe to ignore c0d1, I've been not using it for this install, at all | 13:41 |
| apw | ok so we can't call this "doesn't see its disks" when it has the disk mounted read only | 13:42 |
| lynxman | apw: true, still something is broken on the driver though | 13:42 |
| lynxman | apw: or that's what it looks like from mine and kirkland diags | 13:43 |
| apw | lynxman, maybe so but a widly inaccurate description isn't helping | 13:43 |
| lynxman | apw: :) true | 13:43 |
| lynxman | apw: apologies, this problem has been jumping like a hot potato | 13:43 |
| apw | so what did it say on the console just before dropping to busybox ? | 13:44 |
| lynxman | apw: exactly the same as in the dmesg,not extra info there :/ | 13:45 |
| apw | it doesn't have any required nfs mounts does it ? | 13:45 |
| lynxman | apw: no | 13:45 |
| lynxman | apw: it's a clean install, no extra anything | 13:45 |
| lynxman | apw: in this case it's a clean natty then dist-upgrade to oneiric, reboot | 13:46 |
| lynxman | apw: same situation happens with direct oneiric install | 13:46 |
| apw | so what occurs if you ^D out of busy box prompt | 13:46 |
| lynxman | apw: trying that nao | 13:47 |
| lynxman | apw: system doesn't boot, 5 lines of touch errors on "Read-only file system" attaching ot bug report | 13:48 |
| apw | ok so ... anything in dmesg | tail thats new ? | 13:48 |
| lynxman | apw: can't do anything, not even dmesg :) | 13:49 |
| lynxman | apw: system completely unresposive | 13:49 |
| lynxman | apw: er it does respond to Ctrl-Alt-Del | 13:49 |
| lynxman | attached | 13:50 |
| apw | ok so when it gets back to busy box could you try remounting / rw manually | 13:50 |
| apw | mount -o rw,remount / | 13:50 |
| apw | and see what that does | 13:50 |
| lynxman | apw: okay :) | 13:50 |
| * apw hopes smb is making more progress than he is | 13:55 | |
| lynxman | apw: if I remount manually then resume boot it just shows "rc-sysinit start/runnin, process 1011" and fails to keep booting | 13:55 |
| apw | lynxman, so it remounts manually r/w ok | 13:56 |
| lynxman | apw: yes | 13:56 |
| TREllis | lynxman: ah, looks like you are having fun | 13:56 |
| apw | so it sounds like a userspace level issue then rather than a kernel issue | 13:56 |
| lynxman | TREllis: aren't I, apw is being extra patient with me | 13:57 |
| lynxman | apw: alright, I'll bug the ubuntu-server guys then :) | 13:57 |
| lynxman | apw: thank you very very very much for your patience as said, one beer is on me at next UDS ;) | 13:57 |
| apw | heh see what they say about how one diagnoses this puppy | 13:57 |
| lynxman | apw: it'll be painful, for sure, remote access to a machine in the Montreal lab | 13:58 |
| apw | lynxman, one thing you can try is adding --verbose to the _end_ of you kernel command line | 14:01 |
| apw | yes with the --, this should make upstart more chatty | 14:01 |
| lynxman | apw: cool, nice tip, thanks :) | 14:01 |
| TREllis | lynxman: remove quiet and add INIT_VERBOSE=yes too :) | 14:02 |
| lynxman | TREllis: for extra fun | 14:02 |
| * ogasawara back in 20 | 14:32 | |
| ppisati | LP seems to be down now... | 14:50 |
| ppisati | ah no | 14:50 |
| ppisati | Timeout... | 14:50 |
| herton | it's slow and timeouting for me too | 14:50 |
| ppisati | yeah | 14:50 |
| ppisati | but even in the main page | 14:50 |
| === jpds_ is now known as jpds | ||
| Daviey | apw: What was the indicator that lynxman's bug was userspace? | 15:21 |
| apw | Daviey, the symptoms was that it booted to a prompt, but root was mounted and could be made r/w | 15:22 |
| apw | so the disks were all there and functioning at the time of the boot filaure | 15:23 |
| === kamalmostafa is now known as kamal | ||
| Daviey | apw: I see.. that makes things less cool. | 15:25 |
| === nickde is now known as Guest76083 | ||
| Daviey | lynxman: Are you sure you were seeing the real filesystem, and not the contents of the intramfs? | 15:30 |
| lynxman | Daviey: certain | 15:31 |
| Daviey | lynxman: Thought about replacing the stock with Dell or Supermicro servers? | 15:33 |
| lynxman | Daviey: Don't think that'll fix the bug :) | 15:33 |
| lynxman | Daviey: although we bought some servers, and they were accepted by #is gladfully :) | 15:34 |
| lynxman | Daviey: at least I think so, otherwise I don't know where they are | 15:34 |
| lynxman | Daviey: they were proliant too | 15:34 |
| herton | ppisati: you missed updating the timestamp in the changelog when closing the ti-omap4 for natty | 15:36 |
| apw | lynxman, how did the --verbose pan out | 15:38 |
| lynxman | apw: didn't add much unfortunately, although if I changed the kernel boot from ro to rw I've got way further than anytime before, got up to rc.local. but then the network card doesn't mount and I don't get getty login | 15:39 |
| lynxman | apw: it looks to me that the system fails to remount itself at some early boot stage | 15:50 |
| apw | lynxman, what tells you that? | 15:51 |
| lynxman | apw: that if I boot the kernel straight rw everything kinda works | 15:51 |
| apw | lynxman, but we also know we can move the disk rw from the prompt, and its userspace which does that normally | 15:52 |
| apw | i assume it is mountall which does that | 15:52 |
| lynxman | apw: yes but in that case it doesn't get too much further up in boot, which I think indicates that there's pre-depending stuff on the FS being rw that doesn't get run properly | 15:52 |
| apw | lynxman, right and the question is why doesn't mountall do its job | 15:53 |
| lynxman | apw: that's the question indeed... | 15:54 |
| lynxman | apw: any way to make mountall super verbose? | 15:54 |
| apw | you could just try running mountall at the prompt when it stops | 15:54 |
| bjf | jsalisbury, how does someone upload the log files from a different system to a bug? | 16:00 |
| * herton -> lunch | 16:03 | |
| lynxman | apw: aha! mountall hangs :) | 16:14 |
| lynxman | apw: Daviey: kirkland: added screenshot to bug report | 16:15 |
| ppisati | herton: the timestamp? | 16:16 |
| ppisati | wait, let me see... | 16:16 |
| ppisati | herton: you mean the "-- Paolo Pisati <paolo.pisati@canonical.com> Mon, 30 May 2011 14:47:51 +0200" at the end of the changelog entry?> | 16:17 |
| ppisati | herton: actually i never touched it, and i thought it was automagically constructed | 16:17 |
| ppisati | btw, i can't close maverick/mvl-dove | 16:18 |
| herton | ppisati: yep, May seems a little in the past :) | 16:23 |
| herton | the timestamp update must be done manually | 16:23 |
| ppisati | herton: ah, didn't know | 16:24 |
| herton | ppisati: hmm what's the issue with the maverick/mvl-dove? | 16:24 |
| ppisati | herton: well, i did it last week | 16:24 |
| ppisati | herton: and i don't think i did anything special | 16:24 |
| herton | ppisati: oh ok, so just invalidate the bug, it was opened because maverick was respinned to revert 2 patches | 16:25 |
| ppisati | herton: i mean, i ran thr update-from-mvl-dove script, readded some commits that were overwritten and then closed it | 16:25 |
| ppisati | herton: but i just noticed that: | 16:25 |
| herton | that reverted patches don't affect it I think | 16:25 |
| ppisati | 1) IMO the last time we release it, it was wrong | 16:25 |
| ppisati | sicne the last changelog entry encompass a loooooong period of time | 16:25 |
| ppisati | so, basically it was never opened/closed correctly | 16:25 |
| ppisati | 2) now the use the script, readd commits and close doesn't work anymore | 16:26 |
| ppisati | bah | 16:26 |
| ppisati | herton: ah, so i can invalidate it then? | 16:26 |
| ppisati | cool | 16:26 |
| ppisati | but still, there's something wrong in there... | 16:27 |
| herton | ppisati: wait, so the rebase script doesn't work anymore? | 16:28 |
| ppisati | herton: nope | 16:28 |
| ppisati | herton: but i'll take a look at it later | 16:28 |
| ppisati | or tomorrow | 16:28 |
| ppisati | as long as i can invalidate it right now, it's ok | 16:28 |
| herton | ppisati: ok. just keep the tracking bug opened for now then | 16:29 |
| ppisati | herton: so, do i invalidate it or not? | 16:29 |
| herton | you can invalidate it, as long as mvl-dove doesn't need a rebase against latest maverick master, that is, nothing since the last maverick master updates affects mvl-dove | 16:29 |
| ppisati | herton: nope, maverick/mvl-dove is a copy of lucid/mvl-dove | 16:30 |
| ppisati | plus a 200 offset in the ABI | 16:30 |
| ppisati | just to avoid clashes | 16:30 |
| herton | oh right, forgot about that. ppisati, so the rebase script is not broken, it uses the latest lucid/mvl-dove branch | 16:31 |
| ppisati | yep | 16:31 |
| herton | that's why it must be failing now, since there were no updates to lucid/mvl-dove | 16:31 |
| ppisati | no, there were, i just packaged the new kernel | 16:31 |
| ppisati | and you can tell the script to use zinc | 16:32 |
| ppisati | anyway, don't worry | 16:32 |
| ppisati | i'll figure it out | 16:32 |
| herton | yep, but you need that me or sconklin push the lucid/mvl-dove to master before you use the rebase script I think | 16:32 |
| herton | *not to master, but to lucid -> mvl-dove branch | 16:32 |
| ppisati | no no | 16:32 |
| ppisati | you can tell to use my lucid tree on zinc instead | 16:32 |
| jsalisbury | bjf, from a different system? I believe you can just add them as an attachment | 16:36 |
| bjf | jsalisbury, i thought that apport had a command line option for it (but i could be mistaken) | 16:37 |
| herton | ppisati: oh ok. well, if you changed lucid/mvl-dove, I think you want to release later the maverick/mvl-dove based on it? in this case you wouldn't invalidate the bug | 16:37 |
| jsalisbury | bjf, ahh, yes it does. | 16:37 |
| jsalisbury | bjf, one sec | 16:37 |
| jsalisbury | bjf, you could do something like this: ubuntu-bug linux --save /tmp/ubuntu-bug-output-BUGNUM.log | 16:38 |
| jsalisbury | bjf, then attach the output file to the bug | 16:39 |
| bjf | jsalisbury, ok, so there's no command line for attaching the output to the bug once you have collected it | 16:39 |
| jsalisbury | bjf, Do you mean: | 16:40 |
| jsalisbury | bjf, apport-collect bug_num | 16:40 |
| jsalisbury | bjf, that attaches the apport-collect output directly to the bug id given for bug_num | 16:41 |
| bjf | jsalisbury, yes, but more like "apport-collect bug_num --logs=/tmp/ubuntu-bug-output-BUGNUM.log" | 16:41 |
| bjf | jsalisbury, anyway, doesn't seem like there is something exactly like I'm describing | 16:42 |
| jsalisbury | bjf, ok, so you mean if you already have the file, how do you attach the file using the apport command vs attaching it manually | 16:42 |
| bjf | yes | 16:42 |
| jsalisbury | bjf, I'm not sure if it has that functionality, but I can dig deeper | 16:42 |
| bjf | jsalisbury, no big deal, thought you might just know off the top of your head | 16:42 |
| jsalisbury | bjf, not off the top of my head, but that would be very useful | 16:43 |
| ppisati | herton: ok, natty/ti-omap4 repushed | 16:43 |
| herton | ack | 16:44 |
| jsalisbury | bjf, hmm, from the man page: | 16:44 |
| jsalisbury | Finally, you can use this program to report a previously stored crash or bug report: | 16:44 |
| jsalisbury | apport-bug /var/crash/_bin_bash.1000.crash | 16:44 |
| jsalisbury | apport-bug /tmp/apport.firefox.332G9t.apport | 16:44 |
| bjf | that looks interesting | 16:44 |
| jsalisbury | bjf, but that looks like the crash file must contain the bug id | 16:45 |
| jsalisbury | s/crash/apport-output/ | 16:45 |
| jsalisbury | bjf, hmm, actually apport-bug with an output file will create a new bug using that output file, not add to an existing bug :-( | 16:50 |
| jsalisbury | bjf, apport-cli may be able to do this, but I would have to try it. | 16:52 |
| jjohansen | rebooting | 17:37 |
| * tgardner -> lunch | 18:04 | |
| cnd | when is kernel freeze? | 18:49 |
| jjohansen | cnd: sept 15 | 18:51 |
| cnd | ok | 18:52 |
| === vanhoof[holiday] is now known as vanhoof | ||
| herton | tgardner: do you know if packages from bug 772381 will be copied to updates? I have a new tracking bug for ti-omap4, but noted that release/bug is still opened with packages in -proposed | 19:01 |
| ubot2` | Launchpad bug 772381 in linux-ti-omap4 "linux-ti-omap4: 2.6.38-1209.13 -proposed tracker" [Undecided,Fix committed] https://launchpad.net/bugs/772381 | 19:01 |
| herton | sconklin: ^ | 19:02 |
| tgardner | herton, looks like 2.6.38-1309.13 must have been copied to -updates already. | 19:03 |
| herton | tgardner: yeah. I just don't want to do a new upload and overwrite what is in -proposed right now | 19:03 |
| tgardner | herton, hmm, this 1309.13 version is a bit strange. | 19:05 |
| herton | tgardner: typo, it's 2.6.38-1209.13 | 19:05 |
| tgardner | herton, perhaps, but Launchpad thinks it is 1309. https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/772381/comments/2 | 19:06 |
| ubot2` | Ubuntu bug 772381 in linux-ti-omap4 "linux-ti-omap4: 2.6.38-1209.13 -proposed tracker" [Undecided,Fix committed] | 19:06 |
| herton | tgardner: seems the 1300 abi is the oneiric version | 19:07 |
| herton | *oneiric upload | 19:08 |
| tgardner | herton, doh! of course it is. it even says so. | 19:08 |
| tgardner | herton, so, you're worried about overwriting the current version in -proposed ? | 19:09 |
| tgardner | natty-proposed | 19:09 |
| herton | tgardner: yes, in the case this 2.6.38-1209.13 will be copied to -updates | 19:09 |
| tgardner | herton, ok, I guess I don't see the issue. | 19:10 |
| herton | tgardner: I'm not sure what's the state of it. should this release have been copied to -updates, or can I do a new update which will "supersede" this in -proposed | 19:11 |
| tgardner | herton, you'll likely have to go through all of the associated bugs and ascertain that they've been verified. | 19:17 |
| herton | tgardner: looking at the bug list, noted that commit dfcc9e415e79d0b9de8cc8db89211ddec663306f in natty/ti-omap4 tree shouldn't have been applied, by the bug report natty don't want the multi-arch stuff | 19:24 |
| tgardner | herton, is that the result of a rebase against master ? | 19:25 |
| herton | tgardner: no, seems natty/ti-omap4 isn't a rebasable branch | 19:25 |
| tgardner | herton, does it have a negative impact? its just some packaging studd as far as I can tell | 19:26 |
| tgardner | suff* | 19:26 |
| tgardner | stuff* | 19:26 |
| herton | don't know really, just noticed looking at the bugs to verify | 19:27 |
| tgardner | herton, I think you can ignore it. | 19:27 |
| herton | also some bugs to verify are patches applied to natty before the kernel freeze, so before the SRU process. I think they can stay unverified also. | 19:29 |
| tgardner | herton, anything that was verified for x86 and is not arch specific is likely fine. | 19:29 |
| herton | tgardner: since that release was not verified, I think it's ok then to supersede it with a new upload/sru process. It'll have to wait for testing etc. I'll set 772381 as won't fix for natty and lets do the update on the new tracking bug, what do you think? | 19:32 |
| tgardner | herton, works for me | 19:33 |
| * ogasawara lunch | 19:52 | |
| * cking calls it a day | 20:00 | |
| Guest76083 | hmm http://pastebin.com/BKcmMd47 | 20:09 |
| === med_out is now known as medberry | ||
| === kentb is now known as kentb-afk | ||
| === medberry is now known as med_out | ||
| kees | ogasawara: so, seccomp_filter goes in for -9.16? | 22:53 |
| ogasawara | kees: yep. we have an abi bump, so it'll actually be -10.16. we'll upload on friday. | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!