[03:06] <alexcabrera> flaccid: Sorry, I got booted before when you were responding to my question. By "reject" I mean that when trying to access my site over HTTP I immediately get a cannot connect error. Nothing in my nginx or apache logs, it's kind of the same thing as when you try to ssh into your instance without having added your WAN IP to your instance's security group
[03:14] <flaccid> alexcabrera: show me what happens when you telnet the port from remote
[03:15] <alexcabrera> flaccid: http://pastebin.org/463651
[03:16] <alexcabrera> shouldn't it echo something back?
[03:24] <flaccid> alexcabrera: not without sending a header
[03:24] <flaccid> that url works fine for me
[03:25] <alexcabrera> flaccid: wtf, really?
[03:25] <alexcabrera> what do you seE?
[03:25] <alexcabrera> err see
[03:25] <flaccid> its a 404, server sig is Apache/2.2.14 (Ubuntu) Server at twinpinesmall.policus.com Port 80
[03:27] <alexcabrera> hm....
[03:27] <alexcabrera> thanks, that helps tracks things down
[03:33] <flaccid> np


[16:31] <nilg> I suspect there's a bug in ubuntustudio-controls or in my system, I have a `/proc/asound/card1` folder without an `id` subfolder and this crashes ubuntustudio-controls.
[16:33] <nilg> Even if it is a bug in my system, I suspect ubuntustudio-controls can be made more robust, however before I start hacking it I'd like to have the latest version. Is 1.7.1 the latest version?
[16:47] <Eickmeyer[m]> !ubuntustudio-backports | nilg: backports has version 1.10
[16:49] <OvenWerks> nilg: what does the trace back look like?
[16:50] <OvenWerks> (run ubuntustudio-controls from terminal)
[16:52] <Eickmeyer[m]> nilg: this is not the support channel.
[16:52] <Eickmeyer[m]> !support
[16:54] <nilg> OvenWerks: I've created the following issue https://bugs.launchpad.net/ubuntustudio-controls/+bug/1841451
[16:56] <OvenWerks> nilg: could you in a terminal type: ls -l /proc/asound |pastebinit
[16:56] <OvenWerks> and put the url here?
[16:59] <nilg> OvenWerks: https://paste.ubuntu.com/p/9rtpwJqjMb/
[17:00] <OvenWerks> nilg: I think that is not too hard to fix. Yes I would say if there is no id file the driver or device is not right.
[17:00] <Eickmeyer> nilg: OvenWerks: Take this to #ubuntustudio. This is not a development discussion. This is a support discussion.
[17:00] <OvenWerks> Eickmeyer: this is dev
[17:00] <OvenWerks> nilg: is this usb or internal
[17:00] <Eickmeyer> How so?
[17:01] <OvenWerks> gathering info to fix a bug
[17:01] <nilg> OvenWerks: I have 3 audio devices (enabled at different moments)
[17:01] <nilg> 1. Internal
[17:01] <nilg> 2. USB
[17:01] <nilg> 3. Bluetooth
[17:02] <nilg> Of course I'm never using or expecting to use the bluetooth device with jack
[17:02] <OvenWerks> It may be that the USB device chip set does not have a "name" entered
[17:03] <Eickmeyer> Gathering info to fix a bug is support. Develpment is collaboration to fix the bug. There's a difference, but what do I know. I'm just trying to keep the IRC council happy.
[17:04] <nilg> I don't mind moving to #ubuntustudio, though to blurry the line further, I don't mind hacking/fixing the bug as well :-)
[17:04] <OvenWerks> anyway, I think I have enough info to fix it.
[17:04] <nilg> I suppose a simple try/catch to skip cards without id would do the trick...
[17:05] <nilg> Awesome!
[17:05] <OvenWerks> simpler I hope
[17:05] <Eickmeyer> !bug | nilg: In the future, for a more complete bug report, use this method
[17:05] <Eickmeyer> So, you would've filed that using ubuntu-bug ubuntustudio-controls
[17:06] <nilg> Oh, thanks.
[17:06] <Eickmeyer> Either way, I triaged the bug and moved it to the proper place, but I fear it'll get marked as incomplete since it wasn't filed correctly.
[17:06] <Eickmeyer> That or invalid.
[17:08] <Eickmeyer> nilg: Also, people in ubuntustudio-devel hang out in #ubuntustudio, so please don't post support questions in here.
[17:08] <nilg> Got it
[17:08] <Eickmeyer> Otherwise, why would we have the two channels?
[17:09]  * Eickmeyer ends rant
[17:09] <OvenWerks> lint --pedantic  ;)
[17:10] <Eickmeyer> OvenWerks: We have to follow IRC guidelines. That's part of it.
[17:27] <teward> *salts Eickmeyer* Python is annoying ain't it
 *salts teward for reasons*
[17:35] <teward> I*drags @tsi
[17:35] <teward> bleh damn phone
[17:35] <teward> *drags @tsimonq2 out back and buries him*
[18:26] <OvenWerks> Eickmeyer: got the other two cheap (under $1) audio devices today... they also have both 44k1 and 48k. I shall have to try running my master at 96k or something.


