[00:22] <infinity> mdz: Glad we could help. :P
[00:23] <infinity> mdz: (Not that I'd recommend clang on armhf over gcc)
[00:23] <mdz> infinity, was building forked-daapd, it seems to default to clang
[00:25] <infinity> Oh, it may be one of the few that relies on clang's extensions to C.
[00:25] <infinity> Because when you're tying to write a standards-compliant compiler than can be a drop-in replacement for $CC, the first thing you should do is add incompatible extensions.
[03:18] <chadbyoung> can someone point me to the channel logs?
[07:45] <dholbach> good morning
[09:10] <spyzer> hey everyone, i am facing this issue that my ubuntu 12.04 pandaboard installation reports pvr_dri.so not found
[09:10] <spyzer> in Xorg.log
[09:12] <ogra_> did you install the pvr driver ?
[09:12] <ogra_> in 12.04 it wasnt included by default, it is in 12.10 though
[09:12] <ogra_> (and its broken in 13.04 currently i think)
[09:13] <spyzer> ogra_, yes i did apt-get install pvr-omap4
[09:13] <spyzer> but it doesn't show the file which Xorg is looking for in that directory
[09:14] <ogra_> ?
[09:14] <ogra_> which file in what directory ?
[09:15] <spyzer> ohh sorry my Xorg logs says that it is unable to find /usr/lib/arm-linux-gnueabihf/dri/pvr_dri.so
[09:16] <ogra_> then the compile failed i guess
[09:17] <spyzer> no it compiled and is syas build done
[09:17] <spyzer> everything was successfully installed
[09:27] <infinity> Potentially not for your running kernel, mind you, if you've upgraded kernels but not rebooted since.
[09:31] <ogra_> hrw, you dont happen to have a similar hack like the flash one for the hangouts plugin, do you ?
[09:31] <hrw> ogra_: nope
[09:31] <ogra_> sad
[09:31] <hrw> ogra_: flash hack was not mine
[09:31] <ogra_> flash works so nicely .... i had some hope :)
[09:31] <ogra_> i know, i saw the bug
[09:33] <hrw> ogra_: does 720p videos work for you on YT?
[09:34] <hrw> ogra_: care to create package for flash?
[09:34] <ogra_> hrw, how should i package that ? its not licensed, it would require to chnage a conffile of another package etc
[09:35] <hrw> ah, right - forgot that this part is not yet in any tarball on their archive
[09:35] <hrw> http://commondatastorage.googleapis.com/chromeos-localmirror lists all available sources
[09:36] <ogra_> This XML file does not appear to have any style information associated with it. The document tree is shown below.
[09:36] <ogra_> pfft
[09:36] <ogra_> google fix your pages !
[09:46] <hrw> all: Nine years ago I bought Sharp Zaurus SL-5500 as my first Linux PDA. And due to this I am where I am.
[09:46] <hrw> http://marcin.juszkiewicz.com.pl/2013/02/11/nine-years-of-embedded-linux/
[09:48] <spyzer> hey everyone, is there some command which can tell me what packages are avilable from a particular software source
[09:49] <hrw> spyzer: apt-cache policy package?
[09:50] <hrw> or: cd /var/lib/apt/lists/;grep ^Package *Packages|sort
[09:50] <xnox> hrw: there is dctrl-grep you know ;-)
[09:50] <hrw> xnox: really?
[09:51] <hrw> cool
[09:51] <hrw> there are so many tools nowadays...
[09:51] <xnox> yeah it does the control file syntax greping across available, installed, packages, etc...... it's quite cool.
[09:51] <hrw> I remember friend telling me that there are some apps other than mplayer for playing videos - but I do not know can I believe him in it ;D
[09:56] <jibel> ogra_, hey, I found a very useful tool called pagemap-tool to track memory usage, it provides a more details on memory usage than smem
[09:57] <ogra_> nice
[09:57] <ogra_> lool, ^^^^
[09:57] <jibel> ogra_, I pushed a version that compiles on raring to  lp:~jibel/+junk/pagemap-tools and sample data for the nexus 7 here http://people.canonical.com/~j-lallement/N7/memusage/pagemap/
[09:57] <ogra_> you should sooo blog about that :)
[09:58] <jibel> :)
[10:17] <janimo> ogra_, is X supposed to start in landscape in the Nexus by default
[10:17] <janimo> ?
[10:17] <janimo> I thought portrait was default and we had to configure otherwise
[10:17] <raster> janimo:  yes
[10:17] <raster> sucky :(
[10:18] <raster> i reconfigured it to be protrait again
[10:18] <raster> and the vsync disturbes me
[10:18] <raster> tearing
[10:18] <raster> :(
[10:18] <janimo> raster, we try to orient according to device position, but I thought it was portrait by default for some reason
[10:19] <janimo> at least the fbdev is
[10:19] <ogra_> janimo, portrait is default since a while
[10:19] <janimo> ogra_, I wonder why mine starts in landscape then :)
[10:19] <ogra_> from an xrandr perspective portrait is "normal"
[10:19]  * janimo goes debug gsd further
[10:19] <ogra_> landscape is "right"
[10:20] <raster> ogra_:  since wehn? my image is from like last year
[10:20] <raster> i havent updated :)
[10:20] <raster> i "fixed it"
[10:20] <ogra_> raster, some time in januar iirc
[10:20] <raster> aah ok
[10:20] <raster> so after my install
[10:20] <raster> :)
[10:20] <raster> oh
[10:20] <raster> and xorg has a nasty nast nasty bug
[10:20] <raster> its deep down in the xinput/evdev subsytstem somewhere methinks
[10:21] <ogra_> yep
[10:21] <ogra_> known
[10:21] <raster> if u do just the right things with mouse grabs
[10:21] <raster> xallowevents() becomes broken indefinitely
[10:21] <raster> thus basically a wm doing click to focus stops all mouse press events going to clients
[10:21] <raster> until u restart x
[10:21] <ogra_> bug 1068994
[10:21] <ubot2> Launchpad bug 1068994 in ubuntu-nexus7 "button1 gets stuck after a while" [Critical,Confirmed] https://launchpad.net/bugs/1068994
[10:21] <raster> i've created a reproduction test case
[10:22] <ogra_> oh, please attach that case to the bug then
[10:22] <raster> it doesnt trigger it
[10:22] <raster> u can trigger ti 100% reliably with e17
[10:22] <ogra_> its our biggest blocker and seems upstream doesnt really do any work on it
[10:22] <raster> and my test case was to rpove that aftrer its been triggered the bug affects any x client that does a passive grab + allow events
[10:22] <raster> so run wm\
[10:22] <raster> trigger it
[10:22] <raster> kill wm
[10:22] <raster> then launch test client
[10:22] <raster> see that it also cant pass events
[10:23] <raster> hmm
[10:23] <raster> i havent got a "Trigger" code yet
[10:23] <janimo> raster, seems you are furthers ahead in debugging that issue :)
[10:23] <raster> basically... i can give you a whole toolkit+wm to trigger it
[10:23] <janimo> furthest
[10:23] <raster> but i think thats a bit much :)
[10:23] <janimo> raster, I think this is a clever scheme to get us buying into E17
[10:23] <raster> basically i know u do work your on unity and i dont want to straddle u with al of that junk
[10:23] <ogra_> well, it happens under unity as well
[10:23] <raster> hehehe
[10:24] <raster> well e17 reiably triggers it in its illume mode
[10:24] <janimo> ogra_, didn;t we at some point reproduce with lubuntu, only took more time?
[10:24] <raster> what can i give u to help?
[10:24] <raster> i know best thing is a "simple x client to repro and prove"
[10:24] <ogra_> janimo, i havent seen it in lubuntu at all
[10:24] <raster> e17 is instant
[10:24] <raster> just press the "menu" butotn on its top indicator bar
[10:24] <raster> presto
[10:24] <raster> broken
[10:24] <raster> 100% reliable for me
[10:24] <janimo> raster, if you suspect various parts of Xorg being at fault that would be a useful pointer too
[10:25] <ogra_> but tjallton said it wouldnt be desktop specific, just thaat compiz triggers it more easily
[10:25] <raster> its not desktop specific for sure
[10:25] <janimo> I know upstream did some patches in the dark based on our symptoms, but some hints as to where you think the bug is may help them
[10:25] <raster> if it were then it would go away afgter i killed the wm off
[10:25] <raster> but my test client proved that wrong
[10:25] <raster> i spent a lot of time debugging e17 and efl trying to find out what was up
[10:25] <raster> and narrowed it down this far
[10:26] <raster> hmm
[10:26] <raster> i'll try make a test client that also triggers it
[10:26] <ogra_> well, having allyour findings on the bug will surely help
[10:26] <janimo> raster, that would be great
[10:26] <raster> if i can get u a simple xlib based test client that alwasy triggers it
[10:26] <raster> then debugging for upsteram should be fast
[10:26] <raster> i know thats what i'd wanty
[10:26] <janimo> indeed
[10:26] <raster> thus why i will hesitate to file anyhing more until i have that :)
[10:26] <raster> i just dont want to annoy ppl :)
[10:27] <janimo> raster, it would be an annoyance with much higher signal/noise rate though that our usual comments on this bug, so feel free too :)
[10:27] <raster> hehe
[10:27] <raster> ok :)
[10:27] <raster> will do right now
[10:28] <raster> let me just double-check
[10:29] <raster> there we go
[10:29] <raster> triggered
[10:29] <raster> oh so easy
[10:44] <janimo> ogra_, uptodate raring and X still starts in landscape (kernel console and plymouth splash are portrait)
[10:44] <raster> oh btw
[10:44] <raster> this issue also happens on my exopc
[10:44] <raster> so its not arm/n7 specific.
[10:44] <raster> :)
[10:44] <ogra_> janimo, well, trhat started with your recent changes to acceld and g-s-d
[10:45] <ogra_> raster, yeah, see the last comment on the bug
[10:45] <janimo> ogra_, ok so not just my setup then, good to know :)
[10:45] <janimo> I thought you had portrait by default with fresh raring
[10:45] <raster> aaah just saw :)
[10:45] <ogra_> janimo, nobody looked into it yet, the behavior is the same as with acceld in the wrong setup thouogh
[10:46] <ogra_> janimo, we do
[10:46] <raster> i should read them.. shouldnt i? :)
[10:46] <infinity> raster: Reading is wildly overrated.
[10:47] <raster> yeah
[10:47] <raster> so i have learned from my users
[10:47] <raster> :)
[10:47] <infinity> It's nice to be on the other end of it, isn't it?
[10:48] <infinity> I sometimes get giddy about filing upstream bugs for that very reason.
[10:48] <infinity> "Ooo, ooo, I get to be the annoying twit this time, yay!"
[10:57] <raster> infinity: hehehe
[10:57] <raster> https://bugs.launchpad.net/ubuntu-nexus7/+bug/1068994/comments/24
[10:57] <ubot2> Ubuntu bug 1068994 in ubuntu-nexus7 "button1 gets stuck after a while" [Critical,Confirmed]
[10:57] <raster> there u go
[10:57] <raster> info
[10:58] <raster> with "demo that its xallowevents() that is busted"
[10:58] <raster> ie thats what is actualyl stuck
[10:58] <raster> actually
[10:59] <raster> there
[10:59] <raster> i even read prevbious comments
[10:59] <raster> :)
[11:04] <ogra_> i poointed #ubuntu-x to it
[11:04] <ogra_> lets see
[11:06] <raster> i wish i had the peferct "just run this small xlib app and presto.. insta-bug"
[11:06] <raster> thats what they really want
[11:06] <raster> :)
[11:06] <raster> dont have it tho
[11:06] <raster> so sorry :(
[11:06] <raster> i have "half of it"
[11:07] <raster> with the other half being all of e17 and a nice little pop up a menu button to get the bug into gear and its pants on and dirty
[11:07] <raster> :)
[11:07] <ogra_> but you identified the broken function
[11:07] <ogra_> that should give some hints
[11:08] <raster> that bit wasnt that hard
[11:08] <raster> some xev fun ande i figured out my buttonpress was gone
[11:09] <raster> WHY was what i was digging into
[11:09] <raster> :)
[11:09] <raster> and guessing it was xallowevents was obvious at that point
[11:09] <raster> but why was eluding me
[11:09] <ogra_> sure, but you dug deeper than the others already
[11:09] <raster> i was tyring to disable the xi/xi2/xi2.2 support in efl to see if it was a combo of selecting for xi2.2 touch events and also mouse events
[11:10] <raster> or if it was some other stupid bug that had crept into efl somewhere
[11:10] <ogra_> oh, you should note that too, our xorg guys always point to that
[11:10] <raster> was xallowevents even being called at alll as it should be? (it worked on desktops and other places so it SHOULD be...)
[11:10] <ogra_> (xi vs xi2 etc)
[11:10] <raster> it didnt make any difference
[11:10] <raster> dont actually have any xi support
[11:10] <raster> just xi2 and 2.2
[11:10] <ogra_> yeah, i thought so
[11:11] <raster> but iw as turing that off and hunting thru it to try find out more info
[11:11] <raster> thus my time sank into that
[11:11] <ogra_> funnily if it happens for me, i can still use the onscreen kbd to switch apps
[11:11] <raster> then trying to figure out the "action" that triggered it
[11:11] <raster> that was pure luck
[11:11] <raster> :)
[11:11] <ogra_> and inside these apps touches are recognized
[11:12] <raster> probably because the kbd isnt a regualr window with click to focus handling on it
[11:12] <ogra_> for me only all compiz elements die but not the apps themselves
[11:12] <raster> well either its not regulr
[11:12] <raster> not managed by the wm
[11:12] <raster> or wm is not handling click interception on it as it asks not otbe focused
[11:12] <raster> not sure
[11:12] <ogra_> it is on top and steals the focus, yeah
[11:12] <raster> didnt look :)
[11:12] <raster> e17 has its own vkbd anyway
[11:12] <raster> which is less annoying (doenst go float on top of apps)
[11:13] <raster> also the mem footprint of onboard is just silly-pants
[11:13] <raster> it soaks up like 20-30mb
[11:13] <ogra_> onboard uses struts now too
[11:13] <raster> for what.. i know not
[11:13] <ogra_> and the footprint is similar to maliit (just tried that on the weekend)
[11:13] <raster> e17's vkbd works more like u'd findin ios/android
[11:13] <raster> where it slides in
[11:13] <raster> and resizes the app window to not overlap
[11:13] <ogra_> right, onboard does the same now
[11:14] <raster> :(unless the app specifcialyl advertises it supports the overlap protocol stuff)
[11:14] <raster> aaah thats changed
[11:14] <raster> :)
[11:14] <ogra_> yeap
[11:14] <ogra_> but it still eats 15-20M of your RAM
[11:14] <ogra_> maliit is closely the same though
[11:14] <ogra_> probably 1M less or so
[11:15] <raster> weird
[11:15] <raster> why so much?
[11:15] <ogra_> no idea, i only tested it from an enduser POV
[11:15] <ogra_> didnt dig into code
[11:15]  * raster shrugs
[11:15] <raster> oh well
[11:15] <ogra_> it is a tad faster than onboard ... butu also only has half the amount of keys
[11:16] <raster> i need to work on our "better touch ui"
[11:16] <raster> time our touch ui got some love
[11:16] <raster> ehhee
[11:16] <raster> starting on board is like watching continental drift
[11:16] <raster> it takes like.. 5-10 sec or so?
[11:16] <raster> or thats what i experienced
[11:16] <ogra_> that should have improved too
[11:17] <raster> well thats like saying "it should now taste better than drinking badger pee"
[11:17] <raster> not too hard to get better
[11:17] <raster> :)
[11:17] <ogra_> yeah
[11:17] <ogra_> its still python and still slow
[11:18] <ogra_> which means you notice every improvement :)
[11:18] <raster> hehehe
[11:25] <janimo> ogra_, we had someone commenting often on onboard bugs, giving me the impression he may be upstream or close to it
[11:25] <janimo> they may know why it takes up so much memory
[11:26] <janimo> being python is not a good enough excuse for 30M (what I see here)
[11:26] <ogra_> wow
[11:26] <ogra_> what do you look at ?
[11:26] <ogra_> RES should be around 15
[11:26] <janimo> I'll have a nother look, but that is what I recall from a few days ago
[11:27] <ogra_> varying between 15 and 20 usually for me
[11:27] <raster> janimo: i find "its python" to be an excellent excuse for almost anything wrong with a python app. i use that line regularly :)
[11:27]  * raster is biased
[11:27] <ogra_> janimo, but yeah, upstream is very busy trying to fix our bugs
[11:27] <ogra_> its a shame that we will likely switch
[11:28] <raster> arent u just going to make your own display system?
[11:28] <raster> :)
[11:28] <raster> why bother fixing the xorg bugs then ? :)
[11:28] <ogra_> roumors ... pfft
[11:28] <raster> well tbh
[11:28] <raster> u are going ot be in for a hard time with ubuntu phone
[11:28] <raster> as it has to piggyback off nadroid to work
[11:29] <ogra_> nah, it will all be fun and unicorns
[11:29] <ogra_> *bellive* me
[11:29] <raster> unless u insist soc vendors provide non-android drivers
[11:29] <ogra_> :)
[11:29] <raster> eg dri/drm/xorg stuff
[11:29] <raster> for e3xample
[11:29] <raster> :)
[11:29] <raster> wanting THAT will be all fun and unicorns :)
[11:29] <ogra_> heh
[11:29] <raster> very few soc vendors will play ball with that
[11:29] <raster> and gpu vendors
[11:29] <raster> etc.
[11:30] <raster> unless u are big big big
[11:30] <raster> and then u generally just get the "well hers the src.. you go do it"
[11:30] <raster> :)
[11:30] <ogra_> we'll see what happens once it is released
[11:30] <raster> sure
[11:31]  * ogra_ explicitly stays away from the phone stuff ... i like the surprise of what i have to get in the archive :)
[11:31] <raster> hahahaha
[11:31] <lool> jibel, ogra_: Yup; I've read jibel's G+ post on it, couldn't make sense of the raw data from my G+ client though
[11:31] <raster> fair enuf
[11:31] <lool> jibel: Looking after files which are only used by a handful of processes is definitely the way to go, I didn't have an easy way to do this with smem short of looking at USS
[11:33] <infinity> raster: Being given the source to JFDI would be just fine.
[11:33] <infinity> raster: What I wouldn't give to be able to actually fix bugs in all these blobs.
[11:33] <raster> infinity: its kind of a poison pil tho
[11:33] <raster> u oftne get ut.. with nice fat legal restrictions on who can see it etc.
[11:33] <raster> :)
[11:34] <infinity> raster: Sure, and it's very not ideal, but not much I can do about it. :/
[11:34] <raster> i keep my hands off closed src driver internals to make sure i dont get "Tainted"
[11:34] <raster> like legally
[11:34] <raster> so if i figure out some behavior
[11:34] <raster> algorithm oir whastevr - i've done it above bosard from the outside
[11:34] <infinity> raster: I don't generally work on the same parts of the stack they touch, so taint wouldn't be an issue for me.
[11:35] <raster> luckily i have "other guys" who get to poke at the internalsd
[11:35] <raster> i regularly have debates about whose bug it is
[11:35] <infinity> If something leaked from an nvidia GL driver into my glibc work, the world would be rather topsy-turvy.
[11:35] <raster> i tend to win most of them and get the drivers fixed :)
[11:35] <raster> hahyahaha
[11:35] <raster> true
[11:35] <raster> actually spekaing of that
[11:35] <raster> i was looking around ont he weekend
[11:36] <raster> is there any options/cointrols to enable gpu dithering for tne n7/tegra3?
[11:36] <raster> i googled around and found some patches for chromebooks
[11:36] <raster> in the android driver layer
[11:36] <raster> but nothing else
[11:36] <infinity> Yeah, no idea.  ogra_ ^
[11:36] <raster> the n7 has some nasty 18bpp banding :(
[11:36] <infinity> I've so far managed to stay very far away from that stuff.
[11:36] <infinity> So far.
[11:36] <raster> it disturbs me and makes small children cry
[11:36] <raster> :)
[11:37] <infinity> Yeah, small children hate banding.
[11:37] <raster> they do
[11:37] <infinity> (Have you ever looked at a banded sunset and thought that reality could do with better gradient dithering?)
[11:38] <raster> yes
[11:38] <raster> i then curse the clouds at them distrubing my smooth sunset gradient
[11:38] <raster> and go gimp up some unbanded  sunsets to disdplay on my screen
[11:39] <infinity> Always takes me back to that great satire article about god choosing the Unreal engine over the Q3 engine for Reality 2.0, and the fake quote from Carmack, "you'd think reality could benefit from curved surfaces".
[11:39] <raster> hahaha
[11:47] <ogra_> raster, i dont think there are any options for the tegra xserver beyond some basics (ARGBHWCursor etc)
[11:48] <raster> yeah
[11:48] <raster> i found those
[11:48] <raster> but not much else
[11:48] <ogra_> /usr/share/X11/xorg.conf.d/61-tegra-gpu.conf
[11:48] <raster> bugger :(
[11:48] <raster> yeah
[11:48] <raster> read that
[11:48] <raster> found some others around
[11:48] <ogra_> thats the xorg.conf coming with the tarball
[11:48] <raster> not much more tho
[11:48] <ogra_> yup
[11:48] <raster> rang strings on the tegra xorg driver
[11:48] <raster> didnt spot anything about dithering
[11:48] <raster> :)
[11:48] <raster> boo
[11:49] <raster> comne on nvidia homies
[11:49] <raster> give us vsync buffer swaps and dither controls pls :)
[11:49] <raster> small children are crying here!
[11:49] <ogra_> they might be there, just not easily found or documented
[11:49] <raster> banded images and tearing just makes them all so sad
[11:50] <raster> :(
[11:50] <ogra_> i think the cursor setting could help a littel here
[11:50] <raster> well it'd get rid of a flickery cursor
[11:50] <raster> :)
[11:50] <raster> tho tbh.. i want to get rid of it in the end anyway
[11:50] <raster> well for touch stuff
[11:50] <raster> easy enuf
[11:51] <ogra_> i think it is supposed to also help marginally with some of the tearing
[11:51] <raster> tho even if blank/empty./. it'll cause xorg overhead in redrawing an empty box
[11:51] <ogra_> even if the cursor isnt shown
[11:51] <ogra_> (there was a bug i cant find atm where an nvidia guy said that)
[11:52] <raster> hmm
[11:52] <raster> so a sw cursor forces drawing to not be vsynced?
[11:52] <ogra_> dunno
[11:52] <ogra_> i would have to find that bug again
[11:52] <raster> hmm
[11:52] <raster> interesting
[11:57] <ogra_> hand there is also ttps://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-tegra3/+bug/1088372
[11:59] <raster> hmm
[11:59] <raster> turning on argb cursors leaves me with a blank screen
[12:00] <raster> maybe an old xorg/driver?
[12:00] <raster> as for that bug
[12:00] <raster> i noticed this first thing i stuck ubuntu onto my n7 last year
[12:01] <raster> same problem with evas and e17
[12:01] <raster> aslo asl for swapinterval of 1
[12:01] <raster> and get tearing
[12:01] <ogra_> and bug 1080789
[12:01] <ubot2> Launchpad bug 1080789 in ubuntu-nexus7 "Corruption around mouse cursor when dragged, particularly around Dash, Indicators, window chrome" [Low,Confirmed] https://launchpad.net/bugs/1080789
[12:01] <ogra_> https://bugs.launchpad.net/ubuntu-nexus7 helps :)
[12:01] <raster> happens in portrait too
[12:02] <raster> nb
[12:02] <raster> it may not be a page flip thing
[12:02] <raster> depending on gpu/gfx chip setup
[12:02] <raster> u can sweap buffers part way thru acan
[12:02] <raster> anr it flips instantly
[12:02] <raster> depending on gfx subsytstem setup u may have to vsync your buffer swaps too
[12:02] <raster> but its also slow/sluggish imho
[12:02] <raster> whihc is hinting at it being sa blit
[12:03] <raster> it should be much after if it were a swap
[12:03] <raster> :)
[12:03] <raster> unless this tegra3 is really that bad...
[14:20] <janimo> xnox, gsettings set org.gnome.settings-daemon.peripherals.touchscreen orientation-lock true seems to be already there for preventing rotation
[14:20] <janimo> just does not seem to be exposed in a GUI
[14:39] <xnox> janimo: nice. as long as it works. I can include that.
[14:40] <janimo> xnox, works in my tests
[14:40] <janimo> include where? you needed it in the installer?
[14:40] <xnox> janimo: yeah. cause when oem-config rotates it can become off-screen.
[14:42] <janimo> xnox, the only issue I saw with it, is that when set, we don't get proper input coordinates on X startup as the whole rotation/adjustment thing is skipped
[14:44] <janimo> I need to let my nexus get charged more than 3%. As it is it keeps resetting when doing a debuild. Weird
[14:54] <fly[ac100]> hi
[14:54] <fly[ac100]> guys, have you any ideas about artefacts like this: http://i.imgur.com/tpOdrtg.png
[14:55] <fly[ac100]> it appears only in chromium and xcb-driven apps
[14:55] <ogra_> cairo ... as i said before
[14:55] <fly[ac100]> gtk apps works fine))
[14:55] <fly[ac100]> yeah, may be
[14:55] <fly[ac100]> but what could I do with it?
[14:56] <ogra_> try downgrading it and see if it fixes the xcb stuff
[14:56] <infinity> Print it out and turn it into a stylish hat?
[14:56] <fly[ac100]> :D
[14:56] <ogra_> or try compiling a new chromium version and see if it fixes it
[14:56] <fly[ac100]> is cairo related to xcb?
[14:57] <fly[ac100]> i mean i use i3 and urxvt
[14:57] <fly[ac100]> and avaik this apps dont use any cairo)
[14:57] <fly[ac100]> afaik*
[14:58] <infinity> cario has many backends, XCB being one of them.
[14:58] <fly[ac100]> so may be problem related to xorg pixmaps engine or kind of
[14:58] <qengho> Speaking of compiling chromium, I'm having some trouble.  I compile, link, and run, SEGV before main() is entered, it seems.
[14:58] <ogra_> if you use aliased fonts in your teminal, cairo is most likely involved somehow
[14:59] <fly[ac100]> hm
[14:59] <qengho> My simple helloworld.c runs fine.
[14:59] <fly[ac100]> yeah, I do
[14:59] <fly[ac100]> but
[15:00] <ogra_> qengho, is that with your NEON detection or without ?
[15:00] <fly[ac100]> dont lxterminal use the same cairo too?
[15:00] <qengho> ogra_: detection off.
[15:00] <ogra_> hmm
[15:01] <ogra_> fly[ac100], just downgrade and see if its cairo :)
[15:01] <infinity> qengho: Can you get a remotely useful backtrace out of it, or is it just a bunch of useless corrupted frames?
[15:01] <ogra_> likely quicker than guessing from app to app
[15:01] <fly[ac100]> downgrade its not so easy in archlinux))
[15:02] <qengho> no neon. ABI hard float. fpu = vfpv3-d16.
[15:02] <infinity> If only this was #archlinux-arm
[15:02] <infinity> qengho: No neon may or may not actually work correctly.  It's an ongoing battle with upstream.
[15:03] <qengho> infinity: not even a bunch.  _start(), __libc_start_main __libc_csu_init, CRASH.
[15:03] <infinity> qengho: Oh, I should have done a /whois first, this makes more sense now. :P
[15:04] <qengho> I need to test in another environment.
[15:04] <qengho> Just never seen it before.
[15:06] <infinity> qengho: Crashing in csu_init certainly points at some sort of miscompilation or wrong target.
[15:06] <infinity> qengho: Given that csu_init is preeeetty simple, and about the only way to segfault it would be to throw it some wildly out-of-range arguments.
[15:06] <ogra_> did you compile an x86 version with vfpv3-d16 ?
[15:06] <ogra_> :)
[15:07] <qengho> infinity: it's in the next (anonymous) frame, not there.
[15:07] <xnox> janimo: I am using nexus image and that gsetting doesn't do anything for me.
[15:07] <xnox> (just fully upgraded) or is that not in ubuntu archive yet?
[15:07] <infinity> qengho: I assume you're running this on real hardware, not emulation?
[15:07] <ogra_> xnox, because acceld still runs in the user session
[15:08] <ogra_> try killing it and see if g-s-d takes over then (it doesnt for me)
[15:08] <qengho> infinity: yes. real. No crosscompile.  12.04 on Chromebook.
[15:09] <infinity> qengho: Try a build without turning off neon and see if that "fixes" it?
[15:09] <infinity> qengho: To narrow it down.
[15:09] <qengho> infinity: right. There's a can of worms. I'll look.
[15:10] <infinity> I'm so very, very close to just writing an email to devel-announce/release announcing that we just don't give a hoot about non-neon systems anymore.
[15:11] <infinity> Excepy hallyn will murder me, after I just mailed him my ac100.
[15:11] <infinity> s/Excepy/Except/
[15:12] <ogra_> infinity, i would go with that too ... but #ac100 would hate us all
[15:12] <ogra_> i guess 14.04 is the time to switch
[15:12] <infinity> ogra_: Yeah.  If only we'd never done anything with ac100s, we could have baselined on v7+neon and been done with it.
[15:12] <ogra_> and doves
[15:13] <ogra_> the doves were actually the business case keeping us from it ... not the ac100
[15:13] <infinity> ogra_: I'd prefer to switch before 14.04, TBH, but this is all a nightmare for the security team if they have to keep maintaining neon-disabling patches for old releases.
[15:13] <ogra_> they just make us keep it now
[15:13] <infinity> ogra_: Yeah, the doves were the reason way back when, but not for 12.04.
[15:13] <ogra_> right
[15:13] <infinity> ogra_: 12.04, there was no business case, just the community case.
[15:13] <ogra_> yup
[15:13] <infinity> I'm still tempted to just, at some point, say "screw it, users of 12.04 on ac100 can't have nice things", and let the security team stop faffing with neon-removal.
[15:14] <infinity> It's not like we "support" ac100 in any way.
[15:14] <ogra_> oh, sigh ... so OMAP will become a blackberry thing it seems
[15:14] <ogra_> there goes the linux support
[15:14] <infinity> Hrm?
[15:14] <ogra_> BB hired most of the laid off TI OMAP people
[15:14] <infinity> The Z10 is an OMAP?
[15:14] <infinity> Oh.
[15:15] <ogra_> and the new HW will be all OMAP it seems
[15:15] <ogra_> ... and QNX :(
[15:15] <infinity> Maybe some of them will do Linux support in their spare time.
[15:15] <infinity> Including for the BB hardware, which looks shiny.
[15:15] <ogra_> sure, still a shame
[15:15] <infinity> (And pigs may fly)
[15:16]  * ogra_ finds his nexus4 more shiny than the BB
[15:16] <infinity> Not that I have anything against QNX, but there's a little part of me that wants to buy a Z10 and jam Android/Ubuntu on it.
[15:16] <infinity> I like the look of the Z10, I dunno.
[15:16] <ogra_> pfft
[15:16] <infinity> The N4 is a little too round for me.
[15:16] <infinity> LG's sister phone to the N4 is more my style.  But, not a Nexus, so less appealing on the software side.
[15:16] <ogra_> yeah
[15:17] <ogra_> well, does it have the rounded touchscreen edges ?
[15:17] <ogra_> these are really awesome
[15:17] <infinity> http://shop.windmobile.ca/ProductCatalog/Handsets/default.aspx <-- Good visual comparison, N4 on top, O4X on the bottom.
[15:17] <ogra_> you can scroll without having your thumb cover any content
[15:17] <infinity> The O4X is just a little more square and utilitarian, and I like that.
[15:18] <ogra_> yeah, i know what you mean, i stayed on my S2 because of the ugly shape the S3 has
[15:18] <xnox> ogra_: so i set acceld to manual (echo manual | sudo tee /etc/init/acceld.override), then boot, then change gsetting, then sudo start acceld and then it respects gsettings value (rotates when lock is false, and doesn't rotate when lock is true)
[15:18] <ogra_> xnox, no, no !
[15:18] <ogra_> xnox, you need the upstart job, but dont want the Xsession.d snippet
[15:19] <infinity> I just wish they'd stop with the value-add fragmentation nonsense. :/
[15:19] <ogra_> ++
[15:19] <infinity> If the O4X was also a pure AOSP build, I'd run out and buy one this afternoon.
[15:19] <ogra_> heh
[15:19] <infinity> Maybe the way Nexus devices sell like hotcakes might be a wakeup call to these vendors.
[15:20] <infinity> Maybe that's actually been Google's plan.  Kill fragmentation by proving it's useless.
[15:21] <ogra_> yeah
[15:21] <ogra_> and the nexus devices are just great HW ... cant complain about the features
[15:21] <infinity> Sure, but so are the O4X, SGSIII, etc.
[15:21] <infinity> In fact, on paper, I'd rather have the O4X too.
[15:22] <infinity> But, again.  Stupid custom build that will never have updates.
[15:22] <ogra_> but the non nexus devices cost twice the price
[15:22] <infinity> At least, if the update history of my current LG phone is anything to go by.
[15:22] <infinity> ogra_: Nah, check that link.  Almost identical prices.
[15:22] <janimo> xnox, while I have an upload in the queue, that setting should work without it actually
[15:23] <ogra_> oh, right "As low as $0 "
[15:23] <ogra_> cant beat that with a nexus :P
[15:23] <infinity> ogra_: Oh, wait.  That would be my carrier adding a premium to the N4.  I can get it cheaper from Google Play.
[15:23] <ogra_> yeah
[15:23] <infinity> ogra_: (Was looking at the 549 vs 529)
[15:23] <ogra_> yup
[15:24] <infinity> But yeah, it's 359 from Google.
[15:24] <ogra_> or 300 if you take the smaller one
[15:24] <ogra_> or so
[15:24] <infinity> No SD slot, don't want the small one.
[15:24] <infinity> (Another selling feature of the O4X, it has SD)
[15:25] <xnox> ogra_: janimo: so are we removing the snipped from Xsession.d soon =) ?
[15:25] <ogra_> xnox, dunno, i was waiting for janimo to finish the transition
[15:25] <xnox> ah , ok.
[15:25] <xnox> i'll use just the gsetting then.
[15:25] <ogra_> Xsession.d should definitely go if you want g-s-d
[15:26] <ogra_> the upstart job just tellls the kernel to enable the device and sets the defaults
[15:26] <ogra_> i guess thats something to keep
[15:26] <ogra_> (if it cant be moved into udev or so)
[15:27] <janimo> xnox, I thought I had removed that snippets in 0.49 or so
[15:27]  * xnox checks what I have.
[15:27] <ogra_> janimo, you didnt... we talked about that already
[15:27] <janimo> ogra_, g-s-d is working besided the bug that initial input orientation is broken
[15:28] <janimo> ogra_, I did not remove the acceld daemon but I thought I had removed the xsession hook
[15:28]  * janimo checks
[15:28] <ogra_> and when i tested rotation completely died when disabling acceld
[15:28] <ogra_> (dosabling the xsession bit i mean)
[15:28] <janimo> https://launchpadlibrarian.net/129949778/ubuntu-defaults-nexus7_0.48_0.49.diff.gz
[15:29] <ogra_> hmm, funny
[15:30] <ogra_> ogra@nexus7:~$ dpkg -l ubuntu-defaults-nexus7|grep ii
[15:30] <ogra_> ii  ubuntu-defaults-nexus7                    0.52                                       all          Default settings for Ubuntu customizations
[15:30] <ogra_> ogra@nexus7:~$ dpkg -S /etc/X11/Xsession.d/95-acceld_start
[15:30] <ogra_> ubuntu-defaults-nexus7: /etc/X11/Xsession.d/95-acceld_start
[15:30] <ogra_> ogra@nexus7:~$
[15:31]  * ogra_ wonders why the binary disagrees with that patch above
[15:32] <janimo> ogra_, is that a config file hence not autoremoved?
[15:33] <ogra_> janimo, well, then dpkg -S shoudl point that out i think
[15:33] <ogra_> probably a later upload re-added it ...
[15:33]  * ogra_ checks the diffs
[15:33] <janimo> ogra_, I am uptodate and do not have it
[15:34] <janimo> dpkg -L does not show it either
[15:35] <infinity> Did you rm_conffile it when removing it?
[15:37] <ogra_> ogra@nexus7:~$ dpkg -L ubuntu-defaults-nexus7|grep Xsession
[15:37] <ogra_> /etc/X11/Xsession.d/95-acceld_start
[15:37] <ogra_> infinity, well, even if that was missed, should dpkg still show it as being part of the package ?
[15:38] <xnox> janimo: is there any event that I can listen to in Gtk+ to find out that the screen size has now changed?
[15:39] <xnox> when rotating ubiquity everything is ok, apart from the panel is keeping it's original size and doesn't recalculate/expand.
[15:40] <xnox> (in the installer the panel is a standalone custom/small faked single small C-file executable)
[15:40] <ogra_> hmm
[15:40] <ogra_> http://paste.ubuntu.com/1636658/ agrees that the file is gone from the binaries
[15:41] <ogra_> so i geuss infinity's suggestion is best here
[15:42] <ogra_> http://wiki.debian.org/DpkgConffileHandling
[15:43] <ogra_> i still think dpkg should somehow indicate its not shipped by the binary
[15:45] <infinity> ogra_: There's a dpkg-query invocation that can tell you if a conffile is obsolete, I forget what it is.
[15:45] <ogra_> well ...
[15:45] <infinity> Our QA people use it to smack us around with bugs on a regular basis.
[15:45] <ogra_> i think dpkg -L should eb clever enough to tell me
[15:45] <ogra_> *be
[15:45] <janimo> xnox, no idea about screen size change callbacks
[15:46] <infinity> dpkg-query -W -f='${Conffiles}\n' | grep obsolete
[15:46] <infinity> And look at that, I have 5 obsolete conffiles on my system.  \o/
[15:46] <ogra_> oh, thanks !
[15:46] <ogra_> there are more :)
[15:46] <ogra_>  /etc/init/alsa-restore.override cf3f2a865fbea819dadd439586eaee31 obsolete
[15:46] <ogra_>  /etc/init/alsa-store.override cf3f2a865fbea819dadd439586eaee31 obsolete
[15:46] <ogra_> and
[15:47] <ogra_>  /etc/cups/cupsd.conf e62a552c7e9e384036b0e0e5df9d46c4 obsolete
[15:47] <janimo> 44 on my system
[15:47] <ogra_> your nexus ?
[15:47] <ogra_> wow
[15:47] <janimo> nope
[15:47] <infinity> Yeah, I'm going to clean up cups, qemu, and usb-creator-gtk right now. :P
[15:47] <infinity> xnox: Unless you plan to reintroduce the usb-creatork-gtk init script that made everyone die inside?
[15:47]  * xnox has 22
[15:48] <infinity> You guys clearly have more packages installed than I do...
[15:49] <xnox> infinity: yes.
[15:49] <infinity> ogra_: When you do the cleaning, read the manpage carefully.  The version check isn't against the version where it disappeared (well, unless that's when you add the code too), it's against the version you're adding the code to, so upgrades from the interim broken versions also DTRT.
[15:49] <ogra_> k
[15:50] <xnox> infinity: shouldn't we be fixing these in the archive....?! aka I have 17 from qemu related stuff
[15:50] <infinity> xnox: Yes, you have more packages than me, or yes, you intend to reintroduce the scary init job?
[15:50] <xnox> (qemu libvirt kvm)
[15:50] <xnox> infinity: both.
[15:50] <infinity> xnox: We should be fixing them, yes.  I only have 3 from qemu.  Give me your output?
[15:50] <ogra_> infinity, the init job needs to stay, but in much saner form in the session upstart
[15:50] <ogra_> (once thats there)
[15:51] <infinity> If the init job is coming back in the same filename, I won't bother removing that obsolete conffile, it'll sort itself.
[15:51] <ogra_> well, it will likely not live in /etc/init
[15:52] <xnox> infinity: http://paste.ubuntu.com/1636688/
[15:53] <infinity> xnox: Oh, I never had qemu-kvm installed, so I only have the latter two, and one from qemu-system-user.
[15:53] <infinity> All very ew, this migration.
[15:53] <xnox> infinity: i remember the fairly recent thread on d-d that there is no sane way to take over a conffile when renaming a package
[15:53] <xnox> =/
[15:54] <infinity> There isn't.
[15:54] <infinity> And that's the problem with some of these.  Hrm.
[15:54] <infinity> Like the cups one.
[15:54] <xnox> ugu
[15:54] <infinity> It's shipped, but not in the same package.
[15:55] <wookey> I've got 96
[15:56] <infinity> You win.
[15:58] <xnox> wookey: how many of those are self-inflicted and didn't come from the archive? =)
[16:00] <janimo> infinity, so when I removed that file from the package should I have also called some dh helpers too for better purging it?
[16:00] <infinity> janimo: man dpkg-maintscript-helper
[16:00] <ogra_> janimo, right, like in the wikipage above
[16:01] <infinity> Which probably SHOULD have a dh wrapper, but doesn't.
[16:01] <janimo> so this is something dh could not autodetect and DTRT?
[16:02] <xnox> janimo: dh doesn't have the previous binary package from the target repository to compare and find out about dropped conffig files
[16:02] <janimo> ah, works around known dpkg limitations
[16:02] <xnox> yeah.
[16:02] <ogra_> well, but it is able to tell me the file is obsolete
[16:03] <infinity> Well, dpkg's treatment of actually obsolete conffiles is basically functioning as designed.
[16:03] <infinity> It's just that sometimes that design is really undesirable.
[16:03] <infinity> The move/takeover bit, though, is a straight up dpkg bug.
[16:03] <ogra_> conffiles should just die
[16:03] <infinity> Replaces: overwrites should DTRT and don't.
[16:04] <ogra_> every package should just ship with a conf.d setup for user overrides
[16:04] <infinity> ogra_: No, conffiles should just be much smarter, and integrate all the crazy stuff that things like ucf tries to do on a much lower and saner level.
[16:04] <ogra_> or that
[16:04] <infinity> (ie: 3-way merges)
[16:05] <ogra_> yup