[00:08] <apachelogger> allee: not really
[00:08] <apachelogger> allee: is kdepimlibs-dev installed?
[00:08] <apachelogger> or kdepimlibs5-dev not sure what the package is called
[08:42] <Riddell> !newversion phonon 4.7.80
[08:42] <Riddell> hmm
[08:42] <Riddell> kubotu: newversion phonon 4.7.80
[08:42] <kubotu> https://bugs.launchpad.net/bugs/1356237
[09:03] <Mamarok> question: if somebody tries a live CD and they tries to play an mp3, do they get the same possibility to install the missing codecs or does that only work on installed systems?
[09:34] <Riddell> Mamarok: older versions disabled that notifications but I think it's enabled now
[09:48] <Mamarok> so there is a file system thingy that allows to install codecs?
[09:50] <Mamarok> just had that question in the forum, I suggested to actually install Kubuntu :)
[09:50] <Riddell> there should be a notification that pops up suggesting you install codecs if you try to play one
[09:51] <Riddell> installing is better, there you just need to tick the "install mp3" box
[10:54] <Riddell> I just noticed http://changelogs.ubuntu.com/meta-release-lts has been updated
[10:54] <Riddell> so expect LTS using  people to be upgrading to trusty
[11:14] <Riddell> yofel: you said to maxy "You have a point though as e.g. we did not notice the ABI breakage in kdepimlibs that you found a couple days ago." do you know why that wasn't picked up by .symbol file changes?
[11:26] <yofel> Riddell: not really, the relevant discussion was http://paste.ubuntu.com/8035333/ 
[11:31] <Riddell> hmm, curious
[11:31] <BluesKaj> Hiyas all
[11:57] <apachelogger> Riddell, yofel: it wasn't because vtables are not reflected in symbols
[12:01] <Riddell> symbols are spooky voodoo
[12:09] <yofel> apachelogger: yeah, I got that much, except that I have no idea what a vtable is (c++ seriously has a sepeate symbol table for virtual functions?)
[12:12] <apachelogger> yofel: it needs to have a separate table
[12:12] <apachelogger> virtual functions are resolved at runtime
[12:13] <apachelogger> the vtable itself is built into the binary IIRC, so you know that vt[0] is void kittens(); and vt[1] is void puppies();
[12:13] <apachelogger> then at runtime any version of kittens or puppies may provided vt[0/1] of the class in question
[12:14] <apachelogger> now if you change the order in the virtual base class around the library will say that vt[0] is puppies and vt[1] is kittens, but the application continues to access vt[0] to get kittens
[12:14] <apachelogger> this is not really ABI breakage it is binary incompatible though
[12:17] <yofel> brrr
[12:18] <shadeslayer> software engineering is hard, lets go shopping
[12:19] <apachelogger> \o/
[12:19] <apachelogger> https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_Do.27s_and_Don.27ts
[12:21] <yofel> @_@
[12:22] <yofel> on that point, someone write such a page for general post-release bugfixing
[12:23] <apachelogger> ?
[12:25] <yofel> Don'ts:
[12:25] <yofel> - remove libraries after release (even if they're not used)
[12:25] <yofel> maybe just a grumpy packager request though
[12:26] <apachelogger> there's worse things one could do I am sure ^^
[12:26] <yofel> true
[12:29] <yofel> did our friendly kf5 upstream actually mention what they'll do should we ship kf5 components with different versions?
[12:30] <apachelogger> yofel: when would that happen?
[12:30] <apachelogger> shadeslayer: u at comput0r?
[12:31] <yofel> apachelogger: maxy currently doesn't update kde packages if there's nothing to update, and he did plan to do the same for kf5
[12:31] <yofel> e.g. what we do with --sru
[12:31] <apachelogger> there's always something to update because the version in cmake always changes :P
[12:32] <yofel> I wonder if we whitelisted that...
[12:33] <yofel> apachelogger: considering he checks stuff manuall I'm not sure if he would consider that a "change" really
[12:33] <yofel> *manually
[12:35] <apachelogger> he wants to check some 100 diffs manually :O
[12:35] <yofel> well, he has some scripts himself, not sure how much they do
[12:36] <apachelogger> "afaik version X frameworks depend on version X frameworks even when they could work with X-1"
[12:36] <apachelogger> le not supported
[12:36] <tsimpson> hopefully the checks are based on tiers
[12:36] <yofel> ah, so that'll fail on a cmake level?
[12:36] <apachelogger> yes
[12:36] <shadeslayer> apachelogger: yes
[12:36] <shadeslayer> we were discussing book tooling
[12:36] <apachelogger> shadeslayer: already resolved
[12:37] <shadeslayer> ok
[12:37] <apachelogger> framework cmakelists have one var for version
[12:37] <apachelogger> that is defined to both define the framework's version and the versions it will look for in other frameworks
[12:38] <yofel> ok, thanks
[12:41] <yofel> hm
[12:41] <yofel> but that would still only require updating those packages that are required by the higher tiers. And the leaf packages are easy to skip as nothing depends on them
[12:42] <yofel> could get messy up higher though
[12:45] <apachelogger> yofel: IMO this should be brought up with dfaure
[12:45] <apachelogger> if a leaf doesn't have changes one mmight as well not updated it upstream
[12:45] <apachelogger> I am reasonable certain one would not want to support that though
[12:45] <apachelogger> leaf libs are like 10kb or so
[13:05] <shadeslayer> Riddell: :O
[13:05] <shadeslayer> Riddell: you dragonnapped konqi
[13:06] <yofel> :O
[13:06] <shadeslayer> https://www.flickr.com/photos/jriddell/14882348636
[13:06] <shadeslayer> someone get to the barcelona office quick
[13:06] <shadeslayer> konqi needs help
[13:22] <yofel> apachelogger: you would already be happy if we just copied our current packaging into a branch on alioth right?
[13:23]  * yofel wonders if pino has any intention of commenting at all
[13:26] <Riddell> shadeslayer: he's sight seeing!
[13:31] <shadeslayer> :D
[13:32] <shadeslayer> Riddell: that's what you say
[13:32] <shadeslayer> yofel: apachelogger found wine
[13:32] <shadeslayer> yofel: you can forget about hearing from him for the rest of the day
[13:32] <yofel> damint :D
[13:35] <apachelogger> it magically appeared!
[13:35] <apachelogger> yofel: yes
[13:35] <yofel> good
[13:35] <apachelogger> yofel: from where I am standing we need to start at some point otherwise we'll never find the perfect setup xD
[13:36] <apachelogger> and meddling with branch layout etc. later is not that big a deal
[13:36] <yofel> yeah, my last mail pretty much reduced the proposal to that
[13:52] <Riddell> anyone know why we do multiarch? what's it actually good for?
[13:55] <valorie> don't listen to him, he's a konqui-kidnapper!
[13:55] <valorie> dangerous Scot
[14:00] <Riddell> valorie: I'm Catalunyan now, father of dragons!
[14:01] <valorie> I heard that now that Scotland is sorted, you were going to Solve Catalonia
[14:01] <valorie> good luck with that!
[14:02] <valorie> how is the catalunyan whisky btw?
[14:04] <apachelogger> valorie: u not working!
[14:04] <valorie> if typing: work(true)
[14:05] <valorie> so there
[14:18] <Riddell> valorie: they seem to mostly sell all the stuff which is so bad it doesn't get sold in scotland
[14:19] <valorie> I hope you are surviving....
[14:22] <Odur> libnepomuk4 got uninstalld when upgraded to 4.13.97. Is that suppose to happen?
[14:22] <Riddell> valorie: I've discovered that when you order a rum and coke here, they take the exact opposite approach to scotland for ratios of coke to rum
[14:22] <valorie> ewww, rum and coke
[14:23] <Riddell> Odur: yes it's expected, will you miss it?
[14:23] <valorie> solution: get something else
[14:23] <Riddell> or gun and tonic
[14:23] <Odur> Riddell: Yeah. Kdenlive depends on it
[14:23] <Riddell> gin and tonic
[14:23] <Odur> But I'll manage
[14:23] <Riddell> Odur: kdenlive in backports is recompiled not to use it, where are you getting it from?
[14:24] <Odur> kdenlive's own repository
[14:25] <Odur> Well, I could probably use Utopics package
[14:28] <Odur> Problem solved :)
[14:29] <Riddell> kdenlive has its own repository?
[14:29] <Riddell> where's this?
[14:29] <shadeslayer> I can poke the kdenlive folks
[14:33] <Riddell> hmm https://launchpad.net/~sunab/+archive/ubuntu/kdenlive-release
[14:34] <valorie> Riddell: they are here refactoring
[14:34] <Riddell> ah, that archive has 0.9.8 which is newer than the 0.9.6 in our kubuntu-ppa/backports
[14:34] <Odur> Yeah, that's the one. (And no problem solved here... must solve a lot of dependencies first :/)
[14:35] <Riddell> so only 1 thing for it, backport 0.9.8
[14:35] <Riddell> volunteers welcome :)
[14:38] <Odur> Well, I probably could packport to my own ppa. But I'm not confident to do a official one
[14:47] <Riddell> Odur: go for it, then I can take it from yours and check for sanity
[14:53] <Odur> Riddell: Is it possible to find the diff for an earlier version in the backports ppa?
[15:08] <Riddell> Odur: probably not, what are you looking for?
[15:09] <Riddell> Odur: to backport 0.9.8 take the package from utopic  run dch to add a ~ubuntu14.04~ppa1 version and compile that on trusty
[15:09] <Odur> Ok
[15:09] <Riddell> ** proofreads needed for this blog https://notes.kde.org/p/jriddell-blog
[15:09] <Riddell> it's about all the work it takes to make packages for kubuntu
[15:13] <turgay>  what is the problem ?   
[15:13] <turgay> http://s22.postimg.org/5ksapuich/ekran_g_r_nt_s_1.png
[15:13] <turgay> kubuntu 14.04   Sürüm 36.0.1985.125 Ubuntu 14.04 (283153)  chromium
[15:15] <Riddell> turgay: best use #kubuntu for user support
[15:15] <turgay> ok 
[15:18] <Odur> Riddell: got "kdenlive (0.9.8-1ubuntu3) UNRELEASED; urgency=medium". Probably because I upgraded to 4.13.97 right? Just change it to "kdenlive (0.9.8-1ubuntu3~ubuntu14.04~ppa1) trusty; urgency=medium" ?
[15:21] <yofel> 0.9.8-1ubuntu2~ubuntu14.04~ppa1, the 3 got auto incremented which you don't want for backports
[15:23] <Odur> yofel: thanks
[15:28] <Odur> Well, uploaded to my ppa. Let's see if I fckd up ;)
[15:30] <Odur> Oops. Didn't notice. My name "Carslöv" got changed to "Carsloev". :/
[15:34] <Riddell> Odur: but it got accepted?  where's your PPA?
[15:44] <Odur> Riddell: https://launchpad.net/~odur/+archive/ubuntu/backports
[15:45] <Riddell> Odur: lovely, does it install and run?
[15:46] <Odur> I'm on it
[15:46] <Odur> just a minute
[15:49] <Odur> Riddell: Nope. Complaining about libnepomuk4
[15:53] <valorie> this is interesting: 
[15:53] <valorie> [08:47] <hggdh> both gksu and gksudo are being ousted
[15:53] <valorie> [08:48] <hggdh> pkexec is being promoted in their place
[15:53] <valorie> from the #ubuntu-ops
[15:54] <valorie> http://manpages.ubuntu.com/manpages/trusty/en/man1/pkexec.1.html
[16:01] <shadeslayer> hm
[16:01] <shadeslayer> should I idle in #ubuntu-ops
[16:01] <shadeslayer> since I have ops in #kubuntu
[16:02] <valorie> I was asked to do so, so I do
[16:03] <shadeslayer> *shrug* then, one person is enough I think
[16:05] <Riddell> Odur: oh your PPA will need to depend on backports PPA
[16:06] <Riddell> >pkexec dolphin
[16:06] <Riddell> dolphin: cannot connect to X server
[16:06] <Riddell> not much use that
[16:10] <Odur> Riddell: That's over my pay grade ;)
[16:11] <Riddell> Odur: yep I'll take it from here, thanks for your help
[16:11] <Odur> Np
[16:11] <Riddell> https://twitter.com/kdecommunity/status/499573190352699392/photo/1  lots of children in randa, a new addition to KDE scene?
[16:11] <Odur> Riddell: Can I delete the package from my ppa then?
[16:12] <valorie> shadeslayer: if you have room in your chanlist, sure
[16:12] <shadeslayer> valorie: nope :p
[16:12] <shadeslayer> too many chans
[16:12] <valorie> I keep shaving chans as well
[16:12] <shadeslayer> I need to cut down
[16:12] <valorie> yes, lots of kids this year
[16:13] <valorie> all very well-behaved
[16:14] <Riddell> Odur: if you want
[16:18]  * Riddell blogs https://blogs.kde.org/2014/08/13/upstream-and-downstream-why-packaging-takes-time
[16:25]  * Riddell blogs http://wire.kubuntu.org/?p=175
[16:25] <Riddell> 17:18  * Riddell blogs https://blogs.kde.org/2014/08/13/upstream-and-downstream-why-packaging-takes-time
[16:25] <Riddell> just incase you missed it shadeslayer :)
[16:25] <Odur> How do I get a pbuilder-dist depend on kubuntu-backports?
[16:31] <yofel> Odur: with pbuilder it would be login --save-after-login, then in there edit the sources.list
[16:31] <soee> Riddell: the packaging for Kubuntu is much different from Arch packages ?
[16:32] <Riddell> soee: probably yes, I've never looked at Arch but I think they have pretty monolithic packages
[16:33] <soee> i wonder if for Kubuntu it would be possible to have package maintainers liek in Arch i think - there each package is maintained by some person right ?
[16:34] <Riddell> that's one of the issues ubuntu always wanted to avoid which debian has
[16:34] <Riddell> if one person blocks then the whole archive slows down
[16:35] <Odur> yofel: Thanks
[16:37] <yofel> soee: considering we maintain some ~250 packages that's... slightly problematic
[16:37] <yofel> even in debian which has package maintainers kde is maintained by the debian-qt-kde team, and usually updated by 1 or 2 people
[16:37] <yofel> (250 is a wild guess, it should be more than that)
[16:39] <soee> yofel: problematic to find those potential people?
[16:40] <yofel> well yeah, you roughly know how large the team is and not everyone focuses on packaging (or even on kubuntu)
[16:40] <yofel> so team management is the sane thing to do
[16:41] <yofel> even if you would tell people to adopt a package, the work required to update a package varies greatly (e.g. compare kfloppy and kde-workspace)
[16:41] <yofel> and as lots of work is scripted these days, some packages don't even need a human to maintain them
[16:41] <Riddell> but the scripts do :)
[16:42] <soee> :)
[16:42] <yofel> that's true ^^
[16:57] <santa> talking about scripting, a couple fo days ago I tried to clone the kubuntu-automation repository but I couldn't
[16:59] <santa> $ bzr branch lp:~kubuntu-packagers/kubuntu-packaging/kubuntu-automation
[16:59] <santa> bzr: ERROR: No es una rama: «bzr+ssh://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kubuntu-automation/»: location is a repository.
[16:59] <Riddell> soee: lp:~kubuntu-packagers/+junk/kubuntu-automation
[16:59] <yofel> the "kubuntu-packaging" projects is solely for packaging branches
[17:01] <Riddell> santa: rather ↑
[17:05] <santa> Riddell: thanks, I have something similar for siduction and I think I have some things which may be interesting to share
[17:05] <Riddell> santa: I'd also be interested in any other comments on that blog of mine
[17:09] <santa> you mean the "Upstream and Downstream: ..." post I guess
[17:10] <santa> seems interesting, I will download it to read this night
[17:10] <santa> (I don't have my own internet connection in august)
[17:11] <yofel> santa: are your scripts somewhere public?
[17:13] <santa> yeah, I have started to push it to a git repository because they got non-trivial
[17:13] <Riddell> I've been using your frameworks dot diagram, lots of deps there
[17:14] <santa> oh, soon enough I will have some stuff to generate the dot file automatically
[17:15] <santa> https://gitorious.org/siduction-kde-kf5/siduction-kde-pkg-scripts
[17:15] <santa> yofel: ↑
[17:15] <yofel> thanks
[17:17] <Riddell> Odur: if you're on trusty would you be able to verify this update at all? bug 1352397
[17:19] <santa> yofel: as a warning they still too 'cheap' if you know what I mean, and they aren't exactly easy to use if you didn't write them
[17:21] <yofel> there's some interesting parts I see though. (e.g. our scripts currently don't use python-debian at all, and really could use it in some places)
[17:22] <santa> to bump the build depends for instance
[17:22] <yofel> and honestly, some parts of our scripts aren't exactly... great... either
[17:22] <santa> yeah, I know
[17:23] <Odur> Riddell: I don't have a screen compatible with one of my laptops, so I can't do the test scenario
[18:02] <santa>  I did a quick inspection of our scripts and there is stuff interesting to steal from each other
[18:36] <santa> yofel, Riddell: if we are going to share stuffof out automation scripts it would be nice to license them asap
[18:37] <santa> mines doesn't have a license yet
[18:37] <yofel> ours neither..
[18:37] <santa> ok, think about a lincense and tell me, I will use the same
[18:37] <santa> as long as it's free :P
[18:38] <yofel> apachelogger, debfx, Riddell, shadeslayer: BSD3 or mit/x11 maybe?
[18:39] <santa> the first thing I would like to get into the kubuntu scripting is my stuff to bump the build depends because I think it works a bit better than yours
[18:40] <apachelogger> yofel: spaceships
[18:40] <apachelogger> what
[18:40] <apachelogger> yofel: gpl
[18:42] <yofel> apachelogger: why?
[18:42] <apachelogger> yofel: why not
[18:42] <yofel> true
[18:42] <apachelogger> if someone improves on our stuffsies and actually ends up distributing it (which is weird in itself) I rather expect the improvements to be available for us to find and possibly pick up
[18:42] <yofel> what though? gpl2+?
[18:42] <apachelogger> gpl kde
[18:42] <yofel> ah right, well wfm
[18:48] <santa> yofel, Riddell: I'm leaving soon, what if I provide you a function in a *.py file to bump all the frameworks and plasma dependencies which works better than yours?
[18:48] <santa> I could work on that @ home without internet and bring you something tomorrow
[19:15] <debfx> yofel: GPL is fine with me
[19:38] <shadeslayer> yofel: I'm fine with MIT/X11
[19:38] <yofel> shadeslayer: I think we'll go with gplkde
[19:40] <shadeslayer> ok
[19:55] <shadeslayer> I'm so full of swiss cheese
[19:55] <shadeslayer> and wine
[19:55] <shadeslayer> so much wine
[19:56] <shadeslayer> apachelogger: I'm running low on wine
[19:56] <shadeslayer> apachelogger: halp
[20:02] <apachelogger> shadeslayer: downstairs?
[20:06] <apachelogger> Riddell: y u post so long
[20:08] <valorie> I liked it!
[20:08] <valorie> but your blog never allows me to respond
[20:11] <genii> Incidentally broken link to what seems to be a picture in https://blogs.kde.org/2014/07/28/kubuntu-plasma-5-isos-rolling
[20:11]  * genii goes back to making coffee
[20:14] <apachelogger> shadeslayer: what's with the wine?
[20:14] <shadeslayer> its gone
[20:14] <shadeslayer> all of it
[20:14] <shadeslayer> nooooooo
[20:19] <apachelogger> shadeslayer: mais non, il y a une autre bouteille 
[20:21] <shadeslayer> :O
[20:23] <shadeslayer> chocolate solves all the problems
[20:23] <shadeslayer> we should get some chocolate
[20:24] <apachelogger> all hail the chocolate god
[20:24] <apachelogger> why you see it is choco-late because it is always late
[20:25] <valorie> oh dear, chocolate and puns
[20:25] <valorie> regretable
[20:25] <shadeslayer> apachelogger: the chocolate god is sitting next to me
[20:25] <shadeslayer> all hail mario
[20:31] <shadeslayer> apachelogger: dude
[20:31] <shadeslayer> apachelogger: did you switch Qt from stable to 5.3
[20:35] <apachelogger> shadeslayer: all hail mario, tell him to mind the beer if he is still there
[20:35] <apachelogger> shadeslayer: also where what when
[20:35] <shadeslayer> here okular now
[20:36] <apachelogger> that's the wrong god
[20:36] <apachelogger> find the right one
[20:36] <shadeslayer> the one true god
[20:36] <shadeslayer> wine
[20:36] <shadeslayer> or well
[20:36] <shadeslayer> alcohol of any sorts
[20:37] <shadeslayer> wine makes me sleepy
[20:48] <Riddell> apachelogger: por que muchos cosas hablar!
[22:40] <soee> hmm i wonder why so many distros build their own appcenter
[22:40] <soee> now i read this http://lmelinux.net/2014/08/13/interview-daniel-fore-founder-elementary-os/
[22:40] <soee> and eos also will have its own
[22:41] <soee> why there cant be one cool appcenter :>
[22:43] <apachelogger> because programming is hard, distro developers rather go shopping intead
[22:43] <apachelogger> also they need to convince themselves that they are different from other distributions, so there's that
[23:10] <ScottK> Riddell: multiarch let's you run 32 bit stuff on 64 bit.
[23:10]  * ScottK runs and amd64 kernel with a 32 bit user space.
[23:11] <ScottK> It made it possible for ia32libs to go away.