[00:04] <ahoneycutt> valorie: our session is Wed June 13 at 1700 UTC
[00:11] <ahoneycutt> do we have all three domains for docs.kubuntu?
[00:11] <ahoneycutt> .com, .org, .co.uk
[00:12] <apachelogger> in theory we could anyway
[00:12] <apachelogger> ovidiu-florin, jose: where are we on website business btw?
[00:13] <jose> apachelogger: ask ovidiu-florin!
[00:13] <ovidiu-florin> we're still having issues with the child theme.
[00:14] <ovidiu-florin> We have some suggestions from someone on how to implement that, but I haven't had the time to try them out
[00:15] <ovidiu-florin> also, someone promissed to make an sketch for the Team page
[00:15] <ovidiu-florin> but no feedback since
[00:15] <ovidiu-florin> I don't remember his name
[00:15] <apachelogger> sgclark: status page adjusted for next http://qa.kubuntu.co.uk/kf5-status/build_status_4.100.0_trusty.html 
[00:16] <apachelogger> ovidiu-florin: check logs and poke? :)
[00:16] <sgclark> apachelogger: ok thanks, power went out :(
[00:16] <ovidiu-florin> will do, in the morning
[00:16] <ovidiu-florin> in ~9 to 10 hours
[00:17] <ovidiu-florin> can someone poke me around then to remind me please?
[00:17] <apachelogger> kubotu: whats the plugin for that?
[00:18] <apachelogger> kubotu: remind ovidiu-florin to poke people in 10 hours
[00:18] <kubotu> apachelogger, you don't have 'remind::other::about' permissions here
[00:18] <apachelogger> kubotu: you are being very rude today
[00:19] <ovidiu-florin> :)
[00:19] <ovidiu-florin> I'll just look over the TODO tomorrow and remember to do that
[00:19] <apachelogger> kubotu: whoami
[00:19] <kubotu> you are my boss
[00:19] <apachelogger> that's right
[00:19] <apachelogger> kubotu: remind ovidiu-florin to poke people in 10 hours
[00:19] <kubotu> okay
[00:19] <apachelogger> thx sweetie :*
[00:20] <ovidiu-florin> nice
[00:20] <ahoneycutt> lol
[00:21] <ahoneycutt> kubotu: whoami
[00:21] <kubotu> you are *ahoneycutt69896164926340
[00:21] <ovidiu-florin> kubotu: whoami
[00:21] <kubotu> you are *ovidiu_florin69896164850320
[00:21] <apachelogger> clearly you are nobodys :P
[00:21] <ovidiu-florin> what's with the numbers?
[00:21] <apachelogger> random number
[00:22] <apachelogger> supposed to make the uid unique I guess ^^
[00:22] <apachelogger> since they are autogenerated
[00:23] <apachelogger> sgclark: I am going to rename the last branches with -kf5 suffix unless you still need them
[00:24] <apachelogger> kwallet/kactivitites/kdnssd
[00:24]  * apachelogger reports out of coffee and runs circles
[00:24] <sgclark> I am done with bzr if thats what you mean
[00:25] <apachelogger> renamed
[00:26]  * sgclark impatiently waits for all these copied packages to build
[00:27] <apachelogger> shall I trigger neon5 retries to delay things a bit? :P
[00:27]  * sgclark cries out nooooo
[00:27] <apachelogger> but it's also terribly red :'<
[00:28] <apachelogger> oh right
[00:28]  * apachelogger writes another mail
[00:44] <apachelogger> pft santa_ is blocking our builds
[00:44]  * ScottK considers starting to merge Qt5 5.3 from Debian. 
[00:44] <apachelogger> please do
[00:44]  * apachelogger wants plasma next with wayland by the end of the week :O
[00:45] <ScottK> Just got to my hotel. Need some dinner first. 
[00:46] <sgclark> apachelogger: wait what?!? how. I need to finish at some point ... 14 hours ugh
[00:46] <apachelogger> https://launchpad.net/~panfaust/+archive/kubuntu-kf5-experiments
[00:47] <apachelogger> assuming they were uploaded before the copy they will get processed first as they supposedly have the same upload score
[00:47]  * sgclark grumbles
[00:48] <santa_> apachelogger: I can remove the packages and do my experiments other day if that helps
[00:48] <sgclark> I still have to apply all my changes files..
[00:48] <apachelogger> already queued now, I don't mind much :P
[00:48] <sgclark> yes please. ^^
[00:49] <apachelogger> santa_: why do you need to build the entire packageset anyway?
[00:49] <apachelogger> just make your ppa dep on next and reuse the existing packages to build from
[00:50] <apachelogger> yofel: did you ever reach any sort of conclusion on continuous builds btw?
[00:50] <santa_> apachelogger: I'm just getting familiar with your ppa's stuff
[00:50] <santa_> never used it before
[00:50] <santa_> gonna remove everything then
[00:52] <apachelogger> santa_: http://i.imgur.com/8BJzoXE.png
[00:53] <apachelogger> if you add another ppa as a dep it will basically add that ppa to the sources.list of the builders
[00:53] <apachelogger> so it will simply resuse the existing packages from kubuntu next
[00:54] <santa_> yep, the thing is I started that ppa to fix the various ftbfs'es in the previous version, so I needed to rebuild everything
[00:55] <apachelogger> ah, please coordinate ftbfs fixes 
[00:55] <santa_> but now I guess I could re-use your stuff, yes
[00:55] <apachelogger> otherwise work gets duplicated because I think sgclark is also working on that
[00:55] <santa_> it's everything merged now
[00:55]  * sgclark is
[00:56] <santa_> I don't have any pending work right now
[01:00] <apachelogger> 4.100 will have compat issues with the released workspace
[01:00]  * apachelogger rolls eyes
[01:01] <apachelogger> Riddell: btw, did you understand how tarme works yet?
[01:10] <ScottK> apachelogger: Of course not.  It'll be perfectly compatible.  In the brave new world of KF5/Plasma Next anyone can release anything whenever they feel like it and it'll be wonderful.  No matter what.  No need for coordination.
[01:10] <ScottK> I'm sure of it because both Aaron and KDE promo said so.
[01:12] <apachelogger> well, frameworks api isn't entirely frozen yet ^^
[01:13]  * sgclark giggles
[01:15] <apachelogger> oh
[01:15] <apachelogger> ScottK: fear not, next month binary interface freeze kicks in
[01:15] <apachelogger> if shit breaks after that we get to throw dirt ^^
[01:16] <ScottK> And then throw dirt again a month later.
[01:16] <ScottK> Oh, wait.  I forgot.
[01:17] <ScottK> Kevin Ottens promises no regressions ever in KF5 so we can just blindly update whenever.
[01:17] <ScottK> What could possibly go wrong.
[01:28]  * apachelogger wonders when devs will remember that qreal != float && qreal != double
[01:30] <ScottK> Never since in Qt5 they aren't required to care.
[01:32] <apachelogger> I see a ftbfs :P
[01:33] <apachelogger> not on kubuntu though
[02:15]  * apachelogger squints
[02:23] <apachelogger> well, it's official lunchpad hates me
[02:24] <apachelogger> oh, actually the buildpackage thing hates me
[02:30] <apachelogger> Riddell: data packages for l10n doesn't compute for me
[02:30] <apachelogger> what's the point of that?
[02:32] <apachelogger> oh multiarch
[02:32] <apachelogger> many a kittens have to die because of the frameworks packaging
[02:33] <apachelogger> simplest of frameworks would have an exciting amount of 4 packages in control
[02:57] <apachelogger> and why does the lib binary:version dep on the data
[03:01] <apachelogger> lconvert: could not find a Qt installation of ''
[03:01] <apachelogger> ...
[03:33] <apachelogger> neon is eating the builders
[03:33] <apachelogger> much rude.
[03:39] <apachelogger> Riddell, yofel, ScottK, shadeslayer: how about we drop the debian subdirs in bzr branches?
[03:39] <ScottK> apachelogger: Please don't.
[03:39] <apachelogger> ScottK: why?
[03:39] <ScottK> It would seriously mess up my workflow.
[03:40] <apachelogger> how so?
[03:40] <ScottK> The .bzr dir is only in the top level dir.
[03:40] <ScottK> so with the debian directory under the top level, I can diff the debian dir in the package and the bzr very nicely.
[03:40] <ScottK> If there was no debian dir, the .bzr ends up in my diff.
[03:41] <ScottK> Really annoying.
[03:41] <apachelogger> ScottK: -x .bzr?
[03:41] <ScottK> What problem are you trying to solve by changing it?
[03:42] <apachelogger> having to type more than I can be bothered to
[03:42] <ScottK> Also then when I diff and patch in and out of the bzr branch (and I do that) then the -p levels get screwed up.
[03:42] <ScottK> d <tab> isn't much
[03:42] <apachelogger> too much considering there's some 80 branches just for frameworks and workspace right now
[03:43] <apachelogger> but, really the issue is probably more the fact that the packages are too splity
[03:44] <apachelogger> bunch of frameworks now got localization so one now gets to hop into every other framework branch, copy and paste the same stanza, adjust the description create the very same install file and commit that
[03:44] <ScottK> Sounds like it's dieing to be scripted.
[03:44] <apachelogger> it is exactly the kind of thing I was talking about yesterday WRT having to batch edit stuff
[05:41] <yofel> apachelogger: continuous builds?
[05:42] <yofel> and please don't drop debian/
[05:42] <yofel> it would be rather inconvenient for things like wrap-and-sort, dch, etc...
[06:12] <yofel> Riddell FYI about our wrap-and-sort breakage:
[06:12] <yofel> "The merged package definitions were separated by one line containing a
[06:12] <yofel> space (line 20 of your control file), but they should be separated by
[06:12] <yofel> one empty line. That's the reason why the package definitions were
[06:12] <yofel> joined."
[06:12] <yofel> from debian 750247
[06:17] <soee> good morning
[07:33] <yofel> apachelogger: what was your plan wrt kubuntu-packaging-next and kbzr?
[09:34] <Riddell> yofel: hmm, quite likely
[09:41] <yofel> Riddell: is there a release schedule for kf5 anywhere? I can find a schedule for plasma, but not for kf5
[10:03] <Riddell> yofel: http://community.kde.org/Frameworks/Epics is the best we've got
[10:03] <Riddell> although it tends to be whenever dfaure is free
[10:17] <BluesKaj> 'Morning folks
[10:25] <ovidiu-florin> kubotu: where's my reminder?
[10:25] <ovidiu-florin> it's been 10 hours
[10:26] <yofel> hm
[10:26] <yofel> kubotu: whoami
[10:26] <kubotu> you are yofel
[10:31] <Riddell> apachelogger: I'm not too sure on the point of moving those kf5 branches, we'll still need to rename the source package for ones with overlapping names
[10:34] <ovidiu-florin> apachelogger: kubotu forgot about my reminder
[10:35] <yofel> weird
[10:35] <yofel> kubotu: remind ovidiu-florin to poke people in 10s
[10:35] <kubotu> yofel, you don't have 'remind::other::about' permissions here
[10:36] <yofel> aha
[10:36] <yofel> remind me about foo in 10s
[10:36] <yofel> kubotu: remind me about foo in 10s
[10:36] <kubotu> okay
[10:36] <yofel> PM'd me, curious
[10:37] <ovidiu-florin> so the reminder is PM?
[10:37] <ovidiu-florin> did not expect that
[10:48] <yofel> Riddell, apachelogger: if we go with a seperate image for plamsa next for now, do they really have to be co-installable?
[10:50] <yofel> I don't particulary see the point in supporting two workspaces in parallel
[10:51] <yofel> if anything, I see version clashes regarding the epoch
[10:52] <Riddell> yofel: they're not coinstallable
[10:53] <yofel> so why rename?
[10:53] <Riddell> yofel: kdelibs and kde-runtime equivalents should be co-installable
[10:53] <Riddell> kde-workspace doesn't matter
[10:53] <Riddell> but there's some bits of kdelibs which have the same name in kf5 and plasma
[10:54] <Riddell> kdnssd, kwallet, kactivities
[10:54] <Riddell> attica
[10:55] <yofel> :/
[10:55] <yofel> how about renaming everything kf5-<module> so it's at least consistent? Or would that be too messy again
[10:56] <Riddell> seems messy an unnecessary to do all, I've been renaming the ones that clash <module>-kf5
[10:56] <yofel> which will need script special casing :/
[10:56] <Riddell> right, such is life
[10:57] <Riddell> in plasma baloo kfilemetadata and milou will need renamed
[10:57] <Riddell> which I can do being upstream
[10:57] <Riddell> suggestions welcome for what to call them
[11:24] <yofel> Riddell: I think you're uploading to the wrong PPA?
[11:24] <Riddell> yofel: so I've just seen
[11:24] <yofel> ^^
[11:36] <ovidiu-florin> yofel: I've replied to a volunteer that offered to help with a few things with the new kubuntu website. I've CC'd the kubuntu-devel mail list, so you guys can see the thread. Aparently it needs aproval because the message is to big. :|
[11:37] <yofel> Riddell: ^
[11:38] <apachelogger> Riddell, yofel: source name has nothing to do with the branch, it never has
[11:38] <apachelogger> as for the renaming
[11:38] <apachelogger> I'll argue that the kde4 sources should be renamed
[11:39] <yofel> you would still have to special case epochs then, or add an epoch to everything
[11:40] <apachelogger> yofel: why? all frameworks will be version 5.x and soversion 5
[11:41] <yofel> baloo 4:4.13.0 >> baloo 5.0
[11:41] <apachelogger> yofel: so?
[11:42] <apachelogger> everything gets epoch 5? :P
[11:42] <yofel> well, 4 would suffice, current is 0
[11:42] <apachelogger> that's confusing, should be 5
[11:42] <yofel> why, the version is 5, epoch has nothing to do with that
[11:42] <apachelogger> you need the epoch in the apps space anyway, since they do not change name and they do not need to be coinstallable
[11:44] <apachelogger> yofel: yes, because apps need it
[11:44] <yofel> how? where? why?
[11:45] <apachelogger> Version: 4:4.13.0-0ubuntu1
[11:45] <apachelogger> !info gwenview
[11:45] <yofel> ...?
[11:46] <apachelogger> yofel: it has an epoch
[11:46] <yofel> what's wrong with 4:5.0
[11:46] <apachelogger> yofel: it's confusing
[11:46] <yofel> well, it's debian...
[11:46] <Riddell> yofel: mind and keep https://notes.kde.org/p/kubuntu-ninjas-frameworks updated when you're working on a KF5 package
[11:46] <apachelogger> yofel: 4:5.1.3+dfsg+really5.1.2
[11:47] <yofel> Riddell: yeah sorry, forgot to do that for the first 2
[11:47] <yofel> apachelogger: looks fine to me ^^
[12:07] <Riddell> yofel: instead of just writing "done" I've been writing ~ppa2 up so we know that if ~ppa2 fails then it needs to be done again
[12:07] <yofel> ok
[12:18] <Riddell> hola sgclark 
[12:23] <sgclark> Riddell: morning :)
[12:43] <ScottK> Coordinate the epoch thing with Debian. If we get to a higher epoch than them it really sucks. 
[12:47] <shadeslayer> hi
[13:05] <yofel> moin shadeslayer ^^
[13:05] <shadeslayer> hello
[13:05] <shadeslayer> how's it going
[13:06] <shadeslayer> apachelogger: I hear you're giving a talk about builder @ UOS :P
[13:08] <shadeslayer> ScottK: do we want a Qt5 sync up session at UOS?
[13:09] <Riddell> builder?
[13:09] <apachelogger> shadeslayer: that's news
[13:09] <shadeslayer> ^_^
[13:10] <apachelogger> yofel: whatever happened to the maintainenance on aliaoth notion
[13:15] <yofel> nothing, at least not from my side. 
[13:15] <yofel> Let me dump our last proposal into the channel and see what happens
[13:15] <yofel> might as well discuss the epoch too
[13:18] <ScottK> shadeslayer: we want 5.3 to go in asap. 
[13:18] <ScottK> If that needs a session, fine. 
[13:19] <shadeslayer> I'll ask around I guess
[13:19] <ScottK> My trying to get someone from Canonical to discuss it via email isn't going very well. 
[13:19] <shadeslayer> ok
[13:24] <ScottK> Frankly though the whole KDE upstream pov that IMO amounts to screw the distros they're on there own causes me to be even more demotivated about being involved in KDE packaging.
[13:25] <shadeslayer> I still have a different view tbh ....
[13:26] <yofel> shadeslayer: take that up with the techboard, until then I'm with scott
[13:27] <yofel> apachelogger: ok, so sune is against renaming sources
[13:27] <yofel> (old ones I mean)
[13:27] <yofel> so the epoch is moot I believe as we can keep 0 for now
[13:29] <apachelogger> yofel: not epoching makes scripting more work because you need to parse the epoch out of the changelog before doing things
[13:29] <apachelogger> unless there is a dch argument that automatically reuses the epoch
[13:33] <ScottK> apachelogger: dch -i does what I think you're suggesting. 
[13:34] <apachelogger> ScottK: no, I mean like dch -v 5.1.0
[13:34] <ScottK> Oh.
[13:34] <yofel> well, currently *nothing* in kf5 has an epoch
[13:34] <apachelogger> yofel: applications will
[13:34] <ScottK> Yeah you need to include it. 
[13:35] <apachelogger> gwenview has epoch 4
[13:35] <yofel> that's not kf5, that's plasma and applications
[13:35] <apachelogger> unless we rename all applications we will have an epoch
[13:35] <yofel> and you can just keep the 4 there
[13:35] <apachelogger> yofel: so you want two different scripts?
[13:35] <yofel> scripts no, different package lists yes
[13:35] <apachelogger> yofel: my point is that to keep the epoch in one part but not the other you then have to script epoch parsing in
[13:36] <apachelogger> something you could entirely avoid if you say everything core kde (whatever that will be in the future) has epoch X
[13:36] <ScottK> FWIW, if someone goes to the TB to ask for an MRE for KF5, I'll probably be arguing against it.
[13:36] <yofel> what's so hard about string.split(':') ?
[13:37] <apachelogger> yofel: you first need to get the version
[13:38] <apachelogger> so we are talking something like parsechangelog | grep Version | sed
[13:38] <apachelogger> which is entirely avoidable by simply not insisting on having no epoch because there is zero benefit to not having an epoch
[13:39] <apachelogger> there however is a benefit to retaining the epoch and that benefit is to not have to worry about the fact that some automated bits have an epoch and others don't
[13:39] <yofel> IMO, I would rather special case stuff for now until we have worked out with debian what they want to do
[13:39] <yofel> if we can put our stuff on alioth, and run our scripts over that, and they're fine with it, I'm ok
[13:40] <apachelogger> well yeah, the epochs should be aligned
[13:40] <yofel> I'm not disagreeing that using one epoch on everything is easier, but they have to be in sync then
[13:40] <apachelogger> I am arguing that the epochs should also be aligned across all bits we need to mass automate
[13:43] <shadeslayer> apachelogger: yofel https://bitbucket.org/unit193/trellobot
[13:44] <apachelogger> bitbucket still exists?
[13:44] <shadeslayer> yes, I use it
[13:44] <shadeslayer> for sekrit repos
[13:44] <yofel> fun
[13:45] <apachelogger> sekrit repos he said
[13:45] <apachelogger> don't be lazy, write an rbot plugin
[13:45] <apachelogger> then you can trello off of kubotu instead of having to run a dedicated bot
[13:46] <shadeslayer> hmm
[13:46] <apachelogger> I personally fail to see the point fwiw
[13:52]  * yofel would rather have commit notifications back :S
[13:53] <apachelogger> lol
[13:54] <apachelogger> I just thought the same and am currently looking into that :P
[13:54] <apachelogger> not quite sure how to do that though
[13:54] <yofel> you could probably do it by having the bot subscribed to the mail notifications from launchpad
[13:55] <apachelogger> that's all sorts of complicated
[13:55] <apachelogger> rss seems more useful
[13:55] <apachelogger> but automatically subscribing to things is a bit rubbish theree
[13:56] <apachelogger> that's also why the bug notifications are not active on everything
[13:56] <yofel> well, if launchpad had rss, sure :S
[13:56] <apachelogger> yofel: it does
[13:56] <apachelogger> well, loggerhead has
[13:56] <apachelogger> oh, actually lunchpad has as well
[13:56] <apachelogger> http://feeds.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/plasma-workspace/branch.atom
[13:56] <yofel> *blink* I did not know about that
[13:57] <apachelogger> it's all very well hidden
[13:57] <apachelogger> ohohoh
[13:58] <apachelogger> I found a team level feed
[13:58] <apachelogger> http://feeds.launchpad.net/~kubuntu-packagers/branches.atom
[13:58] <apachelogger> msg kubotu
[13:58] <apachelogger> eh
[13:58] <apachelogger> ^^
[13:58] <apachelogger> msg kubotu
[14:00] <yofel> @_@
[14:03] <apachelogger> the feed content is a bit pointless
[14:03] <apachelogger> kubotu: rss show branches 1
[14:03] <kubotu> lemme fetch it...
[14:03] <kubotu> Channel : Branches for Kubuntu Packagers
[14:03] <kubotu> 2014/06/03 13:11 :: lp:~kubuntu-packagers/kubuntu-packaging-next/kdbusaddons @ https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/kdbusaddons (by Kubuntu Packagers)
[14:04] <yofel> that's missing the interesting part -.-
[14:04] <apachelogger> oh, maybe by project would work better
[14:05] <apachelogger> kubotu: rss show branches 1
[14:05] <kubotu> lemme fetch it...
[14:05] <kubotu> Channel : Latest Revisions for kubuntu-packaging
[14:05] <kubotu> 2014/06/02 19:58 :: [khtml] r28 Fix remain wrap-andsort breaks... (by Scarlett Clark)
[14:05] <apachelogger> that one doesn't have links ^^
[14:06] <yofel> link might be a bit long IMO
[14:06] <yofel> we know where it is anyway (as long as the project is shown)
[14:06] <apachelogger> not if one takes next into the picture
[14:06] <apachelogger> well, when there's branch with equal name in both projects anyway
[14:07] <yofel> hence my point about the project
[14:08] <yofel> FWIW, that's already more useful than the bug notifications...
[14:08] <apachelogger> what's wrong with the bug notification :O
[14:09] <yofel> uhm, that it always shows the same message each time...?
[14:09] <apachelogger> so?
[14:09] <apachelogger> you know the bug has changed
[14:10] <yofel> I can let kmail notify me about that...
[14:10] <yofel> ok, nevermind
[14:10] <apachelogger> just like with branches :P
[14:10] <yofel> I'm just used to having *content* in such messages
[14:10] <apachelogger> by that standard irc notifications make no sense altogether because you could simply sub by mail :P
[14:10] <apachelogger> yofel: well, tell launchpad that
[14:10] <apachelogger> can't do much about the title the feeds give
[14:11] <yofel> yeah, I got that the second after I finished writing -.-
[14:11] <apachelogger> ^^
[14:11] <apachelogger> I think I found a way to track all bug reports btw
[14:11] <apachelogger> it's much more straight forward once one realizes that teams have feeds ^^
[14:12] <shadeslayer> hidden features, hidden features everywhere
[14:13] <yofel> apachelogger: I'm not arguing about launchpad, I'm just arguing that the title isn't really sufficient to tell me anything :/
[14:14] <apachelogger> mh
[14:14] <apachelogger> it appears one can write custom filters for the feed plugin
[14:14] <apachelogger> not that I know or understand how that would work
[14:15] <apachelogger> eean or markey would apparently since they hold authorship :P
[14:15] <yofel> I'm not really sure though if the posts warrant a like 7 line bot message in here though
[14:15] <yofel> even if I like the long kde commit notifications
[14:16] <apachelogger> looking I say, looking
[14:17] <apachelogger> well
[14:17] <apachelogger> yofel: as far as the atom is concerned I don't think filtering is an option either
[14:17] <apachelogger> the actually useful data is html content
[14:18] <apachelogger> extracting meaningful things from that seems nigh impossible
[14:18] <shadeslayer> oh oh oh
[14:18] <shadeslayer> ScottK: yofel apachelogger reckon I should schedule a session for Frameworks releases in ubuntu?
[14:19] <yofel> urgh, yeah, that content looks awful
[14:20] <yofel> shadeslayer: to discuss it with whom?
[14:20] <shadeslayer> TB
[14:21] <yofel> well, go ahead if you want, you're not going to have me on your side unless I've seen a couple releases without any breakage
[14:21] <apachelogger> I'll say that unless there have been actual releases a discussion would involve 99% handwaving
[14:21] <shadeslayer> I see
[14:22] <shadeslayer> so whats the plan for 14.10 then
[14:22] <apachelogger> land in ppa
[14:22] <yofel> ^
[14:22] <yofel> we could put it in the archive, but it would be essentially unsupported
[14:23] <yofel> depends on demand really I think
[14:23] <apachelogger> which is not in the interest of anyone as that prevents upstream to quickly iterate initial bugs out of the way
[14:23] <shadeslayer> ^^
[14:24] <apachelogger> one could make an argument for landing it all the same as even with intial bugs it makes it easier for devs to transition to frameworks
[14:24] <apachelogger> but truth be told right now I actually feel that even then they'd be better served with using the PPA to get the latest and greatest asap
[14:24] <shadeslayer> I think landing is pointless unless we can keep updating monthly
[14:25] <yofel> adding a PPA isn't that hard, IMO it only makes sense if someone comes up and says that package X that he wants in the archive uses kf5 module Y, then it might make sense
[14:26] <shadeslayer> yeah, basically, not having KF5 in the archive blocks KF5 apps in the archive for 9 months
[14:27] <yofel> shadeslayer: we can put it in as soon as we put something in the archive that needs it, currently that's nothing, so no point in having it there
[14:28] <yofel> and it's not like we can put applications in the archive post-release
[14:29] <shadeslayer> but then if random-app requires a tier 3 framework, what then
[14:34] <yofel> shadeslayer: as I said, then we can talk about it, but if random app isn't ready by 14.10 FF, I'm against including it
[14:38] <yofel> kubotu: newversion calligra 2.8.3
[14:38] <kubotu> https://bugs.launchpad.net/bugs/1326002
[14:40] <shadeslayer> ooh
[14:40] <shadeslayer> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[14:40] <shadeslayer> has autopkgtest output now
[14:40] <shadeslayer> sweet
[14:41] <yofel> wow, how colorful ^^
[14:41] <shadeslayer> :D
[14:41] <yofel> autopkgtest for kde4libs 4:4.13.1-0ubuntu1: Always failed
[14:41] <yofel> greaaaaat
[14:42] <yofel> shadeslayer: do you think it's sensible to add autopackagetest to our kf5 stuff? So far dh_test is being run, but not autopkgtest
[14:43] <shadeslayer> yofel: that kdelibs part failing is because of dh-acc not depending on debhelper
[14:43] <yofel> ah k
[14:43] <shadeslayer> workaround would be to add it manually to our test
[14:44] <shadeslayer> as for autopkgtest for KF5, yeah, I think so, plus we can add dh-acc checks to make sure ABI doesn't break
[14:44] <yofel> right, still need to read up on that
[14:46] <ScottK> shadeslayer: I think we already decided about frameworks in our session.  No need for something at UOS.
[14:46] <shadeslayer> ScottK: roger
[14:47] <shadeslayer> whole bunch of stuff is blocked on non installable maxima
[14:47] <shadeslayer> hm
[14:52] <sgclark> ok so I dput ktextwidgets v3 to ppa:kubuntu-ppa/next but seems to have vanished into space, any ideas?
[14:54] <yofel> shouldn't happen unless you didn't sign it
[14:54] <sgclark> Successfully uploaded packages.
[14:54] <yofel> to the right ppa?
[14:54] <apachelogger> shadeslayer: there's not much leeway when we land frameworks, we propose an update exception to TB, they either approve or not and then we have to deal with that
[14:56] <apachelogger> the only real alternative is to then seek approval for allowing a ppa to be enabled by default as to deploy updates outside the scope of the archive (which really amounts to the same problem domain anyway) or worst case have a checkbox somewhere to enable updates for frameworks
[14:56] <apachelogger> enable updates for frameworks would then add the PPA
[14:56] <apachelogger> so short of getting update approval it's either ppa by default or opt-in ppa
[14:56] <sgclark> yofel: used wrong key, thank you
[14:56] <ScottK> That sort of thing has been turned down before.
[14:57] <ScottK> apachelogger: I say we update to feature freeze and then start cherry picking.
[14:58] <apachelogger> well regardless of the outcome of a TB decision we don't have that many options really
[14:58] <shadeslayer> ScottK: except that cherry picking might result in confusing backtraces for upstream
[14:58] <apachelogger> ScottK: that can only be done if the big distros band together and put up a maintenance system
[14:59] <apachelogger> i.e. that cherrypicking would have to be implemented upstream with more than one party involved otherwise that calls for screwuppery
[14:59] <apachelogger> also that potentially is a lot of work with some 60 potential frameworks that need watching
[14:59] <ScottK> shadeslayer: Upstream bought that confusion when they declined to support their releases.  Not my problem.
[15:00] <ScottK> apachelogger: Agreed.  If only upstream cared about maintenance.
[15:00] <yofel> shadeslayer: Ben made that point, and was completely ignored, so I guess they're fine with it
[15:00] <apachelogger> ScottK: that's where our perception differs I think we can be upstream just as much as upstream is upstream, in fact I think we should be upstream ;)
[15:00] <ScottK> Obviously cherrypicking will be manpower limited, so it'd only be for severe issues.
[15:01] <apachelogger> it's a lot like the dead upstream discussion we had a while back, distros patch k3b, but no one actually bothers enough to pick up maintenance (whatever that may mean) and roll a tarball of new fixes
[15:03] <ScottK> AIUI upstream objected to stable branches even existing.
[15:05] <apachelogger> haven't seen that
[15:06] <kubotu> feed branches had 4 updates, showing the latest 3
[15:06] <kubotu> ::branches:: [kaccessible] r106 Release... (by Rohan Garg)
[15:06] <kubotu> ::branches:: [kaccessible] r107 Fix control file to have proper fields... (by Rohan Garg)
[15:06] <kubotu> ::branches:: [kaccessible] r108 Release... (by Rohan Garg)
[15:07] <yofel> IMHO, 'upstream' in this case should really be someone that knows the code. If $distro_dev becomes stable branch maintainer upstream without knowing what he's doing I'm not sure I'll happily use a point release coming from there
[15:07]  * shadeslayer has a headache
[15:07] <yofel> I've seen plenty of breakage where someone from $distro1 upstreamed a patch which caused breakage in $distro2
[15:08] <yofel> so a cherry-pick that's safe in $distro1 doesn't have to be safe in $distro2
[15:09] <yofel> (not that upstream is in a much different position, just less likely to mess up)
[15:09] <apachelogger> yofel: that's why it needs to be a joint effort
[15:10] <shadeslayer> oohh
[15:10] <shadeslayer> debian/libkactivities-models1.abi.tar.gz.amd64
[15:11] <yofel> wat
[15:11] <shadeslayer> yofel: that's the base abi file for dh-acc to work
[15:11] <shadeslayer> to compare things against
[15:11] <yofel> *blink*
[15:11] <yofel> and where's that o.O?
[15:11] <shadeslayer> debian git
[15:12] <apachelogger> eh
[15:12] <kubotu> ::branches-next:: [ktextwidgets] r26 Bump depends versions (by Scarlett Clark)
[15:12] <kubotu> ::branches-next:: [ktextwidgets] r27 Fix control file... (by Scarlett Clark)
[15:12] <yofel> wait, are we now adding binary files to the source o.O?
[15:13] <shadeslayer> yofel: in the debian packaging, supposedly, yeah 
[15:13] <yofel> I'm sorry, but that's crap -.-
[15:13] <apachelogger> git likes binary files a lot :P
[15:15] <sgclark> Riddell: plasma-workspace in bzr needs review when you have time
[15:17] <yofel> shadeslayer: that looks like a gzipped tar with a single json file in it to me...
[15:20] <shadeslayer> mhm
[15:22] <yofel> and ofc. .abi.tar.gz is hardcoded in dh_acc
[15:22] <yofel> supreme fun
[15:47] <Riddell> sgclark: I'll take a look if I get a chance but I think it's worth just going back to KF5 for now as that's got the new release and plasma will do later this week
[15:49] <sgclark> Riddell: sorry what? upstream is going back to kf5? bzr revert should work then right?
[15:53] <yofel> Riddell: why is libkf5pty-data arch:any?
[16:06] <kubotu> ::branches:: [kactivities] r121 * Merge with debian, no remaining changes... (by Rohan Garg)
[16:06] <kubotu> ::branches:: [calligra] r98 * New upstream release (LP: #1326002)... (by Philip Muškovac)
[16:08] <sgclark> Riddell: I reverted to pre- name change so don't worry about reviewing it. I have name change backed up if that is not what you meant.
[16:11] <shadeslayer> Actual votes cast thus far: 16
[16:11] <shadeslayer> ~40% voting done
[16:12] <kubotu> ::branches-next:: [plasma-workspace] r6 Rename - drop kf5... (by Scarlett Clark)
[16:12] <kubotu> ::branches-next:: [knotifications] r35 Fix description-synopsis-starts-with-article for the binary ... (by Philip Muškovac)
[16:18] <Riddell> yofel: sounds like a mistake
[16:20] <Riddell> sgclark: just looked, that rename to drop the kf5 looks good
[16:20] <Riddell> sgclark: where did you get the idea to use libpkgs_addsubst_allLibraries ?
[16:24] <sgclark> saw all those merges with it
[16:24] <sgclark> Riddell: so go back to dropping the kf5?
[16:26] <sgclark> Riddell: also the merges I have done , the debian version all have allLibraries
[16:30] <ScottK> The problem with libpkgs_addsubst_allLibraries is that if you have one lib installed once you install the -dbg it pulls all the other libs too.
[16:31] <ScottK> Installing a -dbg shouldn't pull in other libs.
[16:36] <Riddell> sgclark: ah so must be a new feature debian has got into using
[16:37] <santa_> Riddell: the allLibraries is something widely used in the debian packaging for packages which have a lot of libraries .e.g. kdepimlibs
[16:37] <Riddell> ScottK: I'm also not convinced it's any easier to maintain or clearer to read
[16:37] <santa_> I mean imagine the control file of kdepimlibs without using that variable
[16:37] <santa_> perhaps the frameworks libs are too small to use this feature
[16:38] <santa_> in any case if we don't use it for frameworks it's not a big loss imo
[16:39] <sgclark> workspace is rather big compared to the rest of kf5
[16:39] <ScottK> KF5 ~= kdelibs, so no surprise.
[16:39] <sgclark> doesn't matter to me :) I just recall we are trying to get debian to adopt our kf5
[16:40] <santa_> well sometimes they use ${allLibraries} sometimes they don't
[16:40] <santa_> the main point of using that in my opinion is
[16:40] <santa_> 1. not forgetting to add libs when a new one appears
[16:41] <santa_> 2. not having to change everything when a library breaks abi and the packages have to be renamed
[16:41] <santa_> about 2 it would make sense to use it in okteta, for instance
[16:42] <santa_> however debian doesn't, but it should
[16:42] <ScottK> My objection is only for -dbg depends.  Installing -dbg shouldn't pull in more libs.
[16:42] <ScottK> For other things, it may be fine.
[16:42] <santa_> that's a different story
[16:42] <santa_> we could downgrade the -dbg depends to suggests
[16:43] <santa_> in any case that's a different issue, which exists with our without ${allLibraries}
[16:44] <santa_> I think you guys have a point when you say it shouldn't pull everything
[16:45] <lordievader> Good evening
[16:46] <santa_> evening
[16:46] <lordievader> Hey santa_, how are you?
[16:47] <santa_> good, fine thanks
[16:51] <santa_> sgclark: ktexteditor has a dupe changelog entry
[16:55] <sgclark> ok
[17:12] <kubotu> ::branches-next:: [kjobwidgets] r27 Fix -dev depends... (by Scarlett Clark)
[17:25] <shadeslayer> yofel: any idea why /usr/share/kde4/apps/kajongg/kajongg.py does something like from qt import QObject, usingQt4
[17:25] <shadeslayer> instead of from PyQt4 import QObject
[17:26] <yofel> no
[17:27] <shadeslayer> ajj
[17:27] <shadeslayer>     new: qt.py and qt4.py bundling all Qt imports
[17:27] <shadeslayer> hurray
[17:27] <yofel> o.O
[17:27] <shadeslayer> 28a90a9d58d44c2b229355cd82599d1b9b4256f8 in kajongg
[17:27] <shadeslayer> also has a debian.control in the source code
[17:27] <shadeslayer> \o/
[17:27] <yofel> do I smell qtchoosery
[17:28] <shadeslayer> yofel: yes
[17:28]  * yofel runs
[17:28] <shadeslayer> :'(
[17:30] <shadeslayer> http://paste.ubuntu.com/7581733/
[17:32] <yofel> ...
[17:33] <shadeslayer> and ofcourse it's not installed
[17:33] <shadeslayer> \o/
[17:46] <shadeslayer> I'm trying not to kill myself right now, because I can't figure out why the freaking qt.py file is not installed
[17:47]  * yofel stares at his kmail window that has pkg-kde-talk@lists.alioth.debian.org as recipient and a huge white space in it...
[17:47] <shadeslayer> :D
[17:48] <shadeslayer> ah
[17:48] <shadeslayer> ahaha
[17:48]  * shadeslayer needs a drink now, even though I still have a hangover from last night
[17:49] <shadeslayer> https://projects.kde.org/projects/kde/kdegames/kajongg/repository/revisions/985bf653088e53483722009f6277dd439423fbfa
[17:49] <yofel> lol
[17:49] <shadeslayer> how was this not freaking picked up
 ::branches-next:: [kjobwidgets] r27 Fix -dev depends... (by Scarlett Clark)
[17:51] <santa_> where is this branch, I don't see it in launchpad
[17:51] <santa_> ?
[17:51] <shadeslayer> which branch
[17:52] <santa_> that one of kjobwidgets having that commit "r27 Fix -dev depends..."
[17:52] <shadeslayer> pad.lv/~kubuntu-packagers
[17:53] <shadeslayer> oh yay
[17:53] <yofel> santa_: lp:~kubuntu-packagers/kubuntu-packaging-next/kjobwidgets
[17:55] <santa_> so how is your workflow with those branches are you going to merge them into this ones https://code.launchpad.net/kubuntu-packaging or what?
[17:57] <yofel> not quite sure yet, apachelogger will know more
[18:01] <sgclark> afaik no, all kf5 will now go into the next
[18:06] <kubotu> ::branches:: [calligra] r99 Fix syntax of not-installed ... (by Philip Muškovac)
[18:10] <yofel> santa_: TBH, the ultimate goal would be to move all the packaging to alioth before it becomes a question whether to move it back or not, not sure how that'll work out for you
[18:12] <kubotu> ::branches-next:: [kbookmarks] r28 * Refresh libkf5bookmarks5.symbols ... (by Philip Muškovac)
[18:12] <kubotu> ::branches-next:: [kio] r34 Patch symbols... (by Scarlett Clark)
[18:13] <santa_> yofel: that would mean I wouldn't be able to work on it, but that's [k]ubuntu's business
[18:46] <yofel> shadeslayer, apachelogger, Riddell, ScottK, sgclark: anything you want to add before I send this? http://paste.kde.org/p87y1jgp7
[18:47] <shadeslayer> +1
[18:54] <sgclark> +1
[18:54] <santa_> so, farewell to any kubuntu's contributions from me I'm afraid
[18:54] <sgclark> don't believe I have access to pkg-kde though
[18:54] <yofel> santa_: well, we're not moving everything immediately, and we could still merge changes from anongit clones
[18:55] <yofel> sgclark: they're fairly reasonable if you have people backing you, so adding you shouldn't be a problem
[18:55] <sgclark> ok
[18:56] <santa_> yofel: yes, the question is, will they allow you to merge any change from me? because I don't think so
[18:56] <yofel> you could start out by hanging out in #debian-qt-kde@irc.oftc.net
[18:56] <yofel> santa_: I don't think it's a problem as long as the change is sane and we review it
[18:59] <sgclark> ok in there
[19:02] <santa_> yofel: http://paste.kde.org/p0orufxa2
[19:02] <santa_> and he was just asking for advice, not actually forwarding anything from me
[19:03] <yofel> I read that when it happened.. maybe not using names would help that -.-
[19:07] <kubotu> feed branches had 4 updates, showing the latest 3
[19:07] <kubotu> ::branches:: [kajongg] r82 * Merge with debian, no remaining changes... (by Rohan Garg)
[19:07] <kubotu> ::branches:: [kamera] r123 * Merge with Debian, no remaining changes... (by Rohan Garg)
[19:07] <kubotu> ::branches:: [kanagram] r119 * Merge with debian, no remaining changes... (by Rohan Garg)
[19:13] <kubotu> ::branches-next:: [kio] r35 Remove MISSING i386 ... (by Scarlett Clark)
[19:13] <kubotu> ::branches-next:: [kio] r36 Fix broken -dev depends ... (by Scarlett Clark)
[19:18] <Riddell> yofel: only 1 master branch? no kubuntu branch?
[19:19] <yofel> Riddell: 1 master and the series branches, you can have unreleased stuff in the utopic branch if it's specific to us
[19:19] <yofel> u+1 would then start off as a branch of utopic
[19:20] <yofel> or as  a merge of utopic and master
[19:23] <Riddell> mm, ambitious, I like it
[19:27] <genii> Does Kubuntu ppa use some different version of os-prober or something? Prior to 14.04 release, grub listed my Kubuntu as actually Kubuntu, then after release, it goes to saying Ubuntu.
[19:27] <ScottK> genii: It's a known change in 14.04.
[19:27]  * ScottK doesn't recall why.
[19:28] <genii> ScottK: I just found it extremely odd, and was curious :)
[19:28] <yofel> me neither, but I remember the UEFI issues in 13.10, maybe related to some more 'ubuntu' hardcoding in the stack
[19:37] <santa_> sgclark: are you working on the kf5 ftbfs'es? may I help?
[19:38] <yofel> santa_: who's working on what is tracked at https://notes.kde.org/p/kubuntu-ninjas-frameworks
[19:39] <shadeslayer> yofel: genii ScottK it was because the uefi entry said ubuntu and looked for ubuntu in GRUB, and keeping the delta was just too much work
[19:39] <shadeslayer> because it could cause issues in the future
[19:39] <yofel> ok, so it was that
[19:39] <genii> Aaaaah, OK
[19:39] <shadeslayer> atleast that's what I recall apachelogger saying
[19:40]  * yofel will send the mail in 20min if there's no more response
[19:43] <santa_> yofel: so mind if I add myself for kactivities?
[19:45] <yofel> santa_: sure, instead of ppaX just post your merge request or the bzr branch with your changes so we can find it
[19:45] <yofel> once you're done, until then put WIP
[19:45] <santa_> allright
[20:01] <yofel> mail sent
[20:07] <kubotu> ::branches:: [calligra] r101 release to utopic (by Philip Muškovac)
[20:31] <santa_> frameworkintegration amd64 build should be retried
[20:34] <sgclark> done
[21:07] <kubotu> ::branches:: [kactivities-work] r33 Remove duplicate changelog entry.... (by Jose Manuel Santamaria Lema)
[21:07] <kubotu> ::branches:: [kactivities-work] r34 Add kf5-kio-dev build depend. (by Jose Manuel Santamaria Lema)
[21:07] <kubotu> ::branches:: [kactivities-work] r35 Update symbols file. (by Jose Manuel Santamaria Lema)
[21:12] <kubotu> feed branches-next had 12 updates, showing the latest 3
[21:12] <kubotu> ::branches-next:: [kparts] r24 * Refresh libkf5parts5.symbols ... (by Philip Muškovac)
[21:12] <kubotu> ::branches-next:: [knewstuff-work] r22 Fix control file, re-adding the -dev package. (by Jose Manuel Santamaria Lema)
[21:12] <kubotu> ::branches-next:: [knewstuff-work] r23 Install the *.pri file in the -dev package. (by Jose Manuel Santamaria Lema)
[21:45] <jose> thanks for the highlights, kubotu...
[22:08] <sgclark> I reviewed santa_ merges and they look good, I just don't know how to do a merge, anyone available to do that? Holding up the works.
[22:09] <yofel> sgclark: go to your local checkout/branch of the branch you want to merge, then run the command the merge page shows at "To merge this branch:"
[22:10] <yofel> IIRC you'll then have to commit the merge, push and you're done
[22:10] <shadeslayer> sgclark: can you point me to the url?
[22:10] <yofel> shadeslayer: frameworks pad has the urls
[22:11] <sgclark> ^
[22:11] <shadeslayer> ^^
[22:11] <shadeslayer> ah ok
[22:11]  * shadeslayer throws a keyboard at his internets
[22:14] <soee> :o
[22:14] <yofel> jose: do you mind? I'm sure apachelogger can hide the names...
[22:15] <yofel> launchpad now has inline diff comments for merges o.O?
[22:15] <yofel> wow
[22:16] <jose> yofel: not a problem :)
[22:16] <jose> yeah, I'm in Beta and find that awesome!
[22:33] <shadeslayer> didn't realize people were still working on Launchpad
[22:40] <santa_> sgclark: thank you
[22:41] <sgclark> santa_: np, and thank you
[22:51] <valorie> shadeslayer: I've not gotten a ballot yet
[22:55] <valorie> at least searching for "ballot" I get nothing
[22:59] <valorie> afk for a bit to run
[23:13] <kubotu> feed branches-next had 6 updates, showing the latest 3
[23:13] <kubotu> ::branches-next:: [kdelibs4support-work] r32 Update kio metainfo install path. (by Jose Manuel Santamaria Lema)
[23:13] <kubotu> ::branches-next:: [kdelibs4support-work] r33 Update symbols file. (by Jose Manuel Santamaria Lema)
[23:13] <kubotu> ::branches-next:: [kdelibs4support-work] r34 Rename libkf5kdelibs4support5.lintian-overrides as libkf5kde... (by Jose Manuel Santamaria Lema)