robrucjwatson: wait, notice what? everything that's in excuses.html should be reflected immediately on the ticket00:21
robrucjwatson: https://requests.ci-train.ubuntu.com/#/ticket/975 <-- shows britney approved, what are you waiting for?00:22
cjwatsonrobru: It's there now, but when I said that at 23:47 it wasn't.00:22
cjwatsonTook ~ten minutes after that to hit "Automated Signoff: Approved"00:23
cjwatsonI did check00:23
robrucjwatson: 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 goes00:23
cjwatsonYeah, I thought it might be something like that00:23
* robru files bug00:23
michicjwatson: Thanks heaps for your help!00:40
michiIs there anything else we need to do?00:40
michiTicket 975 looks good now00:41
cjwatsonmichi: Still needs to get through QA, and we'll see what else we need to do once it's published to -proposed00:49
cjwatsonBut otherwise I think not00:49
michiYes. But it’s progress. Thanks again!00:49
cjwatsonHaving 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:50
robrucjwatson: 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
robrucjwatson: 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 vivid00:52
robruexcept for this one present case, first time after years of use.00:53
cjwatsonYeah.  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
cjwatsonIt would have made more sense to have prepared it as a xenial-only silo that just deals with the various ABI changes.00:53
robrucjwatson: I might have recommended doing the xenial stuff in a separate silo that wasn't a dual silo, but meh, it's done now00:54
cjwatsonAnd then sync up later when the dust has settled.00:54
cjwatsonBut anyway, as you say, done.00:54
AlbertA_trainguards: not sure what to do about this failure in autopkgtest:00:56
AlbertA_looks like a flaky test to me.. and not related to mir00:57
cjwatsonAlbertA_: I'll retry it.00:57
AlbertA_cjwatson: thanks!00:57
robrucjwatson: 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 packages01:00
robruare "DONE" but not in release.01:00
robrujust 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:06
robruOOHHH 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 it01:08
robrui 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 like01:10
cjwatsonrobru: I'd wondered about that myself.  Thanks for working it out.01:19
=== rpadovani_ is now known as rpadovani
dobeyrobru: right, i presumed DONE was because they were in archive not the ppa, when i saw that02:19
=== 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.
sil2100michi, pstolowski: hey, what's going on with the unity-scopes-api silo?11:54
michisil2100: which one?11:54
sil2100michi, pstolowski: the PPA has mir in it...11:54
pstolowskisil2100, looking on QA trello board, it's currently under testing11:55
michiI think that was the one we decided to abandon last night11:55
michiBecause it had only the emergency fix in it.11:55
michicjwatson adhored me not to interfere, so I didn’t :)11:56
sil2100We need this to finish the libjsoncpp transition11:56
michiI thought it might help if we unbundled the scopes-api fix in a silo of its own.11:56
sil2100e.g. disabling the ABI checker since otherwise the packages will fail to build, right?11:56
michiI think you want to look at silo 37 instead11:56
michiTeh same change is in there too.11:56
sil2100doko just pushed no-change rebuilds for all the 3 projects11:57
sil2100So those will fail in the archive11:57
sil2100I hate when he does that, he should have known I was taking care of the transition11:58
pstolowskimichi, the standalone unity-scopes-api silo was abandoned yesterday, there is only 37 now11:58
michiDo I need to do anything?11:58
michipstolowski: Exactly11:58
sil2100pstolowski, michi: ok guys, thanks for the update11:58
michisil2100: abigail is coming along. Should have a branch with that tomorrow.11:59
sil2100Excellent, I somehow feel so uneasy when a project drops their ABI-related checks11:59
sil2100Even though there's not much risk11:59
davmor2sil2100: just passed 6412:00
davmor2jibel: ^12:00
jibeldavmor2, awesome, now we have to release an OTA ;)12:02
sil2100davmor2: wooohoo, users will be happy12:02
sil2100Damn, too bad I don't use rc-proposed on my phone12:02
sil2100I don't feel brave enough to switch though12:02
jibelsil2100, is it possible to do an OTA with 9+ just this fix?12:02
sil2100jibel: yeah, we were thinking about that yesterday12:02
jibelsil2100, we should definitely do that.12:03
sil2100jibel: it is possible as we have the hotfix snapshot ppa12:03
sil2100jibel: you think we could also sneak in the unity8 security fix we got at the begining of OTA-9.5?12:03
sil2100I would also release the bind, curl and libxml -security updates as well, would make jdstrand happy12:04
cjwatsonsil2100: archive> can't we forcibly push those ignoring the conflict?12:04
sil2100Need to see how much other changes the silo had12:04
cjwatsonsil2100: Anyway, getting the transition moved along faster in the archive seems on balance a good thing12:04
sil2100cjwatson: which conflict do you mean?12:05
cjwatsonsil2100: the version conflict introduced by doko's rebuild-only uploads12:05
sil2100cjwatson: that's fine, we can easily overwrite that, it's just that doko wasted time unnecessarily12:06
sil2100His time I mean12:06
cjwatsonsil2100: Almost certainly negligible, he does lots of rebuild uploads and I'm sure he has it scripted12:06
sil2100cjwatson: 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
sil2100cjwatson: by moderated I mean, requiring approval?12:16
cjwatsonsil2100: I'm not very familiar with our mailing list integration, I'm afraid.12:17
pstolowskisil2100, the "Failed to build (unity-scopes-api/xenial)." in silo 37 is the failure you expected a few minutes ago?12:17
cjwatsonWhat.  Wasn't it all fully built etc. already?12:19
sil2100That was built and ready for testing12:19
sil2100Anyone rebuilt that silo?12:19
pstolowskinot me..12:19
sil2100btw. this silo is a mess, what's libjsoncpp doing in that silo?12:19
cjwatsonsil2100: I put it there, that's required for autopkgtests to pass12:20
cjwatsonsil2100: I spent most of yesterday getting that working, would be nice not to undo my work ;-)12:20
sil2100Ok, phew ;)12:20
cjwatsonsil2100: It's difficult because it's an interaction between a partly-complete transition in -proposed and a partial transition in this silo12:20
cjwatsonsil2100: So we need to copy enough stuff into the silo so that it can be autopkgtested in isolation12:20
pstolowskii'm just a spectator of this silo since yesterday' morning ;)12:21
sil2100cjwatson: ok, we'll have to remember to remove those from the silo before publishing not to do some silly unnecessary uploads ;)12:21
sil2100pstolowski: the packages look built fine in the silo, so I would ignore that12:21
cjwatsonsil2100: No need12:21
cjwatsonsil2100: They'll be no-op copies12:21
sil2100Let's wait for QA to test it12:21
cjwatsonYeah, 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 too12:23
sil2100rvr: hey! Ignore the invalid status of the silo 3712:23
pstolowskisil2100, ok.. i wasn't sure why it turned red.. wasn't red last time i checked afair12:23
sil2100It's just some confusion12:23
cjwatsonpstolowski: Indeed, it was green last night12:23
rvrsil2100: Ack12:23
cjwatsonI think it must relate to the unity-scopes-api upload to the primary archive in some way12:23
sil2100Maybe, 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 something12:24
sil2100Fetch it for diffing etc.12:24
cjwatsonCould be12:25
sil2100cjwatson: thanks for looking into that silo btw. ;)12:30
cjwatson^- no more relevant/true than the previous failure12:38
Mirvsil2100: ^ 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?12:40
=== alan_g is now known as alan_g|lunch
rvralecu: Hi13:13
rvralecu: How can I test this? https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/139230713:13
ubot5`Launchpad bug 1392307 in unity-scope-click (Ubuntu) "Can submit reviews for click apps that are not in the store" [High,In progress]13:13
sil2100Mirv, robru: you're right13:18
sil2100Something's wrong13:18
sil2100Anyway, ACKing it13:18
alecurvr: hi! I can't recall any such app from the top of my head. Let13:18
alecurvr: let's ask dobey13:18
sil2100robru, Mirv: btw. even though I appreciate the idea we want to get rid of jenkins for artifacts etc. but...13:19
rvrdobey: ^13:19
sil2100robru, 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 page13:19
sil2100robru, 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 browser13:20
Mirvsil2100: 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:21
cjwatsonsil2100: You want https://addons.mozilla.org/en-us/firefox/addon/open-in-browser/13:30
cjwatsonMirv: ^-13:30
cjwatsona workaround, but a useful one :-)13:30
Mirvthank you :)13:30
=== boiko_ is now known as boiko
dobeyrvr: 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 store13:54
dobeyrvr: something from mzanetti's "open store" should not be in our store, for example13:54
dobeynor the open store app itself i guess13:55
Mirvwow for QA Signoff: ready silo 32, finally autopkgtests aligned themselves in the correct order. ticket 222 is somewhat long-in-brewing silo.13:58
=== alan_g|lunch is now known as alan_g
sil2100AlbertA_: hey!14:20
sil2100AlbertA_: 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:22
Mirvsil2100: 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:30
sil2100Mirv: lemme look :)14:31
Mirvor 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:31
sil2100hm, I never really did any reviews there, maybe we could ask morphis for a quick review?14:33
morphissil2100: for what?14:34
=== mhall119_ is now known as mhall119
Mirvmorphis: https://code.launchpad.net/~timo-jyrinki/ubuntu-touch-session/qt_networkmanager_bearer/+merge/272568 - sil2100 probably just observed you have committed things there before14:36
rvrdobey: 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
rvralecu: ^14:37
morphisMirv: ok, let me have a quick look14:37
morphisMirv: what does the variable do?14:38
morphisforces us to use the network manager bearer?14:38
Mirvmorphis: 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 variable14:38
morphisMirv: approved14:38
Mirvmorphis: thank you!14:38
Mirvmorphis: can you top-approve as well?14:39
Mirvthanks, the silo is ready otherwise for testing14:39
dobeyrvr: great. that's correct behavior; previously the review entry was showing for .click apps that aren't in the store14:40
rvrdobey: Ok14:51
cjwatsonpstolowski: erk, changing that again?14:52
cjwatsonpstolowski: oh, never mind, different ticket :)14:52
pstolowskiyeah :)14:53
=== vrruiz_ is now known as rvr
rvralecu: This is weird. I can't see anything in the App Store now.15:00
rvralecu: It's not my internet connection, because with another device I can.15:01
rvralecu: I thought Open Store did something, so uninstalled the package.15:01
rvralecu: There is no crash file15:02
alecudobey: ^15:02
rvrdobey: Is there any log I can check?15:04
AlbertA_sil2100: I have to check if it would be a similar deadlock issue15:05
sil2100AlbertA_: hey! I guess we're basically decided to pull in the whole mir so for now don't worry about it :)15:05
rvrDispatching search: "com.canonical.scopes.clickstore" "Dekko" ""15:06
rvrflushUpdates: "com.canonical.scopes.clickstore" #results = 0 finalize: true15:06
rvrDispatching search: "com.canonical.scopes.clickstore" "" ""15:06
rvrflushUpdates: "com.canonical.scopes.clickstore" #results = 0 finalize: true15:06
rvrBut no result is shown15:06
AlbertA_sil2100: nice thanks!15:07
dobeyrvr: ~/.cache/upstart/scope-registry.log is it15:08
dobeyrvr: 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 now15:09
dobeynot sure why empty search or dekko would show no results though, without a network error or something similar15:10
rvrdobey: I couldn't get any result15:10
rvrAfter reboot, it's ok15:10
dobeyrvr: 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 something15:11
rvrdobey: Hmm15:14
sil2100rvr: almost done with silo 37 testing I see? ;)15:15
rvrsil2100: He15:16
rvrdobey: I see what happens15:16
dobeyrvr: oh?15:17
rvrdobey: I was testing the flight mode15:18
rvrAfter reconnecting, I couldn't get any results15:18
rvrBut I don't know whether it was a problem with the device connection or with the scope15:18
dobeyrvr: ah, that is probably an issue with the qt backend thing that talks to n-m15:20
rvrdobey: Yeah, cannot reproduce with similar steps. I'll continue testing.15:22
dobeyrvr: 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 necesarily15:26
rvrdobey: Yes... I really hate the Telegram app, because of that problem :)15:27
rvrSometimes I have to restart the app to get new messages15:27
rvrdobey: Again, no results15:55
rvrdobey: I can navigate with the webbrowser15:56
dobeyrvr: switching between network types (or off for flight mode)?15:59
rvrdobey: No switching this time15:59
dobeyrvr: and what's in the log?15:59
dobeyrvr: and what kind of connection are you on?15:59
rvrdobey: Wifi16:00
dobeyrvr: how did you get to the point of no results? what's in the logs?16:06
rvrdobey: https://pastebin.canonical.com/149604/16:08
rvrdobey: I don't know exactly what triggers this16:10
dobey2016-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
rvrI installed another app, and I was trying to install an scope16:10
dobey2016-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 arguments16:11
dobeyrvr: that seems like an issue in the n-m integration16:11
rvrdobey: Hmm16:13
Saviqtrainguards, can you please delete ubuntu-system-settings from silo 51? thanks16:14
sil2100Saviq: on it!16:14
dobeyrvr: 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 i16:15
Saviqsil2100, oh, and qtubuntu, too, please16:15
sil2100Saviq: with gles of course? On it16:15
Saviqsil2100, yup16:15
sil2100All done16:16
dobeyrvr: 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:16
rvrdobey: I can't uninstall euronews scope16:18
rvrI mean16:18
rvrI can16:18
dobeyrvr: i don't think you need to uninstall it. it's installed by defauled on the bq phones right?16:18
rvrdobey: Right16:19
rvrdobey: But, how to know whether it is the click scope or something else?16:19
dobeyrvr: it shouldn't be causing the click scope to have issues, since it's in a separate process16:19
dobeyrvr: well i don't know how euronews is implemented; maybe it's using qtnetwork too16:19
dobeyrvr: i was just pointing out what i saw in your log16:20
dobeyrvr: 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 through16:23
rvrdobey: That's what I am trying to do.16:23
rvrdobey: An interesting thing is that click scope has no connection back after I switch off/on the device, or the flight mode.16:24
dobeythat's very odd indeed16:28
dobeybut even switching flight mode on/off, i can't recreate a situation where i get no results, on my mako16:29
dobeyrvr: you are testing on rc-proposed right?16:30
rvrdobey: Yes16:30
dobeyrvr: 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:33
dobeyi really need to take my lunch (which is already being cut short) now16:34
rvrdobey: 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:34
dobeyrvr: ok, well there are definitely no changes in the silo which would cause that16:35
dobeyi'll be back in ~1hr16:36
sil2100jibel, davmor2, rvr, robru: anything to discuss on the LT meeting?17:02
sil2100Since I'm alone here but not sure if you guys want to sync up17:03
sil2100There's not too much currently17:03
Saviqrobru, hey, Q: I've often recently seen a situation like https://requests.ci-train.ubuntu.com/#/ticket/93817:14
Saviqrobru, where a build job finished a moment ago17:14
Saviqbut bileto still says "preparing"17:14
Saviqwhat's more the diffs are inaccessible (unauthorized), not sure if that's related17:14
Saviqhah, now they are again17:15
Saviqsil2100, can you answer https://code.launchpad.net/~mterry/langpack-o-matic/pam-touch/+merge/285657/comments/726880 ?17:27
sil2100Saviq: let me take a look in a moment17:38
dobeyrvr: any luck/progress with the silo?17:58
rvrdobey: I'm checking with and without it17:59
=== alan_g is now known as alan_g|EOD
mterrySaviq, I talked with pitti this morning about it, I'm going to do some investigation18:01
mterrySaviq, (re: langomatic)18:01
Saviqmterry, ack18:02
Saviqrobru, found a corner case where citrain device-upgrade fails18:33
robruSaviq: oh yeah? well i found a corner case in your face!18:42
Saviqrobru, 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 out18:43
robruSaviq: 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
Saviqrobru, 15 minutes!? that's lifetime!18:44
robruSaviq: 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 up18:44
robruSaviq: I don't understand your device-upgrade failure, is there a live silo i can see this on?18:45
Saviqrobru, yeah, just try to upgrade from 5118:46
Saviqrobru, 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:47
Saviqrobru, 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 phone18:48
Saviqrobru, apt decides to not upgrade mir because of pinning, so BOOM18:48
robruSaviq: the apt pinning means it should take everything in the silo every time...18:48
Saviqrobru, yes, it's about the dependency of what's in silo18:49
robruSaviq: I thought you said you copied all the new deps into the silo?18:49
Saviqrobru, it seems the setup we have will only pull _new_ packages from archive, not18:49
Saviqrobru, nope18:49
robruSaviq: well you should do that ;-)18:49
Saviqnot new versions of deps18:49
cjwatsonrobru: face> https://www.youtube.com/watch?v=_tt0cuTQvvk&feature=youtu.be&t=8618:49
Saviqrobru, except that new dep is already in archive18:49
Saviqrobru, so without pinning everything's golden18:50
Saviqs/new dep/updated dep/18:50
robruSaviq: is the problematic package in the overlay ppa?18:51
Saviqrobru, yes, actually18:51
robruSaviq: yeah, that's why, the overlay ppa is pinned higher than the archive.18:51
Saviqrobru, but but, I think it was the same on xenial, so no overlay involved18:51
robruSaviq: so if there's something new you need from the archive you need to copy it into your silo18:51
Saviqrobru, well, archive == overlay in my mind :P18:52
Saviqin this case18:52
Saviqrobru, let me verify on xenial18:52
robrucjwatson: heh18:54
rvrdobey: I got this emptiness in the Amazon scope in OTA9. Maybe something is wrong with the server ?19:09
dobeyrvr: 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 issues19:10
Saviqrobru, yup, same on xenial: https://paste.ubuntu.com/15018345/ and then I can force: http://pastebin.ubuntu.com/15018373/19:18
robruSaviq: 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
robruSaviq: 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:21
rvrdobey: sil2100: Silo 37 approved.19:23
dobeyrvr: yay, thanks!!!19:25
dobeyrobru: hey, what does "Silo has bad status" mean for publish failure?19:31
robrudobey: it probably has a build failure or something? read the status.19:31
dobeyrobru: hmm, for some reason it's caring about the s390x builds now19:33
dobeyrobru: but those have never been successful here19:33
robrudobey: 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 ubuntu19:33
robrudobey: what package?19:34
dobeyrobru: unity-scopes-api19:34
dobeyand unity-scope-mediascanner has a depwait on it19:34
dobeyand Destination version 0.1.1+16.04.20160128-0ubuntu2 is missing from changelog (unity-scope-click/xenial).19:34
dobeythat is a lie19:35
dobeymayve if i DIFF_ONLY again?19:36
robrudobey: diff only isn't going to change your changelog19:36
rvrdobey: sil2100 asked me to ping him to publish the silo19:36
dobeyrobru: but the changelog isn't missing the entry!19:37
dobeyhmm ok19:37
robrudobey: 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
robrudobey: what silo?19:37
dobeyoh damnit doko19:38
dobeyrobru: 3719:38
dobeyfml now i'm going to have to shove that into scopes-api trunk and rebuild the silo aren't i?19:38
dobeyoh and for unity-scope-click too19:38
dobeyaaaaaaaand probably mediascanner19:39
robrudobey: 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 found19:40
dobeyrobru: yeah i just now saw that doko uploaded no-change rebuilds of everything this morning19:40
dobeyand it fucked our silo up :(19:40
robrudobey: I wouldn't bother rebuilding just for a no-change, just publish over it and clobber the changelog.19:40
dobeyrobru: i guess we need sil2100 for that though?19:41
dobeyor can we get kenvandine to do it? :)19:41
robrudobey: 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:42
dobeykenvandine: heeeeeeey. can you help us? :)19:43
robruand whoever does that copying should not bother to copy the ones that say "diff (0 lines)" as those are no-ops19:43
dobeyrobru: well rvr *just* approved it after having been testing it all day19:43
dobeyrobru: 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:45
robrudobey: dunno.19:46
robrudobey: 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 work19:47
robrudobey: note that a bunch of that stuff you actually don't want in vivid overlay19:47
robrudobey: probably best to just copy everything19:47
dobeywell, 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 there19:49
dobeybut sure19:49
Saviqrobru, think that's really needed? will that not then play havoc when landing?19:51
Saviqrobru, or do you mean that we should remove from silo before landing?19:52
robrudobey: if they're in the overlay then future SRUs of those packages will be ignored19:52
robruSaviq: 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 archive19:52
dobeyrobru: oh, because the image building script has apt pinning of priority?19:53
Saviqrobru, ok then, please copy mir 0.19.2 to silo 5119:53
robrudobey: yes19:53
Saviqrobru, from vivid/overlay and xenial19:53
dobeyrobru: 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:53
robrudobey: oh, true, then i guess it doesn't matter19:55
dobeyrobru: or i guess you can delete those extra things that were copied in, from the silo now, and then we just force publish it19:55
robruSaviq: ok copied, give it a few minutes to "publish" (in the ppa sense not the train sense)19:57
Saviqrobru, yup yup19:57
robrudobey: I'd rather not touch this silo seeing as I don't have permission to publish it anyway.19:57
dobeyrobru: great. doko was still around, so i asked him to copy the packages to xenial-proposed and he's done it now :)20:32
dobeyrobru: 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:06
robrudobey: looking21:07
robrudobey: ok try now21:13
dobeyrobru: 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
dobeyrobru: 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:26
robrudobey: 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
dobeyrobru: i was cc:ed on a few threads, yeah21:39
dobeyi don't know which one you're specifically referring to though. the jsoncpp one?21:40
dobeyrobru: 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 gcc521:41
robrudobey: ok copied. yeah there seems to be a bug in publishing at the moment, I'll have to dig in a bit21:42
dobeya bug?21:42
robrudobey: yeah this is the second time I've seen this, it prevented you from publishing due to a "packaging diff" but there wasn't one21:43
robruat least not for the package indicated21:43
dobeyrobru: well, does it consider removing a changelog entry a "packaging diff" ?21:43
dobeyhmm, i guess not21:44
robrudobey: 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.diff21:44
robruso 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 somehow21:45
robrubrb tho21:46
dobeyrobru: 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 ppa21:46
dobeyrobru: or maybe i should just force merge now and go on about my life21:50
dobeyor maybe it'll just do that automatically once things migrate22:19
dobeyanyawy, i have to go now22:19
robrudobey: it will auto merge, yes22:26
Saviqtrainguards, please delete unity-scopes-shell from silo 51, thanks!23:36
robruSaviq: on it23:36

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