[00:00] <ahoneybun> yea I just like to not wait till the last min
[00:03] <ahoneybun> we are getting noticed thats for sure
[00:10] <valorie> good work tends to do that!
[00:13] <valorie> now, dinner
[00:13] <valorie> ttyl
[01:11] <ahoneybun> palasso_: ping
[01:11] <ahoneybun> palasso_: is this you? https://plus.google.com/113434423178207628891/posts
[01:25] <ahoneybun> valorie: 
[01:29] <ahoneybun> dantti: 
[01:29] <ahoneybun> Darkwing: 
[01:29] <ahoneybun> dantti: sorry wrong person
[02:01] <ahoneybun> himcesjf: hello
[03:06] <himcesjf> Hey
[03:06] <himcesjf> Hi ahoneybun
[03:12] <shadeslayer> morning
[03:39] <ahoneybun> himcesjf: hi
[03:39] <ahoneybun> shadeslayer: late night here
[03:40] <ahoneybun> himcesjf: do you have a google plus page?
[04:00] <shadeslayer> dafuq
[04:00] <shadeslayer> W: Failed to fetch https://private-ppa.launchpad.net/kubuntu-ninjas/ppa/ubuntu/dists/saucy/main/binary-amd64/Packages  
[05:35] <lordievader> Great link about the sysadmins, valorie :D
[05:38] <palasso> ahoneybun, yeah that's me though I don't use it often ;)
[05:41] <shadeslayer> Riddell: ping
[05:47] <ScottK> Riddell: Apparently Canonical do think they own the binaries.  http://www.canonical.com/intellectual-property-policy claims you need to recompile binaries if you want to redistribute modified versions of Ubuntu.
[05:52] <shadeslayer> ScottK: it also says "The disk, CD, installer and system images, together with Ubuntu packages and binary files, are in many cases copyright of Canonical "
[05:52] <shadeslayer> many cases? like what?
[05:52] <shadeslayer> does that apply to only unity stuff?
[05:53] <shadeslayer> Riddell: I can't figure out how to start an ec2 instance :S
[05:53] <shadeslayer> something is going wrong with key.pem
[06:26] <soee> good morning
[08:46] <Riddell> ScottK: yeah I know, which is nonsense and very objectionable
[08:47] <Riddell> shadeslayer: what are you doing?
[08:48] <apachelogger> shadeslayer: I believe they mean ubiquity/unity/casper/etc.
[08:49] <shadeslayer> Riddell: I tried ec2-run-instances ami-6f951d6e -t m1.small --region ap-northeast-1 --key key
[08:49] <shadeslayer> but that didn't work
[08:50] <Riddell> "Client.InvalidKeyPair.NotFound: The key pair 'key' does not exist"  uh oh
[08:51] <Riddell> shadeslayer: oh ap-northeast-1
[08:51] <shadeslayer> hm?
[08:51] <Riddell> shadeslayer: keys are different for each ec2 regions
[08:51] <shadeslayer> ahhhh
[08:51] <Riddell> I've only made them for us east
[08:51] <shadeslayer> ahhh
[08:51] <shadeslayer> I didn't know that
[08:52] <shadeslayer> okay, anyway, don't need one now
[08:52] <shadeslayer> I was trying to figure out UTAH
[08:52] <Riddell> UTAH?
[08:53] <shadeslayer> Ubuntu Testing Automated Harness
[08:53] <shadeslayer> I think ...
[08:55] <Peace-> guys i ahve asked to krita devs and they said that it's the plasmoid that has a bug 
[08:55] <Peace-> and it's the widget menu bar 
[08:55] <Peace-> it doesn't work properly with krita sometimes 
[08:56] <Peace-> Riddell: http://www.youtube.com/watch?v=-zafY8ZbBoE  bug of krita and menu bar
[08:59] <shadeslayer> Riddell: btw I think you forgot to bzr add some files while merging, I fixed those
[09:00] <shadeslayer> for eg. in kiten
[09:02] <apachelogger> agateau: who maintains menubar?
[09:09] <apachelogger> :@
[09:09] <apachelogger> locale setting is not working
[09:09] <apachelogger> as expected
[09:10] <apachelogger> Riddell: I really don't see how we'd correctly get from KDE l10n settings to linux locale setitings
[09:10] <apachelogger> they are just so different
[09:16] <Riddell> apachelogger: ug, why KDE why?!
[09:16] <apachelogger> KDE is too mighty
[09:16] <apachelogger> Linux is too dumb
[09:20] <apachelogger> yofel: oh, btw, someone at some point mentioned that the qt meta git repo tends to break because of their shitty CI
[09:21] <apachelogger> e.g. submodules hashes not existing
[09:21] <apachelogger> so I guess atomic packaging may be more sensible
[10:00] <jussi> apachelogger: ScottK shadeslayer et al, the flags are now correctly set
[10:00] <apachelogger> jussi: thank you
[10:00] <jussi> yw
[10:01] <Riddell> flags?
[10:03] <apachelogger> Riddell: channel flags... new council to be op, former council to not be op
[10:04] <shadeslayer> lthx
[10:04]  * shadeslayer checks
[10:04] <shadeslayer> jussi: * #kubuntu: You're not a channel operator 
[10:04] <shadeslayer> :S
[10:05] <jussi> shadeslayer: /msg chanserv op #kubuntu
[10:05] <jussi> shadeslayer: /msg chanserv op #kubuntu shadeslayer
[10:05] <shadeslayer> so quassel is broken
[10:06] <jussi> !opguide
[10:06] <jussi> no.... 
[10:06] <shadeslayer> jussi: "Give op status" doesn't work :P
[10:06] <shadeslayer> I suppose it only works if you're currently op'd
[10:06] <jussi> shadeslayer: to give op status y.. yes
[10:07] <apachelogger> msg chanserv op #kubuntu-devel
[10:07] <apachelogger> u noob :P
[10:13] <agateau> apachelogger: maintainers of my former appmenu stuff is Cédric Bellegarde
[10:13] <agateau> apachelogger: gnumdk on irc
[10:32] <yofel> \o/
[10:33] <yofel> thanks jussi
[10:39] <apachelogger> oh a yofel
[10:40] <apachelogger> yofel: how should we handle recipes for neon kf5?
[10:40] <apachelogger> I was thinking ... if we have one big branch with all the packaging we could just as well drop the recipes in there
[10:40] <apachelogger> e.g. qtbase.cfg qtbase/ phonon4qt5.cfg phonon4qt5/
[10:41] <apachelogger> also how to do the recipe definition ...
[10:41] <apachelogger> we could have simple ruby modules as recipes (gives flexibility of writing arbitrary codez within the module)
[10:41] <apachelogger> or we could have simple shell modules (gives equal amounts of flexibility but since the builder is ruby ... :P)
[10:42] <apachelogger> or we could have string markup like launchpad (le crap as it requires a parser for no good reason...)
[10:44] <apachelogger> or we could have some accepted information container format like json (would be between silly markup and raw code modules - having the flexibility but also not having to write code strictly speaking)
[10:44] <apachelogger> pick your poison please :P
[10:48] <yofel> putting the recipes with the packaging is fine with me.
[10:48] <yofel> As for the recipes, feel free to use ruby if you already wrote the rest in ruby. That can be turned into something shell-callable easy enough
[10:48] <apachelogger> generally it will work like this: builder creates/updates pbuilder -> executes builder, calling builder itself inside pbuilder -> pbuilded builder munches on recipes (pending decision on how that hsould happen) -> updates bzr/git cache -> merges in build directory -> bumps version -> pbuilder-satisfies deps -> builds src -> uploads [repeats for each package]
[10:48] <yofel> launchpad markup only makes sense with the parser from bzr dailydeb, and I don't quite get what you want to do with json
[10:49] <apachelogger> so... the envrionment the sources are built in is clean in general but not recreated for each source for performance reason
[10:50] <apachelogger> yofel: json being the more reasonable approach to the markup business
[10:50] <yofel> how do plan to update the bzr/git cache from inside pbuilder? (bind mount the cache dir?)
[10:50] <apachelogger> yes
[10:51] <apachelogger> builder.rb build/ cache/git/ cache/bzr/
[10:51] <apachelogger> @args = "--basetgz '#{BASE}/#{POCKET}.tar.xz' --compressprog xz --distribution #{POCKET} --extrapackages '#{EXTRAPKGS}' --bindmounts #{BASE}"
[10:51]  * yofel puts a note somewhere to learn ruby
[10:52] <apachelogger> eh, builder should be easy to read :P
[10:52] <apachelogger> mostly it's just a shell script using classes
[10:52] <apachelogger> http://paste.kde.org/757388/
[10:52] <yofel> I might want to do something else than reading every now and then :P
[10:53] <yofel> ah, looks easy enough indeed
[10:53] <apachelogger> 208 to 214 would be approximately what a package recipe would loook like
[10:54] <apachelogger> (less ugly, but you'd create your copy jobs to copy repos or arbitrary paths around)
[10:59] <yofel> looks reasonable enough to me
[11:03] <yofel> apachelogger: what might  be needed for KF5 would be a way to make a source depend on the same-day version of the previous tier uploads
[11:05] <apachelogger> yeah, variable substitution like in kde-l10n-common I'd say
[11:05] <yofel> right, something like that
[11:06] <apachelogger> just another job ;)
[11:08] <yofel> apachelogger: is the kf5 builder stuff in a branch somewhere?
[11:08] <apachelogger> nope
[11:09] <apachelogger> just save the paste as builder somewhere and run it :P
[11:09] <apachelogger> won't produce results though as stuff is commented out
[11:09] <yofel> lol, use gist then ^^
[11:09] <apachelogger> whatever that is :P
[11:10] <yofel> though you could just put it into the project-neon repo
[11:10] <apachelogger> first it needs to do something :P
[11:10] <yofel> never used gist.github.com?
[11:10] <apachelogger> no
[11:10] <apachelogger> I tend to not use github
[11:11] <apachelogger> (fortunately I need to for work reasons)
[11:11] <yofel> ah. imagine pastebin with git repo
[11:11] <apachelogger> what'd be the point of that?
[11:11] <apachelogger> I'd just put it in a repo
[11:11] <yofel> dunno, but people still use it ^^
[11:11] <apachelogger> silly people
[11:12] <apachelogger> or rather, browser people :P
[11:12] <apachelogger> supposedly diffing is the only useful thing
[11:33] <Riddell> apachelogger: so medibuntu decss on vlc server?
[11:34] <apachelogger> yes
[11:34] <markey> Riddell: so there seem to be serious issues with QtScript on Ubuntu. Amarok crashes left and right, and the BT is always deep in QtScript JIT code
[11:35] <markey> on Gentoo this doesn't seem to happen at all
[11:35] <markey> here is one bug report: https://bugs.kde.org/show_bug.cgi?id=261839
[11:36] <markey> sometimes I can't even get it to start, when Resume Playback on Start is enabled
[11:36] <apachelogger> I spy different backtraces
[11:37] <Riddell> QtScript is some scary foo
[11:37] <apachelogger> and outdated Qt in the prominent ones
[11:37] <markey> yes it is
[11:37] <markey> apachelogger: check the last comment by me, it's a recent BT
[11:37] <markey> with Raring
[11:37] <apachelogger> it's also different from what the previous backtraces head
[11:38] <apachelogger> *had
[11:38] <markey> apachelogger: there are several different crashes, but all in QtScript
[11:38] <apachelogger> so?
[11:38] <markey> well, something is wrong with QtScript
[11:38] <markey> or with the QtScript bindings
[11:40] <apachelogger> *shrug*
[11:42] <Mamarok> shrugging is not nice, folks, really, this needs to be fixed
[11:42] <apachelogger> what needs to be fixed?
[11:43] <Mamarok> the Kubuntu QtScript package, as this is a very Kubuntu specific bug, can't be reproduced on other distros
[11:43] <apachelogger> there are 3 distinct crashes in that report.....
[11:43] <apachelogger> and the majority of them on an old Qt
[11:43] <Mamarok> apachelogger: don't look at the old stuff, only look at thre recent reports
[11:44] <Mamarok> markeyŝ backtraces are all recent
[11:44] <apachelogger> and incomplete
[11:46] <Mamarok> apachelogger: the new ones are not incomplete
[11:46] <Mamarok> again, look at the most recent backtraces
[11:46] <apachelogger> I am reasonable certain that amarok has more than one thread
[11:47] <Mamarok> what the heck are you talking about?
[11:47] <Mamarok> the relevant parts are there, stop being a dick
[11:47] <apachelogger> yeah
[11:47] <apachelogger> so here is the thing
[11:48] <apachelogger> if you want someone else to look at stuff
[11:48] <apachelogger> then you should provide all the information
[11:48] <apachelogger> right now I see a backtrace with one thread
[11:48] <Mamarok> markey: ^
[11:48] <apachelogger> and I happen to know that the qtscript jit shit had at least one crash in the past that was in fact thread related
[11:48] <apachelogger> so showing me one thread makes me go: "that backtrace aint complete" because it is not complete...
[11:49] <markey> here you go: http://paste.ubuntu.com/5729104/
[11:50] <apachelogger> markey: dpkg-query -l libqt4-script
[11:51] <markey> here's the output: http://pastie.org/8000126
[12:00] <soee> hiho, kde 4.10.4 is scheduled for this week >
[12:00] <soee> ?
[12:00] <apachelogger> markey: no failed assert?
[12:01] <Mamarok> soee: was this a statement or a question?
[12:02] <markey> apachelogger: no assert, nope
[12:02] <soee> Mamarok, the ? sign is the answer for your question :0
[12:02] <soee> :)
[12:03] <shadeslayer> soee: http://kyofel.dyndns.org/kubuntu/build_status_4.10.4_saucy.html
[12:03] <shadeslayer> kdepim fails because of boost weirdness
[12:04] <soee> shadeslayer, so saucy first than backports ?
[12:04] <shadeslayer> yes
[12:04] <shadeslayer> files changed around quite a bit
[12:04] <shadeslayer> which is why I haven't uploaded for raring
[12:04] <soee> shadeslayer, ok thank you for the info
[12:04] <shadeslayer> fix saucy, then we won't have to fix raring, quantal and precise
[12:04] <soee> ;o
[12:04] <shadeslayer> s/fix/upload
[12:04] <shadeslayer> anyway
[12:05] <shadeslayer> -./usr/share/icons/hicolor/80x80/apps/khangman-harmattan.png
[12:05] <shadeslayer> whut
[12:05] <apachelogger> -.-
[12:09] <shadeslayer> yofel: apparently ubuntu has had ddebs for some time
[12:09] <shadeslayer> http://ddebs.ubuntu.com/
[12:09] <shadeslayer> and soyuz will have ddebs soonish
[12:23] <apachelogger> markey: which scripts and applets do you have?
[12:23] <Peace-> apachelogger: do you know how to debug ksplashqml ?
[12:23] <apachelogger> debug?
[12:24] <apachelogger> amarok
[12:24] <Peace-> apachelogger: now to understand if it look well and if the code is good i am using the kcm module to test the theme 
[12:24] <Peace-> isn't there another way ?
[12:25] <markey> apachelogger: "LyricWiki", "Cool-Streams", "LibriVox", "Free Music Charts"
[12:25] <shadeslayer> Riddell: want to take over 4.10.4 for saucy? I'm done for the day :)
[12:25] <markey> apachelogger: it's easy to reproduce when you enable "Resume Playback on Start"
[12:26] <apachelogger> markey: trying that
[12:26] <markey> and have it start playing stuff right away
[12:26] <apachelogger> so far no luck
[12:26] <Riddell> shadeslayer: mm can do, much more to do?
[12:26] <shadeslayer> not really
[12:26] <markey> I think this "Free Music Charts" script triggers  crashing a lot
[12:27] <apachelogger> markey: thing is... there was upstream breakage in a similar call chain which should not happen in 4.8.4
[12:27] <shadeslayer> just 3-4 packages + oxygen-icons and kajongg I think
[12:27] <shadeslayer> Riddell: http://kyofel.dyndns.org/kubuntu/build_status_4.10.4_saucy.html
[12:27] <apachelogger> markey: *** Error in `amarok': double free or corruption (!prev): 0x0000000000a55170 ***
[12:27] <apachelogger> on exit
[12:27] <markey> hm
[12:27] <markey> I don't get that on exit
[12:27] <apachelogger> markey: which applets do you have in teh context view?
[12:27] <shadeslayer> Riddell: it's not as bad as it looks on that page
[12:28] <shadeslayer> apachelogger: that's from pgst
[12:28] <markey> apachelogger: Current Track, Analyzer, Wikipedia, Lyrics
[12:28] <shadeslayer> well
[12:28] <shadeslayer> apachelogger: it only happens with pgst 1.0
[12:28] <shadeslayer> and hurray, you get that too
[12:28] <apachelogger> oh right, gstreamer
[12:28] <markey> yep
[12:28] <markey> pGST
[12:28] <shadeslayer> haven't been able to debug that
[12:28] <apachelogger> whatwhatwhat
[12:28] <apachelogger> markey: you are on pgst1?
[12:28] <apachelogger> ah
[12:28] <markey> apachelogger: using default from Raring
[12:28] <apachelogger> shadeslayer: the double free you mean?
[12:29] <shadeslayer> apachelogger: yes
[12:29] <apachelogger> kk
[12:32] <apachelogger> markey: got it
[12:33] <yofel> shadeslayer: saucy has nothing to do with raring, backports aren't SRU-able. You need to re-run the script once .3 is in -updates
[12:33] <markey> apachelogger: got a crash?
[12:33] <apachelogger> yes
[12:33] <markey> ok
[12:33] <apachelogger> http://wstaw.org/m/2013/06/03/plasma-desktopyY2118.png
[12:33] <apachelogger> also that
[12:34] <markey> Oo
[12:34] <markey> what's that?
[12:34] <shadeslayer> lol
[12:34] <yofel> shadeslayer: and what about ddebs? Those have existed since the age of time
[12:34] <shadeslayer> yofel: oh, I wasn't aware of them :S
[12:34] <apachelogger> markey: my context view
[12:34] <shadeslayer> I thought they were still not implemented
[12:35] <yofel> shadeslayer: https://wiki.ubuntu.com/DebuggingProgramCrash
[12:35] <shadeslayer> isn't that dbgsym?
[12:35] <shadeslayer> wait
[12:35] <shadeslayer> I'm confused now
[12:35] <yofel> shadeslayer: that's the same damn thing
[12:35] <shadeslayer> whoopsie
[12:35] <apachelogger> lol
[12:35] <yofel> packagename is -dbgsym, file extension is .ddeb
[12:35] <shadeslayer> for some reason I thought ddebs meant delta debs :/
[12:36] <yofel> ^^
[12:36] <apachelogger> they aren't debs if they are delta -.-
[12:37] <apachelogger> markey: I think ben is on to something
[12:37] <apachelogger> 2.7 does not crash
[12:37] <markey> apachelogger: no, actually I looked into that. it's not related to that code
[12:38] <apachelogger> it still does not crash with 2.7
[12:38] <markey> I doubt that
[12:38] <markey> also consider: on Gentoo it never crashes with QtScript
[12:38] <markey> I find that odd
[12:39] <apachelogger> that means nothing for qtscript
[12:39] <apachelogger> it's highly dependent on platform/compiler/flags
[12:39] <markey> true
[12:39] <apachelogger> the crash I was talkign about earlier with the same backtrace was such a thing.. it would crash only on amd64 because of platform specifics
[12:40] <markey> apachelogger: how about trying to disable the JIT?
[12:40] <markey> maybe that could fix it
[12:41] <apachelogger> no
[12:41] <apachelogger> that would work around it
[12:41] <apachelogger> anyway
[12:42] <apachelogger> it does not crash with 2.7.0
[12:42] <apachelogger> so I suspect a change in master screwed with it somehow
[12:51] <BluesKaj> Hiyas all
[12:55] <soee> someone using 13.04 on laptop ?
[12:55] <yofel> soee: me
[12:55] <soee> yofel, can you boot system and leave it for night and next day check how kded4 behaves ?
[12:56] <yofel> soee: the system has been running for 2 days now and nothing unusual so far (neither the week it had been running before that)
[12:57] <soee> for me if i do such thing or im using laptop for few hours kded4 starts to eat whole free memory and i have to reboot to be able to use it
[12:58] <soee> after whole night when i checked in the morning it was using > 2GB ram
[12:58] <soee> so then system stops to response or do it very slooow 
[12:58] <yofel> hm... you can unload kded modules over dbus somehow I believe. Maybe that could help with debugging.
[12:58] <soee> the only option is to kill kded4 when im starting my work on lap
[13:06] <shadeslayer> yofel: unloadModule
[13:07] <yofel> shadeslayer: explain that to soee, I forgot the exact invocation
[13:07] <shadeslayer> qdbus org.kde.kded /kded org.kde.kded.unloadModule moduleName
[13:08] <shadeslayer> qdbus org.kde.kded /kded org.kde.kded.loadedModules   will give you all the loaded modules
[13:08] <markey> apachelogger: ok here's the deal. I'll set my git to 2.7.0 tag and try with it. we'll see
[13:08] <markey> easy enough
[13:09] <yofel> shadeslayer: thanks!
[13:09] <shadeslayer> np
[13:09] <yofel> soee: for reference: the modules I have in use: http://paste.kde.org/757436
[13:09] <rdieter> soee: saw mention of kded mem usage, may want to look @ https://bugs.kde.org/show_bug.cgi?id=271934  (which is apparently some odd interaction between kauth and cron jobs)
[13:11] <soee> rdieter, yes this might be my case 
[13:11] <soee> they mentioned it happens on old HP devices
[13:12] <soee> and im using old dv5
[13:26] <markey> apachelogger: ok, I'm running 2.7.0 now, it crashes as well :(
[13:31] <markey> darn QtScript
[13:41] <apachelogger> why is it not crashing for me then Oo
[13:41] <apachelogger> markey: same bt?
[13:41] <markey> yep
[13:41] <markey> well
[13:42] <markey> let me get you a BT from that one
[13:42] <markey> it's coming from this Free Music Charts script
[13:43] <markey> it seems to crash a little less often. maybe only 1 in 5 startups
[13:43] <markey> that could be coincidence though
[13:43] <markey> apachelogger: http://pastie.org/8000533
[13:46] <apachelogger> markey: does it crash always for you?
[13:46] <apachelogger> because even with master it only crashes after a while or perhaps not at all (or I just didn't wait long enough)
[13:46] <markey> apachelogger: no, as I said. maybe 1 in 5 starts crashes
[13:46] <apachelogger> right
[13:46] <markey> sadly
[13:46] <apachelogger> race condition :P
[13:46] <markey> Heisenbug...
[13:46] <apachelogger> or reentrancy
[13:46] <apachelogger> weeh
[13:46] <markey> yes...
[13:47] <apachelogger> or still architecture specific memory crap
[13:47] <apachelogger> #12 Phonon::Gstreamer::Pipeline::cb_error (bus=<optimized out>, gstMessage=0x7f2159a92ca0, data=0x25c6a90) at ../../gstreamer/pipeline.cpp:486
[13:47] <apachelogger> it's curious that pgst would get the error callback still
[13:48] <apachelogger> so I guess I'll put my money on memory crap for the time being
[13:48] <markey> bug in QtScript you mean?
[13:49] <apachelogger> could be that something messes up the heap and gstreamer goes "fu" and then jit goes "fu, I am dead"
[13:49] <apachelogger> markey: for example
[13:49] <apachelogger> I mean it would be a bug in qtscript anyway
[13:49] <markey> this is a nightmare :(
[13:49] <apachelogger> yes
[13:49] <apachelogger> markey: talk to #qt people maybe
[13:51] <apachelogger> markey: tell them we have http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qt/view/head:/debian/patches/kubuntu_38_revert_fix_jit_crash.diff
[13:51] <apachelogger> albeit that patch should have fixed this trace
[14:18] <rdieter> apachelogger (and markey): i dont think that revert/patch is needed or desirable in 4.8.4 anymore (the original 4.8.3 qtscript problem was fixed in a small followup, see https://bugreports.qt-project.org/browse/QTBUG-27322 and https://codereview.qt-project.org/#change,37896 which should be included in 4.8.4)
[14:18] <rdieter> unless that reversion is something different, in which case, ignore me and carry on
[14:18] <apachelogger> yeah, no one ever figured out if it was in 4.8.4
[14:19] <rdieter> by reverting that, you may be seeing the original QTBUG-23871
[14:22] <apachelogger> yofel: ^
[14:24] <markey> is this related to the Amarok crashes?
[14:24] <markey> hmmm
[14:25] <markey> it might be, I think
[14:27] <mck182> shadeslayer Riddell: my upgrade using muon is stuck on "Waiting for configuration file" for about an hour now...can I just kill it?
[14:27] <yofel> apachelogger: hm?
[14:27] <shadeslayer> :S
[14:28] <shadeslayer> mck182: attach gdb and check the backtrace ?
[14:28] <apachelogger> mck182: wait for JontheEchidna to tell you how to debug it ^^
[14:28] <shadeslayer> yeah ^^
[14:28] <JontheEchidna> it should be telling you about a difference in an /etc/conf file on the frontend
[14:29] <mck182> JontheEchidna: nope, no such dialog anywhere on my desktop
[14:29] <JontheEchidna> :(
[14:29] <mck182> unless it's really cleverly hiding
[14:29] <JontheEchidna> that's pretty weird, since the frontend did catch that it's supposed to be prompting. I'll have to play around with that I suppose.
[14:30] <mck182> JontheEchidna: what do I do?
[14:30] <markey> yofel: see what rdieter wrote above, regarding QTBUG-23871
[14:30] <apachelogger>         load file
[14:30] <apachelogger>         populate(self)
[14:30] <agateau> JontheEchidna: could it be interesting to look at the process tree?
[14:30] <apachelogger> ruby is really creepy at times
[14:30]  * mck182 looks
[14:30] <agateau> JontheEchidna: to see if apt is stuck at some command line front end
[14:31] <JontheEchidna> It's waiting on Muon to present a "do you want to replace this conf file that you've changed with the updated one from the package" dialog, but Muon's not doing it, even though it knows it should
[14:31] <mck182> well, there's qaptworker with qthread/dpkg as a child
[14:32] <JontheEchidna> I've not found a good way to test conf file replacement, due to it requiring a package update to change a conf file
[14:32] <JontheEchidna> so it's possible that there are bugs like this I guess....
[14:32] <agateau> JontheEchidna: I like how you talk about Muon as if it was a stuborn child :)
[14:32] <mck182> btw. probably the most stupid plasma bug ever - https://dl.dropboxusercontent.com/u/6761102/recorditnow_tmp.mp4 - two screens, trying to unmount my disk, no clicking involved
[14:32] <JontheEchidna> haha, it kind of is in some ways :P
[14:33] <mck182> JontheEchidna: so...what should I do with it?
[14:34] <JontheEchidna> mck182: you'll have to kill muon and qaptworker, run "sudo dpkg --configure -a" and run another upgrade
[14:34] <apachelogger> ohhh
[14:34] <mck182> oh well
[14:34] <agateau> mck182: awesome!
[14:34] <apachelogger> yofel: /opt/project-neon/share/project-neon/pkg-project-neon.mk
[14:34] <mck182> agateau: it is!
[14:34] <apachelogger> yofel: fiddeling the buildsystem will be fun
[14:35] <apachelogger> started that 3 weeks ago, gave up after 300 replaces of /opt/project-neon for /opt/project-neon-kf5 :S
[14:35] <yofel> apachelogger: looking at qt
[14:35] <mck182> agateau: until you want to actualy unmount the drive
[14:35] <JontheEchidna> mck182: so this is with the updater frontend?
[14:35] <apachelogger> yofel: groovy
[14:35] <mck182> JontheEchidna: I guess...?
[14:35] <apachelogger> I am checking out for today anyway
[14:36] <agateau> mck182: this is what "sudo umount" is for :)
[14:36] <yofel> apachelogger: that's a symlink to ../0/project-neon.mk, you should be looking at that and default-settings.mk
[14:36] <mck182> JontheEchidna: I run muon and pressed full upgrade
[14:36] <apachelogger> yofel: there's much more
[14:36] <JontheEchidna> oh, so the Muon Package Manager
[14:36] <JontheEchidna> ok, thanks. I'll take a look at that today
[14:36] <mck182> yeah
[14:36] <mck182> anytime :)
[14:36] <apachelogger> you have like a bazillion lines of code just for the envrionment setup and build system and what not
[14:36] <apachelogger> really spooky
[14:36] <yofel> I know -_-"
[14:37] <JontheEchidna> oh, well that was stupid.
[14:37] <JontheEchidna> slots generally work better when connected to signals
[14:37] <apachelogger> anyway, my builder has runtime recipe inclusion working, so I'll fiddle a bit on error handling tomorrow
[14:37] <JontheEchidna> -_____-
[14:37] <apachelogger> we should be good to start packaging by the end of the week or so I hope
[14:37] <yofel> apachelogger: changing the *directory* should be as easy as changing NEONDIR though
[14:38] <apachelogger> JontheEchidna: ololo
[14:38] <yofel> though it's not overridable currently
[14:38] <apachelogger> JontheEchidna: you should switch the worker to qt5 :P
[14:38] <JontheEchidna> I should
[14:38] <apachelogger> use &slot notation
[14:38] <apachelogger> yofel: nah it's hardcoded all over the place
[14:38] <JontheEchidna> this is why I dislike dynamic compilation, for exactly reasons like this
[14:38] <apachelogger> and those need manual review making it a bit of a drag
[14:39] <yofel> apachelogger: it's hardcoded in *some* places, most of which should be fixed
[14:39] <apachelogger> our definitions of some seem diverge :P
[14:39] <apachelogger> but yeah, the pn macro magic should be the least of our show stoppers
[14:40] <mck182> JontheEchidna: probably not your area of expertise anymore, but running that dpkg... gave me "Error! Bad return status for module build on kernel: 3.8.0-23-generic (x86_64)
[14:40] <mck182> "
[14:40] <mck182> oh and "ImportError: No module named apport
[14:40] <mck182> "
[14:41] <JontheEchidna> mck182: is that for the virtualbox kernel module or something?
[14:41] <apachelogger> afiestas_: bug 1182272 ... does that also require a bluedevil update?
[14:41] <yofel> apachelogger: counting only the build system, I see 3 wrong hardcoded paths. Possibly 4.
[14:41] <yofel> the environment setup is a bit messy though indeed
[14:42]  * yofel needs to read up on deferred variable definition in make again...
[14:42] <mck182> JontheEchidna: dunno, this is all I see http://paste.kde.org/757478/
[14:42] <apachelogger> it's problematic anyway for the setup ... to reliably include a global definition you'd still need to hardcode the path all over the place
[14:43] <apachelogger> (not one of bash's most enjoyable attributes)
[14:43] <mck182> JontheEchidna: oh it's nvidia
[14:43] <mck182> oh boy
[14:43] <JontheEchidna> ah
[14:43] <JontheEchidna> hmm, yeah. I'm not really familiar with dkms stuff
[14:44] <apachelogger> mck182: what does /var/lib/dkms/nvidia/313.18/build/make.log say?
[14:44] <mck182> but I use packaged drivers! :(
[14:44] <mck182> apachelogger: *** Unable to determine the target kernel version. ***
[14:45] <mck182> and DKMS make.log for nvidia-313.18 for kernel 3.8.0-23-generic (x86_64) 
[14:45] <apachelogger> lol
[14:45] <mck182> yeah
[14:45] <apachelogger> mck182: #ubuntu may be able to help
[14:45] <apachelogger> actually
[14:47] <apachelogger> yofel: http://paste.kde.org/757484/ what a recipe would contain right now
[14:47] <apachelogger> though the bzrcache would go away with the grand unified packaging repo
[14:47] <shadeslayer> what does teach you ? dont buy crap hardware ...
[14:48] <apachelogger> shadeslayer: hm?
[14:48] <shadeslayer> that was aimed at Martin
[14:49] <mck182> I think the hardware is just fine, thank you very much :P
[14:49] <apachelogger> yeah
[14:49] <apachelogger> the hardware is not crap
[14:49] <apachelogger> the company is :P
[14:49] <mck182> that it is, yeah :D
[14:50] <apachelogger> we ahve too many untriaged bugs -.-
[14:50] <mck182> JontheEchidna: is there a plan to put "reinstall" in muon?
[14:50] <apachelogger> also I get too many mails
[14:51] <apachelogger> JontheEchidna: bug 1018952
[14:52] <apachelogger> and then there is bug 668748 which d_ed was supposed to fix :S
[14:52] <apachelogger> nothing interesting on the board otherwise
[14:52]  * apachelogger scuttles off to dinner and checks out for today
[14:53] <JontheEchidna> lol, bug 1181120
[14:55] <yofel> meh, I have no qt clone lying around :S
[15:06] <yofel> apachelogger, markey: dropping that qt patch looks like the right thing to do indeed. I'll remove it from saucy. I'll make a PPA package for raring later
[15:32] <afiestas_> apachelogger: nope
[15:48] <markey> yofel: great, thanks! let me know when the package for Raring is available, then I'll test it with Amarok
[15:48] <markey> fingers crossed that it fixes the crashes
[15:51] <jessie> vHanda: Any news on my Nepomuk? I miss it already. Email searching without it sucks terribly.
[15:51] <vHanda> no, I'm sorry, I still haven't looked at it
[15:51] <vHanda> let me put it on my todo list
[15:52] <Peace-> apachelogger: the default splash scree on kubuntu it's the default one of kde?
[15:52] <jessie> Thanks. I do appreciate it.
[15:52] <Peace-> apachelogger: i did this one :) http://www.youtube.com/watch?v=JfTeLXFmQZ4 
[15:53] <Riddell> Peace-: yep, all our artwork is from KDE
[15:54] <Peace-> Riddell: oh thanks 
[16:46] <palasso> ahoneybun, I didn't forget abt trello but idk if I'll be able to contribute on the next months (I don't have much free time those days) so idk if I should be on trello
[16:53] <markey> how could I enable EGL with my Intel driver? need to test something
[17:31] <lordievader> Does Kubuntu participate in the Candence Weeks?
[17:44] <yofel> lordievader: no(t so far)
[17:44] <lordievader> Hmm, too bad (I think).
[17:54] <yofel> lordievader: well, ubuntu does continous testing and no alphas. We rather stick to focused alpha testing when we have KDE releases, esp. with the amount of testers we have
[17:54] <lordievader> Ah I see. Ok :)
[17:55] <yofel> lordievader: it'll only get interesting in 9 days anyway, that's 4.11b1 release
[17:55] <yofel> though packaging will take a while
[17:56] <lordievader> yofel: That is about the time of Candence Week 1, that starts the 15th.
[17:56] <lordievader> I guess the testers will get pinged to test 4.11b1? (Or will that be later in the KDE release cycle?)
[17:57] <yofel> alpha1 is 20th, and one week for packaging is already ambitious
[17:58] <yofel> lordievader: you'll get pinged
[17:58] <lordievader> Yaayyy :D
[18:32] <palasso> ahoneybun, https://wiki.kubuntu.org/Kubuntu/KubuntuDocs/Software/Internet#Opera Opera is not on the repos. Prior steps are required for this to work (adding a repo having package 'opera'). Also since this documentation is targeted towards newcomers should the Muon Software Center solution be suggested instead of Muon Package Manager (same in Chromium). Finally should Chromium be ordered on top of Opera since it's more well known a
[18:32] <palasso> nd has a larger userbase?
[18:45] <ahoneybun> palasso: just keep that thought in mind and we will make them awesome, and I moved MSC above MPM
[18:47] <ahoneybun> palasso: yea chromium should be on top, if opera is not in the default repos then remove it
[18:47] <palasso> ok I'll do those changes
[18:48] <palasso> "Open the 'Muon Package Manger', then search for 'chromium-browser'. " May I replace it with "Open the 'Muon Software Center', then search for 'chromium-browser'. "
[18:48] <ahoneybun> yes
[18:51] <ahoneybun> palasso: good work :)
[18:52] <palasso> thnx
[18:56] <ahoneybun> palasso: whatever time you can give is great
[18:58] <palasso> ahoneybun, sure ;)
[19:05] <ahoneybun> palasso: you can just use trello to keep track of the work
[19:42] <ahoneybun> palasso: very good changes
[20:11] <ahoneybun> howdy people
[21:27]  * yofel notes that he overwrote *someone's* kdepim .4 upload for saucy in the ninja ppa
[21:27] <yofel> please commit the changes to bzr when uploading otherwise I notice that too late
[21:56] <jessie> ^ Always push changes to the source control.