[14:04] <BluesKaj> Hi folks
[14:08] <santa_> hi BluesKaj 
[14:08] <BluesKaj> hi santa_
[20:04] <RikMills> 5.89.0 embargoed tars are up: https://mail.kde.org/pipermail/release-team/2021-December/012570.html
[20:05] <santa_> hi
[20:05] <RikMills> o/
[20:06] <santa_> RikMills: so let's have look into the sync/merge from debian strategy? (non-vehemence edition™)
[20:07] <RikMills> ok
[20:08] <santa_> so, let's see...
[20:08] <santa_> you have seen the mandalorian right?
[20:10] <RikMills> yep
[20:10] <santa_> for those who didn't, opening scene: https://www.youtube.com/watch?v=9HgRXwMozEY
[20:12]  * RikMills hugs baby yoda
[20:12] <RikMills> well, not actually him, but hey
[20:13] <santa_> so that's a story about an apparently ruthless and brutal man who had a strict religious education and who works in the private sector
[20:15] <santa_> so the thing is: that story "sounds familiar to me"
[20:17] <santa_> just FYI: if you understand how the mandalorian of the TV show operates, you will understand how the flesh and bones mandalorian who is talking to you right now operates
[20:19] <santa_> for example: he does the same things, uses the same knowlegde, uses the same tools, no matter if the work is for money or not
[20:20] <santa_> also he takes into account the cost of things, because he has to
[20:21] <santa_> that's just FYI in case it helps you to understand the way I think a bit better
[20:22] <santa_> do you have any question or may I go on with the technical part?
[20:23] <RikMills> carry on
[20:24] <santa_> ok, so about doing syncs with debian, it's not that it bothers me the fact itself or having a disagreement about it, but the consequences of that
[20:25] <santa_> so, the thing is: if we can deal with the consequences properly, I think I could tolerate it
[20:26] <santa_> so let's see some concerns I expressed about the syncs with debian, I will start with a few minor ones
[20:27] <santa_> 1. when doing a sync the vcs fields get's overriden
[20:28] <santa_> in addition to that, they now changed, the maintainers field, have you noticed?
[20:28] <santa_> * they now changed the maintainers field
[20:29] <RikMills> yes, I was pondering what to do there
[20:30] <santa_> ok, so to fix both problems I suggest to do the following: and in KA code to set the Maintainers and vcs fields for kubuntu when we do a new release
[20:30] <santa_> * add in KA code ...
[20:31] <santa_> this way we would have the fields correctly set for the -XubuntuX packages
[20:32] <RikMills> that is fine with me. the maintainer part mirrors what should be done with 'update-maintainer' for other non KDE things when we make a ubuntuX delta
[20:32] <santa_> if it's synced with debian. on the other hand, they would have the "debianesque" fields
[20:33] <santa_> sure, also there was an original-maintainer or something, let me have a look
[20:33] <RikMills> there is
[20:33] <santa_> https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#What_does_XSBC-Original-Maintainer_mean.3F
[20:33] <santa_> yep
[20:34] <RikMills> so in cases wher I would otherwise be inclined to do a sync, it would be had scripty to make an upload which is mor or less that, BUT with the fields fixed and an ubuntu1
[20:34] <RikMills> *be nice to have
[20:36] <santa_> if you want to do that, we can resurrect the ka-debian2kubuntu-merge or something similar to that
[20:36] <santa_> I guess we can discuss the details maybe other day so we don't lose the big picture?
[20:37] <RikMills> indeed
[20:38] <santa_> ok, so for now I would focus on getting the fields right with gbp-nr, and  let's move on with the discussion...
[20:38] <santa_> another thing that debian syncs have is getting the symbols file overriden
[20:39] <santa_> this is usually not nice, because the c++ symbols files tend to be slightly different with different compilers
[20:39] <santa_> and of course they tend to be a bit different between distributions
[20:40] <santa_> also another thing is the following:
[20:41] <santa_> imagine we have a new bunch of legit symbols (not leaks) in a specific package of frameworks 5.89
[20:41] <santa_> so we update the symbols and we get them into the file with 5.89 version
[20:42] <santa_> now imagine they don't package 5.89 in debian (not the first time that the skip version)
[20:43] <santa_> and then this symbols get added in, let's say frameworks 5.91
[20:43] <RikMills> yes, I am aware of how that goes
[20:44] <santa_> then imagine we sync the symbols file
[20:44] <santa_> we are getting a "worse" symbols file
[20:44] <santa_> ok, not a big tragedy, but imho for packages with symbols files it's better to keep ours
[20:44] <RikMills> I did allow overwrite in some cases. minor differences in arches tested, ordering, minor 1st occurring versions changes that looked no to have an impact
[20:45] <RikMills> but I did in error miss some
[20:45] <santa_> ok, fair enough
[20:46] <santa_> now let me go into the "jewel of the crown"
[20:47] <RikMills> a careful comparison or our and debian's debian folder using meld or similar is usually what I do
[20:48] <RikMills> Note: I used to do that that even with the KA merge scripts
[20:48] <santa_> ok ok
[20:50] <santa_> so the "jewel of the crown": one million dollar question that I have when I do a small fix, like that one in powerdevil is: "are my changes going to be overriden by a debian sync"?
[20:52] <santa_> the one from powerdevil is easy, because it was meant to fix a lintian warning, so executing the thing for the status pages should get you the thing in orange after syncing with debian
[20:53] <santa_> however there might be others more tricky, for example:
[20:54] <santa_> qml dependency on prison for purpose
[20:55] <santa_> I have seen that you kept that, thanks
[20:55] <santa_> however, please note that if you get that overriden, you won't notice in the status page
[20:56] <santa_> because I already added the thing to cmake-ignore.json
[20:58] <RikMills> when I inspected the delta, that was one of the things that meant I did not consider a sync
[20:58] <santa_> my point is: back in the days our strategy to keep these kind of changes was merging from debian's git
[20:59] <santa_> so the strategy now is: inspecting the delta before doing the sync, not doing if we have custom changes, is that correct?
[21:02] <RikMills> yes, but perhaps the other way might be better. i.e. do a test merge, then inspect to see whet might be dropped or needs keeping. if nothing needs keeping, abandon the merge and do a pseudo sync as suggest. or if we need the diff, then carry on with the merge
[21:06] <santa_> ok, well, this was my main concern, I will let you think about that if that's ok with you
[21:07] <santa_> may I move on to the next topic/concern/suggestion?
[21:07] <RikMills> ok. a lot a things are unlikely to need more merging this cycle, so we have time to ponder
[21:08] <RikMills> go ahead
[21:09] <RikMills> I will have to go soon, so please be brief if that is ok
[21:09] <santa_> ok, one suggestion I have is: when doing a big batch of merges/syncs would be possible to do them in a PPA before getting them into the archive
[21:09] <santa_> ?
[21:10] <santa_> like, "we are going to merge all (or almost all) the frameworks", in that case use the staging PPA and the staging branches
[21:11] <santa_> then, after checking the QA push the thing so the archive and the _archive branches?
[21:11] <santa_> s/so the archive/to the archive/
[21:11] <RikMills> fine with me
[21:12] <RikMills> pity you can't access the landing ppas to get riscv64 etc builds done
[21:13] <santa_> ok, using PPAs and _staging branches is very nice, because this way I can discern between warnings "imported from debian" and previous warnings we had
[21:14] <santa_> ok, since you have to leave, let me add a final note:
[21:16] <santa_> I have done today a test rebuild, and I have seen the status pages are green, thank you for that. please note that doing merges from debian tends to increase the number of warnings
[21:16] <santa_> so imho, it would be nice if we could keep some balance between fixing existing warnings and doing things that tend to add more :)
[21:17] <RikMills> it was always my intention to do a full QA run with a PPA. in fact I did that in the ninjas PPA, hence in part the greenishness
[21:18] <santa_> ok, because I was starting to be concerned about that XD
[21:19] <RikMills> I just did it in an out of the PPA that time
[21:20] <RikMills> *out of the way
[21:21] <RikMills> santa_: do you intend to do 5.89?
[21:21] <santa_> RikMills: yep
[21:21] <RikMills> kool
[21:21] <santa_> oh, one thing not related to merges/syncs: do you mind if I update the signing key of some packages in apps and plasma?
[21:22] <santa_> (I would need that to test properly this feature to verify signatures of upstream tarballs)
[21:22] <RikMills> go for it
[21:22] <santa_> as a side effect, it should reduce the delta with debian
[21:23] <santa_> ok, so...
[21:24] <santa_> I'm going to have a 15-30 min walk, then start to do kubuntu stuff before going to bed
[21:24] <santa_> (I've just had dinner before the chat)
[21:28] <RikMills> santa_: ok, and thanks for the discussion
[21:28] <santa_> thank you as well