[00:01] <twb> OK, so I built 3.0 with "make deb-pkg" on hardy, and it gave stripped packages.  So I guess the builddeb script as at 2.6.32 is just too stupid to do that :-/
[00:01] <twb> I don't really wanna go back to make-kpkg
[00:07] <twb> Actually make it wasn't stripped, I only looked at the .deb size (5MB instead of 150MB), but that might just be because I used defconfig instead of the allmodconfig-esque ubuntu .config
[00:10] <twb> not stripped.
[00:11] <twb> Aaand nor are the .ko's in my personal ones, so "make deb-pkg" doesn't normally strip, either.  Mea culpa.
[01:05] <twb> OK, it turns out to be simple -- pass INSTALL_MOD_STRIP=1 to build and then strip, or unset CONFIG_DEBUG_INFO in your .config to avoid building debugging symbols in the first place.
[01:05] <twb> The former is handy if you want to go back and "make debug-package" or so (can't remember the exact target name).
[02:21] <jonpry> how can i debug an acpi problem?
[06:04] <cemc> hi. I'm trying to rebuild the latest hardy kernel package. I've got the .dsc, I've changed what I wanted, then uploaded it to my ppa, but it doesn't build: https://launchpadlibrarian.net/83147123/buildlog_ubuntu-hardy-i386.linux_2.6.24-29.94~cemc111019~ppa1_FAILEDTOBUILD.txt.gz . it's complaining about some missing ABI files. I have no idea what I need to do. never messed with a kernel package before. any pointers would be appreciated
[06:33] <matei1> hi, I have a question about Ubuntu 11.10 on EC2: is it possible to use transparent hugepages in the latest cloud kernel? the /boot/config-* file says that CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y, and I have an application that uses madvise with MADV_HUGEPAGE, but I don't see any AnonHugePages created in /proc/meminfo
=== smb` is now known as smb
[07:21] <smb> cemc, Probably https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI is closest to help
[08:20] <sroecker> hi, does the kernel bugzilla work again?
[08:21] <smb> Does not seem so
[08:24] <sroecker> bummer, i would like to have a look at http://bugzilla.kernel.org/show_bug.cgi?id=36152 to fix bug 706039
[08:24] <ubot2> Launchpad bug 706039 in isight-firmware-tools "Can't produce data in UYVY" [Undecided,Confirmed] https://launchpad.net/bugs/706039
[08:25] <ubot2> sroecker: Error: Could not parse XML returned by bugzilla.kernel.org: timed out (https://bugzilla.kernel.org/xml.cgi?id=36152)
[08:59] <cemc> smb: thanks!
[09:00] <apw> bah everyone i go to answer has always gone, so frustrating
[09:01] <smb> apw, Was that the hugepage question?
[09:01] <apw> yeah
[09:01] <apw> actually and one futher up in scrollback ... sigh
[09:01] <smb> Has been gone almost immediately after asking
[09:02] <apw> moin
[09:02] <smb> (well almost a bit strechted)
[09:02] <smb> moin
[09:03] <smb> apw, Actually you could answer me, I am not completely sure. Would say it should work, even finding some old information that it may depend on the hypervisor, too. 
[09:04] <apw> i would think it is very dependant on the hypervisor supporting it, as it would need to support the PTE formats etc
[09:05] <smb> Right, so ec2 actually may not work as they are on 3.4.x at most
[09:06] <apw> and even if it is available at the hypervisor i would expect it to be a configurable option and probabally off by default
[09:06] <smb> Found some 2yr old info about required boot arguments for the hypervisor and guests, but those did not appear in the current wiki. Which could mean the wiki is incomplete or the option is gone..
[09:07] <apw> yeah, i presume you can tell from the proc/cpuinfo cpu flags that xen gives you
[09:08] <apw> it also depends on xen giving you contigious physical ram, and i am not sure it does that either by default
[09:09] <apw> smb, cifs is the in kernel samba implementation i think right?
[09:09] <smb> apw, well the sort of guest part I think
[09:10] <apw> right that bit yes
[09:10] <apw> do you have a samba server on the network your hardy box is on ?
[09:10]  * apw has a cve which i wonder if anyone can reproduce on hardy
[09:11] <smb> apw, Yes, the test system can access it
[09:11] <apw> so the bug in theory is you use cifs to mount it, then you use another user to mount it but without a password, and it "reuses" the password the kernel already has allowing the second user access too
[09:12] <smb> I guess I can give it a try...
[09:13] <apw> if you have time that would rock, as i have a patch for it, but who knows if it works
[09:13] <smb> apw, any preference on 32 or 64 bit?
[09:14] <apw> no specification either way in the bug, so i assume it is generic
[10:04] <smb> apw, Ok, so it seems to incorrectly work as you described it
[10:04] <apw> that is awsome
[10:05] <apw> smb, you 32 or 64 bit
[10:05] <smb> apw, 64bit
[10:05] <alexbligh> I am attempting to build a new flavour of ubuntu kernel (oldstyle/xenlinux xen, for 3.3 hypervisor). My kernel builds fine, but as it makes a vmlinuz not a bzImage, it doesn't package. I can see there are bits in debian.master/rules.d to control this on a per arch basis (though I don't understand them). How do I control on a per flavour basis?
[10:06] <apw> alexbligh, how are you triggering the build
[10:07] <alexbligh> fakeroot debian/rules binary-myflavour
[10:07] <apw> alexbligh, the output file requested is controled by the debian.<branch>/rules.d/<arch>.mk file
[10:07] <alexbligh> right, but arch is amd64. I only have a flavour. Or do I need to do a whole new arch?
[10:07] <apw> install_file    = vmlinuz
[10:08] <apw> isn't a vmlinuz a bzImage anyhow ?
[10:08] <apw> its not an x but a z
[10:08] <alexbligh> The XEN patches cause it not to produce the bzImage.
[10:08] <alexbligh> No, I don't think they are the same
[10:09] <apw> build_image     = bzImage
[10:09] <alexbligh> At least not according to the debian patch which says "we can't load a bzImage so load a vmlinuz for now"
[10:09] <apw> have you changed tha t?
[10:09] <apw> kernel_file     = arch/$(build_arch)/boot/bzImage
[10:09] <apw> and indeed that ?
[10:09] <alexbligh> You mean in debian.master/rules.d/amd64.mk?
[10:09] <apw> yep
[10:10] <alexbligh> I haven't changed that file at all, because I wanted amd64 to continue to build. I only wanted the targets to change for my flavour.
[10:10] <apw> i am pretty sure we have the same problem with powerpc in older releases
[10:10]  * apw isn't sure you can do that
[10:10] <alexbligh> ok. that's not the end of the world.
[10:10] <alexbligh> so build_image should be vmlinuz
[10:10] <apw> alexbligh, we don't normally want to make the originals when we make a derived branch like that
[10:10] <alexbligh> install_file should be vmlinuz (as it is at the moment)
[10:11] <alexbligh> and kernel_file should be what?
[10:11] <apw> build_image should be what you type when you type make in a native tree
[10:11] <alexbligh> vmlinuz
[10:11] <apw> kernel_file should be whatever it makes when it builds it when you do that :)
[10:11] <apw> its a bit of a guessing game
[10:12] <alexbligh> Kernel: arch/x86/boot/vmlinuz is ready  (#2)
[10:12] <alexbligh> that then :-)
[10:12] <apw> yeah that sounds about right
[10:12] <alexbligh> apw, thanks
[10:12] <apw> np
=== gema_ is now known as gema
=== lag` is now known as lag
[12:53]  * apw notes that you are all going to get a spurious v3.1-rc10 build announcement ... i hope
[13:31] <ogasawara> herton, bjf: just fyi http://people.canonical.com/~ubuntu-archive/pending-sru appears to mention there is a separate report for our kernel SRU's, but the url it points to is invalid, ie it points to http://people.canonical.com/~ubuntu-archive/pending-sru
[13:32] <ogasawara> herton, bjf: bah, http://kernel.ubuntu.com/~kernel-ppa/reports/sru-report.html is the invalid url location
[13:32] <bjf> ogasawara: nice, it actually points to the ~kernel-ppa location where it used to be
[13:32] <bjf> ogasawara: i'll mention it to pitti
[13:33] <ogasawara> bjf: yah, didn't know if you wanted to set up a re-direct to get pitti to fix it
[13:33] <bjf> ogasawara, it's been broken forever so not many people must be using it
[13:42] <bjf> ogasawara: pitti has fixed his script and it will be fixed in the next update
[13:43] <ogasawara> bjf: cool
[14:12]  * ogasawara back in 20
=== ericm|ubuntu is now known as ericm-Zzz
[15:43] <herton> apw: ogasawara: did you saw this error before when uploading to c-k-t ppa? Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied.
[15:43] <herton> I'm trying to upload the new linux-lts-backport-oneiric, the packages were signed by bjf
[15:43] <herton> I already uploaded packages signed by him and it went ok, may be the fact the package is new has something to do with it
[15:45] <smb> herton, whether new or not should not matter. maybe the signage key was accidentally not the one in lp...?
[15:46] <herton> smb: nope, the key is ok, matches the lp one
[15:46] <ogasawara> I think if it's the first upload of the new package, you might new core dev privs to do so?  I swear I might have hit something similar doing lbm at one time
[15:46] <ogasawara> herton: I think I had to have tgardner do the first upload, and after that I was ok
[15:47] <smb> ogasawara, herton Oh, maybe right because its new new (as not in the upload rights list)
[15:47] <ogasawara> smb: yep
[15:47] <herton> ogasawara: hmm ok, only tim is core dev?
[15:47] <smb> yep
[15:48] <ogasawara> herton: and I think he's out until UDS?
[15:48] <smb> but you could ask cjwatson to add the package to the list I guess
[15:50] <herton> calendar shows him on vacation until this friday. I'll ask cjwatson if he can see this
[15:52] <bjf> smb, looks like tim's "hit by bus" rule applies here, we should probably get apw and ogasawara and maybe yourself as core dev ?
[15:52] <bjf> smb, need more than one
[15:52] <smb> bjf, Yeah, me and apw have it on our list... Just always seemed "too hard"
[15:53] <ogasawara> smb: yah, seems like a lot of extra work for not much more gain
[15:56] <ogasawara> herton: have you gone before the DMB yet to get your kernel upload rights?
[15:56]  * ogasawara meant to ack your application
[15:57] <bjf> ogasawara, he hasn't yet
[15:57] <herton> ogasawara: I'm with my application ready, but the October 24th date is a not good one, since tim may be is away and sconklin too, and the timing is not good, I was thinking of sending the application for the meeting after
[15:57] <herton> october 24
[15:58] <ogasawara> cool
[15:59] <smb> herton, now try to upload lts-backport again...
[16:00] <herton> smb: still the same
[16:01] <smb> Hm, bjf what is your lp username again?
[16:01] <bjf> smb: brad-figg
[16:10] <smb> bjf, OK seems solved... It was only a fake error. And our upload rights actually do not matter as everything goes via ppa. But I guess it does not hurt if our package uploader rights mtach what damage we could do via the ppa
[16:11] <herton> yeah, the builds are showing on c-k-t ppa despite the error, so should be ok
[16:55] <ogasawara> bjf, jsalisbury: are you guys going to want to have an official UDS kernel bug session, or can we just chat over a pint of beer at the bar
[16:56] <bjf> ogasawara: beer!
[16:57] <ogasawara> heh, I probably didn't even need to ask :)
[17:01] <jsalisbury> ogasawara, beer works for me :-D
[17:01] <jsalisbury> ogasawara, bjf or both
[17:02] <bjf> ogasawara, jsalisbury, don't need a session
[17:02] <jsalisbury> bjf, ok
[17:08] <ogasawara> apw: before I forget again, we're planning on sticking with the 3 digit version scheme for Precise right?
[17:10] <apw> i think its likely, we should think about it at UDS and check before we upload 3.2
[17:11] <ogasawara> apw: yep, I pretty much forced us to the 3 digit when I uploaded 3.1.0 yesterday, but am banking on the fact we'll be using at least 3.2
[21:03] <jsalisbury> ogasawara, bug 876996 looks like a regression that prevents an install/upgrade of Oneiric
[21:03] <ubot2> Launchpad bug 876996 in linux "Ubuntu 11.10 fresh install crashed" [High,Triaged] https://launchpad.net/bugs/876996
[23:10] <hggdh> ogasawara: can you reset bug 871899? I wrongly set the kernel verification task as completed
[23:10] <ubot2> Launchpad bug 871899 in kernel-sru-workflow "linux: 2.6.32-35.78 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/871899