[16:30] <xnox> ls
[16:30] <stgraber> gema: can you reproduce this using system-image-cli on the command line too?
[16:30] <pitti> boiko: ah, thanks
[16:30] <boiko> pitti: IIRC om26er did some code to move that away and restore at the end of the test, can't remember if it was for dialer-app or messaging-app
[16:30] <gema> stgraber: I haven't tried that, what is the command you want me to use to try?
[16:30] <gema> stgraber: reflashing back atm
[16:31] <stgraber> gema: otherwise it may be some dbus related issue or something to do with the downloader code which we're changing in the next image to use the download service instead (so your problem may go away then). Anyway barry knows that stuff way more than I do since he's the one working on the client...
[16:31] <pitti> boiko: easy enough; i. e. move file away and kill history-daemon in setUp() , restore it in tearDown()
[16:31] <boiko> pitti: yep
[16:31] <gema> barry: ^^
[16:31] <stgraber> gema: just run "system-image-cli" as root that will figure out the upgrade path, download and reboot. It won't print anything though unless you pass -v (or some extra -v to get even more verbose output)
[16:31] <boiko> pitti: and kill history-service again in tearDown() just in case
[16:31] <pitti> right
[16:32] <om26er> boiko, pitti we do that for a few other apps as well. e.g calculator sudoku-app. we have not yet done that for dialer/messaging
[16:32] <gema> stgraber: ack
[16:32] <om26er> boiko, you probably reviewed my branch for the calculator
[16:32] <mhr3> mfisch, home-scope branch landed in trunk
[16:32] <stgraber> gema: we also had a socket bug which slangasek fixed recently and that was causing the download to fail under some condition and may cause what you've been seeing (I had that happen to me on the command line a couple of times with pretty out of date devices)
[16:32] <boiko> om26er: yep, but I remember you asked me how to do that for the history-service stuff, I thought you had implemented that already :)
[16:32] <om26er> I did that in the connected tests for the phone-app in the past.
[16:33] <om26er> boiko, Yes, I was working on that when I was at the sprint in Lex but now someone else is working on it
[16:33] <gema> stgraber: I am using the first image that shouldn't require a full upgrade, fwiw
[16:33] <slangasek> stgraber: hum, I'm pretty sure I didn't fix any socket bugs except wrt the testsuite itself
[16:33] <boiko> om26er: ok, np, thanks
[16:33] <gema> slangasek: we are talking about bug 1233094
[16:34] <pitti> om26er, boiko: I implemented it now, thanks
[16:34] <mfisch> mhr3: cool, now we just need it in the image!
[16:34] <mhr3> mfisch, i wouldn't hold my breath there
[16:35] <mfisch> yeah I'm not
[16:35] <mfisch> we may just build it ourselves
[16:35] <mhr3> mfisch, fwiw it should be in the daily build ppa soonish
[16:35] <slangasek> gema: we've landed the new system-image architecture based on ubuntu-download-manager in part because of unreliabilities in the previous architecture, and most of these bugs aren't going to be solvable retroactively because the bugs are in the client in the old image.  I think the only thing we can advise here is "reflash to an image that uses the new code".
[16:36] <mfisch> mhr3: perfect then we dont even have to buld it
[16:36] <stgraber> slangasek: oh, ok, didn't look at the actual code change. So anyway, I've had some weird timeout related issues here when an image is made of a lot of files, sometimes it'd take 2-3 tries to get everything downloaded properly. Hopefully the download maanger will fix that issue.
[16:36] <mhr3> mfisch, soonish == ~12hours
[16:36] <slangasek> gema: now, I think separate to that we should be thinking about having some tests which stress the downloader client by artificially feeding it a large download (~200M) so that we can verify it's handled correctly; but we need to run such tests against current client code, not old stuff
[16:36] <gema> slangasek: ok, so what is the first image with the new architecture?
[16:36] <slangasek> gema: 73
[16:37] <slangasek> (not yet promoted)
[16:37] <gema> slangasek: ok, so I should be testing from 73 onwards
[16:37] <gema> which hasn't even landed
[16:37] <slangasek> gema: yes please :)
[16:37] <slangasek> it's still in devel-proposed, yes
[16:37] <gema> slangasek: you do realise that we are going to have almost no change of catching this kind of bug because our upgrade path is not going to be big enough, right?
[16:37] <gema> slangasek: this is a calculated risk, I assume?
[16:38] <mhr3> mfisch, but if you ask someone nicely they might be able to publish it there manually
[16:38] <mhall119> are we going to get contacts syncing again anytime soon?
[16:38] <slangasek> gema: as I said, I think we should have tests with artificially-large updates
[16:38] <gema> slangasek: do you have some of those?
[16:38] <slangasek> gema: the upgrade path from v. 5 to v. 70 (the current version on the devel channel) is going to go straight to 70 and download it in one large block; we can simulate that
[16:38] <mfisch> mhr3: we're waiting for a bunch of other stuff, so I can wait
[16:39] <mfisch> mhr3: is it the usual daily PPA or a special unity one?
[16:39] <slangasek> stgraber: ^^ could you prepare a stand-alone artificially large system-image to use for upgrade testing?
[16:39] <mfisch> cwayne: We'll have a deb soonish to put apps at the top of the home scope
[16:39] <gema> slangasek: ack, that sounds good
[16:39] <mhr3> mfisch, this one https://launchpad.net/~ubuntu-unity/+archive/daily-build
[16:39] <mfisch> mhr3: perfect
[16:39] <slangasek> stgraber: actually, I think it would be sufficient to prepare an artificial channel that always forces a full download
[16:40] <stgraber> slangasek: well, just call system-image-cli with -b 0 then and you'll get a full ;)
[16:40] <stgraber> slangasek: or even better, with -f full which will ignore any existing delta image in the resolution
[16:41] <gema> stgraber: not what I am trying to test, sorry
[16:41] <gema> stgraber: I am trying to test a different upgrade path
[16:41] <gema> and make sure the UI does the right thing
[16:41] <gema> etc
[16:42] <ogra_> yay, android built
[16:42] <stgraber> so what you could do is use -5 but first upgrade system-image to the latest version on the device
[16:42] <gema> stgraber: so I'd do a phablet-flash ubuntu-touch --revision -5 from 73, right?
[16:42] <stgraber> so switch to writable mode, update the system-image packages with apt, switch back to read-only, reboot the device, run the update
[16:43] <stgraber> yep, same thing as you were testing so far, except that you remount you / writable, update system-image and reboot before proceeding with the update
[16:43] <stgraber> that way you'll actually be testing the current system-image client code
[16:43] <stgraber> something along the lines of:
[16:43] <stgraber> adb shell mount -o remount,rw /
[16:43] <stgraber> adb shell apt-get update
[16:43] <gema> I know what you mean
[16:44] <gema> I don't think it is going to work
[16:44] <gema> it's not what I am trying to test
[16:44] <stgraber> adb shell apt-get install system-image-cli system-image-common system-image-dbus
[16:44] <stgraber> adb shell reboot
[16:44] <stgraber> then test as usual
[16:44] <stgraber> gema: what are you trying to test then?
[16:45] <gema> stgraber: usually I'd flash X images back and try to upgrade to current, first test case is going back as many as it takes to trigger the full update
[16:45] <slangasek> stgraber: we need a standing test case based on recent images, not retrofitting system-image packages onto a version 5 image
[16:45] <gema> stgraber: then one less
[16:45] <slangasek> stgraber: and it needs to work from the UI, not just from system-image-cli
[16:45] <mhall119> um, I'm running ubuntu-system daily stable images......why is apt-cache running and using up my CPU?
[16:45] <gema> stgraber: and make sure in the first case I get a full image upgrade
[16:45] <gema> and in the second I don't
[16:46] <jdstrand> sergiusens: yes-- I am waiting on bug #1231863 to land in the archive
[16:46] <slangasek> stgraber: so I think this could be done by forcing /etc/ubuntu-build on the filesystem, right?
[16:46] <cjwatson> mhall119: use "ps axf" to find out what's calling it
[16:46] <jdstrand> sergiusens: it is unrelated to the usermetrics, but because it is difficult getting things into the image, I am gathering up the various bug fixes into one upload
[16:46] <cjwatson> mhall119: there's still an apt cache on ubuntu-system images even though it's RO
[16:47] <mhall119> cjwatson: well it's not running anymore, but if I see it again I'll do that
[16:47] <mhall119> cjwatson: right, but it shouldn't be using 50% of my CPU
[16:47] <cjwatson> Sure
[16:47] <stgraber> slangasek: hmm, then for each image you need to have a server import that, generate a bunch of big updates in a way that you result with X deltas before the upgrader decides to use a full and have your test device use that. It's definitely possible but we'd first need to get the ports/oem server work done as that'd need something similar for the import+signature and then probably a few more days of work to generate the right "fake" updates
[16:47] <cjwatson> Just saying that it's kind of orthogonal to whether you're on ubuntu-system or not
[16:48]  * mhall119 nods
[16:49] <slangasek> stgraber: why would you need to generate a bunch of big updates?
[16:49] <sergiusens> jdstrand, I feel your pain :-)
[16:49] <slangasek> stgraber: install version n-1; set /etc/ubuntu-build to 0; upgrade
[16:49] <stgraber> slangasek: because what's failing for gema is not a full update, it's a massive amount of mid-size updates
[16:49] <slangasek> stgraber: no, the path from 5 to 70 is certainly going to be a full update
[16:50] <slangasek> unless she's done something to override
[16:50] <stgraber> slangasek: she's testing with -5
[16:50] <stgraber> slangasek: which means 5 versions before the current one and that's most likely to be a delta path, not a full
[16:50] <slangasek> oh?
[16:50] <slangasek> then I misunderstood
[16:51] <gema> slangasek: I am testing from 57 to 70
[16:51] <gema> slangasek: I edited the bug to make it clearer
[16:51] <gema> slangasek: just big enough delta - 1
[16:51] <slangasek> stgraber: are you sure the upgrade path from 57 to 70 pulls deltas, not a full update?
[16:51] <slangasek> ah, ok
[16:51] <gema> slangasek: I am positive
[16:51] <stgraber> testing a full update is really quite simple indeed, just change channel.ini to force a lower version, run the code again, done (or use system-image-cli -f full for a cleaner solution). Simulating a case where you need to download 25 small files in parallel is tricky (and that's the case that's been failing for me here with weird timeouts)
[16:51] <slangasek> right, I completely misunderstood the problem, sorry
[16:52] <slangasek> so yeah, we need to test both of those cases
[16:52] <stgraber> slangasek: well, since they wrote a script to tell you which version to take to get the biggest possible delta, I sure hope so ;)
[16:52] <gema> slangasek: http://bazaar.launchpad.net/~javier.collado/+junk/upgrade-tests/view/35/scripts/full-update.py
[16:52] <slangasek> but we *definitely* need to test the "Multiple small updates" case using the new code, and not the code that was in 57
[16:52] <slangasek> I think the right way to do this is with a synthetic channel
[16:52] <stgraber> oh, actually, faking the version number would work in either case
[16:53] <slangasek> true
[16:53] <stgraber> because if you're on rev 71 and change channel.ini to say it's 57
[16:53] <stgraber> it'll resolve a path using a bunch of deltas
[16:53] <stgraber> which will just end up replacing files you alrady have, no big deal, same end result
[16:53] <stgraber> so that'd work
[16:53] <slangasek> yep - but the deltas may have different characteristics from one version to the next, that doesn't make for a very reliable test case
[16:53] <stgraber> how so?
[16:54] <slangasek> we really want the integration tests for the *updater* to be based on fixed data
[16:54] <slangasek> stgraber: one day, the max deltas to download might be 3; another, it might be 6; how will the behavior change, and what are we trying to test?
[16:55] <slangasek> if it's a problem with parallel downloads, we don't want to overlook a regression because a particular day's delta was large and cause a smaller number of parallel downloads
[16:56] <stgraber> right but doing that needs a separate server with fixed size pointless deltas that are properly signed and trusted on the device
[16:56] <stgraber> that's definitely possible and moderately easy to do once we have the oem/port code implemented in the server side code, but don't count on it for at least another 2 weeks to a month
[16:57] <stgraber> so it may be better to have a slightly less optimal testcase today than try and aim for a perfect one and run with none until then
[16:58] <gema> stgraber: jcollado is working on that
[16:58] <gema> stgraber: not sure if he has spoken to you yet or not
[16:58] <slangasek> stgraber: we shouldn't spend a lot of energy on a test case that's not going to test the code we care about
[16:58] <gema> stgraber: I am not even sure he is aware of this rearchitectured version of the upgrader
[16:59] <slangasek> we care about testing that upgrades *will* work from the current version of the image, before we promote it... because that's the point where we have the opportunity to fix bugs
[16:59] <slangasek> learning that there were bugs in an image from two weeks ago really doesn't help us ;)
[16:59] <stgraber> gema: the upgrader hasn't change in the past month, the client and server did (sorry, I'm picky about terminology but it's easy to misunderstand what we're talking about if we're not using the right terms)
[16:59] <stgraber> gema: and yeah, he talked to me a bit a few weeks back, haven't heard much since
[16:59] <gema> stgraber: you are well right to be picky, I don't really understand what changes you guys are talking about
[16:59] <slangasek> and while installing s-i + u-d-m on an old image and testing that is better than nothing, it's not a true integration test - let's make sure we're targeting the right thing
[17:00] <stgraber> slangasek: that's why using the latest image and faking channel.ini seems reasonable to me
[17:00] <slangasek> as a first pass, yes
[17:00] <gema> slangasek: so you don't care that you can upgrade from a week ago to today's update, you care that today's image can upgrade to future, or do you care about both?
[17:00] <stgraber> slangasek: that'll have the current code of the latest image try to do a full update and a large series of delta updates at pretty much no implementation cost
[17:01] <slangasek> gema: I care about things I can fix; if the upgrader in the already-released image is broken, I can't fix that
[17:01] <gema> slangasek: because if you produce an upgrade that is broken somehow, or that is not backwards compatible, you want to know
[17:01] <gema> slangasek: the upgrade may be wrong/broken
[17:01] <gatox> dpm, hi.... do you know where the winners of the app showdown are going to be announced?
[17:01] <stgraber> slangasek: well, we can fix an upgrade path from an old image on the server side.
[17:02] <slangasek> gema: so integration testing of the *upgrader* should test from the current upgrade with a mocked channel.ini; integration tests of the *upgrades* should test with a previous image using the real channel
[17:02] <gema> slangasek: if today's upgrade renders millions of phones unusable for whatever reason, you definitely don't want to promote that upgrade
[17:02] <stgraber> slangasek: if we notice that a particular delta path will fail, we can break it and force a full for those. So we should definitely test that so we can know about it before we get user reports.
[17:02] <gema> slangasek: agreed
[17:02] <gema> slangasek: so we are talking about two things at once
[17:02] <slangasek> gema: and I thought what we discussed previously was to test upgrades from n-2 to n-1 and n-1 to n.  What's driving the test from n-5 here?
[17:03] <gema> slangasek: n-2 is not good enough to trigger a full upgrade and I wanted to test that
[17:03] <gema> slangasek: automation is not in place yet, so I am doing manually
[17:03] <slangasek> stgraber: I'm not happy for us to be hands-on managing that on the server.  We should be setting a high bar for the reliability of the upgrader, which makes this issue moot
[17:03] <cwayne> sil2100: ping
[17:04] <slangasek> gema: right, but if you want to trigger a full upgrade, just install n-1 and set /etc/ubuntu-build to 0
[17:04] <stgraber> slangasek: sure, I still think it's worth knowing if we messed up so we can do something about it rather than panic when we get users report after releasing the new image
[17:04] <gema> slangasek: I am seeing problems that only happen if the ro partition hasn't been touched
[17:05] <gema> slangasek: so doing that is not a real life scenario, which is what I am trying to test
[17:05] <stgraber> gema, slangasek: /etc/system-image/channel.ini, not /etc/ubuntu-build, /etc/ubuntu-build is just there for backward compatibility, it's not read by the client at all!
[17:05] <slangasek> gema: there's nothing magical about the filesystem that it knows when it's touched
[17:05] <gema> slangasek: I am sitting here with shrodinger's cat
[17:05] <slangasek> stgraber: ah, ok
[17:06] <gema> slangasek: I know, still bugs stop being reproducible after that
[17:06] <gema> slangasek, stgraber I am being called for dinner, will have to continue this conversation tomorrow, I will read backlog anyway
[17:08] <slangasek> gema: well, testing with versions of code that we don't care about and don't tell us anything about the current code is not a good workaround for the fact that some bugs aren't reproducible if the filesystem has been touched.  I'm happy to help root-cause *those* bugs if it would help, but we still need the test I'm describing to answer the question of whether the upgrader in the to-be-promoted version works
[17:08] <slangasek> gema: ok, buen aprovecho :)
[17:10] <gema> slangasek: I agree with you, we need that testing as well and I am going to make sure jcollado is on the same page tomorrow as well
[17:10] <gema> slangasek: thanks!
[17:12] <barry> gema: hi.  still need help?
[17:27] <tedg> popey, Is there a bug tracking the alarm stuff?
[17:29] <atomic0x> Hello all, I've just installed saucy touch nightly (downloaded today) on my nexus 4. I'm unable to get a data connection over 3G. Calling works fine. I've taken a snip of /var/log/syslog showing Network Manager trying to connect but failing. It's here http://pastebin.com/GJ52g5J8
[17:30] <davmor2> ogra_, stgraber: did image 75 happen yet?
[17:31] <ogra_> davmor2, not yet
[17:31] <tedg> nik90, ^ question for popey above, do you know?
[17:32] <nik90|Office> tedg: can you copy paste the question again?
[17:32] <nik90|Office> tedg: I am viewing through office irc account
[17:33] <tedg> nik90|Office, Is there a bug tracking the alarm stuff?
[17:33] <cwayne> atomic0x: i believe that should be fixed with the next image
[17:33] <nik90|Office> tedg: https://bugs.launchpad.net/ubuntu-clock-app/+bug/1233176
[17:33] <tedg> nik90|Office, Great!  Thanks!
[17:34] <tedg> charles, ^
[17:34] <nik90|Office> tedg: although that bug is localised to the clock app..so you may want other bugs in respective projects for other stuff like indicator-datetime and sdk
[17:35] <atomic0x> Excellent. I'll try again in a day or two :) thanks!
[17:35] <tedg> nik90|Office, I added bug tasks, I think it's close enough.
[17:35] <nik90|Office> tedg: ah perfect. thnx
[17:36] <nik90|Office> tedg: in your MP, why does it say .app_id = "calendar-app" instead of clock-app?
[17:37] <tedg> nik90|Office, Cut and paste bug :_)
[17:37] <tedg> :-)
[17:37] <tedg> nik90|Office, Fixing
[17:37] <nik90|Office> ;)
[17:38] <nik90|Office> tedg: also fyi for the clock app, the id is applicationName: "ubuntu-clock-app"
[17:38] <nik90|Office> that's how it is defined in the main view
[17:38] <nik90|Office> I am not sure if that helps or not
[17:38] <tedg> nik90|Office, What is the name of the desktop file?
[17:39] <nik90|Office> tedg: ubuntu-clock-app.desktop
[17:39] <nik90|Office> tedg: it executes Exec=qmlscene /usr/share/ubuntu-clock-app/ubuntu-clock-app.qml
[17:39] <tedg> nik90|Office, Yup, found it on my phone.
[17:43] <cwayne> om26er: ping
[17:44] <om26er> cwayne, pong
[17:46] <cwayne> om26er: hey, your touchshot script is pretty useful, any plan on including it in phablet-tools?
[17:46] <om26er> cwayne, I would but its not going to work in a few days as we move to Mir :/
[17:46] <om26er> screencap is SF specific
[17:46] <cwayne> om26er: ah, i gotcha
[17:49] <nerochiaro> bfiller_afk: when you have some time please email me the next priorities. What remains from your last email is either waiting on something/someone or almost done, so it would be nice to have some other things to fill the gaps and to start on next week. Thanks
[17:51] <RAZORQ> Is there anyone online xD?
[17:52] <dobey> no
[17:53] <dobey> only robots
[17:53] <dobey> some have attained self-awareness though
[17:53] <gilbert32> call me robot?
[18:07] <mfisch> stgraber: will images in /stable be safe from pruning?
[18:08] <stgraber> mfisch: no
[18:08] <stgraber> mfisch: /stable is an alias for /saucy, /saucy contains up to 10 images then prunes the old ones
[18:09] <mfisch> stgraber: okay, thanks
[18:10] <davmor2> dobey: isn't that the start of Terminator?
[18:11] <davmor2> dobey: or the matrix
[18:12] <dobey> davmor2: and all the religious books in the world.
[18:14] <davmor2> dobey: Pretty sure that god is a robot whose been dealing with 3d printing for a while :D
[18:20] <cwayne> dobey: btw updated the MR with more info
[18:26] <ogra_> build 75 done ...
[18:27] <popey> ogra_: need testing?
[18:27] <ogra_> we wont release it tonight ...
[18:28] <ogra_> but yeah, go ahead if you feel like
[18:28] <popey> ok, will do
[18:28] <ogra_> TZ selection should work now
[18:28] <popey> oh, good good
[18:28] <ogra_> and the breakages should be gone again
[18:28]  * ogra_ crosses fingers
[18:28] <lenios> next step is to get mir on it, i guess
[18:32] <davmor2> ogra_: meh I just got 74 again
[18:33] <davmor2> popey: check it's 75 you get
[18:34] <dobey> cwayne-afk: that also doesn't solve the problems
[18:34] <popey> yip yip
[18:34] <ogra_> davmor2, cdimage is done, system-image might still be processing
[18:35] <davmor2> ogra_: right
[18:35] <popey> yeah, its still grabbing previous image
[18:35] <popey> phablet-flash should report the image number
[18:35] <popey> imo
[18:35] <ogra_> file a whishlist bug
[18:35] <davmor2> popey: +1
[18:35] <popey> then pause 3 seconds so you can CTRL+C it ☻
[18:36] <davmor2> popey: better still would be a confirmation to continue
[18:36] <popey> hmm, i prefer no confirmation
[18:36] <popey> figlet build number 74
[18:36] <popey> like that
[18:36] <popey> so i see it and then stab ctrl+c ☻
[18:37] <davmor2> popey: agreed plus it is one less thing to automate if you run the script automagically
[18:40] <popey> bug 1233800
[18:44] <davmor2> popey: +1'd
[18:44] <dobey> why are so many of the icons not on a square canvas?
[18:47] <stgraber> ogra_: looks like the import is running at the moment
[18:47] <ogra_> stgraber, yeah, i was suspecting that
[18:49] <karni> I'm trying to run an app (just a "Simple Touch UI" template from Ubuntu SDK) on a phone. Have you guys seen this message?
[18:50] <karni> mkdir: cannot create directory â/home/phablet/.local/share/applicationsâ: Permission denied
[18:52] <cyphermox> davmor2: got news for me? :)
[18:53] <cyphermox> I can't seem to find a way to break it so far
[18:53] <davmor2> cyphermox: just waiting on system image to catch up
[18:53] <davmor2> cyphermox: then I have 75 and can test
[18:56] <davmor2> ogra_: any idea how long system image should take to play catchup  at all?
[18:57] <davmor2> ogra_: ignore that looks like it's there now
[18:57]  * popey cancells the bug and just gets davmor2 to check the status of system image for me
[18:58] <davmor2> popey: tsk I might be on holiday then what do you do?
[19:01] <tedg> ricmm, sergiusens (or someone else non-English native), do you guys translate "WEP Enterprise" in UIs?
[19:02] <sergiusens> tedg, my env is in English :-)
[19:02] <davmor2> cyphermox: as soon as image 75 is installed I'll get your mod installed and leave it on 3g till tomorrow, if it's still connected you win, if not you LOSE ;)
[19:03] <tedg> sergiusens, ah, that's no fun!
[19:04] <davmor2> cyphermox: that will hopefully give it enough time that if the connection is gonna drop it will of dropped :)
[19:08] <popey> davmor2: get your phone number from the directory ☻
[19:08] <barry> stgraber: are there any examples on s-i.u.c where an image has a phased-percentage key?
[19:11] <timppa> ogra_: What was the URL for the changelogs? I've seem to lost it somehow
[19:11] <stgraber> barry: not at this point, I actually still have to implement the feature server side (though I expect it to take 30min at most, it's pretty trivial on my side)
[19:11] <sil2100> cwayne-afk: pong
[19:12] <barry> stgraber: okay.  so just so i understand how it's going to work: only an image with the highest version number can have a phased-percentage key, and if that exists and it is < hash, we essentially treat that image as not existing when we calculate all the upgrade paths
[19:13] <Chocanto> Hey everyone ! Do you know if we have a way to know the header height of the tabs ?
[19:13] <Chocanto> When I ask the height of an element, it always give me the total height of the screen, not the height without the header
[19:13] <stgraber> barry: correct
[19:13] <davmor2> ogra_: worrtingly I have mtp conected but a black screen
[19:13] <davmor2> ogra_: nevermind it finally woke up
[19:13] <barry> but i won't enforce that "must be on the highest version", so if for some reason an intermediate image has a non-matching phased-percentage, i'd ignore that image but it probably wouldn't matter as the next delta would get you past that anyway
[19:14] <barry> stgraber: ^^.  if so, i think my logic is pretty simple
[19:14] <stgraber> barry: yep, that's perfectly fine. On the server side, I'll change the function that actually writes and signs the index.json to strip phased-percentage from all images but the latest, so we'll never have that case in production anyway
[19:15] <stgraber> (and .set_phased_percentage() will fail on older images too so people won't get confused when the flag won't stick ;))
[19:19] <barry> stgraber: +1
[19:26] <davmor2_> ogra_: still no incoming call tone
[19:34] <zzarr> hello hashcode
[19:36] <zzarr> I just wounder how the hdmi driver is comming along?
[19:48] <zzarr> does anyone know how mir compares to x? (speed, security, etc)
[19:58] <sergiusens> tedg, mhall119, know anything about locales?
[19:58] <sergiusens> looking at setting a search path for them
[19:58] <tedg> sergiusens, <sergiusens> tedg, my env is in English :-)
[19:59] <tedg> Search path like where the .mo files are?
[19:59] <sergiusens> tedg, I know, that's why I don't know how to do this :-) Turns out the apps have translations now and I don't know how to 'find' them from the click pkgdir
[20:00] <sergiusens> tedg, if it's an envvar, can we com up with a convention in upstart-app-launch?
[20:01] <tedg> Yeah, I think that would make sense.
[20:01] <popey> yay time/date setting works now!
[20:01] <tedg> Perhaps it would make sense to put in the manifest.  So, in theory, people could change it.
[20:02] <tedg> I've got a TEXTDOMAINDIR as an env.
[20:02] <tedg> Oh, I bet seb128 knows.
[20:02] <sergiusens> tedg, that works for me ... jdstrand  || cjwatson  ^^ ?
[20:02] <seb128> tedg, what?
[20:02] <mhall119> sergiusens: what about locales?
[20:02] <tedg> seb128, Trying to figure out locale stuff for click packages.
[20:03] <tedg> seb128, Is there an env we should set so they know to look in their install directory?
[20:03] <sergiusens> mhall119, just figuring out how to find them from a click pkgdir
[20:03] <seb128> tedg, I don't think so, for langpacks we patched libc
[20:03] <tedg> seb128, It turns out that even though he speaks non-English, sergiusens doesn't use it.
[20:03] <mhall119> sergiusens: wouldn't they be in ./po/ in the click install dir?
[20:04] <tedg> seb128, Oh, wow.  I didn't realize it went that far.
[20:04] <sergiusens> mhall119, and that _just works_ TM? :-)
[20:04] <mhall119> sergiusens: of course, because it's built by a team of talented engineers who wouldn't date ship broken code
[20:05] <mhall119> translation: I have no idea if it works, but it should
[20:05] <tedg> I don't think you want po files, you want mo files.
[20:08] <tedg> Uhm... eglibc is the most complex packaging I think I've seen.
[20:08] <kenvandine> mhall119, i have a rough WIP implementation of content transfers initiated by an exporter
[20:08] <kenvandine> mhall119, no promises on this landing for 13.10, this was deferred
[20:09] <sergiusens> tedg, are we discarding TEXTDOMAINDIR?
[20:09] <kenvandine> mhall119, but i wanted to spend a little time on it now to see how the API would behave, it might be doable for 13.10...
[20:10] <mhall119> tedg: given that we likely won't have content-hub doing what we need for docviewer-app before 13.10, can I submit an MP to url-dispatcher to do the work in the mean time?
[20:10] <mhall119> kenvandine: thanks
[20:10] <mhall119> kenvandine: remember that 13.10 is in 2 weeks :)
[20:11] <tedg> sergiusens, Looking at the eglibc patch... seeing if that's right.
[20:11] <tedg> sergiusens, Not looking good.
[20:11] <tedg> mhall119, That's fine.  Just know it'll break when we switch to registering URL types.
[20:11] <sergiusens> tedg, I'll send an email to the list to see if someone has more ideas
[20:11] <kenvandine> tedg, clearly not for 13.10, but maybe url-dispatcher could support finding the app that owns content based on a file URI and invoking it to initiate an export
[20:12] <kenvandine> so filemanager-app could just use url-dispatcher, which would query the hub for a handler to start a transfer
[20:12] <tedg> kenvandine, Not sure I'd like to complicate url-dispatcher for a corner case like filemanager....
[20:12] <kenvandine> tedg, note  currently we have no way to query to find what app owns a file... but maybe we need to think about that
[20:13] <tedg> kenvandine, Seems like filemanager should be complicated in itself.
[20:13] <pmcgowan> kenvandine, remember file manager wont even be on the consumer devices
[20:13] <tedg> kenvandine, That way if most people don't use it, they're not encumbered by the complexity.
[20:13] <kenvandine> oh true... i guess filemanager might be the only app to use it that way
[20:13] <kenvandine> pmcgowan, understood
[20:15] <tedg> sergiusens, Looking around I don't see anything.
[20:16] <sergiusens> tedg, ack, I just sent a bunch of questions to the appstore list
[20:16] <tedg> sergiusens, Perhaps look at how the 0install folks do it.
[20:16] <sergiusens> tedg, 0install?
[20:17] <sergiusens> oh, maybe typo :-)
[20:17] <tedg> sergiusens, http://0install.net/
[20:17] <sergiusens> tedg, well I know cwayne-afk and mfisch sent an email with customization and stuff, they may have looked at it already
[20:20] <tedg> sergiusens, In Inkscape when doing relocatable binaries we change what we pass to bindtextdomain()
[20:21] <plars> jhodapp: mediaplayer seems to be exhibiting different behavior on mako vs. maguro. It is failing 1 test on maguro with build 75 (passed on 73, 74) but on mako has been failing 4-5 tests on all  3 of the latest builds
[20:22] <sergiusens> tedg, hmmm, bindtextdomain can work for compiled apps
[20:24] <jhodapp> plars, thanks for the heads up...I don't have a mako but rsalveti does
[20:24] <tedg> sergiusens, patch qmlscene ?
[20:25] <plars> jhodapp: if time allows, will try to do some more retries, and try locally too, but trying to get through a lot of the other tests right now also
[20:25] <sergiusens> tedg, to take a param with the domaindir and domainname?
[20:25] <plars> jhodapp: I did retry once with the same results
[20:26] <sergiusens> tedg, if there is no better option this is as good as it gets
[20:26] <tedg> sergiusens, No, to set bindtextdomain with the correct value depending on the env.
[20:27] <plars> jhodapp: ah, there's a .crash file on both of them too: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4512/mediaplayer-app-autopilot/
[20:27] <jhodapp> plars, could you send an email to rsalveti and myself detailing which tests are failing and the output of them running with GST_DEBUG=*:3,*amc*:5,mirsink:5 as well as the logcat output?
[20:28] <plars> jhodapp: there's a link to the logcat and a list of the failing tests at the link I just posted, I'll need a bit before I can try it with the debug settings though.  Where do I set those?
[20:29] <sergiusens> tedg, I'll branch the qmlscene code (which is probably in a huge code base :-/) and see what I can do
[20:30] <jhodapp> plars, just set it on the command line before the test's executable name
[20:30] <tedg> sergiusens, Cool, check for UBUNTU_APPLICATION_ISOLATION=1 and then use the current working directory.
[20:30] <jhodapp> plars, for example: GST_DEBUG=*:3 ./my_media_tests
[20:31] <sergiusens> tedg, current working directory + rel path or just a hardcoded locale dir?
[20:31] <plars> jhodapp: the tests start the mediaplayer themselves though, don't they?
[20:31] <tedg> sergiusens, I imagine "$cwd/locale" would be best.
[20:32] <plars> jhodapp: so I don't think setting that on my side is going to get that downstream to the app
[20:32] <sergiusens> tedg, nah... -translation <translationfile> ............ Set the language to run in
[20:32] <tedg> sergiusens, ?
[20:32] <sergiusens> tedg, that already in qmlscene
[20:33] <tedg> How useless
[20:33] <tedg> I guess qmlscene was only ever built as a demo.  So I shouldn't give it too hard a time.
[20:34] <sergiusens> tedg, we were never supposed to use qmlscene, not sure why it was kept as the way to go
[20:34] <tedg> sergiusens, The Europeans are sleeping, let's blame them!
[20:34] <tedg> :-)
[20:35] <sergiusens> The qmlscene utility is meant to be used for testing your QML applications, and not as a launcher in a production environment. To launch a QML application in a production environment, develop a custom C++ application or bundle the QML file in a module
[20:35] <jhodapp> plars, it will, that's how I run the mediaplayer
[20:35] <sergiusens> that's from http://qt-project.org/doc/qt-5.0/qtquick/qtquick-qmlscene.html
[20:35] <jhodapp> plars, gstreamer is in-process to the mediaplayer
[20:35] <pmcgowan> sergiusens, upstream is working on something new and shinier, so we didnt want to duplicate that effort
[20:36] <plars> jhodapp: so I guess you aren't using phablet-test-run right?
[20:36] <sergiusens> pmcgowan, makes sense
[20:36] <cwayne> dobey, i'm sorry to keep harping on this, but i don't understand the issue int he icon-fix MR.  it's following the same convention as the other ubuntu-mobile apps, and we really need this icon fix for when we demo this
[20:36] <sergiusens> tedg, can we reuse that or should I still patch qmlscene?
[20:37] <tedg> sergiusens, We can't reuse that, we'd have to do too much special casing.
[20:38] <sergiusens> tedg, ack, I'll work on  a patch
[20:40] <jhodapp> plars, no I'm not
[20:41] <dobey> cwayne: if other apps are doing it, then they are doing it wrong too.
[20:41] <dobey> cwayne: but i'm not blocking that branch afaik
[20:42] <cwayne> dobey, that's where every other app's icon lives.  is literally every single app doing it wrong?
[20:43] <cwayne> dobey, it still needs top-approval, not sure who would do that?
[20:43] <m-b-o> balloons: ping
[20:43] <balloons> m-b-o, howdy
[20:44] <m-b-o> I'm fighting with a testing the updated removable list ite,
[20:44] <m-b-o> m
[20:44] <m-b-o> balloons: swipe to delete, where you have to click the trashcan icon
[20:45] <dobey> cwayne: i think you're overstepping the amount of exaggeration you need to provide in your argument.
[20:45] <dobey> cwayne: and the mobile apps are supposed to be migrated to click packages anyway, not remain debs, so yes, they would be doing it wrong in that respect as well.
[20:47] <dobey> cwayne: i don't know who all has privileges to set the global approve on those branches. sil2100 can at least. but i'm not going to. :)
[20:47] <balloons> m-b-o, ohh, what's wrong with it?
[20:48] <m-b-o> balloons: how to write an autopilot test for it
[20:49] <stgraber> barry: if you want to confirm that your parser is correct, I've marked image 75 as phased at 50% in saucy-proposed
[20:52] <balloons> m-b-o, well swipe as usual, and if you have to confirm it, then do so
[20:52] <balloons> I think the clock and rss reader both do that
[20:52] <balloons> are you stuck on a piece of it?
[20:53] <m-b-o> balloons: it's acm ewith an update som e hours ago, so I dont' know, if we are talking about the same
[20:54] <rsalveti> jhodapp: plars: I'll take a look, was planning to do that today anyway
[20:54] <rsalveti> I know some will indeed fail
[20:55] <rsalveti> as we're using the hw accelerated based media stack at today's image
[20:55] <plars> ah
[20:56] <rsalveti> plars: we're working on the remaining issues, but we decided to push it yesterday as that would finally bring the missing feature
[20:58] <m-b-o> balloons: https://code.launchpad.net/~martin-borho/ubuntu-weather-app/LocationLookup
[21:09] <barry> stgraber: cool, thanks
[21:13] <cwayne> stgraber, image 75 looking *much* better btw
[21:13] <balloons> m-b-o, can I have a look at this tomorrow? are you needing to land the branch now?
[21:14] <balloons> m-b-o, I see the diff. You do the drag and then click the trashcan
[21:15] <m-b-o> ballons: yes, and somehow it's going ahead too fast
[21:15] <m-b-o> or the click gets somehow dismissed
[21:15] <balloons> m-b-o, ok let me just visually see it :-)
[21:15] <balloons> one sec
[21:16] <balloons> m-b-o, I got brokenness off the bat
[21:20] <cwayne> Laney, heya! timezone worked when set from cli with the gdbus call!  although still not from system settings for me
[21:20] <sergiusens> slangasek, stgraber I'm having a bit of issues with the upstart-local-bridge; on the android side I have around a 100 events and on the local bridge on the ubuntu side I only get 4
[21:21] <slangasek> sergiusens: I don't know this code at all; your best bet is to ask jodh when he's around during the UK workday
[21:21] <sergiusens> slangasek, ok, I'll ask him early tomorrow
[21:21] <slangasek> sergiusens: I can try to reproduce here the issues you're seeing and maybe take a shot at debugging, but I'm coming in cold
[21:22] <sergiusens> slangasek, no worries, I'm waiting for salveti to apply my patches so the bridge is setup on boot so tomorrow jodh can have an easier debug session
[21:26] <stgraber> barry: note that those will automatically get flushed when 76 is released (unless I messed up the code, but I'm pretty sure that's tested ;))
[21:27] <barry> stgraber: not to worry.  i now have test data with that value, so i'm relatively confident that the live site can be handled
[21:29] <slangasek> so, I saw someone mention the other day this blank 'update manager' icon... anyone know what that's about?  I can't imagine that we're meant to have update-manager on the device, and package lists confirm it's not there.
[21:34] <stgraber> slangasek: not idea, but I've seen that icon on my devices for a few days now
[21:36] <rickspencer3> slangasek, stgraber that is the click app updater app
[21:36] <slangasek> ah
[21:36] <slangasek> WIP then? :)
[21:36] <rickspencer3> there should be a fix for the icon in the next promoted image, and a fix for it to "actually work" in the next image
[21:36] <rickspencer3> slangasek, well, I would say "bugs" more then WIP
[21:37] <rickspencer3> I suspect it will be fixed in 76, which I suspect will be promoted tomorrow
[21:37] <slangasek> ok
[21:37] <slangasek> and image promotion is still all manual overriding of test failures?
[21:37] <rickspencer3> slangasek, maybe we should rename it to "app updater" or something?
[21:37] <rickspencer3> slangasek, aiui, image promotion involves didrock's dipping the image in some kind of holy water
[21:37] <slangasek> rickspencer3: might be good to avoid confusion with the unrelated update-manager command on teh desktop
[21:38] <slangasek> rickspencer3: right, so still manual; my understanding was that the goal is to have images passing all tests on a standing basis so that they can be autopromoted, I wonder how close we are to that
[21:38] <rickspencer3> slangasek, I'll log that bug, but I don't know what to log it against!
[21:38] <slangasek> heh
[21:38] <rickspencer3> slangasek, we are not close
[21:39] <rickspencer3> and when we turn on Mir, I assume we will get further from that
[21:39] <slangasek> apparently the package name is 'click-update-manager'
[21:40] <rickspencer3> slangasek, https://bugs.launchpad.net/click-update-manager/+bug/1233863
[21:40] <ubot5`> Ubuntu bug 1233863 in Click Update Manager "app should be renamed to avoid confusion with system updates" [Undecided,New]
[21:41] <slangasek> rickspencer3: coolio
[21:43] <cjwatson> sergiusens,tedg: Patching eglibc to handle this in click packages would be pretty insane I think.  Setting TEXTDOMAINDIR seems reasonable.  How about doing it in aa-exec-click, which already sets various other environment variables?
[21:43] <sergiusens> slangasek, rickspencer3 shouldn't that live in settings too?
[21:43] <cjwatson> sergiusens,tedg: I don't like the idea of having to pass extra arguments when there's already a perfectly good environment variable.
[21:43] <rickspencer3> sergiusens, it's a super temporary app
[21:44] <sergiusens> rickspencer3, ack
[21:44] <rickspencer3> the functionality will be taken over by the apps scope asap
[21:44] <stgraber> [systemimage] Oct 01 21:43:53 2013 (18303) Upgrade path is 17:18:19:20:21:22:23:24:25:26:27:28:29
[21:44] <stgraber> barry: that's quite an update path ^
[21:44] <tedg> cjwatson, I don't see that variable get used in eglibc
[21:44] <sergiusens> cjwatson, sure, I'll confirm that TEXTDOMAINDIR works
[21:44] <cjwatson> tedg: I was going off the conversation above; I didn't check the name but I'm pretty sure one exists
[21:44] <barry> stgraber: indeed.  turn on verbose logging for a full dump of the candidates and scores
[21:44] <sergiusens> cjwatson, the next thing would be to see if we want a hardcoded location or something we can setup in the manifest
[21:45] <tedg> cjwatson, I thought so too, but I couldn't find one with grep :-/
[21:45] <stgraber> barry: oh, I'm sure it's right, I was just surprised to see one that long ;)
[21:45] <cjwatson> Maybe I'm remembering a conventional automake variable or something instead ...
[21:45] <tedg> And it seems that most projects set it in their build.
[21:46] <stgraber> barry: that's devel-proposed-customized which gets quite a few more updates than devel-proposed most of which are tiny
[21:46]  * barry nods
[21:47] <cjwatson> tedg: Hmph.  Maybe you're right. :-(
[21:48] <cjwatson> tedg: So what calls bindtextdomain in a qmlscene app, if anything?
[21:48] <cjwatson> Something in Qt I suppose
[21:48] <cjwatson> I'm assuming it uses gettext rather than being wrong in some different way
[21:49] <tedg> Heh, I'm not sure I'd assume that :-)
[21:49] <cjwatson> Oh God, .ts files
[21:49] <cjwatson> I hope we're not using those
[21:50] <tedg> It'd be nice if we could find a way were, for instance, GEdit could repackage as a click and things would generally work.
[21:50] <tedg> Not sure if that's possible, but I think it'd be a good goal.
[21:50] <cjwatson> Way out of scope for anything I care about
[21:51] <cjwatson> And I think it's the wrong goal - focus on the things we can't already do rather than furtling about with the things we can
[21:51] <cjwatson> (I understand where you're going but I think this is a fundamental misfocus that we're prone to)
[21:51] <cjwatson> https://bugreports.qt-project.org/browse/QTBUG-2404, grr
[21:52] <tedg> Sure, and I understand your point.  It just seems like "something that should work"
[21:52] <cjwatson> So what are we doing right now?
[21:52] <cjwatson> I mean, do we have qmlscene-ish translated apps at all, even non-click?
[21:52] <tedg> Not sure, sergiusens ? ^
[21:52] <sergiusens> tedg, cjwatson ... yes, dpm made me look yesterday... he has a rule that looks like this http://paste.ubuntu.com/6181462/
[21:53] <popey> cjwatson: clock has translations.. https://translations.launchpad.net/ubuntu-clock-app
[21:53] <sergiusens> *targe in rules
[21:53] <cjwatson> We could LD_PRELOAD bindtextdomain with a thing that tries the current directory first
[21:53] <cjwatson> You may vomit now
[21:53] <sergiusens> cjwatson, so it's mo
[21:53] <cjwatson> sergiusens: Is that in ubuntu-clock-app or something else?
[21:53] <popey> ./debian/ubuntu-clock-app/usr/share/locale/en_GB/LC_MESSAGES/ubuntu-clock-app.mo
[21:53] <cjwatson> Since I'm more interested in the app's setup code for it
[21:53] <popey> has lots of mo files
[21:54] <sergiusens> cjwatson, that's actaully the clock, yeah
[21:54] <sergiusens> cjwatson, but all apps have translations
[21:54] <tedg> cjwatson, I think patching eglibc makes more sense than LD_PRELOAD ;-)
[21:54] <cwayne> sergiusens, heyo, i made phablet-config work with the new (right!) way to change timezones: https://code.launchpad.net/~cwayne18/phablet-tools/phablet-config-timezone-fix/+merge/188727
[21:54] <cjwatson> tedg: Patching eglibc should be a last resort - high bar
[21:54] <cjwatson> Maybe LD_PRELOAD is a laster resort :-)
[21:55] <sergiusens> cwayne, goodie
[21:55] <cjwatson> popey: Hm.  So, all well and good, but what loads them?
[21:56] <lool> cjwatson: I think we recommend using the gettext bindings for QML apps
[21:56] <cjwatson> Has this been seen to actually load translations? :-)
[21:56] <popey> cjwatson: congratulations on reaching the limit of my knowledge on the subject. have a cookie.
[21:56] <cjwatson> Heh
[21:57] <lool> i18n.tr() calls
[21:57] <cjwatson> Oh, so it's in the UI toolkit
[21:57] <sergiusens> interesting
[21:58] <sergiusens> pmcgowan, do you know how the translation features are supposed to work?
[21:58] <pmcgowan> sergiusens, not exactly but I thought it was pretty transparent
[21:58] <cjwatson> So we could make the UI toolkit do this pretty easily
[21:58] <pmcgowan> whats the issue?
[21:58] <pmcgowan> sergiusens, this was worked out some time ago bit I dont have the details
[21:58] <cjwatson> pmcgowan: Never mind, I've found the code now
[21:59] <lool> cjwatson: that's *if* apps are using i18n.tr() calls, which is recommended, but I'm not sure they are doing
[21:59] <sergiusens> pmcgowan, just loading translations from non conventional paths as a click install path for a package ;-)
[21:59] <cjwatson> lool: clock is, anyway
[21:59] <lool> cool
[21:59] <pmcgowan> lool, pretty sure they are
[21:59] <cjwatson> So there's an i18n.bindtextdomain interface to set the domain, but clock doesn't use it
[21:59] <sergiusens> pmcgowan, what about ours?
[21:59] <pmcgowan> core apps team and our own guys do
[21:59] <sergiusens> pmcgowan, good
[21:59] <cjwatson> So it'll just get the default
[21:59] <pmcgowan> we had them all showing chinese at some point
[21:59] <cjwatson> i.e. we can't assume that right now core apps are doing something we can easily override for click
[22:00] <sergiusens> cjwatson, hmm, just found this https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1220395
[22:00] <ubot5`> Ubuntu bug 1220395 in ubuntu-ui-toolkit (Ubuntu) "translations are not updated after calling i18n.bindtextdomain" [Undecided,New]
[22:00] <sergiusens> it's click + translations
[22:02] <lool> cjwatson: I just did a quick grep to see whether we were calling bindtextdomain by default and it seems not; the i18n plugin isin ubuntu-ui-toolkit/modules/Ubuntu/Components/plugin/i18n.*
[22:02] <cjwatson> And https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1233071
[22:02] <ubot5`> Ubuntu bug 1233071 in Ubuntu UI Toolkit "Set up the translation domain automatically for click packages" [Undecided,New]
[22:03] <cjwatson> That looks like this is in progress
[22:03] <cjwatson> So I'm inclined not to try to dive in :)
[22:04] <sergiusens> cjwatson, yeah, too bad it seems we are in silos at times
[22:04] <cjwatson> In general it's not like you can take an arbitrary program configured with prefix=/usr and relocate it to be a click package anyway; takes work
[22:05] <popey> yeah, i wanted to clickify irssi for my phone but it looked like a lot of work ☹
[22:05] <popey> cowsay on the other hand...
[22:06] <sergiusens> yeah, not that much once you have all the workings in your mind
[22:06] <sergiusens> translations was new to me though
[22:06] <cjwatson> Certainly if it doesn't touch the filesystem then it's trivial, but not the general case
[22:06] <cjwatson> Even say man-db isn't going to work if you just shove it into a different shape on the filesystem since it knows about paths to bits of itself
[22:07] <cjwatson> Common
[22:07] <sergiusens> heh, luckily man doesn't have a reason to be in clicks... yet
[22:16] <cjwatson> sergiusens: I'm using it as an example of a not fundamentally all that complicated program that isn't relocatable, to try to deflate the implicit assumption I see going around that it might be straightforward to relocate existing packages without rebuilding.
[22:18] <cjwatson> (And, as I say, I think it'd basically be a waste of effort better spent elsewhere)
[22:20] <sergiusens> cjwatson, I'm not sure I follow, is that in general or specific to these apps?
[22:20] <cjwatson> What apps?
[22:20] <cjwatson> I'm off on a tangent, not talking about translation of core apps :)
[22:21] <cjwatson> Never mind
[22:21] <sergiusens> cjwatson, ok, then I did follow perfectly fine ;-)
[23:31] <krisabsinthe> having some difficulty getting the sdk setup properly. I dont see any "ubuntu touch" project templates. any thoughts?


[21:33] <setuid> Can someone give me a hand debugging why keystone -always- fails on 14.04 using openstack-install?:
[21:33] <setuid> I'm getting:  idle - hook failed: "config-changed"
[21:34] <setuid> I see this in the juju logs on that keystone host:
[21:34] <setuid> 2016-07-09 21:25:37 INFO worker.uniter.jujuc server.go:172 running hook tool "juju-log" ["-l" "ERROR" "FATAL ERROR: Could not determine OpenStack codename for version 8.1"]
[21:34] <setuid> 2016-07-09 21:25:37 ERROR juju-log FATAL ERROR: Could not determine OpenStack codename for version 8.1
[21:35] <setuid> I wiped the entire host, reinstalled, over and over, it dies here
[21:38] <setuid> This didn't work:
[21:38] <setuid> $ juju resolved --retry keystone/0
[21:38] <setuid> ERROR unit "keystone/0" is not in an error state
[21:38] <setuid> juju status --format tabular shows:
[21:38] <setuid> ID         WORKLOAD-STATE AGENT-STATE VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
[21:38] <setuid> keystone/0 unknown        allocating          1                            Waiting for agent initialization to finish
[21:40] <setuid> $ juju debug-hooks keystone/0 config-changed
[21:40] <setuid> ERROR error fetching address for unit "keystone/0": public no address
[21:40] <setuid> At this point, I'm out of options
[21:44] <setuid> juju debug-log shows:
[21:44] <setuid> machine-0: 2016-07-09 21:44:14 ERROR juju.worker runner.go:223 exited "firewaller": machine 1 not provisioned
[21:53]  * setuid tries with the /experimental ppa
[22:21] <jrwren> setuid: juju ssh to keystone/0 and check /var/log/juju/unit-keystone*.log
[22:22] <jrwren> setuid: err, nevermind. I see you already did.
[22:46] <setuid> Moving to experimental ppa seems to have fixed the keystone issue, though I don't know if it's going to introduce other instability that may be fixed in stable
[22:46] <setuid> i'll work with this for now
[22:57] <setuid> I stand corrected, that failed too
[23:01] <setuid> Exactly the same error message:
[23:01] <setuid> 2016-07-09 22:47:16 DEBUG juju.worker.uniter modes.go:31 [AGENT-STATUS] error: hook failed: "config-changed"
[23:06] <setuid> I'm floored, 14.04 has been out for how long? And openstack doesn't install on it -AT ALL-, for what, a year or more now?
[23:06] <setuid> Sorry, 2 years
[23:07] <jrwren> setuid: it does, but maybe not every openstack version.
[23:07] <jrwren> setuid: 14.04 was released with icehouse release AFAIK. So icehouse should run on it well.
[23:07] <setuid> This is liberty, the default in stable
[23:07] <setuid> Ok, let me try that
[23:08] <jrwren> well, https://wiki.ubuntu.com/OpenStack/CloudArchive  ubuntu supports openstack releases LTS same years as ubuntu distro
[23:08] <jrwren> libery it unsupported in about 10months.
[23:08] <jrwren> but liberty should be supported and work. I'm sorry. I don't know.
[23:10] <setuid> crazy, because it keeps pulling down 198 of the keystone charm, but 255 is current in stable
[23:10] <setuid> Right, so basically... NONE of this works
[23:10] <setuid> I've tried every version, every permutation, every tool.. openstack-install, conjure-up, juju, etc. on 14.04 and 16.04, with every version of openstack
[23:11] <setuid> been fighting this for 4 weeks now, hundreds of install attempts
[23:13] <setuid> icehouse blows up right away
[23:13] <setuid> Unable to create container:  (lxc-create: utils.c: get_template_path: 1340 No such file or directory - bad template: ubuntu-cloud
[23:14] <setuid> lxc-create: lxccontainer.c: do_lxcapi_create: 1435 bad template: ubuntu-cloud
[23:14] <setuid> lxc-create: lxc_create.c: main: 318 Error creating container openstack-single-setuid)