[07:34] <lordievader> Good morning.
[08:35] <soee> Riddell: ok i can run the configuration module by using #kcmshell kcm_kscreen but it does not work as it should
[08:35] <soee> http://paste.ubuntu.com/7818634/
[08:35] <soee> also if i have secon monitor connected through hdmi, plasmashell crashes @start
[10:03] <BluesKaj> Hiyas all
[10:29] <Riddell> soee: report a bug on that crash then
[10:32] <BluesKaj> stuck in dependency hell cgmanager :/
[10:33] <BluesKaj> on my desktop pc 
[10:36] <BluesKaj> that damn systemd is mucking up my system and I'm not even using it
[10:46] <yofel> BluesKaj: for now, you could edit /var/lib/dpkg/info/cgmanager.prerm and replace the "exit $?" with "exit 0"
[10:47] <yofel> then try to upgrade again, which will again fail. After that do the same changes to cgmanager.postinst and run --configure
[10:47] <yofel> that's how I get around the mess on my systemd test system...
[10:48] <BluesKaj> yofel,  ok, thanks, will try that
[10:52] <soee> lates upgrades ask me to use lightdm or sddm
[10:52] <soee> sddm is supported already ?
[10:53] <yofel> sddm is in next, IIRC with a few rough edges but it should work
[10:54] <soee> but also might break right ? :)
[10:55] <soee> anyway will try ot
[11:02] <soee> sddm fails
[11:02] <soee> back on lightdm
[11:08]  * yofel install kubuntu-plasma5-desktop on his eeepc and is curious what'll happen
[11:08] <yofel> *installs
[11:11]  * yofel notes that you can't log out anymore if you do that
[11:14]  * BluesKaj thinks it's still too early for plasma5 on this laptop...don't think I'll attempt it on the desktop
[11:14] <yofel> hm, sddm is indeed rubbish :/
[11:15] <yofel> great... I have no session that I could log into @_@
[11:17] <yofel> oh duh, some updates are missing
[11:19] <rick_timmis> Oh dear I'm stuck
[11:20] <rick_timmis> I'm practicing packaging, and debuild -S -sa complains not private GPG key available. I have check gpg --edit-keys and it says my Secret key is available. I'm getting confused can anyone help ?
[11:21] <yofel> does the person in the changelog match your gpg key information?
[11:21] <rick_timmis> Ah I don't know, will check
[11:22] <rick_timmis> Hmm it does in the /debian/changelog
[11:23] <yofel> could you please pastebin the full debuild output?
[11:23] <rick_timmis> I am playing with Ed
[11:23] <rick_timmis> Sure yofel, just runing it again
[11:23] <rick_timmis> kubotu: paste bin ?
[11:24] <yofel> !paste
[11:25]  * yofel sees plasma5 \o/
[11:26] <rick_timmis> yofel: Here is the output http://paste.ubuntu.com/7819136/
[11:26] <rick_timmis> !ircbot
[11:26] <rick_timmis> !ubottu
[11:27] <rick_timmis> !kubotu
[11:27] <yofel> ~me
[11:27] <yofel> hm, or not
[11:27] <yofel> rick_timmis: is that in a chroot?
[11:28] <rick_timmis> I don't believe so. I haven't run pbuilder yet.
[11:28] <rick_timmis> yofel: /home/rick/ubuntu-playground/ed-1.10
[11:28] <rick_timmis> el: 
[11:29] <yofel> and gpg --list-keys shows the key for Rick Timmis <Rick.Timmis@Abazander.com> ?
[11:30] <rick_timmis> yofel: http://paste.ubuntu.com/7819155/
[11:31] <yofel> "Rick Timmis (Sick Rimmit)" != "Rick Timmis", that matters ^^
[11:31] <yofel> what you can do:
[11:31] <rick_timmis> Ah ha OK
[11:31] <yofel> put DEBSIGN_KEYID=<id> in ~/.devscripts
[11:32] <yofel> e.g. I have DEBSIGN_KEYID=2EC0A9FF in there
[11:32] <yofel> that'll tell debsign to always use that key no matter what the changelog says
[11:32] <rick_timmis> OK I believe I understand you,
[11:32] <rick_timmis> lets try it
[11:40] <rick_timmis> Yay Success!! Woo Hoo
[11:40] <rick_timmis> yofel: Thank you, I would never have worked that out myself
[11:41] <yofel> that's trick to figure out ^^
[11:41] <yofel> *tricky
[11:41] <yofel> I actually went and re-created my key when that happened to me a couple years ago :D
[11:41] <rick_timmis> Well that was going to be my next idea
[11:42] <rick_timmis> But now I am wondering, perhaps I need to set my environment so that the changelog entry that gets created matches the gpgkey output ?
[11:42] <yofel> well, changing your DEBFULLNAME to match it would be enough
[11:43] <rick_timmis> Perhaps DEBF
[11:43] <rick_timmis> I you got there before me
[11:43] <rick_timmis> OK. I'm going to try that, so it's consistent for other later too
[11:46] <BluesKaj> yofel,  decided to reinstall the OS to / , your edits worked as far as upgrading was concerned, but I lost access to the desktop and couldn't get a VT/TTY to start the dm or X
[11:47] <BluesKaj> my system was already pretty messed up anyway 
[11:48] <yofel> dang, sounds like bug 1343802
[11:49] <BluesKaj> yofel,  I wasn't booting with systemd tho
[11:50] <yofel> the error output earlier looked like you did though... which is the confusing part :/
[11:53] <BluesKaj> well , I had tried systemd, but due to the probs with cgmanager and systemd-shim depends I re-edited grub and removed the systemd init string at quiet spalsh, and updated grub 
[11:55] <rick_timmis> yofel: Bingo!! That's sorted. Thank you again.
[12:04] <BluesKaj> bbl
[13:05] <Riddell> sgclark: putting into proposed
[13:06] <sgclark> Riddell: thanks!
[13:19] <Riddell> sgclark: builds fine locally, uploaded!
[13:19] <sgclark> Riddell: thanks :)
[13:43] <sgclark> Riddell: hmm this could pose interesting problems, it needs baloo-dev 4.13.90
[13:49] <BluesKaj> dist
[13:49] <BluesKaj> oops wrong KB
[13:50] <Riddell> sgclark: is that ready to upload?
[13:52] <Riddell> oh it needs pimlibs
[13:52] <Riddell> this could go on
[13:52] <Riddell> and kfilemetadata
[13:56] <Riddell> -- The following REQUIRED packages have not been found:
[13:56] <Riddell> * Akonadi (required version >= 1.12.90) , Akonadi server libraries , <http://pim.kde.org/akonadi>
[13:56] <Riddell> and kdepimlibs needs that new akonadi
[13:57] <Riddell> kfilemetadata up
[13:58] <sgclark> Riddell: hmm that new akonadi is up..
[13:58] <Riddell> but only in the PPA no?
[13:58] <sgclark> in ninjas that is
[13:59] <sgclark> right
[13:59] <sgclark> but packaged :)
[13:59] <Riddell> so akonadi -> kdepimlibs -> baloo -> nepomuk-core
[13:59] <Riddell> what a lot of pain for an obsolete technology
[13:59] <sgclark> lol I know :(
[13:59] <sgclark> but a bulk of the remaining packages need it :(
[14:00] <sgclark> kdepimlibs will also need libgapi and libkolab that I packaged in ninjas
[14:00] <sgclark> Riddell: ^
[14:00]  * sgclark has been busy
[14:01] <Riddell> jings you have
[14:01] <Riddell> is there a new libkolabxml too? they usually go together
[14:02] <sgclark> oh, did not check, didnt cry for it
[14:03] <Riddell> seems it's only kdepim-runtime that needs those libs, kdepimlibs fine without
[14:03] <sgclark> ahh ok 
[14:04] <Riddell> no new libkolabxml
[14:05] <sgclark> figured, it usually wont build without
[14:11] <Riddell> akonadi up
[14:12] <Riddell> rick_timmis: going to become an elite kubuntu ninja?
[14:13] <rick_timmis> Riddell: I am working on it, trying to get Ubuntu packaging in my toolkit
[14:42] <Riddell> sgclark: all uploaded, hope that neopmuk-core will build now
[14:43] <sgclark> Riddell: getting fails :( akonadi depends on akondai-server.. but will not be installed, which is odd as they are in same package..
[14:43] <sgclark> Riddell: seems to be arm
[14:43] <sgclark> Riddell: seems to be arm*
[14:44] <ScottK> Arch all versus arch any?
[14:44] <sgclark> Riddell: and baloo powerpc same failure
[14:57] <ScottK> sgclark: Usually failures like that are because the -dev package is arch all (and built with i386) and the lib is arch all and wasn't available yet for that arch.
[14:58] <ScottK> I retry will solve that, but no point until kdepimlibs-dev is available so it won't just depwait.
[14:58] <ScottK> s/I/A//
[14:58] <kubotu> ScottK meant: "A retry will solve that, but no point until kdepimlibs-dev is available so it won't just depwait."
[14:59] <sgclark> ScottK: libakonadi-dev is any
[14:59] <ScottK> OK, something else in the stack probably then.
[15:00] <ScottK> In any case, for things like that which are only one arch, a retry once things are a little more built almost always works.
[15:00] <sgclark> ScottK: ok thanks. Riddell: will need to retry when kdepimlibs is ready, I do not have the powers there :)
[15:02] <ScottK> Bottom line, it's something to keep track of, but not really worry about
[15:02] <ScottK> Anyone who can upload can retry.
[15:03] <sgclark> ScottK: I do not believe I can upload to proposed
[15:03] <ScottK> No.  You need to be an Ubuntu developer of the right kind (e.g. kubuntu-dev)
[15:03] <ScottK> You'll get there though.
[15:03] <sgclark> :)
[15:14] <sgclark> Riddell: sorry I have run out of time for today :( I will continue my efforts tomorrow.
[17:28]  * rick_timmis mind boggles with oodles of interlinked documentation 
[17:29] <rick_timmis> So I packaged ed-1.10, and got a resulting .deb
[17:30] <rick_timmis> I went on to have a crack at wget-1.15, but debuild is failing with a missing make file
[17:31] <rick_timmis> I'm confused, as I understand it pbuilder will do the build of the package, so I don't need to do configure && make
[17:31] <rick_timmis> at this point I vanished into the abyss of Debian documentation, and now my brain hurts
[17:32] <yofel> rick_timmis: buildlog please?
[17:32] <yofel> maybe I can spot what's wrong
[17:32] <rick_timmis> !paste
[17:33] <yofel> also useful:
[17:33] <rick_timmis> http://paste.ubuntu.com/7820735/
[17:33] <yofel> !pastebinit
[17:34] <yofel> that is... fun
[17:37] <yofel> rick_timmis: the archive wget package has some manual cleanup handling and I guess you're missing that autotools command there
[17:38] <rick_timmis> yofel: Right, so I didn't understand any of what you said there, which suggest I am biting off more than I can chew at this point
[17:39] <yofel> not really, it's just that wget seems to need some manual intervention in the build process as debhelper can't figure this out by itself
[17:39] <rick_timmis> yofel: Ah OK I see
[17:40] <rick_timmis> yofel: Perhaps I should stop at this point with wget. What I am really trying to achieve, is just some practice a building a package, so I increase my confidence with the tools
[17:41] <rick_timmis> I am trying to get to a point where I can Bug Fix, and repackage, working from Kubuntu-Bugs on lp~ 
[17:42] <yofel> for that it does help to look at various packages as there's several ways how a rules file can be written. For us you'll probably want to get familiar with kde packages and dh7 style rules first
[17:43] <rick_timmis> Hmmm OK, well I had fancied having a crack at packaging Rekonq, but perhaps you could suggest something I coudl have a practice with ?
[17:43] <rick_timmis> i.e perhaps your aware of something that builds in a pretty straight forward manner ?
[17:44] <yofel> well, rekonq is pretty straight forward.. and is one of the simpler cmake packages that don't use dhmk
[17:44] <yofel> (dhmk is the build system for the kde sc from pkg-kde-tools)
[17:45] <rick_timmis> OK, any pointers on docs to look at ?
[17:45] <rick_timmis> !dhmk
[17:45] <rick_timmis> !pkg-kde-tools
[17:46] <yofel> not really for beginners, but you can install pkg-kde-tools and look at /usr/share/pkg-kde-tools/qt-kde-team/2/README
[17:47] <rick_timmis> yofel: Hey OK, and thanks again for your help
[17:47] <yofel> you can see in our kde packages how it's used, kde-workspace being one that's not completely simple
[19:38] <ScottK> Riddell: Rejecting baloo out of binary New.  libbalooqueryparser4 is empty.
[19:39] <Riddell> meh
[19:39] <Riddell> hmm
[19:39] <Riddell> missing .install file probably
[19:41] <Riddell> yep, uploaded again
[19:42] <BluesKaj> systemd-shim and cgmanager still have broken dependencies ?
[19:43] <Riddell> sorry not our area
[19:43] <BluesKaj> yeah, realized that right after typing the question:)
[20:08] <yofel> ScottK: any chance you can look at ksnakeduel in proposed?
[20:18] <ScottK> yofel: Should go now.
[20:19] <yofel> thanks a lot!
[20:20] <ScottK> Riddell: baloo accepted.
[20:32] <rick_timmis> Me again
[20:33] <rick_timmis> So I'm looking at Kubuntu-Bugs.. https://bugs.launchpad.net/ubuntu/+source/kdegames/+bug/880555
[20:34] <rick_timmis> This report is status New, and yet was filed in 2011,  which makes me ask am I missing something, or are we short on Bug triage workers ?
[20:34] <yofel> the latter
[20:35] <rick_timmis> Ah OK, So could I be useful, by having a crack at triaging some of this stuff ?
[20:37] <rick_timmis> stupid question, and irrelevant. Of course I could
[20:37] <yofel> hehe, anything will help there :)
[20:37] <yofel> see https://community.kde.org/Kubuntu/Policies#Bug_Triage too
[20:43] <rick_timmis> Ah I'm getting confused again, as whilst it appears to be assigned into the Kubuntu-bugs team, it's actually a Xubuntu desktop problem when running a KDE application.
[20:44] <rick_timmis> Not that I mind helping with Ubuntu stuff, but I really want to to target my effort to Kubuntu community
[20:45] <rick_timmis> I just find all of this so confusing, and I've been chipping away at this of and on for 2 years, and I just continually got lost, confused, and disorientated. 
[20:51] <ScottK> rick_timmis: Any KDE application should work regardless of the desktop environment being run.
[20:53] <ScottK> That said, Unity uses a bunch of stuff that's different the everyone else, so Unity related bugs aren't always very fixable.
[20:54] <ScottK> That particular one might be related to the menu stuff they do.
[20:56] <rick_timmis> OK, well looking at the Bug_Triage policy, I wonder whether it should be assigned to Xubuntu team, rather than Kubuntu. However, I'm running up a VM now to see if the bug still exists..
[20:57] <rick_timmis> After spending the whole day reading docs, and breaking everything, I just want to do something, that makes me feel as though I have achieved something
[21:04] <rick_timmis> https://bugs.launchpad.net/debian/+bug/1157723
[21:05] <rick_timmis> Looking at Bug_Triage policy, it looks to me as though this bug should now be closed. It's fixed in release for Kubuntu, but remains open new for Debian.
[21:06] <rick_timmis> Triage policy suggests that one our work is done tracking should be in the upstream, and my thoughts are that an advisory post to Debian team and closure by Kubuntu_Bugs team is the corect course of action
[21:06] <rick_timmis> Sound correct ?
[21:06] <rick_timmis> s/one/once/
[21:06] <kubotu> rick_timmis: You did something wrong... Try s/you/me/ or tell me "help sed"
[21:11] <ScottK> rick_timmis: If it's a bug in Debian (which that is) you can't change it in launchpad anyway.  It's an import from the Debian BTS.  The Ubuntu task is already marked fix released.
[21:23] <rick_timmis> ScottK: OK, well I'll keep on rollin, thanks 
[21:26]  * apachelogger sighs at pyqt5
[21:45] <rick_timmis> https://bugs.launchpad.net/redshift/+bug/1008967
[21:45] <valorie> yes please
[21:45] <rick_timmis> We have this packaged and released, but Redshift still has it as New. 
[21:46] <valorie> I've wanted to try that out for a year or two
[21:46] <rick_timmis> This example might be the cause of my confusion
[21:46] <valorie> interesting
[21:47] <rick_timmis> Are we now awaiting the Redshift team to update their end of the Bug report to reflect our release, or can we ( I ) do that ?
[21:47] <valorie> do it
[21:47] <valorie> I installed it, and now I'm supposed to restart
[21:47] <valorie> !
[21:48] <valorie> anyway, close the bug with a ref to the package
[21:48] <rick_timmis> Ah yes, you could probably get away with just restarting the Xserver if you wanted to
[21:48] <rick_timmis> The redshift daemon requires an X extension, so that will need an X restart
[21:50] <valorie> I'll restart at the end of the day
[21:51] <valorie> rick_timmis: you are the answer to apachelogger's laments about no one looking at bugs
[21:53] <rick_timmis> Well I'm ready and willing to help, I'm getting very confused, but your input has lead me one step further along the path of believing "It's not me being stupid" its just the Bug Tracker is in a bit of a mess
[21:53] <apachelogger> uh
[21:53] <apachelogger> apt.progress.base.CdromProgress has broken API and no one noticed
[21:56] <valorie> I think "bit of a mess" is an understatement
[21:56] <rick_timmis> If you have a mind to, please check
[21:56] <rick_timmis> https://bugs.launchpad.net/redshift/+bug/1008967
[21:56] <rick_timmis> Does this look like I have done this update correctly
[21:57] <valorie> I'm no expert, but to me it looks lovely
[22:02] <valorie> seems that yofel forgot to mark that fix released
[22:02] <valorie> there are lots of fiddly steps in packaging
[22:03] <rick_timmis> Well the Bug count has gone from 69 -> 68, in my book that's a result
[22:03] <yofel> uh, s/yofel/Quintasan/
[22:03] <rick_timmis> I will keep on with Packaging, but I spent 10 hours on it today, and now my brain hurts
[22:04] <valorie> oops, sorry yofel
[22:04] <yofel> ^^
[22:05] <rick_timmis> It'
[22:05]  * rick_timmis scratch that wrong window
[22:09] <apachelogger> waah, the upgrader
[22:10] <apachelogger> Riddell: ubuntu-release-upgrader, good news: same minimalistic usage of kde as other stuff; bad news: the code is le shitty to begin with
[22:10] <apachelogger>         if os.path.exists("/usr/share/icons/oxygen/16x16/actions/arrow-right.png"):
[22:11] <apachelogger> Riddell: also I am not particularly sure how to handle pyqt4 support
[22:12] <apachelogger> what with upgrader from $targetseries being run on $originseries, so we'll need to retain the old version for quite a while
[22:13] <apachelogger> ah
[22:14] <apachelogger> probably some exception handling magic
[22:14] <apachelogger> and two different sets of code files, then it'd try to load the qt5 stuff first and if that fails it tries kde4
[22:15] <apachelogger> #ramblingsfrombeyondthefringe
[23:23] <valorie> redshift is nifty