=== ricotz_ is now known as ricotz
[14:00] <ali1234> i'm trying to build a kernel with mainline-build-one
[14:00] <ali1234> it fails with this error: trusty-amd64: chroot not found (::,)
[14:02] <rtg> cyphermox, everything appears to be correct in ppa:canonical-kernel-team/unstable 
[14:02] <rtg> (and built)
[14:03] <cyphermox> ok
[14:04] <ali1234> i am trying to bisect from v3.17-utopic to v3.18-rc1-utopic
[14:04] <ali1234> my build system is running trusty
[14:05] <apw> ali1234, mainline-build-* all assume you have builder chroots available, they are not very smart
[14:08] <ali1234> okay. well i am trying to follow this wiki page: https://wiki.ubuntu.com/Kernel/KernelBisection
[14:08] <ali1234> none of the instructions there seem to work
[14:08] <ali1234> and indeed the links to other pages don't seem to make any sense
[14:09] <ali1234> it seems like this page is very very out of date
[14:09] <ali1234> for example "First, follow the KernelTeam/GitKernelBuild  guide to build a new kernel from git.  The step you will be doing the  most is #9. "--append-to-version=-custom" is very important to change to  help differeniate your kernels."
[14:09] <apw> ali1234, hrm, that would not supprise me, the problem with documents is you stop using them once you know how to do something
[14:09] <ali1234> if you follow that link, step 9 is "cd .."
[14:09] <apw> jsalisbury, ^ this is right in your balywick ... you do a lot of bisections
[14:16] <ali1234> https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter seems to have instructions to create a builder chroot?
[14:19] <ali1234> seems a little outdated again... the script has a different name now
[14:19] <ali1234> Error: /usr3/chroots does not exist.
[14:21] <ali1234> apparently i have to make it... okay
[14:21] <rtg> ali1234, just create it. 'sudo mkdir -p /usr3/chroots'
[14:27] <kilbith> hello, silly question : does the current ubuntu kernel (4.4) has backporting of upstream kernel patches (as both kernels are LTS) ?
[14:33] <apw> kilbith, i assume you are asking does the ubuntu 16.04 kernel recieve upstream stable updates ... to which the answer is yes
[14:35] <jsalisbury> ali1234, apw, I'll add it to my list to go through those pages, test and update as nessessarry.  
[14:37] <kilbith> apw, hmmm ok but then the ubuntu kernel versioning ought not be stuck on 4.4.0, which is misleading
[14:38] <apw> kilbith, that is a complex thing to answer, but the short answer is that that part has to be 3 digit or userspace gets broken, but if we change that a lot it means we cannot hsare the same .orig blowing up the archive side storage requirements
[14:38] <apw> kilbith, i have a branch pending for Yakkety to drop that .0 from the versioning
[14:39] <apw> an LTS was not hte place to play with such things
[14:40] <kilbith> well changing the minor versioning would inform the users at which point the ubuntu kernel is sync with upstream
[14:41] <rtg> kilbith, but that would be inaccurate since the Ubuntu kernel is never exactly in sync with upstream
[14:41] <kilbith> "never exactly" <- by how much usually ?
[14:42] <rtg> kilbith, feel free to do a comparison between Xenial and vanilla 4.4
[14:42] <kilbith> that's a bit pain with git
[14:43] <kilbith> #ubuntu-mesa
[14:44] <kilbith> oops, sorry
[14:45] <apw> kilbith, the minor version as reported by uname is that version
[14:45] <apw> kilbith, sorry in /proc/version_signature
[14:46] <kilbith> oh right - 4.4.8
[14:46] <kilbith> while upstream is at 4.4.12 already, fyi
[14:50] <apw> kilbith, yep, though the next kernel which has been in testing for a couiple of weeks is at least 4.4.11
[14:50] <rtg> and master-next has 4.4.12 applied
[14:50] <kilbith> well rushing onto new versions is not necessarily a good thing
[14:51] <apw> right we stage them in as we cut updates in each sru cycle, so whatever is available as we open the cycle is applied
[14:51] <apw> then we test that for a couple of weeks and then release it
[14:51] <kilbith> but i'm also surprised why some past ubuntu releases did not choose LTS kernels for example
[14:51] <kilbith> that makes no sense
[14:51] <kilbith> *Ubuntu LTS releases, sorry
[14:52] <apw> kilbith, because we do not control which kernels upstream are LTS and sometimes we have had to chose a kernel and commit to it before upstream has made a choice
[14:52] <apw> though this time we managed to have that conversation early enough to get the alignment we would desire
[14:53] <kilbith> i assume you're mainly constrained by the release schedule and you pick the latest kernel whenever a new release is imminent
[14:53] <kilbith> on the other hand Debian stable always pick a LTS kernel
[14:54] <apw> kilbith, not quite true, they are using a kernel we maintained stable on for a long time
[14:54] <apw> kilbith, for one of their releases
[14:54] <apw> but in general we are not looking to be doing our own work if we can be aligned, sometimes that is not possible in an LTS, this time it was
[14:55] <kilbith> hmm, i just checked on distrowatch and indeed all debian stable and oldstable kernels are LTS
[14:56] <kilbith> http://distrowatch.com/table.php?distribution=debian
[14:58] <apw> kilbith, jessie is on 3.16 which was not an official LTS kernel, that we in ubuntu supported for several years, and now debian themselves are supporting it
[14:58] <kilbith> ah ok, i get it
[14:58] <apw> kilbith, alignement is not always possible for them or us, though that time we were at least aligned between them and us
[14:59] <kilbith> that's surprising since they have more developers for maintaining
[15:04] <ali1234> i think i'm getting a bit closer. now i get: trusty-amd64: chroot not found ( chroot:utopic-amd64 ::Available chroots: utopic-amd64,)
[16:02] <ali1234> hmm... it wants a trusty chroot?
[16:02] <ali1234> okay... whatevs
[17:41] <ali1234> now i get: I: You do not have permission to access the schroot service.
[17:41] <ali1234> am i supposed to run this with sudo or what?
[17:50] <apw> ali1234, you prolly have to give yourslef permission, likely you got added to the schroot group but have not logged out/in since
[17:51] <ali1234> i wasn't added
[17:51] <ali1234> think it will help if i add myself?
[17:51] <ali1234> schroot isn't even a group
[18:04] <rtg> ali1234, I think you need to be in the sbuild group
[18:06] <ali1234> nope, still doesn't work
[18:06] <ali1234> E: default: Chroot not found
[18:07] <rtg> ali1234, ah, that is different. what is in /etc/schroot/chroot.d/ ?
[18:07] <ali1234> a file for each of the chroots i have made using make_chroot
[18:08] <ali1234> trusty-amd64, trusty-i386 and utopic-amd64
[18:08] <ali1234> so i tried to run "schroot trusty-amd64" and got that error
[18:08] <rtg> schroot -c trusty-amd64 ?
[18:08] <ali1234> ah there we go, it works!
[18:10] <ali1234> and it's building a kernel finally. thanks :)