=== genii is now known as genii-core [14:04] Hi folks [14:08] hi BluesKaj [14:08] hi santa_ [20:04] 5.89.0 embargoed tars are up: https://mail.kde.org/pipermail/release-team/2021-December/012570.html [20:05] hi [20:05] o/ [20:06] RikMills: so let's have look into the sync/merge from debian strategy? (non-vehemence edition™) [20:07] ok [20:08] so, let's see... [20:08] you have seen the mandalorian right? [20:10] yep [20:10] for those who didn't, opening scene: https://www.youtube.com/watch?v=9HgRXwMozEY [20:12] * RikMills hugs baby yoda [20:12] well, not actually him, but hey [20:13] 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] so the thing is: that story "sounds familiar to me" [20:17] 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] 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] also he takes into account the cost of things, because he has to [20:21] that's just FYI in case it helps you to understand the way I think a bit better [20:22] do you have any question or may I go on with the technical part? [20:23] carry on [20:24] 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] so, the thing is: if we can deal with the consequences properly, I think I could tolerate it [20:26] so let's see some concerns I expressed about the syncs with debian, I will start with a few minor ones [20:27] 1. when doing a sync the vcs fields get's overriden [20:28] in addition to that, they now changed, the maintainers field, have you noticed? [20:28] * they now changed the maintainers field [20:29] yes, I was pondering what to do there [20:30] 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] * add in KA code ... [20:31] this way we would have the fields correctly set for the -XubuntuX packages [20:32] 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] if it's synced with debian. on the other hand, they would have the "debianesque" fields [20:33] sure, also there was an original-maintainer or something, let me have a look [20:33] there is [20:33] https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#What_does_XSBC-Original-Maintainer_mean.3F [20:33] yep [20:34] 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] *be nice to have [20:36] if you want to do that, we can resurrect the ka-debian2kubuntu-merge or something similar to that [20:36] I guess we can discuss the details maybe other day so we don't lose the big picture? [20:37] indeed [20:38] 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] another thing that debian syncs have is getting the symbols file overriden [20:39] this is usually not nice, because the c++ symbols files tend to be slightly different with different compilers [20:39] and of course they tend to be a bit different between distributions [20:40] also another thing is the following: [20:41] imagine we have a new bunch of legit symbols (not leaks) in a specific package of frameworks 5.89 [20:41] so we update the symbols and we get them into the file with 5.89 version [20:42] now imagine they don't package 5.89 in debian (not the first time that the skip version) [20:43] and then this symbols get added in, let's say frameworks 5.91 [20:43] yes, I am aware of how that goes [20:44] then imagine we sync the symbols file [20:44] we are getting a "worse" symbols file [20:44] ok, not a big tragedy, but imho for packages with symbols files it's better to keep ours [20:44] 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] but I did in error miss some [20:45] ok, fair enough [20:46] now let me go into the "jewel of the crown" [20:47] a careful comparison or our and debian's debian folder using meld or similar is usually what I do [20:48] Note: I used to do that that even with the KA merge scripts [20:48] ok ok [20:50] 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] 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] however there might be others more tricky, for example: [20:54] qml dependency on prison for purpose [20:55] I have seen that you kept that, thanks [20:55] however, please note that if you get that overriden, you won't notice in the status page [20:56] because I already added the thing to cmake-ignore.json [20:58] when I inspected the delta, that was one of the things that meant I did not consider a sync [20:58] my point is: back in the days our strategy to keep these kind of changes was merging from debian's git [20:59] so the strategy now is: inspecting the delta before doing the sync, not doing if we have custom changes, is that correct? [21:02] 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] ok, well, this was my main concern, I will let you think about that if that's ok with you [21:07] may I move on to the next topic/concern/suggestion? [21:07] ok. a lot a things are unlikely to need more merging this cycle, so we have time to ponder [21:08] go ahead [21:09] I will have to go soon, so please be brief if that is ok [21:09] 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] ? [21:10] 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] then, after checking the QA push the thing so the archive and the _archive branches? [21:11] s/so the archive/to the archive/ [21:11] fine with me [21:12] pity you can't access the landing ppas to get riscv64 etc builds done [21:13] 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] ok, since you have to leave, let me add a final note: [21:16] 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] 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] 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] ok, because I was starting to be concerned about that XD [21:19] I just did it in an out of the PPA that time [21:20] *out of the way [21:21] santa_: do you intend to do 5.89? [21:21] RikMills: yep [21:21] kool [21:21] 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] (I would need that to test properly this feature to verify signatures of upstream tarballs) [21:22] go for it [21:22] as a side effect, it should reduce the delta with debian [21:23] ok, so... [21:24] I'm going to have a 15-30 min walk, then start to do kubuntu stuff before going to bed [21:24] (I've just had dinner before the chat) [21:28] santa_: ok, and thanks for the discussion [21:28] thank you as well