[00:02] <mdeslaur> Is there an ETA for the lucid mini 9 sound regression caused by kernel 2.6.32-34? (LP: #875300)?
[00:03] <mdeslaur> or do I have to apply workaround for all family and friends?
[00:44] <redzarf> more details are here: http://stackoverflow.com/questions/8088901/
[00:46] <jjohansen> redzarf: whats up :)
[00:46] <redzarf> jjohansen: I was hoping you might be around :)
[00:46] <redzarf> still can't get the image deb file to build
[00:46] <jjohansen> yeah I gathered that :)
[00:47] <jjohansen> redzarf: what kernel source are you using, and on what version of the OS are you building
[00:47] <redzarf> kernel: linux-ec2-2.6.32
[00:47] <redzarf> OS is lucid (latest on EC2)
[00:48] <jjohansen> alright and where is it failing
[00:48] <redzarf> Been trying from the plain Ubuntu AMI's
[00:48] <redzarf> I think it's during the fakeroot debian/rules binary
[00:49] <redzarf> the stackoverflow page has the error message that comes up at the end
[00:49] <jjohansen> redzarf: okay, can you paste the error some where? paste.ubunt.com ?
[00:49] <jjohansen> redzarf: ah, okay looking again
[00:49] <redzarf> thx
[00:51] <jjohansen> redzarf: in the source directory, what debian directories exist?  is it debian and debian.ec2 or debian and debian.master
[00:52] <redzarf> all 3
[00:53] <jjohansen> redzarf: hrmm, try binary-ec2
[00:54] <jjohansen> it should be hooked up so that binary, does binary-ec2 /me is wondering if there is a bug there
[00:55] <redzarf> still similar errors as before (no image file)
[00:56] <jjohansen> redzarf: what is under debian/build/
[00:56] <redzarf> i'll try redownloading source and doing it from scratch, then paste the full output
[00:56] <redzarf> i'll try redownloading source and doing it from scratch, then paste the full output to paste.ubuntu.com
[00:57] <jjohansen> redzarf: oh wait did you do a fakeroot debian/rules clean first
[00:57] <redzarf> i did
[00:57] <redzarf> but i'll do it from scratch to be sure
[00:58] <redzarf> would you recommend I get linux-image-2.6.32-318-ec2 or just linux-ec2?
[00:58] <jjohansen> redzarf: honestly I would recommend the git tree
[00:59] <redzarf> what settings would i need to change for ec2?
[00:59] <jjohansen> git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
[00:59] <jjohansen> git checkout --track ec2 -b ec2 origin/ec2
[01:00] <jjohansen> second command from within the directory the first creates
[01:00] <redzarf> ah, excellent :-)
[01:00] <redzarf> nearly finished using the apt-get version...
[01:00] <jjohansen> I know the source tarball should be good enough, but I always use the git tree
[01:02] <redzarf> http://paste.ubuntu.com/738824/
[01:03] <jjohansen> looking
[01:03] <redzarf> btw, i think the file that is touch'ed on line 11 doesn't exist - the place it's copied from doesn't have that file
[01:05] <jjohansen> redzarf: ah yeah, okay do
[01:05] <jjohansen> make mrproper
[01:05] <jjohansen> git checkout -f
[01:06] <jjohansen> and try building again
[01:06] <redzarf> ok, doing the clone now
[01:07] <redzarf> then I do the first checkout above? (--track ec2)
[01:07] <redzarf> then those 2 commands?
[01:08] <redzarf> do i make menuconfig just before doing the debian/rules clean?
[01:08] <jjohansen> oh, sorry no
[01:08] <jjohansen> within a git tree, those last to will let you get past the mrproper error and build, but not from the source tarball
[01:09] <jjohansen> so the the clone and checkout commands
[01:09] <jjohansen> then do
[01:09] <jjohansen> fakeroot debian/rules editconfigs
[01:10] <jjohansen> if you do menu config before clean, its changes will get blown away
[01:10] <jjohansen> actually you will need to do an
[01:10] <jjohansen> fakeroot debian/rules clean
[01:10] <jjohansen> before editconfigs
[01:11] <jjohansen> editconfigs is a wrapper around make menuconfigs
[01:11] <redzarf> i'd been doing make menuconfig then the fakeroot debian/rules clean then fakeroot debian/rules binary, so i guess they were out of order
[01:11] <redzarf> right
[01:12] <jjohansen> well you can do it but, I won't guarentee that it will work
[01:12] <redzarf> so do i still do make mrproper and git checkout -f ?
[01:12] <jjohansen> actually I think make menuconfig will but then you hit the mrproper problem
[01:12] <jjohansen> no
[01:13] <redzarf> so this is what i'm about to run:
[01:13] <redzarf> git checkout --track ec2 -b ec2 origin/ec2
[01:13] <redzarf> fakeroot debian/rules clean
[01:13] <redzarf> fakeroot debian/rules editconfigs
[01:13] <redzarf> fakeroot debian/rules binary
[01:14] <redzarf> fatal: git checkout: updating paths is incompatible with switching branches.
[01:15] <jjohansen> oops
[01:15] <jjohansen> git checkout --track -b ec2 origin/ec2
[01:15]  * jjohansen messed up the checkout syntax
[01:15] <redzarf> thats ok, the noob who doesn't know any better will forgive you :)
[01:17] <jjohansen> well even for someone who uses git daily sometimes its syntax is uhm less than friendly
[01:20] <redzarf> the binary command is running - taking much longer than it ever has before, so I'll take that as a good sign
[02:01] <redzarf> jjohansen: it's finished and the image file is there!! :)
[02:01] <redzarf> so I just run  dpkg -i linux-*.deb  then restart - anything else?
[02:02] <jjohansen> redzarf: that should be it
[02:03] <redzarf> great, thanks for your help!
[02:05] <jjohansen> redzarf: np
[08:39] <apw> GrueMaster, did it end up in universe perhaps
[08:55] <smb> morning .+
[08:58] <n0ti0nis> morning
[10:01] <ppisati> morning morning
[10:56] <seb03> Hi, I'd like to help with the ASPM bug, how do I know that I've installed the patched kernel correctly?
[10:57] <seb03> does it simply replace the existing one or should it be selectable on boot?
[10:57] <smb> seb03, It would replace the existing one if you take the same version
[10:57] <smb> Theoretically you should notice a difference in uname -a after boot
[10:58] <smb> but in doubt it is the one compiled on Sat-12
[10:58] <seb03> sure do: uname -a Linux snoopy 3.0.0-13-generic #22+mjgaspmfix SMP Mon Nov 14 18:02:48 UTC 2011 i686 i686 i386 GNU/Linux
[10:58] <smb> So that is the patched one
[10:59] <seb03> so how do I get rid of it again after I've done my power readings?
[10:59] <seb03> install the meta package from the repo again?
[11:02] <smb> seb03, In doubt you can get the package from there https://launchpad.net/ubuntu/oneiric/+source/linux/3.0.0-13.22
[11:02] <smb> There is also some way to force a reinstall with specifying a version, but I personally find it rather complicated. :)
[11:04] <seb03> thanks
[11:10] <iceroot> hi
[11:11] <iceroot> https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/869502  can you have a look at this bug to give me infos how i can support you on a better way to get it fixed
[11:11] <ubot2> Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed]
[11:14] <iceroot> see also http://article.gmane.org/gmane.linux.kernel/1211290 and http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=6192
[12:08] <seanius> hi, quick question:  I'm maintaining a local kernel package based off the ubuntu-lucid git repo.  I'm wondering how I should make commits to incrememnt the changelog frmo the ubuntu version
[12:09] <seanius> is there some magic string i need to put in the commit to get it show up in debian/changelog?  and is there anything else I need to do to increment the ubuntu version?
[12:16] <tgardner> seanius, kernel maintenance is described somewhere in https://wiki.ubuntu.com/Kernel 
[12:20] <ppisati> seanius: everything you commit (except if you use the Ignore: Yes string in the commit log) should show up in the changelog
[12:20] <ppisati> seanius: about the version, it's your duty to increment it
[12:21] <ppisati> seanius: you mean the last 2 numbers, right?
[12:21] <ppisati> seanius: e.g. linux-image-3.0.0-1206-omap4_3.0.0-1206.12_armel.deb
[12:21] <ppisati> seanius: the 1206 and 12 numbers in this pkg
[12:31]  * ppisati -> lunch
[12:48] <seanius> ppisati: none of my commits show up in the changelog, but like I said I don't know if there's some documented syntatic sugar i'm missing in the commit or some script/template etc
[12:49] <seanius> tgardner: i will poke around and see what i can find
[12:49] <apw> seanius, you probabally need a fakeroot debian/rules insertchanges to get them into the changelog, of course that implies you have followed standard proceedure in opening the changelog entry (fakeroot debian/rules newrelease)
[12:50] <apw> all of this is documented (poorly) in the kernel-team wiki
[12:50] <seanius> looking at https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePatchApplication right now
[12:51] <seanius> basically, i have a set of about 50 backported patches which i need to maintain on top of one of the ubuntu-lucid kernels
[12:51] <seanius> and periodically rebase against the ubuntu updates int the repo
[12:54] <seanius> each time i rebase the list of patches get a bit smaller but i don't see the problem ever going away entirely
[12:55] <seanius> at least until 3.2 is released and backported :)
[12:55] <seanius> it looks like apw's suggestion agrees with the above wiki page, so i'll try working with that
[12:56] <seanius> thanks!
[13:12] <seanius> one more question: what provides maint-getabis?
[13:19] <apw> there is a getabis script in the tree, maint-getabis is more for use by team members, as it talks to our PPAs etc
[13:20] <smb> (which would be in the kteam-tools git repo)
[13:20] <seanius> right, thx
[13:22] <seanius> and for changes to be inserted via debian/rules insertchanges they need to have an "UBUNTU:" line in them?
[13:24] <apw> nope
[13:24] <apw> for them to have your name against them ye
[13:24] <apw> yes, otherwise no
[13:24] <seanius> or... i guess the new release commit has to go before them
[13:25] <apw> nope, not that either
[13:25] <apw> it looks for the previous release commit
[13:25] <apw> the format of the release commit title is important
[13:25] <seanius> insertchanges turns my new release changelog into a blank entry
[13:25] <ppisati> seanius: did you close it properly?
[13:26] <apw> its all simple shell in debian/rules.d so you should be able to debug it pretty easy
[13:26] <apw> its definatly orientied to our use models
[13:26] <seanius> understandable
[13:26] <seanius> okay so this is what i'm doing so far
[13:26] <apw> normally an empty entry is triggered by it failing to find the previous release commit
[13:27] <seanius> git pull --rebase to get some updates
[13:27] <apw> and fakeroot debian/rules printenv will tell you what it things current and previous are
[13:27] <seanius> git clean -dffx && git reset --hard
[13:27] <seanius> fakeroot debian/rules clean
[13:27] <seanius> fakeroot debian/rules startnewrelease
[13:27] <seanius> git commit -s -F debian/commit-templates/newrelease
[13:28] <seanius> oh, oops, there's a git add debian/changelog in there
[13:28] <seanius> er, debian.natty/changelog
[13:28] <seanius> and then  fakeroot debian/rules insertchanges, which sets the changelog to be empty
[13:29] <apw> ok, as i say thats probabally because its failing to find its previous entry
[13:29] <apw> fdr printenv will show you the version it is looking for
[13:31] <seanius> i also see an error from expr when running fdr startnewrelease
[13:31] <seanius> apw: will look at printenv after i clean up again
[13:32] <apw> then likely your version format is probabally not working for the tooling, and the tools may need a tweak
[13:32] <seanius> but i haven't added any version yet
[13:32] <seanius> but this is in the natty-lts-backport tree so maybe it's something existing in the repo
[13:33] <apw> if your version is triggering the expr then likely the previos version is being broken
[13:33] <apw> which means we won't find it to do the entry detection
[13:33] <apw> you can just ignore the tooling there and use like
[13:35] <apw> if you look at the implementation of insertchanges, you can see how it works
[13:35] <apw> you can use git log of your own in the same command line
[13:36] <seanius> ah, yeah, you have a bug in rules.d :)
[13:37] <seanius> revision          = 13.52~lucid1
[13:37] <seanius> @nextminor=$(shell expr `echo $(revision) | awk -F. '{print $$2}'` + 1);
[13:37] <apw> yep, probabally never used on lts backports
[13:38] <apw> we don't generate those that way
[13:38] <seanius> but really, if all i'm interested is sticking a version on top of the existing backport version, and don't care about good changelog documentation, i could just directly edit the debian.natty/changelog file?
[13:39] <apw> yes
[13:39] <seanius> okay, simplicity ftw then :)
[15:29]  * ogasawara back in 20
[15:41] <apw> smb, whats the latest official relase of your drm33 tree ?
[15:42]  * smb believes 2.6.32.48.21
[15:43] <smb> apw, ^ Should be that. Am I slacking somewhere?
[15:43] <apw> smb, no making sure the flip back to kernel.org worked
[15:43] <apw> and that we are up to date
[15:43] <smb> Ah, ok
[15:45] <smb> apw, We should be up to date from before. I think I saw builds happening while I still was bringing k.org back to life
[15:46] <apw> url = git://kernel.ubuntu.com/smb/linux-2.6.32.y-drm33.z.git
[15:46] <apw> oh we are on the old one, which one do you want to use
[15:46] <apw> are you keeping our mirror up to date anyhow?
[15:48] <smb> apw, Sort of automatically as I use it to transfer to local builders to test builds. I had been a bit more lax with the tag, but I guess I will use it as a real mirror now
[15:48] <smb> Otherwise: git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git
[15:54] <apw> smb, ok will leave it pointing at your ubuntu one for nwo
[16:01] <ogasawara> ##
[16:01] <ogasawara> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:01] <ogasawara> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[16:01] <ogasawara> ##
[16:55] <ogasawara> ##
[16:55] <ogasawara> ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting
[16:55] <ogasawara> ##
[20:02] <apw> ogasawara, ok i've redone the configuration review and dumped a slew of new inconsistant items on your plate :)
[20:02] <ogasawara> apw: ack
[20:02] <apw> ogasawara, did we add doing a re-review at rally to the work items ?
[20:03] <tgardner> ogasawara, I was sure ther would be a few. it was kind of mind numbing with all the new options
[20:03] <ogasawara> apw: yep, and I thought you added it to the agenda already
[20:03] <apw> tgardner, yeah epecially as you see them all 20 times
[20:03] <apw> ogasawara, will check and confirm
[20:04] <apw> ogasawara, yep its there good
[20:04] <ogasawara> tgardner: how's the sprint going?
[20:04]  * ogasawara rebases precise to 3.2-rc2
[20:05] <tgardner> ogasawara, neck deep in server configuration....
[20:10] <apw> ogasawara, I assume there is no patches for the 3.1.0 -> 3.1.1 stuff
[20:10] <ogasawara> apw: which stuff?
[20:10] <apw> Replace compat-wireless 3.1.0 with 3.1.1
[20:11] <apw> that stuff, i assume your thread is not meant to contains patches for the code itself
[20:11] <ogasawara> apw: not exactly, it just dumps the 3.1.1 tarball over the 3.1.0 bits
[20:13] <apw> ogasawara, what are we naming the meta packages nwo
[20:14] <apw> i was sort of expecting the relase to be 3.1 in the meta package, pointing to 3.1.x whatever it is called in the lbm package
[20:14] <ogasawara> apw: for oneiric it's linux-backports-modules-cw-3.1.1-oneiric-<flavor>
[20:14] <ogasawara> apw: I suppose we could make it just be 3.1
[20:15] <apw> we use 2.6.38 presumably for the meta package in previous releases yes?
[20:15] <apw> ie it points to the base version?  then i think the new ones should be 3.0 3.1 etc as they are meant to upgrade
[20:16] <ogasawara> apw: yep, in lucid for we used 3.0.0, so I followed suit and used 3.1.1
[20:17] <apw> well 3.0.0, and 3.1.0 (where the 0 is always 0) might also make sense as it matches our kernel naming
[20:17] <apw> but the .1 is like patch releases right?  if so then we don't want that bit to change in the meta package name
[20:17] <apw> so either not there, or zapped to 0, so we get upgrades
[20:19] <ogasawara> apw: yah, I think I like the 2 digit convention
[20:19] <ogasawara> apw: eg just 3.1
[20:20] <apw> ogasawara, yeah
[20:20] <ogasawara> apw: I'll send a revised patch to the list
[20:20] <mdeslaur> tgardner: who do I need to ping for SRU regressions?
[20:22] <tgardner> mdeslaur, start with the stable team
[20:22] <mdeslaur> who is on the stable team?
[20:23] <apw> mdeslaur, bjf and herton in the first instance
[20:24] <mdeslaur> apw: thanks!
[20:24] <apw> mdeslaur, fileing a bug against the version with regresion-proposed or regression-updates would get their attention too
[20:24] <apw> what you found, anything fun ?
[20:26] <EtienneG> trying to test the latest natty kernel in natty-proposed, but it seems like linux-image-2.6.38-13-generic is not in the archive.  Is it still building?
[20:26] <mdeslaur> apw: there's already a bug open (#875300)...we broke sound on mini 9's running lucid...and now, a bunch of friends have started pestering me :P
[20:26] <mdeslaur> apw: never _ever_ recommend machines to friends :P
[20:26] <apw> EtienneG, shouldn't work that way as things are copied in as a chunk
[20:27] <apw> EtienneG, which flavour are you having issues with 
[20:27] <EtienneG> apw, -generic, amd64
[20:27] <EtienneG> apw, it shows on https://launchpad.net/ubuntu/natty/amd64/linux-image-2.6.38-13-generic/2.6.38-13.52, but it not apt-getable from us.a.u.c or archive.u.c directly
[20:28] <EtienneG> also, linux-image-generic do depend on linux-image-2.6.38-13-generic, but it is not there ...
[20:28] <EtienneG> I am perplexed
[20:29] <EtienneG> might just be me doing something wrong
[20:30] <apw> EtienneG, they appear to be in universe
[20:31]  * apw investigates
[20:31] <EtienneG> ah!
[20:31] <EtienneG> weird, but he
[20:32] <tgardner> EtienneG, an inexperienced archive admin likely forgot the overrides (again)
[20:32] <apw> tgardner, looks like it yep
[20:32]  * apw starts poking on #ubuntu-devel
[20:32] <EtienneG> tgardner, I am shocked! is there such a thing as an "inexperienced archive admin"?  :)
[20:32]  * apw wishes it was not so
[20:33] <apw> though the kernel copies is meant to be scripted so in thory that could be part of the scirpting
[20:33] <apw> EtienneG, adding universe temp should let you get testing
[20:33] <EtienneG> anyway, that was it.  my sources.list entry for natty-proposed only had main and restricted
[20:33] <EtienneG> so there
[20:34] <EtienneG> thanks for the pointer, as long as I can it, I am happy
[20:34] <EtienneG> I guess it will be fixed in time
[20:36] <apw> yep, will poke that aa's to get it resolved
[20:36] <apw> looking likely will be tommorrow now
[21:04] <apw> ogasawara, under the new rougime wherein the archive is meant to work all the time, i wonder if we should upload a semi-official kernel to the kernelppa or something so we can get some testing on it before unleashing it on the unsuspecting public
[21:04] <ogasawara> apw: sounds reasonable
[21:05] <apw> of course that assumes we have PPAs
[21:05] <ogasawara> apw: I know there are still some powerpc build failures that I need to fix us (assuming they're not fixed with -rc2)
[21:06] <apw> ogasawara, ok :)  let me know if i can help, else i'll keep grinding on the configuration check tommorrow
[21:06]  * apw drifts away
[21:07] <ogasawara> apw: ack, I'm gonna kick off test builds and see what's still breaking.  Likely won't get to fixing them up till tomorrow since I drop off here in a bit.
[21:07] <apw> ogasawara, sounds like a plan to me, now where is that beer
[22:01] <ogra_> apw, you might find this thread intresting https://lists.ubuntu.com/archives/ubuntu-users/2011-November/254160.html
[22:02] <ogra_> (looks like overlayfs /cow contents dont go into swap)
[22:08] <apw> ogra_, could be