[02:44] valorie: my bad I fell asleep [02:45] np [02:45] can you check and publish? [02:45] why are we linking to 14.04? [02:46] ? [02:46] on the download page? [02:46] because it's LTS [02:46] for those who need the old plasma [02:47] no the post you drafted [02:47] it says 14.04.1 but it was linked to 16.04.1 [02:47] typo I guess [02:48] I copied an old post and updated it [02:48] that's why a review is always good! [02:48] want to link it to the text or just make it a link? [02:48] the sentence should be a link [02:48] same with the announce email [02:49] dunno who to make wordpress do that [02:49] I can do it, also updated the alt download page from 16.04 to 16.04.1 [02:49] and 14.04 to 14.04.4 [02:49] super [02:50] thank you [02:50] np [02:51] let me make one change to the download page and I'll get out and let you check [02:53] valorie: aright I'm out [02:54] well logged out, still here if things need to be fixed [02:55] ahoneybun: I don't see it [02:55] did you publish? [02:55] it's a draft still [02:56] if that is how you meant it to look [02:56] it's out; let's publish [02:56] alright [02:56] added the release notes of .1 on the getkubuntu page as well [02:57] I pushed the publish button [02:57] thanks ahoneybun [02:57] cool np :) [02:58] uh [02:58] why is 15.10 there? [02:58] that isn't supported anymore, is it? [02:58] !releases [02:58] Ubuntu releases a new version every 6 months. Each version is supported for 9 months (non-LTS) or 5 years (LTS). More info at https://wiki.ubuntu.com/Releases & http://wiki.ubuntu.com/TimeBasedReleases [02:59] yea it lost it this month [02:59] I can remove it [02:59] yes please [02:59] let's see if ovidiuflorin gets mad lol [03:00] I think it actually officially loses support tomorrow, but whatever [03:00] since it was released on the 22nd [03:01] done [03:01] \o/ [03:02] at least we're ahead there then [05:14] clivejo, acheronuk: you see my upload? [05:42] /me is mad [05:42] about? [05:42] :-P [05:42] You asked me to get mad, now I'm mad. [05:42] 😜 [05:42] XD [05:43] I did not break anything so [05:44] tsimonq2: yes, see the comments after 13:48 https://irclogs.ubuntu.com/2016/07/21/%23kubuntu-devel.html [05:45] oh okay [05:47] tsimonq2: the original versioning on that package is confusing [05:47] acheronuk: well it wouldn't let me rebuild with ubuntu1 [05:47] wait a minute [05:48] acheronuk: has it already been handled? [05:48] if not, I'll just replace the debian revision with 3build1 [05:48] should be something like 1.8.18+git20160320-3d8622c-3build1 [05:48] yeah [05:49] acheronuk: so my question was, has it already been handled or can I do that again? [05:49] just checking the ppas... [05:50] nope. nothing there I can see [05:50] alright [05:50] acheronuk: do you have access to upload my fix? [05:51] as you have a -4 in your ppa, it might reject you uploading -3build1 to ppa [05:52] deleted the PPA [05:52] it's a throwaway PPA [05:52] I can copy to the kubuntu ppas anything that is fixed, yes [05:53] alright :) [05:53] acheronuk: why is the package being rebuilt? [05:53] it may have worked by deleting the package and waiting the 20-30 mins for launchpad to delete the sources from disk [05:53] (for the changelog entry) [05:54] but a new ppa also works [05:55] the package needs rebuilding as the one in the archive was built against old dependency versions [05:55] Qt 5.5 etc [05:56] and the newer versions in the staging-plasma ppa cause the package to be removed or become uninstallable as a result [05:57] acheronuk: https://launchpad.net/~tsimonq2/+archive/ubuntu/testing-1 [05:57] acheronuk: just uploaded [05:57] so it needs a no change rebuild against those newer packages to work with thsoe [05:57] yeah [05:58] acheronuk: https://launchpad.net/~tsimonq2/+archive/ubuntu/testing-1/+packages [05:58] :) [06:00] :D [06:03] that can get copied across making sure that the option "Rebuild the copied sources" is selected, which would then rebuild again in our ppa against the versions there [06:08] as per yofel's comment @21:19 UTC, and backport to xenial would have to be versioned differently. i.e 3build1~ubuntu16.04~ppa1 [06:14] tsimonq2: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-plasma/+packages?field.name_filter=qtcurve&field.status_filter=published&field.series_filter= [06:30] yeah acheronuk [06:31] acheronuk: so I need to upload the Xenial fix? [06:31] yes [06:32] alright [06:33] thanks acheronuk for uploading that then :D [06:33] s/then// [06:33] no probs :) [06:34] acheronuk: version in Xenial is 1.8.18+git20160112-0cd6aae-1 , so I have to make it 1.8.18+git20160112-0cd6aae-1build1 [06:35] tsimonq2: no, you can backport the yakkety one you have done [06:36] oh alright [06:37] as something like 1.8.18+git20160320-3d8622c-3build1~ubuntu16.04~ppa1 [06:38] acheronuk: I have a version in mind [06:40] kubuntu keeps to a versioning scheme for ppas and backports, so it's clear they are a backport, a ppa version, and upgrade ok if someone upgrades to the next ubuntu version [06:41] alright so I have to change it from what I uploaded? https://launchpad.net/~tsimonq2/+archive/ubuntu/testing-1/+packages [06:41] acheronuk: or is it fine as-is? [06:41] it needs to have the ~ after the version you did for yakkety [06:43] that makes apt/dpkg see it as an earlier version than the YY one you did, so if someone then upgrades to YY the XX one gets replaced [06:43] as said, yesterday yofel suggested 1.8.18+git20160320-3d8622c-3build1~ubuntu16.04~ppa1 [07:10] alright acheronuk [07:10] acheronuk: I'll do that [07:13] acheronuk: argh... dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address [07:13] hmmm.... not sure [07:19] Why would someone rm -rf /var/lib/apt/lists/* after installing some packages in a Docker image? [07:21] I've checked /var/lib/apt/lists after installing somehting and it's empty [07:21] I don't get it [07:25] tsimonq2: ummm..... I get that as just a warning, but not an error http://paste.ubuntu.com/20422182/ [07:29] grrr. or even if I could follow my own suggestion properly, then http://paste.ubuntu.com/20422518/ [07:35] acheronuk: what OS are you running? what command did you run? [07:37] I am running Xenial, and I ran 'debuild -S -sa' [07:37] I'm running Yakkety [07:37] *gets Xenial schroot* [07:38] tsimonq2: should make no difference as far as I know [07:39] clivej does everything while running yakkety [07:40] weird [07:41] I've only been doing this a few months, so others may see something obvious I can't right this second [07:50] ovidiuflorin: that directory contains the apt package list cache (i.e. the files that apt update downloads). You could argue that's data you don't need in a docker image [07:51] yeah... that's what the doker folks told me [07:51] I hoped for a more detailed explanation [07:53] yofel: would you happen to know why I can't build this? [07:55] ovidiuflorin: well, that folder is 510M on my system, and those are files that you can always download again if you need to install something, so it's really not something you want inside a docker *image*, only in a running container if you need them [07:55] as you generally want to keep the image size as small as possible [07:56] and if you keep updating the images, those files would also bloat the diff between versions [07:57] I get how for docker that would be a bad thing, but what's in there more precicely? [07:58] the package lists, which are the files that tell apt what packages it can download from which repositories. e.g. /var/lib/apt/lists/de.archive.ubuntu.com_ubuntu_dists_trusty_main_binary-amd64_Packages [08:00] plus the package description translations, DEP-11 metadata for icons and components, etc. [08:03] acheronuk: would it be okay if I named it 1.8.18+git20160320-3d8622c-3build1~16.04~ppa1 ? [08:03] yeah, that'll be fine [08:04] tsimonq2: does that work for you then? [08:04] yup [08:04] perfect [08:05] yofel tsimonq2: maybe the yakkety version of devscripts etc has stricter checks now then? [08:05] maybe [08:05] hm, that's dpkg, not devscripts [08:05] but yeah, probably [08:06] yofel, acheronuk: uploaded, building now: https://launchpad.net/~tsimonq2/+archive/ubuntu/testing-1/+packages [08:07] * acheronuk goes to look at dpkg changelog [08:13] acheronuk: done building, do you wait until it's published to copy or can you do it now? [08:14] if (length $ENV{DEBEMAIL} and $ENV{DEBEMAIL} =~ /\@ubuntu\.com/) { [08:14] error(g_('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address')); [08:14] } else { [08:14] warning(g_('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address')); [08:14] interesting.... [08:14] weird [08:14] tsimonq2: copied https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-plasma/+packages?field.name_filter=qtcurve&field.status_filter=published&field.series_filter= [08:15] \o/ [08:16] acheronuk: so what happens after that PPA? [08:16] acheronuk: and is there anything else packaging-related I can do? [08:18] tsimonq2: will end up going into Xenial backports ppa in the end hopefully, and the YY packages into YY if someone with main archive permissions deems them ok [08:18] alright :) [08:18] acheronuk: I see a bunch of `Newer version available` warnings, is that expected? [08:19] for example: qtconnectivity-opensource-src - 5.6.1-2~yakkety+build1 (Newer version available) [08:20] tsimonq2: normally you'd worry on that, but with those packages it's ok [08:20] it's because 5.6.1 of that package is in the archive already [08:20] with a higher version than in the PPA [08:20] reason being that ubuntu Qt maintainers uploaded their versions, but the builds failed. but launchpad still sees the newer sources are there [08:22] when building in the ppa LP takes the ppa version, as the archive version has no actual built .debs [08:26] tsimonq2: clivejo probably has a better handle on what is currently needed re packaging tasks [08:32] alright [08:32] clivejo: could I get something else to do? :) [08:34] yofel: so if I had an ubuntu.com email address like simon, it would give me an error? [08:34] probably. I use my kubuntu.org one, so that explains why I never get that [08:36] I can see the logic. sorta. ubuntu uploader and 'ubuntu' in version, but not ubuntu maintainer = wtf (error) [08:41] yeah, we just hit a corner case where that's nonsense [08:57] tsimonq2: I can now use that ppa without it removing my qtcurve themes for kde :) [08:57] which makes me happy, as I'm not keen on breeze or the qt5 oxgen :D [09:44] Has log in time slowed down again in 5.7.2? [09:49] i have this feeling [09:55] acheronuk: yay! :D [09:56] acheronuk, yofel: maybe it would be worth it to file a bug [09:57] tsimonq2: what was the context again? [09:57] soee: feeling it has slowed down? [09:57] clivejo: It seems about the same for me, unless the missing-folderview-desktop bug is triggered. [09:58] yofel: can't have Ubuntu revisions because it [09:58] That bug is sort of similar to what we were seeing early with 5.6.x when the folderview on the desktop would disappear and it would take a very long time on the splash screen. [09:58] I feel like its delayed by about 15seconds compared to previous versions of plasma [09:58] *the maintainer doesn't have an Ubuntu address [09:58] clivejo: ^ [09:58] wait didn't mean to ping you but hello :) [09:58] * clivejo waves [09:58] clivejo: yes [09:59] sorry, just logged on, trying to catch up! [09:59] so many different threads of conversation [09:59] tsimonq2: feel free to, IMO that's not worth an error, even if the original intentions were good [09:59] yofel: where did you find the code for that? [10:00] scripts/Dpkg/Vendor/Ubuntu.pm [10:00] clivejo: I'm looking for something else to do now :) [10:00] yofel: in what package? [10:00] dpkg [10:00] alright thanks [10:00] clivejo: In my case, the problem was that the ~/.config/plasma-org.kde.plasma.desktop-appletsrc had lastScreen=-1 for the folderviews. Obviously, you can't have negative monitors, so once I replaced those values with 0 and 1, it worked fine. [10:02] oh, the trello integration for my nick is fixed. yay [10:02] clivejo: got anything? :) [10:02] hey clive [10:06] mamarley: i had one lastSeenScreen=-1 in that file [10:06] changing it doesn't speed up loading [10:06] hmm but i still have it set to -1 [10:07] soee: You may have to shut down Plasma before changing it, or you may not be suffering from the same problem as me. [10:07] tsimonq2: well Im working on testing Plasma 5.7.2 on YY [10:07] trying to resolve the installation issues with it [10:08] there is some issue with plasma-dsicover I havent managed to figure out yet [10:08] discover [10:09] anyone else see this on YY? [10:11] clivejo: that same PPA? [10:11] staging-plasma [10:12] you could also look for packaging issues you can fix on KCI [10:12] send us a merge request [10:13] alright [10:13] what's KCI? [10:13] Kubuntu Continious Intregration [10:13] http://kci.pangea.pub [10:13] alright [10:14] it grabs the latest source code from KDE and combines it with our packaging ( https://code.launchpad.net/~kubuntu-packagers/+git ) [10:14] aww why does it have to remove LXQt? [10:15] now I have to use it in a VM [10:15] :P [10:15] clivejo: I would highly suggest removing any conflicts with LXQt [10:15] those messages from kubuntu-ci are being generated by KCI [10:16] tsimonq2: I dont know enough about LXQt to comment on that [10:16] alright [10:17] LXQt are going to have to cope with the Qt 5.6 transtion in YY eventually, if that is the cause [10:17] Hiyas all [10:18] clivejo: I can maybe have a look at that discover conflict later if no-one else does [10:19] acheronuk: yeah LXQt uses Qt 5.5.1 [10:19] clivejo: just now I'm about to go for a pub-lunch, so will be some time [10:20] tsimonq2: Well Qt 5.6 will go in the main archive for YY, so they'll have to cope with it as we are doing [10:20] tsimonq2: do you know any of the LXQt people? [10:21] clivejo: great friends with them :) [10:21] well not really [10:21] but I know them [10:22] clivejo: I'll do some test builds locally [10:22] maybe you could get in touch and see if they need help transitioning to Qt 5.6.1 [10:23] alright, but like I said, maybe it already works [10:23] I dont personally use it so dont see the conflicts [10:23] *shrug* [10:23] sddm doesn't accept jpegs for background on the login page [10:24] on Yakkety [10:24] maxyz has done a build of lxqt-qtplugin - 0.10.0-3build1~2 in his ppa today [10:24] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-024/+packages [10:25] so he at least is looking at it === greyback_ is now known as greyback [10:25] ok. bbl [10:25] ooh let's see [10:28] clivejo: let's say foo depends on bar. bar 0.2 is in the PPA but bar 0.1 is in Ubuntu. I upload foo 0.1-1. Does foo use bar 0.1 or 0.2 when building? [10:28] (this is in a PPA) [10:29] packagekit : Depends: libpackagekit-glib2-16 (= 0.8.17-4ubuntu6~gcc5.4ubuntu2) but 0.9.5-0ubuntu1 is to be installed [10:30] 0.1-1 is debian version [10:31] clivejo: but just for example [10:31] but 0.2 is higher so if its in the same PPA, it will build using that [10:31] alright [10:31] great [10:31] do you know about epochs? [10:32] in what context? [10:32] packages [10:32] sort of [10:33] !info ark [10:33] ark (source: ark): archive utility. In component universe, is optional. Version 4:15.12.3-0ubuntu1 (yakkety), package size 421 kB, installed size 1535 kB [10:33] 4:15.12.3-0ubuntu1 The 4: is an epoch [10:33] oh then I don't know [10:34] the -0 is the debian version [10:35] and ubuntu1 is our archive version [10:35] with the 15.12.3 being the upstream KDE version of the package [10:36] oh okay [10:36] git pull [10:37] oupps [10:37] I knew what the rest standed for, I just don't know what the 4: means [10:37] usually to fix a boo boo someone makes with the version [10:38] ie if they made a typo and released 51.12.3 [10:39] that version will not be upgradeable again until upstream get to a version higher than it [10:40] so the epoch overrides it and allows us to fix the versioning so it is upgradable again [10:40] oh okay [10:40] can be confusing [10:41] but essential to understanding you need the epoch for build deps as well [10:45] so wait, the 4 means that 51.12.3 can't be upgraded to 51.12.4 and over? [10:45] or am I not understanding this correctly? [10:45] 51 is just an example [10:46] a typo where someone might have put 51 instead of 15 [10:46] ohhhh [10:46] so I understand the purpose now [10:46] but the next natural version from KDE is 16.04 [10:46] but why 4? [10:46] but because 51 is greater, it wouldnt allow the upgrade [10:47] why not 15 then? [10:48] once its gone to the archive and install on many systems we cant just change it back [10:49] its rare, but in Kubuntu we have a few :/ [10:49] I think an automation script may have messed up in the past, but I dont know the reason [10:49] so give me an example of a correct epoch then [10:51] well ark is an example [10:51] it has an epoch of 4: [10:52] oh [10:52] http://anonscm.debian.org/cgit/pkg-kde/applications/ark.git/tree/debian/changelog [10:52] I guess what is the barrier with 4? [10:52] why does it have to be 4? [10:53] I'm not understanding that [10:53] well in this case I cant answer that! [10:54] Initial packaging on line 635 of changelog seems to indicate it started off life with an epoch [10:54] does it have to universally be 4 and if not, why? [10:54] I think, someone decided to use 4 [10:54] maybe KDE4 at the time [10:55] sorry for not understanding this, but what about in a different package? [10:55] and because we use automation it might been easier to just give all the applications suite a 4: epoch [10:56] most of KDE Applications have an epoch of 4: [10:56] I would like to understand what it's preventing. Is it if the version is over 4? [10:56] If so, then that isn't right [10:56] http://qa.kubuntu.co.uk/ppa-status/applications/build_status_16.04.3_yakkety.html [10:56] I mean, what does it prevent? [10:57] it allows the package to be upgradeable again after a mistake in the versioning [10:58] say for example I release 16.07 of my latest app [10:59] but I made a type and instead released version 61.07 [10:59] I then release 17.01 of the app in January [10:59] but the archive has version 61.07 which is higher [11:00] my new app will never be upgradeable until the version is greater than 61.07 [11:00] so to override that my new version would need an epoch [11:01] ie 1:17.01 [11:02] this now means my new version will be installed, upgrading version 61.07, the freak package of doom [11:02] oh okay [11:02] clivejo: then for the next release do you remove the epoch? [11:03] no [11:03] it cant be removed [11:03] so then what happens if you do it again? [11:03] if I did another mistake, ie 1:71.05 [11:03] then I have to bump the epoch again [11:03] to 2:17.06 [11:04] and so forth [11:04] oh okay [11:04] that makes sense [11:04] I get it now :) [11:04] clivejo: so why do I need to know this for rebuilds? [11:04] LOL you dont [11:04] you asked about versions [11:05] and epochs are very important [11:05] but also confusing! [11:07] LOL [11:07] git fetch santa [11:08] 05:40:51 AM < clivejo> can be confusing [11:08] 05:41:20 AM < clivejo> but essential to understanding you need the epoch for build deps as well [11:08] I took that as I needed it for rebuilds XD [11:08] but hey, nice to know :) [11:08] no, just packaging in general [11:09] its an area that took me a while to get my head around [11:09] Im very bad with numbers [11:09] Im Dyslexic === clivejo changed the topic of #kubuntu-devel to: Kubuntu - Friendly computing | Yakkety open, happy hacking | Plasma 5.6.5 Y-LANDING, X-BACKPORTS / Apps 16.04.03 Y-STAGING, X-STAGING / FW 5.24 Y-STAGING, 5.23 X-BACKPORTS| https://trello.com/kubuntu | http://qa.kubuntu.co.uk/ | Package Docs (WIP) https://notes.kde.org/p/kubuntu-packaging [11:13] clivejo: I think this is failing due to the lack of memory... http://kci.pangea.pub/job/yakkety_unstable_kdepim-addons/ [11:14] yeah, KCI has "issues" [11:14] but PIM is a beast, noone likes tackling it! [11:29] santa_: was there an issue with kde4libs? [11:33] acheronuk: Mmh, no, that was not me [11:47] clivejo: what Qt, non-KDE packages are in the staging-plasma PPA? [11:47] clivejo: just all the qt* packages? [11:48] clivejo: it was ftbfsing from git/kubuntu_yakkety_archive because of symbols, build logs: [11:49] https://launchpadlibrarian.net/271959760/buildlog_ubuntu-yakkety-amd64.kde4libs_4:4.14.22-0ubuntu1~ubuntu16.10~ppa1_BUILDING.txt.gz [11:50] http://gpul.grupos.udc.es/logs/kde4libs_4.14.22-0ubuntu1+santa30_amd64.build [11:51] clivejo: ffmpeg thimbs was failing too bacause of a less trivial issue, I have a merge request fixing that one [11:51] * ffmpegthumbs [11:52] tsimonq2: what was your doubt about versioning, you don't understand the "4:" prefix of some packages? [11:53] santa_: he cleared things up for me [11:53] k [11:55] [13:07] git fetch santa [11:55] lol [11:58] ah I see you already merged my stuff, thanks! [11:59] don't we have a bug for the ffmpegthumbs issue? [12:02] if we have it I don't know [12:02] bug 1574037 - anyone fancy doing an SRU for that? [12:02] bug 1574037 in ffmpegthumbs (Ubuntu) "ffmpegthumbs 4:15.12.3-0ubuntu1 uses the wrong path for plugin libraries" [Medium,Confirmed] https://launchpad.net/bugs/1574037 [12:02] ah, that's other issue [12:02] santa_: that was fixed in the diff you proposed to merge though [12:03] yes, because it uses the new pkg-kde-tools stuff [12:03] making the path right [12:03] exactly [12:04] I was planning to prepare a couple of merge requests for things in xenial [12:04] (targeted to updates) [12:05] santa_: everyone of that would need an SRU bug associated with it [12:06] but it would be great to have a list of stuff that we should be fixing [12:08] * yofel wonders what happened to apps 16.10 [12:09] 16.10? [12:09] er, 16.08 [12:10] ah [12:11] yofel: any document about how the ubuntesque "bureaucracy" works for sru's? [12:11]