/srv/irclogs.ubuntu.com/2014/05/15/#ubuntu-kernel.txt

oneHow is a system backed up to remake the install cd?02:01
one say backed up and remake the install cd, they are nearly the same thing.02:52
oneI say backed up and remake the install cd, they are nearly the same thing.02:53
oneIf the install cd installs a clone of the system it is also a backup.02:53
oneHi e11bits 03:00
one;5C03:01
one;5C03:01
oneWhat are the packages required for the dpkg build system again?06:13
oneI want to save them but it looks like apt-get is autocleaning the cache or else a remote prompted it.06:14
=== smb` is now known as smb
GortiZHi I'm trying to bisect the kernel between 3.15 and 3.14 to find the commit which fixes a but I've on my laptop. I think I'm doing something wrong due to the "git log" reporting strange dates per the last commit between the bisects.07:46
GortiZI've marked the 3.14 as good and 3.15 as bad following the guide, then each kernel which is working is marked bad and each which is not working is marked good. Is this the correct path? (I'm just trying to check if I understood properly the guide since each steps takes half a day and git tells me that I need about 15 steps)07:46
=== fmasi_afk is now known as fmasi
apwGortiZ, a bisect can show commits from a merged branch which can be older than your oldest step, it sounds like you are doing a reverse bisect correctly.08:09
GortiZapw: thanks, so I'll go on and I hope to complete it before the end of the week. :)08:11
tseliotapw: I'm wondering why the tests didn't catch the failure with nvidia-30409:15
apwtseliot, /me will check09:17
apwtseliot, the tests did find it, but they also say it is as broken on trusty, therefore it is not a regression09:18
tseliotapw: I've just pushed a fixed nvidia-304. Apparently I had forgotten to patch it to build with 3.1409:18
tseliotapw: err... it should build in trusty09:18
tseliot(it does in my chroot here)09:19
apwtseliot, sorry ... as broken on utopic with the trusty kernel, but not with the trusty kernel in trusty ... odd09:19
apwtseliot, oh not, the disaster we call jenkins has just failed both the 32 and 64 bit builds due to hudson09:20
tseliotapw: it works fine here in my utopic chroot with the 3.13 kernel (i.e. what we have in the repository)09:20
tseliot:)09:20
apwdammit it all, this testing is USELESS if you cannot rely on the red/ggree blobs09:20
tseliothehe09:21
apwjibel, ^^ like 30-40% of the DKMS builds i have had to rerun because jenkins, if i have to read the logs for every single build every time, we may as well remove the red/green blobs09:21
infinityapw: jenkins must die, this isn't news. :/09:31
jibelapw, what do you mean "because of hudson" ? 09:32
apwno "because hudson", meaning "some random and different hudson error"09:32
jibelapw, http://d-jenkins.ubuntu-ci:8080/view/DKMS/view/U%20KT-PPA%20-generic/job/dkms-utopic-release_canonical_kernel_team_ppa-generic-nvidia_304/lastBuild/ARCH=amd64,label=wazn-adt/artifact/results/nvidia-304/304.117/build/make.log show a buld failure and the status is red09:32
jibelapw, ah sorry, hudson was the former name of jenkins :)09:32
apwyeah, in a lot of cases the top level job was red because it failed to get the two good greens from underneath; i've rerun all those09:33
apwand in the 307 case both the jobs exploded in the middle with a random error like "unable to delete file" in hudson land09:33
apwi've rerun them as well, but this level of baby sitting is just ass09:33
jibelapw, hm I see, jenkins lost the connection to the slave. I'll check if it's possible to restart the build in that case.09:37
apwif they could be made more robust all the better indeed09:37
jibelapw, I can just concur with infinity. I'll workaround by retriggering the tests that failed due to jenkins. 09:41
apwjibel, thanks :)09:42
ckingwhat happens in jenkins keeps on failing, won't it just spin forever re-doing the tests?09:56
infinitycking: I'm sure there could be a fail counter if a slave explodes N times in a row.  Though, honestly, if jenkins spins indefinitely, we sort of got what we paid for there.09:58
infinity(PS: jenkins sucks)09:58
ckingyep, just wanted to ask the obvious question, kind of sucks of jenkins was spinning on those tests forever09:59
ckings/of/if/09:59
=== fmasi is now known as fmasi_lunch
* apw notes that the rerun of those nvidia ones shows they should have been green, and there is/was a regression that tseliot fixed :)10:32
northHi, where can I get the Ubuntu-touch kernel to build for Nexus4 ?10:39
apwnorth, "get" what binaries source ?10:41
northsorry apw didn't understand that ?10:42
apwnorth, read it as "north, i don't think i understand what you are asking for?"10:44
northapw, I would like to know where I can find the kernel-sources for Ubuntu-touch ?10:50
apwthey are in our git repos, on branches by the target device, start with the trusty repo.  git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git10:51
northI use git behind corporate proxy, is there any way, I can download sources using http ? I mean are they hosted anywhere else by which I can clone using http protocol apw ?10:53
apwhttp://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-trusty.git i think10:53
northno such file10:54
apwlooks ok in my browser10:54
infinityThat URL certainly seems to be cloning fine here.10:56
apwyeah starts to clone ok here too10:56
apwnorth, ^10:56
infinityExcept for the shocking lack of verbosity when cloning over http...10:56
apwyeah its utterly crap isn't it10:57
apwand the immense slowness10:57
northyeah gotcha10:57
northforgot to export http variables :p10:57
=== fmasi_lunch is now known as fmasi
oneapw: any tips on how to get this onto an omap device?12:00
=== psivaa is now known as psivaa-afk
tjaaltondoes the kernel packaging allow building only changed bits when bisecting?12:09
tjaaltonlike, I've built a package, now I want to test another commit without building the whole kernel12:09
tjaaltonpackaging is not committed, using upstream branches12:09
apwtjaalton, "support" is probabally too strong12:10
apwi think you can remove the build stamp and it'll do the right thing12:10
apwdebian/stamps/something *build*12:10
apwbut don't let it clean12:10
tjaaltonah, ok12:10
apwthen agian if you build more than one flavour you lose i think12:11
tjaaltonjust binary-generic12:11
tjaaltonbut that target takes roughly 30min to compile on my box12:11
tjaaltonor a bit less, but still12:11
apwtjaalton, so that should be compatible with the stamp thing, remove stamp redo binary-generic12:16
tjaaltonok cool12:16
rtgtjaalton, when bisecting I always just use the deb-pkg target (which is mostly a native kernel build). Its much better about rebuilding with incremental changes.12:17
tjaaltonrtg: alright, I'll try that too12:17
rtgtjaalton, make sure you turn off debug in the config else you'll end up with a giant deb12:18
tjaaltongood point..12:18
rtgtjaalton, CONFIG_DEBUG_KERNEL I think12:19
rtgmake deb-pkg INSTALL_MOD_STRIP=112:19
tjaaltonyeah seems that removing the stamp didn't result in a diff build, seems to build everything12:33
tjaaltonand then fails later12:43
rtgtjaalton, 'fdr clean prepare-generic' then copy that config and use the deb-pkg target. without really deep knowledge of the Ubuntu packaging, bisect is an enormous pain in the ass.12:45
tjaaltonright :)12:45
tjaaltonhum, make -j 8 much better13:11
=== psivaa-afk is now known as psivaa
tjaaltongit bisect seems to assume that I'm bisecting a regression, when in fact it's the other way around.. how to reverse the logic?13:42
tjaaltonso I'm trying to find when a bug got fixed, but marking an earlier commit bad makes it barf13:43
tseliotthe man page says "git-bisect - Find by binary search the change that introduced a bug"13:44
tjaaltonok then, just reverse the meaning of those and it's fine :)13:44
tjaaltonso cheating works13:44
josephthttp://stackoverflow.com/questions/15407075/how-could-i-use-git-bisect-to-find-the-first-good-commit13:45
tjaaltonyeah, found that13:45
tseliotnice13:46
tjaaltonjust need to be careful when marking commits.. argh :)13:59
apwtjaalton, you can make aliases "worked" and "failed14:03
apwwich point to the right "good" "bad"14:03
tjaaltonyeah14:09
tjaaltonnice that deb-pkg bumps the package revision too14:09
tjaaltonon each build14:10
rtgtjaalton, yup, it just seems to DTRT14:14
tjaaltonvery handy14:14
bjfjsalisbury, in the precise tree: 9b33bf99915d39bbf699facefacfbd391289162e14:34
jsalisburybjf, that is still in proposed, correct?  3.2.0-6214:36
jsalisburywell now up to 3.2.63.9414:36
bjfjsalisbury, yes14:37
jsalisburybjf, ok.  I'll ask him to test proposed first14:37
bjfjsalisbury, where was that revert of that patch targeted? the one that you just recently sent to the mailing list.14:42
jsalisburybjf, It was not a revert request, it was a new patch.  It was requested for the lts-backport-raring kernel and lts-backport-quantal14:43
jsalisburybjf, but it looks like regular precise got it as well, which is fine.14:45
bjfjsalisbury, wasn't your new patch effectively a revert? it undid that setting of mac->link_state14:46
jsalisburybjf, oh wait, that is right.  commit 9b33bf99915d39bbf699facefacfbd391289162e adds that line and my patch removes it14:46
bjfjsalisbury, and that "bad" commit is in precise, quantal, saucy, trusty14:47
jsalisburybjf, right.  And the bug report says 3.2.0-63 is bad, which would have that commit and 3.2.0-61.93 would not.14:48
jsalisburybjf, so let me build a test kernel with a revert of that commit in 3.2.0-63 in precise and have him test that.14:48
bjfjsalisbury, i'm thinking that commit should be reverted in all our kernels14:52
jsalisburybjf, ack14:54
jsalisburybjf, I have a Precise test kernel building now with a revert.  I'll ask the bug reporter to test it and confirm it fixes the bug.14:54
onejsalisbury: for the NST?14:57
bjfi'm beginning to wonder if we should even release this set of kernels and just start the next SRU cycle on monday14:58
jsalisburyone, ?14:58
jsalisburybjf, test kernel is built and posted for bug 1319735.  I'll let you know if it fixes the bug.15:22
onecompile kernel for NST15:53
oneinclude drivers15:54
oneprovide sources15:54
bjfjsalisbury, you got a possitive test result on that kernel test16:20
jsalisburybjf, just looked, and yes it does16:20
oneDoes philipballew need a task?16:48
questor_Hi. I have a crashing linux-kernel during startup of a laptop. it's all the time in an interrupt, but always a different callstack. how can I get more information to find out what is going on? (when I can get to the desktop it's working fine for many hours, but getting there is difficult)17:11
questor_system is linux-mint16 with kernel 3.14.4-031404-generic17:12
onequestor_: check the logs17:15
onephilipballew: compile kernel for NST17:15
onephilipballew confirm receipt of task17:17
bjfone, please don't make me ban you. if you keep pestering people i will do so17:25
apwquestor_, those are only debug kernels made from pure upstream source not really intended for production use18:34
apwquestor_, does this occur with the release kerenls?18:34
questor_I had issues with the default 3.11 from mint and upgraded in the hope of a fix18:36
questor_I'm inspecting kernel-logs and it seems that when the system does not boot there are (besides others) messages like "ACPI.... CPU4: failed to get CPU APIC ID." 18:36
questor_when it's booting I can't see this messages in the log18:37
questor_and ACPI warnings: "SystemIO range conflicts"18:38
apwquestor_, sounds lovely indeed, i would file a bug against the kernel in linux-mint for that indeed18:39
apwand add those bad logs to it, they may make more sense en-toto18:39
questor_when the kernel crashes it's always in an interrupt (nmi), but always different callstack. and most of the time the nmi takes much too long to be processed18:39
questor_okay. will do that18:40
questor_thanks18:41
apwquestor_, you might try the latest 3.11.0-22.37 from ubuntu on there and see if that helps; you never know18:47
questor_apw: had the same issue with the the 3.11-kernel18:51
apwquestor_, what version was that though, was it the latest18:52
questor_I had mint 16 installed with the default kernel, so I think it was based on the ubuntu-stable, mom, I will try to find it out18:53
questor_3.11.0-19-generic seems to work, now I will test 3.11.0-20-generic18:58
questor_3.11.0-20 seems also to work. okay, will downgrade and test.19:02
questor_thanks!19:02
=== broder_ is now known as broder

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