[01:41] <rsalveti> plars: sorry, was off today
[01:41] <rsalveti> plars: you could try to start the console before the container is fully up
[01:42] <rsalveti> and see if it helps at least
[07:33] <didrocks> sil2100: Mirv: hey! FYI, I've changed quite extensively the status computation on the CI Train spreadsheet to get some new features unblocked I'm working on. If you see anything unusual, do not hesitate to tell me :)
[07:34] <sil2100> didrocks: ok ;) Thanks! What are the new features? Is it for the ci bot? ;p
[07:34] <didrocks> sil2100: it's for the bot, I wanted to finish the data side before getting to the bot side :)
[07:35] <didrocks> nothing should be visible in the change (as long as you don't look at the hidden columns)
[07:35] <didrocks> but the formulas have changed
[07:38] <Mirv> didrocks: ok :) I took away "/" from B2 in metadata since Chipaca was annoyed by the double "//":s in the URL:s, but it will need to be added back if there was some URL that then lacks the "/" (all URL:s seemed to work for me)
[07:38] <sil2100> didrocks: coolio ;) Was there any news regarding CI Airline lately?
[07:38] <didrocks> sil2100: I guess ask the CI guys. They are working on it, I see tickets flowing!
[07:39] <didrocks> Mirv: you have done that in every silos?
[07:39] <Mirv> didrocks: I tried all the button links in two silos, I guess the links should be identical in each silo?
[07:40] <didrocks> Mirv: ah, metadata, yeah! all is fine, thanks ;)
[07:40] <Mirv> yes, metadata, that :)
[07:40] <didrocks> Mirv: maybe it's what was breaking the redirect?
[07:45] <Mirv> didrocks: hmm, that's possible too
[08:02] <sil2100> ChipacaUbuntu - I wonder what that is ;)
[08:20] <Chipaca> ooh, i was in the topic?
[08:20] <Chipaca> morning, all :)
[08:20] <Chipaca> NoNameYet_xnox: some day you too will be famous
[08:20] <NoNameYet_xnox> Chipaca: lol =)
[08:21] <ogra_> once he has a name for sure ;)
[08:21] <Chipaca> baby steps
[08:21] <NoNameYet_xnox> Chipaca: this is a protest for inability to upload things into development series =)
[08:21] <ogra_> ++
[08:21] <ogra_> i was expecting to see a post over the easter weekend ...
[08:22] <ogra_> seems i was wrong
[08:22] <Chipaca> lamp posts, maybe?
[08:23] <Chipaca> sil2100: Mirv: didrocks: good morning! Could I have a landing for silo 8 / row 25, please?
[08:23] <Chipaca> or is that what NoNameYet_xnox is complaining about
[08:23] <sil2100> Chipaca: let me see :)
[08:23] <sil2100> Chipaca: ah, you mean, you want it landed?
[08:23] <Chipaca> NoNameYet_xnox: are you complaining about there not being a dev series yet, or are you complaining about not having package upload rights?
[08:24] <Chipaca> sil2100: um.... is that silly of me?
[08:24] <ogra_> Chipaca, no dev series
[08:24] <sil2100> Chipaca: yeah, well, we would recommend waiting for U to open, since the other road is making the upload as an SRU - which might even take more time than waiting for U
[08:24] <ogra_> Chipaca, we are completely stuck until mark comes across with a name
[08:24] <sil2100> So I would recommend joining NoNameYet_xnox in the protest!
[08:25] <Chipaca> sil2100: well... the fixes there would be nice to have on a stable image, unfortunately. Is that SRU land, or do we cut stable images from dev series too?
[08:28] <didrocks> popey: sil2100: ogra_: Mirv: davmor2: do we need to have a meeting this morning?
[08:29] <popey> happy to.
[08:29] <ogra_> didrocks, we need to talk about python-evdev ... there was a long discussion about us bringing it back on the foundations ML
[08:29] <davmor2> didrocks: yes
[08:29] <davmor2> :D
[08:29] <ogra_> but we can do that on IRC
[08:30] <didrocks> ogra_: IRC is fine for me
[08:30] <ogra_> ok
[08:31] <Mirv> hmmkay
[08:31]  * davmor2 slaps didrocks with a kipper for getting him up this early for no good reason ;)
[08:31] <sil2100> didrocks: so no meeting? I personally have nothing to report, due to things being blocked landing-wise ;)
[08:31] <ogra_> didrocks, so barry seems to have had the expectation that dropping of python-evdev actually removes all of python2 his mail sounds slightly unhappy that we brought it back in
[08:31] <Mirv> davmor2: "this early", 5 hours ago! :)
[08:31] <didrocks> sil2100: yeah, I think it's useless
[08:32] <didrocks> ogra_: well, it didn't removed it, right?
[08:32] <didrocks> ogra_: we saw it only removed python-evdev itself
[08:32] <ogra_> didrocks, we did for a few images ...
[08:32] <didrocks> but nothing else
[08:32] <ogra_> which shows that it does *not* drop any other packages
[08:32] <didrocks> ogra_: did he even checked on those images before?
[08:32] <davmor2> Mirv: look just cause you live in the Wrong timezone is not our problem ;)
[08:32] <didrocks> ogra_: exactly
[08:32] <didrocks> ogra_: did he track/check that?
[08:32] <didrocks> or work on why?
[08:33] <ogra_> didrocks, no, but he insists it has to go any wants the change reverted in an SRU ...
[08:33] <ogra_> seems gallery app keeps py2 around additionally
[08:33] <ogra_> https://code.launchpad.net/~barry/gallery-app/py3autopilot/+merge/208055
[08:33] <ogra_> another proposed SRU for that case
[08:33] <Mirv> I'm taking some time to please bzoltan to try to get saucy qt 5.2 backport ~done
[08:34] <didrocks> ogra_: he needs to talk to the SRU team about it anyway
[08:34] <ogra_> didrocks, not sure what to do, i dont think we should break the world with SRUs
[08:34] <bzoltan> Mirv: that would be awesome :)
[08:34] <didrocks> ogra_: well, let him lead that and do all the paperwork
[08:34] <ogra_> and dropping evdev again will surely cause extra work in the infra
[08:34] <didrocks> ogra_: I don't care for us, it's easy to bring it back if it's broken
[08:34] <UtilitarianUvula> My SRU is small, cherry picked to address problems in what got into the stable image
[08:34] <UtilitarianUvula> FWIW :)
[08:35] <didrocks> ogra_: he better has to fix the packaging and ensure he doesn't regress
[08:35] <didrocks> ogra_: if he wants that
[08:35] <ogra_> didrocks, it still breaks testing
[08:35] <didrocks> ogra_: so, it's a no
[08:35] <didrocks> ogra_: it's him who wants to bring that issue, it's him to fix it
[08:35] <ogra_> which means infra needs work or we keep it as is
[08:35] <didrocks> not us
[08:35] <didrocks> and he needs to coordinate with the infra guys
[08:35] <didrocks> let him lead that
[08:35] <didrocks> if it's important to him
[08:35] <ogra_> well, he noeeds to know about the additional work it causes
[08:35] <didrocks> being clear we won't accept it if it's not all polished
[08:36] <didrocks> yeah, I didn't see that in any ML I'm in
[08:36] <ogra_> no, itsthe foundations ML
[08:36] <didrocks> right
[08:36] <didrocks> so if he wants that, tell him that he needs to do the work
[08:36] <didrocks> and coordinate with the needed people
[08:37] <NoNameYet_xnox> didrocks: coordinate exactly what?
[08:37] <NoNameYet_xnox> didrocks: the gallery-app merge-proposal is stand alone, porting remaining portions of ap to python3.
[08:37] <ogra_> NoNameYet_xnox, changing and fixing all tests
[08:37] <ogra_> NoNameYet_xnox, that wont help if the automated tests all fail
[08:38] <didrocks> NoNameYet_xnox: apparently ogra_ is telling that dropping python2 from the image will impact the infra
[08:38] <ogra_> we rolled back because there were issues
[08:38] <ogra_> right the issue was only found because the infra tests went flat
[08:38] <NoNameYet_xnox> didrocks: gallery-app merge proposal has nothing to do with dropping python2 from the image, as in just merging that will not cause python2 to be dropped from the image.
[08:39] <ogra_> NoNameYet_xnox, barry wants python-evdev gone again
[08:39] <NoNameYet_xnox> cihelp
[08:39] <didrocks> NoNameYet_xnox: were we talking about the gallery-app MP?
[08:39] <ogra_> NoNameYet_xnox, whioch causes the automated tests to fail
[08:39] <didrocks> NoNameYet_xnox: read the beginning of the discussion
[08:39] <ogra_> gallery-app is just a side note here :)
[08:41] <ogra_> NoNameYet_xnox, and the gallery-app fix is fine if it passes testing ... its is the breaking of the other tests due to dropping -devdev that causes issues for us since all tests would have to be touched and app devs would always need to test in rw mode)
[08:41] <ogra_> *-evdev
[08:42] <popey> NoNameYet_xnox: did you autopilot test sudoku before uploading to the store?
[08:42] <NoNameYet_xnox> ogra_: that's why i said -evdev should be seeded into ubuntu-touch seed, instead of relying on transitive dependency from one package.
[08:43] <ogra_> NoNameYet_xnox, right, i was with you on that one but others insisted to just revert the change
[08:43] <ogra_> which was done in the end
[08:43] <NoNameYet_xnox> popey: sudoku ? sudoku was published at 180 2 weeks ago and i didn't upload that recently.
[08:44] <popey> NoNameYet_xnox: sorry, I meant stock ticker. my bad
[08:44] <ogra_> same thing :)
[08:44] <popey> hah
[08:45] <NoNameYet_xnox> popey: i did a while a go, but not on the latest-greatest trusty image. it will be a while until i can upgrade to retest on recent. (dual-boot is preventing installing upgrades due to "not enough battery")
[08:46] <popey> NoNameYet_xnox: we always autopilot test before uploading core-apps to the store. please can you run it next time before upload?
[08:46] <NoNameYet_xnox> popey: ok. in this particular case, it can't go worse, since stock-ticket autopilot tests have never passed =)
[08:46] <NoNameYet_xnox> popey: and they were fixed to finally work in recent commits.
[08:47] <popey> ☻
[08:47] <NoNameYet_xnox> popey: when my phone charges up enough, i'll rerun the tests.
[08:47] <popey> k
[08:47] <popey> Thank you.
[08:52] <UtilitarianUvula> Mirv: in answer to your quesiton on the spreadsheet, it can also go to U, yes; I'll be merging trunk (which has these changes) into automatic (which these changes were cherrypicked from) once things are landed
[08:53] <UtilitarianUvula> you know, the closer we get to Zaftig Zebra, the more nervous I am every time a name needs to be announced
[08:57] <pete-woods> didrocks: hi, is there any information about how the CI train works with SRUs?
[08:58] <didrocks> pete-woods: just do as usual, and don't diverge too much, like focus on bug fixing
[08:58] <pete-woods> basically I have a bug fix for something in trusty main, and wondered what the process would be, (being a person who has never had upload rights, that sorta thing)
[08:59] <pete-woods> as usual means use CI train? or means follow the SRU page on the wiki?
[08:59] <ogra_> both :)
[09:00] <didrocks> pete-woods: yeah, both
[09:00] <didrocks> just follow the SRU page
[09:00] <UtilitarianUvula> didrocks: are stable images only cut from stable releases?
[09:00] <didrocks> and proposed your fix to trunk
[09:00] <didrocks> UtilitarianUvula: for now, yes
[09:00] <didrocks> it's still under discussions
[09:00] <UtilitarianUvula> ok :)
[09:01] <pete-woods> didrocks, ogra_: okay, thanks guys, that makes sense :)
[09:01] <didrocks> pete-woods: yw ;)
[09:05] <Mirv> UtilitarianUvula: yeah I meant only U or also T. for SRU you need to file a bug with Impact/TestCase/RegressionPotential and also otherwise follow the https://wiki.ubuntu.com/StableReleaseUpdates instructions
[09:06] <UtilitarianUvula> Mirv: ah, ok. But to SRU I need it in U first :)
[09:06] <ogra_> well, it needs to land in U at the same time at least
[09:07] <ogra_> (you can do paperwork and prepare the trusty side even without U existing)
[09:07] <UtilitarianUvula> okie doke
[09:08] <UtilitarianUvula> should I create a new bug for all the things fixed in the branch, or should I tag each bug fixed in the branch separately?
[09:08] <UtilitarianUvula> the former sounds like less hassle
[09:44] <mandel> om26er, hello! so you were right and umd was broken!!! sorry for doubting you! mea culpa!
[09:45] <mandel> om26er, I have updated the code and now it works perfectly ok (I have tested and retested) can you take a look?
[09:45] <om26er> mandel, sure no problem, Since the release is out i guess you wont need my testing onow
[09:46] <mandel> om26er, probably not, but you added a comment and it does not feel right if I edit it :)
[09:46] <mandel> om26er, is better that you do it
[09:46] <om26er> mandel, yes, sure. let me do that.
[09:47] <mandel> om26er, awesome, thx
[09:53] <didrocks> ogra_: I kicked an image to check that the infra is working fine
[09:54] <ogra_> ok
[09:58] <davmor2> Morning all
[09:59] <imgbot> [10:30]  * popey spies a bazillion webapps from ogra_ 
[10:30] <ogra_> haha
[10:31] <ogra_> only 15
[10:46]  * didrocks goes for a run
[10:48] <mardy> Can please someone help me in making Jenkins build this: https://code.launchpad.net/~mardy/signon-ui/oxide/+merge/215661 ?
[10:50] <davmor2> ogra_: did you poach popey 's create a webapp is one easy script or something
[10:50] <popey> not my script
[10:51] <ogra_> i have my own script
[10:51] <ogra_> :)
[10:51] <ogra_> but i just learned that the app name doesnt come from the .desktop file anymore
[10:51]  * ogra_ edits all the app neames :(
[10:52] <popey> yeah, when i saw them appear in the store I thought "he probably doesn't want that"
[10:54] <ogra_> and with bild.de we finally have the true yellow press in the store
[10:54]  * ogra_ notices that no brit is brave enogh to upload a sun.co.uk webapp :P
[10:55] <davmor2> ogra_: that's cause we'd rather chew our own arms off
[10:55] <NoNameYet_xnox> ogra_: haha
[10:55] <ogra_> davmor2, well, you dont have to use it :)
[11:14] <imgbot> [11:14] <imgbot> [11:16] <ogra_> didrocks, seems to still work
[11:24] <popey> anyone else see nothing "available" from the app scope on #302?
[11:24] <popey> http://popey.com/~alan/phablet/device-2014-04-22-122428.png
[11:25] <sil2100> Works fine here
[11:27] <davmor2> popey: how many apps do you have open?
[11:27] <ogra_> same here
[11:27] <popey> davmor2: 5
[11:27] <popey> just the ones you see on that screenshot
[11:28] <ogra_> is your U1 auth messed up perhaps ?
[11:29] <popey> its there
[11:29] <popey> dunno how I'd know if it was messed up tbh
[11:29] <ogra_> heh, me neither
[11:29] <popey> ah!
[11:29] <popey> if I search, i then see available category
[11:29] <davmor2> popey: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-22-122906.png same 5 apps open
[11:30] <popey> nowsearching unblocked it
[11:31] <sil2100> Notabug, ship it!
[11:31] <popey> we did!
[11:31] <sil2100> Oh...
[11:31] <sil2100> ;)
[11:32] <davmor2> only click updates right?
[13:24] <bfiller> sil2100: hi, can I have a silo assigned for line 26 please?
[13:27] <sil2100> bfiller: sure, give me a moment ;)
[13:28] <rsalveti> morning
[13:28] <Mirv> bfiller: sil2100: assigned
[13:28] <bfiller> thanks guys
[13:29] <sil2100> ;)
[13:29] <Mirv> bfiller: as usual, it targets trusty still so if you want to land it to trusty you'll need SRU bug filed
[13:29] <Mirv> and if you want to land it to U series, you need to wait until we have a name for U...
[13:29] <sil2100> Well, for experimenting and testing, silos are good anyway
[13:30] <sil2100> Since we don't have too many reliable usages now anyway before U is opened
[13:30] <bfiller> Mirv: are we building anymore trusty phone images?
[13:30] <Mirv> bfiller: today we built one, and probably tomorrow too at least if U doesn't open. I don't know the grand plan, though.
[13:33] <alecu> hello
[13:43] <sergiusens> Mirv: is there any plan in motion to be able to still release the gallery, camera et.al. as just click? I gess bfiller can continue work on that side
[13:43] <sergiusens> a merge and commit without a publishing
[13:44] <ogra_> sergiusens, there is  big MP from barry to switch gallery to py3
[13:45] <sergiusens> ogra_: can't go into trunk, which means it can't get to the click which means it is also blocked with our current infra
[13:45] <ogra_> yes, it is SRU blocked anyway
[13:45] <ogra_> without a U release where it can land first
[13:46] <sergiusens> ogra_: if it were just a click package it can get to the store
[13:46] <cjwatson> In the past we've gone ahead with SRUs in advance of the next series opening
[13:46] <sergiusens> ogra_: no need for SRUs there
[13:47] <cjwatson> I don't see why we should suddenly start hard-blocking on that now
[13:47] <ogra_> cjwatson, yeah, i would expect it could land at the same time at least
[13:47] <ogra_> so that the SRU work could already be done
[13:47] <cjwatson> We just need to make sure that we copy things forward as needed
[13:48] <ogra_> sergiusens, well, not so sure ... we should actually define how we update core apps for released systems ...
[13:48] <sergiusens> ogra_: all core apps have been getting updates since saucy was released ;-)
[13:48] <ogra_> probably less strict than SRUs but we kind of need to make sure they get enough testing on the old image etc
[13:49] <ogra_> did anyone ever test them against saucy ? :)
[13:49] <sergiusens> ogra_: well that was one of my complaints about autopilot making a change in it's API; apps became untestable
[13:50] <ogra_> right ...
[13:50] <ogra_> :/
[13:50] <ogra_> that will bite us at some point i guess
[13:50] <ogra_> (i really dont care if they work on saucy but we will have to test backwards compatibility from some point on)
[13:51] <ogra_> (once we had our first "stable" release)
[13:52] <sergiusens> ogra_: anyways, fwiw, I thought the store for clicks would of been treated the same as a partner archive
[13:53] <sergiusens> ogra_: I would put emphasis to still run the click tests on trusty now (as part of ci)
[13:54] <ogra_> right
[13:54] <ogra_> well, i think core apps that we actually ship by default need some special treatment wrt testing backwards compatibility
[14:00] <sil2100> Damn, thunder close by
[14:01] <ogra_> russians ?
[14:01] <ogra_> :)
[14:02] <popey> lol
[14:12] <rsalveti> plars: would you mind trying the serial console with http://paste.ubuntu.com/7307282/?
[14:12] <rsalveti> that will give you a tty1 right after the kernel is done booting
[14:13] <ogra_> rsalveti, why wait on cdmanager ?
[14:13] <ogra_> *cg
[14:13] <plars> rsalveti: will do
[14:13] <rsalveti> ogra_: don't need to wait on it specifically, just wanted it to be started together with the container
[14:13] <rsalveti> and not blocked by it
[14:14] <ogra_> i would just start on startup :)
[14:14] <ogra_> then you can even watch the container starting :)
[14:14] <rsalveti> right, let me try if that would work
[14:16] <rsalveti> plars: ogra_: yeah, startup went fine as well: http://paste.ubuntu.com/7307308/
[14:16] <ogra_> right, as long as the device node exists and getty is available it shoudl be fine
[14:16] <rsalveti> yup
[14:16] <ogra_> botrh is dealt with in the initrd
[14:17] <plars> rsalveti: that seems to get me a login pretty early
[14:17] <ogra_> cool
[14:17] <plars> but...
[14:18] <ogra_> dont say that !
[14:18] <ogra_> :)
[14:18] <plars> it's hard to say if adb is available by then anyway
[14:18] <rsalveti> oh, it's not
[14:18] <ogra_> it isnt
[14:18] <ogra_> adb starts after the container
[14:18] <rsalveti> adb needs the container to be up
[14:18] <ogra_> or after the container properly failed
[14:18] <plars> the hope here was that even if the device gets wedged in a state where nothing works (stuck booting but can't get to fastboot, or recover, or adb, or anything) that we could use this to recover from it
[14:18] <ogra_> if the container didnt attempt to start at all you are screwed
[14:18] <rsalveti> plars: you can still
[14:18] <plars> ok, so this would get us shell access earlier at least
[14:18] <ogra_> (on my list for fixes in U)
[14:19] <rsalveti> just use the tty to reboot the phone
[14:19] <plars> could be some corner cases still
[14:19] <ogra_> i doubt serial will hellp you with the fastboot case
[14:19] <plars> so now we just need a good way to shove this into the device at install time.. I also added --autologin root so that we get a shell rather than a login
[14:19] <plars> ogra_: yeah, I suspect there are lots of cases where we're still screwed
[14:20] <plars> ogra_: so the other avenue we're pursuing is instrumenting the buttons with relays
[14:20]  * ogra_ wonders why you dont just deply a hacked up adbd job that always starts regardless
[14:20] <rsalveti> sudo reboot -f bootloader should get you back to the bootloader
[14:20] <ogra_> right
[14:21] <plars> which is still complicated I guess since sometimes we don't know what power state the device is in, but in theory you could have it hold the power button down for [? seconds] and also hold the volume up/down for [? seconds] and end up at the bootloader ready to flash a known good image
[14:21] <rsalveti> ogra_: you could still get adb in some weird states
[14:21] <rsalveti> uart would always work
[14:21] <ogra_> true but i guess thats a very rare corner case
[14:22] <sergiusens> plars: keep in mind that the boot into fastboot sequence is different per device ;-)
[14:22] <plars> sergiusens: yeah
[14:22] <rsalveti> yeah, and uart would only work for mako atm
[14:22] <plars> sergiusens: these devices need a big debug plug on them that gives you full control, so that our lives would be simple :)
[14:23] <ogra_> they do have it ... if you buy these devices without the case and call them devboards ...
[14:23] <ogra_> :)
[14:23] <rsalveti> hm, nexus 7 could have the same uart interface, let me check
[14:24] <plars> rsalveti: so these plugs might work on flo also?
[14:24] <rsalveti> will check
[14:24] <plars> rsalveti: https://plus.google.com/104363289464878469115/posts/AbvyWECLPXo
[14:25] <rsalveti> right
[14:25] <plars> https://android.googlesource.com/kernel/tegra/+/b0d6be9e2033745e46624e518f55e067b75bcd50
[14:26] <rsalveti> but this is for the older n7
[14:26] <plars> rsalveti: sounds like the n5 might have it also
[14:26] <plars> rsalveti: can't find anything about manta though
[14:26] <ogra_> call samsung :)
[14:27] <rsalveti> yeah, I think they all have an easy way to get uart
[14:28] <plars> http://www.abclinuxu.cz/blog/Lorris/2013/12/serial-console-on-google-nexus-5
[14:28] <rsalveti> great
[14:28] <plars> ogra_: yeah, I'll just call their customer support line and ask about that
[14:28] <plars> heh
[14:28] <ogra_> *g*
[14:31] <rsalveti> plars: yeah, so we could make it work for both mako and flo
[14:33] <plars> sergiusens: any way with u-d-f to specify an extra/local custom tarball to add at install time? Something like this could go in at install time so it's there from the first boot like that, but I'm guessing this conf file won't be part of the normal image for obvious reasons
[14:34] <ogra_> you just have to dump it in the right place before the device reboots i guess
[14:34] <ogra_> or even after install and a forced reboot to recovery
[14:35] <rsalveti> can't it just be part of the custom tarball?
[14:35] <rsalveti> or do we need more than one custom tarball?
[14:35] <sergiusens> plars: wrt rsalveti is on the right track
[14:35] <ogra_> rsalveti, no, but we need to deploy that tarball
[14:35] <rsalveti> ogra_: flashing it with u-d-f
[14:36] <sergiusens> ogra_: what would it have and how do you guarantee it's not stepping on anythings toes?
[14:36] <ogra_> does u-d-f have an option to inject that ?
[14:36] <plars> sergiusens: but u-d-f doesn't give us an option to do that, and also, what if we are already testing the custom image?
[14:36] <rsalveti> we could add the support for multiple custom tarballs, which I believe it was discussed before already
[14:36] <sergiusens> plars: well I had no requirement for that; was trying to follow the upgrade spec as close as possible
[14:37] <plars> we really just need to deploy one file, and it's not one that would exist already. but we can't wait until the first boot to deploy it
[14:37] <ogra_> dumping a signed tarball into /cache/recovery and rebooting into recovery should be enough, no ?
[14:37] <plars> sure
[14:37] <sergiusens> I would rather have stgraber's opinion on this
[14:37] <sergiusens> ogra_: to sign it you would need access to the magic keys
[14:37] <sergiusens> I can't sign client side
[14:38] <ogra_> wasnt there an option for unsigned ...
[14:38]  * ogra_ thought he saw some MP pass by recently 
[14:38] <sergiusens> plars: it doesn't need to be a customization tarball; just an extra tarball in the image server
[14:38] <ogra_> https://code.launchpad.net/~jani/goget-ubuntu-touch/tls-skip-verify/+merge/216141
[14:38] <plars> sergiusens: but I can't put this on the image server
[14:39] <sergiusens> ogra_: that's for the https server itself
[14:39] <plars> that's the point
[14:39] <ogra_> ah, k
[14:39] <sergiusens> plars: not even on a different channel?
[14:39] <plars> sergiusens: not if we're going to test the same images
[14:39] <ogra_> well, if you modify them you taint them in any case
[14:39] <sergiusens> plars: well it's sort of the same if you are going to inject it anyways
[14:39] <plars> sergiusens: this is to help make the smoke testing devices more resilient so we have another avenue to recover them if we get a busted image
[14:40] <ogra_> and if you do that you can as well just adb push ...
[14:40] <plars> ogra_: and if the image we just flashed is busted?
[14:40] <ogra_> then you have serial to force it back into bootloader at least
[14:40] <sergiusens> plars: can't we have this always in and triggered form initrd from a property? ogra_ rsalveti?
[14:41] <plars> ogra_: then we wouldn't have the opportunity to adb push
[14:41] <ogra_> sergiusens, i have "fix adbd if no container is there" on top of my TODO
[14:41] <sergiusens> plars: I can add the option to inject; but it needs to be signed; or you need to discuss this with stgraber at least
[14:41] <ogra_> wont need a property
[14:41] <ogra_> but yeah, we could ship some code for special cases
[14:42] <rsalveti> we could have a property for it, but not sure if we want this enabled by default
[14:42] <ogra_> properties dont work without container though
[14:42] <ogra_> apart from grepping presistent.$prop files
[14:43] <rsalveti> atm we could safely have an upstart job that could start a tty at the right UART
[14:43] <rsalveti> we're starting adb by default
[14:43] <ogra_> right
[14:43] <ogra_> but how do you know the UART device ?
[14:43] <rsalveti> it'd just need to parse proc/cmdline to find out the right UART
[14:44] <ogra_> assuming you want that job to be generic
[14:44] <ogra_> ok, thats trivial
[14:44] <rsalveti> yup
[14:44] <ogra_> but only works if the cmdline has a console= entry
[14:44] <rsalveti> that's fine
[14:44] <ogra_> (and one that points to an existing device node actually)
[14:50] <sergiusens> ogra_: rsalveti plars I still prefer to have a .*-debug channel; it would also be used to enable adb once we disable it by default
[14:50] <sergiusens> and by handling it on the server/image side; we can keep in sync and not play catch up
[14:50] <ogra_> well, we want to have a developer mode
[14:50] <ogra_> even on images where  its disabled by default
[14:50] <plars> sergiusens: that also means we'd need a -debug of things that already have customizations (customized image)
[14:51] <sergiusens> ogra_: yeah, but you need to manually enable it ;-)
[14:51] <ogra_> sergiusens, yeah
[14:51] <ogra_> manually or via a script
[14:51] <sergiusens> plars: custom images only really on the customization framework; changing the boot cmd goes away from a customization scope
[14:52] <sergiusens> custom images only really stick to the customization framework; changing the boot cmd goes away from a customization scope
[14:53] <plars> sergiusens: I wasn't suggesting to change the boot command, just add in that extra file under /etc/init
[14:53] <sergiusens> plars: well file placing is supposed to stay in /custom for customization
[14:54] <plars> ah, I see
[14:54] <sergiusens> plars: just saying, while you say you are customizing the image; it is far from a custom image that we promote as custom images
[14:54] <plars> so it's more than just something a customization tarball can add
[14:56] <sergiusens> plars: any tarball can add anything, so we are fine there; it's just not a custom image if you add that mod (market speak)
[14:57] <ogra_> lets just ship the needed bits by default and add switches to en/disable them
[14:59] <plars> ogra_: as long as that switch can be flipped before the first boot, but then I think we're back to the same problem
[15:00] <ogra_> it could be a cmdline option ... but that would mean to need to modify the boot.img
[15:00] <ogra_> or it could be a property ... for that you would have to touch some file in /data/property/ from recovery
[15:02] <rsalveti> I'd like the developer mode to be enabled via a property or such
[15:02] <rsalveti> and for that we could use a custom tarball as well
[15:02] <ogra_> hmm
[15:02] <sergiusens> yeah, let
[15:02] <ogra_> i dont want to force people to custom tarballs for just setting a switch
[15:02] <sergiusens> let's just no call it custom tarball
[15:02] <sergiusens> as it seems to confuse people
[15:03] <sergiusens> ogra_: well it's only for ci
[15:03] <ogra_> adb shell touch /data/property/persist.plars.mode
[15:03] <ogra_> ;)
[15:03] <plars> ogra_: that doesn't get wiped when you flash?
[15:04] <ogra_> if itr does you just touch it again while you flash
[15:05] <plars> sure, so we would just  need a --pwned option in u-d-f
[15:06] <rsalveti> ogra_: right, the custom is just because we can deploy custom properties with it
[15:06] <ogra_> --plarsed :)
[15:06] <rsalveti> but yeah, anyway, we could hack it around
[15:06] <rsalveti> let's just enabled it by default and we can clean everything up once we create the developer mode switch
[15:07] <ogra_> right, we just need to put it under the switch later
[15:10] <plars> sure, this could probably all be part of the developer mode once we have a real consumer/product mode for it to be distinct
[15:11] <ogra_> right
[15:12] <ogra_> we should probably aggregate all that into one package
[15:12] <ogra_> so that you can just omit that package at build time for images that are not supposed to ever have a dev mode
[15:16] <plars> yeah
[15:24] <ogra_> didrocks, did you plan to have an evening meeting ?
[15:24] <ogra_> (its not like much changed since the morning)
[15:26] <sil2100> I wouldn't mind, but I don't have too much to say/discuss landing-wise still
[15:27] <ogra_> right, and landings are still getting to -proposed only anyway
[15:27] <ogra_> or did anything migrate to -updates yet
[15:33] <didrocks> ogra_: we do have an image
[15:33] <didrocks> so I guess just a 10 minutes one would be find
[15:34] <ogra_> sure
[15:34] <didrocks> fine*
[15:34] <ogra_> not like it has any interesting changes though :)
[15:34] <didrocks> ogra_: what? popey's changes are uninteresting? :)
[15:34] <ogra_> nah, but i trust them to be heavily tested anyway
[15:34]  * popey hugs ogra_ 
[15:34] <popey> nice recovery
[15:35] <ogra_> and tehz CI infra is off
[15:35] <ogra_> so we dont get any automated results
[15:36] <didrocks> ogra_: hum, why?
[15:36] <didrocks> plars: ? ^
[15:36] <ogra_> didrocks, see the ML
[15:36] <plars> didrocks: apparently there's a storage failure in the dc
[15:37] <didrocks> ah, like 10 minutes ago :p
[15:37] <didrocks> don't ask me to be fresh on the last 10 minutes ;)
[15:40] <ogra_> pfft
[15:43] <sil2100> ;)
[16:02] <didrocks> robru: popey: coming?
[16:24] <robru> didrocks, any word when U is going to open?
[16:25] <ogra_> lol
[16:25] <didrocks> robru: I don't know more than you. We need a name first :p
[16:25]  * ogra_ points robru to sabdfl 
[16:25] <ogra_> please ask there
[16:26] <Laney> srsly
[16:26] <Laney> we should redesign this new name process :(
[16:26] <ogra_> robru, dont count on being able to land anything in U this week ... even if we have a name it will take a few days to get everyhitng up and runnning
[16:26] <robru> ok
[16:26] <ogra_> Laney, ++
[16:26] <ogra_> we should juat use random letter generators
[16:27] <ogra_> *just
[16:27] <Laney> like the early nexus 7 images?
[16:27]  * Laney sniggers
[16:27] <robru> didrocks, so what are we doing with landings then? should I just take the week off? ;-)
[16:28] <ogra_> you can land stuff in trusty-proposed
[16:28] <Laney> not anything though
[16:28] <robru> just fixes right?
[16:30] <ogra_> SRU stuff, yeah
[16:30] <Laney> https://wiki.ubuntu.com/StableReleaseUpdates#When
[16:57] <sil2100> robru: it is best to ask everyone if they want their fix to land as an SRU or maybe they prefer waiting for U ;)
[16:58] <robru> sil2100, well I doubt anybody will *prefer* to wait an extra week on their landings.
[16:58] <ogra_> and make sure they understand how much paperwork an SRU can be :)
[16:58] <robru> sil2100, it's more like "how life threatening is this landing?"
[16:58] <sil2100> robru: well, SRUs can take a week as well, and a lot of paperwork which we will not do for them
[16:59] <sil2100> robru: so sometimes it might not be even worth it
[16:59] <robru> sil2100, oh, we're not doing the SRU paperwork? yippee!
[17:03] <ogra_> why would you
[17:03] <asac> all went fine today?
[17:03] <ogra_> asac, what would you expect to have "gone"
[17:03] <ogra_> we are all stuck
[17:04] <ogra_> new release cant open
[17:04] <asac> ok i realize it was a bit of a loaded question :)
[17:04] <ogra_> heh
[17:04] <asac> I take, besides that it seems to be all good :)
[17:04] <ogra_> nothing moved, so nothing broke :)
[17:05] <ogra_> well, not true, popey landed some well tested click packages and didier rolled an image including them
[17:05] <asac> see
[17:05] <asac> thats how it should be; just hold the line by name :P
[17:05] <asac> lol
[17:09] <ogra_> heh
[18:29] <robru> ogra_, cyphermox : I seem to be getting red light of death on my nexus 4. you guys ever seen this? http://forum.xda-developers.com/nexus-4/general/final-fix-nexus-4-red-light-death-t2250454
[18:29] <robru> i'm not really well equipped for opening the phone
[18:36] <robru> guess i gotta go buy some torx wrenches... sigh
[18:39] <pmcgowan> robru, you should not need to
[18:39] <pmcgowan> red light is good, let it charge
[18:40] <robru> pmcgowan, yeah, I've seen it before where it won't turn on but then i let it charge for a few hours and it's fine... but in this case it was plugged in through the entire easter weekend
[18:40] <pmcgowan> robru, with the wall wart?
[18:40] <pmcgowan> it can get in a state where its not actually charging
[18:40] <robru> pmcgowan, no, plugged into laptop usb
[18:40] <pmcgowan> yeah usb not good enough
[18:41] <pmcgowan> when its low, needs more amps
[18:41] <robru> pmcgowan, ok, it's plugged into the wall now, i'll give it a shot again in a bit
[18:41] <pmcgowan> ok
[18:48] <robru> hmmm now it's turned itself on after just a couple minutes of charging ;-)
[18:49] <pmcgowan> robru, perfect
[18:49] <pmcgowan> thats what it do
[18:49] <robru> pmcgowan, thanks, saved me a long trip to the store ;-)
[18:49] <pmcgowan> in my experience they can always be revived
[18:50] <pmcgowan> plug in, loooong press, what for redlight, let it charge
[18:50] <robru> pmcgowan, yeah, I've revived it a couple times before, but usually only after it had been unplugged for a long time. never seen it die after being plugged in all weekend
[18:50] <pmcgowan> that is odd
[18:50] <pmcgowan> but if laptop was off, usb was too
[18:50] <robru> pmcgowan, no no, laptop is always on ;-)
[19:14] <kgunn> asac: you on?
[19:14] <kgunn> wondering if there is like a master view of transitioning touch from trusty to whatever "u" is gonna be
[19:17] <kgunn> and sort of a hidden question there, if i think we're gonna land mir soon... e.g.  non-blocking swap buffers which fixes qt gui thd block
[19:17] <kgunn> should that be for both trusty and "u"
[19:18] <robru> kgunn, from my perspective, the only value of landing fixes in trusty is if they impact the unity8 preview session for desktop users... if you're talking about phone-only fixes then they should just wait for u.
[19:20] <kgunn> robru: thanks...in that instance it sounds like a "u" target
[19:21] <kgunn> sorry to be so out of touch, if i land something today...is it "u" by default?  or does it go to trusty ?
[19:21] <kgunn> i would assume "u"...
[19:21] <robru> kgunn, well it goes to "trusty" because u doesn't exist yet. but it can't get to trusty without going through SRU, which is a lot of paperwork and extra testing
[19:22] <robru> kgunn, so for the most part all landings are blocked until u gets created, unless we're talking about some critical desktop fix, then we can SRU it for trusty
[19:25] <pmcgowan> kgunn, we can all take vacation until mark has a name
[19:25] <robru> pmcgowan, yes, that's what ogra told me earlier today ;-)
[19:25] <pmcgowan> I see NoNameYet is catching on
[19:25]  * kgunn thinks ...what!?!?!
[19:27] <robru> it does seem a little bit silly to me that our entire operation is completely held up on one guy picking a codename. I'm not sure why we couldn't just open an archive called literally "u" and starting landing there, and then just rename it later
[19:27] <cjwatson> Sadly that would break a bunch of stuff
[19:27] <cjwatson> I spent some time thinking about it last cycle and thought "nah, Mark will have learned his lesson and this won't happen again"
[19:27] <robru> cjwatson, does your IRC client ping you at every mention of "archive"? ;-)
[19:27] <cjwatson> No, I just happened to be reading ...
[19:28]  * kgunn also considers old will shakespeare...a rose is a rose
[19:28] <cjwatson> I also thought about making the version the primary "name" rather than the codename, although that also has complicated problems associated with it
[19:28] <josharenson> doanac, I had a build fail yesterday, but I think I fixed it. How do I manually kick of the jenkins job again?
[19:29] <doanac> josharenson: can you share the MP?
[19:29] <cjwatson> Basically I was kind of not motivated to work on this because it's a really stupid problem to have to spend any cycles at all on fixing, rather than just having a dratted codename in the first place
[19:29] <doanac> josharenson: we are in the midst of an outage so it might not be possible at this very moment
[19:29] <sergiusens> cjwatson: more importantly, what happens after z?
[19:29] <robru> cjwatson, true
[19:29] <kgunn> someone needs to file a bug on the next release that's a showstopper that says we can't release w.o a name for next
[19:29] <robru> sergiusens, easy, it'll just be zz ;-)
[19:30] <cjwatson> sergiusens: I assume we wrap around.  I've been whack-a-moling all the cases where people assume codenames are sorted alphabetically for some time
[19:30] <josharenson> donac: :-p bummer. The MP is https://code.launchpad.net/~josharenson/mir/install_glmark2/+merge/216504 if its possible
[19:30] <cjwatson> kgunn: AFAIK we actually have a codename, we're just blocked on Mark blogging about it so that we're allowed to make it public
[19:30] <kgunn> lol
[19:30] <cjwatson> I kid you not
[19:30] <robru> cjwatson, how do you "fix" code that sorts ubuntu codenames alphabetically? just hard-code the list without sorting?
[19:30] <doanac> josharenson: you've done the right thing. I believe this isn't running because our jenkins servers are affected by the outage
[19:30] <doanac> a new commit on the branch should trigger jenkins to re-run
[19:31] <cjwatson> robru: Well, you fix the data so that that code doesn't need to exist
[19:31] <robru> ah
[19:31] <josharenson> doanac, ok I'll just be patient
[19:31] <cjwatson> robru: e.g. a while back we fixed the versions of packages in -backports to be ubuntu14.04.1 or similar rather than trusty.1, that kind of thing
[19:31] <cjwatson> robru: And there's distro-info for mapping codenames to versions
[19:32] <robru> cjwatson, BUT WHAT HAPPENS IN 2099?! WHAT THEN?!?! ;-)
[19:32] <cjwatson> I see no problem with 1.0~ubuntu100.04.1 :-)
[19:32] <robru> good call
[19:32] <cjwatson> Versions act sensibly with that kind of thing
[19:32] <cjwatson> We'll all have made our millions from the 2038 bug by then anyway
[19:39] <renato> hi guys could you check why jenkins did not build this MR: https://code.launchpad.net/~renatofilho/address-book-app/fix-1306798/+merge/216732
[19:39] <dbarth> robru: good evening, we have a new silo ready to land (silo 005)
[19:41] <robru> dbarth, it'll probably have to wait until U opens unless you feel the fixes are important enough for SRU for desktop trusty.
[19:42] <dbarth> robru: what are the options? severity level expected for an SRU?
[19:42] <dbarth> robru: you can see the bug reports, we're talking about links not opening in g+ or facebook for example
[19:42] <dbarth> robru: ie, good to land imo for phone at least, and desktop when updates are considered appropriate
[19:43] <pmcgowan> dbarth, can we get a blanket SRU for webapps?
[19:43] <pmcgowan> what ever happened to that
[19:43] <robru> dbarth, yeah, we do tend to SRU everything for webapps
[19:43] <robru> dbarth, https://wiki.ubuntu.com/StableReleaseUpdates#When
[19:43] <dbarth> right, i think that qualifies
[19:44] <dbarth> pmcgowan: could do yes, since we'll have some more to close the gap with what we had when using the browser as a container
[19:45] <dbarth> (vs the new oxide)
[19:45] <pmcgowan> dbarth, right, be worth greasing the landings now
[19:45] <pmcgowan> based on the bug set target
[19:46] <robru> dbarth, ok i'll hit publish on that silo, I see 2/3 of those bugs are already in SRU format, will need that third one converted into an SRU
[19:46] <dbarth> oh sure?
[19:46] <dbarth> fine
[19:47] <dbarth> let me search the main sru request we had
[19:47] <robru> dbarth, this is the one to SRU-ify: https://bugs.launchpad.net/unity-webapps-googleplus/+bug/1308784
[19:50] <renato> robru, could you check why jenkis did not build this branch? https://code.launchpad.net/~renatofilho/address-book-app/fix-1306798/+merge/216732
[19:50] <robru> renato, well, jenkins is down. but that's more of a fginther question.
[19:53] <dbarth> robru: https://bugs.launchpad.net/unity-webapps-googleplus/+bug/1308784
[19:53] <dbarth> robru: the description should be better now
[19:53] <robru> dbarth, great, thanks
[19:53] <robru> dbarth, i'll subscribe ubuntu-sru to those bugs and then it's up to them.
[19:54] <dbarth> thank you
[19:54] <dbarth> i'll m&c tomormrow morning
[20:03] <balloons> fginther, ping
[20:03] <fginther> balloons, pong
[20:04] <balloons> fginther, lol your email answered my question. I was really wanting music to have the real device testing for mp's. The mp I'm proposing requires it
[20:04] <balloons> music still has the plugin issue, so, got it :-)
[20:05] <fginther> balloons, how far off is that problem from being solved?
[20:05] <balloons> fginther, let me see
[20:06] <sergiusens> fginther: can we add the testing of the clicks pre store landing? as in the ones in the 'click' view?
[20:06] <sergiusens> just a post build job that installs and runs the tests
[20:08] <balloons> fginther, sounds like it's rolled up in media-hub, and is *soon*
[20:09] <fginther> sergiusens, I had started some work on what you are describing, but that got redirected by working on a different method with balloons and others
[20:10] <fginther> sergiusens, we're trying to basically do autolanding with the click build and test as a part of that
[20:12] <balloons> right.. so there's no confusion.. the click that was generated by the mp that passed everything can go into the store
[20:12] <balloons> less work, less surprises I hope
[20:12] <sergiusens> balloons: it's not part of media hub
[20:12] <sergiusens> balloons: your music problem is tied to grilo and media scanner
[20:12] <fginther> sergiusens, is this something that would directly help you, because converting all the projects to this method may be a little ways off. Adding a test job to the current click build jobs may be a short term solution
[20:13] <balloons> sergiusens, well mediascanner 2.0 is supposed to drop the plugin
[20:13] <balloons> I guess I'm misspeaking to say mediahub is a requirement then, eh?
[20:13] <sergiusens> fginther: if you do what I ask, we can atest off the bat that a click app passes it tests and upload directly to the store
[20:14] <sergiusens> balloons: yeah, media hub was a req for removing qtpowerd, which it already has been
[20:14] <plars> I just heard that q-jenkins has storage again, and confirmed that the image tests on 303 are now running
[20:16] <sergiusens> fginther: this would also offload testing autopilot manually from popey and myself
[20:17] <balloons> sergiusens, I believe what's happening does that already
[20:17] <balloons> you remove an MP, it generates a click, tests in on the device and you approve. You can then simply grab that click and place it into the store
[20:17] <balloons> *review an MP, hah
[20:18] <sergiusens> balloons: what if you need multiple MRs?
[20:18] <fginther> balloons, I do have some concerns about this working right away. we've already noticed that some apps are not passing when testing on the phone
[20:19] <sergiusens> balloons: what if we need a new translation pushed? Those don't go through MP/MRs
[20:19] <fginther> sergiusens, I'll try to do an interim solution to testing of clicks. it's just a bit of work
[20:19] <balloons> sergiusens, yes it doesn't eliminate building a click from trunk
[20:20] <sergiusens> fginther: balloons in the following weeks; I'm adding x86/armhf fat click packages; those would also be harder to test from MPs I guess
[20:20] <balloons> sergiusens, but I don't think we should force testing on the click build.. that's a parm or separate job
[20:20] <sergiusens> balloons: that's why I said post build step ;-)
[20:20] <sergiusens> it's different job
[20:20] <balloons> sergiusens, any hopes of landing this btw? Or did I miss it? https://code.launchpad.net/~sergiusens/phablet-tools/emu_prov/+merge/207440
[20:21] <fginther> balloons, it would be implemented as two separate jobs, using the existing job to build it and then another job to run the test
[20:21] <balloons> sergiusens, click-buddy still needs some love for armhf builds I think.. I'm still using my own chroot.. I'm guessing you too
[20:21] <balloons> fginther, fair enough
[20:22] <sergiusens> fginther: balloons to summarize one job builds trunk -> if it passes, it runs the tests in a job (passing the click as a parameter)-> if it passes, a possibility of pushing to store (passing the click as a parameter)
[20:22] <sergiusens> balloons: my chroot is currently broken; I can't build anything
[20:22] <balloons> sergiusens, you want jenkins to push to the store?
[20:23] <sergiusens> balloons: yes; to mitigate the one password/key to rule them all problem
[20:23] <balloons> sergiusens, yes I remember your broken chroot :-)
[20:23] <balloons> sergiusens, I like that
[20:23] <balloons> uploading has been streamlined, it's completely possible
[20:28] <sergiusens> balloons: wrt to click-buddy; I'm going to try and get consensus with zbenjamin during sprint time and just do everything once; we have a google doc rolling with some loose ideas
[20:28] <balloons> sergiusens, yes I've been working on the file manager click build issues, and one of the issues is click-tools and qtcreator don't agree on the manifest file layout
[20:29] <balloons> so at the moment I'm not sure of a way to allow building with both to work
[20:32] <balloons> sergiusens, do you mind sharing the doc with me?
[20:32] <sergiusens> balloons: yeah, I'll have to find it again though :-)
[20:33] <balloons> :-)
[21:29] <josharenson> josepht, I'm trying to get lp:qa-dashboard to run locally, and I'm having some issues. Are you able to help?
[22:50] <bfiller> robru: can I have a silo for line 28 please?
[22:52] <robru> bfiller, sure thing, you got 16
[22:52] <bfiller> robru: cheers
[23:09] <bfiller> robru: and one for line 29 too please
[23:10] <robru> bfiller, ok, you got 18 ;-)
[23:11] <bfiller> thanks
[23:11] <robru> you're welcome
[23:56] <josharenson> cjohnston do you happen to _not_ be eod?