| infinity | plars: (If there's anyone you can hand off those regression-testing tasks to, I'd like to be able to release those kernels tonight to clear the road for more, if possible) | 02:12 |
|---|---|---|
| plars | infinity: good timing, one of them *just* finished, the other is still in progress | 02:13 |
| infinity | plars: Kay. Those would be the LTS ones? What's the continuing story with ti-omap4? | 02:13 |
| plars | infinity: the omap4 one was done much earlier, but we had a couple of failures | 02:13 |
| infinity | Were all the failures just whacky timing issues? Reproducible (or haven't had time for a second test run)? | 02:14 |
| plars | infinity: https://bugs.launchpad.net/kernel-sru-workflow/regression-testing/+bug/1181023 is the one that just finished | 02:14 |
| ubot2 | Ubuntu bug 1181023 in Kernel SRU Workflow "linux-lts-raring: 3.8.0-22.33~precise1 -proposed tracker" [Medium,In progress] | 02:14 |
| infinity | plars: Lovely. | 02:14 |
| plars | infinity: on omap, reproducible, two runs were done (they take 8+ hours each) | 02:14 |
| infinity | Hrm. Curious. Do you have output anywhere that I can try to digest? | 02:15 |
| plars | infinity: I can set it up with the previous kernel and run it there and see if we get the same result | 02:15 |
| infinity | Or that. | 02:15 |
| plars | if so, it wouldn't be a regression for sure | 02:15 |
| plars | infinity: but won't know anything until morning | 02:15 |
| plars | infinity: because it will take that long to run | 02:15 |
| infinity | Well, testing if it really is a regression would be good, but I'm also curious what the exact failures are. | 02:15 |
| plars | infinity: I can forward you the mail, one moment | 02:16 |
| infinity | (If we release everything except omap4, that won't hurt my feelings much either) | 02:16 |
| plars | infinity: sent | 02:17 |
| plars | infinity: because those other two were in parallel, this other one for quantal lts has a few hours to go because it was waiting on system. So far it has all passed though | 02:20 |
| infinity | Hrm, that log is curious. | 02:23 |
| infinity | Did you reboot between the first and second test run? | 02:24 |
| infinity | And does dmesg show anything weird? | 02:24 |
| plars | infinity: yes, I did reboot | 02:29 |
| plars | infinity: what was changed in this sru? | 02:35 |
| infinity | plars: Same as was changed on every other arch, if that's helpful. :P | 02:39 |
| infinity | (I'm looking now to see if there was anything ARM-specific and obviously scary) | 02:39 |
| plars | infinity: if it helps, the test description is only '''ptrace allowed only on children or declared processes''' | 02:45 |
| plars | infinity: not horribly familiar with what these tests are trying to do though I'm afraid | 02:45 |
| plars | this is all stuff from the security team | 02:46 |
| infinity | plars: Yeah, I'm fairly sure I know what the test will be trying to do, but I'm not seeing any obvious reasons why it would be failing all of a sudden. | 02:49 |
| infinity | plars: I guess we'll wait on your results tomorrow, and if it's broken the same way, dig deeper. | 02:49 |
| plars | infinity: ok | 02:50 |
| plars | I'll get this set back up with the old kernel | 02:50 |
| infinity | plars: But the whole "tar no can read files, HALP" thing afterward, after a "sudo chown -R" points more the "maybe the system just got very confused and pooped itself" or similar. :P | 02:50 |
| infinity | s/more the/more to/ | 02:50 |
| plars | infinity: the " Cannot stat: Permission denied" on the tar? | 02:52 |
| plars | infinity: I think that's just a missing sudo | 02:52 |
| infinity | plars: That makes little sense, given the line directly above. | 02:52 |
| plars | I've heard that's not new, so I'm ok with that one. It needs to be fixed though | 02:52 |
| infinity | plars: We explicitly chown all those files first. | 02:52 |
| infinity | ("We" being the test, I have nothing to do with this testsuite) | 02:52 |
| plars | infinity: well, as it stands on the system post-testing, the file doesn't exist | 02:53 |
| plars | yes, nor do I except to run it | 02:53 |
| plars | I'd like to dig into it a bit though | 02:54 |
| infinity | plars: ETA on lts-quantal? Or did you abandon me for, like, having a life? :) | 04:45 |
| plars | no, just lying here in a puddle of drool | 04:46 |
| plars | infinity: it's running, I would have thought it to be done by now, there are only two systems left, but all the others look ok with the exception of a "out of space" error on one test that seems to have been seen before. Will check the lab set up to see if that's something like a too small disk, or just a buggy test not cleaning up previous messes | 04:47 |
| plars | ok, one just finished, one more left | 04:49 |
| infinity | \o/ | 04:49 |
| plars | infinity: it's done, all good | 05:41 |
| infinity | plars: Yay, thanks. | 05:42 |
| plars | infinity: the panda (prev kernel) test is running too | 05:43 |
| plars | infinity: I'm going to go pass out now, good night | 05:43 |
| apw | chiluk, if you remove the build stamp from debian/stamps (it has build in its name) then in theory it 'continues' rather than restarting | 09:01 |
| NikTh | Hello. | 09:30 |
| NikTh | Question: Can someone tell me why the "~" character is not allowed in package name ? Read here another build failure of mine. https://launchpadlibrarian.net/140581585/buildlog_ubuntu-raring-amd64.linux_3.8.0-999~bfsbfq1_FAILEDTOBUILD.txt.gz | 09:31 |
| NikTh | I have already uploaded a package with this.. tilda (I think is the name) character inside and I had no problem. 3.8.0-21.32nikth1~bfsbfq1 | 09:31 |
| NikTh | But this time I have a problem. I changed the ABI number because I didn't want users who add my PPA to upgrade the Official Ubuntu kernel with mine. I want to install (if they want) a new kernel version manually. | 09:32 |
| apw | NikTh, indeed ~ is valid in a version not in a package name | 09:32 |
| apw | NikTh, that is a debian dpkg limitiation. the kernel copies the version before the first - in the version into the binary package names, which means you cannot have a ~ before the first - in a version in the kernel packages | 09:33 |
| NikTh | apw: sorry but I need to understand this little better. This pacakge name is correct: 3.8.0-21.32nikth1~bfsbfq1. This package name isn't correct : linux_3.8.0-999~bfsbfq1 . What is the major difference here? And how can I set up a correct name that will indicates a completely different version. | 09:37 |
| NikTh | A completely different version so when a user add my PPA this will not upgrade the Official Ubuntu kernel. But if he/she want to install my kernel he/she must do it manually. | 09:39 |
| apw | it is actually everything to the first . following the first - that is copied out of the version into the package names | 09:40 |
| apw | therefore you cannot add a ~foo to the ABI number | 09:40 |
| apw | and anyhow 999~foo would sort higher than any version we would use | 09:40 |
| apw | so you would still upgrade the kernel regardless | 09:40 |
| apw | i cannot see why you would care if your package upgrades their kernel | 09:41 |
| apw | surely the point of adding you PPA would be to get the kernel and you | 09:41 |
| apw | want that to be automatic. if the PPA has other things in it, you might really want | 09:41 |
| apw | a new PPA for this kernel alone | 09:41 |
| apw | you can have more than one iirc | 09:41 |
| NikTh | Ohh.. so I miss a dot here ? Correct name would be: 3.8.0-99.9.1~bfsbfq1 ? | 09:42 |
| NikTh | sorry I meant : 3.8.0-999.1~bfsbfq1 | 09:42 |
| NikTh | apw: Yes, I don't have a problem to create a new PPA for this propose. I just consider this upgrade thing as .... dangerous ? Better would be to install new kernel Insead of upgrade the current one. | 09:44 |
| NikTh | I screwed up ABI number. And the builder thought this 999~bfsbfq1 was the ABI ? Am I correct ? | 09:50 |
| apw | NikTh, right, you cannot have a ~ in the name of a package, which includes the ABI number, which you set to 999~b... | 11:27 |
| NikTh | apw: Do I must edit the debian/control file in order to create a new custom name ? For example the name : linux-nick 3.8.0-23.foo.32 I think is correct and also I will achieve my goal (not upgrade ubuntu's kernel), but of course it conflicts in debuild -S | 11:31 |
| apw | NikTh, in principle that would be ok, but in practice the kernle produces prodigious numbers of ancillary packages which also would need to be changed to prevent their kernel being replaced | 11:32 |
| apw | NikTh, using your own ABI number which is high like 500 or whatever (but without any text in it) would at least keep it separate and non-overlapping | 11:32 |
| apw | NikTh, _but_ it will be preferred over all of our kernels regardless of version | 11:33 |
| NikTh | apw: So if anyone add my PPA, he/she will install a custom-kernel and Ubuntu kernels will not be replaced, BUT he/she will not receive any updates in future from Ubuntu official kernel because of ABI number. No, this is not good (IMO). I want a separate package, a package that not effect or defect the original Ubuntu kernels in any case. | 11:39 |
| apw | NikTh, anything you install which places a bootable kernel in a place where grub will use it, will trigger that kernel to either be so new it is always new, or so old it is never the default boot. | 11:45 |
| apw | NikTh, if you want people to have to select it each time in grub then you could make the ABI number much lower than all of ours, so they would get our updates; but that would mean they have to take action at the grub menu to get your kernel | 11:46 |
| NikTh | apw: Is this allowed ? I mean to upload a version older than the current ? | 11:49 |
| apw | nope, a ppa will reject that | 11:49 |
| apw | bah, what you want to do is hard | 11:50 |
| Adri2000 | hi | 12:21 |
| Adri2000 | the -22 kernel in raring has a regression over -21. it's not that critical (brightness control), but thought it might be useful to let you know | 12:23 |
| Adri2000 | this is bug #1163720 | 12:23 |
| ubot2 | Launchpad bug 1163720 in Linux "Brightness control broken on XPS13 with 3.8.0-16" [Medium,Incomplete] https://launchpad.net/bugs/1163720 | 12:23 |
| maxb | Adri2000: The bug title disagrees with what you said (about versions) | 12:30 |
| apw | Adri2000, yeah what maxb said; if that bug is not your bug I would file a new one for your machine and add a comment mentioning the other one | 12:31 |
| apw | kamal, was the XPS13 the one your kernel was for ? | 12:31 |
| Adri2000 | maxb, apw: see the last two comments of the bug report. it's the right bug, that was fixed at some point, and reappeared with the -22 kernel | 12:36 |
| maxb | If you're *strongly convinced* it's the same bug exactly, update the bug title - otherwise, consider whether it would be appropriate to open another bug report (mentioning the previous one, of course, but tracking the new occurrence) | 12:37 |
| maxb | Oh, actually, having just read the comment just before those two, *definitely* open a new bug | 12:38 |
| apw | Adri2000, it is good to get the exact h/w you have etc, in case there is a subtlty etc. | 12:40 |
| Adri2000 | looking at the kernel changelog I see the the fix has been explicitely reverted: "SAUCE: (no-up) drm/i915: revert PCH_PWM_ENABLE quirk for XPS13-FHD", mentioning another bug report | 12:40 |
| apw | jsalisbury, ^^ | 12:40 |
| Adri2000 | yeah, I'll try to investigate a bit, but any more information would be welcome as well :) | 12:41 |
| apw | Adri2000, ahh ... then yes that is expected, and in that case it probabally should have been reopened when we reverted the patch | 12:41 |
| jsalisbury | apw, ack | 12:41 |
| apw | henrix, ^^ | 12:41 |
| apw | jsalisbury, ta | 12:41 |
| jsalisbury | Adri2000, I'll take a look at the bug report | 12:41 |
| henrix | apw: looking | 12:42 |
| apw | henrix, it seems we reverted the fix explicitly but it is implied here the bug remained closed | 12:43 |
| henrix | apw: yep, looks like we need to either re-open or create a new bug. | 12:43 |
| henrix | apw: maybe its better to wait for kamal to be around, both bugs have been handled by him. lets see what are his thoughts on this | 12:44 |
| henrix | looks like the patch to fix the bug breaks something else | 12:45 |
| apw | henrix, yeah, when we revert we need to remember to move things back from Fix Released so they do not get lost ... shame LP has no syntax for it | 12:59 |
| henrix | apw: yep, that would help. i'll move it back to Confirmed and ping kamal on this | 13:00 |
| apw | henrix, great, that seems safest | 13:00 |
| === kentb-out is now known as kentb | ||
| === kentb is now known as kentb-afk | ||
| rsalveti | rtg: were you able to test the grouper kernel? | 14:44 |
| rsalveti | that's the only one pending still | 14:44 |
| rtg | I have not yet. too many other distractions. | 14:45 |
| rtg | I can get to it today | 14:45 |
| kamal | Adri2000, apw, jsalisbury, henrix: fyi, that "revert" commit did not actually revert the brightness fix for bug #1163720 ... the original fix commit applied the quirk to both the original XPS13 and the newer XPS13-FHD, but ... | 15:28 |
| ubot2 | Launchpad bug 1163720 in linux (Ubuntu Raring) "Brightness control broken on XPS13 with 3.8.0-16" [Medium,Confirmed] https://launchpad.net/bugs/1163720 | 15:28 |
| kamal | we then determined that it actaully broke brightness control on the XPS13-FHD (brightness control seemed to work on the -FHD without any additional fix needed), so ... | 15:29 |
| kamal | the commit "SAUCE: (no-up) drm/i915: revert PCH_PWM_ENABLE quirk for XPS13-FHD" actually just removed the application of the quirk for the XPS13-FHD. | 15:29 |
| kamal | at that point (3.8.0-21), all of the XPS13{,-FHD} users seemed satisfied. so . . . . | 15:30 |
| henrix | kamal: ok, so do you think its worth building a test kernel reverting that revert? | 15:30 |
| kamal | if its broken again in 3.8.0-22 (arrrghghgh!) then we'll need an all new bug report -- not a reopen of 1163720 | 15:30 |
| kamal | ... and the information: is this on an XPS13, or an XPS13-FHD ? | 15:31 |
| kamal | henrix, first thing: I'll test 3.8.0-22 on my (non-FHD) original model XPS13 as a sanity check | 15:32 |
| henrix | kamal: ok, cool. just a detail: i moved back the bug to 'confirmed'. you already said that's probably not the right thing to do, so... | 15:33 |
| kamal | henrix, I'll fix it | 15:33 |
| kamal | :-) | 15:33 |
| henrix | kamal: ok, cool. but maybe we want a new bug # first to add the comment before changing? | 15:34 |
| kamal | henrix, let me test -22 (will do momentarily) then we'll sort it out | 15:34 |
| henrix | ack | 15:34 |
| kamal | henrix, Adri2000: on my (non-FHD) original model XPS13, the brightness control still works fine for me with 3.8.0-22.33, so ... | 15:37 |
| === kentb-afk is now known as kentb | ||
| kamal | Adri2000, is yours the new XPS13-FHD model, perchance? I'm now not sure if the issue here is that the quirk *does* need to applied to some -FHD's but not others, or if something else in the i915 driver changed out from under me again . . . | 15:39 |
| rtg | ogasawara, remind me again, when does Raring LTS kernel go EOL ? when 14.04 LTS is published ? (which is longer then the 9 month support window for raring). I get so confused. | 15:43 |
| kamal | Adri2000, fyi, bug #1169376 is the one where we determined that applying the quirk broke the XPS13-FHD, hence the "revert" commit to remove the -FHD from the quirk list. | 15:52 |
| ubot2 | Launchpad bug 1169376 in linux (Ubuntu) "XPS13 backlight stopped working after update 3.8.0-18.28" [Undecided,Confirmed] https://launchpad.net/bugs/1169376 | 15:52 |
| ogasawara | rtg: 14.04.1 time frame | 15:56 |
| ogasawara | rtg: we wanted some baking time of the official 14.04 HWE kernel in Precise before we EOL'd the previous stacks | 15:56 |
| ogasawara | rtg: and indeed it'll be longer than the natural Raring support window of 9mo | 15:57 |
| rtg | ogasawara, we have a wiki page on this right ? I should start embedding that URL into the descriptions of the meta packages. | 15:57 |
| ogasawara | rtg: https://wiki.ubuntu.com/Kernel/LTSEnablementStack | 15:57 |
| bjf[afk] | rtg, ogasawara if 14.04 follows a similar schedule to 12.04 then 14.04.1 would come out around the 3rd week in Aug. of 2014 | 15:58 |
| === bjf[afk] is now known as bjf | ||
| rtg | which gives raring 14 months of support | 15:58 |
| bjf | rtg, the raring kernel anyways, yes | 15:59 |
| rtg | right | 15:59 |
| Kalidarn | i can confirm 3.8.0-22 panics 100% of the time 3.8.0-21 works fine though | 16:34 |
| bjf | Kalidarn, do you have a bug # ? | 16:35 |
| Kalidarn | pretty sure it is bug 1182038 | 16:35 |
| ubot2 | Launchpad bug 1182038 in linux (Ubuntu) "kernel panic fatal exception in interrupt" [High,Confirmed] https://launchpad.net/bugs/1182038 | 16:35 |
| Kalidarn | i see that: VFS: Cannot open root device "UUID=<uuid>" or unknown-block(0.0: error -6 | 16:36 |
| Kalidarn | it must be a nasty regression because i booted -22 3 times failed on all 3 times, then i booted -21 and it worked. | 16:36 |
| bjf | Kalidarn, can you start tracking that bug and contribute to the testing? | 16:37 |
| Kalidarn | sure | 16:37 |
| Kalidarn | hmm not sure if it is the same thing | 16:38 |
| Kalidarn | it seems to load module verification cerificates right. | 16:38 |
| bjf | Kalidarn, go ahead and open a new bug and we can worry about it being a dupe later | 16:38 |
| Kalidarn | "please append a correct "root=" boot option; here to the available partitions: | 16:39 |
| Kalidarn | i haven't edited my grub configs. | 16:39 |
| bjf | Kalidarn, did you open a new bug? | 16:51 |
| Kalidarn | bjf: bug 1183912 i filed is probably a duplicate but i don't really knwo | 16:52 |
| ubot2 | Launchpad bug 1183912 in linux (Ubuntu) "Kernel 3.8.0-22 fails to boot." [Undecided,New] https://launchpad.net/bugs/1183912 | 16:52 |
| Kalidarn | *know much more | 16:52 |
| Kalidarn | if anyone has any specific things they want me to test just ping my name, i really must be going to bed :) | 16:54 |
| Kalidarn | no doubt im not the only one effected | 16:54 |
| Kalidarn | though i suppose it could be a specific hardware configuration | 16:54 |
| bjf | Kalidarn, i'll add a test request to the bug | 17:26 |
| * rtg -> lunch | 17:30 | |
| bjf | bjf -> lunch | 17:54 |
| === bjf is now known as bjf[afk] | ||
| * rtg -> EOW | 18:59 | |
| === bjf[afk] is now known as bjf | ||
| bjf | i'm back | 19:23 |
| infinity | plars: Did we come to any conclusions about ti-omap4? | 19:25 |
| plars | infinity: sbeattie was looking at it, said he has a patch for the test | 19:27 |
| plars | infinity: but it did *not* fail on the older kernel | 19:27 |
| plars | ... | 19:28 |
| plars | <plars> sbeattie: and I did see it on two separate runs with the sru kernel | 19:28 |
| plars | <plars> sbeattie: now, 3 runs not sufficient to say it's not still a random occurrence, but I found it a bit odd | 19:28 |
| plars | <plars> works fine on 3.2.0-1430-omap4 #39 the problem happened on 3.2.0-1432-omap4 #41 | 19:28 |
| plars | infinity: ^ | 19:28 |
| infinity | plars: Could still be a fluke. Or could be that the new kernel changed something entirely unrelated just enough to tickle a weird race in the test? | 19:30 |
| Adri2000 | kamal: I don't know how can I reliably check what version of the XPS 13 I have (is it somewhere in the output of lshw or dmidecode?); but I know it has a full hd screen (aka I'm using 1920x1080 resolution) | 21:42 |
| plars | infinity: I think both sbeattie and I are at a loss, I've not been able to reproduce this timout when running the test in isolation | 21:48 |
| plars | infinity: but unless sbeattie disagrees, I think the risk is low because a) we know the test *can* pass because it works when I run it standalone, and b) it's not an explicit failure, just a timeout | 21:49 |
| infinity | plars: Yeah, I'm not fussed about it, especially if it's not breaking in isolation. It may well just be a fluke that you tripped it twice. | 21:51 |
| plars | yes, known possibility | 21:51 |
| plars | I'll comment on the bug, but call it passed | 21:51 |
| infinity | plars: Odds are that you could trip it in isolation if you ran it a few thousand times (for i in `seq 1 3000`; do test.py; done), but meh. | 21:51 |
| plars | infinity: I suspect it may have something to do with previous tests getting the system slowed just enough | 21:52 |
| infinity | Could be coming out of swap death from the previous test(s), yes. | 21:52 |
| infinity | Restoring your entire system's RAM over a USB link isn't quick. | 21:52 |
| plars | indeed | 21:53 |
| === kentb is now known as kentb-out | ||
| sbeattie | plars, infinity: no objection from me. | 23:11 |
| infinity | sbeattie: Good deal, cause I already released it based on jjohansen's say-so. ;) | 23:19 |
| sbeattie | hehe | 23:20 |
| sbeattie | phew, I was worried for 30 seconds that my opinion might actually be important. | 23:20 |
| infinity | And the ABI checker is too quick. It caught the LP OOPS that made the kernel/meta updates span a publisher cycle. :/ | 23:21 |
| infinity | Oh well, should be all fixed now. | 23:22 |
| === fmasi is now known as fmasi_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!