[00:05] <Riddell> :)
[00:39] <ScottK> bulldog98_: Fixed the kinfocenter thing.  Thanks.
[01:19] <kubotu> ::workspace-bugs:: [1082345] dpkg: error processing /var/cache/apt/archives/kde-window-manager-common_4%3a4.9.80-0ubunt... @ https://bugs.launchpad.net/bugs/1082345 (by Marcin Juszkiewicz)
[03:27] <ScottK> svn://svn.debian.org/python-apps/packages/pymilter-milters/trunk/
[03:27] <ScottK> oops
[03:28] <ScottK> Meant to paste http://www.slideshare.net/ggreve/ec-workshop-on-frand-and-open-source
[04:05] <ScottK> Someone needs to add print-manager to the package list for the kubuntu-automation scripts
[05:02] <ScottK> afiestas: I tried to rebuild kamoso with the new libs from 4.9.80 and it fails with this error: http://paste.debian.net/211931/ is this something you've fixed already?
[05:11] <ScottK> kphotoalbum fails too (even the one from debian/experimental)
[05:11]  * ScottK will file a bug.
[05:12] <ScottK> That leaves Digikam as the major non-SC package that's entangled with getting all of 4.9.80 from proposed to release.
[05:22] <ScottK> https://bugs.kde.org/show_bug.cgi?id=310593
[05:35] <shadeslayer> ScottK: add perlkde to that
[05:35] <shadeslayer> for some reason it's not picking up akonadi
[05:35] <ScottK> I just uploaded it.
[05:35] <ScottK> jr did a patch that was in ninjas
[05:35] <shadeslayer> oh cool
[05:37] <ScottK> So I think now it's mostly a matter of waiting for powerpc to build.
[05:38] <ScottK> shadeslayer: If you wanted to start on the libs package for KDE Games, that would enable people to package a game here and there as they have time.
[05:39] <shadeslayer> okay
[05:39] <shadeslayer> the only problem is that I have to leave in another hour or so
[05:39]  * shadeslayer gives it a go anyway
[05:41] <ScottK> shadeslayer: Or you could package https://projects.kde.org/projects/playground/accessibility/libkdeaccessibilityclient so kmag works better.
[05:42] <shadeslayer> already started on libkdegames
[05:46] <ScottK> OK
[05:46] <ScottK> Fixed up the package list in kubuntu-automation.
[05:48] <shadeslayer> question, should I ship private libs with the public libs package or make a separate package called libkdegamesprivate1 and make libkdegames6 depend on that?
[05:54]  * shadeslayer bundles with public libs for now
[06:03] <ScottK> shadeslayer: I'd have suggested split.
[06:03] <ScottK> That's what we did with akonadi, IIRC>
[06:04] <shadeslayer> hmm
[06:05] <shadeslayer> well ... the do have a separate so version as well
[06:15] <shadeslayer> I'll have to go in 10 minutes, so initial packaging in lp:~rohangarg/+junk/libkdegames
[06:15] <shadeslayer> https://code.launchpad.net/~rohangarg/+junk/libkdegames
[06:15] <shadeslayer> primarily stuff like symbols and copyright is left
[07:36] <kubotu> ::workspace-bugs:: [1082345] dpkg: error processing /var/cache/apt/archives/kde-window-manager-common_4%3a4.9.80-0ubunt... @ https://bugs.launchpad.net/bugs/1082345 (by Marcin Juszkiewicz)
[09:40] <kubotu> ::workspace-bugs:: [1082604] package kde-workspace-bin 4:4.9.3-0ubuntu2 failed to install/upgrade: trying to overwrite ... @ https://bugs.launchpad.net/bugs/1082604 (by Alex Buell)
[11:41] <kubotu> ::workspace-bugs:: [1082625] package kde-workspace-bin 4:4.9.3-0ubuntu2 failed to install/upgrade: trying to overwrite ... @ https://bugs.launchpad.net/bugs/1082625 (by Christian)
[11:44] <Riddell> claydoh: able to handle this? http://paste.kde.org/613814/
[12:51] <BluesKaj> Hey all
[13:19] <mparillo> Anybody trying the new beta of KDE SC 4.10 with daily 13.04 Kubuntu Builds? Muon found the update, and after I applied it, I lost some indicator plasmoids on my panel, and the shutdown option was gone from my exit tab on the Kickoff Application Launcher.
[13:19] <mparillo> I think I am running a pretty generic Kubuntu 13.04 install, accepting all updates, and the only KDE app I am running out of the ordinary was Rekonq 1.3, which I compiled myself.
[13:43] <shadeslayer> ok, back, resuming libkdegames
[13:57] <shadeslayer> hmm odd
[14:17] <shadeslayer> anyone fancy populating debian/copyright for libkdegames? :P
[14:33] <shadeslayer> this thing has GPL v2 / GPL v2+ / LGPL-2 / LGPL-2+ / Custom license
[14:33] <shadeslayer> oh wait
[14:33] <shadeslayer> BSD as well
[14:34] <shadeslayer> I guess the only thing left is Apache and MIT
[14:39] <Mamarok> shadeslayer: I am sure there are far too many
[14:39] <shadeslayer> well ... those are the major ones :)
[14:40] <Mamarok> still, for one package? That is just absurd
[14:40] <shadeslayer> yep
[14:41] <Mamarok> espceially the v2 you can remove if there already is v2+
[14:41] <Mamarok> this is redundant
[14:41] <Mamarok> and the custon license seems like a bad idea
[14:42] <Mamarok> get in touch with the authors and ask them to sort that out, it just makes no sense at all
[14:42] <Mamarok> they can ask for help in the eV
[14:43] <shadeslayer> Mamarok: https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/revisions/master/entry/highscore/kscoredialog.h#L7
[14:43] <Mamarok> that is not even a proper license
[14:44] <shadeslayer> I agree
[14:44] <Mamarok> they really should sort that out
[14:44] <Mamarok> you can't ship a mix like that
[14:45] <Mamarok> ask in the games mailing list and make then aware that without a proper license the package can't be shipped by distributions
[14:45] <shadeslayer> since it's a lib, shouldn't it all be under LGPL?
[14:45] <Mamarok> that is to the authors to solve that, not to you
[14:45] <Mamarok> but they really have to sort that out, in that stage this is not shipable
[14:46] <Mamarok> they need to decide on a proper license
[14:46] <Mamarok> and since I don't know all the other dependencies let them sort that out
[14:47]  * shadeslayer will email the KDE Games ML then
[14:47] <Mamarok> yes, copy to kubuntu-devel
[14:48] <shadeslayer> aye
[14:48] <shadeslayer> ScottK: just to make sure, do we have such weird licenses in the repo? https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/revisions/master/entry/highscore/kscoredialog.h#L7
[14:49] <shadeslayer> hmm I wonder what the older package did
[14:50] <shadeslayer> this is a fun copyright file to look at
[14:50] <shadeslayer> it has a email conversation in it
[14:51] <shadeslayer> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/kdegames/raring/view/head:/debian/copyright#L325
[14:53] <Mamarok> oh my
[14:54] <Mamarok> and why are there copyright headers for card decks in that file? Thy should get legal counsellin, that is just totally absurd
[14:56] <Mamarok> maybe also remind then that KDE is an associate organisation of the FSFE, so legal counselling is available
[14:56] <shadeslayer> all this copyright stuff has made me hungry :]
[14:58]  * Mamarok is eating cake with tea
[14:58]  * shadeslayer has no idea what's for dinner
[14:59] <Mamarok> ask?
[15:00] <shadeslayer> I don't think anything is cooking ... 
[15:00]  * shadeslayer peeks into the kitchen
[15:01] <shadeslayer> hmm,  some leftover food from lunch ...
[15:02] <Mamarok> leftovers are usually yummy
[15:35] <ScottK> shadeslayer: That license is fine.  It's a BSD license variant.
[15:40] <Mamarok> ScottK: then it should say so
[15:41] <ScottK> Mamarok: the literal BSD license can't properly be used by anything but the University of California.
[15:41] <ScottK> (since part of the text of it is Copyright Regents of the University of California)
[15:42] <ScottK> So seeing BSDish variants is really quite common.
[15:42] <Mamarok> ScottK: that I know, but if this is a license then it should say so, with the workd "license"
[15:42] <Mamarok> word*
[15:43] <ScottK> Right.  Not arguing it's ideal, just that it's not a problem and not wildly different than a lot of other things.
[15:43] <Mamarok> still, they should make correct license headers to avoid any ambiguity
[15:43] <ScottK> When asked, I usually recommend the MIT license over BSD/some BSD variant.
[15:45] <Mamarok> ScottK: agreed, but the problem still is that they need to word their licenses correctly aka name the license explicitly
[15:46] <ScottK> I agree that would be better.
[15:47] <ScottK> There are copyrights in that file that go back to 1998.
[15:47] <ScottK> I suspect that's where the license comes from.
[15:47] <Mamarok> it is a giant mess IMO
[15:47] <ScottK> (such things used to be much more common than they are now)
[15:47] <ScottK> That would likely make it difficult to change.
[15:48] <Mamarok> and I bet there is little to no code left from the start, so it makes not much sense
[15:48] <ScottK> Could be.
[15:48] <Mamarok> but yes, if people do not adhere to s clear license structure you end up with a mess like that
[15:48] <Mamarok> s/s/a/
[15:48] <kubotu> Mamarok meant: "but yea, if people do not adhere to s clear license structure you end up with a mess like that"
[15:48] <Mamarok> oops
[15:49] <Mamarok> *a clear license structure
[15:49] <ScottK> OTOH, it's clearly a free license and compatible with other KDE licenses, so I don't see an actual problem that results from it.
[15:50] <Mamarok> well, the problem is that the text is ambiguous as it doesn't clearly state the license it is. Mind you, I talk about https://projects.kde.org/projects/kde/kdegames/libkdegames/repository/revisions/master/entry/highscore/kscoredialog.h#L7
[15:51] <ScottK> Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted ...
[15:51] <ScottK> That is sufficient.
[15:51] <ScottK> None of the following conditions render it non-free.
[15:55] <ScottK> Mamarok: The actual BSD license doesn't have the word license in it: http://opensource.org/licenses/bsd-license.php
[15:56] <Mamarok> well, once usually starts a license header with the name of the license
[15:57] <Mamarok> one*
[15:59] <Mamarok> like this: *This program is Free Software: you can redistribute it and/or modify it under the terms of the <license name>"
[16:02] <ScottK> the BSD license really doesn't work that way since there's not just one.
[16:03] <ScottK> Specifying BSD license might actually cause more confusion.
[16:05] <ScottK> Would someone else try to rebuild calligra?
[16:05] <Darkwing> Hey guys. Sorry it's been a while.
[16:05] <ScottK> We need to rebuiild it against the new kdegraphics libs and I get an unrelated build failure.
[16:05] <ScottK> Heya Darkwing.
[16:06] <Darkwing> Hye ScottK. I'm finally stable again. :D
[16:06] <ScottK> Great.
[16:16] <yofel> hey Darkwing :)
[16:18] <yofel> ScottK: what variant is that actually? 3-clause?
[16:21] <ScottK> yofel: http://opensource.org/licenses/BSD-3-Clause yes
[16:21] <yofel> k
[16:22] <Darkwing> just to give an update. I'm finally in school and I finally have a place to stay and steady internet. :)
[16:22] <Darkwing> So, I'll actually be around for this cycle.
[16:22] <yofel> good to have you back, we were a bit worried already as you've been absent for a while :)
[16:23] <Darkwing> Yeah, I was just really stuggling with life issues. 
[16:36]  * yofel tries to rebuild digikam
[16:37] <Quintasan> Darkwing: \o/
[16:37]  * Quintasan pats Darkwing
[16:38] <Quintasan> Love burndown charts
[16:38] <Quintasan> I have 2 tasks in a blueprint
[16:38] <Quintasan> done one and burndown chart says it's 33% done
[16:38] <Quintasan> :D
[16:38] <Darkwing> I need to get on board with what happened at UDS :D
[16:38] <ScottK> Quintasan: You'll need the new digikam. It's in Debian experimental, but it needs to be modified not to use the embedded libs.
[16:40] <Quintasan> ScottK: I'll need it for what?
[16:40] <ScottK> To get something that build.
[16:40]  * Quintasan doesn't follow
[16:41] <Quintasan> ScottK: Could you explain it with --verbose? :P
[16:41] <ScottK> There are API changes in the libs that Digikam uses in 4.9.80
[16:42] <ScottK> I know our current Digikam won't build with it.
[16:42] <yofel> meh, true
[16:42] <yofel> might as well package 3b3 then
[16:42] <ScottK> The digikam devs also do the kdegraphics libs, so they bundle a copy with Digikam.
[16:43] <ScottK> Since Debian doesn't have the newer graphics libs, their package uses the embedded libs.  Since we have them now, we'll need to use the system libs.
[16:43] <Quintasan> ScottK: So you want me to do that?
[16:43] <ScottK> Yes.
[16:43] <ScottK> Someone needs to.
[16:44] <yofel> Quintasan: feel free to take over bug 1045767 then
[16:44] <ScottK> We need digikam, calligra, kphotoalbum, and kamoso to build before the 4.9.0 stuff will migrate from proposed.
[16:45] <ScottK> Riddell: I deleted print-manager off the pad.  I uploaded it last night.
[16:46] <ScottK> That and the kdepim FTBFS on armhf are the major blockers for being "done" with 4.9.80
[17:12] <oy> looks like lcms2 is only available in 12.10 :-/
[17:16] <oy> will there be KDE 4.10 backports for 12.04 ?
[17:19]  * yofel fixes some more kde-workspace overwrites
[17:22] <yofel> what the hell is a kinfocenter.install.linux file o.O?
[17:22] <yofel> that's what's causing the file conflicts in the first place
[17:27] <yofel> Riddell: did those files show up in list-missing? (as you added them to the other packages for 4.9.80)
[17:30] <Quintasan> oy: Probably yes
[17:31]  * yofel out for a while
[17:36] <yofel> fun, I can't log out anymore after updating to 4.9.80
[17:36] <yofel> the window never shows up
[17:36] <yofel> gone for real now
[17:36] <oy> ok, will prepare for both cases (lcms1 only / + lcms2)
[17:49] <Riddell> yofel: mm I guess so (guessing without looking at it)
[17:49] <Riddell> kinfocenter.install.linux is files that only install on linux, not on kfreebsd or any other debian oddity
[18:26] <yofel> re
[18:27] <yofel> Riddell: if it did that would be a bug in list-missing though, not your fault
[18:27]  * yofel didn't do a test build after removing the files
[18:29] <yofel> Quintasan: are you going to do digikam now or not? If not I might look at it tomorrow, not sure if I'll have enough time though
[18:30] <Quintasan> yofel: Not today.
[18:31] <yofel> Quintasan: the bug is still assigned to me, so I would like to have a yes or no answer before we both start working on it...
[18:31] <yofel> I won't mind if you do it ^^
[18:35] <yofel> new knotify is nice :)
[18:40] <Quintasan> yofel: No.
[18:40] <yofel> ok
[18:40] <yofel> thanks
[19:06] <afiestas> ScottK: nope, can you report a bug pls?
[19:06] <ScottK> afiestas: Will do.  Thanks.
[19:11] <ScottK> afiestas: https://bugs.kde.org/show_bug.cgi?id=310618
[21:02] <mparillo> Are these instructions still current? http://developer.ubuntu.com/packaging/html/packaging-new-software.html
[21:03] <mparillo> I have successfully compiled and installed reknoq 1.3 but I am getting:  bzr: ERROR: unknown command "dh-make"
[21:03] <mparillo> In the Starting a Package section.
[21:09] <Riddell> you'll need to install dh-make
[21:09] <Riddell> oh and bzr-builddeb
[21:10] <Riddell> at least if you want to use bzr like that guide suggests, many people don't
[21:14] <mparillo> Riddell: TY. I already had dh-make installed. Installing bzr-builddeb now. Is there an easier cookbook?
[21:19] <Riddell> mparillo: well yeah, that I'm not too sure on
[21:20] <Riddell> this is the debian one http://www.debian.org/doc/manuals/maint-guide/
[21:20] <Riddell> which doesn't confuse you with bzr stuff that isn't much used
[21:20] <Riddell> but is a bit long and convoluted
[21:22] <Riddell> and of course you can ask here or in #ubuntu-motu
[21:28] <mparillo> Thx, and I do not want to slow you down on the KDE SC 4.10 beta. But, installing builddeb helped me get to the next error message.
[21:28] <mparillo> bzr dh-make rekonq 1.3 rekonq-1.3.tar.bz2
[21:28] <mparillo> bzr: ERROR: Either run the command from an existing branch of upstream, or move rekonq aside and a new branch will be created there.
[21:34] <yofel> mparillo: I don't know what that error means as I don't use bzr for that, but why aren't you basing it off the existing package?
[21:36] <mparillo> Because I was following the directions like a monkey? 
[21:37] <mparillo> The existing Rekonq package is 1.1, and I have now compiled 1.3. 
[21:41] <BluesKaj> mparillo, I wish rekonq the best , but I'm still skeptical 
[21:41] <yofel> hm, uscan gives me 1.70 :/
[21:43] <mparillo> 1.70 is the beta for Rekonq 2. I tried it, but it was way too unstable, so I dropped back to 1.3.
[21:47]  * yofel gives it a try
[21:48] <yofel> and the new knotify can't handle more text than it's window can display. It just cuts it off
[21:49] <yofel> kubotu: newversion rekonq 1.70
[21:49] <mparillo> To see why I think 1.70 is the beta for Rekonq 2, look at the target for taste it now from: http://rekonq.kde.org/
[21:49] <kubotu> https://bugs.launchpad.net/bugs/1082738
[21:49] <yofel> from the verison 1.70 sounds rather like alpha
[21:49] <yofel> well, the site does say tech preview
[21:50] <mparillo> 1.70 certainly did not seem very stable enough for me.
[21:51] <yofel>  Coming stable for xmas...
[21:51] <yofel> let's see what comes out of it
[21:51] <yofel> I'll stuff a package into the experimental ppa if someone wants to try it
[21:51] <yofel> raring should rather get 1.3 so we can backport it
[21:52] <yofel> mparillo: I can take you through the old-style package update process
[21:52] <yofel> no idea how that's done with UDD and bzr
[21:54] <mparillo> Not to sound too ungrateful, but I will be in and out. But I am ready for step 1.
[21:55] <yofel> rekonq shouldn't take too long
[21:56] <Riddell> get the tar, ensure it follows the right name pattern, apt-get source rekonq to get the current package, copy over the debian/ directory, dch for a new changelog and debuild to build it
[21:56] <yofel> <quote Riddell />
[22:06] <mparillo> OK, now I have tars for both 1.1 and 1.3.  1.1 has the debian/directory (because it was from apt-get source?), but 1.3 does not (because it came from git clone?)
[22:08] <yofel> mparillo: 1.1 has the debian/ dir because it's from the archive, yes.
[22:09] <yofel> 1.3 shouldn't be from git, but the unpacked tarball. Which won't have the packaging as that's distribution-specific
[22:09] <yofel> copy the debian folder from 1.1 over to 1.3 and add a new changelog entry for 1.3
[22:43] <mparillo> OK, I added a new changelog entry for 1.3 at the top of debian/changelog
[22:44] <mparillo> but I did it using kate. Was that a mistake. I see upwards Riddell says use dch
[22:45] <Riddell> doesn't matter but dch will give you the template so you don't have to do any copy and paste
[22:50] <mparillo> OK, I deleted the 1.3/debian directory, and recopied the 1.1/debian directory.
[22:53] <mparillo> It seemed to be about the same thing, this time using nano (my choice). Now I use debuild from my rekonq 1.3 directory?
[22:57] <Riddell> mparillo: yep that'll do the package build
[23:02] <mparillo> hmm I have a rekonq-1.3.tar.bz2, but debuild was hoping to find rekonq_1.3.orig.tar.bz2
[23:05] <Riddell> mparillo: mv is a handy command in these situations :)
[23:05] <yofel> rename it
[23:05] <Riddell> packaging is very paticular about the name of the tar
[23:11] <mparillo> Not only does it need to be named correctly, it needs to be in the parent directory. I suppose my next step is to apt-get install pkg-kde-tools ? It is a build dependency?
[23:11] <yofel> you can run 'sudo apt-get build-dep rekonq' to get the build-deps for the archive package in one go
[23:12] <yofel> (i.e. that'll get the build-deps that 1.1 needed)
[23:15] <Riddell> mparillo: I hope you're taking notes :)
[23:18] <mparillo> If I succeed, I will try to edit this IRC log. Next time I ask for a cookbook, somebody might suggest I draft one.
[23:22] <mparillo> Alas, I have far too many fatal errors, even for a pastebin. I guess I have wasted all your time, but thank you both.
[23:22] <yofel> feel free to put them on paste.ubuntu.com anyway
[23:28] <mparillo> The errors overflowed my Konsole buffer, but here is the end: http://paste.ubuntu.com/1383957/
[23:40] <yofel> mparillo: somehow your rekonq-1.3 folder doesn't match with the tarball contents and you left the build/ folder in it
[23:40] <yofel> unpack the tar again, copy the debian folder over and try debuild again