[00:16] Im afraid that’s me done for the night! [00:16] Night clivejo [00:17] should be a few more fixes in the pipeline, but the KCI queue is full and god knows when it will get around to building them [00:19] only 24 failing packages in yakkety :) [00:19] Nicr [00:19] *nice [00:22] 00:21:09 make: *** Cannot allocate memory. Stop. [00:22] grrr [00:22] makes me angry [00:22] good night [07:06] hiho [07:25] I've filed some bugs to please release team a bit more (they didn't ask, but I thought they might) https://bugs.launchpad.net/bugs/+bugs?field.tag=kf524 [07:25] I left out marble and okteta that I probably fixed now with symbol updates (marble also accepted to get built now), and akonadi-search that I'm still retrying to see if it's only flaky test as it failed only on one arch [07:26] no response from release team however even though infinity said to be looking at the override plea "later" (14h ago) [07:26] so, waiting continues today [07:41] Mirv: thanks! Having a track list of the tests is useful [08:24] o/ === chs is now known as chris17 === chris17 is now known as chs [09:25] someone is using Enpass ? [09:30] uhm desktop app is GTK but at least the icon works and fits pretty nice systray [09:44] we got the autopkgtest forces! [09:45] I'm still waiting for unity8 QA however to fix its tests. after that it's about pondering with release team "why nothing happens", which is usually the case and update_output.txt is needed in addition to the excuses page. [09:51] oh ok missed a single plasma-framework s390x issue. I will ask that once we know whether u8 landing makes that green or not (if not, I'll ask if it could be overridden too and investigated later) [10:01] Howdy folks [10:09] o/ BluesKaj [10:10] hey ts [10:10] lol [10:11] tsimonq2,^, it's early, still on my first coffee :-) [10:12] BluesKaj: well are you in #ubuntu-community-team ? I thought it was from the joke I literally just started there :P [10:12] no [10:13] HAHAHAHAHA [10:14] guess I missed the humour [10:14] BluesKaj: I PMed you what was said so I don't spam the channel [10:36] green <3 [10:37] https://www.youtube.com/watch?v=OzgY_S7rEoo [10:49] that was a nice minute of my life... :P [11:23] LOL [11:24] Gonna have that stuck on replay in my head all day now [11:24] Thanks soee [11:25] :d [11:25] Only 17 broken packages sitting on the wall [11:26] how do they become brokne exactyly ? [11:26] The current ones have been broken for a while [11:27] Most are PIM related [11:29] Upstream changes mostly [11:31] Clifford meanwhile I'll have this garbage stuck in my head all day :P https://www.youtube.com/watch?v=mVHJ6OwTYWc [11:31] libkf5calendarsupport http://paste.ubuntu.com/22018296/ [11:49] acheronuk: wrap those tests in xvfb-run [11:51] so.....? [11:51] override_dh_auto_test: [11:51] xvfb-run dh_auto_test [11:53] yofel: and add xvfb to the build depends? [11:53] acheronuk: yes, and yes [11:53] great. thanks :) [11:56] can someone confirm this ugly clear button for filter field: http://i.imgur.com/xn3gWXs.png ? [11:57] soee: Nope, sorry, looks fine here. [11:58] :< [11:58] filter? [11:58] search field [11:58] can't read your language [11:59] it is not about lang, just the darkest button on the image :D [12:00] I see a pixel black button [12:00] yup [12:25] wee.. warranty was goof [12:26] *good [12:26] i will have my monitor chnaged ot new one :) [12:49] www.youtube.com/watch?list=PL0pdzjvYW9RFM_RjJhUhOO0OH8uVoRn3J&v=EshNTl23liY [13:08] yofel: those tests still fail http://paste.ubuntu.com/22025809/ [13:09] huh, why does that need glx... [13:10] seems an odd thing to want for that, yes [13:12] libkf5calendarsupport_16.04.3+p16.10+git20160803.1257.orig.tar.xz: [13:12] huh? why isn't that called calendarsupport? [13:14] bbl [13:29] bbl o/ === mgolden is now known as mgolden_ [13:49] ummm. so disable that test? [13:50] I fixed it, you need to set the screen by hand for GL (took that from an autopkgtest config) [13:51] ah. thanks [13:56] Hey guys there will be a respin shortly for 14.04.5 will someone be available to help out testing it? [14:01] davmor2: maybe, what's the rough equivalent of 'shortly' in hours? [14:02] * yofel agrees with infinity that our job is breaking things most of the time :D [14:02] yofel: About an hour I've been told but infinity can give a more accurate time [14:02] k, thanks [14:07] the yakkey fix page fits on one screen \o/ [14:13] hm........... [14:15] let me merge the current state in kubuntu_stable. Those symbols are 16.12 material [14:19] that was my next question if I got it built. I tried in pbuilder with the tests disabled, and got all those missing! [14:21] * yofel is a bit lost about the symbols [14:21] having the build jobs stay broken is bad, but then we loose symbol tracking for the archive updates which we need :/ [14:22] patching debhelper in the ci PPA would be an idea... [14:22] patching to do what exactly? [14:22] not fail the build on missing symbols [14:23] but the build fails because that really does require an so version change :( [14:24] debianabimanaging all failures would be the perfect solution. But that's an overkill amount of overhead :/ [14:25] or we keep leaving the MISSING comments in there and just update the symbols [14:25] but then we need to extend our archive QA to actually detect that [14:25] which probably would mean adding more patches to pkg-kde-tools [14:38] huh, what did *that* build o.O [14:38] *why [14:39] marble [14:39] set(GENERIC_LIB_VERSION "0.24.80") [14:39] set(GENERIC_LIB_SOVERSION "25") [14:39] set for 16.08 branch [14:40] I would postpone marble and okteta until after we've done the release branching for 16.08 [14:40] and those latest big changes were in the 16.08 branch as well as master, so are the ok to fix? [14:42] ok. won't touch them [14:42] without a stable job it's hard to say [14:42] really all changes? The diff between 16.08 and master is huge for marble [14:43] let me check again [14:45] ok, this one was in both: https://quickgit.kde.org/?p=marble.git&a=commit&h=6c5a0b395dd34457d107780b398fb1df5beb9950 [14:45] which was the big one I got the other night, and then said stop! [14:46] acheronuk: I guess lets risk it for both, and remember to re-check once we upload 16.08 [14:47] I'll have another look through both before I even think about making changes, and if I'm not sure I'll query [14:49] hm, we never did finish 16.04.3 [15:10] ALSA 1.1.2 Released [15:12] Something trout something === aaron is now known as Guest69044 === Guest69044 is now known as ahoneybun [15:29] yofel: if calendarsupport unstable is now merged to stable, are those symbols OK to fix now? or are you still pondering things and would prefer it left? [15:30] acheronuk: just fix it [15:31] okay [15:31] we'll probably have to cherry pick stuff from kubuntu_unstable anyway, so lets worry about that in a week [15:34] santa_: so agreed, pkg-kde-tools is probably the appropriate place for that. Now I wonder how I would detect that we're building for the CI.. [15:34] having a patched pkg-kde-tools in the ci ppa all the time would be somewhat annoying :/ [15:34] I have a source of inspiration for that [15:34] let me check... [15:43] mm there goes tryin got build the telepathy morse plugin [15:46] yofel: I think I would go for a shell evironment variable. so the CI would build with this variable [15:47] hm, then I need to figure out how to pass that into docker... not sure how the env looks like right now [15:48] but I did consider that too [15:48] (as it would be the most straight-forward solution build-system wise) [15:49] shouldn't be adjusting the templates for the build slaves enough? [15:50] santa_: the actual binary builds happing on launchpad, not in jenkins [15:51] hm..... [15:51] oh [15:51] or the ci-tooling injects a file into the source before uploading it [15:52] what builds in launchpad you are talking about? the ppa builds or something else in the kubuntu's workflow I am not aware yet? [15:53] santa_: the CI builds. Jenkins generates the sources, uploads that to the kubuntu-ci/ PPAs, then continues its work once the builds are done [15:54] ah, ok [15:56] yofel: in case you go for "or the ci-tooling injects a file into the source before uploading itor the ci-tooling injects a file into the source before uploading it"(TM) I had an script to alter one packages debian/rules and pass -c0 to dpkg-gensymbols [15:57] it supported both packages with and without dhmk [15:58] santa_: hm, true, that then actually doesn't need any pkg-kde-tools modification at all. As long as people don't accidentally copy that change into git [15:58] but altering the source like that is a bit ugly [15:58] although, that can be detected and the CI build made to fail on that [15:59] right, but the only other way I can currently think of is checking whether sources.list contains 'kubuntu-ci', which is ugly :( [15:59] does sbuild export something useful.. [16:00] well, looking at the bright side of altering the source this would allow you to select which packages you want to build with -c0 and which ones you don't, right? [16:00] it would at least allow the possibility of doing that [16:03] on second though, with that we can only disable the check for /unstable, as /stable really should throw errors [16:04] and the tooling already messes with the changelog, so adding this won't really hurt [16:05] oh fun, I found the reason why the post-publishing checks aren't running [16:06] unless File.exist?('logs/i386.log') [16:06] puts 'found no logs' [16:06] exit 0 [16:06] we don't build i386 anymore ^^ [16:07] hmm, what happens with i386 finally? [16:08] santa_: the logs? That's used for the lintian and symbol-addition checks [16:09] it also has a rather hacky qml dependency checker. Need to see if harald improved that in neon [16:10] yofel: no I mean I remember I read something about dropping i386 suport or something like that [16:10] but I don't remember where [16:10] santa_: oh that, I don't think we'll do that for the archive until 18.10, but we did remove it from the ci build list [16:10] it was on ubuntu-devel [16:10] ML [16:11] hm, why is i386 hardcoded there when there's proper archindep handling below that code.... [16:11] yofel: another one that produced significant symbols changes - messagelib (kf5-messagelib) https://launchpadlibrarian.net/276544991/buildlog_ubuntu-yakkety-amd64.kf5-messagelib_4%3A16.04.3+p16.10+git20160803.1248-0_BUILDING.txt.gz [16:11] ah, there's a thread in kubuntu-devel too [16:12] yeah, that was partially CCd [16:12] acheronuk: maybe ignore that for today. I'll try to get the symbol ignoring added to the CI today after the meeting [16:13] yofel: no problem at all. will do [16:17] oh, the host key validation for launchpad is also only done once. I thought that happened for every dput attempt [16:36] yofel: when I build libkolab it puts the lib in usr/lib/libkolab.so.1 but the install file is looking for usr/lib/*/libkolabxml.so.1* do I adjust the install file to match or try and make it put it into /usr/lib/ [16:37] clivejo: first of all, that xml part sounds really wrong. But I would see why it doesn't put it into first [17:05] Ive got a number of failed build emails from LP [17:05] it's updating trusty still? [17:05] huh? [17:05] [Notice] -queuebot to #kubuntu-devel- Builds: Kubuntu Desktop amd64 [Trusty 14.04.5] has been updated (20160803) [17:22] libkf5eventview is looking for KGanttConfig.cmake [17:23] but libkf5kdgantt2 in KCI produces KF5KDGantt2Config.cmake [17:23] so FAIL! [17:25] https://gitlab.com/siduction-tools/pkg-kde-automation/blob/master/pass-c0-gensymbols [17:26] yofel ↑ the script I was usingto automate the addition of -c0 [17:27] I can schedule a rebuild in my ppa simulation of frameworks/plasma/apps to check that it's still in shape [17:38] hmmm. they decided to use kdiagram https://quickgit.kde.org/?p=eventviews.git&a=blobdiff&h=4ae046296e4863b8a2af003c3da5d05e3014473d&hp=6ec8aeb705da8876bac5a796735dc18b009ff472&hb=b8ba0ff8aecd28e97d603bf659cf1c8a0191e291&f=CMakeLists.txt [17:39] which I can't see that we have [17:45] acheronuk: right, those images need testing [17:46] erm, ahoneybun^ [17:46] lol [18:03] who wants to see me dance with a chicken? https://hangouts.google.com/hangouts/_/event/c7qcgbtvn089cm84i6jumg2kplo?hl=en [18:42] awww gosh darnit [18:42] I missed it... [18:42] missed? [18:42] it's still on BBB atm [18:43] !!! [19:11] santa_: thanks, with that I at least don't need to figure that out, just rewrite it in ruby [19:19] yay, I fixed the publication checks, building stuff is failing again \o/ [19:19] :D [19:25] lol "It would very much appear that symbols have been retracted" [19:29] funny enough, akonadi is one of the packages that has -c0 set by default [19:29] which really shouldn't be the case === ghostcube_ is now known as ghostcube [19:30] but yeah, i'll have to disable that check later on ^^ [19:31] others will work though? I did wonder where they went, but thought it must have been by design [19:31] or hm [19:32] acheronuk: no, there was a weird requirement for an i386 buildlog, so that's why they stopped working [19:32] yeah, I saw where you worked that out earlier. [19:33] 19:17:10 KCI-E :: E: libkf5akonadiwidgets5: symbols-file-contains-current-version-with-debian-revision on symbol _ZN7Akonadi19ManageAccountWidget23setDescriptionLabelTextERK7QString@Base [19:33] I can't really disable that though... [19:43] clivejo: please record Rick the next time he says it [19:43] i want it as a ring tone [19:43] * tsimonq2 does it [19:43] ty ;) [19:43] :P [19:44] I have it up in Audacity [19:44] RECORDED [19:46] OMG you are awesome [19:46] can you send it on irc? xD [19:48] hm, figuring if something is for 'stable' or 'unstable' is again complicated by the existence of frameworks :/ [19:49] as those are - by design - only built in unstable [19:49] but are in fact only-stable [19:50] :/ [19:51] jimarvan: soon one sec [19:56] jimarvan: http://picosong.com/Dk8m/ [19:57] lol [19:58] :D [19:59] lol, look at the song metadata [19:59] XD [20:04] guess I'll ditch the QA checks for frameworks for now [20:04] I might bring that back once the metadata for stable is back [20:20] http://picosong.com/DkNh/ [20:20] again, see the song metadata :P [20:22] pmsl [20:38] gn peeps :) [20:39] night Jim [21:04] yofel: so I'm seeing if I can fix that ^ [21:04] yofel: but I'm wondering why it's doing thast [21:04] *that [21:05] tsimonq2: 21:03:41 dpkg-source: info: the patch has fuzz which is not allowed, or is malformed [21:05] I see that, but I'm having trouble actually seeing what the error is [21:05] I'll try some more locally but I don't know... :/ [21:06] fuzz means that parts of the context lines around the patch block have changed [21:06] oh that's helpfuk [21:06] *helpful [21:06] so a simple quilt refresh of the patch should be enough to fix this [21:06] there's a couple of them that I would like to fix [21:06] as long as it still applies with fuzz [21:07] the fuzz check is only applied at build time, not while unpackging and patching the source package [21:07] then it's just a warning [21:08] well I learned something new today, thanks yofel :) [21:09] * yofel deploys experimental code to linode [21:10] if akonadi wasn't building.. [21:12] yofel: what's mgmt? [21:12] tsimonq2: "management" - CI maintenance jobs [21:12] oh okay [21:15] I taking a look now at the YY FIX page with only 17 items, because if those tests work again that is going to fill right back up I think [21:17] ahhhhhhhhhrgh [21:20] whee, I wrote ruby code that actually works \o/ [21:22] * clivejo cheers [21:23] could someone let me know what the *correct* procedure is for fixing fuzz errors? I'm trying but failing miserably... [21:24] or rather, how are patches created (correctly) in the first place? [22:54] anyone about? [22:54] acheronuk: ping [22:55] clivejo: yes, waiting for someone to respond to my question :P [22:55] what's up? [22:55] what was your question [22:55] 04:23:09 PM < tsimonq2> could someone let me know what the *correct* procedure is for fixing fuzz errors? I'm trying but failing miserably... [22:55] 04:24:53 PM < tsimonq2> or rather, how are patches created (correctly) in the first place? [22:56] I dunno what the correct procedure is, but I tend to read the patch and if the lines are out, fix them [22:57] alright [22:57] or create a new patch by manually doing the edits [22:57] good idea [22:57] if its a bit more complicated [22:59] so I would do quilt new Simons_new_ubber_fix.patch [22:59] LOL [22:59] quilt add [22:59] yeah I have a guide somewhere, thanks ;) [22:59] then make the changes [22:59] and so fore [22:59] forth [23:00] tsimonq2: what are you trying to fix in what branch? [23:00] try and keep the original descriptions and headers [23:00] santa_: are .h files usually installed into -dev packages? [23:01] clivejo: usually yes, why? [23:01] got a ton of header files not sure what to do with them [23:02] what package? [23:02] it seems to be a new one [23:02] from pim [23:02] Im building a test package [23:02] yes [23:02] which one? [23:02] its called kdiagram [23:03] is the packaging already on git? [23:03] https://launchpadlibrarian.net/276588091/buildlog_ubuntu-yakkety-amd64.libkf5eventviews_4%3A16.04.3+p16.10+git20160803.1733-0_BUILDING.txt.gz [23:03] cant find it [23:03] libkf5eventviews wants KGanttConfig.cmake [23:03] not in debian either [23:03] this package seems to provide that [23:04] Im just making skeleton packaging to see if it works [23:04] and d you have kgantt packaged? [23:04] * do you [23:05] nvm [23:05] you say it's suposed to be provided by kdiagram, right? [23:09] the eventview devs switched to building with kdiagram for some reason https://quickgit.kde.org/?p=eventviews.git&a=blobdiff&h=4ae046296e4863b8a2af003c3da5d05e3014473d&hp=6ec8aeb705da8876bac5a796735dc18b009ff472&hb=b8ba0ff8aecd28e97d603bf659cf1c8a0191e291&f=CMakeLists.txt [23:11] santa_: yes, its building two libs [23:11] kchart and kgantt [23:12] the 16.08 branch of eventviews still uses the old KF5KDGantt2. so far [23:12] so that shoudl be fine I hope [23:14] santa_: kde-baseapps [23:15] santa_: kubuntu_unstable [23:15] santa_: so don't touch until I'm done please :P [23:15] tsimonq2: I don't have git perms yet, just want to know what are you doing [23:16] oh k :) [23:17] tsimonq2: so it's the enable_debianabimanager.diff what is failing right? [23:18] yeah [23:19] ahhhhhhhh *pulls hair out* [23:19] clivejo: can you please lend me a hand? [23:20] http://kci.pangea.pub/job/yakkety_unstable_kde-baseapps/23/console [23:21] thats the Debian ABI Manager [23:22] basically it added a line or two to the CMakeLists.txt file [23:23] download the source and see whats changed [23:23] its probably just line numbers [23:24] I tried... [23:24] I'll try again... [23:25] that's not the only patch in the series that will fail ;) [23:25] aaaaaaaa [23:26] acheronuk: we'll get there when we get there... :P [23:27] dpkg-source -i --before-build kde-baseapps [23:27] dpkg-source: info: applying enable_debianabimanager.diff [23:27] dpkg-source: info: applying enable_dlrestrictions.diff [23:27] dpkg-source: info: applying kubuntu_folderview_livecd_directory.diff [23:27] dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/kubuntu_folderview_livecd_directory.diff/ --reject-file=- < kde-baseapps/debian/patches/kubuntu_folderview_livecd_directory.diff gave error exit status 1 [23:27] can't find file to patch at input line 10 [23:28] tsimonq2, acheronuk: how can I download the source package? [23:28] or just the orig.tar.xz [23:30] there are snapshot links for .bz2 etc on kde quickgit, or you can do a shallow clone from git and tar it yourself [23:31] or.............. [23:32] santa_: from unstable PPA [23:33] santa_: https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable/+packages?field.name_filter=kde-baseapps&field.status_filter=published&field.series_filter= [23:34] ie https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable/+files/kde-baseapps_16.04.3+p16.10+git20160802.0908.orig.tar.xz [23:34] clivejo: that would be the last source it managed to patch OK though? [23:34] not the newer source snapshot that is failing to patch [23:35] ah yes [23:35] yeah, I got the last one which was built [23:35] (which works) [23:36] gona clone from kde git then if nobody has a better suggestion [23:36] how are you guys doing it? [23:36] the workspace build directory on KCI also contains that last snapshotted source I think? [23:37] http://kci.pangea.pub/job/yakkety_unstable_kde-baseapps/ws/build/ [23:37] but you need to log in to get to that? [23:37] this is true [23:38] aaaargh I need help [23:38] I don't have access to that [23:39] santa_: that was more for tsimonq2 [23:40] tsimonq2: what is the trouble [23:40] acheronuk: I can't get this stupid thing to build [23:40] acheronuk: everything I try doesn't work [23:40] acheronuk: I tried to recreate the patch [23:41] acheronuk: I tried to do it locally, works fine [23:41] acheronuk: I'm struggling [23:42] tsimonq2: so that patch applies locally with quilt, but doesn't when you try to built the source package? [23:42] *build [23:43] acheronuk: I can build the source package fine locally [23:45] against what source? as it should fail on other patches in the series, even if you fix the first one [23:53] acheronuk: I'll try grabbing that git repo then [23:53] *shrug* [23:55] tsimonq2: in your local stuff, can you paste the output of "quilt pop -a && quilt push -a"? [23:59] FINALLY I can locally reproduce it [23:59] tsimonq2: passing an option to fail on fuzz I presume