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