[06:23] jgdx, hey, https://code.launchpad.net/~ken-vandine/libqofono/0.82/+merge/270812 needs approval too for silo 44 [06:23] jgdx, also, jenkins integration is failing for https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/availableTechnologies/+merge/270736 [06:27] abeato, I think libqofono is a package upload. Does that restriction still apply? [06:27] abeato, ci fails due to the new libqofono version, so not much to do there. [06:28] jgdx, hmm, there is a MP so I do not think libqofono is a direct upload [06:28] jgdx, ack about jenkins [06:37] jgdx, anyway, do you mind if I approve libqofono branch to have QA happy? [06:37] abeato, well, in that case, isn't that mp invalid? It says it drops a patch but I don't see that. [06:39] jgdx, hmm, yeah, that's weird [06:40] jgdx, I guess the patch changed availableTechnologies from upstream to modemTechnologies [06:40] jgdx, which is not necessary anymore [06:40] abeato, but it's supposed to be in the diff, right? [06:40] jgdx, maybe the patch was a direct upload [06:41] jgdx, the mentioned patch is not in http://bazaar.launchpad.net/~phablet-team/libqofono/ubuntu/files/head:/debian/patches/ [06:42] bad... it must have been a direct upload, let me get the source package [06:46] jgdx, the source package contains expose_modem_tech.patch [06:47] jgdx, at the same time there are a couple of patches that are not in the package but appear in the branch: connman-resetcontexts.patch and context-preferred.patch [06:48] jgdx, so basically the MP drops the patch simply by using the bzr branch as the patch is not there [06:50] jgdx, hmm, wait I think I did not download the overlay ppa package; connman-resetcontexts.patch and context-preferred.patch are probably there [06:58] jgdx, in the end I think all is fine: previously libqofono was a direct upload, but kenvandine created last week lp:~phablet-team/libqofono/ubuntu to integrate it with the CI-train I guess [06:59] jgdx, so I think the MP is fine, do you mind if I approve it? [07:03] abeato, no, but one question, do you have the silo installed? [07:04] jgdx, yep, well, I had to download manually the packages, but installing things manually worked [07:04] abeato, could you change the radio tech and check the system settings log output? That'd definitely ease my mind [07:05] abeato, tail -f .cache/upstart/application-legacy-ubuntu-system-settings-.log [07:05] jgdx, sure [07:08] jgdx, no log output, but radio settings does change in ofono, and I see radio detaching and attaching again [07:09] abeato, +01 [07:10] abeato, approved [07:10] jgdx, cool, thanks [07:11] jgdx, re: the jenkins failure, the build fails because the package dependency is in the PPA and jenkins does not get packages from there? just curious [07:13] abeato, right, libqofono-0.82 is only in the silo ppa and the tests are run using rc-proposed (vivid+overlay). [07:13] we really would like to be able to disable CI for these branches and instead run it against the silo. [07:14] jgdx, I see, thanks [07:22] ogra_: sil2100: a core dev would be apparently needed to publish 035 https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish/20/ - it seems train failed to do the diff, and therefore falls back to requiring a core dev for publishing (packaging changes or not) [07:25] Mirv: source packages always require core dev even without diff. [07:25] And man, i really gotta fix oxide diffing [07:27] Mirv: the reason oxide fails is because the diff always ends up being several GB and the current diffing algo we use tries to have it all in memory at once, so it OOMs and then catches the error or something. There's a bug somewhere saying not to diff in memory [07:28] Yeah, we had constant issues with publishing oxide [07:30] It boggles my mind how oxide functions as a project with diffs that huge. Last time we successfully diffed it it was like 3.5GBs. [07:30] The diff is really small this time anyway, so we can use the LP one instead: https://launchpadlibrarian.net/216837188/oxide-qt_1.9.1-0ubuntu0.15.04.1_1.9.2-0ubuntu0.15.04.1.diff.gz [07:31] robru: oh, I thought I was still able to publish main packages if there are no packaging changes. that explains. [07:31] Mirv: nah you can only publish if it's an MP and there's no packaging changes. [07:31] ogra_: you have a moment to publish landing https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish ? The changes are here: https://launchpadlibrarian.net/216837188/oxide-qt_1.9.1-0ubuntu0.15.04.1_1.9.2-0ubuntu0.15.04.1.diff.gz [07:34] sil2100: is that the full diff? Why the hell didn't the train get that? Wtf? [07:36] That's the full diff alright, still... even getting such a small diff by diffing two huge sources might cause trouble on the train machine or something [07:37] robru: you! Go rest! It's unhealthy to use your holidays for work ;) [07:37] sil2100: Hmmmmmmm but i thought i shelled out to make the diff and then only kept the diff in memory. It surely doesn't put the whole project in memory to do the diff... [07:38] sil2100: OK OK I'm going ;-) [07:51] my root partition on the Nexus 4 is full, and I've just reflashed my phone yesterday (wily, devel-proposed). Any tricks to free some space? [08:05] mardy: flash with --wipe? [08:05] mardy: if that already done, maybe --bootstrap --wipe [08:06] wipe should probably do what it says already [08:06] There's not much difference between --bootstrap and --wipe, both do the same thing but in different ways IIRC [08:08] Mirv, sil2100: is there a way to flash the phone which completely resets the / to its original state, but keeps /home untouched? [08:10] sil2100: and another unrelated question about "wily" being skipped: does it mean that the 15.10 framework will be skipped too? Or will it come via the vivid + overlay channel? [08:11] mardy: I don't think we have an easy way for doing that, I think the best way is to tar up /home and then do a wipe/bootstrap flash [08:13] mardy: and for the framework - we'll be shipping it in our vivid overlay, we already have it there actually [08:13] Rationale here: [08:13] https://bugs.launchpad.net/ubuntu/+source/click/+bug/1456328 [08:13] Ubuntu bug 1456328 in Canonical System Image "Need a development framework on Vivid overlay" [High,Fix committed] [08:13] Not released on stable phones yet though [08:24] sil2100: I think the last --bootstrap changed my device id. but I also had a screen "this device needs to be brought to service center" or something so maybe it did something super extra. I hadn't seen that screen before. [08:26] huh [08:30] sil2100, did the publishing happen already ? [08:32] ah, your link was just to short ... Mirv's is better :) [08:33] done [08:43] ogra_: eeek, ok, irssi cut it up [08:43] Thanks! [09:18] rvr, hey, the branches for silo 44 are approved now [09:19] abeato: Cool [09:24] 20 builds and weeks of autopilot later I'm wiser, but not exactly closer to landing anything... [09:50] morphis: ping [10:04] rvr: ping [10:20] morphis: I have a problem installing silo 22 [10:20] morphis: Setting up bluez (4.101+15.04.20150914.2-0ubuntu1) ... [10:20] morphis: And stops there [10:21] rvr: ah [10:21] morphis: How did you install it? [10:21] http://paste.ubuntu.com/12416639/ [10:21] it tries to restart the services on install which doesn't work [10:22] as that conflicts a bit with the android container for bluetooth [10:22] rvr: so either you pull http://paste.ubuntu.com/12416639/ and save that as citrain [10:22] then use it as normal to install the silo [10:23] or you do manually a echo "exit 101" | sudo -A tee /usr/sbin/policy-rc.d [10:23] before you install the silo [10:23] have a go a MP out against the citrain tool to fix that [10:24] Ok, let me see [10:25] sil2100, hi, I'd like to seed package gstreamer1.0-plugins-ugly-amr into the phone images (see bug #1386553) [10:25] bug 1386553 in Canonical System Image "AMR audio codec not supported" [Undecided,New] https://launchpad.net/bugs/1386553 [10:25] sil2100, which steps should I follow? [10:25] abeato: hey! Let me take a look at the bug first [10:25] sil2100, ok [10:26] morphis: just to confirm bt is working on reboots [10:27] davmor2: ? [10:28] morphis: you wanted confirmation that a connected device would reconnect on a reboot it does, I think in the end you realised it was an issue with you config, but I said I'd look for you and confirm if it worked or not :) [10:28] ah right [10:28] thanks! [10:36] morphis: The bash script doesn't work [10:36] ? [10:36] morphis: /bin/sh: 0: Illegal option - [10:37] rvr: you're running the script from your PC? [10:37] morphis: citrain works on the PC, yes [10:39] rvr: which arguments are you using? [10:39] robru: Getting strange failure with silo 10: https://ci-train.ubuntu.com/job/ubuntu-landing-010-1-build/226/console [10:39] morphis: citrain.sh device-upgrade [10:40] + su -p pbuser -c './debian/rules clean' [10:40] make: dh: Command not found [10:40] make: *** [clean] Error 127 [10:40] rvr: to make sure there is no copy-error: wget http://file.gravedo.de/citrain && chmod +x citrain [10:41] morphis: ERROR 404: Not Found. [10:41] ah sorry .. wget http://files.gravedo.de/citrain [10:43] michi: robru is on holidays right now ;) [10:44] michi, is you package missin a build-dep on debhelper perhaps ? :) [10:45] michi: did your package in this state build before in the train? [10:46] sil2100: Yes, it built just a few days ago. [10:46] This is brand new. [10:46] I don’t think this has anything to do with what I did? [10:46] Hmmm... [10:46] I’m using an absolutely minimal control file. [10:47] Because the real control file is generated. [10:47] But that works fine with bzr bd. [10:47] michi: did you change anything in the packaging since the last time it built? I just want to first get the baseline here [10:47] rvr: https://code.launchpad.net/~morphis/phablet-tools/citrain-changes/+merge/271094 [10:47] sil2100: ... [10:47] OK, I think I might know. [10:47] Which package is dh in? [10:47] debhelper? [10:47] Yes [10:47] Hmmm… I left that as the only build-dep. [10:48] Basically, I reduced the dummy control file to the bare bones, so no-one would mistake it for the real thing. [10:48] As part of that, I removed all build-deps except for debhelper. [10:48] I wonder whether there is something else I should have left in place. [10:48] morphis: Nice, the one hosted in your website works :) [10:48] rvr: very good :) [10:48] AARGH! [10:48] I removed debhelper. [10:48] Mea culpa. [10:49] My apologies for the noise. [10:49] michi: interesting that it's not really installing debhelper to build the source package [10:49] heh [10:49] Yeah [10:49] No worries ;) [10:49] Apparently, unless you have an explicit build dep, debhelper isn’t installed. [10:50] morphis: It's important to add any relevant installation information to silos [10:53] morphis: Ok, bluetooth seems to be working, approving 22 [10:53] rvr: thanks! [10:53] rvr: will add that bit next time [10:53] morphis: Thanks :) [10:53] ogra_: Thanks, yes, well spotted! :) [10:54] sil2100, ogra_: Amazing how much difference one little line can make :) [11:00] :D [11:36] trainguards: hey, I'm in silo27, I'm trying to dual-land qtubuntu-gles. Train seems to have only built the vivid+overlay package however. Any ideas? [11:37] greyback: hey, let me take a quick look [11:39] hm, looks like the wily source package was built at least, let me see why it didn't reach the PPA [11:40] Ah, wait, I might have an idea [11:51] greyback: interesting [11:52] :) [11:54] greyback: I think I see the problem, but I wonder if this somehow worked before - do you know if you were dual landing qtubuntu with qtubuntu-gles previously? [11:54] greyback: so I think the issue is this: [11:55] sil2100: honestly I don't think so. [11:55] https://code.launchpad.net/~mir-team/qtubuntu/gles-sync/+merge/269178 <- this is the -gles sync merge, right? [11:55] but I didn't see any obvious reason why isn't not possible [11:55] sil2100: yeah [11:55] It is possible, but it needs to be done a bit differently :) [11:55] ok, lead on! [11:56] So how dual landings work - they take the selected merge proposal, build a source package of it for wily (the main series) and then the train copies that, re-versions the wily source package to vivid and uploads both to the PPA [11:56] This implies that the original merge needs to target the wily branches [11:57] Now, what happens here - the mp for the -gles sync actually targets vivid, as you can see the version number is 0.62+15.04.20150914-0ubuntu1 instead of 0.62+15.10.20150914-0ubuntu1 (15.04 vs 15.10) [11:58] yep, so I should retarget it to wily? [11:58] So the train built that, created the 0.62+15.04.20150914-0ubuntu1 source package targetting wily (!), then copied it and wanted to reversion to vivid (which was a noop), so it overwritten the wily versions [11:58] Yeah [11:58] Just change the MP to have the wily version [11:58] 0.62+15.10.20150914-0ubuntu1 [11:58] And I suppose this should help [11:58] (if my understanding is correct) [11:59] ok, trying === alan_g is now known as alan_g|lunch [12:26] robru, kenvandine hey guys, michi made some tweaks to the MP in silo 10 and also commented on the last NACK, can you give it another look? [12:27] pstolowski: robru is on vacation. [12:28] pstolowski: michi: there are no common files, but I believe what was wanted is that upon upgrade the no-longer-built-from-any-source-package binary packages would get removed from the systems via conflicts [12:28] kenvandine: James and I discussed this at length. We don’t think there is any need for a Conflicts or Replaces entry for the Qt library because there are no binaries that are common. [12:28] Mirv: Hmmm... [12:28] So, if the Conflicts entry is missing, the old lib won’t be removed? [12:28] or at least ken is saying "for the binaries that landed in wily that aren't built anymore" [12:29] I really don’t know what he means there. [12:29] yes, people will have the old libraries infinitely [12:29] We are using Replaces/Conflicts for unity-scopes-api because that package installs executables, such as the scoperegistry [12:29] OK. [12:29] Can you help me here? [12:30] What is the difference between Conflicts and Replaces when it comes to upgrading/uninstalling? [12:31] michi: Conflicts = can't be installed at the same time, remove the other one. Replaces = allow the fact that there are identical files in two packages, ie don't fail even if the other package wasn't yet completely uninstalled. I don't see why Replaces would be needed here though if all the file paths are different. [12:32] For the Qt lib, there are no common file paths. [12:32] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts [12:32] And both old and new can be installed at the same time, as far as the Qt lib package is concerned. [12:32] Although, they may well have conflicting prereqs. [12:33] Thanks for the link! [12:33] So, I don’t really mind. [12:33] I can add a Conflicts entry, a Replaces entry, or both. [12:33] Mirv: can you publish https://requests.ci-train.ubuntu.com/#/ticket/314 ? [12:33] But I honestly don’t know which one is right. [12:33] All three options are equally easy to do. [12:34] michi: I believe the correct thing would be Breaks: only :) not Replaces, and using Breaks since both can be unpacked at the same time (no same file paths) [12:35] so Breaks: oldbinarypackagenamethatisnolongerinarchivesafterthissourceversion [12:35] Checking the debian bible… [12:35] yeah, me too... always takes a couple of re-readings.. [12:36] Mirv: “Normally, Breaks should be used in conjunction with Replaces.” [12:37] and Breaks should be used "when moving a file from one package to another" [12:37] Mirv: Section 76.1 [12:38] Mirv: Hmmm… Sounds like Breaks: is right. [12:38] But does it need a Replaces: or not? [12:38] michi: my interpretation would be that Conflicts + Replaces is a poor man's replacement for what should be usually Breaks :) [12:39] Aha. [12:39] only if some files are getting overwritten, Replaces would be needed (as it reads in 7.3) [12:39] So, sounds like I should be adding a Breaks: entry then for the Qt lib [12:39] Chapter and verse… [12:40] morphis: probably not, as it has packaging changes. but I'll try [12:40] Mirv: what extra work would it need then? [12:40] morphis: it'll need us to ping a core-dev to run the publishing job [12:41] like... ogra_, please, https://ci-train.ubuntu.com/job/ubuntu-landing-022-2-publish/35/ [12:41] interesting [12:42] this changed a week/two ago, we can't anymore just verbally ask for an ack from a core-dev, the core-dev needs to run the publish job [12:43] ah I see [12:43] Mirv: Thanks for your help. I’ll have another go at this tomorrow. It’s late here, and I’m too tired to make changes now without making a mistake. [12:43] Another day, another chance… [12:46] morphis, Mirv, done ... [12:46] ogra_: thanks! [12:47] renatu: ping [12:48] renatu: hey! The indicator-transfer landing that introduced indicator-transfer-download-manager - did that land already? [12:51] Mirv,michi: if it's just a library soname change, you should normally have none of Conflicts/Breaks/Replaces. why is Breaks required here? [12:52] and no, Conflicts+Replaces is not a "poor man's replacement" for Breaks; that has a different purpose. [12:52] cjwatson: I honestly don’t know. [12:52] I’m just getting beaten up by the QA guys ;) [12:52] michi: which binary package is at issue here? [12:52] Sec... [12:53] cjwatson: libunity-scopes-qt [12:53] See silo 10 [12:55] michi: AFAICS kenvandine is wrong. None of Conflicts/Breaks/Replaces is necessary there. [12:55] cjwatson, oh? [12:55] That’s what jamesh thinks too. [12:55] kenvandine: Justify your position :) [12:55] we should clean up the old binaries if they are installed... [12:55] No. [12:55] That's not the purpose of those fields. [12:55] Stop misusing them. [12:56] :) [12:56] we want the new binary to replace the old one [12:56] If you're misusing them in this way routinely, then you are making apt's job harder and in some cases harmfully so. === alan_g|lunch is now known as alan_g [12:56] Stop it :) [12:56] the old ones should automatically drop from the image if nothing pull them in [12:56] trainguards: can silo 21 be published, please? [12:56] and not leave a bunch of old version around... especially if they aren't compatable [12:56] oSoMoN: on it now! [12:56] That is not the purpose of Conflicts/Breaks/Replaces. [12:56] kenvandine, compatible with what? [12:56] It's the purpose of other tools. [12:56] oSoMoN: apologies, was on lunch [12:56] e.g. deborphan [12:57] sil2100, yes [12:57] sil2100, no worries, I just came back from lunch myself :) [12:57] Misusing C/B/R for this causes upgrade problems. [12:57] if there is a e.g a dbus api that changed, it makes sense to force the removal of things that talk the old protocol [12:57] they renamed the lib package twice [12:57] one of which only landed in wily [12:57] and they are reverting that [12:57] Simple soname changes shouldn't have any of C/B/R. [12:58] If you add them, then apt has to do significant extra work to order changes in a way that's otherwise entirely unnecessary. [12:58] i think they wrap dbus apis [12:58] cjwatson, what if the old lib talks to a server over a protocol that changed and make them not work with the new service? [12:58] it's unity scope apis [12:58] iirc [12:58] seb128: I would still not expect to see lib0.2 conflicting with or breaking lib0.1! [12:58] kenvandine: This has nothing to do with dbus or on-the-wire protocols. [12:58] cjwatson, right, but the new service with the old lib maybe? [12:58] hey trainguards, i'd like to abandon silo 57 (requested same stuff twice by mistake), but not sure how [12:58] The library under discussion is a plain Qt API. [12:59] seb128: Maybe. But that's not what was being argued ... [12:59] michi, i see... i thought it was a lib that wrapped dbus apis [12:59] "there needs to be a replaces/conflicts for the binaries that landed in wily that aren't built anymore" [12:59] which is a specious argument [12:59] cjwatson, I don't think kenvandine defends the current solution, just the fact that the old libs shouldn't be co-installable with the new service since they are incompatible [12:59] pstolowski: Merge and Clean. Then ONLY_FREE_SILO [12:59] That throws the whole thing away. [12:59] pstolowski: as michi said [12:59] seb128: the thing I quoted above was the reason given, and it is not a good reason [12:59] agreed [13:00] just saying that there might be a need for some of those conflicts [13:00] in different places [13:00] seb128: There is no issue about the old libs being compatible with the service. [13:00] perhaps i didn't explain my concern well enough, since it was for the scopes API i thought it was dbus [13:00] then that fine [13:00] No, no dbus involved in any of this. [13:00] michi, so clients of the old soname keep working fine? [13:00] Yes. [13:00] they don't need to ported/migrated to the new one [13:00] Correct. [13:00] kenvandine, seems good then :-) [13:01] then that's fine [13:01] OK, phew... [13:01] kenvandine: hey! Could you publish https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/ ? There's this change: https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/92/artifact/webbrowser-app_packaging_changes.diff [13:01] (so only a dep bump) [13:01] One of these days, my debian Fu will hopefully increase to level 7, so I can actually claim that I more or less know what I’m doing... [13:01] * kenvandine checks [13:02] seb128, michi allright, thanks [13:02] OK, great. I just try to nip confusion in this area in the bud so that some poor soul in foundations isn't left digging through apt debugging output in a month's time trying to make the upgrade sensible :) [13:02] (not that that is my problem any more ...) [13:02] renatu: do you know if anyone pushed the seed changes, or should I do it now? [13:03] cjwatson, Mirv, kenvandine: Thanks for all your help everyone, I truly appreciate it! [13:05] sil2100, I need to check, do you have the link for the the repository with the meta-package? [13:05] renatu: no worries, I'll check it then :) [13:05] sil2100, ok thanks [13:07] Wow [13:09] renatu: ok, I see didrocks uploaded the wily change and Mirv did the overlay change [13:09] Good [13:09] great thanks [13:09] sil2100, done [13:09] kenvandine: \o/ Thanks! [13:11] Mirv: hey, regardin indicator-transfer seed change, you could have removed indicator-transfer when adding the new package ;) [13:11] As it pulls it in as a dependency [13:11] kenvandine: hm, so you reviewed silo 10 already, right? [13:12] not 10 [13:12] Since I have the power to publish it, but it's a big diff - should I also take a look at it? Or will I be doubling work then? [13:12] 21 [13:12] kenvandine: right, but silo 10 is the silo that you NACKed earlier :) [13:13] ah [13:13] then i had reviewed it [13:13] And seeing the discussion above, the NACK was invalidated - so is it completely reviewed now? :) [13:13] yeah [13:13] that was my only concern [13:13] Thanks! [13:13] np [13:22] kenvandine: I wonder - do soname bumps require us poking archive admins for permission? [13:22] Or can we just publish those as is? [13:22] Since there's that rule that new binary package additions require archive admin ACKs [13:22] hmmm [13:23] i think you have to publish them so they show up in NEW [13:24] New binary packages won't show up in the NEW queue, those go straight to the archive [13:24] New source packages only show up in the NEW queue when published from the CI Train [13:24] That was one of the issues of the train itself [13:24] sil2100, oh... i didn't know that [13:25] i thought the usual archive workflow would be maintained [13:25] Sadly for new bins it's bypassing the normal workflow, which is why there's that warning on top of the packaging diff when there are new binary packages involved ;) [13:28] sil2100: technically that does require an archive admin ack yes [13:28] one of these days we will fix that LP bug :-/ [13:29] cjwatson: could you take a look? :) https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/80/artifact/unity-scopes-api_packaging_changes.diff <- it's from silo 10 that was discussed some moments ago, it's from the changes that make the packaging to generate packaging basing on what series the package builds for [13:29] (I know how that sounds) [13:31] I have no problem with such things in principle, depends rather on how they're done :) [13:31] sil2100: ok, sorry, this is more than I have time for right now though. could you ask in the usual places? [13:32] hah, yeah, that's what I thought originally when I saw the diff [13:32] Ok, let me bring that up on -release [13:32] Thanks! [13:35] cjwatson: thanks. I also thought nothing would be needed at the first sight but I tried to interpret (correctly) what kenvandine seemed to want (which turned out is not really wanted) [13:37] sil2100: why remove? [13:37] Mirv, sorry, i'm just used to most of these types of changes being to handle incompatible dbus API changes under the covers, /me grumbles about indicators :) [13:37] sil2100: oh right, I understand, not needed anymore, true [13:37] Mirv: not a biggie, just redundant :) [13:37] :) [14:17] abeato: Is silo 44 ready or not? :-/ [14:18] rvr, it is, awe_ got confused :) [14:18] Ah, nice :) [14:18] rvr, just talking with him on hangouts [14:18] The comment disappeared just after I read it [14:19] hahaha [14:19] self-destroying message :p [14:29] sil2100: ping [14:44] morphis: pong [14:45] sil2100: I just pushed a fix for phablet-tools which ogra_ already reviewed [14:45] question now is where to land this [14:45] wily only? [14:47] morphis, in the phablet-tools PPA [14:49] ogra_: can I do that from bileto? [14:50] morphis, no idea :) [14:50] i guess sil2100 could tell [14:50] morphis: you can do that with bileto too, at least that was possible in the past [14:51] Let's experiment with that ;p [14:51] ogra_: did you use the train to release phablet-tools in the past anyway? [14:51] sil2100: so I have to select another target ppa? [14:51] morphis: yes, just write down the phablet-tools PPA in the same format as the overlay one is written [14:52] sil2100: good [14:52] do we need QA for that, I think so, right? [14:52] sil2100, i dont think so, i always dput'ed to the PPA [14:58] ogra_, morphis: if the train wasn't used for that, then I suppose a dput is enough - we don't usually do QA on it since it's not really on the image [14:58] sil2100: ok [14:58] ogra_: can you do the dput then? [14:59] morphis, no guarantees i can manage that today, sorry ... snapp yrelease preparation is ongoing and i'm very behind on stuff [14:59] ogra_: np [14:59] no hurry [15:04] plars: I [15:04] 'm looking at the old desktop utah testing, and I have an old approved branch that I think I'd like to try to land [15:04] are you the person to talk to about that? [15:16] nuclearbob: I actually don't remember where that box landed... it's technically still in a maas cluster that CI controls, but probably not really in their scope or ours at the moment... one of those limbo things :) [15:17] plars: I'm not actually looking for the box at the moment, I'd like to land a change to the utah code [15:17] nuclearbob: where's the code? [15:17] plars: https://code.launchpad.net/~nuclearbob/utah/psutil-2 [15:18] or maybe https://code.launchpad.net/~nuclearbob/utah/psutil-2/+merge/226313 makes more sense [15:22] nuclearbob: right now, it's pulling lp:~canonical-ci-engineering/ubiquity/ubiquity-ci-testing but that's a ubiquity branch, not utah [15:22] nuclearbob: iirc this thing never used utah [15:22] nuclearbob: are we talking about the same tests? [15:23] plars: this isn't about the ubiquity testing, this is about the desktop utah tests in lp:ubuntu-test-cases/desktop, but changed to psutil back in utopic have broken the utah vm provisioner [15:23]