[07:04] <flexiondotorg> Morning
[07:04] <flexiondotorg> Martin for Ubuntu MATE here. Just wondering how the Kubuntu 16.04.1 image testing is going?
[07:08] <acheronuk> I haven't had a chance myself. Yesterday the isotracker links to the images were even broken
[07:09] <acheronuk> ah. fixed this morning. that helps!
[08:40] <jimarvan> Good morning peeps
[08:49] <santa_> jimarvan: good morning
[08:59] <yofel> moin
[09:02] <jimarvan> hey yofel
[09:02] <jimarvan> all alright?
[09:29] <yofel> jimarvan: somwhat
[09:29] <yofel> I could use less heat :P
[09:43] <jimarvan> hehe
[09:49] <yofel> santa_: you want to reply to ben's email about packager access to depot, 
[09:49] <yofel> "Just as a final reminder, i've yet to see responses from:
[09:49] <yofel> - Siduction </snip others>
[09:49] <yofel> The accounts for the above will be closed based on the lack ofresponse in 2 days time."
[09:52] <santa_> yofel: I did, did you got the mail CC'ed to kubuntu-devel?
[09:52] <yofel> santa_: no, what mail? (maybe it's in the moderation queue?)
[09:53] <santa_> yofel: https://lists.ubuntu.com/archives/kubuntu-devel/2016-July/010545.html
[09:53] <santa_> maybe your filters sent it to other folder
[09:53] <yofel> ah, possibly
[09:55] <yofel> santa_: key added
[09:55] <yofel> user is ftpubuntu
[09:57] <santa_> yofel: ack, where did you get my key? I have several
[09:57] <yofel> santa_: launchpad
[10:04] <santa_> yofel: nice, thank you, just reconfigured ssh, tested and works
[10:15] <santa_> clivejo, yofel: btw I finished adding qt support to the bd bumping system, I tested it doing a test rebuild of frameworks and plasma
[10:15] <santa_> http://gpul.grupos.udc.es/tritemio_buildstatus_ubuntu-exp3/ubuntu-exp3_status_kf5.html
[10:15] <santa_> http://gpul.grupos.udc.es/tritemio_buildstatus_ubuntu-exp3/ubuntu-exp3_status_plasma.html
[10:16] <santa_> everything built fine i.e. no hanging builds because of an incorrect versioned build depend
[10:16] <santa_> testing also with applications as we speak
 Can someone look at plasma 5.7.1 staging please?
 Figure out why breeze won't build on Xx
[10:48] <yofel> Clifford: acheronuk figured that out (see #kde-neon), needs a fix for qtchooser
[10:49] <acheronuk> yofel: clivejo Which 30s ago I uploaded
[10:52] <acheronuk> hopefully that will fix it, or at least get it a stage closer anyway
[10:53] <santa_> what's the problem with qtchooser?
[10:55] <acheronuk> santa_: needed http://packaging.neon.kde.org/cgit/qt/qtchooser.git/commit/?h=Neon/release&id=b8d8e0eba28299b260f8ba887b017a447a5aecd0
[10:55] <acheronuk> if the backport was going to work for xenial
[10:59] <santa_> acheronuk: ah, ok, nothing to worry for my current tests
 Ah its a Qt issue
[11:43] <acheronuk> yes, and breeze just built :)
 Acheronuk use the retry script to poke the rest on
[11:48] <acheronuk> I have no idea how or where that is. lol
 Kubuntu automation
 Should be an example in readme
 Sorry I'm not at computer at the moment
[11:51] <acheronuk> while true; do ./kubuntu-retry-builds -r plasma --ppa=kubuntu-ppa --ppaname=staging-plasma --force; sleep 1200; done
[11:51] <acheronuk> that?
[11:52] <soee> o/
[11:53]  * soee is going to buy https://www.amazon.co.uk/LG-29UC97C-Ultrawide-2560x1080-Speakers/dp/B010PVTFJK
[11:54] <acheronuk> nice
 Yes. But drop the while loop
[11:57] <acheronuk> so just ./kubuntu-retry-builds -r plasma --ppa=kubuntu-ppa --ppaname=staging-plasma --force
 Yup
[11:58] <acheronuk> gotcha
 20 mins isn't enough time at the moment
[11:58] <acheronuk> 20 mins?
[11:59] <acheronuk> oh, right
 That while loop runs the script every 20 mins
[11:59] <acheronuk> yes, sorry. just realised that obviousness after I typed
[12:02] <acheronuk> Could not find package filepackage-name-lists/plasma-wily for package
 -d xenial
[12:08] <acheronuk> clivejo: -s option to specify xenial?
 Or update the script to default to xenial :)
[12:10] <acheronuk> I think that is running. I will update it later, as that seems an obvious thing to set now
 Can you keep poking it after plasma-intregration
 Publishes
