[02:01] <one> How is a system backed up to remake the install cd?
[02:52] <one>  say backed up and remake the install cd, they are nearly the same thing.
[02:53] <one> I say backed up and remake the install cd, they are nearly the same thing.
[02:53] <one> If the install cd installs a clone of the system it is also a backup.
[03:00] <one> Hi e11bits 
[03:01] <one> ;5C
[03:01] <one> ;5C
[06:13] <one> What are the packages required for the dpkg build system again?
[06:14] <one> I want to save them but it looks like apt-get is autocleaning the cache or else a remote prompted it.
=== smb` is now known as smb
[07:46] <GortiZ> Hi 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] <GortiZ> I'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)
=== fmasi_afk is now known as fmasi
[08:09] <apw> GortiZ, 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:11] <GortiZ> apw: thanks, so I'll go on and I hope to complete it before the end of the week. :)
[09:15] <tseliot> apw: I'm wondering why the tests didn't catch the failure with nvidia-304
[09:17] <apw> tseliot, /me will check
[09:18] <apw> tseliot, the tests did find it, but they also say it is as broken on trusty, therefore it is not a regression
[09:18] <tseliot> apw: I've just pushed a fixed nvidia-304. Apparently I had forgotten to patch it to build with 3.14
[09:18] <tseliot> apw: err... it should build in trusty
[09:19] <tseliot> (it does in my chroot here)
[09:19] <apw> tseliot, sorry ... as broken on utopic with the trusty kernel, but not with the trusty kernel in trusty ... odd
[09:20] <apw> tseliot, oh not, the disaster we call jenkins has just failed both the 32 and 64 bit builds due to hudson
[09:20] <tseliot> apw: 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] <apw> dammit it all, this testing is USELESS if you cannot rely on the red/ggree blobs
[09:21] <tseliot> hehe
[09:21] <apw> jibel, ^^ 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 blobs
[09:31] <infinity> apw: jenkins must die, this isn't news. :/
[09:32] <jibel> apw, what do you mean "because of hudson" ? 
[09:32] <apw> no "because hudson", meaning "some random and different hudson error"
[09:32] <jibel> apw, 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 red
[09:32] <jibel> apw, ah sorry, hudson was the former name of jenkins :)
[09:33] <apw> yeah, 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 those
[09:33] <apw> and in the 307 case both the jobs exploded in the middle with a random error like "unable to delete file" in hudson land
[09:33] <apw> i've rerun them as well, but this level of baby sitting is just ass
[09:37] <jibel> apw, 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] <apw> if they could be made more robust all the better indeed
[09:41] <jibel> apw, I can just concur with infinity. I'll workaround by retriggering the tests that failed due to jenkins. 
[09:42] <apw> jibel, thanks :)
[09:56] <cking> what happens in jenkins keeps on failing, won't it just spin forever re-doing the tests?
[09:58] <infinity> cking: 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:59] <cking> yep, just wanted to ask the obvious question, kind of sucks of jenkins was spinning on those tests forever
[09:59] <cking> s/of/if/
=== fmasi is now known as fmasi_lunch
[10:32]  * 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:39] <north> Hi, where can I get the Ubuntu-touch kernel to build for Nexus4 ?
[10:41] <apw> north, "get" what binaries source ?
[10:42] <north> sorry apw didn't understand that ?
[10:44] <apw> north, read it as "north, i don't think i understand what you are asking for?"
[10:50] <north> apw, I would like to know where I can find the kernel-sources for Ubuntu-touch ?
[10:51] <apw> they are in our git repos, on branches by the target device, start with the trusty repo.  git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
[10:53] <north> I 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] <apw> http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-trusty.git i think
[10:54] <north> no such file
[10:54] <apw> looks ok in my browser
[10:56] <infinity> That URL certainly seems to be cloning fine here.
[10:56] <apw> yeah starts to clone ok here too
[10:56] <apw> north, ^
[10:56] <infinity> Except for the shocking lack of verbosity when cloning over http...
[10:57] <apw> yeah its utterly crap isn't it
[10:57] <apw> and the immense slowness
[10:57] <north> yeah gotcha
[10:57] <north> forgot to export http variables :p
=== fmasi_lunch is now known as fmasi
[12:00] <one> apw: any tips on how to get this onto an omap device?
=== psivaa is now known as psivaa-afk
[12:09] <tjaalton> does the kernel packaging allow building only changed bits when bisecting?
[12:09] <tjaalton> like, I've built a package, now I want to test another commit without building the whole kernel
[12:09] <tjaalton> packaging is not committed, using upstream branches
[12:10] <apw> tjaalton, "support" is probabally too strong
[12:10] <apw> i think you can remove the build stamp and it'll do the right thing
[12:10] <apw> debian/stamps/something *build*
[12:10] <apw> but don't let it clean
[12:10] <tjaalton> ah, ok
[12:11] <apw> then agian if you build more than one flavour you lose i think
[12:11] <tjaalton> just binary-generic
[12:11] <tjaalton> but that target takes roughly 30min to compile on my box
[12:11] <tjaalton> or a bit less, but still
[12:16] <apw> tjaalton, so that should be compatible with the stamp thing, remove stamp redo binary-generic
[12:16] <tjaalton> ok cool
[12:17] <rtg> tjaalton, 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] <tjaalton> rtg: alright, I'll try that too
[12:18] <rtg> tjaalton, make sure you turn off debug in the config else you'll end up with a giant deb
[12:18] <tjaalton> good point..
[12:19] <rtg> tjaalton, CONFIG_DEBUG_KERNEL I think
[12:19] <rtg> make deb-pkg INSTALL_MOD_STRIP=1
[12:33] <tjaalton> yeah seems that removing the stamp didn't result in a diff build, seems to build everything
[12:43] <tjaalton> and then fails later
[12:45] <rtg> tjaalton, '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] <tjaalton> right :)
[13:11] <tjaalton> hum, make -j 8 much better
=== psivaa-afk is now known as psivaa
[13:42] <tjaalton> git 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:43] <tjaalton> so I'm trying to find when a bug got fixed, but marking an earlier commit bad makes it barf
[13:44] <tseliot> the man page says "git-bisect - Find by binary search the change that introduced a bug"
[13:44] <tjaalton> ok then, just reverse the meaning of those and it's fine :)
[13:44] <tjaalton> so cheating works
[13:45] <josepht> http://stackoverflow.com/questions/15407075/how-could-i-use-git-bisect-to-find-the-first-good-commit
[13:45] <tjaalton> yeah, found that
[13:46] <tseliot> nice
[13:59] <tjaalton> just need to be careful when marking commits.. argh :)
[14:03] <apw> tjaalton, you can make aliases "worked" and "failed
[14:03] <apw> wich point to the right "good" "bad"
[14:09] <tjaalton> yeah
[14:09] <tjaalton> nice that deb-pkg bumps the package revision too
[14:10] <tjaalton> on each build
[14:14] <rtg> tjaalton, yup, it just seems to DTRT
[14:14] <tjaalton> very handy
[14:34] <bjf> jsalisbury, in the precise tree: 9b33bf99915d39bbf699facefacfbd391289162e
[14:36] <jsalisbury> bjf, that is still in proposed, correct?  3.2.0-62
[14:36] <jsalisbury> well now up to 3.2.63.94
[14:37] <bjf> jsalisbury, yes
[14:37] <jsalisbury> bjf, ok.  I'll ask him to test proposed first
[14:42] <bjf> jsalisbury, where was that revert of that patch targeted? the one that you just recently sent to the mailing list.
[14:43] <jsalisbury> bjf, It was not a revert request, it was a new patch.  It was requested for the lts-backport-raring kernel and lts-backport-quantal
[14:45] <jsalisbury> bjf, but it looks like regular precise got it as well, which is fine.
[14:46] <bjf> jsalisbury, wasn't your new patch effectively a revert? it undid that setting of mac->link_state
[14:46] <jsalisbury> bjf, oh wait, that is right.  commit 9b33bf99915d39bbf699facefacfbd391289162e adds that line and my patch removes it
[14:47] <bjf> jsalisbury, and that "bad" commit is in precise, quantal, saucy, trusty
[14:48] <jsalisbury> bjf, 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] <jsalisbury> bjf, 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:52] <bjf> jsalisbury, i'm thinking that commit should be reverted in all our kernels
[14:54] <jsalisbury> bjf, ack
[14:54] <jsalisbury> bjf, 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:57] <one> jsalisbury: for the NST?
[14:58] <bjf> i'm beginning to wonder if we should even release this set of kernels and just start the next SRU cycle on monday
[14:58] <jsalisbury> one, ?
[15:22] <jsalisbury> bjf, test kernel is built and posted for bug 1319735.  I'll let you know if it fixes the bug.
[15:53] <one> compile kernel for NST
[15:54] <one> include drivers
[15:54] <one> provide sources
[16:20] <bjf> jsalisbury, you got a possitive test result on that kernel test
[16:20] <jsalisbury> bjf, just looked, and yes it does
[16:48] <one> Does philipballew need a task?
[17:11] <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:12] <questor_> system is linux-mint16 with kernel 3.14.4-031404-generic
[17:15] <one> questor_: check the logs
[17:15] <one> philipballew: compile kernel for NST
[17:17] <one> philipballew confirm receipt of task
[17:25] <bjf> one, please don't make me ban you. if you keep pestering people i will do so
[18:34] <apw> questor_, those are only debug kernels made from pure upstream source not really intended for production use
[18:34] <apw> questor_, does this occur with the release kerenls?
[18:36] <questor_> I had issues with the default 3.11 from mint and upgraded in the hope of a fix
[18: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:37] <questor_> when it's booting I can't see this messages in the log
[18:38] <questor_> and ACPI warnings: "SystemIO range conflicts"
[18:39] <apw> questor_, sounds lovely indeed, i would file a bug against the kernel in linux-mint for that indeed
[18:39] <apw> and add those bad logs to it, they may make more sense en-toto
[18: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 processed
[18:40] <questor_> okay. will do that
[18:41] <questor_> thanks
[18:47] <apw> questor_, you might try the latest 3.11.0-22.37 from ubuntu on there and see if that helps; you never know
[18:51] <questor_> apw: had the same issue with the the 3.11-kernel
[18:52] <apw> questor_, what version was that though, was it the latest
[18:53] <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 out
[18:58] <questor_> 3.11.0-19-generic seems to work, now I will test 3.11.0-20-generic
[19:02] <questor_> 3.11.0-20 seems also to work. okay, will downgrade and test.
[19:02] <questor_> thanks!
=== broder_ is now known as broder