=== smb` is now known as smb
[07:06]  * smb mornings
[07:35] <ppisati> moin
[07:40] <cooloney> ppisati: moin,
[07:46] <smb> ppisati, cooloney morning guys
[07:46] <smb> (or whatever time)
[07:47] <cooloney> smb: hey, man
[12:21] <tgardner> apw, so, are you reworking 'UBUNTU: [Config] linux-image-extras needs full postinst' ?
[12:22] <apw> tgardner, yep, have it here, forgot to send it out :/
[13:43] <tgardner> apw, http://tech.surveypoint.com/make-grub2-boot-the-last-operating-system-you-used.html
[13:45] <apw> tgardner, thats not quite the same ... hmm
[13:45] <tgardner> apw, not quite, but there are some clues there
[13:49] <apw> tgardner, i am sure its a doable indeed.
[14:17] <apw> ogasawara, ok i've enhanced the config checker so it basically has teh same predicate language for configuration settings ... i've made a preliminary alpha1 review page for comparison: https://wiki.ubuntu.com/KernelTeam/Specs/QKernelConfigReview/Alpha1
[14:18] <ogasawara> apw: thanks, /me will review
[14:18] <ppisati> apw: can you send the script used to generate the matrix?
[14:18] <ppisati> *send me
[14:19] <apw> ppisati, its all in kteam tools, you need the before release and after release git repos, both checked out at the branch tip you want to compare
[14:19] <ppisati> apw: ack, what's the name of the script?
[14:19] <apw> then you do like .../kteam-tools/devel/devel-config-summary ubuntu-precise ubuntu-quantal >SUMMARY
[14:20] <apw> ppisati, but let me push the latest
[14:20] <apw> ppisati, ok pushed
[14:20] <ppisati> apw: so in my case, to do a comparison between master and omap4 branchesi need two dirs with Q/master and Q/omap4, right?
[14:20] <apw> ppisati, to compare a non-standard branch with a standard b
[14:21] <apw> branch, you can checkout the say ti-omap4 at the tip you want, and then fdr genconfigs, then checkout master-next again and regenerate
[14:21] <apw> and you will get the configs mixed together
[14:21] <ppisati> uhm, ok
[14:21] <ppisati> let me try
[14:34] <hallyn> So I've got this lenovo s10-3.  since start of maverick, it hasn't resumed from suspend, and Len Brown basically threw his hands in the air saying the bios is doing something wrong.  Now, as of a few weeks ago, the precise kernel seems to leave the wireless NIC in a bad state (broadcom) iwth phy0 rfkill hard off
[14:35] <hallyn> i have to boot into lucid, suspend, resume, and then it's back up (until i boot precise)
[14:35] <hallyn> anyone heard of such a thing?
[14:35] <hallyn> i'm about to resign myself to running lucid on it... (or holding down paper with it)
[14:37] <tgardner> cking, didn't you work on this one ^^
[14:37] <cking> tgardner, I can't recall any fix I worked on for that machine
[14:37] <apw> ppisati, success ??
[14:37] <tgardner> cking, the s10 sounds like a model the hwe worked on.
[14:38] <apw> vanhoof, ^^
[14:40] <cking> bah, laptop just died
[14:40] <apw> cking, you need to fix that
[14:40] <cking> apw, it's called get a new one
[14:47] <cking> apw, henrix, shall I check for flights for the sprint then?
[14:47] <henrix> cking: hmm... actually, not sure yet as i may be flying from lisbon
[14:48] <cking> henrix, ack
[14:48] <henrix> cking: anyway, i'll let you know later today (or most probably tomorrow)
[14:48] <henrix> cking: and thanks for asking
[14:52] <cking> hallyn, I've see another S10-3 which only  suspend/resume on worked on natty
[14:52] <apw> cking, yeah i may want to go out earlier will find out tonight
[14:52] <hallyn> cking: for awhile in maverick/natty you could make suspend/resume work (not 100% reliably) by not using intel_idle.  but that stopped.
[14:53] <hallyn> still, not resuming was a pain but not a showstopper.  no wireless is more of a showstopper.
[14:53] <cking> hallyn,  apparently using kernel parameter "nohpet" seemed to have helped that particular user
[14:53] <hallyn> i just don't understand why suspend/resume unblocks wireless
[14:53] <hallyn> right.  nohpet never worked for me, but i've seen that.
[14:53] <apw> hallyn, bios is run during those two
[14:53] <hallyn> why isn't bios run during boot?  :)
[14:54] <apw> hallyn, literally _anything_ can happen
[14:54] <hallyn> oh, the kernel driver must muck it up?
[14:54] <apw> hallyn, some bits of it are, but who knows if its working right
[14:54] <apw> hallyn, likely the kernle is doing what the bios asks, and that is not working
[14:54] <cking> you did say it was broadcom wireless- I suspect that's the binary blob wl driver 
[14:55] <apw> hallyn, which chipset is it?  perhaps brcmsmac will work better for you
[14:55] <hallyn> cking: i could try blacklisting that (thought about it( but the brcmsmac driver hangs my laptop completely
[14:55] <hallyn> interesting!
[14:55] <hallyn> in lucid it reports a different model # :)  Broadcom Corporation Device 4727 (rev 01)
[14:56] <hallyn> pretty sure in precise kernel it said 43xx (not sure what the xx were )
[14:56] <hallyn> i'm upgrading the precise partition under chroot right now, hoping for a hail mary
[14:57] <apw> hallyn, that prolly means its a pciid 4727 and lucid doesn't know it
[14:57] <tgardner> hallyn, have you tried the Q kernel ? sforshee has done good stuff for brcmsmac. https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
[14:59]  * cking notes it could be a collection of issues, wifi, firmware, etc, so teasing it out with a Q kernel may be a good starting place
[15:00] <hallyn> ok, i'll try the q kernel (if i can successfully upgrade under chroot)
[15:00] <hallyn> thanks
[15:01] <cking> hallyn, if you are feeling adventurous and can bear to download 650M of .ddeb, you can also try: https://wiki.ubuntu.com/Kernel/Reference/S3SystemTapDebug
[15:04] <ppisati> apw: cut&pasting all the config diff is such a PITA...
[15:04] <apw> ?
[15:04] <apw> ppisati, from where to where ?
[15:06] <hallyn> cking: probably worth it, will try, once wifi is up
[15:08] <ppisati> apw: after config generation into a wiki page
[15:08] <apw> ppisati, editmoin ?
[15:08] <ppisati> apw: do you have any smarter way to get the data there?
[15:08] <ppisati> apw: never used
[15:08] <apw> thats the smarter way 
[15:09]  * ogasawara back in 20
[15:16] <apw> ogasawara, where are we with alpha1 kernel, i am doing some config review goop, and wondering if you'd want that in or out of a1
[15:21] <tgardner> apw, I've been pushing config review related changes
[15:23] <apw> tgardner, ok ta
[15:29] <ogasawara> apw: push it, I'm gonna upload our Alpha-1 kernel first thing Monday
[15:29] <apw> ogasawara, will do, a _few_ more do to sign
[15:29] <apw> sigh
[15:47] <apw> smb, CONFIG_XEN_ACPI_PROCESSOR ... any idea why that is on for amd64 and off i386
[15:47] <smb> apw, I think it was changed because we don't really support a dom0 on i386
[15:48] <smb> hrmpf
[15:49] <smb> which was true last release at least but I just did apt-cache search...
[15:50] <tgardner> apw, smb: I don't think we want to support an i386 dom0
[15:51] <hallyn> cking: well i've got deb http://ppa.launchpad.net/ubuntu-x-swat/q-lts-backport/ubuntu precise main, but i'm not getting the kernel from that
[15:52] <apw> hallyn, you'd have to opt in ... tgardner whats todays meta packag for the lts kernel ?
[15:52] <hallyn> d'oh
[15:53] <tgardner> hallyn, apw: one of the packages in  linux-meta-lts-backport-quantal
[15:53] <tgardner> linux-image-generic-lts-backport-quantal
[15:53] <hallyn> thanks.  i'd tried just 'linux-lts-backport-quantal' but tha didn't help
[15:54] <tgardner> hallyn, it didn't help because its not a package ?
[15:55] <tgardner> hallyn, p.s. the name of the meta package is going to change. rick doesn't like 'backport' in the name
[15:55] <hallyn> right i guess it's the source pkg name?  anyway i'm now tethered over my phone to wifi so have a wider pipe. installing, thanks :)
[15:56] <tgardner> hallyn, do you normally live at the end of a 19K baud serial line ?
[15:57] <hallyn> how i wish for 19K!  300, acoustically coupled
[15:57] <tgardner> what a dinosaur
[15:57] <smb> tgardner, apw Somehow I would think at least the options should be right if there is a i386 hypervisor around. Which I thought was not but seem to be wrong
[15:57] <hallyn> all right not really.
[15:58] <tgardner> smb, -ENOPARSE, huh?
[15:58] <apw> tgardner, he is saying even if we don't support it its there and the options should be right in it
[15:59] <smb> *sigh* yeah, what he said
[15:59] <tgardner> apw, agreed. I just don't wanna support it regardless.
[16:01] <tgardner> some crazy outfit will bet their business on 32 bit dom0 using 10 year old Dell servers.
[16:01] <smb> zul, Can you refresh my memory why the xen source package is in main but the binaries seem all to be in universe...
[16:01] <zul> smb: the hypervisor?
[16:01] <smb> tgardner, There probably already are them doing it with kvm and openstack
[16:01] <smb> zul, that and the utils too
[16:01] <smb> zul, at least
[16:02] <zul> smb: because libxen is in main since its a dep for libvirt the rest isnt in main
[16:02] <tgardner> smb, perhaps, but we don't have to give them more ways to hang themselves.
[16:08] <smb> tgardner, if I am not just going mad (more than the usual) we already have the config in a way to enable it on i386 (at least precise)
[16:10] <tgardner> smb, I'm sure we do, but I want it dropped by the time 14.04 is released. no better time to cut those ties then right now.
[16:11] <hallyn> sigh, that didn't give me a nic at all.  fraid i need to put it aside for a bit.
[16:12] <tgardner> hallyn, wtf kind of nic do you have ?
[16:12] <smb> tgardner, apw I would not want to make that decision just factually. Right now a different setting for the acpi processor in quantal sure does not make sense with the other options being what they are
[16:12] <apw> smb, yeah i would say i'll harmonise them to stop the errors i am seeing
[16:12] <apw> and you can argue with server and get it gone
[16:12] <hallyn> tgardner: broadcom somesort
[16:13] <tgardner> hallyn, you're gonna have to get a dmesg before we can figure out whats happening
[16:13] <smb> apw, Right, if that makes sense. Just that this is sort of a new decision/new target.
[16:14] <hallyn> yeah, if i don't throw it out the window first, i'll open a bug with dmesg output and such next time i turn the thing on
[16:14] <hallyn> really would be nice to have it working, but since i still have no hope for resume anyway, it'll never be what it once was :)
[16:14] <apw> hallyn, if you are going to throw it out send it to sforshee
[16:15] <rtg_> smb, there is no CONFIG_XEN_ACPI_PROCESSOR in precise.
[16:16] <smb> rtg_, There should be. At least it is in what I got in master. And what I have been testing in -proposed
[16:17] <apw> ppisati, do omap boards have 8250 serial ?
[16:17] <hallyn> apw: is he building a beowulf cluster of netbooks?
[16:17] <apw> hallyn, no but he has a fine hammer
[16:17] <smb> rtg_, 15ca7f9c2a2dd8fdf263963c57504d0da6fbd84e
[16:18] <hallyn> apw: it's my best laptop to use in the car, so i'm all talk - would more likely pick up a $15 wireless-n usb stick
[16:20] <rtg_> smb, ok, it would help if I was looking at the _tip_ of master-next.
[16:20] <smb> rtg_, or tip of master now
[16:20] <apw> hallyn, i was thinking he could try and fix it, is easier with the device in your hand
[16:20] <smb> (its the change that is currently under verification)
[16:21]  * apw pokes ppisati
[16:21] <ppisati> apw: there's an omap serial config, dunno if it exploits 8250
[16:21] <ppisati> apw: let me check
[16:21] <rtg_> smb, so I don't understand your objection to dropping this in quantal 32 bit. 
[16:22] <smb> rtg_, The objection is that it does not make sense to drop that single bit from 32bit then
[16:22] <rtg_> smb, thats circular.
[16:23] <apw> rtg_, i think he means you have to turn off all of XEN host in 32bit or this option should be harmonised even if we offer no support
[16:23] <smb> rtg_, Not when it is set y in common config
[16:23] <smb> in precise
[16:24] <apw> ogasawara, do yo u have a list of options you dinged for build failures on arm back in the day ?
[16:24] <rtg_> apw, so what we _shold_ do for quantal is CONFIG_XEN_DOM0=n
[16:24] <smb> rtg_, But that is actually a new decision
[16:25] <ogasawara> apw: I'd have to grep the logs, just a sec.  I did give them all similar commit subjects so I could find them again.
[16:25] <rtg_> smb, so? we make new decisions about config options all the time.
[16:25] <smb> Which has not been discussed, asked for, yada, yada
[16:26] <ogasawara> apw: 1bd2e66f5ab6063b153e7638453d0bcf719f842f UBUNTU: [Config] Temporarily disable CONFIG_AX88796 on arm
[16:26] <ogasawara> df954481918bae6b7f93320b1be5fc0b6db42192 UBUNTU: [Config] Temporarily disable CONFIG_TI_CPSW on arm
[16:26] <ogasawara> be637dbbc9c3cf51f91efec7236bef1f054c4a2f UBUNTU: [Config] Temporarily disable CONFIG_USB_EHCI_HCD_PLATFORM on arm
[16:26] <ogasawara> 32e2f0b7eef1c46494ef4244646bccaa34d3b0e8 UBUNTU: [Config] Temporarily disable CONFIG_LIS3L02DQ on arm
[16:26] <ogasawara> 37962f948cb20ee7fc1def0a3a8bff40abddc524 UBUNTU: [Config] Temporarily disable CONFIG_MFD_OMAP_USB_HOST on arm
[16:26] <ogasawara> b1dad7778d5965bd81499ad7f44214453e5a94d6 UBUNTU: [Config] Temporarily disable CONFIG_EZX_PCAP on arm
[16:26] <ogasawara> 59e1b9557ddc329e6181891ef4716ec4f2c6e1b2 UBUNTU: [Config] Temporarily disable CONFIG_TOUCHSCREEN_EGALAX on arm
[16:26] <ogasawara> b45ba114bef30fbdd10c57309963f8774e8f01a9 UBUNTU: [Config] Temporarily disable CONFIG_TOUCHSCREEN_EETI on arm
[16:26] <apw> rtg_, that is cirtainly an option indeed.  for me i would just leave it on and docuemnt it unsupported ...
[16:26] <smb> rtg_, What I want to say is that we should bring this topic to next uds and then move forward and not just do it in q
[16:27] <apw> if we are going to change it, we should at least start a thread about it
[16:27] <smb> I guess at least that. Otherwise (or even with it) it ends up as the we drop non-pae
[16:28] <ppisati> apw: totally different stuff (omap_serial vs 8250)
[16:29] <ppisati> drivers/tty/serial/omap-serial.c
[16:29]  * smb goes off to have a pint of fermented apple juice...
[16:30] <apw> ppisati, ok so that doesn't need to be builtin for arm* then yes?  8250 serial drivers ?
[16:31] <ppisati> apw: nope
[16:31] <ppisati> apw: actually i'm talking about omap here
[16:31] <apw> ppisati, as am i, omap only
[16:31] <ppisati> apw: if you are doping another arm soc, it's a totally different thing
[16:31] <ppisati> ok
[16:31] <apw> omap3 only indeed
[16:31] <apw> master branch only
[16:31] <ppisati> ack
[16:32] <apw> ppisati, thanks
[16:35] <ogra_> do we have an equivalent to the linux-version tool from debian ? (from linux-base)
[16:35] <apw> ogra_, no but that one should be installable now after tgardner fixed it
[16:35] <apw> ogra_, as to whether it works ... is another question, if not poke me
[16:35] <ogra_> ah, great, seems the new flash-kernel uses it 
[16:36] <ogra_> yeah, i got f-k on my TODO for tomorrow to fix the rough edges
[16:36] <apw> ogra_, ok let me know, i need some u-space to play with
[16:36] <ogra_> k
[16:37] <hallyn> tgardner: http://paste.ubuntu.com/1015033/ has dmesg and lspci -v output fwiw (with q-backport kernel)
[16:37] <rtg_> ogra_, all I dropped from linux-base was /usr/bin/perf. /usr/bin/linux-version should still be intact.
[16:37] <apw> rtg_, my memory is it may need ubuntuisation, but ogra_ can test that, and if it does we can fix it
[16:38] <ogra_> rtg_, awesome 
[16:38] <ogra_> yeah, i will work through the bits and pieces tomorrow and let you guys know if i stumble
[16:38] <rtg_> apw, possibly, but thats a different problem.
[16:39] <hallyn> oh that's before i modprobe brcmsmac
[16:39] <rtg_> hallyn, why do you have to modprobe it? do you have black lists ?
[16:39] <apw> hallyn, do yo have wl installed, that blacklists brcmsmac by default, and bcma which it needs
[16:40] <rtg_> hallyn, what apw said. plus you may need linux-firmware-nonfree
[16:40] <hallyn> oh riht that might have happened, i can't check right now bc after i tried to soft-unblock phy0 (with fn-f5) it hung
[16:41] <hallyn> do i need linux-firmware-nonfree only to use wl, or also for brcmsmac?
[16:41] <rtg_> hallyn, just for brcmsmac
[16:48] <hallyn> these names just kill me.  is brcmsmac supposed to replace b43?
[16:49] <apw> hallyn, i believe so yes
[16:49] <hallyn> actually bcma-pci-bridge is what has started auto-modprobing
[16:49] <hallyn> heh, but no change.  when i unblock phy0, the thing hangs
[16:56] <hallyn> cking: d'oh, i assume ddebs.ubuntu.com won' thelp me when i'm running the q-backports kernel
[16:57] <rtg_> hallyn, correct
[16:57] <cking> hallyn, yep
[17:18] <dileks> http://packages.ubuntu.com/precise/all/linux-firmware/filelist
[17:18] <dileks> http://packages.ubuntu.com/quantal/all/linux-firmware/filelist
[17:19] <dileks> are there missing fws for ath6k?
[17:23] <bjf> rtg_: when you get some free time, gomeisa could use htop
[17:24] <rtg_> bjf, done
[17:25] <apw> dileks, there appear to be fewer in quantal, presumably we don't need them there as we only have 3.4 kernels ... rtg_ ^
[17:25] <cking> bjf just wants to see how hard he is driving it
[17:26]  * bjf likes to make her squeal
[17:26] <rtg_> dileks, right, I removed some older firmware files. did I get overzealous ?
[17:28] <dileks> cant test as I have no ath6k wificard. I was asking bwh whuzzup on debian as ath6k was activated recently for trunk.
[17:29] <dileks> is linux-firmware the correct place or should it be in -nonefree pkg?
[17:31] <dileks> I mean whats the criteria to put fws in the one or other pkg?
[17:32] <rtg_> dileks, its must be redistributable
[17:33] <jwi> rtg_: oh, that's a nice surprise for folks bisecting through older kernels...
[17:33] <dileks> if its in linux-firmware.git its "freely redistributable"?
[17:34] <rtg_> jwi, we don't support kernels older then 3.2 on precise.
[17:34] <rtg_> dileks, yep.
[17:36] <jwi> rtg_: i think the ar9170* are no longer used (replaced by carl9170); ar7010 looks fairly old too (htc_7010 now?)
[17:37] <dileks> rtg_: thank you for enlightenment
[17:37] <rtg_> jwi, I mostly went by the MODULE_FIRMWARE statements in the kernel. there may well be some old cruft that I missed. 
[17:38] <rtg_> I should get back and finish up a more thorough review
[17:38] <rtg_> I was just looking to save some space on the LiveCD
[17:43] <apw> ogasawara, ok i've updated the summary a few more times, added a 'BUILD FAILURES' section for the ones you t
[17:43] <apw> turned off
[17:44] <ogasawara> apw: ah nice
[17:45] <ogasawara> apw:  so did you just hardcode the build failure ones?  or should I stick with the same commit subject so it can be auto extracted?
[17:45] <rtg_> apw, when using quilt in a  debian package it appears you cannot patch anything under the debian directory. Is that your experience ?
[17:45] <apw> rtg_, right you can just edit those is my understanding
[17:45] <apw> ogasawara, they are listed in the overrides right now
[17:46] <rtg_> apw, thats what I've done after struggling a a bit
[17:48] <jwi> rtg_: dropping support is fine; but missing firmware is gonna make it a little harder to even *run* an older kernel (for testing purposes, to investigate a regression, ...).
[17:48] <jwi> but i guess those folks know where to get the files manually
=== rtg_ is now known as tgardner-lunch
[17:56]  * ppisati is off
[17:56] <dileks> is that apt-pinning really necessary?
[17:56] <dileks> https://wiki.ubuntu.com/Testing/EnableProposed
[17:57] <dileks> especially -security and -updates
[17:57] <dileks> if there is a higher ubuntu-version, this will be taken
[17:57] <apw> dileks, i beleive that lets you not get proposed items you didn't specificially ask for
[17:58] <dileks> giving -proposed 400 will not automatically update pkgs
[17:58] <dileks> not using a preferences file will give -proposed 500
[17:59] <apw> dileks, i believe the intent of those is to let you make -proposed optin like -backports now is, i have no idea if that will work as written
[18:00] <dileks> /etc/apt/sources.list.d/ubuntu-precise.list: http://paste.ubuntu.com/1015170/
[18:02] <dileks> I put that extra and partner repo stuff into /etc/apt/sources.list.d/ubuntu-precise-partner-and-extras.list
[18:02] <dileks> http://paste.ubuntu.com/1015175/
[18:03] <dileks> dunno why /etc/apt/sources.list.d/$file is not used
[18:03] <dileks> its much nicer than a big fat sources.list
[18:12] <apw> dileks, presumably cause all the code which fiddles with it from the UI would have to change
[18:12] <apw> even if ti could be cleaner and simpler now
[18:12] <apw> ogasawara, am just buildtesting my config changes on x86 and then will push
[18:12] <ogasawara> apw: ack
[18:13] <apw> ogasawara, not bad for an afternoons effort, some 20 or so purples gone
[18:13] <ogasawara> apw: nice
[18:13] <apw> the new predicate based matching is helping get rid of 'em
[18:14] <apw> ogasawara, more tommorrow :/
[18:14] <dileks> apw: what do you mean by "UI"?
[18:40] <tgardner> ogasawara, you won't send out the LTS kernel email  soon, will you ? I'm futzing with meta package names still.
[18:41] <ogasawara> tgardner: am coordinating with nick skaggs, we're thinking of sending out some sort of announcement next Thurs to align with Alpha-1
[18:41] <ogasawara> tgardner: that enough time?
[18:42] <tgardner> ogasawara, thats plenty of time. thanks.
[18:45] <apw> dileks, the config manager thing for sources
[20:10] <tgardner> ogasawara, uploaded new LTS kernel and meta packages to Q-series LTS Backport with -backport removed from all names. they should appear in awhile.
[20:11] <ogasawara> tgardner: ack
[20:11] <ogasawara> balloons: ^^
[20:11] <tgardner> ogasawara, gotta keep rick happy :)
[20:11] <balloons> ack, thanks
[20:11] <ogasawara> tgardner: heh, yah I informed nick we should strip all uses of the word "backport" from the announcement
[20:12] <tgardner> ogasawara, cool. I'll confirm everything looks good in the morning. I'm EOD.
[20:12] <ogasawara> tgardner: ack, I can test here too
[20:14]  * tgardner -> EOD
=== yofel_ is now known as yofel