[00:17] <xnox> qtdeclarative-opensource-src seems to have a weird binary split. For binaries that are in main, only those on i386/amd64/armhf are in main powerpc/ppc64el/arm64 are in universe which makes other packages depwait on powerpc/ppc64el/arm64
[00:19] <infinity> xnox: Can fix.
[00:20] <infinity> Though, I don't see this...
[00:20] <infinity> Oh, cause it's in proposed, and my report only does the release pocket.
[00:20]  * infinity hunts and fixes manually.
[00:22] <xnox> infinity: yeah, it's quite confusing. Ideally we'd have an architecture-mismatches-proposed.txt report or something like that.
[00:23] <infinity> No, ideally this wouldn't happen at all. :P
[00:23] <xnox> =))))))))))))))))))
[00:23] <infinity> But it's another fun side-effect of some bugs with copying from PPAs.
[00:23] <infinity> Also, whee.  Maximising a window under LIM gives you NO MENUS.
[00:23] <infinity> I kinda expected the top bar to become my menu/title bar...
[00:24] <xnox> infinity: for me there are menus, they are just below the top bar, cause window is maximazied underneath it.....
[00:24] <infinity> xnox: "below", as in Z-index, or you have a fat top bar?
[00:24] <xnox> "Z-index"
[00:24] <infinity> Cause it may well be Z below, but how would I know? :P
[00:25] <xnox> but somehow at the moment i have both LIM and global menus simultaneously =/
[00:25] <infinity> Cute trick.
[00:25] <infinity> Alright, overrides fixed, as of the next publisher run.
[00:37] <infinity> xnox: Do you know if there's already a bug for the LIM Z-Index I HAZ NO MENUS OR BUTTONS thing?
[00:37] <infinity> Given all the users would wouldn't know how to use Alt-Space or similar, I guess they'd just be stuck with that window forever.
[00:37] <xnox> infinity: i only saw seb128 saying they have dozens of bugs / duplicates about LIM and Lock Screen.
[00:38] <infinity> Hrm, my screel lock seems to be fine.
[00:38]  * infinity does one more pass on qt5 component mismatches.
[00:38] <xnox> infinity: the most hallarious one is that one needs to use indicator to get unstuck from: alt+tab, release tab, keep pressing alt, press ctrl+l
[00:39] <xnox> infinity: input keeps going into the session, yet lock screen is the highest on the Z-order and thus one can't see anything, nor unlock the lock screen =)
[00:40] <infinity> xnox: Hahaha.  Cute.
[00:41] <infinity> xnox: Doesn't seem like something I'd do by accident, but fun to do on purpose.  If I was at a sprint right now, I'd so be locking people's machines that way and waiting for passwords in IRC.
[01:06] <xnox> infinity: thanks for promotions, looks much better now. But why is this still failing? https://launchpad.net/ubuntu/+source/qt3d-opensource-src/5.0~git20130731-0ubuntu2
[01:13] <cjwatson> xnox: that's just lack of upstream architecture support, isn't it?
[01:13] <cjwatson> oh, it's a different failure from before
[01:13] <xnox> cjwatson: it's failing to install dependencies, no?
[01:14] <cjwatson> it is now, but previously in the PPA it failed with a real build error later
[01:14] <cjwatson> so it isn't going to do better even if you fix this
[01:14] <xnox> =(
[01:14] <xnox> porter box doesn't have -proposed enabled, so isn't that useful either =(
[01:15] <cjwatson> any of the recent qt5 landings were already tried on all arches; they're probably being retried again in the primary archive, but are unlikely to do better
[01:15] <xnox> cjwatson: ok, there was architecture-component missmatch in proposed which infinity fixed now.
[01:16] <cjwatson> yeah, I saw
=== stgraber_ is now known as stgraber
[01:16] <xnox> let me retrace my steps from proposed-migration report where i thought it might be a problem blocking the migration (once the block is lifted)
[01:19] <cjwatson> hm, yeah, there is something still wrong
[01:20] <cjwatson> attacking with chdist
[01:20] <cjwatson> ah, this one is arch-indep
[01:21]  * cjwatson promotes libqt5core5a qtbase5-doc-html to main
[01:21] <infinity> I already got those.
[01:21]  * cjwatson ctrl-cs quickly
[01:21] <infinity> In my last pass.
[01:21] <cjwatson> lucky my internet is slow ;-)
[01:21] <infinity> I think...
[01:21] <cjwatson> https://launchpad.net/ubuntu/trusty/i386/libqt5core5a doesn't show it
[01:22] <infinity> Yeah, maybe not.
[01:22] <infinity> The names all look the same.
[01:22] <infinity> Ahh, indeed, those two are on c-m-p, they weren't before.  Or I missed them in my copy and waste run.
[01:22] <infinity> Weird.
[01:23] <infinity> Carry on.
[01:23] <cjwatson> ok, doing
[01:23] <xnox> qtsensors5-dev looks weirdly split as well.
[01:24] <infinity> Anything that was NEW in those arches probably is.
[01:24] <infinity> Let me see.
[01:24] <xnox> (it's in main on primary arches, universe on ports arches)
[01:24] <xnox> http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt for -proposed would be nice =)))
[01:24] <infinity> xnox: I'll get the qtsensors ones.
[01:25] <xnox> infinity: thanks.
[01:26] <infinity> Alright, that source package is sorted.
[01:28]  * infinity hunts for more.
[01:30] <infinity> Alright, found more. :P
[01:35] <infinity> Okay, missed that publisher run.  As of the next, I think all of qtdeclarative's rdeps should be in a sane state.
=== kitterma is now known as ScottK
[01:57] <xnox> cjwatson: so qt3d build on ppc64el fails on embedded copy of assimp, which did build fine in the archive, i wonder why embedded 3rdparty copy is used.
[01:58] <cjwatson> ok, but probably best not to ask me :-)
[02:41] <xnox> compiles well, after porting, and only two test failures on .3ds file format. will poke that more tomorrow.
[02:41]  * xnox Zzzzz
[03:02] <darkxst> I suppose its getting too late now to have any change of bug 1228765 happening?
[03:02] <ubot2> Launchpad bug 1228765 in unity-control-center (Ubuntu) "[FFe] Implement DisplayConfig dbus interface and transition to gnome-desktop 3.10" [Low,In progress] https://launchpad.net/bugs/1228765
[03:11] <slangasek> darkxst: has this been coordinated with the Ubuntu Desktop team?  The two linked branches for the unity packages are both marked 'disapprove'
[03:12] <slangasek> I also don't understand the claim in the bug description that the move to 3.10 was blocked by the unity forks of g-s-d and g-c-c... it sounds like these "forks" are *still* entangled (and therefore blocking)
[03:12] <slangasek> (so, what was the point in forking if they still have to be upgraded in lockstep?)
[03:12] <darkxst> slangasek, desktop team wouldn't consider this work unstill things were forked
[03:13] <darkxst> the whole point of forking was so ubuntu GNOME can have g-s-d/g-c-c 3.10
[03:13] <slangasek> darkxst: I'm talking about the merge proposals that were specifically raised on the unity-control-center and unity-settings-daemon packages, which are the forked versions
[03:14] <slangasek> if they're forked, why are they tied into this FFe request?
[03:14] <darkxst> right, they need to be patched for the new gnome-desktop api
[03:14] <darkxst> and they got marked disapproved because Noskcaj proposed merges without an FFe
[03:16] <slangasek> I would want to see an explicit ack from the Desktop team that they're happy with letting this in, before I would sign off on this
[03:16] <slangasek> obviously we don't want to be holding back Ubuntu-Gnome, but we are past FF and I'm not in a position to evaluate the impact on the desktop
[03:19] <darkxst> they were ok with it when I proposed the FFe (a couple of weeks ago), but I can check with them if still ok
[03:20] <slangasek> darkxst: that's not how I understand the comments in the bug log, where a member of the desktop team last week is calling it 'risky'
[03:21] <darkxst> its seb's whole 1 step at a time policy, that made this end up so late!
[03:25] <darkxst> I wanted to land this stuff a month ago, but Seb said it had to wait for u-s-d to be done
[03:27] <slangasek> well, whatever the reason, it's now in a place where it needs a FFe; and I don't think any member of the release team is going to say "yes" to an FFe if the affected flavors are saying "no"
[03:31] <slangasek> (and if it does require a new version of bluez, like bug #1267909 suggests, that's a whole new level of due diligence required)
[03:31] <ubot2> Launchpad bug 1267909 in unity-control-center (Ubuntu) "Update Bluetooth panel" [Wishlist,Triaged] https://launchpad.net/bugs/1267909
[03:32] <darkxst> slangasek, no intention to update BlueZ this cycle
[03:33] <darkxst> all bluetooth changes were reverted in our packaging so it works fine with gnome-bluetooth 3.8
[03:34] <slangasek> ah, and I see now that you said so on the bug - sorry for overlooking
[03:38] <darkxst> anyway I will chat again with desktop team tonight and see if they will still ack this
=== SpamapS_ is now known as SpamapS
[08:54] <darkxst> infinity, around?
=== sil2100_ is now known as sil2100
[10:01] <didrocks> anyone available from the RT to override some packages for migrating?
[10:03] <didrocks> (5.2 migration)
[11:15] <Riddell> didrocks: yo, what's it need?
[11:15] <didrocks> Riddell: hey, I had to go with the "removing binary packages" that will be reintroduced in next upload anyway (as the Qt 5.2 transition is big, I'm trying to ensure that we are well advanced before EOD)
[11:16] <didrocks> I check all rdepends, and it won't introduce uninstallable packages
[11:16] <didrocks> (as most of them are just new build in -proposed)
[11:22] <Riddell> didrocks: let me know if I can help
[11:22] <didrocks> Riddell: yeah, will do, thanks for the offer :)
[11:38] <xnox> uploaded remaining 6 packages that didn't rebuild against libqt5core5a yet.
[11:39] <xnox> that should make britney more happy about qt5.2 transition.
[11:47] <didrocks> xnox: oh, Mirv did you miss those ^
[11:47] <didrocks> I saw cordova-ubuntu
[11:48] <didrocks> xnox: hum, why wallch?
[11:48] <didrocks> it's qt4
[11:49] <didrocks> same for qgo, isn't it?
[11:53] <Mirv> didrocks: yes, it's possible, only last week I added peg-e, pokerth, mediscanner2 (which was new user as well)
[11:54] <Mirv> and phonon
[11:54] <Mirv> my fault was to use reverse build depends checks only most of the time
[11:55] <Mirv> plus generally having enough stuff to do all the time to remember to check whether http://pad.ubuntu.com/qt52-dependencies was complete
[11:56] <Mirv> not that I'd have seemingly found qgo anyway
[11:58] <Mirv> I did see those phonon plugins, then forgot about them after I built the phonon itself :) nice that none of those missed ones were too big
[12:01] <xnox> didrocks: wallch 4.0-0ubuntu3 depends on libqt5core5 (>= 5.0.2), libqt5gui5 (>= 5.0.2), libqt5network5 (>= 5.0.2), libqt5webkit5, libqt5widgets5 (>= 5.0.2)
[12:01] <xnox> didrocks: thus it's qt5, and totally needed rebuild for libqt5core5a.
[12:02] <Mirv> ah, so there's a 4.0 wallch in -proposed and that's why reverse-depends doesn't show it or qgo?
[12:02] <xnox> didrocks: dito qgo.
[12:02] <Mirv> and 3.0 was Qt4
[12:02] <didrocks> xnox: ah, so they were stuck in proposed already
[12:02] <xnox> didrocks: Mirv: yes, all of those were packages that were stuck in proposed, and got build against libqt5core5.
[12:02] <Mirv> thanks xnox for spotting all of those
[12:02] <didrocks> ok, making sense then
[12:03] <didrocks> xnox: so, they were just being blocked I guess, not blocking Qt 5.2 migration itself?
[12:03] <xnox> Mirv: well, proposed-migration did =) then I wrote a ben transition tracker that generate a list for me ;-) it's not like I scanned the archive by hand ;-)
[12:03] <didrocks> as previous version in release were 4.0, they will just not migrated
[12:04] <xnox> didrocks: i don't know, but these rebuilds should lower the uninstallable count and make the proposed-migratin page look more sane.
[12:04] <xnox> didrocks: e.g. with libav britney was blocking on "leaf packages like above" for a long time, until it didn't and allows NBS into release pocket.
[12:05] <xnox> didrocks: i hope you didn't do any removals to force qt5.2 transition in, did you?
[12:06] <xnox> yeah, the list is now very small.
[12:06] <xnox> i'll wait for phonon to build and then it should be clear what remaining couple of packages are that britney points out.
[12:07] <xnox> cause e.g. britney still thinks that " ubuntu-touch" would become uninstallable =))))))
[12:07] <didrocks> xnox: we had to remove some packages, this was discussed already as it's temporary and agreed on
[12:07] <didrocks> (arm64/ppc64el and powerpc)
[12:08] <xnox> didrocks: which ones were those? i don't see how those could be blocking qt5 transition, given that most of qt5 never built on those.
[12:08] <xnox> (qtdeclarative and up)
[12:08] <didrocks> xnox: qtdeclarative is fine, but not the sdk
[12:08] <xnox> oh, right.
[12:09] <didrocks> xnox: and there is another MP to fix the sdk, but colin told to go ahead and do that once the transition is done
[12:09] <xnox> cool, there still looks something odd with libaccounts/signon stack though.
[12:09] <didrocks> yeah, I did remove for libaccounts/signon
[12:09] <didrocks> so should be fine
[12:09] <didrocks> (part of the same set blocked by sdk and have no rdepends)
[12:10] <didrocks> xnox: tell me if you see anything else bad, multiple eyes help :)
[12:12] <mdeslaur> hrm, the archive is busticated
[12:13] <mdeslaur> libdbusmenu-qt in now available, but was built against qt5.2 that's still in -proposed
[12:13] <didrocks> I didn't touch that one
[12:13] <didrocks> weird that it migrated?
[12:13] <mdeslaur> yeah, quite weird
[12:14] <didrocks> waow, you're right
[12:14] <xnox> well, britney goes by uninstall count, thus removing a package can trade _anything_ into the release pocket.
[12:14] <didrocks> ah I know, there are some magic IIRC
[12:14] <didrocks> to remove the dep on qt5
[12:14] <didrocks> so that we can have appmenu without bringing the whole qt4 and qt5 on the image
[12:14] <didrocks> so that's why :/
[12:14] <xnox> yeah, it is weird, it only _suggests_ qt5 libs.
[12:14] <didrocks> yep
[12:15] <didrocks> IIRC, that was that, was years ago (when appmenu was introduced)
[12:15] <didrocks> xnox: hum, all those plugin on i386 is worrisome
[12:15] <mdeslaur> I have a funny feeling this is going to break people
[12:15] <mdeslaur> (well, it already broke ubuntu-sdk)
[12:15] <didrocks> mdeslaur: yeah, and depends how long we are going to take before the transition ends
[12:16] <xnox> didrocks: i wonder if it's just a hint missing, or something like that.
[12:16] <mdeslaur> bug 1292487
[12:16] <ubot2> Launchpad bug 1292487 in libdbusmenu-qt (Ubuntu) "libdbusmenu-qt can't resolve symbols" [Undecided,New] https://launchpad.net/bugs/1292487
[12:17] <didrocks> xnox: yeah, can be, we need to try a chdist?
[12:18] <xnox> didrocks: right there are hints missing, you'd want to hint for e.g.
[12:19] <xnox> didrocks: signon-plugin-oauth2 to go in together with qtbase-opensource-src
[12:19] <didrocks> xnox: I never did that (only block/unblock) in britney, mind doing or guiding me? :)
[12:19] <xnox> didrocks: and i think that's it.
[12:19] <didrocks> xnox: you just apt-get install both btw to confirm it?
[12:20] <didrocks> mdeslaur: just for the note, if it's the only transient issue with this migration involving 122 packages, I will be happy ;)
[12:20] <xnox> yeah, they are installable. plus hints are not forcing anything, it's just telling britney to consider the packages together in the analysis. So it would still validate that they are installable.
[12:20] <didrocks> xnox: ok, I just:
[12:20] <didrocks> hint signon-plugin-oauth2 qtbase-opensource-src
[12:20] <didrocks> or something else?
[12:22] <xnox> didrocks: it's like this: easy ubuntu-settings/14.04.4 gnome-session/3.9.90-0ubuntu11
[12:22] <xnox> so:
[12:23] <xnox> didrocks: wait that will not work =)
[12:23] <didrocks> xnox: easy qtbase-opensource-src/5.2.1+dfsg-1ubuntu7 account-plugin-evernote/0+14.04.20140113.2-0ubuntu1?
[12:23] <didrocks> weird
[12:23] <didrocks> account-plugin-evernote is already in the release pocket
[12:24] <xnox> didrocks: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html  signon-plugin-oauth2  has not satisfiable dependencies on arm64.
[12:24] <didrocks> ah yeah, making sense that all plugins fail
[12:24] <xnox> didrocks: which i think means that sigon-plugin-oauth2 should be removed on arm64 from trusty-release.
[12:24] <didrocks> xnox: let me check rdepends
[12:24] <xnox> didrocks: or better, fixed.
[12:24] <didrocks> xnox: all that will be fixed in a second time
[12:25] <didrocks> let's get everything in, there is already a followup silo for the sdk
[12:25] <xnox> didrocks: so all are valid candidates, which is good, but signon-plugin-oauth2 on arm64.
[12:25] <didrocks> xnox: yeah, I didn't grep multiple times the file to get to that state TBH :)
[12:25] <didrocks> so account-plugin-tools
[12:25] <didrocks> ok, only ubuntu-touch as a rdepends
[12:26] <xnox> didrocks: account-plugin-tools is arch:all, that's fine for it to not be installable on one arch =)
[12:26] <didrocks> yeah, arch:all
[12:26] <xnox> and there is no ubuntu-touch on arm64.
[12:26] <didrocks> so ok, seems only signon-plugins-oauth2
[12:26] <didrocks> really? striking news! ;)
[12:27] <xnox> didrocks: do you want me to upload ubuntu-touch-meta which builds on arm64? i can totally do this +)))))))
[12:27] <didrocks> xnox: tsssssssss ;)
[12:27]  * xnox dch -i "Didrocks said I should do this..."
[12:27] <didrocks> ahah
[12:27] <xnox> i'll sponsor it with your name ! =)
[12:28] <didrocks> xnox: I bet you will be so evil to do that ;)
[12:28]  * didrocks flushed signon-plugin-oauth2
[12:28] <didrocks> ok, so arm64 will be happy
[12:28] <xnox> yeah, so next britney run, hopefully it will migrate.
[12:29] <didrocks> yeah, let's see ;)
[12:31] <didrocks> xnox: at least, when I had my block, it was easy to grep on "didrocks"
[12:49] <didrocks> common britney, refresh!
[12:49] <didrocks> come on*
[12:50] <xnox> 12:53?!
[12:50] <didrocks> xnox: prediction of 30 minutes + 21s? :p
[12:51] <xnox> didrocks: it will take more than 21s for britney to process the migration, if it migrates stuff =)
[12:51] <didrocks> xnox: yeah, so you mean the longer we wait, the more hopeful we can be? :p
[12:52] <didrocks> xnox: in case I removed the packages before it took them into account :p
[12:52] <xnox> not this time =(
[12:52] <xnox> the package is removed, yet britney still thinks it's out of date.
[12:52] <didrocks> argh, refreshed
[12:52] <didrocks> yeah
[12:53] <xnox> oh!
[12:53] <xnox> yeah =)
[12:53] <xnox> Valid candidate =)
[12:53] <didrocks> hum
[12:53] <didrocks> still failed
[12:53] <didrocks> failed: qtbase-opensource-src
[12:53] <xnox> SUCCESS (129/0)
[12:53] <didrocks> ah
[12:53] <xnox> loads of stuff did migrate.
[12:53] <didrocks> yeah :)
[12:53] <didrocks> why the stenza after then?
[12:54] <xnox> oh, there are NBS left around.
[12:54] <didrocks> xnox: I'm not sure to follow you where you are seeing that
[12:54] <xnox> didrocks: britney treis to remove "old packages" but that's mostly a lie in britneys brain, as those actions are not hooked up to launchpad api whats-so-ever.
[12:54] <didrocks> ahah
[12:54] <didrocks> ok, making sense
[12:56] <xnox> published in release pocket =) no idea if it timedout doing copies, thus one publisher run might be partial ;-)
[12:58] <xnox> didrocks: well done, sir! =) now the cleanup can proceed.
[12:58] <didrocks> xnox: thanks for your help as well!
[12:58] <didrocks> xnox: I'll still retake the list
[12:58] <didrocks> and grep against next -excuses
[12:59] <didrocks> to ensure nothing is left
[13:18] <xnox> didrocks: we definately need another publishing cycle, as quite a few things didn't manage to finish copying. e.g. http://people.canonical.com/~ubuntu-archive/nbs.html is full of lies =)
[13:18] <didrocks> xnox: yeah, seeing that, I've my grep ready as well :p
[13:18] <xnox> what do you grep and how? =)
[13:19] <didrocks> for p in `cat package_list`; do grep $p update_excuses.html; done
[13:22] <xnox> retrying qtmultimedia-oepnsource-src on powerpc, hopefully sagari will do better (e.g. the one test-suite failure is not seen in debian build)
[13:30] <didrocks> yeah :)
[14:01] <apw> it seems that something odd happened maintainer side for hv-kvp-daemon-init, and in 0.4 they inadvertantly reintroduced the i386 build and then removed it, this has triggered an NBS on i386 for the later versions
[14:10] <xnox> apw: affirmative.
[14:10] <xnox> didrocks: could you please remove  hv-kvp-daemon-init version 0.4ubuntu0 suite trusty-proposed arch i386
[14:10] <xnox> it's not-built-from source, yet we have no NBS report for things in -proposed.
[14:17] <xnox> infinity: didrocks: please promote qt3d-oepnsource-src binaries on arm64/powerpc/ppc64el into main where same binaries are in main on other arches. (e.g. all packages but qtdeclarative5-qt3d-plugin)
[14:17] <xnox> $ rmadison -S qt3d-opensource-src | grep trusty
[14:19] <seb128> xnox, looking
[14:19] <xnox> seb128: thanks.
[14:22] <seb128> xnox, done
[14:22] <xnox> seb128: thanks. both requests? =)
=== henrix_ is now known as henrix
[14:23] <seb128> xnox, no, the nbs thing seemed lower priority :p
[14:24] <xnox> seb128: but but it's needed for Microsoft Hyper-V hypervisor support.
[14:24] <xnox> seb128: what can I do for you to process that one as well? =)
[14:25] <seb128> xnox, looking...
[14:25] <seb128> $ ./remove-package -s trusty-proposed -a i386 -m "NBS" hv-kvp-daemon-init
[14:25] <seb128> Removing packages from trusty-proposed:
[14:25] <seb128> 	hv-kvp-daemon-init 0.4ubuntu3 in trusty
[14:25] <seb128> 		hv-kvp-daemon-init 0.4ubuntu3 in trusty amd64
[14:25] <seb128> hum
[14:25] <xnox> no.
[14:25] <seb128> what did I do wrong? ;-)
[14:25] <xnox> $ rmadison -S hv-kvp-daemon-init | grep trusty
[14:25] <xnox>  hv-kvp-daemon-init | 0.3ubuntu9         | trusty           | source, amd64
[14:25] <xnox>  hv-kvp-daemon-init | 0.4ubuntu0         | trusty-proposed  | i386
[14:25] <xnox>  hv-kvp-daemon-init | 0.4ubuntu3         | trusty-proposed  | source, amd64
[14:26] <xnox> seb128: i only wanted the 0.4ubuntu0 and i386 removed.
[14:26] <seb128> oh, -b
[14:26] <seb128> xnox, I know, I was just wondering why it was listing amd64
[14:26] <seb128> I did "n" that btw
[14:26]  * xnox is not a trained AA at all, so i'm not sure about the utils much.
[14:27] <seb128> I got confused, change-override defaults to binaries
[14:27] <seb128> remove-package is the opposite, you need to -b
[14:27] <xnox> yeah, -b seems to do the right things.
[14:27] <seb128> $ ./remove-package -s trusty-proposed -a i386 -m "NBS" -b hv-kvp-daemon-init
[14:27] <seb128> Removing packages from trusty-proposed:
[14:27] <seb128> 	hv-kvp-daemon-init 0.4ubuntu0 in trusty i386
[14:27] <seb128> Comment: NBS
[14:27] <seb128> Remove [y|N]? y
[14:28] <seb128> xnox, ^ done
[14:28] <xnox> apart from: lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized, for me =)
[14:28] <xnox> seb128: yeah, looks good! thanks =)
[14:28] <seb128> yw!
[14:42] <cjwatson> xnox: FYI the touch-release people are only supposed to have permissions to block/unblock, not to apply arbitrary hints
[14:45] <xnox> cjwatson: ok, i thought didrocks was normal-release as well. I guess AAs are not actually included in ~ubuntu-release, despite the large overlap.
[15:09] <apw> seb128, thanks
[15:09] <seb128> yw!
=== sil2100_ is now known as sil2100
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[16:54] <infinity> Anyone object to me breaking our "never release on Fridays" rule for tzdata, so I don't forget about it later and anger Turkey? :P
[17:09] <ScottK> infinity: Please go ahead.
[17:29] <infinity> Have our tools become sentient?
[17:29] <infinity>   [ CI bot ]
[17:29] <infinity>   * fixes the segfault occuring when the scale factor is < 1.0 (LP:
[17:29] <infinity>     #1288166)
[17:30] <mdeslaur> oh wow, can I fork that for a CVE fixing bot?
[17:57] <dbarth> hey there
[17:58] <dbarth> slangasek: hi, i guess that will fall on your plate somehow, but i'm trying to make sure you guys are aware of the FFE request for Oxide
[17:58] <dbarth> on the desktop
[17:58] <dbarth> https://bugs.launchpad.net/libunity-webapps/+bug/1290535
[17:58] <ubot2> Launchpad bug 1290535 in webbrowser-app (Ubuntu) "[FFE] Webapps support for the new Oxide container" [Undecided,New]
[18:00] <dbarth> alex-abreu can fill you in later in the day if you need info/status
[18:07] <slangasek> dbarth: thanks for the info
[18:11] <xnox> infinity: yes they have. =) i've noticed a few uploads like that ;-)
[18:12] <xnox> infinity: at times, it steals my commits like that, because they are merged up due to conflicts and thus somehow the change gets attributed to the ci bot committer, instead of myself.
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[20:42] <rsalveti> can someone help getting qtcreator-plugin-cmake promoted?
[20:47] <infinity> rsalveti: Yeahp.
[20:47] <infinity> But first, explain this:
[20:47] <infinity> +Depends: libc6
[20:49] <rsalveti> thanks
[20:49] <rsalveti> yeah, not sure yet
[20:49] <rsalveti> oh, it's indeed in the dep list of debian/control
[20:50] <infinity> rsalveti: Yes, that's just plain wrong.
[20:50] <rsalveti> indeed
[20:50] <infinity> rsalveti: Looks like dh_shlibdeps needs to be called to scan the plugin .so directory.
[20:50] <infinity> Let me experiment a tad.
[20:50] <rsalveti> great, thanks
[20:51] <infinity> Erm, lolz.
[20:51] <infinity> override_dh_shlibdeps:
[20:51] <infinity>         # Qt Creator does not have shlibs, so this hack is needed to build this plugin
[20:51] <infinity>         dh_shlibdeps -XlibCMakeProjectManager.so
[20:51] <infinity> And that's why it has broken deps.
[20:51] <infinity> WHY?
[20:52]  * infinity tests without that to see what they were trying to work around.
[20:53] <slangasek> is that a package in the archive and who can I have drawn and quartered?
[20:53] <infinity> slangasek: Yes, and pick someone.
[20:53] <infinity> slangasek: It's qtcreator-plugin-cmake
[20:54] <infinity> Looks like you get to stab Mirv.
[20:54] <slangasek> man
[20:55] <slangasek> infinity: how did you assign blame?  These are all ppa copies, so launchpad shows nothing of who did what. :P
[20:55] <infinity> slangasek: changelog.
[20:55] <infinity> Anyhow, this is what happens without the hack:
[20:55] <infinity> dpkg-shlibdeps: error: no dependency information found for /usr/lib/x86_64-linux-gnu/qtcreator/libExtensionSystem.so.1 (used by debian/qtcreator-plugin-cmake/usr/lib/x86_64-linux-gnu/qtcreator/plugins/QtProject/libCMakeProjectManager.so)
[20:55] <slangasek> am I looking at the wrong package?
[20:56] <infinity> Why the solution wasn't to FIX THE PACKGAE PROVIDING THE LIBRARY, I don't know.
[20:56] <slangasek> no, I'm sure I cut'n'pasted qtcreator-plugin-cmake right
[20:56] <slangasek> and bzoltan != Mirv
[20:56] <infinity> slangasek: https://launchpad.net/ubuntu/+source/qtcreator-plugin-cmake/3.0.1-0ubuntu4 ?
[20:56] <infinity> Looks Mirvy to me.
[20:56] <slangasek> oh, because my apt-get source didn't look at -proposed, I really should fix that
[20:57] <infinity> pull-lp-source, FTW.
[20:57] <infinity> Lets you get rid of deb-src lines in sources.list too, which is a big win.
[20:58] <slangasek> but then I have to trust https instead of gpg
[20:58] <slangasek> (how's that for an off-the-cuff post-hoc rationalization?)
[20:58] <Mirv> yep, me, the new upload just added the comment, and the manual dependency as suggested at ci-eng
[20:59] <Mirv> it's the same as lp:qtcreator-plugin-ubuntu, from where the SDK Team copied the packaging
[20:59] <infinity> Mirv: Really?  Who suggested a manual dep on libc6, so I can poke them with a broadsword?
[21:00] <infinity> It seems there are attempts all over here to shoot yourselves in the foot.
[21:00] <infinity> From qtcreator:
[21:00] <infinity> override_dh_makeshlibs:
[21:00] <infinity>         # qtcreator doesn't provide any public libraries
[21:00] <infinity> So, if it's not public, why are other packages linking to it?
[21:00] <infinity> If it is public, why are you skipping shlibs?
[21:01] <infinity> This is pretty black and white.
[21:05] <infinity> Mirv: So, I'm not entirely joking.  We should hunt down the origin of this manual libc6 dep and educate the person who was giving bad advice.
[21:05] <Mirv> infinity: http://irclogs.ubuntu.com/2014/03/14/%23ubuntu-ci-eng.html#t09:09
[21:05] <infinity> Mirv: And we also need to fix this "no shlibs for libraries that other packages are obviously linking with" mess.
[21:05] <Mirv> it was probably not very well studied suggestion
[21:05] <Mirv> within all the multitaskin at that point of time
[21:06] <Mirv> infinity: upstream doesn't support 3rd party plugins, so it's a hack made by sdk team to be able to have something to build against
[21:06] <Mirv> and to not need to ship the plugins in qtcreator source
[21:06] <infinity> Mirv: If these are pure plugins, and you expect the qtcreator dep to satisfy all the deps it needs, that might be fine, but you still don't need a libc6 dep.
[21:07] <infinity> Mirv: Unless you honestly think someone's going to sort out how to run dpkg and install qtcreator without having a C library installed.
[21:07] <ScottK> There's even a lintian check for this.  http://lintian.debian.org/tags/package-depends-on-hardcoded-libc.html
[21:07] <Mirv> yeah, it was substituting a lintian error with a warning
[21:08] <Mirv> I guess it was the lintian error that made didier want to push to change something, just that the something was worse than not doing it
[21:09] <infinity> Mirv: So, my take would be that qtcreator should have a shlibs that makes anything with a plugin dep depend on qtcreator >= $upstream, and then you could get all your deps from dpkg.
[21:09] <Mirv> anyway, bzoltan + zbenjamin can look at it next week
[21:09] <Mirv> a bug would be welcome, 11pm here
[21:09] <infinity> This is quite important, as a plugin could depend on OTHER external libraries, and you're now skipping resolving those.
[21:10] <infinity> I might do better than a bug, and instead submit patches.  We'll see how much my anger fuels me.
[21:10] <Mirv> thanks
[22:59]  * infinity keeps boggling at this packaging...
[23:00] <roaksoax> infinity: howdy! did you happen to upgrade the firmware on the P8?
[23:00] <infinity> +DEB_LDFLAGS_MAINT_APPEND  = -Wl,--as-needed
[23:00] <roaksoax> err
[23:00] <roaksoax> nevermind
[23:00] <infinity> ^-- If only that were the toolchain default or something.
[23:00] <infinity> roaksoax: The firmware I was asked not to upgrade?
[23:00] <infinity> Err, also, ECHAN.
=== yofel_ is now known as yofel
=== knome_ is now known as knome