[06:08] <lifeboy> Hi all!
[06:08] <lifeboy> Is there a channel log somewhere to go read?
[10:07] <apw> tseliot, hey ... have you done any testing with 3.2 kernels as yet, for binary drivers
[10:08] <apw> lifeboy, yes there are, something like irclogs.ubuntu.com
[10:08] <tseliot> apw: no, not yet. Is 3.2 in precise or is it just in the mainline ppa?
[10:09] <apw> tseliot, we're working up to uploading it, but i am worried about nvidia particularly for design peeps
[10:09] <apw> tseliot, if i put a kernel in a PPA somewhere would that help
[10:09]  * apw notes that kano was just complaining it works on mainline and not our kernel
[10:09] <tseliot> apw: yes, definitely, I'll see if I can patch it
[10:10] <apw> tseliot, ok so i'll get you a kernel
[10:10] <tseliot> apw: thansk
[10:10] <tseliot> *thanks
[10:10] <apw> tseliot, are raw .debs ok?  that i can get you in much less time
[10:11] <tseliot> apw: sure, as long as they are for amd64 ;)
[10:36] <apw> anyone else having trouble with LP waiting on fonts.googleapis.com ?
[10:39] <apw> tseliot, these are built from the tip of our tree: http://people.canonical.com/~apw/master-next-precise/
[10:40] <tseliot> apw: excellent, thanks
[10:40] <apw> tseliot, thank you for looki
[10:40] <apw> looking at it
[11:18] <ppisati> wasn't there a script to check if a release was closed properly?
[11:19] <apw> ppisati, yep, erm ...
[11:19] <apw> ppisati, stable/verify-src-package perhaps ?
[11:19] <ppisati> let me try
[11:19] <apw> i'd guess its meant to be against the source package though
[11:19] <ppisati> uhm no
[11:20] <ppisati> wait
[11:20] <ppisati> i use that against the topic branches
[11:20] <ppisati> perhaps it works in this case too
[11:20] <ppisati> no wait
[11:20] <apw> the rules should be the same
[11:20] <ppisati> in the topic branches case i use the
[11:20] <ppisati> kteam-tools/maintscripts/verify-release-ready
[11:21] <ppisati> and in fact the release wasn't closed properly...
[11:21] <ppisati> ok
[11:21] <apw> cool
[11:21] <apw> odd that its not in the same place ... sigh
[11:22] <ppisati> btw stable/verify-src-package seems a complete different tool
[11:23] <apw> joy
[13:41] <apw> herton, just remembered, while you weer away a number of kernels ended up in universe.  not sure if they all got fixed correctly, may be worth checking
[13:42] <ogra_> they are universal kernels !
[13:42] <ogra_> :)
[13:42] <herton> apw: yep, I noted some of those, and reported the problem on the tracking bugs, mostly all arm kernels ended up in universe
[13:43] <ogra_> just ping an archive admin ... thats faster
[13:43] <apw> herton, well all the otehre i think as well, i had everything moved for the master branches for everything back to lucid, i ma unsure if hardy got done or not, it was late
[13:44] <apw> and hardy is more complex
[13:44] <herton> ogra_: I usually do, but it's usually a recurrent issue, I don't know how the copy is done and why it happens
[13:45] <ogra_> there is a command the admin runs, sometimes they miss the right option then the kernel goes to universe
[13:45] <herton> apw: ah yes, for the master branches I looked I think on wednesday/yesterday and seems fine now
[13:45] <ogra_> usually an oversight 
[13:45] <ogra_> and quick to fix 
[13:45] <tseliot> apw: can you reupload this file, please? http://people.canonical.com/~apw/master-next-precise/linux-headers-3.2.0-2_3.2.0-2.4~masternext201111180933_all.deb
[13:46] <apw> tseliot, reupload it?  s is missing?
[13:47] <tseliot> apw: or one which ends with 80936
[13:48] <herton> apw: for hardy I think it didn't work, checking now it's still on universe (http://archive.ubuntu.com/ubuntu/pool/universe/l/linux/)
[13:48] <apw> herton, i think hardy got missed as some do belong there and some not and steve wasn't sure
[13:48] <tseliot> apw: I'm getting "short read on buffer copy for failed to write to pipe in copy"
[13:48] <apw> herton, probabally should re-refer that one to pitti
[13:49] <herton> ok
[13:49] <tseliot> (also the file is 688kb)
[13:49] <apw> tseliot, on it
[13:49] <tseliot> thanks
[13:51] <seanius> is there something extra that needs to be done to enable the linux-crashdump support?  i.e. do i need to tweak anything OOTB?  the Kernel/CrashDumpRecipe page doesn't seem to imply i
[13:53] <apw> seanius, i thought it was something that needed enabling in /etc/default/somethng
[13:53] <apw> other than that i think its meant to be automatic
[13:54] <seanius> apw: yeah, i found /e/d/kexec in which kexec wasn't enabled
[13:54] <seanius> which is what i was wondering about actually
[13:55]  * apw isn't a crahsdump expert unfortuanatly, though i am asking abuot
[13:55] <seanius> and *no*, this doesn't have aything to do with that custom kernel stuff i was asking about earlier :)
[13:55] <apw> tseliot, ok there now should be a new one in there ... well in about 2:30
[13:56] <seanius> what i really want is osmething like redhat's netdump support, but i don't think that exists in debian/ubuntu
[13:56] <seanius> i.e. on crash scp /proc/kcore to a remote server, and reboot
[13:57] <apw> thats a pretty nifty idea maybe you could file a bug suggesting it
[13:57] <apw> it doesn't sound like so very hard
[13:57] <seanius> heh, they were saying the same thing in #debian-devel
[13:58] <apw> yep, we are small compared to redhat so we have less effort to focus
[13:58] <seanius> could probably be done with the existing stuff and an extra initramfs hook
[13:58] <apw> so we don't always see the obvious
[13:58] <apw> i'd have thought so indeed
[13:59] <apw> tseliot, there now
[14:00]  * cking reboots
[14:05] <seanius> hrm, panic seems to still panic, and i get no files in /var/crash
[14:09] <seanius> is there any way to test the crash kernel without triggering a panic?
[14:13] <tseliot> apw: ok, thanks
[14:16] <apw> seanius, not that i know of
[14:16] <apw> seanius, mostly people do that via sysrq
[14:18] <seanius> apw: yes i can do that but it's not loading the crash kernel, hence my wondering.  kexec -p.... seems to work
[14:18] <seanius> but i get nothing beyond that
[14:18] <apw> what happens?  just normal boot ?
[14:18] <seanius> that's just the "prepare" step afaict
[14:18] <apw> when you ask it to start
[14:19] <apw> you must be able to trigger it like you can a normal boot
[14:19] <apw> when kexec is installed reboot uses it, i'd have thought -p and whatever it uses to trigger the start might work
[14:25] <ogasawara> bug 888597
[14:25] <ubot2> Launchpad bug 888597 in linux "linux-image-extra-3.1.0-2-virtual is uninstallable" [High,Confirmed] https://launchpad.net/bugs/888597
[14:26] <ogasawara> apw, tgardner, smb`: so there are test debs for 3.2.0-1.1 on gomeisa in precies-amd64 and precise-i386 in my home dir, but I'm gonna try and fix up 888597 and then respin tests
[14:28] <apw> ogasawara, ok will wait on that
[14:28] <apw> ogasawara, i have just been talking to tseliot about checking the nvidia binary drivers
[14:28] <apw> ogasawara, as that will affect a lot of design people if it doesn't work
[14:29] <apw> ogasawara, we may want to wait till he reports back before uploading
[14:29] <ogasawara> apw: ack.  also because we've merged server into generic, I also wanted to pick your brain about the best approach for fixing up linux-meta in terms of the control.d files
[14:29] <apw> ogasawara, ok so is it just called generic now ?
[14:29] <ogasawara> apw: yep
[14:30] <apw> ogasawara, wil have a poke in a bit and see whats what
[14:30] <ogasawara> apw: awesome thanks
[14:30] <ogra_> why do you keep the -generic tag at all ?
[14:30] <ogra_> if we only have one kernel that feels somehow redundant
[14:31] <apw> we still ahve two, generci and virtual
[14:31] <ogra_> ah
[14:31] <apw> and getting rid of it to add it back when someone makes a new one is confusing too
[14:31] <ogra_> indeed
[14:31] <tseliot> apw: the latest driver in precise seems to work well with linux 3.2 (at least with the one you gave me)
[14:32] <apw> tseliot, nvidia binary drivers yes ?
[14:32] <tseliot> apw: yep
[14:32] <apw> tseliot, would you be interested in testing fgrlx ?
[14:33] <tseliot> apw: sure, even though I'm going to update them, either today or next week
[14:33] <apw> will give us some confidence in the viability of our new kernel at least
[14:35] <tseliot> apw: I can already tell you that the fglrx module builds, I only have to see if it segfaults ;)
[14:35] <apw> tseliot, :) just bound to work
[14:38] <tseliot> :)
[14:49] <tgardner> ogasawara, I updated the precise chroots on gomeisa
[14:49] <ogasawara> tgardner: ack
[15:05]  * herton -> lunch
[15:19]  * ogasawara back in 20
[16:07] <apw> ogasawara, http://status.ubuntu.com/ubuntu-precise/group/topic-precise-kernel-essential.html <-- should represent the release critical blueprints
[16:07] <ogasawara> apw: awesome, did that just recently appear?
[16:08] <apw> i made it about 5 hours ago yep, and its finally in the output :)
[16:09] <tgardner> ogasawara, 3.2.0-2-generic - at least suspend now works again on my HP mini
[16:11] <tseliot> apw: fglrx works well too :)
[16:11] <apw> ogasawara, ^^ so i think thats both binary drivers tested :)
[16:12] <ogasawara> apw: cool.  do you want me to pull in that last config change you pushed to master-next before I upload
[16:12] <ogasawara> apw: I think I might wait till we have the linux-meta bits sorted as well
[16:15] <apw> ogasawara, the config changes i am pushing are not urgent or important
[16:15] <ogasawara> apw: k, I'll leave it for the next one then since I've already prepped the master branch
[16:16] <apw> yeah will look at that next, i suspect we want to keep the seaparation at the meta package level, so not a tranisitional package
[16:16] <apw> should be pretty easy in theory, though we don't need it till the builds are complete anyhow
[16:16] <ogasawara> apw: yah, I was hoping to keep it separate in case we do want to fall back to having a server flavor
[16:17] <apw> ogasawara, how much testing have we had on those builds of your?  you were updating them last i looked and haven't seen if new ones are there
[16:17] <ogasawara> apw: I kicked of the new builds, not sure if they've finished yet
[16:18] <ogasawara> apw: been sidetracked with the release meeting
[16:19] <apw> yep no worries
[16:24] <tgardner> pgraner, tangerine.buildd:~rtg/ukb/oneiric/amd64/master-next/linux-image-3.0.0-14-generic_3.0.0-14.23_amd64.deb
[16:39] <apw> ogasawara, i have just pushed an update to ubuntu-precise-meta which i think is what we want
[16:41] <apw> ogasawara, obviously it still needs a version bump as and when
[16:43] <apw> cking, are you aware of this page: http://status.ubuntu.com/ubuntu-precise/u/colin-king.html
[16:44] <apw> cking, that has all your WIs regardless of blueprint, i note you have some duplicates by the look of it
[16:45] <ppisati> i'm trying to package a new omap4 kernel for O, but can't get the debian* stuff right i.e. fdr printchanges is always empty
[16:45] <ppisati> can anyone give it a look?
[16:45] <ppisati> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=shortlog;h=refs/heads/ti-omap4
[16:45] <cking> apw, ah, duplication, hrm, well I was unsure if the power management was a general placeholder for all things related to this kind of work
[16:45] <ppisati> (btw i bumped abi to 1400 to distinguish it from O/omap4 kernels)
[16:45] <apw> ppisati, if the previous version differs in the changelog then it won't find it
[16:46] <apw> ppisati, and you just have to do the changelog bits by hand, common on the first upload for a release
[16:46] <ppisati> apw: i think i did it
[16:46] <apw> you can see how its done in the debian/rules.d
[16:46] <ppisati> i can even build the first pkg
[16:46] <apw> fdr printenv gives you hints if its not recognising the previous version
[16:46] <ppisati> but now i would like to add some stuff on top of it
[16:47] <apw> ?
[16:47] <ppisati> but fdr printenv insist in using the OLD abi (1206)
[16:47]  * apw pulls
[16:47] <ppisati> and fdr printchanges is still empty
[16:47] <ogasawara> apw: awesome, thanks
[16:48] <ogasawara> apw: also test builds on gomeisa finished, feel free to pull the debs and test on any kit you have there
[16:51] <apw> ppisati, do there are no new commits on here after the close ?
[16:51] <ppisati> apw: nope
[16:51] <ppisati> locally, didn't push them
[16:51] <ppisati> wait
[16:52] <ppisati> apw: pushed
[16:57] <apw> ppisati, so if you want to make a .2 you need to open that with fdr startnewrelease, if you want to replace .1 then you need to rebase the .1 close commit out of existance
[16:58] <ppisati> apw: why shall i obliterate the .1 close commit?
[16:58] <apw> ppisati, which are you trying to do make a new .1 or move on to .2
[16:58] <ppisati> move to .2
[16:58] <apw> then you should be ading a startnewrelease
[16:59] <apw> fdr startnewrelease, then commit that
[16:59] <ppisati> ok
[16:59] <apw> then you can close it to make .2
[16:59] <ppisati> start new release add the boilerplate in debian.ti-omap4/changelog
[16:59] <ppisati> but i don't understand why fdk printchanges doesn't show anything
[17:00] <ppisati> ...
[17:00] <ppisati> never mind
[17:00] <ppisati> printchanges work only AFTER a new release has been opened...
[17:00] <ppisati> "a storm in a changelog..."
[17:05] <cking> power measuring gets a little repetatititititive after a while
[17:08] <apw> ppisati, indeed so
[17:34] <apw> cking, yep that why you need a program to do it
[17:49] <cking> apw, true, but somebody has to install software, run the test, gather the data for different tests...
[17:51] <ppisati> herton: how does ktl.ubuntu.series_name() knows if a version is in one release or in another one? does it use hardcoded values?
[17:53] <herton> ppisati: yes, it checks the version/abi or the package name if necessary, and do the specific checks if needed (verifying abi number for ex.)
[17:54] <herton> ppisati: eg. if it's linux-mvl-dove, it just checks abi and returns lucid or maverick
[17:54] <ppisati> herton: ok
[17:56] <ppisati> apw: one last thing, if you are still alive
[17:57] <ppisati> apw: now it complains about "package linux-image-3.0.0-1401-omap4 is not in control info"
[17:57] <ppisati> apw: http://paste.ubuntu.com/742485/
[17:58] <ppisati> apw: and here is the pkg: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=shortlog;h=refs/heads/ti-omap4
[18:04] <EtienneG> Beginner's question, guy's: the pae flag in /proc/cpuinfo, that means the CPU supports PAE, right?
[18:04] <EtienneG> (I guess so, just want to be sure)
[18:11] <jjohansen> EtienneG: yes if pae is listed then the processor should support PAE
[18:11] <EtienneG> jjohansen, thanks!
[18:12] <EtienneG> reason I asked is the discussion about dropping non-PAE kernel or not in precise.  Not sure if a final decision was made, but I want to be ready in case it is
[18:12] <apw> ppisati, have you cleaned it properly
[18:12] <EtienneG> by making an inventory of the machines that will be non-upgradable
[18:13] <ppisati> apw: i think so
[18:13] <ppisati> apw: let me try with a git clean -fdx
[18:13] <apw> ppisati, have a look at the control.stub.in and make sure the base version is updated correctly
[18:14] <ppisati> apw: ok, i'll do
[18:15] <apw> ppisati, and check control afer a clean
[18:20] <mfilipe> will Oneiric Kernel be update to 3.2?
[18:20] <apw> mfilipe, no it will remain on 3.0
[18:22] <mfilipe> apw, will be released any package to update the kernel to 3.2?
[18:23] <jjohansen> mfilipe: probably not, there will be the backports kernels from the next releases Q, R, S but Q likely will be on of 3.3, 3.4, 3.5
[18:24] <jjohansen> just depending on when the upstream kernels come out
[18:24] <mfilipe> hum... 3.2 will have many improvements in energy management 
[18:25] <mfilipe> anyway, I compile it if be necessary 
[18:25] <ppisati> mfilipe: why don't you simply install precise kernel?
[18:25] <mfilipe> jjohansen, apw: thanks for informations
[18:25] <mfilipe> ppisati, precise kernel?
[18:26] <ppisati> it's 3.2 based
[18:27] <jjohansen> mfilipe: oh shoot you where talking Oneiric, and here I was thinking precise, there will be no backports for Oneiric, the are for precise
[18:28] <mfilipe> http://packages.ubuntu.com/precise/kernel-image-3.1.0-2-generic-pae-di
[18:28] <mfilipe> it is 3.1
[18:29] <jjohansen> ppisati: err no its not
[18:29] <mfilipe> when torvalds tree tagged 3.2 final release, will you update to 3.2?
[18:30] <ppisati> jjohansen: well, not yet... :)
[18:31] <jjohansen> right
[18:32] <jjohansen> mfilipe: yeah we should move to 3.2, its 3.3 that will be skipped (/me was remembering the wrong revision)
[18:32] <mfilipe> ok
[18:32] <mfilipe> thanks a lot!
[18:33] <ogasawara> mfilipe: I'm getting ready to upload the first 3.2 based precise kernel in just a bit
[18:34] <jjohansen> ogasawara: oh really without binary drivers?
[18:35] <ogasawara> jjohansen: was told that tseliot tested both nvidia and fglrx this morning on the 3.2 kernel
[18:35] <jjohansen> ogasawara: ah, I hadn't heard that and was expecting those to be a pita
[18:36] <mfilipe> ogasawara, but 3.2 stay like release candidate yet 
[18:36] <mfilipe> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
[18:36] <ogasawara> mfilipe: yep, we rebased to the latest 3.2-rc2
[18:36] <ogasawara> mfilipe: we'll keep rebasing until 3.2 is final
[18:38] <mfilipe> ok, nice
[18:42] <apw> yeah unexpectedly they still work (the binary drivers)
[19:01] <ricotz> the vbox dkms module will break though
[19:07] <apw> ricotz, maybe so, they will need to sort it out 
[19:08] <ricotz> apw, yeah, 4.1.6 should be compatible which is already in debian
[19:08] <apw> ricotz, then it should get synced in the mass sync with luck
[19:08] <ricotz> apw, it is still in testing so it wont :\
[19:09] <ricotz> a manual sync would be nice here though
[19:09] <ricotz> oh meant "unstable"
[19:53] <GrueMaster> ppisati: I am seeing several missing CVE issues with the omap4 kernel on maverick (2.6.35).  I'll add them to the kernel release tracking bug.
[20:05] <herton> GrueMaster: what CVEs are missing?
[20:06] <GrueMaster> LP #729839 is one.  I have 7 failures, some are CONFIG_ features that are not enabled.
[20:06] <ubot2> Launchpad bug 729839 in linux "PR_SET_PTRACER does not work from a thread" [High,Fix released] https://launchpad.net/bugs/729839
[20:07] <GrueMaster> I added a log to bug 888569
[20:07] <ubot2> Launchpad bug 888569 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.35-903.27 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/888569
[20:18] <GrueMaster> test-kernel log now added as well.
[20:21] <sforshee> ogasawara, do you have a 3.2-rc2 precise build somewhere that I can get at easily?
[20:22] <ogasawara> sforshee: yep, check on gomeisa in my home dir under the precise-amd64 or precise-i386 dirs
[20:22] <sforshee> ogasawara, thanks, now I don't have to wait for a build :)
[20:26]  * herton -> eow
[20:33] <arges> sforshee, who would be the wifi guru to talk to , just was able to reproduce https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/836250
[20:33] <ubot2> Launchpad bug 836250 in network-manager "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [High,Invalid]
[20:38] <sforshee> arges, the bug is assigned to tgardner and he's the most knowledgeable about wireless anyway, but he's not around right now
[20:38] <arges> ah, yea I just got hit with it when I tried a new router
[20:39] <sforshee> arges, you should probably grab dmesg and syslog while you're seeing the symptoms as a starting point
[20:40] <arges> Yea, there seems to be quite a bit of info in the bug... so trying to determine if I won't just be adding a 'me too' case to it
[20:40] <sforshee> arges, also you might look at http://linuxwireless.org/en/users/Documentation/Reporting_bugs for some things you might want to try
[20:42] <sforshee> although it seems most of the stuff there is geared towards problems associating, not performance problems
[20:42] <arges> Cool. I might add some info. One thing was looking at iwlist/iwconfig etc its not obvious which wireless 'mode' i'm connected to 802.11a/g/n etc
[20:43] <arges> so I was trying to just figure out how to switch modes from my laptop to isolate it being an 'n' issue vs 'b/g' which is what I've been seeing switching the modes on the router side.
[20:43] <arges> the workaround in the bug seems to agree since it just involves disabling n mode on the laptop. 
[20:44] <arges> by disabling it in the module
[20:45] <sforshee> arges, if you look at the bit rate in iwconfig you can probably guess at which mode it is
[20:45] <sforshee> i don't know a definitive way to tell though
[20:45] <arges> yea that's what I was figuring
[20:45] <arges> ok
[20:45] <sforshee> there's probably a better way to tell, i just don't know what it is
[21:27] <Sarvatt> no more brcmsmac driver in 3.2.0-1?
[21:27] <mjg59> It moved from staging. The config may not have been updated.
[21:40] <arges> sforshee, so I installed ogasawara's 3.2-rc2 kernel in my system using dpkg -i and its not showing up in grub, do I need to do something special to get that entry made? It looks like it was doing the hooks for the grub update
[21:41] <sforshee> arges, update-grub should be run as part of the installation, but I guess you could try running it manually just to be sure
[21:43] <sforshee> arges, also run 'dpkg --get-selections | grep ^linux' and make sure the packages really are installed
[21:48] <arges> sforshee, yea checked if it was installed first nad it is... will re-run update-grub
[21:49] <arges> trying again...
[21:58] <sforshee> ogasawara, did you see the above comments about brcmsmac?
[23:49] <ogasawara> Sarvatt, sforshee: thanks, have added an item to our config blueprint for brcmsmac.  will look into it on Monday.