[08:24] <yfried> hi, I'm looking for a way define ifcfg files via cloud-init. can anyone point me to an example?
[22:06] <harlowja> fyi smoser  + others ; http://blog.oddbit.com/2014/12/10/cloudinit-and-the-case-of-the-changing-hostname/
[22:06] <harlowja> perhaps time to adjust that?


  When PHP calls one of our Oracle database packages, a query in the package executes against an execution plan that causes it to take 30 minutes to get the results.
[16:18] <maxolasersquad> If we call that package directly in the database, or with Ruby or Python, the query runs in milliseconds.
[16:29] <mhall119> what's a database package?
[16:30] <maxolasersquad> mhall119: Oracle has its own language, PL/SQL, which is stored as database objects.  A package is a collection of procedures and functions.
[16:30] <mhall119> ah, ok
[16:30] <mhall119> I have no experience with them
[16:30] <mhall119> is it the execution that takes 30 minutes, or is it transfering data from Oracle to PHP?
[16:30] <maxolasersquad> We have added a bunch of debugging.  It is the execution of the SQL statement.
[16:31] <mhall119> I've noticed that some DB drivers pull data only when needed, while other's load all available data when the query is executed
[16:31] <mhall119> maxolasersquad: the execute command in PHP? or the query processing in Oracle?
[16:31] <maxolasersquad> These packages execute on the database.  There's no good explenation as to why they would execute differently by who called it.
[16:32] <mhall119> if PHP is reading data while others are not, that might account for it
[16:32] <maxolasersquad> PHP does something calls the OCI driver with something like "BEGIN foo.bar(args) END;"
[16:33] <maxolasersquad> We capture, in the procedure, the time it was called, and with what parameters, and the time that different points of the code are executing.
[16:34] <maxolasersquad> So we can see that execution of the SQL query taking a long time, but once it is done, PHP gets the results and processes them quickly.
[16:34] <maxolasersquad> However, if we call that same package with the OCI drivers for Ruby or Python, that query executes really fast.
[16:34] <maxolasersquad> It's rather frustrating.
[16:35] <maxolasersquad> We keep making small changes to the query, and that fixes it, but any time a small dependency changes, the query goes to poop, and we have to play some more.
[16:37] <maxolasersquad> We've decided if we ever get stuck, we will have PHP call Ruby, which will call the package, and send the results up the chain.
[16:40] <mhall119> lol
[17:52] <itnet7> RoAkSoAx: ping
[18:01] <RoAkSoAx> itnet7: pong
[19:05] <DammitJim> can someone help me with java basics on negative numbers?
[19:17] <mhall119> what's to know?
[19:18] <DammitJim> I'm so confused about the simplicity of negative numbers
[19:18] <DammitJim> I'm reading a register from a radio and it gives me 0xFFAB
[19:18] <DammitJim> that's -55 in decimal
[19:19] <DammitJim> so, my question is... can I do regular arithmetic with this short?
[19:28] <mhall119> as far as I know
[19:38] <DammitJim> darnet... it seems I need to sign extend it


[10:00] <danboid> Happy Halloween jujuers! What an apt day for me to show up back here!
[10:00] <danboid> Is there a guide to recovering control of a juju controller? How do I identify it and then how do I register it or whatever s that I can run `juju status` etc again?
[10:01] <danboid> By identify I mean if I can log into it (which I can) then there must be some files present somewhere that identify it as a juju controller
[10:02] <danboid> I'm trying to re-assemble some a jujju openstack installation that got moved / disconnected that wasn't properly documented
[10:06] <danboid> I need to be able to run juju register to see whats not connected up yet but I lost the credentials / key for juju
[10:06] <danboid> I mean juju status


