[00:04] valorie: our session is Wed June 13 at 1700 UTC [00:11] do we have all three domains for docs.kubuntu? [00:11] .com, .org, .co.uk [00:12] in theory we could anyway [00:12] ovidiu-florin, jose: where are we on website business btw? [00:13] apachelogger: ask ovidiu-florin! [00:13] we're still having issues with the child theme. [00:14] We have some suggestions from someone on how to implement that, but I haven't had the time to try them out [00:15] also, someone promissed to make an sketch for the Team page [00:15] but no feedback since [00:15] I don't remember his name [00:15] sgclark: status page adjusted for next http://qa.kubuntu.co.uk/kf5-status/build_status_4.100.0_trusty.html [00:16] ovidiu-florin: check logs and poke? :) [00:16] apachelogger: ok thanks, power went out :( [00:16] will do, in the morning [00:16] in ~9 to 10 hours [00:17] can someone poke me around then to remind me please? [00:17] kubotu: whats the plugin for that? [00:18] kubotu: remind ovidiu-florin to poke people in 10 hours [00:18] apachelogger, you don't have 'remind::other::about' permissions here [00:18] kubotu: you are being very rude today [00:19] :) [00:19] I'll just look over the TODO tomorrow and remember to do that [00:19] kubotu: whoami [00:19] you are my boss [00:19] that's right [00:19] kubotu: remind ovidiu-florin to poke people in 10 hours [00:19] okay [00:19] thx sweetie :* [00:20] nice [00:20] lol [00:21] kubotu: whoami [00:21] you are *ahoneycutt69896164926340 [00:21] kubotu: whoami [00:21] you are *ovidiu_florin69896164850320 [00:21] clearly you are nobodys :P [00:21] what's with the numbers? [00:21] random number [00:22] supposed to make the uid unique I guess ^^ [00:22] since they are autogenerated [00:23] sgclark: I am going to rename the last branches with -kf5 suffix unless you still need them [00:24] kwallet/kactivitites/kdnssd [00:24] * apachelogger reports out of coffee and runs circles [00:24] I am done with bzr if thats what you mean [00:25] renamed [00:26] * sgclark impatiently waits for all these copied packages to build [00:27] shall I trigger neon5 retries to delay things a bit? :P [00:27] * sgclark cries out nooooo [00:27] but it's also terribly red :'< [00:28] oh right [00:28] * apachelogger writes another mail [00:44] pft santa_ is blocking our builds [00:44] * ScottK considers starting to merge Qt5 5.3 from Debian. [00:44] please do [00:44] * apachelogger wants plasma next with wayland by the end of the week :O [00:45] Just got to my hotel. Need some dinner first. [00:46] apachelogger: wait what?!? how. I need to finish at some point ... 14 hours ugh [00:46] https://launchpad.net/~panfaust/+archive/kubuntu-kf5-experiments [00:47] 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] apachelogger: I can remove the packages and do my experiments other day if that helps [00:48] I still have to apply all my changes files.. [00:48] already queued now, I don't mind much :P [00:48] yes please. ^^ [00:49] santa_: why do you need to build the entire packageset anyway? [00:49] just make your ppa dep on next and reuse the existing packages to build from [00:50] yofel: did you ever reach any sort of conclusion on continuous builds btw? [00:50] apachelogger: I'm just getting familiar with your ppa's stuff [00:50] never used it before [00:50] gonna remove everything then [00:52] santa_: http://i.imgur.com/8BJzoXE.png [00:53] if you add another ppa as a dep it will basically add that ppa to the sources.list of the builders [00:53] so it will simply resuse the existing packages from kubuntu next [00:54] 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] ah, please coordinate ftbfs fixes [00:55] but now I guess I could re-use your stuff, yes [00:55] otherwise work gets duplicated because I think sgclark is also working on that [00:55] it's everything merged now [00:55] * sgclark is [00:56] I don't have any pending work right now [01:00] 4.100 will have compat issues with the released workspace [01:00] * apachelogger rolls eyes [01:01] Riddell: btw, did you understand how tarme works yet? [01:10] 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] I'm sure of it because both Aaron and KDE promo said so. [01:12] well, frameworks api isn't entirely frozen yet ^^ [01:13] * sgclark giggles [01:15] oh [01:15] ScottK: fear not, next month binary interface freeze kicks in [01:15] if shit breaks after that we get to throw dirt ^^ [01:16] And then throw dirt again a month later. [01:16] Oh, wait. I forgot. [01:17] Kevin Ottens promises no regressions ever in KF5 so we can just blindly update whenever. [01:17] What could possibly go wrong. [01:28] * apachelogger wonders when devs will remember that qreal != float && qreal != double [01:30] Never since in Qt5 they aren't required to care. [01:32] I see a ftbfs :P [01:33] not on kubuntu though [02:15] * apachelogger squints [02:23] well, it's official lunchpad hates me [02:24] oh, actually the buildpackage thing hates me [02:30] Riddell: data packages for l10n doesn't compute for me [02:30] what's the point of that? [02:32] oh multiarch [02:32] many a kittens have to die because of the frameworks packaging [02:33] simplest of frameworks would have an exciting amount of 4 packages in control [02:57] and why does the lib binary:version dep on the data [03:01] lconvert: could not find a Qt installation of '' [03:01] ... [03:33] neon is eating the builders [03:33] much rude. [03:39] Riddell, yofel, ScottK, shadeslayer: how about we drop the debian subdirs in bzr branches? [03:39] apachelogger: Please don't. [03:39] ScottK: why? [03:39] It would seriously mess up my workflow. [03:40] how so? [03:40] The .bzr dir is only in the top level dir. [03:40] 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] If there was no debian dir, the .bzr ends up in my diff. [03:41] Really annoying. [03:41] ScottK: -x .bzr? [03:41] What problem are you trying to solve by changing it? [03:42] having to type more than I can be bothered to [03:42] 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] d isn't much [03:42] too much considering there's some 80 branches just for frameworks and workspace right now [03:43] but, really the issue is probably more the fact that the packages are too splity [03:44] 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] Sounds like it's dieing to be scripted. [03:44] it is exactly the kind of thing I was talking about yesterday WRT having to batch edit stuff [05:41] apachelogger: continuous builds? [05:42] and please don't drop debian/ [05:42] it would be rather inconvenient for things like wrap-and-sort, dch, etc... [06:12] Riddell FYI about our wrap-and-sort breakage: [06:12] "The merged package definitions were separated by one line containing a [06:12] space (line 20 of your control file), but they should be separated by [06:12] one empty line. That's the reason why the package definitions were [06:12] joined." [06:12] from debian 750247 [06:12] Debian bug 750247 in src:python-debian "devscripts: [wrap-and-sort] removes package definitions when wrapping control file" [Normal,Open] http://bugs.debian.org/750247 [06:17] good morning [07:33] apachelogger: what was your plan wrt kubuntu-packaging-next and kbzr? === vinay is now known as Guest94768 [09:34] yofel: hmm, quite likely [09:41] Riddell: is there a release schedule for kf5 anywhere? I can find a schedule for plasma, but not for kf5 [10:03] yofel: http://community.kde.org/Frameworks/Epics is the best we've got [10:03] although it tends to be whenever dfaure is free [10:17] 'Morning folks [10:25] kubotu: where's my reminder? [10:25] it's been 10 hours [10:26] hm [10:26] kubotu: whoami [10:26] you are yofel [10:31] 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] apachelogger: kubotu forgot about my reminder [10:35] weird [10:35] kubotu: remind ovidiu-florin to poke people in 10s [10:35] yofel, you don't have 'remind::other::about' permissions here [10:36] aha [10:36] remind me about foo in 10s [10:36] kubotu: remind me about foo in 10s [10:36] okay [10:36] PM'd me, curious [10:37] so the reminder is PM? [10:37] did not expect that [10:48] Riddell, apachelogger: if we go with a seperate image for plamsa next for now, do they really have to be co-installable? [10:50] I don't particulary see the point in supporting two workspaces in parallel [10:51] if anything, I see version clashes regarding the epoch [10:52] yofel: they're not coinstallable [10:53] so why rename? [10:53] yofel: kdelibs and kde-runtime equivalents should be co-installable [10:53] kde-workspace doesn't matter [10:53] but there's some bits of kdelibs which have the same name in kf5 and plasma [10:54] kdnssd, kwallet, kactivities [10:54] attica [10:55] :/ [10:55] how about renaming everything kf5- so it's at least consistent? Or would that be too messy again [10:56] seems messy an unnecessary to do all, I've been renaming the ones that clash -kf5 [10:56] which will need script special casing :/ [10:56] right, such is life [10:57] in plasma baloo kfilemetadata and milou will need renamed [10:57] which I can do being upstream [10:57] suggestions welcome for what to call them [11:24] Riddell: I think you're uploading to the wrong PPA? [11:24] yofel: so I've just seen [11:24] ^^ === joshwambua_ is now known as joshwambua [11:36] 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] Riddell: ^ [11:38] Riddell, yofel: source name has nothing to do with the branch, it never has [11:38] as for the renaming [11:38] I'll argue that the kde4 sources should be renamed [11:39] you would still have to special case epochs then, or add an epoch to everything [11:40] yofel: why? all frameworks will be version 5.x and soversion 5 [11:41] baloo 4:4.13.0 >> baloo 5.0 [11:41] yofel: so? [11:42] everything gets epoch 5? :P [11:42] well, 4 would suffice, current is 0 [11:42] that's confusing, should be 5 [11:42] why, the version is 5, epoch has nothing to do with that [11:42] 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] yofel: yes, because apps need it [11:44] how? where? why? [11:45] Version: 4:4.13.0-0ubuntu1 [11:45] !info gwenview [11:45] gwenview (source: gwenview): image viewer. In component universe, is optional. Version 4:4.11.5-0ubuntu0.1 (saucy), package size 2815 kB, installed size 4366 kB [11:45] ...? [11:46] yofel: it has an epoch [11:46] what's wrong with 4:5.0 [11:46] yofel: it's confusing [11:46] well, it's debian... [11:46] yofel: mind and keep https://notes.kde.org/p/kubuntu-ninjas-frameworks updated when you're working on a KF5 package [11:46] yofel: 4:5.1.3+dfsg+really5.1.2 [11:47] Riddell: yeah sorry, forgot to do that for the first 2 [11:47] apachelogger: looks fine to me ^^ [12:07] 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] ok [12:18] hola sgclark [12:23] Riddell: morning :) [12:43] Coordinate the epoch thing with Debian. If we get to a higher epoch than them it really sucks. [12:47] hi [13:05] moin shadeslayer ^^ [13:05] hello [13:05] how's it going [13:06] apachelogger: I hear you're giving a talk about builder @ UOS :P [13:08] ScottK: do we want a Qt5 sync up session at UOS? [13:09] builder? [13:09] shadeslayer: that's news [13:09] ^_^ [13:10] yofel: whatever happened to the maintainenance on aliaoth notion [13:15] nothing, at least not from my side. [13:15] Let me dump our last proposal into the channel and see what happens [13:15] might as well discuss the epoch too [13:18] shadeslayer: we want 5.3 to go in asap. [13:18] If that needs a session, fine. [13:19] I'll ask around I guess [13:19] My trying to get someone from Canonical to discuss it via email isn't going very well. [13:19] ok [13:24] 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] I still have a different view tbh .... [13:26] shadeslayer: take that up with the techboard, until then I'm with scott [13:27] apachelogger: ok, so sune is against renaming sources [13:27] (old ones I mean) [13:27] so the epoch is moot I believe as we can keep 0 for now [13:29] yofel: not epoching makes scripting more work because you need to parse the epoch out of the changelog before doing things [13:29] unless there is a dch argument that automatically reuses the epoch [13:33] apachelogger: dch -i does what I think you're suggesting. [13:34] ScottK: no, I mean like dch -v 5.1.0 [13:34] Oh. [13:34] well, currently *nothing* in kf5 has an epoch [13:34] yofel: applications will [13:34] Yeah you need to include it. [13:35] gwenview has epoch 4 [13:35] that's not kf5, that's plasma and applications [13:35] unless we rename all applications we will have an epoch [13:35] and you can just keep the 4 there [13:35] yofel: so you want two different scripts? [13:35] scripts no, different package lists yes [13:35] 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] something you could entirely avoid if you say everything core kde (whatever that will be in the future) has epoch X [13:36] FWIW, if someone goes to the TB to ask for an MRE for KF5, I'll probably be arguing against it. [13:36] what's so hard about string.split(':') ? [13:37] yofel: you first need to get the version [13:38] so we are talking something like parsechangelog | grep Version | sed [13:38] which is entirely avoidable by simply not insisting on having no epoch because there is zero benefit to not having an epoch [13:39] 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] IMO, I would rather special case stuff for now until we have worked out with debian what they want to do [13:39] 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] well yeah, the epochs should be aligned [13:40] I'm not disagreeing that using one epoch on everything is easier, but they have to be in sync then [13:40] I am arguing that the epochs should also be aligned across all bits we need to mass automate [13:43] apachelogger: yofel https://bitbucket.org/unit193/trellobot [13:44] bitbucket still exists? [13:44] yes, I use it [13:44] for sekrit repos [13:44] fun [13:45] sekrit repos he said [13:45] don't be lazy, write an rbot plugin [13:45] then you can trello off of kubotu instead of having to run a dedicated bot [13:46] hmm [13:46] I personally fail to see the point fwiw [13:52] * yofel would rather have commit notifications back :S [13:53] lol [13:54] I just thought the same and am currently looking into that :P [13:54] not quite sure how to do that though [13:54] you could probably do it by having the bot subscribed to the mail notifications from launchpad [13:55] that's all sorts of complicated [13:55] rss seems more useful [13:55] but automatically subscribing to things is a bit rubbish theree [13:56] that's also why the bug notifications are not active on everything [13:56] well, if launchpad had rss, sure :S [13:56] yofel: it does [13:56] well, loggerhead has [13:56] oh, actually lunchpad has as well [13:56] http://feeds.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/plasma-workspace/branch.atom [13:56] *blink* I did not know about that [13:57] it's all very well hidden [13:57] ohohoh [13:58] I found a team level feed [13:58] http://feeds.launchpad.net/~kubuntu-packagers/branches.atom [13:58] msg kubotu [13:58] eh [13:58] ^^ [13:58] msg kubotu [14:00] @_@ [14:03] the feed content is a bit pointless [14:03] kubotu: rss show branches 1 [14:03] lemme fetch it... [14:03] Channel : Branches for Kubuntu Packagers [14:03] 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] that's missing the interesting part -.- [14:04] oh, maybe by project would work better [14:05] kubotu: rss show branches 1 [14:05] lemme fetch it... [14:05] Channel : Latest Revisions for kubuntu-packaging [14:05] 2014/06/02 19:58 :: [khtml] r28 Fix remain wrap-andsort breaks... (by Scarlett Clark) [14:05] that one doesn't have links ^^ [14:06] link might be a bit long IMO [14:06] we know where it is anyway (as long as the project is shown) [14:06] not if one takes next into the picture [14:06] well, when there's branch with equal name in both projects anyway [14:07] hence my point about the project [14:08] FWIW, that's already more useful than the bug notifications... [14:08] what's wrong with the bug notification :O [14:09] uhm, that it always shows the same message each time...? [14:09] so? [14:09] you know the bug has changed [14:10] I can let kmail notify me about that... [14:10] ok, nevermind [14:10] just like with branches :P [14:10] I'm just used to having *content* in such messages [14:10] by that standard irc notifications make no sense altogether because you could simply sub by mail :P [14:10] yofel: well, tell launchpad that [14:10] can't do much about the title the feeds give [14:11] yeah, I got that the second after I finished writing -.- [14:11] ^^ [14:11] I think I found a way to track all bug reports btw [14:11] it's much more straight forward once one realizes that teams have feeds ^^ [14:12] hidden features, hidden features everywhere [14:13] apachelogger: I'm not arguing about launchpad, I'm just arguing that the title isn't really sufficient to tell me anything :/ [14:14] mh [14:14] it appears one can write custom filters for the feed plugin [14:14] not that I know or understand how that would work [14:15] eean or markey would apparently since they hold authorship :P [14:15] I'm not really sure though if the posts warrant a like 7 line bot message in here though [14:15] even if I like the long kde commit notifications [14:16] looking I say, looking [14:17] well [14:17] yofel: as far as the atom is concerned I don't think filtering is an option either [14:17] the actually useful data is html content [14:18] extracting meaningful things from that seems nigh impossible [14:18] oh oh oh [14:18] ScottK: yofel apachelogger reckon I should schedule a session for Frameworks releases in ubuntu? [14:19] urgh, yeah, that content looks awful [14:20] shadeslayer: to discuss it with whom? [14:20] TB [14:21] 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] I'll say that unless there have been actual releases a discussion would involve 99% handwaving [14:21] I see [14:22] so whats the plan for 14.10 then [14:22] land in ppa [14:22] ^ [14:22] we could put it in the archive, but it would be essentially unsupported [14:23] depends on demand really I think [14:23] which is not in the interest of anyone as that prevents upstream to quickly iterate initial bugs out of the way [14:23] ^^ [14:24] 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] 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] I think landing is pointless unless we can keep updating monthly [14:25] 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] yeah, basically, not having KF5 in the archive blocks KF5 apps in the archive for 9 months [14:27] 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] and it's not like we can put applications in the archive post-release [14:29] but then if random-app requires a tier 3 framework, what then [14:34] 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] kubotu: newversion calligra 2.8.3 [14:38] https://bugs.launchpad.net/bugs/1326002 [14:40] ooh [14:40] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [14:40] has autopkgtest output now [14:40] sweet [14:41] wow, how colorful ^^ [14:41] :D [14:41] autopkgtest for kde4libs 4:4.13.1-0ubuntu1: Always failed [14:41] greaaaaat [14:42] 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] yofel: that kdelibs part failing is because of dh-acc not depending on debhelper [14:43] ah k [14:43] workaround would be to add it manually to our test [14:44] 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] right, still need to read up on that [14:46] shadeslayer: I think we already decided about frameworks in our session. No need for something at UOS. [14:46] ScottK: roger [14:47] whole bunch of stuff is blocked on non installable maxima [14:47] hm [14:52] ok so I dput ktextwidgets v3 to ppa:kubuntu-ppa/next but seems to have vanished into space, any ideas? [14:54] shouldn't happen unless you didn't sign it [14:54] Successfully uploaded packages. [14:54] to the right ppa? [14:54] 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] 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] enable updates for frameworks would then add the PPA [14:56] so short of getting update approval it's either ppa by default or opt-in ppa [14:56] yofel: used wrong key, thank you [14:56] That sort of thing has been turned down before. [14:57] apachelogger: I say we update to feature freeze and then start cherry picking. [14:58] well regardless of the outcome of a TB decision we don't have that many options really [14:58] ScottK: except that cherry picking might result in confusing backtraces for upstream [14:58] ScottK: that can only be done if the big distros band together and put up a maintenance system [14:59] i.e. that cherrypicking would have to be implemented upstream with more than one party involved otherwise that calls for screwuppery [14:59] also that potentially is a lot of work with some 60 potential frameworks that need watching [14:59] shadeslayer: Upstream bought that confusion when they declined to support their releases. Not my problem. [15:00]