[07:22] <apachelogger> http://paste.ubuntu.com/8203827/ I totally wrote a control parser \o/
[07:34] <valorie> apachelogger: thanks so much for trying to patch up my old laptop
[07:34] <valorie> just finished a response
[07:37] <valorie> damn, now it doesn't want to shut down
[07:37] <valorie> "In -65 seconds"
[07:39] <valorie> :(
[07:40] <valorie> the only two choices from the kmenu are log out and lock
[07:40] <valorie> cli works of course
[07:42] <valorie> hmmm, but it hasn't quit
[07:42] <valorie> oh, well
[07:48] <lordievader> Good morning.
[09:53] <kdeuser56> shadeslayer_: regression, iso does again not respect "noninteractive" and "maybe-ubiquity"
[09:54] <kdeuser56> shadeslayer_: since I have not tested everyday I cannot say when this was introduced again, I know for sure the iso from aug, 29 was affected too
[09:56] <kdeuser56> shadeslayer_: all i know is that the iso from aug, 27 worked fine, I think the one from 28 too, but not sure
[10:13] <shadeslayer_> kdeuser56: I'll take a look later on
[10:13] <kdeuser56> shadeslayer_: thx
[10:13] <shadeslayer_> also, noninteractive and maybe-ubiquity go together?
[10:14] <shadeslayer_> because I know about maybe-ubiquity, tried a fix, didn't work
[10:14] <kdeuser56> shadeslayer_: i tested them individually
[10:14] <shadeslayer_> what is noninteractive supposed to do?
[10:14] <kdeuser56> shadeslayer_: they worked fine individually on aug 27 
[10:15] <kdeuser56> shadeslayer_: noninteractive starts ubiquity on a vt without x
[10:15] <shadeslayer_> maybe-ubiquity might have bought up ubiquity-dm, but you couldn't login
[10:15] <shadeslayer_> so no, it did not work
[10:15] <kdeuser56> shadeslayer_: what did not work?
[10:15] <shadeslayer_> login
[10:16] <kdeuser56> shadeslayer_: when?
[10:16] <shadeslayer_> "Try Kubuntu" did not login
[10:16] <shadeslayer_> ever
[10:16] <shadeslayer_> anyway
[10:16] <shadeslayer_> it's on my todo to fix
[10:16] <shadeslayer_> so yeah
[10:16] <kdeuser56> shadeslayer_: oh I am not sure I tested that
[10:16] <shadeslayer_> :p
[10:17] <kdeuser56> shadeslayer_: but what I know for sure is that bother noninteractive and maybe-ubiquity worked find individually on aug 27, as I wrote you in the confirmation mail 
[10:17] <shadeslayer_> again, maybe-ubiquity only partially worked
[10:17] <kdeuser56> shadeslayer_: what I mean by worked is, that it was invoked
[10:17] <shadeslayer_> right
[10:17] <shadeslayer_> I know, I kind of fixed it :)
[10:18] <kdeuser56> shadeslayer_: so you deliberately disabled respecting the ubiquity commands as a workaround for the login problem?
[10:21] <shadeslayer_> yes, I did not want a beta 1 that wouldn't login out of the box
[10:21] <shadeslayer_> plus, it was that way before as wekll
[10:21] <shadeslayer_> *well
[10:21] <kdeuser56> shadeslayer_: ah okay, so it seems what you disabled disabled noninteractive too
[10:21] <kdeuser56> shadeslayer_: any plan to reintroduce it as soon as the login works with maybe-ubiquity?
[10:22] <shadeslayer_> don't think so
[10:22] <shadeslayer_> ( re non interactive )
[10:22] <shadeslayer_> kdeuser56: yep
[10:23] <kdeuser56> shadeslayer_: but somehow it stopped working when maybe-ubiquity stopped working ...
[10:23] <kdeuser56> shadeslayer_: anyway, why don't we do it like ubuntu? two grub entries: one live session, one install ubuntu
[10:24] <shadeslayer_> dunno, you'd have to ask Colin
[10:26] <kdeuser56> shadeslayer_: so how exactly did you disable maybe-ubiquity from working? you could have simply changed the default boot command line
[10:26] <kdeuser56> to not include "maybe-ubiquity" 
[10:26] <shadeslayer_> I think the command line might be shared across flavors
[10:26] <shadeslayer_> *boot command
[10:26] <shadeslayer_> but I do not for sure
[10:27] <shadeslayer_> *do not know for sure
[10:27] <shadeslayer_> https://code.launchpad.net/~rohangarg/ubiquity/plasma5/+merge/228528
[10:27] <shadeslayer_> reverted that
[10:30] <kdeuser56> shadeslayer_: so this change was for sure in the plasma5 iso on aug 27?
[10:30] <kdeuser56> (before reverting it)?
[10:31] <shadeslayer_> yes
[10:31] <shadeslayer_> https://launchpad.net/ubuntu/+source/ubiquity/2.19.3
[10:31] <shadeslayer_>  Wed, 27 Aug 2014 17:01:20 +0200
[10:31] <kdeuser56> shadeslayer_: okay, and http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/sddm/revision/40 is still in?
[10:32] <kdeuser56> shadeslayer_: yeah must be because text works ...
[10:32] <shadeslayer_> yep
[10:32] <kdeuser56> shadeslayer_:  okay than the revert must have broken it, unless another change was made in that area after aug 27
[10:33] <kdeuser56> shadeslayer_: the options work fine on the latest kubuntu-utopic kde4 version
[10:57] <shadeslayer_> *shrug*
[12:12] <apachelogger> Riddell, shadeslayer_: kdesu(5) needs debian alternative support added so that kdesudo can hijack it :: kmix(4) apparently does not autostart in plasma(5) :: starting synaptic from menu apparently doesn't work (which might or might not be related to kdesu)
[12:12] <apachelogger> please have a look
[12:34] <apachelogger> https://launchpadlibrarian.net/183715491/buildlog_ubuntu-utopic-amd64.kcoreaddons_5.1.0%2Bgit20140901.1414~0_FAILEDTOBUILD.txt.gz
[12:34] <apachelogger> this I just don't get
[12:34] <apachelogger> and it only appears to fail on amd64 Oo
[12:34] <apachelogger> ah no, i386 was still building when jenkins aborted 
[12:34] <apachelogger> smart thing
[12:35] <Riddell> buenos tardes
[12:35] <apachelogger> Riddell: hola
[12:35] <sgclark> hi
[12:36] <apachelogger> Riddell: note highlight from earlier
[12:36] <apachelogger> bbiab
[12:39] <Riddell> apachelogger: kdesu alternate? gotit
[12:48] <BluesKaj> Hiyas all
[13:14] <soee> wrr, what was the cmd do upgrade 14.04 to 14.10 ?
[13:15] <BluesKaj> sudo do-release-upgrade -d
[13:16] <soee> BluesKaj: thank you
[13:16] <apachelogger> java is really very shitty
[13:16] <BluesKaj> soee, yw
[13:17] <apachelogger> or maybe it's java devs
[13:17] <Riddell> apachelogger: I'm glad you won't be complaining about python any more :)
[13:17] <Riddell> kubotu: newversion libindi 0.9.8
[13:17] <Riddell> kubotu: newversion libindi 0.9.9
[13:17] <apachelogger> java being shitty doesn't make python less shitty
[13:17] <kubotu> https://bugs.launchpad.net/bugs/1364005
[13:17] <kubotu> https://bugs.launchpad.net/bugs/1364006
[13:18] <apachelogger> like foo = foo() will make foo() the variable but you can't do def foo:
[13:19] <Riddell> all of this pales into insignificance compared to the weirdness of JavaScript
[13:20] <apachelogger> https://svn.jenkins-ci.org/trunk/hudson/plugins/log-parser/src/main/java/hudson/plugins/logparser/ParserRuleFile.java <- "I don't always make classes that aren't really classes, but when I do I make sure they are especially pointless"
[13:20] <apachelogger> Riddell: how's javascript weird?
[13:20] <apachelogger> not that I disagree, I just haven't noticed yet :P
[13:24] <apachelogger> it also suffers from the inconsistent enforcing of braces as a matter of fact ;)
[13:24] <Riddell> apachelogger: it has no classes but it still likes to have a new operator?
[13:24] <Riddell> it tried to add semicolons where it feels they're needed
[13:24] <apachelogger> well, it has prototypes
[13:24] <Riddell> it tries to add vars where it feels they're needed
[13:25] <apachelogger> huh Oo
[13:25] <Riddell> it has global namespace for variables!
[13:25] <Riddell> it has a weird == operator and a slightly more useful [13:25] <apachelogger> oh [13:25] <Riddell> nice e-mail du jour http://paste.kde.org/pmtnvsrzc
[13:26] <apachelogger> I DONT ALWAYS TYPE IN CAPITALS BUT WHEN I DO I WRITE LONG MAILS
[13:26] <apachelogger> Riddell: I feel like we might need to revise workspace deps
[13:27] <apachelogger> I just did a t1+workspace build from my local jenkins and it is entirely bottlenecked on plasma-framework
[13:28] <Riddell> well a lot of plasma stuff does depend on plasma-framework so I think that'll always be a bottleneck
[13:28] <apachelogger> I have khotkeys blocked on it though
[13:28] <apachelogger> khotkeys probably doesn't use it
[13:29] <apachelogger> ksysguard as well
[13:29] <Riddell> plasma-framework should not really have been a framework
[13:30] <shadeslayer_> apachelogger: yeah I know I know
[13:30] <shadeslayer_> bunch of things broken
[13:30] <shadeslayer_> fixing them all
[13:30] <apachelogger> shadeslayer_: muchos important right now :P
[13:30] <apachelogger> shadeslayer_: also, u upgrading server?
[13:30] <shadeslayer_> apachelogger: which ones? kdesu?
[13:30] <shadeslayer_> apachelogger: doing now
[13:30] <apachelogger> shadeslayer_: all of them, mission critical for us
[13:30] <Riddell> khotkeys CMakeLists.txt says it needs plasma-framework so I assume it knows what it's doing
[13:31] <shadeslayer_> should I just run do-release-upgrade and see what breaks? :p
[13:31] <apachelogger> Riddell: perhaps upstream needs to detangle some stuff as well
[13:31]  * apachelogger looks for a way to prevent recursive build triggers
[13:31] <apachelogger> shadeslayer_: there's a simulation mode
[13:31] <apachelogger> -s I think
[13:31] <shadeslayer_> apachelogger: yeah using that :)
[13:32] <shadeslayer_> Sandbox setup failed 
[13:32] <apachelogger> alas, you'll likely need to reboot the server afterwards because umount never worked for me in simulation
[13:32] <shadeslayer_> xD
[13:32] <apachelogger> screwed up the apt cache
[13:32] <apachelogger> shadeslayer_: ah yes, rubbish software :P
[13:32] <shadeslayer_> yeah
[13:32]  * apachelogger also couldn't be bothered into making it more robust
[13:32] <apachelogger> there's a bunch of ways the sandboxing can fail for the most silly reasons
[13:32] <apachelogger> (it always fails for me as long as my uefi partition is mounted ^^)
[13:32] <shadeslayer_> hm
[13:32] <apachelogger> shadeslayer_: ah well
[13:33] <apachelogger> shadeslayer_: I did a dist-upgrade earlier, maybe reboot and just run the update
[13:33] <apachelogger> oh
[13:42] <apachelogger> I am really not very sure how to integrate our build log parsing into jenkins without too much work
[13:57] <apachelogger> shadeslayer_, yofel_: http://paste.ubuntu.com/8206476/ dir structure for jenkins, any thoughts?
[13:58] <shadeslayer_> apachelogger: can't think of anything wrong about it from the top of my head
[13:59] <Riddell> yofel_: what's the usual practice to verify an upate of kde-workspace? bug 1353973 needs it
[13:59] <apachelogger> I am yet unsure how to reliably do dependency tracking
[14:01] <apachelogger> ultimately the build job itself would update the directly related projects, but that still makes dep tracking off-by-one as far as jenkins is concenred
[14:01] <shadeslayer_> apachelogger: oh oh regarding synaptic
[14:01] <shadeslayer_> I think that's a bug in klauncher stuff
[14:01] <shadeslayer_> and also in the synaptic-kde.desktop file
[14:02] <shadeslayer_> I was investigating that before randa
[14:02] <shadeslayer_> maybe we can sit down and figure it out at Akademy
[14:02] <apachelogger> oh
[14:02] <apachelogger> synaptic-kde
[14:02] <apachelogger> I am 99% certain it's kdesu then :P
[14:03] <shadeslayer_> no no
[14:03] <shadeslayer_> it's a path issue sort of
[14:03] <apachelogger> X-KDE-SubstituteUID=true
[14:03] <shadeslayer_> synaptic is in /usr/sbin and PATH doesn't have that
[14:03] <shadeslayer_> or something along those lines
[14:03] <apachelogger> PATH didn't have that because of sddm? :P
[14:03] <shadeslayer_> ( it should have been fixed btw )
[14:03] <shadeslayer_> yes
[14:03] <apachelogger> at any rate even if there is a path issue ... kdesuid would break it as that would go through kdesu
[14:03] <shadeslayer_> kinda
[14:04] <shadeslayer_> the gtk version is using pkexec
[14:04] <apachelogger> I think ours should too
[14:04] <apachelogger> in fact
[14:04] <shadeslayer_> no
[14:04] <apachelogger> why not?
[14:04] <shadeslayer_> Exec=synaptic
[14:04] <apachelogger> yes
[14:04] <shadeslayer_> that's the question/bug
[14:04] <apachelogger> u not listening :P
[14:04] <apachelogger> X-KDE-SubstituteUID=true
[14:05] <apachelogger> that will make the exec run through kdesu
[14:05] <yofel_> Riddell: same as the rest of the sc usually... install and try some of the main features
[14:05] <apachelogger> and I am arguing that it probably should use pkexec like the regular desktop file
[14:05] <apachelogger> and ultimately perhaps X-KDE-SubstituteUID=true should be changed entirely to pkexec
[14:05] <shadeslayer_> hm
[14:05] <apachelogger> not sure there's much difference to be had
[14:05] <apachelogger> oh, I think kdesudo at least will preserve relevant parts of the env
[14:05] <apachelogger> so there's that
[14:06] <apachelogger> anywho
[14:06] <apachelogger> it's probably broken because of kdesu :P
[14:06] <shadeslayer_> apachelogger: but X-KDE-SubstituteUID doesn't work, is that because of update alternatives?
[14:06] <apachelogger> shadeslayer_: that's what I am thinking
[14:06] <shadeslayer_> hm
[14:06] <apachelogger> i.e. it would try to launch kdesu
[14:06] <shadeslayer_> apachelogger: running pkexec synaptic does the right thing though
[14:06] <apachelogger> and that won't work well
[14:06] <shadeslayer_> brings up a auth dialog on neon
[14:06] <apachelogger> shadeslayer_: yeah, as it should
[14:06] <apachelogger> shadeslayer_: perhaps file a bug against synaptic
[14:06] <apachelogger> to drop the kde desktop file and use pkexec instead
[14:06] <shadeslayer_> yes
[14:07] <shadeslayer_> would make the most sense tbh
[14:07] <apachelogger> kdesu still needs to be fixed tho ^^
[14:07] <shadeslayer_> IDK why there's a separate kde desktop file
[14:07] <apachelogger> Spent an hour waiting for plasma-framework to build, we are giving up now.
[14:07] <apachelogger> Oo
[14:08] <yofel> apachelogger: wrt dir structure: why is bzr not cached? Otherwise no complaints
[14:08] <apachelogger> there's a bug in my python script and there's weird scheduling on lunchpad
[14:09] <apachelogger> yofel: because each branch would constitute a different remote url/repo and as such there is no advantage to be had from caching them globally
[14:09] <yofel> k
[14:09] <apachelogger> with git you have one upstream unstable unit that can be shared for multiple ubuntu series
[14:10] <apachelogger> (in neon we actually cache bzr as well, doesn't give us anything though ^^)
[14:55] <Riddell> anyone on trusty still?
[14:56] <Riddell> !testers | test kde-workspace 4.11.11 in -proposed on trusty - bug 1353973
[14:57] <BluesKaj> Riddell, add proposed to the sources.list ?
[14:59] <BluesKaj> oops, forgot that i dumped trusty
[15:04] <Riddell> yeah that's needed :)
[15:12] <shadeslayer_> does anyone know why we need this http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/kdoctools/view/head:/debian/patches/missing-all-l10n.xml.diff
[15:13] <shadeslayer_> it's not cool that we have patches that have a) not been forwarded upstream and b) Have no dep 3 headers
[15:14] <Riddell> shadeslayer_: I suspect that's a temporary patch that can be droped
[15:14] <Riddell> sgclark did it I think
[15:14] <Riddell> (but she's travelling to akademy now)
[15:18] <shadeslayer_> well, all-l10n.xml is still empty
[15:18] <shadeslayer_> so it should be really reported upstream
[15:20] <Riddell> hmm, I remember it having some discussions upsteram but I'm not sure what sorry
[15:21] <Riddell> didn't the patch come from upstream?
[15:21] <Riddell> ooh sgclark 
[15:21] <Riddell> shadeslayer_  is wondering about the origin and destination of http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/kdoctools/view/head:/debian/patches/missing-all-l10n.xml.diff ?
[15:23] <shadeslayer_> Riddell: if it came from upstream it should have dep 3 headera
[15:23] <shadeslayer_> *headers
[15:23] <Riddell> it /should/ have dep3 headers regardless, but I often find myself forgetting
[15:23] <shadeslayer_> My computer has frozen
[15:23] <shadeslayer_> Hurray
[15:23] <shadeslayer_> Riddell: yeah, I will write a compliance checker
[15:24] <shadeslayer_> Nag people via email
[15:24] <sgclark> Riddell: that was a long time ago pre knowing about dep 3, anyway at the time it would not compile without it, not sure about now
[15:25] <shadeslayer_> It compiles
[15:25] <shadeslayer_> But empty file 
[15:26] <shadeslayer_> Anyway
[15:26] <shadeslayer_> The way to fix this is nagging people
[15:26] <shadeslayer_> With autochecjs
[15:27] <shadeslayer_> And autoremoving patches after 2-3 weeks if they do not have dep3
[15:27] <shadeslayer_> Will figure out how to do that tomorrow
[15:28] <apachelogger> write jenkins job
[15:28] <shadeslayer_> :)
[15:28] <shadeslayer_> apachelogger: yeah that was the plan :p
[15:28] <apachelogger> have fun with java :P
[15:28] <ScottK> shadeslayer: as long as you fix the resulting bugs.
[15:28] <shadeslayer_> ScottK: not my fault that the author did not write dep3 headers, because people always forget what a patch is for
[15:29] <shadeslayer_> and then we keep it around because we fear shit might break
[15:29] <shadeslayer_> and then it lingers on and on till the end of time
[15:29] <sgclark> As I said that was from back when I first started and did not know, good grief
[15:29]  * apachelogger notes that there's should be a monthly nag about patches that say Forwarded: no and Forwarded: not-needed
[15:29]  * sgclark goes back to packing
[15:29] <ScottK> shadeslayer: Some predate the DEP.
[15:30] <shadeslayer_> ScottK: this is exclusively for frameworks
[15:30] <shadeslayer_> I'm not too concerned about KDE4
[15:30] <ScottK> OK
[15:30] <shadeslayer_> sgclark: I'm not singling you out
[15:30] <shadeslayer_> sgclark: we've all done this
[15:30] <shadeslayer_> so I really want some automated checks for this
[15:31] <shadeslayer_> because we're all human and we will forget about patches
[15:31] <shadeslayer_> it's simply not possible for us to keep track of all the patches in our head
[15:31] <shadeslayer_> or atleast not for me
[15:31] <shadeslayer_> dunno about you guys
[15:35] <sgclark> I am sure I have alot of pre dep 3 patches out therre as I was only told recently
[15:36] <sgclark> and no I don't know where they are
[15:37] <sgclark> anyway my long journey to akadamy begins today so I am not going to be much help sorry :(
[15:37] <shadeslayer_> sgclark: http://people.ubuntu.com/~rohangarg/ubuntu-patch-status.html
[15:37] <shadeslayer_> for future reference
[15:38] <shadeslayer_> sgclark: have a uneventful trip :)
[15:39] <sgclark> Thank you shadeslayer_ bookmarked that to fix at another time
[15:39] <shadeslayer_> yw
[15:43] <Riddell> shadeslayer_: add it to qa.kubuntu.co.uk if you think it's useful
[15:45] <shadeslayer_> Riddell: yeah, need to setup a cron job
[15:46] <Riddell> but they're all kde 4 bits so unlikely they'll be changed
[15:46] <shadeslayer_> Riddell: yeah, I'm running it again
[15:46] <shadeslayer_> for some reason the kf5 bits are not there in that file
[15:47] <shadeslayer_>     At least 4 queries/external actions issued in 0.11 seconds OOPS-6d4f0a3853980a04267cc30344e3215a
[15:47] <shadeslayer_> heh
[16:15] <shadeslayer_> alrighty, I have to go
[16:15] <shadeslayer_> cya tomorrow
[16:50] <Riddell> hi ahoneybun, hi vgezer 
[16:50] <ahoneybun> hey Riddell