[11:51] <oSoMoN> ubuntu-qa: do you know what’s up with the autopkgtest for qtcreator-plugin-ubuntu 3.5.0+16.04.20151204.1-0ubuntu1 ? they seem to be blocking migration from proposed of various packages, including webbrowser-app
[11:55] <davmor2> oSoMoN: not sure who would be best to talk to, jibel would this be a pitti question?
[12:57] <bzoltan_> trainguards: Is it for real? https://ci-train.ubuntu.com/job/ubuntu-landing-031-1-build/18/console
[12:59] <sil2100> uh
[13:00] <sil2100> I thought we got rid of the space issues
[13:00] <sil2100> robru: ^
[13:11] <sil2100> bzoltan_: impossible, df says there's sh*t load of space - could you re-build?
[13:12] <sil2100> Maybe some strange hiccup
[13:12] <bzoltan_> sil2100:  that is what i did, but i thout you want to know about such a hiccup.
[13:12] <sil2100> bzoltan_: yeah, thanks for letting me know, it is strange
[13:12] <sil2100> So many strange things going on recently ;)
[13:21] <Mirv> bzoltan_: pretty weird.. but I think you're not the only one with strange things happening
[13:22] <bzoltan_> Mirv:  and now I am back with the version magic -> https://ci-train.ubuntu.com/job/ubuntu-landing-031-1-build/20/console
[13:23] <Mirv> bzoltan_: did you ping robert yet with your new version magic woes? (in case that error is the same one as on weekend)
[13:23] <bzoltan_> Mirv:  not yet...
[13:24] <bzoltan_> Mirv:  now I just merged the staging UITK to the landing branch  and bumped the version... so it fails now
[13:33] <Saviq> robru, hey, any idea why https://ci-train.ubuntu.com/job/ubuntu-landing-022-1-build/13/consoleFull ? it seems to have copied the tarball fine but then fail?
[13:38] <Saviq> ah 0.4.7
[13:39] <rvr> dbarth: Silo 60 approved.
[13:39] <Saviq> robru, unping
[13:44] <bfiller> Mirv: do you know what the status is on qt5.5 in xenial? we have silo stuck in xenial proposed now since last week because of it
[13:45] <dbarth> rvr: ah nice, thanks
[13:52] <sil2100> bfiller: it seems that the autopkgtest infra has some issues right now and doesn't let Qt through
[13:52] <sil2100> bfiller: at least that was the case in the morning, pitti was on it
[13:52] <bfiller> sil2100: ok thanks
[13:56] <Mirv> bfiller: the status is what sil2100 said, autopkgtest infra has some issues and we're basically hoping that it happens really soon
[13:57] <bfiller> Mirv: the issue is being worked by pitti?
[13:57] <Mirv> bfiller: yes
[13:58] <bfiller> Mirv: thanks
[13:58] <Mirv> bfiller: is the stuckness of the silo blocking your next work? if so, we can manually clean&merge it and just remember tracking also your package migrates successfully
[13:58] <bzoltan_> sil2100: Mirv: yet again I have problems with the gles versioning.. now i really have no idea what should I do.
[13:58] <bfiller> Mirv: it is blocking, sil2100 already took care of a few silos for us - we'll probably have more later today
[14:03] <mzanetti> trainguards: seems we're outta space again
[14:04] <mzanetti> https://ci-train.ubuntu.com/job/ubuntu-landing-001-1-build/14/console
[14:11] <davmor2> Saviq: passes sorry forgot to mark it so before I went for Lunch
[14:11] <Saviq> davmor2, tx!
[14:11] <Saviq> sil2100, ↑ that's the hotfix silo
[14:12] <Saviq> might wanna take care of what's needed to get it in
[14:13] <sil2100> \o/
[14:14] <sil2100> Saviq: ok, will copy it to the snapshot once I'm back home, I'll be there in 45 mins
[14:14] <Saviq> ack
[14:14] <sil2100> mzanetti: ugh, that's really strange
[14:14] <sil2100> mzanetti: could you re-try?
[14:14] <sil2100> mzanetti: last time I checked we had like 80% of the volume free
[14:14] <mzanetti> sil2100, had that on friday already a couple of times. robru cleared up some space
[14:15] <mzanetti> sil2100, problem is, a unity7 build needs some 2GB temp space
[14:15] <mzanetti> unity8
[14:15] <sil2100> robru: still some out-of-space issues it seems
[14:15] <mzanetti> I can retry, sure..
[14:15] <davmor2> dbarth: I'm trying to test silo 003, I don't see the scope you guys are talking about
[14:17] <sil2100> davmor2, jibel: you guys mind if I switch silo 14 to 'needs QA'? I don't want anyone to publish that by accident
[14:17] <sil2100> Since it's supposed to be binary-copied
[14:17] <davmor2> sil2100: I don't care
[14:18] <jibel> sil2100, I don't mind
[14:19] <sil2100> Ok, brb, driving home, be back shortly
[14:42] <mterry> trainguards: still low on space in jenkins?
[14:45] <davmor2> dbarth: is silo 003 a desktop fix?
[14:48] <dbarth> davmor2: yes, plus a general change that also affects touch as well
[14:48] <dbarth> the ussoa updates
[14:49] <davmor2> dbarth: right so what is the test on touch because the testplan is non-existant and only really mentions the gdrive scope which is desktop only
[14:51] <bzoltan_> trainguards: this -gles issue is blocking the main UITK testing here -> https://requests.ci-train.ubuntu.com/#/ticket/754
[14:51] <bzoltan_> Mirv:  ^  now the trick does not help
[14:53] <Saviq> bzoltan_, 1.3.1741 vs. 1.3.1742 afaict
[14:54] <Saviq> trainguards, ENOSPC :(
[14:56] <bzoltan_> Saviq: hawkeye
[14:56] <bzoltan_> thanks... getting blind on these version numbers
[14:56] <Saviq> bzoltan_, just fought a similar issue with qtmir earlier today, is all ;)
[15:24] <oSoMoN> trainguards: is it ok to force merge silo 58 ? the package has been blocked in xenial-proposed since Friday, apparently because of a conflict between libqt53d5 and libqt53dquick5, and it’s preventing from building other webbrowser-app silos
[15:24] <mterry> cihelp, robru: are we still low on space for builds?  Looks like a build of mine failed for that reason
[15:25] <fginther> trainguards, see ^ from mterry
[15:43] <bfiller> trainguards, cihelp: yes we really need this disk space issue resolved ASAP, please help
[15:53] <rvr> jibel: There is this one https://prod.practitest.com/p/1548/tests/489175/edit
[15:54] <rvr> Oops, wrong channel
[15:57] <Saviq> sil2100, yeah, ENOSPC in train :/
[15:57] <sil2100> Still?!
[15:58] <sil2100> Ok, on it now, but not sure if I'll be able to help
[15:58] <sil2100> The train is not really my 'turf'
[15:59] <sil2100> Especially that it looks like we have 58 GB free, hmm, maybe something changed in the deployment
[16:01] <sil2100> Saviq: ok, it seems the deployment changed and pbuilder is again using the non-persistent storage
[16:02] <sil2100> I freed some space again, but this won't do, there's only 3 GB free
[16:04] <sil2100> robru: what's the current state of the 'no free space' situation? webops once switched to using the persistent volumes, it doesn't seem to be the case anymore
[16:04] <sil2100> robru: was that reverted during some jenkins redeployment, or maybe reverted for other reasons?
[16:31] <oSoMoN> trainguards: is it ok to force merge silo 58 ? the package has been blocked in xenial-proposed since Friday, apparently because of a conflict between libqt53d5 and libqt53dquick5, and it’s preventing from building other webbrowser-app silos
[16:35] <sil2100> oSoMoN: on it - if it's blocked by qt5 migrating, then I'll merge
[16:35] <oSoMoN> sil2100, thanks
[16:55] <bzoltan_> sil2100: I still need help with the silo31 :( that gles package is holding up the UITK landing
[17:00] <bzoltan_> robru: I was strugling with that gles package... I think it would be useful to allow th emain package build even if the gles package has problem.
[17:01] <bzoltan_> robru:  or please tell me what should I do to make the gles source
[17:02] <kdub> what does 'diff missing' mean?
[17:03] <kdub> https://requests.ci-train.ubuntu.com/#/ticket/725
[17:07] <bzoltan_> trainguard: I really need help with this - https://ci-train.ubuntu.com/job/ubuntu-landing-031-1-build/25/console
[17:08] <bzoltan_> Mirv: sil2100: robru ^ please
[17:10] <Mirv> bzoltan_: robru should be online soon and he can double-check what should be done with the new gles problems
[17:13] <bzoltan_> Mirv:  is there a way to force build the main without the gles? there used to be an option for that.
[17:18] <Mirv> bzoltan_: that is also a request for robru, but the ignore twin packages option was removed earlier
[17:19] <rvr> boiko: Hi. Silo 24 has a couple of merge proposals that need review.
[17:38] <kdub> trainguards what to do if I have a "diff missing" message in silo? https://requests.ci-train.ubuntu.com/#/ticket/725
[17:38] <sil2100> kdub: run the build job with the DIFF_ONLY flag checked
[17:39] <kdub> sil2100, thanks
[17:40] <bzoltan_> sil2100: Is anybody available who can fix my silo? I soon have to EOD and I must deploy a build before the night otherwise we loose a full day
[17:40] <sil2100> bzoltan_: does it still fail even after me cleaning the pbuilder cache?
[17:41] <bzoltan_> sil2100: it just failed
[17:41] <bzoltan_> sil2100: the ubuntu-ui-toolkit-gles_1.3.1742+16.04.20151207.1.orig.tar.gz  is created and still bzr: ERROR: Unable to find the needed upstream tarball for package ubuntu-ui-toolkit-gles, version 1.3.1742+16.04.20151207.1.
[17:42] <sil2100> robru: hey, you around? ^
[17:43] <sil2100> robru: you have more knowledge of the infra, I'm deep in OTA_8.5 re-spin...
[17:44] <bzoltan_> robru: sil2100: I am desperate :) is there a way to force the build without the gles?
[17:44] <sil2100> There were so many changes that I don't know anymore, we had a flag for that in the past
[17:46] <bzoltan_> sil2100:  that flag could save me hours of strugle :(
[17:51] <sil2100> bzoltan_: hmm, no flag like that anymore, ehh
[17:51] <sil2100> And I don't know the new methods for -gles builds anymore
[17:52] <sil2100> Would have to dive in, but I also need to get this candidate image going
[17:52] <sil2100> Let me try doing that in-between before robru appears :)
[17:52] <bzoltan_> sil2100: only robru can help
[18:14] <boiko> rvr: oups, sorry, let me get to those, they are all reviewed and tested, just forgot to approve them
[18:14] <rvr> boiko: Ok
[18:16] <boiko> rvr: all approved now
[18:17] <rvr> boiko: Great
[18:59] <robru> bzoltan_: stop trying to predict dates in your changelogs. just make the changelog version be 'x+16.04-0ubuntu1' and the train will generate dates that match. you have 05 in one and 07 in the other.
[19:01] <robru> bzoltan_: even better, don't touch debian/changelog in gles branch at all. most people are letting the train manage it entirely
[19:08] <bzoltan_> robru: no, they are exactly the same in the main and in the gles
[19:08] <bzoltan_> robru:  that is not the problem... it was in one version and Saviq spotted it quickly. but the issue remained
[19:08] <bzoltan_> robru:  something is not right how the gles is handled.
[19:09] <bzoltan_> robru:  but first of all, can we force the main package to build even if the gles has problems?
[19:09] <robru> bzoltan_: no, that was taken away so that gles twins always build with same version numbers.
[19:10] <bzoltan_> robru: except now
[19:10] <bzoltan_> robru: what should I do?
[19:10] <robru> bzoltan_: i told you. stop predicting version numbers, you're confusing the train.
[19:10] <bzoltan_> robru:  what is wrong here - https://ci-train.ubuntu.com/job/ubuntu-landing-031-1-build/27/console
[19:11] <robru> bzoltan_: one is .1 and one isn't because you put wrong version numbers in changelog
[19:11] <bzoltan_> robru:  I am not predicting.... it is what it is.
[19:12] <robru> bzoltan_: take the dates out of the changelog entries you are writing. that is my official advice.
[19:13] <robru> bzoltan_: the whole point of the gles work I did recently was so that the train could manage the version numbers for you.
[19:14] <bzoltan_> robru:  I have removed the dates from the main and from the gles.. I trigger a build now.
[19:17] <bzoltan_> robru: I did not know that I have to manually remove the date string from the version before landing. That is new to me. Sorry for the mistake... the UITK changelog always had a date...now i removed them. let's see what the train thinks
[19:19] <sil2100> bzoltan_: robru created a better way of dealing with gles rebuilds some time ago, don't have much info about that though
[19:34] <robru> bzoltan_: sil2100: so in the before time, you had to manually put version numbers that matched in both branches, and the train didn't try to generate version numbers because it was possible to rebuild one without the other (so auto versions would get out of sync). but to enable automatic versions, we said "ok, the train can pick version numbers, but now
[19:34] <robru> always build both so they always stay in sync when picking new version numbers"
[19:35] <robru> bzoltan_: sil2100: but if your inputs have pre-filled version numbers that don't match, the train gets confused and increments them wrong. so you have to not put the date in your changelog so that the train can fill it out itself
[19:40] <bzoltan_> robru: the problem was that the UITK changelog does have  date in version number and I did not know that I have to remove that before landing.
[19:40] <robru> bzoltan_: sil2100: so the theory is that it's easier to let the train manage the version numbers, but the trick is that you have to give inputs that don't confuse the train. most of the time now eg for qtmir and qtubuntu, their gles merge is just totally empty, the train makes the whole changelog for them
[19:42] <robru> bzoltan_: well strictly speaking you don't have to "remove" the date, you just have to give dates that don't confuse the train. you had one merge that was ...05 and one was ...07 so the train incremented 05 to 07, and incremented 07 to 07.1, which doesn't match and causes the failure.
[19:42] <robru> bzoltan_: it probably would have worked if they both started with the same value. but removing the date entirely is a brute-force way to ensure they match
[19:45] <bzoltan_> robru:  I think that this train is like my daughter... super easy to confuse :)
[19:46] <robru> bzoltan_: Garbage In, Garbage Out!
[20:37] <robru> sil2100: https://rt.admin.canonical.com/Ticket/Display.html?id=86888 rsync currently broken by this, so if you need to publish anything you'll have to copy-package
[20:37] <robru> (for the last hour or so)
[20:49] <sil2100> robru: ACK
[20:57] <robru> kenvandine: renatu: apologies, train is having some hiccups with concurrent builds, will be resolved in 20 minutes.
[20:57] <robru> I'll retry all builds that fail
[21:10] <kenvandine> robru, thx
[21:23] <robru> dobey: apologies, your build failure is my fault, retrying now, should work
[21:25] <dobey> ok
[21:46] <dobey> i like how gcc crashes on ppc64el all the time
[21:53] <cjwatson> dobey: sadly it's most likely the infrastructure's fault, not gcc's
[21:54] <dobey> cjwatson: buildd issues you mean?
[21:54] <cjwatson> dobey: virtualisation layer
[21:54] <cjwatson> dobey: occasional guest memory corruption, basically
[21:55] <dobey> ah
[21:55] <cjwatson> it's rare enough that it's approximately tolerable
[21:56] <dobey> yeah, usually just doing a retry gets around it, afaict
[22:04] <dobey> speaking of
[22:04] <dobey> trainguards: can get a retry on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-023/+build/8406976 please?
[22:05] <cjwatson> dobey: done
[22:07] <dobey> thanks
[22:09] <dobey> at least ppc64el is reasonably fast