[12:48] <acheronuk> yes, just have done
[13:00] <clivejo> acheronuk: what was wrong with Qt chooser?
[13:01] <clivejo> ah I see
[13:02] <clivejo> can you copy the fixed package to KCI too please?
[13:04] <acheronuk> done.
[13:05] <clivejo> acheronuk: get anywhere with asking for a KDE bouncer?
[13:05] <acheronuk> clivejo: I'm on it now
[13:05] <clivejo> ah nice
[13:06] <acheronuk> ugly hostname cloak, but not really fussed on that
[13:07] <clivejo> cant you get a community cloak?
[13:09] <acheronuk> probably. I may ask...
[13:16] <clivejo> acheronuk: fancy staging plasma 5.7.2?
[13:17] <acheronuk> can do. :)
[13:17] <clivejo> and testing santa_ 's new scripts to bump qt and plasma deps at the same time
[13:19] <acheronuk> going to have to talk me through that again
[13:19] <clivejo> probably need santa_ on hand as Im not sure of the new script options myself
[13:20] <santa_> acheronuk, clivejo: yeah
[13:20] <santa_> I'm here
[13:20] <clivejo> :)
[13:20] <santa_> so ... lets try the new scriptery?
[13:20] <clivejo> so we want to stage plasma 5.7.2 using the scripts can you guide us?
[13:21]  * clivejo opens a new notepad
[13:21] <santa_> of course I might need to fix/adjust some things on the fly
[13:21] <davmor2> hey guys is anyone testing for 16.04.1?
[13:21] <santa_> I will do at the same time a test against tritemio
[13:22] <acheronuk> ok
[13:24] <clivejo> is there a certain directory structure?
[13:24] <santa_> yes
[13:24] <santa_> before anything lets clone this branch https://code.launchpad.net/~panfaust/+git/kubuntu-automation/+ref/work
[13:24] <clivejo> can you guide us through from beginning
[13:24] <santa_> it has the recently added support for qt
[13:25] <santa_> yes, just clone that branch and add it to the PATH
[13:26] <santa_> so we have something like
[13:26] <santa_> $ which git-clone-all
[13:26] <santa_> /home/santa/kubuntu-automation/git-clone-all
[13:26] <santa_> this way we won't have to type the full paths of the commands
[13:27] <santa_> let me know when you are done
[13:27] <clivejo> Ive just removed the regular KA and clones yours instead
[13:28] <clivejo> so Im done
[13:28] <acheronuk> ditto. I hope
[13:29] <santa_> ok, before anything, lets download the tarballs
[13:30] <santa_> lets change the version in conf/versions.json of plasma
[13:31] <clivejo> done
[13:31] <clivejo> this also where we can set build deps bumps for Qt, FW etc?
[13:32] <acheronuk> done also I hope
[13:32] <santa_> not yet, lets go step by step
[13:33] <santa_> now lets do the download of tarballs
[13:33] <santa_> $ download-tarballs -r plasma
[13:34] <acheronuk> in a clean workdir?
[13:34] <clivejo> where does it put them?
[13:34] <santa_> the location where the tarballs are downloaded is configured in conf/tarball-locations.json
[13:34] <acheronuk> ah
[13:35] <acheronuk> ~/kde-ftp/... 
[13:35] <clivejo> why is plasma plasma-next 
[13:36] <clivejo> yet frameworks is just frameworks
[13:36] <santa_> we can change that, indeed
[13:37] <santa_> historically I called it plasma-next because it wasn't clear the name of plasma 5
[13:37] <santa_> this scriptery comes from my early siduction times
[13:37] <acheronuk> downloaded anyway
[13:39] <santa_> ok, now lets create a fresh directory for plasma git repos
[13:39] <clivejo> ok, finished too
[13:40] <santa_> something like $ mkdir plasma-test
[13:40] <santa_> $ cd plasma test
[13:40] <acheronuk> anywhere?
[13:41] <clivejo> I put it in my home :/
[13:41] <santa_> acheronuk: wherever you want
[13:41] <santa_> also the name of the directory is irrelevant
[13:41] <acheronuk> I just did the same as clivejo 
[13:41] <santa_> ok
[13:41] <santa_> now $ git-clone-all -r plasma inside the directory
[13:42] <acheronuk> klone wars
[13:42] <clivejo> do you check anywhere for new or removed packages?
[13:43] <santa_> the list of packages is obtained from ftp
[13:43] <santa_> so any new will be there
[13:43] <santa_> but there is no way to find out about missing packages yet
[13:43] <clivejo> what happens if there is a new package, but no git?
[13:43] <santa_> it will fail and will say it in the summary
[13:44] <acheronuk> "All packages were cloned succesfully"
[13:44] <santa_> that's the summary
[13:44] <clivejo> cool
[13:44] <santa_> however whenever you can feel free to test with applications
[13:44] <santa_> in applications kdelibs will fail, so you can see the behaviour
[13:45] <clivejo> due the to naming?
[13:45] <clivejo> kdelibs4support?
[13:45] <santa_> yeah
[13:46] <santa_> we agreed on doing that one manually for now
[13:47] <santa_> once the packages are cloned: $ do-all git checkout kubuntu_yakkety_archive
[13:47] <santa_> so we will get to the branches we want to work on
[13:47] <acheronuk> done
[13:47] <clivejo> santa_: this is one part that messed me about a bit
[13:48] <clivejo> how to you escape " in that do-all script
[13:48] <santa_> ?
[13:48] <yofel> for what?
[13:48] <clivejo> ie if I wanted to do do-all git merge -m "Backporting to Xenial"
[13:49] <santa_> hmm
[13:49] <santa_> do we need to merge something for this release?
[13:49] <clivejo> no, just curious
[13:49] <santa_> if no let's continue, but I will add that to my notes
[13:49] <clivejo> its a problem I hit before
[13:49] <santa_> ok
[13:51] <santa_> note taken
[13:51] <clivejo> sorry, just remembered
[13:51] <santa_> nah, it's good, this way I can re-check the stuff
[13:52] <santa_> ok, so ...
[13:52] <santa_> do we have the clones in the correct branch?
[13:52] <clivejo> I do
[13:53] <santa_> acheronuk ?
[13:53] <acheronuk> seems so
[13:53] <clivejo> klones :P
[13:54] <santa_> ok, now it's time to prepare the build depends bumping
[13:55] <santa_> right now we already have a json for qt in dev-package-name-lists/qt-yakkety.json
[13:55] <clivejo> is the dev-deps a manual or automatic process?
[13:55] <santa_> semi automatic
[13:55] <santa_> we update the json files inside dev-package-name-lists/ with the script dev-package-names-list
[13:55] <clivejo> can i ask the reason why it needs to be distro locked?
[13:56] <santa_> what you mean distro locked?
[13:56] <clivejo> ie why do we need qt-xenial and qt-yakkety
[13:56] <santa_> we maight need different build depends for yakkety and xenial, for instance (I think)
[13:57] <acheronuk> "libenginio1-dev": "1.6.1~"?
[13:57] <clivejo> yofel: is there a case that would be true?
[13:58] <santa_> supose I'm working on a new frameworks and plasma releases for ubuntu unstable
[13:58] <santa_> and at the same time you work on a plasma point release for the last stable
[13:59] <santa_> and that my new plasma needs the new frameworks
[13:59] <acheronuk> is that meant to be 1.6.1?
[13:59] <santa_> I think so
[13:59] <santa_> let me check where that comes from qt
[14:00] <mparillo> Is it time for ISO testers for 16.04.1? http://iso.qa.ubuntu.com/qatracker/milestones/363/builds
[14:02] <santa_> 1.6.1
[14:02] <santa_> wtf
[14:03] <santa_> acheronuk: thanks for spotting it, I will have a look later
[14:03] <santa_> for now we can alter that file manually
[14:03] <clivejo> !info libenginio1-dev
[14:03] <santa_> and put 5.6.1~
[14:03] <santa_> oh, even better
[14:03] <acheronuk> I don't recall it, but it didn't seem right
[14:03] <yofel> clivejo: yes, although the difference is really meant to be "stable" and "dev", where stable is for SRU's
[14:04] <yofel> because in the past we had overlapping release timelines for kde sc
[14:04] <yofel> and we will have that again for plasma LTS
[14:04] <clivejo> so it should be qt-stable and qt-dev?
[14:05] <yofel> yes, but then you need *another* mapping to say what release stable and dev belong to
[14:05] <yofel> so just using the series names was easier
[14:05] <santa_> exactly
[14:05] <clivejo> I see
[14:06] <santa_> note taken about the enginio bizarre thing, for now is harmless, so let's continue?
[14:07] <clivejo> ok
[14:07] <acheronuk> yep
[14:07] <santa_> just as a note, no need to do this
[14:08] <santa_> inside a qt directory you can do git-clone-all -r qt
[14:08] <santa_> and then
[14:08] <santa_> $ dev-package-names-list -d yakkety -r qt
[14:08] <santa_> to get the map
[14:08] <santa_> but we already have the map, so lets skip that one
[14:09] <santa_> at this point, clivejo, what build depends we want to bump in this plasma release
[14:09] <santa_> qt, frameworks and plasma itself?
[14:09] <clivejo> Id like to bump Qt, Frameworks should be already done and then Plasma from 5.7.1 to 5.7.2
[14:10] <clivejo> although lets bump Framewworks too
[14:10] <santa_> should be a no-op but ok
[14:11] <clivejo> I added in some framework buld deps without a version, so this should fix those
[14:11] <clivejo> in theory
[14:11] <clivejo> kwayland recent moved from plasma to frameworks
[14:12] <clivejo> can this script fix those?
[14:12] <santa_> yes
[14:12] <santa_> you can create a frameworks directory
[14:13] <santa_> then git-clone-all
[14:13] <santa_> then do-all git checkout kubuntu_yakkety_archive
[14:13] <santa_> then dev-package-names-list -d yakkety -r plasma
[14:14] <santa_> clivejo: ↑ that should overwrite the map
[14:14] <santa_> take your time if you want to test that
[14:16] <clivejo> not -r frameworks?
[14:17] <santa_> ugh, sorry
[14:17] <santa_> -r frameworks
[14:17] <clivejo> seems to be ok - https://git.launchpad.net/~panfaust/+git/kubuntu-automation/tree/dev-package-name-lists/frameworks-yakkety.json?h=work
[14:17] <clivejo> kwayland-dev is listed as 5.24.0
[14:18] <santa_> ok, so now in plasma we want to bump the plasma itself + fw + qt
[14:18] <santa_> so we can do the map this way
[14:18] <santa_> inside the directory with the plasma clones:
[14:19] <acheronuk> yes
[14:19] <BluesKaj> Hiyas all
[14:20] <clivejo> hi BluesKaj
[14:20] <santa_> $ dev-package-name-list -d yakkety -r plasma -m frameworks qt
[14:20] <clivejo> doesnt run for me
[14:21] <clivejo> write /home/clivejo/kubuntu-automation/dev-package-name-lists/plasma-yakkety.json
[14:21] <santa_> inspect the contents of that file
[14:21] <santa_> doesn't have now the map of plasma itself, frameworks and qt?
[14:22] <clivejo> oh yes
[14:22] <clivejo> its all the build deps together?
[14:23] <santa_> yes, the -m option is meant to merge more stuff in the json file
[14:23] <clivejo> I see
[14:23] <santa_> you can understand the contents of dev-package-name-lists/plasma-yakkety.json as "build dependencies to be bumped for plasma"
[14:24] <BluesKaj> hi clivejo
[14:24] <acheronuk> drat. big lag
[14:29] <santa_> clivejo, acheronuk: do we continue? (y/n)
[14:29] <clivejo> y
[14:31] <santa_> acheronuk: are you ok?
[14:33] <acheronuk> I was getting HUUUUUUGE lag.
[14:34] <acheronuk> and my router than crapped out
[14:34] <clivejo> back with us?
[14:34] <santa_> np
[14:34] <acheronuk> typical when I'm trying to follow this
[14:34] <santa_> muphy's law
[14:34] <acheronuk> seems ok again for now....
[14:35] <acheronuk> but give me 1 min
[14:35] <santa_> k
[14:35] <santa_> tell us when you are back
[14:36] <acheronuk> ok :)
[14:37] <acheronuk> plasma-yakkety.json written
[14:38] <santa_> ok, lets see now a few scripts meant to be executed inside a git clone for a single package
[14:39] <santa_> lets cd to plasma-destop/git (inside the dir with all the plasma clones)
[14:39] <santa_> $ bump-build-dep-versions -d yakkety -r plasma
[14:39] <santa_> and $ git diff to see what it does
[14:40] <santa_> as you can see it doesn't alter the changelog but the control file
[14:40] <clivejo> it auto displays a diff
[14:40] <santa_> ah, maybe
[14:41] <santa_> ok now $ git checkout debian/control to revert the changes
[14:41] <santa_> that script is useful to test the bumping build dependency function
[14:41] <clivejo> yes that appears to be bumping Qt and Plasma packages
[14:42] <santa_> and not frameworks because it was already bumped
[14:42] <clivejo> yup
[14:42] <acheronuk> ame result here
[14:42] <acheronuk> *same
[14:42] <santa_> also the script is idempotent, mening you can execute it several times and the result is the same
[14:42] <santa_> * meaning
[14:45] <santa_> ok, now lets try this
[14:45] <santa_> $ new-release -d yakkety
[14:46] <santa_> you should get something like this
[14:46] <santa_> https://paste.kde.org/pnasmvdkz
[14:46] <acheronuk> in what dir? if any?
[14:46] <santa_> plasma-desktop/git
[14:47] <santa_> like the other one is meant to be executed into the git clone
[14:47] <santa_> this way you can do it for all packages with $ do-all new-release -d yakkety
[14:47] <santa_> same for the previous script
[14:48] <clivejo> I get one line output
[14:48] <clivejo> /home/clivejo/kubuntu-automation/lib/../.cache/kubuntu-automation/
[14:48] <acheronuk> oh. nice :)
[14:49] <santa_> clivejo: are you in the right directory?
[14:49] <clivejo> yes
[14:49] <clivejo> I dont like that git diff
[14:49] <acheronuk> http://paste.ubuntu.com/20184626/
[14:49] <mparillo> For 16.04.1 (http://iso.qa.ubuntu.com/qatracker/milestones/363/builds), on the live ISO, the favorites are still empty in the Application Launcher.
[14:50] <clivejo> surely it shouldnt be making a completely new entry for 5.7.2?
[14:50] <clivejo> as 5.7.1 is UNRELEASED
[14:50] <acheronuk> if it's UNRELEASED?
[14:50] <acheronuk> snap
[14:51] <santa_> we can change that indeed
[14:51] <santa_> let me continue with other script more and I will fix new-release
[14:51] <clivejo> also, we have been including the version recently too
[14:52] <clivejo> ie   * New upstream release (5.7.2)
[14:52] <santa_> allrigh, I know
[14:52] <clivejo> just helps changelog readability 
[14:53] <santa_> ok, the other script: $ add-ppa-suffix -d yakkety
[14:53] <santa_> and this should alter the first line of changelog like this:
[14:54] <santa_> plasma-desktop (4:5.7.2-0ubuntu1~ubuntu16.10~ppa1) yakkety; urgency=low
[14:54] <clivejo> but we shouldnt push that to git?
[14:55] <santa_> yeah thats why new-release and add-ppa-suffix are different scripts
[14:55] <santa_> so you could commit/push to git in between
[14:56] <santa_> clivejo: does the behaviour od add-ppa-suffix look right to you?
[14:57] <clivejo> not sure in this context
[14:57] <santa_> to make an upload to staging, is the version correct?
[14:57] <clivejo> currently we use git-buildpackage-ppa which does this for us
[14:58] <clivejo> santa_: have you used the old tooling?
[14:59] <santa_> clivejo: nope as I never did uploads to anything official
[15:00] <clivejo> well that script when run in the git directory creates a PPA build
[15:01] <clivejo> creates a folder called build-area
[15:01] <clivejo> finds the Source tarball version on depot or downloads 
[15:02] <clivejo> and creates the source ready for upload to LP
[15:02] <acheronuk> I'm going to have to go for about 2hrs in a min
[15:04] <acheronuk> more lag...
[15:04] <santa_> np we will resume later
[15:04] <santa_> in the meantime I will discuss with clivejo what we have so far and fix things
[15:05] <acheronuk> I'll check the logs and be back on later
[15:10] <santa_> clivejo: I'm looking git-buildpackage-ppa
[15:11] <clivejo> it just grabs SC and using the current git creates an upload for us to dput to LP
[15:15] <clivejo> git-buildpackage-ppa -d xenial -y 16.04 will create a backport
[15:15] <santa_> https://paste.kde.org/pbguydzli
[15:15] <santa_> also how does it deal with unreleased versions
[15:15] <santa_> i.e. uscan isn't good for doing this, is it?
[15:16] <yofel> it doesn't
[15:16] <santa_> my stuff does
[15:16] <yofel> easiest workaround is to go to build-area, run pull-ppa-source to get the tarball, go back and try again
[15:17] <yofel> does your stuff work with single packages?
[15:17] <santa_> yes
[15:17] <yofel> ok, then git-buildpackage-ppa should eventually use that
[15:18] <santa_> maybe we should drop it, but I'm not sure
[15:18] <santa_> in any case see my pastebin there, I can't get it working
[15:18] <yofel> how do you build ppa packages?
[15:19] <yofel> gbp:info: Moving '/home/santa/plasma/plasma-desktop/build-area/plasma-desktop-tmp' to '/home/santa/plasma/plasma-desktop/build-area/plasma-desktop-5.7.1'
[15:19] <yofel> dch warning: your current directory has been renamed to:
[15:19] <yofel> ../plasma-desktop-5.7.2
[15:19] <santa_> inside a git repository you can do
[15:19] <yofel> wait what?
[15:19] <yofel> why would it change the upstream version?!?
[15:20] <santa_> git-buildpackage bizarreness I guess?
[15:20] <yofel> give me a sec
[15:21] <santa_> I don't have the changes commited or added with git add if that matters
[15:21] <yofel> depends on what those changes are
[15:21] <yofel> but gbp should just throw an error with uncommitted changes without trying to build anything
[15:23] <yofel> oh yeah, not committing actually causes that
[15:23] <yofel> santa_: so yeah, commit first, then it'll work
[15:24] <yofel> wait, why is --git-ignore-new part of the options o.O
[15:24] <yofel> ah, for local tests I think
[15:27] <santa_> yofel: it worked after commiting
[15:38] <santa_> yofel: how do I skip the signature of packages?
[15:39] <santa_> apparently you can pass options to debuild but I don't understand well how
[15:39] <yofel> santa_: with git-buildpackage-ppa, you don't. Otherwise it's appending -us -uc to the options
[15:40] <santa_> parser.add_argument("options", nargs="*", help="debuild options")
[15:40] <santa_> yofel: ↑ I have the impresion this line doesn't work as expected
[15:41] <yofel> possibly, I never tried using that
[15:43] <santa_> note taken, I might want to look further later
[15:43] <jimarvan> brb
[15:45] <ahoneybun> jimarvan: join #kubuntu-podcast
[15:46] <santa_> yofel: maybe it should skip lintian, shouldn't it?
[15:46] <yofel> why?
[15:47] <santa_> because there is already the status pages and such and saves time if you want to build a bunch of packages
[15:47] <yofel> it's used for non-tooling ppa uploads as well - without status pages
[15:47] <yofel> an option to turn that off during tooling run sounds sensible though
[15:48] <santa_> ok, note taken to look further later
[16:43] <santa_> yofel: I have been thinking about what we have right now and I would like to discuss a bit more about the upcoming fixes for the automation
[16:43] <santa_> the idea I have right now in mind for the new tooling is:
[16:43] <santa_> 1. using "new-release" (with fixes) to create the new upstream changes
[16:44] <santa_> 2. using your "gbp-buildpackage-ppa" (with fixed) to build the source package
[16:45] <santa_> 3. using my "uploadsource" to upload the produced source packages
[16:45] <santa_> and they can be used wither with a single source package or all of a set via do-all
[16:45] <santa_> yofel: does sound right so far?
[17:18] <soee> :D
[17:21] <maxyz> santa_: ping, Are you still working with siduction? Ben Cooksley is requiring a reply about the accounts access.
[17:22] <soee> got my Plasma running fine on this: https://mediamarkt.pl/komputery-i-tablety/monitor-lg-29uc97c-b :D
[17:40] <soee_> with this screen i feel like using mac 
[17:42] <soee_> ahoneybun: ping
 Pong
[17:45] <soee_> "Overlord Is Being Released For Linux Tomorrow"
[17:46] <soee_> gonna try this one ? :D
[18:02] <yofel> santa_: sounds about right in general. tarball-dwonload and new-release should eventually get a wrapper that imitates staging-upload IMO (humans forget stuff), but for that archive sanity checking is still missing I think.
[18:03] <yofel> santa_: not that there is also git-buildpackage-real which is for archive uploads
[18:04] <santa_> maxyz: replied
[18:04] <yofel> *note
[18:04] <yofel> otoh, that's just a 2 line shell script..
[18:04] <santa_> yofel: ack, I'm fixing "new-release"
[18:08] <jimarvan> helloz :D
[18:09] <ahoneybun> I've never played overlord soee_
[18:10] <ahoneybun> but I'll look at it
[18:12] <santa_> yofel: fixed new-release, now it does this with the changelog https://paste.kde.org/pm101t6pk
[18:13] <jimarvan> overlord????
[18:13] <soee_> aye
[18:13] <jimarvan> where have I heard that before???
[18:14] <jimarvan> hmm let me look at it
[18:14] <jimarvan> I was checking some free linux games on Steam
[18:14] <yofel> santa_: any reason why you're not simply using dch?
[18:14] <jimarvan> a Half-life expansion and a card game
[18:14] <jimarvan> awesome really
[18:15] <jimarvan> soee_: OMG OMG :D is that game ported to Linux?
[18:15] <santa_> yofel: you mean dch instead of new-release?
[18:15] <soee_> jimarvan: release tomorrow 
[18:15] <yofel> santa_: or that, yeah
[18:15] <soee_> jimarvan: http://www.phoronix.com/scan.php?page=news_item&px=Overlord-Tomorrow-Linux
[18:16] <santa_> yofel: because we need to find out the latest upstream version, so even if we use dch we would have to wrap it around a script
[18:16] <jimarvan> my god this is my dream 20 years now, awesome games in Linux :)
[18:16] <santa_> that would be what new-release does
[18:17] <yofel> santa_: which was my original question, if there is one script that gives you the current upstream version, then new-release could be a 2 (or even 1) line shell script
[18:17] <yofel> yes, but if we implement a custom dch, changing options becomes more work, and we have yet more code to maintain
[18:18] <santa_> yofel: but new-release also bumps the build dependencies in control
[18:18] <yofel> not having scripts do multiple things was the original idea of redoing the tooling..
[18:19] <yofel> the wrapper that uses new-release should bump the dependencies, not new-release
[18:19] <yofel> i.e. what eventually replaces staging-upload
[18:20] <yofel> I'm fine with new-release being a shortcut wrapper itself, but I'm not a fan of having multiple layered wrapping
[18:21] <yofel> if new-release is a wrapper, then the new staging-upload is not supposed to use it
[18:21] <santa_> and it doesn't
[18:21] <yofel> so it would use dch?
[18:21] <santa_> no
[18:21] <santa_> nothing
[18:22] <yofel> how would it then add changelog entries?
[18:23] <santa_> oh well
[18:23] <santa_> you want a wrapper doing so many things
[18:24] <santa_> let's dig into it
[18:24] <yofel> I'm fine with doing the responsibility splitting in steps, so for now this would be ok I guess. But if new-release will eventually get split up itself, then the whole changelog modification code feels like throw-away code as it duplicates dch...
[18:26] <yofel> santa_: I want a wrapper that does everything eventually, so that whoever runs it doesn't forget a step as we have many of those.
[18:26] <yofel> but those steps should themselves be independent so you could do them by hand if you need to
[18:26] <yofel> staging-upload does the first, your tooling does the latter
[18:27] <yofel> now we just need to figure out a good way to do both ;)
[18:27] <santa_> yofel: thats easy, we can just convert some scripts to libraries
[18:27] <yofel> (and I'm not much of a fan of code duplication, which is why I didn't understand why you partially re-implemented dch)
[18:28] <yofel> either that or the wrapper will be a shell script
[18:33] <santa_> yofel: 1. you have to find out the latest version. that's done checking the ftp/cache with getFtpVersionMap
[18:33] <santa_> yofel: 2. you have to alter the changelog
[18:33] <clivejo> anyone able to test installation of Plasma 5.7.1 on Xenial?
[18:34] <santa_> and you can do 2. either a) calling a dch process b) using python-debian
[18:34] <santa_> yofel: and since I was already doing a python script, I just used python-debian
[18:35] <yofel> well, keep that for now then as you already did the work
[18:37] <santa_> right now I'm using both the approach a) and b) but we can change the thing to use only a)
[18:38] <acheronuk> clivejo: http://paste.ubuntu.com/20209511/
[18:39] <santa_> yofel: also note about dch that it's behaviour may change very much depending on the configuration, so that should be done with time and care
[18:39] <santa_> for now we can go, as you said with the dubious current implementation
[18:40] <yofel> hm, that's a point, true
[18:42] <santa_> yofel: tell me more about your other issues with the "user interface", you also wanted a wrapper
[18:43] <santa_> do you want a staging-upload clone?
[18:43] <santa_> or something similar?
[18:50] <acheronuk> clivejo: I note neon rebuild python-pyqt5, so that isn't removed wit their plasma
[18:50] <clivejo> I just uploaded YY rebuild to staging-ppa
[18:50] <clivejo> to see if that works
[18:50] <acheronuk> clivejo yofel wpuld we need to follow suit?
[18:50] <acheronuk> ah, ok
[18:51] <clivejo> wonder does discover need a no change rebuild
[18:57] <clivejo> is it a no change rebuild in Neon?
[19:01] <acheronuk> plasma-discover stays at our ppa version 5.6.5 here if I enable neon on a xenial box
[19:09] <acheronuk> this is what an upgrade to Neon dev edition unstable would do to this box as it stands now http://paste.ubuntu.com/20213328/
[19:11] <acheronuk> so a few things Neon have done their own builds of there, besides just plasma/FW etc
[19:18] <clivejo> kgamma5: git unclean or out of sync
[19:18] <clivejo> khotkeys: git unclean or out of sync
[19:18] <clivejo> kinfocenter: git unclean or out of sync
[19:18] <clivejo> kmenuedit: git unclean or out of sync
[19:18] <clivejo> sddm-kcm: git unclean or out of sync
[19:19] <clivejo> how are they out of sync in like a week
[19:54] <clivejo> yofel: ping
[19:56]  * acheronuk is about to give up on the internet for the day at this rate
[19:56] <clivejo> whats going on Rik?
[19:56] <acheronuk> won't work for more than 5 mins at a time without dropping for a while
[19:57] <clivejo> how long has that been going on?
[19:57] <clivejo> I read somewhere that BT is having issue?
[19:57] <acheronuk> http://www.bbc.co.uk/news/technology-36844712
[19:58] <acheronuk> I'm not on BT, but I imagine it will effect other providers
[20:01] <acheronuk> or it's just damn annoying coincidence
[20:01] <clivejo> problem is its probably provided via BT wholesale
[20:03] <acheronuk> This is Sky, which is easyNet, but most are linked and do "peer sharing" of resources, so yes 
[20:04] <clivejo> if you have to pay a "line rental" its more than likely a resold BT package!
[20:04] <acheronuk> Plus loads of people on BT will probably ask to use their friends/neighbours/relatives SkyBB  
[20:05] <acheronuk> BT will be under there somewhere at some level
[20:05] <clivejo> BT need a good kick up the backside
[20:05] <acheronuk> BT need to enable my cabinet for fibre... grrrr
[20:06] <clivejo> UK needs a BTexit
[20:46] <acheronuk> Looks like Mirv has started builds again into https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-024/+packages for YY Qt 5.6
[20:52] <clivejo> any 5.7 yet?
[20:52] <acheronuk> yofel: for YY KCI and plasma staging, would it make more sense to use those packages ^^
[20:53] <acheronuk> as they would more closely match what will eventually be in the YY archive?
[20:54] <clivejo> shouldnt be much difference to yourse
[20:54] <acheronuk> clivejo: no, just 5.6.1 as far as I can see
[20:55] <yofel> yes, we should use those once they're ready
[20:55] <yofel> and 5.6 is all that's planned for yakkety, no 5.7
[20:55] <acheronuk> clivejo: shouldn't much diff in theory, but I would rather avoid any last minute nasty surprises with YY, as sounds like timing will be close to get it in
[20:56] <yofel> we'll probably need an FFE anyway, unless qt makes it into proposed ~2 weeks before FF
[20:57] <yofel> early FFE's are non-issues though
[20:57] <acheronuk> yofel: that's a slight relief :)
[21:03] <santa_> yofel: I have changed git-buildpackage-ppa to interact nicely with the tarballs downloaded by "download-tarballs"
[21:03] <santa_> https://git.launchpad.net/~panfaust/+git/kubuntu-automation/commit/?id=27a2f2512b315da3da938380f54a7c06589a353b
[21:04] <santa_> if it doesn't find it, it downloads with uscan
[21:04] <santa_> I could change it to download it from depot if it doesn't find it
[21:04] <santa_> but seems to me good enough for now
[21:06] <yofel> that's already better, thanks
[21:06] <santa_> now I just need to do a "last" thing
[21:06] <santa_> change gpb-ppa to move the resulting stuff from ../build-area to .../upload
[21:07] <santa_> so uploadsource would upload what's in ../upload
[21:07] <yofel> could you symlink it instead?
[21:07] <santa_> maybe
[21:08]  * santa_ checks dcmd man page
[21:08] <yofel> or hardlink/copy, whatever works
[21:08] <santa_> yofel: hmm what about just moving it?
[21:09] <yofel> I would like to be able to expect the files to actually be in build-area where they're supposed to be
[21:10] <yofel> ah, staging-upload does dcmd cp
[21:10] <santa_> oh, btw
[21:10] <santa_> git-buildpackage-ppa -- -us -uc
[21:10] <santa_> ↑ to build unsigned
[21:11] <yofel> ah right, gbp needed the --
[21:11] <ScottK> yofel: You might want to consider just syncing Kf5.  It doesn't look like you all are having time to deal with and and maxyz is doing a good job of keeping it up to date in Debian.
[21:12] <yofel> clivejo: your opinion ^
[21:13] <clivejo> sorry, wasnt following
[21:13] <yofel> clivejo: just what scott said
[21:16] <clivejo> dont understand the question
[21:16] <clivejo> can LP just auto sync with debian?
[21:16] <yofel> clivejo: drop packaging frameworks or not. You're doing most of that, so it's up to you
[21:17] <yofel> clivejo: it does that all the time for non-ubuntu-changed packages
[21:17] <clivejo> or we do a merge via our tooling every release?
[21:17] <yofel> the idea is to *reduce* our workload, not increase it :P
[21:18] <clivejo> true
[21:18] <clivejo> at the moment Im happy enough
[21:18] <yofel> we would probably need to keep 2 or 3 packages merged by hand
[21:18] <yofel> but we could just skip the rest
[21:18] <clivejo> actually doing it by hand help me learn
[21:19] <clivejo> but having Debian and KDE Neon archives to look at when I get stuck is very useful
[21:19] <clivejo> problem is that if you automate things, thats great in the short term
[21:19] <yofel> clivejo: wouldn't you have enough to do just with plasma and apps?
[21:20] <clivejo> but long term the natural cycle of volenteers will mean we lose the skills to actually do to the packaging
[21:21] <clivejo> is it something easy to setup (syncing directly with debian)
[21:21] <yofel> it is something that doesn't require setup
[21:22] <yofel> the ubuntu archive auto-syncs packages without "ubuntu" in the version
[21:22] <yofel> all I would need to do is a one-time force-sync for every package
[21:22] <yofel> the "problem" would be to figure out if we need any migration breaks/replaces for some packages
[21:22] <yofel> and one or two are not syncable
[21:23] <yofel> maybe
[21:25] <ScottK> If it were me, I'd just sync all of Kf5 and see if anything broke.
[21:25] <clivejo> can we hold off for a while?
[21:25] <ScottK> It'd be a lot less effort to fix any fallout than to manually review it all.
[21:26] <jimarvan> does the frameworks packaging break that much?
[21:26] <jimarvan> oh i see for the non-ubuntu-changed packages
[21:27] <yofel> probably not, but I'm not much of a fan of intentionally shipping potentially broken packages :/
[21:27] <jimarvan> ye :/
[21:27] <yofel> we had decided to do this at the beginning of yakkety, but then clive went ahead and just continued to update fw
[21:27] <jimarvan> hmm
[21:28] <jimarvan> I wonder how serious bug fixes are the kde frameworks
[21:28] <clivejo> well if that was the plan go for it
[21:28] <jimarvan> *...updates
[21:29] <yofel> well, there are no bugfix updates, so you just use the latest and greatest and hope for the best
[21:29] <jimarvan> ye :D
[21:29] <yofel> clivejo: uh, didn't we talk about that for sever weeks?!?
[21:29] <yofel> *several
[21:29] <jimarvan> hmm
[21:29] <clivejo> I cant remember !
[21:30] <jimarvan> clivejo, yofel if you have a team of 3-4 testers
[21:30] <jimarvan> so they check on a virtualbox if the frameworks work (generally checking bug fix list)
[21:30] <jimarvan> would that help?
[21:30] <valorie> I remember -- sgclark and yofel were working on tooling, clivejo started with fw
[21:30] <clivejo> but you are RM and I know you think outside the box
[21:30] <sgclark> ?
[21:31] <yofel> what we haven't figured out is what to do with the CI
[21:31] <valorie> sgclark was working on applications, then got two jobs!
[21:31] <sgclark> busy yeah
[21:31] <sgclark> stable ci is busted because of no namespaces. have not had time to sort that
[21:32] <yofel> sgclark: stable is gone for the time being (because busted), same are i386 builds
[21:32] <sgclark> cool
[21:32] <yofel> now it ~kind of actually works
[21:32] <sgclark> awesome
[21:32] <yofel> sgclark: how does one add new packages
[21:32] <sgclark> yofel: let me look, been awhile
[21:33] <yofel> I haven't been able to figure that out
[21:33] <yofel> jimarvan: well, not bad an idea. We could probably put the debian builds in a PPA and see how it works out
[21:33] <clivejo> yofel: Ill go with whatever you think is best
[21:34] <yofel> let me sleep over this. I'm all for syncing in the archive, but for the CI I haven't made up my mind
[21:34] <clivejo> KCI could pull packaging direct from Alioth?
[21:34] <yofel> hm, true that
[21:34] <valorie> I'm setting up a new virt to test 16.04.1  right now
[21:34] <yofel> clivejo: sounds like a plan I guess
[21:34] <yofel> we wouldn't be able to fix anything though
[21:35] <jimarvan> :D
[21:35] <yofel> or we hack the merger to merge debian before building
[21:35] <yofel> which on second thought sounds like a nightmare
[21:35] <clivejo> LOL
[21:35] <jimarvan> you make the build, I try to break it on tests :P
[21:36]  * mamarley kicks LP.
[21:36] <sgclark> yofel: pangea-tooling/ci-tooling/data/projects then you need to run the update-projects.rb
[21:36] <yofel> for that it actually has to build first :P
[21:36] <jimarvan> true :P
[21:36] <yofel> oh, so it was update-projects
[21:36] <yofel> sgclark: ok thanks, I'll try to get that working
[21:36] <sgclark> np
[21:37] <acheronuk> I'll work with whatever people think is best also
[21:38] <jimarvan> going to have a nap, was such a tiring day today
[21:38] <yofel> lets for now just not touch frameworks when doing something. We have plasma to finish and the apps beta gets out this week
[21:39] <jimarvan> good night everyone, see you tomorrow
[21:39] <yofel> nini
[21:39] <jimarvan> ;)
[21:40] <acheronuk> 'not touch' as in not even fixes in CI?
[21:40] <yofel> nah, you can do that
[21:41] <acheronuk> good night jimarvan :)
[21:41] <clivejo> I wish KCI would stop this *** Cannot allocate memory.  Stop. rubbish
[21:42] <acheronuk> yofel: ok. good. 
[21:43] <acheronuk> while the workflow goalposts keep moving, and least I can practice packaging with that!
[21:48] <clivejo> moving goal posts help you work better :P
[21:52] <valorie> darn it, my internet connection crapped out right when the crucial part of the conversation happened
[21:52] <acheronuk> I'm sure they will in the long run
[21:52] <valorie> and irclogs.ubuntu.com isn't up to date quite
[21:53] <valorie> can someone paste to me that past 10 mins or so?
[21:54] <acheronuk> valorie: http://paste.ubuntu.com/20233603/
[21:54] <valorie> from :30 - 34, actually
[21:55] <acheronuk> http://paste.ubuntu.com/20233774/
[21:56] <valorie> thank you acheronuk
[21:57] <valorie> ha, I said a couple more lines but they got lost
[21:57] <valorie> thanks, comcast.....
[21:58] <acheronuk> My BB in the UK has been dropping all day. Only just got stable the last hr or so
[21:58] <valorie> so I saw
[21:58] <valorie> my sympathy!
[21:59] <acheronuk> It's actually normally not too bad for ADSL
[22:01] <acheronuk> glad I got that KDE BNC, or I would have been in and out of this channel every 5 mins!
[22:02] <clivejo> its handy!
 Please review http://kubuntu.org/news/kubuntu-podcast-14/
