[08:32] <Riddell> Quintasan: you pinged?
[08:33] <Quintasan> Riddell: I did. I accidentaly the screen in Archos G9 101
[08:33] <Quintasan> I consider this a good opportunity to have you guys decide about future of Active on Akademy
[08:33] <apachelogger> ur missing a verb old friend
[08:33] <Quintasan> But broken stuff is broken stuff.
[08:34] <Quintasan> Should I try getting it repaired or replaced? Getting a new replacement is going to be hard since you can't really find it anymore in shops
[08:34] <yofel> I wouldn't touch it again until it's just another plasma 5 interface
[08:34] <apachelogger> oh bother, version bumpery in kubuntu-automation depends on a manual list of stuff ti may bump
[08:34] <Quintasan> apachelogger: That was on purpose.
[08:34] <apachelogger> oh oh
[08:34] <apachelogger> also, what yofel said
[08:35] <Quintasan> That still needs a formal decision or something
[08:35] <yofel> apachelogger: that's because there should be a json file or whatever for source <-> binary matching, or a 2 pass processing. None of that exists yet
[08:35] <Quintasan> Riddell: I asked some of KC people but got no definite answer yet.
[08:35] <apachelogger> active is not moving forward in its present version.
[08:36] <apachelogger> there's your decision
[08:36] <Quintasan> What about the device?
[08:36] <apachelogger> any and all time spent on it is a waste of time and better had been spent on creating a suitable replacment using plasmashell(5)
[08:37] <apachelogger> Quintasan: don't know, don't care :P
[08:37] <apachelogger> that you will have to ask the KC about
[08:37] <apachelogger> for all I care you could plug a screen to it and use it as a media control center or something :P
[08:37] <Quintasan> That's what I'm trying to do -_-
[08:38] <apachelogger> an external screen
[08:39] <apachelogger> control = re.sub(r'%s\s*\(>=.*?\)' % builddep, '%s (>= %s%s)' % (builddep, epoch, upstreamVersion), control)
[08:39] <apachelogger> you know
[08:39] <apachelogger> python often is a lot like perl
[08:39] <apachelogger> completely and utterly unreadable
[08:39] <kdeuser56> apachelogger: do I have to build full kdelibs for patching drkonqi? I guess
[08:40] <yofel> how is that not readable... replaces <pkg> (>= .*) with the new dep
[08:40] <yofel> should probably be done with deb822 rather
[08:40] <yofel> maybe
[08:42] <apachelogger> yofel: yeah
[08:42] <apachelogger> and
[08:42] <apachelogger> control.gsub!(/#{builddep}\s*\(>=.*?\)/, "#{builddep} (>= #{epoch}#{upstreamVersion}")
[08:42] <apachelogger> that does what you said
[08:42] <apachelogger> the python line just does % jerking :P
[08:42] <apachelogger> silly languages be silly
[08:49] <yofel> *shrug*, it does the job
[08:49] <apachelogger> so does perl
[08:50] <apachelogger> anywho
[08:50] <apachelogger> yofel: what's your thought on this... should we put the logic into an own script and call that from initial-upload as well as the CP scripting or should we simply replicate the regex into the CP stuff
[08:50]  * apachelogger thinks putting it into a script is more future proof
[08:51] <yofel> do that, initial upload needs a rewrite at some point anway
[08:54] <apachelogger> brrr
[08:54] <apachelogger> well
[08:55] <apachelogger> if CP gets full adoption including upstream tarball madness in jenkins initial upload will become unnecessary
[08:55] <apachelogger> that's in 10 years then xD
[08:57] <yofel> well, some of our workflow will probably be obsolete after 4.14 is done anyway. With git some more of it
[09:04] <apachelogger> :O
[09:04] <apachelogger> I really should not look at our scripts' code
[09:05] <apachelogger> http://paste.ubuntu.com/8138983/
[09:07] <apachelogger> which actually makes me continue to wonder why oxygen-font has a different version
[09:07] <apachelogger> Riddell: why does oxygen-font have a different version than the rest of workspace?
[09:07] <apachelogger> and why kscreen
[09:09] <Riddell> apachelogger: oxygen-fonts does because the upstream maintainer called it 0.4 then forked his own project and disappeared, I didn't change it in the hope of him coming back but I think I should
[09:09] <Riddell> apachelogger: the libkscreen developer says it's not part of Plasma and should have a different version number
[09:09] <Riddell> kscreen hasn't been released yet although the developer says we should package it and I think sgclark did that and I'll review it today
[09:10] <apachelogger> good thing we decided against 14.month versions, they would have been so much less confusing -.-
[09:11] <Riddell> mm hmm
[09:13]  * apachelogger squints over ecm having a different version
[09:14] <apachelogger> shadeslayer: there, in may you asked why neon recipes were separated in folders and I removed it and now I need the feature!
[09:47] <apachelogger> uhh
[09:47] <apachelogger> not python3 compatible
[09:47] <apachelogger> lovely
[09:52] <apachelogger> oh because of launchpad lib
[10:04] <Riddell> jussi: can you remember the postal address you used to send stuff to akademy?
[10:06] <apachelogger> yofel, debfx: please review that I did not screw up in kubuntu-automation rev 437
[10:06] <apachelogger> ubottu: ur silly
[10:48] <apachelogger> btw I still find it very drunk that frameworks has no epoch
[10:49] <apachelogger> also makes my life harder than it needs to be
[10:49] <Riddell> apachelogger: why would it need an epoch? all new sources
[10:49] <apachelogger> because it makes automation more complicated that's why
[10:50] <yofel> live with it, or talk with maxy about adding an epoch
[10:50] <apachelogger> consider build recipe A and B, A has no epoch, B has an epoch, B depends on A
[10:51] <Riddell> plasma and framework version numbers don't align anyway
[10:51] <apachelogger> that's less of a problem than epoch
[10:51] <apachelogger> to find out the epoch of a package you need to actually look at the packaging
[10:52] <yofel> and?
[10:52] <apachelogger> which is substantial more complicated if A and B are atomic units that do not know about one another
[10:53] <Riddell> well how would it know the rest of the version number?
[10:54] <apachelogger> if you assume that all of plasma has the same version and all of frameworks has the same version then interdependencies are always that very same version number
[10:55] <yofel> maxy already complained about that, so that'll most like not be the case in debian
[10:55] <apachelogger> and a dependency from plasma to frameworks would be based of what is defined in cmake, but since epochs might be involved or not you do not know
[10:56] <apachelogger> yofel: complained about what? things being released having the same versions?
[10:56] <yofel> things being released with new versions if nothing changed
[10:56] <Riddell> but all of frameworks has no epoch, if you know it's in frameworks you know the epoch
[10:56] <apachelogger> I hope he takes that up with upstream
[10:57] <apachelogger> Riddell: yes and if that changes then you get crap like this http://paste.ubuntu.com/8138983/
[10:57] <yofel> what he currently does with the SC is what we do with --sru, except that he applies that to any version
[10:57] <yofel> apachelogger: that's about different package sets though
[10:59] <apachelogger> yofel: the hardcoding of special casing?
[10:59] <yofel> ah, that at the top no
[11:00] <apachelogger> all of it is special casing :P
[11:00] <BluesKaj> 'Morning folks
[11:00] <yofel> it's a workaround for not actually having a package database with versions
[11:00] <yofel> well, the center part should've been done differently
[11:00] <apachelogger> all of it should IMHO, the thing at the bottom sort of is upstream screwup tho
[11:11] <Riddell> shadeslayer: alive?
[11:11] <shadeslayer> Yes
[11:36] <apachelogger> shadeslayer: did you by any chance break the bzr branches? debian/rules:4: /usr/share/pkg-kde-tools/qt-kde-team/3/debian-qt-kde.mk: No such file or directory
[11:37] <apachelogger> oh, 15.15 doesn't exist
[11:37] <apachelogger> shadeslayer: did you by any chance not upload pkg-kde-tools and thus break all the bzr branches?
[11:53] <apachelogger> shadeslayer: piiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiing
[12:46] <Riddell> apachelogger: he's still playing tabletennis
[12:55] <kfunk> work harder!
[12:56] <apachelogger> Riddell: tell him to come to workstation and fix the branches plz
[12:56] <apachelogger> he's holding up CP
[12:56] <shadeslayer> apachelogger: pkg-kde-tools is in staging
[12:56] <shadeslayer> why do you need tier 1 for CP
[12:57] <shadeslayer> I thought we were only doing plasma
[12:57]  * Riddell puts kscreen git into kubuntu-ppa/next
[12:57] <shadeslayer> which is why I broke them a little bit
[13:08] <apachelogger> shadeslayer: that was until Riddell decided to bump plasma-desktop requirement
[13:09] <apachelogger> actually david had a commit on friday I believe that also increased the requirement to kf5 master somewhere
[13:09] <shadeslayer> uff
[13:09] <apachelogger> so we need kf5 to proceed now
[13:09] <shadeslayer> apachelogger: give me 20 minutes
[13:10] <apachelogger> yeah, I am playing around with jenkins right now anyway
[13:10] <apachelogger> shadeslayer: also do note  my query about that btw
[13:12] <Riddell> yofel: anything blocking bug 1353973 kde-workspace update to 4.11.11 in trusty?
[13:12] <yofel> I don't think so
[13:12] <Riddell> I'd like to make sure bug 1304805 gets fixed, somehow we lost the fix I did
[13:13] <Riddell> yofel: ok I'll upload 4.11.11 with that fix for qdbus 
[13:13] <yofel> go ahead
[13:13] <apachelogger> Riddell: the fix is still there
[13:13] <apachelogger> qtchooser is still broken
[13:14] <BluesKaj> heh, what about logout failure ? ")
[13:24] <Riddell> apachelogger: what's the fix?
[13:24] <apachelogger> Riddell: alias
[13:24] <apachelogger> it's not a fix really
[13:25] <apachelogger> it's a workaround
[13:25] <apachelogger> the fix would be to make qtchooser not broken
[13:25] <apachelogger> of course no one wants to do that, so we have that workaround there
[13:25] <Riddell> apachelogger: but it uses quotes which aparently break sometimes and need to be removed
[13:26] <Riddell> qdbus="QT_SELECT=qt4 qdbus" ->  qdbus=QT_SELECT=qt4 qdbus
[13:32] <apachelogger> Riddell: no it doesn't
[13:32] <apachelogger> read the comments
[13:32] <apachelogger> what happens is that they have qdbus:i386 installed while they need qdbus:amd64
[13:32] <apachelogger> and since qtchooser is dumb as shit it doesn't manage to look for i386 on amd64 so it fails
[13:32] <apachelogger> that's not a new issue and that's not an unknown issue really
[13:34] <Riddell> how on earth do they get qdbus:386 installed?
[13:37] <Riddell> apachelogger: but we did upload it without the quotes and that did fix the issues for people, the quotes have re-appeared somehow, should we not upload it without the quotes again?
[13:39] <apachelogger> no
[13:39] <apachelogger> you uploaded a var assignment without quotes which broke the invocation
[13:39] <apachelogger> so I changed it to an alias with quotes as otherwise the alias also would be broken
[13:40] <apachelogger> i.e. what we have now is correct
[13:40] <apachelogger> qtchooser is still broken, so things still fall over
[13:43] <Riddell> hmm, right
[13:51] <apachelogger> shadeslayer: so, I am wondering, alas, I am not yet sure this is entirely possible but ... we could use jenkins and do dependency tracking there (I am not yet sure upstream even does that tho, it seems a big not so dynamic maybe) and then have one build project per packaging repo, the build themselves would then block on launchpad, so the build would be make-source -> upload-source -> wait-on-launchpad-build-green
[13:52] <apachelogger> that way we could possibly even elevate the bdep version requirement fiddling in CP as builds always would happen in the correct order anyway
[13:52] <apachelogger> so far the theory anyway :)
[13:52] <shadeslayer> so, jenkins is blocked till LP is green?
[13:53] <apachelogger> shadeslayer: the relevant jenkins build job yes
[13:53] <shadeslayer> also, all of this sounds suspiciously like ubuntu's CI train
[13:53] <shadeslayer> or CI aeroplane
[13:54] <apachelogger> well, it's all CI :P
[13:54] <apachelogger> shadeslayer: they don't land into PPAs though do they, they really just do CI with debs?
[13:56] <shadeslayer> I thought they landed in PPA's
[13:56] <shadeslayer> and then PPA promoted to archive
[13:57] <shadeslayer> I think ScottK knows more
[13:57] <apachelogger> ScottK: please sprinkle some wisdom
[13:57] <shadeslayer> also, there's a mail about that
[13:57] <shadeslayer> https://wiki.ubuntu.com/citrain/FAQ
[13:57] <shadeslayer> https://wiki.ubuntu.com/citrain/NewbieGuide
[13:58] <apachelogger> prepare a silo
[13:59] <apachelogger> shadeslayer: that's so complicated it gives me a headache
[13:59] <apachelogger> well, I already had one, but you know what I mean :P
[13:59] <shadeslayer> ^_^
[13:59] <apachelogger> You have a preproduction code silo in silo-000. You only have access to it if you check "use preproduction silo" 
[14:00] <shadeslayer> apachelogger: CI Airline seems better
[14:00] <shadeslayer> https://docs.google.com/presentation/d/1LQK5Xll3D-G_zSFgFFDZiCmIZ8P33b_C7crefECsquA/edit#slide=id.gdde8ecc3_016
[14:00] <apachelogger> it does generally seem a lot like what we need
[14:01] <shadeslayer> yep
[14:01] <apachelogger> shadeslayer: airline still looks like aeroplane science
[14:02] <shadeslayer> https://docs.google.com/presentation/d/1LQK5Xll3D-G_zSFgFFDZiCmIZ8P33b_C7crefECsquA/edit#slide=id.g121c94af0_04 < seems like Ubuntu Engineering doesn't know how planes fly
[14:02] <shadeslayer> that one is clearly crashing into the ground
[14:02] <apachelogger> good things we don't make software for planes I guess :O
[14:03] <apachelogger> QA sign off needed: only in effect if we are in TRAINCON-0 - and then *only* stuff with QA-sign-off: granted can enter the image 
[14:03] <apachelogger> so
[14:03] <apachelogger> you know, I do write a lot of weird things even when sober
[14:03] <apachelogger> but that citrain thing totally doesn't compute for me
[14:03] <shadeslayer> TRAINCON-0 is when things regress
[14:03] <shadeslayer> I think
[14:04] <shadeslayer> that's what I recall at least
[14:04] <shadeslayer> so say the camera app breaks
[14:04] <shadeslayer> status goes into TRAINCON-0 to stop things from landing
[14:04] <shadeslayer> ( like DEFCON 0 ? )
[14:04] <apachelogger> couldn't possibly be called LANDINGHALT or whatever
[14:05] <apachelogger> that'd not be fancy enough now would it
[14:05] <apachelogger> https://github.com/robru/citrain-web I do like how canonical things aren't being put in bzr :P
[14:05] <shadeslayer> xD
[14:06] <apachelogger> shadeslayer: is pkg-kde fixed yet?
[14:07] <shadeslayer> no
[14:07] <shadeslayer> what
[14:07] <shadeslayer> no
[14:07] <shadeslayer> please wait
[14:07] <shadeslayer> still trying to figure out a proper solution
[14:08] <apachelogger> but I am heading out soon
[14:08] <apachelogger> you'll have to launch builder then
[14:08] <apachelogger> I'd like to look into t1 FTBFS tomorrow
[14:08]  * apachelogger wonders why the citrain website uses google spreadsheets as data provider
[14:08] <shadeslayer> apachelogger: just tell me how
[14:09] <apachelogger> shadeslayer: su kubuntu -> build-builder
[14:09] <shadeslayer> ok
[14:09] <shadeslayer> that's all?
[14:10] <apachelogger> yes
[14:12] <apachelogger> shadeslayer: you should totally show alex the train thing, it's like what we always wanted for RRs xD
[14:12] <shadeslayer> :)
[14:12]  * apachelogger finds it a bit confusing how that is wired up with jenkins though
[14:12] <shadeslayer> I rarely see him these days
[14:12] <shadeslayer> but will try to remember
[14:12] <apachelogger> anywho, ubuntu CI things would cause overhead we don't want or need
[14:14] <apachelogger> considering we never directly land into production archives there's no benefit from all the excess steps involved there
[14:15] <shadeslayer> yes
[14:16] <apachelogger> I do also believe that our staging PPAs need substantial amounts of QA and automation though, so I definitely can imagine us adopting simplified workflows at some point ^^
[14:27] <apachelogger> pfts
[14:28] <apachelogger> dep tracking via jenkins truly is not very exciting
[14:28] <apachelogger> what we could do is have a script trigger everything but everything initial waits for their dependencies to be built
[14:29] <apachelogger> somewhat nasty, and I am not quite sure what the use of jenkins would be then but hey, options
[14:29] <apachelogger> :S
[14:42] <apachelogger> ohoho, I think I found api for dep meddling hooray
[14:45] <Riddell> anyone know how to read the output from the jenkins upgrade test? https://jenkins.qa.ubuntu.com/job/upgrade-kubuntu-trusty-utopic-desktop-amd64/
[14:47] <Riddell> ScottK: bug 1353973 for your SRU love
[15:04] <kdeuser56> what is the exact diff command for the patches that are in the debian.tar.xz?
[15:09] <shadeslayer> Riddell: http://bubb.al/vote
[15:09] <shadeslayer> Interestingly Barcelona says "No"
[15:10] <shadeslayer> I'm afraid it's quite a bit of red all over the map
[15:10] <alket> .al ? its my country :p
[15:10] <kdeuser56> shadeslayer: got my mail about sddm still not accepting noninteractive and text?
[15:10] <shadeslayer> yes
[15:10] <shadeslayer> I was looking at that now
[15:11] <kdeuser56> apachelogger: I am afraid your kubuntu_raise_after_drkonqi.patch needs to be adjusted for kcrash framework (code changed a bit)
[15:11] <shadeslayer> I would imagine so
[15:14] <shadeslayer> kdeuser56: fwiw using noninteractive + text on the regular kubuntu ISO boots to the desktop directly
[15:19] <kdeuser56> shadeslayer: what regular iso?
[15:19] <kdeuser56> shadeslayer: http://cdimage.ubuntu.com/kubuntu/daily-live/current/ ?
[15:19] <shadeslayer> yes
[15:20] <kdeuser56> shadeslayer: wait, I am away for a few minutes to eat, then I will look at it again ... (though I tried all options independently (only text, only noninteractive, both)
[15:21] <shadeslayer> kdeuser56: same here
[15:21] <shadeslayer> kdeuser56: I think a bug report would be better btw
[15:26] <apachelogger> brm brm
[15:26] <apachelogger> shadeslayer: so
[15:26] <shadeslayer> ??
[15:26] <apachelogger> shadeslayer: we could apparently use jenkins but it wouldn't do much
[15:26] <shadeslayer> oh?
[15:27] <apachelogger> namely we'd need an outside tool that somehow gathers up all bdep relationships and then sets up the jenkins dependencies accordingly
[15:28] <apachelogger> then we'd need a helper tool that jenkins can use to do the work as earlier lined out get-upload-wait
[15:28] <apachelogger> launchpad would do the heavy lifting
[15:28] <apachelogger> then we'd probably want another tool to do static log analysis and fail the job depending on that (e.g. mark fail when a cmake dep is not found)
[15:29] <apachelogger> so in the end what jenkins would do is poll bzr for changes and display build status :P
[15:31] <apachelogger> workwise however it wouldn't make much difference whether we use jenkins or not the heap of the work would be to split builder up into more than one tool so that it can do parallel builds (and then either the existing builder would orchestrate or jenkins)
[15:31] <apachelogger> in the long run I have a very unreasonable feeling that jenkins would be nicer
[15:33] <shadeslayer> kdeuser56: the behaviour seems to be consistent across ubuntu and kubuntu btw
[15:33] <shadeslayer> both boot directly into the desktop
[15:47] <kdeuser56> shadeslayer: hm ... not here 
[15:48] <kdeuser56> shadeslayer: did you remove the maybe-ubiquity parameter?
[15:48] <shadeslayer> no
[15:48] <kdeuser56> shadeslayer: okay did that, because it seems to contradict noninteractive
[15:48] <shadeslayer> btw why do you need this
[15:49] <kdeuser56> shadeslayer: what?
[15:49] <kdeuser56> shadeslayer: the noninteractive boot option?
[15:49] <shadeslayer> why do you need noninteractive mode
[15:49] <shadeslayer> yes
[15:49] <kdeuser56> shadeslayer: for preseeding 
[15:49] <shadeslayer> might want to ask in #ubuntu-devel about that
[15:49] <shadeslayer> maybe something changed
[15:50] <kdeuser56> shadeslayer: where?
[15:50] <shadeslayer> just to make sure that you're doing it the right way
[15:50] <shadeslayer> just ask in #ubuntu-devel if there's a guide on preseeding
[15:50] <kdeuser56> shadeslayer: apparently preseeding / installer automation documentation for ubuntu is crap, unlike feora/redhat
[15:51] <shadeslayer> which is why you should ask in #ubuntu-devel
[15:51] <shadeslayer> yeah so
[15:51] <shadeslayer> removed maybe-ubiquity
[15:51] <shadeslayer> booted with noniteractive text
[15:51] <shadeslayer> boots to desktop
[15:52] <kdeuser56> shadeslayer: where? on the latest kubuntu utopic iso?
[15:52] <shadeslayer> yes
[15:52] <kdeuser56> shadeslayer: from here: http://cdimage.ubuntu.com/kubuntu/daily-live/current/ ?
[15:52] <shadeslayer> yes
[15:52] <kdeuser56> shadeslayer: wtf, i just tried that
[15:52] <kdeuser56> shadeslayer: what do you use? virtualbox? kvm?
[15:52] <shadeslayer> vbox
[15:52] <apachelogger> shadeslayer: don't forget to run builder kthxbai
[15:53] <shadeslayer> apachelogger: I'm waiting on Sune for a answer
[15:53] <apachelogger> revert the branches and merge into unstable or something then :P
[15:53] <shadeslayer> will run builder after fixing shit, so maybe sometime around dinner?
[15:53] <shadeslayer> uf
[15:53] <apachelogger> CI breakage is bad breakage
[15:53] <apachelogger> anywho
[15:53] <apachelogger> really off now
[15:53] <shadeslayer> bye
[15:53] <shadeslayer> not if it's intended
[15:54] <shadeslayer> I'd rather not do reverts
[15:54] <shadeslayer> more work
[15:54] <kdeuser56> shadeslayer: hm ... sorry I can't reproduce what you are seeing, I subsitute "maybe-ubiquity" with "text noninteractive" and the noninteractive installer starts up
[15:55] <kdeuser56> shadeslayer: I can make a screencast if you do not believe me
[15:55] <shadeslayer> I do believe you
[15:55] <shadeslayer> I just don't know what else to do here
[15:55] <kdeuser56> shadeslayer: regarding doc: https://wiki.ubuntu.com/DesktopCDOptions
[15:55] <shadeslayer> The one place I could think of
[15:56] <shadeslayer> where this would be configured
[15:56] <shadeslayer> was casper
[15:56] <shadeslayer> I fixed that last week
[15:57] <kdeuser56> shadeslayer: text an noninteractive work on all isos except the plasma 5 one and the neon one (text works for neon though i believe)
[15:58] <kdeuser56> shadeslayer: and i find it strange that despite removing all stuff in /etc/rc?.d/???sddm it still starts up ... why is that?
[16:01] <kdeuser56> shadeslayer: official documentation is really really bad, but everything works for me with the mentioned isos, so it has something todo with plasma5 iso
[16:02] <kdeuser56> shadeslayer: the "text" or "textonly" boot parameters, as well as the noninteractive boot parameters are documented in the official documentation
[16:03] <kdeuser56> shadeslayer: and I am currently not attatching any preseed file to the isos, I am just booting up the isos in a vm using the officially documented boot options and they are not respected
[16:03] <kdeuser56> this has nothing to do with preseed whatsoever
[16:04] <kdeuser56> shadeslayer: apart form that i have asked about preseeding various times in the past in the ubuntu-devel channel and got funny and contradicting answers by different people
[16:05] <kdeuser56> shadeslayer: it seems the general knowledge about preseeding (the desktop) is as bad as the documentation, or people simply do not want to share their knowledge
[16:09] <kdeuser56> shadeslayer: apart from that, the "maybe-ubiquity" option does not work either, which should bring up the dialog where you can choose between "install" and "try without installing"
[16:15] <kdeuser56> sorry for the flooding and the rant, I know you guys are doing an awesome job
[16:20] <Riddell> apachelogger: you ported software-properties and usb-creator to qt5, are you expecting those to be packaged and put into next?
[16:22] <kdeuser56> Riddell: did someone already look into providing the breeze c++ implementation? (for neon)?
[16:26] <Riddell> kdeuser56: what what?
[16:26] <Riddell> I'm not sure what that is
[16:27] <kdeuser56> Riddell: git://anongit.kde.org/scratch/hpereiradacosta/breeze as described here: https://forum.kde.org/viewtopic.php?f=285&t=122376
[16:28] <Riddell> aah so shadeslayer was right in saying that qtcurve was being replaced
[16:28] <Riddell> kdeuser56: anyway I doubt we'll package it until there's a release made, otherwise grumpyness tends to happen
[16:29] <kdeuser56> Riddell: sure
[16:29] <Riddell> makes me wonder what gtk 2 and 3 and qt 4 could be themed with
[16:29] <Riddell> and libreoffice
[16:29] <kdeuser56> Riddell: maybe hugo is so nice to also do the ports, since the work is based on oxygen
[16:35] <soee> guys are you able to android device in dolphion and navigate through all dirs/subdirectories on it ?
[16:35] <soee> *open
[16:36] <Riddell> yes although it's slow and not always reliable
[16:38] <soee> if i try to open some directory it is trying to read it and i se loading and loading and nothing more
[16:49] <kdeuser56> Riddell: what is the diff command for the patches in kubuntu?
[16:51] <Riddell> kdeuser56: we use quilt 
[16:51] <Riddell> or sometimes I just use git diff
[16:51] <Riddell> or sometimes I just use  diff -urN
[16:55] <kdeuser56> Riddell: thanks
[17:03] <kdeuser56> Riddell: where would I post a patch that should be included in a frameworks package?
[17:39] <Riddell> it's .. sgclark!
[17:40] <Riddell> aren't you trying to sync yourself to europe time?
[17:42] <shadeslayer> apachelogger: ping if you're around
[18:33] <Riddell> -- Installing: /build/buildd/plasma-workspace-5.0.1/debian/tmp/usr/etc/xdg/wallpaper.knsrc
[18:33] <Riddell> shadeslayer: next-staging installing into /usr/etc/ not /etc ?
[19:07] <sgclark> Riddell: Sorry, seems quassel failed to inform me of highlight. Trying being the operative word. Will be putting serious effort this week.
[22:55] <ScottK> Riddell: I've had no time for SRU stuff recently.
[23:49] <ahoneybun> hey valorie Riddell