=== marlinc_ is now known as marlinc
=== cpaelzer_ is now known as cpaelzer
=== pesari_ is now known as pesari
=== shuduo is now known as shuduo-afk
=== essembe is now known as sbeattie
=== adrian|sick is now known as adrian
=== lilstevie_ is now known as lilstevie
[12:55] <apw> stgraber, more lxc test regression fun for you: LP: #1556931
[12:55] <ubot5> Launchpad bug 1556931 in lxc (Ubuntu) "lxc: adt testing failing across the board on ppc64el" [Undecided,New] https://launchpad.net/bugs/1556931
=== henrix_ is now known as henrix
[14:59] <dsmythies> on my 16.04 test server, and as of maybe a day or two now, I can not compile "perf" (tools/perf). At the   "LINK     perf" step there is an error: "/usr/bin/ld: cannot find -liberty".  I haven't been able to figure out what package or whatever is missing. I successfully compiled perf just 48 hours ago, on March12th, but have done updates and some cleanup in between. Any ideas?
[15:02] <apw> dsmythies, sounds like a lack of build-deps ? libiberty-dev or something ?
[15:06]  * dsmythies goes off to check stuff...
[15:11] <dsmythies> apw: Yes, I agree, but I haven't been able to figure out what exactly is missing. By the way, compiling the kernel (mainline) is working fine. 
[15:11] <apw> dsmythies, well -liberty is "give me library iberty, which is libiberty.so et al
[15:12] <apw> have you checked libiberty-dev was installed ?
[15:19] <dsmythies> apw: It wasn't. And with it, now compiles fine. Thanks. Still do not understand: There is no "/usr/lib/x86_64-linux-gnu/liberty.so"; Why it worked 2 days ago, but not now. Anyway, thanks very much.
=== maxb_ is now known as maxb
[15:27] <apw> libiberty.so
[15:34] <dsmythies> apw: yes, but I didn't know to look for that, my only clue was "/usr/bin/ld: cannot find -liberty" which I thought meant liberty.so. Anyway it was autoremove that didn't realize I needed it and removed the package: "2016-03-13 13:02:21 remove libiberty-dev:amd64 20160215-1 <none>". Conclusion: My mistake (like that is a surprise to anyone reading this).
[15:37] <apw> dsmythies, well your build-deps are defined in debian/control in the package, so you should be building in a chroot with all those deps installed to match what the code is expecting
[15:43] <dsmythies> apw: I never build that way. I only build mainline and only use, for example, "time make -j9 olddefconfig bindeb-pkg LOCALVERSION=-test"
[15:44] <apw> dsmythies, right, so then you get to work out your build-deps using the "extreme pain and guesswork" way
[15:44] <apw> as you are finding, though if it was me, i would install the build-deps for the ubuntu kernel into a chroot, and build my mainline ones in that chroot
[15:49] <dsmythies> apw: I have never had much success with that method. I also seem to get better error reporting with the way I do it (which is similar to: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild ) or so I think (it has been years since I did your method).
=== rw is now known as dax
[16:22] <stgraber> apw: fine to ignore, we don't have ppc64el images on images.linuxcontainers.org right now
[16:23] <apw> stgraber, ack thanks, i'll hint those
=== tyhicks` is now known as tyhicks
[16:36] <jdstrand> jsalisbury: hey, you gave me a new kernel for bug #1547619, but I'm not 100% sure 4.3.0-040300-generic (#201603101009) doesn't have the bug
[16:36] <ubot5> bug 1547619 in linux (Ubuntu Xenial) "Intermittent screen blinking with 4k external mini display port with 4.4 kernels" [Medium,In progress] https://launchpad.net/bugs/1547619
[16:37] <jdstrand> jsalisbury: my comments today were saying that the I needed an ubuntu kernel for overlayfs, so tried the latest xenial when doing that and it had the bug. I am back to testing 4.3.0-040300-generic (#201603101009) now
[16:37] <jdstrand> I suspect it doesn't have the bug, but I'm not sure yet
[17:16] <jsalisbury> jdstrand, ack
[17:17] <jsalisbury> jdstrand, I'll remove that kernel and reset the bisect
[17:22] <cristian_c> jsalisbury: hi
[17:31] <jsalisbury> cristian_c, hello
[17:31] <cristian_c> jsalisbury: I'd like to know if upstream has received the patch
[17:32] <cristian_c> *wether
[17:32] <jsalisbury> cristian_c, not yet, I'll send it today
[17:32] <cristian_c> ok
[17:33] <jdstrand> jsalisbury: sorry for the confusion
[17:40] <jsalisbury> jdstrand, np 
[18:34] <melodie> hi
[18:34] <melodie> to install the 4.4 kernel on a Kubuntu Wily, is that the right place to get the packages and the only one? http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-wily/
[18:35] <apw> those are only debug kernels, they have no ubuntu sauce
[18:35] <melodie> hi apw
[18:35] <melodie> "ubuntu sauce" ?
[18:36] <melodie> which packages do I need and where should I get them from?
[18:36] <melodie> http://linuxdaddy.com/blog/install-kernel-4-4-on-ubuntu/
[18:36] <apw> there are no official packages for wily of 4.4
[18:36] <melodie> what this gui said: would that be ok?
[18:36]  * apw bets that is the guy who tells you to wget foo | sudo bash
[18:36] <melodie> kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.4-wily/  ?
[18:36] <apw> that well known security plan
[18:37] <apw> those are debug kernels, with no ubuntu additional patches, no stable updates, no bug fixes etc
[18:37] <apw> no updates
[18:38] <melodie> I need 4.4.x kernel and headers for someone who buys a machine with the latest Intel Skylake CPU
[18:38] <melodie> he will be aware that it will be a temporary solution 
[18:38] <melodie> already aware...
[18:38] <melodie> and will need to upgrade to Xenial later
[18:39] <melodie> he will also be aware how to unlock the kernel thing and make it the "linux-image" and "linux-image-generic" rules in his package manager
[18:39] <apw> why not just upgrade him to xenial anyhow
[18:39] <apw> anyhow iirc skylake is not stabled with 4.4
[18:39] <melodie> last time I wanted to install Kubuntu Xenial in virtualbox the installer just didn't work there (in Mate, it did though)
[18:40] <apw> i seem to recall we have like a 100 commits on top of 4.4 in xenial just for skylake and broadwell
[18:40] <melodie> ok, so do we stick with the kernel that's in Wily by default?
[18:40] <apw> if it was me i'd upgrade to xenial, warts and all
[18:40] <apw> i mean i run it on all my kit, and its been pretty good
[18:40] <melodie> I can't afford to take the risk
[18:40] <apw> which risk
[18:41] <melodie> Kubuntu?
[18:41] <apw> runnign a kernel with no security is a hell of a risk
[18:41] <melodie> I'm one hour and half far from this man's office 
[18:41] <melodie> and he is just a user
[18:41] <apw> i can probabally find 3-4 root exploits in 4.4
[18:41] <apw> just by reading the changelog
[18:41] <sbeattie> did the 4.4.0-12.28 tag not get pushed to the xenial git tree?
[18:41] <melodie> I believe you, just if he can use the actual kernel that's in Wily, I'm ok with that
[18:42] <melodie> I run Xenial in my own machine (upgraded from former installs) and I have 4.4.0-12-generic #28-Ubuntu
[18:42] <melodie> sbeattie is that the one version you are talking about?
[18:44] <apw> sbeattie, i have it in my tree, have you git fetch --tags origin that repo
[18:44] <apw> sbeattie, as we are rebasing some in some cases you can miss tags if we wen from 11 -> 13 before you fetch
[18:44] <apw> (without --tags)
[18:47] <sbeattie> apw: ah, it's there, just not on master 
[18:47] <apw> right, a little rebase in there somewhere
[18:48] <melodie> I'll be doing the install next thursday. Can I have a 4.3 or a 4.4 that's ok for an end user who has high demands? :) (and has been using Ubuntu boxes only since several years!)
[18:50] <apw> if he has skylake i think he is out of luck for reliablity before xenial, or lts-xenial
[18:51] <sbeattie> melodie: sorry, my question was unrelated to yours, was trying to figure out which commits are in that kernel, and which are in the next one.
[18:51] <apw> sbeattie, yep
[18:51] <melodie> apw the store where they put the computer together tried Kubuntu Wily on it and they said as live it booted fine
[18:51] <melodie> sbeattie yes sure
[18:52] <apw> melodie, then he shouldn't need 4.4
[18:52] <melodie> sbeattie now the users out there, at "askubuntu" and such all seem to agree to use the 4.3 or 4.4 in Wily, while Xenial is being worked on to reach the final
[18:53] <apw> xenial is pretty much stablised now, we're not making huge changes any more, we are past FF and on the home straight
[18:53] <apw> xenial seems pretty stable in the main to me
[18:53] <melodie> apw boot is one thing, then he does image processing with very high resolution (and the machine besides Skylake has a good asus mobo, 8 GB Ram)
[18:53] <melodie> what is FF ?
[18:54] <melodie> is it a beta now?
[18:54] <apw> feature freeze, change gets much harder to apply now that is past
[18:54] <melodie> ok let me grab one :)
[18:54] <apw> we've produced some betas yeah
[18:54] <melodie> apw from my former experiences, LTS used to be stable after the first version of the new edition, for Xenial it would be 16.04.1 ^^
[18:55] <sbeattie> melodie: if kubuntu is needed, I'm unsure what the state of kubuntu/xenial is. you might ask sgclark in #kubuntu-devel, as she's been doing a lot of the packaging work for kubuntu.
[18:55] <melodie> ok, I'll head there right now, thanks for the info
[18:56] <melodie> I'll grab one anyway to give it a whirl
[18:59] <melodie> my iso is feb 8th. can someone remind me what is the zsync command line to update the ISO?
[18:59] <melodie> this is the link to the actual iso: http://cdimage.ubuntu.com/kubuntu/daily-live/current/xenial-desktop-amd64.iso
[19:00] <apw> zsync -o <file> <url.zsync>
[19:00] <melodie> apw thks!
[19:01] <melodie> starting! nice! :D
[19:05] <dsmythies> melodie: There are always example commands ( I use rsync and can never remember) on the daily testing page at : http://iso.qa.ubuntu.com/qatracker/milestones/351/builds/114631/downloads which in turn I got to from http://iso.qa.ubuntu.com/qatracker/milestones/351/builds
[19:06] <stgraber> apw: hey, so looks like powerpc (not 64el) isn't booting with current 4.4 from xenial
[19:06] <stgraber> apw: smoser may have some more details for you, all I know is that I dist-upgraded my ppc VM and it stopped booting, smoser had to reboot me into 3.19 manually
[19:08] <apw> stgraber, which versoin number is that ?
[19:08] <melodie> dsmythies thanks but that would be even worse for me to remember, just now I realised what the structure of the command line is, and as for the -o option, I guess a "zsync --help" will remind it to me next time
[19:08] <stgraber> ii  linux-image-4.4.0-12-powerpc64-smp    4.4.0-12.28                     powerpc      Linux kernel image for version 4.4.0 on 64-bit PowerPC SMP
[19:08] <apw> stgraber, and do you have one which did boot before that, in 4.4 ?
[19:08] <smoser> 3.19 booted
[19:08] <apw> stgraber, i think we need a bug and i'll get jsalisbury to get this bisected
[19:08] <apw> i just realised we don't run adt on power, sigh
[19:08] <stgraber> apw: nope, I upgraded from trusty to xenial so it's the first 4.4 I try
[19:09] <smoser> qemu cmdline that results in "cant find root" looks like this
[19:09] <smoser> qemu-system-ppc64 -name rockne-01 -echr 0x05 -enable-kvm -M pseries -cpu host -smp cores=2,threads=1 -m 8G -net nic,macaddr=52:54:00:00:42:01 -net tap,script=no,downscript=no,ifname=tap4201 -device spapr-vscsi -drive file=/var/lib/libvirt/images/shared/rockne-01/disk1.img -drive file=/var/lib/libvirt/images/shared/rockne-01/eph0.img -drive file=/var/lib/libvirt/images/shared/rockne-01/save.img -nographic -vga none
[19:09] <jsalisbury> apw, I'll watch for the bug to come in
[19:09] <smoser> where disk1.img has the root filesystem on it.
[19:09] <stgraber> apw: the issue is storage related, smoser got dropped into a shell with no block listed in /proc/partitions
[19:09] <smoser> only ram disks.
[19:10] <apw> stgraber, we may have lost a storage driver from the initrd, this is all new initramfs-tool
[19:10] <apw> s
[19:10] <apw> jsalisbury, this might also not be the kernel, this might be initrafs-tools
[19:10] <jsalisbury> apw, ack
[19:11] <apw> i wonder if its possible to downgrade initramfs-tools on there to wily and see if that boots
[19:11] <apw> stgraber, ^
[19:11] <apw> to eliminate that
[19:12] <stgraber> there doesn't appear to be any storage related module loaded on the 3.19, so I'm assuming it was all built-in then
[19:12] <stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1557130
[19:12] <ubot5> Launchpad bug 1557130 in linux (Ubuntu) "Current 4.4 kernel won't boot on powerpc" [Critical,Triaged]
[19:12] <apw> ok so going back won't help
[19:12] <stgraber> pseries_rng             3547  0
[19:12] <stgraber> rtc_generic             2711  0
[19:12] <stgraber> autofs4                53194  2
[19:12] <stgraber> ibmveth                29947  0
[19:12] <apw> stgraber, does that have a dmesg, i might be able to tell from that
[19:13] <stgraber> that's all I've got loaded on 3.19, none of them sound storage related
[19:13] <stgraber> apw: it doesn't as I don't have access to that, smoser may be able to get it if I reboot back into the busted kernel
[19:13] <apw> stgraber, a dmesg from the good kernel is what i want
[19:13] <stgraber> ah
[19:13] <apw> so i can see waht driver has the device
[19:13] <stgraber> that I can give you
[19:15] <stgraber> apw: http://paste.ubuntu.com/15386280/
[19:15] <smoser> well, 
[19:15] <smoser>  http://bazaar.launchpad.net/~smoser/+junk/powerkvm-install/view/head:/README
[19:16] <smoser> i did:
[19:16] <smoser>  http://cdimage.ubuntu.com/ubuntu-server/daily/current/xenial-server-powerpc.iso
[19:16] <infinity> apw: The first port of call here would be diffing configs from ppc64-smp and generic/ppc64el, since they're meant to be identical minus endian flip and some Mac drivers.
[19:16] <smoser>  ./ubuntu-boot-iso ./ubuntu-14.04.3-server-powerpc.iso sda.img --stuff-preseed=ubuntu.preseed
[19:16] <apw> infinity, and indeed as far as i know they are
[19:16] <smoser> which works to isntall trusty
[19:16] <smoser> and that fails loading usb drivers with xenial iso
[19:16] <infinity> apw: Lemme tear apart the debs and look.
[19:17] <stgraber> apw: so ibmvscsi it looks like
[19:17] <apw> infinity, i'll look see if this dmesg tells me the driver name
[19:17] <smoser> running ^ shows:
[19:17] <smoser>  Error while running 'modprobe -v usb-storage'
[19:17] <stgraber> oh, could it be as simple as me missing the -extra package?
[19:17] <apw> smoser, well its now a module
[19:18] <apw> if you have no extras, you are likely in a hole
[19:18] <stgraber> I just did a package diff between the ppc64el and powerpc box and they don't have the same set of kernel packages installed...
[19:18] <apw> as you have no hardware drivers
[19:18] <infinity> stgraber: There is no extra for ppc64-smp
[19:18] <infinity> It's not split.
[19:18] <stgraber> infinity: ah
[19:18] <apw> oh, heh, except that
[19:18]  * apw checks this is in the initrd, might not be
[19:18] <apw> and it was builtin in W so you'd be fine
[19:18] <infinity> It would also be a bug if the virt drivers were in extra, of course. ;)
[19:19] <apw> heh yeah
[19:19] <smoser> well, it seems to me that powerpc at least under qemu and '-device spapr-vscsi' -cdrom needs some love)
[19:19] <apw> but a _differnet_ one
[19:19] <apw> ok this is most likelyu an initramfs-tools issue
[19:19] <smoser> after a while, it fails saying:  Detect and mount CD-ROM ... could not be mounted
[19:19] <stgraber> root@1ss-powerpc:~# lsinitramfs /boot/initrd.img-4.4.0-12-powerpc64-smp | grep ibmvscsi
[19:19] <stgraber> lib/modules/4.4.0-12-powerpc64-smp/kernel/drivers/scsi/ibmvscsi
[19:19] <apw> as this moved =y -> =m
[19:19] <stgraber> lib/modules/4.4.0-12-powerpc64-smp/kernel/drivers/scsi/ibmvscsi/ibmvfc.ko
[19:19] <stgraber> lib/modules/4.4.0-12-powerpc64-smp/kernel/drivers/scsi/ibmvscsi/ibmvscsi.ko
[19:19] <stgraber> so the module is in the initrd apparently
[19:19] <apw> oh hrm
[19:20] <apw> that is less expected
[19:20] <smoser> and yeah, no disk device there either
[19:20] <smoser> so seems iso shows same failure that stgraber is hitting.
[19:21] <apw> smoser, if you boot that to the initramfs prompt, does ibmvscsi appear in lsmod, and if not does modprobe ibmvscsi make the disks appear
[19:21] <apw> maybe we have a missing device alias
[19:21] <smoser> i just killed it. but i tried modprobing it and not there. 
[19:21] <smoser> i can get it back to the iso failure quick enough
[19:21] <apw> ack
[19:23] <smoser> apw, exactly zero modules loaded in the initramfs
[19:23] <smoser> er... in the installer environment
[19:24] <apw> and if you attempt to load them by hand ?
[19:24] <smoser> ~ # modprobe ibmvscsi
[19:24] <smoser> modprobe: ERROR: could not insert 'ibmvscsi': Unknown symbol in module, or unknown parameter (see dmesg)
[19:24] <apw> wtf
[19:24] <smoser> dmesg | tail -n 4
[19:24] <smoser> [   12.006176] ibmvscsi: Unknown symbol mcount (err 0)
[19:24] <smoser> [   12.016503] ibmvscsi: Unknown symbol mcount (err 0)
[19:24] <smoser> [   13.070630] usb_storage: Unknown symbol mcount (err 0)
[19:24] <smoser> [  125.209403] ibmvscsi: Unknown symbol mcount (err 0)
[19:24] <smoser> so it did try to load it.
[19:24] <stgraber> so missing dependency it looks like
[19:24] <apw> i thought the kernel rewrite the mcount bits 
[19:24] <smoser> also 
[19:24] <smoser> [    0.839630] ibmvscsi: module verification failed: signature and/or required key missing - tainting kernel
[19:25] <apw> ?
[19:25] <infinity> Oh!
[19:26] <infinity> That's a bug I knew about already but hadn't had time to look at.
[19:26] <infinity> Silly me for not having 48 hour days.
[19:26] <apw> infinity, happenign in all ppc kernels, or just this one
[19:27] <apw> smoser, can you get an entire dmesg off there somehow ?
[19:27] <infinity> apw: Hard to say, this is the one most people exercise.
[19:27] <smoser> http://paste.ubuntu.com/15386345/
[19:27] <infinity> apw: But for weird reasons, only happening on big-endian.
[19:27] <infinity> apw: Maybe due to the CPU support being different between powerpc and ppc64el, leading to different optimised routines and submodules.  Hadn't had a chance to look.
[19:27] <smoser> you want anything else there?
[19:28] <apw> i am sure mcount is -g stuff, and i have this feeling the kernel uses that and rewrites it for ftrace, or something vile
[19:28] <apw> so i am not expecting to see mcount in there
[19:29] <infinity> apw: I'll get a VM booted into that kernel with some violence so we can examine it a bit better.
[19:29] <apw> infinity, oh not it is called mcount, we do use that we just supply an mcount which does ftrace and not counting
[19:29] <apw> so perhaps ftrace is busted on there
[19:30] <smoser> you can probably boot it in qemu-system-ppc64 on intel
[19:30] <smoser> in lightning fast speed. https://gist.github.com/smoser/7a07d9f8929dc11b4ed9
[19:36] <smoser> oh well, attempt at that failed
[19:36] <infinity> apw: Huh.
[19:36] <apw> infinity, i might have found it
[19:37] <infinity> apw: So, I happened to have a very old xenial ISO.
[19:37] <apw> infinity, go ahead
[19:37] <infinity> apw: And this broke between 4.2.0-16.19 and 4.2.0-17.21
[19:37] <infinity> Which is curious.
[19:37] <infinity> Since nothing changed there...
[19:38] <infinity> Maybe that's a red herring, and it's actually how the initrd was built that broke.
[19:38] <apw> there is a fix after 4.4, which could account for this 
[19:38] <infinity> apw: Yeah, but that doesn't account for why wily.iso works and xenial.iso with almost the same kernel doesn't. :P
[19:39] <apw> oh no we have it in via stable
[19:39] <apw> yes, it would if the compiler changes, what gcc are we using in x
[19:39] <infinity> It must be a userspace thing...
[19:39] <infinity> Not a compiler issue.
[19:39] <infinity> This kernel was built in wily.
[19:39] <infinity> With the same toolchain as the working one.
[19:39] <infinity> https://launchpad.net/ubuntu/+source/linux/4.2.0-17.21
[19:39] <infinity> That's the delta between working and not.
[19:40] <infinity> So I don't think it's the kernel's fault.
[19:40] <apw> infinity, ok ... not that then
[19:40] <infinity> I need to tear apart these initrds.
[19:40] <melodie> hi infinity o/
[19:40] <apw> infinity, kmod ?
[19:40] <apw> no you say in wily, hrm
[19:40] <infinity> apw: The kernels were both built in wily.  The userspace for the second is xenial.
[19:41] <infinity> apw: Which is, I'm sure, the key.
[19:41] <apw> well what else does one use other than kmod to load a kernel
[19:41] <apw> module, and fial in this case
[19:42] <apw> i guess any depedency libraries
[19:42] <infinity> 20151021 -> 20151203
[19:43] <infinity> That's our date range for breakage.
[19:43] <infinity> Based on the two ISOs I have here.
[19:43] <apw> infinity, and kmod is almost the same
[19:43] <apw> last year, so before kmod
[19:43] <apw> but, we use very little in userspace in initramfs
[19:44] <infinity> apw: No difference in file lists in the two initrds.
[19:45] <apw> phththt
[19:45] <apw> infinity, and you have the same mcount oddness
[19:46] <apw> infinity, and this regression is in the wild on wily, argle
[19:46] <infinity> apw: I don't think it is.
[19:46] <infinity> apw: I think it requires xenial userspace to be fucked.
[19:46] <apw> oh i see, but
[19:46] <infinity> apw: But I could install wily and upgrade to be sure.
[19:47] <apw> i don't thnk that isnecessar
[19:47] <apw> y
[19:47] <apw> as we are clear the same kernel is broke with xenial
[19:47] <apw> so what is in the initrd that is not busy box
[19:48] <apw> to load a module we just map it and offer it to the kernel
[19:50] <infinity> Hahaha.
[19:50] <infinity> I thought I was going to be clever by using virtio to work around the issue so I could get installed.
[19:50] <infinity> [   16.884617] isofs: Unknown symbol mcount (err 0)
[19:50] <infinity> So, no ISO for me.
[19:50] <infinity> Time for netboot.
[19:52] <apw> infinity, can you install any modules at all, or are tey all broken
[19:53] <infinity> apw: Some work.
[19:53] <infinity> apw: Switching to virtio for both nic and scsi is getting me tooling along, luckily.
[19:54] <infinity> Oh Em Gee, d-i has a "show password" toggle now!
[19:56] <infinity> apw: Install grinding along decently now.  Will revisit in a bit and we can investigate on a live system with the issue.  Might make more sense there than trying to unwind the code blind.
[19:57] <apw> infinity, indeed
[19:59] <infinity> Man, I've been spoiled by live-installer on the server ISOs.  A full netinst is much slower.
[19:59] <infinity> Reminds me that I wanted to publish those base images and use live-installer for netinst too.
[19:59] <infinity> Probably too late to wedge that into xenial. :/
[19:59] <apw> infinity, when quilt 3.0 applied patches it is meant to barf if they have any fuzz right ?
[19:59] <infinity> apw: Fuzz, yes, offsets no.
[20:00] <infinity> (Thankfully)
[20:00] <apw> ahh ok, then that makes more sense
[20:00] <infinity> You can feed it some extra options to make it reject on offset mismatches too, if you're paranoid about code blocks migrating.
[20:01] <apw> infinity, i am getting an odd behaviour on debdiff where the diff is not including the applied patches, which ... it should
[20:02] <melodie> infinity seeing you makes me think, I'd like to ask if you remember having considered adding a conf file for zram-config in the next LTS?
[20:02] <apw> and yet when you unpack it it is applied ok
[20:02] <infinity> apw: The debdiff shouldn't show patches applied.
[20:02] <apw> thats stupid
[20:03] <melodie> infinity one allowing to setup / choose the size of blocks and the number?
[20:03] <infinity> You say stupid, I say working as intended. :P
[20:03] <infinity> melodie: It would be lovely to do, but I can't commit any time right now.  Maybe after Beta2.
[20:03] <infinity> melodie: My life is remarkably hectic right now.
[20:04] <melodie> infinity I just wanted to remind you about it, to be sure you didn't forget our discussion a few months ago and for you to try to stick it to some kanban somewhere. :)
[20:05] <melodie> the users of zram-config would all really appreciate, especially the long time users :)
[20:05] <infinity> apw: If debdiff showed patches applied, you'd get the diff twice, essentially.
[20:06] <apw> i guess, hrm
[20:06] <apw> still makes my head hurt :)
[20:08] <infinity> apw: Alright, on a full system, it still can't probe it.  So it's not just a missing dep in the initrd.
[20:08] <apw> infinity, no can't be that i can see
[20:09] <apw> if you are running modprobe foo, and it fails there are not a whole heap of things involved
[20:09] <apw> kmod and the kernel, and a teensy bit of libc
[20:09] <apw> infinity, and that is the same kernel that works in wily
[20:10] <apw> and indeed libc is its only library
[20:11] <infinity> Well, not the same kernel now, I installed with 4.4.0-12
[20:11] <infinity> But I can downgrade to wily's for a proper comparison.
[20:13]  * infinity gets all sciency.
[20:16] <apw> heh
[20:18] <infinity> ARGH.
[20:18] <infinity> WHAT.  THE...
[20:18] <infinity> apw: 4.2.0-16.19 (wily's ship kernel) works fine.
[20:18] <infinity> On xenial userspace.
[20:19]  * infinity tries -17 again to see if he's insane.
[20:20] <infinity> apw: is toolchain stuff in the .deb somewhere, or do I have to scrub build logs?
[20:21] <apw> if it does, work forward to find the last one
[20:21] <apw> build logs i would think
[20:21] <apw> we should record that, oh we must record the compiler in /boot somewhere
[20:21] <apw> not anything else though
[20:21] <apw> infinity, ^
[20:22] <apw> infinity, oh no, we grep it out of the kernel
[20:22] <rtg> apw, don't we record it in the .deb ?
[20:23] <apw> infinity, rtg, we record it in every .ko, which is how i check it apparently
[20:23] <apw> readelf -p .comment "$ko"
[20:24] <infinity> Okay, now I'm going to lose my mind slightly.
[20:24] <infinity> 4.2.0-17-powerpc64-smp, which failed on an old xenial server ISO, works fine on my installed system.
[20:25] <apw> well that is more believeable, can you hop skip and jump forward
[20:25] <apw> looking for the first bad
[20:26] <apw> as you've just eliminated userspace i assume
[20:26] <infinity> apw: It's more believable, but why did that ISO show the problem?  It's asking more questions than it answers. :P
[20:26] <apw> shhhh it'll hear you and change
[20:26]  * infinity goes to find an early 4.3.0
[20:28]  * apw puts a small bet on 4.4.0-3.17 as the first bad
[20:28] <infinity> apw: Any particular reason?
[20:28] <infinity> apw: Is that where the commit you thought was the "fix" was introduced?
[20:28] <apw> there is only one fix to the module scraper, fixnign a gcc-6 thing in the tree
[20:28] <apw> and i want it to be that
[20:29] <infinity> apw: Was that pulled into 4.2.0 stables too?
[20:29] <apw> it looks benign but ... maybe its not
[20:29] <infinity> (I have no access to the librarian here, it's much easier if I can pull from the archive. :P)
[20:29] <apw> infinity, looks like it was
[20:29] <infinity> apw: Tags?
[20:30] <apw> Ubuntu-4.2.0-28.33 was the first one with in 4.2
[20:30] <apw> Ubuntu-4.4.0-3.17 in 4.4
[20:30] <apw> dunno if that is it of course, but it is a worry
[20:31] <apw> though if you can test one of those version brackets i guess it might eliminate easily
[20:32] <apw> Ubuntu-4.2.0-27.32 is prev on 4.2 and Ubuntu-4.4.0-2.16 on 4.4 if that helps any
[20:33] <infinity> 28 and 29 don't exist, grabbing 30.
[20:33] <infinity> Must have been respin hell.
[20:33] <apw> oh yeah, probabally, we did a lot back there
[20:34] <apw> oh we don't reap nbs in -updates, handy for you here
[20:34] <infinity> Quite.
[20:35] <infinity> Booting 27.
[20:37] <infinity> That seems fine.
[20:38] <apw> these are the "first sane" looking 4.3 and 4.4s Ubuntu-4.3.0-1.10 Ubuntu-4.4.0-1.15
[20:38] <infinity> -30 is also fine.
[20:38] <apw> ok so not that then, pup
[20:38] <apw> your search continues then
[20:39] <apw> of course you will get to -12 and it will work
[20:39] <apw> such is the nature of the world
[20:39] <infinity> Yeah, I'm worried about that myself.
[20:43] <infinity> apw: Well, at least 4.4.0-12 still fails.  So, I'm not completely insane.
[20:44] <infinity> I'm going to have to mirror a bunch of kernels and scp them up to test more interim ones.
[20:44] <apw> ack
[21:08]  * apw wonders how it is going
[21:26] <Beret> man
[21:27] <Beret> unplugging a usb key from my xenial machine just hard locked it
[22:20] <nusch> how to get broadcomm wireless driver (bcmwl-kernel-source) working with mainline(4.5) kernel to test for some bug?
[22:21] <apw> nusch, i doubt that anyone has made one yet
=== hughhalf_ is now known as hughhalf
[23:31] <nusch> @apw would would you then suggest to debug this https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1545320 ? I need wireless to reproduce this bug. Use 4.4? Or somehow backport only relevant functionality of i915 ?
[23:31] <ubot5> Launchpad bug 1545320 in xserver-xorg-video-intel (Ubuntu) "Dell XPS13 with i915 hangs with only mouse cursor and SSH working" [Medium,Incomplete]
[23:34] <apw> nusch: i am not sure why you need wifi for a graphics bug, could you use an ethernet or wifi usb dongle