[00:12] <shadeslayer> Quintasan: haha
[02:47] <ScottK> I hope someone is going to the release team BoF tomorrow.
[03:20] <manchicken> yofel: I added the base repo now, too.
[03:20] <manchicken> I resubmitted my merge request.
[03:20] <manchicken> JontheEchidna: I don't really know what else we could do about the QAptDecorator bit, I kinda wanted something we could pull out and put somewhere else if needed, too.
[03:21] <manchicken> JontheEchidna: I've thought about maybe just adding a KApt wrapper around it, but I don't think that we really have that much that we need to do here... so I thought that simplest would be best, and simplest seemed like a class method.
[08:04] <Riddell> ScottK: I'm at release bof, what shall I say?
[08:04] <Riddell> general position is it would be ok but we have a selfish preference for 6 months cos that matches
[08:04] <Riddell> if going with three months a .3 and maybe .4 bugfix release would be nice but it's ok to exponentially increase the time between bugfix releases
[08:53] <shadeslayer> Riddell: did you bring that up yet ?
[08:54] <Riddell> shadeslayer: nope
[08:54] <shadeslayer> ok 
[09:03] <shadeslayer> yofel: Riddell for us it is mostly about getting the feature releases in ubuntu backports 
[09:04] <shadeslayer> or longer support ...
[09:05] <yofel> shadeslayer: well, if the changes are smaller, we *could* maybe take that up with the TB again. With the full backport procedure that's simply impossible, we would need some kind of macro backport exception
[09:05] <shadeslayer> true 
[09:05] <shadeslayer> can we ask for a full archive rebuild against a PPA or sth ?
[09:06] <shadeslayer> for a release that has been out 
[09:06] <Riddell> erk
[09:06] <shadeslayer> ?
[09:07] <Riddell> a full archive rebuild against a PPA: I really doubt it
[09:08] <shadeslayer> Hm 
[09:08] <Quintasan> \o
[09:08] <shadeslayer> if we can figure out that part of the infrastructure on our side, wouldnt it be easier for us ?
[09:11] <yofel> do we need a full archive rebuild?
[09:11] <Riddell> yeah what would that be for?
[09:11] <yofel> we need to *check* all reverse dependencies, and possibly fix some
[09:11] <yofel> but we don't need to generically rebuild everything (that's what symbols files were e.g. for?)
[09:14] <shadeslayer> yofel: does the check entail only checking installabillity or compiling as well ?
[09:14] <yofel> shadeslayer: both + runnability
[09:14] <yofel> e.g. that the kipi-plugins need to be rebuilt can't be figured out without actually trying to run them
[09:15] <shadeslayer> right, so maybe not a full archive rebuild, but can we make a subset of packages that we can create somehow ?
[09:15] <shadeslayer> and ask for a rebuild of those 
[09:16] <yofel> it would still be a rather large list... 
[09:17] <shadeslayer> I just think Riddell's point that it would fix more bugs than it would create is very valid 
[09:20] <debfx> are you talking about putting a whole KDE release into the official backports repo?
[09:20] <yofel> that was his plan
[09:21] <debfx> there is a technical problem about that: you can only selectively install packages from backports (except when you change the pinning)
[09:21] <yofel> background: albert asked why ubuntu can push out new firefox releases to every ubuntu release, but we can't update KDE
[09:21] <yofel> good point
[09:22] <yofel> though now I remember that the firefox packages are pretty self-contained
[09:22] <yofel> they had to change the packaging quite a bit back when they started doing those feature updates
[09:23] <debfx> firefox isn't in *-backports, it's in security (and thus also updates)
[09:24] <shadeslayer> right 
[09:25] <debfx> yeah they had to change a few things, like killing all extension packages and everything that depends on xulrunner
[09:26] <shadeslayer> heh ...
[09:27] <shadeslayer> so basically I want to make sure Kubuntu uses supported KDE releases, something that was not viable during the 18 month cycle, but seems fairly viable now 
[09:30] <Riddell> 4 month release cycle seems to be popular
[09:32] <shadeslayer> still doesn't solve our support issue ?
[09:32] <yofel> would mean we would skip releases irregularily as well
[09:32] <yofel> :/
[10:03] <Riddell> Quintasan: <yofel> can you finish 4.11, there are  like 2 packages left with missing files
[11:53] <BluesKaj_> Hiyas all
[13:19] <ScottK> Firefox is an exception because of the vast array of security issues in the code and the upstream release model, it's impossible to support otherwise (Chromium too).
[13:19] <ScottK> We could probably sell QtWebKt upgrades similarly, but that's about it.
[13:20] <ScottK> Riddell: How'd the BoF go?
[13:58] <lordievader> Good afternoon.
[15:00] <apachelogger> agateau: I'll probably freeze about-distro tomorrow in case you want anything changed still
[15:25]  * apachelogger sighs at bzr
[15:26] <apachelogger> yofel: plz note that runtime had an intermediate change
[15:28] <apachelogger> JontheEchidna: ping
[15:39] <soee> hows the work on RC1 going?
[19:00] <ScottK> Can someone else test 4.10.5 and put their results in the bug?  It's sufficiently aged tomorrow, but I'm a little reluctant to release it just based on my testing.
[22:30] <yofel> apachelogger: oh, so I still need like half of the patch?
[22:37] <yofel> I just made kdelibs 4.10.95 build the udisks2 backend instead of the udisks one as an experiment (The Limux intend to use 4.11 on 12.04 with udisks2. Not sure how sane that is but lets try it out on 13.10 at least)
[22:37] <yofel> *limux folks
[22:38] <yofel> I'll be at the solid sprint tomorrow to get more information on that
[22:38]  * yofel is off to bed
[23:04] <Riddell> http://blogs.kde.org/2013/07/17/qtwebkit-232-and-qtwebkit-qt-51
[23:04] <Riddell> !newversion qtwebkit-source 2.3.2
[23:04] <Riddell> kc8qvp_: newversion qtwebkit-source 2.3.2
[23:04] <Riddell> kubotu: newversion qtwebkit-source 2.3.2
[23:05] <Riddell> hmm
[23:05] <kubotu> https://bugs.launchpad.net/bugs/1202425
[23:09] <kc8qvp_> Riddell: I am not only a bot.
[23:25] <Riddell> http://blogs.kde.org/2013/07/18/akademy-2013-day-4-photos