[00:20] <Br0wn_> so has monitor mode on the broadcom chips inside of nexus 7's been figured out yet?
[00:20] <Br0wn_> hi btw :)
[00:24] <pirea_> hy
[00:25] <pirea_> ubuntu touch will not be released for nexus 7(2012)?
[00:25] <Br0wn_> pirea, apparently not
[00:25] <Br0wn_> that's what a news release says
[00:26] <RAOF> Well, not really.
[00:26] <RAOF> Also, we've already released 1.0 for the N7 :)
[00:28] <OttOmanTR> RAOF: News say there will be official ubuntu Touch phone in 2014?
[00:28] <RAOF> And it's not like the N7 will immediately cease to work. It's just that it'll no longer be one of our primary development targets. It'll be easy enough for someone else to pick up and make 2012-N7 images.
[00:28] <RAOF> OttOmanTR: So they say :)
[00:29] <OttOmanTR> I was expecting to see it in CES 2014
[01:33] <lx> hello
[01:47] <fishscene> Greetings, It seems to be difficult to find information on my question, try as I might.. but is it possible to access ubuntu-touch on my Nexus 7 without having to use ADB/SSH commands from my Mac? As in plug it in, and have it show up as a device on OSX?
[01:59] <thomi> charles: are you still around?
[02:00] <nhaines> fishscene: if OS X supports MTP, then yes, it should be automatic.
[02:00] <nhaines> If not, then no, there probably is no way.
[02:01] <fishscene> ah ok. I'll check into OSX support for MTP as currently, it doesn't show up as a device. Thanks!
[02:01] <nhaines> :)
[02:02] <fishscene> mhaines: http://apple.stackexchange.com/questions/106156/does-mavericks-support-mtp (In case this question ever comes up again)
[02:40] <ds2> where exactly does the sources for 3.0.0-3-maguro live? neither the CM mirror nor does the ubuntu kernel repo seems to have that particular kernel source
[04:20] <nhaines> fishscene: fantastic. Thanks!
[04:25] <DjMadness> is there any plans for official samsung galaxy s4 9505 support ?
[04:25] <nhaines> DjMadness: no.
[04:26] <nhaines> Canonical is going to support as few device as possible.  Samsung probably doesn't care about Ubuntu right now.
[04:27] <mhall119> DjMadness: the Nexus line was designed to do what we need hardware to do
[04:27] <mhall119> which makes it the obvious choice for development and testing right now
[04:27] <nhaines> Google only supports 4 Android hardware platforms, and Canonical is dropping support for all but 2.
[04:28] <DjMadness> a shame, powerful phone, would be nice with it... guess ill need to study the current port and see what i can fix
[04:28] <mhall119> we're adding support for at least one
[04:28] <nhaines> It's the hardware OEM's job to port and support any particular OS to a phone.  On the other hand, there's nothing preventing community support from popping up too.  :)
[04:29] <mhall119> +1, we need community help to bring Ubuntu to a larger number of phones
[04:29] <mhall119> and we will continue to offer whatever support we can to those community ports
[04:29] <nhaines> mhall119: if Canonical would keep building Ubuntu for the current platforms without official support, that would be a huge help.
[04:30] <mhall119> nhaines: that's one of the options being discussed
[04:30] <nhaines> mhall119: it sounded awfully hypothetical on the ubuntu-phone ML.
[04:31] <mhall119> nhaines: we just started those discussions this morning
[04:32] <nhaines> Pledging to discontinue all support for maguro (as an example), and then starting a discussion about maybe continuing builds is not promising.
[04:32] <mhall119> maguro has other issues, it's not going to get a KitKat update from Android
[04:32] <mhall119> which means to maintain it we'd need to maintain two versions of the Android stack
[04:32] <nhaines> Okay then.  Pledging to discontinue all support for grouper (as an example), and then starting a discussion about maybe continuing builds is not promising.
[04:33] <nhaines> I know TI still supports the maguro drivers for Android.  In about a week or so I'll probably look into that situation if no one else looks like they're going to.
[04:34] <mhall119> nhaines: I can't undo the past, but dholbach and I are currently working on it
[04:35] <nhaines> Don't get me wrong, my KitKat ire over maguro is directed squarely at Google.  But automated builds for the 13.10 supported platforms would be a big help.  Maguro has other issues.
[04:36] <mhall119> nhaines: at a minimum we will make it easy for anybody to build their own images for the N7 and N10 using the latest Ubuntu
[04:37] <nhaines> I think if goldfish gets a good x86 port that'll make a huge difference.  I really do hope that the feature roadmap takes off at a much, much faster rate than it currently is.
[04:38] <mhall119> well, we only have so many man-hours, and we'd like to put most of them towards improving Ubuntu rather than maintaining Android
[04:39] <mhall119> we already have 1 ubuntu image, and multiple device images
[04:39] <nhaines> Yes, I understand what a time sink platform support can be.  But Ubuntu 13.10 under-delivered, 14.04 is way behind schedule, and the SDK version plans for the click app store are a guaranteed failure.
[04:40] <nhaines> So I really, really hope that dropping platform development allows the OS development to get back on track.
[04:41] <nhaines> This sounds kind of negative.  Dropping hardware support is really disappointing, but isn't really important in the long run.  It's the OS and SDK development that's really critical.
[04:42] <nhaines> And that's the progress that worries me.  I'm hoping that there's a dramatic speedup in the next couple of weeks.
[04:46] <ds2> is there a tag or a way to finding the corresponding sources for an image?
[04:47] <ds2> (and no, the apt-get source doesn't seem to do the right thing)
[05:06] <Mirv> barry: the qt5.2 eta depends on how quick all those build failures get fixed. address-book-app is slightly later in the dependency chain, see http://pad.ubuntu.com/qt52-dependencies - but I notice one of the dependencies at least hasn't been even tried to rebuilt yet, so I'll try that which may make address-book-app buildable
[05:14] <Mirv> oh, it had been tried but failed
[06:33] <Mirv> barry: progress! address-book-app's dependencies and it itself got compiled now, unlike 4 days ago. slightly less red now.
[08:05] <dholbach> good morning
[08:06] <tsdgeos> morning
[10:07] <didrocks> thostr_: actually, we have found a HUD regression
[10:07] <didrocks> psivaa: can you give details, please? ^
[10:11] <psivaa> thostr_: didrocks: so from image 126 onwards with the introduction of 13.10.1+14.04.20140108-0ubuntu1 hud version messaging ui smoke test is failing on maguro
[10:11] <psivaa> http://ci.ubuntu.com/smokeng/trusty/touch/maguro/126:20140113.1:20140107.1/6050/messaging-app-autopilot/663980/ is the failing link
[10:12] <psivaa> reverting the hud, libhud-client, libhud2 from 13.10.1+14.04.20140108-0ubuntu1 to 13.10.1+14.04.20131205-0ubuntu1 makes the test pass
[10:13] <didrocks> thostr_: are you able to get those fixed? I would be in favor of reverting for now to let you more time investigating the issue
[10:13] <didrocks> psivaa: thanks for finding it out :)
[10:14] <psivaa> didrocks: yw :)
[10:14] <didrocks> psivaa: just one remaining! :)
[10:14] <psivaa> right on that now
[10:29] <thostr_> didrocks: yes, we'll be looking into it right now
[10:29] <didrocks> thostr_: ok, direct upload for reverting meanwhile, ack?
[10:29] <didrocks> (I don't change trunk)
[10:31] <thostr_> didrocks: is this really hud?
[10:32] <thostr_> didrocks: the log says: "Could not determine application identifier. HUD will not work properly. Provide your application identifier in $APP_ID environment variable."
[10:32] <didrocks> thostr_: well, it's linked to HUD change, see what psivaa pasted ^
[10:32] <didrocks> "11:12:55           psivaa | reverting the hud, libhud-client, libhud2 from 13.10.1+14.04.20140108-0ubuntu1 to
[10:32] <didrocks>                           | 13.10.1+14.04.20131205-0ubuntu1 makes the test pass
[10:32] <didrocks> "
[10:33] <thostr_> didrocks: sure, isn't it more that case by hud now doing proper checking revealed an issue somewhere else?
[10:34] <thostr_> didrocks: the environment variable is used by other services as well, so it should be set
[10:34] <didrocks> thostr_: that's possible. I'm not the one knowledge for those env variable. Hence the "need more investigation", right now, we are trying to go back to a promotable image ASAP
[10:35] <didrocks> thostr_: note that messaging-app is a deb, not click app
[10:35] <didrocks> so I guess it doesn't have APP_ID
[10:35] <thostr_> didrocks: right
[10:36] <thostr_> didrocks: ok, then revert and we'll get in touch with other guys and try to get it resolved
[10:36] <didrocks> thanks thostr_, doing
[10:37] <dpm> xnox, good morning. I'm trying out the emulator, (on Trusty, amd64, Intel graphics) and all I get is a black screen such as http://ubuntuone.com/3nKQs3TFjEiIYxEFFrVMEc - any ideas what could be causing this? I can see a warning about decreasing the amount of memory allocated in the log, but I'm not sure it's got something to do with it - http://pastebin.ubuntu.com/6755473/
[10:37] <twosixfour> Hi all... got some questions re: security if anyone is happy to answer them or point me to some documentation.
[10:37] <Laney> dpm: he's apparently away this week
[10:38] <twosixfour> Basically need info on security and crypto support from a networking perspective
[10:39] <dpm> ah, thanks Laney for the heads up
[10:45] <pitti> kalikiana, tvoss_: if you have some time in the next days, I'd appreciate some criticism for https://code.launchpad.net/~pitti/qtubuntu-sensors/integration-tests/+merge/201742
[10:46] <pitti> kalikiana, tvoss_: should I fix the broken outputRange() (and enable the corresponding test) in that MP, or in a subsequent one?
[10:46] <tvoss_> pitti, a subsequent one, review for your branch is at the top of my list
[10:46] <pitti> ack
[10:47] <pitti> tvoss_: not *that* urgent, please don't drop something else for it :)
[10:47] <didrocks> thostr_: HUD revert uploaded
[10:47] <pitti> didrocks: ah, found the regression that broke images?
[10:47] <didrocks> pitti: for messaging-app yeah, remaining rssreader one
[10:50] <thostr_> didrocks: not sure if it's hud... when looking at the the test case code it's not using HUD anywhere...
[10:51] <didrocks> thostr_: maybe a side effect? did anyone try the same revert than psivaa did?
[10:51] <didrocks> will be a first step I guess ;)
[10:52] <thostr_> didrocks: we're running autotests... trying to figure out where it fails
[10:52] <didrocks> thostr_: the list of changes in the image messaging-app is the following one: http://people.canonical.com/~ogra/touch-image-stats/20140113.1.changes
[10:52] <didrocks> s/in the image messaging-app/in the image messaging-app started to fail/
[10:54] <thostr_> didrocks: pete-woods is on it
[10:55] <twosixfour> ..okay. Looking for some information regarding serious crypto support for ipsec style networking for Ubuntu Touch and whether reliance on the android low level layer will come with the same inherent vulnerabilities. If any kernel devs can give some insight and point me to some info on launchpad 'd be greatly appreciated as I'm trying to work out whether I'll be needing to fork Android, attempt to fork Tails for ARM, or whether I
[10:55] <twosixfour> Will very happily contribute upstream for any code from the project I'm working on.
[10:58] <popey> dpm: the emulator takes a LOOOONG time to start
[10:59] <popey> i get a black screen for ages
[10:59] <dpm> ah, good to know
[10:59]  * dpm re-runs it
[11:00] <pete-woods> didrocks: the messaging app autopilot tests pass for me using the newest HUD on my N4
[11:00] <dpm> popey, it's alive! :)
[11:00] <popey> ☻
[11:00] <pete-woods> is there something I'm missing?
[11:00] <didrocks> pete-woods: see the test results, it's maguro only
[11:00] <pete-woods> d'oh!
[11:01] <davmor2> Morning all
[11:01] <pete-woods> I don't have a galaxy nexus to try on :/
[11:03] <didrocks> pete-woods: maybe check on the emulator just in case?
[11:03] <pete-woods> I'll try it
[11:04] <didrocks> thx
[11:05] <davmor2> didrocks: if it is maguro only I can run the tests to look into it but it could be the issue I highlighted the other day if it is only maguro
[11:05] <didrocks> davmor2: can be, can you reproduce and chat with psivaa about the revert he has done on the HUD?
[11:06] <davmor2> didrocks: will do, let me run through my incoming first and then I'll get on it
[11:09] <pete-woods> didrocks: that autopilot test doesn't even use HUD
[11:09] <pete-woods> it does look like the environment isn't being set up correctly, http://ci.ubuntu.com/smokeng/trusty/touch/maguro/126:20140113.1:20140107.1/6050/messaging-app-autopilot/663980/
[11:09] <pete-woods> Could not determine application identifier. HUD will not work properly.
[11:09] <pete-woods> Provide your application identifier in $APP_ID environment variable.
[11:09] <didrocks> pete-woods: as told, can be a side effect, we need to investigate why the revert worked reliably for psivaa
[11:10] <pete-woods> fair enough
[11:10] <didrocks> pete-woods: is it provided for .debs?
[11:10] <didrocks> (see the discussion I had with thostr_ above ^)
[11:10] <pete-woods> didrocks: it is
[11:10] <didrocks> remember that messaging-app is a .deb
[11:10] <didrocks> ok
[11:10]  * pete-woods thought he'd been very thorough with this HUD release, I ran like *all* the autopilot tests I could find :/
[11:11] <dpm> does anyone know if networking is supposed to be working with the emulator? I don't get any list of existing networks or connection to the access point my host PC is connected to
[11:12] <popey> dpm: network works for me
[11:12] <popey> its transparent.
[11:12] <mandel> didrocks, morning, I'm wondering if there is a way to fix the following CI fails https://jenkins.qa.ubuntu.com/job/ubuntu-download-manager-trusty-amd64-ci/161/console that are due to the speed of jenkins instead of increasing the timeout, is a little ugly to keep increasing the timeout when in a local machine there are no issues
[11:13] <popey> i.e. open the browser and you get ubuntu.com load, without selecting a network
[11:13] <didrocks> mandel: this question is for the CI team, you should ping cihelp in #ubuntu-ci-eng
[11:13] <mandel> didrocks, ok, thx!
[11:14] <psivaa> davmor2: didrocks: pete-woods: what i did was to remove hud, libhud-client, libhud2 first and then installed all of them of 13.10.1+14.04.20131205-0ubuntu1 version
[11:20] <dpm> popey, ah, cool, let me try that. Any other caveats you've run into with the emulator worth mentioning?
[11:25] <popey> dpm: it doesnt seem to update
[11:25] <popey> i dont know if that's intentional
[11:26] <dpm> popey, ok, thanks, good to know
[11:29] <dpm> popey, what I've noticed as well is that the left swipe to reveal the launcher is extremely sensitive. You have to be very accurate to hit a narrow pixel area to reveal it
[11:30] <popey> yeah the emulator doesn't do edge swipes
[11:33] <Mirv> tsdgeos: zsombi1 might be able to fill in where the tests fail on his computer. I think he even had so that one run failed and the second one succeeded.
[11:35] <zsombi1> Mirv: that was with the text inputs
[11:36] <ogra_> didrocks, heh, seems pitti didnt read your "hold the line for touch" mail
[11:36] <ogra_> (we need <Blink> tags for email subjects ;) )
[11:36] <pitti> ogra_: ah, ubuntu-touch-meta?
[11:36] <didrocks> let's put Blink back!
[11:37] <didrocks> well, it's sdk-libs, they are not installed by default?
[11:37] <pitti> I can add a propagation blocker bug if you want
[11:37] <ogra_> pitti, yeah
[11:37] <ogra_> i doubt thats needed though
[11:37] <pitti> but it didn't seem like something which would be installed by default
[11:37] <ogra_> err
[11:38] <ogra_> indeed ubuntu-sdk-libs is installed by default
[11:38] <didrocks> good ;)
[11:38] <ogra_> everything depends on it ... thats our API
[11:38] <didrocks> argh, I read a NOT
[11:38] <ogra_> heh
[11:39] <didrocks> hum, ok, will had a little noise then, normally new components shouldn't regress anything existing though, let's hope ;)
[11:39] <ogra_> sdk libs holds all of Qt, sensors html etc support
[11:39] <pitti> ah, ok
[11:39] <ogra_> its only html5 stuff anyway
[11:39] <pitti> now, we can add a propagation blocker
[11:39] <ogra_> pitti, nah, i doubt html changes do anything to the tests
[11:39] <ogra_> we dont have specific html5 app tests yet
[11:39] <ogra_> (we probably should though)
[11:43] <davmor2> didrocks: so I can exactly reproduce the issue on the rss app so I'll start digging there but it is looking like it thinks a state is missing and it can't search for canonical which might be the header or a list items view so I'll get back to you when I know more
[11:44] <didrocks> davmor2: thanks! did you try the messaging app as well?
[11:44] <didrocks> with reverting the HUD? (to have a confirmation)
[11:46] <FuLgOrE> hi guys. fyi: http://phandroid.com/2014/01/13/ubuntu-touch-devices-2/
[11:47] <davmor2> didrocks: that I'll be running in a minute once I get the tests pulled for the rssreader so I can see what it is attempting to do and try to reproduce it manually
[11:50] <ogra_> seb128, could it be that your last gstreamer merge added a dependency for libgl1-mesa-glx on arm ? (we are trying to make out why http://people.canonical.com/~ogra/touch-image-stats/20140110.1.changes exploded)
[11:50] <davmor2> didrocks: hmm that;s not a good start http://paste.ubuntu.com/6755753/
[11:54] <ogra_> (neither glu nor glx should ever be on arm)
[11:57] <seb128> ogra_, could be, Laney did those
[11:57] <seb128> Laney, ^
[11:57] <seb128> ogra_, what happens if you try to uninstall libgl?
[11:57] <seb128> e.g what wants to be removed?
[11:57] <ogra_> hmm, havent tried yet
[11:58]  * ogra_ twiddles thumbs ...
[11:58] <ogra_> i totally forgot how slow apt is
[11:58] <ogra_> (on the device)
[11:59] <ogra_> Reading package lists... 38%
[11:59] <ogra_> *twiddle*
[11:59] <KathyReid> just wanted to note big thanks to popey for his help today. Now running version 121 after flashing. Many thanks.
[12:00] <Laney> looks like it
[12:00] <ogra_> Laney, can we revert that ?
[12:00] <popey> KathyReid: yay
[12:00] <ogra_> it made the image 10M bigger (compressed, i bet its a lot more uncompressed)
[12:00] <Laney> revert, everyone's favourite word
[12:01] <KathyReid> popey: thanks heaps! That command worked a treat.
[12:01] <Laney> let's find out why and then have a look
[12:01] <ogra_> Laney, ok
[12:01]  * ogra_ still sits in front of 38%
[12:02] <ogra_> ahm finally http://paste.ubuntu.com/6755787/
[12:04] <seb128> ogra_, you have your answer then
[12:04] <seb128> Laney, ^
[12:04] <Laney> so it's via opencv
[12:04] <seb128> is that new plugin?
[12:05] <Laney> it's only being built now
[12:05] <ogra_> seems like
[12:06] <seb128> easy solution would be to disable that option
[12:06] <ogra_> right
[12:06] <Laney> is that the right thing to do?
[12:06] <seb128> I don't even know what opencv is
[12:07] <seb128> if we didn't use it until now and it was not an issue I doubt that's something we really need
[12:07] <ogra_> well, you could make it not hard depend on glx/glu on arm
[12:07] <pete-woods> it's a computer vision library for doing feature detection
[12:07] <seb128> yeah, if somebody wants to "fix" opencv that's alright
[12:08] <seb128> not sure how much work that is, I would prefer us to not spend too much efforts on stuff we don't need
[12:08] <ogra_> i'm not concerned by opencv, just by the GL libs that are of no use (and might bend our alternatives in a direction we dont want)
[12:08] <Laney> I think the word 'we' is dangerous in situations like this
[12:08] <Laney> the archive doesn't exist only to support the Ubuntu Touch effort
[12:08] <ogra_> GL and GLU on arm are pointless
[12:09] <rsalveti> ogra_: can you give nested a try with grouper?
[12:09] <Laney> I'm not denying that it's a bug
[12:09] <ogra_> rsalveti, i would love to, my battery misbehaves since i got up ... it still reboots as soon as i unlock the screen (just tried) .... but i plan to once it works again
[12:09] <seb128> Laney, it goes back to the old difference of opinion on whether we should spend ressources on fixing the whole universe (nothing specific to touch, we had the same argument about !desktop before)
[12:10] <rsalveti> ogra_: ok, cool
[12:10] <seb128> Laney, we could spend our life fixing every un-used package in universe, or we can focus on what benefits most users (e.g the default images)
[12:10] <seb128> Laney, but we already have that discussion and agreed that some of us disagree, so let's not have it again
[12:14] <Laney> I'll try disabling opengl on armhf
[12:16] <ogra_> Laney, thanks
[12:16] <Laney> ogra_: I'd appreciate it if you could report a Debian bug about it with rationale
[12:16] <Laney> not something I'm particularly familiar with
[12:17] <ogra_> well, there is no opengl HW on arm so it is pointless ... needs to use gles or should be disabled
[12:18] <ogra_> Laney, i'd like to heard someone like jhodapp on that case first ...
[12:18] <Laney> sounds like a good basis for a report :-)
[12:18] <ogra_> i'm not a graphics guy either :)
[12:18] <Laney> buh
[12:19] <ogra_> (but i know that our (not debians i think) mesa packages fiddle with the alternatives a lot ... my fear is simply that some GL path gets bent in a way that breaks our setup)
[12:21] <pete-woods> didrocks: hi, could ofono-phonesim and ofono-phonesim-autostart have been updated as transitive dependencies of the ones listed in (http://people.canonical.com/~ogra/touch-image-stats/20140113.1.changes) ?
[12:22] <didrocks> pete-woods: no, the only packages that changed on the images are all listed by ogra_'s script
[12:22] <ogra_> pete-woods, then they would be listed
[12:22] <pete-woods> it's just that if I say, install messaging-app-autopilot, it brings in a lot of other packages
[12:23] <pete-woods> including those two I listed
[12:23] <pete-woods> what I mean is, those packages aren't in the image
[12:25] <ogra_> pete-woods, because we dont want to ship all the test packages
[12:25] <ogra_> we'll soon do a cleanup and rip all autopilot stuff out
[12:25] <pete-woods> I don't expect them to be in the image
[12:26] <pete-woods> what I mean is, does the script report version changes in them, as they are not part of the image
[12:26] <ogra_> no
[12:26] <ogra_> the diff gets created for the image manifest files, it only compares image changes
[12:26] <pete-woods> so they could change version, break something, and that script would not list them as potential suspects?
[12:26] <ogra_> right
[12:26] <ogra_> we only care about image changes here
[12:27] <pete-woods> that's fine, I just want to understand the information I've been given
[12:27] <ogra_> if you want external stuff compared i guess QA would have to set something up for this
[12:27] <davmor2> didrocks: I'm in the rss app trying to reproduce the steps bit by bit and the keyboard isn't appearing that might make it trickier to work with I'll reboot and try again from scratch but if that is happening in the test that might explain why it is failing to find a topic it can't type it in
[12:27] <ogra_> walking down the autopilot dependencies and list version changes there or some such
[12:28] <pete-woods> that sounds like a sensible thing to have set-up
[12:28] <pete-woods> it's the dependencies of each of the autopilot test suites we care about
[12:28] <ogra_> right
[12:29] <ogra_> Laney, hmm, looking at CMakeList.txt in opencv i wonder why GL is used at all ...
[12:29] <ogra_> OCV_OPTION(WITH_OPENGL         "Include OpenGL support"                      OFF  IF (NOT ANDROID AND NOT APPLE) )
[12:29] <ogra_> shouldnt that force it off ?
[12:30] <didrocks> davmor2: yeah, then, please join your effort with psivaa with his revert results
[12:30] <ogra_> oh, debian/rules overrides it
[12:31] <Laney> ya
[12:41] <davmor2> psivaa: okay can you run me through this step by step.  Make the phone writable, remove hud, libhud-client, libhud2, then install hud, libhud-client and libhud2 from 13.10.1+14.04.20131205-0ubuntu1 ? does that sound about right and then run the tests on the device if they will let me
[12:44] <psivaa> davmor2: yes, that sounds good for maguro message app test failure
[12:45] <davmor2> psivaa: okay cool thanks
[12:45] <seb128> davmor2, not sure you need to remove, installing the old version should be enough
[12:46] <davmor2> seb128: thanks
[12:53] <ogra_> ah, finally a sign of life from my grouper
[12:57] <tuxylord> hello everybody, i have just installed ubuntu touch, after rebooting the device i dont see anything no log in or something else. The device is a google nexus 10
[13:00] <thostr_> didrocks: we can now reproduce the hud failure... however, it fails also for the old hud :(
[13:01] <thostr_> didrocks: do we have another list of changes happened between the images, not package changes but rather test or setup changes?
[13:01] <didrocks> thostr_: interested, not sure this env variable is linked
[13:02] <didrocks> thostr_: we know messaging_app tests didn't change itself as there was no messaging_app release
[13:02] <didrocks> and the tests are in upstream code
[13:03] <thostr_> any changes to ap itself?
[13:04] <didrocks> you would have seen it in the package list
[13:35] <rsalveti> ogra_: next image should also be a bit faster on grouper, as I added back the hwcomposer
[13:35] <ogra_> rsalveti, whee !
[13:36] <rsalveti> ogra_: but for it to work properly we need mir to land as well
[13:36]  * ogra_ just noticed he had his image default to SF
[13:36] <rsalveti> don't know the current status of that
[13:36] <davmor2> gah!!!!!! why will this test not run damn it
[13:36] <rsalveti> ogra_: system-image?
[13:36] <rsalveti> afaik cdimage is still booting with SF by default
[13:36] <ogra_> rsalveti, we switched it around saucy release
[13:37] <ogra_> the released image had Mir by default
[13:40] <rsalveti> ogra_: right, but just system-image
[13:41] <rsalveti> I flashed cdimage yesterday and it booted with SF
[13:41] <ogra_> oh, indeed
[13:41]  * ogra_ doesnt use that old cruft
[13:41] <rsalveti> I use it when I need to build large packages
[13:47] <ogra_> rsalveti,
[13:47] <ogra_> root@ubuntu-phablet:/# ps ax|grep unity-system
[13:47] <ogra_>  1240 ?        Sl     0:02 unity-system-compositor --file /tmp/mir_socket --from-dm-fd 8 --to-dm-fd 13 --vt 7
[13:47] <ogra_> looks fine
[13:47] <ogra_> UI is up and usable
[13:48] <rsalveti> ogra_: great
[13:48] <ogra_> hmm should the flickering bug be gone ?
[13:49] <ogra_> i dont see any strobe like flickering anymore, thats great
[13:49] <ogra_> ah, there it is
[13:49] <psivaa> davmor2: it could be outdated but some steps in http://pastebin.ubuntu.com/6213423/ might be helpful to run the AP test locally..
[13:49] <ogra_> starting a webapp triggers it again
[13:50] <ogra_> ricmm_, did we have a fix for that in the pipe ? ^^^
[13:50] <davmor2> psivaa: figured it out I was trying to run a specific case rather than the suite D'oh
[13:50] <rsalveti> ogra_: it's already fixed in mir's trunk
[13:50] <psivaa> davmor2: ack
[13:50] <ogra_> rsalveti, ah, thanks
[13:50] <rsalveti> that's why I said we need latest to land
[13:51] <ogra_> yeah
[13:51] <ogra_> didrocks, so i can confirm that all devices now work fine with nested Mir mode, but we need another Mir release to land it then
[13:51] <ricmm_> ogra_: triggers what?
[13:52] <ogra_> ricmm_, strobe like flickering of the display
[13:52] <didrocks> ogra_: ok, it was planned for tomorrow (if we can promote an image today)
[13:52] <ricmm_> on what device
[13:52] <ogra_> ricmm_, grouper
[13:52] <ogra_> ricmm_, seems rsalveti knows about it and there is a fix, so ignore me
[13:53] <ricmm_> you mean apps not launching?
[13:53] <ricmm_> and the shell flickering forever in total edath?
[13:53] <ricmm_> death*
[13:53] <rsalveti> ricmm_: the screenshot issue
[13:53] <ricmm_> right
[13:53] <ogra_> ricmm_, i mean the whole display flickering like a strobe right after i start the first app
[13:53] <ricmm_> yea, its in trunk
[13:53] <ricmm_> lp:mir
[13:53] <ogra_> right
[13:53] <ricmm_> helease it
[13:53] <ogra_> all fine then
[13:53] <ogra_> i wish i could
[13:53] <ricmm_> go fix that rss reader
[13:53] <ogra_> all landings are stopped
[13:54] <ricmm_> I landed like 4 branches yesterday and a large unity-mir patch
[13:54] <ricmm_> and it was flawless
[13:54] <ogra_> ricmm_, awesome, so we'll get that in 8 weeks on the images :P
[13:54] <ricmm_> isnt it just rss reader blocking it?
[13:54] <ogra_> yeah
[13:54] <ricmm_> my packages are in since 128
[13:55] <ricmm_> go fix it then
[13:56] <ricmm_> didrocks: any updates on rss reader? I took a stab at it but frankly I cant see anything obvious from our side of things
[13:56] <didrocks> ricmm_: psivaa is still reverted one by one
[13:56] <didrocks> and davmor2 as well is investigating AFAIK
[13:57] <no-comp> hi folks
[13:57] <no-comp> any success for some of you about using it on galaxy s3 ?
[13:58] <davmor2> didrocks: so I can confirm that I am not getting a failure now on messaging running phablet-test-run -p messaging-app-autopilot messaging_app
[13:58] <didrocks> davmor2: what's the difference with the CI? seems that psivaa is getting the failure quite reliably (and we have it everytime since image 122 on all runs)
[13:59] <davmor2> didrocks: no this is with the reverted hud
[13:59] <psivaa> didrocks: ricmm_: i'm reverting the last bit for the rss reader failure. no luck yet. not sure if any format change in the feeder page could cause this type of failure
[13:59] <didrocks> davmor2: ah ok, sorry, mixed my brain
[13:59] <didrocks> davmor2: thanks for confirming :)
[13:59] <didrocks> thostr_:  ^
[14:00] <didrocks> psivaa: ah, can be…
[14:00] <sergiusens> didrocks, should I hold on the calendar app test changes?
[14:00] <didrocks> sergiusens: yes please, just prepare it so that we can get that in once we can promote an image
[14:01] <psivaa> didrocks: http://www.canonical.com/rss.xml is the link, not sure who maintains that. probably IS?
[14:02] <didrocks> balloons: do you know? ^
[14:02] <sergiusens> didrocks, it's all prepared; just not in store; as in store == in next image
[14:02] <didrocks> sergiusens: ok, perfect, thanks! I'll keep you posted :)
[14:03] <ricmm_> but the test isnt failing at the xml itself
[14:13] <ricmm_> ahhhh
[14:13] <ogra_> ?
[14:14] <ricmm_> didrocks: psivaa the error comes from a format change in the page
[14:14] <ricmm_> the feed name changed from Canonical to Insights
[14:14] <ricmm_> and the autopilot test is poking at a hidden object field
[14:14] <ricmm_> not the visible "Canonical" thats on screen
[14:14] <ricmm_> Ran 1 test in 93.418s
[14:14] <ricmm_> OK
[14:14] <psivaa> phe
[14:14] <psivaa> phew
[14:14] <ogra_> why does the test not use a local feed that autopilot ships ?
[14:14] <ricmm_> you can test by fetching rss.xml from web archive from the 9th
[14:14] <ricmm_> ogra_: because its a broken test
[14:14] <ogra_> obviously
[14:14] <ricmm_> asac: ^
[14:15] <ricmm_> now promote me an image
[14:15] <ogra_> heh
[14:15] <ogra_> ricmm_, http://ci.ubuntu.com/smokeng/trusty/touch/maguro/129:20140115:20140107.1/6080/ ...
[14:15] <cwayne_> can we put a call out to test devs for mocking stuff instead of pulling live unreliable data?
[14:15] <ogra_> calendar app doesnt look good atm
[14:15] <cwayne_> because what if theres a network problem, then all this stuff will fail when the apps themselves may be working just fine..
[14:16] <davmor2> ricmm_: ah that explains it then I was looking at it seeing the canonical and thinking it is right there  you dumb ass app ;)
[14:16] <davmor2> ogra_: that is an issue on the maguro opening and closing the app repeatedly it locks up I discovered that one
[14:16] <ricmm_> so the test is broken in two parts
[14:16] <ricmm_> 1. using the live XML feed
[14:16] <ricmm_> 2. poking at a non-visible QML element
[14:16] <ogra_> davmor2, right, but we cant promote it as is
[14:17] <davmor2> ogra_: but there is no way to easily fix it as it is a massive can of worms of race conditions
[14:17] <jdstrand> sergiusens: I guess its normal that android-emulator is to be removed when installing ubuntu-emulator?
[14:17] <ogra_> lovely
[14:17] <davmor2> ogra_: everyones favourite
[14:18] <ricmm_> davmor2: whats the can of worms?
[14:18] <ricmm_> calendar app breakages?
[14:18] <ogra_> ricmm_, yeah
[14:18] <ricmm_> how come
[14:18] <sergiusens> jdstrand, android-emulator is a virtual package
[14:18] <ricmm_> 128->129 changelog should be null, or very small, no?
[14:18] <davmor2> ogra_: I've manually run the tests and it is fine, it's just when autopilot runs them you get the races
[14:18] <ricmm_> arent landings stopped
[14:18] <ogra_> ricmm_, http://people.canonical.com/~ogra/touch-image-stats/20140115.changes
[14:18] <ricmm_> sure, but why isnt it failing in 128 then
[14:19] <ricmm_> oh thats a few pkgs
[14:19] <jdstrand> ah
[14:19] <sergiusens> jdstrand, it's replaced by ubuntu-emulator-runtime and ubuntu-emulator-[data|images] (forget the exact name); you can safely remove android-emulator and ubuntu-emulator-data
[14:19] <davmor2> ricmm_: you know the bug I pointed you to yesterday  and you said it is a race condition on the unity-app-launcher
[14:19] <ricmm_> yea
[14:19] <ricmm_> oh its the same?
[14:19] <jdstrand> sergiusens: my next question was if you and xnox chatted, but now I don't have to ask that :)
[14:19] <davmor2> and maguro is slow
[14:19] <davmor2> ricmm_: no that is the issue I was looking into
[14:19] <ricmm_> ohhh the breakage is in maguro
[14:19] <ogra_> why is qdbus coming in there is beyond me
[14:19] <ricmm_> sorry I thought it was a new test fail on mako
[14:20] <ricmm_> on 128->129
[14:20] <ricmm_> nvm
[14:20] <ogra_> ricmm_, well, it didnt fail in 128
[14:20] <ricmm_> sure, but it didnt fail because of the race
[14:20] <sergiusens> cwayne_, wrt to mocking, balloons has it on his agenda I think
[14:20] <ricmm_> davmor2: add something to autopilot that makes sure the PID is gone
[14:20] <ricmm_> libupstart-app-launch can get you an APP_ID's running PID
[14:20] <cwayne_> sergiusens, ah, perfect :)
[14:20] <davmor2> ogra_: I ran the tests 10 time of the 10 3 worked
[14:21] <ogra_> davmor2, on 128 or 129 ?
[14:21] <sergiusens> davmor2, opening and closing calendar on the emulator kills it too; I'm looking into why, but it seems I'm running out of RAM; which can only mean that there's some drops of bits leaking
[14:21] <davmor2> ogra_: from 125 on I think
[14:22] <davmor2> ogra_: ^
[14:22] <ricmm_> what I just said makes sense I think
[14:22] <ricmm_> just make autopilot more robust to these things
[14:22] <ogra_> 125 was the one we got the new hud, no ?
[14:23] <davmor2> ogra_: https://bugs.launchpad.net/bugs/1268693 this is the bug for the calendar app
[14:25] <davmor2> ogra_: it's been happening since the new mir landed so it could be a big mismatch, the fact that sergiusens can reproduce on the emulator is a good sign too :)
[14:26] <davmor2> oh n4 is shipped
[14:27] <balloons> sergiusens, did the calendar app land yesterday?
[14:27] <ogra_> davmor2, are you sure that it is only from 125 on ?
[14:28] <ogra_> trhe bug seems to indicate it could be GLES related ... in the 122 image the desktop GL/GLX mesa libs were added (by accident) to the image
[14:28] <davmor2> ogra_:  125 was when I was asked to look into it I think it had been happening from 119 iirc
[14:28] <ogra_> that could cause issues in GLES behavior i suspect
[14:28] <ricmm_> mesa is not loaded on the phone
[14:29] <ogra_> ricmm_, manifest disagrees
[14:29] <ogra_> ricmm_, http://people.canonical.com/~ogra/touch-image-stats/20140110.1.changes
[14:29] <ogra_> libgl1-mesa-glx:armhf
[14:29] <ogra_> libglu1-mesa:armhf
[14:29] <ricmm_> I mean not loaded by mir at any point
[14:29] <fourq> so Galaxy Nexus, and Nexus 4 are the only supported phones atm still?
[14:29] <ogra_> ricmm_, but the postinst scripts of mesa tweak the GL paths etc
[14:30] <ogra_> fourq, soon only N4
[14:30] <fourq> hmm
[14:30] <ricmm_> if hybris EGL wasnt being hit it'd be 100% failure
[14:31] <barry> Mirv: great!  i'll start taking another look
[14:32] <ogra_> ricmm_, /etc/alternatives/armhf-linux-gnu_egl_conf (and friends) tweak the ld searchpaths ...
[14:32] <rsalveti> right, but hybris should be the priority for egl still
[14:32] <ricmm_> yea, otherwise nothing would run
[14:32] <sergiusens> balloons, on hold
[14:32] <ogra_> if thats done for GL (not GLES) on arm you might get funny results
[14:33] <ogra_> because suddenly GL functions are there while they shouldnt (i assume)
[14:33] <ricmm_> thats not how mir works
[14:33] <ogra_> ok
[14:34] <ogra_> i just know it can cause weird things on X
[14:34] <ogra_> and it is pretty low level
[14:34] <sergiusens> balloons, but as soon as it's greenlighted, it will be in
[14:34] <balloons> sergiusens, :-)
[14:35] <s0u][ight> hello, is there currently anyone working on a nexus 7 2013 port?
[14:36] <ogra_> s0u][ight, yes
[14:36] <sergiusens> s0u][ight, yes, since that is going to be the focused platform
[14:36] <ogra_> it will become the default tablet platform soon
[14:36] <ogra_> (dropping all other tablets)
[14:36] <s0u][ight> where can I find information about the port status?
[14:36] <ogra_> here :)
[14:37] <s0u][ight> alright, what is the port status?
[14:37] <ogra_> s0u][ight, rsalveti currently works on porting the android tree to 4.4 ... once that is done the work for building an image for that device will start
[14:38] <ogra_> you should see first images within 1-2 weeks (rough guess)
[14:38] <s0u][ight> is it going to be CM based again, or aosp?
[14:38] <ogra_> aosp
[14:38] <s0u][ight> why the change?
[14:39] <ogra_> easier to track ... there will be a CM branch too iirc
[14:39] <s0u][ight> alright
[14:39] <rsalveti> aosp but we'll also be publishing a Cm based branch
[14:40] <rsalveti> but I already ported most of the important stuff from CM into our aosp branch
[14:40] <rsalveti> so it's really easy to add a new device in there
[14:40] <s0u][ight> I have a bluetooth keyboard and I attach a mouse via usb otg, could I use my tablet as a desktop once the port is there?
[14:40] <ogra_> no
[14:41] <ogra_> unity8 doesnt come with any desktop yet
[14:42] <s0u][ight> are there any roadplans to allow this?
[14:42] <s0u][ight> btw, am I bothering with these questions?
[14:42] <s0u][ight> rsalveti: why having an aosp and cm branch?
[14:43] <rsalveti> s0u][ight: aosp will be the official one, CM is just to make it easier for porters
[14:43] <rsalveti> but we might just be good with aosp only, still need to check what is CM specific
[14:44] <s0u][ight> thanks for answering
[14:44] <s0u][ight> what is your current status?
[14:45] <cwayne_> speaking of porters
[14:45] <cwayne_> are we going to have a way to flash community images with phablet-flash?
[14:46] <cwayne_> i.e. is there going to be a system-image for not-supported-by-us images?
[14:47] <sergiusens> cwayne_, image server you mean?
[14:47] <cwayne_> yeah
[14:47] <ogra_> cwayne_, stgraber was working on that before the holidays i think
[14:47] <rsalveti> cwayne: yes, the idea is to have unsupported channels that would allow people to use phablet-flash to download it
[14:47] <ogra_> afaik the signing is still an issue
[14:47] <sergiusens> use ubuntu-device-flash if you can and drop phablet-flash :-)
[14:48] <cwayne_> sergiusens, ooh, fancy :)
[14:48] <no-comp> hi folks, what is the best phone to get for have the less bug experience using ubuntu touch?
[14:48] <cwayne_> does it have the --alternate-server capability too still?
[14:48] <ogra_> no-comp, nexus 4
[14:49] <no-comp> thxx ogra_
[14:49] <no-comp> on gs3 it s useless
[14:49] <no-comp> freezing white screen bummer
[14:49] <ogra_> no-comp, patches gracefully accepted ;)
[14:49] <no-comp> it s not working on nexus 5 ?
[14:49] <cwayne_> ogra_, yeah, the signing is what concerned me the most, hopefully we find an easy way to figure it out :)
[14:49] <no-comp> i bet ogra_  ;)
[14:49] <sergiusens> cwayne_, that said; there's a --server option and you can always play with --channel
[14:49] <ogra_> nope, nexus4 is our default device atm
[14:49] <no-comp> thxx a lot
[14:49] <no-comp> i gonna get one
[14:49] <no-comp> gosh
[14:49] <ogra_> and the android bits we use are not on kitkat yet
[14:49] <sergiusens> cwayne_, my though is to have an unsupported-devel-proposed channel
[14:50] <no-comp> am i leaving android after all this years? feel like cheating
[14:50] <ogra_> once they are there nexus5 community support will be possible
[14:50] <sergiusens> cwayne_, ogra_ we can always disable signing for community ports if they don't care for it
[14:50] <sergiusens> as part of the port
[14:51] <ogra_> sergiusens, well, not sure, does our recovery mode script support that ?
[14:51] <ogra_> i thought it didnt yet
[14:51] <sergiusens> ogra_, it lives in the android tree, so it could be done as porting work
[14:51] <cwayne_> we'd have to disable it in the recovery image
[14:51] <ogra_> cwayne_, well, as i understood stgraber he tries to make it work for the server side so that users can use their own keys
[14:52] <ogra_> and run their own server
[14:52] <ogra_> so before we drop security in recovery we should first talk to him i guess ;)
[14:53] <cwayne_> good call ogra_ :)
[14:54] <stgraber> I actually have a working branch for that, it just lacks test coverage so can't be merged yet but I believe there's just 50-60 lines of code to cover with tests at this point before I merge it
[14:54] <cwayne_> sergiusens, hm, should ubuntu-device-flash --list-channels supposed to work?
[14:59] <sergiusens> cwayne_, it use to, let me check
[15:00] <sergiusens> cwayne_, it does; you just need to specify a device
[15:00] <sergiusens> or attach one
[15:01] <cwayne_> sergiusens, ah, ok thanks
[15:01] <cwayne_> that's what i i was missing :)
[15:09] <asac> ricmm_: awesome... if thats rssreader tell balloons
[15:09] <asac> he is happy to know how to fix things
[15:10] <asac> ricmm_: was it easy to find by just sitting down and looking at the code while runnig it?
[15:10] <asac> :)
[15:12] <ogra_> asac, he found it by looking at the feed on canonical.com
[15:13] <balloons> are you talking about the blog feed name being different? I've changed that, but working on not having the hardcoded values :-)
[15:13] <maor-israel> hello
[15:14] <ricmm_> can we not use a live XML ?
[15:14] <ogra_> balloons, well, the issue is mainly that a test actually uses an external source
[15:14] <ogra_> we need some autopilot web service that runs locally for such tests
[15:14] <maor-israel> is there anyone that can help me port to galaxy s3?
[15:14] <balloons> well, yes that's quite an issue indeed
[15:14] <asac> balloons: you shot yourself in the food and couldnt find that this broke your own tests, really? :P
[15:15] <asac> sorry... had to make a punt like that
[15:15] <asac> hehe
[15:15] <maor-israel> is there anyone that can help me port to galaxy s3?
[15:15] <ogra_> !ask maor-israel
[15:15] <maor-israel> sry
[15:15] <ogra_> !ask |maor-israel
[15:16] <ogra_> ask about your actual problem :)
[15:16] <ogra_> what works or doesnt with porting ... where do you need help etc
[15:16] <maor-israel>  my problam is that i want ubunu on my galaxy s3 !!  hhhh :)
[15:16] <maor-israel> and on my note 3
[15:16] <ogra_> !devices
[15:17] <ogra_> i think there is already some effort to port to the S3 ... see the wikipage above
[15:17] <ogra_> that should link to an xda forum thread
[15:17] <maor-israel> there was
[15:17] <maor-israel> but closed
[15:17] <maor-israel> i tryied but failed
[15:19] <ogra_> well, the link to the porting guide is in the channel topic ... if you grab the trees from the discontinued port from xda you might be able to improve it or so
[15:20] <maor-israel> to hard
[15:20] <balloons> you might also try asking on the mailing list or searching it to see if someone else has a device. In general, if you want the port, it would be helpful to try and resurrect the existing work and keep going
[15:20] <maor-israel> i gave it a shot but failed
[15:21] <maor-israel> how can i take his work and use the new image
[15:22] <maor-israel> i need to recompile it no?
[15:26] <ogra_> yes
[15:26] <maor-israel> to hard hhhhh
[15:26] <cwayne_> sergiusens, btw great job on the ubuntu-emulator, works like a charm :)
[15:26] <ogra_> take the recent ubuntu tree, add his changes, fix what is not building, uild and try it
[15:28] <maor-israel> sound easy
[15:28] <maor-israel> jj
[15:28] <maor-israel> hh
[15:28] <asac> balloons: well, we asked you to check why rssreader regressed. sound there we didnt know... so we were trying to bisect package changes etc. for you
[15:42] <tvoss_> mzanetti, ping
[15:43] <mzanetti> tvoss_: hey
[15:48] <sergiusens> cwayne_, thanks
[15:48] <sergiusens> couple of improvements in my list already
[15:50] <Wellark_> didrocks, psivaa, davmor2: one question. did you try to run the messaging-app autopilot tests straight after cold boot?
[15:50] <Wellark_> I can repro the ap failure using the emulator
[15:50] <didrocks> Wellark_: from what I know, the CI machinery always reboot and run them
[15:51] <Wellark_> straight of from cold boot
[15:51] <Wellark_> but if the emulator sits idle for couple of minutes before running the tests the problem goes away
[15:51] <balloons> ty sergiusens.. I believe you have notes on the actions to take, but if you need them, I wrote them down :-)
[15:51] <Wellark_> I also tried to increase the timeout and that allowed the tests to pass even straight off the cold boot
[15:51] <Wellark_> http://pastebin.ubuntu.com/6756622/
[15:52] <Wellark_> just compare the numbers.. above is straight after cold boot and below is on an idle system
[15:52] <sergiusens> balloons, thanks, I have notes yup; feel free to add them to the document I linked; it's a scratchpad more than anything :-)
[15:52] <Wellark_> looking at top the system is under very heavy load when the greeter becomes visible
[15:53] <Wellark_> and stays so for a long time
[15:53] <sergiusens> balloons, copied from my local zim :-)
[15:53] <balloons> sergiusens, no permissions :-)
[15:53] <Wellark_> pete-woods tested on n4 and the even straight from cold boot the tests only took around 30 secs
[15:54] <sergiusens> balloons, fixed
[15:58] <pete-woods> didrocks: this load issue really does seem to be the culprit - I think it only happens for the messaging app because for some reason that makes the usermetrics service crash on maguro
[15:58] <Wellark_> which trickers apport
[15:58] <pete-woods> yes
[15:58] <Wellark_> which brings the device down to it's knees
[15:58] <Wellark_> but the same can be observer on the emulator also
[15:59] <Wellark_> the system is under heavy load for a long time after unity8 becomes available
[16:00] <sergiusens> Wellark, the autopilot 10s timeout you mean?
[16:01] <Wellark> sergiusens: yes
[16:01] <Wellark> it's not enough
[16:02] <sergiusens> Wellark, agree; causes havok on emulator :-)
[16:03] <didrocks> pete-woods: Wellark: well spot, more than possible
[16:03] <cwayne_> i see a lot of failures on touch_custom due to the 10s timeout btw
[16:29] <Wellark> didrocks: so, what needs to happen so that we get the newer hud back to the image?
[16:29] <Wellark> pete-woods worked hard to get that done :)
[16:29] <j0chn> Hi
[16:30] <j0chn> need help installing ubuntu touch on galaxy nexus
[16:30] <didrocks> Wellark: I guess fixing the usermetrics service crash, then trying to bring back the new hud and running the test on maguro again
[16:30] <j0chn> I use the manual download and installation guide
[16:31] <j0chn> the fastboot flashes (recovery/boot/system) seem to work fine
[16:31] <j0chn> But when I have to push the files for autodeploy there is a problem
[16:31] <j0chn> adb push trusty-preinstalled-touch-armel+maguro.zip /sdcard/autodeploy.zip
[16:31] <Wellark> didrocks: buts, it's a load issue. not caused by the hud itself
[16:32] <j0chn> than I reboot to recovery and nothing happens. The screen is just black (and keeps being black)
[16:32] <j0chn> And without taking off the baetterie I can't restart the phone
[16:33] <didrocks> Wellark: better if we have a test to proove it in that case and workaround it if possible
[16:33] <j0chn> I already had a working version flashed on the Nexus but unfortunatly the usb connection got lost when I updated the phone.
[16:33] <didrocks> Wellark: but I guess that the load is due to the collect of usermetrics service crashing
[16:33] <didrocks> Wellark: and it's not crashing due to load, right?
[16:33] <j0chn> And I try to flash the version 20140114
[16:34] <ogra_> j0chn, might be that the manual installl does not work anymore
[16:34] <Wellark> didrocks: sure. usermetrics thing is separate issue, hud is not even interacting with it in any way
[16:34] <ogra_> i dont think anyone tested it in a while since we dont really support that anymore
[16:35] <j0chn> Than I should use "phablet-flash"?
[16:35] <Wellark> but there is no way to write a test that proves that we have timeout because of load issues, is there? :)
[16:35] <didrocks> Wellark: so, to not introduce a failing tests, I would suggest to fix the usemetrics so that we can introduce hud without getting this load issue side-effect making the test failing
[16:35] <didrocks> especially nice as usptream for both is the same guy :)
[16:35] <ogra_> j0chn, you might be able to tell it to flash by selecting the zip via the menu in recovery
[16:35] <ogra_> but yeah, phablet-flash is the preferred method
[16:36] <j0chn> Nice idea.. I will try the recovery flash first
[16:37] <j0chn> Okay, manual flash from recovery mode doesnt work
[16:38] <ogra_> well, then it is phablet-flash ...
[16:38] <Wellark> didrocks: well, sure :)
[16:39] <Wellark> let's just hope some other tests are not starting fail on completely irrelevant changes just because the load situation gets worse
[16:40] <j0chn> what is the parameter "bootstrap" for?
[16:40] <ogra_> wipe everything
[16:41] <j0chn> nice
[16:42] <j0chn> Okay, just to get sure "phablet-flash --channel devel --bootstrap --no-backup"
[16:42] <j0chn> This will do a full wipe without any backups and the newest ubuntu touch version
[17:02] <jdstrand> sergiusens: is 'adb shell' supposed to work with ubuntu-emulator? I see this in the conole output:
[17:02] <jdstrand> init: cannot find '/sbin/adbd', disabling 'adbd'
[17:02] <sergiusens> jdstrand, that's from android; as in android adbd
[17:02] <jdstrand> ok
[17:02] <sergiusens> jdstrand, ubuntu's should work
[17:02] <sergiusens> once it loads
[17:02] <jdstrand> I'll continue to be patient then
[17:03] <jdstrand> we have some patches to apparmor_parser that should cut the parser time roughly in half on the emulator
[17:03] <sergiusens> jdstrand, that would be awesome!
[17:03] <jdstrand> which is actually what I'm trying to test right now :)
[17:04] <jdstrand> it is still going to be slow though
[17:04] <jdstrand> the arm emulator is just painful
[17:04] <jdstrand> x86 will be great though
[17:04] <jdstrand> (painful wrt the apparmor parser that is)
[17:24] <sergiusens> jdstrand, x86 is coming soon; we'll know sooner what soon means as soon as 4.4 is in tree
[17:24]  * sergiusens used soon a lot :-)
[17:26] <ogra_> sergiusens, i was about to say soon that you are using soon a lot
[17:36] <jdstrand> hehe
[17:43] <daker> Laney: hi i commented on bug 1265250
[17:43] <Laney> ty
[17:43] <daker> Laney: without --all argument it shows only one entry
[17:44] <daker> and with --all it shows two entries
[17:44] <Laney> we'll need to decide how to handle it
[17:44] <Laney> because if you have two versions then they are both taking up space
[17:46] <daker> Laney: yes one in /usr/share/click/preinstalled/com.ubuntu.notes/ and one in /opt/click.ubuntu.com/com.ubuntu.notes
[17:46] <daker> Laney: this will happen to all preinstalled apps
[17:47] <Laney> right
[17:47] <daker> once they are updated the first time using the update manager they will be shown twice in the storage panel
[17:48] <Laney> I understand the issue
[17:48] <daker> Laney: should i comment on the bug report ?
[17:48] <Laney> no, it's fine thank you
[17:49] <daker> ok
[18:18] <Hashcode> arcee: ping
[18:43] <slangasek> feh, why does qtbase5-dev ship windows.h on Linux systems
[18:45] <slangasek> qt_windows.h, rather
[18:45] <j0chn> I want to install samsung galaxy nexus driver on ubuntu 12.04 but I donÄt know how ^ Can you help me.?
[18:57] <kdub> whats the magic command to remount /system read-write?
[18:59] <pmcgowan> kdub, adb shell mount -o remount,rw /
[19:01] <kdub> didn't work, something I don't understand is going on with the mounts and lxc
[19:01] <kdub> pmcgowan, thanks though
[19:01] <pmcgowan> kdub, huh, works for me here, oh well
[19:21] <kdub> ah, figured out the fstab-updating scripts
[20:03] <nps1985> any info on ubuntu for s2?
[20:09] <balloons> ping kenvandine
[20:09] <kenvandine> balloons, pong
[20:10] <balloons> kenvandine, afternoon :-) So, looking at getting reminders up onto the dashboard and need a way to mock having setup an evernote account in online accounts. Is there an easy way for us to write the db entry or use an api to do this?
[20:11] <kenvandine> balloons, i'm sure there's a way, but best to talk to mardy
[20:12] <balloons> ahh.. might be a bit late for mardy. thank ken
[20:12] <kenvandine> yeah
[20:12] <kenvandine> catch him in the morning
[20:28] <shiggitay> !devices
[20:28] <shiggitay> heh
[20:36] <cwayne_> stgraber, ping, how is the device tarball applied?
[20:40] <j0chn> Hi there.
[20:41] <j0chn> What do I do when I plugin my Nexus one (Ubunto Touch ist flashed) into a Computer with Ubuntu 12.04 and I can't acces the phone via adb?!
[20:42] <ogra_> whats your error ?
[20:43] <j0chn> Well I plugin my device (Ubuntu Touch 14.04) into my PC (Ubuntu Desktop 12.04) and my phone is not recognized... I don't need mtp or something. I just want to acces the phone via adb.
[20:44] <ogra_> well, you must get an error or something when you try to access it via adb, how else would you know it does not work
[20:45] <j0chn> When I use "adb devices" there is a line "list of attached devices" and then there is an empty line and then the command prompt appears
[20:46] <ogra_> ok
[20:46] <ogra_> (thats a lot more helpful than "doesnt work")
[20:46] <stgraber> cwayne_: in the same way as all the other tarballs, with the exception that entries under partitions/ are flashed to the matching block device
[20:46] <vorach> hello every body
[20:46] <j0chn> :D
[20:46] <ogra_> j0chn, try that: adb kill-server; sudo adb start-server ... then check again ... could be a permission issue
[20:47] <j0chn> Same problem ;/
[20:47] <vorach>  i read thar thé gnexus have be stopped ?
[20:47] <cwayne_> stgraber, so there's no reason that we couldn't have *everything* device-specific in that device tarball? (i.e. we could put /etc/init/bluetooth-touch-maguro.conf in the maguro device tarball)?
[20:47] <ogra_> hm, but you see the ubuntu touch UI on screen ?
[20:49] <ogra_> (adb is permanently enabled and starts before the UI gets started so it should always be accessible)
[20:49] <stgraber> cwayne_: that was actually the intent of that tarball, but we haven't put a lot of efforts into moving other device-specific files to it
[20:49] <j0chn> My devices is botted into Ubuntu Touch, so when I short press the power buttin I see the "lock-screen"
[20:49] <vorach>  it's possible to stop vibration on maguro with thé last dev build
[20:50] <cwayne_> stgraber, ah! wonderful.  well that just solves pretty much all of our problems here :)
[20:51] <stgraber> cwayne_: one thing though, you need to make sure you never touch a file which also exists in the ubuntu tarball
[20:51] <j0chn> I started the adb server and rebooted my phone. Still not working.
[20:51] <stgraber> cwayne_: if you do that for some reason, you'll need to make sure that file is in all updates of the device tarball, even if it didn't change
[20:51] <achiang> doanac: hi, it's no rush, but at some point, can you please take a look - https://code.launchpad.net/~achiang/ubuntu-test-cases/savilerow/+merge/201849
[20:52] <stgraber> cwayne_: otherwise, if the file changed in the ubuntu tarball and not in yours, the device would be updated back to the ubuntu one and not the device-specific one
[20:52] <stgraber> (sorry, if that gives you a headache, haven't found a better way to explain it ;))
[20:52] <achiang> cwayne_: that sounds like we need a linter or test case...
[20:52] <j0chn> Ubuntu on my PC is a clean installation. I just upgraded it and installed adb fasboot and phablet.
[20:52] <achiang> stgraber: how is the device tarball created? we could write some linter that runs automatically in there
[20:53] <ogra_> j0chn, check with: dmesg | tail
[20:54] <ogra_> when you plug in, if the phone is recognized at all
[20:54] <j0chn> What do I have to look for?
[20:55] <ogra_> well, you should see lines talking about your phone
[20:55] <j0chn> shall I paste it here? ^
[20:56] <ogra_> no, usea a pastebin
[20:56] <ogra_> should look something like this http://paste.ubuntu.com/6758383/
[20:56] <stgraber> achiang: it's currently generated by loading 3 files from the filesystem (the android system image, the boot image and the recovery image). So that code would need to be changed a bit to load extra files into the tarball, probably with a bit telling it whether those files should always be included (even if they didn't change between two images) or not.
[20:57] <j0chn> http://paste.ubuntu.com/6758391/
[20:57] <ogra_> j0chn, that doesnt look like your USB was even recognized
[20:57] <achiang> stgraber: is writing some sort of automated checker/warner something we should investigate?
[20:57] <ogra_> j0chn, are you sure the cable is ok ?
[20:57] <j0chn> I thought so when I saw your paste :/
[20:57] <achiang> stgraber: and by "we" i mean my team? (vs you taking it on... ;)
[20:58] <ogra_> even if adb wouldnt run on the phone you should see some USB even there
[20:58] <ogra_> *event
[20:58] <j0chn> Well not 100% but on Windows the cable works.
[20:58] <stgraber> achiang: I don't really see the value of adding a check which would basically say "sucks to be you" with no real way to recover from it
[20:59] <stgraber> achiang: because the way system-image works, you won't be able to catch that kind of problem when the image is generated
[20:59] <achiang> stgraber: maybe i am not understanding correctly then.... ok, your 2nd sentence explains it :-/
[20:59] <stgraber> achiang: but later on at any point you try to make a delta with that image, with some of those deltas resulting in the conflict and some others not
[21:00] <achiang> stgraber: i was hoping to write some sort of tool that could run during image generation time
[21:00] <ogra_> j0chn, well, to me this looks more like some physical error than anything with ubuntu touch, try a different USB port, if you have try a different cable etc
[21:00] <stgraber> achiang: running during image creation time won't do you any good as it can't possibly predict what will be added in the ubuntu tarball a month from now
[21:00] <cwayne_> stgraber, so that's the only limitation? other than that it can put any file anywhere on the filesystem?
[21:01] <stgraber> achiang: and the problem happens when a month from now, the same file path you have in your device tarball gets added to the ubuntu tarball and you device gets a delta update suddenly changing a device-specific file, bricking it in the process
[21:01] <j0chn> Another USB Port worked... not I have an Error: Unable to open MTP device [usb:001,011]
[21:01] <j0chn> Ha, strange thing :D
[21:01] <achiang> stgraber: i agree we can't predict the future, but i do think that running some check during image creation time has value to prevent stupid/silly mistakes by an OEM engineer or someone on my team
[21:02] <ogra_> j0chn, awesome, yeah there are still some bugs with MTP, ignore that one :) adb should definitely work now
[21:02] <j0chn> Ok wait I will try
[21:03] <j0chn> still no devices listed :/
[21:03] <stgraber> cwayne_: instead, I think we should go with something like we did for the custom tarball, that's a specific path which is guaranteed to never be in the ubuntu tarball
[21:03] <cwayne_> stgraber, right, but then we'd have to patch stuff to look for stuff in that path (i.e. upstart)
[21:04] <cwayne_> (which is probably fine, but some effort is required of course)
[21:04] <ogra_> cwayne_, patching upstart ??
[21:04] <ogra_> what kind of customization do you plan there
[21:05] <stgraber> cwayne_: so I guess the question is what kind of stuff do we want in there
[21:05] <ogra_> why would you patch distro binaries
[21:05] <ogra_> (instead of just changing them in the distro)
[21:05] <stgraber> ogra_: he's saying that if we only allow the device tarball to write files to say /device/, upstart won't know to go look in /device/etc/init
[21:06] <ogra_> stgraber, right, so a patch for this (probably a kernel cmdline option or whatever that enables it) should happen in the distro
[21:06] <ogra_> not by replacing stuff from the tarball
[21:06] <mterry> rsalveti, thanks for uploading that libhybris fix, btw
[21:06] <achiang> ogra_: you'd need to patch upstart to know to look in /device/etc/init
[21:06] <stgraber> ogra_: I don't think he said he'd replace upstart itself in the tarball, just that we'd need to change upstart in the distro to support that
[21:07] <ogra_> achiang, right, but not from the customization tarball
[21:07] <ogra_> stgraber, oh, then i misunderstood
[21:07] <stgraber> cwayne_: anyway, it all really depends on exactly what you need. I basically see 3 options, trying from the easiest to the hardest:
[21:07] <achiang> ogra_: right. we're talking about patching stuff in the distro
[21:07] <ogra_> thogh i dont get whats wrong with just using .override files instead of introducing an additional path for the jobs
[21:08] <j0chn> thanks for your help ogra
[21:08] <j0chn> but im of fnow
[21:08] <j0chn> cu and thanks
[21:08] <ogra_> j0chn, ok, come back and we'll get that sorted
[21:08] <achiang> ogra_: how can we install .override files if /etc is ro?
[21:09] <stgraber> 1) Add another tarball (so not in the device tarball) which is similar to the version tarball, meaning that it'll always be part of an update so long as one of the other tarballs changed. That's the easiest way to implement it, those files will always be dumped on the device and can't be overriden by anything. Downside is that you need to grab and unpack them with every single update (so no multi-MB files in there).
[21:09] <ds2> is there a specific repo that the current dev images are coming from?
[21:09] <ds2> repo in the generic sense... not in the sense of the 'repo' tool
[21:09] <ogra_> ds2, nope, all from the archive
[21:09] <rsalveti> mterry: no worries, latest image should also bring hwcomposer support for grouper, which makes it a bit faster
[21:09] <ds2> so there is no "label" archive?
[21:09] <stgraber> 2) Use the device tarball, and make very sure never to have a conflict with the ubuntu rootfs (probably easier said than done).
[21:10] <ds2> ogra: what about for the kernel? none of the archives seems to have the kernel that is in the images
[21:10] <ogra_> ds2, nope, its all in the ubuntu archive
[21:10] <rsalveti> mterry: still waiting latest mir to have a fully working shell though (the freeze when moving back to shell after opening an app)
[21:10] <stgraber> 3) Use the device tarball, but in the same way as the custom tarball, with everything going in a single directory which is guaranteed never to be part of the ubuntu rootfs
[21:10] <rsalveti> but that should happen later this week
[21:10] <ogra_> ds2, look for linux-$device
[21:10] <ds2> which one?
[21:10] <ogra_> ds2, i.e. linux-mako for nexus4
[21:10] <rsalveti> ds2: every kernel we use is available in the archive
[21:10] <rsalveti> mako, grouper, goldfish, manta and maguro
[21:11] <ds2> so this is wrong -
[21:11] <ogra_> right
[21:11] <ds2>         url = git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git
[21:11] <ds2> ?
[21:11] <ogra_> no
[21:11] <ds2> am I on the right server at least?
[21:11] <rsalveti> that's right, but you need the correct branch as well (if you're looking for the sources)
[21:11] <ogra_> thats the source path from which these kernel packages are built from
[21:11] <ds2> yes, I am banging my head looking all over for the source
[21:11] <ds2> the current kernel shows up as 3.0.0-3-maguro
[21:12] <ogra_> thats right
[21:12] <ds2> but I find no 3.0.0-3 kernel tag. everything is 3.0.31
[21:12] <cwayne_> stgraber, 3) sounds the safest to me, although also potentially the most work :)
[21:13] <rsalveti> ds2: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=shortlog;h=refs/heads/maguro
[21:13] <rsalveti> major is -3
[21:13] <ds2> is this the branch it is suppose to be - remotes/origin/maguro?
[21:13] <stgraber> cwayne_: well, technically 1) is the safest and easiest, if you can afford it
[21:13] <cwayne_> stgraber, right, but that seems a bit much imho, if we already have a tarball per-device, we should probably use it
[21:14] <achiang> stgraber: cwayne_: we can't predict the future there either. at this point, we don't have a good understanding of everything an OEM might want to customize
[21:14] <achiang> stgraber: cwayne_: so we can't promise "no big MB files" in the new tarball
[21:14] <cwayne_> right
[21:14] <ds2> rsalveti: but the Makefile says that is 3.0.31
[21:15] <stgraber> achiang: well, I was under the impression that all we were discussing here was strictly for device enablement, if that was resulting in multi-MB files, something would be very wrong
[21:15] <ds2> commit 10819b10b94b22be0d15734652c6c1c68b95122a (HEAD, origin/maguro)
[21:15] <stgraber> achiang: if an OEM wants to customize the device, they should use the customization tarball for that
[21:15] <ds2> grep SUBLEVEL Makefile
[21:15] <ds2> SUBLEVEL = 31
[21:15] <ds2> is there some other renaming going on? uname -a claims it is 3.0.0-3
[21:15] <rsalveti> ds2: right, the packaging version is not fully in sync
[21:15] <rsalveti> but it's the same kernel
[21:16] <achiang> stgraber: i guess i don't know the scope of the types of files we'd need for just "device enablement"
[21:16] <ds2> rsalveti: uname -a should be indepedent of the packaging or have I missed something?
[21:16] <stgraber> cwayne_: there's not much overhead in adding an extra tarball really, on the generation side, it's just a line in a conffile, it doesn't impact upgrade path calculation speed, so it's just down to the extra download and unpack size, which are < second if you're doing things right and don't have massive files in there.
[21:16] <stgraber> achiang: ok
[21:16] <rsalveti> ds2: uname will show whatever comes from the packaging I guess
[21:17] <rsalveti> from the packaging rules
[21:17] <ogra_> yeah
[21:17] <ds2> rsalveti: interesting...that must be a Ubuntu specific patch
[21:17] <ogra_> would be weird if it didnt
[21:17] <ds2> or config
[21:17] <rsalveti> yup
[21:17] <stgraber> achiang: the problem with that is that you don't know what you'll need to hook into either, which makes 3) pretty difficult as we won't go patching random bits of Ubuntu post-release to accomodate it
[21:17] <ogra_> else you could never tell the kernel package version from uname
[21:18] <ds2> so I have no way of rebuilding the kernel without pulling in all of the CM stuff oh phablet?
[21:18] <achiang> cwayne_: maybe we should do some homework to figure out exactly what type of files might need to live in this new tarball
[21:18] <ogra_> (which is i.e. used in bug reports etc)
[21:18] <achiang> cwayne_: we also need to get ondra involved in this conversation
[21:18] <ds2> what is odd is there is no tag for 3.0.0-3 either
[21:18] <achiang> stgraber: sure, i think that is a reasonable stance to take
[21:19] <achiang> stgraber: i do like the idea of localizing all the device-specific stuff into a separate filesystem namespace / hierarchy though. makes it quite obvious to someone inspecting the system what is going on
[21:20] <stgraber> achiang: so yeah, I think it'd be best if you could come up with a list of files that you need to get on the device, then we can see how to best distribute those.
[21:20] <ogra_> ds2, ask #ubuntu-kernel, there are some policies, i'm sure they are documented
[21:20] <ds2> 'k thanks
[21:20] <rsalveti> ds2: you can cross build just the kernel
[21:20] <stgraber> achiang: FWIW, for the current devices, the amount of device-specific data in the rootfs (so outside the system tarball) is < 100K
[21:20] <stgraber> achiang: (just some udev rules)
[21:20] <ds2> rsalveti: I am trying to do that.. .but I am coming up with a 3.0.31 uname
[21:21] <ds2> rsalveti: which apparently breaks the graphics stuff
[21:21] <cwayne_> stgraber, right, but there's some stuff in the rootfs that shouldn't be
[21:21] <rsalveti> ds2: using the same tree with same config?
[21:21] <cwayne_> although it's quite small
[21:21] <ds2> rsalveti: yes. I used that tree at that point + the config from /proc/config.gz
[21:21] <achiang> stgraber: ok, good to know. it's just an extra tarball is one more thing to fail... also, i am trying to minimize the complexity of what it's like to actually work on ubuntu for our OEMs
[21:21] <ds2> ultimately, the problem for me is the firmware loader is broken
[21:21] <rsalveti> ds2: you can also find the config at http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=blob;f=debian.maguro/config/config.common.ubuntu;h=e1440b73df25fdc231bbade51fe806eb9b3db9e0;hb=refs/heads/maguro
[21:22] <achiang> stgraber: "one more thing to understand / manage / maintain" ... trying to keep those to a minimum
[21:22] <rsalveti> ds2: hm, that's weird
[21:22] <stgraber> achiang: such as? The only thing that I'm aware of is a per-device udev rule file, if there's more, I'd like to know so I can go complain about it (I really hate having device-specific data in our rootfs)
[21:22] <ogra_> ds2, apt-get source linux-image-3.0.0-3-maguro ... and https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile ... is what i usually use
[21:22] <cwayne_> achiang, that's why i think we should try to contain everything device-related in the 'device' tarball
[21:22] <ds2> orga_: can't do that since the read only mounts on the ubuntu touch image is read only
[21:22] <ds2> not just root but other bits
[21:22] <cwayne_> stgraber, see my email to ubuntu-phone (device-specific configs in debs)
[21:23] <ogra_> ds2, ? i'm talking about your desktop
[21:23] <stgraber> well, I expect the typical private server to have: ubuntu, device, customization, keyring and version
[21:23] <cwayne_> stgraber, it's some upstart jobs for bluetooth, apparmor policies, ubuntu-touch-session.d/whatever
[21:23] <achiang> stgraber: i am thinking about the overall design we are presenting to OEMs... "X files go in this tarball, Y files go in that tarball... and now Z files go into this OTHER tarball"
[21:23] <stgraber> so at this point, you already need to make sure your OEM understands how the update system works
[21:23] <ds2> ogra_: that will grab the right thing?
[21:23] <stgraber> at which point, one tarball more or less shouldn't make a huge difference :)
[21:23] <ogra_> ds2, should, yeah ... then just follow the corss building wiki
[21:23] <achiang> stgraber: we are trying to be simpler/better than android
[21:24] <achiang> cwayne_: is there more homework to do beyond the mail you already sent?
[21:24] <ds2> orga_: do I need a PPA or something? cuz I just tried it and it fails -
[21:24] <ds2> E: Unable to find a source package for linux-image-3.0.0-3-maguro
[21:24] <ogra_> ds2, what release are you on
[21:25] <cwayne_> achiang, well, we'd have to figure out what kind of device-specific files we might need, and what if anything would require patching to look in a separate dir for device-specific stuff
[21:25] <cwayne_> (off the top of my head, apparmor and upstart)
[21:25] <ds2> Ubuntu 12.04.3 LTS \n \l
[21:25] <ds2> per /etc/issue
[21:25] <ogra_> ds2, we only have that package since saucy ... you would need some saucy or trusty deb-src lines in your sources.list
[21:25] <ogra_> ah
[21:26] <ogra_> ds2, https://launchpad.net/ubuntu/saucy/+source/linux-maguro/3.0.0-3.18
[21:26] <achiang> cwayne_: ok, so please go do that extra homework so this conversation can move from theoretical to actual problem solving
[21:27] <ogra_> you can grab it from there
[21:27] <cwayne_> achiang, yep, already making a KB card :)
[21:27] <ds2> wget'ing it...let see what that does
[21:28] <ogra_> ds2, btw, dont expect any firmware loading on the ubuntu side ... this is explicitly disabled
[21:28] <ogra_> we rely on the android container to DTRT
[21:28] <ds2> ogra_: that's fine... if I can rebuild it, I can work around that
[21:28] <ogra_> since thats in fact our HW layer
[21:29] <ds2> orga_: is that a debian ism?
[21:29] <ogra_> what ?
[21:29] <ogra_> to leave firmware loading to android ? no :)
[21:29] <ds2> firmware loading
[21:29] <ogra_> we run effectively two systems
[21:29] <ds2> or you mean the container is disallowed from loading firmware?
[21:29] <ogra_> ubuntu as the main OS and the android container with the android HAL to drive the binary blobs
[21:30] <ogra_> if you let udev as well as ueventd both handle the firmware loading you will cause crashes
[21:30] <ogra_> only one can  load the fw
[21:30] <ds2> ah... so it isn't disabled in the kernel but rather in udev?
[21:30] <ogra_> and since we assume that andoid knows best about the HW we leave that to android
[21:30] <ogra_> right
[21:31] <ds2> gotcha, misunderstood what you meant there
[21:31] <ogra_> on the ubuntu side, nothing should ever load fw
[21:31] <ds2> so to do firmware loading, I need to screw with /system/lib/modules on the android side?
[21:31] <ogra_> well, if you load it for something thats not also handled by andrroid it should be fine to manually load it from ubuntu
[21:32] <ogra_> the problam is the clashing of the two systems
[21:32] <ds2> thta's fine...trying to test stuff
[21:32] <ds2> problem I am seeing is the sysfs entries don't show up right
[21:32] <ds2> so either android side is NAK'ing it immediately or the kernel is broken
[21:33] <ds2> is there a easy way to look at the /system for android?
[21:33] <ogra_> look in /system :)
[21:33] <ds2>  /system is the real /system seen by android?
[21:33] <ogra_> oh, or it moved to /android/system
[21:34] <ds2> gotcha
[21:34]  * ogra_ checks
[21:34] <ogra_> /system should be fine
[21:37] <doanac> achiang: thanks. i'll get it merged
[21:39] <achiang> doanac: thanks
[21:46] <sergiusens> jdstrand, hey, can a precompile the apparmor profile cache on x86 for the emulator?
[21:46] <jjohansen> sergiusens: the cache can be precompiled
[21:46] <jdstrand> sergiusens: should be able to, yes. the key bits are the parser and the kernel
[21:47] <sergiusens> we already mangle the emulator image; I can add that for when we create it
[21:47] <jjohansen> same can be done for the arm emulator
[21:47] <jdstrand> I think that is what he was asking about
[21:48] <sergiusens> yes :-)
[21:48] <jdstrand> precompiling arm profile cache on x86
[21:48] <jjohansen> ah, yes. the cache doesn't actually care about the architecture. Its the kernel flag set and the parser time stamp
[21:49] <sergiusens> jjohansen, jdstrand so what do I need to run; going to test this out
[21:50] <jdstrand> jjohansen: I'll help sergiusens
[21:50] <jjohansen> jdstrand: ack
[21:51] <sergiusens> thanks
[21:53] <jdstrand> sergiusens: for each profile in /var/lib/apparmor/profiles, do apparmor_parser -KT -W --cache-loc=/var/cache/apparmor
[21:53] <jdstrand> sergiusens: well, let's back up
[21:53] <jdstrand> sergiusens: how are you accessing the filesystem?
[21:55] <sergiusens> jdstrand, I mount it
[21:56] <sergiusens> jdstrand, seems I can get by with that magic line above
[21:56] <jdstrand> sergiusens: let me put it another way. you are going to need to be running a goldfish kernel and apparmor_parser is going to need to have access to /sys/kernel/security/apparmor
[21:56] <sergiusens> jdstrand, ah, so I need a running kernel
[21:56] <sergiusens> that's what I was afraid of
[21:57] <jdstrand> sergiusens: so, you should be able to do something like: foreach profile in /var/lib/apparmor/profiles* ; do apparmor_parser -KT -W --cache-loc=/var/cache/apparmor <profile> ; done
[21:57] <sergiusens> jdstrand, so that means we need to do this server side to make it worthwhile
[21:57] <jdstrand> sergiusens: then again with: foreach profile in /etc/apparmor.d/* ; do  apparmor_parser -KT -W --cache-loc=/etc/apparmor.d/cache <profile> ; done
[21:58] <jdstrand> (typos notwithstanding)
[21:58] <jdstrand> sergiusens: if you don't have an x86 goldfish kernel-- I guess so, yeah
[21:59] <sergiusens> jdstrand, is `/sys/kernel/security/apparmor static?
[21:59] <sergiusens> static per kernel I mean
[21:59] <sergiusens> I might be able to stub it
[21:59] <jdstrand> sergiusens: also, the above commands didn't tak into account the mount point. ie: /mnt/var/lib/apparmor/profiles/*, etc
[22:00] <sergiusens> yeah, I can take care of that
[22:00] <jdstrand> sergiusens: I think the big thing you need is /sys/kernel/security/apparmor/features
[22:01] <jdstrand> sbeattie: do we do any stubbing in the apparmor testsuite for /sys/kernel/security/apparmor?
[22:02] <jdstrand> sergiusens: I'm asking cause sergiusens wants to fake up a goldfish kernel /sys/kernel/security/apparmor enough to run apparmor_parser on some x86 kernel to precompile goldfish policy caches
[22:03] <jjohansen> jdstrand: if the x86 kernel has apparmor with the same feature set, that would work too
[22:04] <jdstrand> right. not sure we can guarantee that
[22:04] <sergiusens> jdstrand, I'll think about this a bit
[22:05] <jdstrand> sergiusens: actually, this might be of help: apparmor_parser -f ... "Set the location of the apparmor security filesystem (default is "/sys/kernel/security/apparmor")."
[22:06] <jdstrand> sbeattie: nm
[22:06] <sergiusens> jdstrand, yup; since the kernel is very unlikely to change; I guess snapshotting that somewhere would be good enough
[22:06] <jdstrand> sergiusens: the apparmor_parser man page has a ton of options
[22:06] <jdstrand> sergiusens: oh, you'll also want to add -Q
[22:07]  * sergiusens rtfm :-)
[22:08] <jdstrand> so, the line is something like: foreach profile in /mnt/var/lib/apparmor/profiles/* ; do apparmor_parser -Q -K -T -W --cache-loc=/mnt/var/cache/apparmor -f /some/mock/sys/kernel/security/apparmor ; done
[22:08] <sergiusens> jdstrand, if the kernel changes; the cache gets a hit, right?
[22:08] <jdstrand> sergiusens: if /sys/kernel/security/apparmor changes
[22:08] <sergiusens> and thus recompilation
[22:08] <sergiusens> ok; makes sense; thanks
[22:08] <sergiusens> I'll play for a bit now
[22:09] <jdstrand> a kernel change may not trigger a policy recompile. well, there are other times a policy recompile might happen, but a kernel may not trigger a compile, no
[22:10] <sergiusens> sounds good, and the kernels do change rather infrequently
[22:10]  * jdstrand nods
[22:10] <sergiusens> at least for the emulator :-)
[22:11] <jdstrand> sergiusens: and it isn't like you wouldn't know when it happens. you'd get a 7 minute slowdown on 1st boot :)
[22:11] <ogra_> whats 7min in the face of eternity
[22:11] <jdstrand> exactly!
[22:12] <jdstrand> we had a 60% improvement over abysmal performance :)
[22:12] <ogra_> :)
[22:12] <jdstrand> new and improved abysmal performance!
[22:23] <sergiusens> :-)
[22:41] <sergiusens> jdstrand, wrt to the device tarball; the path you mention can stay read only as when images are updated; everything is read write :-)
[23:40] <Br0wn_> hello, is anyone around?
[23:41] <Br0wn_> does anyone know if the kernel in ubuntu touch enables monitor mode on the broadcom chips inside of nexus 7 2013's??????
[23:42] <popey> Br0wn_: we dont have a port for nexus 7 2013 yet


[11:09] <manadart_> achilleasa: Need a review for the AWS VPC re-use.
[11:09] <manadart_> https://github.com/juju/juju/pull/11872
[11:12] <achilleasa> manadart_: looking in 5'
[11:46] <achilleasa> manadart_: are you using venv to test ^^^ ?
[11:46] <manadart_> achilleasa: Yes.
[11:49] <achilleasa> we will need to bump the requirements: https://pastebin.canonical.com/p/JQg2k6T7c8/
[11:50] <achilleasa> I will try to get it up & running and send you a diff for requirements.txt
[11:55] <achilleasa> looks like it's only some of the azure bits...
[11:56] <achilleasa> manadart_: https://pastebin.canonical.com/p/6ghJG7gC2q/ not sure if removing these will break winrm.py...
[12:03] <achilleasa> manadart_: are the 400 responses at the end of the test the known cleanup issues that you mention in the PR description?
[12:06] <manadart_> achilleasa: For the security groups?
[12:06] <achilleasa> yeap
[12:07] <manadart_> achilleasa: Have not yet looked at those. I always get a destroy-model failure.
[13:47] <manadart_> achilleasa: https://github.com/juju/juju/pull/11873 merges that single patch forward.


[04:56] <pitti> Good morning
[05:11] <Mirv> pitti: morning! could you add ps-jenkins to https://launchpad.net/~canonical-platform-qa/+members ? cmake-extras would like to merge back from CI Train.
[05:14] <pitti> Mirv: err, that sounds weird; that team isn't supposed to hand out development rights for projects, it's a "people" team
[05:15] <pitti> Mirv: but I believe some "cmake"ish team was created recently, and ~canonical-platform-qa was put into that, sec
[05:16] <pitti> Mirv: so ps-jenkins should perhaps be added to https://launchpad.net/~cmake-extras/+members ?
[05:16] <pitti> (I can't do that, though)
[05:20] <Mirv> pitti: right, maybe the code branch is then wrong where it's trying to push (https://code.launchpad.net/~canonical-platform-qa/cmake-extras/trunk)
[05:20] <pitti> Mirv: oh yes, this should almost certainly be owned by ~cmake-extras
[05:21] <pitti> Mirv: I think https://code.launchpad.net/~cmake-extras/cmake-extras/trunk is the real trunk, and Allan just forgot to delete the ~c-p-qa one
[05:21] <Mirv> but there's also https://code.launchpad.net/~cmake-extras/cmake-extras/trunk which looks identical, so I can just push manually to there
[05:21] <Mirv> indeed :)
[05:21] <pitti> I can delete the c-p-qa one if you want
[05:22] <pitti> Mirv: I think what happened is that he started with that one first, people complained about spam (and such a team is really a bad owner for projects anyway), and then created the ~cmak-eextras one
[05:23] <Mirv> pitti: sure, go ahead. I'll ask eg. satoris to pull the temporary branch pushed by ps-jenkins to the trunk.
[05:23] <pitti> Mirv: ah, there's a pending MP on the c-p-qa one; I think we should better ask allan to deal with that, he'll know for sure
[05:24] <Mirv> ok, makes sense
[06:28]  * didrocks implements mock ssl server now that the http is done and found http://www.piware.de/2011/01/creating-an-https-server-in-python/ which seems to be perfect for my needs!
[06:28]  * didrocks hugs pitti
[06:31] <larsu> good morning!
[06:31]  * pitti hugs didrocks back, bonjour!
[06:31] <pitti> hey larsu, guten Morgen
[06:31] <didrocks> hey larsu, pitti! :)
[08:04] <Laney> morning!
[08:04] <larsu> hi Laney
[08:04] <seb128> good morning desktopers!
[08:05] <seb128> hey Laney, wb! had good days off work?
[08:05] <seb128> hey larsu ;-)
[08:05] <didrocks> good morning Laney!
[08:06] <Laney> seb128: yep, very nice thank you
[08:06] <larsu> hi seb128 :)
[08:06] <Laney> climbing & bought a new suit ;-)
[08:06] <seb128> what's the occasion? ;-)
[08:07] <Laney> going to a wedding in a few weeks
[08:07] <Laney> I still had the same one that I bought 10 years ago in school ...
[08:07] <seb128> cool
[08:07] <seb128> doesn't fit you anymore? ;-)
[08:07] <pitti> hey Laney, bonjour seb128
[08:08] <Laney> not sure it ever did :P
[08:08] <seb128> pitti, lut, wie gehts?
[08:08] <Laney> hey pitti larsu et didrocks!
[08:08] <pitti> seb128: très bien, danke !
[08:08] <pitti> or perhaps..
[08:08] <pitti> je vais very gut, dankon !
[08:09] <seb128> lol
[08:10] <Laney> stgraber: We don't have tracker in desktop, I'm happy for it to be processed as a normal gnome bugfix SRU personally
[08:12] <seb128> Laney, what was the question?
[08:12] <Laney> tracker sru
[08:12] <seb128> I'm unsure tracker follows the GNOME releases rules
[08:14] <Laney> I thought it was by what's in the core (or whatever the name is) moduleset for jhbuild
[08:14] <Laney> which tracker is afaik
[08:15] <seb128> k, I'm unsure where tracker is nowadays
[08:16] <seb128> the spirit of the standing exception was to trust things that follow the GNOME feature/UI/... freeze
[08:16] <seb128> since that defines "stable" updates
[08:16] <seb128> tracker might be part of that
[08:25] <Laney> anyways even without exceptions I tend to like upstream bugfix releases going in
[08:25] <Laney> oh hey, the desktop-session mp was approved
[08:26] <seb128> Laney, yeah, speaking of which we should SRU stuff to trusty when we can ... like there is a new webkitgtk point release, and a new rhythmbox one
[08:27] <Laney> yep
[08:27] <Laney> the last webkit only got released yesterday
[08:27] <seb128> do you want to do the webkit one?
[08:27] <Laney> ok
[08:27] <seb128> thanks
[08:28] <seb128> oh ok, I just noticed because it's red on versions
[08:28] <Laney> into trusty-updates i mean
[08:28] <seb128> oh, ok
[08:28] <seb128> yeah, I know, I marked it verification-done on monday
[08:28] <Laney> cool, thanks for that
[08:29] <seb128> yw!
[08:42] <didrocks> pitti: would you know by hard how with nosetests to be able to print debug logging statement? I'm trying to use --nologcapture --logging-level=debug, but only logger.warn() and logger.info() are printed, not the debug one (like when a test fails)
[08:44] <pitti> didrocks: sorry, I don't know; I hardly ever use nose
[08:44] <didrocks> no worry, thanks! :)
[08:44] <pitti> didrocks: but I doubt that you can control logger with environment variables; usualy you have to call logging.basicConfig() yourself and set the log level
[08:46] <didrocks> pitti: seems that --logging-level=INFO from nose resets the logging level to what you want (even for dynamically created logger). The only "issue" is that it doesn't display them until a test fails. For debugging, I would like them to be displayed anyway
[08:46] <didrocks> --nologcapture prevents nose to capture them, but don't display them either
[09:07] <didrocks> ok, seems to work well now :)
[09:07]  * didrocks drops a nose configuration files for easier loading later as well
[09:36] <didrocks> waow, awesome to see that python-mock documentation also covers my cornercase and have an example for it: https://docs.python.org/3.5/library/unittest.mock-examples.html#coping-with-mutable-arguments :)
[09:40] <mvo> didrocks: mock is the bomb
[09:40] <larsu> mvo: nice picture, thanks ;)
[09:41] <mvo> larsu: your very welcome, I like it too!
[09:41] <didrocks> mvo: I'm using it for a while already, but didn't get to that case yet. Nice to see it being covered by the documention :)
[09:41] <didrocks> documentation*
[09:41] <mvo> didrocks: yeah, my experience exactly, its not only great, its also very well documented
[09:43] <didrocks> indeed, enjoyed a lot. Unfortunatly, most of the time, I end up in readthedoc which is slightly outdated since mock entered the python library
[11:10] <pitti> seb128: mind having a quick look at https://code.launchpad.net/~3v1n0/gnome-session/remove-compiz-requiriment/+merge/216236 ? does that make sense?
[11:10] <pitti> seb128: (I'll merge it to the correct branch and upload, just wanted to get a second opinion)
[11:13] <seb128> pitti, looks good to me in principle, I didn't look at the login sequence to see if that creates flickering issues or such though ... but I guess we can fix those later if needed
[11:13] <seb128> well, Trevinho claims compiz is already started by upstart in most cases atm, so should not have that of an impact
[11:13] <pitti> thanks
[11:13] <seb128> pitti, +1 from me, thanks for the sponsoring ;-)
[12:26] <om26er> if system-settings is started by autopilot on the phone it seems the settings are not saved in accountservice for ringtone etc, does anyone have clues on what could be wrong ?
[12:27] <om26er> the same thing if done on the desktop works fine
[12:36] <popey> Could someone point me in the direction of the thing that generates the xdg folders in $HOME? The ~/Music, ~/Downloads etc folders
[12:37] <seb128> popey, xdg-user-dirs-gtk
[12:37] <popey> thank you seb128!
[12:37] <seb128> popey, on desktop at least (/etc/xdg/autostart/xdg-user-dirs-gtk-update.desktop is the thing run on login)
[12:38] <popey> perfect! thanks.
[12:39] <seb128> yw
[12:39] <seb128> om26er, could be that the dbus env is wrong? (similar to recent issues with the split greeter)
[12:41] <daveyesdave> I'm looking for a way to colour code nautilus when connected to a remote server, for example red background when connected to live server etc...
[12:41] <pp20> daveyesdave: funny that! I asked the same yesterday... if you find out, let me know :)
[12:44] <om26er> seb128, that could be the case do you have any workarounds/suggestions ?
[12:45] <om26er> because when autopilot changes the tone and get backs to the sounds panel the ringtone remains the same
[12:46] <seb128> om26er, just make sure the dbus environment for those jobs is the same as the one from the user session
[13:11] <daveyesdave> pp20, great minds and all that...
[13:13] <seb128> daveyesdave, seems like a wishlist to report on https://bugzilla.gnome.org/enter_bug.cgi?product=nautilus
[13:18] <daveyesdave> seb128, do you know an alternative file manager that might already offer this function? commander etc?
[13:18] <seb128> daveyesdave, no idea, try #ubuntu for user questions
[13:19] <daveyesdave> seb128, I'll give them a go, thanks
[13:19] <seb128> yw!
[13:53] <Laney> new webkit switches to geoclue 2 in Debian
[13:53] <Laney> should we do this too?
[13:53] <seb128> tedg, ^ do you know?
[13:54] <seb128> Laney, do you know what changed in the new one? are the providers the same?
[14:01] <Laney> it looks like the API has been trimmed
[14:01] <Laney> but the two versions are parallel installable
[14:01] <seb128> +1 for following Debian on webkit
[14:01] <seb128> we can still change back later if it turns out to be problematic
[14:01] <Laney> so we'd have to promote the new one
[14:01] <Laney> should be ok I guess
[14:02] <seb128> that's a new codebase I think
[14:02] <seb128> so maybe stick to the old one until we SRU the new webkit/get the MIR reviewed
[14:02] <Laney> http://www.hadess.net/2013/04/geocluing-desktop-slowly.html
[14:03] <Laney> don't know how the ubuntu geoip stuff will fit in there
[14:03] <seb128> yeah, me neither, why is why I pinged tedg ;-)
[14:04] <tedg> Sorry, OTP.
[14:04]  * tedg reads backlog
[14:05] <tedg> seb128, Laney, well my understanding is that there are no plugable providers in GeoClue 2.
[14:05] <tedg> But that's kinda a moot point in that we'll probably move things to location service.
[14:05] <seb128> tedg, do we need one?
[14:05] <tedg> So I don't think that it matters really.
[14:06] <tedg> If we wanted to use our GeoIP service, we'd need something plugable. But, not sure that we need one for generic webkit.
[14:06] <tedg> We'll probably just end up working with Oxide there.
[14:07] <seb128> tedg, what is our provider doing that the upstream one isn't?
[14:07] <seb128> tedg, we don't want to regress unity7, not sure where we use geoclue ... we probably don't care much about webkitgtk, but we do care about ubiquity and the indicator I guess?
[14:08] <tedg> seb128, I think that we can have both, no? We can stick with GeoClue 1 for those while having GeoClue 2 for webkit GTK.
[14:09] <tedg> I think the issue is the service being free to use or needing API keys and the such.
[14:09] <seb128> tedg, sure, but it means we have 2 versions supported/installed
[14:09] <tedg> For the interim releases, but I'm sure we'll be off GeoClue by the next LTS for those.
[14:10] <seb128> k
[14:10] <seb128> tedg, thanks
[14:10] <seb128> Laney, ^ makes sense to you?
[14:11] <Laney> do you have to explicitly ask for ubuntu geoip with geoclue 1?
[14:13]  * xnox is pretty sure ubiquity uses geoclue 1 against our canonical hosted server
[14:13]  * xnox goes to check
[14:14] <xnox> actually, no we don't. We just do a GET request to http://geoname-lookup.ubuntu.com/?query=%s&release=%s
[14:16] <Laney> I think it's alright to use both for now I guess
[14:16] <Laney> if I was curious I'd ask about the origins of location-service
[14:16] <Laney> but I'm alright not knowing for now actually ;-)
[14:24] <xnox> Laney: when location-service first came up, i thought it was related to cellphone-tower possition, which geoclue1 did not do....
[14:24] <seb128> Laney, you don't want to ask, that's another "cpp is better than g"
[14:24] <seb128> like we could have contributed to the geoclue rewrite with the GNOME guys
[14:25] <Laney> xnox: I think there was an opportunity to influence geoclue :)
[14:25] <Laney> seb128: yeah let's move on :P
[14:25] <xnox> seb128: qt5 has a hard-dep on gtk2 still, i think we know what's better =)
[14:25]  * xnox all Qt5 on Linux is delivered to you by Gtk+2 =)
[14:26] <xnox> same like it used to be the case with all Airbus planes to be delivered by a Boeing cargo transporter.
[14:31] <Laney> symbiosis
[14:35] <Trevinho> pitti: on that patch it's probably the case also to remove unity-settings-daemon as well
[14:35] <Trevinho> pitti: as it's using upstart
[14:39] <didrocks> ok, seems the rain ended outside, time for a run!
[14:40] <seb128> didrocks, enjoy!
[14:41] <didrocks> thanks, wish me luck to avoid any rain shower :)
[14:41] <didrocks> (at least, temperature is nice)
[15:57] <sil2100> kgunn: hey! Did you guys propose your blueprints for the UOS already?
[18:08] <rickspencer3> hey all, mediascanner-service is using a lot of resources on my desktop :(
[18:09] <rickspencer3> and it keeps respawning if I kill it
[18:11] <rickspencer3> seb128, still around at all?
[18:21] <Laney> rickspencer3: Looks like it has an upstart job which will restart it
[18:21] <Laney> stop mediascanner-2.0 should do it
[18:21] <rickspencer3> Laney, yeah, I finally figured that out
[18:21] <Laney> ah
[18:21] <rickspencer3> it was not in the list of upstart jobs
[18:21] <rickspencer3> but, I am probably just super confused
[18:22] <rickspencer3> I thought service --status-all would show me what it is called
[18:22] <rickspencer3> Laney, popey hooked me up (along with tab completion) :)
[18:22] <Laney> I don't know what that does
[18:22] <rickspencer3> Laney, I assumed it would show all the services and their current status
[18:22] <Laney> initctl list is that one that I know
[18:23] <Laney> anyway I would hope that it's running at a low enough priority to not impact the usage of your system
[18:23] <Laney> did you notice it being slow?
[23:02] <xnox> Laney: service command only ever operates on system-init (if it doesn't / leaks user-session info, it's a bug)
[23:02] <xnox> Laney: indeed initctl commands should have been used instead...
[23:34] <thumper> Trevinho: around?
[23:34] <thumper> Trevinho: because you work crazy hours...
[23:35] <Trevinho> thumper: hi :)
[23:35] <thumper> Trevinho: hey there
[23:35] <thumper> Trevinho: I have some unity weirdness...
[23:35] <Trevinho> thumper: tell me...
[23:35] <thumper> Trevinho: I have five emails open, so lots of pips next to thunderbird
[23:36] <thumper> if I alt-` I get the tab spread, right?
[23:36] <Trevinho> thumper: you should yes
[23:36] <thumper> however, the images in the spread flicker
[23:36] <thumper> going from shaded to not, to shaded
[23:36] <Trevinho> thumper: yes, that's a known issue...
[23:36] <thumper> ok
[23:36] <thumper> Trevinho: is it an issue that is likely to be fixed soon?
[23:37] <Trevinho> thumper: I also know how to prevent it, but it's not an optimal fix, so I avoided it for now... but it's something we should avoid asap
[23:37]  * thumper nods
[23:38] <Trevinho> thumper: basically there's one-line change that fixes it (damaging the switcher area when painting these windows), but it would cause too many redraws also when not needed... and although I didn't notice any slow-down I didn't like the idea :)
[23:38] <thumper> :)
[23:38] <Trevinho> anyway... yeah a better solution is in my list for some time
[23:52] <robert_ancell> RAOF, is there any logical reason why in X you can have a depth=32 window with bpp=24?
[23:53] <RAOF> robert_ancell: Hm. I thought it would be the other way around.
[23:53] <RAOF> robert_ancell: But, sure! Drivers want 32 bits per pixel, because 4 bytes is a nice round number.
[23:54] <RAOF> robert_ancell: So basically it's a “pixels are 32bits, of which 24 are actually significant”
[23:54] <robert_ancell> RAOF, so it should be allowed?
[23:54] <RAOF> Yeah. But from memory depth is the number of significant bits and bpp is the total number of bits; are you sure you're not getting those reversed?
[23:55] <robert_ancell> RAOF, I'm chasing down an assertion that's hit in X when running under qemu - the root window is 24bpp and if you use  the depth=32 visual on the window and render to it using RENDER it doesn't render/renders wrong
[23:56] <robert_ancell> So I'm not 100% sure where the bug is, but the fact the drawable is set that way suggests something went wrong at window creation
[23:56] <RAOF> Ah.
[23:56] <robert_ancell> which might be the fb backend, because I think that's what qemu is using; at least on my system
[23:57] <RAOF> I'm not entirely sure if RENDER handles that case correctly. It's possible to do correctly.
[23:57] <robert_ancell> RAOF, yeah, so RENDER should be dropping some bits somewhere to make it fit?
[23:57] <RAOF> Yeah. The 8 bits of alpha would be a prime candidate :)
[23:57] <robert_ancell> yep
[23:58] <robert_ancell> RAOF, and a follow up there. Is there anything that actually specifies in a depth=32 visual that the remaining 8 bits is actually alpha? Is that just a convention?
[23:58] <RAOF> As far as I can tell, convention. :(
[23:59] <robert_ancell> yeah, the spec mentions nothing. I was wondering if it got specified in a an extension somewhere
[23:59] <robert_ancell> There really should be a XALPHA extension that turns this on