[06:21] <soee> good morning
[08:05] <yofel> apachelogger: considering you merged frameworkintegration, do you plan to rename kf5-kio into kio as well?
[08:10] <ovidiu-florin> How can I rename the Guest user?
[08:11] <apachelogger> yofel: most likely
[08:11] <apachelogger> I doubt anyone cares
[08:11] <yofel> apachelogger: seems so (see #dqk)
[08:13] <apachelogger> right then, renaming it is
[08:13] <apachelogger> I actually was writing a script to get a list of all upstream frameworks before I got interrupted by everyone at the same time :P
[08:13] <Riddell> ovidiu-florin: you can't, it's not a real user?
[08:13] <Riddell> apachelogger: any way to specify a branch in tarme?
[08:14] <apachelogger> you are asking the third time now
[08:14] <apachelogger> no you can't
[08:14] <Riddell> you haven't answered :)
[08:14] <apachelogger> you can specify an origin
[08:14] <Riddell> aww
[08:14] <Riddell> isn't that just for translations?
[08:14] <apachelogger> translations always map to one exact branch
[08:15] <apachelogger> so by defining the translation origin you implicitly also define which branch must be used for the source
[08:18] <Riddell> ./tarme.rb --origin frameworks --version 4.97.0 kfilemetadata
[08:18] <Riddell> ./tarme.rb:25:in `<main>': invalid argument: --origin frameworks (OptionParser::InvalidArgument)
[08:18] <Riddell> it no likey
[08:18] <ovidiu-florin> Riddell: I just want to change the name it shows on the login prompt
[08:19] <ovidiu-florin> Guest is not descriptive enough for kids in the school I put Kubuntu in
[08:19] <apachelogger> Riddell: trunk or stable
[08:19] <ovidiu-florin> I want to change it to Elev
[08:19] <apachelogger> always trunk or stable
[08:19] <apachelogger> there is no origin other than trunk or stable :P
[08:23] <apachelogger> my comput0r is too slow for bzr
[08:24] <ovidiu-florin> Riddell: any solutions, pleasE?
[08:26] <Riddell> ovidiu-florin: isn't it translated?
[08:26] <ovidiu-florin> in 13.10 it isn't
[08:26] <ovidiu-florin> I haven't upgraded yet
[08:27] <Riddell> it won't have changed
[08:27] <Riddell> d_ed will probably know
[08:28] <Riddell> or robert ancell
[08:28] <ovidiu-florin> is there a meta package for all KDE games?
[08:29] <yofel> there is kdegames
[08:30] <ovidiu-florin> thank you
[08:30] <apachelogger> the guest string might actually be from accountservice FWIW
[08:39] <Riddell> apachelogger: ah, I think what you mean to say is "jonathan, set the trunk branch in projects.kde.org and wait 10 minutes for it to propagate"
[08:40] <apachelogger> Riddell: possibly
[08:40] <Riddell> now, I wonder if there's a way to magically rename the tar
[08:44] <apachelogger> there isn't
[08:44] <apachelogger> Riddell: why would you?
[08:44] <ovidiu-florin> Riddell: rm -rf *.tar
[08:44] <ovidiu-florin> oh wait
[08:44] <Riddell> apachelogger: because e.g. baloo needs to be baloo-kf5 or something
[08:44] <ovidiu-florin> that't not rename
[08:44] <apachelogger> Riddell: what, why?
[08:44] <ovidiu-florin> oups :P
[08:45] <Riddell> apachelogger: else distros will have to rename it, and better to do it upstream
[08:45] <d_ed> Riddell: I'm pinged in something?
[08:45] <apachelogger> Riddell: nope, that indeed best had been done on a distro level
[08:46] <Riddell> d_ed: ovidiu-florin here asks if the Guest user can be renamed or translated in lightdm
[08:46] <Riddell> apachelogger: why do you think that is?
[08:46] <apachelogger> they only need renaming because shitty distro tools cannot deal with the same source having two different versions
[08:46] <d_ed> it /should/ be able to
[08:46] <apachelogger> that is to say with rpm I think you don't even need to rename the source at all for example
[08:46] <d_ed> it comes from KDE code
[08:46] <d_ed> which goes via i18n
[08:46] <ovidiu-florin> d_ed: how?
[08:47] <apachelogger> d_ed: a grep did not yield useful results on Guest
[08:48] <d_ed>         QStandardItem *guest = new QStandardItem(i18n("Guest"));
[08:48] <d_ed> in lib
[08:48] <apachelogger> ah, in lib
[08:49] <d_ed> it's probably not covered by a Messages.sh or something equally rubbish
[08:49] <ovidiu-florin> d_ed: So there's no whay I can change that to "Student" or something like that without recompiling?
[08:49] <d_ed> sorry, no.
[08:49] <ovidiu-florin> bummer
[08:49] <apachelogger> well
[08:50] <apachelogger> if it is translated you could simply change the translation 6^
[08:50] <apachelogger> ^^
[08:51] <ovidiu-florin> can I do that without changing the official translation?
[08:54] <ovidiu-florin> is that a spupid question? since no one is answering, i can assume so..
[08:55] <yofel> more tricky than stupid I think, as my answer would be no
[08:56] <yofel> but I'm not a l10n expert
[08:56] <ovidiu-florin> i guess the translations are stored as po files
[08:56] <ovidiu-florin> so I should be able to change the text in one
[08:56] <ovidiu-florin> to get it overritten on update
[08:57] <yofel> po yes, but compiled to mo which is what you would have to replace
[08:57] <ovidiu-florin> oh
[08:57] <yofel> see gettext docs
[08:57] <ovidiu-florin> so, the answer is no
[08:58] <yofel> maybe a PPA package that's adjusted would be an option
[09:02] <yofel> shadeslayer: what happened to you uploading 4.13.1?
[09:04] <yofel> apachelogger: regarding E: libkf5wallet5: arch-dependent-file-not-in-arch-specific-directory usr/bin/kwalletd5
[09:04] <yofel> put into 'kwallet' (which doesn't exist yet), or kwalletd5 ?
[09:05] <apachelogger> yofel: libkf5kwallet-bin
[09:05] <yofel> or kwalletd
[09:05] <yofel> hm, ok
[09:05] <apachelogger> although
[09:05] <yofel> it's a single binary... so I didn't really want to add lib
[09:05] <apachelogger> hm?
[09:05] <apachelogger> it's a runtime support binary for the lib
[09:06] <apachelogger> on its own I doubt kwalletd will have much use
[09:06] <apachelogger> you could ask teo in kde-devel though
[09:06] <yofel> ah nevermind, it has a bunch of support stuff too
[09:06] <yofel> so -bin it is
[09:07] <yofel> apachelogger: pre-depends was nonsense, right?
[09:07] <apachelogger> yofel: we at least did not find out what it was good for
[09:08] <apachelogger> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/kf5umbrella/".
[09:08] <apachelogger> Riddell: ^ that's why upstream we shouldn't randomly rename things
[09:09] <yofel> "To ensure that a multiarch-compatible libc is configured before your shared library package is unpacked to the new multiarch library paths (and the old version of the library deleted from /usr/lib), each shared library must declare a Pre-Depends on the multiarch-support package."
[09:09] <yofel> But that seems to be from the old times
[09:11] <yofel> apachelogger: it does actually get substituted to Pre-Depends: multiarch-support
[09:12] <ovidiu-florin> how does the guest session work?
[09:12] <ovidiu-florin> how does it start?
[09:12] <ovidiu-florin> it creates a new user with a tmp home dir?
[09:12] <Riddell> /usr/lib/lightdm/guest-session-auto.sh may help
[09:12] <ovidiu-florin> where does it copy the settings from?
[09:12] <Riddell> also /usr/lib/lightdm/lightdm-guest-session
[09:12] <ovidiu-florin> ok
[09:13] <Riddell> and /usr/sbin/guest-account
[09:13] <apachelogger> yofel: I am not sure that is still necessary
[09:13] <Riddell> ovidiu-florin: same as any new user I expect
[09:13] <Riddell> ovidiu-florin: yes it makes a new user with a tmp home dir
[09:13] <yofel> apachelogger: I'll ask debian if they need it
[09:13] <ovidiu-florin> Riddell: that file does not exist on 13.10
[09:15] <ovidiu-florin> are there any logs for when a guest session failes?
[09:19] <yofel> apachelogger: 
[09:19] <yofel> [11:16:46] <ansgar> yofel: That was only for squeeze -> wheezy upgrades.
[09:19] <yofel> [11:18:51] <ansgar> yofel: It's not needed any longer.
[09:19] <yofel> so as we won't backport << trusty we won't need it either
[09:20] <apachelogger> groovy
[09:23] <Riddell> ovidiu-florin: /var/log/lightdm/ maybe?
[09:23] <yofel> hm, libkf5kwallet5 is definitely not section:libdevel
[09:29] <shadeslayer> yofel: I did
[09:29] <shadeslayer> probably in the queue
[09:29] <yofel> ah yeah, probably
[09:30] <yofel> apachelogger: libkf5wallet-bin would be Multi-Arch: none? (or just skip the field?)
[09:30] <apachelogger> yofel: skip == none
[09:30] <apachelogger> yofel: and lib recommends bin
[09:31] <yofel> ack
[09:34] <yofel> apachelogger: on the topic of naming, is it intentional that we're using kactivities and not libkf5activites-bin ?
[09:34] <apachelogger> I have no clue
[09:34] <yofel> consistency-- -.-
[09:34] <apachelogger> mind you kactivities is special because upstream says the runtime bits are interchangable
[09:35] <apachelogger> i.e. you can use kde4 runtime or kf5 runtime, doesn't matter to the lib
[09:35] <yofel> well, the kde4 runtime is in libkactivities-bin :S
[09:35] <apachelogger> then something is astray I'd say
[09:35] <apachelogger> but yeah, I'm doing a whole review of frameworks later
[09:35] <apachelogger> also structural alignment and whatnot
[09:35] <yofel> ok
[09:36] <apachelogger> possibly also trying to get substvars going for descriptions
[09:36] <Riddell> not quite interchangeable, kf5 kactivities needed for kf5 land
[09:36] <Riddell> but should be backwards compatible
[09:37] <yofel> so you're supposed to be able to run kde4 with kf5 activities o.O?
[09:37] <Riddell> yes I believe so
[09:37] <yofel> fun
[09:42] <apachelogger> Riddell, santa_: did you run the kdelibs4support patch by upstream?
[09:42] <apachelogger> also, it doesn't have dep3
[09:43] <yofel> which reminds me I never voted on policy :(
[09:43] <shadeslayer> boo
[09:43] <yofel> I'll do that after lunch
[09:43] <yofel> +1 anyway
[09:44] <Riddell> apachelogger: he promised to do so
[09:44] <apachelogger> Riddell: did you read what I wrote about backlog yesterday
[09:44] <apachelogger> also
[09:44] <apachelogger> the patch is not documented in the changelog in any way
[09:45] <Riddell> nope, what did you write about backlog?
[09:45] <apachelogger> that there's a bug
[09:45] <apachelogger> a bug that has been fixed 20 hours ago mind you
[09:48] <santa_> apachelogger: not yet, but will submit the pacth today to reviewboard and add the headers
[09:49] <apachelogger> [11:45] <apachelogger> a bug that has been fixed 20 hours ago mind you
[09:49] <apachelogger> you first talk to upstream and then you do things.
[09:51] <apachelogger> yofel: is list-missing our code?
[09:51] <yofel> apachelogger: in the build logs? It's a patch to pkg-kde-tools I believe so it's script-parsable
[09:52] <shadeslayer> http://people.canonical.com/~ubuntu-archive/phased-updates.html
[09:52] <apachelogger> yofel: just wondering why we don't make it detect manpages properly ^^
[09:52] <shadeslayer> quite fancy that stuff
[09:52] <yofel> shadeslayer: only implemented in update-manager I believe?
[09:53] <shadeslayer> :(
[09:53] <yofel> the issue listing is cool though
[09:53] <shadeslayer> https://errors.ubuntu.com/problem/2bb11f5013b5638956cbb06a6f822d811fde60a4 < known issue
[09:54] <shadeslayer> https://errors.ubuntu.com/problem/d43591a91bd75c89b52b372618f42d0cabdc7e94 dupe
[09:54] <shadeslayer> https://errors.ubuntu.com/problem/e0d7f4fb342e721238de3d5cc79148ab67ba3fe2 dupe
[09:54] <shadeslayer> https://errors.ubuntu.com/problem/1a794f4f0b1fa61aa9916353ae643de6085125fc dupe
[09:54]  * apachelogger wonders how one makes kate open */debian/* without thorwing a bazillion errors on directories
[09:54] <yofel> apachelogger: generally list-missing is part of dh_install though, extended by pkg-kde-tools to support not-installed and run by us during build time for parsing
[09:55] <apachelogger> well yeah
[09:55] <apachelogger> but if we can estend through not-installed we could just as well check manpages I guess
[09:55] <yofel> what's actually wrong with the manpage check?
[09:55] <apachelogger> supposedly dh_install should get its act together though
[09:56] <apachelogger> yofel: manpages get compressed by dh_manthing
[09:56] <apachelogger> so they always yield false positives
[09:56] <yofel> oh right, it did complain about that
[09:56] <yofel> it's the same for movelibkdeinit
[09:57] <Riddell> movelibkdeinit neeeds posted to kf5
[09:57] <Riddell> movelibkdeinit neeeds ported to kf5
[09:58] <apachelogger> what's that do?
[09:59] <yofel> moves libkdeinit4_* to /usr/lib/kde4/libkdeinit/
[09:59] <apachelogger> why don't we do that upstream?
[09:59] <yofel> uh, no idea? That was done before my time...
[10:00] <apachelogger> why don't we do that upstream for kf5
[10:00] <yofel> no idea, should be done really
[10:00] <apachelogger> Riddell: release dude we haz feature request :P ^
[10:01]  * yofel -> lunch
[10:10] <apachelogger> yofel: I hope you are already done with kwallet
[10:10]  * apachelogger is breaking all the frameworks
[10:13]  * apachelogger will need to write a control parser at some point
[10:14] <santa_> apachelogger: the inclusion of that patch is documented in the changelog
[10:14] <apachelogger> not what it does
[10:15] <Riddell> apachelogger: needs working out what else dh_movelibkdeinit does then working out if it can be done in cmake or elsewhere
[10:16] <santa_> apachelogger: yes, it does, it's listed as a change below "build against network-manager"
[10:16] <apachelogger> it does not explain what the patch does
[10:16] <santa_> meanin it's needed to build against network-manager
[10:17] <apachelogger> it does not explain what the patch does
[10:17] <santa_> making you able to build against network-manager?
[10:17] <santa_> but if it's not clear enough, feel free to re-word it
[10:23] <Riddell> apachelogger: merge for you https://code.launchpad.net/~panfaust/kubuntu-packaging-next/kdelibs4support-work/+merge/222154
[10:25] <Riddell> tsdgeos: does setting the master branch for baloo and milou and kfilemetadata to frameworks in projects.kde.org screw up 4.14 alpha/beta releases?
[10:25] <tsdgeos> Riddell: busy, please send me an email or reask when not working
[10:31] <BluesKaj> 'Morning
[10:33] <yofel> apachelogger: what exactly are you doing to our poor frameworks o.O?
[10:42] <apachelogger> yofel: everything
[10:42] <yofel> :O
[10:42] <apachelogger> http://paste.ubuntu.com/7593964/
[10:43] <yofel> fun
[10:43] <apachelogger> I am actually thinking about splitting short and long description such that you can append stuff to the shortsies
[10:43] <apachelogger> - development files
[10:44] <apachelogger> otherwise the short description is the same for all packages of the framework which is a tad rubbish
[10:45] <Riddell> apachelogger: waa, tarme doesn't save the release_data file if you run it multiple times :(
[10:46] <apachelogger> yeah
[10:46] <apachelogger> Riddell: suggestions?
[10:47] <apachelogger> or for that matter... why do you run it multiple times and expect the data to be there?
[10:48] <Riddell> apachelogger: append rather than overwrite
[10:49] <apachelogger> Riddell: but why
[10:50] <Riddell> because I need to make multiple tars then e-mail the release list with the list of hashes
[10:51] <apachelogger> Riddell: tarme.rb -v 1.0 --origin trunk kde/workspace/ rolls aaaaaallllll tars at the same time
[10:52] <yofel> apachelogger: btw. I asked you yesterday whether kubotu has flood control for the commit messages enabled (if it has to process like 200 commits). Is there something?
[10:52] <apachelogger> no
[10:52] <apachelogger> yes
[10:52] <apachelogger> it posts 13 lines at the most
[10:52] <yofel> ok
[10:52] <yofel> enough for me
[10:52] <apachelogger> that is 12 commits and one for the fact that there is more than 12 commits
[10:53] <apachelogger> might reduce it to 8, but since I haven't seen a 12 line block yet I can't say whether that ends up too much
[10:53] <yofel> I think it's fine, most I've seen was 10 so far which is rare
[10:55] <apachelogger> I find the package control sorting really annoying what with -dev being first becuase they don't have the soversion suffix -.-
[10:56] <Riddell> apachelogger: mm, interesting
[10:56] <yofel> that's how we always did it.. and why do you need the soversion o.O?
[10:57] <apachelogger> yofel: noooo, we always had lib first, dev second, dbg last
[10:57] <yofel> my memory is buggy then
[10:57] <apachelogger> Riddell: pft, I made that feature specifically for you so you don't have to run releaseme 300 times and then have forgotten about one tarball :P
[10:58] <apachelogger> yofel: well, last I really packaged something was like 4 years ago, so who knows :P
[10:58] <Riddell> apachelogger: features are no use unless someone knows about them :)
[10:58] <apachelogger> after a while the kde4 controls wer a bit of a mess anyway, but I really think libs generally came before the dev package
[10:58] <apachelogger> Riddell: I did tell you about that :P
[10:58] <apachelogger> like twice at the very least
[10:59] <apachelogger> http://paste.ubuntu.com/7594059/
[10:59] <apachelogger> short and long description split
[10:59] <apachelogger> and I really think I need a control parser, because I also think Architecture should be listed first in the package stanzas
[11:00] <apachelogger> in particular section should not be first becuase it's rubbish and no one cares about it anyway ^^
[11:00] <yofel> section should be there, end. Architecture usually comes next, but that's not defined anywhere, just how we usually do it
[11:01] <yofel> after that I don't think we really have a pattern what comes next, IIRC usually it's Pre-Depends, Depends, Recommends, Suggests, Breaks, Replaces, Conflicts
[11:01] <yofel> Provides
[11:01] <apachelogger> yofel: section is optional
[11:01] <apachelogger> architecture is not
[11:02] <apachelogger> so really the order should be arch>multiarch>section>priority>depends>breaks>conflicts>replaces>description IMO
[11:02] <yofel> I know it's optional, but I've always seen section coming before architecture
[11:03]  * yofel looks at policy
[11:03] <apachelogger> it doesn't even come first in the policy, becuase the policy also knows that the mandatory architecture fields is more important :P
[11:04] <yofel> well, by that logic description should come after architecture, but you're right, section comes after arch
[11:05] <apachelogger> nope
[11:05] <apachelogger> description is a multiline field
[11:05] <yofel> and breaks-conflicts-provides-replaces
[11:07] <yofel> yeah, but homepage, built-using and package-type coming after that sounds a bit weird then - even if it's like that in DEBIAN/control
[11:07] <apachelogger> yofel: coming after what?
[11:07] <yofel> description
[11:08] <yofel> I guess I'll agree though that the order should at least follow policy
[11:08] <apachelogger> those are autogenerated for the binary anyway
[11:08] <apachelogger> but even when not descripition would be last
[11:09] <yofel> we never use those so that's a moot point anyway
[11:09] <yofel> looking at kde4libs you're right that libs come before dev though :/
[11:10] <yofel> apachelogger: in any case, please at least tell debian about the field reordering in case they're against it
[11:10] <apachelogger> I am not even sure I'll bother TBH
[11:11] <yofel> shadeslayer: are you adding back libs to kdepim o.O?
[11:11] <apachelogger> if I write a control parser or get down and dirty with perl I'd just do mass changes to fields through that
[11:11] <apachelogger> then I'll never have to look at the fugly control files anyway
[11:11] <shadeslayer> yofel: yes, for utopic
[11:11] <yofel> why?
[11:12] <yofel> it's not like they're coming back...
[11:12] <shadeslayer> for a .1 release it's bad to remove them?
[11:12] <shadeslayer> we can nuke them in the beta release
[11:12] <yofel> well, that was for the SRU, but whatever
[11:12] <shadeslayer> SRU?
[11:12] <shadeslayer> ah
[11:13] <apachelogger> what does it matter whether the release is .1 or not for utopic?
[11:13] <shadeslayer> the reverts were for the SRU
[11:14] <yofel> apachelogger: well, I did write a very basic control file editor in perl for neon once as overriding some fields at build time in rules didn't go so well
[11:14] <yofel> it was fun
[11:14] <yofel> was for the apport stuff IIRC
[11:14] <apachelogger> perl is a really dumb ruby, that's all
[11:15]  * yofel should read learnrubythehardway once
[11:15] <shadeslayer> ^^
[11:15] <shadeslayer> I'm currently reading learncthehardway 
[11:15] <shadeslayer> neat stuff
[11:15] <yofel> I used perl because ruby isn't part of the default system :P
[11:17] <shadeslayer> yofel: since Riddell uploaded some 4.13.1 stuff, how do you want to handle 4.13.1 for utopic
[11:17] <yofel> shadeslayer: for the 2 packages I did yesterday I just uploaded .1
[11:18] <shadeslayer> ok
[11:18] <shadeslayer> so just upload then?
[11:18] <shadeslayer> *upload 4.13.1
[11:19] <yofel> yeah
[11:19] <yofel> apachelogger: that thing is still there actually ^^ http://bazaar.launchpad.net/~neon/project-neon5/project-neon5-runtime/view/head:/opt/project-neon5/share/pkg-project-neon5/scripts/get_control_field.pl
[11:22] <apachelogger> you could just have used the existing perl modules you know :P
[11:22] <yofel> they were confusing me even more so I was frustrated enough to write it from scratch..
[11:23] <apachelogger> yeah, perl does that
[11:23] <apachelogger> but the dpkg modules are actually reasonably well documented from what I have seen
[11:37] <apachelogger> dch -.-
[11:53] <apachelogger> Riddell: how does one check whether a bzr branch has uncommited changed through the $?
[11:58] <apachelogger> well that only caused a bunch of bogus commits -.-
[11:58] <yofel> bzr diff?
[11:59] <Riddell> as yofel says
[12:00] <apachelogger> strangely enough it returned 0 in both cases earlier
[12:02] <yofel> well, parse output wrt. not/empty then
[12:04] <apachelogger> much terrible
[12:05] <yofel> apachelogger: what exactly are you trying to do?
[12:05] <apachelogger> check whether a working tree is dirty
[12:05] <yofel> you can just go and commit, empty commits will give exit 3 from commit
[12:06] <apachelogger> yofel: except they'd be dirty if I simply dch 
[12:06] <yofel> why would you not want to commit dchß
[12:06] <yofel> ?
[12:06] <apachelogger> yofel: dch -a -m yolo && debcommit
[12:07] <apachelogger> which is conditional to initial dirtyness
[12:08] <yofel> why is it conditional?
[12:08] <sgclark> Riddell: good morning, anything for me to work on?
[12:08] <apachelogger> http://paste.ubuntu.com/7594397/
[12:09] <apachelogger> yofel: because dch would make it dirty
[12:09] <BluesKaj> whynot dirtynessful :)
[12:09] <yofel> apachelogger: are you trying to auto-generate changelogs from actual changes o.O?
[12:09] <apachelogger> well yes
[12:10] <yofel> ah, interesting
[12:10] <apachelogger> I did a sed on all 3 million branches
[12:10] <apachelogger> but the change only applies to 2 of the 3 million
[12:10] <apachelogger> so one needs a way to check which were actually changed and then dch && commit those
[12:10] <apachelogger> the other ones ought to be left alone
[12:11] <yofel> hm, if I run bzr diff on a branch with changes I get exit 1
[12:11] <yofel> which matches the 'diff' behaviour
[12:11]  * yofel wonders why he always writes that in en_GB
[12:12] <yofel> I blame school
[12:12] <apachelogger> yofel: yes, except when I tired that it still was 0
[12:12] <BluesKaj> it's proper english, not the 'merican english
[12:12] <apachelogger> alas, now it is 1 when I try it
[12:12] <apachelogger> eitherway
[12:12] <apachelogger> diff is nasty
[12:13] <yofel> well, parsing of $? is rather error prone
[12:13] <apachelogger> yeah, for if you use it on bzr diff :P
[12:13] <apachelogger> which is why I was asking for a proper way
[12:13] <yofel> I show the exit status in my prompt and even that has $? caching in PS1
[12:14] <kubotu> feed branches-next had 25 updates, showing the latest 16
[12:14] <yofel> ah, flood limit is 16 ^^
[12:14] <Riddell> sgclark: here's a first short of tars, you can see if they compile, install translations, do other sane things http://starsky.19inch.net/~jr/tmp/plasma-4.97.0/
[12:14] <Riddell> sgclark: I'll be remaking the tars because the version numbers are not updated there
[12:15] <sgclark> Riddell: on it, thank  you
[12:15] <apachelogger> kubotu: config set rss.announce_max 8
[12:15] <kubotu> sure
[12:15] <Riddell> sgclark: so just for checking for problems for now
[12:15] <apachelogger> yofel: 8 seems to be the golden spot really
[12:15] <sgclark> Riddell: ok
[12:15] <yofel> apachelogger: fine with me, IRC throttling does make 16 a bit long
[12:15] <apachelogger> yeah
[12:16] <apachelogger> if it spammed all within a second it would almost be fine, but even so, too big a wall of text 
[12:19] <Riddell> sgclark: oh actually you probably can't compile much because it needs qt 5.3
[12:19] <sgclark> Riddell: oh, is that available?
[12:19] <Riddell> so one could ask if we should move next development to utopic which has at least some qt 5.3 packages
[12:20] <Riddell> sgclark: yep, in https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2  but for utopic
[12:20] <Riddell> apachelogger, yofel, sgclark: should we move next development to utopic?
[12:21] <sgclark> Riddell: I think we should
[12:21] <Riddell> sgclark: than I guess you can dist-upgrade and tell us if it's safe :)
[12:22] <yofel> if plasma needs 5.3, sure.
[12:22] <yofel> I'm not upgrading to utopic though until the whole init mess is kind of sorted out
[12:22] <sgclark> Riddell: lol sure
[12:23] <apachelogger> Riddell: ENOPOINT until alpha2 if you ask me
[12:23] <Riddell> apachelogger: how else would we do development?
[12:24] <apachelogger> trusty, we are only doing userspace anyway, if something breaks from trusty to utopic that would strike me as odd :P
[12:24] <apachelogger> my point is... until most of us are using utopic there is 0 point in developing on utopic
[12:24] <apachelogger> or well, some at least :P
[12:25] <sgclark> but the missing qt 5.3 is the problem
[12:25] <apachelogger> earlierst point would be when qt 5.3 lands
[12:25] <apachelogger> sgclark: is that landed yet in utopic?
[12:25] <Riddell> it's in a PPA
[12:25] <yofel> apachelogger: it's in PPA
[12:25] <sgclark> ^
[12:25] <apachelogger> yeah, so no point :P
[12:25] <Riddell> the point is to have qt 5.3 packages available
[12:26] <yofel> apachelogger: so you want to not work on it until 5.3 is in o.O?
[12:26] <yofel> why?
[12:26] <apachelogger> Riddell: take them and build for trusty?
[12:26] <apachelogger> yofel: what's the point if they are in a ppa anyway
[12:26] <yofel> apachelogger: what's the point of backporting 5.3?
[12:26] <yofel> (that's rather heavy)
[12:26] <apachelogger> just as much work as ppa porting
[12:26] <apachelogger> well I don't care
[12:27] <apachelogger> if you feel that you need utopic, use utopic
[12:27] <apachelogger> I find it very pointless
[12:27] <yofel> as I understand it it would be a no-change rebuild to use the archive 5.3 packages, if anything
[12:28] <yofel> apachelogger: point is to continue working on plasma without much extra work
[12:28] <yofel> and backporting 5.3 is work
[12:29] <yofel> apachelogger: if anything we can wait on you to finish rewriting the kf5 packages
[12:32] <apachelogger> well that would be rather handy :P
[12:37] <apachelogger> god this is a mess
[12:37] <apachelogger> libkf5auth5-dbg vs. libkf5auth-dbg vs. kauth-dbg
[12:38] <yofel> middle
[12:38] <yofel> or hm
[12:38] <apachelogger> exactly :P
[12:39] <yofel> I think debug stuff is SOVERSION coinstallable, so first usually, second if a -bin package exists, third if a kauth package exists
[12:39] <yofel> total mess
[12:40] <apachelogger> looking through the archive middle certainly appears the most
[12:40] <Riddell> debian-kde gave both answers when I asked them
[12:40] <Riddell> some preferred foo5-dbg and some didn't care
[12:40] <Riddell> so I went with foo5-dbg
[12:41] <apachelogger> utterly random
[12:43] <yofel> well, debug coinstallability is probably nonsense, or can by done with dbgsym, so first is junk, so it would be middle if only one lib is there, and last if multiple?
[12:43] <apachelogger> when will debian get dbgsym so we can do away with those shitty dbg packages
[12:43] <apachelogger> it's an outrage
[12:43] <sgclark> it shouldn't be, they should be foo5-dbg. Now I was new at the beginning and perhaps some old builds were missing 5 but should be removed
[12:44] <apachelogger> yofel: debugs are always coinstallable as the symbol file name is the uuid of the build artifact
[12:44] <apachelogger> there is no actual tie to soversion or anything in terms of debug symbol
[12:44] <yofel> well, not if the packages have the same name
[12:45] <apachelogger> yeah
[12:45] <yofel> i.e. libfoo5-dbg <-> libfoo6-dbg versus 2xlibfoo-dbg
[12:45] <apachelogger> hence the so is supreme
[12:45] <apachelogger> but what about packages like kio
[12:45] <apachelogger> and wouldn't kio-dbg render the entire notifion of having coinstallable dbg completely pointless anyway
[12:45] <yofel> it would
[12:46] <yofel> which is why I said that it's junk
[12:46]  * apachelogger declares manual dbg packages the biggest piece of bullshit ever invented
[12:46] <yofel> you need dbgsym for that
[12:46] <yofel> I would prefer dbgsym, if only they were properly compressed -.-
[12:48] <apachelogger> why is sonnet split into 2 lib packages and 1 plugins package?
[12:49] <apachelogger> shadeslayer: ^
[12:49] <apachelogger> some of these packages seem drunk
[12:50] <yofel> looks sane to me
[12:50] <apachelogger> upstream makes one tarball, not 3
[12:50] <yofel> libs have to be by themselves, everything else is in sonnet-plugins
[12:51] <apachelogger> no they don't have to be
[12:51] <apachelogger> stop making the weird lib splitting nonesense up to be policy 
[12:51] <apachelogger> it aint
[12:51] <yofel> stop meshing stuff into packages that don't belong together
[12:51] <apachelogger> solid-bins vs. libkf5solid-bin vs. libkf5solid5-bin
[12:52] <apachelogger> yofel: upstream makes one tarball, not 3
[12:52] <yofel> middle is what we decided on, didn't we?
[12:52] <apachelogger> there is absolutely no reason why sonnetcore and sonnetui couldn't be in the same package
[12:52] <apachelogger> they are both multiarched and their soversion is actually linked together in the build system
[12:52] <yofel> apachelogger: ok, so bring back kdelibs5 which has all libs in it
[12:52] <apachelogger> yofel: upstream makes one tarball, not 3
[12:53] <yofel> debian package library naming requires the package to match the lib name in it, more than one lib in a lib package is an error
[12:54] <apachelogger> where does it say that in the policy?
[12:54] <sgclark> lintian tells you everytime
[12:54] <apachelogger> where does it say that in the policy?
[12:54] <yofel> apachelogger: there's even a lintian warning for that http://lintian.debian.org/tags/package-name-doesnt-match-sonames.html
[12:54] <apachelogger> where does it say that in the policy?
[12:55] <yofel> if it doesn't then that's a bug in the policy
[12:55] <yofel> not in our packaging
[12:55] <apachelogger> aha
[12:55] <apachelogger> so we must have one package per library because debian packaging mandates that
[12:56] <apachelogger> and if debian packaging doesn't mandate it then it should because...?
[12:56] <santa_> it's good to have just the library in the package library
[12:56] <apachelogger> the point of naming a package after the library is that you can install two versions at the same time
[12:57] <yofel> Not sure, the original reason might have been to prevent disk space waste
[12:57] <yofel> as libs are supposed to be installed on demand, not when the developer thinks it makes sense to have libfoo or libbar installed
[12:59] <santa_> having plugins in the lib package usually adds additional symbols (which shouldn't be there) to the symbols files, making it harder to maintain
[13:00] <santa_> also it would make easiear to deal with a possible abi break
[13:00] <yofel> santa_: we're not talking about plugins, but /usr/lib/x86_64-linux-gnu/libfoo.so.5 and /usr/lib/x86_64-linux-gnu/libbar.so.5 from the same source being in the same package
[13:00] <yofel> though I'll agree that this would most likely break the debian abi manager as well
[13:00] <apachelogger> pkg-kde invention
[13:00] <yofel> as that does package name <-> cmake rule matching
[13:00] <santa_> yofel: second thing I said still applies
[13:01] <yofel> santa_: as I admitted with my point about the abi manager
[13:01] <apachelogger> abi break should be dealt with upstream
[13:01] <santa_> yofel: k
[13:01] <yofel> apachelogger: it's a freakin' bloody workaround for stupid or ignorant upstreams
[13:01] <yofel> make that ignorant
[13:02] <apachelogger> don't package their software then?
[13:02] <yofel> don't package kde-workspace?
[13:02] <santa_> no, sometimes upstream says they don't intend to keep bc
[13:02] <santa_> so it has to be done in the packaging
[13:02] <apachelogger> yofel: if you have a problem with the upstream don't package the software?
[13:02] <apachelogger> binary bumpery is half way forking it anyway, might as well go and fork it entirely
[13:03] <apachelogger> santa_: right, so you are to fork upstream
[13:03] <yofel> apachelogger: I would very much like to package it in the contstraints that our policy put on it, if upstream derives from that we have a problem
[13:03] <santa_> no, just bumping the soname when it's needed
[13:04] <santa_> apachelogger: ↑
[13:04] <apachelogger> yofel: the made up constraint about lib packages being based on the soname or the real constraint of not having a constraint on library naming and/or bc?
[13:04] <apachelogger> santa_: yeah, so you fork it
[13:04] <yofel> well my point was about  BC really
[13:05] <apachelogger> yofel: we also have no policy on that
[13:05] <apachelogger> that is also made up
[13:05] <yofel> we have a policy that BIC changes must cause a SONAME change
[13:05] <yofel> out of pure practicability
[13:05] <santa_> apachelogger: call it the way you like, it's the right thing to do
[13:06] <yofel> we don't have a policy that SONAME must not change, after all we're doing that all the time
[13:06] <santa_> and if not that, rename the package and rebuild everything depending on it
[13:06] <apachelogger> santa_: says who?
[13:07] <apachelogger> yofel: where's that policy?
[13:07] <santa_> apachelogger: says the common sense, if you have an abi break you must deal with it in the packaging
[13:07] <apachelogger> sooooo
[13:07] <yofel> apachelogger: why does that need a policy? An application breaking because of BIC in a lib is ok by policy?
[13:08] <apachelogger> if it s common sense then I guess everyone will want to do it, so 300 distros will do an abi bump manually on their own
[13:08] <apachelogger> so back to my point, it should be done upstream
[13:08] <yofel> ok, please fix all our X-Debian-ABI > 0 issues upstream
[13:09] <yofel> I usually get yelled at when I try 
[13:09] <apachelogger> what issues were those?
[13:09] <ovidiu-florin> How can I change the default settings for the Guest user?
[13:09] <yofel> last was a BIC in libtaskmanager IIRC, which is obviously KDE-public-but-in-fact-private-ABI
[13:10] <ovidiu-florin> I've tried adding my changes to /usr/share/kde4/config
[13:10] <ovidiu-florin> but they don't take effect
[13:10] <apachelogger> yofel: private, I wonder why we package that publicly
[13:11] <yofel> apachelogger: IIRC it has to be public to be usable in kdeplasma-addons and some third party task managers
[13:11] <yofel> (if any of those still exist)
[13:11] <apachelogger> well it's not private if we allow third parties to use it
[13:11] <yofel> santa_: that belongs in meta-kde, not pkg-kde-tools
[13:12] <yofel> apachelogger: yeah, which lead to the issue that it's private upstream but in fact public for us
[13:12] <yofel> of the SONAME change was rejected upstream
[13:12] <santa_> yofel: yep, I have realized my repo name is wrong
[13:12] <yofel> *so the
[13:12] <santa_> sorry about that
[13:12] <yofel> ah ok
[13:12] <santa_> the rest of the merge request is fine though
[13:14] <yofel> apachelogger: FWIW:
[13:14] <yofel> Normally, the run-time shared library and its SONAME symlink should be placed in a package named librarynamesoversion, where soversion is the version number in the SONAME of the shared library. Alternatively, if it would be confusing to directly append soversion to libraryname (if, for example, libraryname itself ends in a number), you should use libraryname-soversion instead.
[13:14] <apachelogger> Normally.
[13:14] <apachelogger> not required
[13:15] <yofel> AIUI, the normally is for the exception in the second sentence
[13:15] <yofel> hm
[13:15] <apachelogger> no, then it would say Except
[13:15] <yofel> wait
[13:16] <yofel> If you have several shared libraries built from the same source tree, you may lump them all together into a single shared library package provided that all of their SONAMEs will always change together. Be aware that this is not normally the case, and if the SONAMEs do not change together, upgrading such a merged shared library package will be unnecessarily difficult because of file conflicts with the old version of the package. When in doubt, 
[13:16] <yofel> always split shared library packages so that each binary package installs a single shared library.
[13:16] <yofel> this is uselessly complicated
[13:19] <shadeslayer> hurray for autopkgtest
[13:19] <shadeslayer> I love this stuff
[13:19] <shadeslayer> caught an issue in my kate merge
[13:20] <yofel> apachelogger: I would still keep the single lib package for abi manager and pretictability
[13:20] <apachelogger> yofel: if sonnet breaks ABI that is a legit upstream break
[13:20] <apachelogger> on related note.. the plugins really should be lumped in with core as well
[13:21] <yofel> I have no issue with that as long as the SONAME changes
[13:21] <yofel> apachelogger: you'll still need a plugin package for map file which is foreign
[13:22] <yofel> or data package
[13:23] <apachelogger> shadeslayer: qtdeclarative5-kf5solid-5.0 is that common naming?
[13:24] <yofel> shadeslayer: hm, which test hook are you using locally?
[13:24] <apachelogger> yofel: data that is
[13:24] <shadeslayer> apachelogger: where is that from?
[13:24] <apachelogger> shadeslayer: solid? :P
[13:25] <yofel> apachelogger: I would prefer not to have so break/replace so-1 though, libkscreen showed how well apt handles that (BAD)
[13:25] <shadeslayer> yofel: http://paste.ubuntu.com/7594792/
[13:25] <shadeslayer> apachelogger: and does the changelog blame me?
[13:25] <apachelogger> shadeslayer: ur orig maint
[13:25] <yofel> shadeslayer: thanks
[13:25] <shadeslayer> wut
[13:25] <shadeslayer> bollocks
[13:25] <apachelogger>   * Added qtdeclarative5-kf5solid-5.0 to hold libsolidextensionplugin.so.
[13:25] <apachelogger> scarlett made that
[13:26] <apachelogger> sgclark: is the package naming conforming to some standard?
[13:26] <yofel> Riddell was discussing qml naming with debian
[13:26]  * apachelogger sees at least all the ubuntu things use that naming
[13:26] <sgclark> apachelogger: Riddell was talking to someone to come up with that, I only followed directions
[13:26] <apachelogger> Riddell: ping
[13:27]  * apachelogger doesn't see another package that has the version appended with a hyphen actually
[13:27] <sgclark> pretty sure it was a conflict thing
[13:27] <yofel> shadeslayer: is that part of our pbuilder-hooks yet?
[13:27] <shadeslayer> yofel: nope
[13:27] <yofel> could you add it?
[13:27] <shadeslayer> sure
[13:28] <yofel> \o/
[13:28] <shadeslayer> done
[13:28] <apachelogger> sgclark: that version suffix definitely is wrong, should be 1.0 actually
[13:28] <apachelogger> alas, I am not sure we should add the version
[13:28] <apachelogger> impossible to keep track of
[13:29] <yofel> version makes no sense if it's not part of the path IMO
[13:29] <apachelogger> nope
[13:29] <apachelogger> they are plugins
[13:30] <apachelogger> could be any version really at any time
[13:30] <apachelogger> so IMO it makes no sense in general
[13:30] <yofel> right, which is why IMO plugins should have a matching subfolder
[13:30] <apachelogger> yofel: ah, yeah, that's true as well
[13:34] <yofel> sgclark: considering we were just talking about policy, did you read the debian policy yet? If not, as packager and now member and thus aspiring ~kubuntu-dev you should do that in the near future
[13:35] <apachelogger> I think that solid package should be qtdeclarative5-solid or possibly qtdeclarative5-kde-solid or qtdeclarative5-kde-solid-plugin
[13:35] <sgclark> yofel: ok
[13:35] <apachelogger> very random nonense those declarative package names are
[13:36] <Riddell> apachelogger: pong
[13:37] <apachelogger> Riddell: how did you come up with the name qtdeclarative5-kf5solid-5.0 
[13:37] <yofel> apachelogger: wrt. kubuntu policy and council quorum: when did we decide that 4 people is quorum? Last I knew it required 3 people for it and none against which is what we usually applied
[13:37] <Riddell> apachelogger: chatting to various people in debain-qt-kde channel
[13:38] <apachelogger> Riddell: I don't see a version that separates version with hyphen in the archive, also some have a -plugin suffix
[13:38] <apachelogger> also the version is pointless in general
[13:40] <yofel> I do think the DMB has a +4 quorum rule where -1 is allowed I think, but I'm not sure
[13:41] <yofel> but that's 4 out of 7
[13:42] <Riddell> apachelogger: qml modules can include multiple versions so yes it might be pointless
[13:43] <Riddell> unless an incompatible version is released
[13:44] <apachelogger> Riddell: as yofel pointed out that version would need a different path though, or if it doesn't it would simply not be installable at the same time as the old version which again would render the version moot
[13:44] <apachelogger> yofel: there might been data lost on the council
[13:45] <yofel> hm, lets continue that on the ML
[13:45] <apachelogger> yofel: it's le wrong
[13:45] <apachelogger> A vote is defined as quorate if at least three council members are present. 
[13:45] <apachelogger> If the meeting is not quorate, voting shall be done by e-mail over a period of three days. 
[13:45] <apachelogger> The chair shall have a casting vote. 
[13:45] <apachelogger> ^ you are not actually ever appointing a chair
[13:46] <yofel> where's that from?
[13:46] <apachelogger> https://wiki.ubuntu.com/Kubuntu/Council?action=recall&rev=16
[13:46] <apachelogger> as I said, information loss
[13:47] <yofel> soooo... how's quorum defined by that? chair: +1, 2 others +1, 3 others -1-> passed?
[13:48] <apachelogger> that's +3 -3, chair breaks tie
[13:49] <yofel> that's rather different from the DMB though which quires +4
[13:49] <yofel> *requires
[13:49] <apachelogger> because we actually do not do a majority of members but a majority of present vote
[13:49] <yofel> then the ML continuuation is moot
[13:50] <apachelogger> the policy simply is wrong, please point that on the ML
[13:50] <apachelogger> needs carrying over the items from the aforementioned page
[13:50] <yofel> will do
[13:50] <apachelogger> yofel: I would suggest the council clearify that part on their own actually
[13:51] <yofel> sure, but I don't think we need the council ML for that
[13:51] <apachelogger> as I said, you do not ever select a chair and according to the way old blueprint from intrepid or whatever Riddell is defined as chair which raises the interesting question what exactly would happen if he drops out of the council
[13:52] <yofel> IMO, then the DMB rules apply, just with 1 point less
[13:52] <apachelogger> DMB is developers is it not?
[13:52] <apachelogger> also what happens if 4 council members are present and tie but the chair is not present
[13:53] <apachelogger> e.g. +2 -2
[13:53] <yofel> which is IIRC why we've settled on the simple +3 rule
[13:53] <yofel> let me actually look up the last CC meeting logs, I think there was something about voting too
[13:55] <apachelogger> yofel: I think that should be written like that then
[13:55] <apachelogger> except
[13:55] <apachelogger> what if you have +3 -3, is the motion carried or not?
[13:56] <apachelogger> if it is simply +3 then it woud be carried anyway, so the chair position is pointless
[13:56] <yofel> http://irclogs.ubuntu.com/2014/05/15/%23ubuntu-meeting.html#t17:00 has pretty much the same talk ^^
[13:56] <apachelogger> well, you need to figure that out for yourselves :P
[13:56] <apachelogger> I am just pointing out the actual voting rules are not exactly clear
[13:57] <yofel> yeah, which I would like to have fixed
[13:57] <yofel> anyway, ML
[13:58] <apachelogger> oh, a bug, oh my
[13:59] <apachelogger> Riddell: so, any objections to dropping the pointless version?
[13:59]  * shadeslayer feels like his eyes are going to pop out
[14:00]  * apachelogger wonders whether we should put the declarative plugin into the libsolid package
[14:01] <apachelogger> usr/lib/*/libKF5Solid.so.4*
[14:01] <apachelogger> usr/lib/*/libKF5Solid.so.5
[14:01] <apachelogger> that's madness btw
[14:01] <yofel> shouldbe .*
[14:01] <apachelogger> yeah
[14:01] <apachelogger> the 4 is shite too
[14:01] <apachelogger> yofel: does the release scripty have logic to deal with bumping all so versions?
[14:01] <yofel> although, then the install won't fail on version change
[14:01] <apachelogger> because we'll have to touch all 60 frameworks come final...
[14:02] <apachelogger> yofel: install would fail on .so.5
[14:02] <yofel> no, we never needed that, because the SC has like 5 dozen differen so versions
[14:02] <yofel> apachelogger: yeah, but I just realized that I overly simplyfied that in kwallet to general .*
[14:02] <yofel> needs fixing
[14:03] <apachelogger> ah
[14:03] <apachelogger> oh well
[14:03] <apachelogger> worse things in life
[14:03] <apachelogger> wouldn't be the first time the glorious abi tracking scheme didn't work out :S
[14:03] <yofel> uh, aspiring kubuntu-members need to inform the council, not the other members, right?
[14:04] <yofel> member don't really have anything to do with this
[14:07] <apachelogger> yofel: where's that from?
[14:07] <yofel> apachelogger: policy: "Application: To apply for membership all you need to do is inform the ~kubuntu-members about your desire to become member..."
[14:07] <yofel> that's council, right?
[14:08] <apachelogger> yofel: kubuntu-devel mailing list technically
[14:08] <yofel> also, "Notes: Ninjas are members of both ~kubuntu-packagers and ~kubuntu-ppa", is packagers membership waiting on policy approval?
[14:09] <ScottK> Council is correct though.
[14:09] <apachelogger> yofel: yes
[14:09] <apachelogger> yofel, ScottK: I think it best had been changed to 'kubuntu-devel ML'
[14:09] <yofel> apachelogger: well, devel is the usual contact, but it's council really. How about "... inform the ~kubuntu-council over the kubuntu devel ML" ?
[14:09] <apachelogger> everything else is silly at best
[14:10] <ScottK> s/over/via/ but yes.
[14:10] <kubotu> ScottK: You did something wrong... Try s/you/me/ or tell me "help sed"
[14:10] <yofel> via it is then
[14:10]  * apachelogger hungry
[14:10] <yofel> apachelogger: I'll also add that ninjas can commit to packagers in the ~packagers section so that's in sync
[14:12] <apachelogger> someone please review solid changes in bzr, might totally have broken something
[14:13] <apachelogger> uploaded as ppa4, afk getting somethign to eat
[14:29] <Riddell> new tars http://starsky.19inch.net/~jr/tmp/plasma-4.97.0/
[14:29] <Riddell> but first everything needs moved to utopic
[14:31] <sgclark> Riddell: I set up a utopic chroot
[14:33] <sgclark> I will start on those and continue reading mounds of policies
[14:35] <Riddell> sgclark: policies are pretty dry, don't send yourself mad by going bored!
[14:35] <Riddell> sgclark: I think the first thing to do is just repackage all the kf5s for utopic
[14:36] <Riddell> and throw them up into next PPA
[14:36] <yofel> sgclark: uhm, you may read 'near future' as a time span counted in weeks. You should finish it before you apply for ~kubuntu-dev at least ^^
[14:37] <yofel> the only thing that's more boring than the DP is the make manual
[14:37] <Riddell> apachelogger: home come tarme shows md5sums but sysadmins these days like sha256?
[14:39] <sgclark> lol ok
[14:39] <Riddell> s/home/how/
[14:39] <kubotu> Riddell meant: "apachelogger: how come tarme shows md5sums but sysadmins these days like sha256?"
[14:40] <sgclark> so anything I should be aware of that I have been doing wrong? apachelogger did a bunch of updates and I am not clear on all that transpired today
[14:40]  * sgclark wans to improve and learn from mistakes
[14:41] <yofel> wrong might not be the right word, we've been clearing some things up in here and with debian and apachelogger did a bunch of templating
[14:42] <yofel> sgclark: I think the points are mostly that pre-depends should be gone for multiarch, and package naming changes
[14:42] <Riddell> nothing is wrong when there are no rules set, and rules are inflexible hinderances :)
[14:42] <apachelogger> sgclark: don't define Section unless you know you need to, also make sure that Description is always last for package stanzas otherwise it looks really weird, otherwise nothing comes to mind
[14:42] <apachelogger> oh and try to not split workspace bits too much I guess :P
[14:42] <Riddell> apachelogger: wrap-and-sort did moving Description around I think
[14:42] <sgclark> ahh apachelogger: wrap-and-sort did that wierd order
[14:43] <apachelogger> piece of shit script that one is
[14:43] <sgclark> ^^
[14:43]  * sgclark agrees
[14:43] <yofel> well yeah, python lib bug -.-
[14:43] <sgclark> it also randomly removed -dev packages
[14:43] <apachelogger> why it is written in python I do not get btw
[14:43] <yofel> someone got tired of perl? ^^
[14:44] <apachelogger> or someone simply didn't feel like using what everyone else uses...
[14:44] <yofel> apachelogger: didn't you want to rename kio?
[14:44] <apachelogger> yofel: dude, I am walking up a pile of packages
[14:44] <apachelogger> currently I have reviewed 5
[14:44] <yofel> :D
[14:44] <apachelogger> and that's not even really precise reviews
[14:44] <apachelogger> you see why I am not particularly happy about having soo many binary packages
[14:46] <apachelogger> the plasma packaging definitely has a runtime tie that is not represented
[14:46] <apachelogger> namely I think the libs need to recommend plasma-framework
[14:46] <apachelogger> guess the problem will turn up sooner or later
[14:48] <apachelogger> Breaks: libkf5windowsystem5-data
[14:48] <apachelogger> Replaces: ${F:Breaks}
[14:48] <apachelogger> look what I just did
[14:51] <yofel> o.O
[14:51] <yofel> does that seriously work o.O?
[14:51] <apachelogger> should anyway
[14:51] <yofel> I'll trust it when I see the binary control file
[14:52] <apachelogger> pft
[14:52] <apachelogger> no faith in my awesome
[14:53] <apachelogger> ultimately I'd totally love to have a substvar for dev packages btw
[14:53] <apachelogger> made a PoC for neon
[14:54] <apachelogger> since the cmake configs declare other cmake packages that need to be present one can theoretically build the majority of -dev dependencies automatically from that
[14:57] <apachelogger> yofel: doesn't work it seems
[14:57] <shadeslayer> apachelogger: does dpkg automatically substitute that or do you have to add additional scripts
[14:57] <apachelogger> shadeslayer: it would do it automatically 
[14:57] <apachelogger> F: is a builtin
[14:58] <yofel> I think that it won't really work for fields that can be there multiple times
[14:58] <apachelogger> from what I understand while parsecontrol runs through the control it will simply throw the resolved fields at the substvar instance
[14:58] <apachelogger> yofel: it does
[14:59] <apachelogger> I am not yet sure what exactly decide in which order they become available/get resolved though
[14:59] <apachelogger> there may well be buggery somewhere
[14:59] <apachelogger> seeing as F: isn't exactly the most used thing ever
[15:00] <apachelogger> yofel: I think you can only access the fields of the previous stanza actually
[15:00] <yofel> deb-substvars doesn't really say much about it either :S
[15:06] <apachelogger> maybe I need to address it differently
[15:06] <apachelogger> it works when I pack it in description though
[15:08] <apachelogger> yofel: it apparently processes things in a fixed order
[15:09] <apachelogger> or not
[15:09] <apachelogger> I don't get this ^^
[15:09] <apachelogger> screw it
[15:59] <apachelogger> Riddell, sgclark: Package: kimageformat-plugins
[15:59] <apachelogger> why -plugins?
[16:04] <apachelogger> !info kdoctools
[16:04] <apachelogger> yofel, Riddell: did anyone ever make a conclusion on kf5-foo vs. foo-kf5 vs. foo5?
[16:05] <apachelogger> when there's name clash with kde4 that is
[16:07] <sgclark> apachelogger: has been -plugins since intitial release which was Rohan Garg (shadeslayer?)
[16:08] <apachelogger> shadeslayer: wheare art thou
[16:08] <shadeslayer> hm?
[16:08] <shadeslayer> what's the source
[16:09] <apachelogger> shadeslayer: kimageformats
[16:09] <apachelogger> which is what I reckon the package name should be
[16:10] <shadeslayer> them logs blame Riddell
[16:11] <apachelogger> yofel, Riddell: here's an intersting one as well ... kded5 contains kded5 binary and cmake stuff and so forth, so holding on to our defined convention it needs to be kded-dev kded kded-dbg, but isn't that way crazy then?
[16:11] <sgclark> well bzr yeah but changelog says you :)
[16:14] <kubotu> feed branches-next had 14 updates, showing the latest 8
[16:14] <apachelogger> mhh
[16:14] <apachelogger> maybe 6 after all
[16:14] <apachelogger> kubotu: config set rss.announce_max 6
[16:14] <kubotu> alright
[16:15] <sgclark> apachelogger, Riddell: are you working on all of kf5? I should probably wait before porting all of these to utopic?
[16:16] <apachelogger> I am anyway
[16:16] <apachelogger> plus I fully expect some breakage in the deps
[16:17] <sgclark> anything I can do to help?
[16:17] <apachelogger> nope, just wait :P
[16:17] <sgclark> alright
[16:17] <apachelogger> going to upload ppa20 when I am done
[16:17] <apachelogger> then probably some build fixing and then we are good for utopic
[16:43] <apachelogger> uploading ppa20 now
[16:45] <apachelogger> done
[16:45] <apachelogger> oh actually that may not end in build failures, we'll see for utopic though ^^
[16:45] <apachelogger> sgclark: feel free to throw everything at utopic
[16:46] <apachelogger> if both trusty and utopic end up green I guess we don't have any obvious dep issues at the very least
[16:52] <sgclark> apachelogger: want me to help with build breaks?
[16:59] <apachelogger> sgclark: please, I am about to head out anyway
[16:59] <sgclark> apachelogger: ok on it
[17:06] <santa_> apachelogger: wrt the kdesu todo in notes.k.o I was planning to do a massive change aabout that, mind if I prepare some merge requests today so you could review them later?
[17:07] <apachelogger> later == next week most likely
[17:07] <apachelogger> fwiw
[17:08] <apachelogger> santa_: the change actually doesn't need to be massive, it just needs a -bin package ^^
[17:08] <santa_> no, but I mean there are other packages affected by the same issue
[17:08] <santa_> i.e. having files which would belong somewhere else
[17:09] <santa_> * i.e. having files in lib* which would belong somewhere else
[17:09] <apachelogger> ah, didn't see any
[17:10] <santa_> apachelogger: https://code.launchpad.net/~panfaust/kubuntu-packaging-next/kauth-work/+merge/222161 for instance
[17:10] <santa_> I think I found ~15-10 having similar issues
[17:11] <santa_> hmm, not so many
[17:11] <santa_> ~10
[17:12] <apachelogger> mh
[17:12] <apachelogger> I don't think moving plugins out makes any sense
[17:13] <apachelogger> they shouldn't be in the symbols file though if that's at all possible
[17:13] <kubotu> feed branches-next had 7 updates, showing the latest 6
[17:14] <apachelogger> ah yeah, there's some with data files in lib apparently
[17:14] <santa_> I tend to think dpkg-gensymbols will complain
[17:14] <apachelogger> these framework packages are truly shitty to maintain
[17:14] <santa_> in any case that's what -bin packages are for
[17:14] <apachelogger> not really, they are there for arch:any content
[17:15] <apachelogger> just like data is there for arch:all
[17:15] <apachelogger> other than that one should be very mindful of what one decides to put where
[18:09] <santa_> sgclark: are you working on build failures?
[18:11] <sgclark> santa_: yes
[18:11] <santa_> sgclark: may I help? let's use notes.kde.org?
[18:12] <sgclark> as of right now solid is the hold up and nnew rev is building right now
[18:27] <santa_> sgclark: I see, now it seems it's almost done
[18:28] <sgclark> santa_: don't think there will be much, but will let you know
[18:29] <santa_> sgclark: the kio -dev renaming
[18:30] <santa_> sgclark: I think kservice amd64 just needs a retry
[18:31] <sgclark> kio-dev renaming?
[18:31] <sgclark> that is not someing I want to do without apachelogger approval
[18:32] <santa_> sgclark: I mean he renamed it, thus some packages should change its build deps
[18:33] <sgclark> oh ok
[18:35] <santa_> sgclark: same for kdoctools, I think a retry would fix it
[18:43] <santa_> sgclark: same for ktextwidgets (I'm checking if they build here)
[18:43] <sgclark> we are doing the same thing heh
[18:45] <santa_> and now we have to wait because evrything else is below in the b-d graph :)
[18:45] <yofel> apachelogger: I don't think we really had a decision on naming conflicting stuff, to foo-kf5 would be my choice so it's at least still in the same alphabetical order
[18:45] <yofel> debian folks didn't really say anything either :/
[19:12] <CodePulsar> Does Kubuntu 14.04 come with a cron job for TRIM when enabling encryption at installation time ?
[19:12] <CodePulsar> *SSD Trim
[19:16] <yofel> CodePulsar: the util-linux package provies /etc/cron.weekly/fstrim, I don't think encryption will have anything to do with that, not sure though
[19:28] <apachelogger> yofel: well, that's the thing kded technically doesn't conflict
[19:28] <apachelogger> it might possibly just be confusing to the casual observer
[19:38] <yofel> well yeah, all hail the splittery
[19:39] <apachelogger> ^^
[19:39] <apachelogger> OTOH no one cares about kded
[19:39] <apachelogger> and chances are there won't be a kded6 but stuff might get outsourced to systemd
[19:39] <apachelogger> it's a bit of a cointoss the name on that one ^^
[19:44] <yofel> well, if there is one we can name that kded6 then
[19:49] <apachelogger> yeah, just saying that makes it even less desirable to name it  kded-kf5 rather than kded IMO
[19:49] <yofel> well, foo-kf5 sounds pretty bad in general, so if there's any other better name that would be preferable, like kded5 here
[19:50] <yofel> except that kded is completle sufficient
[20:00] <CodePulsar> yofel: for encrypted partitions additional stuff needs to be done as per http://www.webupd8.org/2013/01/enable-trim-on-ssd-solid-state-drives.html "For encrypted partitions" section
[20:01] <shadeslayer> yofel: pokety poke
[20:01] <yofel> shadeslayer: pong
[20:02] <yofel> CodePulsar: I don't have an ecrypted partition to verfy this either, so either ask in #kubuntu if someone can help, or feel free to file a bug 
[20:02] <shadeslayer> yofel: know anyone from Xubuntu/Lubuntu/Ubuntu GNOME?
[20:02] <shadeslayer> I can't think of anyone :S
[20:04] <yofel> for what o.O? #ubuntu-quality would be a place to dig someone up for testing I guess, and there's #xubuntu-devel - haven't been in contact with the other flavors much lately
[20:05] <shadeslayer> well, badgering them to give a session at UOS
[20:06] <shadeslayer> btw, if anyone wants to give a session in the Ubuntu Development track, feel free to propose one and give me a link :D
[20:15] <shadeslayer> http://uds.ubuntu.com/getinvolved/propose-a-session/
[20:15] <shadeslayer> Riddell: ^^ good idea to propose a session about KF5 packaging status/plans maybe?
[20:15] <yofel> again, what do we still need to discuss?
[20:16] <shadeslayer> not a discussion, but more of a "Inform everyone about what our plans are"
[20:16] <yofel> if anything we could talk about how to get it in debian, but that's probably not a plan for the next debian release
[20:42] <yofel> hm, we need a dh_test result parser for kubuntu-status
[22:12] <ahoneybun> hey valorie
[22:44] <Riddell> shadeslayer: yeah go for it
[22:44] <shadeslayer> Riddell: go for the KF5 packaging session?
[22:44] <shadeslayer> you'll have to do it btw :P
[22:48] <Riddell> que? mi? get sgclark to do it
[22:49] <shadeslayer> sure
[23:05] <valorie> hi ahoneybun
[23:06] <valorie> sorry, about to go afk and run