=== _salem is now known as salem_ === salem_ is now known as _salem [01:13] awesome === 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 [06:28] this transition is again turning out to be the most gigantic ever [06:29] so we now have Qt, poppler, s390x to an extent and then apt itself. === chihchun is now known as chihchun_afk [08:08] Mirv: transition! All! The! Things! [08:23] "Give me a button to push, and I will transition the world." -Aristoteles [08:23] Archimedes, even [08:23] A something anyway === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [09:12] dednick: morning [09:12] dednick: do you have an idea on when your branch for the volume slider will be ready@ [09:12] ? [09:13] dednick: my idea is to move the silo today to QA [09:13] dednick: if your branch is not ready... then I guess I should open a separated bug for it and land it later [09:14] xavigarcia: i've made the changes required already. i'll get it reviewed again. [09:15] xavigarcia: ah, it's already been done. [09:15] xavigarcia: you can add it to your silo if you want. [09:15] https://code.launchpad.net/~nick-dedekind/unity8/lp1520548.volume-resync/+merge/279399 [09:16] dednick: cool [09:17] dednick: thanks... also... please review again my branch, that you marked as "needs fixing" [09:20] xavigarcia: done [09:25] sil2100: 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] s/with aptdaemon/with apt 1.1/ [09:25] dednick: thanks! [09:26] Mirv: things keep piling up! [09:26] Whyyyy [09:27] sil2100: 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] Mirv: nooooo [09:27] sil2100: :) [09:29] jgdx: kenvandine: any chance one of you could review https://code.launchpad.net/~phablet-team/ubuntu-system-settings/permission-page-url/+merge/279883 ? [09:34] nerochiaro, certainly, but did you address the test thing and the path comment? :) [09:35] nerochiaro, if not, and you don't want to, that's okay. The panel is thoroughly tested either way. [09:36] jgdx: sorry, what was the "path comment" ? [09:37] nerochiaro, ken's. Basically, he wanted to be able to link to the access page directly using security-privacy/access [09:37] right now you can't, IIRC [09:38] jgdx: i can add that, no problem. so the url would be security-privacy/acccess?service=camera ? [09:39] nerochiaro, yeah, I think that'd be good. [09:49] sil2100: 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] sil2100: it'd been the Qt LTS version which would have suited well [10:22] sil2100, Mirv: can one of you drop the miracast-service packages from silo 0? [10:23] we renamed the component so also the package names will be different [10:33] morphis: on it [10:33] sil2100: thanks! [10:33] morphis: both miracast packages dropped :) [10:34] Mirv: look on the plus side: when you backport 5.6 to xenial.1, there won't be any other transitions to interfere ;-) [10:34] sil2100: great [10:34] robru: btw. is there any timeline to get git support into citrain? [10:34] morphis: nope. Tons of other stuff is higher priority unfortunately [10:34] Backporting Qt major releases - niiice [10:34] ;) [10:34] robru: ok [10:35] morphis: don't get me wrong I'd love that. But it'll be months before i can even think about it [10:35] robru: yeah that is what I already feared :) [10:36] morphis: 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 recently [10:36] robru: heh :) [10:37] robru: yeah that would work, we're doing that for ofono [10:37] but still some extra work [10:37] and we're currently progressing very fast and not even landing things so that would only make things more complicate [10:38] if we would just have a good bzr-git-bridge .... [10:38] morphis: 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 support [10:39] robru: I did one sometime ago and it just worked for me [10:39] morphis: last time i tried i couldn't even find ui for proposing a merge so i gave up ;-) [10:40] robru: yeah its a bit hard to find you the project you want to propose a MP against needs to be setup correctly [10:40] robru: we're using it for libhybris now [10:41] morphis: please email me some example git MPs to poke at [10:41] robru: https://code.launchpad.net/~chrisccoulson/libhybris/+git/libhybris/+merge/280070 [10:41] morphis: email ;-) I'm on my phone [10:42] And i should be sleeping! Goodnight! [10:42] robru: ah :-) [10:43] robru: sent [10:43] Thanks! Goodnight! [10:52] 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? [11:18] bzoltan_: hey! Which silo is that? [11:20] sil2100: 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 silo [11:25] morphis: hmm... edit your request in the train and remove miracast-service from Source Package Names [11:25] And try to rebuild [11:25] I guess that should help [11:25] ok [11:26] sil2100: hm, it gets readded once I start the build [11:29] morphis: ok, I see a few problems [11:29] sil2100: which? === _salem is now known as salem_ [11:33] morphis: 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 names [11:33] morphis: the other problem - your merges target trunk, but trunk doesn't seem to exist? ;) [11:34] it does [11:34] lp:aethercast is there [11:34] sil2100: hm, the debian/ stuff is changed with one of the MPs [11:34] thought that would be enough [11:35] so let me merge https://code.launchpad.net/~morphis/aethercast/name-conversion/+merge/280110 [11:39] hmm [11:39] morphis: https://code.launchpad.net/~morphis/aethercast/trunk [11:39] This gives me "This page does not exist, or you may not have permission to see it. " [11:40] I've just changed the owner [11:40] btw. you need to make sure the train bot has write access to the trunk branch [11:40] to phablet-team [11:40] Yeah, +1 on that [11:40] don' really understand why some gets on ~morphis when I push to lp:aethercast for creating a repo [11:40] Anyway, might be some strange edge case of the train here [11:46] sil2100: [11:46] 2015-12-10 11:45:13,338 INFO Merging https://code.launchpad.net/~morphis/aethercast/null-merge at r113. [11:46] 2015-12-10 11:45:13,339 INFO Merging: https://code.launchpad.net/~morphis/aethercast/null-merge [11:46] 2015-12-10 11:45:13,339 INFO Into: /var/lib/jenkins/silos/ubuntu/landing-000/xenial/miracast-service/miracast-service [11:46] that doesn't really make sense to me [11:46] uugh [11:47] the MP is definitely against lp:aethercast [11:47] see https://code.launchpad.net/~morphis/aethercast/null-merge [11:48] not sure from where it gets the lp:miracast-service reference [11:48] there is no further reference to it in one of the MP or the request === chihchun_afk is now known as chihchun [11:52] popey, 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] sil2100: 31 [11:52] 7 cities [11:52] jibel, it was limited in the previous version, and I think we carried that over [11:54] morphis: might be some strange bug in the train... [11:54] morphis: what I would propose trying: [11:54] morphis: remove all athercast merges from the silo, rebuild the silo (should be a no-op) - remove the miracast-service from the Source Package Names [11:55] morphis: afterwards I would try re-adding the aethercast merges back and building [11:55] Well... that's just an idea [11:56] popey, okay. Apparently now I can add as many as I want but the list only shows 18. [11:57] sil2100: let me try that [11:57] popey, I'll update the test case and file a bug [11:57] thanks [11:57] morphis: I think no one considered the edge-case of renaming sources during a landing etc. [11:58] ok === chihchun is now known as chihchun_afk [12:06] Mirv, looks like Qt's finally gonna migrate soon? === chihchun_afk is now known as chihchun [12:12] 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:17] bzoltan_: 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 ago [12:18] Was something uploaded to xenial less than 22 hours ago that caused it to regress? [12:19] bzoltan_: actually... I see your address-book-app is really old in the silo (since 2 days) [12:19] bzoltan_: could you rebuild it and check if it helps? [12:20] sil2100: I have built it like 5 times [12:20] sil2100: but I can try [12:20] Maybe 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-app [12:20] So it might be goodish now === chihchun is now known as chihchun_afk [12:27] sil2100: the Vivid build was fine and I have no idea what is causing the Xenial failure. [12:27] bzoltan_: did you re-build address-book-app in the end? [12:28] sil2100: https://ci-train.ubuntu.com/job/ubuntu-landing-031-1-build/3/console started now [12:28] bzoltan_: ok, thanks, let's see how it goes [12:29] sil2100: I hope that the address book app's failure on Xenial does not block our OTA9 landing to Vivid Overaly :) [12:29] bzoltan_: well, it depends if UITK is causing it ;) Since as I said, it built fine on vanilla Xenial 22 hours ago === chihchun_afk is now known as chihchun [12:47] sil2100: might be really close again.. stay tuned but don't hold breathe :) [12:47] uh oh === chihchun is now known as chihchun_afk [13:05] sil2100: you got my last messages? looks like I got disconnected .. [13:05] morphis_: hm, I don't think I did [13:06] sil2100: if I assign a new silo for the request can you copy over all packages? [13:06] sil2100: meaning all source package which are not build from an MP [13:06] before I spend too much time with getting this fixed [13:12] pete-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/1472186 [13:12] Ubuntu bug 1472186 in indicator-network (Ubuntu) "Can't install libconnectivity-qt1-dev on multiarch" [High,Confirmed] [13:21] morphis_: is it still making problems? === pat_ is now known as Guest15515 [13:33] sil2100: yes [13:34] rebuilding without the MP drops it but when putting the MP back in it still refers to miracast-service [13:34] Ouch, is using a completely different silo for everything not an option? [13:34] This is crazy [13:35] popey: it's beyond me [13:35] I've tried asking for help with it, but no luck there [13:35] pete-woods, is it a packaging thing? perhaps Mirv can help? [13:35] yeah [13:35] it's packaging [13:35] Mirv is the king of packaging, I'm sure it's within his capabilities ;) [13:36] well hopefully he can spot what's wrong :) [13:39] robru: 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] morphis_: ah, sorry, mis-read your earlier question [13:39] morphis_: yeah, that should be a valid option - at least something workable [13:39] yes [13:39] morphis_: but you would have to submit a new request [13:40] morphis_: like a new one with the same contents, we assign it a different silo, copy all the packages there and then free the original one [13:40] sil2100: fine for me [13:40] I just hope CI Train won't go all nuts because of the other merges not getting built traditionally [13:41] There's been so many changes that I have no idea how it does builds anymore [13:41] :-) [13:42] sil2100: "2015-12-10 13:41:19,576 ERROR Assignment failed: Low on silos: Ask a trainguard to assign" [13:42] sil2100: new request is https://requests.ci-train.ubuntu.com/#/ticket/769 === chihchun_afk is now known as chihchun [13:43] What the FUDGE [13:43] morphis_: https://ci-train.ubuntu.com/job/prepare-silo/11/console [13:44] miracast-service again [13:44] Where does he get that from?! [13:44] Let me run it with debug, one moment [13:44] WTF [13:45] sil2100: not sure if that matters but what I did to get lp:aethercast initialized was to push from a lp:miracast-service checkout [13:47] Shouldn't be a problem, let me look at the train code [13:55] morphis_: this is really really REALLY bizzarre [13:55] sil2100: yes .. [13:56] morphis_: the CI Train code does a check of debian/changelog from the branches [13:56] hmm [13:56] Let me try something [13:56] sil2100: where is the debug log for this? [14:01] pete-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 installed === chihchun is now known as chihchun_afk [14:01] What I pasted in is the best we get, let me try again as all commands that the train executes executed separately return the correct data [14:03] morphis_: I'm starting to worry that there's some caching going on here or something [14:03] morphis_: as it's impossible [14:04] sil2100: just checked but trunk doesn't contain any reference to lp:miracast-service anymore [14:05] I'll try another reassign [14:06] hmmm [14:24] morphis_: right now I suspect paranormal activity (tm) [14:27] hey 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:28] dbarth: will try to give you one in a minute, battling some ghosts now [14:29] sil2100: hm [14:30] sil2100: nw, ty [14:34] dbarth: assigned [14:35] morphis_: 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 anywhere [14:35] hm [14:35] morphis_: the train is just a set of scripts and it's not supposed to cache anything, especially for the prepare job [14:35] sil2100: lets try with a brand-new MP [14:35] Yeah, maybe that could work [14:36] But I even called the API directly and all was good [14:36] Might 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 sense [14:37] sil2100: https://code.launchpad.net/~morphis/aethercast/null-merge-2/+merge/280152 [14:38] sil2100: you want to add that or should I? [14:38] Let me modify the request [14:38] sigh [14:38] morphis_: the same thing... [14:39] brr [14:39] morphis_: just as an experiment, let's try building the silo [14:39] Just the aeathercast package [14:39] Let me try that with debug [14:40] No, doesn't work [14:41] This is really crazy [14:41] hm [14:41] Ah [14:41] Wait, I've got another idea [14:47] sil2100: which one? [14:49] sil2100: thanks; can you upload a source copy from this ppa please? https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages [14:50] it is oxide-qt-1.11.3-ubuntu1 [14:51] morphis_: I'm asking IS to remove one branch in case that matters, as the ci-train-bot pushed one branch-in-progress [14:51] That's probably not it though, but I'm slowly out of ideas [14:51] ok [14:51] worth a try [15:03] dbarth: in a minute [15:03] morphis_: ok, I don't see anything [15:04] morphis_: 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 branch [15:04] hm [15:04] And bzr cat --directory lp:aethercast debian/changelog returns the right thing [15:05] The only thing I could think of now is that bzr cat is somehow buffering stuff [15:05] But I called the same command in a test job on jenkins and got the right response [15:05] sil2100: is it the right jenkins instance? [15:05] Yeah, the same [15:07] robru: 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 source [15:09] robru: 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 time [15:09] robru: bzr cat of the target branch says the same [15:10] robru: 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] IT'S HAPPENING!! [15:11] pmcgowan: 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 finally [15:12] \o/ [15:12] * sil2100 still sees qtbase in excuses though, just hope it's a matter of time now [15:12] sil2100: thanks! [15:13] Mirv, great [15:14] sil2100: it's happening, but britney did some "trading" and there are remaining things broken. [15:24] sil2100: 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:28] robru: 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:29] sil2100: 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 did [15:35] dbarth: hey [15:35] dbarth: silo 57 is supposed to be for the overlay? [15:39] sil2100: yes, the vivid overlay only; the wily/xenial and desktop vivid packages are released via the security pocket as usual [15:40] dbarth: ok, just asking, since I'll have to append the ~overlay bit in that case :) [15:40] Eeek, will take a bit [15:42] robru: 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] Mirv, what happened with the rebuild of webbrowser-app against Qt 5.5.1 ? looks like the history of lp:webbrowser-app got rewritten [15:43] ok, but the UITK issue seems on track to be resolved via s390x fixes too so hopefully not much work anymore [15:45] oSoMoN: 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:46] Mirv: woohooo \o/ [15:46] oSoMoN: the other affected package is qtubuntu-camera which also had one landing while 012 was not yet cleaned [15:49] oSoMoN: 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 whole [15:49] commit is really about (or what exactly happened) http://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/revision/1295 [15:51] Mirv, 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 reconciled [15:51] oSoMoN: 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 done [15:51] oSoMoN: robru: well there most likely were two distinct trunks that now got combined in a very complex way :) [15:52] webbrowser-app is schizophrenic [15:54] robru: so basically nothing for you regarding webbrowser-app, we were just staring at the amazing work train was doing exactly correctly :) [15:55] oSoMoN: 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:57] robru, 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] I don’t expect 20151130-0ubuntu1 would overwrite 20151204-0ubuntu1 [15:58] oSoMoN: 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:59] oSoMoN: like two conflicting silos both published it seems [15:59] robru, 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 version [15:59] robru, so iiuc the changes in silo 12 are not actually published [15:59] (not the other way around) [16:00] oooohhhhh kay... [16:01] oSoMoN: 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 commits [16:03] Mirv: I don't understand why you merged without publishing [16:11] robru: you're confusing things. 012 was published last weeks, but then before merging that oSoMoN did new landings of webbrwoser-app [16:11] oSoMoN: 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 trunk [16:11] robru: oSoMoN: the 1130 release was a no-change rebuild, so it does not hurt if the changelog entry was removed [16:12] the 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 before [16:13] hmmmm ok [16:15] robru: 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-camera [16:15] well a bit different but anyway, kaleo's later landing contained the same change [16:17] oSoMoN: 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 1126 [16:17] Mirv, so the landing of 0.23+16.04.20151204-0ubuntu1 was correctly built against Qt 5.5.1 ? [16:18] robru: ok! [16:18] oSoMoN: sure, against xenial-proposed where Qt 5.5 was already at that time [16:18] excellent [16:18] so we can close the matter I think [16:19] oSoMoN: 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] but that does not directly concern you [16:21] robru: what's the PPA/bzr version mismatch https://requests.ci-train.ubuntu.com/#/ticket/771 ? I don't see any mismatches [16:21] Mirv: click the log for details [16:22] that looks like a thing that will clear in a bit [16:22] probably just wasn't quite in the PPA yet [16:22] robru: I clicked, it seems incorrect message [16:22] oh, yeah [16:23] Mirv: did you *just* build that? [16:23] robru: yes, just [16:23] Mirv: it should sort itself out next time it runs in 15 minutes then [16:23] robru: ok, I just hadn't seen that before [16:25] Mirv: 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 details [16:25] robru: ah, it's that in a new form, I've seen that before. thanks! [16:26] yw [16:30] jibel, robru, davmor2, rvr: I'll have to skip today's landing meeting [16:30] sil2100: Ok [16:30] We need to drive to the vet again, we won't make it otherwise [16:30] sil2100: let's cancel [16:31] I have nothing for that meeting [16:34] sil2100: i guess you forgot about https://wiki.ubuntu.com/citrain/LandingProcess#Renaming_a_Source_Package [16:43] morphis_: still around? [16:44] robru: yes [16:45] morphis_: 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_Package [16:46] morphis_: if you're ready to try a new build i can flush that cache real quick [16:46] robru: ah... there is a cache :-) [16:46] robru: no problem [16:46] this isn't urgent [16:46] robru: but yeah, I am ready :-) [16:48] morphis_: OK try it now [16:49] morphis_: 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 cache [16:50] robru: yeah, that is what happened [16:50] pushed lp:miracast as lp:aethercast [16:50] then did a MP with the renaming (also renaming changelog entries) [16:50] which doesn't seem to work [16:51] morphis_: 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] ok [16:51] good to know for the future :-) [16:51] morphis_: yeah it relies on the name in trunk, you can't rename it from an MP. [16:52] ok [16:52] Same thing with adding packaging for the first time, won't work unless trunk already has debian/changelog at least [16:52] I should probably figure out some way to flush the cache but that's hard, let's go shopping [16:56] morphis_: 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:58] robru: wonderful [17:01] robru: great, packages are in the silo and building [17:01] tvoss_, jhodapp, awe_: ^^ [17:01] Yay [17:01] nice! [17:01] what's the silo #? [17:02] jhodapp: 0 [17:02] thanks [17:02] Yw [17:46] trainguards: 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] sorry... I spoke too early. Here they are :-) [17:48] Trevinho: compiz is still building in ppa but the rest of the packages have been there for an hour [17:49] robru: 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:50] Trevinho: your last build only built compiz [17:51] robru: 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:52] Trevinho: 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] Trevinho: it wouldn't rebuild a failure unless there are new commits to fix the failure... [17:52] yeah... I thought it was also checking whether there had been a build failure on previous rebuild [17:53] not wrong... Although sometimes there are random failures :-D [17:53] In this case was a missing libnux package from the arm64 archive... While it should be there forever [17:53] Trevinho: those failures should be retried in the ppa, not rebuilt and reuploaded [17:54] robru: I can I do that? [17:54] Trevinho: no, you have to ask me. There's a bug open to add that feature for everybody [17:55] robru: ah, it would be cool [17:55] Yeah, lots of higher priorities unfortunately [17:58] robru: I understand... Can you then trigger a rebuild of unity for arm64? :😃 [17:58] OK [17:59] robru: thanks [17:59] Trevinho: you're welcome [18:29] morphis_, robru: did the mystical silo mystery got resolved? [18:30] robru: oh, so there was some caching in the end somewhere? [18:30] sil2100: yes, I'm surprised you forgot about the cache, it's not new [18:31] robru: didn't see it in the code, how do you clean it? [18:31] sil2100: the doc i linked has the instructions [18:32] sil2100: also if you were looking at the function, it says "@ramdisk" right there [18:32] huh, had no idea what that meant, ok [18:33] Ok, now I know what that decorator is for, I didn't even notice it really [18:35] sil2100: the clue was "disk" i guess [18:36] sil2100: the sister decorator is "@memoize", which does the same thing, only in memory, no disk storage [18:36] k [18:36] ACK, thanks [18:37] sil2100: 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 cache [18:38] Yw [19:37] renatu: humm, that looks transient, trying again: https://ci-train.ubuntu.com/job/ubuntu-landing-055-1-build/3/console [19:38] renatu: is your name short for Nosferenatu? ;-) [19:40] robru, no :D [19:40] robru, "renato" is in use already :D [19:40] ah [19:51] jhodapp: Silo 41 approved [20:00] rvr, awesome thanks [21:09] bblunch === salem_ is now known as _salem