[07:41]  * apw yawns
[10:19] <Daviey> zul <-> apw <-> NCommander 
[10:19] <Daviey> discuss.
[10:19] <apw> ?
[10:19] <Daviey> zul: Share what you just showed me please.
[10:19] <zul> it looks like some lxc containers stuff is not enabled on omap4 (i ran lxc-checkconfig on the board and this is the output)
[10:20] <zul> http://pastebin.ubuntu.com/662527/
[10:29] <apw> Daviey, where was the bug on these
[10:30] <apw> zul, some of this is known i believe and sitting fix committed
[10:31] <zul> ah ok cool then
[10:34] <zul> is there a ppa with the latest omap kernel that might have these fixes?
[10:41] <apw> zul nope, but i can make you a kernel shortly once i've checked they are all set correctly
[10:42] <zul> apw: yes please :)
[10:47] <apw> zul can you tell from your tree what the File capabilities: missing
[10:47] <apw> is checking ?
[10:48] <zul> CONFIG_SECURITY_FILE_CAPABILITIES i think
[10:49] <apw> ok that check is just bogus, that security option is gone
[10:49] <apw> the code it enabled is always enabled now
[10:50] <zul> ok cool
[10:50] <apw> doesn't bode well for the code actually tracking the kernel very well, as it was removed in .33
[10:58] <apw> zul: http://people.canonical.com/~apw/lp787749-oneiric/
[10:59] <zul> apw: thanks
[11:49] <tekess> hi.. i could use some help, i hope there's somebody awake..
[11:50] <tekess> I've used my tv as screen via HDMI with my old ubuntu 9 without a problem, but it won't work with newer versions.. I'm starting to thing it has something to do with recent kernels
[11:50] <tekess> rings any bell?
[12:08] <apw> tekess, doesn't ring a bell for me no, i think i've used my hdmi right up to natty
[12:10] <tekess> it works on natty for you? 
[12:10] <tekess> without any tunning?
[12:14] <apw> tekess, yep, plug it in and on it comes 
[12:14] <tekess> which kernel version are you using?
[12:14] <apw> what happens for you, does running xrandr --auto do anything
[12:14] <apw> whatever the latest in natty is
[12:15] <tekess> i have no idea, could you check it please?
[12:15] <apw> i'd have to reboot to confirm confirm, as i am running an oneiric kernle right now for testing
[12:16] <tekess> oh, it's ok.. thanks anyway
[12:17] <tekess> bummer :-/
[12:17] <apw> tekess, i'd suggest you file a bug anyhow.  though do plug it in and run xrandr --auto
[12:17] <apw> it may pick it up
[12:18] <tekess> i can't run xrandr, when doing it remotely it won't work
[12:18] <apw> export DISPLAY=:0.0 first ?
[12:19] <tekess> mmnn
[12:25] <tekess> sorry.. apw, still there?
[12:31] <tekess> i exported display and then ran xrandr --auto... it said "can't open display"
[12:39] <apw> are you the same user as logged in ?
[12:40] <tekess> i've tried with my user and with root as well
[12:40] <tekess> but i don't follow.. what do you mean?
[12:41] <apw> well you can only access the display server as the logged in user
[12:41] <tekess> which logged in user?
[12:42] <tekess> you mean there must be an xsession opened?
[12:42] <apw> i was assuming so yes
[12:43] <tekess> well.. it's hard to initiate an xsession when i can't see anything
[12:43] <tekess> but i guess i can try if then there's something i can do to check if i did it correctly
[12:43] <apw> hmmm
[12:44] <tekess> but since it's a just installed system i have no idea what the screen will look like..
[12:45] <tekess> since during the instalation i created my non-root user.. can I asume the login window will have my user already selected and I just have to type my password?
[12:45] <apw> probabally return <password> return will do the trick; but first
[12:45] <apw> see what modes you have avilable on that connector
[12:46] <apw> apw@dm$ cd /sys/class/drm/card0-HDMI-A-1
[12:46] <apw> you should have something like that directory available
[12:46] <apw> in there, what do status and modes contains
[12:46] <tekess> status: connected
[12:47] <tekess> modes: lots of them..
[12:47] <tekess> first one is 1920x1080, which is the one it's working on my old ubuntu 9
[12:49] <tekess> is there any log in which i can track if i do any login attempt?
[12:49] <apw> cat dpms ?
[12:49] <tekess> On
[12:54] <tekess> sorry again :(
[12:54] <tekess> apw, i hope you're still there, you're helping me a lot!
[12:55] <apw> tekess, well those parameters imply the kernel thinks that output is on
[12:56] <tekess> what the hell can be happening then?
[12:56] <apw> well the mode could be incompatible with the monitor so its switching off
[12:56] <apw> unfortuanatly the kernel is not telling me which mode is enabled
[12:57] <tekess> but the mode that is active should be the first one in modes file, right?
[12:57] <tekess> can i force one specific mode?
[12:57] <apw> tekess, i have no idea, mine are in order largest to smallest, and yes the first one happens to be selected
[12:58] <apw> but 1) i can't say for sure it always is, and 2) that list has no refresh rate info
[12:58] <tekess> ok
[12:58] <apw> so ... i think you need to attempt to login on that console
[12:58] <apw> and then run xrandr remotly to find out the real mode selected
[12:58] <tekess> ok, would you help me to do that?
[12:58] <apw> i think ret <passwd> ret should do it, and if your sound works you should hear the login sound
[12:59] <tekess> i think i've already tried and i didn't hear anything, let me try again
[13:00] <tekess> no sound
[13:00] <tekess> no logs I could check?
[13:00] <_ruben> this might not be the best place to ask, but i'll try anyway :) .. the statistics as shown by 'ip -s link', can they be fetched (easily) from the kernel "manualy"? like through proc/sys/whatever?
[13:01] <apw> _ruben, you could try stracing the command to see where it gets them
[13:01] <_ruben> why didn't i think of that.. sigh
[13:02] <_ruben> ah, uses netlink it seems, wonder how friendly that interface is
[13:04] <tekess> apw,  i think i might have logged in,  w command reports me in tty7 running x-session-manager and there are a lot of processes running, such as gnome-screensaver, etc
[13:04] <apw> tekess, sounds good, then export DISPLAY=:0.0 and run xrandr
[13:04] <apw> pastebin the output or something
[13:05] <tekess> ok
[13:06] <tekess> "no protocol specified, can't open display :0.0"
[13:10] <apw> can you paste the exact commands please
[13:10] <apw> as that combination works here for me
[13:10] <tekess> sure
[13:11] <tekess> http://pastebin.com/hYv4ab8K
[13:17] <apw> tgardner, remind me how wireless channel overlap, there is some complexity
[13:18] <tekess> hey, apw.. I found this in Xorg.0.log:   "Output HDMI1 using initial mode 1920x1080"
[13:18] <apw> is that a reasonable output
[13:18] <tekess> but I also found "Output HDMI1 connected" a few lines upper
[13:19] <tekess> reasonable? i guess so.. it's a hdtv, and that mode works on ubuntu 9
[13:19] <apw> tekess, what Xorg.*.log files do you have in /var/log
[13:20] <tekess> 0 and 6
[13:20] <apw> and whats the machine called with the hdmi output
[13:21] <tekess> mmnn.. what do you mean?
[13:22] <apw> the hostname of it
[13:22] <tekess> i'm really sorry, my english sucks :(
[13:22] <tekess> it's rubik
[13:22] <apw> and you logged in as tekess ?
[13:22] <tekess> yes
[13:22] <tekess> it's the only non-root user existing
[13:23] <apw> ps -ef | grep compiz, does that show anything
[13:23] <tekess> nope
[13:24] <tgardner> apw, its most common in the 2.4Ghz band using 802.11bg. channels are 5Mhz wide, but the radio uses 15 Mhz. therefore, the only completely non-overlapping channels are 1,4,8, and 12 (IIRC)
[13:24] <apw> tekess, can you pastebin the ps -ef output
[13:24] <tekess> sure
[13:24] <apw> tgardner, so 2 5 9 would be a valid combination
[13:25] <apw> trying to work out why my wireless perf has gone to turd all of a sudden
[13:25] <apw> and i am on 8
[13:25] <apw> but ... there are peeps on 6 (and a lot of em)
[13:25] <tgardner> apw, yep, as long as there aren't any sources on 1,4,8 etc
[13:25] <apw> so perhaps they are my problem
[13:25] <tgardner> possibly.
[13:25] <tekess> apw, http://pastebin.com/7wuPd97P
[13:28] <tekess> what about running xrandr from .xinitrc and redirecting its output to some file, would that work?
[13:29] <tekess> or .xsession.. I never remember which one to use
[13:30] <apw> can you pastebin the output of cat -vet /proc/2547/environ
[13:31] <tekess> here, http://pastebin.com/RSVSJ38t
[13:32] <apw> DISPLAY=:0 ... so the X server really is on :0
[13:32] <tekess> I also tried export DISPLAY=:0
[13:33] <apw> XAUTHORITY=/var/run/gdm3/auth-for-tekess-PbBgRZ/database
[13:33] <apw> you could try exporting that too
[13:33] <tekess> ok, let me try
[13:36] <tekess> bummer
[13:36] <tekess> http://pastebin.com/LNBL8zEy
[13:36] <apw> tekess, ok so ... what resolution is this external monitor
[13:37] <tekess> it's a high definition tv
[13:37] <apw> either the manual will tell you the resolution, or you'll have to tell us the make to make sure
[13:38] <apw> as HD tells us almost nothing
[13:38] <tekess> yeah, i know
[13:38] <tekess> let me check
[13:38] <tekess> with ubuntu 9 i never had to do anything special
[13:38] <tekess> just select the correct aspect ratio so the whole screen would fit
[13:39] <apw> tekess, 9.04 or 9.10
[13:41] <_ruben> hm, seems ifconfig uses /proc/net/dev .. that seems more "accessible"
[13:41] <tekess> 9.10
[13:41] <tekess> I can run it if there's some command output that could help us
[13:42] <apw> tekess, you might try xrandr --output HDMI1 --mode 1280x720 
[13:43] <apw> tekess, what make and model is your display/tv
[13:44] <tekess> give me a minute, its owner's manual is a pain in the ass
[13:46] <tekess> it's a LG, 32LG30
[13:46] <tekess> i can't believe it, but i can't find resolution or whatsoever in the manual
[13:47] <tekess> oops, sorry, correct model is 32LG5600
[13:48] <apw> did xrandr --output HDMI1 --mode 1280x720 change anything
[13:49] <tekess> actually it did
[13:49] <tekess> still blank, but there's no "no signal" message
[13:50] <apw> and you've tried to wiggle the mouse to wake it up
[13:50] <tekess> yep
[13:51] <tekess> that's weird... i do ctrl+alt+f3  or f4, and I get the "no signal"
[13:51] <tekess> but not in f7
[13:52] <apw> not so supprising as the other vts are in their own modes
[13:53] <tekess> mmnn..  with  xrandr --output HDMI1 --mode 1920x1080  I get back the "no signal" thing
[13:53] <apw> also not supprising htat was the mode you were using before
[13:53] <tekess> yep, i know
[13:53] <tekess> aaaaargh, i hate this!
[13:54] <tekess> am i supposed to keep ubuntu 9 till the end of time? or buy a monitor? arrgh
[13:55] <apw> tekess, nope, something is broke, but you have reached then end of my X knowledge.  you should get a bug filed and move this over to #ubuntu-x, they should know more than I
[13:56] <tekess> ok
[13:56] <tekess> thank you so much though
[14:00] <apw> tgardner, looks to be worse than we thought, 1, 6, and 11 are the only non-overlapping combinations
[14:01] <tgardner> apw, the only _truly_ non-overlapping channels. its an analog kind of thing. 
[14:01] <apw> right
[14:01] <smb> left
[14:02] <apw> *slap*
[14:02] <smb> *duck*
[14:02] <apw> toooo slow
[14:02] <smb> *ouch*
[14:03] <tekess> I'll give it another try after having lunch, good bye you all, and Andy, thanks again
[14:03] <tekess> bye
[14:31] <_ruben> hm, got errors in 'dmesg' about ata4, wonder how i could find which disk is attached to it
[14:44] <smb> _ruben, Should be possible to find looking at dmesg
[14:44] <smb> If there is still the beginning
[14:44] <_ruben> couldn't find any hard references really
[14:48] <smb> _ruben, Hm, currently not be able to verify with more disks, but I believe there is /proc/scsi/scsi and a relation to the host controller
[14:49] <_ruben> the problem slightly changed, box hang, rebooted, now stuck at boot :/ .. last line is regarding fsck exiting with 1 for /boot 
[14:50] <smb> Maybe problems with ata4 was trying to hint you something...
[14:54] <smb> Sometimes a manual fsck recovers thing, though (without knowing/seeing more) it also could be some more serious trouble with the driver.
[14:54] <_ruben> pretty much unrelated, pulled all drives from that software raid volume, leaving only the flashdisk with /boot and root-on-lvm .. still bails at the fsck
[14:54] <smb> I mean drive
[14:57] <_ruben> guess i'll be hooking up an usb cdrom drive later on to boot a recovery cd .. few reboots later no fsck errors, but it completing remains the last lines on screen
[15:00] <smb> "it" meaning the fsck? Or dropping to the recovery shell? 
[15:01] <smb> Oh, otherwise hanging... could it have the raid in fstab and mountall waiting?
[15:01] <smb> Then hitting "s" may help
[15:11] <_ruben> ah right, lets try that (didnt know that 's')
[15:12] <_ruben> s just prints on screen .. ctrl-c's show up as ^C ..
[15:12] <_ruben> and yes, the raid's in fstab
[17:47] <apw> tgardner, i am wondering if we should upload oneiric ti-omap4 given all the pending config stuff
[17:47] <tgardner> apw, I've no problem with that
[17:48] <tgardner> want me to do it?
[17:48] <apw> tgardner, ok i'll tie a bow on it and shove
[19:06] <kees> apw: where did your "ALL" export move to?
[19:06] <apw> s/~apw/~kernel/
[19:06] <kees> cool, thanks
[19:06] <apw> sorry didn't realise you used it
[19:06] <kees> it's pretty! :)
[19:07] <apw> its curtianly something :)  got a bit smaller today
[19:07] <kees> any idea what the ETA is for ti-omap4 and fsl-imx51 ?
[19:07] <kees> yup
[19:07] <apw> kees, i am unsure as to whats going on with them.  i'll ask sconklin
[19:07] <apw> sconklin, ^^
[19:08] <sconklin> kees: dunno. Honestly we sort of throw those over the fence. I'll check
[19:08] <apw> sconklin, that in part is why its odd they are lagging, they almost should lead :)
[19:09] <sconklin> they can't lead the branch they are rebased from
[19:11] <apw> sconklin, well they can pass in testing :)
[19:11] <apw> sconklin, if there is something we can do to help get them out let me know
[19:11] <sconklin> oh, wait, we're talking about ~recent~ kernels
[19:12] <apw> i can always find time to poke arm people with sharp sticks if they arn't testing
[19:12] <apw> yeah, actually about those carrying lots of cves now
[19:13] <herton> apw, sconklin: this week the bot should be opening bugs for the arm packages, once they get copied to -proposed
[19:14] <kees> herton: using create-cve-tracker, or is this something else?
[19:14] <sconklin> herton: that's right - this should mostly resolve the issue
[19:14] <apw> kees, he means release trackers
[19:14] <kees> ah, okay
[19:14] <apw> which drives them to get uploaded etc
[19:14] <herton> kees: something else, the stable bot (sru-workflow-manager aka shank bot)
[19:15] <kees> herton: okay, cool. should we add them to create-cve-tracker too?
[19:15] <apw> kees, arm branches are already in the cve bugs
[19:16] <apw> kees, that reminds me 2011-1833 as your magic script added the missing nominations etc ?
[19:16] <apw> *has
[19:16] <kees> apw: ah, true. it's missing -ec2
[19:16] <apw> yeah we should fix that
[19:16] <apw> though you are fixing it anyhow right automatically
[19:16] <kees> apw: it has the capability, yes.
[19:17] <kees> apw: I add nominations automatically, but not missing packages (e.g. -ec2)
[19:17] <apw> oh i see
[19:17] <apw> then you won't fix 2011-1833 ... as someone added a different package bug to the cve i assume you won't use the create-tracker to fix it ?
[19:18] <kees> I _can_ have it add the missing packages, but I've left that disabled for now since it wasn't clear yet if it had value.
[19:18]  * kees looks
[19:18] <apw>   kees perhaps i'll ask a differnt way.  what should i expect to happen to that CVE
[19:18] <apw> as its not in a workable state right now kernel wise
[19:19] <kees> ah right, let me stab it with my script...
[19:22] <apw> kees, should it have a new bug, or should we aim to fix the existing ?
[19:22] <kees> apw: I'll update the existing. one moment.
[19:25] <apw> kees, ok i'll add -ec2 to the creater
[19:26] <kees> apw: 732628 should reflect reality now
[19:26] <apw> bug #732628
[19:26] <ubot2> Launchpad bug 732628 in ecryptfs-utils "TOCTOU in mount.ecryptfs_private" [High,Fix released] https://launchpad.net/bugs/732628
[19:29] <apw> kees, linux-ec2> added and pushed to the git repo
[19:31] <kees> apw: cool, thanks.
[19:31] <apw> kees, you seem to have added linux-source-2.6.15, and linux-ti-omap
[19:32] <kees> yeah, just noticed that. removing from the list now....
[19:32] <apw> kees, but i don't think either have anything but Invalid across the board, and you haven't applied that either
[19:32] <apw> cool
[19:33] <apw> kees, on the Introduced-by: Fixed-By: ... if we have more than one bug they are hard to pair up, why did we not use a Break-Fix: type thing instead.  either Break-Fix: or just Fixed-by: but with two parameters ?
[19:34] <apw> s/bug/fix
[19:34] <kees> apw: I can swap that around. Just using "Break-Fix:" there seems the most sane.
[19:34] <apw> yeah i concur
[19:55] <mfilipe> sforshee, hi! do you think that intel bugfix will be release in 11.10? 
[20:08] <sforshee> mfilipe, I think so -- I just checked, and it looks like it has been merged to the i915 maintainer's tree as a fix for 3.1
[20:12] <mfilipe> ;)
[20:12] <mfilipe> thanks
[20:33] <kees> why does LP have to be so slow? :P
[20:33] <kees> OOPS-2048CP55
[20:33] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=2048CP55
[20:41] <kees> apw: I see that linux-linaro is not in your ALL report. what's the support state of that kernel?
[20:46] <herton> ogasawara: brad told me that may be you know, or may be someone else, do we have a machine to build powerpc test kernels (like tangerine)?
[20:47] <ogasawara> herton: yep, use davis
[21:21] <cnd> sforshee, did I not respond to your trackpad email?
[21:22] <cnd> if I did I'm really sorry
[21:22] <cnd> I try to hit everyone who emails me, but sometimes stuff slips through...
[21:27] <sforshee> cnd, I did't see a reply, but don't worry about it :)
[21:28] <cnd> sforshee, it looks like you're making progress on alps :)
[21:28] <cnd> when I decoded the magic trackpad I would do things like two finger drags in only the X or Y direction
[21:29] <cnd> and then watch the bits to see what's changing
[21:29] <cnd> dunno if that helps
[21:29] <sforshee> cnd, I've been trying that, but I still haven't found the pattern for some of the stuff
[21:30] <cnd> ok
[21:30]  * herton -> eod
[21:30] <cnd> I'm glad we're getting somewhere with alps though
[21:30] <sforshee> the values seem to vary based on position, I just can't find the relationship
[21:30] <cnd> hmm
[21:31] <sforshee> cnd, at this point I could get pretty close to a workable driver without multitouch
[21:31] <cnd> sforshee, with multifinger?
[21:32] <sforshee> cnd, I could give one position and number of touches
[21:32] <sforshee> the main problem is that sometimes that position seems to jump to a different contact point
[21:32] <cnd> that's a big improvement in itself :)
[21:32] <cnd> that's not too surprising actually
[21:33] <sforshee> yeah, but it makes for a jumpy cursor sometimes :)
[21:33] <cnd> we see the same issue with the semi-mt multitouch trackpads
[21:33] <cnd> if you look at the synaptics driver, I believe we always emit the smallest of the two values in one slot, and the largest in the other slot
[21:34] <sforshee> cnd, I think I remember seeing that
[21:34] <sforshee> I'm only getting one value right now tho
[21:34] <cnd> but even in semi-mt mode, synaptics tries to provide the best single touch coordinate
[21:34] <cnd> is that because you haven't decoded the second packet?
[21:34] <sforshee> maybe, I'm not sure whether the second packet contains a coordinate or not
[21:35] <sforshee> the values can seem very haphazard
[21:35] <sforshee> sometimes they look like they might be tracking position, then they do something crazy that doesn't make sense
[21:36] <cnd> hmmm
[21:36] <cnd> it's quite a puzzle :)
[21:36] <sforshee> no doubt
[21:36] <cnd> if you could use a second pair of eyes on a trace to try to decode it, I'd be happy to try :)
[21:37] <sforshee> it can't hurt
[21:37] <sforshee> let me clean up my notes, and I'll send those to you along with some traces
[21:37] <cnd> ok