[00:02] -kubuntu-ci:#kubuntu-devel- Project merger_kdiamond build #618: FAILURE in 54 sec: http://kci.pangea.pub/job/merger_kdiamond/618/
[00:02] -kubuntu-ci:#kubuntu-devel- Project merger_kdesdk-thumbnailers build #108: STILL FAILING in 1 min 18 sec: http://kci.pangea.pub/job/merger_kdesdk-thumbnailers/108/
[00:04] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:04] -kubuntu-ci:#kubuntu-devel- Project merger_kdeconnect-kde build #106: FIXED in 3 min 35 sec: http://kci.pangea.pub/job/merger_kdeconnect-kde/106/
[00:07] -kubuntu-ci:#kubuntu-devel- Project mgmt_merger build #702: STILL UNSTABLE in 6 min 36 sec: http://kci.pangea.pub/job/mgmt_merger/702/
[00:07] -kubuntu-ci:#kubuntu-devel- Project mgmt_progenitor build #688: STILL UNSTABLE in 6 min 37 sec: http://kci.pangea.pub/job/mgmt_progenitor/688/
[00:36] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdesdk-kioslaves build #91: STILL UNSTABLE in 28 min: http://kci.pangea.pub/job/xenial_unstable_kdesdk-kioslaves/91/
[00:36] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kppp build #18: STILL UNSTABLE in 28 min: http://kci.pangea.pub/job/xenial_unstable_kppp/18/
[00:37] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kde-runtime build #222: STILL FAILING in 27 min: http://kci.pangea.pub/job/yakkety_unstable_kde-runtime/222/
[00:37] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kdesdk-kioslaves build #52: STILL UNSTABLE in 28 min: http://kci.pangea.pub/job/yakkety_unstable_kdesdk-kioslaves/52/
[00:37] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kppp build #95: STILL UNSTABLE in 28 min: http://kci.pangea.pub/job/yakkety_unstable_kppp/95/
[00:44] <mhall119> ahoneybun: context?
[00:45] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kopete build #95: STILL UNSTABLE in 37 min: http://kci.pangea.pub/job/xenial_unstable_kopete/95/
[00:46] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kde-runtime build #216: STILL FAILING in 36 min: http://kci.pangea.pub/job/xenial_unstable_kde-runtime/216/
[00:46] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kopete build #72: STILL UNSTABLE in 37 min: http://kci.pangea.pub/job/yakkety_unstable_kopete/72/
[00:54] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kcoreaddons build #273: STILL UNSTABLE in 17 min: http://kci.pangea.pub/job/xenial_unstable_kcoreaddons/273/
[01:02] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_okular build #28: STILL UNSTABLE in 26 min: http://kci.pangea.pub/job/xenial_unstable_okular/28/
[01:03] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kde-runtime build #223: STILL FAILING in 21 min: http://kci.pangea.pub/job/yakkety_unstable_kde-runtime/223/
[01:04] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_okular build #106: STILL UNSTABLE in 26 min: http://kci.pangea.pub/job/yakkety_unstable_okular/106/
[01:04] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kdevelop-pg-qt build #28: STILL UNSTABLE in 27 min: http://kci.pangea.pub/job/yakkety_unstable_kdevelop-pg-qt/28/
[01:04] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kauth build #163: STILL UNSTABLE in 27 min: http://kci.pangea.pub/job/yakkety_unstable_kauth/163/
[01:10] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kde-runtime build #217: STILL FAILING in 19 min: http://kci.pangea.pub/job/xenial_unstable_kde-runtime/217/
[01:10] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kcrash build #284: STILL UNSTABLE in 16 min: http://kci.pangea.pub/job/xenial_unstable_kcrash/284/
[01:10] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kauth build #291: STILL UNSTABLE in 16 min: http://kci.pangea.pub/job/xenial_unstable_kauth/291/
[01:16] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kcrash build #160: STILL UNSTABLE in 13 min: http://kci.pangea.pub/job/yakkety_unstable_kcrash/160/
[01:55] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kwallet build #137: STILL UNSTABLE in 12 min: http://kci.pangea.pub/job/yakkety_unstable_kwallet/137/
[01:56] <tsimonq2> yofel, clivejo, sitter, acheronuk, valorie, santa_: I fixed notifications in #kubuntu-ci when I was poking around. It was entered as "# kubuntu-ci"... :/
[02:29] <tsimonq2> Early bed for me. o/
[02:31] <DarinMiller> o/  night Simon.
[02:35] <valorie> thank you tsimonq2
[02:55] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_ktexteditor build #101: STILL FAILING in 1 min 4 sec: http://kci.pangea.pub/job/yakkety_unstable_ktexteditor/101/
[03:01] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_ktexteditor build #102: STILL FAILING in 46 sec: http://kci.pangea.pub/job/yakkety_unstable_ktexteditor/102/
[03:02] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_ktexteditor build #239: STILL FAILING in 1 min 10 sec: http://kci.pangea.pub/job/xenial_unstable_ktexteditor/239/
[03:08] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_ktexteditor build #240: STILL FAILING in 41 sec: http://kci.pangea.pub/job/xenial_unstable_ktexteditor/240/
[03:15] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_spectacle build #114: STILL UNSTABLE in 11 min: http://kci.pangea.pub/job/xenial_unstable_spectacle/114/
[03:15] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_spectacle build #93: STILL UNSTABLE in 11 min: http://kci.pangea.pub/job/yakkety_unstable_spectacle/93/
[03:20] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_umbrello build #85: STILL UNSTABLE in 18 min: http://kci.pangea.pub/job/yakkety_unstable_umbrello/85/
[03:25] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kstars build #133: STILL UNSTABLE in 23 min: http://kci.pangea.pub/job/yakkety_unstable_kstars/133/
[03:30] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_umbrello build #100: STILL UNSTABLE in 22 min: http://kci.pangea.pub/job/xenial_unstable_umbrello/100/
[03:36] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_okteta build #122: STILL UNSTABLE in 21 min: http://kci.pangea.pub/job/xenial_unstable_okteta/122/
[03:37] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_cantor build #102: STILL UNSTABLE in 17 min: http://kci.pangea.pub/job/yakkety_unstable_cantor/102/
[03:52] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kirigami build #47: STILL UNSTABLE in 21 min: http://kci.pangea.pub/job/yakkety_unstable_kirigami/47/
[03:52] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_plasma-mediacenter build #110: STILL UNSTABLE in 21 min: http://kci.pangea.pub/job/yakkety_unstable_plasma-mediacenter/110/
[03:53] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kstars build #265: STILL UNSTABLE in 44 min: http://kci.pangea.pub/job/xenial_unstable_kstars/265/
[03:53] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_ktp-common-internals build #142: STILL UNSTABLE in 22 min: http://kci.pangea.pub/job/yakkety_unstable_ktp-common-internals/142/
[03:53] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_ktp-common-internals build #216: STILL UNSTABLE in 27 min: http://kci.pangea.pub/job/xenial_unstable_ktp-common-internals/216/
[04:03] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_plasma-integration build #11: STILL UNSTABLE in 11 min: http://kci.pangea.pub/job/yakkety_unstable_plasma-integration/11/
[04:04] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_plasma-sdk build #129: STILL UNSTABLE in 11 min: http://kci.pangea.pub/job/yakkety_unstable_plasma-sdk/129/
[04:04] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_libkcompactdisc build #56: STILL UNSTABLE in 11 min: http://kci.pangea.pub/job/xenial_unstable_libkcompactdisc/56/
[04:09] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_ktp-auth-handler build #143: STILL UNSTABLE in 16 min: http://kci.pangea.pub/job/yakkety_unstable_ktp-auth-handler/143/
[04:09] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_ktp-auth-handler build #190: STILL UNSTABLE in 16 min: http://kci.pangea.pub/job/xenial_unstable_ktp-auth-handler/190/
[04:09] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_cantor build #200: STILL UNSTABLE in 16 min: http://kci.pangea.pub/job/xenial_unstable_cantor/200/
[04:10] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_plasma-mediacenter build #193: STILL UNSTABLE in 17 min: http://kci.pangea.pub/job/xenial_unstable_plasma-mediacenter/193/
[04:10] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kirigami build #43: STILL UNSTABLE in 17 min: http://kci.pangea.pub/job/xenial_unstable_kirigami/43/
[04:15] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_discover build #11: STILL UNSTABLE in 12 min: http://kci.pangea.pub/job/yakkety_unstable_discover/11/
[04:17] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kwin build #22: STILL UNSTABLE in 24 min: http://kci.pangea.pub/job/yakkety_unstable_kwin/22/
[04:22] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_akonadi-calendar build #11: STILL UNSTABLE in 11 min: http://kci.pangea.pub/job/yakkety_unstable_akonadi-calendar/11/
[04:22] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_plasma-sdk build #235: STILL UNSTABLE in 12 min: http://kci.pangea.pub/job/xenial_unstable_plasma-sdk/235/
[04:34] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_akonadi-contacts build #47: STILL UNSTABLE in 19 min: http://kci.pangea.pub/job/xenial_unstable_akonadi-contacts/47/
[04:35] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_plasma-integration build #11: STILL UNSTABLE in 12 min: http://kci.pangea.pub/job/xenial_unstable_plasma-integration/11/
[04:46] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_messagelib build #11: STILL FAILING in 5 min 0 sec: http://kci.pangea.pub/job/yakkety_unstable_messagelib/11/
[04:49] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kwin build #20: STILL UNSTABLE in 27 min: http://kci.pangea.pub/job/xenial_unstable_kwin/20/
[04:56] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_messagelib build #12: STILL FAILING in 4 min 54 sec: http://kci.pangea.pub/job/yakkety_unstable_messagelib/12/
[04:58] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_messagelib build #9: STILL FAILING in 4 min 50 sec: http://kci.pangea.pub/job/xenial_unstable_messagelib/9/
[05:09] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_messagelib build #10: STILL FAILING in 5 min 53 sec: http://kci.pangea.pub/job/xenial_unstable_messagelib/10/
[05:10] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdepim-addons build #82: STILL FAILING in 38 sec: http://kci.pangea.pub/job/xenial_unstable_kdepim-addons/82/
[05:15] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kdepim-addons build #83: STILL FAILING in 36 sec: http://kci.pangea.pub/job/xenial_unstable_kdepim-addons/83/
=== Squt is now known as Sput
[08:09] <jimarvan> good morning :)
[08:11] <acheronuk> morning :)
=== kfunk_ is now known as kfunk
[08:25] <jimarvan> acheronuk: anything exciting? :)
[08:36] <yofel> so I did fall asleep the moment I got home yesterday, bummer. Did anything come out from the meeting?
[08:44] <acheronuk> stuff to think about re: coordinating doing debian merges etc. 
[08:44] <acheronuk> some wondering if it's really worth giving users 5.7 backports at this point when if things go nicely 5.8 would ideally be soon anyway
[08:45] <acheronuk> trying santa's new proposed staging workflow
[08:46] <acheronuk> so more pondering than deciding/doing perhaps, but it always helps to know what others are thinking
[08:47] <acheronuk> jimarvan: nothing startlingly exiting
[08:50] <jimarvan> :)
[08:51] <jimarvan> sounds very reasonable about 5.8
[08:52] <acheronuk> yofel: your input was missed, but things are as they are. I was short of sleep last week, & would have been better catching up sooner than I in the end did
=== Blizzzek is now known as Blizzz
[10:52] <BluesKaj> Hi all
[10:58] <soee_> hiho BluesKaj
[10:58] <BluesKaj> Hi soee_
[11:27] <ahoneybun> mhall119_: context?
[11:44] <ahoneybun> opps with 2 Factor Login for Google I can't use Kmail anymore
[11:53] <yofel> I think it works with an auth key, but I haven't  tried that in years
=== mhall119_ is now known as mhall119
[12:38] <mhall119> ahoneybun: 19:12 < IrcsomeBot> <ahoneybun> I remember mhall sent a email about it but  nothing came from it
[12:54] <jimarvan> BluesKaj: hello (a bit late...)
[12:54] <BluesKaj> hi jimarvan
[12:55] <jimarvan> ahoneybun: I think it never worked with 2 factor?
[12:55] <jimarvan> am I wrong?
[12:59] <clivejo> tsimonq2: it was disabled like that for a reason, I was sorting out stuff with FreeNode so the bot wasnt banned as spammer
[13:02] <yofel> huh? why did that work for harald then?
[13:03] <clivejo> I had to reset the password etc
[13:04] <clivejo> it will work, but the bot needs to log in as a registered nick
[13:04] <clivejo> I think its sorted now, so doesnt make any difference
[13:07] <clivejo> just saying that it was left like that for a reason and not everything needs "fixing"
[13:07] <yofel> aah
[13:08] <clivejo> do we have a private email address for KC or dev?
[13:09] <clivejo> the bot is registered directly to Harold and he has to forward on any emails to admin it
[13:12] <yofel> no
[13:18] <clivejo> ahoneybun: you should be able to use it with twofactor auth
[13:21] <clivejo> you need to enable IMAP access and setup tokens to use as the password
[13:22] <BluesKaj> Hey folks , fwiw check this script out , block ads via dns for debian based OSs, http://www.makeuseof.com/tag/adblock-everywhere-raspberry-pi-hole-way/
[13:23] <clivejo> ahoneybun: https://support.google.com/mail/answer/185833?hl=en
[13:23] <clivejo> https://security.google.com/settings/security/apppasswords
[13:24] <clivejo> Setup Kmail as an "app" then use that token as the password to login via Kmail
[13:25] <clivejo> make sure you give it access to your mail
=== pavlushka is now known as pavlushka_
=== pavlushka_ is now known as pavlushka
=== lordievader_b is now known as lordievader
[15:33] <clivejo> santa_: so the old tooling would move packages with problems into a manual folder, how does your tooling handle thoe?
[15:33] <clivejo> those
[15:35] <santa_> clivejo: they are reported in the end of do-all
[15:36] <clivejo> even packages out of sync with archive?
[15:36] <santa_> you are confusing one thing with another
[15:36] <santa_> one thing is that the package doesn't source-build
[15:37] <santa_> another different one is if it's out of sync with the archive or not
[15:37] <clivejo> Im comparing that the old tooling used to do, compared to what the new tooling does now
[15:38] <santa_> I have in my to-do list a tool to check if the git repositories match the archive, but that's an entirely different problem
[15:39] <clivejo> so the new tooling doesnt look at whats in the archive and wont flag up if someone has, for example done a no change build on something?
[15:39] <santa_> no
[15:40] <clivejo> ok just checking
[15:41] <santa_> !ninjas
[15:41] <ubottu> yofel, clivejo, acheronuk, tsimonq2, santa_: we need your attention!
[15:41] <santa_> before staging anything, please ping me
[15:42] <clivejo> is there anything else we need to know about the process?
[15:43] <IrcsomeBot> <tsimonq2> Wut?
[15:43] <santa_> not very much, but we did some partial work yesterday
[15:44] <santa_> so if we are going to continue I want to be in the "anonshell" like yesterday
[15:44] <clivejo> does your tooling add debian as a remote as default?
[15:47] <santa_> git-clone-all does
[15:47] <santa_> and neon
[15:47] <jimarvan> see ya later peeps :)
[15:48] <santa_> but it may have some glitches, I have various things in mind to improve the new tooling yet
[15:48] <santa_> it's reasonably mature now though
[15:48] <clivejo> so if I'm following your instructions and do do-all git merge debian/master that will work, without any other commands?
[15:48] <santa_> no please, hold on for that
[15:49] <santa_> I have been working on that yesterday and I plan to continue today
[15:49] <clivejo> Im not doing it, Im asking if it would work
[15:49] <santa_> no, it won't
[15:49] <santa_> you will get conflicts for each and every framework
[15:50] <clivejo> due to the VCS fields and so forth
[15:50] <santa_> yes
[15:51] <IrcsomeBot> <acheronuk> so on the eventual debian merges, we will have to divvy those up and work through more or less by hand?
[15:51] <clivejo> Im not in favour of merging with Debian automatically
[15:52] <clivejo> if we are going down that road, just sync the entire frameworks with debian
[15:52] <jimarvan> is it a lot of work to merge with debian manually?
[15:53] <jimarvan> hmm sorry reading what santa said
[15:53] <clivejo> but I would like to think we can get on top of this in the not so distant further and maybe get ahead of debian again
[15:54] <clivejo> future
[15:58] <santa_> <clivejo> if we are going down that road, just sync the entire frameworks with debian
[15:58] <santa_> it's not the same
[15:58] <clivejo> it might as well be
[15:58] <santa_> and also it depends on your definition of "automatically"
[15:59] <clivejo> automatically taking debians packaging and adding a ubuntu1.. at the end of it
[16:00] <clivejo> and changing the VCS to LP, but everything else is the same
[16:02] <IrcsomeBot> <acheronuk> In my head merging with debian mean keeping our packaging, but merging theirs to the exent and purpose of getting rid of unwanted and problematic differences
[16:03] <clivejo> acheronuk: yes but we need some difference sometimes
[16:03] <clivejo> for example that ABI break you found
[16:04] <IrcsomeBot> <acheronuk> yes, and under what I just that they would be 'wanted' and 'not probematic ones'
[16:05] <santa_> merging from debian doesn't mean dropping our changes
[16:06] <santa_> doing a merge it's not copying the contents of one branch to another
[16:06] <santa_> hence why it's not the same than syncing the packages
[16:06] <IrcsomeBot> <acheronuk> no. just redcucing the delta to a minimal level while retaining what we want and need
[16:06] <clivejo> but how do you do that automatically?
[16:06] <santa_> we won't do that automatically
[16:07] <santa_> we will just have an script to pre-process the debian master branch to avoid spurious conflicts
[16:07] <santa_> and we could run that script in do-all
[16:07] <IrcsomeBot> <acheronuk> requires a bit of non-machine inteligence to do correctly/well
[16:08] <santa_> if you want to consider that "automatic" ok
[16:08] <santa_> yes, it would be like provinding a new upstream release, you will need to correct some things manually
[16:10] <clivejo> so whats the point of having kubuntu_unstable and stable branches in this new workflow?
[16:11] <santa_> the same they allways had
[16:13] <clivejo> where are you going to put this specially prepared debian/master branch?
[16:16] <santa_> nowhere, it won't be on the server side
[16:17] <IrcsomeBot> <tsimonq2> Hey yofel, since last time I checked I have to clear vacations with you, I'll be gone from January 9-20 for finals.
[16:17] <IrcsomeBot> <tsimonq2> :P
[17:22] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[17:22] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_ktexteditor build #241: FIXED in 13 min: http://kci.pangea.pub/job/xenial_unstable_ktexteditor/241/
[17:22] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[17:22] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_ktexteditor build #103: FIXED in 13 min: http://kci.pangea.pub/job/yakkety_unstable_ktexteditor/103/
[17:46] <clivejo> ScottK: can you review new Debian packages?
[18:26] <blaze> clivejo: packaging for kdevelop-php is missing. can you clone it from debian?
[18:29] <clivejo> on LP?
[18:29] <blaze> yes
[18:44] -kubuntu-ci:#kubuntu-devel- Starting build #3 for job mgmt_pause_integration (previous build: ABORTED)
[18:50] -kubuntu-ci:#kubuntu-devel- Project mgmt_pause_integration build #3: ABORTED in 5 min 11 sec: http://kci.pangea.pub/job/mgmt_pause_integration/3/
[18:56] <blaze> LP is back to normal (slow mode) I guess
[18:59] <clivejo> blaze: we had no branches on Debian
[18:59] <clivejo> so I have created xenial and yakkety branches with whats in the archive
[18:59] <clivejo> https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/kdevelop-php
[18:59] <clivejo> and then merged master into yakkety_archive to create unstable
[19:00] <clivejo> are you packaging it?
[19:01] <blaze> clivejo: do you mean at kubuntu? I'll look what I can do here.
[19:01] <clivejo> yes, I want to get kdevelop into zesty
[19:01] <clivejo> kci is building it
[19:02] <clivejo> but not those plugins
[19:02] <blaze> are some builds failing?
[19:02] <clivejo> http://kci.pangea.pub/search/?q=kdevelop
[19:03] <clivejo> no seems build last time it was run
[19:03] <clivejo> blaze: you know about the team Ovi setup?
[19:03] <blaze> no
[19:03] <clivejo> https://launchpad.net/~kdevelop
[19:04] <clivejo> the wishlist is for KCI to build it daily and copy the packages over to that PPA
[19:04] <clivejo> and have uptodate releases as well
[19:05] <clivejo> I was going to update to 5.0.2 but had issues with our tooling
[19:06] <clivejo> I also want to get 5.x uploaded into zesty
[19:09] <blaze> will it be synced from debian? I see 5.0.1 is already in stretch
[19:10] <blaze> and plugins are here as well
[19:12] <clivejo> I think we sync'ed from debian and some cherry picking from Neon
[19:13] <clivejo> for the 5.0.1 packages in the PPA
[19:13] <clivejo> Ovi was working on it at Akademy
[19:18] <blaze> okay, got it
[19:19] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kauth build #164: STILL UNSTABLE in 18 min: http://kci.pangea.pub/job/yakkety_unstable_kauth/164/
[19:19] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[19:19] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_breeze-icons build #295: FIXED in 18 min: http://kci.pangea.pub/job/xenial_unstable_breeze-icons/295/
[19:19] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kcoreaddons build #274: STILL UNSTABLE in 18 min: http://kci.pangea.pub/job/xenial_unstable_kcoreaddons/274/
[19:19] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[19:19] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_breeze-icons build #182: FIXED in 18 min: http://kci.pangea.pub/job/yakkety_unstable_breeze-icons/182/
[19:25] <acheronuk> clivejo: can't get back onto BBB: Error: createMeeting() failed Error internalError: Net::ReadTimeout
[19:26] <clivejo> seems to be ded
[19:26] <clivejo> bead
[19:26] <clivejo> dead
[19:31] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kcrash build #161: STILL UNSTABLE in 9 min 51 sec: http://kci.pangea.pub/job/yakkety_unstable_kcrash/161/
[19:31] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kcrash build #285: STILL UNSTABLE in 12 min: http://kci.pangea.pub/job/xenial_unstable_kcrash/285/
[19:31] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kauth build #292: STILL UNSTABLE in 12 min: http://kci.pangea.pub/job/xenial_unstable_kauth/292/
[19:35] <acheronuk> still dead here for BBB
[19:36] <clivejo> Im back on
[19:38] <blaze> I think I'm missing something
[19:39] <clivejo> santa_: when we run gbp-nr, what should the changelog entry be dated as?
[19:39] <santa_> clivejo: it should pick the current date
[19:40] <clivejo> The old script dated it as current date, new script seems to be whatever the changelog was
[19:46] <acheronuk> ha! I just found that remove duplicates patch....
[19:47] <clivejo> Ive just uploaded that
[19:48] <acheronuk> yes. found it on debian, then saw you had already got there.
[19:48] <acheronuk> just checked 3 random changelogs, and a dates are correct as today.
[19:49] <clivejo> why it not do it for breeze?
[19:50] <acheronuk> santa_: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/breeze-icons/commit/?h=kubuntu_zesty_archive&id=d66e1b8f2b94a6536f10cb7127b08465063aefc8
[19:51] <santa_> because they changelog block already existed
[19:52] <santa_> * the
[19:53] <acheronuk> another: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/kcoreaddons/commit/?h=kubuntu_zesty_archive&id=0a99dc7c564d8cc99d0106351bdcd1f24c8d3d5a
[19:53] <clivejo> should the staging not override that to current date/time?
[19:54] <clivejo> it should also override the packager too
[19:55] <santa_> well, you have a very particular point of view on the changelog trailers
[19:55] <santa_> according to acheronuk last time we discussed this the changelog trailer "should be the person who started the work" (sic)
[19:56] <santa_> and you seemed to agree
[19:56] <clivejo> in the case of archive upload
[19:56] <santa_> accroding to me I think there isn't any single official document from debian or ubuntu stating that that should be the convention
[19:57] <santa_> and also according to me the changelog trailer should be overriden once the package is uploaded
[19:57] <santa_> with the name of the uploader and the current date
[19:58] <santa_> which is what dch --release does byt the way
[19:58] <santa_> s/byt/by/
[19:58] <santa_> s/accoding/according/
[19:58] <acheronuk> this for example is misleading: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/kcoreaddons/tree/debian/changelog?h=kubuntu_zesty_archive
[19:59] <santa_> and where is the mislead exactly?
[19:59] <clivejo> it also messes up when we try to merge debian due to being searched by date
[19:59] <clivejo> I didnt stage 5.27
[19:59] <clivejo> rik did
[20:00] <clivejo> and it needs to record that in the changelog
[20:00] <clivejo> as well as the date he did it
[20:01] <santa_> don't you realize that you are inventing on the fly, and completely on your own, a new custom convention for changelogs that isn't documented and that isn't followed anywhere else on debian and ubuntu?
[20:02] <santa_> what does dch --release does?
[20:02] <clivejo> Im not inventing anything, Im passing on what the old tooling did
[20:02] <acheronuk> oh, wait, you did the CVE patch removal in unstable, so maybe that one is fair enough.
[20:04] <clivejo> when I merged breeze with debian the changelog moved our entry down to second
[20:04] <clivejo> because of the date
[20:05] <IrcsomeBot> <tsimonq2> Hai
[20:05] <santa_> if that's correct, we could update the trailer when calling gbp-nr
[20:05] <santa_> for the merge's sake
[20:06] <santa_> but otherwise the trailer shouldn't be touched (to make git commit revert) easier to work
[20:07] <santa_> and finally when uploading the package the changelog trailer should be updated again with the name of the uploader and the current date
[20:07] <santa_> (... which is one of the actual conventions from debian/ubuntu)
[20:08] <santa_> therefore what was in the changelog trailer was "irrelevant"
[20:10] <santa_> clivejo: about your point about not breaking the merges with debian, why do you think the merge driver sorts it by date?
[20:10] <santa_> because I would bet it does it by version number
[20:13] <santa_> (in other words, updating the date in the changelog trailer won't fix the issue (according to my bet))
[20:13] <santa_> when doing gbp-nr I mean
[20:15] -kubuntu-ci:#kubuntu-devel- Project xenial_unstable_kwallet build #299: STILL UNSTABLE in 12 min: http://kci.pangea.pub/job/xenial_unstable_kwallet/299/
[20:17] -kubuntu-ci:#kubuntu-devel- Project yakkety_unstable_kwallet build #138: STILL UNSTABLE in 15 min: http://kci.pangea.pub/job/yakkety_unstable_kwallet/138/
[20:18] <clivejo> Im not arguing any more, all I know is the way we used to do it, it worked for years that way.  Why is was done this way I have no idea, it was decided by far smarter people than I
[20:18] <acheronuk> clivejo: I can see the issue with kwayland. some new symbols introduced after 5.27 that we've updated unstable for, but which clearly are not known in just 5.27
[20:20] <acheronuk> bound to get a few problems like that were 'unstable' packaging had got ahead of 5.27
[20:23] <santa_> what is the issue with kwayland?
[20:25] <acheronuk> santa_: as I said above. 5.27 was released on October 8th, but since then kwayland devs have made changes giving new symbols, which have been accounted for on unstable/CI
[20:25] <valorie> earlier I noticed: [18:28] [Notice] -queuebot to #ubuntu-release- New binary: libdrumstick [ppc64el] (zesty-proposed/universe) [1.0.2-1] (no packageset)
[20:26] <valorie> not sure why that is not in our packageset
[20:26] <valorie> later it was accepted
[20:26] <acheronuk> santa_: so building 5.27 with that merged packaging shows them as gone missing where in fact on 5.27 they don't exist yet
[20:27] <santa_> ok
[20:27] <santa_> acheronuk: have you staged 5.27 already?
[20:31] <santa_> hmm, about the previous discussion....
[20:32] <santa_>  <santa_> because I would bet it does it by version number
[20:32] <santa_> https://lintian.debian.org/tags/latest-debian-changelog-entry-without-new-version.html
[20:33] <santa_> yes, there's even a lintian warning, so when merging changelogs the entries will be sorted by date, for sure
[20:33] <santa_> so to avoid having the debian changelog block on top of ours we must increase the version number, not the date
[20:34] <acheronuk> santa_: retry builds has changed so it guesses the ppa, correct?
[20:34] <santa_> acheronuk: yes
[20:34] <santa_> acheronuk: but have you staged 5.27 already or not?
[20:35] <acheronuk> santa_: so how would I run that against a ppa that isn't the staging one?
[20:35] <acheronuk> yes
[20:35] <acheronuk> on the old version I could do that
[20:36] <IrcsomeBot> <tsimonq2> Get me up to speed?
[20:38] <IrcsomeBot> <acheronuk> @tsimonq2, faster faster
[20:38] <santa_> clivejo: regarding the "it's mislealing point", the actual ppa packages have the changelog trailer updated, the clones aren't updated, that's what gbp-nr and gbp-ppa does. not arguing, just explaining
[20:38] <IrcsomeBot> <tsimonq2> What's been going on?
[20:38] <IrcsomeBot> <tsimonq2> Progress report? Where can I help?
[20:39] <santa_> clivejo: now arguing a bit again I think we should change again that dch call in gbp-archive
[20:40] <santa_> (to update the changelog trailer to the person doing the upload)
[20:40] <acheronuk> santa_: that would be highly misleading
[20:40] <santa_> that is the actual convetion
[20:41] <IrcsomeBot> <ahoneybun> valorie I'd like to be more active in Code-in this year
[20:41] <santa_> "highly misleading" is inventing on the fly your own convention
[20:41] <IrcsomeBot> <ahoneybun> Any junior jobs can you throw them my way?
[20:41] <santa_> which is what we are doing now
[20:41] <santa_> Simon, than kajongg bug?
[20:42] <acheronuk> you can argue the toss on who should be on the trailer for earlier work, but changing to to whatever random person happens to just run the script to package up the upload is certainly misleading
[20:43] <santa_> ... according to you
[20:44] <santa_> so who should be on the changelog trailer on the final upload to the archive according to you?
[20:47] <santa_> I have three possible reasonable values
[20:48] <santa_> a) the person who prepared the upload with gbp-nr
[20:48] <santa_> b) Kubuntu Developers <kubuntu-devel@lists.ubuntu.com>
[20:48] <santa_> c) Kubuntu Automation <kubuntu-devel@lists.ubuntu.com>
[20:53] <santa_> acheronuk: any preference on ny of the above?
[20:54] <santa_> a) has a good thing, it makes the package signing easier
[20:54] <acheronuk> until now it would the person who did the initial staging, so (a). but you proposed then replacing that again to whatever person happens to put together the archive sources
[20:55] <santa_> b) and c) has the advantage that we would get the ftbfs'es mails on the mailing lists
[20:56] <santa_> and let's index d) the person who did the initial staging
[20:57] <santa_> there's also an advantage in a) and it's that the person who did the upload would get possible rejection mails and such
[20:57] <santa_> (I think)
[20:57] <santa_> d) doesn't have any advantage
[20:58] <acheronuk> signing is a bit of a non issue, as you either prepare ppa packages which are independent of the git trailer. or the devopler uploader either does then or resigns
[20:59] <santa_> it's not when running gbp-archive
[20:59] <santa_> it is when running gbp-archive
[20:59] <santa_> it's not when running gbp-ppa, +1 on what you said
[21:00] <santa_> acheronuk: what about b) or c)
[21:00] <acheronuk> there is not reason why gpb-archive must always sign them
[21:01] <santa_> but when it does, it's easier if the person doing the upload is in the trailer
[21:03] <acheronuk> not that much easier, and it's certainly not really good reason to take over other people's changelog entries
[21:04] <santa_> the signing it won't fail - the other way it may or may not
[21:04] <santa_> and you aren't taking over anything, you are preparing the upload using gbp-archive and therefore you put yourself in the trailer
[21:05] <acheronuk> either (1) you are preparing the upload for another dev to upload, in which case they would have to force resign them again anyway. or (2) you are doing them for yourself in which case you are either already there, or can just do as (1)
[21:05] <santa_> like the actual convention says
[21:06] <acheronuk> and yes, it is taking over the entry for no other reason than a spurious cause
[21:06] <santa_> (1) is true
[21:06] <santa_> (2) is not
[21:07] <acheronuk> (2) is true
[21:08] <santa_> no it's not, if you are doing it for yourself it will work out of the box if you have your signing key in the host where you are running gbp-archive
[21:08] <santa_> if you don't touch the changelog trailer it may work or not
[21:09] <santa_> and no, you aren't taking over anything
[21:09] <acheronuk> no, that would involved taking over the trailer entries, which is the thing which we are saying was not and should not be done.
[21:09] <santa_> please give me a link to any official documentation saying that what you say is the actual official convention
[21:10] <santa_> and well "should not be done" is what you say
[21:10] <santa_> according to your invented-on-the-fly convention
[21:12] <acheronuk> it is the convention kubuntu has been working by, and makes the best sense out of what is an imperfect set of options
[21:12] <santa_> it was what the old tooling was doing
[21:12] <santa_> there isn't any actual convention
[21:13] <santa_> even clive said himself he was just pointing out what the old tooling was doing
[21:14] <acheronuk> yes, and what it did is basically the option the makes best sense out what is a imperfect set of possibilities.
[21:15] <santa_> no, it's not
[21:15] <santa_> and please read the actual conventions
[21:15] <santa_> http://pkg-kde.alioth.debian.org/changelogstandard.html
[21:15] <santa_> just scroll to 3)
[21:16] <santa_> There are two reasons for this: it will update the trailer and distribution (UNRELEASED to the previously used one) and it will update the mainttrailer to whoever uploads the package (who might even not be listed as a committer in the changelog).
[21:16] <santa_> AND
[21:17] <santa_> 4.4 Debian changelog: debian/changelog
[21:17] <santa_> https://www.debian.org/doc/debian-policy/ch-source.html
[21:18] <santa_> "The maintainer name and email address used in the changelog should be the details of the person who prepared this release of the package. They are not necessarily those of the uploader or usual package maintainer."
[21:19] <santa_> it would be very funny to find any reference in the debian policy to "the person who did the initial staging"
[21:20] <santa_> too bad the old KA tooling didn't followed the actual conventions
[21:20] <santa_> * didn't follow XD
[21:21] <acheronuk> not the same as whatever random person gets told to run gbp-achive though. and quite honestly, the way is has been done the best sense for me for attribution. 
[21:22] <acheronuk> so I stick by what I said and reasoning
[21:23] <santa_> so "the random person it was told to run gbp-nr" is much better according to your common sense
[21:23] <santa_> and because of that theorical stubborness we won't get any of the advantages of a) b) and c)
[21:23] <santa_> great
[21:24] <acheronuk> sorry, we going to have to agree to disagree for tonight I think :)
[21:25] <santa_> zero reasoning. whatever, if you want to change the way the changelog trailers are handled in KA, do it yourseld
[21:26] <santa_> I'm not wasting a single minute of my time in following a convention which you just invented on the fly and written nowhere
[21:28] <santa_> s/yourseld/yourself/
[22:33] <acheronuk> grr... broadband just died for at least 20 mins
[22:33]  * acheronuk needs fibre
[22:40] <mparillo> I switched from Coax to FTTP, and if it were up to me, it would be a serious consideration in any house-hunt.
[23:49] <tsimonq2> !info taglib unstable
[23:49] <ubottu> Package taglib does not exist in unstable
[23:49] <tsimonq2> !info libtagc0-dev unstable
[23:49] <ubottu> libtagc0-dev (source: taglib): audio meta-data library - development files for C bindings. In component main, is optional. Version 1.11.1-0.1 (unstable), package size 25 kB, installed size 69 kB
[23:49] <tsimonq2> !info libtagc0-dev zesty
[23:49] <ubottu> libtagc0-dev (source: taglib): audio meta-data library - development files for C bindings. In component main, is optional. Version 1.9.1-2.4ubuntu1 (zesty), package size 12 kB, installed size 63 kB
[23:50] <IrcsomeBot> <ahoneybun> Is that unstable debian Sid?
[23:53] <tsimonq2> Yep.
[23:54] <IrcsomeBot> <ahoneybun> K