[03:33] Good morning [04:30] morning! [04:48] pitti: hi! seen this already? https://tecnocode.co.uk/2015/06/01/checking-d-bus-api-stability/ [04:48] hey larsu! [04:48] larsu: fun, mbiebl just pointed it to me one minute ago [04:48] no, I didn't see it yet [04:48] looks great! [04:49] ha cool. pwhithnall just released it yesterday :) [06:54] good morning desktopers [06:57] Mirv, hey, easy question for you, why do we rebuild gsettings-qt on minor .1 qt updates (eg https://launchpad.net/ubuntu/+source/gsettings-qt/0.1+14.10.20140807-0ubuntu4) [06:59] seb128: morning (and thanks ;) ) [06:59] larsu, hey (yw ;-) [07:27] Guten Morgen! [07:28] morning willcooke [07:28] How goes larsu? [07:28] willcooke: tired. Got up at 6:30 [07:28] you? [07:29] :/ [07:29] I've got a cold *again* [07:29] ugh sorry man. Get better! [07:31] hey willcooke [07:31] woah new meeting routine [07:32] new routine? [07:33] seb128: send emails with the updates befpre [07:33] read again? :p [07:33] * seb128 hands larsu some tea [07:33] oh [07:33] seb128: hm? Typo? It [07:33] willcooke, you meant "can't" there right? [07:33] says "if you CAN make it, send updates" [07:33] larsu, that sentence doesn't make sense [07:33] * larsu drinks tea that he actually just made before seb128 mentioned it [07:34] hehe [07:34] it's very good, thanks [07:34] yw! :-) [07:34] I'm so used to do that sort of typo that my brain autocorrect them on reading, I didn't even notice it was wrong/different from other weeks :p [07:35] seb128: it's very important that you read willcooke's emails thoroughly [07:35] especially the meeting ones. He's testing us. [07:38] yeah, I almost falled for it, thanks for watching Lars ;-) [07:40] :) [07:44] doh [07:45] Good job you guys are pros [07:45] ;) [07:45] willcooke: but it was actually a typo? [07:45] yes [07:46] * larsu feels better now [07:49] larsu, oh, so you didn't trust me? :p [07:52] seb128: of course not! :P [07:53] lol [07:58] wheee - 50 MPH wind later on today [08:03] yo [08:03] hey Laney, wie gehts? [08:04] yo yo yo [08:04] hey didrocks who is on London time, how is the office today? [08:04] seb128: less sunny than yesterday [08:04] back to classical London weather [08:04] otherwise, good! [08:04] good :-) [08:04] yeah doing okay [08:05] i had the fire on last night though [08:05] on the first day of summer [08:05] crapseason [08:05] :/ [08:05] morning Laney, bonjour didrocks! [08:06] chimney definitely needs to be swept [08:06] * Laney smells of smoke [08:06] Cure some meats first :) [08:06] Laney, it's not summer yet ;-) [08:06] but yeah, it's cold here as well [08:06] yesterday was the first day of summer, i heard it on the news! [08:07] lie! [08:07] it was the local news though [08:07] the work experience kid probably read the internet wrong [08:07] hey larsu! [08:07] didrocks: what colour did you have your shower this morning? [08:07] aubergine [08:07] (no kidding) [08:08] good choice [08:08] you company man [08:08] * didrocks feels very corporate [08:08] Laney: he's on a work trip [08:08] it's the only option that makes sense, really [08:08] any reason wily can't be selected on packages.ubuntu.com yet? [08:08] adroitly observed [08:08] ahah [08:09] ochosi: go ask rhonda @ #ubuntu-motu [08:09] Laney: thanks, will do [08:09] lol [08:10] ochosi: btw, eta 8th june ;-) [08:10] Laney, didrocks, k, so Colin merged the cdimage changes and it seems the system is trying to build a snappy image now, https://launchpadlibrarian.net/208044896/buildlog_ubuntu_wily_i386_ubuntu-desktop-next_BUILDING.txt.gz [08:10] it hits " system-image-snappy-cli : Conflicts: system-image-cli but 3.0-0ubuntu2 is to be installed" though [08:11] so I guess some of the phone stuff tries to bring the system-image-cli and create issue [08:11] Laney: mine is still in the state "order received" with the same ETA :'( already tried to contact dell, but it seems they have shut down all their phone lines etc, meh [08:11] it could be the settings [08:12] seb128: hey. because of bug #1426335 [08:12] bug 1426335 in gsettings-qt (Ubuntu) "gsettings-qt uses a private symbol" [Undecided,New] https://launchpad.net/bugs/1426335 [08:12] seb128: do they provide the same interface? [08:12] Laney, I don't know, need to check [08:12] seb128: yeah, that's possible [08:12] in fact ubuntu-touch-core depends on system-image-cli [08:12] I guess -desktop includes -core? [08:12] that's the common stuff [08:12] IIRC, yeah [08:13] I wonder if we need a snappy-core [08:13] Mirv, thanks [08:13] larsu, ^ see bug from Mirv [08:18] seb128: uh! [08:18] how am I not getting bugmail on that project... [08:18] seb128: if they provide the same interface then you could make it Provide and then seed it from desktop or something [08:18] seb128: thanks! [08:18] otherwise we need to fix uss or whatever it is to work with both I guess [08:18] and then move it out from core to touch and desktop [08:18] Laney, right, I'm going to look at that, but the issue is not coming from settings there [08:19] touch-core depends on system-image-cli [08:19] Sweet5hark1: since the PPA doesn't seem ready yet i tried LO 5.0 from the LO website, but the icon themes are hardcoded there, so i can't really test anything with it... [08:19] larsu, yw! [08:19] Sweet5hark1: just to be sure, 5.0beta1 will pop up in the "fresh" PPA? [08:21] seb128: try something like http://paste.ubuntu.com/11515737/ [08:22] Laney, oh, good idea ... want to commit it since you did the change? ;-) [08:24] sneaky [08:24] but ok, this one time! [08:24] thanks :-) [08:25] oh wait, there's some weird thing around not being able to upload the package isn't there [08:25] I'm looking at the interface things for settings [08:25] you mean? [08:25] didrocks had problems with it the other day [08:25] was it on friday when infra went down? [08:25] no [08:26] something to do with the overlay ppa [08:26] ogra_: can I just upload touch-meta to wily as normal? [08:31] Laney: the seed is fixed now, it wasn't due to the overlay ppa, but missing package in the seed [08:31] so you should be able to regenerate as usual and upload [08:31] ok [08:34] Laney, sure, just verify the generated changelog twice [08:34] (as usual i guess ;) ) [08:34] measure twice, cut once [08:39] ochosi: no, beta and rcs for the first release of a new major series appear in libreoffice-prereleases ppa. its not there yet. [09:01] Sweet5hark: oh ok, good to know! will there be any sort of announcement or call for testing when it lands? [09:02] ochosi: usually I do twiiter/g+ posts, but not blog posts. [09:05] Sweet5hark: okeydoke, will look out for those! thanks! [09:15] hmmm, its not even noon yet and on #libreoffice-dev "plastic rooster porn" is being discussed. [09:29] Sweet5hark: it's noon somewhere... [09:31] :) [10:04] is there any point to a M-A: Same -dbg package? [10:04] s/S/s/ [10:08] Laney: wouldn't they file-collide left and right? [10:09] unless the source builds multiple -dbg packages of course, in particualr separate ones for librarires [10:09] but in that case, it seems easier to just drop the -dbg in ubuntu and use our ddebs :) [10:09] not if it's /usr/lib/debug/usr/lib/triplet/... [10:10] but in this case we have /usr/lib/debug/usr/bin/stuff already too [10:12] (so the :same doesn't work, so I'll drop it) [10:12] was wondering about this piece of delta on gtk+3.0 [10:25] NOOOOOOOOOOOOOOoooooooooooooo [10:25] * pitti hugs Laney, what happened? [10:27] in the last few days there's been a mir upload which broke the build of the gtk mir backend [10:29] * larsu hugs Laney and offers to help [10:29] although [10:29] it should have been broken by this one on the 12th https://launchpad.net/ubuntu/+source/mir/0.13.0+15.10.20150512-0ubuntu1 [10:29] but I never got that?! [10:30] larsu: I wonder if trunk is fixed [10:30] was hoping we'd get at least one upload without an update-mir-from-git patch :| [10:30] Mirv: I've tracked down the issue, it's from a header in qt. Are you sure this is a private symbol? I read somewhere that QObjectPrivate may be used from subclasses [10:31] Laney: bah... [10:31] attente: do you know if gtk-mir is fixed upstream to build with current mir? [10:31] is that patch we're using from upstream? [10:32] a couple of weeks ago we had additional changes on there [10:32] larsu: our marking of private symbols should be working correctly. you should be able to manually call dh-shlibdeps -- -v -v -v to see how that symbol brings the qtbase-abi dependency [10:32] and the qtbase-abi comes from using symbols in qtbase5-private-dev [10:33] no patch atm, 3.16.3's version was working [10:33] "was" [10:33] until may 29th [10:34] I'm going to add this test this week so they can't break it again [10:34] Mirv: how do we mark private symbols? (Asking to include some useful information in an upstream bug report) [10:34] Laney: I'm starting to regret that we have this in upstream gtk [10:35] looks like https://git.gnome.org/browse/gtk+/commit/gdk/mir?id=ea190a339a9e61a52db9d307568f12e0a234f52b [10:35] thanks attente! [10:35] larsu: pkgkde-mark-private-symbols debian/qtbase5-private-dev/usr/include , http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pkg-kde-tools/wily/view/head:/pkgkde-mark-private-symbols [10:35] it doesn't benefit anyone, since not everyone is using unstable ubuntu [10:36] is the api expected to stabilise any time soon? [10:36] hahahahahhahaaaaaah [10:36] hahahahahah [10:36] haha [10:36] * Laney weeps [10:36] funny. [10:37] well, then creating some consequences is interesting to me [10:37] Mirv: that's out definition of private, right? If upstream uses something in a header file, surely that's not their bug?! [10:37] s/out/our [10:37] Laney: are you doing a release? [10:38] ya, soon [10:38] can we put build/api fixes like that into the stable gtk branches? [10:39] larsu: yes, upstream can use private headers within itself, but the private symbol usage shoudn't be brought to our code. sorry, I don't actually understand what gsettings-qt is doing to use that symbol, so I'm just talking generally. [10:39] Laney: there's a branch wip/mir-unstable which fixes some things [10:41] i might just merge that in now [10:41] larsu: so it's something like you're using public headers only but somehow using those bring a private symbol usage anyway? [10:41] larsu: it seemed strange to me, but it's only gsettings-qt that's affected [10:44] attente: ok, do you want to make a new debian/patches/mir-backend patch on top of our bzr branch? [10:44] * Laney pushes that [10:45] Mirv: yes. Removing the call to the QQmlPropertyMap constructor in gsettings-qml.cpp makes it not link against that symbol [10:45] Laney: are you basing it off master? i'm just going to make sure it works on top of it and merge it in [10:45] Mirv: (but it also breaks functionality) [10:45] attente: 3.16.3 [10:46] might go to 3.17 if it eases mir backend pain though, but not straight away [10:46] so we need a patch on 3.16 for now [10:46] Mirv: qqmlpropertymap.h dereferences a QObjectPrivate - and has for quite a while [10:46] the thing is that nobody is using that class really [10:46] i'm guessing it will apply mostly cleanly [10:46] ok, can you take those patches then? i don't think gtk-mir is in a good state without it [10:46] Mirv: feel free to close bug #1461034 once everything if uploaded (if any), it's more for tracking [10:46] bug 1461034 in ubuntu-touch-meta (Ubuntu) "Brings offline qthelp and sdk documentation" [Undecided,New] https://launchpad.net/bugs/1461034 [10:47] attente: probably easiest if you provide an MP or a .patch [10:47] I'm worried I will miss something [10:47] good idea to merge your wip branch into master too I think [10:48] hi attente :) [10:48] Laney: sure [10:48] didrocks: thanks. I started yesterday but didn't commit yet since it was a bit more complicated and I need kalikiana to confirm some bits of what he needs for building UITK's own html documentation. but I can push the seed changes anyhow even if not cleaning everything from UITK itsef. [10:48] larsu: hi larsu :) [10:49] thanks! [10:49] lp:~ubuntu-desktop/gtk+3.0/ubuntugtk3 is what I was hoping to upload [10:51] Mirv: do you want to look into this again? Not sure an upstream bug is warrented just yet [10:54] larsu: well, I filed the bug because I couldn't fix it myself :( I thought you might have an educated guess what should be changed in the QML plugin to avoid the symbol. [10:54] Mirv: I cannot avoid the symbol. I'm using qt's API as documented [10:55] Mirv: and I don't think it's private API (as defined by upstream) [10:56] larsu: right, it's not also in the sense that you're not build depending on qtbase5-private-dev. it might be their bug that using a public API brings that private symbol into play, but I can't say for sure. [10:58] Mirv: QObjectPrivate is in a _p.h, but it is marked as Q_CORE_EXPORT and includes a macro named Q_DECLARE_PUBLIC [10:59] larsu: oh.. then it might be a bug in marking the symbols. mitya57 did we have a case like Q_DECLARE_PUBLIC before with the symbols? [10:59] No, I think the script doesn't handle it [10:59] Maybe we should fix it [10:59] not sure what exactly those mean, but declare_public sounds ... obvious :) [10:59] larsu: well then it's Invalid for gsettings-qt [10:59] * mitya57 looks [10:59] larsu: and a bug for qtbase [11:00] * larsu closes tab with upstream bug [11:00] Mirv, mitya57: cool. reassigning. Thanks [11:02] larsu: thanks for looking into it! [11:02] Mirv: no worries. sorry for taking so long. I wasn't subscribed to gsettings-qt bugs for some reason [11:03] (am now, of course) [11:03] Mirv, larsu: Q_DECLARE_PUBLIC is not for declaring classes public [11:03] #define Q_DECLARE_PUBLIC(Class) \ [11:03] inline Class* q_func() { return static_cast(q_ptr); } \ [11:03] inline const Class* q_func() const { return static_cast(q_ptr); } \ [11:03] friend class Class; [11:03] It is for defining some internal stuff in the class [11:03] (To be used later using Q_Q macro) [11:04] hmm, that explains why it's in _p.h after all [11:04] willcooke: see? all the hard work you missed in Cambridge: https://libreoffice-from-collabora.com/libreoffice-uk-hackfest-after-action-report/ === sabdfl_ is now known as sabdfl [11:04] * willcooke reads [11:04] So if it's in _p.h, then it's private [11:05] mitya57: well that's at least easier that there are no such corner cases upstream. the problem larsu is facing is that he's only using public API (qtbase5-dev) but ends up with that symbol. [11:05] * mitya57 reads the backlog [11:05] mitya57: is that macro documented anywhere? [11:06] larsu: It's only for internal use within Qt [11:06] mitya57: in short: gsettings-qt is using QQmlPropertyMap() protected constructor (as documented) and that pulls in this symbol [11:06] mitya57: well yeah, but I'd like to know what it's supposed to do [11:06] I think it's documented in https://wiki.qt.io/D-Pointer [11:06] Let me look at what can pull private symbols in your case [11:07] larsu: do you have qtbase >= 5.4.0+dfsg-6? [11:08] Nevermind, it's quite old and already in vivid [11:08] I'm on updated-this-morning W [11:14] larsu: Hm, I believe we can't do anything about this [11:15] mitya57: how do you mean? [11:15] As that constructor is really using a private QObject constructor, and is effectively inline as it's a template === MacSlow is now known as MacSlow|lunch [11:15] this is the current shlibdeps output http://paste.ubuntu.com/11518643/ [11:16] template [11:16] QQmlPropertyMap(DerivedType *derived, QObject *parentObj) [11:16] : QObject(*allocatePrivate(), parentObj) === mzanetti is now known as mzanetti|run [11:17] I think it was not intended for public use (and was only for use by Qt's own QQmlPropertyMap subclasses) [11:17] no, it's definitely intended for public use [11:17] we've fixed a couple of bugs with it already [11:19] why are these "private" symbols exported in the first place? Because other qt libraries need them? [11:19] Currently pkgkde-mark-private-symbols considers not only QSomePrivateClass methods as private, but also all other functions accepting an instance/pointer of a QSomePrivateClass [11:19] Yes, other Qt modules need them [11:19] And also bindings like PyQt [11:22] I fail to see how this is an upstream bug then, as they don't really consider those symbols private [11:22] They do [11:22] if some projects are using them, they must keep stability [11:22] ABI stability is guaranteed only for classes defined in public headers [11:23] I am thinking if we should allow methods *taking* private class instance to be public [11:23] fair enough, it's a qt bug then [11:23] mitya57: will you file it upstream please? [11:24] On Qt side this can be fixed by using a different constructor, but that will look like a workaround [11:24] I will ask lisandro for his opinion and then file a bug [11:24] thanks [11:24] I will go out for a run. bbiab [11:25] thanks mitya57 for looking into it too! [11:25] YW! [11:29] larsu: I have just noticed that that code dereferences a QObjectPrivate* pointer, so it actually passes an instance, not a pointer. [11:29] And as sizeof(QObjectPrivate) will change in future, then that constructor definitely is not ABI stable [11:32] So we can't really do anything about it, and it's an upstream (minor, not-easily-fixable) bug [11:55] Laney, what test do you want to add? making sure that mir update don't stop gtk from building? is that really something we should block uploads on? we don't block gcc uploads on any ftbfs they create in the archive [11:56] doko does test rebuilds and we try to fix as many as possible before uploading [11:58] I don't think randomly finding out that the api has broken when we come to want to upload gtk is a good situation [11:59] we can assume that any mir update is going to require updating the gtk backend [12:00] so maybe just enforce that through packaging rules [12:00] how? [12:02] Depends >> libmir_current, << libmir_nex [12:02] nex [12:02] next [12:02] grrr [12:02] ... [12:03] you mean you want to force a rebuild of gtk every time? [12:03] I don't see how it helps - if it's broken then it needs fixing at this point anyway and if it's not then you rebuild for no reason [12:03] yes [12:03] oh well [12:04] go for a build test if you want [12:04] it feels boggus to me to "block" on such changes [12:04] maybe a daily build recipe if those work still [12:04] we should flag the issue [12:04] unsure we should block [12:04] buildtime is not running, it doesn't impact users [12:06] could also put it in their CI [12:07] but then where to target fixes [12:08] hey, unsure, they could build from our packaging trunk [12:08] but we could have unrelated changes stacked there [12:08] so it's suboptimal [12:09] ya [12:09] mitya57: they could pass a reference, no? Or move the constructor into the .cpp === MacSlow|lunch is now known as MacSlow [12:14] kgunn: got a sec to chat mir landings? [12:14] kgunn: Wondering if I can add a step to the pre-upload checklist for a gtk rebuild so that we always keep it building in the archive [12:15] Laney, kgunn, do we ensure that the qt qpa still builds before mir uploads? [12:15] Laney: sound like a good idea, something we could automate [12:15] if not we should do that as well [12:16] would be good, especially if automated [12:16] seb128: you mean qtubuntu yes [12:16] kgunn: got a URL? [12:16] Laney: to? [12:16] kgunn, k, good, so just need to do the same for gtk ;-) [12:16] $checklist [12:16] * Laney will edit it [12:16] Laney: https://wiki.ubuntu.com/Process/Merges/TestPlans/Mir [12:17] camako: ^ we need to inform vogons [12:17] got it [12:17] mitya57: anyway. got a bug? [12:17] camako: and put a card on backlog to automate [12:17] Laney: thanks [12:17] thanks for agreeing! [12:18] Laney: nice! [12:18] done === mzanetti|run is now known as mzanetti [12:53] larsu, Mirv: https://bugreports.qt.io/browse/QTBUG-46433 (sorry for the delay) [12:53] mitya57: thanks :) [12:54] seb128, any progress on fixing GtkFileChooser for sorting folders first? [12:55] seb128, upstream has commit 2aa3eea781ed21a02ecdf1e3c753a1ec5694d6c8 [12:56] xclaesse, I forgot about that, do you know if there is a bug open about it on launchpad? [12:56] but it's not in 3.14 that ubuntu has [12:56] seb128, don't know, but will open it now if I can't find one ;) [12:56] xclaesse, yeah, as said we are not going to add an UI to the stable version, rather just change the default there [12:56] Laney, ^ can you do that if you do a gtk upload? [12:57] * xclaesse is always lost in lp for search/report bugs [12:58] xclaesse, https://launchpad.net/ubuntu/+source/gtk+3.0/+bugs?orderby=-id&start=0 doesn't seem to have one [12:58] just click on "report a bug" on the right [12:59] I don't remember this [12:59] we disagree with upstream? [12:59] dunno what upstream thinks [12:59] you want to change the default [12:59] they add an UI back to change the preference [12:59] in 3.16 [13:00] yes, xclaesse asked if we could make the old behaviour still the default [13:00] or backport the UI [13:00] the UI would mean new string [13:00] reported https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1461085 [13:00] Launchpad bug 1461085 in gtk+3.0 (Ubuntu) "GtkFileChooser should sort folders first" [Undecided,New] [13:00] Laney, it's just restoring things the way they were, I think it makes sense for at least 3.14 which doesn't have an UI for users who want the old way [13:00] for 3.16 we can argue [13:01] since it has the UI users can tweak it to their liking [13:01] I don't really care, *but* it is changing the behaviour in a stable release [13:02] right, back to a sane one :-) [13:02] * xclaesse consider it fixing a regression [13:03] also to a consistent one with nautilus/gtk2/qt [13:03] as seb128 said, if we had an setting then I wouldn't care much about the default tbh [13:03] well, I still think the default should be consistent between toolkits, or at least between gtk versions [13:03] that means they have to maintain gtk2? [13:03] yes [13:04] or that we have to be conservative with our changes [13:04] it's also inconsistent with nautilus. IMO if we want to change the default, it should be changed in both. [13:04] +1 [13:04] I think that change was just not properly thought through [13:04] so we should revert the behaviour to the old one [13:04] it's only a settings so it's easy [13:08] Laney, in fact that seems like more an ubuntu-settings tweak, let me do that change [13:09] ok, as you wish [13:10] kgunn: I think that past mistakes are being fixed both in Mir and in the process. I'd prefer we only fix them in Mir. [13:16] xclaesse, uploaded to wily and SRUed to vivid [13:17] \o/ [13:17] seb128, thanks ! [13:17] yw! [13:21] alan_g: if you mean "let's not add another manual step, but an automated test" agreed.... [13:22] kgunn: I mean like we accidentally had clients-side users linking to libmircommon and that meant we didn't realise that a libmircommon ABI bump would break them [13:23] Which is why we had to pull qtubuntu into the release process [13:24] We should have checks /in Mir/ that this can't happen, not have steps in the release process [13:27] larsu: upstream pointed me that I'm wrong [13:27] I don't think it scales to require a rebuild of qtmir, platform-api, libubuntu-application-api, sdl, xserver, gtk, egl1-mesa, etc. for a Mir release that maintains ABI. === rickspencer3_ is now known as rickspencer3 [13:35] kgunn: we're breaking the client ABI with the 0.14 series so we'll have to pay the price for that release. But many of the changes are intended to give better ABI and API stability. And just when we deliver that the intention appears to be to gate the release on rebuilding all the rdepends anyway. [13:41] hi, i just did a dist-upgrade, but my machine is no longer passing the boot stage [13:41] wondering if anyone else has this problem? this is my boot.log: http://paste.ubuntu.com/11521041/ [13:42] alan_g: ah, i get you now @abi, but i do think we should have a sanity integration test for gtk-mir somewhere in the release process [13:42] i was kinda thinking this during the sprint anyhoo [13:45] kgunn: I'm not sure of the names, but I thought packages could specify some smoke tests to run when dependencies update. But that these would typically be running the archive binaries, not rebuilding from source. [13:46] so gtk-mir-smoke-test would gate its upstreams including Mir [13:47] alan_g: I proposed that, we can definitely do it but it's quite late in the process [13:47] unless you want to run these also as part of mir's CI or something [13:48] Laney: I'd suggest Mir's autolanding definitely. CI would depend on their cost [13:49] you mean proposed-migration? [13:49] But I don't think we should be gate on FTBFS [13:50] Laney: what's "proposed-migration"? [13:50] the tests that run after you upload a package [13:50] mitya57: that bug report doesn't describe the issue we're seeing though... [13:51] gating on build failures is exactly what I want, we shouldn't have gtk broken in the archive at any point [13:51] mitya57: the size of the struct doesn't need to be known, that's true. You were arguing that an application using qqmlpropertymap shouldn't link against a private constructor [13:53] Laney: Mir changes autoland on an integration branch that is pulled into the releases. That's when I think we should first identify downstream incompatibilities. (Not stop the merge but flag some action is needed before release.) [13:54] Fair enough, if that's how you want to implement it - the end result is what I care about [13:55] But that's not "kgunn: Wondering if I can add a step to the pre-upload checklist for a gtk rebuild so that we always keep it building in the archive" [13:56] * Laney shrugs [13:56] That's what *I* can do [13:56] you can optimise the process if you want [13:58] * alan_g wants to "ensure the downstreams in archive works", not to "always rebuild all the downstream" [14:00]