=== chihchun_afk is now known as chihchun
[08:30] <sil2100> Browser restart needed
[08:57] <ogra_> jibel, sil2100 bug 1473898
[08:57] <ubot5> bug 1473898 in ubuntu-system-settings (Ubuntu) "custom channel version in "OS Build Details" shows wrong version info" [Undecided,New] https://launchpad.net/bugs/1473898
[09:06]  * seb128 hits ogra_ with a duplicate bug report sticker
[09:08]  * ogra_ puts on the sticker and wears it with pride
[09:08] <seb128> hehe
[09:09] <seb128> ogra_, joke aside we did discuss that issue on IRC several times, you knew it was reported no?
[09:09] <seb128> oh well, the question in the bug stand
[09:09] <seb128> is s-i providing a (dbus) api we can query to get the info
[09:09] <ogra_> i definitely forgot about it, sorry
[09:09] <seb128> no worry
[09:09] <ogra_> i think it does ... that a barry question though
[09:09] <ogra_> *that's
[09:10] <seb128> http://manpages.ubuntu.com/manpages/vivid/man8/system-image-dbus.8.html
[09:10] <seb128> see        Information() section
[09:11] <seb128> it has build number, device name, channel name
[09:11] <seb128> maybe the  version_detail one?
[09:11] <ogra_> yes
[09:11] <ogra_> but that needs to be parsed
[09:11] <seb128> why can't things be easy? ;-)
[09:11] <ogra_> system-image-clie does that (if you compare ots output with the raw channel.ini content)
[09:12] <ogra_> *-cli
[09:12] <seb128> k
[09:12] <seb128> so 3 options
[09:12] <ogra_> i guess you can steal the parser from there
[09:12] <seb128> 1. we re-do the parsing
[09:12] <ogra_> (or at least a prototype)
[09:12] <seb128> 2. we ask s-i to provide the parsed/formatted info
[09:12] <seb128> 3. we system() call the s-i-cli command
[09:12] <seb128> I like 2. better
[09:13] <ogra_> as long as someone works on 2 :)
[09:13] <seb128> I'm not going to duplicate parsing code
[09:13] <seb128> so if somebody want to see that bug fixed they can nag the s-i team to have 2. implemented
[09:14] <ogra_> seb128, that bug *was* fixed
[09:14] <ogra_> it is a regression
[09:14] <seb128> ?
[09:14] <seb128> I doubt it
[09:14] <ogra_> settings clearly showed the right thing for quite a while
[09:14] <seb128> no it didn't
[09:14] <ogra_> some time last week i noticed that my krillin still shows the right stuff while my arale showeed the 14... number
[09:14] <seb128> that code didn't change since cwayne reported it, which is before vivid
[09:15] <ogra_> and on the weekend i noticed that krillin switched the format too
[09:15] <seb128> k, maybe /custom/build_id has the right thing
[09:15] <seb128> had
[09:15] <ogra_> sure, *it* changed somewhere :)
[09:15] <seb128> yeah, just not on settings
[09:15] <seb128> likely somebody changed the content of those files on disk then
[09:15] <ogra_> could be the way the stamp is created (why we read it is beyond me though(
[09:16] <seb128> we read it because it's the only info we have and it's not documented
[09:16]  * ogra_ only noticed the changes in the UI
[09:16] <seb128> so whoever did the setting code assumed that reading that was better than nothing
[09:16] <ogra_> well, s-i should be our only source for that info
[09:17] <seb128> yeah, but s-i doesn't publish that info
[09:17] <ogra_> it does, you just dont want to parse it :P
[09:17] <ogra_> (which is correct)
[09:18] <seb128> are you sure it does?
[09:18] <seb128> "              · version_detail - A string containing a comma-separated list of
[09:18] <seb128>                 key-value   pairs   providing   additional  component  version
[09:18] <seb128>                 details, e.g. "ubuntu=123,mako=456,custom=789"."
[09:18] <ogra_> yes
[09:18] <seb128> I'm not even sure those pairs contain what you are asking for
[09:18] <ogra_> they do
[09:18] <seb128> and if it does, is the format documented somewhere?
[09:18] <ogra_> look in channel.ini
[09:18] <ogra_> yes, in the system-image docs on the wiki somewhere
[09:19] <ogra_> version_detail: ubuntu=20150710,device=20150709-8965e37,custom=20150709-814-6-40,version=58
[09:19] <ogra_> thats what i have in channel.ini
[09:19] <ogra_> 20150709-814-6-40 is the proper version for the custom tarball
[09:19] <seb128> k, fair enough
[09:24] <Laney> a{sv} anyone?
[09:27] <seb128> you would think...
[09:28] <pete-woods> trainguards: silo plz kthx? :)
[09:34] <sil2100> pete-woods: on it in a min :)
[09:34] <Mirv> pete-woods: I can, if sil2100 takes a min :)
[09:35] <Mirv> pete-woods: silo 046
[09:35] <pete-woods> Mirv: awesome, thanks!
=== chihchun is now known as chihchun_afk
[10:18] <infinity> pstolowski: FWIW, the kernel team's response to this is that we're fools for expecting good usec resolution in the first place. :P
[10:20] <pstolowski> infinity, heh, yeah, I wouldn't expect 1 usec precision even though stat offers tv_nsec, but surely it should be different every second, no?
[10:23] <infinity> pstolowski: So, it gets more interesting.  Apparently, the mtime bumps at HZ resolution, according to Andy's math.  Sometimes, it's spot on, sometimes not quite, depending on platform.
[10:24] <infinity> pstolowski: So, that could be 4 times per second or 10 or whatever, depending on kernel config.
[10:24] <infinity> pstolowski: Anyhow, as I said in my mail, your bug is that you're checking for .tv_nsec, and if it exists, you're using it bare.
[10:24] <infinity> pstolowski: You need to use tv_sec *and* tv_nsec to have any hope of knowing if time progressed.
[10:25] <infinity> pstolowski: Cause it looks like the odds are very real that on a low-res kernel, tv_nsec can actually duplicate from second to second.
[10:25] <pstolowski> infinity, ok. thanks for investigating that! will fix and restest!
[10:46] <infinity> pstolowski: And that has a typo. ;)
[10:46] <infinity> +                    last_write_time_nsec_ = st.st_mtim.tv_nsec;
[10:47] <infinity> +                    last_write_time_nsec_ = st.st_mtim.tv_sec;
[10:47] <pstolowski> infinity, oh jeeez, thanks for keeping an eye on it :/
[10:47] <infinity> pstolowski: I was just curious to see your fix, but you get a review for free out of it.
[11:00] <infinity> pstolowski: Oh, the other thing I'd suggest on top of the code change (which is good), would be to alter the testsuite to sleep for slightly longer than 1s, ie: 1.1
[11:01] <infinity> pstolowski: That would make it more resilient when running on ext3, since a jittery clock can make a system with no subsecond resolution give you the same second before and after a 'sleep 1'.
[11:01] <pstolowski> infinity, good idea, yeah
[11:01] <infinity> pstolowski: A 1.1s sleep would be guaranteed to cross a 1s boundary, unless the system is an Amiga from 1991.
[11:02] <infinity> pstolowski: (it also fixes your nsec timestamps, but that's moot, since you needed to fix your code to actually be sane anyway).
[12:13]  * sil2100 off to lunch
=== _salem is now known as salem_
[13:13] <cwayne> sil2100: heya
[13:20] <sil2100> cwayne: hey!
[13:22] <cwayne> sil2100: question: I've got an update for the euronews scope that's just branding updates, shall I go through the ci-train, or JFDI?
[13:29] <sil2100> cwayne: how do those branding updates look? What's changing?
[13:31] <cwayne> sil2100: just like the scope headers/colors
[13:34] <sil2100> cwayne: I would say this can just go in as it is, but let's double-confirm with jibel
[13:39] <renatu> hey guys I am facing this bug #1461476 on OTA5 image
[13:39] <renatu> this is very critical in my opinion, since my phone never gets locked
[13:39] <renatu> https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1461476
[13:40] <sil2100> jibel, davmor2: ^ ?
[13:42] <davmor2> sil2100: I've not seen that on arale or krillin, renatu is there a way to test for it that doesn't require plugging in a usb lead
[13:43] <pmcgowan> renatu, do you know how you got it in that state?
[13:43] <renatu> pmcgowan, I do not know
[13:44] <sil2100> My arale works fine here
[13:44] <pmcgowan> kgunn, and I were trying to reproduce on vivid last week and could not
[13:44] <renatu> pmcgowan, I remember that I was using a long delay something like 5min
[13:45] <renatu> I updated my phone some few times
[13:45] <renatu> using over the air update
[13:45] <ogra_> renatu, thats a wily bug
[13:45] <renatu> and now it is not working. I try to change to 1 min but still not working
[13:46] <ogra_> wily bugs are generally low prio
[13:46] <pmcgowan> renatu, what does powerd-cli list say
[13:46] <renatu> ogra_, I am using 15.04 r(58)
[13:46] <ogra_> renatu, then i'd file a new bug if i were you
[13:46] <pmcgowan> ogra_, it sounds like the same bug to me
[13:47] <renatu> ogra_, in the bug comments there is more people with the same bug on vivid
[13:47] <ogra_> with over a month apart on twoi different releases ?
[13:47] <ogra_> well, whatever you think :)
[13:47] <pmcgowan> the usc was recently syncd I believe
[13:47] <pmcgowan> renatu, can you run that powerd command
[13:48] <ogra_> ah, into both ?
[13:48] <pmcgowan> need to check with kgunn
[13:48] <renatu> pmcgowan, http://paste.ubuntu.com/11872517/
=== chihchun_afk is now known as chihchun
[13:50] <seb128> ogra_, see what happens when you say it's fine to have bugs in wily ... things get copied later to vivid and then the bug hit users...
[13:50] <pmcgowan> renatu, ok that doesnt tell me anything
[13:50] <ogra_> seb128, i dont say it is fine to have bugs in wily ... i warn people that they are treated lower prio than vivid
[13:51] <ogra_> (and vivid is definitely more important with wily never seeing a real phone )
[13:51] <seb128> right
[13:51] <seb128> I'm just saying that overlooking wily bugs bite us back on vivid
[13:52] <renatu> pmcgowan, anything else that I can use to debug?
[13:52] <ogra_> if the same things land simultaneously ... for sure
[13:52] <pmcgowan> renatu, I am grabbing someone for u-s-c
=== karni is now known as karni-brb
[13:54] <kgunn> pmcgowan: what channel ?
[13:55] <kgunn> pmcgowan: sorry, was otp, i'm about to set a silo up with a potential fix
[13:55] <kgunn> for the screen blank
[13:55] <pmcgowan> kgunn, screen blank?
[13:55] <kgunn> i've discovered at least, fresh flash, just go to setting, change value to something, and it won't blank
[13:56] <pmcgowan> kgunn, is it only on a new flash then?
[13:56] <kgunn> pmcgowan: seems so, somehow it seems to "recover" i presume through punching the powerbutton/user activity
[13:57] <pmcgowan> kgunn, I dont really understand how the MR fixes it
[13:57] <pmcgowan> renatu, was that the first bot after a flash for you?
[13:57] <pmcgowan> boot
[13:57] <renatu> pmcgowan, no
[13:58] <kgunn> pmcgowan: first boot was only in terms of consistency
[13:58] <renatu> pmcgowan, I have rebooted several times
[13:58] <kgunn> i can't claim it truly self heals
[13:58] <kgunn> first boot = first boot after flash
[14:00] <pmcgowan> kgunn, MR says we get invalid dbus events
=== karni-brb is now known as karni
[14:01] <pmcgowan> but why is that happening
[14:02] <alf_> pmcgowan: here
[14:02] <pmcgowan> alf_, thanks, renato is seeing that bug on the ota
[14:02] <pmcgowan> alf_, how can he show its the same issue?
[14:03] <pmcgowan> alf_, and do we know why we get invalid events on dbus?
[14:03] <kgunn> or what's the diff between valid and invalid events
[14:04] <pmcgowan> mzanetti, can we get silos 18 and 35 signed off
[14:04] <mzanetti> pmcgowan, both for OTA-5?
[14:04] <pmcgowan> mzanetti, possibly, debating cracking it to get them in
[14:04] <mzanetti> ack
[14:05] <mzanetti> dobey, hey, about this ^^
[14:05] <mzanetti> are you on QA duty today?
[14:05] <alf_> pmcgowan: kgunn: The events are not invalid per se, perhaps a better word is "uninteresting" for USC. USC is listening for clients disconnecting from dbus, so that if such a client disconnects USC can clear any keep-display-on requests it may have issued and not explicitly cleared.
[14:05] <mzanetti> erm... sorry dobey, I meat davmor2
[14:06] <mzanetti> davmor2, I have two silos, both for unity8, both need QA signoff
[14:06] <mzanetti> davmor2, should I merge them into one?
[14:06] <dobey> oh ok :)
[14:06] <alf_> pmcgowan: kgunn: There was an error in our USC code that retriggered the inactivity timeout when we got such disconnection events from clients that hadn't registered any keep-display-on requests.
[14:06] <davmor2> mzanetti: rvr and I will be hitting silos shortly if he hasn't started already, what's up?
[14:06] <pmcgowan> alf_, any idea why this only happens rarely?
[14:07] <mzanetti> davmor2, so the thing is, we either merge them into one, or we need to QA, land, rebuild the other, QA, land
[14:07] <mzanetti> davmor2, what's your preferred approach?
[14:08] <davmor2> mzanetti: keep them separate, we only open the gates again this morning we were just finishing off the arale testing before moving onto silos,  are these suddenly urgent or something not been following the conversation sorry
[14:08] <mzanetti> davmor2, I think this is for OTA-5 still
[14:09] <alf_> pmcgowan: kgunn: That's what I have managed to reproduce at least... it's about the timing of these events. If e.g. the timeout is 2:00 and such an event comes at 1:50 then the timer is reset for 3:50 etc
[14:09] <jibel> mzanetti, which silos?
[14:09] <mzanetti> jibel, 18 & 35
[14:09] <kgunn> pmcgowan: fwiw, it's not rare 1st boot post flash
[14:09] <kgunn> it's 100% for me
[14:10] <alf_> pmcgowan: kgunn: we could also have a different problem in addition to that one though
[14:10] <jibel> pmcgowan, the lockscreen in landscape lands in OTA5 finally
[14:10] <jibel> ?
[14:10] <alf_> kgunn: which USC version are is included in OTA5?
[14:10] <kgunn> alf_: i'd have to look
=== sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: http://s-jenkin.ubuntu-ci:8080/ needs to be restarted, it's hung. Landing gates still closed
[14:12] <jibel> mzanetti, davmor2 if both must go into OTA5 I'd rather merge them and do only 1 landing.
[14:12] <mzanetti> I'd say too. on it
[14:12] <alf_> kgunn: because I also found a related problem on USC trunk today (https://bugs.launchpad.net/unity-system-compositor/+bug/1473979), but I don't think the offending code has been released in any package
[14:12] <davmor2> jibel: fair enough
[14:13] <kgunn> alf_: unity-system-compositor - 0.0.5+15.04.20150506.1-0ubuntu1
[14:13] <kgunn> that's what's in ppa overlay
[14:13] <seb128> alf_, kgunn, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5077581/+listing-archive-extra
[14:13] <alf_> kgunn: ok, that doesn't have the issue I just mentioned
[14:15] <sil2100> mzanetti: combining sounds nice, assigning
[14:15] <davmor2> mzanetti: so line 77 will be the unified silo for both right?
[14:15] <sil2100> mzanetti: assigned
[14:15] <mzanetti> davmor2, thanks
[14:15] <mzanetti> sil2100, thank
[14:15] <mzanetti> davmor2, yes :D
[14:16] <mzanetti> building
[14:17] <mzanetti> sil2100, I did not reuse the other in case we decide to only include one of them... But I promise I won't request any more silos now and use the current ones up asap
[14:19] <kgunn> alf_: so to be clear, i grabbed
[14:19] <kgunn> https://code.launchpad.net/~afrantzis/unity-system-compositor/fix-1461476-display-off-ubuntu/+merge/264128
[14:19] <kgunn> so we can test in a silo, and land if it solves
[14:20] <dbarth> hi trainguards; i'm trying to get a silo for line 61
[14:20] <kgunn> (i also created a wily silo as well with the other twin of that mp)
[14:20] <dbarth> for reference, we uploaded a new rev. to the debian changelog (recommended by sil2100) to make that compatible with the CI sw
[14:22] <alf_> kgunn: Ack. Which channel are you using to flash the phone (to ensure we are in sync)?
[14:22] <alf_> kgunn: (Since you can reproduce it consistently)
[14:22] <kgunn> alf_: ubuntu-touch/rc-proposed/*
[14:23] <kgunn> any device
[14:24] <alf_> kgunn: and bq-aquaris.en or bq-aquaris.en-proposed?
[14:25] <kgunn> alf_: either...yeah, i think en-proposed just has custom tarball on it
[14:25] <kgunn> extras :)
[14:25] <kgunn> crap
[14:26] <kgunn> oh, it's just the wily one...
[14:26] <alf_> kgunn: yeah, that needs 0.14 mir
[14:27] <kgunn> alf_: ah...duh...you told me that, sorry i'm not coffee'd enough yet
[14:27] <kgunn> alf_: do we want anpok to make it part of mir0.14 ? or just land it later ?
[14:29] <alf_> kgunn: If it can make it into 0.14 then great
[14:29] <alf_> kgunn: I think we have time to pull it in
[15:06] <Mirv> dbarth: landing-052 for line 61
[15:18] <alf_> kgunn: let me know if the fix works or doesn't work for you
[15:19] <popey> sil2100: dbarth anyone reported issues between content hub and webapps?
[15:20] <popey> it impossible to tweet a photo from gallery via. content hub
[15:20] <popey> browser dies during transfer
[15:20] <kgunn> alf_: thanks!
[15:20] <popey> arale rc proposed 58
[15:20] <kgunn> wil do now
[15:25] <sil2100> hm, didn't see that reported
[15:25] <sil2100> davmor2, jibel: did you notice anything like that?
[15:26] <dbarth> popey: on krillin?
[15:27] <dbarth> popey: if you have too many apps opened, the oom killer might have you:/
[15:28] <dbarth> Mirv: thanks!
[15:28] <popey> arale
[15:29] <popey> dbarth: no apps open
[15:29] <ogra_> popey, well, there is that bug from sturmflut about arale memory management being totally off
[15:29] <popey> it is unusable
[15:29] <ogra_> so you might hit oom even if there is plenty of ram
[15:30] <popey> which bug?
[15:33] <davmor2> sil2100: yes it is a failed test
[15:34] <ogra_> popey, if i could fine the # i would have given it here :P
[15:34] <ogra_> *find
[15:34] <popey> dbarth: 5 apparmor denials in twitter
[15:34] <popey> sorry for being terse. on mx4 with no pc
[15:35] <ogra_> popey, bug 1468077
[15:36]  * ogra_ tickles ubot2
[15:37] <cwayne> jibel: hiya, would you like me to submit a scope update to QA first for a simple branding update, or just upload it to the store? sil2100 mentioned uploading it directly is fine but the check with you first :)
[15:40] <popey> ogra_: would i see oom in dmesg?
[15:40] <ogra_> syslog i think
[16:00] <kgunn> pmcgowan: alf's fix is looking good for me
[16:00] <kgunn> u-s-c screen blank
[16:00] <alf_> kgunn: \o/
[16:01] <pmcgowan> cool
[16:01] <kgunn> pmcgowan: do i need to mark that tested? e.g. will we put into ota5 ?
[16:01] <seb128> alf_, why did you say earlier that the vivid version didn't have the issue?
[16:01] <pmcgowan> kgunn, indeed
[16:01] <kgunn> seb128: 2 diff issues....
[16:01] <kgunn> 1 issue exist only in wily
[16:01] <seb128> k
[16:01] <kgunn> the other exsits everywhere
[16:04] <mzanetti> jibel, davmor2: silo 44 is built and tested, ready for qa.
=== chihchun is now known as chihchun_afk
[16:27] <pmcgowan> jibel, davmor2 silo 49 is also ready
=== dpm is now known as dpm-afk
[18:00] <slangasek> robru: meeting?
[18:01] <robru> slangasek: yeah I'm in there...
[18:01] <slangasek> robru: no you aren't ;)
[18:01] <sil2100> We can't see you
[18:01] <robru> slangasek: in landing-meeting? google says I'm the first one
[18:02] <sil2100> landing-team
[18:20] <sil2100> mzanetti: whoops, I blew something up in unity8 trunl
[18:20] <sil2100> *trunk
[18:20] <sil2100> Fixing it now, apologies for that...
[18:23] <mzanetti> sil2100, no worries :)
[18:23] <sil2100> Damn, stupid me...
[18:23] <sil2100> ;/
[18:24] <sil2100> One wrong button press and everything went to hell
[18:24] <mzanetti> hehe, what happened?
[18:25] <mzanetti> sil2100, did you merge a silo instead of discarding it?
[18:26] <sil2100> Yeah, I checked 'force' instead of 'free only'
[18:26] <sil2100> ;)
[18:27]  * sil2100 does a push --overwrite
[18:27]  * mzanetti looks away
[18:27] <davmor2> ssh sssssh it's oh so quiet, it's oh so still, it's oh so lovely....until, BIG BANG CRASH WALLOP sil2100 presses the wrong button
[18:27] <sil2100> mzanetti: could you check in a moment if it looks sane now?
[18:28] <sil2100> davmor2: ;p
[18:29] <mzanetti> sil2100, looks ok. the history is a bit funny. the "Merged branch lp:~aacid/unity8/revert_session_screenshotter" comment seems to be in a LP translation commit instead of albert's one
[18:29] <mzanetti> not sure if that's how the train merges tho
[18:30] <mzanetti> a pull on my previous trunk shows the correct modified files
[18:30] <sil2100> hm, I think it might be just leftover from the previous state
[18:30] <mzanetti> looks we're good
[18:31] <popey> can someone try and play vid on http://pad.lv/1474081
[18:31] <popey> am on poor wifi and dunno if my video worked
[18:32] <mzanetti> "This video is private. "
[18:32] <popey> balls
[18:32] <popey> ta
[18:32] <mzanetti> np
[18:33] <popey> now?
[18:33] <mzanetti> yep, working
[18:33] <popey> ta
[18:36] <robru> brbrunch
[18:47] <davmor2> sil2100: any second now
[18:48] <davmor2> sil2100: ^
[18:48] <davmor2> pmcgowan: ^
[18:48] <pmcgowan> woot
[18:48] <pmcgowan> thanks
[18:52] <sil2100> o/
[18:52] <sil2100> Publishing
[18:53] <sil2100> Forced the publish
[19:26] <pmcgowan> sil2100, building?
[19:26] <davmor2> sil2100, or robru: once the image is built can you please ping ToyKeeper who will carryout testing on it, many thanks
[19:27] <robru> davmor2: hm, doesn't seem there's an imgbot at the moment
[19:27] <robru> sil2100: when are you building the image?
=== bfiller_ is now known as bfiller_afk
[19:30] <pmcgowan> I haven't seen imgbot for some time
[20:06] <ToyKeeper> Hmm, well, I suppose I can just keep checking.
[20:07] <ToyKeeper> I assume it'll be krillin 66 and arale 59?
[20:23] <sil2100> popey, robru: yes
[20:23] <sil2100> It's building, but slow
[20:23] <popey> yes ?
[20:23] <sil2100> uh
[20:23] <sil2100> popey: sorry!
[20:23] <sil2100> I meant pmcgowan ^
[20:23] <sil2100> ;)
[20:23]  * popey goes back to beer
[20:23] <ToyKeeper> All you p<tab>s are the same, right?  ;P
[20:24] <popey> lulz
[20:25]  * pmcgowan wishes for beer
[20:27]  * ogra_ hands pmcgowan a Fucking Hell
[20:27] <pmcgowan> oh my
[20:27] <ogra_> http://www.younilife.com/site-uploads/2014/03/fucking-hell-bear.jpg
[20:28] <ogra_> (from the bavarian city "fucking" ... and its a light beer ... (hell in german))
[20:28] <ogra_> :)
[20:30] <pmcgowan> ogra_, you had me going
[20:31] <popey> i did wonder if ogra_ had lost it
[20:31] <ogra_> lol
[20:31] <ogra_> i only recently learned about that beer :)
[20:31] <popey> but then remembered he lost it years ago
[20:32] <ogra_> lol, so true ...
[20:49] <mzanetti> cihelp: this looks like a temporary issues to me: https://jenkins.qa.ubuntu.com/job/wily-adt-unity-scope-click/ARCH=amd64,label=adt/80/console
[20:50] <mzanetti> cihelp: also only failed on one arch. can we try restarting it for getting silo 44 landed?
[20:52] <cjwatson> mzanetti: can't retry on only one arch there, unfortunately (that'll be fixed by the new infrastructure I believe), but I've kicked off a new build
[20:52] <mzanetti> cjwatson, thanks
[20:53] <fginther> cjwatson, thanks
[23:03] <sil2100> ;/
[23:08] <sil2100> Why is the importer taking so long?
[23:09] <sil2100> It's running all the time
=== salem_ is now known as _salem
[23:23] <sil2100> ogra_, slangasek: is it normal that import-images runs for 2 hours already?
[23:37] <slangasek> sil2100: not normal, but it's not impossible...
[23:38] <slangasek> hmm why is it using xz instead of pxz