[00:37] <boiko> plars: bfiller_afk: tomorrow I will investigate those crashes
[03:03] <plars> t1mp: I made one minor but important change to that branch, so you might want to repull it. I've proposed a merge for it, and it ought to land in trunk of lp:ubuntu-test-cases/touch tomorow
[03:05] <imgbot> [04:25] <imgbot> [04:25] <imgbot> [05:13] <Mirv> good morning
[05:58] <Mirv> now I realize I forgot to ask sergiusens for click credentials yesterday, after ball_oons taught me how to publish click packages. on the other hand, I'd like to go through the first time by double-checking the steps anyway.
[05:58] <Mirv> (regarding the gallery-app)
[06:07] <Mirv> nice to see 100% green again http://ci.ubuntu.com/smokeng/trusty/touch/mako/261:20140325.3:20140304/7375/
[07:39] <Mirv> tvoss: were you planning to test+land dbus-cpp ppc64el fix before the process-cpp one? I mean, you are not having a problem of not having a silo for process-cpp yet?
[07:39] <tvoss> nope
[07:40] <tvoss> Mirv, coming back to you in ~30
[07:40] <Mirv> I take that as a positive answer to my triple negations etc ;)
[07:40] <Mirv> cool
[07:42] <didrocks> Mirv: 3rd day of the week, triple negations… Tomorrow, four? :)
[07:44] <Mirv> :)
[07:55] <sil2100> Morning!
[07:56] <sil2100> didrocks: so, I checked the dch parameters, and found the difference between precise and now - in precise we need to use "--release-heuristic changelog", as by default it uses 'log'
[07:56] <sil2100> didrocks: it works differently as the default heiristics looks for dput upload files, not the changelog contents ;/
[07:56] <didrocks> sil2100: oh, I was overleading that in the directory
[07:56] <didrocks> but as we moved CI Train, I guess we missed that
[07:56] <didrocks> yeah
[07:56] <didrocks> you're more than right
[07:57] <didrocks> so the fix is easy!
[07:57] <didrocks> morning sil2100 :)
[07:57] <didrocks> sil2100: want to propose a branch? ;)
[07:57] <sil2100> didrocks: ok ;)
[07:57] <didrocks> sil2100: with some unit tests will be bonus!
[07:57] <tvoss> Mirv, hey, I'm confused :) https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-ppc64-el/+merge/211894
[07:57] <tvoss> says that it is merged
[07:57] <sil2100> Will try, guess it won't be that hard ;p
[07:58] <didrocks> sil2100: shouldn't, thanks!
[07:59] <Mirv> tvoss: err. let's see.. it seems to have been published by robru (somehow) https://lists.ubuntu.com/archives/trusty-changes/2014-March/013069.html
[08:00] <tvoss> Mirv, it used to be in silo 001 before
[08:02] <Mirv> tvoss: it looks to me that sil2100 published it on Monday http://<IP_ADDRESS>/job/landing-001-2-publish/59/ :D maybe he can explain something to this confusion
[08:02] <Mirv> I'm not seeing a line in CI Train where it got published
[08:02] <sil2100> hmm, I remember publishing that in CI train
[08:03] <Mirv> tvoss: and yes it build for ppc64el, and we got 100% pass on CI Train too from image #261 so I guess that counts as tested.. https://launchpad.net/ubuntu/+source/dbus-cpp/2.0.0+14.04.20140322-0ubuntu1
[08:03] <tvoss> Mirv, so you don't need me to do anything, correct? :)
[08:03] <sil2100> Mirv: I guess something racy happened, let's set it to landed I guess ;)
[08:04] <Mirv> tvoss: yeah no need, let's get that silo to your newest process-cpp line then :)
[08:04] <Mirv> sil2100: only free silo?
[08:05] <sil2100> Mirv: yes, only free silo in the m&c, and then let's set it to Landed manually :)
[08:05] <Mirv> running
[08:05] <sil2100> Thanks o/
[08:05] <tvoss> Mirv, hang on, I need to bump build deps before we can do that
[08:05] <tvoss> Mirv, give me ~15
[08:05] <Mirv> tvoss: ok
[08:07] <Mirv> FYI we'd have the gallery-app click package built too, if we'd just have someone to push it to the store together with publishing landing-009
[08:18] <tvoss> cjwatson, for https://code.launchpad.net/~thomas-voss/process-cpp/fix-death-observer/+merge/211996 and your comment on build deps: Do I have to bump the build deps and make them versioned?
[08:20] <tvoss> cjwatson, as in: requiring libprocess-cpp-dev (>= 1.0.0) in dbus-cpp for example
[08:22] <Mirv> thomas has a silo now, so he can click build when the brances are double-checked to be ready
[08:23] <ToyKeeper> Oi, it has been a long day.  I just realized I marked all my test results with image 261, but it was really image 262.
[08:26] <didrocks> ToyKeeper: just update on the spreadsheet, thanks for the testing!
[08:26] <ToyKeeper> I already did.
[08:26] <tvoss> Mirv, can I just add trunk branches to the silo as well? To check that everything still works together?
[08:26] <dbarth> sil2100: hi
[08:27] <dbarth> sil2100: there seems to be an issue with landing silo 002
[08:27] <dbarth> a message about a package in the unapproved queue
[08:28] <sil2100> dbarth: let me take a look
[08:28] <sil2100> dbarth: ah, might be due to the freeze
[08:29] <sil2100> didrocks: btw. looking at the unit tests ;p When and where do we run those unit tests? As I already see a zillion unit tests that should fail in our case! ;)
[08:29] <Mirv> tvoss: if you're not planning to publish those trunks, maybe just build the silo and then update to the silo locally and to the test builds? I mean, it becomes slightly tricky if there are "just out of interest" builds/branches in the PPA which need to be cleaned before publishing.
[08:30] <didrocks> sil2100: hum, are you sure they are failing? I run them recently and they don't
[08:30] <Mirv> tvoss: if you want non-x86 PPA builds, I can help by building in another PPA against the landing PPA after it has built
[08:30] <didrocks> sil2100: nosetests tests/unit/
[08:30] <didrocks> sil2100: Ran 190 tests in 18.055s
[08:31] <sil2100> didrocks: they wouldn't fail for me here, would have to modify it to 'do the wrong thing' - but looking code wise they should just fail, as all the test_refresh_symbols_files_* compare the resulting changelog with the 'right' one, and this should fail - let me experiment ;)
[08:31] <tvoss> Mirv, alternatively, I could setup MPs for the packages that have a build and runtime dep on process-cpp, bumping the build-dep to libprocess-cpp-dev (>= 1.0.0)
[08:31] <tvoss> Mirv, does that make sense?
[08:32] <didrocks> sil2100: I don't use a mock dch, but let me check
[08:33] <dbarth> sil2100: ah, so what's the way forward?
[08:33] <didrocks> sil2100: yeah, only bzr, dput and sudo are mocked
[08:33] <Mirv> tvoss: do they need the rebuild and the bumping of build-dep? if so, yes it makes sense, but if there is no need other than testing that they WOULD build against the new process-cpp, again I'd use another PPA that builds against that landing PPA
[08:33] <tvoss> Mirv, I think I'm a fan of versioned build-deps here, so I would prefer bumping them
[08:34] <sil2100> dbarth: I think we'll have to poke the release team and try to convince them that it's something we need to get pushed through
[08:35] <Mirv> tvoss: if you can get approvals for the version bump MP:s similar to the other MP:s, sure I don't object :)
[08:35] <tvoss> Mirv, ack :)
[08:37] <tvoss> Mirv, could you have a look at http://<IP_ADDRESS>/job/landing-014-1-build/40/console
[08:37] <sil2100> didrocks: so, when running the unit tests locally by emulating what's going on on the citrain device (i.e. a precise system with heuristics default to log), then I get all the test_refresh_symbols_* tests failing
[08:37] <sil2100> didrocks: so on the citrain machine it has to be failing as well!
[08:37] <didrocks> sil2100: ah, so making sense!
[08:38] <didrocks> sil2100: let me see if I can install nosetest on the machine
[08:40] <sil2100> didrocks: anyway, I was shocked on how many tests you wrote for this :o There's like almost every case supported :o
[08:40] <didrocks> sil2100: I told you it's not some small scripts :)
[08:40] <sil2100> ;)
[08:40] <didrocks> Ran 190 tests in 21.974s
[08:40] <didrocks> FAILED (failures=7)
[08:40] <didrocks> sil2100: confirmed!
[08:40] <didrocks> and the diff contains this :p
[08:41] <didrocks> http://paste.ubuntu.com/7155572/
[08:41] <didrocks> which confirms the theory
[08:41] <didrocks> sil2100: so yeah, my fault was to only run the test on my machine :p
[08:41] <sil2100> didrocks: \o/ the branch for a quick-fix is here: https://code.launchpad.net/~sil2100/cupstream2distro/dch_heuristics/+merge/212788
[08:41] <didrocks> not a precise one
[08:42] <sil2100> didrocks: yeah, who would have guessed there would be these subtle differences ;p
[08:42] <didrocks> sil2100: excellent :)
[08:42] <didrocks> sil2100: well, TBH, I've seen it while putting the train in production
[08:42] <didrocks> and you can see I changed that when generating the changelog
[08:42] <didrocks> didn't thought about the symbols file
[08:42] <didrocks> though
[08:42] <Mirv> tvoss: I checked them out and it looks like lp:~marcustomlinson/unity-scopes-api/scope_process_lifetime would need another sync with the trunk to have the latest changelog entry included too before bumping the version
[08:43] <didrocks> sil2100: so approved!
[08:43] <Mirv> tvoss: there was a release on Monday of it
[08:43] <didrocks> sil2100: we'll put that in prod at the same time than the other changes (continuing on the spreadsheet refactoring for the request id support)
[08:43] <didrocks> sil2100: feel free to merge manually to cu2d
[08:44] <sil2100> didrocks: ah, we don't have an auto-merger?
[08:44] <didrocks> sil2100: unfortunately, not
[08:44] <sil2100> Ok :)
[08:53] <sil2100> Mirv: are you handling Bill's gallery-app landing, or can I pick it up and publish?
[08:59] <Mirv> sil2100: it needs the simultaneous click publishing, so we need someone that can push the (already built) click package too
[08:59] <Mirv> sil2100: and I can't do that even though I was taught how to, since I forgot to ask sergiusens for crendentials yesterday
[08:59] <Mirv> additionally, the Python publishing thing fails to run for me for some reason (it downloads random modules from the internet so maybe that's why)
[09:02] <pete-woods> seb128: morning! sorry to grab you as you arrive
[09:02] <pete-woods> but what you were worried about with the HUD sync has happened
[09:02] <pete-woods> seems my boss was immediate in following my instructions to clean the PPA
[09:03] <pete-woods> do you have any advice about what I should do?
[09:03] <seb128> hey pete-woods, I guess you need to put a new landing ask for the same vcs-es and do a new landing :/
[09:04] <seb128> infinity, slangasek, ^ (silo cleaned while the copy was in trusty unapproved queue, is there any way around redoing a build/upload)?
[09:06] <pete-woods> I do actually have another MR I'd have liked to add, so I can just request another silo (and not clean this time) if that would work
[09:06] <pete-woods> then maybe just reject the sync?
[09:06] <dbarth> sil2100: should i just go here on the channel and ask the release tema?
[09:08] <seb128> pete-woods, yes, rejecting the sync is fine
[09:09] <seb128> pete-woods, if you need a landing feel free to give me the merge requests urls, I can put one for you (I think thostr is off today)
[09:09] <pete-woods> seb128: the silo's in a weird state now, though, the branches have been merged, but the spreadsheet doesn't know it's clean
[09:10] <pete-woods> seb128: https://code.launchpad.net/~unity-api-team/hud/dbusmenu-safety-valve/+merge/212668 is the one
[09:10] <pete-woods> that branch is based on top of the merged trunk, though..
[09:10] <dbarth> sil2100: i'd like to flush the siloi to get started with the more important oxide branches for webbrowser-app
[09:11] <seb128> pete-woods, the weird state is because thostr stopped the clean job
[09:11] <seb128> pete-woods, but the ppa was already cleared
[09:11] <pete-woods> seb128: ah, he must have got my "wait, don't clean the PPA" ping too late
[09:12] <seb128> sil2100, Mirv, didrocks: what's the proper way to deal with that ^?
[09:12] <sil2100> dbarth: yeah, sorry, let's try doing that - was busy with something
[09:13] <didrocks> seb128: so, something was cleared, but the job was stopped?
[09:13] <didrocks> seb128: and so unassignement didn't work?
[09:13] <sil2100> pete-woods, seb128: so, branches are merged but packages still not released?
[09:13] <sil2100> Or is everything in the archive and merged in properly, just the silo is still there?
[09:13] <seb128> didrocks, sil2100: right, the clean job was started, it merged back and send the clean ppa order, then the job was stopped
[09:13] <pete-woods> sil2100: yes, the packages ended up in the unapproved list
[09:13] <seb128> so things are merged&cleaned
[09:14] <didrocks> seb128: wonder why people are doing that
[09:14] <didrocks> hum
[09:14] <didrocks> which silo #?
[09:14] <seb128> didrocks, because we overlooked that "sync to unapproved" are not copies
[09:14] <seb128> 11
[09:14] <pete-woods> didrocks: silo 11
[09:14] <didrocks> seb128: what the link with sync to unapproved?
[09:14] <seb128> didrocks, those syncs are links to the ppa, so when you clean the ppa the item in the unapproved queue becomes void/can't be accepted
[09:14] <didrocks> merge and clean will have failed with that
[09:15] <didrocks> telling don't merge, things are in unapproved
[09:15] <seb128> didrocks, well, we didn't want to block the silo until beta freeze
[09:15] <seb128> otherwise we are going to be out of silo and locked down today
[09:15] <didrocks> so override?
[09:15] <seb128> that's what happened
[09:15] <didrocks> nice… :/
[09:15] <seb128> until we realized that cleaned the ppa makes the upload unvalid
[09:15] <seb128> since the queue doesn't have a copy
[09:16] <seb128> just a pointer to the ppa librarian
[09:16] <didrocks> everything was blocked or some components passed?
[09:16] <seb128> you mean?
[09:16] <pete-woods> didrocks: hud didn't make it, the other package did
[09:16] <didrocks> ok
[09:16] <pete-woods> (libqtdbustest)
[09:16] <seb128> oh, right
[09:16] <didrocks> I suggest that you bzr push --overwrite HUD trunk to the previous status
[09:17] <didrocks> to reconcile with what's in the distro
[09:17] <didrocks> then, we force m&c
[09:17] <didrocks> and redo a landing
[09:17] <pete-woods> didrocks: should I go and reopen the MRs then?
[09:18] <didrocks> pete-woods: yeah, rewrite history basically! :)
[09:18] <pete-woods> okay, cool, I'll do that then
[09:18] <didrocks> pete-woods: seb128: if that request is set to landed, that's fine?
[09:18] <seb128> didrocks, can't we just add a landing for a new mp?
[09:18] <didrocks> (that's what will happen)
[09:18] <seb128> that would do trunk + that new change
[09:18] <didrocks> seb128: depends, is there any?
[09:18] <seb128> yes
[09:18] <didrocks> ok, that can work as well
[09:18] <seb128> https://code.launchpad.net/~unity-api-team/hud/dbusmenu-safety-valve/+merge/212668
[09:18] <didrocks> if you don't let the ball dropping and we are not in a middle-state
[09:18] <didrocks> pete-woods: ^
[09:19]  * didrocks runs m&c with "only free silo"
[09:19] <pete-woods> didrocks: I'm happy with whichever way you guys think will work
[09:19] <seb128> let put a landing ask for ^
[09:19]  * seb128 does that
[09:19] <didrocks> pete-woods: yeah, so just file a new request with that branch, but please mention that the rest in the decription will land as well
[09:20] <pete-woods> it's just frustrating being "unapproved" for bug fixes while if I had a phone FFE I could land anything
[09:20] <pete-woods> anyway, I'm not interested in moaning, I will get that landing request in
[09:20] <didrocks> pete-woods: we are in beta freeze, that's why desktop updates are blocked
[09:20] <seb128> I think the release team is making that more difficult that it should
[09:20] <seb128> they should let stuff in proposed and britney block
[09:20] <didrocks> yep
[09:22] <didrocks> and then people complain about Touch process ;)
[09:24] <seb128> didrocks, pete-woods, sil2100: l48
[09:24] <didrocks> sil2100: letting you assigned once the current silo is freed?
[09:24] <didrocks> (should be refreshed in less than a minute)
[09:25] <didrocks> sil2100: done, please assign
[09:26] <didrocks> pete-woods: seb128: set manually the previous status to "Landed but HUD"
[09:26] <sil2100> didrocks: should I explicitly specify that silo, or just leave citrain to decide which silo to use?
[09:26] <didrocks> sil2100: let CI Train deciding
[09:27] <didrocks> nothing remained in the silo
[09:27] <didrocks> it's really freed and gone
[09:29] <sil2100> dbarth: hmmm...
[09:29] <sil2100> dbarth: actually, give me some time to think about how to proceed ;/
[09:30] <dbarth> sil2100: sure
[09:30] <dbarth> sil2100: i just want to clear decks as much as you do i guess
[09:30] <sil2100> Yeah, it's a sticky situation
[09:30] <pete-woods> seb128, didrocks, sil2100: thanks for sorting me out here , guys :)
[09:31] <ogra_> |HELP
[09:31] <didrocks> pete-woods: yw :)
[09:32] <Laney> ah interesting
[09:32] <Laney> So deletion and queues don't interact very well
[09:32] <didrocks> popey: coming?
[09:32] <popey> sorry, yeah
[09:33] <ogra_> |HELP
[09:33] <imgbot> I am the firendly image watchbot
[09:33] <ogra_> :)
[09:33] <seb128> Laney, no they don't, pocket copies are not actual copies, they are pointers to the librarian
[09:33] <seb128> Laney, so when you clean the source you loose the data and the unapproved entry becomes invalid
[09:33] <Laney> firendly indeed
[09:33] <davmor2> ogra_: I don't believe you
[09:33] <Laney> seb128: I see
[09:33] <ogra_> heh
[09:34] <Laney> Not sure if that would be fixable in LP
[09:34] <Laney> but you could use an intermediate PPA
[09:34] <seb128> lol
[09:34] <seb128> more crazyness isn't the answer :p
[09:34] <seb128> just let thing in proposed and review there?
[09:35] <Laney> This argument is already hitting a wall, so I'll go and do something more useful
[09:35] <seb128> yeah, same here
[09:35] <seb128> I guess I don't care enough
[09:36] <seb128> let's hit the silos lockdown situation
[09:36] <Laney> I do, but if there is no option to change anything CI is doing then it's pointless even talking about it
[09:36] <seb128> but I guess that's going to come down back from management on why we lock everything then
[09:36] <seb128> Laney, I guess there is the option, but why isn't release open to consider changes as well?
[09:39] <Laney> Essentially I think that any process designed to work with the archive has to be able to deal with what it does, and that includes freezes sometimes
[09:39] <Laney> It could just be that LP can actually be fixed to work how we want it to here, but I don't know enough to say that
[09:39]  * Laney EOD :-)
[09:39]  * wgrant wakes up
[09:40] <Laney> o hai
[09:40] <wgrant> Haven't ready all of scrollback, but is the problem that a copy sitting in the queue will fail if the source PPA has the source removed?
[09:40] <wgrant> That should work if it's accepted within a week or so
[09:41] <Laney> Yeah
[09:41] <Laney> I assume there was an actual incident, but ...
[09:41] <seb128> infinity warned that if we clean the ppa we screw the items in the queue
[09:41] <seb128> we just took his words on it
[09:42] <wgrant> Well
[09:42] <wgrant> That was a problem back when stuff would sit in unapproved for weeks
[09:42] <wgrant> But stuff is copiable until at least seven days after it was deleted from the origin.
[09:42] <Laney> Would it be possible to notice the reference made by a copy record?
[09:43] <wgrant> Not in the current model.
[09:44] <Laney> Fair enough
[09:44] <wgrant> There's a redesign in progress, but it's currently blocked on a couple of other big projects.
[09:44] <Laney> Well anyway, I think 7 days should actually be alright for our purposes
[09:44] <Laney> People start pinging after 7 hours, anyway. ;-)
[09:44] <seb128> right
[09:50] <Laney> sil2100: ^^^ you should be alright
[09:53] <sil2100> didrocks: ^
[09:55] <didrocks> ok, then, just m&c with "ignore package in dest"
[09:56] <cjwatson> tvoss: I would tend not to unless the changes require the new APIs
[09:57] <tvoss> cjwatson, yup, same here. But with that, we cannot easily add trunk for the build deps to the silo as per what Mirv said
[09:57] <sil2100> dbarth: we might have a solution!
[09:57] <cjwatson> tvoss: or just wait until the new process-cpp is in trusty and then it won't matter
[09:58] <sil2100> dbarth: let me get back to you in a some minutes
[09:58] <cjwatson> tvoss: bumping the build-deps isn't *wrong*, I wouldn't spend much time agonising about it, but it does impede situations where you might otherwise be reasonably able to backport things
[09:58] <tvoss> cjohnston, ack and thanks
[10:00] <dbarth> sil2100: ok
[10:00] <didrocks> sil2100: Mirv: FYI, when I'll be in a little bit of a quieter place, I'll be able to finish the spreadsheet part and then switch to the new assignement silo/reconfiguration process
[10:00] <didrocks> I'll keep you posted
[10:03] <Mirv> ok
[10:13] <didrocks> davmor2: can you give me the new bug # ref?
[10:13] <didrocks> so that I can +1, set the appropriate priority as well
[10:14] <sil2100> didrocks: ok ;)
[10:17] <davmor2> didrocks: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1297770
[10:19] <davmor2> didrocks: I added the secondary icons visible in header as I assume the two are linked
[10:22] <didrocks> davmor2: yeah, I think they are
[10:22] <didrocks> sil2100: this is the bug to give to the unity8 team as well ^
[10:23] <didrocks> davmor2: please mention it's a regression from latest promoted image and the image #
[10:39] <sil2100> dbarth: ok, so, what we'll do - I'll merge and clean your silo (as we need to do some special handling) and then I can assign a new silo for your features
[10:39] <sil2100> dbarth: it seems that we can do it now even
[10:49] <tvoss> Mirv, Marcus and me are testing silo 14, would be great if you could setup a ppa for testing the process-cpp build-deps
[10:51] <dbarth> sil2100: perfect
[10:52] <dbarth> sil2100: need me to push some buttons?
[10:52] <sil2100> dbarth: no no, all is handled from our side ;)
[10:52] <sil2100> dbarth: which landing from your list is now the highest priority?
[10:55] <didrocks> Mirv: so, you're going to publishin landing-002 as we discussde?
[10:55] <pete-woods> seb128: hi, the HUD silo has been tested (and succeeded) now, would you be able to mark it as such for me?
[10:56] <sil2100> Mirv: I'll publish the gallery-app silo in the meantime
[10:56] <Mirv> tvoss: you can set one at https://launchpad.net/~thomas-voss/ or I can push builds to some PPA when you give me a list of packages to build against the landing PPA
[10:56] <Mirv> sil2100: thanks
[10:57] <tvoss> Mirv, ack
[10:58] <pete-woods> seb128: thanks :)
[10:59] <seb128> pete-woods, yw ;-) publishing as well (just not cleaning this time)
[10:59] <pete-woods> :)
[11:00] <Mirv> tvoss: so which way, your PPA or my PPA? :)
[11:00] <dbarth> sil2100: uh sorry; it's line 18
[11:00] <tvoss> Mirv, your PPA :)
[11:01] <Mirv> tvoss: does this happen to be the correct set: connectivity-api dbus-cpp platform-api platform-api unity-mir unity-scopes-api ? (reverse-depends -b libprocess-cpp-dev)
[11:01] <tvoss> dbus-cpp unity-mir and unity-scopes-api are sufficient
[11:03] <davmor2> didrocks: so it looks like the header in it's current format will be removed so what do you want to do about it?
[11:03] <didrocks> davmor2: I won't take any decision, I guess it's your/QA decision to take
[11:04] <didrocks> for it being a promotion blocker or not
[11:04] <didrocks> like, are we happy to have users with such bugs on their phone
[11:04] <davmor2> Oh I wouldn't block on it
[11:09] <Mirv> tvoss: rebuilds of those against landing-014 visible now at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper/+packages?field.name_filter=&field.status_filter=published&field.series_filter=trusty
[11:09] <tvoss> Mirv, thank you
[11:20] <sil2100> dbarth: oh, but line 18 is still not set to ready - is it ready?
[11:24] <sergiusens> Mirv, what's up? How were you shown the process?
[11:31] <sil2100> sergiusens: morning! Could you release a new gallery-app to the click store? :)
[11:31] <dbarth> sil2100: ah wait, yes i was putting on hold
[11:31] <dbarth> sil2100: just re-checking the branches real quick
[11:32] <sergiusens> sil2100, yeah
[11:32] <dbarth> sil2100: oh and they're stacked on each other, so i need to flatten that first
[11:33] <sil2100> dbarth: ok, just give me a poke once it's ready and I'll assign a silo then :)
[11:33] <sil2100> sergiusens: thanks
[11:40] <Mirv> sergiusens: the gallery-app would need publishing as sil2100 said. balloons showed me the jenkins job(s) that can be used to build click packages, and explained lp:click-toolbelt having a tool to push those packages
[11:44] <sergiusens> Mirv, yeah, can you install click-toolbelt into a vitualenv?
[11:45] <Mirv> sergiusens: nope, since the install fails at some point to "TypeError: dist must be a Distribution instance"
[11:46] <sergiusens> Mirv, yeah, make the virtualenv python2
[11:46] <sergiusens> Mirv, we need to tell pindonga about that py3 bug
[12:21] <Mirv> sergiusens: (first time using virtualenv) even if I use virtualenv --python=python2.7 I get the same error. installing python-stevedore from archives instead of fetching it via the easy_install resolves that problem at install time, but I still get some DistributionNotFound error when trying to execute the resulting bin/click-toolbelt
[12:21] <sergiusens> hm, I don't have that error
[12:22] <Mirv> some pastebin instructions on how you install lp:click-toolbelt could be enlightening
[12:23] <sergiusens> Mirv, all I did from trusty was; virtualenv [path]; [path]/bin/activate; bzr branch lp:click-toolbelt; cd click-toolbelt; python setup.py install
[12:25] <sergiusens> Mirv, anyways, direct uploads is broken... talking to pindonga about it and he confirmed... http://paste.ubuntu.com/7156378/
[12:26] <sergiusens> manual uploads seem broken too :-/
[12:27] <Mirv> sergiusens: tried http://pastebin.ubuntu.com/7156410/
[12:27] <Mirv> sergiusens: right
[12:28] <sergiusens> Mirv, try installing oauthlib locally
[12:28] <davmor2> popey: are you getting the welcome screen locking for a while most times you wake the device?
[12:28] <popey> yes
[12:28] <popey> suspected it's the queuing issue
[12:29] <ogra_> yeah
[12:29] <ogra_> it seems to take longer the longer it was suspended
[12:29] <ogra_> which kind of points to the queue issue
[12:29] <Mirv> sergiusens: both python-oauthlib and python3-oauthlib seem already installed, or do you mean locally as in force its installation to the virtual env too? can try.
[12:29] <ogra_> takes nearly 30sec in the morning for me
[12:30] <davmor2> that's the answer I was hoping for atleast :)
[12:30] <Mirv> sergiusens: thanks for the e-mail anyway, in case I'm required to do some publishing at some point
[12:30] <ogra_> i guess there is a lot of sensor events and such that pile up
[12:31]  * davmor2 must remember to try ringing his phone after it has been off for a while, now where did I put that pad
[12:31] <ogra_> heh, did anyone try the new scopes on flo already ?
[12:32] <ogra_> the font in my Apps header is slightly moved to the center after boot
[12:32] <ogra_> only moves to the left once i switched back and forth between scopes
[12:32] <sergiusens> Mirv, sure, just copy that into~/.config/click-toolbelt/click_toolbelt.cfg
[12:34] <sergiusens> Mirv, ok, with python3 (and yes this feels broken), just do python setup.py install in a loop until it works (just tried myself)
[12:36] <Mirv> sergiusens: ...
[12:36] <Mirv> sergiusens: works :S
[12:36] <sil2100> ;)
[12:37] <sergiusens> Mirv, ugly; but the dev told me to do this; it's one of the reasons I asked for proper packaging on the list...
[12:37] <Mirv> this fits well in my (granted, very limited) experience of "easy" install, ruby gems and so on
[12:38] <Mirv> sergiusens: ok, I'm set up then, in case the uploads start working at some point and something in addition to the currently pending gallery app is needed during EU timezones
[12:39]  * davmor2 has poached popey 's excellent idea of a pad for quick notes/bugs you need to file :)
[12:40] <davmor2> unfortunately it's now filling up :)
[12:40] <ogra_> geez, just dont add stuff then !
[12:42] <sergiusens> Mirv, sil2100 so I can't upload the new gallery until the store gets fixed
[12:42] <davmor2> popey: erm what.  On the desktop pull down the system inidcator what is lock now called :)
[12:44] <sil2100> sergiusens: ok... any ETA on that?
[12:46] <seb128> davmor2, not sure what you describe, the indicator-session items didn't change
[12:47] <sergiusens> sil2100, I don't have one
[12:50] <tvoss> Mirv, I would like to the unity-scopes-api branch out of the silo
[12:50] <didrocks> sergiusens: Mirv: ok, the spreadsheet is ready… I'm going for a run now. However, we'll see depending on ping crazyness if I deploy it today or tomorrow
[12:50] <tvoss> Mirv, take it out
[12:50] <didrocks> tvoss: you can do that yourself
[12:50] <didrocks> tvoss: just reconfigure with the list of MP and remove the unity-scopes-api from it
[12:51] <didrocks> (but we need to remove the package if there is no more MP associated to it)
[12:51] <tvoss> didrocks, in the silo tab?
[12:51] <didrocks> tvoss: yeah, if unity-scopes-api has been built from a MP
[12:52] <Mirv> tvoss: if you do that ^ I can remove the package fro the PPA
[12:53] <tvoss> didrocks, Mirv when I try to alter in the silo tab, I only get a formula
[12:53]  * tvoss is scared
[12:53] <didrocks> tvoss: hum, see the "reconfigure" button?
[12:53] <davmor2> seb128: in the live session it's called start screensaver I'm assuming because there is no password for lock.  I was just double checking that it was lock on a real desktop rather than rebooting
[12:54] <seb128> davmor2, real desktop is fine
[12:55] <davmor2> seb128: okay cool
[12:58] <tvoss> didrocks, Mirv I reconfigured here: http://<IP_ADDRESS>/job/landing-014-0-reconfigure/9/
[12:58] <didrocks> great :)
[12:59] <Mirv> tvoss: looks good :) I removed the unity-scopes-api from the PPA now
[13:00] <tvoss> Mirv, thanks
[13:02] <sergiusens> sil2100, seems the bug is soon to be solved; given it's backened it might take a bit to propagate
[13:04] <sil2100> sergiusens: excellent!
[13:08] <t1mp> didrocks: hello, we are discussing adding a staging branch for the ubuntu-ui-toolkit
[13:08] <t1mp> didrocks: I have a proposal here https://docs.google.com/a/canonical.com/document/d/1rgXqqCeGg9JjHEHmDHOfhBJOGTgk7luBuBbpzNTMMLk/edit#
[13:08] <t1mp> didrocks: it would be good to get your feedback/approval on that :)
[13:09]  * sil2100 goes for a longer lunch
[13:21] <tvoss> Mirv, okay, with silo 14 reconfigured, and the rebuild packages from your ppa, things still work. Could you give it a quick spin, too?
[13:31] <Chipaca> didrocks: hello there. How can I become a lander for ubuntu-push? :)
[13:32] <Mirv> tvoss: ok I updated my phone with those two PPA:s and even removed the libprocess-cpp0, indeed I don't notice anything different
[13:33] <tvoss> Mirv, okay, that's good in this case, so I will set the silo to tested
[13:33] <tvoss> Mirv, thanks for the help :)
[13:33] <tvoss> Mirv, done
[13:34] <Chipaca> is there an easy way to point at a /usr/lib/{multiarch}/yadda/yadda from an upstart script?
[13:38] <Mirv> tvoss: ok. I'm going to run "watch only" build job now first since it seems the spreadsheet doesn't update correctly.
[13:38] <Mirv> oh, right there's an eternal build job running already
[13:39] <Mirv> so, let's see if watch only correctly notices just the process-cpp
[13:40] <Mirv> tvoss: darn, you've a small ppc64el problem that would prevent the package from migrating to release pocket since it built there before: https://launchpadlibrarian.net/170746201/buildlog_ubuntu-trusty-ppc64el.process-cpp_1.0.0%2B14.04.20140326.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[13:41] <Mirv> why that is only on ppc64el I don't know
[13:44] <Mirv> tvoss: and the build problem wasn't visible on the dashboard since there was a stalled build job running for the silo that waited eternally for unity-scopes-api
[13:44] <cjwatson> should be trivial to change anyway
[13:53] <tvoss> Mirv, cjwatson updated the symbols file
[13:53] <Mirv> sergiusens: are you able to find time to drive (test) your landings in silos 010 (phablet-tools) and 005 (usensord, platform-api) soon? just wondering since they've been built for quite some time now.
[13:53] <tvoss> still weird ...
[13:53] <Mirv> tvoss: ok! kick a rebuild then. now it shouldn't stall on unity-scopes-api anymore.
[13:54] <bfiller> sil2100: silo-13 ready to be released
[13:54] <sergiusens> Mirv, I thought usensord and platform api were unassigned already two weeks ago+
[13:55] <sergiusens> Mirv, for silo 10; I can deal with that today if doanac has a minute to spare
[13:55] <tvoss> Mirv, kicked
[13:55] <sergiusens> doanac, can you rerun a full ci with the phablet-tools from silo 10?
[13:55] <Mirv> sergiusens: ok. does that mean the usensord/platform-api silo should be cancelled?
[13:56] <Mirv> sergiusens: I think the silo was temporarily freed, but the line was not removed so it got a new silo since it still looked like it would be wanted to be landed
[13:57] <sergiusens> Mirv, needs some fixing from ricmm; I'll talk to him today
[13:59] <Mirv> sergiusens: ok, I'll let the silo then be still there but add a comment with that info
[14:09] <ogra_> davmor2, popey, hey you english speakers ... is there a bug open for all translations missing for the new scopes ? :)
[14:09] <ogra_> dpm, ^^^^do you know if anything is in the works here ?
[14:10] <dpm> ogra_, no, I don't know, I've just realized this myself
[14:10] <dpm> I think the new scopes don't support translations
[14:10] <ogra_> lol ?
[14:11] <popey> oof
[14:11] <dpm> but perhaps Saviq knows more on whether the translations for the new scopes are still provided by the shell or by the scopes themselves ^
[14:11] <Saviq> dpm, scopes
[14:12] <Saviq> dpm always backends, we in unity8 can't even dream to be able to hold all the translations for all the possible scopes etc.
[14:12] <dpm> in that case, they need to add i18n support
[14:12] <dpm> thanks Saviq
[14:12] <Saviq> yup
[14:12] <doanac> sergiusens: sure thing
[14:13] <dpm> is unity-scopes-api the best place to file the bug?
[14:14] <Saviq> dpm, basically each scope in question needs to enable i18n for its own strings, -api might facilitate a bit, but there's also smart scope server that we need to make sure gets the locale from the device and communicated to the scopes
[14:14] <Saviq> dpm, so probably a bug with real many tasks - unity-scopes-api, unity-scope-click, unity-scope-scopes, unity-scope-mediascanner2, $smart-scope-server
[14:15] <dpm> oh dear
[14:15] <ogra_> dpm, given that went completely unnoticed ansd we want to be regression free in the future, i wonder if it makes sense to have translateability as a landing criteria ... i.e. if something lands that was possible to translate before it has to fulfill that requirement too before being allowed to land
[14:16] <dpm> ogra_, that sounds sensible (and great!) to me, but I'm easy to convince when it comes to internationalization :)
[14:16] <ogra_> heh
[14:17] <ogra_> i think it isnt necessary to require translations, but at least the code need to keep the ability to be translated in a new iteration when it lands
[14:17] <dpm> +1
[14:17] <davmor2> ogra_: no idea
[14:17] <sergiusens> doanac, if that works we are going to finally be able to get some traction :-)
[14:17] <ogra_> didrocks, asac ^^^^ i wonder how to put that down as a "policy"
[14:20] <doanac> sergiusens: http://q-jenkins:8080/job/andy-smoke-daily-test/4/console
[14:22] <infinity> seb128: Why are you taking my name in vain?  I'm not the one who warned against silos and freezes. :P
[14:23] <seb128> infinity, do I get to take a penalty card? and a few more for lying? :p
[14:23] <infinity> seb128: Have a whole deck.
[14:24] <seb128> :-(
[14:24] <seb128> but yeah, checking logs, it was stgraber who said that
[14:24] <didrocks> ogra_: dpm: I have list of projects not loading translations
[14:24] <seb128> infinity, my apologies
[14:25] <ogra_> didrocks, right, i think we should make it a policy that formerly translated code still needs to be translateable, even after a major rewrite before it lands
[14:25] <didrocks> Chipaca: ask to asac, he's giving the landers card (but I think your team already have 2 ;))
[14:25] <Chipaca> didrocks: from your POV, who is my team?
[14:25] <didrocks> t1mp: well, I can give a look. Won't approve as discussed at UDS as you're shooting in your own feet IMHO
[14:26] <didrocks> t1mp: I just want that if one day there is a regression, I don't want to have to pull whole trunk to have a fix. So the more work to get the fix will be on you
[14:26] <didrocks> Chipaca: I didn't followed last tractation, but I thought you were moved to phonfundation
[14:27] <didrocks> ogra_: agreed
[14:27] <ogra_> (this is why i pinged asac too, not sure where we should put down such things )
[14:27] <Chipaca> didrocks: at that granularity, I was teamless for a while; now I'm in "dash-server"
[14:27] <t1mp> didrocks: how are we shooting in our own foot? Because we add an extra layer between the initial MP and landing in the image?
[14:28] <t1mp> didrocks: I mean, you think we can have problems there that will cost us more time to fix?
[14:28] <didrocks> t1mp: yeah, and no focus on getting things fixed, no automated feedback on the AP tests and so on
[14:28] <didrocks> t1mp: and yeah, on the cost to fix
[14:28] <t1mp> didrocks: what do you mean with automated feedback on AP tests? is that something we have now?
[14:29] <didrocks> t1mp: you have in your trunk, with manual testing
[14:29] <t1mp> didrocks: the standards still stay high.  You mean that we do less testing on each MP before it is approved to be merged in staging?
[14:30] <didrocks> Chipaca: I'm fine with it, however, you would need some pre-training, do you think ralsina or anyone you feel close to being a lander can help there?
[14:30] <ralsina> didrocks, Chipaca: haappy to help, I did a bunch of landings before
[14:30] <didrocks> t1mp: right, I don't think you will be able to run manually all AP tests on all your rdependencies on every single MP + the test suite of manual tests
[14:30] <ralsina> some of them even succesful! ;-)
[14:30] <didrocks> ralsina: heh :)
[14:31] <t1mp> didrocks: that is exactly what we are doing now for each MP
[14:31] <didrocks> t1mp: you run like dialer-app AP tests for each MP?
[14:31] <didrocks> t1mp: and all click apps?
[14:31] <t1mp> didrocks: yes
[14:31] <Chipaca> ralsina: you're a lander?
[14:31] <t1mp> didrocks: we discussed that as a requirement in the SDK team, but it does not seem feasible now that's why we are discussing an alternative
[14:31] <ralsina> Chipaca: I think I still am, yes
[14:31] <Chipaca> :)
[14:32] <didrocks> t1mp: on the device? waow, I'm unsure why we got this complain when you needed to do that at each landing then
[14:32] <t1mp> didrocks: yes we do it on the device
[14:32] <didrocks> t1mp: great then, I have no objection, you just do manually what the airline will do automatically
[14:32] <t1mp> didrocks: maybe we are putting the standards for the MPs too high?
[14:33] <t1mp> didrocks: it sounds great, but it is a big burden, especially since we decided not to top-approve an MP if not all tests pass
[14:33] <didrocks> t1mp: I guess it's costly, but I prefer that the contrary :)
[14:33] <t1mp> didrocks: and some times tests/apps are broken, so we are slowed down a lot in top-approving MPs
[14:33] <dpm> Saviq, ogra_ bug 1297889 (I still need to find out the project for the remote scopes, though)
[14:33] <ogra_> ++
[14:34] <asac> ogra_: hmm. not sure if and how we should really try gating translatability. we might want to include it in the upstream checklists so the reviewers know about this.
[14:34] <t1mp> didrocks: so the problem is, like this we get a backlog of MPs
[14:34] <didrocks> Chipaca: gave you the rights. Please check with ralsina on the process and test plan requirements :)
[14:34] <t1mp> didrocks: the idea is to relax the requirements a bit for MPs to merge into staging, so we proceed with staging, and then before landing it in image and the trunk we keep the same requirements of 100% passrate
[14:34]  * Chipaca sets everything on fire
[14:34] <didrocks> t1mp: what is preventing you to land all the approve one?
[14:34] <Saviq> dpm, thanks
[14:34] <ogra_> asac, i think its a regression if formerly translated apps come without i18n support after an update
[14:35] <ogra_> asac,  so code that had it before needs to also have it after upgrade ...
[14:35] <t1mp> didrocks: nothing, but because we require 100% OK before approving, we don't have approved ones now
[14:35] <t1mp> didrocks: just a lot of MPs that are basically approved, but need to pass all the tests before top-approving
[14:35] <didrocks> t1mp: so you lower your standards to be faster?
[14:36] <ogra_> (doesnt mean there need to be translations immediately, but the gettext support, the .pot file etc should be there)
[14:36] <t1mp> didrocks: for staging, we will no longer require 100% OK for all app tests if we don't have an image at that moment for which we know that all tests are OK
[14:36] <t1mp> didrocks: and then when we get 100% OK for all apps in staging, we do a landing
[14:37] <didrocks> t1mp: how will we not come back in a situation where you don't land anything for 2 months and half?
[14:37] <t1mp> bzoltan / zsombi / kalikiana ^ please correct me if I am saying something that you don't agree with
[14:37] <didrocks> which happened in the past
[14:37] <t1mp> didrocks: we kind of are in that situation now, and we are thinking of ways to avoid that,
[14:38] <t1mp> didrocks: so if there is no image that we can use for testing, we can still decide to approve MPs to go to staging
[14:38] <didrocks> t1mp: seems you need to find a way to think why you can't land your MPs now
[14:38] <didrocks> as you don't have any lock
[14:38] <didrocks> or pend on us
[14:38] <t1mp> didrocks: perhaps now with image 262 it will work,
[14:39] <t1mp> didrocks: but the past week there was no image with which I could get 100% OK from all the tests
[14:39] <didrocks> t1mp: well, as told you the other day, compare with just latest proposed image dashboard
[14:39] <didrocks> t1mp: and see if you reproduce the same issues or not
[14:39] <t1mp> didrocks: I was told we should use the proposed image, but there can always be some tests of which we are not sure they will pass without even having changes in UITK that we want to test
[14:39] <didrocks> t1mp: you don't need to be 100%, you need to not regress the dashboard
[14:39] <didrocks> meaning, each failure to be analyzed
[14:39] <t1mp> didrocks: that would be relaxing our current standards of 100%.
[14:39] <didrocks> if already in the proposed image -> ignore
[14:40] <didrocks> t1mp: yeah, nothing into that involve using another branch though
[14:40] <t1mp> didrocks: we have a lot of MPs, and we would have to analyze it for each MP? in the staging proposal, we would have to do that for each landing, not for each of the MPs that are part of the landing
[14:40] <didrocks> t1mp: no, get one landing with a bunch of MP
[14:40] <didrocks> test that
[14:41] <didrocks> and reiterate
[14:41] <Saviq> didrocks, can I have silo for row 49?
[14:42] <Saviq> didrocks, in lieu of thostr I took over click scope landings
[14:42] <didrocks> Saviq: sure, looking
[14:42] <didrocks> Saviq: btw, any progress on the crashers?
[14:43] <Saviq> didrocks, yours is still not reproducible
[14:43] <Saviq> didrocks, davmor2
[14:43] <t1mp> didrocks: ok, so we drop the high standards for the MPs and move those to the landing only
[14:43] <didrocks> Saviq: theone in the dashboard?
[14:43] <Saviq> didrocks, does not retrace
[14:43] <Saviq> didrocks, /me needs to up kill timeout again...
[14:43] <didrocks> Saviq: can you add a longer timeout?
[14:43] <didrocks> yeah
[14:43] <Saviq> didrocks, but!
[14:43] <sergiusens> Mirv -> http://paste.ubuntu.com/7157039/ <- popey can you test
[14:43] <didrocks> Saviq: as we have it at every image test run, it's quite high
[14:43] <Saviq> didrocks, since that doesn't affect tests, I say that's an exit crash
[14:44] <didrocks> sil2100: any news from bfiller on the telephony-service crash?
[14:44] <didrocks> Saviq: we have one test which failed
[14:44] <Saviq> in which case it'd be bug #1256360
[14:44] <Saviq> didrocks, yeah, not a crash but a flakyness that we thought was fixed
[14:44] <didrocks> Saviq: see 2 images ago
[14:44] <didrocks> Saviq: argh
[14:44] <didrocks> ok
[14:44] <davmor2> Saviq, didrocks: I've not been able to reproduce it
[14:46] <didrocks> Saviq: let's keep it on the radar, shall we? We'll downgrade it if we don't see more issues tomorrow, ok?
[14:46] <didrocks> Saviq: still, bump the timeout
[14:46] <slangasek> seb128: if it was in the trusty unapproved queue, it should still be there, shouldn't it?  A silo clean shouldn't have rights to remove packages from the unapproved queue
[14:46] <didrocks> Saviq: assigned btw
[14:46] <Saviq> didrocks, thanks
[14:46] <Saviq> didrocks, yeah, would be nice if we had a "kill timeout none"
[14:46] <slangasek> seb128: (which packages, and did this already get sorted while I was sleeping? :)
[14:46] <didrocks> Saviq: +1
[14:46] <Saviq> didrocks, I can't find the failed test in smoke?
[14:47] <seb128> slangasek, that got sorted out thanks
[14:47] <didrocks> Saviq: didn't you say you already analyzed it?
[14:47] <Saviq> didrocks, yeah, but wanted to give it to Albert
[14:47] <didrocks> Saviq: argh, it's been rerun, maybe vila would have the link
[14:47] <seb128> slangasek, well, a silo clean does clean the ppa, or pocket copies are not actual copies for librarian pointers, so the target is cleaning and the queue item becomes buggy
[14:48] <seb128> slangasek, though wgrant said it takes a week before the librarian data actually get cleared
[14:48] <seb128> slangasek, so it's still ok if things are reviewed on a timelined fashion
[14:48] <wgrant> Right, you have at least a week.
[14:48] <didrocks> otherwise, I'll have to reuse the same tricks than for SRU
[14:48] <didrocks> meaning, copying to another ppa
[14:48] <slangasek> seb128: oh, right.  stupid unauditable pocket copies. :P
[14:48] <didrocks> and requesting the sync from that
[14:49] <didrocks> (this is the SRU mode of cu2d)
[14:49] <seb128> yeah, that's what Laney suggested earlier
[14:49] <didrocks> well, the code is already there just in case
[14:49] <seb128> seems like the release team would like that
[14:49] <didrocks> involves more complexities I guess if we kick something from unapproved and want to reland the same day
[14:50] <vila> didrocks, Saviq : context ?
[14:50] <didrocks> vila: the unity8 AP test failing, you mentionned you rerun it IIRC?
[14:50] <didrocks> vila: do you have a link to it in any case?
[14:51] <vila> on q-jenkins probably, on ci.u.c harder, let me check
[14:52] <vila> didrocks, Saviq : https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/185/testReport/junit/unity8.shell.tests.test_emulators/DashAppsEmulatorTestCase/test_open_preview_Native_Device_/
[14:52] <Saviq> vila, thanks
[14:52] <didrocks> thanks vila ;)
[14:53] <bfiller> didrocks: boiko looking at crashes, one due to qtubuntu/mir crash. he's trying to fix the indicator related crash - looks valid
[14:53] <vila> . o O (I wish I understand how my memory kept track of 185...)
[14:57] <Laney> didrocks: I'd hope the >7 day case is rare enough that we can reupload if that happens
[14:57] <Laney> should be able to fish the code out of the tag in bzr anyways
[15:00] <didrocks> bfiller: thanks! (what's the one due to qtubuntu/mir crash?)
[15:00] <didrocks> Laney: yep
[15:01] <bfiller> didrocks: don't know exactly, boiko can give the details
[15:01] <didrocks> boiko: ? ;)
[15:01] <didrocks> vila: human mystery…
[15:01] <bfiller> didrocks: I believe he said dialer-app is crashing becuase mir crashes
[15:01] <boiko> didrocks: let me paste the backtrace
[15:01] <didrocks> oh, the dialer-app crash we have for so long?
[15:02] <boiko> didrocks: not sure, might be a different one: http://paste.ubuntu.com/7157131/
[15:02] <boiko> didrocks: but I would bet the root cause is the same: starting the application from command line instead of using upstart
[15:03] <didrocks> boiko: interesting… I thought AP was using upstart though
[15:03] <boiko> didrocks: nope, at least not for the telephony-apps
[15:03] <didrocks> boiko: on silo 013, I never remember if address-book-app is click
[15:03] <didrocks> boiko: ah, would make sense
[15:04] <bfiller> didrocks: not yet, still a deb
[15:04] <didrocks> thanks bfiller, boiko, publishing it
[15:04] <boiko> didrocks: yesterday cwayne was showing me an MR to change the addressbook to be launched using upstart
[15:04] <boiko> didrocks: thanks
[15:04] <bfiller> boiko: I will file a bug for this MIR issue, looks to be a legimate bug
[15:04] <didrocks> yw
[15:04] <didrocks> (migrating now)
[15:05] <boiko> bfiller: I think I will give it a try on making autopilot use upstart to launch the app
[15:06] <bfiller> boiko: wouldn't that be an infrastructure change needed across all of the tests for all apps?
[15:06] <didrocks> yeah, seems weird to be it needs to be defined on each app
[15:06] <didrocks> the default should be to use upstart
[15:06] <didrocks> with a possible override for very special cases
[15:06] <boiko> bfiller: if the changes cwayne did for his address-book-app are correct, that's not really a big change
[15:08] <bfiller> boiko: that stack trace you pasted was from the dialer-app.crash file?
[15:11] <bfiller> didrocks, boiko, kgunn : here is a bug for the qtubuntu crash causing the dialer to crash: https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1297900
[15:12] <bfiller> note, this seems to be a different issue than the previous mir related crashes that were causing dialer to crash
[15:12] <didrocks> bfiller: ah, interesting, so do you think it should be in a high priority list?
[15:12] <didrocks> or do we put that as the other dialer-app crash "don't impact user experience, so no mention"
[15:13] <bfiller> didrocks: well, I think it's high priority in that it possible would affect all apps during launching
[15:13] <didrocks> ok, noting it down then
[15:13] <bfiller> didrocks: not specific to dialer, but a platform bug that should be addressed I think
[15:14] <didrocks> bfiller: yeah, understood
[15:14] <davmor2> didrocks, Saviq: jfunk has agreed that the header issue shouldn't be a blocker as long as the bug remains tracked and isn't an issue in the new header code, so treat it as a bug against the new header.
[15:14] <bfiller> didrocks: the good news is that on the device itself apps are launched via upstart-app-launch and won't go through this code path I believe
[15:14] <didrocks> bfiller: yeah, so just high priority, not blocker
[15:14] <bfiller> didrocks: yup
[15:14] <didrocks> davmor2: so, he's going to track it?
[15:15] <davmor2> didrocks: well I'll possibly need to track it and test it on the new header but yes it will be monitored
[15:15] <didrocks> ok
[15:19] <sil2100> dbarth: just one merge in the landing :o ?
[15:20] <doanac> sergiusens: looking good for the first autopilot test: http://q-jenkins:8080/job/andy-smoke-daily-test/ws/clientlogs/friends_app/test_results.xml/*view*/
[15:21] <doanac> based on my simple computer science experience if it works for x=1, it should work for x=infinity :)
[15:21] <doanac> i'll let you know when its done though
[15:23] <sergiusens> doanac, the concerning ones are music, calendar and gallery iirc; good to know it didn't break
[15:24] <sergiusens> doanac, not sure if after this runs you want to do some subunit things
[15:24] <doanac> sergiusens: yep. i'll start working on using subunit in our daily image testing after we get this landed
[15:24] <tvoss> Mirv, the build succeeded \o/
[15:27] <didrocks> ogra_: if you continue to troll on the ML, I'm about the send the "let's do a pool" argument!
[15:27] <ogra_> haha
[15:29] <dbarth> sil2100: ok, good now
[15:29] <dbarth> sil2100: yes, just 1
[15:29] <sil2100> dbarth: let me see if we can assign
[15:30] <sil2100> tvoss: publishing then ;)
[15:31] <sil2100> dbarth: in the meantime, please include some test plans for the landing :)
[15:39] <sergiusens> popey, hey, sorry for reping, but did you see my message about a new gallery in the store?
[15:39] <popey> sergiusens: i did not
[15:39] <popey> so thank you
[15:40] <dbarth> sil2100: yeah, the test plan must be huge, but i will put something together
[15:40] <tvoss> sil2100, thx
[15:41] <sil2100> dbarth: ok ;) If anything, a silo is assigned
[15:41] <sergiusens> popey, then Mirv might have not see it either :-)
[15:42] <dbarth> sil2100: saw that; thanks a lot
[15:42] <didrocks> bfiller: I didn't get an update on bug #1297395 btw
[15:43] <didrocks> bfiller: do you think it's the same qtubuntu one?
[15:47] <sergiusens> robru, double question; can you review the MR in line 50 and also provide a silo?
[15:47] <davmor2> am I the only one that is now tired of not being able to hear calls cause the volume was turned down for the Music app.  Please can we have different volumes for all the sections pretty please :D
[15:48] <sil2100> sergiusens: it's a new package, yes?
[15:49] <sergiusens> sil2100, yes
[15:51] <sil2100> sergiusens: not sure if robru is around yet - in the meantime I'll take a look at the packaging as well
[15:52] <bfiller> didrocks: haven't looked at this yet
[15:52] <didrocks> bfiller: ok, keeping on the list, feel free to answer on it
[15:53] <bfiller> didrocks: will look into it today
[15:53] <didrocks> sure, thanks!
[15:58] <sil2100> sergiusens: commented on two issues that I noticed on first glance - thanks!
[15:58] <sergiusens> thanks, will look
[16:01] <sergiusens> sil2100, how do I demangle symbols?
[16:01] <sergiusens> c++filt I know
[16:01] <sergiusens> but in one shot
[16:02] <sil2100> sergiusens: I have a nice line prepared for that, one moment
[16:03] <didrocks> and it's in the wiki!
[16:03] <sil2100> sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' symbols | c++filt >new_symbols (I use this)
[16:03] <sergiusens> didrocks, yeah, I give that reply and it never works ;-)
[16:03] <sergiusens> :-P
[16:04] <sil2100> sergiusens: I also commented on the branch with a proposition more to the upstream about restricting which symbols they export ;p
[16:04] <sil2100> sergiusens: since I see the symbols files are huge, not sure if we need all of those visible to the whole world!
[16:04] <davmor2> sil2100: man that sed has such glinty eyes
[16:04] <sil2100> It also makes managing symbols files much easier
[16:05] <sergiusens> sil2100, that's jhodapp's problem I asked him about that and he said it should be abi stable
[16:08] <sil2100> sergiusens: yeah, indeed that's why I mentioned it's more of a proposition for upstream, but still
[16:09] <sergiusens> sil2100, yeah, I understand, it's going to be his problem and he will likely fix it if it comes to it
[16:13] <sergiusens> sil2100, ok, I've pushed, thanks; let's wait for the bot to say I didn't screw up those symbols
[16:14] <sil2100> sergiusens: ok, thanks for the fixes! I'll double check again, but I guess otherwise the packaging looks ok
[16:15] <popey> sergiusens: approved gallery
[16:20] <sil2100> tvoss: hi! So, regarding that process-cpp landing - there was no ABI break, right?
[16:20] <sil2100> tvoss: just the soname got bumped?
[16:21] <tvoss> sil2100, there was an ABI break, but no one used that API thus far
[16:21] <tvoss> sil2100, that's why I bumped the so name
[16:21] <sil2100> tvoss: since sadly, I discussed it with Mirv right now on what tests he did, and I think sadly we'll have to add to the silo some no-change rebuilds of all the rdeps for this package
[16:22] <tvoss> sil2100, I discussed that with cjwatson, too
[16:23] <tvoss> sil2100, why would we have to trigger the rebuilds if things still work? we tested it from Mirv's ppa
[16:23] <sil2100> tvoss: what was his opinion on this? He also thinks it's needed? Since from my understanding, if I'm thinking correctly, this might lead to a situation where all the rdeps will be uninstallable
[16:24] <sil2100> tvoss: since basically libprocess-cpp0 stops existing in the archive, and now dbus-cpp and the others are still depending on that package, can't find it and cannot be installed
[16:24] <sil2100> tvoss: Mirv said he used his PPA with no-change rebuilds of all rdeps
[16:24] <tvoss> sil2100, okay, I asked for that and people told me that there is no need for the rebuilds
[16:24] <sil2100> So basically his PPA had the thing that we would need to have in the archive, I guess
[16:25] <sil2100> hmm... I might misunderstand something, but I think this is how it would logically work
[16:25] <tvoss> sil2100, okay, so we need empty mp's for all rdeps?
[16:25] <sil2100> didrocks: ^ can you help me and tell me if I understand correctly? ;p
[16:26] <sil2100> tvoss: probably, but let's wait for a packaging-master to comment, since Mirv also agreed on my concerns but we're both a bit weary
[16:32] <didrocks> sil2100: I'm in a meeting
[16:32] <didrocks> so just do what you think is the best
[16:33] <sil2100> ACK ;)
[16:42] <boiko> bfiller: sorry, I went for lunch, yes, it is from the dialer-app crash file
[16:43] <sil2100> sergiusens: well, it seems that the package doesn't want to build on my system when using bzr bd - symbols file problem
[16:56] <davmor2> popey: install an app and see if it is still listed in the Available section
[16:59] <didrocks> sil2100: will stay in meeting, please lead that one
[17:00] <sil2100> didrocks: ok
[17:02] <sergiusens> sil2100, yeah, demangling broke
[17:02] <sergiusens> sil2100, same can be seen on ci
[17:06] <sergiusens> sil2100, can I just revert the demangling?
[17:10] <sergiusens> didrocks, ^^
[17:10]  * sergiusens doesn't like this part
[17:16] <sil2100> C++ symbols are really a PITA to tell the truth, I think non-demangled symbols would result in a NACK from core devs though
[17:16] <sil2100> sergiusens: who's upstream for this?
[17:16] <sergiusens> jhodapp
[17:17] <sergiusens> sil2100, the qt landings have non demangled symbols though
[17:17] <cjwatson> The more I read the C++ FQA (sic) the more I think providing C++ interfaces at all is a mistake :-)
[17:17] <cjwatson> (Not that I expect people to agree)
[17:18] <robru> sil2100, didrocks: I have to step out, will be back in ~30 minutes. feel free to email me with anything you want me to take care of
[17:18] <sil2100> sergiusens: you would have to ask some core dev if it's ok to provide mangled names in symbols files, but I would certainly not want something like that - I would opt for poking upstream, getting a nice symbols map and exporting only needed demangled symbols
[17:18] <sil2100> robru: ok
[17:18] <sergiusens> heh; while c++ is nice to write, it's really hard infra wise
[17:19] <sergiusens> sil2100, well rsalveti gave me a review and said it was ok; he's a core dev
[17:19] <sil2100> cjwatson, sergiusens: I noticed that once you restrict what you export in C++ then the symbols can be a bit less painfull ;)
[17:20] <cjwatson> Absolutely
[17:20] <sil2100> Ok then, I guess we can proceed with reverting the demangling
[17:20] <cjwatson> Good idea in any library of course, it's just more obvious in C++
[17:20] <sergiusens> sil2100, can you guide jim into doing that?
[17:20] <sil2100> sergiusens: sure, let me send him an e-mail
[17:21] <sil2100> We can take care of that in a separate landing then, I won't argue with a decision of a core-dev ;)
[17:23] <sil2100> didrocks: so, from our meeting - a bug worth mentioning in our landing e-mail: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1297965
[17:23] <sil2100> didrocks: Alan found another one that might be related: #1297436
[17:23] <didrocks> ok
[17:23] <sil2100> oh, ubot5 didn't react
[17:23] <sil2100> LP: #1297436
[17:23] <didrocks> sil2100: who is working on it?
[17:24] <sil2100> didrocks: no one yet, proceeding to ping someone, it was filled in during the meeting
[17:24] <didrocks> ok
[17:24] <didrocks> sil2100: last upload did that?
[17:25] <sil2100> didrocks: we're suspecting it has something to do with the scopes transition
[17:25] <sil2100> davmor2: did you try bisecting when it appeared?
[17:25] <didrocks> sil2100: ping pawel
[17:35] <sil2100> didrocks: ok, it seems a fix for that bug is in the works, dobey knows about it and alecu has a branch fixing that in-progress
[17:35] <boiko> didrocks: hey, so on silo landing-013 I have this message that account-plugins is in the UNAPPROVED queue, do I have to take any action on that?
[17:35] <dobey> huh?
[17:36] <sil2100> boiko: no, sadly, it's because of the beta freeze
[17:36] <sil2100> boiko: we have to wait - we can force a release of the silo if needed, but we're only doing that when there is some high-priority needs
[17:37] <sil2100> boiko: let me check the landing in mention
[17:37] <boiko> sil2100: I just wanted to merge the changes on address-book-app and address-book-service to their respective trunks
[17:37] <didrocks> boiko: or you can bribe the release team
[17:38] <boiko> didrocks: that depends on how desperate renato is to get his stuff landed :)
[17:38] <sil2100> ;)
[17:38] <didrocks> heh
[17:38] <didrocks> boiko: #ubuntu-release for such requests
[17:39] <boiko> didrocks: ok, I will join there and ask
[17:39] <boiko> thanks
[17:40] <didrocks> yw
[17:41] <didrocks> boiko: if you commit to really look at it, you can m&c with "ignore package in dest"
[17:41] <didrocks> boiko: but please, look if it's getting block anywhere for no reason
[17:41] <boiko> didrocks: sil2100: so, just to make sure, the address-book-{app,service} upload was ok, right? it is only the account-plugins that is unapproved
[17:41] <sil2100> boiko: yes, everything else landed in the archive
[17:41] <didrocks> boiko: right!, those should have go to the destination if it doesn't say anything about it
[17:41] <didrocks> boiko: they are fine without account-plugins btw?
[17:42] <sil2100> boiko: just this one is in the unapproved queue
[17:42] <boiko> didrocks: yes, they are
[17:42] <boiko> didrocks: the account-plugins change is going to be needed later when we merge contact syncing support
[17:42] <didrocks> ok, feel free to run "m&c with "ignore package in dest"
[17:43] <boiko> didrocks: yep, will do
[17:43] <boiko> didrocks: sil2100: thanks
[17:43] <sil2100> boiko: just be sure to look at if it gets blocked somewhere or not later :)
[17:43] <didrocks> boiko: don't overuse that option please :p
[17:43] <sil2100> After the freeze
[17:43] <boiko> didrocks: up to now I didn't even knew it was possible, and sure I don't plan to overuse that :)
[17:45] <boiko> until when the freeze is going to be in effect?
[17:47] <didrocks> boiko: if you have stuff blocked in UNAPPROVE and you know that the rest which transition is fine
[18:07] <sergiusens> sil2100, can we get a testing landing silo for jhodapp even if the MRs aren't final?
[18:25] <rsalveti> sergiusens: guess we can get a silo with the mrs we currently have
[18:25] <rsalveti> and keep iterating that once we get the other ones
[18:25] <rsalveti> they will be around later today afaik anyway
[18:25] <rsalveti> reconfigure && build for every additional mr we get
[18:26] <sergiusens> rsalveti, yeah, I can't reconfigure when new projects (trunk/source packages) show up; but that's the gist of it
[18:26] <robru> hooray!
[18:26] <rsalveti> sergiusens: I can, just ping me
[18:27] <rsalveti> at least I could last time I tried
[18:27] <rsalveti> but we have robru :-)
[18:27] <rsalveti> he's like a landing machine
[18:27] <robru> rsalveti: sure am! what needs doing?
[18:27] <rsalveti> robru: nothing now, but might need help reconfiguring a silo later today
[18:28] <sergiusens> rsalveti, robru well we can get one assigned for starters :-)
[18:28] <robru> rsalveti: sure just ping me. I'll try to be responsive (I'm currently on a network that is blocking IRC, so I'm using the web client, so I may not see pings as promptly as I normally do)
[18:31] <rsalveti> sergiusens: at https://code.launchpad.net/~sergiusens/media-hub/packaging/+merge/209926, don't we need to change the changelog version entry to be compatible with CI as well?
[18:31] <t1mp> plars: I see the --no-provision landed :)
[18:31] <rsalveti> like we had for ofono
[18:32] <plars> t1mp: yep
[18:33] <sergiusens> rsalveti, it already is; ci train adds the +$(date) by itself
[18:33] <rsalveti> sergiusens: got it, great then
[18:33] <t1mp> plars: ok, I'll try it now.
[18:34] <t1mp> plars: provisioning now. When its done, I install the debs from the MR, and then I try run-smoke. Still have to see which parameters to use
[18:35] <t1mp> kalikiana: ^
[18:37] <didrocks> robru: btw, in case sil2100 didn't mention it…
[18:37] <didrocks> robru: the bug in CI Train was covered by test
[18:37] <robru> yes?
[18:37] <t1mp> plars: ImportError: No module named yaml
[18:37] <didrocks> but dch changed between precise and trusty
[18:37] <t1mp> plars: do I need python-yaml or python3-yaml?
[18:37] <didrocks> and of course, I run the tests on my machine :p
[18:37] <robru> didrocks: ahhhhhh
[18:38] <didrocks> so the fix is in, not deployed (as trunk contains the requestid change)
[18:38] <didrocks> which is all ready
[18:38] <didrocks> spreadsheet-side as well
[18:38] <didrocks> just not enabled
[18:38] <didrocks> and I won't do that and bye bye :)
[18:38] <didrocks> so my tomorrow morning :)
[18:38] <robru> didrocks: good call
[18:38] <plars> t1mp: python-yaml, but I think you might also need utah-client
[18:38] <didrocks> robru: supposively, the change will result in:
[18:38] <didrocks> - display an ID
[18:38] <didrocks> - you copy and paste that ID
[18:39] <sergiusens> didrocks, you need to start using golang :-)
[18:39] <sergiusens> lol
[18:39] <didrocks> if you reconfigure a silo:
[18:39] <didrocks> - just click on the build
[18:39] <plars> t1mp: I don't recall for sure, I know you need utah though
[18:39] <didrocks> nothing else needed :p
[18:39] <didrocks> sergiusens: yeah, I'll do that for the bot :)
[18:39] <robru> didrocks: humm, still copy&paste? well as long as the ID is displayed without quotes the copy&paste will be easier ;-)
[18:39] <plars> t1mp: you can try just python-yaml first if you like
[18:39] <sergiusens> no abi breakage, symbol exposure issue or where did I build and run issue
[18:39] <sergiusens> so much easier to back port a package
[18:39] <didrocks> robru: yeah, unfortunately, still no plugin to "inject" that
[18:40] <plars> t1mp: I know at one time utah-client was needed for the utah (non-autopilot) tests though
[18:40] <t1mp> plars: what is the difference between run-smoke and run-autopilot-tests?
[18:41] <plars> t1mp: run-smoke handles the whole process, run-autopilot-tests does... just the individual autopilot tests
[18:41] <t1mp> plars: ./run-smoke --help at least doesn't say it needs yaml
[18:41] <plars> t1mp: it imports it
[18:42] <t1mp> plars: how/where do I get utah? I don't see a package in the archive
[18:43] <plars> t1mp: ppa:utah/daily
[18:43] <plars> t1mp: sorry, I mean ppa:utah/stable
[18:43] <plars> t1mp: I doubt there would be much difference, but you just need the stable one
[18:44] <t1mp> kalikiana: ^fyi, the provision.sh script is downloading the autopilot tests from lp for me :)
[18:44] <sergiusens> robru, rsalveti ok, can we get a silo setup for line 50 then?
[18:45] <robru> sergiusens: sure
[18:46] <t1mp> kalikiana: I started with this ./provision.sh -n ~/network-manager-conf -w
[18:48] <jhodapp> thanks robru
[18:48] <robru> sergiusens: ok, got you silo 6. for future reference, please space-separate the list of packages (just like the MP list, it needs to be copy&pasted into a jenkins form that parses based on spaces)
[18:48] <robru> jhodapp: you're welcome
[18:51] <t1mp> plars: ./run-smoke adds the --no-provision option, but in ./run-smoke --help that option is not listed
[18:51] <t1mp> plars: is that intentional?
[18:52] <jhodapp> sergiusens, you might want to add a comment that says to land libhybris and gst-plugins-bad first
[18:53] <doanac> sergiusens: the silo test completed for phablet-tools: http://q-jenkins:8080/job/andy-smoke-daily-test/4/
[18:53] <doanac> seems pretty good
[18:53] <rsalveti> jhodapp: why first, will it fail if not there?
[18:53] <jhodapp> rsalveti, yes
[18:53] <rsalveti> if so, then we need to bump the build-dep version requirement for them
[18:54] <rsalveti> in a way that they will not be built because the latest libhybris and gst packages are not there yet
[18:54] <jhodapp> rsalveti, makes sense
[18:54] <plars> t1mp: it should be there, are you sure your bzr tree is up to date?
[18:55] <plars> t1mp: I see it in --help with mine
[18:55] <jhodapp> rsalveti, there's a tool to bump that right, I forget what it's called
[18:55] <sergiusens> jhodapp, I'm actually in charge of that and have your list
[18:55] <jhodapp> sergiusens, ok cool
[18:55] <jhodapp> thanks
[18:55] <rsalveti> jhodapp: you need to change debian/control and add that build version requirement in there
[18:55] <rsalveti> for whatever packages that are depending on libhybris and gst-bad
[18:56] <t1mp> plars: you are right, I am blind
[18:56] <sergiusens> doanac, are those two failures just random ones?
[18:56] <t1mp> it is there
[18:56] <kgunn> robru: hey...after some discussion, i'm giving up line 40 (which is using silo16)....we decided to do it later with some other mp's post beta
[18:56] <kgunn> not sure what the protocol is there....
[18:56] <sergiusens> doanac, seems so to me
[18:56] <jhodapp> sergiusens, need me to do that?
[18:57] <t1mp> plars: I installed utah-client, but I still get a failure: http://pastebin.ubuntu.com/7158414/
[18:57] <robru> kgunn: ahh, thank you
[18:57] <sergiusens> jhodapp, do what? sorry, context switching is broken for me :-)
[18:57] <jhodapp> sergiusens, from what rsalveti said: "if so, then we need to bump the build-dep version requirement for them
[18:57] <jhodapp>  in a way that they will not be built because the latest libhybris and gst packages are not there yet"
[18:57] <sergiusens> robru, you'll be happy to hear we are close to landing silo 10
[18:58] <robru> sergiusens: always happy to hear from you!
[18:58] <rsalveti> sergiusens: build version requirements for whatever packages that are depending on a newer hybris/gst
[18:58] <rsalveti> in debian/control
[18:58] <plars> t1mp: looks like you installed utah-client, but not utah
[18:59] <sergiusens> jhodapp, yeah, that's not in the branch I have control over (media-hub) but the other ones
[18:59] <t1mp> plars: I'll install utah-all then
[18:59] <jhodapp> sergiusens, ok
[18:59] <sergiusens> rsalveti, yeah, media-hub doesn't depend on hybris
[18:59] <jhodapp> sergiusens, actually it does
[19:01] <robru> sergiusens: just a heads up: you might run into a snag with silo 6 because you're attempting to rename the source package. in the past I've seen citrain not deal well with that. give it a shot for now, but you might end up having to push the source package rename directly to trunk first, then rebuild in the silo
[19:02] <sergiusens> robru, if it comes to it, I'll wipe the changelog completely; music-hub never landed in archives
[19:02] <sergiusens> robru, oh, I see what you mean
[19:03] <sergiusens> robru, I'll manually merge it and use the second MR proposed
[19:03] <sergiusens> jhodapp, I don't see any hybris packages in build-depends for media-hub
[19:03] <robru> sergiusens: yeah, you might have to.
[19:03] <t1mp> plars: it is still failing IOError: [Errno 2] No such file or directory: '/home/tim/dev/ubuntu-test-cases/touch/scripts/clientlogs/all/utah.yaml'
[19:03] <jhodapp> sergiusens, yeah it needs to be added, libhybris-dev
[19:03] <t1mp> plars: after I installed utah-all
[19:04] <sergiusens> jhodapp, I'll wait for rsalveti's version of choice then
[19:04] <t1mp> plars: is something missing? http://pastebin.ubuntu.com/7158446/
[19:05] <jhodapp> sergiusens, you could just say the version > what is currently built for trusty
[19:07] <plars> t1mp: 'ALL' is case sensitive i think
[19:08] <t1mp> plars: I think I'm calling it wrong tim@ideapad:~/dev/ubuntu-test-cases/touch/scripts$ TESTS=all APPS=all ./run-smoke --no-provision
[19:08] <t1mp> plars: so TESTS=ALL APPS=ALL ./run-smoke ?
[19:08] <rsalveti> sergiusens: just put current+1
[19:08] <rsalveti> ubuntuX where x = previous + 1
[19:08] <plars> t1mp: -n
[19:08] <plars> :)
[19:08] <sergiusens> rsalveti, ack; there's no hurry anyways; it needs to build in the silo as well
[19:08] <rsalveti> true
[19:08] <t1mp> plars: ok, let's try that :)
[19:09] <plars> t1mp: doesn't apply to you in this situation obviously, but if you do ever want to run without -n and have it provision for you, make sure that you have ubuntu-device-flash installed. It uses that instead of phablet-flash now
[19:11] <t1mp> plars: cool.
[19:11] <sergiusens> robru, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=28
[19:11] <t1mp> plars: I've been using ubuntu-device-flash for a while already :)
[19:11] <sergiusens> robru, please take a look at the link tests as well
[19:11] <sergiusens> robru, but there is no better test than a full ci run
[19:11] <sergiusens> :-)
[19:11] <robru> sergiusens: oh I agree! ;-)
[19:12] <sergiusens> takes like 6 hours though :-P
[19:12] <jhodapp> sergiusens, you can use this for media-hub, I just tested it: libhybris-dev (>= 0.1.0+git20131207+e452e83-0ubuntu13)
[19:13] <jhodapp> sergiusens, I'll let you make that change to your branch, and I'll make the proper changes in the other branches
[19:14] <sergiusens> jhodapp, yeah, just wait for it; I need to manually merge mine anyways
[19:14] <jhodapp> sergiusens, that cool, we can change media-hub when you're ready then
[19:14] <jhodapp> sergiusens, the other ones are almost updated
[19:15] <robru> sergiusens: published
[19:15] <t1mp> plars: there still seems to be a problem with utah :s http://pastebin.ubuntu.com/7158497/
[19:16] <jhodapp> rsalveti, so the correct version of gst-plugins-bad will need to be seeded, there's no build-dep version to check for for that
[19:17] <rsalveti> jhodapp: it's already seeded, so no worries, if not needed for build-time, then we're good
[19:17] <jhodapp> rsalveti, right, ok
[19:18] <sergiusens> robru, thanks
[19:18] <jhodapp> rsalveti, how about gst-plugins-bad having the right libhyris-dev?
[19:18] <sergiusens> robru, now I'm not holding the oldest silo anymore :-)
[19:18] <rsalveti> jhodapp: that I'll change when uploading both to the silo ppa
[19:18] <jhodapp> rsalveti, ok excellent, thanks
[19:19] <t1mp> plars: shouldn't the script create the the utah.yaml file?
[19:20] <robru> sergiusens: ;-)
[19:21] <plars> t1mp: yeah, but utah is crashing for some reason before it gets there: OSError: [Errno 2] No such file or directory: '/var/cache/utah/autorun/inprogress'
[19:21] <plars> t1mp: "it works on my machine" :)
[19:23] <plars> t1mp: my best guess is there's some sort of utah setup step you're missing, doanac any ideas? http://pastebin.ubuntu.com/7158497/ is what he's seeing
[19:23] <jhodapp> sergiusens, ok, other than the media-hub libhyris build-dep update and the one rsalveti will do for gst-plugins-bad depending on libhyris-dev, the other packages should be ready
[19:23] <plars> oh
[19:24] <rsalveti> alright
[19:24] <doanac> t1mp, plars: is utah installed on this system?
[19:24] <t1mp> plars, doanac I'm running the script without root priviliges
[19:25] <doanac> if TESTS=ALL you'll need utah.
[19:25] <t1mp> doanac: yes utah: Installed: 0.15+20140305~ubuntu14.04.1
[19:25] <plars> doanac: I believe he's installed both utah and utah-client
[19:25] <plars> t1mp: so am I
[19:25] <doanac> t1mp: I think utah might need to be run as root
[19:25] <plars> doanac: I think that's why it prompts him for sudo though
[19:25] <t1mp> doanac: http://pastebin.ubuntu.com/7158497/ line 41
[19:26] <t1mp> will it ask the password more ofteh?
[19:26] <t1mp> *ofthen
[19:26] <t1mp> *often
[19:26] <t1mp> :s
[19:26] <t1mp> :)
[19:26] <t1mp> I'll try  sudo TESTS=ALL APPS=ALL ./run-smoke --no-provision
[19:27] <doanac> i bet that doesn't fix it
[19:27] <doanac> i'm thinking you are missing a utah package
[19:27] <t1mp> I installed utah-all
[19:27] <doanac> or you need to create this directory by hand: /var/cache/utah/autorun/inprogress
[19:28] <t1mp> same error with sudo
[19:28] <plars> doanac: I don't have that dir either, but it doesn't complain about it with me
[19:28] <plars> so I'm not sure why it's looking for it
[19:29] <t1mp> plars: did you try with TESTS=ALL APPS=AL and -n ?
[19:29] <plars> t1mp: yep
[19:29] <plars> oh, hang on
[19:29] <t1mp> *APPS=ALL
[19:29] <plars> t1mp: did you provision your device with provision.sh before making the modifications?
[19:30] <t1mp> plars: yes, first I ran provision.sh, and then I installed some deb files
[19:30] <t1mp> mkdir -p  /var/cache/utah/autorun/inprogress seems to help
[19:31] <t1mp> something is running now
[19:31] <boiko> robru: hey, is it known that sometimes the MRs are not marked as merged after clicking merge and clean?
[19:32] <doanac> plars: nuclearbob recently made some client changes to utah near that area. I wonder if it now requires that directory and you and I are just on an older utah
[19:32] <plars> oh
[19:32] <plars> yeah t1mp you are on a much newer utah than me - I guess you got the daily after all?
[19:32] <robru> boiko: no? it doesn't happen immediately...
[19:33] <boiko> robru: it landed two hours ago
[19:33] <t1mp> plars: sudo apt-add-repository  ppa:utah/stable && sudo apt-get install utah-all
[19:33] <boiko> robru: only one of the MRs didn't get marked as merged, the other ones are OK
[19:33] <boiko> robru: the code got merged though
[19:34] <t1mp> I'll need to tweak the script probably for our use case. I don't need to run the idle tests that are running now
[19:34] <t1mp> but first lets see if everything works without additional parameters/changes :)
[19:35] <boiko> robru: no big deal, just checking if you want to debug something before I manually mark it as merged
[19:36] <plars> I think maybe I'm just on the one I had before upgrading to trusty on this box
[19:36] <boiko> robru: it is the https://code.launchpad.net/~renatofilho/address-book-app/optimize-app/+merge/210199 MR from row 17
[19:37] <robru> boiko: did anything unusual happen, like was there a reconfig that dropped that MR? one MR merged into another MR or something?
[19:37] <boiko> robru: nope, not that I know of, just regular MR dependency
[19:37] <plars> t1mp: did you try just creating the directory?
[19:38] <boiko> robru: if that's of no use for debugging, I can just mark it as merged manually
[19:40] <t1mp> plars: yes I created the directory, and now the tests are working
[19:40] <t1mp> plars: 20:30:50 < t1mp> mkdir -p  /var/cache/utah/autorun/inprogress seems to help
[19:40] <plars> t1mp: ok, sounds like a bug in recent utah versions then
[19:40] <plars> t1mp: let me know if you run into any more issues
[19:41] <t1mp> plars: shall I report the bug or will you?
[19:41] <plars> t1mp: if you could file one, that would be great
[19:42] <robru> boiko: yeah just mark it merged for now. how often does it happen? just the once?
[19:42] <boiko> robru: first time this happened since I started landing stuff using the CI train
[19:42] <t1mp> ~/dev/ubuntu-test-cases/touch/scripts/clientlogs/ is filling up.. next challenge is how to parse all the log files to see what passed/failed
[19:43] <robru> boiko: first guess would be that it's more a bug in launchpad. i don't think citrain has any code for explicitely marking branches as merged. my understanding is that citrain just merges the branches and then launchpad is the one that notices the merge commit and marks the MP merged.
[19:43] <robru> boiko: or at least, the few odd times I've done manual merges, lp automatically mared the MPs for me after I pushed the merge commit, so I assume the same applies to jenkins/citrain
[19:44] <boiko> robru: ah ok, got it, yeah, now that you mentioned, I remember having MRs marked as merged automatically in launchpad
[19:47] <t1mp> plars: https://bugs.launchpad.net/utah/+bug/1298026
[19:47] <boiko> robru: btw, I have just added line 52 to the spreadsheet, whenever you get a free silo, would you mind assigning it?
[19:47] <robru> boiko: sure thing!
[19:49] <robru> boiko: ok you got silo 12
[19:50] <t1mp> plars: is my pipeline correct? if I use provision.sh and then install UITK deb files, and then run-smoke, will all the AP tests be ran against the UITK version that I installed? Or will something be overwritten?
[19:50] <boiko> robru: thanks!
[19:50] <robru> boiko: you're welcome!
[19:50] <t1mp> plars: and the UITK AP tests come from the ubuntu-ui-toolkit-autopilot package that is installed on the system right? Or from lp or a click package?
[19:52] <plars> t1mp: hmm, well the toolkit tests do try to install (and thus remove) the autopilot tests for u1tk - ubuntu-ui-toolkit-autopilot
[19:53] <plars> t1mp: hopefully that won't affect you?
[19:53] <t1mp> plars: I installed ubuntu-ui-toolkit-autopilot myself, so I like to use that version
[19:54] <plars> t1mp: will the version in the archive supersede it? or does yours have a higher version number
[19:55] <t1mp> plars: I installed ubuntu-ui-toolkit-autopilot_0.1.46+14.04.20140321.1bzr948pkg0trusty892-0ubuntu1_all.deb
[19:56] <plars> t1mp: as long as yours has a higher version number, then I would think that apt-get install ubuntu-ui-toolkit-autopilot would just do nothing
[19:56] <plars> t1mp: otherwise, you'll get "upgraded"
[19:56] <t1mp> plars: currently I have this on the device http://pastebin.ubuntu.com/7158704/
[19:57] <t1mp> it looks like I still have the versions matching the .debs that I downloaded
[19:58] <t1mp> so if 20140321.1bzr938... > 20140321.1-ubuntu1 I think I'm safe
[19:59] <t1mp> IF that is the case. Seems logical but I'm not sure if b > -
[20:23] <t1mp> plars: do you know how long a full test run like this will take?
[20:24] <plars> t1mp: ~3 hours
[20:24] <plars> t1mp: one thing to be aware of, even if your package doesn't get upgraded, it will get uninstalled after the toolkit tests run
[20:24] <sergiusens> robru, hey, upon reconfiguring I now get this http://<IP_ADDRESS>/job/landing-006-0-reconfigure/18/console
[20:25] <plars> t1mp: you may want to run *just* those tests after reinstalling and watch it very carefully
[20:26] <sergiusens> robru, ah it seems it was never configured (from the prior build logs)
[20:26] <t1mp> plars: oh, ok
[20:26] <t1mp> plars: after the toolkit tests finished I don't need them anymore... but
[20:26] <t1mp> plars: the other tests use the uitk-autopilot emulators. Are those part of the uitk-autopilot package?
[20:29] <robru> sergiusens: yeah, that looks like what I mean about the source package rename not working. did you merge the MP manually yet?
[20:32] <plars> t1mp: no idea
[20:32] <robru> sergiusens: ok, looks good after a reconfigure. please build
[20:35] <sergiusens> robru, yup, that's what I did, reason I wanted to reconfig :-)
[20:40] <sergiusens> robru, just did m&c on silo 10
[20:41] <robru> sergiusens: sweeeeeet, thanks
[21:06] <boiko> robru: landing-012 tested
[21:07] <robru> boiko: thanks!
[21:08] <robru> boiko: published!
[21:09] <boiko> robru: thanks!
[21:09] <robru> boiko: you're welcome ;-)
[21:37] <robru> boiko: please merge & clean silo 12 ;-)
[21:37] <boiko> robru: yep, I was just waiting for rmadison to show the right version on trusty
[21:38] <boiko> (not sure it is really necessary to wait for that, but in any case)
[21:39] <robru> boiko: nope, citrain goes by what launchpad says, it's only necessary to wait for rmadison if you are intending to kick an image build shortly after and you want the new image to include your recently published silo. as I learned the hard way with image #257 ;-)
[21:39] <boiko> robru: ah ok, got it, thanks :D
[21:39] <robru> boiko: you're welcome!
[21:40] <boiko> robru: well, I will keep on watching rmadison anyways, as I want to rebuild some messaging-app jenkins jobs using this version of history-service
[21:40] <robru> boiko: ah, no worries
[21:40] <robru> boiko: we're not crunched on silos like i was afraid we'd be
[21:41] <boiko> robru: I guess people are rebasing/retesting stuff before submitting
[21:41] <boiko> (at least that's what is happening in the apps team)
[21:41] <boiko> robru: silo being cleaned already
[21:41] <sergiusens> robru, I have a fast track landing; is there a bullet train :-P
[21:42] <sergiusens> robru, kidding, but would be good to get phablet-tools/line 53 a silo
[21:42] <robru> sergiusens: you better believe it! (well, aside from the beta freeze that's outside my control)
[21:43] <robru> sergiusens: ok, you got silo 10
[21:43] <robru> boiko: thanks
[21:43] <boiko> robru: you're welcome!
[21:55] <sergiusens> robru, heh, phablet-tools is trending on silo 10
[21:55] <robru> sergiusens: it's a happy place.
[23:23] <robru> alright everybody, I'm off for dinner, should be back in 3-4 hours, if anybody needs anything just shoot me an email and I'll get back to it later tonight.


[17:41] <michael_e_brown> 7.10 question: we need to have firstboot come up in Chinese for when we ship to a certain, nondisclosed, geographical area. Setting /etc/environment and /etc/defaults/locale seems to have no effect. Editing /etc/init.d/oem-config to source /etc/environment (to set LANG) seems to have no effect.
[18:10] <BagOfMostlyWater> michael: i don't have experience w/this, but i'm willing to try. how are you doing the installations? are you using a custom cd? network install?
[18:12] <evand> michael_e_brown: you may want to email Colin directly on this.  My guess would be that it will involve seeding languagechooser/language-name or debian-installer/locale, but having not written the OEM code, I'm not sure what the full proper solution is here.
[19:17] <michael_e_brown> evand, thanks. We tried setting debian-installer/locale, but that completely breaks our install
[19:31] <twb> michael_e_brown: how so?
[19:34] <michael_e_brown> twb, fails partitioning
[19:34] <twb> Are you seeding the partitioning steps at all?
[19:34] <michael_e_brown> twb, I saw a note somewhere that the preseed text must match exactly the GUI text
[19:34] <michael_e_brown> twb, sort of... just a sec.
[19:35] <michael_e_brown> d-i partman-auto/init_automatically_partition \
[19:35] <michael_e_brown>       select Guided - use the largest continuous free space
[19:35] <michael_e_brown> d-i partman-auto/choose_recipe \
[19:35] <michael_e_brown>        select All files in one partition (recommended for new users)
[19:35] <twb> Please use a pastebin
[19:35] <michael_e_brown> right. sorry. (thought 4 lines wouldnt be too objectionable...)
[19:35] <twb> Have you tried seeding just the locale, and not any of the partitioning stuff?
[19:35] <michael_e_brown> twb, didnt work last time I tried.
[19:35] <twb> OK.
[19:35] <michael_e_brown> brought up the part screen.
[19:35] <twb> re paste, np. I see 4 lines and aren't sure if that's all, or if there are another 98 coming
[19:37] <michael_e_brown> http://pastebin.com/m758c0d2e
[19:37] <michael_e_brown> ^--- the whole preseed file.
[19:37] <michael_e_brown> Requirement: we need firstboot to come up with chinese selected by default (and in chinese)
[19:37] <twb> You're seeding it to en_US there
[19:38] <michael_e_brown> If I change debian-installer/locale, the whole install breaks
[19:38] <twb> You change it to zh_CN?
[19:38] <michael_e_brown> if I change it to zh_CN, it breaks at partitioning.
[19:38] <twb> Oh yes, of course
[19:38] <twb> partition messages are localized
[19:38] <michael_e_brown> So, my idea was to just do install in english
[19:38] <twb> So if you change the default locale, you need to change those strings to chinese
[19:38] <michael_e_brown> (as that happens in our factory, that is ok)
[19:39] <michael_e_brown> and then just change system language in a post-install script
[19:39] <twb> Well, you could do that instead.
[19:39] <michael_e_brown> but that dont work, either.
[19:39] <michael_e_brown> firstboot comes up in english
[19:39] <michael_e_brown> I changed /etc/environment and /etc/defaults/locale to zh_CN and still comes up in english
[19:39] <twb> See this string: "Guided - use the largest continuous free space"
[19:40] <twb> You need to change that to whatever the zh_CN locale uses
[19:40] <twb> Similarly for "All files in one partition (recommended for new users)"
[19:40] <twb> Or try just commenting them out
[19:40] <michael_e_brown> problem being that there are 4 different strings like that...
[19:41] <twb> So change them all
[19:41] <michael_e_brown> twb, problem is that I dont know that would even fix firstboot
[19:41] <twb> For your second idea, to change the locale in the late command, you seem to have forgotten to install the zh locale package
[19:41] <twb> michael_e_brown: so TEST IT
[19:41] <michael_e_brown> d-i pkgsel/language-packs string en es fr de pt zh
[19:41] <twb> Oh sorry
[19:42] <twb> I've never seen that seed before
[19:42] <michael_e_brown> twb, I've been sitting here all day testing it...
[19:42] <michael_e_brown> and now I'm asking for some more help
[19:42] <twb> You said 06:41 <michael_e_brown> twb, problem is that I dont know that would even fix firstboot
[19:42] <twb> So my suggestion is to find out
[19:43] <michael_e_brown> so: from what I can tell, changing the language only changes /etc/environment and /etc/defaults/locale
[19:53] <BagOfMostlyWater> michael: have you tried configuring your locale entirely using debconf after an install, verifying that it works, and then dumping via debconf-get-selections to see what is required for preseeding?
[19:53] <twb> BagOfMostlyWater: that would discard the d-i seeds, wouldn't it?
[19:54] <twb> IIRC there's some other magic command for those
[19:55] <michael_e_brown> BagOfMostlyWater, that is a useful suggestion.
[19:55] <michael_e_brown> BagOfMostlyWater, I'm trying to reinstall now using spanish ( since I can at least speak that )
[19:56] <michael_e_brown> I want to see if doing the install in spanish will cause firstboot to come up in spanish
[19:56] <BagOfMostlyWater> thats beyond me i'm afraid. i wonder where debconf-get-selections and debconf-get-selections --installer overlap.
[19:56] <BagOfMostlyWater> by 'discard the d-i seeds' do you mean the preseeds wouldn't be owned by d-i?
[19:56] <michael_e_brown> the main problem so far is that firstboot doesnt appear to honor the "normal" language selection in /etc
[20:01] <twb> michael_e_brown: ah, I just assumed you spoke zh.
[20:01] <michael_e_brown> twb, no, I dont.
[20:01] <michael_e_brown> twb, which makes it exceedingly difficult to test
[20:01] <twb> That makes sense now
[21:31] <michael_e_brown> so...
[21:32] <michael_e_brown> doing an install completely in spanish does not cause firstboot to come up in spanish
[21:32] <michael_e_brown> doh.
[21:32] <michael_e_brown> cjwatson_, ping
[21:33] <michael_e_brown> did an install in spanish and firstboot still comes up in english
[21:34] <michael_e_brown> funny:
[21:34] <michael_e_brown> did an install in spanish with spanish keyboard setting
[21:34] <michael_e_brown> and firstboot *does* keep that.
[21:46] <michael_e_brown> twb, doesnt look like your suggestion panned out. So, I am back to square one.
[21:58] <evand> michael_e_brown: he's on vacation until Tuesday I think, thus my email suggestion.  If this is pressing I can try to figure out a solution over the weekend for you.
[21:59] <michael_e_brown> evand, it is not an emergency, but Tuesday is a ways off...
[21:59] <michael_e_brown> evand, looks to me like the code doesnt ever initialize the language setting until you click a language
[21:59] <michael_e_brown> evand, *just* finished a re-install so I can look at the firstboot code fresh
[22:00] <michael_e_brown> I'll send an email. I dont need you to work on the weekend on this.
[22:01] <evand> michael_e_brown: ok, an email would be much appreciated, and I'll give it a shot on Monday then.  Enjoy your weekend.
[22:01] <michael_e_brown> composing now... thx
[22:38] <michael_e_brown> evand, did you get my email? It bounced from cjwatson_'s address...
[22:57] <evand> michael_e_brown: yes, I did and odd.  Perhaps trying cjwatson at ubuntu.com and colin.watson at canonical.com might get it through.
[22:58] <evand> my understanding is that the nicknames carry over both domains, though, so I'm not sure why the address you used wouldn't work.
[23:29] <michael_e_brown> evand: http://paste.ubuntu-nl.org/50780/
[23:29] <michael_e_brown> evand, email to colin still not working --^
[23:29] <michael_e_brown> could you kindly forward?
[23:30] <michael_e_brown> leaving in a couple mins. have a good weekend.
[23:37] <michael_e_brown> evand, I also just got word that this is a bit more urgent, as we were supposed to exit devel today, but that is more my bad than your problem because I somehow missed the dates. :(
[23:37]  * michael_e_brown isnt going home as soon as he thought...


[08:50] <Fudge> is at-spi-atk actually a package or is it part of atk1
[08:57] <Fudge> Oh I found it


[23:44] <tanepiper> hi, can someone help me with this: https://gist.github.com/2d1703cede3597abd595
[23:44] <tanepiper> if i try start on startup, i get an error that /var isn't mounted
[23:45] <tanepiper> however if I manually call start quartermaster, the app starts fine
[23:51] <tanepiper> oh looks like i solved it :)  start on mounted; env MOUNTPOINT=/var
[23:52] <ion> Ubuntu? ‘start on filesystem’
[23:52] <ion> Such an ‘env’ stanza doesn’t really do anything except set the value of MOUNTPOINT for your scripts.
[23:53] <ion> HOME is something you could use env for.
[23:53] <tanepiper> well that's working as well, thanks :)
[23:54] <ion> ‘start on mounted’ probably never really worked. If it happened to get started at the right time based on it, you were just lucky. :-)
[23:54] <ion> Also, 2>&1 before 1>… makes stderr go to stdout and stdout go to the logfile. You probably want to make 2 a copy of 1 after 1 has been redirected to a file.
[23:56] <tanepiper> yea, i started with a copy & paste job for running nodejs but that just wasn't working.  I'll definetly read up more on the upstart blog
[23:58] <tanepiper> so 1> /var/log/foo > &2  ?
[23:58] <ion> >>/var/log/foo 2>&1
[23:59] <tanepiper> gotch


[19:26] <jeremydei> does anyone know how many days behind the main archive, the canonical ec2 mirrors are?
[19:27] <elmo> they shouldn't be more than hours behind
[19:28] <jeremydei> hours? wow!
[19:29] <elmo> they sync every 4-6 hours, I forget which
[19:30] <jeremydei> elmo, do you know where I can find a list of the mirrors' dns? (assuming there's one in each zone..)
[19:32] <elmo> jeremydei: eu.ec2.archive.ubuntu.com  and us.ec2.archive.ubuntu.com
[19:35] <jeremydei> elmo, yep I see this for the lookup us.ec2.archive.ubuntu.com. 600	IN	CNAME	ec2-174-129-225-54.compute-1.amazonaws.com
[19:35] <jeremydei> does that mean there's only 1 in the US region?
[19:35] <elmo> jeremydei: at the moment yes
[19:36] <elmo> jeremydei: we're looking at expanding that, but the cost of traffic between regions is pretty minimal
[19:36] <elmo> between regions in the same availability zone, I mean
[19:37] <jeremydei> cool, thanks for the info! (esp the hours behind).  I'm looking at using this mirror as a primary upstream for the RightScale mirrors
[20:07] <smoser> the ec2 mirrors are lightning fast too
[20:08] <smoser> at least they have been, till everyone finds out about them :)