[22:32] <valorie> ovidiuflorin: made a couple of little edits, mostly punctuation. Thanks for publishing!
[22:41] <santa_> yofel: I think I'm done today with KA, now git-buildpackage-ppa is suposed to be compatible with the new tooling
[22:41] <santa_> I'll retest the workflow tomorror
[22:41] <santa_> * tomorrow
[22:42] <valorie> \o/
[22:59]  * clivejo kicks the *beep* out of LP
[23:04] <santa_> clivejo: tomorrow whenever you are up to upload plasma to staging just give me a ping please
[23:04] <clivejo> santa_: Ive done it
[23:04] <clivejo> its in staging-plasma at the moment
[23:05] <santa_> clivejo: with the old tooling I guess
[23:05] <clivejo> yeah
[23:05] <santa_> have you bumped the qt versions?
[23:05] <clivejo> yup
[23:06] <santa_> so yo used the old tooling but my "work" branch?
[23:07] <clivejo> I used the merged plasma-yakkety.json file your tooling generated
[23:07] <clivejo> copied it into our old tolling
[23:07] <clivejo> tooling
[23:09] <santa_> clivejo: ok, willing to retry the new tooling for the next release? thanks for your patience by the way
[23:10] <clivejo> just want to get eyes on plasma 5.7
[23:15] <valorie> yay, the desktop folder is the right size in the installer
[23:22] <valorie> and install seems to be going well
[23:29] <clivejo> valorie: you still got a YY install?
[23:32] <valorie> gotta do it again
[23:32] <valorie> it says not enough disk space
[23:36] <valorie> I forgot that it wants all I can give it
[23:36] <valorie> every time
[23:42] <valorie> we still have a slideshow -- I thought it was removed because of problems?
[23:42] <valorie> or is that just in YY
[23:43] <valorie> no problems with this install, yet
[23:45] <clivejo> just YY