=== gerald is now known as Guest78324
[06:07] <sbeattie> bjf: Hi. I just looked at the apparmor failure log in http://kernel.ubuntu.com/testing/onibi__3.13.0-53.88__2015-05-18_17-33-00/console_output.txt.html ; it looks like it pulled in the apparmor packages in trusty-proposed, which means you shouldn't see the apparmor apport hook failure anymore (yay!), but it it looks like the trusty-proposed deb-src line wasn't enabled in apt's sources.list.
[06:09] <sbeattie> bjf: that may be the cause of the different failures seen this time, as part of the apparmor qrt test script downloads the source package and runs make check in it.
[06:11] <bjf> sbeattie, ack, i'll look at it tomorrow. thanks
[06:14] <sbeattie> bjf: no worries, thanks.
[06:22] <sbeattie> ah, yep, I've reproduced the the failures with the sources from apparmor 2.8.95~2430-0ubuntu5.1 while binary packages from 2.8.95~2430-0ubuntu5.2 are installed.
[06:41] <FourDollars> sforshee: Hi, did you remember the patch you made for Dell New XPS 13? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/hid-multitouch.c?id=2c6e0277e1eab3df5db81c59e408b7b1c14b1b72
[06:41] <FourDollars> sforshee: Does it fix any problem?
=== gerald is now known as Guest33142
[09:16] <pkern> The new 3.13 contains "tcp: make connect() mem charging friendly" but doesn't seem to contain "tcp: Fix crash in TCP Fast Open", is that intentional?
[09:17] <pkern> I didn't check if it crashes in the same way as 3.16 did, but it's somewhat concerning that the fixup wasn't picked up if it's needed. |:
[09:21] <pkern> Yeah, it's dead on arrival for us.
[09:22] <apw> pkern, new 3.13 stable or new 3.13 in -updates in trusty ?
[09:22] <pkern> 3.13 in -updates in trusty.
[09:22] <apw> henrix, ^
[09:22] <pkern> Of course it relies on things to use fast open. Which probably just Google does? I don't know.
[09:23] <apw> yes, you are likely the only people in the world advertising that feature sadly
[09:23] <pkern> And using it in clients, I guess.
[09:23]  * henrix goes have a look
[09:24] <apw> that patch shows applied across the board (as it was a cve) but it was behind the other releases in trusty
[09:24] <apw> but i had assumed that meant the introducing commit was also not released either ... hmmm
[09:25] <henrix> ugh
[09:25] <henrix> yeah, that's correct
[09:28] <henrix> pkern: thanks for spotting that!  i'll go work on fixing that ;)
[09:28] <infinity> henrix: Hrm.  Should we do a single-commit respin to pick that up?
[09:28] <pkern> henrix: ta!
[09:29] <infinity> According to Ben's commit message, it should only affect 3.13 and 3.16.
[09:29] <infinity> And it was fixed in 3.16 already, so just 3.13.
[09:30] <apw> yeah somehow we paired it up in 3.16 and not in 3.13
[09:30] <henrix> infinity: yeah, i believe a quick respin will be needed.  i go finish the V respin and start with fixing T
[09:30] <infinity> henrix: +1 from me for a single-commit resping of T and lts-T.
[09:30] <infinity> respin, too.
[09:30] <infinity> Typing hard.
[09:31] <infinity> pkern: Since you seem to be a pro at reproduction, can I get you to test henrix's kernel when he does the deed, so we can turn it around ASAP?
[09:32] <pkern> infinity: Sure.
[09:36] <genkgo> infinity: last week you helped me out with getting cloud tools for kernel 3.19. we switched to this kernel for our problems with creating vss snapshots on our hyperv machine.
[09:37] <genkgo> infinity: unfortunately, it did not solve the issue. our vps goes read-only sometimes while creating these vss snapshots. now we have switched to a new kernel, the error is different than before.
[09:37] <infinity> genkgo: You want apw, not me.
[09:37] <genkgo> blk_update_request i/o error, dev sa, sector xxx
[09:37] <infinity> genkgo: I was just helping with the packaging mysteries, not the hyperv madness.
[09:37] <genkgo> infinity: ok :)
[09:38] <genkgo> apw: i still have some hyperv madness :)
[09:38] <apw> genkgo, ok add that info to the bug, and the new dmesg, and remind me of the bug number, and i'll see if we can get someone to reproduce it
[09:39] <pkern> henrix: Just drop me a mail at $nick@google.com if you have something to test for me. I take it that a respin would likely be released earlier than next Sunday? :)
[09:40] <henrix> pkern: yeah, for sure before Sunday :)
[09:40] <henrix> pkern: i hope to have it uploaded and building later today, i'll email you once we have a test kernel
[09:41] <pkern> henrix: Thank you :)
[09:41] <genkgo> apw: i did not report a bug before, because we thought it was related to the kernel version. if i run "ubuntu-bug linux" i get "This is not an official Ubuntu package. Please remove any third party package and try again." (*** Problem in linux-image-3.19.0-17-generic)
[09:43] <infinity> pkern: If all goes well, I'd expect to release it in < 24h.
=== dupondje_ is now known as dupondje
[10:23] <genkgo> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
[10:23] <ubot5> Launchpad bug 1456985 in linux (Ubuntu) "Filesystem goes read-only while creating VSS snapshot on HyperV" [Undecided,New]
[10:34] <genkgo> apw: While browsing through other bugs related to Hyper-V in the Ubuntu kernel, I found this one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1445195. These patches will solve my problem. The reported problem here https://social.technet.microsoft.com/Forums/windowsserver/en-US/8807f61c-565e-45bc-abc4-af09abf59de2/ubuntu-14042-lts-generation-2-scsi-errors-on-vss-based-backups is an exact copy of the problem we are having.
[10:34] <ubot5> Launchpad bug 1445195 in linux (Ubuntu Wily) "[Hyper-V] Kernel patches for storvsc" [High,Triaged]
[10:52] <infinity> genkgo: Ahh, lovely, thanks.
[10:53] <infinity> apw: Bonus points if you can get those on to all the master-nexts before the next SRU cycle happens. :)
[10:54] <genkgo> infinity: for me this also great news. i had the feeling i was on my own with this problem. now fortunately i see there are many others that have the problem. and there is already a patch it.
[10:54] <infinity> genkgo: Always nice to see that it's ultimately not our fault, too. :P
[10:55] <genkgo> hehe, i totally understand that!
[11:19] <apw> sigh, i believe we are waiting on some testing for those from microsoft, will chace that up
[11:30] <genkgo> apw: if there is any testing we can do: please let me know. i'd love to help.
[11:31] <apw> genkgo, yep, will make sure you get some test kerenls
[11:31] <genkgo> apw: wonderful, thanks for the good work
[12:08] <jsalisbury> genkgo, Should have test kernels for each release in about 15 to 20 minutes
[12:08] <genkgo> jsalisbury: wonderful!
[12:09] <genkgo> jsalisbury: should build a kernel myself then or is it apt-get install? i am not extremely familiar with building a kernel.. :)
[12:10] <jsalisbury> genkgo, I'll have the kernels as a .deb file, then you can dpkg -i them
[12:10] <genkgo> jsalisbury: aight, that would be no problem :)
[12:11] <jsalisbury> genkgo, there is already a vivid kernel here: http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/  Building the other releases now
[12:12] <genkgo> jsalisbury: we are on trusty with vivid kernel, so i can use those already
[12:13] <genkgo> jsalisbury: i am still working on something else now, but will make sure to install today. last time it took 36 hours before we had a machine crashed on backup, and then we were creating backups every hour.
[12:13] <jsalisbury> genkgo, great.  You just need to install the linux-image and linux-image-extra .deb packages.
[12:14] <jsalisbury> genkgo, ok, thanks
[12:14] <genkgo> jsalisbury: great, thanks for the work
[12:14] <jsalisbury> genkgo, np
[12:15] <jsalisbury> genkgo, thanks for offering to test!
[12:18] <genkgo> jsalisbury: sure, we would like to get rid of the problem asap. i am going to run the tests on a production machine. on machines with not enough activity (test machine) we were not able to reproduce the bug. or we did not wait long enough (4 days, backup every hour).
[12:36] <sforshee> FourDollars: that patch gets INPUT_PROP_BUTTONPAD set for the xps 13 touchpad in i2c mode, though 015fdaa9f8edd89a456b3331088e1b77ebdad9d0 does as well
[12:45] <genkgo> jsalisbury: could you say which patches are applied to that build?
[12:47] <jsalisbury> genkgo, yes, they are the following:
[12:47] <jsalisbury> scsi: storvsc: Increase the ring buffer size
[12:47] <jsalisbury>   scsi: storvsc: Size the queue depth based on the ringbuffer size
[12:47] <jsalisbury>   scsi: storvsc: Always send on the selected outgoing channel
[12:47] <jsalisbury>   scsi: storvsc: Retrieve information about the capability of the target
[12:47] <jsalisbury>   scsi: storvsc: Fix a bug in copy_from_bounce_buffer()
[12:47] <jsalisbury>   scsi: storvsc: Don't assume that the scatterlist is not chained
[12:47] <jsalisbury>   scsi: storvsc: Set the tablesize based on the information given by the 
[12:47] <genkgo> jsalisbury: thanks, how about this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1454758?
[12:47] <ubot5> Launchpad bug 1454758 in linux (Ubuntu Wily) "[Hyper-V] storvsc: Set the SRB flags correctly when no data transfer is needed" [Critical,Triaged]
[12:50] <jsalisbury> genkgo, that particular commit is not in that test kernel.  It was cc'd to upstream stable and should come down through the normal stable process. 
[12:51] <jsalisbury> genkgo, I can build a test kernel the that commit and the previous 7 I posted
[12:52] <genkgo> jsalisbury: i am not able to qualify whether the particular bug we are having (backups with hyperv) is related to that one, or to the storvsc onw. can you?
[12:53] <jsalisbury> genkgo, I don't believe it is related to eh backups bug, which is why it was requested in a seperate bug report
[12:54] <genkgo> jsalisbury: just to be sure: the build you created fixes a.o. the backup bug, right?
[12:54] <jsalisbury> genkgo, correct
[12:54] <genkgo> jsalisbury: lovely :)
[12:55] <jsalisbury> genkgo, I'll be building Utopic and Trusty test kernels as well, the commits are requiring a little backporting, so taking a little longer than expected.
[12:56] <genkgo> jsalisbury: ok, but i need the one you already have builded, so that is no problem
[12:56] <jsalisbury> genkgo, cool
[12:56] <genkgo> jsalisbury: at least, i do not see a reason why i should go back to 3.13 kernel
[13:08] <FourDollars> sforshee: So what's the difference between yours and the original one? I mean if there is no your commit, what's going to happen?
[13:11] <sforshee> FourDollars: basically they arrived on the list at about the same time, and they went ahead and took both. For the xps 13 the results are identical; possibly for some other touchpads one or the other might not work.
[13:13] <FourDollars> sforshee: I see
[13:13] <FourDollars> sforshee: Thanks for your explanation.
[13:13] <sforshee> FourDollars: obviously I like my approach better ;-)
[13:13] <FourDollars> sforshee: haha
[16:38] <genkgo> jsalisbury: i am having dependency problems
[16:39] <jsalisbury> genkgo, I now have test kernels for Trusty and Utopic if your willing to test?  All the test kernels are available from: http://kernel.ubuntu.com/~jsalisbury/lp1445195/
[16:39] <jsalisbury> genkgo, Can you post any errors you are seeing
[16:40] <genkgo> jsalisbury: http://paste.ubuntu.com/11247594/
[16:40] <genkgo> jsalisbury: while runing sudo dpkg -i *.deb
[16:41] <jsalisbury> genkgo, try only installing one package at a time.  First the linux-image package then the linux-image-extra package
[16:42] <genkgo> jsalisbury: no difference
[16:43] <genkgo> jsalisbury: could it be the same dependency errors that i was having before?
[16:43] <genkgo> apw: could this be the same dependency problem?
[16:44] <genkgo> jsalisbury: there is only a problem with tools and cloud tools
[16:44] <genkgo> image headers and extra are doing fine
[16:45] <jsalisbury> genkgo, you won't need linux-tools or linux-cloud for this testing, only linux-image and linux-image-extra
[16:45] <jsalisbury> genkgo, So these two .debs:
[16:45] <jsalisbury> linux-image-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
[16:46] <apw> jsalisbury, yes if you are installing a "standard" kernel, not lts-foo, then you need to switch to the default linux-tools-common things
[16:46] <jsalisbury> 	linux-image-extra-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb	
[16:46] <genkgo> jsalisbury: those are installed
[16:47] <jsalisbury> apw, is linux-tools needed for testing these hyper-v commits?  I didn't think so
[16:48] <genkgo> jsalisbury: microsoft is saying they are required
[16:49] <genkgo> jsalisbury: they are required, in which sense (backuping or otherwise) is unknown
[16:51] <genkgo> jsalisbury: http://paste.ubuntu.com/11247689/
[16:52] <genkgo> jsalisbury: so i still have the linux-lts-vivid-cloud-tools-common package
[16:53] <jsalisbury> genkgo, Hmm, I wonder if we need to remove that first.  Is this on a non-production system, so we can remove it first.  Then run:
[16:53] <jsalisbury> sudo apt-get install -f
[16:53] <jsalisbury> sudo apt-get clean
[16:53] <jsalisbury> sudo dpkg -i linux-tools-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
[16:55] <genkgo> jsalisbury: this is production :)
[16:56] <genkgo> jsalisbury: not working, same error: linux-tools-3.19.0-17-generic depends on linux-tools-3.19.0-17; however: linux-tools-3.19.0-17-generic depends on linux-tools-3.19.0-17; however:
[16:59] <jsalisbury> genkgo, let me see if I can install it locally
[17:00] <apw> i think you need to remove the lts-foo versions of the common tools packages, which in fixed packages wont exist
[17:00] <apw> and then you ought to get the appropriate ones installed instead, the ones that got removed last time when installing lts-vivid
[17:00] <jsalisbury> genkgo, so remove this one:  linux-lts-vivid-cloud-tools-common 
[17:01] <genkgo> jsalisbury: already did
[17:01] <genkgo> no differece
[17:02] <jsalisbury> genkgo, can you run the dpkg -l command again, to see what else is there
[17:04] <genkgo> jsalisbury: 
[17:04] <genkgo> jsalisbury: http://paste.ubuntu.com/11247908/
[17:06] <jsalisbury> genkgo, can you purge all of the linux-tools pacakges then reinstall just linux-tools-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
[17:06] <jsalisbury> sudo dpkg --purge PACKAGENAME
[17:07] <genkgo> jsalisbury: sorry, but same issue
[17:08] <genkgo> http://paste.ubuntu.com/11247941/
[17:08] <genkgo> you can see, all purged, won't install
[17:08] <genkgo> hmm
[17:08] <jsalisbury> genkgo, It looks like it did install, see line 586
[17:08] <jsalisbury> iU  linux-tools-3.19.0-17-generic       3.19.0-17.17~lp1445195              amd64        Linux kernel version specific tools for version 3.19.0-17
[17:09] <genkgo> no, it got errors while installing
[17:10] <jsalisbury> genkgo, same dependency error:
[17:10] <jsalisbury> ?
[17:11] <jsalisbury> genkgo, hmm, I wound if it's because I added ~lp1445195 onto the package name.  It doesn't cause issues with the kernel, but maybe the tools package doesn't like it
[17:11] <jsalisbury> genkgo, let me build one more kernel without that extra text
[17:15] <genkgo> jsalisbury: ok, i will wait for that, my system is pretty clean now: http://paste.ubuntu.com/11248013/.
[17:16] <jsalisbury> genkgo, ok, building now, it should only take 15minutes or so
[17:36] <genkgo> jsalisbury: i just got a reply from microsoft on my bug report
[17:36] <genkgo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
[17:36] <ubot5> Launchpad bug 1445195 in linux (Ubuntu Wily) "duplicate for #1456985 [Hyper-V] Kernel patches for storvsc" [High,Triaged]
[17:37] <genkgo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
[17:37] <genkgo> jsalisbury: he is telling we also need https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1454758, which is not included in your build
[17:37] <ubot5> Launchpad bug 1454758 in linux (Ubuntu Wily) "[Hyper-V] storvsc: Set the SRB flags correctly when no data transfer is needed" [Critical,Triaged]
[17:38] <jsalisbury> genkgo, Ok, I'll add it to my next build.  
[17:38] <genkgo> jsalisbury: ok, thanks a lot
[17:39] <genkgo> i will wait for that before testing, thanks for the stuff you have already done
[17:41] <jsalisbury> genkgo, np
[18:30] <jsalisbury> genkgo, I have an updated kernel available at: http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
[18:54] <infinity> pkern: The trusty kernel with that fix should be hitting -proposed on mirrors over the next 15-30 minutes (it just hit disk on ftpmaster).
[20:14] <genkgo-> jsalisbury: still have dependency problems: Package linux-cloud-tools-3.19.0-18 is not installed.
[20:15] <genkgo-> Same for the tools package
[20:18] <jsalisbury> genkgo, I'll have to investigate further.  We may be able to just use the --ignore-depends with dpkg since this is only a test kernel.
[20:18] <genkgo-> apw: can this be related to dependency problems we had before?
[20:19] <infinity> No, it's not related to the previous issue, it's that jsalisbury builds his test kernels a bit differently from how they're built in the archive, I'd guess.
[20:19] <infinity> Oh, and it's a vivid kernel, not an lts-vivid kernel, which changes things somewhat.
[20:21] <infinity> Hrm.  That tools package is indeed useless. :P
[20:22] <infinity> Just a bunch of symlinks into the missing package that you don't have built.
[20:24] <jsalisbury> genkgo, we might get away without installing tools just to test this bug, but I'll test locally to see if I can get it to install.
[20:25] <infinity> jsalisbury: AFAIK, he needs the tools for the backup thingee to work.
[20:25] <infinity> jsalisbury: And your build didn't produce all the right packages.
[20:25] <genkgo-> infinity: that is what i believe too
[20:25] <infinity> jsalisbury: Did you just do a binary-generic build instead of a full build?
[20:26] <genkgo-> i dont know how ignore depends works
[20:26] <infinity> genkgo-: Don't bother, ignoring deps will just leave you a bunch of dangling symlinks.
[20:26] <jsalisbury> infinity, I used this:
[20:26] <infinity> No actual binaries.
[20:26] <jsalisbury> fakeroot debian/rules clean && fakeroot debian/rules binary-headers && fakeroot debian/rules binary-generic
[20:26] <jsalisbury> so thats probably it
[20:26] <infinity> jsalisbury: Yeah.  Do a full build instead.
[20:26] <infinity> jsalisbury: THen you'll get the common packages, etc.
[20:27] <jsalisbury> infinity, ack, thanks.  First time someone needed the tools package from me :-)
[20:29] <jsalisbury> infinity, do you happen to know the option for a full build off hand?  If not, I'll dig it up
[20:30] <apw> jsalisbury, to make the tools you need binary-tools as well
[20:31] <jsalisbury> apw, got it, Thanks!
[20:33] <jsalisbury> genkgo, I should have an updated tools package for you shortly
[20:35] <genkgo-> jsalisbury: aight, i will make sure to go ahead with it right away, thanks again!
[20:36] <jsalisbury> apw, doing a 'fakeroot debian/rules binary-tools' produced an error:
[20:36] <jsalisbury> dpkg-gencontrol: error: package linux-image-3.19.0-18-tools not in control info
[20:36] <jsalisbury> dh_gencontrol: dpkg-gencontrol -plinux-image-3.19.0-18-tools -ldebian/changelog -Tdebian/linux-image-3.19.0-18-tools.substvars -Pdebian/linux-image-3.19.0-18-tools returned exit code 255
[20:36] <jsalisbury> debian/rules.d/2-binary-arch.mk:407: recipe for target 'binary-tools' failed
[20:36] <jsalisbury> make: *** [binary-tools] Error 2
[20:40] <flexiondotorg> infinity, I've had a few sponsor requests turned down.
[20:40] <flexiondotorg> infinity, Please take a peek at this - https://bugs.launchpad.net/ubuntu-mate/+bug/1456591
[20:40] <ubot5> Launchpad bug 1456591 in ubuntu-mate-artwork (Ubuntu) " ubuntu-mate-artwork 0.4.8 bug fix release [debdiff attached]" [Wishlist,Incomplete]
[20:41] <flexiondotorg> infinity, I'm just wanting to know if this is standard practice?
[20:41] <flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1456597
[20:41] <ubot5> Launchpad bug 1456597 in ubuntu-mate-settings (Ubuntu) " ubuntu-mate-settings 0.4.5 release [debdiff attached]" [Wishlist,Incomplete]
[20:43] <flexiondotorg> sorry. Wrong channel.
[21:25] <jsalisbury> apw, ah ha.  This what is needed to build the tools: fakeroot debian/rules binary-perarch
[21:32] <jsalisbury> genkgo, There is a new tools package called linux-tools-3.19.0-18_3.19.0-18.18_amd64.deb at the URL: 
[21:32] <jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
[21:45] <garrettr> I'm working on building Ubuntu kernels w/ grsecurity
[21:46] <garrettr> The command I use to build the kernel is make-kpkg --initrd --overlay-dir=../ubuntu-package kernel_image kernel_headers
[21:46] <garrettr> Where ubuntu-package is a copy of /usr/share/ubuntu-package from an up-to-date version of Ubuntu trusty (currently running 3.13.0-53)
[21:48] <garrettr> I have seen other guides recommend download the ubuntu-trusty git repo from kernel.ubuntu.com, and replace some of the Debian control scripts from /usr/share/kernel-package with the ones in the git repo
[21:49] <garrettr> My questions are: 1. why do this? 2. why don't the control scripts in ubuntu-trusty/debian/control-scripts match those in /usr/share/kernel-package/{image,headers}?
[22:37] <bjf> sbeattie, i'm following up on the apparmor tests
[22:37] <bjf> sbeattie, i'm looking at: http://kernel.ubuntu.com/testing/dagmar__3.13.0-53.89__2015-05-20_21-43-00/ubuntu_qrt_apparmor/results/ubuntu_qrt_apparmor.test-apparmor.py/debug/ubuntu_qrt_apparmor.test-apparmor.py.DEBUG.html
[23:23] <cyking> jsalisbury, let me know when/if you have time to assist with that bug report. thanks :)
[23:26] <jsalisbury> cyking, sorry, I got side tracked today, I'll have the next kernel built shortly.
[23:27] <cyking> jsalisbury, all good! thanks.