[00:02] <ToyKeeper> robru: Confirmed, simply rebooting didn't help, but silo 15 fixed the thumbnail issue.  (libthumbnailer0_1.0+14.04.20140319-0ubuntu1_armhf.deb)
[00:02] <robru> ToyKeeper, oh excellent
[00:02] <robru> ToyKeeper, can you dogfood a little bit more with silo 15 to make sure it doesn't break anything?
[00:02] <robru> i'm testing a different silo right now
[00:02] <ToyKeeper> Yes, but it probably won't be until a bit later.
[00:02] <robru> oh ok
[00:14] <ToyKeeper> Hmm, my time zone bug seems to be back.
[00:16] <ToyKeeper> (basically, Denver is not UTC+1: http://toykeeper.net/tmp/phablet-tz-denver-wrong.png )
[00:16] <ToyKeeper> ... will continue when I get back later, though.
[00:41] <robru> alright, I'm heading out for dinner, will check in after a few hours
[03:04] <imgbot> [04:14] <imgbot> [04:14] <imgbot> [04:38] <Mirv> Laney: thank you for publishing qtbase, you were the lander after all. I have a note of proposing that to upstream.
[04:38] <Mirv> I mean, Debian
[06:44] <didrocks> Mirv: hey! are you looking at the calendar-app thread on the phone ML? Seems as it's Qt related, you would be the best to understand it
[06:48] <Mirv> didrocks: yes I've been looking. maybe sdk team can also help.
[06:49] <didrocks> Mirv: that would be sweet!
[07:52] <thostr_> can I get a silo for line 64
[07:56] <Mirv> thostr_: sure, just a minute
[07:56] <Mirv> thostr_: actually not, it's already on line 15
[07:57] <Mirv> the question is whether to release it since it claims to be tested, or how risky it is now that we're almost having a promoted image
[07:58] <sil2100> Indeed
[07:58] <Mirv> and did the build actually include the exif branch, hmm
[07:59] <Mirv> yes, yes it did
[07:59] <thostr_> so, what about then adding the fix to line 15
[07:59] <thostr_> and rebuilding it
[07:59] <thostr_> then we can still decided whether to land or not
[07:59] <Mirv> thostr_: it is already there, I just checked  that it was included during the build: http://<IP_ADDRESS>/job/landing-015-1-build/20/consoleFull
[07:59] <Mirv> the same branch
[08:00] <thostr_> Mirv: ah, ok. then we're good for now
[08:01] <Mirv> sil2100: would you have time to double test gallery-app? I'm trying to debug the calendar app problems at the moment on my device.
[08:01] <sil2100> thostr_, Mirv: the changes look pretty safe, but I would only land it if someone from our team could double-test it
[08:01] <sil2100> Mirv: sure
[08:01] <sil2100> Mirv: you're reading my mind!
[08:02] <Mirv> thanks :)
[08:02] <sil2100> Let me just re-flash
[08:02] <Mirv> a crasher fix is a crasher fix after all (thumbnailer)
[08:09] <didrocks> thostr_: can you cleanup the req you have from line 6 to line 10? seems some can be removed
[08:10] <sil2100> thostr_: hmmm, regarding landing 10...
[08:10] <thostr_> didrocks: still applicable... some where blocked or waiting on other fixes
[08:10] <sil2100> thostr_: landing line 10 I mean
[08:11] <thostr_> didrocks: i have been the bottle neck as well...
[08:11] <didrocks> thostr_: most of them are ready: no though?
[08:11] <didrocks> thostr_: see the comment on line 9 as well
[08:11] <didrocks> it's already merged?
[08:11] <sil2100> thostr_: the FFe bug you mentioned is not the curent one - that one is from 13.10
[08:12] <sil2100> thostr_: url-dispatcher is not in the FFe list from https://bugs.launchpad.net/ubuntu/+bug/1282590
[08:12] <sil2100> didrocks: ^ is the old FFe still valid? The one from last cycle that Steve filled in?
[08:12] <sil2100> didrocks: or should we only look at the trusty one now?
[08:14] <thostr_> didrocks: sil2100: I'll recheck all my landing requests today... need to wait for some for ted/charles though
[08:15] <didrocks> thostr_: ok, please do :)
[08:15] <didrocks> sil2100: no, its not
[08:15] <didrocks> sil2100: so yeah, we need a new one for trusty
[08:20] <sil2100> thostr_: ok :)
[08:23] <Mirv> the calendar-app issue looks complex. I can confirm reverting the last commit fixes the crasher on x86, which was mentioned to be blocking a fix for the autopilot test. I pinged tsd_geos so that he could look at my local backtrace bug #1294995
[08:23] <Mirv> then regarding the flaky test, it hasn't flaked during the last five images at all it seems
[08:24] <Mirv> and I remember I didn't get the failure on my tests either
[08:34] <didrocks> Mirv: I think we may want to follow reverting both?
[08:35] <sil2100> Mirv: regarding that landing 15 - I'm starting to test it right now, but I see some of the MRs there are not approved or reviewed even
[08:35] <sil2100> I would say we wait for Bill to appear with landing this one
[08:35] <Mirv> didrocks: which both? so https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/revert-212/+merge/211813 seems to fix the x86 crasher balloons mentions to be a blocker for landing fixes for the AP problems in bug #1293489
[08:36] <sil2100> I'm not confident in releasing something from merges that don't have a visible review on them, it's state is a bit 'unknown' right now
[08:37] <Mirv> sil2100: yeah, even though it's mentioned to be tested the branches should be top-approved
[08:38] <didrocks> Mirv: there is as well that one: https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/standalone-ap-for-1293489/+merge/211854
[08:38] <didrocks> to fix the real AP test issue
[08:39] <Mirv> didrocks: oh, ok, you just said "reverting both" but that other one is refactoring
[08:40] <Mirv> but yes, approving both of them. I should test the autopilot on desktop more with/without branches.
[08:40] <didrocks> Mirv: ah sorry, yeah, needing both branches :)
[08:59] <sil2100> didrocks: so, the flaky messaging-app test fix that boiko did - there is a landing for that but I cannot assign a silo for it as messaging-app is already part of landing-009, which is 'Testing pass' but seems a little bit risky for me
[08:59] <didrocks> sil2100: please override, add a commit to the other one with the rationale and set testing to no
[08:59] <sil2100> didrocks: ACK
[09:05] <seb128> sil2100, http://irclogs.ubuntu.com/2014/03/19/%23ubuntu-release.html#t20:41
[09:06] <seb128> sil2100, that's where the url-dispatcher ffe got discussed (you are being overzealous on that one it seems ;-)
[09:07]  * didrocks prefers overzealous than having something to be reproached for :)
[09:07] <seb128> I can see that
[09:07] <sil2100> seb128: well, I just checked the FFe bug back then and didn't see it ;) Just doing my duties!
[09:08] <seb128> sil2100, I had the link to the bug in the comment, it just happens that they are 2 bugs for touch ffe now?
[09:08] <seb128> if that one is invalid/from last cycle we should maybe fix released it?
[09:08] <sil2100> seb128: yes, one is for last cycle, one is for this cycle
[09:08] <seb128> we should close the old one then
[09:08] <sil2100> seb128: probably, I already once made the mistake on looking at the wrong one...
[09:08] <seb128> to avoid those confusions
[09:09] <didrocks> seb128: I'm unsure from the discussion it came to a resolution though
[09:09] <didrocks> (seeing your IRC link)
[09:09] <didrocks> and yeah, they are not leftover, they were in last cycle one because those weren't in the desktop seed, and they are now
[09:10] <seb128> didrocks, I'm based on "slangasek	so if we're sure that lib isn't used except on touch, then yeah, that all sounds reasonable"
[09:10] <seb128> we don't use url-dispatcher in the indicator to run stuff on desktop
[09:10] <seb128> so I think virtually that's not being used
[09:10] <didrocks> seb128: I'm just looking at what's pulling it in, one sec
[09:11] <seb128> but if you guys want a formal confirmation we need to go back to slangasek
[09:11] <didrocks> so, the indicators
[09:11] <seb128> didrocks, indicators to call settings mostly I think
[09:11] <didrocks> pulling liburl-dispatcher1
[09:11] <didrocks> ok
[09:11] <seb128> right
[09:11] <didrocks> I think if there is no ABI breakage and based to yesterday discussion, that we can +1
[09:11] <didrocks> sil2100: wdyt?
[09:11] <Mirv> didrocks: correction. the revert-212 branch includes the other branch, the other branch alone just isn't enough
[09:11] <didrocks> on*
[09:12] <didrocks> Mirv: ok, it's a prereq?
[09:12] <sil2100> didrocks: sounds good to me I guess
[09:15] <Mirv> didrocks: no, it's included, the other one is just the "other fixes" but not the revert which is needed to fix the crash
[09:15] <Mirv> then, to fix the actual AP bug two more branches from bug #1293489 are needed
[09:15] <seb128> didrocks,  do you have a "<n> free silo" counter somewhere? looks like it would be useful ;-)
[09:16] <didrocks> seb128: for people with the right commit access level, it's possible, but yeah, can do that
[09:17] <didrocks> seb128: I'm working on making reconfigure/assignement easier first
[09:17] <didrocks> Mirv: ok, seems we need to test this whole bundle
[09:18] <seb128> didrocks, ok, that would be nice (I keep wondering if stuff are waiting because there are no silo left :p)
[09:19] <sil2100> seb128: I'll be assigning silos in a moment ;)
[09:19] <sil2100> Was busy testing
[09:19] <seb128> sil2100, no hurry, it's just that the topic came back a few days this week
[09:20] <sil2100> seb128: well, in overall we're a bit 'stuffed' with things which we either don't want to land before promoting an image or need to test manually and/or need comment from the authors
[09:21] <sil2100> So things tend to stretch a bit longer, I hope we'll get a promotable image soon...
[09:21] <seb128> sil2100, well, Mirv assigned me silos for my desktop specific entries so I'm happy enough
[09:21] <seb128> it feels like l32&33 should be fine as well
[09:21] <seb128> one touch the wizard in settings, which is not used
[09:21] <seb128> the other one is in a test tool
[09:22] <sil2100> All seem safe
[09:22] <didrocks> seb128: G1
[09:23] <seb128> didrocks, thanks!
[09:23] <didrocks> yw :)
[09:23] <seb128> so we are on top of the normal assignment atm
[09:24] <sil2100> seb128: ok, one more silo assigned - but the rest needs to stay free for emergency needs ;)
[09:24] <didrocks> yep
[09:24] <seb128> sil2100, right, thanks
[09:24] <sil2100> I'll test some ready safe-landings in the meantime
[09:24] <sil2100> yw
[09:28] <mhr3> sil2100, publish 28 pls?
[09:30] <sil2100> mhr3: one moment, resolving that one, some doubts
[09:30] <sil2100> (and meeting)
[09:31] <didrocks> Mirv: coming?
[09:34] <Mirv> I needed to juggle between laptops a bit
[09:43] <ogra_> psivaa, doanac seems to only have the phonesim install/remove code to the dialer-app test, but not to the messaging-app one, could we get it there too ? (messaging-app fails with "no phonesim found" on both tablets ... it works on N4 because there is a physical SIM apparently)
[09:43] <ogra_> *have added
[09:44] <ogra_> (that will get us 16 failures less per tablet :) )
[09:47] <psivaa> ogra_: 'messaging-app-autopilot' does not look to have it as a dep.. but i'll take a look at this deeper. thanks for looking at it
[09:47] <ogra_> psivaa, no, thanks to you :)
[09:49] <sil2100> mhr3: testing the landing and publishing - just tell me sincerely: how 'risky' you thing those changes are? ;)
[09:49] <sil2100> *think
[09:50] <mhr3> sil2100, very low, plus no effect without new-scopes
[09:50] <sil2100> mhr3: I love landings like that, thank you for that!
[09:51] <sil2100> mhr3: anyway, expect it being published in the nearest minutes, just want to run unity8 tests till the end as a quick double-check
[09:51] <mhr3> it really can't affect that, it's all new-scopes only
[09:59] <popey> hmm, phone is plugged into usb, does that prevent deep sleep?
[10:00] <didrocks> ogra_: ^
[10:00]  * popey starts the song again
[10:00] <popey> getting sick of this song now ㋛
[10:00] <ogra_> i think adbd keeps a wakelog in the kernel
[10:00] <popey> ok
[10:00]  * popey unplugs
[10:01] <didrocks> ogra_: wakelock, you meant? (you keep sayig wakelog, so maybe I missed something? :p)
[10:01] <didrocks> saying*
[10:01] <ogra_> err, not really awake locked here :P
[10:01] <ogra_> (indeed i meant wakelock ;) )
[10:05] <sergiusens> didrocks, hey, fyi; last night it seems cjwatson gave me the hint that components landing only for ubuntu touch are covered by the spirit of the original bug/FFe ... the only thing I forgot to ask yesterday was if we should add a comment or edit the description of such bug
[10:06] <didrocks> sergiusens: hum, I think the description was clear it was about that, (and that's why there is the exact list). It's telling:
[10:07] <didrocks> I would like to request a blanket FFe wrt Ubuntu Touch, for those packages that are part of Ubuntu Touch but not part of Ubuntu Desktop
[10:07] <sergiusens> didrocks, oh, I'm not talking about the current list; but about additions to that list
[10:08] <didrocks> sergiusens: ah, it needs to be acked first, so I guess on comment
[10:08] <didrocks> sergiusens: and then, we add it to the description
[10:09] <didrocks> sergiusens: maybe in a subsection, mentioning that they are in other seeds, but won't have any backward incompatible breakage/not used really on the desktop
[10:09] <didrocks> to make the separation clear
[10:10] <sergiusens> didrocks, yeah, my case is for totally new components like media-hub and push-notifications
[10:11] <didrocks> sergiusens: oh sure, I guess once it's recorded in the comment that the RT +1 on it, feel free to append at the bottom of the description
[10:11] <sergiusens> ok, good that we have a process; fwiw media-hub was separately logged and approved already :-P
[10:12] <didrocks> sergiusens: ah great, so if you want to add to the list, please do (and reference the other bug in a comment)
[10:15] <sil2100> didrocks: packaging ACK: http://<IP_ADDRESS>/job/landing-005-2-publish/46/artifact/packaging_changes_unity-scopes-shell_0.4.0+14.04.20140320-0ubuntu1.diff <- looks sane
[10:16] <didrocks> sil2100: +1
[10:24] <cjwatson> sergiusens: I think it's appropriate to ask, just saying that from the point of view of the release team it probably means we normally don't need to think *too* hard
[10:28] <sergiusens> sounds good, thanks
[10:44] <sil2100> dbarth_: hi, wanted to ask some questions regarding landing line 12
[10:56] <seb128> sil2100, ok, I freed some silos, you are back to 4 ;-)
[10:57] <dbarth_> sil2100: go ahead
[10:58] <dbarth_> sil2100: it's good to go; i was just checking and sounds like robru didn't land it
[10:59] <dbarth_> sil2100: tests pass, we verified that with alex_abreu yesterday; can you press publish?
[10:59] <dbarth_> sil2100: then i can merge and clean that silo
[10:59] <sergiusens> Mirv, can you look at silo 1? it should be low risk fwiw; but land after promoting if you want
[11:05] <sil2100> dbarth_: I just wanted to double check if all is ok from the phone side, but it seems ok
[11:05] <sil2100> dbarth_: how would you assess the risk factor of this landing?
[11:07] <sil2100> seb128: thanks! I noticed already earlier, that's why I assigned an additional silo for you ;)
[11:07] <seb128> sil2100, thanks ;-)
[11:12] <dbarth_> sil2100: limited, it changes JS code used by the html5 stack; only html5 app developers would be affected if there is a regression we haven't seen
[11:12] <davmor2> popey: didrocks: Stairway to heaven 8:02 played from start to finish no issues
[11:12] <popey> davmor2: while plugged in or not?
[11:13] <davmor2> popey: not I was downstairs
[11:13] <popey> hm, okay
[11:13] <popey> how odd
[11:13] <sil2100> dbarth_: publishing!
[11:13] <davmor2> didrocks: also I've replied to the phone list
[11:14] <dbarth_> sil2100: ok
[11:16] <davmor2> morning all
[11:16] <Mirv> sergiusens: you're correct that it looks safe since it only adds a plugin not touching other things. that said, it wouldn't hurt to have the promotion happening either
[11:16] <Mirv> sergiusens: the docs branch is not top-approved
[11:21] <sergiusens> Mirv, right; the top approving is really necessary these days?
[11:21] <Mirv> sil2100: ^
[11:21] <Mirv> sergiusens: I don't know, asking from the more experienced train mover :)
[11:22] <davmor2> popey: just played it again to prove it wasn't a fluke still not plugged in
[11:22] <sil2100> sergiusens, Mirv: it's nice to have, but it's not necessary - as long as we see there is someone from upstream doing any approval for the newest and latest of the commit
[11:22] <sil2100> *commits
[11:22] <Mirv> sil2100: yeah, so some approval is enough. ok.
[11:23] <Mirv> sil2100: would you mind looking too if https://code.launchpad.net/~diegosarmentero/ubuntu-download-manager/udm-qml-plugin/+merge/209573 seems safe to you? it only adds stuff so that's why it'd seem to me it's safe to publish.
[11:23] <sil2100> Mirv: u-d-m! Oh noes! Let me check
[11:23] <Mirv> sil2100: yeah, I've some memories of u-d-m breaking earlier, that's why it feels like it's useful to be extra sure :)
[11:25] <sil2100> Mirv: I think you're right - it seems really nice and safe, only adding the plugin - is it tested in a silo already? :)
[11:25] <sergiusens> Mirv, fwiw; we landed u-d-m 2 times this week already
[11:26] <Mirv> sil2100: yes, it's tested. there's another MP that claims to be docs only but I see slight weird differences there otherwise too: https://code.launchpad.net/~mandel/ubuntu-download-manager/documentation/+merge/209664
[11:26] <Mirv> sergiusens: why there's a registerMetaType() function removed in the docs commit?
[11:26] <mandel> Mirv, let me double check, but it is mainly docs and I did the test plans for udm, click scope and system image updates
[11:26] <Mirv> and there are consts added, and &:s moved around
[11:27] <Mirv> mandel: ok, just pointing out since it claims to be about documentation but has some other slight changes
[11:27] <mandel> Mirv, the function call was removed because it was never used and makes no sense
[11:27] <mandel> Mirv, const were added but are just for internal objects in the priv lib
[11:28] <mandel> Mirv, I can link bugs about that to document it, no problem
[11:28] <Mirv> mandel: it'd be enough if the MP commit / description would state that some function and some constructors were removed and consts:s added, in addition to docs changes
[11:29] <Mirv> well and of course if there are already bugs open, those are welcome too to be linked
[11:29] <mandel> Mirv, there are no bugs added, no, but I'll update the commit msg, does that sound good?
[11:29] <Mirv> s/constructors/destructors/
[11:29] <Mirv> mandel: sounds good
[11:30] <Mirv> other than the group_download_struct.cpp changes it's quite clear
[11:30] <popey> davmor2: bug 1295086  if you can reproduce pls..
[11:30] <popey> seen it for ages, only just got round to filing it
[11:31] <mandel> Mirv, MR updated
[11:31] <Mirv> mandel: thanks
[11:32] <mandel> Mirv, no proble, sorry for that I did it without thinking it was very important :-/
[11:33] <Mirv> didrocks: I'd need packaging ack for http://<IP_ADDRESS>/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-download-manager_0.3+14.04.20140319.1-0ubuntu1.diff - seems good, unless all plugins are wanted to be forced to be of the form qtdeclarative5-[packagename][version]. I'd allow that, but I'm not sure how strict our policy is. that current version sounds better than qtdeclarative5-ubuntu-download-manager0.1
[11:34] <mandel> Mirv, we can ping gatox about that
[11:34] <Mirv> mandel: you just did :)
[11:35] <mandel> Mirv, I think is better to follow the norm if possible
[11:35] <mandel> Mirv, awesome, then I'll let you guys decided about qml, is out of my area :)
[11:35] <gatox> mandel, if it's about naming, i think it shold follow the convention
[11:35] <Mirv> mandel: gatox: yeah, I don't see too many deviations from that norm, so possibly qtdeclarative5-ubuntu-download-manager0.1 should be used
[11:35] <Mirv> ok, commenting on the MR then
[11:35] <Mirv> didrocks: unping
[11:36] <mandel> gatox, please, can you update that? I think with that change we can land the qml so that the browsers guys can start looking into it
[11:36] <sil2100> ;)
[11:38] <Mirv> commented, also mentioning the version-specific install directory which we are implementing quite poorly in general but that was the proposed policy and makes sense
[11:38] <Mirv> working unping would actually be useful
[11:39] <gatox> mandel, updated
[11:39] <mandel> Mirv, didrocks ^^
[11:39] <mandel> gatox, sweet, thx
[11:39] <Mirv> mandel: gatox: then the version specific install directory too, please
[11:40] <Mirv> so eg. UbuntuDownloadManager.0.1, so that when you'll have 0.2 the new package can be co-installed
[11:41] <gatox> mandel, Mirv version added to the install folder
[11:41] <Mirv> it might need a bit more tweaking in the .pro files
[11:42] <gatox> Mirv, how's that?
[11:42] <Mirv> gatox: the make install obviously needs to install to that directory too
[11:42] <Mirv> it could be tricked with packaging maybe too, though, but that'd need creating directory manually and moving files or such
[11:43] <Mirv> friends has something like http://bazaar.launchpad.net/~super-friends/qml-friends/trunk/view/head:/modules/Friends/Friends.pro
[11:43] <Mirv> so modifying installPath
[11:45] <davmor2> popey: I get the same even if I hit reload I think it is an issue in mtp infrastructure and instantly blame ogra_ ;)  can you see if the same thing happens on your iphone?
[11:45] <davmor2> popey: ie if it is mtp at fault or just our implementation of it
[11:46] <davmor2> popey: oh by the way were you able to replicate the issue I found with contacts/dialer app?
[11:48] <gatox> Mirv, mandel .pro updated
[11:51] <Mirv> mandel: ok, kick a rebuild?
[11:51] <Saviq> didrocks, just thought of a relatively simple thing that could be helpful if possible - updating the PPA description with some data like the description of the landing, list of included MPs and such
[11:51] <mandel> Mirv, sure
[11:52] <davmor2> popey: confirmed and commented
[11:59] <popey> davmor2: thanks, also.. can you test alarms? They're not going off for me
[11:59] <davmor2> popey: and confirmed it works correctly on android so it is just our implementation of mtp
[11:59] <davmor2> popey: in which case I definitely blame ogra_  :D
[12:01] <davmor2> popey: alarm set for 5 minutes past
[12:02] <davmor2> popey: should they go off with the phone screen blank?
[12:02] <davmor2> popey: or is that still not implemented yet?
[12:03] <popey> davmor2: even with the screen on
[12:04] <popey> it should ring.
[12:05] <davmor2> popey: okay, did you look at this in the end https://bugs.launchpad.net/bugs/1294710
[12:05] <davmor2> popey: ringing with screen on and the clock app closed
[12:05] <popey> davmor2: no, i have no contacts on my phone
[12:06] <davmor2> popey: right trying again now with the screen off
[12:08] <davmor2> popey: do you have like a 150 number to check your balance that is free to call?
[12:09] <popey> i have lots of numbers i can call for free, I just have no contacts on my device so will need to set them up to try it, not got round to it thats all
[12:10] <davmor2> popey: ah okay cool :)
[12:10] <davmor2> popey: Huston I think we have a problem
[12:10] <didrocks> Saviq: that's a good idea. I have other things I want to do first, but if you open a bug, I'll do that after the bot :p
[12:11] <Saviq> didrocks, ;D
[12:11] <davmor2> popey: with the screen on I got an alarm, with the screen off I don't and looking at the device it seem that the clock got stopped when the alarm should of gone off
[12:11] <popey> davmor2: tried your bug, can't reproduce, contact appears
[12:12] <popey> davmor2: clock doesn't trigger alarms, indicator-datetime does
[12:12] <davmor2> popey: yeah the time in the indicator is stuck when the alarm should of gone off
[12:13] <Saviq> didrocks, bug #1295096
[12:14] <davmor2> popey: can you edit an alarm twice and have it update correctly?
[12:15]  * popey tries
[12:15] <popey> davmor2: when i try to edit an alarm I get this... http://popey.com/~alan/phablet/device-2014-03-20-121531.png
[12:16] <sil2100> boiko: hello! Your messaging-app is in silo 014
[12:16] <davmor2> right so I've set an alarm now for 18 minutes past I'll let the phone sleep and I'm betting at 19 minutes past the clock will still say it is 18 minutes past
[12:16] <didrocks> Saviq: thanks :)
[12:17] <popey> davmor2: also, clock crashes when you delete an alarm
[12:17] <popey> [Thu Mar 20 12:07:55 2014] type=1400 audit(1395317761.205:493): apparmor="DENIED" operation="mknod" parent=1928 profile="com.ubuntu.clock_clock_1.0.373" name="/home/phablet/.config/com.ubuntu.clock_clock_1.0.373.conf.L21550" pid=21550 comm="qmlscene" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011
[12:17] <davmor2> popey:  oh I don't get that what happened for me is the last alarm was at 12:08 I changed it to 12:15 hit save and it still showed 12:08
[12:17] <boiko> sil2100: thanks, let me build that
[12:17] <didrocks> davmor2: popey: IIRC, alarms were not triggered already in previous promoted image, right?
[12:17] <davmor2> popey: it just deletes them here
[12:18] <popey> didrocks: lemme try
[12:18] <boiko> sil2100: oh, they are already built, nice
[12:18] <sil2100> boiko: I already pressed build to speed things up if anything ;)
[12:18]  * didrocks has never seen that working
[12:18] <boiko> sil2100: nice! thanks
[12:18] <popey> didrocks: having two phones means i find it hard to remember what works where ☻
[12:18]  * sil2100 wants this fix badly ;)
[12:18] <davmor2> didrocks: iirc it did if the phone was awake but not when it was asleep
[12:18] <didrocks> popey: ETOOMANYPHONES!
[12:18] <didrocks> davmor2: hum
[12:18] <popey> you're right
[12:19] <davmor2> didrocks: which is what I am seeing now
[12:19] <didrocks> on arlams or on the too many phones? :p
[12:20] <popey> didrocks: bad news!
[12:20] <davmor2> popey: it looks like the alarm just went off and now won't stop so 2 minutes late and the clock says 12:18
[12:20] <popey> alarm just went off on my stable phone!
[12:21] <davmor2> didrocks: ^
[12:21] <didrocks> hum
[12:21] <didrocks> grrr, ok :(
[12:21] <didrocks> not sure what our tests, there are alarms tests
[12:21] <davmor2> just had to reboot the phone to stop the alarm
[12:21] <didrocks> popey: davmor2: so I guess it's alarm testing time…
[12:22] <davmor2> didrocks: now I know it works I will I wasn't adding it till it did though there was no point :)
[12:23] <didrocks> so, the question is… is it a blocker in your opinon?
[12:24] <davmor2> popey: Column AD does the description make sense?
[12:25] <didrocks> davmor2: popey: so on latest promoted image, it was only working if the screen wasn't blank?
[12:26] <popey> wait 2 mins for my alarm
[12:26] <davmor2> popey: ^  does it work with the screen blank as well as active?
[12:26]  * popey taps power button
[12:26]  * popey waits
[12:26] <didrocks> davmor2: IMHO, if didn't work with a blank screen ~= non functional for me
[12:27] <popey> alarm rings when screen is blank
[12:28] <didrocks> ok, and so, not on latest image, right?
[12:28] <popey> on current build number: 237
[12:28] <didrocks> aah
[12:28] <didrocks> but?
[12:28] <didrocks> you didn't say the contrary
[12:28]  * didrocks is lost
[12:28] <popey> so, in summary:-
[12:28] <didrocks> ah, #237, so latest promoted
[12:28] <popey> You asserted that the alarms never worked on a promoted image. I'm saying they did. When blanked.
[12:28] <didrocks> ok
[12:29] <popey> dpm just heard it via a hangout :D
[12:29] <didrocks> so, we need to bisect
[12:29] <dpm> hahaha
[12:29] <popey> let me test again on latest image
[12:29] <didrocks> yep
[12:29] <popey> note though that I see a lot of this...
[12:29] <popey> [Thu Mar 20 12:07:56 2014] type=1400 audit(1395317761.205:493): apparmor="DENIED" operation="mknod" parent=1928 profile="com.ubuntu.clock_clock_1.0.373" name="/home/phablet/.config/com.ubuntu.clock_clock_1.0.373.conf.L21550" pid=21550 comm="qmlscene" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011
[12:29] <popey> on the latest promoted image
[12:29] <didrocks> jdstrand: ^
[12:30] <popey> gnnnn
[12:30] <sergiusens> popey, make sure alarms work on flo which doesn't have the wakeloc problem
[12:30] <popey> latest non-promoted image
[12:30] <popey> ffs
[12:30] <sil2100> ;/
[12:30] <didrocks> sil2100: so, continue to not publish anything risky :p
[12:31] <popey> bah. clock crashes on alarm save
[12:31] <sil2100> I hate news like this! I want to publish everything as it goes already ;p !
[12:31] <didrocks> sil2100: well, even once we promote, we need to ramp up publication
[12:31] <didrocks> sil2100: and cut images regularly
[12:31] <davmor2> popey: on current when the alarm goes off does it wake the screen in the same way a call would?
[12:31] <popey> no
[12:31] <popey> just rings
[12:32] <popey> right, cleared out all alarms and created a new one
[12:32] <popey> no errors in dmesg, no crash
[12:32] <sil2100> didrocks: indeed
[12:32]  * popey hits power and waits 2 mins
[12:33] <davmor2> popey: okay that's odd are you leaving the clock app open?
[12:34] <jdstrand> didrocks, popey: that is bug #1288742
[12:35] <popey> thanks jdstrand
[12:35] <jdstrand> np
[12:35] <davmor2> popey: last alarm didn't go off but the clock app was open, trying again now with the clock app closed
[12:35] <popey> didrocks: alarm didnt ring on latest unpromoted
[12:36] <popey> aha!
[12:36] <popey> it displays but doesn't ring!
[12:36] <popey> but if the display is off, obviously you can't see it
[12:36] <didrocks> jdstrand: argh, so it was known?
[12:36] <jdstrand> yes, I filed it weeks ago
[12:36] <didrocks> jdstrand: but I guess you didn't know it was preventing the alarm going off
[12:37] <didrocks> sil2100: Mirv: can we try to land that with bzoltan's help?
[12:37] <jdstrand> and reported it on the list when I examined new denials
[12:37] <jdstrand> didrocks: actually, I think I said as much-- ie, that the app wouldn't work right. I told Pat about it. looking at the bug there is an MP
[12:38] <popey> didrocks: davmor2 http://popey.com/~alan/phablet/device-2014-03-20-123802.png
[12:38] <popey> thats latest unpromoted, the alarm _does_ trigger, but no ring
[12:38] <jdstrand> (ie, I told Pat, Pat escalated it, there is an MP)
[12:38] <didrocks> jdstrand: ok :( sad that Pat didn't report the info
[12:38] <jdstrand> well, I did
[12:39]  * jdstrand finds the thread
[12:39] <Mirv> didrocks: sil2100: with bzoltan's help, yes
[12:39] <Mirv> bzoltan: can you check https://bugs.launchpad.net/ubuntu-clock-app/+bug/1288742 and add a line for that MP only?
[12:40] <didrocks> Mirv: I guess if bzoltan isn't aroud, we have to land and test ourself ASAP
[12:40] <davmor2> didrocks, jdstrand: so till this is fixed are we saying that alarms should be flakey then?
[12:40] <didrocks> jdstrand: on the ML == on the Qt 5.2 discussion? it wasn't raised as a blocker (not meaning by you, but when I asked for remaining bugs)
[12:40] <jdstrand> actually, I didn't mention that bug in the thread I was thinking of, cause I had already reported it and it was escalated
[12:40] <Mirv> didrocks: ok, adding line
[12:40] <sil2100> Mirv: ok
[12:40] <popey> didrocks: davmor2 i believe the issue jdstrand is talking about is separate from the alarm sounding.
[12:41] <didrocks> Mirv: and build and so on :)
[12:41] <sil2100> Mirv: need some help with testing?
[12:41] <didrocks> sil2100: can you help on the testing ^
[12:41]  * jdstrand doesn't actually know the impact of the bug
[12:41] <popey> the alarm saves, and we get the DENial, but when the alarm time comes, it _does_ trigger, just makes no noise.
[12:41] <didrocks> jdstrand: do you think it can impact the current bug we are talking about?
[12:41] <jdstrand> I just assume that things won't work right cause it can't write out its .conf file
[12:41] <sil2100> didrocks, Mirv: just in case poke me once the packages are built and I'll perform the testing as well
[12:41] <jdstrand> I have no idea. All I reported is what I saw in the log
[12:41] <asac> didrocks: whowever owns this MP should have pusehd for landing it
[12:41] <asac> didrocks: who owns the MP?
[12:42] <davmor2> popey: how are you taking screenshots now?
[12:42] <jdstrand> this isn't a new bug though
[12:42] <popey> davmor2: magic
[12:42] <popey> davmor2: http://paste.ubuntu.com/7125032/
[12:42] <didrocks> asac: we are still unsure it's going to fix it though, seems we just know apparmor denies something
[12:42] <didrocks> asac: you have the bug link, I'm like you, just discovering it
[12:42] <didrocks> and I wasn't on those meeting nor coordinating the landing
[12:43] <jdstrand> I reported it on the 6th. if they were working and now don't, it is unlikely due to only this bug
[12:43] <asac> didrocks: just saying that pat seeded the priority somewhere and that somewhere probably failed to continue talking to us
[12:43] <didrocks> asac: the MP is https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/statesaver-discard-shutdown/+merge/205042
[12:44] <asac> bzoltan: ^^ can you check why this wasn't pushed for landing yet?
[12:44] <asac> if thats not right etc.
[12:44] <asac> thanks
[12:44] <didrocks> asac: we are trying/testing ourselves for now
[12:44] <jdstrand> but it is easy to test: update /var/lib/apparmor/profiles/click_com.ubuntu.clock_clock_* to have 'owner @{HOME}/.config/com.ubuntu.clock.conf* rw,', then run sudo apparmor_parser -r /var/lib/apparmor/profiles/click_com.ubuntu.clock_clock_*
[12:44] <didrocks> as it seems bzoltan isn't around
[12:44] <didrocks> popey: can you try that? and then try the alarm again? ^
[12:44] <asac> ok asked zsombi as well what he remembers
[12:44] <asac> in -touch
[12:45] <popey> sure thing didrocks
[12:45] <didrocks> just to see if this is a side-effect (no nose made)
[12:45] <didrocks> thanks popey
[12:46] <ogra_> davmor2, you blame me for what exactly ?
[12:46] <ogra_> (seems part of your conversation got lost in my disconnect)
[12:47] <popey> ogra_: probably for the best ☻
[12:48] <Mirv> I'm trying to get zsombi here to discuss..
[12:48] <ogra_> heh
[12:48] <popey> jdstrand: any particular place in that file?
[12:48] <popey> inside the "profile" stanza I guess?
[12:48] <jdstrand> popey: just within the {}
[12:48] <davmor2> ogra_: mtp on the phone doesn't update on the fly.  If you add a file via nautilus to Videos, say.  It shows in Nautilus and on the phone.  If you remove it via adb shell rm /home/phablet/Videos/*  it still shows in nautilus even if you remount the device or reload nautilus
[12:48] <popey> kk
[12:49] <davmor2> ogra_: tried it on android and it removed the file immediately
[12:49] <boiko> sil2100: I have just finished testing landing-014, it is ready to go
[12:49] <ogra_> davmor2, blame nautilus :P
[12:49] <Mirv> UITK building at https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/+packages
[12:49] <davmor2> ogra_: no tis mtp honest let me try one more thing though
[12:50] <ogra_> well, file a bug, did that ever work ?
[12:50] <popey> ogra_: no
[12:50] <ogra_> ah
[12:50] <popey> its always been like this
[12:50] <popey> i did file a bug ☻
[12:50] <davmor2> ogra_: there is a bug
[12:50] <popey> Step 1: File a bug.
[12:50] <popey> Step 2: berate ogra_
[12:51] <ogra_> davmor2, cyphermox owns the daemon, i guess it needs to learn about inotify
[12:51] <Mirv> I still didn't get zsombi here, but t1mp is here for your UITK questions at least :)
[12:51] <mandel> Mirv, sil2100 the silo 01 has been rebuilt, can you please take a look
[12:51] <mandel> ??
[12:51] <didrocks> Mirv: read #ubuntu-touch
[12:51] <Mirv> didrocks: ah!
[12:52] <davmor2> ogra_: yes but if we pick on you it magically gets fixed that's the way it always works ;)
[12:53] <davmor2> popey: there you go assign the bug to cyphermox :)
[12:53] <Mirv> mandel: the binary looks good to me now in the PPA! could do just a quick testing and mark it then to be tested again (I marked it "no" earlier)?
[12:53] <mandel> Mirv, sure, I'll do a second run of the tests (including system image updates && click scope
[12:53] <sil2100> boiko: excellent! I'll publish it after quickly grabbing something to eat
[12:53] <Mirv> it's useful to test the plugin still works actually etc
[12:54] <Mirv> mandel: excellent!
[12:54] <sil2100> Mirv: I'll grab some food right now, if you can ping me once packages are ready for testing I would be grateful :)
[12:54] <sil2100> I'll be around the PC all the time
[12:54] <mandel> Mirv, will do a schroot test for the plugin since I have no app that uses it
[12:54] <boiko> sil2100: nice! any ETA on when general landing is going to be allowed again? we have been blocked on landing for quite some time now
[12:55] <popey> jdstrand: sudo apparmor_parser -r is taking quite some time but I see nothing eating cpu
[12:55] <Mirv> sil2100: sure I'll do
[12:55] <sil2100> Mirv: thanks!
[12:56] <sil2100> boiko: we hoped to have things unblocked today, but we'll see...
[12:56] <jdstrand> popey: that is weird. can you just tap the Enter key? it shouldn't take more than a couple seconds
[12:56] <popey> yeah, did that
[12:56] <popey> Warning from stdin (line 1): apparmor_parser: cannot use or update cache, disable, or force-complain via stdin
[12:56] <popey> got that when i started it
[12:56]  * popey checks he didnt mess the file up
[12:57] <jdstrand> popey: can you paste your full command and the contents of the file?
[12:57] <davmor2> ogra_: on a plus side I've not found the bug that blocks the build from being promoted it's all popey's fault today :D
[12:57] <popey> jdstrand: sure
[12:57] <ogra_> davmor2, yeah, agreed :)
[12:57] <popey> jdstrand: http://paste.ubuntu.com/7125093/
[12:58] <popey> root@ubuntu-phablet:/var/lib/apparmor/profiles# sudo -u phablet -i
[12:58] <popey> phablet@ubuntu-phablet:~$ sudo apparmor_parser -r
[12:58] <sil2100> boiko: in the meantime, I'm double testing that landing and then publishing
[12:58] <popey> then the warning and ... Time passes...
[12:58] <boiko> sil2100: we didn't even finished flushing the pile of MRs we had since the qt5.2 switching, it is getting complicated :/
[12:59] <didrocks> jdstrand: sil2100: Mirv: reading #ubuntu-touch, doesn't seem so clear it's related to that
[13:00] <jdstrand> popey: the file parses fine. can you paste the command you are running?
[13:00] <Mirv> I'm confused at least, but it's worth a shot upgrading and seeing if it affects the found bug
[13:00] <popey> jdstrand: see above
[13:01] <popey> jdstrand: my bad, missed a parameter. what a putz
[13:01] <popey> sorry
[13:01] <jdstrand> popey: ah! it is sudo apparmor_parser -r <path to profile>
[13:01] <popey> ok, works now
[13:01] <jdstrand> cool
[13:01]  * popey reboots to set an alarm
[13:03] <sil2100> Mirv: +1
[13:04] <popey> jdstrand: ok, the apparmor denials go away
[13:04] <jdstrand> k, so now you can rule out apparmor definitively if the bug is still there
[13:07] <popey> ok. so now... it's different
[13:08] <sil2100> didrocks, boiko: messaging-app looks nice, publiishing
[13:08] <boiko> sil2100: thanks
[13:09] <didrocks> sil2100: hum, is it sane?
[13:09] <didrocks> with the current regressions we have?
[13:09] <didrocks> sil2100: or is it the fix for the flaky test?
[13:09] <boiko> didrocks: fix for the flaky test
[13:09] <didrocks> ok
[13:09] <didrocks> thanks boiko :)
[13:09] <sil2100> didrocks: fix for tests ;)
[13:09] <boiko> np
[13:10]  * boiko is just hoping to get unblocked soon to land more stuff :)
[13:10] <didrocks> boiko: well, seems there is yetanotherregression
[13:10] <didrocks> so it all depends on anyone's help
[13:18] <Mirv> sil2100: ppa:ci-train-ppa-service/landing-008 has the new UITK now
[13:18] <Mirv> (published)
[13:21] <sil2100> Mirv: thanks! Upgrading :)
[13:22] <didrocks> Mirv: sil2100: so, seems we can drop it
[13:22] <sil2100> ...oook
[13:22] <sil2100> ;)
[13:22] <Mirv> didrocks: I'm just testing if magic happens
[13:22] <didrocks> yeah, let's see
[13:22] <Mirv> "it shouldn't work!"
[13:23] <didrocks> but based on the feedback
[13:23] <didrocks> I'm not hopeful
[13:23] <Mirv> er, um, somehow I got the alarm ringing even though my screen was blanked
[13:24] <sil2100> uh
[13:24] <sil2100> Let me try then
[13:24] <Mirv> maybe I didn't do everything the same way, I among else removed the earlier one and added new one
[13:26] <ogra_> davmor2, i'm hitting the same bug with the UI being unresponsive for a whille here ... seems apport is running when that happens
[13:26] <ogra_> (eating 95% CPU)
[13:27] <Mirv> sil2100: ok, now I got the "usual" behavior, ie same as before upgrade
[13:27] <davmor2> ogra_: when you wake the device from a sleep right?
[13:27] <Mirv> so nothing sounds, but when I turn on the screen after some time I see the visual alarm is there
[13:27] <ogra_> davmor2, yes, just wanted to upgrade it after i hadnt touched it for two days
[13:28] <davmor2> ogra_: and then it works fine afterwards right?
[13:28] <ogra_> yes, but i just noticed i'm 10 versions behind (238)
[13:28] <sil2100> Mirv: rebooting my device to make sure and testing to see if I have the same
[13:28] <ogra_> so probably not relevant for what you are seeing
[13:29] <davmor2> ogra_: no I've hit it on and off for a little bit so it could be I'd not seen it for a few days so threw me when I got hit by it again this morning, let me see if there is a crash file
[13:30] <ogra_> well, it was definitealy apport eating the device for me here
[13:30] <didrocks> davmor2: mind checking with Mirv? ^
[13:30] <didrocks> Mirv: before you update or after?
[13:30] <davmor2> ogra_: _usr_lib_arm-linux-gnueabihf_qt5_bin_qmlscene.32011.crash
[13:31] <ogra_> i see a unity8 and system-settings one here
[13:31] <didrocks> Mirv: so, it fixes it for you?
[13:31] <didrocks> if I read correctly?
[13:31] <Mirv> didrocks: no, it worked once and no again doesn't, so maybe same as davmor2
[13:31] <didrocks> Mirv: ok, maybe try to upgrade then
[13:32] <didrocks> add a new alarm
[13:32] <didrocks> and see…
[13:32] <Mirv> didrocks: this is after upgrading, I also tested it before updating
[13:32] <didrocks> ah ok :(
[13:32] <didrocks> so yeah, ditch the silo
[13:32] <Mirv> sure, sil2100 will probably soon come up with the same report as well
[13:32] <sil2100> Mirv: for now I can't seem to get an alarm working at all!
[13:32] <davmor2> Mirv, didrocks: yeah that sounds like what I saw it works sometimes with a delay and doesn't work again properly with the screen off, but with the display active it seems to work
[13:33] <davmor2> biab lunch
[13:36] <dobey> didrocks: can we get ddebs support enabled on the silo PPAs please?
[13:36] <didrocks> dobey: you do have ddebs support, but they can't be published
[13:37] <didrocks> or binary copies don't work then
[13:37] <dobey> huh? where can i get the dbgsym packages then?
[13:38] <cjwatson> I think they get slurped to ddebs.ubuntu.com in a nasty way
[13:39] <wgrant> Nasty and not always totally reliable.
[13:39] <cjwatson> yeah, so e.g. https://launchpad.net/~ci-train-ppa-service/+archive/landing-015/+build/5828962 has its ddebs on http://ddebs.ubuntu.com/pool/universe/g/gallery-app/
[13:39] <cjwatson> right
[13:41] <thostr_> didrocks: sil2100: how are the chances to promote a Qt 5.2 image today? I'm really want to switch scopes...
[13:41] <dobey> ick
[13:42] <sil2100> thostr_: well... the alarm and music regressions are a bit troublesome right now
[13:42] <didrocks> thostr_: none
[13:42] <popey> davmor2: added a video to your clock bug
[13:42] <didrocks> thostr_: but good news is that the alarm regressions is set to your team
[13:42] <didrocks> thostr_: so you can help us getting back to green :)
[13:42] <thostr_> didrocks: amazing, regressions without changes... will take care of it
[13:43] <thostr_> didrocks: so, for scopes, do I have to sacrifice a cow to finally get it in next week?
[13:43] <didrocks> thostr_: well, you need even more than a cow :)
[13:44] <didrocks> thostr_: the regression is from first day of Qt 5.2 btw
[13:44] <didrocks> thostr_: but no test apparently
[13:44] <didrocks> so only spotted today
[13:45] <thostr_> didrocks: mhhh, ok. but scopes need to land next week... it's getting embarassing slowly
[13:45] <didrocks> thostr_: don't you think I am embarassed either?
[13:46] <thostr_> didrocks: good point
[13:46] <didrocks> thostr_: not sure if you realize how much complains and handling regression is hard
[13:46] <thostr_> didrocks: I do believe you
[13:51] <cjwatson> dobey: we'll be able to do better once we have the new wonderful expandable librarian, which is blocked on prodstack 4
[13:52] <cjwatson> dobey: but right now, well, https://lpstats.canonical.com/graphs/LibrarianFreeDiskSpace/
[13:52] <cjwatson> death in one month
[13:58] <didrocks> thostr_: https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1295122 btw
[13:58] <didrocks> thostr_: seems the sdk team says it's charles being the best asset for it
[13:58] <didrocks> thostr_: this is one of the blockers
[13:58] <didrocks> thostr_: I'm inviting you to the landing meeting as well, as now, all landers having blockers are invited
[13:59] <didrocks> so that we can share status and so on
[14:05] <sil2100> Mirv: pun intended :D
[14:08] <Mirv> sil2100: :)
[14:12] <asac> thostr_: on qt5.2 ... help us nail the two/three late coming regressions found that prevent sending this to dogfooders
[14:13] <boiko> sil2100: looking at the update_excuses file, it is saying that messaging-app has unsatisfiable dependencies on telephony-service and history-service stuff
[14:13] <sil2100> Mirv, didrocks: as notes-app is anyway click and trunk is already in our images, I'll publish the silo with notes-app to flush it as a deb package
[14:13] <sil2100> boiko: let me see
[14:13] <Mirv> sil2100: yeah, thanks, I was meaning to ask about it but then other things rushed forward
[14:13] <sil2100> boiko: ah, ok, so it seems we need powerpc and ppc64el in the end
[14:13] <thostr_> asac: will take care of the datetime thing
[14:14] <cjwatson> sil2100: oh, I think I started looking at that, let me have another poke
[14:14] <boiko> sil2100: so, will that land on trusty or do I need to take any action on that?
[14:14] <cjwatson> boiko: ^-
[14:14] <cjwatson> since I'm blocked on something else right now anyway ...
[14:14] <sil2100> cjwatson: thanks! :)
[14:14] <boiko> cjwatson: thanks
[14:14] <didrocks> sil2100: yeah, things like that is fine
[14:15] <ogra_> asac, thostr_, so we nailed the issue down to "*all* events get queued when suspended" volume changed as well as playing the next song from the playlist (and i suspect also alarms) get queued up as long as the screen is off ... and get applied immediately when we wake up the device
[14:15] <ogra_> *volume changes
[14:16] <ogra_> didrocks, ^^^
[14:16] <sil2100> ogra_: oh
[14:16] <didrocks> so it would be -2 issues
[14:16] <didrocks> (still 2 to go)
[14:16] <ogra_> i think all our bugs have the same source
[14:16] <ogra_> (well at least music and alarms)
[14:16] <didrocks> ogra_: do you think it's due to unity-mir or Qt?
[14:17] <ogra_> eirther ...
[14:17] <ogra_> or unity8
[14:27] <asac> Saviq said its MIR, no?
[14:27] <asac> i dont even kno whow to stop event loops in qt
[14:27] <asac> is that a central feature?
[14:28] <didrocks> asac: mir as unity-mir, app lifecycle maybe…
[14:28] <asac> if we know how to do that we can find clients that do that and probably get one step closer to the soruce :)
[14:28] <didrocks> I wonder if you put your phone off
[14:28] <asac> folks are discussing in #phablet
[14:28] <didrocks> and try to call you
[14:28] <didrocks> popey: davmor2: do you try that? ^
[14:29] <asac> if theory is right, nothing should really work with screen off
[14:29] <asac> though phone all might trigger something else that might make things wake up
[14:29] <sil2100> I'll try that as well
[14:29] <popey> didrocks: lemme test
[14:29] <Saviq> asac, that was a suspicion, and Mir, not MIR
[14:29] <popey> didrocks: it does ring
[14:30] <sil2100> didrocks, popey, asac: so, on my phone it rings
[14:30] <Saviq> asac, and we're discussing, might be that Qt queues events when it can't render (and it can't render because buffers are not being swapped)
[14:30] <didrocks> Saviq: popey: it's off, like screen blank and low power?
[14:30] <didrocks> hum sil2100 ^
[14:30] <popey> well, screen off, dunno how to tell low power
[14:30] <sil2100> didrocks: yes, I had the screen off for a longer time now, but when I call it lights up and rings
[14:30] <Saviq> didrocks, no, enough to be screen blank and no low power
[14:30] <popey> i press power button
[14:30] <Saviq> didrocks, keeping it active via powerd-cli doesn't help
[14:30] <sil2100> didrocks: not sure how long should I wait
[14:31] <didrocks> Saviq: so, seems some events are proceeding still, but it's another app
[14:31] <Saviq> :'( can we not do this in two channels in parallel?
[14:31] <didrocks> ok sil2100
[14:31] <Saviq> someone decide #phablet or here
[14:31] <davmor2> didrocks: wakes, shows the notification and ringfs
[14:31] <davmor2> rings even
[14:31] <didrocks> Saviq: not sure why the discussion should be in another than public channel
[14:32] <asac> didrocks: ok... lets give Saviq some time to investigate with his teams ... probably more helpful to not distract them for an hour or two :P
[14:32] <ogra_> didrocks, well, it happens in two public and one private channel atm
[14:32] <asac> lol
[14:32] <sil2100> o_O
[14:32] <Saviq> @all: #ubuntu-touch please
[14:32] <asac> yep
[14:33] <sil2100> Ah crap, it's Thursday again
[14:33] <ogra_> can we move all conversation about it to #ubuntu-touch ?
[14:33] <ogra_> ah
[14:33] <ogra_> Saviq, beats me
[14:50] <sil2100> When does Bill appear usually?
[14:51] <ogra_> didrocks, wow, the last notes-app changelog looks funny
[14:52] <ogra_> (on trusty-changes)
[14:52] <didrocks> ogra_: how funny? it matches commit messages
[14:52] <didrocks> https://code.launchpad.net/~phablet-team/notes-app/trunk
[14:52] <didrocks> people are using "merge"
[14:53] <ogra_> bah
[14:53] <sil2100> ._.
[14:53] <ogra_> couldnt it pull the info about "which branch" in automatically ?
[14:53] <cjwatson> Oh.  Suddenly the history-service failure makes more sense - it actually fails to build on all architectures now.
[14:54] <sil2100> cjwatson: oh, why now?
[14:54] <cjwatson> method signature change in telepathy-qt5
[14:54] <cjwatson> diagnosis not helped by (I think) clashing versions between the primary archive and the landing-006 PPA when Qt 5.2 was landing
[14:55] <balloons> didrocks, so I'm landing the merge for calendar to get a stable build into the store
[14:55] <balloons> can we make the next image?
[14:55] <didrocks> balloons: yeah, I guess you tested not any other AP tests failure/regressions?
[14:56] <balloons> didrocks, it passes on all my devices, my desktop and in jenkins. I feel good about the changes
[14:56] <balloons> popey will still be vetting it as well of course before it lands completely
[14:56] <didrocks> balloons: ok, then please, go ahead (anyway popey is retesting)
[14:56] <didrocks> yep
[14:56] <didrocks> so sounds good
[14:58] <cjwatson> boiko: do you think you could fix the history-service and telephony-service build failures?  they aren't power-specific, should reproduce easily
[14:58] <cjwatson> you can probably do it a lot quicker than me
[14:59] <cjwatson> boiko,sil2100: The rest of it should consist of landing https://code.launchpad.net/~cjwatson/libusermetrics/valgrind-optional
[15:01] <sil2100> cjwatson: so, the libusermetrics is also one of the things blocking messaging-app, or is it only history-service and libusermetrics is simply one of the leftovers with arch build problems?
[15:02] <cjwatson> sil2100: the former
[15:02] <cjwatson> sil2100: (indirectly)
[15:02] <sil2100> boiko: could you ping me once you have a fix for those? We would bundle it up along with the libusermetrics merge in one silo
[15:03] <sil2100> bfiller: hi!
[15:05] <bfiller> sil2100: hi
[15:05] <sil2100> bfiller: so, we were looking at landing 14 in the morning and I noticed that some of the merges from the landing do not have any approvals or even reviews
[15:05] <sil2100> bfiller: did anyone from upstream look through them code-wise ;) ? Could we at least have some local approvals of those MPs from someone?
[15:06] <bfiller> sil2100: which landing?
[15:06] <bfiller> silo 14?
[15:07] <bfiller> sil2100: if you're talking about gallery-app line 14, I literally tested all day yesterday these fixes
[15:07] <bfiller> sil2100: I'll double check the mr's but all should be approved
[15:08] <sil2100> bfiller: yes, line 14, silo 15 - if you could just check it code-wise real quick we'll at least have a +1 on that
[15:10] <sil2100> didrocks, Mirv: I would like to publish gallery-app and thumbnailer as well - the gallery-app changes anyway should not break anything as gallery is now click (so it will not be visible to the users), and the thumbnailer only fixes a crasher, and the code is safe
[15:10] <didrocks> sil2100: ok then
[15:10] <sil2100> didrocks, Mirv: I already ran all the gallery-app tests in the morning twice and it was +1
[15:10] <sil2100> (with only the new .deb installed)
[15:13] <sil2100> bfiller: if you could give me a quick poke if the MRs code wise are ok and/or approved then I'll publish
[15:13] <bfiller> sil2100: done
[15:13] <sil2100> Fast!
[15:13] <sil2100> ;)
[15:13] <bfiller> sil2100: I did this over hte past few days, just did not update the MR's
[15:14] <sil2100> Excellent, we just weren't sure, as we knew it was tested but didn't know about the code
[15:14] <bfiller> sil2100: my mistake, sorry about that
[15:15] <mandel> Mirv, sil2100 silo 01 looks good as it is
[15:16] <didrocks> sil2100: remember that tomorrow will be DEFCON0 is we can't promote an image today
[15:17] <didrocks> sil2100: if you are not going to attend the meeting this evening
[15:19] <sil2100> didrocks: http://<IP_ADDRESS>/job/landing-015-2-publish/lastSuccessfulBuild/artifact/packaging_changes_gallery-app_0.0.67+14.04.20140319-0ubuntu1.diff <- packaging ACK needed!
[15:19] <sil2100> didrocks: :<
[15:19] <sil2100> mandel: I'll look, but I'm only publishing things that are not risky
[15:20] <sil2100> mandel: ah, this!
[15:20] <mandel> sil2100, ok, although I'm quite sure is ok
[15:20] <didrocks> sil2100: +1
[15:20] <sil2100> mandel: ok, I would say it's good indeed, I'll just take a one-more-look before pressing any buttons
[15:20] <mandel> sil2100, great, thx!
[15:21] <bregma> sil2100, if you're not busy, could I get a silo assigned to line 39 (Unity7/Compiz bugfixes)?
[15:21] <sil2100> mandel: since we're on PHONECON1 right now still
[15:21] <sil2100> bregma: ok, if it's only desktop then I would be happy to provide a silo for you ;p
[15:22] <Saviq> sil2100, icanhassilo for row 42? it's not in landing state yet, but we wanted to start dogfooding split greeter
[15:22] <Saviq> 42!
[15:22] <cjwatson> sil2100: ah, it looks like boiko already fixed history-service and telephony-service in the middle of other branches (http://bazaar.launchpad.net/~boiko/telephony-service/conf_call/revision/780, http://bazaar.launchpad.net/~boiko/history-service/fix_filtering/revision/138)
[15:22]  * Saviq will always put his landings in row 42 from now on!
[15:23] <Saviq> can we have a silo -042, too? ;D
[15:23] <cjwatson> boiko: are those changes going to be ready to land soon, or would it perhaps be better to split them out into build-fix-only branches so that we can get them landed today?
[15:24] <sil2100> ;)
[15:24] <sil2100> Saviq: hmmm! I might add you one, just know that you'll be flushed out if we need a fix for unity8!
[15:25] <sil2100> bregma: silo ready
[15:25] <bregma> wicked, thanks
[15:27] <bfiller> sil2100: after the gallery-app is published can we get a silo for line 22? I think it should be clear of clashes with other silo's then
[15:27] <bfiller> sil2100: kenvandine and I itching to get that one tested and landed :)
[15:27] <kenvandine> please!
[15:31] <sil2100> bfiller: I'll see what we can do about that ;)
[15:33] <Saviq> sil2100, already discussed with didrocks
[15:33] <Saviq> sil2100, let's not for now
[15:34] <sil2100> Saviq: mhm, a good choice I guess
[15:34] <didrocks> Saviq: bfiller: line 22 seems a risky change involving multiple component, right? as we have difficulties to promote an image, not sure
[15:35] <bfiller> didrocks: just asking for a silo to test
[15:35] <bfiller> didrocks: yes many components
[15:35] <sil2100> bfiller: I didn't assign it till now because it seemed big, and we wanted to first flush out everything else and get a promoted image
[15:36] <bfiller> sil2100: right, plus it was blocked on the gallery silo
[15:36] <bfiller> (and others)
[15:36] <bfiller> but we need a test bed at this point to test all the changes together
[15:36] <didrocks> bfiller: please be aware that long-standing silos are the airline model, not ci train (not shaped for that), but if you are ok with your work potentially been flushed out anytime because we are low on silo for things to release, it's ok
[15:36] <didrocks> Saviq: we can do that as well, but you'll loose even more work than bfiller's I guess ^
[15:37] <bfiller> didrocks: ok, my hope is it will all work very quickly and can be released in the next image :)
[15:37] <bfiller> but understood
[15:37] <didrocks> bfiller: next image == after next promoted image, right? :)
[15:37] <bfiller> yup
[15:37] <kenvandine> didrocks, we've been testing from a ppa while waiting for a silo, so hopefully no surprises
[15:37] <didrocks> bfiller: ok then
[15:37] <didrocks> sil2100: mind doing? (with that ocmming)
[15:37] <didrocks> comment*
[15:37] <Saviq> didrocks, I don't really think that's a problem for us
[15:37] <didrocks> Saviq: to be potentially flushed out?
[15:37] <Saviq> didrocks, it's not like getting a silo is a lot of work
[15:37] <Saviq> didrocks, yeah
[15:38] <Saviq> didrocks, the row in Pending will still be there
[15:38] <didrocks> Saviq: yeah, but building Mir in the right order due to ABI breakage is, right?
[15:38] <Saviq> didrocks, sure, assuming there is a breakage, which I don't know yet
[15:38] <didrocks> Saviq: well, you'll figure out I guess :)
[15:38] <sil2100> didrocks: ok
[15:38] <didrocks> sil2100: maybe we should do that as well ^
[15:39] <Saviq> didrocks, truth be told once the silo is there I can transition to some other PPA
[15:39] <didrocks> assign, be ready to be flushed guys!
[15:39] <Saviq> didrocks, in case we need to flush
[15:39] <didrocks> yeah
[15:39] <Saviq> didrocks, I don't expect to rebuild all that often
[15:39] <sil2100> didrocks, Saviq, bfiller: I'll mention in the comment for other landers that these silos are candidates for flushing if we're really low on silos if you don't mind ;)
[15:39] <Saviq> didrocks, can we get one for right-edge, too? ;D
[15:39] <didrocks> sil2100: yeah :)
[15:39] <Saviq> sil2100, great
[15:40] <didrocks> Saviq: hum… we are really really low, don't push too much :p
[15:40] <didrocks> < 3 silos isn't ok
[15:40] <Saviq> didrocks, hence the ;
[15:40] <didrocks> we have 4 regression :p
[15:40] <Saviq> didrocks, so 3 is the limit? /me only has 1 atm ;)
[15:40] <didrocks> Saviq: no, 3 remaining
[15:40] <Saviq> didrocks, sorry, j/k
[15:40] <Saviq> didrocks, ah
[15:41] <didrocks> see cell G1 :p
[15:41] <Saviq> didrocks, really, I don't want to push, just the fact that this thing touches so many projects makes it a chore to do manually
[15:41] <Saviq> I mean the split one
[15:41] <Saviq> not right-edge, that can wait
[15:42] <didrocks> yeah, let's assign the split
[15:42] <didrocks> sil2100: ^
[15:43] <sil2100> didrocks: sure, I was just reviewing a packaging change, since there's something I don't like
[15:44] <sil2100> didrocks: http://<IP_ADDRESS>/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-download-manager_0.3+14.04.20140320-0ubuntu1.diff <- I don't like how the new qtdeclarative5-ubuntu-download-manager0.1 has a dep on qtdeclarative5-dev, seems invalid
[15:44] <sil2100> mandel: ^
[15:44] <mandel> gatox_lunch, ^^^
[15:44] <sil2100> mandel: do you know why a dev package, qtdeclarative5-dev, is needed to use qtdeclarative5-ubuntu-download-manager0.1 ?
[15:45] <didrocks> sil2100: yeah, it should be invalid
[15:45] <mandel> sil2100, no idea, we need to ask gatox_lunch
[15:45] <sil2100> mandel: sorry that 001 is blocked again ;)
[15:46] <mandel> sil2100, sure, better to be blocked than sorry, we can ask diego and tell him to fix it
[15:47] <cjwatson> what should I do about history-service and telephony-service?  I really want to unblock messaging-app ASAP, the fixes exist but they're in branches with other stuff in them, and boiko seems to be away
[15:47] <cjwatson> should I cherry-pick them onto fresh branches that just fix the build failures, and get that set into a silo?
[15:48] <cjwatson> or should I wait for boiko to get back?
[15:48] <sil2100> cjwatson: I would say that's the right way to go, as we might not be able to land the branches that boiko has prepared anyway, as they might have some other risky changes in them
[15:48] <sil2100> didrocks: wdyt? ^
[15:48] <cjwatson> yeah, one is called "conf_call", I don't think it's trivial
[15:50] <sil2100> bfiller: I'll prepare a silo for you in the meantime, just remember about the flushing when low on silos until we are promoted again
[15:52] <sil2100> bfiller: can I assign a silo or are you modifying the MR list right now?
[15:52] <bfiller> sil2100: think we're good
[15:53] <sil2100> bfiller: you can m&c some silos in the meantime if you have a spare moment ;)
[15:53] <bfiller> sil2100: sure, looking
[15:55] <bfiller> sil2100: m+c on two of them. line 14 says needs ack for packaging changes still so I didn't do that one
[15:56] <sil2100> bfiller: ah, I'll assign in a moment, as gallery-app still didn't migrate
[15:56] <sil2100> bfiller: yeah, mis-click from my side ;/
[15:56] <sil2100> It should be merge-and-clickable in a moment
[15:56] <sil2100> ETOOMANY
[16:02] <sil2100> Saviq, didrocks: unity8 and a few projects are already allocated in different silos
[16:03] <sil2100> didrocks: should I ignore-conflicts? Or I shouldn't push that?
[16:05] <didrocks> well, don't check with me, but with upstream I guess :)
[16:07] <sil2100> didrocks: I didn't want to use this feature 'just like that' without consulting with you, as it's to be used only on priority things ;)
[16:07] <didrocks> sil2100: if you asssess it's priority…
[16:09] <Saviq> didrocks, you slytherin?
[16:10] <didrocks> Saviq: tssssssss
[16:10] <didrocks> ah maybe :p
[16:11] <Saviq> sil2100, I know it probably doesn't work that way
[16:11] <Saviq> sil2100, but ideally the projects put into that silo would not get locked
[16:11] <Saviq> sil2100, it would be our responsibility to reconcile
[16:11] <boiko> cjwatson: back
[16:14] <sil2100> Saviq: I'll ignore-conflicts, but mention that you'll have to rebuild and retest if the other silos get free
[16:15] <Saviq> sil2100, yes, of course
[16:19] <sil2100> Saviq: silo assigned, with the proper warning
[16:21] <Saviq> sil2100, thanks!
[16:22] <Saviq> kgunn, mterry, so we decided there is ABI breakage?
[16:22] <gatox_lunch> mandel, sil2100 that seems to be a left over that was to be used to add some ui components to the download manager, but it's not there yet, so removing the dependcy
[16:23] <sil2100> gatox, mandel: ok, once it's in the branch, please rebuild and we'll retry publishing
[16:23]  * sil2100 prepares for practice
[16:23] <gatox> mandel, sil2100 removed
[16:23] <gatox> and pushed
[16:24] <sil2100> gatox: thanks!
[16:57] <psivaa> ogra_: i've made the jenkins job config change to install/remove the dep. pkges just before/after the tests now after doing a full a mako run. This should fix the messaging app test failures on manta and flo
[16:57]  * ogra_ hugs psivaa
[17:00] <psivaa> ogra_: although, it could point that ofono-phonesim-autostart could have some issues when rebooting the phablet devices. not really sure
[17:00] <ogra_> we'll see, the test results for messaging can hardly get worse on the tablets :)
[17:01] <psivaa> ogra_: ack, the latest runs succeeded when we actually install messaging-app-autopilot and run the tests straight away
[17:01] <ogra_> perfect !
[17:02] <didrocks> kgunn: coming?
[17:02] <didrocks> kgunn: as you have an item for Mir (qt event loop)
[17:02] <kgunn> didrocks: not today...i'm double booked
[17:04] <kgunn> didrocks: i think you're a little quick on the mir trigger for qt event loop right ?....not convinced mir has a play here...or have i missed more  info ?
[17:06] <didrocks> kgunn: Saviq: can you update the bug with your infos?
[17:06] <didrocks> infos
[17:06] <didrocks> info*
[17:07] <didrocks> from what I know we were waiting on a Mir patch
[17:07] <Saviq> didrocks, am building now
[17:07] <Saviq> didrocks, but that wasn't to fix
[17:07] <Saviq> didrocks, but to test the theory
[17:08] <Saviq> didrocks, I confirmed that the bug is between images 237 and 238, so Qt 5.2
[17:08] <Saviq> i.e. http://people.canonical.com/~ogra/touch-image-stats/238.changes
[17:14] <imgbot> [17:17] <Saviq> didrocks, q: so if I need no-change rebuilds of stuff due to abi break, what do I do in CI train?
[17:18] <didrocks> Saviq: empty MP
[17:18] <Saviq> didrocks, ok, so the "additional source packages" are only for you knowledgeable people?
[17:19] <didrocks> Saviq: for direct upload to the ppa
[17:19] <Saviq> didrocks, right, which I can't do, understood!
[17:21] <cyphermox> didrocks: robru: so, messaging-app is wiating for telephony-service on arm64, powerpc, and ppc64el; which is ftbfs on powerpc and depwait on the others
[17:21] <robru> cyphermox, what can we do?
[17:22] <cyphermox> robru: either 1) unblock it explicitly, which I would like to not do if we can fix the issue, or 2) go through the deps to unbreak stuff
[17:22] <cyphermox> I'm looking into 2, to figure out what needs to be unbroken
[17:23] <cyphermox> so telephony-service needs libusermetrics on arm64 and ppc64el...
[17:23] <robru> cyphermox, yeah, i like 2 too, but no clue
[17:23] <cyphermox> and that's depwait waiting for valgrind
[17:23] <robru> cyphermox, its depwaits all the way down ;-)
[17:24] <cyphermox> valgrind just isn't being built for these arches for whatever reason
[17:24] <cyphermox> I did try to start it in sbuild but I don; t remember the result
[17:25] <cyphermox> robru: didrocks: I'll look at that, if it's worthwhile, but perhaps we should just unblock it for now ^
[17:26] <robru> cyphermox, last time i hit this issue, instead of hard-coding arches, I just added a build-dep that was also arch-limited, and then it got unblocked through -proposed
[17:26] <didrocks> cyphermox: thanks
[17:27] <cyphermox> robru: ideally we might actually want to try to build everything on all arches, if it's not actually impossible for reasonable reasons
[17:30] <cyphermox> didrocks: I'll unblock messaging-app fi you're okay with my assessment
[17:30] <rsalveti> didrocks: bug 1295266
[17:30] <robru> cyphermox, ok, something came up for me, I need to run to the store urgently. will be back within 30 min
[17:30] <cyphermox> ok
[17:31] <didrocks> rsalveti: do you think it's a blocker?
[17:32] <rsalveti> didrocks: probably not as it seems I was the only one that got the crash
[17:32] <didrocks> rsalveti: I think it's something to keep on the radar
[17:32] <didrocks> yeah
[17:32] <rsalveti> but still good to track
[17:32] <didrocks> rsalveti: well, I won a new tab I guess :p
[17:32] <rsalveti> ;-)
[17:34] <didrocks> cyphermox: sure
[17:34] <didrocks> cyphermox: I know that cjwatson did some valgrind hacking where it's not available on all archs
[17:39] <Laney> https://code.launchpad.net/~cjwatson/libusermetrics/valgrind-optional/+merge/211563
[17:39] <Laney> you should get that in
[17:40] <cyphermox> yeah
[17:43] <cjwatson> cyphermox: so this is all in scrollback
[17:44] <cjwatson> cyphermox: there's that libusermetrics change Laney just linked to, and there are two commits from boiko in other history-service and telephony-service branches which IMO ought to be pulled out and landed separately
[17:44] <cjwatson> boiko: ^- do you agree with that?  If so could you please prepare appropriate branches?
[17:44] <cjwatson> boiko: or do you want me to?
[17:50] <cyphermox> yeah let's land those
[17:51] <boiko> cjohnston: bill just sent a mail to didrocks and sil2100 about that
[17:51] <boiko> cjwatson: ^
[17:51] <boiko> cjohnston: sorry
[17:51] <boiko> cjwatson: it is not worth the trouble
[17:52] <boiko> cjwatson: I will just add that messaging-app MR to the silo landing-009 together with the MRs already there and we land when things start moving again
[17:53] <cjwatson> why a messaging-app merge?  that shouldn't be needed to get the existing version in -proposed in
[17:53] <cjwatson> I don't think we should be stacking up more there, we should be trying to keep -proposed as clear as possible
[17:54] <cyphermox> yeah, and make the landing as small and self-contained as possible, there are enough regressions already
[17:55] <cyphermox> cjwatson: should I unblock messaging-app in the meantime or should we keep it as a reminder to fix this stuff?
[17:56] <robru> cyphermox, back, need anything?
[17:56] <cyphermox> robru: not right this moment
[17:56] <boiko> cjwatson: but then we will have to spend even more time solving conflicts on the branches that were already reviewed and tested
[17:56] <sergiusens> cyphermox, or robru can I bother you with a packaging review for lp:ubuntu-push ?
[17:56] <cyphermox> yes
[17:57] <boiko> cyphermox: we were doing small landings, but with the Qt5.2 switch things started piling up, and we can't spend all day long landing one MR at a time
[17:58] <cjwatson> cyphermox: you can't unblock it
[17:58] <cjwatson> I can possibly force it on the understanding that it's being fixed
[17:59] <cjwatson> we definitely shouldn't do robru's proposal of an arch-limited build-dep here though, not when we have a fix in sight
[17:59] <robru> cjwatson, ok
[17:59] <cjwatson> that's sensible when we know it's hard
[18:03] <cjwatson> forced for next run
[18:04] <cjwatson> boiko: ^-
[18:06] <boiko> cjwatson: thanks
[18:08] <jdstrand> I marked the apparmor line in Pending to 'yes' several hours ago. I planned on attending the meeting today, but another meeting ran over
[18:08] <jdstrand> do I need to do anything more to be assigned a silo, or do I need to formally ask?
[18:11] <robru> jdstrand, asking is always best, it gets our attention
[18:11] <jdstrand> ok
[18:11] <jdstrand> may I have a silo?
[18:11] <jdstrand> :)
[18:12] <robru> jdstrand, yep, on it
[18:12] <jdstrand> note-- this silo is not a MP
[18:12] <jdstrand> robru: ^
[18:12] <robru> jdstrand, but there's an MP?
[18:12] <jdstrand> so, right, I'm trying to define our process for apparmor
[18:12] <jdstrand> upstream releases tarballs
[18:13] <jdstrand> and we do source package uploads
[18:13] <jdstrand> I have a branch, apparmor-ubuntu-citrain, that represents what is in the archive now
[18:13] <jdstrand> I then ask people when the prepare a new source package to merge again it (using the contents of the new source)
[18:13] <jdstrand> that we, we can review, add the checklists, etc
[18:14] <jdstrand> the intention being, when I am assigned a silo, I would upload to it (or pocket copy in this case)
[18:14] <jdstrand> and then when we publish, I do the merge manually
[18:14] <jdstrand> perhaps there is a better way?
[18:15] <robru> jdstrand, if you list an MP in the MP list, citrain builds it.
[18:15] <robru> jdstrand, if you want to upload a source package, you need to leave the MP list empty, and list your source package name in the source package name list
[18:15] <jdstrand> ah, so maybe I can just add it to the comments or something if people want to review it
[18:16] <jdstrand> ah!
[18:16]  * jdstrand adjusts
[18:17] <jdstrand> robru: 'Additional source packages to land'?
[18:17] <cyphermox> yeah, you can make it just a souce package to land
[18:17] <jdstrand> I think the word 'Additional' threw me
[18:17] <cyphermox> then we´ ll upload that to the citrain silo ppa
[18:17] <cyphermox> and do testing there before syncing to the archive
[18:17] <robru> cyphermox, well, jdstrand can upload can't he?
[18:18] <jdstrand> note, the package is actually already built in https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages
[18:18] <cyphermox> being a lander yes
[18:18] <jdstrand> we could in theory pocket copy, but if it is easier to upload, that's fine too
[18:18] <cyphermox> nah you could copy too
[18:18] <cyphermox> maybe just make it rebuild the package to be sure
[18:19] <jdstrand> ok
[18:19] <cjwatson> if ubuntu-security-proposed can't build packages fit for the archive then we're all doomed
[18:19]  * jdstrand adds to notes about how to do source package citrain uploads
[18:19] <cjwatson> that's already something we copy to the archive from, isn' tit?
[18:19] <cjwatson> *isn't it
[18:19] <jdstrand> it is
[18:19] <cyphermox> yes
[18:19] <jdstrand> it doesn't have -proposed enabled
[18:19] <cjwatson> so I don't think we should waste builder time on rebuilding it just 'cos
[18:20] <robru> jdstrand, ok sorry, you got silo 8
[18:20] <jdstrand> robru: why are you sorry, that is good news, no?
[18:21] <jdstrand> incidentally, I only ask about the pocket copies cause I don't know how the spreadsheet/process will all cope with a pocket copy
[18:21] <robru> jdstrand, oh, because it should have been done like 10 minutes ago, i just got a little distracted
[18:21] <jdstrand> heh
[18:21] <jdstrand> robru: np! thanks
[18:21] <cyphermox> jdstrand: it won't matter really
[18:21] <robru> jdstrand, you're welcome
[18:21] <jdstrand> so, shall I do the binary copy then?
[18:21] <cyphermox> sure
[18:21] <jdstrand> here goes nothing! :)
[18:21] <cyphermox> :)
[18:22] <cyphermox> so we're just using this for testing the package really
[18:22] <jdstrand> yes
[18:23] <jdstrand> ok, so spreadsheet say 'Silo ready'
[18:23] <jdstrand> I requested the pocket copy
[18:23] <jdstrand> https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/ shows it in there
[18:24] <jdstrand> but the status is pending (that's fine)
[18:24] <cyphermox> yup
[18:24] <imgbot> [18:24] <imgbot> [18:31] <robru> boiko, please clean silo 14
[18:32] <jdstrand> so, I don't need to press the Build button at all with source upload/pocket copy?
[18:32] <jdstrand> I test and when done, mark the box as testing done?
[18:32] <boiko> robru: doing it right now, thanks
[18:33] <robru> boiko, thanks
[18:33] <robru> jdstrand, what you can do is start a build job with the flag WATCH_ONLY, then the spreadsheet will get the right build status from the PPA
[18:45] <seb128> cyphermox, robru, can we get silos for l44&45 (desktop only changes)
[18:46] <jdstrand> robru: ack, thanks
[18:48] <cyphermox> sure
[18:49] <jdstrand> Finished: SUCCESS
[18:49] <jdstrand> \o/
[18:49] <robru> yay!
[18:50] <robru> cyphermox, are you doing seb's silos?
[18:51] <kenvandine> seb128, don't hog the silos, i want one too :)
[18:52] <seb128> kenvandine, 6 available, don't worry
[19:01] <balloons> ping asac; are you going to be around next week?
[19:04] <seb128> cyphermox, robru: ?
[19:05] <robru> seb128, yeah?
[19:05] <seb128> robru, can one of you give me silos? ;-)
[19:05] <robru> seb128, oh i thought cyphermox was doing it. ok, on it
[19:05] <seb128> robru, thank
[19:05] <seb128> s
[19:06] <seb128> robru, seems he's not, which is why I did a new ping ;-)
[19:06] <cyphermox> I was
[19:06] <cyphermox> but please give me the time to log in and stuff
[19:06] <seb128> robru, ^
[19:06] <seb128> cyphermox, sorry, I didn't get that the "sure" was for me
[19:06] <robru> cyphermox, oh, well i just did l44
[19:06] <seb128> one each? l45 for cyphermox ;-)
[19:06] <seb128> robru, thanks
[19:07] <robru> kenvandine, what line do you want a silo for? is it ready?
[19:07] <kenvandine> robru, 22
[19:07] <kenvandine> bfiller_afk, we're ready right?
[19:08] <kenvandine> robru, yes, we're ready
[19:08] <kenvandine> i think it was blocked on gallery getting published
[19:08] <kenvandine> which is done now
[19:11] <robru> bfiller_afk, kenvandine : ok you guys got silo 14. i see bill is afk, want me to hit the build button?
[19:11] <kenvandine> robru, any reason not to build?
[19:11] <kenvandine> :)
[19:11] <robru> kenvandine, nope ;-)
[19:11] <kenvandine> go for it
[19:11] <cyphermox> seb128: 15
[19:11] <kenvandine> thx!
[19:11] <robru> waiting for bill to get back just means testing is delayed
[19:11] <robru> kenvandine, you're welcome
[19:12] <robru> kenvandine, http://<IP_ADDRESS>/job/landing-014-1-build/35/console
[19:15] <seb128> cyphermox, thanks
[19:22] <asac> balloons: from what i can see, yes. why?
[19:22]  * asac likes such open questions :)
[19:23] <balloons> asac, I was hoping to put together a meeting to talk about images, regressions and our landing process :-) Some of what's being raised on the phone mailing list is worthy of discussion
[19:24] <asac> balloons: i surely can go on a call and listen if someone summarizes the points
[19:24] <balloons> to frame it, it's not about the ci-train; rather our considerations for release blockers and our methodology on things
[19:24] <asac> balloons: if you could put together a summary of the key points made
[19:24] <asac> that would help
[19:24] <balloons> asac, perfect.. yes, I have a presentation to share..
[19:25] <asac> i think i got them all
[19:25] <asac> but like to hear them in different words :)
[19:25] <asac> and maybe i missed them
[19:25] <balloons> asac, haha..
[19:26] <ogra_> balloons, oooh +++++
[19:36] <kgunn> robru: sorry if this is repeat, wifi weirdness at the house...could you reconfig silo4 for me ?
[19:37] <thomi> robru: cyphermox: Any idea what the status of landing our autopilot is? Did the image you were waiting for get made OK?
[19:37] <robru> kgunn, no repeat, no problem
[19:37] <robru> thomi, yeah so i can provisionally land it today, but i have to do a lot of my own testing with it
[19:37] <kgunn> no repeat? arg....stupid verizon router
[19:38] <thomi> robru: yay! Please let me know if there's anything I can do to help out. This is pretty critical for us now.
[19:38] <robru> kgunn, i see from here you disconnected briefly
[19:38] <kgunn> thanks...
[19:39] <robru> thomi, just help by writing code that doesn't regress ;-) but seriously I'm just going to enable the silo and do a bunch of testing and as long as we stay 100% green I'll publish it
[19:40] <thomi> robru: "writing code that does not regress"... You *do* know that that's what every programmer on the planet aims to do, right? And *none* of them achieve it 100% of the time. Having said that, we have a test process that takes a long time, to try and catch as many of those regressions as possible :)
[19:40] <robru> thomi, I know, I was kidding :-P
[19:41] <thomi> yeah, I know - sorry , gotta vent sometimes
[19:41] <thomi> I'm kind of fed up with the notion that released regressions are caused by lazieness or lack of skill
[19:41] <thomi> not that you suggested that, mind you
[19:42] <robru> true
[19:48] <t1mp> are clock-app and/or music-app autopilot test flaky in image 249?
[19:57] <robru> t1mp, not that I'm aware of? didn't we just get 100% green in 248?
[20:04] <robru> kenvandine, hrm, just noticed merge conflicts in that build log. if you want to take that branch, resolve the conflict, and push your own branch, I can reconfig the silo with your new branch and rebuild. http://<IP_ADDRESS>/job/landing-014-1-build/35/console
[20:05] <robru> kgunn, ugh, sorry, i only just now noticed that my attempt at reconfiguring your silo failed. let me try that again
[20:06] <kgunn> robru: thanks...i saw, but thot i'd be bugging you :)
[20:06] <robru> kgunn, no please, I'm highly distracted today, i could use some poking when I fall behind on things
[20:07] <robru> (distracted by unimportant things, like squirrels in my birdfeeder and bootstrapping a new laptop I just bought)
[20:07] <robru> kgunn, ok, silo 4 should be good to build now
[20:08] <kgunn> robru: thanks man...damn squirrels
[20:09] <t1mp> robru: I have some failures with packages from a merge request, that's why I'm asking
[20:09] <robru> t1mp, not sure, sorry, i'm not super familiar with those components.
[20:10] <t1mp> robru: http://pastebin.ubuntu.com/7127039/
[20:10] <t1mp> ok
[20:11] <t1mp> I'm testing for this MR - https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/ima-bug1288876/+merge/211330
[20:11] <t1mp> I thought you guys want to get that fix before promoting the image
[20:11] <t1mp> I'm not sure though - is https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1288876 a blocker?
[20:12] <robru> t1mp, i don't believe that's a blocker, at least that's not one of the ones i saw blocking image promotion
[20:12] <robru> t1mp, i'm just in the middle of running unity8 ap tests (loooong), will try clock app shortly
[20:13] <t1mp> robru: I'm running *all* app tests (and uitk and unity8). about 90min in total. When its done I can re-run the ones that failed to see if it is consistent
[20:13] <t1mp> robru: thanks :)
[20:15] <robru> t1mp, no worries
[20:15] <robru> humm, just got a pass on unity8 but now the device seems frozen. not responding to touch
[20:18] <kgunn> robru: hey that build in silo 4 just failed....strangely to me anyway
[20:18] <kgunn> can you take a peak
[20:18] <kgunn> or peek
[20:19] <kgunn> seems it wanted a src package it can't find to match the debian ver #
[20:19] <robru> kgunn, is this the first citrain landing of ubuntu-touch-session? it seems like the packaging is wrnog
[20:19] <kgunn> robru: it might be
[20:21] <robru> kgunn, ugh, native package... hm
[20:31] <robru> kgunn, https://code.launchpad.net/~robru/session-manager-touch/packaging/+merge/212047 ok, so this would be my recommendation for packaging changes to get session-manager-touch through the ci train
[20:32] <kgunn> robru: ok, do i just need to add that mp ?
[20:32] <kgunn> to the list of mp's or does it have to land first or something
[20:32] <robru> kgunn, well, it needs some input
[20:33] <robru> kgunn, because I'm changing it from a native package to a split one, that's somewhat controversial. also I renamed the source package name, people are going to be ruffled by that. so we need to identify the stakeholders and see what they say
[20:36] <kgunn> robru: ok...so this silo is really only for testing...not landing...can i add that mp in the meantime ?
[20:36] <robru> kgunn, oh, sure. just add it to the start of the list before reconfiguring
[20:37] <robru> ogra_, I guess you are the most relevant person to review: https://code.launchpad.net/~robru/session-manager-touch/packaging/+merge/212047 please don't hate me ;-)
[20:39] <robru> t1mp, yeah i just got one failure in clock app...
[20:40] <robru> mine's different though
[20:54] <kgunn> t1
[20:54] <t1mp> robru: I got two, see https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/ima-bug1288876/+merge/211330/comments/500843
[20:54] <t1mp> it has a link to the full logs
[20:56] <robru> t1mp, sorry, forgot to paste mine, let me dig it from my terminal scrollbar
[20:57] <robru> t1mp, here's my failure: http://paste.ubuntu.com/7127287/
[20:57] <robru> t1mp, totally different tests. seems flaky i guess. i only ran it once -- did you retry yet?
[20:58] <t1mp> robru: ah yes, I didn't get clock failure.  I did get clock failures
[21:06] <t1mp> I'm re-running the wrong tests..
[21:07]  * t1mp re-queued the clock tests
[21:12] <robru> kgunn, hmmm
[21:13] <robru> kgunn, i don't see my MP in that build log...
[21:14] <robru> kgunn, oh, your reconfig failed. let me redo it
[21:18] <t1mp> robru: I'm running clock tests again. they fail somewhere else now
[21:19] <robru> t1mp, well that seems quite flaky then
[21:19] <robru> t1mp, i'm running other stuff (because I'm testing autopilot itself) and it seems fine elsewhere. i'll rerun clock app in a bit
[21:22] <t1mp> robru: it is long past EOD time for me so I step out now. I linked all the logs with clock-app failures here https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/ima-bug1288876/+merge/211330
[21:22] <robru> t1mp, ok cool. good night!
[21:23] <t1mp> robru: let me know if you report a bug for clock-app tests, I'll read it tomorrow. Otherwise I can report it tomorrow
[21:23]  * t1mp off
[21:42] <robru> thomi, so I've been testing autopilot for like, 3 hours. it's looking really good. I expect to publish it in an hour or so
[21:42] <thomi> robru: wooo! that's great news, thanks
[21:43] <robru> thomi, you're welcome
[22:03] <plars> robru: cyphermox: looks like 249 is still running, not much to report so far except that calendar-app appears to have 2 errors on mako
[22:04] <cyphermox> robru: didn't we assign 46 and 47 before? I thought we had?
[22:04] <robru> plars, thanks
[22:04] <cyphermox> plars: thanks
[22:04] <robru> cyphermox, nah you're thinking of 45 and 44
[22:04] <cyphermox> alright
[22:04] <cyphermox> well, I'll take care of them now
[22:04] <cyphermox> I added l48, which is more indicator stuff
[22:07] <veebers> robru: will the up-coming TRAINCON-0 affect assigning silos? i.e. I'll want to grab one today for autopilot release+1 so I can hit it in my morning next week
[22:10] <robru> veebers, ehhhhhh.. in theory "no" but if there's lots of blocked landings there might be a silo shortage
[22:15] <veebers> robru: ack, thanks
[22:17] <robru> veebers, i'll try to assign your next silo as soon as we complete the publishing of the current one
[22:20] <veebers> robru: awesome, thank you
[22:22] <robru> veebers, are the MPs listed in the sheet already?
[22:23] <veebers> robru: not yet. I'm getting things together and sorting out any merge conflicts
[22:23] <robru> veebers, ok cool.
[22:23] <veebers> robru: I'll have something soon (as we can partly reconfigure silos ourselves now, right?)
[22:25] <robru> veebers, you can reconfigure yourself as long as you don't add any new packages. but don't reconfig 3 or we'll have to retest the whole thing
[22:26] <veebers> robru: ack, I'm not going to touch 3 ^_^
[22:35] <jdstrand> robru: apparmor testing completed and good. ok for me to publish? I assume I just need ACK_PACKAGING
[22:36] <robru> jdstrand, uhhh... how big of a change is this? do you promise no regressions? ;-)
[22:37] <jdstrand> it is a new upstream release. it is heavily tested on touch, desktop and server. FFe discussion happened with infinity. it is good
[22:37] <robru> jdstrand, ok, publish away then.
[22:39] <jdstrand> thanks
[22:39] <jdstrand> merge and clean should be ONLY_FREE_SILO cause of the source package upload/pocket copy, correct?
[22:39] <jdstrand> robru: ^
[22:40] <robru> jdstrand, hmm, i don't think so. just run merge & clean like normal, it won't merge anything because it has no MPs. should be fine
[22:40] <jdstrand> ok
[22:41] <robru> brb
[22:42] <robru> back
[22:53] <robru> thomi, veebers: cyphermox and I are a little concerned about the diff for upstart-app-launch. it looks like some zeitgeist-core stuff got reverted. Is that intentional, or a mistake?
[22:53] <thomi> robru: what? no!
[22:53] <thomi> robru: my branch changes two lines only
[22:54] <robru> thomi, http://<IP_ADDRESS>/job/landing-003-2-publish/51/artifact/packaging_changes_upstart-app-launch_0.3+14.04.20140318-0ubuntu1.diff sounds like a mistake then ;-)
[22:54] <thomi> just changes the name of the nev var that's set from QT_TESTABILITY -> QT_LOAD_TESTABILITY
[22:54] <thomi> robru: yes, I didn't do that!
[22:54] <thomi> robru: this is my MP: https://code.launchpad.net/~thomir/upstart-app-launch/trunk-fix-env-var/+merge/208716
[22:55] <robru> cyphermox, ohhh, i think I see what's happening. the revert is 0ubuntu3, so it would have been a manual distro upload that wasn't in trunk. that's why it got lost in the silo
[22:55] <cyphermox> well, you're missing 0ubuntu2 and 0ubuntu3
[22:55] <cyphermox> for this change: https://launchpad.net/ubuntu/+source/upstart-app-launch/0.3+14.04.20140220-0ubuntu3
[22:56] <robru> cyphermox, yeah, whoever did those didn't bother to sync trunk.
[22:56] <cyphermox> which also shows up in the diff, and I kind of agree with xnox's change
[22:56]  * thomi is totally lost :)
[22:56] <cyphermox> I would rather not land this as it is, it's wrong to revert changelog like this
[22:57] <robru> thomi, sorry, basicaly xnox uploaded some changes direct to distro (short-circuiting citrain) and now citrain is really confused. it thinks you want to undo those changes. but you don't. so we need to re-sync
[22:57] <cyphermox> thomi: so basically, what you'd need to do is take the diffs from 0ubuntu2 and 0ubuntu3 and apply them in the merge request or however else, on the branch, so as to be in sync with twhat's in the archive
[22:57] <robru> cyphermox, yes you're right, we just need to resync
[22:57] <thomi> robru: do I need to do anything, or will you guys take care of it?
[22:57] <robru> thomi, i can take care of it if you're not comfortable with this level of debian-fu
[22:57] <thomi> and, as an aside, how come changes are bypassing ci-train?
[22:58] <thomi> robru: thanks, I'll buy you a beer in Malta :)
[22:58] <robru> thomi, well, xnox is being a bad boy. shame on him
[22:58] <robru> thomi, haha, thanks
[22:58] <robru> cyphermox, ok, so other than those accidental reverts, any other concerns? i'll fix that then publish?
[22:59] <cyphermox> pretty much
[22:59] <cyphermox> let me check what 0ubuntu2 is
[23:00] <cyphermox> https://launchpad.net/ubuntu/+source/upstart-app-launch/0.3+14.04.20140220-0ubuntu2
[23:00] <cyphermox> yeah, if you get the diff for both these uploads, then you'd basically have no packaging diff except for a possible changelog entry
[23:00] <kgunn> robru: i started to hit build again for the packcages that didn't show up...was wondering if you were up to something special there ?
[23:01] <kgunn> only the ubuntu-touch-session & mir packages built
[23:01] <kgunn> but not....the many others
[23:01] <robru> kgunn, oh sorry. i wasn't sure what the status of the silo was so I ran a build job to only build the touch-session package. i guess mir built from before.
[23:02] <robru> kgunn, if there's anything missing, by all means, rebuild the silo
[23:02] <kgunn> cool....
[23:02] <cyphermox> eh
[23:24] <robru> thomi, ok, sorry for the delay. i synced distro into trunk and now I'm rebuilding *just* upstart-app-launch (so we don't have to retest autopilot). should be ready to go soon here
[23:32] <thomi> robru: awesome! \o/
[23:35] <kenvandine> robru, i don't know what's up with that merge conflict, i just grabbed his branch and tried merging trunk
[23:36] <kenvandine> says nothing to do
[23:36] <kenvandine> i merged in my 2 branches he prereq'd on and it did something... but no diff
[23:36] <kenvandine> i commited them at lp:~ken-vandine/content-hub/peer_picker_ui
[23:38] <robru> kenvandine, can you push it all to fix_pending_check and i'll rebuild?
[23:45] <robru> kenvandine, oh, just saw "bzr help criss-cross" in the log. never saw that before. bzr kinda sucks at merging it seems
[23:46] <kenvandine> robru, so i merged that into my quiet_logging branch
[23:46] <kenvandine> which was built off of peer_picker_ui branch
[23:46] <kenvandine> so you can just remove that branch from the config
[23:46] <robru> kenvandine, oh ok thanks
[23:46] <kenvandine> and i refreshed all the branches based on that
[23:46]  * kenvandine crosses fingers
[23:46] <kenvandine> sucks to have so many branches queued up :(
[23:47] <kenvandine> soooo much change
[23:48] <kenvandine> bfiller, ^^ i merged his peer_picker_ui branch into one of mine that was stacked on it and robru is going to reconfigure it
[23:49] <kenvandine> bfiller, hopefully that'll clear it up
[23:49] <robru> kenvandine, bfiller: ok fingers crossed! http://<IP_ADDRESS>/job/landing-014-1-build/37/console
[23:49]  * kenvandine thinks it's beer thirty... goes to get a cold one
[23:49] <kenvandine> robru, thx
[23:53] <robru> kenvandine, lol
[23:53] <robru> you're welcome
[23:59] <bfiller> kenvandine: nice, Elleo and I did the same with peer_picker_ui and peer_details and we got further
[23:59] <bfiller> kenvandine: this criss-cross bzr stuff is a bit of a mystery
[23:59] <kenvandine> yeah
[23:59] <bfiller> kenvandine: we were guessing we'd end up with one big mamoth branch


[09:40] <flxfoo> Hi there,
[09:42] <flxfoo> I have a quick question, I am trying to "upgrade" a apache/zookeeper charm to bionic/focal series. The install hook fails complaining about version of setuptools installed (v39) which does not match >=42 or so... Any idea where to look at to deal with that?


[22:40] <aeden__d> anyone here know much about i2p?
[22:42] <Unit193> Much?  No, but a litt.e
[22:43] <aeden__d> the i2p router console is pretty intimidating. is it a service that runs in the background?