[09:08] <ricotz> henrix, hi :), are looking into backporting 4.2.0-19.23 as linux-lts-wily to trusty too?
[09:15] <henrix> ricotz: yes, i'll probably be uploading it into the kernel team PPA today.  soon it will hit -proposed
[09:24] <ricotz> henrix, great thanks
[10:37] <caribou> apw: smb` cking: any reason why vt.handoff=7 would break my boot following upgrade to Xenial ?
[10:37] <apw> caribou, you should have the same kernel as you had in wily, so no
[10:37] <caribou> I have a fully encrypted HD and unless I remove it, I just get a blank screen & nothing else
[10:38] <caribou> apw: I noticed a change in libplymouth
[10:38] <apw> caribou, try hitting esc (or is it tab) twice to switch out of and into graphics mode again at the prompt
[10:38] <caribou> I also loose my USB keyboard + external display
[10:39] <caribou> apw: thanks, will try that
[10:39]  * caribou biab
[10:40] <apw> caribou, what did you upgrade from, as the kernel, grub2, and plymouth are at the same versions in wily as xenial
[10:51] <caribou> apw: yes, I just noticed that
[10:51] <caribou> apw: I upgraded from Wily
[10:51] <caribou> apw: so hitting tab/esc brings me to the encryption password
[10:51] <caribou> so I'm able to boot but w/o sound, external display & USB keyboard even if this one is seen by the kernel
[10:52] <caribou> so I don't think it's a kernel issue
[11:12] <apw> caribou, very odd behaviour though.  i am going to guess the tab thing is a race as much as anything, i have seen that before i think
[11:13] <apw> caribou, but the  latter issues with sound etc is just plain strange
[11:13] <caribou> apw: indeed, I'm looking at it atm
[11:16] <caribou> apw: well, alsactl reports on soundcard found, so that takes care of it
[11:17] <apw> "no" or "one"
[11:17] <apw> ?
[11:18] <caribou> apw: alsactl[808]: /usr/sbin/alsactl: load_state:1735: No soundcards found...
[11:18] <caribou> apw: I also get systemd complains about apparmor
[11:18] <apw> oh systemd, hmmm, cking didn't you have that barfing on you as well ?
[11:19] <cking> apw, it SEGV'd on an arm64 debian unstable update for me
[11:19] <apw> there is a new apparmour in xenail-proposed
[11:19] <cking> rendered the machine unbootable
[11:20] <cking> apw, I was not using apparmor 'cos I was using debian unstable ;-)
[11:20] <apw> cking, if it was debian then its off the table 
[11:20] <apw> ta
[11:21]  * cking notes that since systemd is critical to a functioning system we should probably do static analysis and some kind of formal stress testing on it to see if we can shake out bugs
[11:23] <diwic> caribou, could it be that the -extra kernel package is missing?
[11:24] <diwic> caribou, that matches somewhat with your description of missing sound and USB
[11:25] <caribou> diwic: I think you are onto something, yes it's not there
[11:25] <caribou> err, NO it's not there
[11:27] <caribou> diwic: apw: is it normal NO TO FIND a linux-image-extra for linux-image-4.2.0-18-generic
[11:27] <caribou> let me reboot to .17 for which I have one
[11:27] <apw> caribou, it is not normal no
[11:28] <apw> have you lost your linux-generic or something ?
[11:30] <caribou> apw: diwic: ok .17 works fine, I got everything back
[11:31] <caribou> apw: let me recheck my archive, one second
[11:31] <apw> caribou, so confirm you have linux-generic installed correctly
[11:31] <apw> caribou, and also check that apt-get install -f doesn't say you are in the middle of an update
[11:33] <caribou> apw: apt-get -f install is fine
[11:34] <caribou> I disabled my squid-deb-proxy as well
[11:34] <apw> and you have linux-generic installed, and you have no linux-image-extra-* ?
[11:34] <caribou> yes
[11:34] <apw> for that abi ?
[11:34] <apw> that ... is impossible (in theory)
[11:35] <caribou> apw: here is the result of apt-cache search linux-image : http://paste.ubuntu.com/13237767/
[11:35] <caribou> apw: maybe a mirror issue, let me point directly to the main archive
[11:35] <apw> caribou, before you do that
[11:35] <apw> show linux-generic | egrep 'Version:|Depends:'
[11:36] <apw> apt-cache show linux-image-generic | egrep 'Version:|Depends:'
[11:39] <caribou> apw: http://paste.ubuntu.com/13237786/
[11:39] <caribou> apw: even with the main archive, I don't see any linux-image-extra for .18
[11:40] <apw> caribou, there is no -18 in xenial ... at alllll
[11:40] <caribou> apw: ok, now I now what happened
[11:41] <apw> this is a process fail, caused by the emergency cve release
[11:42] <caribou> apw: I manually installed .18 just before the upgrade because it was complaining that it couldn't find it in the xenial archive
[11:43] <caribou> apw: so I went back to wily & manually installed .18 (forgetting to install the -extra)
[11:43] <apw> caribou, ok ... that then is all explained, and i am asking for that to be copied up, it should have been
[11:43] <caribou> apw: then upgraded
[11:43] <apw> yep, and now you are in a mess :)
[11:43] <caribou> apw: well, no I still have .17 which has all the bits
[11:43] <apw> hopefully we'll get that copied up into xenial today, it should have been
[11:43] <caribou> apw: ok, so that's the source of the problem, good to know
[16:00] <dannf> rtg: thanks for the pull! sorry for not mentioning the branch - i actually thought about it and decided to omit it, because start/end hashs would be unique (if my git foo is accurate)
[16:03] <rtg> dannf, I think you have to know the branch in order to fetch the commit, but no matter. 
[16:05] <dannf> rtg: cool - yeah, will go back to including the branch name. TA!
[16:05] <apw> right, the sha1s are unique in space and time (in theory) but you need a handle which is exported, which is a tag or branch, you can't fetch arbitrary sha1s from a repo
[16:06]  * dannf didn't know you could restrict fetching shas to a branch - seems like every fetch i do from a remote get all objects
[16:06] <dannf> for some definition of all objects (not sure if objects from deleted branches are fetched)
[16:07] <rtg> dannf, a fetch should only be fetching the objects on that branch that you don't already have
[16:07] <rtg> if you fetch tags then you might be getting more then you need
[16:08] <dannf> i don't  - just get fetch. for example, when i git fetch my wily remote, i get both wily/master and wily/master-next
[16:13] <henrix> iirc, when you do 'git fetch' it will fetch all remote tracking branches (there's a git-config to set those i believe)
[16:14] <henrix> e.g. remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
[16:40] <apw> dannf, as henrix says a clean fetch is fetching "all branches" and any objects those reference you don't have
[16:43] <apw> dannf, so to use your sha's i'd have to actually add your entire repo as a remote and fetch it, then find the shas that way, its more normal to offer me a real branch as then i can git fetch git://... yourbranch:dannf
[16:43] <apw> ...
[16:45] <dannf> apw: got it - makes sense
[17:22] <kamal> rtg, so I find that I can get all of the linux/tools/* stuff to build in our chroots with just two more -dev packages:
[17:22] <kamal> +ADDPKG="$ADDPKG libpopt-dev libreadline6-dev"
[17:22] <kamal> I think we should just go ahead an add those to build-mkschroot
[17:23] <kamal> also, build-mkschroot feels like it needs a good cleanup ... there are waaaay too many separate case $SUITE clauses, including at least one that I think is entirely pointless
[17:24] <kamal> (a case that adds libssl-dev to some $SUITES -- but libssl-dev is already added to all suites)
[17:25] <kamal> I'll submit those two patches ^^, but will hold off on doing any more cleanup, in case you like it the way it is
[17:29] <rtg> kamal, I'm fine with that. it has accumulated a lot of cruft as we add special cases to it from release to release