[00:21] cjwatson: wait, notice what? everything that's in excuses.html should be reflected immediately on the ticket [00:22] cjwatson: https://requests.ci-train.ubuntu.com/#/ticket/975 <-- shows britney approved, what are you waiting for? [00:22] robru: It's there now, but when I said that at 23:47 it wasn't. [00:23] Took ~ten minutes after that to hit "Automated Signoff: Approved" [00:23] I did check [00:23] cjwatson: oh I see, right bileto doesn't get the updated britney data until the end of the run. i should really fix that so it updates it as it goes [00:23] Yeah, I thought it might be something like that [00:23] * robru files bug [00:25] Ta [00:40] cjwatson: Thanks heaps for your help! [00:40] Is there anything else we need to do? [00:41] Ticket 975 looks good now [00:49] michi: Still needs to get through QA, and we'll see what else we need to do once it's published to -proposed [00:49] But otherwise I think not [00:49] Yes. But it’s progress. Thanks again! [00:50] Having to copy from vivid as well to keep the dual-landing mode happy was a little confusing to me (though I can see why it might be hard to implement dual landings otherwise), but other than that I think this even makes sense as a workaround. [00:52] cjwatson: yeah the idea of having manual sources in a dual silo is pretty much a hack, the point of a dual silo is that it takes the same MPs and builds them once for xenial and again for vivid. [00:52] cjwatson: like the whole point of it is for keeping vivid overlay in sync with xenial development, it doesn't make sense to have a silo where only some bits are in xenial and nothing in vivid [00:53] except for this one present case, first time after years of use. [00:53] Yeah. It's a bit unfortunate that this silo combines pure rebuild stuff with (I think?) other MPs that need to go to vivid as well. [00:53] It would have made more sense to have prepared it as a xenial-only silo that just deals with the various ABI changes. [00:54] cjwatson: I might have recommended doing the xenial stuff in a separate silo that wasn't a dual silo, but meh, it's done now [00:54] And then sync up later when the dust has settled. [00:54] right [00:54] heh [00:54] But anyway, as you say, done. [00:56] trainguards: not sure what to do about this failure in autopkgtest: [00:57] https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-064/excuses.html [00:57] looks like a flaky test to me.. and not related to mir [00:57] AlbertA_: I'll retry it. [00:57] cjwatson: thanks! [00:57] (done) [01:00] cjwatson: oh actually I have a question about https://requests.ci-train.ubuntu.com/#/ticket/975 , do you know what 'DONE queue' means? that comes from asking the archive what queue it's in (eg NEW or UNAPPROVED) and it comes back "done", but if the package was copied from the release pocket it should say 'Release pocket', so I'm not sure why these packages [01:00] are "DONE" but not in release. [01:06] just checked, those "DONE" packages are copied direct from vivid, version number matches, .changes matches... not sure why train isn't catching that as 'Release pocket' [01:08] OOHHH nm, it's because it's looking in the overlay ppa, not ubuntu archive. the packages aren't in the ppa so that check fails, goes to the upload queue and finds 'DONE'. got it [01:10] i don't think that'll block anything. once published they'll be copied to overlay ppa and then the train will notice the match and say 'Release pocket' and then everything should merge all happy like [01:19] robru: I'd wondered about that myself. Thanks for working it out. [01:19] yw === rpadovani_ is now known as rpadovani [02:19] robru: right, i presumed DONE was because they were in archive not the ppa, when i saw that [02:21] yeah === robru changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Use JenkaaS: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: OTA-9.5 preparation in progress. [11:54] michi, pstolowski: hey, what's going on with the unity-scopes-api silo? [11:54] sil2100: which one? [11:54] michi, pstolowski: the PPA has mir in it... [11:55] https://requests.ci-train.ubuntu.com/#/ticket/983 [11:55] sil2100, looking on QA trello board, it's currently under testing [11:55] I think that was the one we decided to abandon last night [11:55] uh? [11:55] Because it had only the emergency fix in it. [11:56] cjwatson adhored me not to interfere, so I didn’t :) [11:56] We need this to finish the libjsoncpp transition [11:56] I thought it might help if we unbundled the scopes-api fix in a silo of its own. [11:56] e.g. disabling the ABI checker since otherwise the packages will fail to build, right? [11:56] I think you want to look at silo 37 instead [11:56] Ah [11:56] Ok [11:56] Teh same change is in there too. [11:57] Ok [11:57] Thanks [11:57] doko just pushed no-change rebuilds for all the 3 projects [11:57] So those will fail in the archive [11:58] I hate when he does that, he should have known I was taking care of the transition [11:58] michi, the standalone unity-scopes-api silo was abandoned yesterday, there is only 37 now [11:58] Do I need to do anything? [11:58] pstolowski: Exactly [11:58] pstolowski, michi: ok guys, thanks for the update [11:59] sil2100: abigail is coming along. Should have a branch with that tomorrow. [11:59] Excellent, I somehow feel so uneasy when a project drops their ABI-related checks [11:59] Even though there's not much risk [12:00] sil2100: just passed 64 [12:00] jibel: ^ [12:02] davmor2, awesome, now we have to release an OTA ;) [12:02] davmor2: wooohoo, users will be happy [12:02] Damn, too bad I don't use rc-proposed on my phone [12:02] I don't feel brave enough to switch though [12:02] sil2100, is it possible to do an OTA with 9+ just this fix? [12:02] jibel: yeah, we were thinking about that yesterday [12:03] sil2100, we should definitely do that. [12:03] jibel: it is possible as we have the hotfix snapshot ppa [12:03] jibel: you think we could also sneak in the unity8 security fix we got at the begining of OTA-9.5? [12:04] I would also release the bind, curl and libxml -security updates as well, would make jdstrand happy [12:04] sil2100: archive> can't we forcibly push those ignoring the conflict? [12:04] Need to see how much other changes the silo had [12:04] sil2100: Anyway, getting the transition moved along faster in the archive seems on balance a good thing [12:05] cjwatson: which conflict do you mean? [12:05] sil2100: the version conflict introduced by doko's rebuild-only uploads [12:06] cjwatson: that's fine, we can easily overwrite that, it's just that doko wasted time unnecessarily [12:06] His time I mean [12:06] sil2100: Almost certainly negligible, he does lots of rebuild uploads and I'm sure he has it scripted [12:16] cjwatson: ah! btw. I know this is not the place for LP questions, but do you know if it's possible to create a mailing list on Launchpad that people could subscribe to to get e-mail but sending mail would be moderated? [12:16] cjwatson: by moderated I mean, requiring approval? [12:17] sil2100: I'm not very familiar with our mailing list integration, I'm afraid. [12:17] sil2100, the "Failed to build (unity-scopes-api/xenial)." in silo 37 is the failure you expected a few minutes ago? [12:19] What. Wasn't it all fully built etc. already? [12:19] Wait [12:19] That was built and ready for testing [12:19] Anyone rebuilt that silo? [12:19] not me.. [12:19] btw. this silo is a mess, what's libjsoncpp doing in that silo? [12:20] sil2100: I put it there, that's required for autopkgtests to pass [12:20] sil2100: I spent most of yesterday getting that working, would be nice not to undo my work ;-) [12:20] Ok, phew ;) [12:20] sil2100: It's difficult because it's an interaction between a partly-complete transition in -proposed and a partial transition in this silo [12:20] sil2100: So we need to copy enough stuff into the silo so that it can be autopkgtested in isolation [12:21] i'm just a spectator of this silo since yesterday' morning ;) [12:21] cjwatson: ok, we'll have to remember to remove those from the silo before publishing not to do some silly unnecessary uploads ;) [12:21] pstolowski: the packages look built fine in the silo, so I would ignore that [12:21] sil2100: No need [12:21] sil2100: They'll be no-op copies [12:21] Let's wait for QA to test it [12:23] Yeah, I don't know why the train thinks that's a build failure. It failed on s390x, but that's true in the primary archive too [12:23] rvr: hey! Ignore the invalid status of the silo 37 [12:23] sil2100, ok.. i wasn't sure why it turned red.. wasn't red last time i checked afair [12:23] It's just some confusion [12:23] pstolowski: Indeed, it was green last night [12:23] sil2100: Ack [12:23] I think it must relate to the unity-scopes-api upload to the primary archive in some way [12:24] Maybe, not sure what checks the train is doing, maybe it wanted to fetch the version from the archive and noticed that the latest one FTBFS or something [12:24] Fetch it for diffing etc. [12:25] Could be [12:30] cjwatson: thanks for looking into that silo btw. ;) [12:38] np [12:38] ^- no more relevant/true than the previous failure [12:40] sil2100: ^ I don't think that's true, no packaging diff is there, only changelog entry. maybe robru needs to look at the new diffing logic regarding this? === alan_g is now known as alan_g|lunch [13:13] alecu: Hi [13:13] alecu: How can I test this? https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1392307 [13:13] Launchpad bug 1392307 in unity-scope-click (Ubuntu) "Can submit reviews for click apps that are not in the store" [High,In progress] [13:18] Mirv, robru: you're right [13:18] Something's wrong [13:18] Anyway, ACKing it [13:18] rvr: hi! I can't recall any such app from the top of my head. Let [13:18] rvr: let's ask dobey [13:19] robru, Mirv: btw. even though I appreciate the idea we want to get rid of jenkins for artifacts etc. but... [13:19] dobey: ^ [13:19] robru, Mirv: the current imprementation is non-optimal - when there's a packaging ACK needed, I need to go out of the jenkins page and switch back to bileto to get the actual diffs, in the past it was just on one page [13:20] robru, Mirv: besides, due to how firefox handles the .diff files, it insists he wants to save them to disk, so I no longer can easily check the contents through the browser [13:21] sil2100: yes, I noticed that too. I can open them in gedit but inline in the browser is better. but that's just about the mimetype offered I guess, should be an easy fix. [13:30] sil2100: You want https://addons.mozilla.org/en-us/firefox/addon/open-in-browser/ [13:30] Mirv: ^- [13:30] a workaround, but a useful one :-) [13:30] thank you :) === boiko_ is now known as boiko [13:54] rvr: install a package from staging, and reboot, then verify you don't see the review entry on production; or just side-load a .click that's not in our store [13:54] rvr: something from mzanetti's "open store" should not be in our store, for example [13:55] nor the open store app itself i guess [13:58] wow for QA Signoff: ready silo 32, finally autopkgtests aligned themselves in the correct order. ticket 222 is somewhat long-in-brewing silo. === alan_g|lunch is now known as alan_g [14:20] AlbertA_: hey! [14:22] AlbertA_: so, we've been wondering - your recent fix in mir for the annoying crasher, do you think it could be also cherry-picked on top of 0.18.1 ? [14:30] sil2100: oh sorry to disturb, could I get top approval for https://code.launchpad.net/~timo-jyrinki/ubuntu-touch-session/qt_networkmanager_bearer/+merge/272568 ? it is an environment variable that retains status quo while upstream code changed a bit and we don't anymore apply distro specific forcing. [14:31] Mirv: lemme look :) [14:31] or point towards correct persion. the env var itself is of course Qt specific, the placement of it should be familiar to people familiar with ubuntu-touch-session (I got the info originally from og_ra) [14:33] hm, I never really did any reviews there, maybe we could ask morphis for a quick review? [14:34] sil2100: for what? === mhall119_ is now known as mhall119 [14:36] morphis: https://code.launchpad.net/~timo-jyrinki/ubuntu-touch-session/qt_networkmanager_bearer/+merge/272568 - sil2100 probably just observed you have committed things there before [14:37] dobey: Ok, thanks. I checked that with the silo packages, Open Store can't be reviewed in the App Store. Nor it shows any info. [14:37] alecu: ^ [14:37] Mirv: ok, let me have a quick look [14:38] Mirv: what does the variable do? [14:38] forces us to use the network manager bearer? [14:38] morphis: it makes Qt use the same network manager bearer backend that we have currently hard-coded via distro specific patch. but we now got instead upstream support for enabling it via environment variable [14:38] aye [14:38] Mirv: approved [14:38] morphis: thank you! [14:39] morphis: can you top-approve as well? [14:39] sure [14:39] done [14:39] thanks, the silo is ready otherwise for testing [14:40] rvr: great. that's correct behavior; previously the review entry was showing for .click apps that aren't in the store [14:51] dobey: Ok [14:52] pstolowski: erk, changing that again? [14:52] pstolowski: oh, never mind, different ticket :) [14:53] yeah :) === vrruiz_ is now known as rvr [15:00] alecu: This is weird. I can't see anything in the App Store now. [15:01] alecu: It's not my internet connection, because with another device I can. [15:01] alecu: I thought Open Store did something, so uninstalled the package. [15:02] alecu: There is no crash file [15:02] weird [15:02] dobey: ^ [15:04] dobey: Is there any log I can check? [15:05] sil2100: I have to check if it would be a similar deadlock issue [15:05] AlbertA_: hey! I guess we're basically decided to pull in the whole mir so for now don't worry about it :) [15:06] Dispatching search: "com.canonical.scopes.clickstore" "Dekko" "" [15:06] flushUpdates: "com.canonical.scopes.clickstore" #results = 0 finalize: true [15:06] Dispatching search: "com.canonical.scopes.clickstore" "" "" [15:06] flushUpdates: "com.canonical.scopes.clickstore" #results = 0 finalize: true [15:06] But no result is shown [15:07] Rebooting [15:07] sil2100: nice thanks! [15:08] rvr: ~/.cache/upstart/scope-registry.log is it [15:09] rvr: yes, results = 0 means there are no results; the scope is unfortunately blank in that situation. there's a bug about empty results, but having a little trouble finding the # right now [15:10] not sure why empty search or dekko would show no results though, without a network error or something similar [15:10] dobey: I couldn't get any result [15:10] After reboot, it's ok [15:11] rvr: right; i'm saying the behavior is expected when there are 0 results, but the 0 results for the queries in the log you pasted are not expected, and i don't see why you got that, when there's no error next to it about network or something [15:14] dobey: Hmm [15:15] rvr: almost done with silo 37 testing I see? ;) [15:16] sil2100: He [15:16] dobey: I see what happens [15:17] rvr: oh? [15:18] dobey: I was testing the flight mode [15:18] After reconnecting, I couldn't get any results [15:18] But I don't know whether it was a problem with the device connection or with the scope [15:20] rvr: ah, that is probably an issue with the qt backend thing that talks to n-m [15:22] dobey: Yeah, cannot reproduce with similar steps. I'll continue testing. [15:26] rvr: either way, it is known that there are some issues with the qt network-manager plug-in bits, that sometimes result in the behavior you described; and they are not specific to the scope. the click scope happens to use qtnetwork, so it tends to hit these issues, while other scopes which don't use qtnetwork don't necesarily [15:27] dobey: Yes... I really hate the Telegram app, because of that problem :) [15:27] Sometimes I have to restart the app to get new messages [15:55] dobey: Again, no results [15:56] dobey: I can navigate with the webbrowser [15:59] rvr: switching between network types (or off for flight mode)? [15:59] dobey: No switching this time [15:59] rvr: and what's in the log? [15:59] rvr: and what kind of connection are you on? [16:00] dobey: Wifi [16:06] rvr: how did you get to the point of no results? what's in the logs? [16:08] dobey: https://pastebin.canonical.com/149604/ [16:10] dobey: I don't know exactly what triggers this [16:10] :-/ [16:10] 2016-02-11 15:43:36,078 - WARNING - Network error: "Error downloading https://search.apps.ubuntu.com/api/v1/package/com.ubuntu.developer.webapps.webapp-amazon-int - server replied: Not Found (203)" [16:10] hmm [16:10] I installed another app, and I was trying to install an scope [16:11] 2016-02-11 15:19:39,111 - WARNING - QDBusConnection: error: could not send message to service "org.freedesktop.NetworkManager" path "/org/freedesktop/NetworkManager" interface "org.freedesktop.NetworkManager" member "ActivateConnection": Marshalling failed: Invalid object path passed in arguments [16:11] hmm [16:11] rvr: that seems like an issue in the n-m integration [16:13] dobey: Hmm [16:14] trainguards, can you please delete ubuntu-system-settings from silo 51? thanks [16:14] Saviq: on it! [16:15] rvr: i have been sitting here refreshing the results for the store for like 10 minutes straight and it's always giving me results; so i can't seem to recreate this issue. looking at your logs it seems this is probably related to the known issues with the qnetwork plug-in we have for ubuntu, and not a regression from the silo (which has no actual network connection related changes anyway). if you can find some way to force the i [16:15] sil2100, oh, and qtubuntu, too, please [16:15] Saviq: with gles of course? On it [16:15] sil2100, yup [16:16] All done [16:16] rvr: hmm, i see some apparmor denials in your log too, but i'm not sure if those are for the click scope or something else (maybe euronews) [16:18] dobey: I can't uninstall euronews scope [16:18] I mean [16:18] I can [16:18] rvr: i don't think you need to uninstall it. it's installed by defauled on the bq phones right? [16:19] dobey: Right [16:19] dobey: But, how to know whether it is the click scope or something else? [16:19] rvr: it shouldn't be causing the click scope to have issues, since it's in a separate process [16:19] rvr: well i don't know how euronews is implemented; maybe it's using qtnetwork too [16:20] rvr: i was just pointing out what i saw in your log [16:20] Ack [16:23] rvr: if you can find some way to reliably recreate the issue so that i can debug it further, i would be happy to, but i think we should treat this as a known problem not caused by this silo, and not block on it further for now, so we can get the critical fixes this silo provides through [16:23] dobey: That's what I am trying to do. [16:24] dobey: An interesting thing is that click scope has no connection back after I switch off/on the device, or the flight mode. [16:28] that's very odd indeed [16:29] but even switching flight mode on/off, i can't recreate a situation where i get no results, on my mako [16:30] rvr: you are testing on rc-proposed right? [16:30] dobey: Yes [16:33] rvr: very weird. maybe something else wrong with your device? i really don't have any other suggestsions because i don't know what's going on there. can we maybe set aside some time to try to debug these issues later, and move ahead with getting 37 landed? [16:34] i really need to take my lunch (which is already being cut short) now [16:34] dobey: I'll keep trying. It's the second time that happens, so I don't feel comfortable landing it without knowing a little bit more. I'll take a look without the silo. [16:35] rvr: ok, well there are definitely no changes in the silo which would cause that [16:36] i'll be back in ~1hr [17:02] jibel, davmor2, rvr, robru: anything to discuss on the LT meeting? [17:03] Since I'm alone here but not sure if you guys want to sync up [17:03] There's not too much currently [17:14] robru, hey, Q: I've often recently seen a situation like https://requests.ci-train.ubuntu.com/#/ticket/938 [17:14] robru, where a build job finished a moment ago [17:14] but bileto still says "preparing" [17:14] what's more the diffs are inaccessible (unauthorized), not sure if that's related [17:15] hah, now they are again [17:27] sil2100, can you answer https://code.launchpad.net/~mterry/langpack-o-matic/pam-touch/+merge/285657/comments/726880 ? [17:38] Saviq: let me take a look in a moment [17:57] hmm [17:58] rvr: any luck/progress with the silo? [17:59] dobey: I'm checking with and without it === alan_g is now known as alan_g|EOD [17:59] ok [18:01] Saviq, I talked with pitti this morning about it, I'm going to do some investigation [18:01] Saviq, (re: langomatic) [18:02] mterry, ack [18:33] robru, found a corner case where citrain device-upgrade fails [18:42] Saviq: oh yeah? well i found a corner case in your face! [18:42] OUCH [18:42] ;) [18:43] robru, just FYI: package A in silo, depending on package B in archive, if required B version is bumped in A in silo, but B is already there on the image, apt bails out [18:44] Saviq: re: diffs & status, that's all expected. the swift container that holds the diffs takes a minute to become public (takes a minute to propagate through all the caches), and then the status is only updated by a job that runs every 15 minutes, the end of the build job just leaves it as 'Preparing' [18:44] robru, 15 minutes!? that's lifetime! [18:44] Saviq: yeah it usually takes 10 minutes to even run so I couldn't make it much more often than that. I need to implement some caching to speed that up [18:45] Saviq: I don't understand your device-upgrade failure, is there a live silo i can see this on? [18:46] robru, yeah, just try to upgrade from 51 [18:47] robru, case in point: mir got upgraded just today to 0.19.2, qtmir in silo 51 got rebuilt with new mir, so it now depends on mir 0.19.2 (it wouldn't have to, but dpkg errs on the safe side) [18:48] robru, so now apt tries to pull in new qtmir-android from the silo, that depends on mir >= 0.19.2, but there is a mir 0.19.1 already on the phone [18:48] robru, apt decides to not upgrade mir because of pinning, so BOOM [18:48] Saviq: the apt pinning means it should take everything in the silo every time... [18:49] robru, yes, it's about the dependency of what's in silo [18:49] Saviq: I thought you said you copied all the new deps into the silo? [18:49] robru, it seems the setup we have will only pull _new_ packages from archive, not [18:49] robru, nope [18:49] Saviq: well you should do that ;-) [18:49] not new versions of deps [18:49] robru: face> https://www.youtube.com/watch?v=_tt0cuTQvvk&feature=youtu.be&t=86 [18:49] robru, except that new dep is already in archive [18:50] robru, so without pinning everything's golden [18:50] s/new dep/updated dep/ [18:51] Saviq: is the problematic package in the overlay ppa? [18:51] robru, yes, actually [18:51] Saviq: yeah, that's why, the overlay ppa is pinned higher than the archive. [18:51] robru, but but, I think it was the same on xenial, so no overlay involved [18:51] Saviq: so if there's something new you need from the archive you need to copy it into your silo [18:52] robru, well, archive == overlay in my mind :P [18:52] in this case [18:52] robru, let me verify on xenial [18:54] cjwatson: heh [19:09] dobey: I got this emptiness in the Amazon scope in OTA9. Maybe something is wrong with the server ? [19:10] rvr: i don't know about the amazon scope. if something is wrong with remote scopes server it doesn't necessarily mean the store will have issues [19:18] robru, yup, same on xenial: https://paste.ubuntu.com/15018345/ and then I can force: http://pastebin.ubuntu.com/15018373/ [19:18] biab [19:21] Saviq: yeah I dunno, that force you do in the second diff sounds like you're overriding the pinning, which is in place because $REASONS that I can't remember. [19:21] Saviq: I recommend you copy the needed packages into the silo for testing (or I guess you need me to do that). what are the packages specifically? [19:23] dobey: sil2100: Silo 37 approved. [19:25] rvr: yay, thanks!!! [19:31] robru: hey, what does "Silo has bad status" mean for publish failure? [19:31] dobey: it probably has a build failure or something? read the status. [19:32] huh [19:32] wtf [19:32] nooooooooooo [19:33] robru: hmm, for some reason it's caring about the s390x builds now [19:33] robru: but those have never been successful here [19:33] dobey: that should only happen if there's a) a successful s390x build in the archive, or b) this is the first time this package has ever been released to ubuntu [19:34] dobey: what package? [19:34] robru: unity-scopes-api [19:34] and unity-scope-mediascanner has a depwait on it [19:34] oh [19:34] and Destination version 0.1.1+16.04.20160128-0ubuntu2 is missing from changelog (unity-scope-click/xenial). [19:34] huh [19:35] that is a lie [19:36] mayve if i DIFF_ONLY again? [19:36] dobey: diff only isn't going to change your changelog [19:36] dobey: sil2100 asked me to ping him to publish the silo [19:37] robru: but the changelog isn't missing the entry! [19:37] hmm ok [19:37] dobey: so I guess the train is looking at this: https://launchpad.net/ubuntu/+source/unity-scopes-api/1.0.2+16.04.20151218.2-0ubuntu2 seeing "no arches with successful builds" and thinking this is equivalent to "this package never released in ubuntu" and then expecting it to work on all arches. [19:37] dobey: what silo? [19:38] oh damnit doko [19:38] robru: 37 [19:38] fml now i'm going to have to shove that into scopes-api trunk and rebuild the silo aren't i? [19:38] oh and for unity-scope-click too [19:38] grrrrrrrrrrrrrrrrr [19:39] aaaaaaaand probably mediascanner [19:40] dobey: http://bazaar.launchpad.net/~ci-train-bot/unity-scope-click/unity-scope-click-ubuntu-xenial-landing-037/view/head:/debian/changelog Ctrl+F 0.1.1+16.04.20160128-0ubuntu2 not found [19:40] robru: yeah i just now saw that doko uploaded no-change rebuilds of everything this morning [19:40] and it fucked our silo up :( [19:40] dobey: I wouldn't bother rebuilding just for a no-change, just publish over it and clobber the changelog. [19:41] robru: i guess we need sil2100 for that though? [19:41] or can we get kenvandine to do it? :) [19:42] dobey: I don't think publishing blocks on "dest version missing from changelog" but it does block on "failed to build" and probably "dependency wait" so yeah basically if you're sure this silo is publishable you're going to need a core dev to copy it to -proposed manually because the train isn't going to touch this hot mess. [19:43] kenvandine: heeeeeeey. can you help us? :) [19:43] and whoever does that copying should not bother to copy the ones that say "diff (0 lines)" as those are no-ops [19:43] robru: well rvr *just* approved it after having been testing it all day [19:45] robru: once they've been copied to xenial-proposed though, i can run publish and it'll do the rest of the work to land stuff in overlay for vivid? [19:46] dobey: dunno. [19:47] dobey: I guess? the vivid ones all say 'successfully built', so if you can make the xenial failures go away by copying manually to -proposed then it might work [19:47] dobey: note that a bunch of that stuff you actually don't want in vivid overlay [19:47] dobey: probably best to just copy everything [19:49] well, really i guess it doesn't much matter if the vivid jsoncpp/capnproto are in the overlay or not; worst case they'll take a couple MB of space there [19:49] but sure [19:51] robru, think that's really needed? will that not then play havoc when landing? [19:52] robru, or do you mean that we should remove from silo before landing? [19:52] dobey: if they're in the overlay then future SRUs of those packages will be ignored [19:52] Saviq: when publishing a silo it only copies stuff that's actually newer than what's in the destination, so it'll harmlessly skip stuff you copied in from the archive [19:53] robru: oh, because the image building script has apt pinning of priority? [19:53] robru, ok then, please copy mir 0.19.2 to silo 51 [19:53] dobey: yes [19:53] robru, from vivid/overlay and xenial [19:53] robru: well, no SRUs are going to be published for it either, since 15.04 is EOL. so all "SRUs" there will go to overlay anyway :) [19:55] dobey: oh, true, then i guess it doesn't matter [19:55] robru: or i guess you can delete those extra things that were copied in, from the silo now, and then we just force publish it [19:56] hmm [19:57] Saviq: ok copied, give it a few minutes to "publish" (in the ppa sense not the train sense) [19:57] robru, yup yup [19:57] tx [19:57] yw [19:57] dobey: I'd rather not touch this silo seeing as I don't have permission to publish it anyway. [19:58] ok [20:32] robru: great. doko was still around, so i asked him to copy the packages to xenial-proposed and he's done it now :) [20:33] great [20:56] hmm [21:06] robru: can you delete capnproto, cmake, libjsoncpp, and ubuntu-touch-meta from slio 37 ppa? then i think i should be able publish ok perhpas? [21:07] dobey: looking [21:13] dobey: ok try now [21:26] robru: oh, looks like it's complaining about the diff due to the override of the no-change uploads, now; i guess you can probably copy the remaining vivid packages over to overlay though? [21:26] robru: also, we need to come up with a better way to deal with these such issues in the future. this has been incredibly painful to get through :) [21:39] dobey: yeah I don't really have a clear understanding of what the issues were. michi started an email thread about it, were you cc'd on that? [21:39] robru: i was cc:ed on a few threads, yeah [21:40] i don't know which one you're specifically referring to though. the jsoncpp one? [21:40] yeah [21:41] robru: ah, so that was just him being overly cautious in asking about it. the jsoncpp abi only broke on xenial. we aren't putting the new jsoncpp into the overlay. and most scopes in the store are going to just crash on xenial anyway, because of gcc5 [21:42] dobey: ok copied. yeah there seems to be a bug in publishing at the moment, I'll have to dig in a bit [21:42] a bug? [21:43] dobey: yeah this is the second time I've seen this, it prevented you from publishing due to a "packaging diff" but there wasn't one [21:43] at least not for the package indicated [21:43] robru: well, does it consider removing a changelog entry a "packaging diff" ? [21:44] hmm, i guess not [21:44] dobey: no, a "packaging diff" is any change under debian/ not including debian/changelog. if you look at the list of artifacts on your request there just isn't a unity-scopes-mediascanner packaging changes.diff [21:45] so i'm not sure why the train thinks it is. started happening when I ported everything to swift, so I guess I'm using swift wrong somehow [21:46] brb tho [21:46] robru: i wonder if maybe we should do another diff_only rebuild to clean things up a little now that the copied archive packages have been removed from the ppa [21:50] robru: or maybe i should just force merge now and go on about my life [22:19] or maybe it'll just do that automatically once things migrate [22:19] anyawy, i have to go now [22:19]