[07:04] Morning [07:04] Martin for Ubuntu MATE here. Just wondering how the Kubuntu 16.04.1 image testing is going? [07:08] I haven't had a chance myself. Yesterday the isotracker links to the images were even broken [07:09] ah. fixed this morning. that helps! === Blizzzek is now known as Blizzz === mgraesslin is now known as mgraesslin_ === mgraesslin_ is now known as mgraesslin [08:40] Good morning peeps [08:49] jimarvan: good morning [08:59] moin [09:02] hey yofel [09:02] all alright? [09:29] jimarvan: somwhat [09:29] I could use less heat :P [09:43] hehe [09:49] santa_: you want to reply to ben's email about packager access to depot, [09:49] "Just as a final reminder, i've yet to see responses from: [09:49] - Siduction [09:49] The accounts for the above will be closed based on the lack ofresponse in 2 days time." [09:52] yofel: I did, did you got the mail CC'ed to kubuntu-devel? [09:52] santa_: no, what mail? (maybe it's in the moderation queue?) [09:53] yofel: https://lists.ubuntu.com/archives/kubuntu-devel/2016-July/010545.html [09:53] maybe your filters sent it to other folder [09:53] ah, possibly [09:55] santa_: key added [09:55] user is ftpubuntu [09:57] yofel: ack, where did you get my key? I have several [09:57] santa_: launchpad [10:04] yofel: nice, thank you, just reconfigured ssh, tested and works [10:15] 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] http://gpul.grupos.udc.es/tritemio_buildstatus_ubuntu-exp3/ubuntu-exp3_status_kf5.html [10:15] http://gpul.grupos.udc.es/tritemio_buildstatus_ubuntu-exp3/ubuntu-exp3_status_plasma.html [10:16] everything built fine i.e. no hanging builds because of an incorrect versioned build depend [10:16] testing also with applications as we speak [10:27] Can someone look at plasma 5.7.1 staging please? [10:27] Figure out why breeze won't build on Xx [10:48] Clifford: acheronuk figured that out (see #kde-neon), needs a fix for qtchooser [10:49] yofel: clivejo Which 30s ago I uploaded [10:52] hopefully that will fix it, or at least get it a stage closer anyway [10:53] what's the problem with qtchooser? [10:55] santa_: needed http://packaging.neon.kde.org/cgit/qt/qtchooser.git/commit/?h=Neon/release&id=b8d8e0eba28299b260f8ba887b017a447a5aecd0 [10:55] if the backport was going to work for xenial [10:59] acheronuk: ah, ok, nothing to worry for my current tests [11:42] Ah its a Qt issue [11:43] yes, and breeze just built :) [11:47] Acheronuk use the retry script to poke the rest on [11:48] I have no idea how or where that is. lol [11:49] Kubuntu automation [11:50] Should be an example in readme [11:50] Sorry I'm not at computer at the moment [11:51] while true; do ./kubuntu-retry-builds -r plasma --ppa=kubuntu-ppa --ppaname=staging-plasma --force; sleep 1200; done [11:51] that? [11:52] o/ [11:53] * soee is going to buy https://www.amazon.co.uk/LG-29UC97C-Ultrawide-2560x1080-Speakers/dp/B010PVTFJK [11:54] nice [11:57] Yes. But drop the while loop [11:57] so just ./kubuntu-retry-builds -r plasma --ppa=kubuntu-ppa --ppaname=staging-plasma --force [11:58] Yup [11:58] gotcha [11:58] 20 mins isn't enough time at the moment [11:58] 20 mins? [11:59] oh, right [11:59] That while loop runs the script every 20 mins [11:59] yes, sorry. just realised that obviousness after I typed [12:02] Could not find package filepackage-name-lists/plasma-wily for package [12:08] -d xenial [12:08] clivejo: -s option to specify xenial? [12:08] Or update the script to default to xenial :) [12:10] I think that is running. I will update it later, as that seems an obvious thing to set now [12:45] Can you keep poking it after plasma-intregration [12:45] Publishes [12:48] yes, just have done [13:00] acheronuk: what was wrong with Qt chooser? [13:01] ah I see [13:02] can you copy the fixed package to KCI too please? [13:04] done. [13:05] acheronuk: get anywhere with asking for a KDE bouncer? [13:05] clivejo: I'm on it now [13:05] ah nice [13:06] ugly hostname cloak, but not really fussed on that [13:07] cant you get a community cloak? [13:09] probably. I may ask... [13:16] acheronuk: fancy staging plasma 5.7.2? [13:17] can do. :) [13:17] and testing santa_ 's new scripts to bump qt and plasma deps at the same time [13:19] going to have to talk me through that again [13:19] probably need santa_ on hand as Im not sure of the new script options myself [13:20] acheronuk, clivejo: yeah [13:20] I'm here [13:20] :) [13:20] so ... lets try the new scriptery? [13:20] 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] of course I might need to fix/adjust some things on the fly [13:21] hey guys is anyone testing for 16.04.1? [13:21] I will do at the same time a test against tritemio [13:22] ok [13:24] is there a certain directory structure? [13:24] yes [13:24] before anything lets clone this branch https://code.launchpad.net/~panfaust/+git/kubuntu-automation/+ref/work [13:24] can you guide us through from beginning [13:24] it has the recently added support for qt [13:25] yes, just clone that branch and add it to the PATH [13:26] so we have something like [13:26] $ which git-clone-all [13:26] /home/santa/kubuntu-automation/git-clone-all [13:26] this way we won't have to type the full paths of the commands [13:27] let me know when you are done [13:27] Ive just removed the regular KA and clones yours instead [13:28] so Im done [13:28] ditto. I hope [13:29] ok, before anything, lets download the tarballs [13:30] lets change the version in conf/versions.json of plasma [13:31] done [13:31] this also where we can set build deps bumps for Qt, FW etc? [13:32] done also I hope [13:32] not yet, lets go step by step [13:33] now lets do the download of tarballs [13:33] $ download-tarballs -r plasma [13:34] in a clean workdir? [13:34] where does it put them? [13:34] the location where the tarballs are downloaded is configured in conf/tarball-locations.json [13:34] ah [13:35] ~/kde-ftp/... [13:35] why is plasma plasma-next [13:36] yet frameworks is just frameworks [13:36] we can change that, indeed [13:37] historically I called it plasma-next because it wasn't clear the name of plasma 5 [13:37] this scriptery comes from my early siduction times [13:37] downloaded anyway [13:39] ok, now lets create a fresh directory for plasma git repos [13:39] ok, finished too [13:40] something like $ mkdir plasma-test [13:40] $ cd plasma test [13:40] anywhere? [13:41] I put it in my home :/ [13:41] acheronuk: wherever you want [13:41] also the name of the directory is irrelevant [13:41] I just did the same as clivejo [13:41] ok [13:41] now $ git-clone-all -r plasma inside the directory [13:42] klone wars [13:42] do you check anywhere for new or removed packages? [13:43] the list of packages is obtained from ftp [13:43] so any new will be there [13:43] but there is no way to find out about missing packages yet [13:43] what happens if there is a new package, but no git? [13:43] it will fail and will say it in the summary [13:44] "All packages were cloned succesfully" [13:44] that's the summary [13:44] cool [13:44] however whenever you can feel free to test with applications [13:44] in applications kdelibs will fail, so you can see the behaviour [13:45] due the to naming? [13:45] kdelibs4support? [13:45] yeah [13:46] we agreed on doing that one manually for now [13:47] once the packages are cloned: $ do-all git checkout kubuntu_yakkety_archive [13:47] so we will get to the branches we want to work on [13:47] done [13:47] santa_: this is one part that messed me about a bit [13:48] how to you escape " in that do-all script [13:48] ? [13:48] for what? [13:48] ie if I wanted to do do-all git merge -m "Backporting to Xenial" [13:49] hmm [13:49] do we need to merge something for this release? [13:49] no, just curious [13:49] if no let's continue, but I will add that to my notes [13:49] its a problem I hit before [13:49] ok [13:51] note taken [13:51] sorry, just remembered [13:51] nah, it's good, this way I can re-check the stuff [13:52] ok, so ... [13:52] do we have the clones in the correct branch? [13:52] I do [13:53] acheronuk ? [13:53] seems so [13:53] klones :P [13:54] ok, now it's time to prepare the build depends bumping [13:55] right now we already have a json for qt in dev-package-name-lists/qt-yakkety.json [13:55] is the dev-deps a manual or automatic process? [13:55] semi automatic [13:55] we update the json files inside dev-package-name-lists/ with the script dev-package-names-list [13:55] can i ask the reason why it needs to be distro locked? [13:56] what you mean distro locked? [13:56] ie why do we need qt-xenial and qt-yakkety [13:56] we maight need different build depends for yakkety and xenial, for instance (I think) [13:57] "libenginio1-dev": "1.6.1~"? [13:57] yofel: is there a case that would be true? [13:58] supose I'm working on a new frameworks and plasma releases for ubuntu unstable [13:58] and at the same time you work on a plasma point release for the last stable [13:59] and that my new plasma needs the new frameworks [13:59] is that meant to be 1.6.1? [13:59] I think so [13:59] let me check where that comes from qt [14:00] Is it time for ISO testers for 16.04.1? http://iso.qa.ubuntu.com/qatracker/milestones/363/builds [14:02] 1.6.1 [14:02] wtf [14:03] acheronuk: thanks for spotting it, I will have a look later [14:03] for now we can alter that file manually [14:03] !info libenginio1-dev [14:03] Package libenginio1-dev does not exist in yakkety [14:03] and put 5.6.1~ [14:03] oh, even better [14:03] I don't recall it, but it didn't seem right [14:03] clivejo: yes, although the difference is really meant to be "stable" and "dev", where stable is for SRU's [14:04] because in the past we had overlapping release timelines for kde sc [14:04] and we will have that again for plasma LTS [14:04] so it should be qt-stable and qt-dev? [14:05] yes, but then you need *another* mapping to say what release stable and dev belong to [14:05] so just using the series names was easier [14:05] exactly [14:05] I see [14:06] note taken about the enginio bizarre thing, for now is harmless, so let's continue? [14:07] ok [14:07] yep [14:07] just as a note, no need to do this [14:08] inside a qt directory you can do git-clone-all -r qt [14:08] and then [14:08] $ dev-package-names-list -d yakkety -r qt [14:08] to get the map [14:08] but we already have the map, so lets skip that one [14:09] at this point, clivejo, what build depends we want to bump in this plasma release [14:09] qt, frameworks and plasma itself? [14:09] Id like to bump Qt, Frameworks should be already done and then Plasma from 5.7.1 to 5.7.2 [14:10] although lets bump Framewworks too [14:10] should be a no-op but ok [14:11] I added in some framework buld deps without a version, so this should fix those [14:11] in theory [14:11] kwayland recent moved from plasma to frameworks [14:12] can this script fix those? [14:12] yes [14:12] you can create a frameworks directory [14:13] then git-clone-all [14:13] then do-all git checkout kubuntu_yakkety_archive [14:13] then dev-package-names-list -d yakkety -r plasma [14:14] clivejo: ↑ that should overwrite the map [14:14] take your time if you want to test that [14:16] not -r frameworks? [14:17] ugh, sorry [14:17] -r frameworks [14:17] seems to be ok - https://git.launchpad.net/~panfaust/+git/kubuntu-automation/tree/dev-package-name-lists/frameworks-yakkety.json?h=work [14:17] kwayland-dev is listed as 5.24.0 [14:18] ok, so now in plasma we want to bump the plasma itself + fw + qt [14:18] so we can do the map this way [14:18] inside the directory with the plasma clones: [14:19] yes [14:19] Hiyas all [14:20] hi BluesKaj [14:20] $ dev-package-name-list -d yakkety -r plasma -m frameworks qt [14:20] doesnt run for me [14:21] write /home/clivejo/kubuntu-automation/dev-package-name-lists/plasma-yakkety.json [14:21] inspect the contents of that file [14:21] doesn't have now the map of plasma itself, frameworks and qt? [14:22] oh yes [14:22] its all the build deps together? [14:23] yes, the -m option is meant to merge more stuff in the json file [14:23] I see [14:23] you can understand the contents of dev-package-name-lists/plasma-yakkety.json as "build dependencies to be bumped for plasma" [14:24] hi clivejo [14:24] drat. big lag [14:29] clivejo, acheronuk: do we continue? (y/n) [14:29] y [14:31] acheronuk: are you ok? [14:33] I was getting HUUUUUUGE lag. [14:34] and my router than crapped out [14:34] back with us? [14:34] np [14:34] typical when I'm trying to follow this [14:34] muphy's law [14:34] seems ok again for now.... [14:35] but give me 1 min [14:35] k [14:35] tell us when you are back [14:36] ok :) [14:37] plasma-yakkety.json written [14:38] ok, lets see now a few scripts meant to be executed inside a git clone for a single package [14:39] lets cd to plasma-destop/git (inside the dir with all the plasma clones) [14:39] $ bump-build-dep-versions -d yakkety -r plasma [14:39] and $ git diff to see what it does [14:40] as you can see it doesn't alter the changelog but the control file [14:40] it auto displays a diff [14:40] ah, maybe [14:41] ok now $ git checkout debian/control to revert the changes [14:41] that script is useful to test the bumping build dependency function [14:41] yes that appears to be bumping Qt and Plasma packages [14:42] and not frameworks because it was already bumped [14:42] yup [14:42] ame result here [14:42] *same [14:42] also the script is idempotent, mening you can execute it several times and the result is the same [14:42] * meaning [14:45] ok, now lets try this [14:45] $ new-release -d yakkety [14:46] you should get something like this [14:46] https://paste.kde.org/pnasmvdkz [14:46] in what dir? if any? [14:46] plasma-desktop/git [14:47] like the other one is meant to be executed into the git clone [14:47] this way you can do it for all packages with $ do-all new-release -d yakkety [14:47] same for the previous script [14:48] I get one line output [14:48] /home/clivejo/kubuntu-automation/lib/../.cache/kubuntu-automation/ [14:48] oh. nice :) [14:49] clivejo: are you in the right directory? [14:49] yes [14:49] I dont like that git diff [14:49] http://paste.ubuntu.com/20184626/ [14:49] 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] surely it shouldnt be making a completely new entry for 5.7.2? [14:50] as 5.7.1 is UNRELEASED [14:50] if it's UNRELEASED? [14:50] snap [14:51] we can change that indeed [14:51] let me continue with other script more and I will fix new-release [14:51] also, we have been including the version recently too [14:52] ie * New upstream release (5.7.2) [14:52] allrigh, I know [14:52] just helps changelog readability [14:53] ok, the other script: $ add-ppa-suffix -d yakkety [14:53] and this should alter the first line of changelog like this: [14:54] plasma-desktop (4:5.7.2-0ubuntu1~ubuntu16.10~ppa1) yakkety; urgency=low [14:54] but we shouldnt push that to git? [14:55] yeah thats why new-release and add-ppa-suffix are different scripts [14:55] so you could commit/push to git in between [14:56] clivejo: does the behaviour od add-ppa-suffix look right to you? [14:57] not sure in this context [14:57] to make an upload to staging, is the version correct? [14:57] currently we use git-buildpackage-ppa which does this for us [14:58] santa_: have you used the old tooling? [14:59] clivejo: nope as I never did uploads to anything official [15:00] well that script when run in the git directory creates a PPA build [15:01] creates a folder called build-area [15:01] finds the Source tarball version on depot or downloads [15:02] and creates the source ready for upload to LP [15:02] I'm going to have to go for about 2hrs in a min [15:04] more lag... [15:04] np we will resume later [15:04] in the meantime I will discuss with clivejo what we have so far and fix things [15:05] I'll check the logs and be back on later [15:10] clivejo: I'm looking git-buildpackage-ppa [15:11] it just grabs SC and using the current git creates an upload for us to dput to LP [15:15] git-buildpackage-ppa -d xenial -y 16.04 will create a backport [15:15] https://paste.kde.org/pbguydzli [15:15] also how does it deal with unreleased versions [15:15] i.e. uscan isn't good for doing this, is it? [15:16] it doesn't [15:16] my stuff does [15:16] easiest workaround is to go to build-area, run pull-ppa-source to get the tarball, go back and try again [15:17] does your stuff work with single packages? [15:17] yes [15:17] ok, then git-buildpackage-ppa should eventually use that [15:18] maybe we should drop it, but I'm not sure [15:18] in any case see my pastebin there, I can't get it working [15:18] how do you build ppa packages? [15:19] 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] dch warning: your current directory has been renamed to: [15:19] ../plasma-desktop-5.7.2 [15:19] inside a git repository you can do [15:19] wait what? [15:19] why would it change the upstream version?!? [15:20] git-buildpackage bizarreness I guess? [15:20] give me a sec [15:21] I don't have the changes commited or added with git add if that matters [15:21] depends on what those changes are [15:21] but gbp should just throw an error with uncommitted changes without trying to build anything [15:23] oh yeah, not committing actually causes that [15:23] santa_: so yeah, commit first, then it'll work [15:24] wait, why is --git-ignore-new part of the options o.O [15:24] ah, for local tests I think [15:27] yofel: it worked after commiting [15:38] yofel: how do I skip the signature of packages? [15:39] apparently you can pass options to debuild but I don't understand well how [15:39] santa_: with git-buildpackage-ppa, you don't. Otherwise it's appending -us -uc to the options [15:40] parser.add_argument("options", nargs="*", help="debuild options") [15:40] yofel: ↑ I have the impresion this line doesn't work as expected [15:41] possibly, I never tried using that [15:43] note taken, I might want to look further later [15:43] brb [15:45] jimarvan: join #kubuntu-podcast [15:46] yofel: maybe it should skip lintian, shouldn't it? [15:46] why? [15:47] because there is already the status pages and such and saves time if you want to build a bunch of packages [15:47] it's used for non-tooling ppa uploads as well - without status pages [15:47] an option to turn that off during tooling run sounds sensible though [15:48] ok, note taken to look further later [16:43] 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] the idea I have right now in mind for the new tooling is: [16:43]