[02:00] <ScottK> shadeslayer: ^^^ can you ask afiestas?
[02:05] <ahoneybun> hey jose
[02:05] <jose> hello, ahoneybun :)
[02:05] <ahoneybun> jose: what is the foss conf in orlando this yeat?
[02:05] <ahoneybun> *year
[02:06] <jose> ahoneybun: fossetcon, fossetcon.org
[02:07] <ahoneybun> signup is closed?
[02:10] <ahoneybun> wow 54 bucks to take a train there
[02:10] <ahoneybun> well to orlando
[02:12] <ahoneybun> jose: you put that email about UOS?
[02:13] <jose> ahoneybun: signup is not open yet but the call for papers is open
[02:13] <jose> which email about UOS?
[02:13] <ahoneybun> about sessions
[02:14] <jose> oh, I think that was valorie
[02:14] <ahoneybun> sorry yea
[02:14] <jose> but, if needed, I can approve sessions in both the community and cloud devops tracks
[02:14] <ahoneybun> I was trying to get one for the Kubuntu Docs team like there is one for the ubuntu docs team
[02:15] <ahoneybun> but the blueprint did not show up
[02:15] <jose> ahoneybun: do you have a link for it?
[02:15] <ahoneybun> does not show up at all
[02:15] <ahoneybun> jose: http://fridge.ubuntu.com/2014/05/28/calling-for-ubuntu-online-summit-sessions/
[02:15] <jose> oh, that one, yeah, I did :P
[02:16] <jose> ahoneybun: it needed to be approved, it's approved now
[02:16] <jose> should show up in Summit shortly so I can schedul it
[02:16] <jose> do you have any preferred times?
[02:16] <ahoneybun> oh 
[02:17] <ahoneybun> I'm on the EST time zone so Tu-F 3:00pm to 9:00pm
[02:17] <jose> https://blueprints.launchpad.net/kubuntu-docs/+spec/community-1406-kubuntu-documentation-team
[02:17] <ahoneybun> Mon is class
[02:17] <jose> hmm, lemme check
[02:17] <ahoneybun> I might want to change the project
[02:18] <ahoneybun> to kubuntu
[02:18] <jose> ahoneybun: are you on EST or EDT?
[02:18] <ahoneybun> UTC-5:00
[02:18] <ahoneybun> https://www.google.com/search?client=ubuntu&channel=fs&q=New+York+time+zone&ie=utf-8&oe=utf-8
[02:19] <jose> you're on -4 right now
[02:19]  * ahoneybun has lots of planning to do now
[02:19] <jose> ahoneybun: I can schedule it at 3PM EDT on Tue, Wed or Thu
[02:19] <ahoneybun> where is the pad we use
[02:19] <ahoneybun> Maybe valorie can join in too
[02:20] <ahoneybun> need to know her times though
[02:20] <jose> the blueprint is not on the system right now, so you might need to wait a bit to get the pad
[02:20]  * ahoneybun emails here
[02:20] <ahoneybun> *her
[02:23] <ahoneybun> hey valorie which time would be better for a UOS session for Kubuntu Docs Team  for you 3PM EDT on Tue, Wed or Thu?
[02:25] <ahoneybun> thanks jose 
[02:25] <jose> not a prob :)
[02:25] <ahoneybun> off to netflix and bed
[02:25]  * jose notes that 3 PM EDT = 19 UTC
[02:25] <jose> enjoy!
[06:20] <soee> good morning
[09:47] <BluesKaj> 'Morning folks
[09:55] <shadeslayer> Noskcaj: I don't follow your upower question
[09:58] <yofel> shadeslayer: I think he's just asking if kde will break with upower 0.99
[09:59] <shadeslayer> yes and no
[09:59] <shadeslayer> it will build
[09:59] <shadeslayer> but no gurantee that it'll work
[09:59] <yofel> well yeah, that was the question ^^
[10:32] <shadeslayer> yofel: any clue why cvsservice was dropped
[10:32] <shadeslayer> seems like it just got lost in the split
[10:37] <yofel> shadeslayer: got lost I believe
[10:37] <shadeslayer> ack
[10:48] <apachelogger> shadeslayer: election card overdue
[10:48] <shadeslayer> thx for reminding
[10:48]  * shadeslayer needs to close vote
[10:49] <shadeslayer> apachelogger: http://community.kde.org/Kubuntu/Policies#Election_Process_.28.28TBD.29.29
[10:49] <shadeslayer> looks done to me?
[10:50] <apachelogger> shadeslayer: I cannot give my vote nowhere
[10:50] <shadeslayer> ah
[10:51] <shadeslayer> I thought TBD meant that the section was still being hashed out in words
[10:51] <apachelogger> well yeah, it's not exactly very helpful :P
[10:52] <shadeslayer> I think it gets the point across
[11:08] <shadeslayer> ScottK: do you have a HTML template for the CIVS description?
[11:39] <ScottK> I just copied/pasted the one before. 
[12:10] <Riddell> santa_: I'm not merging your allLibrary variable as it looks to me like it just adds complexity rather than simplifies, otherwise all good
[12:21] <Riddell> santa_: and I removed polkit from kauth, it's qt4
[12:22] <santa_> Riddell: ah, ok apparently the cmake stuff asks for it
[12:23] <Riddell> yes, longstanding upstream problem
[12:46] <Riddell> "Git 2.0.0 released" waa, and I only just half understand git 1!
[12:51] <soee> :p
[12:51] <apachelogger> shadeslayer: oh btw, I think there is a script for getting all the email addys of members
[12:51] <shadeslayer> I know
[12:52] <shadeslayer> gives me 41 members
[12:52] <apachelogger> k
[12:52] <shadeslayer> though we have 46
[12:52] <apachelogger> people who list no email addy on launchpad will have to request access manually
[12:52] <shadeslayer> yep, just double checking poll description
[12:52] <shadeslayer> will send it out shortly
[12:54] <apachelogger> actually
[12:54] <shadeslayer> emails going out
[12:54] <apachelogger> what I just thought of
[12:54] <shadeslayer> apachelogger: too late
[12:54] <apachelogger> I think we could simply change the script to list $lpid@ubuntu.com
[12:54] <shadeslayer> probably
[12:55] <apachelogger> AFAIK the primary email on lunchpad will be what that leads to anyway
[12:55] <apachelogger> so in theory that should cover all members
[12:55] <apachelogger> and if someone has an invalid primary or whatever they would not get the mail eitherway 
[12:56] <shadeslayer> true
[12:56] <yofel> doesn't launchpad have a 'send to all members' button?
[12:56] <apachelogger> mail goes through civs
[12:56] <yofel> ah dang
[12:58] <ScottK> Mail not going through launchpad is a feature, not a bug. 
[13:01] <shadeslayer> ^^
[13:01] <shadeslayer> yofel: everyone gets a unique url
[13:02] <apachelogger> no one ever nominates me
[13:02] <yofel> yeah, I forgot about that for a second
[13:02] <apachelogger> life's a harsh mistress sometimes
[13:03] <shadeslayer> Actual votes cast thus far: 4 , hurray, 10% votes casted
[13:04] <sgclark> as a new member how do I get the *ubuntu email address?
[13:04] <apachelogger> that won't reach 50% IIRC :'<
[13:04] <apachelogger> sgclark: should get one after a while
[13:05] <sgclark> ok
[13:05] <apachelogger> sgclark: did someone tell you to change your launchpad id btw? ^^
[13:05] <shadeslayer> you can't if you've published packages
[13:05] <sgclark> huh?
[13:05] <apachelogger> I think you had a launchpad id with a number or something
[13:05] <shadeslayer> yep ^^
[13:05] <apachelogger> and then ubuntu address is lpid@ubuntu.com/kubuntu.org
[13:06] <apachelogger> council not telling people about things...
[13:07] <shadeslayer> apachelogger: blasphemy
[13:07] <apachelogger> sgclark: you'll want to delete your ppa, then you should be able to change your username on launchpad to something other than scarlett-7
[13:07] <shadeslayer> again, don't think so, you can't change once you've published packages I think
[13:07] <apachelogger> you can delete ppas
[13:08] <apachelogger> then you can change again
[13:08] <apachelogger> shadeslayer: the id itself has no baring on the publishing process in general
[13:08] <sgclark> I was not aware I have to change it? change it to what? sorry I am confused
[13:08] <apachelogger> works the other way around through the packages it will figure out which account did a change etc.
[13:08] <apachelogger> sgclark: right now you'll get an email address scarlett-7@ubuntu.com
[13:09] <sgclark> oh eww
[13:09] <apachelogger> if you want something nicer like sgclark@ubuntu.com you have to change your launchpad name
[13:09] <sgclark> I see now, thanks
[13:09] <apachelogger> sgclark: https://wiki.ubuntu.com/UbuntuEmail#Changing_your_Launchpad_name
[13:09] <shadeslayer> sgclark: fwiw I don't see your email in the kubuntu-members email list
[13:10] <shadeslayer> so I'll add you manually to the poll
[13:11] <apachelogger> https://launchpad.net/people/+me/+edit <- untick ' Hide my email addresses from other Launchpad users' to fix that :P
[13:11] <sgclark> ok yeah had to delete my PPA, I have to wait for that to complete
[13:12] <sgclark> I would like to start moving to my new email when I get that sorted tbh
[13:13] <sgclark> unhidden thanks
[13:13] <apachelogger> random word of advise: since the @kubuntu/@ubuntu addresses are aliases you always need your primary address on launchpad to be another one or you won't get any mail
[13:14]  * apachelogger didn't think of that and broke email delivery for a month ^^
[13:15] <Quintasan> https://launchpad.net/~kubuntu-ppa/+archive/ppa?field.series_filter=trusty
[13:15] <Quintasan> Was any testing done for those?
[13:16] <yofel> Quintasan: they should be fine, want to put them in -proposed?
[13:16]  * yofel totally forgot..
[13:16] <Quintasan> yofel: Do we have any script for that?
[13:17] <yofel> kubuntu-archive-upload --sru should do it
[13:17] <yofel> l10n you'll have to do by hand as usual
[13:18] <Quintasan> crap
[13:19] <Quintasan> yofel: Can't do it now. Somebody turned off my PC @ home.
[13:19] <yofel> np, there's still 3 days until .2 
[13:21] <shadeslayer> yofel: I could do it
[13:46] <Riddell> "chris.halls@credativ.co.uk has been removed from kubuntu-devel"  aww, he's one of the original folks who was there at the start when there was only 3 of us
[13:56] <shadeslayer> aw
[13:58]  * yofel just realized that he's been here for almost 5 years now...
[13:58] <yofel> time sure flies
[13:59] <apachelogger> how the octopus do we automate kf5/plasmanext/jellyfishworkspace packaging?
[14:00] <apachelogger> it's gonna be a drag^2 without some scripteroo
[14:01] <yofel> IIRC we have a --kf5 mode for the automation stuff, not sure what else so far
[14:01] <yofel> maybe a --mode=foo switch would be better
[14:01] <shadeslayer> --mode=unicorns
[14:01] <shadeslayer> there
[14:01] <shadeslayer> I just made it awesome
[14:01]  * apachelogger throws an empty coffee mug
[14:02] <apachelogger> yofel: what's that do?
[14:02] <yofel> --mode=doctor is more awesome
[14:02] <apachelogger> https://www.youtube.com/watch?v=4Lp5a-r3MJU
[14:02] <yofel> apachelogger: use a different package list file I think? Riddell added it IIRC
[14:03] <apachelogger> sounds like a drag already
[14:03] <apachelogger> down with the manual lists I say
[14:03] <yofel> it's not like kf5 or plasma<whatever> are that different from the sc
[14:03] <apachelogger> there's just more of it at different release cycles
[14:03] <yofel> well, we could delete some...
[14:03] <apachelogger> more of it means more possibility to screw up packaging, because we need to split everything 3 times over
[14:03] <yofel> the backport lists are there on purpose though, the other ones could be temporary
[14:04] <shadeslayer> Actual votes cast thus far: 10
[14:05] <shadeslayer> ~25% voting done
[14:06] <apachelogger> if I had a firmer grasp on what our automation does and needs to do I'd totally be able to comment in a useful way xD
[14:06] <shadeslayer> grab bzr, update bzr with new release number, grab tar, smash them together, run bzr-buildpackage
[14:07] <yofel> apachelogger: they're a really elaborate launchpad glue for a bunch of subprocess calls that do what you usually do
[14:08] <apachelogger> right
[14:08] <apachelogger> so
[14:08] <apachelogger> what if I need to make a change that applies to all frameworks
[14:08] <apachelogger> because really frameworks are very much alike at this point so a change to the packaging of one may well applie to every framework in its tier or all of them even
[14:09] <apachelogger> and let's make it interesting that changes happens outside a release packaging
[14:10] <Riddell> bash for loops are your friend
[14:10] <apachelogger> so you want to script rubbish manually whenever such a case arises?
[14:10] <yofel> didn't bother people enough to far to make a script
[14:11] <Riddell> https://notes.kde.org/p/kubuntu-ninjas-frameworks  kf5 beta 3 up <--
[14:11] <yofel> altough that idea is essentially how the backport hooks work
[14:18] <Riddell> anyone in germany want to see if they can renew our web server?
[14:18] <yofel> I'm pretty sure you'll have to ask whoever owns it about that
[14:20] <Riddell> yofel: the trouble is the guy who owns it has e-mailed to remind us that it's going to run out on june 26th
[14:21] <Riddell> yofel: so I e-mailed back to say how do we renew and I've not heard back
[14:21] <yofel> hm..
[14:21] <Riddell> yofel: would you be able to phone them up and ask?
[14:26] <yofel> I could I guess... are we covering the costs for it then?
[14:26] <Riddell> yofel: yes, council has agreed to do so
[14:28] <shadeslayer> Riddell: you could ask for costs to be reimbursed via the donation pot
[14:29] <Riddell> same thing, it's all kubuntu council money
[14:30] <Riddell> sgclark: lots of lovely new kf5 packages for fixing http://qa.kubuntu.co.uk/kf5-status/build_status_4.100.0_trusty.html
[14:30] <sgclark> Riddell: ok
[14:32] <apachelogger> why do they fail so much?
[14:33] <Riddell> dunno, to be investigated
[14:33] <apachelogger> version incompat
[14:33] <apachelogger> CMake Error at CMakeLists.txt:28 (find_package):
[14:33] <apachelogger>   Could not find a configuration file for package "KF5JS" that is compatible
[14:33] <apachelogger>   with requested version "4.100.0".
[14:33] <apachelogger> ^ also needs handling in automation
[14:33] <Riddell> hmm, maybe the scripts didn't update the build-depends
[14:34] <Riddell> foo it didn't
[14:34] <Riddell> I'll do a mass update
[14:34] <sgclark> ok so script issue?
[14:34] <sgclark> ok
[14:34] <Riddell> sgclark: unless you want to do it
[14:35] <sgclark> Riddell: probably something I should learn at some point
[14:36] <Riddell> sgclark: well I'd just do it with bash loops, I could show you on an ec2 or just try and describe it here
[14:37] <sgclark> Riddell: describe here should be fine
[14:37] <Riddell> I've a list of the frameworks http://starsky.19inch.net/~jr/tmp/LIST
[14:38] <Riddell> and I run stuff like    for asdf in `cat LIST`; do echo ${asdf}; mkdir ${asdf}; done
[14:38] <apachelogger> ^ why can't the automationdo that?
[14:38] <Riddell> apachelogger: that's the next issue to fix that
[14:38] <apachelogger> just make a list of things wrong with the automation please :P
[14:39] <Riddell> can't run automation init script twice
[14:39] <apachelogger> we have a rewrite card, so we best rewrite things and then accomodate new use cases
[14:39] <apachelogger> as to not write code for new use cases and possibly have to start over because the rewrite changed the architecture or something
[14:39] <Riddell> sgclark: and I run stuff like    for asdf in `cat LIST`; do echo ${asdf}; cd ${asdf}; kbzr co ${asdf}; cd ..; done
[14:40] <Riddell> sgclark: then one to run sed s,4.99.0,4.100.0, debian/control -i
[14:40] <Riddell> and another for extra-cmake-modules build-dep version
[14:40] <Riddell> then ones to bzr diff   bzr commit   bzr-buildpackage-ppa -s 2
[14:40] <Riddell> and then fix the automation script so it does the right thing next time :)
[14:41] <sgclark> hah ok
[14:42] <yofel> hm, I fixed the "does really stupid things when run twice" issue in the script really, I think what's missing is a suffix parameter for the upload
[14:42] <sgclark> you would probably be faster on this round, but I will improve my scripting skills
[14:43] <yofel> you would end up with the same commit message again though
[14:55] <shadeslayer> so much stuff to mere @_@
[14:58] <apachelogger> yes
[14:58] <apachelogger> how does merging work?
[15:00] <yofel> very manual
[15:00] <apachelogger> drag^3
[15:01] <shadeslayer> Quintasan: I need some polish vodka
[15:01] <shadeslayer> to tide over merges
[15:01] <shadeslayer> Quintasan: the hazelnut stuff
[15:01] <apachelogger> ualcoholic
[15:01] <shadeslayer> merges do that to you
[15:01] <shadeslayer> also I've come to love polish vodka :3
[15:01] <apachelogger> wanna do some python code reading instead
[15:02] <shadeslayer> no thx
[15:02] <apachelogger> pft
[15:02] <shadeslayer> that stuff makes you a drug user
[15:02] <apachelogger> our cmake log parser is way too fragile
[15:02] <apachelogger> I repaired one bit now another bit broke
[15:02] <shadeslayer> and I don't know any dealers
[15:03] <apachelogger> sounds like a kerfuffle 
[15:03] <apachelogger> did I mention that ark can easily be crashed by trying to close it while it is loading?
[15:03] <apachelogger> one of the top crasheroos that is
[15:03] <yofel> you can do that to kmail too
[15:06] <apachelogger> with kmail it doesn't surprise me that much
[15:06] <apachelogger> it's very big with many a great things it uses
[15:06] <apachelogger> but ark...
[15:06] <shadeslayer> apachelogger: fixed by tsdgeos
[15:06] <shadeslayer> or I vaguely recall seeing a patch
[15:07] <tsdgeos> apachelogger: yeah, you're old man, update and stop complaining _P
[15:07] <apachelogger> pft
[15:07] <apachelogger> I can't we first have to package 3000 tarballs ....
[15:08] <apachelogger> someone please explain the ppa-status script to me
[15:08] <yofel> self-documenting >.>
[15:09] <apachelogger> yesyes
[15:09]  * Riddell watches #ubuntu-meeting for rohan grilling
[15:09] <apachelogger> it marks the i386 build orange because "No lintian output in build log."
[15:09] <apachelogger> and the amd64 build it marks green
[15:09] <apachelogger> because I dunno
[15:09] <yofel> IIRC that was so someone actually notices if the lintian stuff is broken
[15:09] <apachelogger> yes
[15:09] <yofel> and amd64 has no arch:all build, so no lintian and list-missing checks
[15:10] <apachelogger> but why only i386
[15:10] <apachelogger>           # Lintian output is only generated on i386
[15:10] <apachelogger>             if (arch == "i386"):
[15:10] <apachelogger> ah
[15:10] <shadeslayer> Riddell: boo :P
[15:10] <apachelogger> holy mother of :@
[15:10] <apachelogger> so here's a story
[15:11] <apachelogger> mgraesslin noticed that the neon5 status page does not correctly track the orangeness of kinfocenter
[15:11] <apachelogger> so it turns out the cmake parser is kaput since forever as the cmake format changed (something I explicitly warned about when we first talked about automation btw :P)
[15:11] <apachelogger> so I repaired the cmake parser
[15:12] <apachelogger> and as it turns out the broken cmake parser somehow prevented the lintian thing to work as well
[15:12] <apachelogger> so now all i386 builds in neon5 are orange while previously they were green (because of the lintian thing...)
[15:12] <apachelogger> I must deduce that the script is not at all reliable and prolly should have been rewritten yesterday :'<
[15:14] <yofel> well wait
[15:14] <yofel> do you have a patched pkg-kde-tools package in your ppa?
[15:14] <apachelogger> no, we no use pkg-kde-tools
[15:14] <apachelogger> that's why it's orange
[15:14] <yofel> ah ok, then you'll have to cover lintian yourself
[15:15] <apachelogger> my problem is not with it being orange it's with the fact that previously half the cmake parser and the entire lintian check was broken and no one noticed because of how the script that does not handle error cases well/atall
[15:16] <yofel> well yeah, at the beginning the scripts had no error handling at all. I added a bunch, but that was more bandaid than anything
[15:25]  * Riddell learns about seeded-in-ubuntu
[15:25]  * apachelogger too
[15:25] <apachelogger> xD
[15:25] <shadeslayer> lol
[15:25] <shadeslayer> u so silly
[15:25] <apachelogger> old people.
[15:27] <Riddell> nothing wrong with grep seeds/*/*
[15:28] <apachelogger> I use the archive tools' edit-acl ^^
[15:28] <apachelogger> although that's more package set than seed
[15:29]  * apachelogger never actually had to check whether something is seeded, outside the scope of kubuntu anyway
[15:30] <apachelogger> I am too stupid to use python argparse
[15:30] <apachelogger> yofel: you surely know about the argparse, right? :S
[15:31] <yofel> didn't know about it until felix used it for the scripts, it's rather simple
[15:31]  * yofel always use optparse
[15:31] <yofel> *used
[15:31] <apachelogger> I don't manage to add an option without argument
[15:31] <apachelogger> perhaps impossible given the name
[15:32] <debfx> apachelogger: add action='store_true'
[15:32] <yofel> see like, the archive-upload script? e.g. --sru
[15:32] <debfx> or store_false
[15:33] <apachelogger> debfx: cheers
[15:37] <apachelogger> https://www.youtube.com/watch?v=8AOfbnGkuGc
[15:39] <apachelogger> shadeslayer: congratz
[15:39] <yofel> shadeslayer++
[15:39] <apachelogger> FYI: kubuntu-ppa-build-status now has a might --nolintian option to avoid the lintian check
[15:39] <shadeslayer> thanks :P
[15:40] <apachelogger> also much long topic with outdated rubbish
[15:40] <apachelogger> someone clean dat topic
[15:40] <yofel> there, shorter
[15:41] <Riddell> I find it quite worrying how wrap-and-sort likes to delete packages from debian/control
[15:41] <sgclark> really? I have not had that
[15:41] <apachelogger> los rubbish
[15:41] <apachelogger> why wrap-and-sort?
[15:41] <yofel> thanks for reminding me that I wanted to file a bug about that -.-
[15:42] <yofel> apachelogger: debian uses it, so merge-diff-reducing
[15:42] <apachelogger> jebus
[15:42] <apachelogger> actually it will increase the delta I think
[15:42] <yofel> Riddell: FWIW, if you fix the mess it did by hand, it shouldn't break it again
[15:42] <yofel> apachelogger: it won't
[15:42] <apachelogger> you sure?
[15:43] <yofel> I'm sick and tired of looking at install file diff where debian sorted and someone here just added files to the bottom
[15:43] <apachelogger> ah, install, who cares about install
[15:43] <apachelogger> wildcard all the shits :P
[15:43] <apachelogger> or more to the point
[15:43] <sgclark> I run it on everything now, but concerned with the deletes stuff stated above heh
[15:43] <apachelogger> if we didn't split everything three times over we'd not need install files
[15:44] <shadeslayer> Riddell: really? it deletes shit? :O\
[15:44] <yofel> sgclark: just verify that it didn't do anything stupid after running it (bzr diff usually tells you that pretty fast :P )
[15:44] <shadeslayer> pft bzr diff
[15:44] <shadeslayer> bzr qdiff ftw
[15:44] <sgclark> yofel: ok
[15:44] <shadeslayer> with nice colors
[15:44] <shadeslayer> my brain has been thanking me several times for switching to kompare and bzr qt :P
[15:44] <yofel> apachelogger: take that up with debian
[15:44] <apachelogger> are we sharing repos yet?
[15:45] <yofel> shadeslayer: FWIW, becoming a member of qt-kde on alioth is usually pretty trivial
[15:45] <yofel> which reminds me that I'm actually a member..
[15:45] <shadeslayer> I *might* already be one
[15:45] <shadeslayer> but I haven't logged into alioth in forever
[15:45]  * yofel makes his way home
[15:45] <yofel> might pick some low hanging merge fruits later
[15:50] <Riddell> hmm, I wonder if I'm a member
[15:56] <Riddell> sgclark: where, if anywhere, did you get to with the build-dep changes?
[15:56] <sgclark> Riddell: said it would be faster if you did, but I am trying now as I noticed they were unchanged :)
[15:59] <Riddell> sgclark: I just did a load of updates so you'll need to bzr update if you have a checkout
[16:00] <sgclark> Riddell: kbzr is where? 
[16:00] <santa_> Riddell: lasts changes https://code.launchpad.net/~panfaust/+activereviews feel free to decline if you already did one of these
[16:01] <Riddell> sgclark: kubuntu-dev-tools
[16:01] <Riddell> lp:kubuntu-dev-tools
[16:01] <santa_> ... and finally everything built https://launchpad.net/~panfaust/+archive/kubuntu-kf5-experiments
[16:01] <sgclark> ty
[16:01] <santa_> no more kubuntu today :P
[16:06] <sgclark> Riddell: is there a way to have bazaar remember my passphrase...
[16:07] <Riddell> sgclark: it should use your gpg no? so I guess it's a passphrase you have on the key?
[16:07] <sgclark> yeah
[16:08] <Riddell> s/gpg/ssh/
[16:08] <kubotu> Riddell meant: "sgclark: it should use your ssh no? so I guess it's a passphrase you have on the key?"
[16:08] <Riddell> but hmm, I don't know
[16:09] <Riddell> santa_: merged, thanks!
[16:10] <santa_> :)
[16:14] <Riddell> sgclark: I'm off soon, you can throw them up into the ppa when you make them, make sure you run bzr update as I've merged some bits from santa now
[16:15] <sgclark> Riddell: ok :) have a good night
[16:15] <Riddell> sgclark: the plasma-workspace conflicts are interesting, I'll get onto fix them upstream tomorrow
[16:16] <sgclark> Riddell: ok thank you
[16:16] <Riddell> sgclark: plasma-workspace source should be ust plasma-workspace no need for a -kf5 on the end
[16:16] <sgclark> Riddell: ok will fix that
[16:16] <Riddell> or in plasma-workspace-kf5-data .deb, also there's in incorrect "Depends: plasma-workspace-kf5"
[16:18] <sgclark> Riddell: ahh riht, other way around right?
[16:20] <Riddell> sgclark: plasma-workspace-kf5-data should be plasma-workspace-data and it doesn't need to depend on anything much
[16:20] <Riddell> plasma-workspace should depend on plasma-workspace-data
[16:20] <sgclark> fixed
[16:21] <sgclark> will upload that as well when built
[16:21]  * Riddell out
[16:22] <Riddell> shadeslayer: how do I turn off notifications in the new black themed spotify client?
[16:22] <Riddell> I don't really want to know what every new song is called
[16:32] <maco> Riddell: oi, whats this "JR's going away" stuff?
[16:32] <ScottK> What? 
[16:33] <maco> ScottK: not kubuntu related i dont think
[16:33] <maco> Riddell: (on fb)
[16:34] <maco> ScottK: saw a thing about a going away party for him and wondered
[16:34] <ScottK> Hmmmm
[16:36] <maco> exporting scottish influence around the world?
[16:39] <ScottK> Dunno. So far that's proven to be pretty hazardous. 
[16:40] <maco> indeed
[16:42] <ScottK> There's http://en.m.wikipedia.org/wiki/Darien_scheme more generally too.
[16:43] <maco> hahah yes i remember that
[16:43] <maco> from reading a bit of a scottish history book
[16:43] <maco> "what's got the english so rich?" "colonies!" "ok we'll get ourselves a colony. what isn't taken yet?" "uh...hmm...well there's this little bit of land overrun with mosquitos and malaria..." "PERFECT!"
[17:11] <yofel> sgclark: there's ssh-agent for not typing the ssh password all the time
[17:11] <yofel> run 'ssh-add' to unlock the key
[17:12] <sgclark> yofel: yay! thanks
[17:12] <sgclark> was taking the automation out of it lol
[17:13] <yofel> yeah, and there's gpg-agent for the other key, though that might need enabling in the config file
[17:23] <sgclark> yofel: I was able to change my launchpad id to sgclark, is there anything else I need to do to get the *ubuntu email?
[17:24] <yofel> I don't *think* so, the alias updates are automatic I think, might take a while though
[17:24] <sgclark> ok thank you
[17:34] <apachelogger> Riddell: why are you staging in experimental?
[17:36]  * apachelogger hijacks builders
[17:40] <sgclark> yofel: ok so bzr diff confirms that wrap-and-sort is indeed doing stupid things eg. removed -dev packages, just skip it?
[17:41] <yofel> sgclark: rather fix what it did wrong, from what I've seen it won't break it again after that
[17:42] <sgclark> yofel: ok
[17:42] <yofel> probably gets confused by too much wrapping -.-
[17:42] <yofel> sgclark: what's the broken package btw.?
[17:43] <sgclark> I am bumping versions on all of the broken kf5 new releases. noticed some did not have wrap-and-sort, so ran it and a great many broken, but I have not committed
[17:44] <yofel> just tell me one so I have something to report a bug with
[17:44] <sgclark> it is all local. want me to commit a broken one?
[17:44] <yofel> no, rather fix it first, but tell me the name
[17:45] <apachelogger> https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/plasma-workspace-kf5
[17:45] <apachelogger> that branch name looks broken
[17:45]  * apachelogger goes :/
[17:45] <yofel> it very much is o.O
[17:45] <sgclark> apachelogger: right, Riddell: made me aware and it is on my long to do list today
[17:45] <yofel> esp. as that doesn't even need the suffix
[17:46]  * sgclark knows and is fixing
[17:46] <yofel> sgclark: could I have an example please?
[17:46] <apachelogger> sgclark: we should move everything to project kubuntu-packaging-next 
[17:46] <apachelogger> avoids name clashes altogether
[17:46] <sgclark> libkf5runner yofel
[17:46] <yofel> thanks :)
[17:47] <sgclark> apachelogger: where is that?
[17:47] <apachelogger> not yet created
[17:47] <yofel> apachelogger: does that really warrant adding project name handling to the scripts?
[17:48] <apachelogger> at least all my scripts work under the assumption that upstream name == branch name
[17:48] <apachelogger> notable and only exception to that is qt
[17:48] <apachelogger> that was one of the original naming considerations when we set up the branches
[17:48] <yofel> right
[17:48] <apachelogger> if you don't hold on to something you end up with random names like plasma-workspace-kf5
[17:48] <yofel> yeah, good point
[17:48] <apachelogger> which is neither tied to the source nor to upstream
[17:49] <apachelogger> all that said, IMO it warrants adding project name handling ^^
[17:49] <yofel> sgclark: what's the source name for that?
[17:49] <apachelogger> plasma-workspace
[17:49] <apachelogger> yofel: legit conflict is kactivities I believe
[17:50] <sgclark> apachelogger: yofel: I only that that that because the previous version was kde-plasma-kf5 and upstream renamed it plasma-workspace. I should not have kept the kf5 and I now know that , but did not when I created it.
[17:50] <apachelogger> basically the options are a) create a new super project until we transit to next b) suffix or prefix *everything* with kf5
[17:51] <apachelogger> sgclark: well, there's a bigger naming problem at work here ^^
[17:51] <yofel> well, new project and moving branches once the old ones are obsolete would be the way to go IMO
[17:51] <apachelogger> we now can have two concurrent versions of a source
[17:51] <sgclark> I agree that only some being kf5 is rather confusing
[17:52] <apachelogger> yofel: yep
[17:52] <apachelogger> also that just reminded me that we should create kubuntu-packaging-abandoned where we can move old branches like the previous monolithic ones
[17:53] <apachelogger> e.g. it happend to me that I pulled kdesdk and worked on it and only afterwards realized that we don't even use that branch anymore ^^
[17:53] <apachelogger> fortunately bzr doesn't actually care about the branch status you can define on launchpad, so you have no actual indication that you should not use that branch 
[17:54] <yofel> I don't particulary care about those, so I'm fine with anything
[17:54] <apachelogger> alternatively we could actually do a rm * commit on old branches, but I think it'd be in favor of tooling performance if we simply move abandoned stuff elsewhere
[17:54] <apachelogger> or well, we do both ^^
[17:55] <yofel> anyone against me wiping our quantal stuff from the PPA's? It's EOL
[17:56] <apachelogger> death to quantal!
[17:57] <ScottK> Kill it with fire.
[17:57] <yofel> heating up :)
[17:58] <apachelogger> this kf5 version hiccup is fun, it's like I now get to poke two ppas to get over the version problem ^^
[17:58] <apachelogger> build queue will be lovely thanks to me :P
[18:01] <apachelogger> sooooo
[18:01] <apachelogger> project name kubuntu-packaging-next or kubuntu-packaging-kf5 or kubuntu-packaging-frameworks
[18:01] <yofel> IMO next, if you want to have plasma in the scope too
[18:02] <apachelogger> that'd be the idea
[18:02] <apachelogger> also it would align with ppa:kubuntu-next
[18:03] <apachelogger> https://launchpad.net/kubuntu-packaging-next
[18:03] <apachelogger> sgclark: are you still working on the branches?
[18:04] <sgclark> apachelogger: yeah
[18:04] <apachelogger> ok
[18:04] <sgclark> fixing some wrap-and-sort breaks
[18:04] <apachelogger> yofel: we need to unify script naming ^^
[18:05] <yofel> as in?
[18:05] <apachelogger> also merge kubuntu-automation in kubuntu-dev-tools or vice versa
[18:05] <apachelogger> yofel: 
[18:05] <apachelogger> astyle-kubuntu  buildstatus   kbuildppa  kde-l10n-build-status  kgetsource       klearppa     kopypackages   kshowseries                 kubuntu-update-symbols  plymouth-rgb-normalizer  pull-ppa-source
[18:05] <apachelogger> batpaste        kbranchmover  kbzr       kde-sc-build-status    khighestversion  klinksource  kshowbranches  kubuntu-members-email-list  newpackage              pull-ninjas-source
[18:05] <apachelogger> many hard to parse. such mess
[18:05] <yofel> heh, yeah
[18:06] <apachelogger>     new_branch = lp.load('https://api.launchpad.net/1.0/~kubuntu-packagers/' + new_project_name + '/ubuntu/') :O
[18:06] <apachelogger> when did we move to that scheme?
[18:06] <yofel> where did you get that from o.O?
[18:07] <apachelogger> kbranchmover
[18:07] <apachelogger> apparently I wrote that script to move branches, but the nature of the move is a mystery to me
[18:07] <yofel> btw. kubuntu-dev-tools was supposed to be packagable IIRC, kubuntu-automation started as a stand-alone set of scripts (bzr-buildpackage-ppa should definitely be in -tools though)
[18:08] <yofel> apachelogger: well, that was our ancient branch naming scheme, but that's like a few years old
[18:08] <apachelogger> I think the packaged version is severely out of date
[18:08] <apachelogger> it would be so nice if one could have automated builds directly to the archive
[18:08] <yofel> apachelogger: it's not even in the archive I think. I have a recipe for it somewhere
[18:08] <apachelogger> it was in the archive 
[18:09] <apachelogger> I definitely landed it after we created it
[18:09] <apachelogger> but that was way back in the batcave days
[18:09] <yofel> I know, but that was long ago
[18:09] <yofel> the current changelog has changes staged for precise ^^
[18:10] <apachelogger> [17:00] <CIA-52> [kubuntu-dev-tools] Harald Sitter <apachelogger@ubuntu.com> * apachelogger@ubuntu.com-20110628160033-w96uq8832y339i67 * (bin/kbranchmover debian/changelog) Add kbranchmover for moving branches around
[18:10] <apachelogger> shadeslayer: there, I can also write useless commit messages :P
[18:10] <apachelogger> also that reminds me... we need a new commit bot ^^
[18:10] <yofel> the script also need some code sharing. I believe we have like 4 different code sets for pasing ppa:<owner>/<archive>
[18:10] <yofel> *parsing
[18:10] <apachelogger> kubotu: care to take over?
[18:11] <yofel> and different behavious between scripts
[18:11] <apachelogger> yofel: because sharing code in python is a flipping pain in the bum
[18:11] <yofel> *behaviour
[18:11] <apachelogger> require_relative ftw!
[18:11] <yofel> apachelogger: well, I know, I tried if you remember -.-
[18:11] <yofel> the mess is still there...
[18:11] <apachelogger> rewrite launchpadlib in ruppee, problem solved. 
[18:12] <apachelogger> been sayin that all along
[18:12] <yofel> well, you *can* have local python includes
[18:12] <yofel> I was trying to keep it packagable...
[18:12] <apachelogger> yofel: that's when the madness begins, I know ^^
[18:13] <yofel> I still wonder if we'll have python3-launchpadlib in this decade ^^
[18:13] <apachelogger> rewrite in ruppeee.
[18:14] <yofel> do we have ruby-lazr.restfulclient or how that thing was called?
[18:14]  * yofel sweeps the quantal ashes together
[18:14] <apachelogger> my world goes like this: write in javascript, if it aint working rewrite in ruby, if it aint working rewrite in c++
[18:14] <yofel> RIP
[18:14] <apachelogger> yofel: I am sure there is some nonesense like that
[18:16] <apachelogger> anyway the problem is that I personally could not be bothered to even look into how exactly this lazr thing works
[18:16] <apachelogger> so I shall not do the rewrite
[18:16] <apachelogger> I hear shadeslayer is down for some coding though 
[18:16] <apachelogger> shadeslayer: piiing
[18:17] <yofel> apachelogger: you know, we should totally make our scripts a single python library and have executables that all only call a single function for bash compatibility
[18:17] <apachelogger> rewrite in bash you say?
[18:17] <apachelogger> yes, I agree
[18:17] <yofel> lol, I would if I could
[18:17] <apachelogger> eval "expr \"\$"$1"\" "
[18:17] <yofel> I was happy that I could keep the backport script in bash
[18:17] <yofel> hahaha
[18:18] <apachelogger> argparsing in bash is crap though
[18:18] <apachelogger> so, I am not too sure from a usage perspective bash would improve anything
[18:19] <apachelogger> generally I agree with the notiion of separating logic into standalone binaries though
[18:19] <apachelogger> this would then also make the earlier discussed approach of having to manually write tiny scripts to do batch editing of things
[18:19] <apachelogger> ..less awful
[18:20] <yofel> at some point I wanted to have it all bash and only glue to python where launchpad was needed, but that's a performance nightmare in some cases :/
[18:20] <apachelogger> depends on what you do
[18:20] <yofel> call a script that opens a connection to launchpad in a bash loop :P
[18:20] <apachelogger> mind you, technically you could pass lambda style bash logic to wahtever wrapper binary
[18:21] <apachelogger> yofel: the thing is why would you need that? :P
[18:21] <yofel> I can't remember, but there was something
[18:22] <apachelogger> as I see it short of actual ppa data retrieval you don't need to call the helper all the time
[18:22] <apachelogger> like when you need a set of branches you'd simply use a script that spits out a list of branches, then you process that in bash and actual branch content editing would happen via bzr anyway
[18:23] <yofel> I think in many cases it's like resolving distro versions etc. which *could* be worked around
[18:23] <apachelogger> ohohoho, now I get the kbranchmover 
[18:24] <apachelogger> it moves from /ubuntu to project specific branches
[18:24] <yofel> uh yes...? ^^
[18:24] <apachelogger> the variable name is very smarter there     new_branch = lp.load('https://api.launchpad.net/1.0/~kubuntu-packagers/' + new_project_name + '/ubuntu/')
[18:24] <apachelogger> shitty dev I say
[18:24] <yofel> lol
[18:25] <apachelogger> that's pretty much how I read code... look at the longest line there is and 90% of the time that should tell you what is going on :P
[18:26] <yofel> apachelogger: so, if we want to merge the tools and automation, make one non-packagable or leave the other one just for runtime stuff?
[18:27] <apachelogger> I don''t think packagable is necessary
[18:27] <apachelogger> what should work is easy deployment to $HOME though
[18:27] <apachelogger> one way or the other
[18:28] <yofel> well, you can do local installs with setup.py, or maybe use virtualenv
[18:28] <apachelogger> kitemmodels-work
[18:28] <apachelogger> what's them branches Oo
[18:28] <yofel> sounds like santa_
[18:29] <yofel> he had something with -work
[18:29] <apachelogger> oh right, getting all branches of a project lists everything I don't care as well -.-
[18:29] <apachelogger> :@
[18:29] <yofel> enjoy the bazaar branch management shittyness :(
[18:30] <apachelogger> branch management? lol? :P
[18:30] <yofel> you get the point..
[18:30] <apachelogger> the absence of management, yeah ^^
[18:30] <santa_> actually I'm not disgusted with bazaar and launchpad
[18:31] <yofel> santa_: were's talking scalability here
[18:31] <apachelogger> I think I am looking at the wrong api documentation again
[18:31] <apachelogger> yofel: fun idea: how about we move to github? :P
[18:31] <yofel> apachelogger: we're using a mix of 1.0 and devel depending on the script
[18:31] <apachelogger> yeah, the documentation is just confusing
[18:31] <yofel> sure, it has git in it
[18:32] <apachelogger> always takes me a while to get used to reading it
[18:32] <apachelogger> found the branch object now ^^
[18:32] <santa_> and yes, have a zillion -work branches, mainly to correct the build issues
[18:33] <santa_> what I'm suposed to do with them, now that are all merged, remove them?
[18:34] <yofel> if people would use launchpad correctly it should be marking them automatically as 'Merged'. Just leave them
[18:37] <apachelogger> launchpad marking them as merged doesn't really do anything other than them not showing up in search results on the website
[18:42] <yofel> should also hide it from the default API listing
[18:44] <apachelogger> yofel: apt listing?
[18:44] <yofel> launchpadlib listing
[18:44] <apachelogger> ah yeah
[18:44] <apachelogger> that is true
[18:50]  * apachelogger wonders how kubuntu-packaging ended up with 500 branches
[18:50] <apachelogger> madness
[18:50] <yofel> well, nobody wanted to create one project per upstream source...
[18:51] <yofel> (even if the API can do that very well)
[18:52] <apachelogger> I wanted to :'<
[18:52] <apachelogger> got downvoted
[18:53] <yofel> oh, sorry then
[18:53]  * yofel curses reportbug
[18:55] <ahoneybun> valorie: http://summit.ubuntu.com/uos-1406/all/
[18:55] <apachelogger> juju is still a thing
[18:55] <apachelogger> magic
[18:56] <yofel> which reminds me we need to re-start the mir flamewar at UOS
[18:56] <apachelogger> we do?
[18:57] <yofel> wasn't that the plan?
[18:57] <apachelogger> I dunno
[18:57] <yofel> the CC said to talk about it at UOS, they don't care
[18:58] <apachelogger> can I get a wayland plasma before that?
[18:59] <yofel> dunno, is it still using X in neon?
[18:59] <apachelogger> yeah
[18:59] <yofel> :(
[19:00] <apachelogger> mostly because MG doesn't want to hold the train up with wayland migration I think
[19:00] <yofel> aha, I guess I as nvidia user should be happy
[19:01] <apachelogger> depends on whether you use novuvulusdlfyo that one is pretty much busted with next I think
[19:01] <apachelogger> as is radeon
[19:01] <apachelogger> as is intel
[19:01] <apachelogger> xD
[19:01] <yofel> I am not
[19:02] <yofel> now, how do I re-send a reportbug report without a properly setup sendmail MTA -.-
[19:02] <yofel> it's this rare moments that I actually like apport in
[19:03] <sgclark> yofel: I have commited my  changes now, but Riddell wanted me to run bzr-buildpackage-ppa -s 2 but all complain that it can't fine package upstream, not sure what to do
[19:04] <yofel> missing watch files, you can work around it by putting the deb-src line for the ppa in your sources.list
[19:04] <yofel> (if the ppa has the source)
[19:15] <sgclark> yofel: that worked thank you
[19:25] <ahoneybun> yofel: I have a notebook with intel + nvidia graphics
[19:25] <yofel> that's the perfect fun combination :D
[19:32] <ahoneybun> yofel: thank fully the new driver manager handles it great
[19:42] <BluesKaj> Optimus ahoneybun?
[19:42] <ahoneybun> BluesKaj: yep
[19:44] <BluesKaj> ahoneybun, nice to know that the new drivers will work with those gpus and the switch, that setup was troublesome in the past
[19:44] <ahoneybun> well the driver manager does not install the switch but I did install it in a previous setup and it seemed to work
[19:45] <ahoneybun> right now it just is using the nvidia for eveyrhting
[19:46] <sgclark> yofel: ok so now it fails at debsign I am not jriddell. I dch -a as I was told in the past, not sure how to tell it to sign with my key
[19:50] <apachelogger> sgclark: debsign -kKEYID
[19:51] <apachelogger> KEYID can be your name or the actual id of the key
[19:51] <sgclark> with bzr-buildpackage-ppa?
[19:52] <sgclark> first or append to that command? sorry first time trying this apachelogger
[19:53] <apachelogger> hum, no clue 
[19:53] <apachelogger> let's see
[19:53] <apachelogger> sgclark: yeah, simply append apparently
[19:54] <sgclark> great, thank you!
[20:06] <yofel> sgclark: you can also permanently override the key in ~/.devscripts
[20:06] <yofel> e.g. I have "DEBSIGN_KEYID=2EC0A9FF" in there
[20:09] <sgclark> oh ok, will try that appending is not working 
[22:11] <doctorpepper> hi guys !!!
[22:22] <Riddell> sgclark: how did you get on?
[22:23] <sgclark> Riddell: all the way to bzr-buildpackage-ppa and that is not going well
[22:23] <Riddell> maco: got bored of scotland, going to find a repressed country where I can moan about central government more
[22:23] <Riddell> sgclark: what's up?
[22:24] <maco> Riddell: just before you get to vote for independence?!
[22:24] <Riddell> maco: I'll get a postal vote :)
[22:25] <sgclark> Riddell: had debsign error, yofel and apachelogger helped me with that and now new error without any sort of message as to why. I am starting again with fresh checkouts.. wish me luck
[22:25] <Riddell> good luck
[22:26] <Riddell> apachelogger: I'm experimenting in experimental
[22:43] <sgclark> Riddell: seems like it is working now, does this put to PPA or do I need to do another bash loop for that ?
[23:06] <santa_> sgclark: kdnssd-kf5 is still at 4.99.0 in bzr apparently
[23:15] <apachelogger> all hail the mighty insomnia
[23:15] <apachelogger> Riddell: experimental doesn't mean that entire package stacks should be broken
[23:16] <apachelogger> that's what staging is for
[23:16] <apachelogger> sgclark, Riddell: I am going to do a mass move of all branches to kubuntu-packaging-next project in a bit
[23:18] <sgclark> apachelogger: I am still building, please wait a little longer. almost one
[23:18] <sgclark> done
[23:22] <sgclark> santa_: not sure what happened there, looks like your merge was merged after my changes
[23:22] <apachelogger> that happens when one doesn't use git :P
[23:24] <ahoneycutt> you on valorie ?
[23:25] <valorie> I'm here
[23:25] <valorie> I saw your ping yesterday, but you had disappeared
[23:26] <sgclark> ok apachelogger all has been built (that didn't get broken) with bzr-buildpackage-ppa. Should I wait to puch these until you do this move?
[23:26] <valorie> what you have filed looks more like the typical old UDS meeting plan
[23:26] <sgclark> s/puch/push
[23:26] <valorie> rather than a presentation
[23:26] <valorie> what exactly do you envision, ahoneycutt?
[23:26] <apachelogger> sgclark: depends on whether your branches are unbound or checkouts
[23:26] <sgclark> checkouts
[23:26] <apachelogger> then you'll have to wait I guess
[23:27]  * valorie sends along some sleepy time tea to apachelogger
[23:27] <apachelogger> valorie: oh, I got myself coffee actually ;)
[23:27] <apachelogger> sleep is for the weak
[23:27] <valorie> that'll help.....
[23:27] <valorie> lol
[23:27] <valorie> sleep is a unix command!
[23:28] <apachelogger> a mostly incorrectly used one mind you ^^
[23:28] <ScottK> valorie: t-shirt
[23:28] <valorie> tshirt?
[23:28] <sgclark> apachelogger: so just to be clear after bzr-buildpackage-ppa I need to do another bash loop to dput these right? and is this where they will be going to a new location other than experimental, or are you moving them to another bzr?
[23:29] <sgclark> and hello valorie :)
[23:29] <apachelogger> it's a shirt with tea
[23:29] <ScottK> That'd be a good one
[23:29] <valorie> ah, true
[23:29] <valorie> apachelogger: don't spill your tea on your shirt
[23:29] <valorie> that is untidy
[23:30] <valorie> hi scarlett
[23:30] <apachelogger> sgclark: the bazaar branches are moving, although I guess you could upload to kubuntu-ppa/kubuntu-next right away
[23:30] <apachelogger> we'll have to move all the kf5 stuff there anyway
[23:30] <ahoneycutt> valorie: to show the community the current way we work our docs, try to open it up more to the community and maybe get some better ideas to improve our current ways
[23:30] <sgclark> apachelogger: ok I will do that, thanks!
[23:30] <apachelogger> valorie: I am wearing a proper shirt
[23:31] <apachelogger> bzr branches moved https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next
[23:31] <valorie> sounds good, ahoneycutt
[23:32] <valorie> apachelogger: appropriate costume is important
[23:32] <apachelogger> indeed
[23:32]  * valorie is wearing a destop summit T
[23:32] <valorie> reminds me of fun times in Berlin
[23:32] <apachelogger> berlin I do not remember
[23:33] <apachelogger> when did we visit berlin?
[23:33] <apachelogger> oh, desktop summit
[23:33]  * valorie sneaks brandy into the apachelogger's coffee
[23:33]  * apachelogger totally thinks that was more of a tomahawk sprint for him
[23:33] <apachelogger> :O
[23:33]  * ahoneycutt is wearing Trusty Tahr Ubuntu shirt
[23:33] <apachelogger> it's before noon here :P
[23:34] <valorie> lol
[23:35] <ahoneycutt> valorie: anything you think we need to discuss there?
[23:35] <apachelogger> sgclark: I'll also need to rename some branches for the name fixing, not right now if you need the branches though
[23:36] <valorie> gathering more translators, ahoneycutt
[23:36] <apachelogger> also Riddell's branch list was incomplete it seems :O
[23:36] <ahoneycutt> valorie: that was the main goal, if we show more people how easy it is to summit translations more will come https://blueprints.launchpad.net/kubuntu-docs/+spec/community-1406-kubuntu-documentation-team
[23:36] <valorie> it's pretty early to begin making the docs for this round, since most technical decisions are in process
[23:36] <apachelogger> sgclark: going to move another bunch of branches now
[23:37] <sgclark> ok
[23:37] <ahoneycutt> valorie: well it can help us brainstorm for this round then
[23:37] <apachelogger> fun story: there actually are two branches for kdnssd since yesterday :S
[23:39] <apachelogger> valorie, ahoneycutt: since we do not do feature development for 4.x I doubt there will be much change between now and release
[23:39] <sgclark> apachelogger: ok rejection fun, so I need to copy all these from experimental?
[23:39] <apachelogger> except for version bumps and those are also rather featureless with a lot of the workspace working happening in 5.x
[23:39] <apachelogger> sgclark: no, huh, what kind of rejection?
[23:40] <sgclark> dput
[23:40] <sgclark> to next
[23:40] <apachelogger> sgclark: ah, sorry, the ppa is kubuntu-ppa/next
[23:40] <sgclark> can't find .orig
[23:40] <apachelogger> sgclark: oh
[23:40] <apachelogger> why that is bad ^^
[23:40] <apachelogger> sgclark: will have to wait for branch moving then
[23:40] <sgclark> yes haha
[23:40] <sgclark> ok
[23:42] <valorie> ahoneycutt: I'll bbl -- laundry then dinner now
[23:43] <apachelogger> sgclark: you could copy them and then upload the new versions, or you could rerun buildpackage with another flag that forces it to upload the origs
[23:43]  * apachelogger can't find the flag though
[23:43] <ahoneycutt> apachelogger: mostly to look at our current ways and tools and think as a team to see if we could do better, and get more translators on board
[23:43] <apachelogger> possibly it was -si
[23:43] <sgclark> apachelogger: I will copy them
[23:45] <apachelogger> sgclark: all branches should be moved now
[23:45] <apachelogger> https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next
[23:45] <sgclark> ok
[23:45] <sgclark> ty
[23:45] <apachelogger>  5. By Scarlett Clark <scarlett@saturn> 9 hours ago 
[23:45] <apachelogger> sgclark: you may want to fix bzr whoami
[23:46]  * apachelogger writes mail
[23:46] <sgclark> blah lol, ok thanks
[23:53] <apachelogger> http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging-next/plasma-workspace/view/head:/debian/changelog is there a reason the source has a suffix btw?