| flexiondotorg | Morning | 07:04 |
|---|---|---|
| flexiondotorg | Martin for Ubuntu MATE here. Just wondering how the Kubuntu 16.04.1 image testing is going? | 07:04 |
| acheronuk | I haven't had a chance myself. Yesterday the isotracker links to the images were even broken | 07:08 |
| acheronuk | ah. fixed this morning. that helps! | 07:09 |
| === Blizzzek is now known as Blizzz | ||
| === mgraesslin is now known as mgraesslin_ | ||
| === mgraesslin_ is now known as mgraesslin | ||
| jimarvan | Good morning peeps | 08:40 |
| santa_ | jimarvan: good morning | 08:49 |
| yofel | moin | 08:59 |
| jimarvan | hey yofel | 09:02 |
| jimarvan | all alright? | 09:02 |
| yofel | jimarvan: somwhat | 09:29 |
| yofel | I could use less heat :P | 09:29 |
| jimarvan | hehe | 09:43 |
| 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:49 |
| 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:52 |
| 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:53 |
| yofel | santa_: key added | 09:55 |
| yofel | user is ftpubuntu | 09:55 |
| santa_ | yofel: ack, where did you get my key? I have several | 09:57 |
| yofel | santa_: launchpad | 09:57 |
| santa_ | yofel: nice, thank you, just reconfigured ssh, tested and works | 10:04 |
| 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:15 |
| 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 | 10:16 |
| IrcsomeBot | <Clifford> Can someone look at plasma 5.7.1 staging please? | 10:27 |
| IrcsomeBot | <Clifford> Figure out why breeze won't build on Xx | 10:27 |
| yofel | Clifford: acheronuk figured that out (see #kde-neon), needs a fix for qtchooser | 10:48 |
| acheronuk | yofel: clivejo Which 30s ago I uploaded | 10:49 |
| acheronuk | hopefully that will fix it, or at least get it a stage closer anyway | 10:52 |
| santa_ | what's the problem with qtchooser? | 10:53 |
| 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:55 |
| santa_ | acheronuk: ah, ok, nothing to worry for my current tests | 10:59 |
| IrcsomeBot | <Clifford> Ah its a Qt issue | 11:42 |
| acheronuk | yes, and breeze just built :) | 11:43 |
| IrcsomeBot | <Clifford> Acheronuk use the retry script to poke the rest on | 11:47 |
| acheronuk | I have no idea how or where that is. lol | 11:48 |
| IrcsomeBot | <Clifford> Kubuntu automation | 11:49 |
| IrcsomeBot | <Clifford> Should be an example in readme | 11:50 |
| IrcsomeBot | <Clifford> Sorry I'm not at computer at the moment | 11:50 |
| acheronuk | while true; do ./kubuntu-retry-builds -r plasma --ppa=kubuntu-ppa --ppaname=staging-plasma --force; sleep 1200; done | 11:51 |
| acheronuk | that? | 11:51 |
| soee | o/ | 11:52 |
| * soee is going to buy https://www.amazon.co.uk/LG-29UC97C-Ultrawide-2560x1080-Speakers/dp/B010PVTFJK | 11:53 | |
| acheronuk | nice | 11:54 |
| IrcsomeBot | <Clifford> Yes. But drop the while loop | 11:57 |
| acheronuk | so just ./kubuntu-retry-builds -r plasma --ppa=kubuntu-ppa --ppaname=staging-plasma --force | 11:57 |
| IrcsomeBot | <Clifford> Yup | 11:58 |
| acheronuk | gotcha | 11:58 |
| IrcsomeBot | <Clifford> 20 mins isn't enough time at the moment | 11:58 |
| acheronuk | 20 mins? | 11:58 |
| acheronuk | oh, right | 11:59 |
| IrcsomeBot | <Clifford> That while loop runs the script every 20 mins | 11:59 |
| acheronuk | yes, sorry. just realised that obviousness after I typed | 11:59 |
| acheronuk | Could not find package filepackage-name-lists/plasma-wily for package | 12:02 |
| IrcsomeBot | <Clifford> -d xenial | 12:08 |
| acheronuk | clivejo: -s option to specify xenial? | 12:08 |
| IrcsomeBot | <Clifford> Or update the script to default to xenial :) | 12:08 |
| acheronuk | I think that is running. I will update it later, as that seems an obvious thing to set now | 12:10 |
| IrcsomeBot | <Clifford> Can you keep poking it after plasma-intregration | 12:45 |
| IrcsomeBot | <Clifford> Publishes | 12:45 |
| acheronuk | yes, just have done | 12:48 |
| clivejo | acheronuk: what was wrong with Qt chooser? | 13:00 |
| clivejo | ah I see | 13:01 |
| clivejo | can you copy the fixed package to KCI too please? | 13:02 |
| acheronuk | done. | 13:04 |
| 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:05 |
| acheronuk | ugly hostname cloak, but not really fussed on that | 13:06 |
| clivejo | cant you get a community cloak? | 13:07 |
| acheronuk | probably. I may ask... | 13:09 |
| clivejo | acheronuk: fancy staging plasma 5.7.2? | 13:16 |
| acheronuk | can do. :) | 13:17 |
| clivejo | and testing santa_ 's new scripts to bump qt and plasma deps at the same time | 13:17 |
| 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:19 |
| 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:20 |
| * 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:21 |
| acheronuk | ok | 13:22 |
| 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:24 |
| santa_ | yes, just clone that branch and add it to the PATH | 13:25 |
| 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:26 |
| santa_ | let me know when you are done | 13:27 |
| clivejo | Ive just removed the regular KA and clones yours instead | 13:27 |
| clivejo | so Im done | 13:28 |
| acheronuk | ditto. I hope | 13:28 |
| santa_ | ok, before anything, lets download the tarballs | 13:29 |
| santa_ | lets change the version in conf/versions.json of plasma | 13:30 |
| clivejo | done | 13:31 |
| clivejo | this also where we can set build deps bumps for Qt, FW etc? | 13:31 |
| acheronuk | done also I hope | 13:32 |
| santa_ | not yet, lets go step by step | 13:32 |
| santa_ | now lets do the download of tarballs | 13:33 |
| santa_ | $ download-tarballs -r plasma | 13:33 |
| 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:34 |
| acheronuk | ~/kde-ftp/... | 13:35 |
| clivejo | why is plasma plasma-next | 13:35 |
| clivejo | yet frameworks is just frameworks | 13:36 |
| santa_ | we can change that, indeed | 13:36 |
| 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:37 |
| santa_ | ok, now lets create a fresh directory for plasma git repos | 13:39 |
| clivejo | ok, finished too | 13:39 |
| santa_ | something like $ mkdir plasma-test | 13:40 |
| santa_ | $ cd plasma test | 13:40 |
| acheronuk | anywhere? | 13:40 |
| 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:41 |
| acheronuk | klone wars | 13:42 |
| clivejo | do you check anywhere for new or removed packages? | 13:42 |
| 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:43 |
| 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:44 |
| clivejo | due the to naming? | 13:45 |
| clivejo | kdelibs4support? | 13:45 |
| santa_ | yeah | 13:45 |
| santa_ | we agreed on doing that one manually for now | 13:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:51 |
| santa_ | ok, so ... | 13:52 |
| santa_ | do we have the clones in the correct branch? | 13:52 |
| clivejo | I do | 13:52 |
| santa_ | acheronuk ? | 13:53 |
| acheronuk | seems so | 13:53 |
| clivejo | klones :P | 13:53 |
| santa_ | ok, now it's time to prepare the build depends bumping | 13:54 |
| 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:55 |
| 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:56 |
| acheronuk | "libenginio1-dev": "1.6.1~"? | 13:57 |
| clivejo | yofel: is there a case that would be true? | 13:57 |
| 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:58 |
| 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 | 13:59 |
| mparillo | Is it time for ISO testers for 16.04.1? http://iso.qa.ubuntu.com/qatracker/milestones/363/builds | 14:00 |
| santa_ | 1.6.1 | 14:02 |
| santa_ | wtf | 14:02 |
| 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 |
| ubottu | Package libenginio1-dev does not exist in yakkety | 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:03 |
| 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:04 |
| 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:05 |
| santa_ | note taken about the enginio bizarre thing, for now is harmless, so let's continue? | 14:06 |
| clivejo | ok | 14:07 |
| acheronuk | yep | 14:07 |
| santa_ | just as a note, no need to do this | 14:07 |
| 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:08 |
| 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:09 |
| clivejo | although lets bump Framewworks too | 14:10 |
| santa_ | should be a no-op but ok | 14:10 |
| 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:11 |
| clivejo | can this script fix those? | 14:12 |
| santa_ | yes | 14:12 |
| santa_ | you can create a frameworks directory | 14:12 |
| 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:13 |
| santa_ | clivejo: ↑ that should overwrite the map | 14:14 |
| santa_ | take your time if you want to test that | 14:14 |
| clivejo | not -r frameworks? | 14:16 |
| 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:17 |
| 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:18 |
| acheronuk | yes | 14:19 |
| BluesKaj | Hiyas all | 14:19 |
| 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:20 |
| 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:21 |
| clivejo | oh yes | 14:22 |
| clivejo | its all the build deps together? | 14:22 |
| 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:23 |
| BluesKaj | hi clivejo | 14:24 |
| acheronuk | drat. big lag | 14:24 |
| santa_ | clivejo, acheronuk: do we continue? (y/n) | 14:29 |
| clivejo | y | 14:29 |
| santa_ | acheronuk: are you ok? | 14:31 |
| acheronuk | I was getting HUUUUUUGE lag. | 14:33 |
| 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:34 |
| acheronuk | but give me 1 min | 14:35 |
| santa_ | k | 14:35 |
| santa_ | tell us when you are back | 14:35 |
| acheronuk | ok :) | 14:36 |
| acheronuk | plasma-yakkety.json written | 14:37 |
| santa_ | ok, lets see now a few scripts meant to be executed inside a git clone for a single package | 14:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| santa_ | ok, now lets try this | 14:45 |
| santa_ | $ new-release -d yakkety | 14:45 |
| 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:46 |
| 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:47 |
| clivejo | I get one line output | 14:48 |
| clivejo | /home/clivejo/kubuntu-automation/lib/../.cache/kubuntu-automation/ | 14:48 |
| acheronuk | oh. nice :) | 14:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| clivejo | ie * New upstream release (5.7.2) | 14:52 |
| santa_ | allrigh, I know | 14:52 |
| clivejo | just helps changelog readability | 14:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| santa_ | clivejo: does the behaviour od add-ppa-suffix look right to you? | 14:56 |
| 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:57 |
| clivejo | santa_: have you used the old tooling? | 14:58 |
| santa_ | clivejo: nope as I never did uploads to anything official | 14:59 |
| clivejo | well that script when run in the git directory creates a PPA build | 15:00 |
| clivejo | creates a folder called build-area | 15:01 |
| clivejo | finds the Source tarball version on depot or downloads | 15:01 |
| 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:02 |
| 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:04 |
| acheronuk | I'll check the logs and be back on later | 15:05 |
| santa_ | clivejo: I'm looking git-buildpackage-ppa | 15:10 |
| clivejo | it just grabs SC and using the current git creates an upload for us to dput to LP | 15:11 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| santa_ | git-buildpackage bizarreness I guess? | 15:20 |
| yofel | give me a sec | 15:20 |
| 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:21 |
| yofel | oh yeah, not committing actually causes that | 15:23 |
| yofel | santa_: so yeah, commit first, then it'll work | 15:23 |
| yofel | wait, why is --git-ignore-new part of the options o.O | 15:24 |
| yofel | ah, for local tests I think | 15:24 |
| santa_ | yofel: it worked after commiting | 15:27 |
| santa_ | yofel: how do I skip the signature of packages? | 15:38 |
| 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:39 |
| 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:40 |
| yofel | possibly, I never tried using that | 15:41 |
| santa_ | note taken, I might want to look further later | 15:43 |
| jimarvan | brb | 15:43 |
| ahoneybun | jimarvan: join #kubuntu-podcast | 15:45 |
| santa_ | yofel: maybe it should skip lintian, shouldn't it? | 15:46 |
| yofel | why? | 15:46 |
| 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:47 |
| santa_ | ok, note taken to look further later | 15:48 |
| 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:43 |
| santa_ | 2. using your "gbp-buildpackage-ppa" (with fixed) to build the source package | 16:44 |
| 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? | 16:45 |
| soee | :D | 17:18 |
| maxyz | santa_: ping, Are you still working with siduction? Ben Cooksley is requiring a reply about the accounts access. | 17:21 |
| soee | got my Plasma running fine on this: https://mediamarkt.pl/komputery-i-tablety/monitor-lg-29uc97c-b :D | 17:22 |
| soee_ | with this screen i feel like using mac | 17:40 |
| soee_ | ahoneybun: ping | 17:42 |
| IrcsomeBot | <ahoneybun> Pong | 17:45 |
| soee_ | "Overlord Is Being Released For Linux Tomorrow" | 17:45 |
| soee_ | gonna try this one ? :D | 17:46 |
| 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:02 |
| yofel | santa_: not that there is also git-buildpackage-real which is for archive uploads | 18:03 |
| 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:04 |
| jimarvan | helloz :D | 18:08 |
| ahoneybun | I've never played overlord soee_ | 18:09 |
| ahoneybun | but I'll look at it | 18:10 |
| santa_ | yofel: fixed new-release, now it does this with the changelog https://paste.kde.org/pm101t6pk | 18:12 |
| jimarvan | overlord???? | 18:13 |
| soee_ | aye | 18:13 |
| jimarvan | where have I heard that before??? | 18:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| yofel | I'm fine with new-release being a shortcut wrapper itself, but I'm not a fan of having multiple layered wrapping | 18:20 |
| 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:21 |
| yofel | how would it then add changelog entries? | 18:22 |
| santa_ | oh well | 18:23 |
| santa_ | you want a wrapper doing so many things | 18:23 |
| 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:24 |
| 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:26 |
| 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:27 |
| yofel | either that or the wrapper will be a shell script | 18:28 |
| 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:33 |
| 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:34 |
| yofel | well, keep that for now then as you already did the work | 18:35 |
| santa_ | right now I'm using both the approach a) and b) but we can change the thing to use only a) | 18:37 |
| acheronuk | clivejo: http://paste.ubuntu.com/20209511/ | 18:38 |
| 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:39 |
| yofel | hm, that's a point, true | 18:40 |
| santa_ | yofel: tell me more about your other issues with the "user interface", you also wanted a wrapper | 18:42 |
| santa_ | do you want a staging-upload clone? | 18:43 |
| santa_ | or something similar? | 18:43 |
| 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:50 |
| clivejo | wonder does discover need a no change rebuild | 18:51 |
| clivejo | is it a no change rebuild in Neon? | 18:57 |
| acheronuk | plasma-discover stays at our ppa version 5.6.5 here if I enable neon on a xenial box | 19:01 |
| 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:09 |
| acheronuk | so a few things Neon have done their own builds of there, besides just plasma/FW etc | 19:11 |
| 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:18 |
| clivejo | how are they out of sync in like a week | 19:19 |
| clivejo | yofel: ping | 19:54 |
| * 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:56 |
| 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:57 |
| acheronuk | I'm not on BT, but I imagine it will effect other providers | 19:58 |
| acheronuk | or it's just damn annoying coincidence | 20:01 |
| clivejo | problem is its probably provided via BT wholesale | 20:01 |
| acheronuk | This is Sky, which is easyNet, but most are linked and do "peer sharing" of resources, so yes | 20:03 |
| 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:04 |
| 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:05 |
| clivejo | UK needs a BTexit | 20:06 |
| 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:46 |
| 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:52 |
| acheronuk | as they would more closely match what will eventually be in the YY archive? | 20:53 |
| clivejo | shouldnt be much difference to yourse | 20:54 |
| acheronuk | clivejo: no, just 5.6.1 as far as I can see | 20:54 |
| 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:55 |
| yofel | we'll probably need an FFE anyway, unless qt makes it into proposed ~2 weeks before FF | 20:56 |
| yofel | early FFE's are non-issues though | 20:57 |
| acheronuk | yofel: that's a slight relief :) | 20:57 |
| 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:03 |
| 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:04 |
| 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:06 |
| santa_ | so uploadsource would upload what's in ../upload | 21:07 |
| yofel | could you symlink it instead? | 21:07 |
| santa_ | maybe | 21:07 |
| * santa_ checks dcmd man page | 21:08 | |
| yofel | or hardlink/copy, whatever works | 21:08 |
| santa_ | yofel: hmm what about just moving it? | 21:08 |
| yofel | I would like to be able to expect the files to actually be in build-area where they're supposed to be | 21:09 |
| 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:10 |
| 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:11 |
| yofel | clivejo: your opinion ^ | 21:12 |
| clivejo | sorry, wasnt following | 21:13 |
| yofel | clivejo: just what scott said | 21:13 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| clivejo | but long term the natural cycle of volenteers will mean we lose the skills to actually do to the packaging | 21:20 |
| clivejo | is it something easy to setup (syncing directly with debian) | 21:21 |
| yofel | it is something that doesn't require setup | 21:21 |
| 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:22 |
| yofel | maybe | 21:23 |
| 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:25 |
| jimarvan | does the frameworks packaging break that much? | 21:26 |
| jimarvan | oh i see for the non-ubuntu-changed packages | 21:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| * 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:36 |
| acheronuk | I'll work with whatever people think is best also | 21:37 |
| 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:38 |
| jimarvan | good night everyone, see you tomorrow | 21:39 |
| yofel | nini | 21:39 |
| jimarvan | ;) | 21:39 |
| acheronuk | 'not touch' as in not even fixes in CI? | 21:40 |
| yofel | nah, you can do that | 21:40 |
| acheronuk | good night jimarvan :) | 21:41 |
| clivejo | I wish KCI would stop this *** Cannot allocate memory. Stop. rubbish | 21:41 |
| acheronuk | yofel: ok. good. | 21:42 |
| acheronuk | while the workflow goalposts keep moving, and least I can practice packaging with that! | 21:43 |
| clivejo | moving goal posts help you work better :P | 21:48 |
| 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:52 |
| valorie | can someone paste to me that past 10 mins or so? | 21:53 |
| acheronuk | valorie: http://paste.ubuntu.com/20233603/ | 21:54 |
| valorie | from :30 - 34, actually | 21:54 |
| acheronuk | http://paste.ubuntu.com/20233774/ | 21:55 |
| valorie | thank you acheronuk | 21:56 |
| valorie | ha, I said a couple more lines but they got lost | 21:57 |
| valorie | thanks, comcast..... | 21:57 |
| 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:58 |
| acheronuk | It's actually normally not too bad for ADSL | 21:59 |
| acheronuk | glad I got that KDE BNC, or I would have been in and out of this channel every 5 mins! | 22:01 |
| clivejo | its handy! | 22:02 |
| IrcsomeBot | <ovidiuflorin> Please review http://kubuntu.org/news/kubuntu-podcast-14/ | 22:04 |
| valorie | ovidiuflorin: made a couple of little edits, mostly punctuation. Thanks for publishing! | 22:32 |
| 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:41 |
| valorie | \o/ | 22:42 |
| * clivejo kicks the *beep* out of LP | 22:59 | |
| 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:04 |
| 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:05 |
| santa_ | so yo used the old tooling but my "work" branch? | 23:06 |
| 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:07 |
| santa_ | clivejo: ok, willing to retry the new tooling for the next release? thanks for your patience by the way | 23:09 |
| clivejo | just want to get eyes on plasma 5.7 | 23:10 |
| valorie | yay, the desktop folder is the right size in the installer | 23:15 |
| valorie | and install seems to be going well | 23:22 |
| clivejo | valorie: you still got a YY install? | 23:29 |
| valorie | gotta do it again | 23:32 |
| valorie | it says not enough disk space | 23:32 |
| valorie | I forgot that it wants all I can give it | 23:36 |
| valorie | every time | 23:36 |
| valorie | we still have a slideshow -- I thought it was removed because of problems? | 23:42 |
| valorie | or is that just in YY | 23:42 |
| valorie | no problems with this install, yet | 23:43 |
| clivejo | just YY | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!