/srv/irclogs.ubuntu.com/2015/12/10/#ubuntu-ci-eng.txt

=== _salem is now known as salem_
=== salem_ is now known as _salem
robruawesome01:13
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
Mirvthis transition is again turning out to be the most gigantic ever06:28
Mirvso we now have Qt, poppler, s390x to an extent and then apt itself.06:29
=== chihchun is now known as chihchun_afk
robruMirv: transition! All! The! Things!08:08
Mirv"Give me a button to push, and I will transition the world." -Aristoteles08:23
MirvArchimedes, even08:23
MirvA something anyway08:23
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
xavigarciadednick: morning09:12
xavigarciadednick: do you have an idea on when your branch for the volume slider will be ready@09:12
xavigarcia?09:12
xavigarciadednick: my idea is to move the silo today to QA09:13
xavigarciadednick: if your branch is not ready... then I guess I should open a separated bug for it and land it later09:13
dednickxavigarcia: i've made the changes required already. i'll get it reviewed again.09:14
dednickxavigarcia: ah, it's already been done.09:15
dednickxavigarcia: you can add it to your silo if you want.09:15
dednickhttps://code.launchpad.net/~nick-dedekind/unity8/lp1520548.volume-resync/+merge/27939909:15
xavigarciadednick: cool09:16
xavigarciadednick: thanks... also... please review again my branch, that you marked as "needs fixing"09:17
dednickxavigarcia: done09:20
Mirvsil2100: the Qt transition is now bound with apt 1.1 transition too and aptdaemon fails a few tests with aptdaemon. and not sure if s390x can be ignored or if it's really bound - xnox is anyway very keen in rebuilding lots of Qt stuff etc on s390x (which doesn't hurt at least as long as the apt issue is there)09:25
Mirvs/with aptdaemon/with apt 1.1/09:25
xavigarciadednick: thanks!09:25
sil2100Mirv: things keep piling up!09:26
sil2100Whyyyy09:26
Mirvsil2100: yes, more and more.. the icing on the cake would be full KDE upload like I mentioned. I see there was a new release a couple of days ago..09:27
sil2100Mirv: nooooo09:27
Mirvsil2100: :)09:27
nerochiarojgdx: kenvandine: any chance one of you could review https://code.launchpad.net/~phablet-team/ubuntu-system-settings/permission-page-url/+merge/279883 ?09:29
jgdxnerochiaro, certainly, but did you address the test thing and the path comment? :)09:34
jgdxnerochiaro, if not, and you don't want to, that's okay. The panel is thoroughly tested either way.09:35
nerochiarojgdx: sorry, what was the "path comment" ?09:36
jgdxnerochiaro, ken's. Basically, he wanted to be able to link to the access page directly using security-privacy/access09:37
jgdxright now you can't, IIRC09:37
nerochiarojgdx: i can add that, no problem. so the url would be security-privacy/acccess?service=camera ?09:38
jgdxnerochiaro, yeah, I think that'd be good.09:39
Mirvsil2100: FYI Qt 5.6 schedule updated for Feb 9th release now (instead of Oct^WDecember), which pretty much rules it out from 16.04 LTS :(09:49
Mirvsil2100: it'd been the Qt LTS version which would have suited well09:49
morphissil2100, Mirv: can one of you drop the miracast-service packages from silo 0?10:22
morphiswe renamed the component so also the package names will be different10:23
sil2100morphis: on it10:33
morphissil2100: thanks!10:33
sil2100morphis: both miracast packages dropped :)10:33
robruMirv: look on the plus side: when you backport 5.6 to xenial.1, there won't be any other transitions to interfere ;-)10:34
morphissil2100: great10:34
morphisrobru: btw. is there any timeline to get git support into citrain?10:34
robrumorphis: nope. Tons of other stuff is higher priority unfortunately10:34
sil2100Backporting Qt major releases - niiice10:34
sil2100;)10:34
morphisrobru: ok10:34
robrumorphis: don't get me wrong I'd love that. But it'll be months before i can even think about it10:35
morphisrobru: yeah that is what I already feared :)10:35
robrumorphis: if bzr is really killing you, make you can develop with git and just import to bzr for train releases? I think some people are already doing this, i saw some git commit hashes in the bzr logs recently10:36
Mirvrobru: heh :)10:36
morphisrobru: yeah that would work, we're doing that for ofono10:37
morphisbut still some extra work10:37
morphisand we're currently progressing very fast and not even landing things so that would only make things more complicate10:37
morphisif we would just have a good bzr-git-bridge ....10:38
robrumorphis: true. Do you know what the status of git MPs are? Last i heard it was crazy and obscure. I'm hoping git gets closer to being first class on launchpad before i start implementing train support10:38
morphisrobru: I did one sometime ago and it just worked for me10:39
robrumorphis: last time i tried i couldn't even find ui for proposing a merge so i gave up ;-)10:39
morphisrobru: yeah its a bit hard to find you the project you want to propose a MP against needs to be setup correctly10:40
morphisrobru: we're using it for libhybris now10:40
robrumorphis: please email me some example git MPs to poke at10:41
morphisrobru: https://code.launchpad.net/~chrisccoulson/libhybris/+git/libhybris/+merge/28007010:41
robrumorphis: email ;-) I'm on my phone10:41
robruAnd i should be sleeping! Goodnight!10:42
morphisrobru: ah :-)10:42
morphisrobru: sent10:43
robruThanks! Goodnight!10:43
bzoltan_sil2100:  Would you be so kind to merge the UITK landing branch to the trunk and publish the package at least to the Overlay PPA, please?10:52
sil2100bzoltan_: hey! Which silo is that?11:18
morphissil2100: I am wondering why https://ci-train.ubuntu.com/job/ubuntu-landing-000-1-build/4/console now still picks up miracast-service where I dropped it's MPs and you removed the packages from the silo11:20
sil2100morphis: hmm... edit your request in the train and remove miracast-service from Source Package Names11:25
sil2100And try to rebuild11:25
sil2100I guess that should help11:25
morphisok11:25
morphissil2100: hm, it gets readded once I start the build11:26
sil2100morphis: ok, I see a few problems11:29
morphissil2100: which?11:29
=== _salem is now known as salem_
sil2100morphis: the train takes the source package name, not the lp project name - and in your aethercast branch the changelog and control files still use the miracast-service names11:33
sil2100morphis: the other problem - your merges target trunk, but trunk doesn't seem to exist? ;)11:33
morphisit does11:34
morphislp:aethercast is there11:34
morphissil2100: hm, the debian/ stuff is changed with one of the MPs11:34
morphisthought that would be enough11:34
morphisso let me merge https://code.launchpad.net/~morphis/aethercast/name-conversion/+merge/28011011:35
sil2100hmm11:39
sil2100morphis: https://code.launchpad.net/~morphis/aethercast/trunk11:39
sil2100This gives me "This page does not exist, or you may not have permission to see it. "11:39
morphisI've just changed the owner11:40
sil2100btw. you need to make sure the train bot has write access to the trunk branch11:40
morphisto phablet-team11:40
sil2100Yeah, +1 on that11:40
morphisdon' really understand why some gets on ~morphis when I push to lp:aethercast for creating a repo11:40
sil2100Anyway, might be some strange edge case of the train here11:40
morphissil2100:11:46
morphis2015-12-10 11:45:13,338 INFO Merging https://code.launchpad.net/~morphis/aethercast/null-merge at r113.11:46
morphis2015-12-10 11:45:13,339 INFO Merging: https://code.launchpad.net/~morphis/aethercast/null-merge11:46
morphis2015-12-10 11:45:13,339 INFO Into: /var/lib/jenkins/silos/ubuntu/landing-000/xenial/miracast-service/miracast-service11:46
morphisthat doesn't really make sense to me11:46
sil2100uugh11:46
morphisthe MP is definitely against lp:aethercast11:47
morphissee https://code.launchpad.net/~morphis/aethercast/null-merge11:47
morphisnot sure from where it gets the lp:miracast-service reference11:48
morphisthere is no further reference to it in one of the MP or the request11:48
=== chihchun_afk is now known as chihchun
jibelpopey, we have a test case for the weather app which says that the list of location is limited to 7. Is it true or it is unlimited?11:52
bzoltan_sil2100:  3111:52
jibel7 cities11:52
popeyjibel, it was limited in the previous version, and I think we carried that over11:52
sil2100morphis: might be some strange bug in the train...11:54
sil2100morphis: what I would propose trying:11:54
sil2100morphis: remove all athercast merges from the silo, rebuild the silo (should be a no-op) - remove the miracast-service from the Source Package Names11:54
sil2100morphis: afterwards I would try re-adding the aethercast merges back and building11:55
sil2100Well... that's just an idea11:55
jibelpopey, okay. Apparently now I can add as many as I want but the list only shows 18.11:56
morphissil2100: let me try that11:57
jibelpopey, I'll update the test case and file a bug11:57
jibelthanks11:57
sil2100morphis: I think no one considered the edge-case of renaming sources during a landing etc.11:57
morphisok11:58
=== chihchun is now known as chihchun_afk
SaviqMirv, looks like Qt's finally gonna migrate soon?12:06
=== chihchun_afk is now known as chihchun
bzoltan_sil2100: the address-book is failing on Xenial, but it has nothing to do with the UITK. I doubt it builds on X anywhere. All other bits in Silo31 are good to go.12:12
sil2100bzoltan_: do you know what in Xenial is causing the FTFBS for address-book-app? Since I see silo 45 has address-book-app and it built it sucessfully 22 hours ago12:17
sil2100Was something uploaded to xenial less than 22 hours ago that caused it to regress?12:18
sil2100bzoltan_: actually... I see your address-book-app is really old in the silo (since 2 days)12:19
sil2100bzoltan_: could you rebuild it and check if it helps?12:19
bzoltan_sil2100:  I have built it like 5 times12:20
bzoltan_sil2100:  but I can try12:20
sil2100Maybe someone was broken in the past and now it's fixed, or the UITK landing is causing the regression - as I said, silo 45 has a successfully built address-book-app12:20
sil2100So it might be goodish now12:20
=== chihchun is now known as chihchun_afk
bzoltan_sil2100:  the Vivid build was fine and I have no idea what is causing the Xenial failure.12:27
sil2100bzoltan_: did you re-build address-book-app in the end?12:27
bzoltan_sil2100: https://ci-train.ubuntu.com/job/ubuntu-landing-031-1-build/3/console started now12:28
sil2100bzoltan_: ok, thanks, let's see how it goes12:28
bzoltan_sil2100:  I hope that the address book app's failure on Xenial does not block our OTA9 landing to Vivid Overaly :)12:29
sil2100bzoltan_: well, it depends if UITK is causing it ;) Since as I said, it built fine on vanilla Xenial 22 hours ago12:29
=== chihchun_afk is now known as chihchun
Mirvsil2100: might be really close again.. stay tuned but don't hold breathe :)12:47
sil2100uh oh12:47
=== chihchun is now known as chihchun_afk
morphis_sil2100: you got my last messages? looks like I got disconnected ..13:05
sil2100morphis_: hm, I don't think I did13:05
morphis_<morphis> sil2100: if I assign a new silo for the request can you copy over all packages?13:06
morphis_<morphis> sil2100: meaning all source package which are not build from an MP13:06
morphis_before I spend too much time with getting this fixed13:06
popeypete-woods, any chance this can be fixed, - it's blocking some developers from building their apps - https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/147218613:12
ubot5Ubuntu bug 1472186 in indicator-network (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [High,Confirmed]13:12
sil2100morphis_: is it still making problems?13:21
=== pat_ is now known as Guest15515
morphis_sil2100: yes13:33
morphis_rebuilding without the MP drops it but when putting the MP back in it still refers to miracast-service13:34
sil2100Ouch, is using a completely different silo for everything not an option?13:34
sil2100This is crazy13:34
pete-woodspopey: it's beyond me13:35
pete-woodsI've tried asking for help with it, but no luck there13:35
popeypete-woods, is it a packaging thing? perhaps Mirv can help?13:35
pete-woodsyeah13:35
pete-woodsit's packaging13:35
popeyMirv is the king of packaging, I'm sure it's within his capabilities ;)13:35
pete-woodswell hopefully he can spot what's wrong :)13:36
cjwatsonrobru: git MPs work just fine - I mean, there are places where we could use better UI, but they're functional.  The thing you may have missed is that you need to propose the merge from the branch, not from the repository; after that it works more or less like bzr.13:39
sil2100morphis_: ah, sorry, mis-read your earlier question13:39
sil2100morphis_: yeah, that should be a valid option - at least something workable13:39
morphis_yes13:39
sil2100morphis_: but you would have to submit a new request13:39
sil2100morphis_: like a new one with the same contents, we assign it a different silo, copy all the packages there and then free the original one13:40
morphis_sil2100: fine for me13:40
sil2100I just hope CI Train won't go all nuts because of the other merges not getting built traditionally13:40
sil2100There's been so many changes that I have no idea how it does builds anymore13:41
morphis_:-)13:41
morphis_sil2100: "2015-12-10 13:41:19,576 ERROR Assignment failed: Low on silos: Ask a trainguard to assign"13:42
morphis_sil2100: new request is https://requests.ci-train.ubuntu.com/#/ticket/76913:42
=== chihchun_afk is now known as chihchun
sil2100What the FUDGE13:43
sil2100morphis_: https://ci-train.ubuntu.com/job/prepare-silo/11/console13:43
sil2100miracast-service again13:44
sil2100Where does he get that from?!13:44
sil2100Let me run it with debug, one moment13:44
morphis_WTF13:44
morphis_sil2100: not sure if that matters but what I did to get lp:aethercast initialized was to push from a lp:miracast-service checkout13:45
sil2100Shouldn't be a problem, let me look at the train code13:47
sil2100morphis_: this is really really REALLY bizzarre13:55
morphis_sil2100: yes ..13:55
sil2100morphis_: the CI Train code does a check of debian/changelog from the branches13:56
sil2100hmm13:56
sil2100Let me try something13:56
morphis_sil2100: where is the debug log for this?13:56
Mirvpete-woods: it must be something in the connectivity-api dependency chain that is not multi-arch ready? try to go through the dependency chain based on the error messages so try installing libconnectivity-qt1:armhf and see what that complains next about why it can't be installed14:01
=== chihchun is now known as chihchun_afk
sil2100What I pasted in is the best we get, let me try again as all commands that the train executes executed separately return the correct data14:01
sil2100morphis_: I'm starting to worry that there's some caching going on here or something14:03
sil2100morphis_: as it's impossible14:03
morphis_sil2100: just checked but trunk doesn't contain any reference to lp:miracast-service anymore14:04
sil2100I'll try another reassign14:05
sil2100hmmm14:06
sil2100morphis_: right now I suspect paranormal activity (tm)14:24
dbarthhey guys, in exchange for the last silos handed over, can i get one for https://requests.ci-train.ubuntu.com/#/ticket/770 and he oxide 1.11 release for Vivid ? ;)14:27
sil2100dbarth: will try to give you one in a minute, battling some ghosts now14:28
morphis_sil2100: hm14:29
dbarthsil2100: nw, ty14:30
sil2100dbarth: assigned14:34
sil2100morphis_: still nothing, as I said it's strange since even executing the bzr cat commands that the train does for your MP yelds proper results and I really doubt there's some cache anywhere14:35
morphis_hm14:35
sil2100morphis_: the train is just a set of scripts and it's not supposed to cache anything, especially for the prepare job14:35
morphis_sil2100: lets try with a brand-new MP14:35
sil2100Yeah, maybe that could work14:35
sil2100But I even called the API directly and all was good14:36
sil2100Might be that the train keeps some files somewhere and just reuses them, but I don't see anything in the code neither would it make any sense14:36
morphis_sil2100: https://code.launchpad.net/~morphis/aethercast/null-merge-2/+merge/28015214:37
morphis_sil2100: you want to add that or should I?14:38
sil2100Let me modify the request14:38
sil2100sigh14:38
sil2100morphis_: the same thing...14:38
morphis_brr14:39
sil2100morphis_: just as an experiment, let's try building the silo14:39
sil2100Just the aeathercast package14:39
sil2100Let me try that with debug14:39
sil2100No, doesn't work14:40
sil2100This is really crazy14:41
morphis_hm14:41
sil2100Ah14:41
sil2100Wait, I've got another idea14:41
morphis_sil2100: which one?14:47
dbarthsil2100: thanks; can you upload a source copy from this ppa please? https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages14:49
dbarthit is oxide-qt-1.11.3-ubuntu114:50
sil2100morphis_: I'm asking IS to remove one branch in case that matters, as the ci-train-bot pushed one branch-in-progress14:51
sil2100That's probably not it though, but I'm slowly out of ideas14:51
morphis_ok14:51
morphis_worth a try14:51
sil2100dbarth: in a minute15:03
sil2100morphis_: ok, I don't see anything15:03
sil2100morphis_: the train code is a bit tricky, but from my POV I don't see any reason why this wouldn't work - when I lp.load() the merge api path and do merge.target_branch.display_name I get u'lp:aethercast', so the correct branch15:04
morphis_hm15:04
sil2100And bzr cat --directory lp:aethercast debian/changelog returns the right thing15:04
sil2100The only thing I could think of now is that bzr cat is somehow buffering stuff15:05
sil2100But I called the same command in a test job on jenkins and got the right response15:05
morphis_sil2100: is it the right jenkins instance?15:05
sil2100Yeah, the same15:05
sil2100robru: hey, once you're around, could you take a look at https://requests.ci-train.ubuntu.com/#/ticket/769 ? No matter how many times we reassign, it invalidly detects that the aethercast merge provides the miracast-service source15:07
sil2100robru: I tracked the code and executed the exact same steps on lp-shell locally and was getting the aethercast name, but the train insists that source_name is miracast-service all the time15:09
sil2100robru: bzr cat of the target branch says the same15:09
sil2100robru: I even did a bzr cat in the same way that the train does in bzr_cat and get_package_name_from_branch but I got the right value (aethercast)15:10
MirvIT'S HAPPENING!!15:10
Mirvpmcgowan: bfiller: sil2100: so xenial is about to get sane wrt train again since we managed to get Qt + apt 1.1 + s390x + half the world migrating to release pocket finally15:11
sil2100\o/15:12
* sil2100 still sees qtbase in excuses though, just hope it's a matter of time now15:12
morphis_sil2100: thanks!15:12
pmcgowanMirv, great15:13
Mirvsil2100: it's happening, but britney did some "trading" and there are remaining things broken.15:14
Mirvsil2100: you may want to keep updated with the rest of the foundations team on what's still to be done. the migration was unoptimal so a couple of key packages (for phone) are still stuck, which normally of course shouldn't ever happen.15:24
Mirvrobru: sil2100: I'm merge & cleaning silo 012, so long for the 9 months old silo :) it did not auto clean since I did a couple of new uploads directly to archives, but otherwise it's done.15:28
Mirvsil2100: but notably ubuntu-ui-toolkit from silo 059 (that you published) is still stuck in proposed, because of s390x issues, which the whole non-functional at the moment: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-ui-toolkit <- that was the "interesting" trade britney did15:29
sil2100dbarth: hey15:35
sil2100dbarth: silo 57 is supposed to be for the overlay?15:35
dbarthsil2100: yes, the vivid overlay only; the wily/xenial and desktop vivid packages are released via the security pocket as usual15:39
sil2100dbarth: ok, just asking, since I'll have to append the ~overlay bit in that case :)15:40
sil2100Eeek, will take a bit15:40
Mirvrobru: sil2100: https://ci-train.ubuntu.com/job/ubuntu-landing-012-3-merge-clean/1/console - among else 45 builds of qtbase 5.5.0alpha/beta/rc/final/5.5.1 deleted :)15:42
oSoMoNMirv, what happened with the rebuild of webbrowser-app against Qt 5.5.1 ? looks like the history of lp:webbrowser-app got rewritten15:42
Mirvok, but the UITK issue seems on track to be resolved via s390x fixes too so hopefully not much work anymore15:43
MirvoSoMoN: wow... I think robru needs to look at that - in practice it was more publishings done while the 012 silo was still there, that is 012 wasn't cleaned while you continued webbrowser-app landings. not 100% sure if bzr magic is wanted to be used to fix that, or could just the current archive version be forced to the trunk (just thinking about the Launchpad - does it get what is now merged or not)15:45
sil2100Mirv: woohooo \o/15:46
MirvoSoMoN: the other affected package is qtubuntu-camera which also had one landing while 012 was not yet cleaned15:46
MirvoSoMoN: robru: however scary the trunk resync looks in webbrowser trunk, if I copy the contents of https://launchpad.net/ubuntu/+source/webbrowser-app/0.23+16.04.20151204-0ubuntu1 release over lp:webbrowser-app, there's zero changes aside from one added changelog entry (the Qt rebuild) and one changed PO file. Train seems to have done exactly what it should have, although I have no idea what this whole15:49
Mirv commit is really about (or what exactly happened) http://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/revision/129515:49
oSoMoNMirv, yeah, it looks like no harm was done, although the trunk history looks a bit weird now, as if there had been two distinct trunks for a short while, and now they got reconciled15:51
MirvoSoMoN: robru: I guess it actually cleaned two silos right after one another? the next to last commit is the Qt rebuild changelog entry, and the last includes this https://code.launchpad.net/~osomon/webbrowser-app/fix-ap-failures-desktop-narrow/+merge/279427 + well whatever it has done15:51
MirvoSoMoN: robru: well there most likely were two distinct trunks that now got combined in a very complex way :)15:51
oSoMoNwebbrowser-app is schizophrenic15:52
Mirvrobru: so basically nothing for you regarding webbrowser-app, we were just staring at the amazing work train was doing exactly correctly :)15:54
robruoSoMoN: Mirv: "Resync trunk" is when there are trunk changes that weren't in your branch. so trunk looks right, but the actual package released didn't have any of that 'resync trunk' stuff in it, looks like you just caused a huge regression, you should do a trunk release to get that stuff back in the released package.15:55
oSoMoNrobru, how can it be possible, if the Qt 5.5.1 release has version 0.23+16.04.20151130-0ubuntu1, and the current release is 0.23+16.04.20151204-0ubuntu1 ?15:57
oSoMoNI don’t expect 20151130-0ubuntu1 would overwrite 20151204-0ubuntu115:57
robruoSoMoN: silo 12 sat around for a long time, somehow something merged to trunk that was not built in the package that just got published.15:58
robruoSoMoN: like two conflicting silos both published it seems15:59
oSoMoNrobru, what I’m saying is I don’t think that package was published, given that it had a version number that is < to the currently published version15:59
oSoMoNrobru, so iiuc the changes in silo 12 are not actually published15:59
oSoMoN(not the other way around)15:59
robruoooohhhhh kay...16:00
robruoSoMoN: Mirv: https://requests.ci-train.ubuntu.com/#/ticket/20 check the audit log, the last few messages specifically say webbrowser-app needs to be rebuilt due to new commits16:01
robruMirv: I don't understand why you merged without publishing16:03
Mirvrobru: you're confusing things. 012 was published last weeks, but then before merging that oSoMoN did new landings of webbrwoser-app16:11
robruoSoMoN: Mirv: indeed 1204 release reverted 1130 release: http://launchpadlibrarian.net/228731358/webbrowser-app_0.23%2B16.04.20151130-0ubuntu1_0.23%2B16.04.20151204-0ubuntu1.diff.gz so better do a new silo with a trunk release to make released vrsion actaully reflect what is in trunk16:11
Mirvrobru: oSoMoN: the 1130 release was a no-change rebuild, so it does not hurt if the changelog entry was removed16:11
Mirvthe reason for no-change rebuild via MP instead of manual upload was that webbrowser-app is in main so this made publishin 012 easier. otherwise train wouldn't have noted since I'd have already updated the trunk before16:12
robruhmmmm ok16:13
Mirvrobru: thanks for checking anyway, but for me it's enough the non-012 landings are intact like they are. the other such landing was qtubuntu-camera16:15
Mirvwell a bit different but anyway, kaleo's later landing contained the same change16:15
robruoSoMoN: Mirv ok well just be aware 1130 is on trunk but not in the archive so next time you do a release that'll re-appear in the diff. so the silo diff will show the new version, then 1204, then 1130 being added, then 112616:17
oSoMoNMirv, so the landing of 0.23+16.04.20151204-0ubuntu1 was correctly built against Qt 5.5.1 ?16:17
Mirvrobru: ok!16:18
MirvoSoMoN: sure, against xenial-proposed where Qt 5.5 was already at that time16:18
oSoMoNexcellent16:18
oSoMoNso we can close the matter I think16:18
MirvoSoMoN: yes. just be aware that we're still working on xenial since ubuntu-ui-toolkit is stuck due to s390x issues. hopefully everything is done before the next image build and tomorrow morning's image is successful (and Qt 5.5 based).16:19
Mirvbut that does not directly concern you16:19
Mirvrobru: what's the PPA/bzr version mismatch https://requests.ci-train.ubuntu.com/#/ticket/771 ? I don't see any mismatches16:21
robruMirv: click the log for details16:21
cjwatsonthat looks like a thing that will clear in a bit16:22
cjwatsonprobably just wasn't quite in the PPA yet16:22
Mirvrobru: I clicked, it seems incorrect message16:22
robruoh, yeah16:22
robruMirv: did you *just* build that?16:23
Mirvrobru: yes, just16:23
robruMirv: it should sort itself out next time it runs in 15 minutes then16:23
Mirvrobru: ok, I just hadn't seen that before16:23
robruMirv: it used to say "VVVV not found in PPA" but I changed the message to not include the version number so that the case of multiple packages in this state can have the same status message, so the train can show a simpler status, then you can click the log to get the details16:25
Mirvrobru: ah, it's that in a new form, I've seen that before. thanks!16:25
robruyw16:26
sil2100jibel, robru, davmor2, rvr: I'll have to skip today's landing meeting16:30
rvrsil2100: Ok16:30
sil2100We need to drive to the vet again, we won't make it otherwise16:30
robrusil2100: let's cancel16:30
robruI have nothing for that meeting16:31
robrusil2100: i guess you forgot about https://wiki.ubuntu.com/citrain/LandingProcess#Renaming_a_Source_Package16:34
robrumorphis_: still around?16:43
morphis_robru: yes16:44
robrumorphis_: apologies about sil not being able to help you, the source package name cache is quite old, well known, and documented: https://wiki.ubuntu.com/citrain/LandingProcess#Renaming_a_Source_Package16:45
robrumorphis_: if you're ready to try a new build i can flush that cache real quick16:46
morphis_robru: ah... there is a cache :-)16:46
morphis_robru: no problem16:46
morphis_this isn't urgent16:46
morphis_robru: but yeah, I am ready :-)16:46
robrumorphis_: OK try it now16:48
robrumorphis_: i guess what happened was you built the old changelog at the new project? Usually if you rename the source package and push the rename to lp:newname it all works fine. But at some point you had the old man's in your changelog at the new trunk and did a build, that muddied the cache16:49
morphis_robru: yeah, that is what happened16:50
morphis_pushed lp:miracast as lp:aethercast16:50
morphis_then did a MP with the renaming (also renaming changelog entries)16:50
morphis_which doesn't seem to work16:50
robrumorphis_: yeah. Unfortunately the train needs that info in a bunch of different places so not caching that is super slow and causes it to redownload the changelog a lot.16:51
morphis_ok16:51
morphis_good to know for the future :-)16:51
robrumorphis_: yeah it relies on the name in trunk, you can't rename it from an MP.16:51
morphis_ok16:52
robruSame thing with adding packaging for the first time, won't work unless trunk already has debian/changelog at least16:52
robruI should probably figure out some way to flush the cache but that's hard, let's go shopping16:52
robrumorphis_: log looks good so far (assuming build doesn't fail), you just need to delete the old name from the sources on the ticket (it will stay gone this time)16:56
morphis_robru: wonderful16:58
morphis_robru: great, packages are in the silo and building17:01
morphis_tvoss_, jhodapp, awe_: ^^17:01
robruYay17:01
jhodappnice!17:01
jhodappwhat's the silo #?17:01
robrujhodapp: 017:02
jhodappthanks17:02
robruYw17:02
Trevinhotrainguards: for some reason on ticket 628 the train built soruce packages 22 minutes ago, but it's still saying that it's preparing them... And thus there's no upload to the ppa.17:46
Trevinhosorry... I spoke too early. Here they are :-)17:46
robruTrevinho: compiz is still building in ppa but the rest of the packages have been there for an hour17:48
Trevinhorobru: yeah, sorry... I didn't see the packages coming to the ppa and i was worried :-D. Although I see the just rebuilt unity not to be there...17:49
robruTrevinho: your last build only built compiz17:50
Trevinhorobru: oh... as there was a build failure in unity, I thought it would have cared about rebuilding it as well without forcing... I'll do that later.17:51
robruTrevinho: 2015-12-10 17:28:05,790 INFO unity has no new commits, skipping. 2015-12-10 17:28:05,791 INFO Including compiz.17:52
robruTrevinho: it wouldn't rebuild a failure unless there are new commits to fix the failure...17:52
Trevinhoyeah... I thought it was also checking whether there had been a build failure on previous rebuild17:52
Trevinhonot wrong... Although sometimes there are random failures :-D17:53
TrevinhoIn this case was a missing libnux package from the arm64 archive... While it should be there forever17:53
robruTrevinho: those failures should be retried in the ppa, not rebuilt and reuploaded17:53
Trevinhorobru: I can I do that?17:54
robruTrevinho: no, you have to ask me. There's a bug open to add that feature for everybody17:54
Trevinhorobru: ah, it would be cool17:55
robruYeah, lots of higher priorities unfortunately17:55
Trevinhorobru: I understand... Can you then trigger a rebuild of unity for arm64? :😃17:58
robruOK17:58
Trevinhorobru: thanks17:59
robruTrevinho: you're welcome17:59
sil2100morphis_, robru: did the mystical silo mystery got resolved?18:29
sil2100robru: oh, so there was some caching in the end somewhere?18:30
robrusil2100: yes, I'm surprised you forgot about the cache, it's not new18:30
sil2100robru: didn't see it in the code, how do you clean it?18:31
robrusil2100: the doc i linked has the instructions18:31
robrusil2100: also if you were looking at the function, it says "@ramdisk" right there18:32
sil2100huh, had no idea what that meant, ok18:32
sil2100Ok, now I know what that decorator is for, I didn't even notice it really18:33
robrusil2100: the clue was "disk" i guess18:35
robrusil2100: the sister decorator is "@memoize", which does the same thing, only in memory, no disk storage18:36
sil2100k18:36
sil2100ACK, thanks18:36
robrusil2100: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/cupstream2distro/utils.py#L106 it only calls the function if the value isn't found in the cache18:37
robruYw18:38
robrurenatu: humm, that looks transient, trying again: https://ci-train.ubuntu.com/job/ubuntu-landing-055-1-build/3/console19:37
robrurenatu: is your name short for Nosferenatu? ;-)19:38
renaturobru, no :D19:40
renaturobru, "renato" is in use already :D19:40
robruah19:40
rvrjhodapp: Silo 41 approved19:51
jhodapprvr, awesome thanks20:00
robrubblunch21:09
=== salem_ is now known as _salem

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!