| === genii is now known as genii-core | ||
| BluesKaj | Hi folks | 14:04 |
|---|---|---|
| santa_ | hi BluesKaj | 14:08 |
| BluesKaj | hi santa_ | 14:08 |
| RikMills | 5.89.0 embargoed tars are up: https://mail.kde.org/pipermail/release-team/2021-December/012570.html | 20:04 |
| santa_ | hi | 20:05 |
| RikMills | o/ | 20:05 |
| santa_ | RikMills: so let's have look into the sync/merge from debian strategy? (non-vehemence edition™) | 20:06 |
| RikMills | ok | 20:07 |
| santa_ | so, let's see... | 20:08 |
| santa_ | you have seen the mandalorian right? | 20:08 |
| RikMills | yep | 20:10 |
| santa_ | for those who didn't, opening scene: https://www.youtube.com/watch?v=9HgRXwMozEY | 20:10 |
| * RikMills hugs baby yoda | 20:12 | |
| RikMills | well, not actually him, but hey | 20:12 |
| 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:13 |
| santa_ | so the thing is: that story "sounds familiar to me" | 20:15 |
| 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:17 |
| 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:19 |
| santa_ | also he takes into account the cost of things, because he has to | 20:20 |
| santa_ | that's just FYI in case it helps you to understand the way I think a bit better | 20:21 |
| santa_ | do you have any question or may I go on with the technical part? | 20:22 |
| RikMills | carry on | 20:23 |
| 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:24 |
| santa_ | so, the thing is: if we can deal with the consequences properly, I think I could tolerate it | 20:25 |
| santa_ | so let's see some concerns I expressed about the syncs with debian, I will start with a few minor ones | 20:26 |
| santa_ | 1. when doing a sync the vcs fields get's overriden | 20:27 |
| santa_ | in addition to that, they now changed, the maintainers field, have you noticed? | 20:28 |
| santa_ | * they now changed the maintainers field | 20:28 |
| RikMills | yes, I was pondering what to do there | 20:29 |
| 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:30 |
| santa_ | this way we would have the fields correctly set for the -XubuntuX packages | 20:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 |
| RikMills | indeed | 20:37 |
| 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:38 |
| 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:39 |
| santa_ | also another thing is the following: | 20:40 |
| 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:41 |
| santa_ | now imagine they don't package 5.89 in debian (not the first time that the skip version) | 20:42 |
| 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:43 |
| 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:44 |
| RikMills | but I did in error miss some | 20:45 |
| santa_ | ok, fair enough | 20:45 |
| santa_ | now let me go into the "jewel of the crown" | 20:46 |
| RikMills | a careful comparison or our and debian's debian folder using meld or similar is usually what I do | 20:47 |
| RikMills | Note: I used to do that that even with the KA merge scripts | 20:48 |
| santa_ | ok ok | 20:48 |
| 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:50 |
| 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:52 |
| santa_ | however there might be others more tricky, for example: | 20:53 |
| santa_ | qml dependency on prison for purpose | 20:54 |
| 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:55 |
| santa_ | because I already added the thing to cmake-ignore.json | 20:56 |
| 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:58 |
| santa_ | so the strategy now is: inspecting the delta before doing the sync, not doing if we have custom changes, is that correct? | 20:59 |
| 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:02 |
| santa_ | ok, well, this was my main concern, I will let you think about that if that's ok with you | 21:06 |
| 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:07 |
| RikMills | go ahead | 21:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| RikMills | pity you can't access the landing ppas to get riscv64 etc builds done | 21:12 |
| 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:13 |
| santa_ | ok, since you have to leave, let me add a final note: | 21:14 |
| 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:16 |
| 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:17 |
| santa_ | ok, because I was starting to be concerned about that XD | 21:18 |
| RikMills | I just did it in an out of the PPA that time | 21:19 |
| RikMills | *out of the way | 21:20 |
| 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:21 |
| 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:22 |
| santa_ | ok, so... | 21:23 |
| 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:24 |
| RikMills | santa_: ok, and thanks for the discussion | 21:28 |
| santa_ | thank you as well | 21:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!