[08:01] <henrix> rozie: hi! i've just commented bug #1492146 about a new kernel available in -proposed
[08:01] <henrix> rozie: it would be great if you could check if that kernel fixes the issue
[08:04] <rozie> gimme like... 15 minutes
[08:08] <henrix> rozie: awesome!  thanks ;)
[08:18] <rozie> henrix: can you give me direct link to packages? I see it's in the proposed, but would like to avoid adding repos
[08:26] <henrix> rozie: here's the links:
[08:26] <henrix> http://archive.ubuntu.com/ubuntu/pool/main/l/linux-lts-utopic/linux-image-3.16.0-49-generic_3.16.0-49.65~14.04.1_amd64.deb
[08:26] <henrix> http://archive.ubuntu.com/ubuntu/pool/main/l/linux-lts-utopic/linux-image-extra-3.16.0-49-generic_3.16.0-49.65~14.04.1_amd64.deb
[08:26] <henrix> rozie: not sure if at this moment you care about other packages (headers, for example)
[08:27] <rozie> thx. I dont care about headers. just got lost in complicated Ubuntu repo structure ;/
[08:28] <henrix> rozie: heh, no prob
[08:28] <rozie> just kidding, but got use to Debian, as it's my primary OS and Ubuntu is... different
[08:29] <rozie> but haven't found this kernel on packages.ubuntu...
[08:30] <rozie> anyway, rebooting...
[08:33] <rozie> looks fine at first glance, but let it work for 5 mins
[08:35] <henrix> rozie: sure, not in a rush.  I really want to make sure the bug is fixed ;)
[08:35] <apw> henrix, was that the wholesale revert ?
[08:36] <henrix> apw: yep
[08:36] <henrix> apw: 14 patches being revert
[08:36] <apw> ouch
[08:37] <apw> did the bug get shoved out of fix-released at the saem time ?
[08:38] <henrix> we'll need to take another look at these backports.  and... i'm not sure i changed it to 'triagged' again (although i remember i commented on the bug)
[08:38]  * henrix goes check
[08:39] <apw> henrix, thanks ... i'd not want that to get lost as a result
[08:40] <henrix> apw: no, iirc joe is currently working on that bug so he probably actually changed it back
[08:42] <rozie> 523 packets transmitted, 523 received, 0% packet loss, time 526808ms - looks fine :-)
[08:43] <henrix> rozie: awesome!  thanks for testing ;)
[08:44] <henrix> rozie: would you please add a comment to the bug, and change the 'verification-needed-trusty' to 'verification-done-trusty' tag?
[08:44] <henrix> rozie: (i can do that for you if you're busy)
[08:46] <rozie> already commented, pls change tag
[08:47] <henrix> rozie: cool, thanks
[08:47] <henrix> infinity: fyi ^^
[10:52] <LocutusOfBorg1> Hi, I don't remember who handles the virtualbox kernel modules
[10:52] <LocutusOfBorg1> but virtualbox 5.0.4 is out, claiming full compatibility with kernel 4.2
[10:52] <LocutusOfBorg1> you might want to sync changes
[10:58] <apw> LocutusOfBorg1, sounds good, thanks
[10:58] <apw> LocutusOfBorg1, mostly i do for what it is worth
[13:30] <popey> Anyone noticed massive slowdown on 4.2? My desktop is pretty much unusable while doing IO
[13:31] <popey> 15s to open a terminal
[13:44] <tjaalton> i've noticed something similar, building a kernel and doing anything is very sluggish
[13:48] <cking> popey, I'll sort out some testing against 4.2 and see what's going on
[13:49] <cking> popey, what's your config in terms of system / CPUs/ HDD/SSDs etc
[13:51] <cking> and what kind of I/O are you doing?
[13:52] <rtg> tjaalton, you ought to be able to provide some numbers if you're doing builds. 
[13:52] <rtg> that seems pretty deterministic
[13:54] <tjaalton> numbers?
[13:54] <popey> cking: i7 / one HDD (spinning rust) / 8GB RAM
[13:54] <tjaalton> I have ivybridge, 240GB ssd, but home is on btrfs..
[13:54] <popey> only thing it's doing is an rsync backup to another machine over gbe
[13:54] <tjaalton> kernel trees on ssd
[13:54] <popey> sandybridge cpu, ext4 filesystem
[13:54] <rtg> tjaalton, build times with 4.1 v.s. 4.2 ?
[13:55] <cking> why does my heart sink when btrfs is mentioned...
[13:55] <popey> backup seems to be chugging along, load average is 4.5
[13:55] <tjaalton> ah, well the build is fine I think, just that doing anything interactive at the same time is sluggish
[13:55] <popey> no btrfs here :)
[13:55] <tjaalton> cking: hehe
[13:56] <cking> ok, let me do ext4 first as that's our default ;-)
[13:56] <popey> thanks
[13:56] <cking> np
[13:56] <davmor2> cking: https://i2.wp.com/ak-hdl.buzzfed.com/static/2014-10/7/19/enhanced/webdr05/anigif_original-grid-image-18241-1412725925-4.gif
[13:57] <cking> hrm
[14:00] <davmor2> cking: just visualising the the heart sinking :)
[14:00] <cking> ah, yes ;-)
[14:04] <tjaalton> more specifically, my $HOME is on a four-disk btrfs HDD RAID
[14:04] <tjaalton> raid10-ish
[15:09] <LocutusOfBorg1> thanks apw 
[15:14] <LocutusOfBorg1> apw, where are the sources for the module?
[15:14] <LocutusOfBorg1> here? http://kernel.ubuntu.com/git/ubuntu/linux.git
[15:15] <apw> LocutusOfBorg1, so we update the module directly from the binaries the dksm package produce
[15:15] <apw> though right now i assume we ahve it patched locally
[15:15] <LocutusOfBorg1> so you provide a .ko module?
[15:16] <LocutusOfBorg1> thanks
[15:16] <apw> yes
[15:16] <apw> but we need the real dkms package updated, which i htink was what you were telling me i hsould (and will) do
[15:16] <LocutusOfBorg1> I thought you were copy-pasting the sources in the kernel tree and providing a build during install :)
[15:16] <LocutusOfBorg1> exactly, I guess this is the best way to do
[15:16] <LocutusOfBorg1> like we do with vbox-dkms
[15:17] <LocutusOfBorg1> having them inside the kernel is really awesome :)
[15:18] <apw> we are indeed pasting in the sources, but i do that from the result of the virtualbox package making the source for the dkms package
[15:18] <apw> if any of that makes any sense
[15:18] <apw> yeah needed for some clouds apparently
[15:46] <cking> popey, i've kicked of a range of file systems tests, i'll get back to you once they are complete (probably next week)
[15:46] <cking> s/of/off
[15:48] <popey> cking: super, thanks
[18:59] <rul_> Hi. Old kernels aren't being autoremoved despite being marked as auto and not being in "APT::NeverAutoRemove"... any hint on how can I debug this issue? 
[19:03] <rul_> debugging autoremove I can see this lines
[19:03] <rul_> Following dep: systemtap:amd64 2.3-1ubuntu1 Suggests linux-image:amd64 , provided by linux-image-3.2.0-59-generic:amd64 3.2.0-59.90Marking: linux-image-3.2.0-59-generic:amd64 3.2.0-59.90, Curr=3.2.0-59.90, Inst=3.2.0-59.90
[19:04] <rul_> it's like the old kernel aren't removed because they're suggested by systemap
[19:07] <apw> those all do provides:linux-image .... infinity ^
[19:12] <infinity> apw: systemtap's dep is bogus.
[19:12] <infinity> "we recommend you have a kernel installed" is about the most useless dep I can think of.
[19:12] <infinity> "Depends: computer".
[19:12] <apw> yeah it cirtainly is ...
[19:12] <apw> ok so we should get that ripped
[19:13] <apw> rul_, can you file a bug against systemtap please and tell me the number
[19:13] <infinity> rul_: To confirm, if you remove systemtap, do kernels autoremove happily afterward?
[19:16] <infinity> apw: It's also possible that our provides is a bit overzealous there, and we should be providing virtuals like linux-image and linux-headers from the metapackages instead of the real packages.
[19:16] <infinity> apw: But can't go back in time and fix all the old kernels to do that.
[19:20] <apw> infinity, moving the provides to the to the meta-pacakge is an interesting idea
[19:23] <infinity> apw: It would get us the behaviour we'd prefer if something did depend on one of those virtuals.  We don't want a one-off ABI-versioned package installed, we want the meta, so people actually get upgrades.
[19:23] <apw> infinity, yes, seems appropriate
[19:23] <infinity> apw: (I still think it's a bug for anything to depend on the virtuals anyway, but some stuff from Debian does, and it's not worth the delta to fix them all)
[19:24] <apw> when rul_ gives me his bug, i'll file one off that for linux/etc to move them
[19:24] <infinity> apw: Anyhow, only something we could fix for >= wily, since stable releases have tons of kernels with the provides already baked in.
[19:31] <apw> infinity, right get it fixed before the next lts
[20:27] <rul_> yup, I've marked systemtap package as auto and suddenly all old kernels can be autoremoved
[20:27] <rul_> filling the bug
[20:45] <rul_> #1494481
[20:47] <apw> bug #1494481