=== s8321414_ is now known as s8321414 [02:16] tsimonq2: Ugh. Sorry about that. I made the mistake of contacting a pillow, and passed out. I'd been up all night. :/ [06:36] slangasek: sorry, you are right; ztex-bmp and winff got their powerpc binaries copied from xenial. I'll go through 'reverse-depends -b src:fpc' and add the missing packages to the bug [08:55] infinity, Laney: do you consider the iptables package split in Debian (https://tracker.debian.org/news/788344) a new feature? [08:55] * pitti wonders if it makes sense to merge iptables for bug 1616437 now, or work around it [08:55] bug 1616437 in iptables (Ubuntu) "FFE: split out libiptc library" [Undecided,New] https://launchpad.net/bugs/1616437 [09:01] pitti: If you review the iptables changes and they are correct, it's fine by me [09:02] yes, of course I'll review/test them (not expecting the release team to judge about correct patches, just the scope of changes) [09:02] thanks! [09:11] pitti: It's a feature, but not a contentious one, IMO. === hyperair is now known as Guest23766 === Guest23766 is now known as hypera1r [10:30] infinity, any chance that we get some of the 2/3 disabled amd64 builders back at some point ? [10:31] (and could someone bump the score on https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/10668598 and https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/10668601 ) [10:32] ogra_: There's some violence being done to scalingstack. They'll come back eventually. / [10:32] ok [10:33] ogra_: And bumped a bit. [10:33] (thats ongoing for over a week ... would be nice :) ) [10:33] thanks [10:34] we should just build all arch: all packages on ppc64el or s390x ;) [10:34] that would drop the load a bit [10:34] Heh. [10:35] Create a PPA with only s390x enabled and, presto, your arch:all builds will be on s390x. [10:36] heh [10:56] ogra_: Active maintenance has only been ongoing for a day or so, but indeed it was bad before that. The problem is that a MySQL instance in the innards of scalingstack has accumulated a vast number of rows relating to old instances and needs to be cleared out. Unfortunately the process of clearing those out appears to be very slow. [10:57] they should just use postgres ... then we could blame pitti :) [10:58] I just asked axino, indeed this seems strange -- "nova delete" doesn't actually remove the db entry, just marks it as "deleted" [10:58] * pitti introduces SQL users to "DELETE FROM" -- et voilà, no accumulation of cruft over time! [10:59] pitti: Yes, it's an Openstack issue. [11:00] Though multi-stage deletes are not uncommon in large systems for one reason or another. [11:00] I don't know what nova's rationale is. [11:17] can i get bumps for https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/3655 and https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/3658 too ? [11:19] ogra_: done [11:19] thanks :) [11:19] that was the last one for today i hope :) [11:32] flexiondotorg: tsimonq2 was very helpfull and nice to work with, it wouldn't have been as fun and easy without him :) [11:33] sakrecoer, Morning. And Thanks! [11:33] For organising us :-) [11:33] :) it was a pleasure! a good way to get to reach out to the community and get to know more people in fact :) [11:34] wish you all a nice friday! read you soon! [11:39] cjwatson: would you please help me with the UITK release from this silo -> https://requests.ci-train.ubuntu.com/#/ticket/1808 it needs a binNEW ack as we have added a new metrics library to enable UI performance monitoring. [11:40] the change is from Loic - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-094/+sourcepub/6828771/+listing-archive-extra [11:40] bzoltan: sorry, I'm not routinely doing this any more, hopefully some other archive admin can help. [11:41] cjwatson: okey, thanks. No prob... i will find somebody else then [11:42] seb128: maybe you :) ^^^ [12:01] slangasek: (for when you are back online) it looks like you already removed powerpc binaries for ztex-bmp, winff. Or did I miss something? Is there anything further I should do for fpc powerpc removal? [14:29] pitti: would you please help me with the UITK release from this silo -> https://requests.ci-train.ubuntu.com/#/ticket/1808 it needs a binNEW ack as we have added a new metrics library to enable UI performance monitoring. [14:29] pitti: the change is from Loic - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-094/+sourcepub/6828771/+listing-archive-extra [14:29] or slangasek ^ [14:29] it's the final freeze day and I would like to get it in to the OTA [14:34] bzoltan: train n00b here, what am I supposed to do ? [14:35] pitti: It is a new binary package to the yakkety archive [14:35] train copies circumvent binary NEW AFAIK [14:36] mayb Mirv knows how to do and what :) [14:40] bzoltan: FTR, NEW queue is here: https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0 (not in there, and I doubt it will actually appear there) [14:41] pitti: He's asking you to review it before copying to the archive, because of that bug [14:46] pitti: Indeed, copies circumventing binNEW is why we require them to get signoff before publishing. [14:47] yeah, I'm determining the new binaries amongst the gazillion existing ones and review [14:48] * infinity ponders scouring the earth for caffeine. [14:49] debian-changelog-line-too-long line 7 (but *shrug) [14:50] bzoltan: any chance to drop the .la files? some years ago we've went through quite some effort to clean them up [14:50] they are useless and just cause trouble (extra dependencies, or lintian warnings like this: incorrect-libdir-in-la-file usr/lib/x86_64-linux-gnu/libUbuntuMetrics.la =/usr/lib/x86_64-linux-gnu != /usr/lib/x86_64-linux-gnu [14:50] (whatever that means) [14:50] (presumably that extra =) [14:51] not sure how much precedent there is with other libraries [14:52] bzoltan: libubuntumetrics5 contains a non-soname specific file: ./usr/lib/x86_64-linux-gnu/qt5/plugins/ubuntu/metrics/libumlttng.so [14:52] that's a major bug for a library as that will break upgrades on the next soname change [14:53] Yeah, plugins should never be in an SONAMEd package. [14:53] that's it mostly; the latter is a rejection reason, the .la file is "meh, pretty please kill them with fire", but could be argued to pass if there's a targetted/assigned bug [14:53] but while you are fixing the packaging anyway please remove that too [14:54] https://requests.ci-train.ubuntu.com/#/ticket/1808 doesn't have anythign to record the review? [14:54] oh, a comment field [14:56] pitti: Would that be OK if I fix it with the next release (next week)? Today is feature freeze for the OTA. [14:57] bzoltan: It's a rejection. [14:57] comment added to the ticket [14:57] pitti: ^^ ? [14:58] bzoltan: it'll be harder to fix then, you need the conflicts:/replaces dance [14:58] pitti: I am happy to do that dance [14:58] also, then it wouldn't be subject to NEW review again [14:58] pitti: I promise I will put you as reviewer of the next landing. [14:59] That's not how this workd. [14:59] well, why the Friday afternoon rush? it seems so much better to land it properly next week than causing more work for everyone [14:59] works* [14:59] pitti: it is a triple landing vivid/xenial/yakkety ... to me the vivid is the priority as it goes to the devices out there [14:59] FFEs exist for a reason.. [14:59] landing it in a stable release is even worse [15:00] pitti: it is not a Friday afternoon rush :( that branch is 10 days old. That how long it takes to spin off a UI Toolkit release. Autopilot tests what takes 2 days, autopkgtests that fail randomly, manual QA tests... it is a long process. [15:00] a feature freeze does not mean "cram in everything half-broken at the last minute", it's a much softer target where exceptions are readily granted immediately afterwards (increasingly less often the longer it goes) [15:00] bzoltan: You're asked to get reviews for a reason. The reason isn't to ignore them. [15:01] hm; seems the binary review should happen at a much earlier time? [15:01] bzoltan: You could have had it reviewed before it was ready to copy, for what it's worth. [15:01] bzoltan: Either way. Being in a rush doesn't make the review result change. [15:01] bzoltan: If it does, the process is broken. [15:01] pitti: I agree, but for some reason the provess is like this [15:01] well, *shrug*, it's a time bomb like that, and I know how things go -- once it's over the fence it tends to be forgotten, and it's *more* work overall to do it twice [15:01] infinity: I appreciate your input. Thank you. [15:02] all that autopkgtest/QA dance etc. will still have to be done again [15:02] pitti: No, I do not forget it. [15:02] bzoltan: well, explain to me how landing that now makes anythign easier? [15:02] pitti: I do that dance every week :) that is not new. But missing the OTA would be really bad. [15:03] well, I don't know these circumstances of the release process; you asked me to review it, I pointed out the packaging bug, do with it what you will :) [15:03] bzoltan: If the bug is OTA-critical (and determined to be such), surely there's a way to escalate and push through a fixed version quickly. [15:03] pitti: Look the description - https://requests.ci-train.ubuntu.com/#/ticket/1808 I have some critical fixes there. [15:04] bzoltan: If you're implying that both "it needs to land" and "it'll take a week" are true statements, something is wrong. [15:04] sorry, I need to leave, appointment [15:04] infinity: yes, the process is difficult and heavy. Not my design, not my process. It is how it is. [15:04] Something's very wrong if the review isn't allowed to actually bounce the fix back [15:07] Laney: The problem is that fixing that "libubuntumetrics5 contains a non-soname specific file: ./usr/lib/x86_64-linux-gnu/qt5/plugins/ubuntu/metrics/libumlttng.so" would put 4-5 days delay on landin. What is OK in the beginning of the OTA period, but at the end IMO it would make sense to be flexible and acept my commitment that it will be fixed next week. Not like I am asking an atomic bomb to pass [15:07] bzoltan: It shouldn't put a 5 day delay on landing. That's insane. [15:08] bzoltan: And reviews aren't in place to argue that reviewers should let it in anyway. There's no point in the AA review step if it's just going to be ignored. [15:08] infinity: I know, as I said it is not my process, not my rules. I am just working here. [15:08] bzoltan: So escalate to the right people to make sure that 5 day process can be turned around in a 6 hours instead for your fixed package. [15:09] bzoltan: There's no reason it has to take that long. [15:09] * infinity feels like he's back at Nokia. [15:09] infinity: I know how it goes... I grew up in easter europe in the 80s :) [15:09] * bzoltan feels like he is back in soviet Hungary [15:10] infinity: Nokia was actually pretty non-flexible organization [15:10] bzoltan: Yes, hence my comment. [15:10] Landing in Maemo was an awful experience. [15:10] infinity: same here.. i am not arguing, I am asking flexibility and trust [15:11] bzoltan: You're arguing with the wrong people. The problem is in how quickly you can turn around a fix, not with someone rejecting your upload. [15:11] infinity: That one I do know :) [15:11] It. Does. Not. Take. 5. Days. To. Get. A. Package. Through. A. Silo. [15:12] infinity: read my lips > _IT_DOES_ [15:12] sil2100: ^^ What can be done to give bzoltan an SLA on one fixed landing? [15:12] infinity: how often do you land a package via CI train? [15:12] What's up? [15:12] bzoltan: Never. But I've seen quick fixes done by others. [15:13] infinity: I do all the time .. 30-40 a year, so please believe me if I say it takes 4-5 days [15:13] sil2100: bzoltan's landing has a bug that prompted an AA reject. He's arguing for it to be let in anyway because citrain is slow and it'll take him a week to land a fix, I'm arguing that he's arguing with the wrong people, cause it shouldn't take more than a day to turn it around, and the rejection was for a valid reason. [15:13] infinity: I am not arguing... I am asking [15:14] bzoltan: Asking repeatedly after you've been given a response is called arguing. [15:14] Yeah, landing through the train can be fast of slow, like with any package landing to the archive - bigger projects tend to take longer since well, tests, etc. but that's not due to the train ;p [15:14] Ouch [15:15] sil2100: specially that it would not be an issue if it were a vivid only landing ... [15:15] bzoltan: just for context, which landing request is this about? [15:15] Anyhow the comment from pitti is valid and yes that issue must be address. [15:15] sil2100: https://requests.ci-train.ubuntu.com/#/ticket/1808 [15:17] bzoltan: I suppose this landing is needed for OTA-13, yes? [15:20] bzoltan: so generally if the archive admins reject an upload we need to just respect that and do a rebuild anyway, just want to know if we can somehow still get this fit into our vivid base [15:20] sil2100: yes, it is the main OTA13 UITK [15:21] bzoltan: is that libumlttng.so library used already? Is this a completely new thing? [15:21] sil2100: a rebuild and the autopkgtests will eat up the weekend for sure [15:21] sil2100: it is brand new and no, nothing yet uses it [15:23] What I'm worried is, if we anyway got that even just for the vivid-overlay and it got out with OTA-13, I'm worried that some stable users/developers could start using this app and have troubles on ABI changes there [15:24] bzoltan: do you guys have a branch for fixing the library so-versioning? [15:25] sorry I'm not having brain capacity at the moment since I'm doing other stuff but how does that plugin there differ from eg libqt5gui5 which has a bunch of differently named plugin .so:s bundled? [15:25] just point out the visible similarity, I've not even opened the binary package contents of this landing [15:26] It was probably missed during archive-admin review? ;p [15:27] infinity: purely out of curiosity, may I know in how many milliseconds the universe would collapse if a package called libubuntumetrics5 would land in Ubuntu archive what provides a library called libumlttng.so? I really do not challenge yur call... but I wish to learn the reason of your decision. What I respect and accept. [15:28] sil2100: that's what's in Debian and has always been, it has at least gone through Debian's NEW queue in the past [15:28] but sorry I'm not really here but on free time [15:30] bzoltan: Sarcasm doesn't change the review either. [15:31] bzoltan: The point is that packages with an SOVER in the name are so designed to be coinstallable with the next SOVER. [15:32] Mirv: qt5 upstream stuff is a bit diffeerent, since the SOVER stays lockstep with the Qt major version, and the plugins are in foo/qt5/bar [15:32] Mirv: In the case of a libsomethingubuntu, I refuse to believe we have the same ABI guarantee (and if other Canonical libraries are any indication, I'm right), so libqt5ubuntuthing5 could be ubuntuthing6 tomorrow, and this all explodes. [15:33] infinity: I could ask in a corporate lingotyle too that what risks it would represent in a short and long term. [15:33] bzoltan: The library name itself isn't necessarily an issue, it's the entire path being non-unique between SOVERs of the package. [15:34] bzoltan: Tacking a "5" on the end of the plugin dir would fix it, for instance. [15:34] infinity: Sorry, I make jokes... it is Friday evening here, my wife makes apple pie, kids ask me to play and here I am trying to understand packaging policcies [15:34] bzoltan: Dude. You've been arguing for more than half an hour when you could have had it fixed and uploaded by now. [15:34] And it's not just your time you're wasting. [15:35] And with that, I'm exiting the conversation. [15:35] infinity: Ohh.. version specific path in Qt libs... duuuude :) I am dreaming about that for about 10 years. Not kidding, that is a big issue. [15:35] This has nothing to do with Qt... [15:35] infinity: it does [15:35] ... [15:35] It doesn't. [15:36] infinity: it is in fact and practice a Qt lib, it will be upstreamed one day to Qt [15:36] infinity: it is a UITK lib and UITK is a Qt/QML toolkit. Very much Qt. 100% Qt. [15:36] Upstreamed as "libUbuntuMetrics"? Seems unlikely. [15:37] But the version specific path I'm talking about is for the plugin, not the library. [15:37] usr/lib/x86_64-linux-gnu/qt5/plugins/ubuntu/metrics/libumlttng.so [15:37] usr/lib/x86_64-linux-gnu/qt5/plugins/ubuntu/metrics5/libumlttng.so [15:37] infinity: to you, maybe... to me. Hmm.. i just talked with Qt folks and yes they are willing to be flexible. [15:37] See, now the path matches the library SOVER. [15:37] When you bump to libUbuntuMetrics.so.6, you change that to metrics6, and look at that, unique path. [15:38] Welcome to how to avoid half an hour of wasted time. [15:39] infinity: it is 5 like Qt5 and it is in the path usr/lib/x86_64-linux-gnu/qt5 [15:40] bzoltan: So, you're guaranteeing that libUbuntuMetrics.so.5 will never break ABI until Qt6? [15:40] If not, then you don't understand how to version libraries. [15:40] And we have a bigger problem. :P [15:40] infinity: that is the most important pledge a Qt lib must take, yes.. in a major version no ABI breaks [15:41] How do you guarantee that? Upstream ABI tracking? Rejection of MPs that would break ABI? [15:42] infinity: and yes, I do wish that Qt would be packaged in Debian and Ubuntu to use the minor versions in the installation path... so minor releases were co-installable [15:42] Err, eww. No. [15:43] That's madness. [15:43] And not at all what I was talking about. [15:43] infinity: there is no ABI tracking, sadly... there should be, or it would really cool. We have tests to secure stability. [15:43] "stability" of.. The ABI? [15:43] is not the point of library minor releases is that they are ABI compatible so that they can replace each other without a build of all the rdeps ? [15:43] apw: Yes. [15:43] infinity: I am talking about different thing. That is not the point. [15:44] bzoltan: So. The bottom line here. If libUbuntuMetrics-built-against-Qt5 will always have the same ABI, ALWAYS, then there's no bug here. [15:45] bzoltan: No removed symbols, no changed signatures. [15:45] bzoltan: If that's definitely true, then you'll never bump the SOVER on it, then the path is fine. [15:45] bzoltan, even with per minor qt version directories, the thing that infinity is asking still applies. that metrics yesterday compiled against qt5.4 or qt5.5 should use metricsN/libumlttng.so as the last path; and metrics today which has abi break should use metrics(N+1)/libulttng.so to match the abi break in the soname it depends on. [15:45] or qml functions removed [15:45] or qml functions changing args/usage [15:47] ginggs: yeah, I believe I've removed all the stragglers now, was just wondering if there was some reason those hadn't been on the list - thanks! [16:00] bzoltan: ok, so I have a proposition [16:08] xnox: there is a 5 in the path [16:09] bzoltan, we are talking about qt5/plugins [16:09] infinity: Yes, that is the case. Just like with all other Qt packages. Under a major release no ABI breaks are accepted. [16:10] we are talking about qt5/plugins/ubuntu/metrics1, qt5/plugins/ubuntu/metrics2, qt5/plugins/ubuntu/metrics3, qt5/plugins/ubuntu/metrics4 -> 3 abi breaks, fro three upstream releases of metrics [16:10] xnox: yes, that is a 5 there :) Is there any other Qt library with a minor version in the path? [16:11] bzoltan, those that do not break the ABI don't need. clearly metrics have broken the abi and resulted in not being coinstallable any more =) [16:11] xnox: there is no library with a subversioned path under /usr/lib/*/qt5/plugins [16:12] bzoltan, is qml plugin abi not broken with abi breaks in the underlaying .so library that it binds? [16:12] my understanding is that, it is. [16:12] and so is infinity's. [16:12] xnox: what metrics? It is a new package called libubuntumetrics5 [16:14] xnox: I am not sure I understand you. Or I miss something. It is a lib under qt5 it does come with an ABI stability pledge. Like all other Qt5 libs. [16:15] ... but it's not qt upstream? [16:15] thus it will eventually go out of sync in abi [16:15] specifically when we triple land it. [16:15] thus it needs it's own abi, irrespective of qt's abi it is compiled against. to allow room for changing it's abi too, no? [16:16] bzoltan, is qt-ubuntu-components have "same abi stability pledge" and that was not broken yet? as in no apps had to change? [16:18] xnox: it will be qt upstream on day and it is super heavily binded to Qt [16:19] xnox: the UITK does not have its own minor version path either... [16:19] and what do you do, when uitk components break/change in incompatible ways? Rename them and keep old version? [16:19] or just bump framework, and break the apps? [16:20] xnox: we do not break apps,if we do that is a bug to be fixed with super high priority [16:27] xnox: Qt libraries and so UITK libraries are not like other C++ libraries. As I said... not a single Qt library or plugin is installed to minor versioned path. Not one. [16:27] xnox: pitti: infinity: and yes, all library installed under qt5 path does come with a super serious ABI compatibility pledge. That is one of the fundaments of Qt. [16:49] bzoltan: That's true of upstream Qt. But what are *you* doing to keep that pledge for this Ubuntu library? [16:49] bzoltan: If you'll be tracking ABI breaks and rejecting changes that alter it, then like I said, there's no bug here. [16:50] bzoltan: If you're just assuming that because it's a Qt library it'll magically follow upstream's rules, I don't buy it. [16:50] infinity: I am not assuming anything. I state, under a major version we do not break ABI. [16:51] infinity: we have loads of tests with dozens of applications to cover that. [16:51] bzoltan: Application tests aren't ABI trackers, unless those applications call into every symbol you expose. [16:51] infinity: with this new package we do not do anything different what we have been doing since the first 0.1 UITK [16:54] infinity: I am totally in to discuss this issue with all of you guys, because you are clearly the best to give advice on this field. But rejecting this landing because of a pratice we have been doing since 2012 without any problem does not sound cool to me. [16:54] bzoltan: how are you defining "major version"? major version of Qt? [16:54] slangasek: yes [16:54] 5.X [16:54] bzoltan: so you are asserting that there will never be a libubuntumetrics6 until qt6? [16:55] because libubuntumetrics will not break ABI for as long as it's against Qt5? [16:55] and 6 is coming. So we have about 1.5 years to survive like we did for 5 years :) [16:55] slangasek: yes, that is the idea [16:55] it needs to be more than an idea, it needs to be a committment :) [16:55] slangasek: and yes, I will kick loicm's ass if he changes something to cause ABI break [16:55] slangasek: I am commited, fully. [16:56] bzoltan: ok, thanks for stating this clearly [16:56] infinity: slangasek: and yes, I have a prototype already to track ABIs under the Qt umbrella [16:56] infinity: ^^ does this address the concern to your satisfaction? [16:58] slangasek: I think infinity's concern is how we guarantee ABI compatibility. We should have a release to release ABI tracking mechanims. What we have, as the UITK releases are tested with the applications built against the previous UITK version. Ifthat makes sense. [17:01] What I am not happy about is that it is Friday night..I am after a massive hurde of releasing this UITK. 2 days of autopilot testing, a day with autopkgtests, 2 rounds of manual QA. And now I do not even have anybody in my team who could review a packaging change. And yes we have a rule that we do not land changes without a review. All of it because of packaging issus what I do promise to fix next week with the next landing. Not like I am going away :) [17:01] Laney: did studio et al get turned on again for the tracker - dailies seem hit and miss for those who did b1 [17:03] 29 16 * * * for-project lubuntu cron.daily; for-project lubuntu cron.daily-live --live; for-project lubuntu-next cron.daily-live --live [17:03] 17 18 * * * for-project ubuntustudio cron.dvd --live [17:03] etc [17:03] Wait for a full day. :P [17:03] I wonder if I should turn kubuntu back on [17:04] yofel: ^-? [17:05] Laney: oh my - sorry old chap - and I knew those times too cos I changed the xubuntu one ... long day on the coal face here ;) [17:06] bzoltan: it is not the archive admins' fault that you waited until Friday night to request the NEW review of this. This can be requested at any time during the landing process [17:07] slangasek: I did not know that. [17:07] and as previously mentioned, the review is not a rubber stamp [17:09] slangasek: Of curse not. Still I do not think that the issues flagged out here are so severe that can not get fixed in the next landing. Specially that I do promise to do it. [17:10] slangasek: and minor versioning in a Qt plugin is really something what is not done anywhere. We develop Qt plugins and Qt libs a lot... not a single is numbered. The Qt major version is in the path, that is all. [17:14] slangasek: Yes, if they're tracking ABI, that addresses the concern. [17:14] Well, tracking and committing to not changing. [17:15] infinity: is any other project or package what delivers Qt library does any sort of ABI tracking? [17:15] ... rethorical question [17:16] bzoltan: Upstream does. [17:16] infinity: the commitment that we do not break ABI means that if that happens then we fix it right away [17:16] bzoltan: I don't know what other non-upstream Qt libraries do. [17:16] infinity: I do [17:17] bzoltan: And that's not how ABI tracking works. You don't fix it after you land it broken. You catch the break in your testing and don't land it. :P [17:17] bzoltan: Anyhow, I'm asking you to track ABI. I don't care what bridge other projects jump off of. [17:17] infinity: As I said, I am happy to discuss this issue with you. But I am not happy to change the rules during a game. [17:17] No one's changing any rules. [17:17] infinity: you just did [17:18] I really didn't. [17:18] Either track ABI or version your path. [17:18] infinity: nobody was ever requiring the UITK to put minor versions in the path [17:18] infinity: so it is a new rule. logical in a way and very deffendable fo rsure.. but new [17:19] Not new to me. [17:19] I don't review every upload. [17:19] infinity: and as I said all functional tests of each new UITK libs are run against apps what are built against the previous UITK. [17:22] infinity: from my point it is a massive change in the rule. We have been lanidng new packags for years under the UITK. Not a single time I have heard that we should add minor versions to the library paths. [17:23] This isn't a minor version. [17:23] It's the SOVER of the library. [17:25] infinity: okey, but that does not make my point invalid. New rule in the middle of a game. [17:31] infinity: pillows are comfy but suck for productivity :P np [17:33] bzoltan: this is a standard rule for the archive. That you were unaware of it is part of why AA review is required. [17:34] bzoltan: but as you have confirmed that yes, the ABI will not change until the Qt major version changes, I believe we're all in agreement that we can let this in [17:35] slangasek: but sir, this is how we land library packages since 2012. We always considered the UITK as a Qt plugin and we have not broke a single time any ABI for any app [17:35] bzoltan: no, it's *not*, because this is the first time you have uploaded a library binary package with files whose paths were not versioned in a way that was obviously changing in lockstep with your library's soname [17:35] slangasek: I agree. And I have started to work on adding version numbering to the UITK lib paths. [17:36] slangasek: as I have said to infinity and to pitti, I understand their point and it makes sense... I just would not not like to block this UITK landing because of this. [17:38] we have already agreed that your committment regarding ABI versioning - which was not obvious from looking at the packaging - is sufficient to let this package into the archive as-is [17:38] slangasek: Thank you [17:40] bzoltan: now, as for the mechanics of releasing it, there's still the QA NACK on the landing which needs clarification [17:40] slangasek: It is OK before pitti's comment [17:41] is this a result of pitti's review, in which case I can override, or is it something else? [17:41] ok [17:41] sil2100:^^ [17:47] Oh [17:47] bzoltan, sil2100: publishing [17:47] slangasek: \o/ [17:47] slangasek: yes, the silo was +1'ed by QA so it's good to go [17:48] woo my first non-jenkins publication [17:48] It's smooth [17:48] Death to jenkins! [17:48] slangasek: sil2100: I and preparing the next landing right away and all pitti's comments will be properly addressed. [17:48] I mean, first time I did the non-jenkins publish I was like: "hmmm, there's something different here, not sure what, the buttons look different..." [17:48] bzoltan: Well, seems the only remaining thing to address is the .la files. [17:48] Since I forgot about the rollout [17:50] https://trello.com/c/CPjxRFsY/3568-1808-ubuntu-landing-094-ubuntu-ui-toolkit-bzoltan was the ACK from QA [17:51] bzoltan: there is no need for you to further change anything because we've established that the ABI isn't changing until the Qt5 upstream soname changes [17:52] I was not giving you a free pass on this package going into the archive with bugs we consider blockers, I was agreeing that the package is ok as-is [18:03] bzoltan: oh - yes, as infinity says, the .la files should be cleaned up, but that's all [18:19] slangasek: thanks for removing the fpc powerpc stragglers! would you please have another look at removing the wine-development armhf binaries? LP: #1612180 [18:19] Launchpad bug 1612180 in wine-development (Ubuntu) "Please remove wine-developement binaries on armhf" [Undecided,Confirmed] https://launchpad.net/bugs/1612180 [18:19] ginggs: I won't have a chance to get to that today [18:20] slangasek: np [19:21] infinity: daily isos are failing to build because seeds need updating to drop pulseaudio-module-x11 recommends, I'm doing GNOME but maybe you could do the other flavors? [19:23] jbicha: um, lubuntu, ubuntu, mate, studio, xubuntu all seem to have current isos [19:24] maybe new pulseaudio hadn't been published yet, see https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu-gnome [19:25] it only affects GNOME, Kylin, MATE and regular Ubuntu [19:25] yeah i see gnome and kylin are behind [19:25] but mate and ubuntu published today [19:32] jbicha: https://launchpadlibrarian.net/281132926/buildlog_ubuntu_yakkety_powerpc_lubuntu_BUILDING.txt.gz >>> Setting up pulseaudio (1:9.0-2ubuntu1) ... [19:32] that's the same version [19:35] wxl: apt rdepends pulseaudio-module-x11 [19:44] jbicha: ah you're right. we don't have pulseaudio-module-x11. sorry for wasting your time [19:46] wxl: nope, you didn't waste my time :) [19:46] jbicha: ok well sorry for wasting MY time then XD [19:46] lol === davmor2 is now known as davmor2_hols [20:34] this is a tiny fix on top of our current SRU (in proposed), would be great to accept it today so we can get some more testing over the weekend! [20:34] (we have obviously confirmed this particular fix to be fine) [20:50] stgraber, done [20:50] apw: thanks!