[03:13] <kubotu> feed branches-next had 4 updates, showing the latest 3
[03:13] <kubotu> ::branches-next:: [plasma-framework-work] r32 Delete plasma-framework5.symbols... (by Jose Manuel Santamaria Lema)
[03:13] <kubotu> ::branches-next:: [plasma-framework-work] r33 Update symbols files. (by Jose Manuel Santamaria Lema)
[03:13] <kubotu> ::branches-next:: [plasma-framework-work] r34 Fix -dev depends.... (by Jose Manuel Santamaria Lema)
[06:44] <soee> good morning
[07:22] <apachelogger> !find krb5-config
[07:23] <valorie> that's a helpful message
[07:23] <apachelogger> he means the package is krb5-config :P
[07:24] <valorie> !find gobbledegook
[07:24] <valorie> ya don't say
[07:24] <apachelogger> ah yes
[07:24] <apachelogger> problem no1: saucy
[07:24] <valorie> !info krb5-config
[07:24] <apachelogger> problem no2: my cache says krb5-config doesn't contain krb5-config
[07:24] <apachelogger> which is a bit funny
[07:25] <apachelogger> tsimpson, jussi: ubottu probably should be bumped to trusty
[07:25] <valorie> but ubottu usually is in trusty
[07:25] <valorie> !find phonon-backend-vlc
[07:25] <valorie> I mean
[07:25] <valorie> !info phonon-backend-vlc
[07:25] <valorie> oooo
[07:26] <tsimpson> @config plugins.PackageInfo.defaultRelease
[07:26] <valorie> ubottu is ahead!
[07:26] <tsimpson> for some reason it has a channel specific value here..
[07:27] <apachelogger> perhaps we switched it to saucy before saucy was a thing because no one in here ever cares about stable?
[07:31] <apachelogger> yofel: uh, changelog generation from git, someone suggested that previously as well, totally forgot about it
[07:31] <apachelogger> certainly would be smartest  IMO
[07:32] <tsimpson> @config plugins.PackageInfo.defaultRelease
[07:32] <tsimpson> !info krb5-config
[07:33] <apachelogger> better
[07:33] <apachelogger> it's still lying, though I think that's because of the package ^^
[07:35] <tsimpson> well its source is apt-cache
[07:37] <tsimpson> if you want to search for files explicitly, use a path (like !find bin/krb5-config)
[07:37] <tsimpson> otherwise it'll try and match to a package name first, then search files
[07:40] <apachelogger> ah
[07:40] <apachelogger> weird package name then
[07:40]  * apachelogger shrugs it off
[08:14] <kubotu> ::branches-next:: [kcmutils] r27 Install qt pri file to -dev package (by Harald Sitter)
[08:14] <kubotu> ::branches-next:: [kactivities] r34 * Wildcard qml plugin installation in kactvities.install... (by Harald Sitter)
[08:45] <shadeslayer> good morning
[08:46] <apachelogger> yo
[08:47]  * apachelogger would like to point out that it makes -32 sense to make multiarch lib packages when one then packs usr/bin/ and etc/ into that package....
[08:58] <Riddell> apachelogger: where have we done that?
[08:58] <apachelogger> kservice
[08:59] <apachelogger> etc is now in a data, kbuildsycoca5 is still in the lib package though
[08:59] <apachelogger> also I get the feeling I am making more things red than green :O
[08:59]  * apachelogger been doing non-standard packaging for too long
[09:04] <apachelogger> Riddell: why is kf5-kio.install instead of kio.install?
[09:05] <yofel> kiconthemes has mulitarch issues too
[09:05] <yofel> E: libkf5iconthemes5: arch-dependent-file-not-in-arch-specific-directory usr/bin/kiconfinder5
[09:06] <yofel> btw. am I understanding this right that we're putting all the l10n stuff into -data packages?
[09:07] <apachelogger> yofel: only when there is no other meaningful package
[09:07] <apachelogger> e.g. in kio I am packing them in with kf5-kio as the l10n is for the slaves and not the libraries themself
[09:08] <yofel> so you're just putting it into the runtime package instead of making an extra arch:all one?
[09:09] <apachelogger> yeah, there's no point in an arch all package there
[09:09] <Riddell> yofel: I'm putting l10n into a -data if that's what multiarch needs it to be
[09:09] <Riddell> apachelogger: hmm, no reason I guess, 
[09:09] <yofel> ok
[09:09] <apachelogger> for the libs I'd also not have put it in data short of multiarch really
[09:09] <apachelogger> more packages just give you more points of failure for the most part
[09:10] <yofel> IMO this is still easy enough to keep multiarch-compatible
[09:10] <apachelogger> hence the -data packages :P
[09:10] <yofel> right
[09:14] <kubotu> feed branches-next had 8 updates, showing the latest 5
[09:14] <kubotu> ::branches-next:: [kconfigwidgets] r32 fix locale install glob... (by Harald Sitter)
[09:14] <kubotu> ::branches-next:: [kservice] r31 * Add new package libkf5service-data for localization and et... (by Harald Sitter)
[09:14] <kubotu> ::branches-next:: [kxmlgui] r29 * Install qt mkspecs pri to libkf5xmlgui-dev... (by Harald Sitter)
[09:14] <kubotu> ::branches-next:: [ktextwidgets] r28 Install qt mkpsecs pri files to libkf5textwidgets-dev (by Harald Sitter)
[09:14] <kubotu> ::branches-next:: [kio] r37 * Update kf5-kio.install with new files... (by Harald Sitter)
[09:23] <apachelogger> so
[09:23] <apachelogger> I broke some dep, I am not sure how though
[09:24] <yofel> which one?
[09:24] <yofel> too much red :S
[09:24] <apachelogger> yofel: dep resolution doesn't work anymore, see kinit e.g.
[09:25] <apachelogger> might have been the kservice replaces breaks I guess
[09:26] <apachelogger> ah, I know, typo ftw
[09:26] <apachelogger> I really think there is too much copy'n'paste shit going on in these packages
[09:26] <apachelogger> like severely too much
[09:27] <apachelogger> 90% of the things I did on the packages so far was cnp in control
[09:27] <apachelogger> libkf5service5-data OR libkf5service-data?
[09:28] <apachelogger> soversion or not, that is the question
[09:28] <apachelogger> opinions plz ^^^
[09:29] <yofel> I've looked into scripting control for neon, but all I found are really shitty dh_clean override hacks to generate it from control.in or running another target first
[09:30] <yofel> apachelogger: not sure what we did for the other packages, but IMO without, it's not like locales are co-installable
[09:30] <yofel> altough, then the dep has to be >= too so it doesn't break
[09:31] <apachelogger> yofel: I think it would already help a lot if we used substvars for the descriptions and so forth
[09:31] <yofel> talk to debian if they want that
[09:31] <apachelogger> yofel: the version not breaking is based on the assumption that libfoo1 has compatible assets with libfoo2
[09:31] <apachelogger> which is a bogus assumption IMO
[09:32] <yofel> well, bogus true, but I don't think it's worth the conflicts
[09:32] <yofel> Riddell: ^ ?
[09:32] <Riddell> what what?
[09:33] <Riddell> I'm preferring no soversion in the -data so libkf5service-data
[09:33] <apachelogger> yofel: except a badly written library can actually have runtime kaputness from incompatible/missing assets
[09:33] <apachelogger> Riddell: yeah, but version >= or = source:version
[09:34] <yofel> apachelogger: that's then a badly written library, but not a packaging issue
[09:34] <apachelogger> sure it is a packaging issue
[09:34] <yofel> how
[09:34] <Riddell> I've been using = source:version, it might not be backwards compatible for some reason
[09:34] <apachelogger> the library is entirely within its right to fail in any manner when assets are corrupted
[09:34] <apachelogger> and corrupted assets are not to tell apart from shitty packaging
[09:34] <apachelogger> Riddell: that's the argument
[09:34] <apachelogger> so
[09:34] <yofel> hm
[09:35] <apachelogger> IMHO we should do =
[09:35] <apachelogger> iff it then turns out one can push a >=
[09:35] <apachelogger> but I think assuming the least compatibility by default is the safer way to go
[09:35] <yofel> I just don't want to end up in the same situation where upstream does something stupid and we can't properly update (i.e. libkscreen)
[09:36] <yofel> but for now keep = then I guess
[09:53] <apachelogger> kf5html5-data
[09:53] <apachelogger> it seems we have a bit of a naming inconsistency
[09:56] <Riddell> fixy fixy
[09:59]  * Mirv haz some Nexus 10 to bring to Berlin for Kubuntu development for someone called Aleix :)
[09:59] <Riddell> Mirv: from jussi?
[09:59] <Riddell> what's happening in Berlin?
[09:59] <Riddell> Aleix Pol?
[09:59] <Mirv> Riddell: yeah, he just ran through my lunch place giving it to me
[09:59] <Mirv> Riddell: Qt Summit
[09:59] <Riddell> ah cool
[10:00] <Mirv> and Mr. Pol, yes
[10:00] <shadeslayer> Mirv: yeah, that would apol on IRC :)
[10:00] <shadeslayer> *would be
[10:02] <Mirv> ok, I'll ping him at some point before next week
[10:04] <apachelogger> #lunchinvasion
[10:05] <shadeslayer> it's only 12 :O
[10:05] <apachelogger> I didn't get invaded either
[10:07] <kubotu> ::branches:: [kanagram] r120 Release... (by Rohan Garg)
[10:07] <kubotu> ::branches:: [kapman] r73 * Merge with Debian, no remaining changes... (by Rohan Garg)
[10:07] <kubotu> ::branches:: [kapman] r74 Release... (by Rohan Garg)
[10:11] <apachelogger> ktexteditor-data
[10:11] <apachelogger> data naming needs serious revising
[10:13] <kubotu> ::branches-next:: [kinit] r24 * Install localization to kinit package... (by Harald Sitter)
[10:13] <kubotu> ::branches-next:: [kpty] r28 -data is arch all (by Jonathan Riddell)
[10:13] <kubotu> ::branches-next:: [kservice] r32 fix data package name... (by Harald Sitter)
[10:13] <kubotu> ::branches-next:: [khtml] r29 * Update libkf5khtml5-data.install to contain localization... (by Harald Sitter)
[10:13] <kubotu> ::branches-next:: [kross] r25 Update kross.install to contain localization (by Harald Sitter)
[10:18] <apachelogger> Riddell: please remind Scarlett to copy -data from another package and adjust description and name only
[10:18] <apachelogger> missing multi-arch fields
[10:20]  * apachelogger wonders why khtml's is multiarch same
[10:20] <apachelogger> really
[10:20] <apachelogger> we need a way to get rid of copynpasting that stuff
[10:23] <yofel> what's the point for multiarch for arch:all packages?
[10:25] <apachelogger> what's the point of multiarch I say
[10:26] <apachelogger> yofel: data must be marked foreign
[10:26] <apachelogger> that's completely independent of the actual binary architecture support
[10:26] <yofel> I still don't get why it has to be foreign if there's just one deb for all architectures
[10:27] <apachelogger> yofel: https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
[10:28] <yofel> o.O
[10:28] <yofel> well, ok
[10:29] <Riddell> apachelogger: multi-arch should be forgeign on -data
[10:29] <apachelogger> that's what I said
[10:33] <BluesKaj> Hiyas all
[11:01] <apachelogger> sections appear a bit wrong all over the place
[11:01] <apachelogger> Package: libkf5iconthemes5
[11:01] <apachelogger> Section: libdevel
[11:01] <apachelogger> don't think that should be libdevel
[11:04] <Riddell> you're right, it should not
[11:05] <Riddell> although I long for the day when Section is removed from Debian policy, it's entirely pointless
[11:05] <apachelogger> Riddell: it's an optional field
[11:05] <apachelogger> even for source apparently
[11:06] <Riddell> gosh
[11:06] <apachelogger> pft
[11:06] <apachelogger> policy doesn't even say what happens if you don't define it ^^
[11:06] <Riddell> Section: whocares ?
[11:07] <apachelogger> Riddell: just set libs on source and don't care otherwise
[11:07] <apachelogger> current packaging sets section incorrectly for too many packages
[11:07] <Riddell> then lintian moans about not setting libdevel or debug
[11:07] <apachelogger> just realized that data also has libdevel
[11:07] <apachelogger> Riddell: override :P
[11:07] <kubotu> ::branches:: [kapptemplate] r49 * Merge with debian, remaining changes... (by Rohan Garg)
[11:07] <kubotu> ::branches:: [kapptemplate] r50 Release... (by Rohan Garg)
[11:07] <kubotu> ::branches:: [qtwebkit-opensource-src] r73 Update arm64 and ppc64el symbols (by Timo Jyrinki)
[11:08] <Riddell> all copy and paste errors I guess
[11:08] <apachelogger> yeah
[11:09] <apachelogger> and I keep saying that we need to do away with the copy and paste somehow :P
[11:13] <kubotu> feed branches-next had 6 updates, showing the latest 5
[11:13] <kubotu> ::branches-next:: [khtml] r30 Change libkf5khtml5-data to multi-arch:foreign (by Harald Sitter)
[11:13] <kubotu> ::branches-next:: [knotifyconfig] r25 * Fix data package name in control... (by Harald Sitter)
[11:13] <kubotu> ::branches-next:: [kdelibs4support] r31 https://code.launchpad.net/~panfaust/kubuntu-packaging-next/... (by Jonathan Riddell)
[11:13] <kubotu> ::branches-next:: [plasma-framework] r31 [ José Manuel Santamaría Lema ]... (by Jonathan Riddell)
[11:13] <kubotu> ::branches-next:: [kiconthemes] r27 * Add libkf5iconthemes-data and add localization to it... (by Harald Sitter)
[11:20] <Riddell> apachelogger: I wouldn't bother with breaks/replaces on packages now, it's just in a PPA that is experimental
[11:21] <apachelogger> public is public
[11:21] <sgclark> good morning
[11:22] <Riddell> hola sgclark 
[11:22] <sgclark> so I have noticed the 4.100 packages are breaking the 4.96 workspace stuff 
[11:23] <apachelogger> yep, known defect
[11:23] <Riddell> they're not binary compatible
[11:24] <Riddell> so I'm leaving workspace until 4.100 kf5 is done
[11:24] <apachelogger> also not source compatible actually because I thin headers were moved around
[11:24] <Riddell> likely yes
[11:26] <apachelogger> :O
[11:26] <apachelogger> what's with the splitting in frameworkintegration?
[11:26] <apachelogger> kf5-infopage.install
[11:26] <apachelogger> kf5-integrationplugin.install
[11:26] <apachelogger> kf5-platformtheme.install
[11:26] <apachelogger> libkf5style5.install
[11:26] <apachelogger> libkf5style-dev.install
[11:26] <apachelogger> splits gone wild
[11:27] <Riddell> how would you do it?
[11:27] <apachelogger> first 3 are one package frameworkintegration
[11:28] <apachelogger> the first is basically data assets and the other two are plugins
[11:29] <Riddell> okay
[11:29] <Riddell> I'm off to lunch, I expect this all to be done by the time I get back :)
[11:36] <apachelogger> dbg is also somehow a complete mess
[11:36] <apachelogger> sometimes it uses sourcename, sometimes libnameso and sometimes libname
[11:37] <yofel> packaging should be... colorful \o/
[11:47] <apachelogger> Riddell: you broke kservice again
[11:49] <apachelogger> Recommends: libkf5service-bin (= ${source:Version})
[11:49] <apachelogger> I am actually not sure it is legit for a multiarch same package to recommend a non-multiarched package
[11:49] <apachelogger> particularly with arch:any
[11:52]  * apachelogger wonders what E: libkf5service5: symbols-file-contains-current-version-with-debian-revision on symbol _ZN12KConfigGroup10writeEntryIiEEvPKcRKT_6QFlagsIN11KConfigBase15WriteConfigFlagEE@Base and 3 others is about
[11:52] <apachelogger> oh, I didn't commit that change
[11:58] <apachelogger> !find NetworkManager.pc
[12:08] <kubotu> ::branches:: [kopete] r44 Move debian/* to top level dir (by Pali)
[12:08] <apachelogger> filed https://bugs.kde.org/show_bug.cgi?id=335786 for kdelibs4support being rubbish and orange on status page
[12:10] <apachelogger> the plasma packaging could be a bit bogus I think
[12:13] <sgclark> bogus?
[12:13] <kubotu> ::branches-next:: [kdnssd] r61 Add libkf5dnssd-data and add localization to it (by Harald Sitter)
[12:13] <kubotu> ::branches-next:: [kdeclarative] r32 * Add -data package... (by Jonathan Riddell)
[12:13] <kubotu> ::branches-next:: [kdnssd] r62 Remove incorrect and pointless libdevel section from libkf5d... (by Harald Sitter)
[12:13] <kubotu> ::branches-next:: [kdnssd] r63 Make libkf5dnssd5 depend on it (by Harald Sitter)
[12:13] <kubotu> ::branches-next:: [kiconthemes] r28 Make libkf5iconthemes5 depend on it (by Harald Sitter)
[12:13] <kubotu> ::branches-next:: [kiconthemes] r29 add data file... (by Harald Sitter)
[12:14] <kubotu> ::branches-next:: [knotifyconfig] r26 * Fix data install file to use correct path... (by Harald Sitter)
[12:14] <kubotu> ::branches-next:: [kservice] r33 Add -bin package... (by Jonathan Riddell)
[12:14] <kubotu> ::branches-next:: [frameworkintegration] r30 * Compound packaging:... (by Harald Sitter)
[12:14] <kubotu> ::branches-next:: [kiconthemes] r30 fix locale install path... (by Harald Sitter)
[12:14] <kubotu> ::branches-next:: [kservice] r34 * Update libkf5service5.symbols... (by Harald Sitter)
[12:14] <kubotu> ::branches-next:: [kdelibs4support] r32 * Add libkf5kdelibs4support5-bin.lintian-overrides... (by Harald Sitter)
[12:14] <yofel> :O
[12:14] <apachelogger> kubotu: can you make that notices?
[12:14] <yofel> flood++
[12:14] <yofel> :D
[12:14] <apachelogger> kubotu: config set rss.announce_method notice
[12:14] <kubotu> aight
[12:14] <apachelogger> should be better
[12:18] <apachelogger> sgclark: something is very wrong with the source
[12:18] <apachelogger> can't put my finger on it
[12:18] <sgclark> ahh gotcha
[12:18] <apachelogger> though I guess the fact that half the stuff is multiarch and the other half is not does contribute to the feeling
[12:18] <apachelogger> :S
[12:20] <apachelogger> I am not sure splitting libKF5PlasmaQuick from the qml assets is much use either
[12:22] <apachelogger> well, the warning should be gone in ppa4 anyway
[12:45] <apachelogger> Riddell: I guess we'll want a new font package to make frameworkintegration cmake shut up about it not finding the font?
[12:45] <Riddell> apachelogger: a new one? what's wrong with the existing one?
[12:45] <apachelogger> too old I guess
[12:46] <apachelogger> oh no
[12:46] <Riddell> hmm
[12:46] <apachelogger> apparently we are simply not bdeping it
[12:46]  * apachelogger rolls eyse and fixes neon
[12:46] <Riddell> it's marked as runtime anyway so fine to ignore
[12:46] <apachelogger> Riddell: yeah, but it makes status orange
[12:47] <apachelogger> so best just install it I'd say
[12:47] <Riddell> not if it's marked as ignore in cmake-override
[12:47]  * Riddell makes it so
[12:47] <apachelogger> ignores are evil
[12:47] <apachelogger> Riddell: not sure that will work for CMake Warning induced warning states btw
[12:47] <apachelogger> from what I have seen in the code the ignores only work on actual feature lists at the bottom
[12:49] <Riddell> mm maybe, let's see
[12:49] <Riddell> upstreams who depend on something which is higher up in the stack are evil
[12:49] <apachelogger> wasn't there a notion to not do runtime dep checks through cmake anyway?
[12:51] <apachelogger> Riddell: declarative still wip?
[12:51] <apachelogger> because it's still red :P
[12:54] <Riddell> "kdeclarative jriddell ppa2 up" says pad, if it's red then needs to go back to WIP, let me do so, probably my mess up
[12:54] <apachelogger>  This package contains kbuildsycoca5.
[12:54] <apachelogger> Riddell: please use generic descriptions 
[12:54] <apachelogger> e.g. This Package contains runtime binaries.
[12:56] <Riddell> apachelogger: I disagree if there's only 1 binary, makes sense to make it search-able by that binary name
[12:56] <apachelogger> Riddell: sure, then the package grows another binary and no one updates the description
[12:56] <apachelogger> very pointless
[12:57] <apachelogger> Pre-Depends: ${misc:Pre-Depends}
[12:57] <apachelogger> what's the point of those btw?
[12:58] <Riddell> no idea
[12:58] <sgclark> no idea either, don't remember them being there before
[12:59] <Riddell> bzr blame is your friend :)
[13:00] <apachelogger> 1      jriddel | Pre-Depends: ${misc:Pre-Depends}
[13:00] <apachelogger> I'll argue that one of you came up with them :P
[13:04] <Riddell> I'm innocent I say!
[13:04] <apachelogger> the log does not lie :P
[13:06] <sgclark> lol
[13:15] <Riddell> santa_: what did you think needed done to kdelibs4support for networkmanager?
[13:16] <apachelogger> Riddell: it's bugged see backlog
[13:16] <santa_> Riddell: going to create a a merge request soon, but I need to leave home for a little while first
[13:16] <santa_> see you soon
[13:33] <Riddell> frameworks all done! other than the networkmanager stuff in kdelibs4support
[13:33] <shadeslayer> go merge KDE4 stuff!
[13:34] <Riddell> sorry, plasma release needs some love next
[13:34] <Riddell> plasma release just sounds so wrong
[13:34] <Riddell> nim makes a face whenever I say it
[13:34] <shadeslayer> xD
[14:15] <santa_> I'm back, will prepare my partial work of kdelibs4support for merging
[14:16] <Riddell> ah, I've a problem with my cunning plan
[14:16] <Riddell> we're all working on trusty, but plasma needs qt 5.3, and there's only packages of that for utopic
[14:24] <shadeslayer> quite neat that all news sites are showcasing Project Neon 5 ISO's :3
[14:25] <shadeslayer> yay
[14:25] <shadeslayer> Qt 5.3 will be landing soonish
 Qt 5.3 will be landing soonish
[14:26] <santa_> where? neon? ubuntu? debian sid?
[14:26] <shadeslayer> youboontoo
[14:27]  * shadeslayer borrows a squid from apachelogger and throws it at kate
[14:27] <yofel> sweet, canonical stuff or based on lisandro's packages?
[14:27] <shadeslayer> https://lists.ubuntu.com/archives/ubuntu-devel/2014-June/038350.html
[14:28] <shadeslayer> makes me think Canonical stuff
[14:28] <shadeslayer> ScottK: ^^
[14:28] <shadeslayer> santa_: Neon already has Qt5.3
[14:28] <Riddell> shadeslayer: got URLs for sites?
[14:28] <shadeslayer> Riddell: http://www.linuxbsdos.com/2014/05/15/screenshots-of-kde-plasma-next-beta-1/
[14:29] <Riddell> shadeslayer: deserved a kubuntu wire blog I'd say
[14:30] <Riddell> shadeslayer: where did neon get qt 5.3? and is it based on trusty?
[14:30] <Riddell> oh from its own packages I presume
[14:30] <shadeslayer> ^^
[14:30] <shadeslayer> git stable
[14:30] <Riddell> right
[14:30] <shadeslayer> so much shit to merge
[14:33]  * shadeslayer could totally do with some Dr. Who right now
[14:34] <santa_> kdelibs4suport done
[14:37] <santa_> in the notes.k.o stuff I changed the following:
[14:37] <santa_> replaced this http://community.kde.org/Frameworks/List
[14:37] <santa_> with this http://api.kde.org/frameworks-api/frameworks5-apidocs/
[14:38] <santa_> also I have added a link to my b-d graph
[14:38] <santa_> I hope you guys are ok with this
[14:38] <Riddell> groovy
[14:40] <shadeslayer> yofel: Riddell did someone upload 4.13.1 to trusty?
[14:40] <yofel> not me
[14:40] <shadeslayer> because 4.13.2 is going to be out soon
[14:40] <shadeslayer> should I do that
[14:40] <yofel> yeah, should be done today
[14:40] <shadeslayer> now that I have super powers
[14:40] <yofel> go ahead
[14:40] <shadeslayer> ok, let me run the script
[14:40] <yofel> I think you'll have to merge kdelibs
[14:41] <shadeslayer> bah
[14:44] <shadeslayer> yofel: are you sure about that?
[14:44] <shadeslayer> I see the meinproc fix in the PPA too
[14:44] <yofel> oh, nevermind then
[14:48] <santa_> Riddell, apachelogger & anyone else interested: if you have some time, there is something I would like to discuss with you before doing a mass-merge-proposals
[14:49] <Riddell> santa_: looking at kdelibs4support, is that patch going upstream?
[14:49] <santa_> I will send it to reviewboard, yes
[14:49] <Riddell> lovely
[14:49] <santa_> I think it's broken upstream
[14:50] <Riddell> seems strange that everything else works in cmake but it does seem to sort the issue
[14:50] <Riddell> santa_: what's your query on merge proposals?
[14:51] <santa_> see this couple of commits by apachelogger
[14:51] <santa_> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/kiconthemes/revision/31
[14:51] <santa_> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/kiconthemes/revision/32
[14:51] <santa_> they reminded me a couple of things which I would like to change massively in the kf5 packages
[14:52] <Riddell> do go on..
[14:52] <santa_> 1. in library packages, do not ship runtime or data files, it shouldn't contain anything but the library
[14:53] <santa_> it's not the first time I see things in library packages which in my opinion shouldn't be there
[14:53] <Riddell> that's what's been done generally, if you see packages which have stuff in libraries that will interfere with multi-arch then do separate them
[14:54] <shadeslayer> yofel: do we have a bug number for 4.13.1
[14:54] <yofel> yes we do, see changelog
[14:55] <santa_> it doesn't really matter if it interferes with multiarch or not, in general it's a good idea to not ship anything but the library in the lib packages
[14:55] <shadeslayer> cool
[14:55] <santa_> I could elaborate more later if you want, but let me explain the 2nd mass merge
[14:56] <santa_> libkf5iconthemes5 recommends libkf5iconthemes-bin
[14:56] <santa_> ↑ about this I think it could be done better
[14:57] <shadeslayer> uploading
[14:57] <santa_> the thing is libfoo5 usually can't depend on libfoo-bin because libfoo-bin it's also linked against libfoo5, therefore we would have a circular dependency problem
[14:58] <shadeslayer> circular deps only affect depends afaik
[14:58] <santa_> so one better way would be adding a dependency on libfoo-bin in libfoo5.symbols
[14:59] <santa_> like in the debian packages with kde-runtime and libkdecore5
[14:59] <yofel> if lintian doesn't complain about a circular dep then it should be fine though
[15:00] <santa_> if you inspect the symbols files of libkdecore5 you will see this http://paste.kde.org/pyajgldnr
[15:00] <santa_> yofel: iirc it does, and, in general it's a bug
[15:00] <Riddell> what's the problem with the recommends?
[15:00] <yofel> santa_: I know that it's there, and we used it for baloo which bit us later
[15:00] <Riddell> there might be a legit reason why you wanted to have something that used libfoo installed but not libfoo-bin, as I found out with baloo
[15:01] <shadeslayer> yofel: do we usually mark the ubuntu-sru bug as affecting all the stuff one uploads?
[15:01] <yofel> shadeslayer: no, just kde4libs
[15:01] <shadeslayer> ack
[15:02] <yofel> I actually believe you would kill a few launchpad queries if you did that...
[15:02] <santa_> Riddell: the problem I see with recommends is that someone might have it disabled by default (think that you are trying to get these packages included in debian sid at some point)
[15:03] <santa_> about this
[15:03] <Riddell> if you disable recommends then you should be prepared for things not working with full features
[15:07] <shadeslayer> yofel: oh btw no pushing to branches right :3
[15:07] <santa_> Riddell: the thing is: are you sure not having the -bin counterpart won't produce crashes or weird behaviours?
[15:07] <yofel> shadeslayer: I should have reverted all of that
[15:08] <shadeslayer> yofel: right, I called the script with --nopush, but I wanted to confirm since it's the first time I'm SRU'ing KDE SC
[15:08] <yofel> ah yeah, --nopush has no effect with --sru
[15:08] <shadeslayer> aha
[15:08] <shadeslayer> awesoem
[15:09] <Riddell> santa_: crashes would be a bug, weird behaviours maybe, but I don't think added it to .symbols files is any better than recommends
[15:09]  * shadeslayer is happy, no silly rejection emails
[15:10] <ScottK> shadeslayer: I replied to their mail.
[15:10] <shadeslayer> yep, saw it
[15:14] <santa_> Riddell: I do, that's what I would have done if I were still working for debian, and that's what it's done in the current kde4 packaging with libkdecore5 and kde-runtime. so I would suggest you to talk about this with current debian's people. but if you want an unbiased judgement about the matter I strongly recommend you to not mention my name at all
[15:15] <santa_> i.e. see what happened when you asked about allLibraries
[15:16] <Riddell> santa_: yeah I'll discuss it, thanks
[15:19] <santa_> Riddell: ok, let me know about the outcome, if we go for this change, I'm ready to do it. for now I will stick to the 1st massive change (which is ok, isn't it?) and I will use Recommends instead of the hard dependency as apachelogger did in his commit
[15:20] <Riddell> apachelogger: did you decide not to rename kf5-kio?
[15:20] <santa_> oh, another less important thing
[15:20] <Riddell> santa_: yes I think your first point is all good
[15:21] <santa_> what about making a couple of metapackages: kde-frameworks-dev and kde-frameworks-dbg?
[15:21] <santa_> so all the headers and dbg stuff could be installed with just one package
[15:21] <shadeslayer> should probably go into meta-kde then
[15:21] <yofel> apachelogger: btw. could you possibly add some flood protection to the bot that limits the output to like 10-15 messages? If kubuntu-initial-upload gets run on bzr it'll be busy for a while...
[15:22] <shadeslayer> yofel: IIRC it does have flood protection
 feed branches-next had 6 updates, showing the latest 5
[15:22] <yofel> shadeslayer: it did, but he either removed or raised the limit quite a bit
[15:22] <shadeslayer> true
[15:22] <shadeslayer> I think it's pointless to show these messages tbh :P
[15:22] <santa_> shadeslayer: perhaps I would start them as a separate source package to make the merges of meta-kde easier
[15:23] <shadeslayer> santa_: why? we already have additional things in meta-kde
[15:23] <shadeslayer> actually, it probably makes more sense to have tier based meta packages
[15:23] <shadeslayer> kde-frameworks-tier1-dev
[15:23] <shadeslayer> or something like that
[15:24] <santa_> shadeslayer: I dunno, less delta suggests me it would be easier, but it's your call since you are more familiar with ubuntu's merges
[15:24] <shadeslayer> santa_: well, delta can be lowered by sending changes back to debian
[15:24] <shadeslayer> pretty sure they'd be interested in such meta packages too
[15:26] <santa_> shadeslayer: when you send the changes back to debian, remember that you don't know me XD
[15:27] <shadeslayer> seeing how we're planning on moving to debian's infra soonish, I can't think of a issue
[15:46] <ScottK> Metapackages shouldn't pull in libs.
[15:46] <ScottK> They should be pulled in as needed by dependencies.
[15:49] <shadeslayer> ScottK: by that definition kde-developer-sdk is busted
[15:49] <shadeslayer> depends on kdelibs5-dev
[15:50] <ScottK> shadeslayer: kdelibs5-dev isn't a lib.
[15:50] <ScottK> A developer metapackage that depends on -dev's is fine.
[15:50] <ScottK> That'll pull in the needed libs.
[15:50] <shadeslayer> aha, ok, I thought that's what santa_ was suggesting
[15:50] <santa_> that's what I was suggesting
[15:51] <ScottK> Possible I'm misreading.  I'm multi-tasking.
[15:51] <shadeslayer> :)
[15:51] <santa_> a -dev metapapackage which would install all frameworks -dev packages
[15:51] <santa_> we could also do -tier1-dev and so on
[15:51] <santa_> and a -dbg to install all the -dbg's
[16:08] <Riddell> apachelogger: how do I make tarme use a git branch?
[16:08] <Riddell> it complains at this ./tarme.rb --origin trunk --version $VERSION --gitbranch=frameworks kfilemetadata
[16:20] <ScottK> shadeslayer: There's a ktp-contact-list SRU for trusty still waiting for verification.
[16:20] <shadeslayer> /o\
[16:20] <ScottK> Please fix that.
[16:21] <shadeslayer> put on my todo for tomorrow
[16:25] <ScottK> I guess any lingering feeling bad I might have about not using LP is resolved.  Canonical is moving away from it too: http://www.jorgecastro.org/2014/06/04/juju-is-now-on-github/
[16:26] <Riddell> gosh
[16:27] <shadeslayer> fun seeing how LP got inline diff comments recently
[16:27] <Riddell> I doubt that's the sole reason for its lack of popularity outside ubuntu
[16:30] <ScottK> I did recently submit a change to a project on github.  The ability to edit the file, make a commit in my own branch, and generate a pull request all in my web browser was pretty awesome.
[16:32] <shadeslayer> yep
[16:32] <shadeslayer> git lab is it's open source alternative
[17:06] <ovidiu-florin> I'd like to make a proposition to change the default power setings
[17:06] <ovidiu-florin> can I ?
[17:08] <ScottK> You can.
[17:10] <ovidiu-florin> unfourtanetly I do't have a kubuntu box in front of me right now, so I'll do my best
[17:11] <ovidiu-florin> It's super annoying on a fresh install when the monitor shuts down when you're watching a movie
[17:11] <ovidiu-florin> or reading something (really slow)
[17:12] <ovidiu-florin> I can't remember if this is the screen locker or powe settings
[17:12] <ovidiu-florin> we should disable that (especially if it's a desktop, not a laptop)
[17:13] <ovidiu-florin> many new kubuntu users have reported this to me
[17:14] <ovidiu-florin> any feedback?
[17:15] <ovidiu-florin> should I send this to the mail list?
[17:15] <ovidiu-florin> along with some ideeas on how to fix this?
[17:22] <shadeslayer> ovidiu-florin: report upstream
[17:23] <shadeslayer> because this is not something kubuntu specific
[17:23] <shadeslayer> also, I'm out, cya tomorrow
[17:55] <soee> plasma next is in experimetnal ? but not usable yet ?
[19:39] <Riddell> soee: now in the new kubuntu-ppa/next PPA
[19:42] <soee> Riddell: this one is for plasma-next related stuff ?
[19:42] <soee> or basically all the KF5, pasma etc?
[19:43] <soee> also is it ready to install on trusty and does it replace current one ?
[21:22] <soee> ping :) someone can tell something about plasma-next ?
[21:30] <Riddell> soee: it's not ready to install no
[21:30] <Riddell> and it does replace plasma 1
[21:32] <soee> oh ok :) when can we expect installable version ?
[21:50] <Riddell> setting times is a fools errand, it'll be done when it's done
[21:50] <Riddell> I hope for next week
[22:43] <soee> thank you