=== ricotz_ is now known as ricotz | ||
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:00 |
rtg | cyphermox, everything appears to be correct in ppa:canonical-kernel-team/unstable | 14:02 |
rtg | (and built) | 14:02 |
cyphermox | ok | 14:03 |
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:04 |
apw | ali1234, mainline-build-* all assume you have builder chroots available, they are not very smart | 14:05 |
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:08 |
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:09 |
ali1234 | https://wiki.ubuntu.com/KernelTeam/KernelMaintenanceStarter seems to have instructions to create a builder chroot? | 14:16 |
ali1234 | seems a little outdated again... the script has a different name now | 14:19 |
ali1234 | Error: /usr3/chroots does not exist. | 14:19 |
ali1234 | apparently i have to make it... okay | 14:21 |
rtg | ali1234, just create it. 'sudo mkdir -p /usr3/chroots' | 14:21 |
kilbith | hello, silly question : does the current ubuntu kernel (4.4) has backporting of upstream kernel patches (as both kernels are LTS) ? | 14:27 |
apw | kilbith, i assume you are asking does the ubuntu 16.04 kernel recieve upstream stable updates ... to which the answer is yes | 14:33 |
jsalisbury | ali1234, apw, I'll add it to my list to go through those pages, test and update as nessessarry. | 14:35 |
kilbith | apw, hmmm ok but then the ubuntu kernel versioning ought not be stuck on 4.4.0, which is misleading | 14:37 |
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:38 |
apw | an LTS was not hte place to play with such things | 14:39 |
kilbith | well changing the minor versioning would inform the users at which point the ubuntu kernel is sync with upstream | 14:40 |
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:41 |
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:42 |
kilbith | #ubuntu-mesa | 14:43 |
kilbith | oops, sorry | 14:44 |
apw | kilbith, the minor version as reported by uname is that version | 14:45 |
apw | kilbith, sorry in /proc/version_signature | 14:45 |
kilbith | oh right - 4.4.8 | 14:46 |
kilbith | while upstream is at 4.4.12 already, fyi | 14:46 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
kilbith | hmm, i just checked on distrowatch and indeed all debian stable and oldstable kernels are LTS | 14:55 |
kilbith | http://distrowatch.com/table.php?distribution=debian | 14:56 |
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:58 |
kilbith | that's surprising since they have more developers for maintaining | 14:59 |
ali1234 | i think i'm getting a bit closer. now i get: trusty-amd64: chroot not found ( chroot:utopic-amd64 ::Available chroots: utopic-amd64,) | 15:04 |
ali1234 | hmm... it wants a trusty chroot? | 16:02 |
ali1234 | okay... whatevs | 16:02 |
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:41 |
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:50 |
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 | 17:51 |
rtg | ali1234, I think you need to be in the sbuild group | 18:04 |
ali1234 | nope, still doesn't work | 18:06 |
ali1234 | E: default: Chroot not found | 18:06 |
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:07 |
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:08 |
ali1234 | and it's building a kernel finally. thanks :) | 18:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!