=== RAOF is now known as tmpRAOF
=== gerald is now known as Guest16438
=== dupondje_ is now known as dupondje
=== jhenke_ is now known as jhenke
[10:28] <apw> alias_neo (N,BFTL), the libvirt thing shouldn't be affected by the kernel at all, so i am confused ?
=== dgadomski_ is now known as dgadomski
[15:29] <tseliot> apw: I'm uploading a patched fglrx that works with linux 3.19. I'll do the same for nvidia soon. Does broadcom need a refresh too?
[15:32] <eren> hello. I need to compile 3.18.3 with debug symbols on to be used in "perf" utility. I am using Ubuntu Server 14.04. Is there a documentation, ppa, or source explaining the way to achieve it?
[15:32] <eren> I also need some firmwares as well
[15:33] <eren> i tried installing 3.18.3 by downloading .deb file in kernel-ppa but debug symbols are off. Additionally, I need to get uncompressed kernel image
[15:33] <eren> any help is appreciated
[15:41] <apw> tseliot, bcmwl_kernel_source looks ok, and ta for the otehrs
[15:41] <tseliot> apw: good :)
[15:43] <apw> eren, we don't make those with debug in, no sorry, the debug symbols are just toooo big
[15:46] <eren> apw: ok, I can compile them, no problem
[15:47] <eren> apw: I'm cloning ubuntu/ubuntu-vivid.git. I also found this wiki page: https://help.ubuntu.com/community/Kernel/Compile
[15:48] <eren> so, what should I do to enable debug symbols and get uncompressed image?
[16:03] <eren> apw: are debug infos stripped after the compilation step because I see CONFIG_DEBUG_INFO=y in amd64 configuration
[16:03] <apw> yes
[16:04] <apw> eren, they are used to make .ddebs and then stripped to make the .deb
[16:04] <apw> though in the mainline kernel case we do not make the .ddebs at all currently
[16:04] <apw> as they are larger per flavour than all of the flavours put together
[16:07] <eren> apw: ok, is there a way to not strip debug symbols as I see the kernel is compiled using debug symbols
[16:07] <apw> eren, the norm is to make the deebs, so you end up with a small runnable kernel, and the ddeb has the dwarf info in it
[16:07] <apw> ddebs
[16:10] <eren> apw: ok, so ddebs are also generated to be installed?
[16:10] <apw> eren, if you trigger a full build yex
[16:10] <apw> yes
[16:10] <apw> doing so off a buildder may be a little more tricky, you may need to override the checks for that
[16:10] <eren> ok, compiling now with "fakeroot debian/rules binary-headers binary-generic"
[16:11] <eren> after grabbing ubuntu-vivid.git, btw
[16:12] <apw> eren, you will need to add full_build=true i believe, else it will short cirtcuit them for you
[16:12] <apw> and make sure you have like 5G or so of space
[16:12] <eren> well space and ram are not problem I have 24 core, 48G ram
[16:12] <eren> apw: oh, I didn't add "full_build=true", should I pass this as an environment variable?
[16:14] <apw> on the debian/rules line after it
[16:14] <eren> DEB_BUILD_OPTIONS=parallel=24 full_build=true AUTOBUILD=1 fakeroot debian/rules binary-headers binary-generic
[16:15] <eren> oh, after it, ok
=== clopez_ is now known as clopez
[17:08] <staylor> Question about building a custom kernel using the debian/rules, what's the correct way to sign the debs afterwards?
[17:09] <apw> staylor, sign them for download ?
[17:10] <apw> most people use a PPA to build them, and get the signatures from tehre
[17:10] <staylor> apw: I mean I've built a custom deb and want to sign the one I distribute
[17:10] <staylor> apw: it's for some custom hardware so using our own internal mirror not PPA
[17:10] <apw> staylor, i think debsign will do that, but you'll have to ship whatever key you are using, the public component
[17:12] <staylor> apw: okay wasn't sure, all our custom debs get signed correctly just using debuild so wasn't sure about kernel packages.
[17:12] <maxb> Normally people don't sign .deb files at all
[17:13] <maxb> .changes and .dsc files get signed to authenticate them to a repository they are being uploaded to
[17:13] <maxb> and Release files get signed to authenticate the contents of the repository to clients
[17:13] <maxb> But debsign may still be the right answer for you, as it kind of sounds like you're trying to sign the .changes file that goes with your .debs to upload them somewhere
[17:14] <staylor> yeah, using reprepro, though building with debian/rules doesn't generate .changes it seems.
[17:15] <apw> staylor, they are they same as any other .deb, so whatever you are doing for them, ought to work
[17:18] <maxb> Direct use of debian/rules is a layer too low in the stack of tools to get a .changes; dpkg-genchanges is normally invoked as a step of dpkg-buildpackage
[18:08] <smoser> arges, bah. did tso's response on bug 1415077 seem correct ?
[18:08] <ubot5> bug 1415077 in e2fsprogs (Ubuntu) "resize2fs -P minimum size differs greatly between v1.42.10 and v1.42.9" [Medium,Invalid] https://launchpad.net/bugs/1415077
[18:09] <smoser> if the only option is to run 'resize2fs -M' multiple times (which results in slow reaad filesystem) then i'll probably just create a new fs.
[18:10] <smoser> and copy contents and uuid and label
[18:45] <shadeslayer> rbasak: I've upgraded the kernel to 3.16 from 3.13 in hopes that the problem got fixed upstream
[18:45] <shadeslayer> rbasak: lets see if it works
[18:46] <shadeslayer> ( atleast pull-lp-source seems to work manually )
[19:14] <arges> smoser: looking
[19:16] <arges> smoser: yea should have read the entire commit, but it seems reasonable. so i'd just adjust your scripts
[21:17] <shadeslayer> rbasak: yeah, upgrading to 3.16 seems to have fixed it
[22:48] <rbasak> shadeslayer: interesting, thanks. I wonder if the race is fixed or if the timing just changed.
[23:22] <shadeslayer> rbasak: not sure, there were a few race condition fixes in git https://github.com/torvalds/linux/commits/master/fs/overlayfs
[23:23] <shadeslayer> which made me think, lets try and upgrade to see what happens
[23:23] <shadeslayer> though I'm not even on the stable kernel, which apparently is 3.18