[06:02] <anpok_> robru: you are probably gone.. but that failure is a bit old before sil2100 uploaded the right source packages .. but I guess you already figured it out... and yes the silo is close to being published.. if all goes well
[06:14] <robru> anpok_: OK just make sure you a notify somebody when you're ready because qa won't see it in the state it's in.
=== chihchun_afk is now known as chihchun
[07:44] <sil2100> I'll die from sleep deprivation because of this cat
[08:00] <seb128> bah, ubuntu on the mx4 is a disastear compared to the bq :-/
[08:01] <seb128> it fails to remember the stored wifi password, ask me at each reboot to enter one by adding an increasing number to the ap name
[08:01] <seb128> "ubuntu1" ..."ubuntu6" now
[08:02] <seb128> and when wifi is offline the SIM card fails to work, like the dialer says "offline"
[08:02] <seb128> I though that was mako specific?
[08:02] <seb128> also when connected to wifi it acts as the phone was online, but if I try to call it I get the voicemail, it doesn't even ring
[08:03] <sil2100> uh?
[08:04] <sil2100> I have no issues like these on my mx4 and I use it daily as my main phone, no issues with WiFi or anything
[08:04] <seb128> yeah, what I though as well
[08:04] <sil2100> You on stable? Or rc-proposed?
[08:04] <seb128> I put another sim, I'm not connected to wifi and I've the sim listed as "denied"
[08:04] <seb128> rc-proposed
[08:04] <seb128> r71
[08:05] <sil2100> Ok, might be something from the recent changes, maybe the mission-control upload actually broke something for the arale
[08:05] <sil2100> i.e. the fix for mako broke arale or something - I'm on stable here so I can't check
[08:05] <seb128> I can try reverting a package
[08:05] <seb128> or can I? do we have the old debs somewhere?
[08:06] <jibel> let me check, I didn't have any problem until now.
[08:06] <seb128> we would if we would be used a derivated distro :p
[08:06] <sil2100> Let me fetch the version and name
[08:07] <sil2100> seb128: I can fetch you the .debs if you want :)
[08:08] <jibel> I'm on r71, and I can send call and sms without any data connection. So if there is a problem it is different than mako
[08:09] <seb128> k
[08:10] <sil2100> seb128: give me 5 minutes
[08:12] <jibel> seb128, does a reboot change anything or this behaviour persists?
[08:12] <seb128> jibel, it persists
[08:15] <sil2100> seb128: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+files/telepathy-mission-control-5_5.16.3-1ubuntu1.0_armhf.deb and https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+files/libmission-control-plugins0_5.16.3-1ubuntu1.0_armhf.deb
[08:15] <jibel> sil2100, what changed between 70 and 71?
[08:15] <seb128> I'm unsure it's a regression
[08:15] <sil2100> jibel: looks like a tarball change, let me check which
[08:15] <seb128> I just tried to use that phone with SIM cards for the first time today
[08:15] <seb128> I can go back to the stable version if that helps
[08:16] <sil2100> jibel: wait, no
[08:16] <sil2100> jibel: http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/71.commitlog
[08:16] <sil2100> 69-70 was a tarball change
[08:17] <seb128> syslog has
[08:17] <seb128> Jul 28 10:14:54 ubuntu-phablet powerd[732]: ofono_get_modems_cb: call error
[08:17] <seb128> Jul 28 10:14:55 ubuntu-phablet NetworkManager[1220]: <warn> could not mark modem as powered: org.ofono.Error.Failed Operation failed
[08:18] <jibel> seb128, can you file a bug, attach syslog, the output of /usr/share/ofono/scripts/list-modems and list-contexts
[08:23] <jibel> seb128, what are all the changes in http://people.canonical.com/~ogra/touch-image-stats/vivid/20150727.2.changes ?
[08:24] <seb128> jibel, you want Lucasz right? ;-)
[08:25] <jibel> seb128, yes sorry
[08:25] <seb128> no worry
[08:25] <jibel> sil2100, ^^
[08:25] <jibel> auto-fingers :)
[08:25] <ogra_> seems you are missing a few indicators to actually replace the whole of the UI :P
[08:26] <jibel> sil2100, also why thumbernailer has been reverted in 70 and upgraded in 71?
[08:28] <seb128> jibel, https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1478836
[08:28] <ubot5> Ubuntu bug 1478836 in ofono (Ubuntu) "SIM "refused" on mx4" [Undecided,New]
[08:29] <sil2100> jibel: how reverted?
[08:29] <sil2100> jibel: 71 doesn't upgrade thumbnailer
[08:29] <sil2100> jibel: and 20150727.2 is http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/78.commitlog
[08:29] <jibel> sil2100, from ogra_ 's changelog
[08:29] <sil2100> jibel: it's an image I had to build after I built the mako re-spin
[08:30] <sil2100> Wait, it's http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/77.commitlog
[08:31] <jibel> sil2100, so where does the difference come from between your commitlog and ogra_'s changelog
[08:31] <jibel> ?
[08:31] <jibel> sil2100, his changelog is a diff between the manifests of the rootfs, it should be rather reliable
[08:32] <sil2100> jibel: mine does exactly the same
[08:32] <sil2100> Maybe some bug though
[08:32] <sil2100> I'll check
[08:33] <ogra_> well, checking the two manifests the list is definitely ok
[08:34] <jibel> exactly, unless the manifests are wrong, which is doubtful
[08:34] <ogra_> i got them open side by side, the changelo is correct
[08:35] <sil2100> jibel, ogra_: I see the problem
[08:35] <sil2100> jibel, ogra_: it's not an issue with commitlogs, commitlogs are right in this case
[08:35] <sil2100> 20150727.1 is the rootfs for the OTA-5+ hotfix respin for mako
[08:36] <sil2100> We use the vivid builders for that as this is the only thing we can do
[08:36] <sil2100> So this rootfs never landed in the rc-proposed channel
[08:36] <sil2100> Image 78 is a diff from 20150727 to 20150727.2
[08:36] <ogra_> ah, you went backwards in time with it ?
[08:36] <sil2100> Yes, since it was based off a snapshot
[08:37] <ogra_> yeah, got it
[08:37] <ogra_> that makes sense
[08:37] <sil2100> In this regard the commitlogs are smart since I only do bindings from images in a channel
[08:37] <ogra_> yeah
[08:37] <sil2100> jibel: ^
[08:37] <sil2100> Phew, got me worried there for a moment
[09:16] <jibel> sil2100, it makes sense. Thanks!
[09:26] <sil2100> jibel: did you get the test results for the HERE tarball mako images?
[09:27] <davmor2> sil2100: re running them evanwang had issues
[09:28] <sil2100> I wonder if the previous versions worked at all
[09:28] <sil2100> I have no idea if anyone is using those images, but since they're on stable I supposed yes...
[09:45] <sil2100> jibel, ogra_: let me modify the commitlog format to actually include the rootfs diffs on top, one moment
[09:59] <davmor2> sil2100: could be an issue but I think I know what it is so I'll dig into that and get back to you
[10:28] <doko> sil2100, please can this one be integrated? https://bugs.launchpad.net/ubuntu/+source/address-book-service/+bug/1475591
[10:28] <ubot5> Ubuntu bug 1475591 in address-book-service (Ubuntu) "address-book-service ftbfs with GCC 5" [Critical,In progress]
[10:29] <sil2100> doko: hey! I don't see a landing for it, but the merge seems starightforward - I can upload it to the PPA and make sure it lands in trunk
[10:31] <doko> sil2100, wait, upload to which ppa?
[10:42] <sil2100> doko: to the overlay or to the GCC transition PPA, whichever is more preferred
[10:42] <sil2100> Ah, ok, scratch it, it's for wily
[10:43] <sil2100> doko: forget my overlay-copy proposition, but I could get that to the transition PPA if needed - but I see address-book-app built correctly in silo 16
[10:43] <sil2100> doko: ...ok, ignore me
[10:43] <sil2100> doko: I think I'm just tired, misread the name
[10:43] <sil2100> It's address-book-service, eh
[10:44] <sil2100> doko: anyway, I can get it scheduled for wily landing and get it to the transition PPA, as mentioned
[10:44] <doko> sil2100, right, address-book-service, but it should land into the archive, not the transition ppa
[10:45] <sil2100> Ok then, let me get that prepared
[10:49] <anpok_> trainguards could it be that silo-047 is in a wrong state?
[10:50] <anpok_> that silo only contains a minimally patched systemd (udevd).. and sits there for some time
[10:55] <sil2100> anpok_: let me take a look
[11:04] <sil2100> anpok_: ok, so generally after a manual upload to a PPA, the lander needs to run the build job with 'watch_only' selected
[11:05] <sil2100> anpok_: doing that now
[11:05] <anpok_> oh
[11:05] <sil2100> anpok_: only then the train will notice the package that got uploaded
[11:05] <anpok_> didnt know that
[11:05] <sil2100> The train has no mechanisms to know when a manual upload happened
[11:06] <sil2100> anpok_: we have documentation for this since a week or two: https://wiki.ubuntu.com/citrain/LandingProcess#CI_Train_for_manual_source_uploads
=== chihchun is now known as chihchun_afk
[12:04] <rvr> popey: https://bugs.launchpad.net/music-app/+bug/1478921
[12:04] <ubot5> Ubuntu bug 1478921 in Ubuntu Music App "Toolbar misbehaves in songs page after music is added" [Undecided,New]
=== alan_g is now known as alan_g|lunch
[12:13] <rvr> popey: Looks like a regression, in OTA5 it doesn't happen
[12:15] <popey> rvr: hmm, what happens when you scroll?
[12:15] <popey> does it go away?
[12:15] <popey> Looks like an sdk bug
[12:15] <seb128> mandel, sorry, I saw your bug question earlier, wanted to wrap something up because checking and forgot to get back to you, I think the issue you described is https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1378678
[12:15] <ubot5> Ubuntu bug 1378678 in ubuntu-system-settings (Ubuntu RTM) "updates panel doesn't deal with invalid u1 tokens" [Critical,Confirmed]
[12:15] <popey> rvr: also, can you attach the music app log from .cache/upstart?
[12:15] <rvr> popey: It happens when new tracks are added
[12:16] <popey> rvr: yes, I understand the circumstances which trigger it.
[12:16] <popey> rvr: but after you add tracks, can you scroll up/down, and does it "fix" it?
[12:16] <rvr> popey: When I scroll, the tracks pass below/over the toolbar
[12:16] <rvr> The toolbar becomes transparent and the title is gone
[12:16] <popey> and when you hit the top, it resets?
[12:17] <rvr> Nope
[12:17] <popey> hm, okay, thanks :)
[12:18] <rvr> The toolbar doesn't hide anymore when scrolling
[12:18] <popey> we may have broken the sdk :)
[12:18] <popey> will try and reproduce, thanks :)
[12:19] <popey> but the logs would be handy
[12:19]  * sil2100 off to lunch
[12:21] <rvr> popey: I'll attach them to the bug report
[12:22] <doko> sil2100, could you land https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1475621 ?
[12:22] <ubot5> Ubuntu bug 1475621 in webbrowser-app (Ubuntu) "webbrowser-app ftbfs with GCC 5" [Critical,In progress]
[12:23] <rvr> popey: Done
[12:24] <sil2100> doko: let me prepare that in the silo as well
[12:24] <popey> thanks rvr
[12:25] <sil2100> oSoMoN: I'm preparing a silo with webbrowser and address-book-service gcc-5 fixes, hope you don't mind
[12:26] <sil2100> oSoMoN: webbrowser-app is dual-landed, right?
[12:28] <doko> sil2100, https://bugs.launchpad.net/ubuntu/+source/thumbnailer/+bug/1476738
[12:28] <ubot5> Ubuntu bug 1476738 in thumbnailer (Ubuntu) "thumbnailer ftbfs using GCC 5" [Critical,In progress]
[12:29] <doko> sil2100, https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1452338
[12:29] <ubot5> Ubuntu bug 1452338 in qtmir-gles (Ubuntu) "please drop build-dependency on g++-4.9" [Critical,In progress]
[12:29] <sil2100> doko: on it as well, here I'll need to poke the developers
[12:29] <doko> sil2100, https://bugs.launchpad.net/ubuntu/+source/qtmir-gles/+bug/1452338
[12:30] <doko> sil2100, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1452348
[12:30] <ubot5> Ubuntu bug 1452348 in unity8 (Ubuntu) "please drop build-dependency on g++-4.9" [Critical,In progress]
[12:33] <sil2100> doko: taking care of all of those, if there are any others you have handy that are ready for release, just send me the links
[12:34] <doko> sil2100, you get a list by searching for the tag lsd-cxx11 (although not all of them may be complete)
[12:35] <doko> sil2100, not sure if this one is approved: https://bugs.launchpad.net/ubuntu/+source/qtorganizer5-eds/+bug/1475604
[12:35] <ubot5> Ubuntu bug 1475604 in qtorganizer5-eds (Ubuntu) "qtorganizer5-eds tests fail when built with GCC 5" [Critical,Triaged]
[12:37] <doko> sil2100, https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1475610
[12:37] <ubot5> Ubuntu bug 1475610 in ubuntu-download-manager (Ubuntu) "ubuntu-download-manager tests fail when built with GCC 5" [Critical,Confirmed]
[12:37] <sil2100> doko: ok, on it, I'll release as much as possible
=== _salem is now known as salem_
[12:38] <doko> sil2100, another thing, what would be the process to reserve another silo like 16 ?
[12:40] <sil2100> doko: not much required, I can assign one for you, we have plenty of free ones, we'd only have to ask Steve/Colin to bump the PPA size if it's supposed to have as many packages as this one - what do you need it for?
[12:41] <sil2100> mzanetti: hey!
[12:41] <mzanetti> sil2100, hey ho :)
[12:41] <sil2100> mzanetti: we'd need the gcc fixes branch landed soon - what's the state of silo 18?
[12:41] <doko> sil2100, same as for 16; seb128 wil prepare a bunch of renamed library packages. but if we upload these to silo 16 directly, we would effectively break installability in silo16 for a while
[12:41] <mzanetti> sil2100, silo 35
[12:42] <sil2100> mzanetti: oh, ok, it also has the gcc dep drop branch?
[12:42] <sil2100> mzanetti: will you land it soon?
[12:42] <mzanetti> sil2100, yeah... just didn't yet clean up the other
[12:42] <mzanetti> sil2100, it's approved by me. waiting on QA
[12:42] <sil2100> mzanetti: do you know if the qtmir gcc changes are scheduled to land anywhere? If not, I can include it in my gcc-5 fix silo
[12:43] <mzanetti> greyback_, ^
[12:45] <sil2100> jamesh: hey!
[12:45] <mzanetti> sil2100, in other words, I don't know. please ask gerry when he's around
[12:45] <mzanetti> :)
[12:45] <sil2100> mzanetti: ok :)
[12:45] <sil2100> greyback_: ping
[12:47] <sil2100> jamesh: are you around? I have a question about how your thumbnailer release process looks like
[12:48] <oSoMoN> sil2100, sure, please be my guest (yes, webbrowser-app is dual-landed)
[12:48] <sil2100> oSoMoN: thanks :)
[12:48] <oSoMoN> you’re welcome
[12:52] <sil2100> doko: ok, I'll prepare a silo for you then and once someone with archive powers appears I'll make sure it gets its size bumped
[12:53] <sil2100> Or maybe the bump won't be needed
[12:53] <sil2100> SInce I suppose there won't be as many packages
[12:54] <doko> sil2100, I'll organize the size change
[12:56] <sil2100> doko: silo 39 assigned: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039
[13:03] <anpok_> sil2100: ^hmm
[13:05] <sil2100> uh
[13:05] <sil2100> hmmm, let me look
[13:11] <greyback_> sil2100: hey, I've got them in silo7, you want to steal?
=== alan_g|lunch is now known as alan_g
[13:21] <sil2100> greyback_: do you want to include some additional fixes there? Or could you maybe just land those gcc fixes?
[13:22] <sil2100> btw. qtmir is not dual-landed?
[13:22] <greyback_> sil2100: just want to land gcc fixes.
[13:22] <sil2100> Excellent, then feel free to do that :)
[13:22] <greyback_> sil2100: it is usually, but mir0.14 is in wily, and 0.13 in vivid+overlay, am waiting for silo11 to land before I'm able to dual land again
[13:23] <sil2100> greyback_: ACK
[13:23] <sil2100> Good as long as you have that under control
[13:23] <popey> greyback_: will mir0.14 come to OTA-6?
[13:23] <greyback_> popey: I think so
[13:24] <popey> \o/
[13:25] <ogra_> ... and will everything be faster ?
[13:25] <ogra_> :)
[13:25] <greyback_> 0.01 times faster! :D
[13:26] <ogra_> yay!
[13:32] <sil2100> jamesh: hey, could you ping me once you're around?
[14:00] <mandel> seb128, ok, thx
[14:18] <greyback_> sil2100: hey, I've stupid questions to ask: my wily-ony silo is good to land (after QA happy). I will now need to land same in vivid. Do I create a branch with vivid+overlay's current contents, and another gcc-fix branch to merge into it, and get silo for that?
[14:32] <anpok_> sil2100: could it be that jenkins believes that it has to build xorg-server?
[14:38] <kenvandine> jibel, looks like silos marked as tested aren't getting added to the trello board, isn't that supposed to be automated
[14:40] <jibel> kenvandine, it is automated, which silo?
[14:41] <kenvandine> 17
[14:42]  * kenvandine is anxious to see that land that so we can get back to dual landings in settings
[14:42] <jibel> and 33?
[14:42] <kenvandine> i want 17 to land first
[14:42] <jibel> kenvandine, sometimes bugs happen :) I'll fix it
[14:42] <jibel> unicode error
[14:42] <kenvandine> jibel, thanks!
[14:43] <kenvandine> i have a bunch of autopilot fixes to land so we can start to get passing CI again :)
[14:47] <sil2100> anpok_: so generally this looks like a CI Train error, nothing you should be worried about
[15:03] <sil2100> anpok_: I'll  try to resolve it anyway
[15:29] <greyback_> davmor2: hey, can I get silo7 added to your list for signoff. It's only a build change (removing gcc4.9 hard dependency, but will still build with 4.9)
[15:29] <rvr> abeato: awe_: Approving silo 48
[15:30] <abeato> rvr, great
[15:35] <davmor2> greyback_: the silo ticket just got added to the queue so it should be hit at some point in the near future :)
[15:35] <greyback_> davmor2: thanks
[15:44] <doko> sil2100, thanks
[15:45] <doko> slangasek, seb128: 39 now has 16 as a dependency
[15:46] <seb128> doko, great
[15:46] <seb128> doko, let me know when you have the list of libs
[16:08] <doko> seb128, email sent
[16:09] <seb128> doko, just got it, thanks!
[16:10] <doko> seb128, and the libsigc++ patch is now forwarded to debian
[16:10] <seb128> doko, thanks
[16:14] <doko> seb128, be sure to download source packages from silo16, some already have local changes
[16:14] <seb128> doko, yeah, thanks for the reminder ;-)
[16:42] <kenvandine> cihelp, can someone reconfigure CI for system-settings to run against vivid+overlay instead of wily?
[16:43] <davmor2> greyback_: did you reconfigure silo 007 to be wily ony?
[16:43] <davmor2> greyback_: or was it always
[16:43] <greyback_> davmor2: yes, the contents changed too
[16:54] <davmor2> sil2100: ^
=== alan_g is now known as alan_g|EOD
[17:00] <fginther> kenvandine, I've added it to the list. Should be done by EOD
[17:00] <fginther> or when we get back from lunch :-)
[17:24] <alf_> trainguards: Hi! Can I please get a silo for row 89?
[17:24] <robru> alf_: one sec
[17:26] <robru> alf_: ok silo 30
[17:26] <alf_> robru: great, thank you
[17:28] <robru> alf_: you're welcome
[17:44] <davmor2> robru: silo7 is wily only and can land
[17:44] <robru> davmor2: thanks
[17:44] <anpok_> robru: silo-11 is still in an on state..
[17:45] <davmor2> robru: I don't know if anything needs doing to it to enable that, it was a dual landing so came through to us
[17:47] <greyback_> davmor2: yay, thank you
[17:48] <kenvandine> fginther, thx
[17:48] <robru> anpok_: did you test the packages in silo 11 to confirm they work?
[18:01] <dobey> cihelp: does the cobertura stuff in jenkins support multiple coverage reports in the same build tree?
[18:15] <doko> seb128, updated https://wiki.ubuntu.com/GCC5
[18:17] <seb128> doko, great, I've a script which is working on one example (cairomm), going to test a bit more and start conversion tomorrow
[18:19] <fginther> dobey, the plug claims to support multiple xml report files. I assume it would work.
[18:21] <dobey> fginther: ok, i think there is a bug in our jenkins config then
[18:22] <dobey> + find . -name coverage.xml -exec cp '{}' /var/lib/jenkins/slaves/cloud-worker-04/workspace/unity-scope-snappy-wily-amd64-ci/work/results ';'
[18:22] <dobey> yeah, you can't copy all the coverage.xml files to a single directory :)
[18:24] <fginther> dobey, ah, yeah. That would be a bug
[18:25] <dobey> fginther: is there one open? or should i file a new one?
[18:25] <fginther> dobey, I'll add it as a bug, but don't expect any quick fix.
[18:28] <fginther> dobey, Feel free to add to this: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1479073
[18:28] <ubot5> Ubuntu bug 1479073 in Ubuntu CI Services "Code coverage collection only collects a single file" [Undecided,Confirmed]
[18:29] <dobey> fginther: any way i could expedite a fix? i'm happy to write a bit of shell and propose a branch to make it work, but i'm not quite sure what the cobertura plug-in expects there
[18:32] <fginther> dobey, you can create your own version of the broken hook script in a stand alone bzr branch.
[18:33] <fginther> dobey, the tooling support overriding the default hooks
[18:33] <dobey> fginther: oh, so i can put a hook in my project branch and it will be used?
[18:34] <fginther> dobey, once you have something, we can update the job configuration to use that bzr branch.
[18:34] <fginther> dobey, not quite. Let me find an example
[18:35] <fginther> dobey, here's an example: https://code.launchpad.net/~canonical-ci-engineering/pbuilderjenkins/unity8-hooks
[18:35] <fginther> dobey, a single hook script needed a workaround, so that was done as a one-off all by itself
[18:37] <dobey> ah. that unity8 hook is intesresting too
[18:37] <fginther> dobey, also keep in mind that those pbuilderjenkins ".in" files are templates. The sections in {} are replacement strings.
[18:38] <anpok_> robru: yes
[18:39] <dobey> fginther: where are the contents of the current hook that is copying the coverage.xml file?
[18:40] <fginther> dobey, you can grab them from the binary pbuilderjenkins package from here: https://launchpad.net/~canonical-ci-engineering/+archive/ubuntu/ci-lab
[18:43] <dobey> ok, cool
[18:55] <anpok_> robru: thx
[18:55] <robru> anpok_: you're welcome
[19:27] <fginther> kenvandine, what about "lp:ubuntu-system-settings/15.04"? Does this branch need to still be in CI?
[19:30] <kenvandine> fginther, yes please, just in case we do a vivid only landing
[19:30] <kenvandine> fginther, i'm not ready to abandon that branch yet, but i don't think we'll use it
[19:31] <fginther> kenvandine, ok... And just so we're on the same page, after making this change, there is no branch for wily, correct?
[19:31] <kenvandine> fginther, right
[19:31] <fginther> kenvandine, thanks for confirming
[19:31] <dobey> fginther: do you know where the configuration for our usage of the cobertura plug-in is in a branch or something? or is it deployed via some private thing where other credentials and such are too?
[19:33] <fginther> dobey, there is no credentials or anything private... The only other bit of configuration is stored in lp:cupstream2distro-config to specify the file pattern of the coverage xml files. For example: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/head/snappy.cfg#L21
[19:35] <dobey> fginther: oh ok, so we configure that coverage.xml path per-project?
[19:35] <fginther> dobey, yes
[19:35] <dobey> ok cool
[19:41] <boiko> trainguards: any idea why silo 40 build job failed? it seems ubuntu-touch-session is missing on the ppa
[19:45] <robru> boiko: most likely the upload failed. You'll need somebody like cjwatson to find what the upload failure was, unfortunately Jenkins doesn't get too see it, and i don't have access to the upload rejection mails.
[19:47] <robru> boiko: that's really strange though, the most common cause of that failure is that a higher version is already in the ppa but i don't see any versions at all...
[19:51] <dobey> fginther: good news. i fixed it for you :)
[19:51] <dobey> https://code.launchpad.net/~dobey/pbuilderjenkins/multi-coverage/+merge/266147
[19:51] <fginther> dobey, nice :-)
[19:51] <dobey> https://code.launchpad.net/~dobey/cupstream2distro-config/multi-coverage/+merge/266148
[19:57] <fginther> dobey, So for this, you just care about coverage files with different names and don't care about multiple files named coverage.xml in different source directories?
[19:59] <dobey> fginther: i think this is the path of least resistance (and having them be different names makes it easier to read the reports anyway)
[20:00] <fginther> dobey, ack, just wanted to clarify
[20:00] <fginther> dobey, in that case, just a review request for a changelog entry
[20:01] <dobey> ah ok
[20:02] <dobey> fginther: should i make it be UNRELEASED or wily in my commit?
[20:02] <fginther> dobey, use wily please
[20:02] <dobey> sure thing
[20:03] <dobey> fginther: done and pushed
[20:08] <fginther> dobey, both MPs approved. I'll let you know when it's all deployed.
[20:08] <dobey> fginther: great, thanks!
[20:08] <boiko> robru: do you think rebuilding would fix it or better check with cjwatson before trying it again?
[20:10] <robru> boiko: impossible to say without knowing what the error was. I guess there's not much harm in trying again but i don't expect it to work.
[20:10] <boiko> robru: ok
[20:11] <robru> boiko: wgrant may also be able to investigate the upload, he may be more tz appropriate
[20:11] <boiko> cjwatson: hi, could you please check why the upload of ubuntu-touch-session failed on silo 40?
[20:11] <boiko> wgrant: could you please help me with the above? ^
[20:12] <thomi> boiko: wgrant won't be online for a few hours yet, unless he gets up super early
[20:13] <boiko> thomi: ah ok, thanks for the info
[20:13] <thomi> nw
[20:33] <boiko> robru: anyone else I could ping regarding silo 40? or should I just wait until tomorrow?
[20:34] <sil2100> boiko: hi! I'll be online in an hour probably so I could take a quick look
[20:34] <sil2100> (but only in an hour, still busy with something else)
[20:34] <boiko> sil2100: nice! thanks! I will be off already, but I will leave IRC opened, so just let me know what you find out
[20:35] <robru> sil2100: no he needs the upload rejection from launchpad you don't have access to that
=== blr_ is now known as blr
[20:58] <bregma> trainguards I I would really like to get my landings rolling in lines 76/77/78 if I could get silos or reasons why not....
[20:59] <robru> bregma: you can assign your own silos now
[20:59] <bregma> did an email about that go out to everyone?
[20:59] <robru> bregma: no I've been onboarding people one at a time.
[20:59] <robru> bregma: also this is the first ping i've seen asking for silos for these
[21:00] <bregma> not the first ping I've sent though
[21:00] <robru> bregma: k I missed the other ones, sorry
[21:00] <bregma> that's what you get for living in the land of the sunset
[21:02] <robru> bregma: the self-assigning silo thing is theoretically part of the spreadsheet replacement, except it's live in production ahead of schedule. once the stupid spreadsheet replacement finally goes live (Any. Freaking. Day. Now) I'll send out a big announcement announcing all changes.
[21:02] <bregma> so I just clicky-clicky in the tools menu?
[21:03] <robru> bregma: yep, assign/reconfigure is now one action, pretty streamlined
[21:04]  * bregma sets the thaumaturgical fluids aflow in the fringe-area localizer and adjusts the grappel grommets to just mesh with the filbert flange 
[21:05]  * bregma watches his ping times go through the roof again as his ISP turns it off and then back on again somewhere
[21:10]  * bregma is astounded by the flights of modern technology as he dons his goggles for safety
[21:11] <bregma> this is almost like having fun
[21:13] <robru> bregma: ze goggles! they do nothing!
=== salem_ is now known as _salem
=== karni-away is now known as karni
[23:38] <fginther> dobey, the coverage updates have been deployed