[05:10] <robru> yay
[05:10] <michi> what happened?
[05:10] <michi> robru: Do I need to rebuild?
[05:11] <robru> michi: we had a buggy rollout, clobbered the creds which caused jos to hang. fixed it, but all the jobs had to be killed, which updated all the statuses unfortunately. this should settle down over the next 15 miutes..
[05:11] <robru> michi: were you in the middle of a build just now?
[05:11] <michi> So, don’t need to do anything?
[05:11] <michi> No, the build had finished earlier.
[05:11] <robru> michi: it's fine then, sorry for the spam
[05:11] <michi> Works for me :)
[09:14] <jibel> bzoltan_, silo 56 fails to build on powerpc. Is it expected or not?
[09:15] <jibel> are you looking into it?
[09:17] <bzoltan_> jibel:  It is balck magic, sometimes it fails sometimes it does not. The failure if incorrect for sure as the library is there. We are looking at it, but it is not a critical issue in my view. the functionality of the UITKis more relevant
[09:32] <Mirv> let me see if it happens every time
[09:33] <Mirv> but yes they are a bit weird since earlier they were fixed but then it was found out it failed on s390x. then it was fixed even more and it built everywhere, and now once again it complains on another architecture (and only 32-bit version of it) where it used to work. some sort of compiler random order magic must be in play.
[10:56] <sil2100> xavigarcia: piiing
[10:58] <xavigarcia> sil2100: hi there
[10:59] <sil2100> xavigarcia: hey! I was looking at publishing of silo 51 and sadly there are some changelog issues there
[10:59] <sil2100> xavigarcia: I see that in https://code.launchpad.net/~xavi-garcia-mena/indicator-sound/restore-osd-notifications/+merge/281290 you modify the changelog - why is that?
[11:00] <sil2100> xavigarcia: we should never really touch existing history in most cases
[11:00] <xavigarcia> sil2100: mmmm, I can't remember
[11:00] <xavigarcia> sil2100: that was probably when I had to rollback trunk before Xmas
[11:01] <sil2100> xavigarcia: ok, could you maybe remove all the debian/changelog changes from your merges and rebuild indicator-sound? :)
[11:01] <xavigarcia> sil2100: sure
[11:01] <xavigarcia> sil2100: I will ping you when it is ready
[11:01] <sil2100> Since in the current state it's not really publishable, we even have some ugh, strange UNRELEASED versions in the changelog history
[11:01] <sil2100> xavigarcia: thanks!
[11:04] <xavigarcia> sil2100: the changes in this branch.... https://code.launchpad.net/~xavi-garcia-mena/indicator-sound/re-add-integration-tests/+merge/281292 are needed, though
[11:04] <xavigarcia> sil2100: is there a problem as they are?
[11:05] <sil2100> xavigarcia: hmmm, why can't those be put in the commit message instead?
[11:06] <sil2100> xavigarcia: so generally there should be no problem for having this debian/changelog modification there, but...
[11:07] <xavigarcia> sil2100: I can't remember who it was, but I was asked to add those lines to the changelog
[11:07] <sil2100> xavigarcia: since the prerequisite branch has those invalid changelog modification/changes, this branch also carries some wrong bits in it (please notice that the indicator-sound (12.10.2+15.10.20151019-0ubuntu2) UNRELEASED; line is UNRELEASED)
[11:07] <xavigarcia> sil2100: to reflect the new files and so on
[11:08] <sil2100> xavigarcia: so generally you can leave the debian/changelog modification in this branch if you make sure that the old changes from the invalid modifications are gone
[11:08] <xavigarcia> sil2100: okay... so if I modify the prerequisite branch....should it be enough?
[11:08] <sil2100> xavigarcia: hmmm... you can try, depends if you have also merged the prerequisite branch to this branch as well
[11:09] <sil2100> xavigarcia: just make sure that before you rebuild, check the https://code.launchpad.net/~xavi-garcia-mena/indicator-sound/re-add-integration-tests/+merge/281292 merge diff if the previous changelog version visible is released to xenial - if it's UNRELEASED than something went wrong
[11:09] <sil2100> *then
[11:10] <sil2100> Only the newest changelog entry should be UNRELEASED
[11:10] <xavigarcia> sil2100: Ok... will do that
[11:18] <xavigarcia> sil2100: Okay, so I've removed the changes in changelog in the prerequisite branch
[11:18] <xavigarcia> sil2100: but I still see UNRELEASED in https://code.launchpad.net/~xavi-garcia-mena/indicator-sound/re-add-integration-tests/+merge/281292
[11:34] <sil2100> xavigarcia: looking how this looks in reality
[11:35] <sil2100> xavigarcia: ok, I think it should be good, it's just a lag in LP it seems
[11:36] <sil2100> xavigarcia: try re-building :)
[11:36] <xavigarcia> sil2100: well, now I have a conflict
[11:36] <sil2100> Oh, where?
[11:36] <Mirv> tvoss: davmor2: like https://requests.ci-train.ubuntu.com/#/ticket/793 says it needs a rebuild due to burned version number qtubuntu-media/vivid
[11:36] <xavigarcia> sil2100: I did some extra changed
[11:36] <xavigarcia> sil2100: changes
[11:37] <xavigarcia> sil2100: I'm going to roll back to the one you saw
[11:37] <tvoss> Mirv, let me see
[11:37] <tvoss> Mirv, davmor2 should I just trigger a rebuild?
[11:38] <davmor2> tvoss: no idea I have nothing to do with that side, I guess it is because jhodapp uploaded a couple of media-hub fixes and might of bumped up the version number maybe
[11:39] <Mirv> tvoss: so it seems. at the same time the diff:s should get updated too. there was jhodapp's https://requests.ci-train.ubuntu.com/#/ticket/820 that landed yesterday
[11:40] <Mirv> davmor2: missing diff:s on media-hub are not a problem, but a qtubuntu-media landing after the last build in that silo is
[11:45] <tvoss> Mirv, so I just trigger a rebuild, correct?
[11:45] <Mirv> tvoss: correct, but specify qtubuntu-media in the packages to build to make it even smaller re-build
[12:30] <bzoltan_> sil2100: Mirv: is there an information about what packages and what versions are in a certain  image version?
[12:31] <sil2100> bzoltan_: like, all packages in an image?
[12:31] <sil2100> bzoltan_: that would be in image manifests
[12:31] <bzoltan_> sil2100:  yes
[12:31] <bzoltan_> sil2100:  where can i find that?
[12:33] <sil2100> bzoltan_: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-touch/vivid/ - go here, find the rootfsid you're interested in, download the log and there you will find the link to the manifest (confusing, I know)
[12:33] <sil2100> bzoltan_: do you want a specific one? I can help you find it
[12:33] <bzoltan_> sil2100:  flo 88-89 diff i am interested in
[12:33] <sil2100> Ah, the diff
[12:33] <sil2100> bzoltan_: which channel?
[12:34] <bzoltan_> sil2100: ubuntu-touch/rc-proposed/ubuntu-pd
[12:38] <sil2100> bzoltan_: let me quickly grab the diff for you
[12:39] <sil2100> bzoltan_: hm, aparently there are no changes between 88 and 89
[12:39] <sil2100> bzoltan_: the manifests are - 88: https://launchpadlibrarian.net/232434413/livecd.ubuntu-pd.manifest and 89: https://launchpadlibrarian.net/232821809/livecd.ubuntu-pd.manifest
[12:40] <bzoltan_> sil2100: on flo? Wow... black magic - https://bugs.launchpad.net/ubuntu-rtm/+source/ubuntu-ui-toolkit/+bug/1530938
[12:40] <ubot5`> Launchpad bug 1530938 in ubuntu-ui-toolkit (Ubuntu RTM) "header navigation broken on flo" [High,New]
[12:40] <sil2100> uh oh
[12:41] <sil2100> Yeah, but as you can see, manifests are the same and it actually makes sense since most people were out-of-office then
[12:41] <sil2100> The touch images also didn't have any changes
[12:42] <bzoltan_> sil2100: as expected
[12:42] <sil2100> Device and custom tarballs are intact
[12:42] <sil2100> So hm, maybe actually the whole 'reflashing' fixed the bug?
[12:43] <bzoltan_> sil2100:  how is that possible?
[12:46] <oSoMoN> trainguards: can I please haz a silo for https://requests.ci-train.ubuntu.com/#/ticket/834 ?
[12:50] <Mirv> oSoMoN: why wouldn't you assign it yourself, the safety limit shouldn't be hit?
[12:56] <oSoMoN> Mirv, I tried, but got a message saying the number of free silos is too low
[12:56] <oSoMoN> (should I try again?)
[12:56] <Mirv> hmm
[12:57] <Mirv> robru: the free silos limit shouldn't be as low as 52? yet it failed https://ci-train.ubuntu.com/job/prepare-silo/77/console
[12:57] <Mirv> robru: oh, it says to me "No silos are available.". there's a glitch in the matrix.
[12:58] <Mirv> oSoMoN: so no luck either from my side unfortunately. there are probably some ghosts haunting somewhere, meanwhile we'll need to wait for some silo to free up.
[12:58] <Mirv> well, I can free one of mine
[12:58] <oSoMoN> ok :(
[12:58] <Mirv> since I'll follow it anyway
[12:59] <Mirv> oSoMoN: no luck even that way. I freed up one silo and it still complains to me :(
[13:00] <sil2100> uuuuu
[13:00] <Mirv> help!
[13:00] <Mirv> sil2100: any idea, or should we just wait for robru?
[13:00] <Mirv> debug run doesn't give any mor einsight
[13:00] <sil2100> Let me take a look
[13:00] <xavigarcia> sil2100: hi there
[13:00] <xavigarcia> sil2100: the silo is built again
[13:01] <xavigarcia> sil2100: could you please check if now looks better?
[13:01] <sil2100> xavigarcia: \o/ any changes besides the changelog?
[13:01] <xavigarcia> sil2100: none
[13:01] <xavigarcia> sil2100: just the changelog
[13:01] <sil2100> xavigarcia: will take a look in a moment, thanks!
[13:02] <xavigarcia> sil2100: thanks
[13:07] <Mirv> tvoss: you didn't run the silo 22 rebuild, I did it now
[13:09] <Mirv> it seems jhodapp had tried to run the rebuild but the job execution had failed since force was not specified and the branch itself didn't have changes
[13:10] <tvoss> Mirv, ack
[13:10] <tvoss> Mirv, and thx :)
[13:10] <Mirv> davmor2: the silo 058 is vivid only landing
[13:14] <sil2100> Mirv: not sure if you got my previous message:
[13:14] <sil2100> Mirv: strange thing, the train doesn't even look for available silos from what I see - but the silo list is properly initialized
[13:22] <davmor2> Mirv: you say that but it doesn't work on vivid, which takes us back to what is it's point :)
[13:30] <Mirv> sil2100: no, that went to /dev/null apparently. ok then.
[13:30] <Mirv> davmor2: yes, it doesn't change the end result :)
[13:32] <Mirv> davmor2: tvoss: on another note, 022 rebuild now done and re-put into QA quque
[13:38] <sil2100> xavigarcia: hmmm
[13:39] <sil2100> xavigarcia: so I checked the silo again and hmmm... so, looks ok, but you removed the changelog modification from the re-add-integration-tests branch in the end?
[13:41] <xavigarcia> sil2100: yeah
[13:41] <xavigarcia> sil2100: it was getting mad
[13:42] <sil2100> xavigarcia: and the merge conflict on LP worries me, but if everything merges correctly when building then it's fine I guess - but I'm just wondering if you removed the big changelog entry with file mentions etc. by accident or planned
[13:42] <xavigarcia> sil2100: it was planned... as there were lots con conflicts with the pre-requisite branches
[13:42] <sil2100> You could have just included all that in the commit message, the train should have just fetched all that and pasted it
[13:42] <sil2100> I mean, *should*, since in theory it shouldn't break anything
[13:43] <xavigarcia> sil2100: you mean the LP commit message or when committing the code?
[13:43] <xavigarcia> sil2100: I can add that in the comment in the MP
[13:43] <sil2100> LP merge commit message, the train always uses that for generating the changelog
[13:43] <xavigarcia> sil2100: ok... will do that then
[13:43] <xavigarcia> sil2100: one sec
[13:43] <sil2100> I mean, we can stick with what we want if the small changelog entry is enough, but I suppose it's a big branch
[13:43] <sil2100> So we might want to be more verbose on what appened
[13:44] <sil2100> *happened
[13:44] <sil2100> Fingers crossed that the train won't mangle it and break the formatting tho...
[13:51] <xavigarcia> sil2100: OK... I've added the info in both, LP and the repository...
[13:52] <xavigarcia> sil2100: rebuilding... will ping you when it's ready
[13:54] <tvoss> Mirv, great, thx
[14:57] <jibel> Mirv, are we supposed to retest 22?
[15:03] <sil2100> robru: once you're up, could you take a look at the problem with assigning silos? I didn't look into much details, but from the first look the backend situation looks alright - from cyphermox-test I saw 50 silos assigned and in ~/.ci-train-silo-names I saw 61 silos defined
[15:04] <sil2100> robru: from the logs it looks like the train does not even really look for free silos, as I didn't see any logs from the "log_value_of.siloname('Checking if available')" bit
[15:06] <sil2100> xavigarcia: hmmm, ok, rebuilding your silo, it seems we need to check the 'TAKE_WHOLE_COMMIT_MESSAGE' field
[15:07] <sil2100> Man, the rebuilds are killing me
[15:11] <xavigarcia> sil2100: ok, thanks!
[15:15] <davmor2> morphis: any second
[15:15] <morphis> davmor2: ?
[15:16] <davmor2> morphis: ^
[15:22] <oSoMoN> trainguards: is the issue with silo assignments fixed?
[15:31] <sil2100> oSoMoN: no... robru will know what's up, he should be around shortly
[15:31] <sil2100> I didn't see anything obvious what could be wrong, and I don't have enough tools to debug that
[15:31] <sil2100> Since it's a closed environment
[15:43] <xavigarcia> sil2100: Hi there, silo 51 is ready again
[15:45] <sil2100> xavigarcia: hey! Ok, so it's built, the changelog got a bit massacred (re-formatted) so it looks a bit ugly
[15:45] <sil2100> But...
[15:45] <sil2100> I suppose this is better
[15:46] <sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-051-1-build/lastBuild/artifact/indicator-sound_xenial_packaging_changes.diff
[15:48] <xavigarcia> sil2100: so... can we land it now?
[15:51] <sil2100> Yeah, I'll do it now ;)
[15:51] <morphis> sil2100: can you push something to a silo for me?
[15:51] <sil2100> morphis: sure
[15:51] <sil2100> :)
[15:51] <morphis> great
[15:57] <Saviq> fginther, hey, think https://launchpad.net/~jenkaas-hackers would be a good place for a jenkaas ML?
[15:58] <fginther> Saviq, yes, I thought there was already one configured
[15:59] <Saviq> fginther, care to join #jenkaas on irc.c.c? :)
[15:59] <fginther> Saviq, perhaps, are you aware that I now work for a different team (landscape)?
[16:00] <dobey> eh, if that team is for people that hack on the thing, then it's not a good place fo ra support ML
[16:00] <Saviq> fginther, sure, doesn't mean you can't help here and there, your call :)
[16:00] <Saviq> fginther, still, you're listed as the owner of ~jenkaas-hackers ;D
[16:00] <dobey> a new team ~jenkaas-users would be better place for a user ML
[16:01] <fginther> Saviq, that's true :-)
[16:01] <Saviq> dobey, don't think they're "hacking on the thing", at least the members list does not suggest that
[16:02] <dobey> Saviq: well, it's got a PPA and owns some branches
[16:03] <dobey> Saviq: so i'd think giving everyone direct commit access to those branches, who wants to join a ML to discuss user issues, is probably not a great plan :)
[16:03] <Saviq> dobey, sure, although it's the users who are the only hackers nowadays
[16:05] <dobey> seems the wrong place for it, to me
[16:25] <oSoMoN> robru, it seems the train is unable to assign silos to new requests, known issue?
[16:25] <oSoMoN> (I need a silo for https://requests.ci-train.ubuntu.com/#/ticket/834)
[16:42] <sil2100> Driving home, will be back in around 1h
[16:45] <Saviq> fginther, so people started requesting adding new folks (and whole teams) to ~jenkaas-hackers, maybe what dobey said makes sense - a lower-impact ~jenkaas-users team+ML could be a safer approach? I understand you might not want to maintain it... in which case a few of the initial users could be nominated as admins, but what happens to ~jenkaas-hackers?
[16:50] <fginther> Saviq, I think that makes sense. The jenkaas-hackers group was setup because the ppas and code needed to be hosted somewhere. A users ML will help keep that separate
[16:50] <fginther> sorry for the slow response, in a meeting
[16:50] <Saviq> fginther, nw
[17:04] <Saviq> fginther, dobey, right, created a private ~jenkaas-users team+ML, owned by pspmteam
[17:46] <davmor2> tvoss, jhodapp: now fight to see who lands theirs first ;)
[18:03] <jhodapp> davmor2, haha
[18:05] <jhodapp> kenvandine, are you up for landing something for me that requires a core dev? :)
[18:05] <kenvandine> jhodapp, sure, link?
[18:05] <jhodapp> kenvandine, https://requests.ci-train.ubuntu.com/#/ticket/812
[18:05] <kenvandine> jhodapp, i'll look at it in a few
[18:05] <jhodapp> kenvandine, sounds great thanks!
[18:07] <kenvandine> jhodapp, interesting, so 5.4 provides 5.6 imports?
[18:08] <kenvandine> i guess there's no harm, just seems odd :)
[18:08] <jhodapp> kenvandine, yes since our 5.4 is a backport of many things...it's to make sure we don't have to have any QML clients do version detection and remain compatible with what's in upstream
[18:08] <kenvandine> ok
[18:09] <jhodapp> kenvandine, also, Mirv looked this patch over already as well
[18:09] <kenvandine> jhodapp, what happens if an app imports 5.4 and uses Audio?
[18:10] <jhodapp> kenvandine, they won't see the playlist stuff
[18:10] <kenvandine> ok
[18:11] <kenvandine> jhodapp, done
[18:11] <kenvandine> that was easy :)
[18:11] <jhodapp> kenvandine, perfect, thanks!
[18:31] <robru> Mirv: hey sorry for the hassle there, investigating now.
[19:38] <bfiller> robru: can you rebuild telephony-service on arm64 only in silo 3?
[19:38] <robru> bfiller: sure one sec
[21:11] <robru> bfiller: there's a bug in ticket creation at the moment, the assignment didn't work because your distribution field is wrong. please edit your ticket, correct the missing values, and then it'll work (I have a fix for this but it's not quite in production yet
[21:14] <bfiller> robru: ok
[23:24] <alesage> robru, do you happen to know if uitk folks (e.g. bzoltan_ ) care about powerpc builds? https://requests.ci-train.ubuntu.com/#/ticket/818
[23:25] <robru> alesage: if the train reports a failure in that arch then it's a regression on that arch, so either they will be forced to care or they will need a really good reason for regressing
[23:26] <alesage> robru ack, ok, I'll pause this silo then and wait for a resolution (otherwise appeared passed)
[23:27] <robru> alesage: looks like it was rebuilt after being set ready for qa so just kick it back to them, yeah
[23:27] <alesage> robru, ack thx
[23:27] <robru> Yw