Bug#1068951: new upstream (6.x)
Hey, quick update on 6.x. There are currently some cleanups and reorganization happening in Knot Resolver master, such as: - https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1577 - https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1598 These are going to change locations of various things so it's better to wait for those with experimental packaging. After these cleanups are complete, I plan go one more round of upstream Debian packaging cleanup before 6.0.9 release and then I'd like to release Debian experimental package. Furthermore, quite a few users of our upstream repos at https://pkg.labs.nic.cz reported various issues when with upgrading to v6 packages that weren't renamed to knot-resolver6. These proved that it's desired for users to rename v6 packages to knot-resolver6* - that's already done upstream with 6.0.8 and I intend to use the 6 postfix for Debian trixie as well unless someone provides convincing reasons not to. I'd leave the source package (and salsa repo) name at knot-resolver, but binary packages will be knot-resolver6, knot-resolver6-module-http, etc. At least for the time being, hopefully returning to knot-resolver eventually in the future. There is sadly no upgrade path from v5 to v6, thus the packages must not share same names. It's not acceptable for a Debian package to break on dist-upgrade. Cheers, Jakub Ružička
Bug#1068951: new upstream (6.x)
On 6/12/24 13:33, Jakub Ružička wrote: I did what I could with the upstream packaging, so now it's your turn with debian/experimental, Daniel, if you have the time :) thanks for all the work - I will have a time for everything this Friday afternoon/evening and will report back. Regards, Daniel
Bug#1068951: new upstream (6.x)
Hey Daniel, I did a spring cleaning in upstream debian packaging (distro/pkg/deb), merging -core and -manager into knot-resolver6, porting most of your debian/experimental patches, and removing many lintian warnings. This was done in upstream MRs now merged into `master` branch (which is now v6, `master-5` is for v5). For your convenience, here's a link to upstream debian dir distro/pkg/deb: https://gitlab.nic.cz/knot/knot-resolver/-/tree/master/distro/pkg/deb The upstream package was renamed to knot-resolver6 in order to prevent unwanted upgrades as there is sadly no upgrade path from v5 to v6. Users were already complaining about such issues with shared v5 & v6 upstream repos and the situation will be equivalent on bookworm -> trixie update so I suggest using that (knot-resolver6) in Debian packaging as well. Debian in particual is expected not to break working systems on upgrade and I don't see a way to ensure that without knot-resolver6 rename. Remaining issues: * debian: adduser -> useradd patch doesn't create knot-resolver group as it should * debian: package should be renamed to knot-resolver6 (?) * debian: python modules must be properly installed (see upstream d/rules) * upstream: meson / ninja is invoked manually as opposed to dh_auto_* because I don't know how to properly refernce meson build dir I did what I could with the upstream packaging, so now it's your turn with debian/experimental, Daniel, if you have the time :) Feel free to sync what you think is good, do the knot-resolver6 rename (or not, I'm still not 100 % decided there), properly use dh_auto_* (if you know how to reference meson builddir in d/rules) or whatever you see fit. After that I'll go one more round of upstream <-> debian sync, hunt some more lintian warnings, and finally release the debian/experimental package. Cheers, Jakub signature.asc Description: PGP signature
Bug#1068951: new upstream (6.x)
Yo Santiago (CC'd), could you please drop your opinion on this for extra reference? On 4/30/24 18:34, Daniel Baumann wrote: Hi, On 4/30/24 18:12, Jakub Ružička wrote: Secondary reason for that was that there is no upgrade path from 5.x to 6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6. For that, the package probably needs a different name (like knot-resolver6) imho this should be handled in the package (e.g. by showing a debconf note or so) and be included in the trixie release notes. renaming the binary package doesn't really solve much and is more suited for (library) transitions, i.e. if there were several knot-resolver-module-* packages or so. We currently have v5 and v6 packages in a single knot-resolver repo on pkg.labs.nic.cz and v5 users are safe to `apt update` from the repo without breaking their setup or they can `apt install knot-resolver6` to upgrade. This would apply to Bookworm -> Trixie transition as well. If there was no distinction between v5 and v6 packages, unwanted updates leading into broken setups are bound to happen, that's not very user friendly. I could split the upstream repos (knot-resolver5, knot-resolver6), but that won't solve Bookworm -> Trixie case. OTOH knot-resolver6 fork is extra maintenance (new source package & Salsa repo...) and an unwanted irregularity although it gets the job done. This was the case for bird2 and upcoming bird3 for example, which also isn't a library. also (I haven't looked at it), is it worthwile to (with users consent) to "try" to guess with (some parts of) the old config to generate the new config from? I don't think that's worthwhile, that's why it's not officially supported. So what do you suggest? generally, the amount of binary packages should be limited to a minimum - oiow there needs to be a reason why an additional binary package is added. some of them are: * saving relative excessive amount of diskspace (e.g. large documentation can be split into a -doc package) * different parts have different dependencies and/or particulary long dependency chains (e.g. gtk parts of a cli tool) therefore, imho the following binary packages make sense here: * knot-resolver * knot-resolver-doc * knot-resolver-module-dnstap * knot-resolver-module-http Consulting with upstream, there doesn't seem to be a strong reason not to merge like that. Separating the python module(s) in a sub-package could be useful in some (official unsupported edge) cases like containers where pulling the extra python deps might increase the image size significantly. I believe vast majority of users will use the manager so it's desirable to install it by default, which would be 100 % ensured by having it a part of knot-resolver package, so that's a plus. Those who want to use kresd without manager can simply disable manager and do what they want at the cost of some unused python deps. I don't think that's too bad of a compromise. So I'm generally in favor of merging the -manager package, I'm just worried about unwanted upgrades if we don't change the name (knot-resolver6) as there isn't really an upgrade path. Such is the price of progress. Note that Fedora policies/customs are strongly in favor of not forking per-version - in line of what you suggest. Note that -dbg packages are generated automatically and don't need to be specified in control (I'll provide a commit for that). Oh, right :) Cheers, Jakub
Bug#1068951: new upstream (6.x)
Hi, On 4/30/24 18:12, Jakub Ružička wrote: Secondary reason for that was that there is no upgrade path from 5.x to 6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6. For that, the package probably needs a different name (like knot-resolver6) imho this should be handled in the package (e.g. by showing a debconf note or so) and be included in the trixie release notes. renaming the binary package doesn't really solve much and is more suited for (library) transitions, i.e. if there were several knot-resolver-module-* packages or so. also (I haven't looked at it), is it worthwile to (with users consent) to "try" to guess with (some parts of) the old config to generate the new config from? So what do you suggest? generally, the amount of binary packages should be limited to a minimum - oiow there needs to be a reason why an additional binary package is added. some of them are: * saving relative excessive amount of diskspace (e.g. large documentation can be split into a -doc package) * different parts have different dependencies and/or particulary long dependency chains (e.g. gtk parts of a cli tool) therefore, imho the following binary packages make sense here: * knot-resolver * knot-resolver-doc * knot-resolver-module-dnstap * knot-resolver-module-http Note that -dbg packages are generated automatically and don't need to be specified in control (I'll provide a commit for that). Regards, Daniel
Bug#1068951: new upstream (6.x)
On 4/29/24 21:13, Daniel Baumann wrote: On 4/29/24 19:50, Daniel Baumann wrote: pushing to the repo requires me to be added to the salsa project.. would you mind adding me? in the meantime, I've pushed to here: https://git.progress-linux.org/users/daniel.baumann/debian/todo/knot-resolver/log/ Nice! before I'll continue: what's the idea of adding knot-resolver-manager binary package? I can't think of a reason why one would use kresd (knot-resolver-core) without the manager, and thus, would fold knot-resolver-manager and knot-resolver-core (back) into knot-resolver. But probably I'm missing something.. That is a great question and in fact the primary topic I wanted some other DD to review. You basically answered that already, but let me elaborate why it's like this. Manager was initially developed in a separate repo imported into kresd as a git submodule and it wasn't clear back then how integrated / optional / required it will be. Manager is now quite integrated in kresd and while it's theoretically possible to use knot-resolver-core without knot-resolver-manager, this isn't officially supported and generally a use case probably not worth supporting. Secondary reason for that was that there is no upgrade path from 5.x to 6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6. For that, the package probably needs a different name (like knot-resolver6) so I made this little trick of moving knot-resolver to knot-resolver-core and added manager to knot-resolver-manager with Provides: knot-resolver6. That way no upgrade is triggered as there is no knot-resolver package in 6.0. However, this is probably just unneeded complexity - I guess the packages could or even should be merged. So what do you suggest? Merging -manager and -core into knot-resolver6? Or is there a way to prevent upgrade without changing package name? Cheers, Jakub OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068951: new upstream (6.x)
On 4/29/24 19:50, Daniel Baumann wrote: pushing to the repo requires me to be added to the salsa project.. would you mind adding me? in the meantime, I've pushed to here: https://git.progress-linux.org/users/daniel.baumann/debian/todo/knot-resolver/log/ before I'll continue: what's the idea of adding knot-resolver-manager binary package? I can't think of a reason why one would use kresd (knot-resolver-core) without the manager, and thus, would fold knot-resolver-manager and knot-resolver-core (back) into knot-resolver. But probably I'm missing something.. Regards, Daniel
Bug#1068951: new upstream (6.x)
On 4/23/24 14:45, Jakub Ružička wrote: Awesome, I've forwarded your words of praise to the hard-working Knot Resolver team :) (jftr: we switched in 2015 from cisco ncr to unbound, and in 2016 from unbound to knot-resolver.. and are super happy ever since) I'm actually quite interested in (the nightmares of) python packaging hehe :) Cool, I've already mental-marked you as a person I'm gonna bother with reviewing my v6 changes even before your willing reply :) no problem, looking forward to it :) IOW ~/src/knot-resolver/distro/pkg/deb and ~/debian/knot-resolver/debian should be as close as possible. +1 Feel free to push your changes (if any) to debian/experimental or use your branch as you prefer, I'm always eager to learn how other DDs do things. pushing to the repo requires me to be added to the salsa project.. would you mind adding me? Regards, Daniel
Bug#1068951: new upstream (6.x)
On 4/23/24 14:05, Daniel Baumann wrote: Hi, On 4/23/24 13:58, Jakub Ružička wrote: but we've agreed the time has come to get extra testing & feedback through Debian experimental. yay, thanks! [ we use knot-resolver at work for the central resolvers for the university, and we love it. kresd 6 offers some nice improvements for us, so looking forward testing it (via local bookworm-backports we maintain) ] Awesome, I've forwarded your words of praise to the hard-working Knot Resolver team :) The only blocker for that is missing python3-json-schema-for-humans needed for docs build which I intend to package later - for now I guess I'll just disable the docs build. (just as an offer) I'll maintain a bunch of python modules already and don't mind another, so I can upload that later today if this is any help. Thanks, but I'm part of PythonTeam so I can do that myself and I'm actually quite interested in (the nightmares of) python packaging in general so it's a welcome opportunity to have some real world experience plus I think it will be a trivial package. I'm hitting boundaries of my Debian knowledge so it's slow. I'm happy to help if you want. Cool, I've already mental-marked you as a person I'm gonna bother with reviewing my v6 changes even before your willing reply :) For example, upstream package uses meson directly and builds in meson_deb dir, but debian package uses debhelper with obj-x86_64-linux-gnu dir and I don't know howto properly reference it from d/rules without relying on shady strings. I didn't find a branch on the salsa repo, where would I find the current 6.x state to send patches against? I don't like pushing broken/incomplete branches but yeah this is gonna take a while so I pushed my Draft to debian/experimental salsa branch (also pristine-tar and new upstream-6). The upstream package is well tested, but it diverged quite far from debian package and syncing them is non-trivial - my mission is to fix that. git clone -b 6.0 https://gitlab.nic.cz/knot/knot-resolver meld knot-resolver/distro/pkg/deb ~/debian/knot-resolver/debian IOW ~/src/knot-resolver/distro/pkg/deb and ~/debian/knot-resolver/debian should be as close as possible. Of course the changes can flow both ways - I'm happy to update the upstream packaging as well. Feel free to push your changes (if any) to debian/experimental or use your branch as you prefer, I'm always eager to learn how other DDs do things. I'd be especially interested about how you translate the distro/pkg/deb/rules to debian/rules without using the static build_deb dir 🤔 There might be variable already defined for this purpose, but I just don't know how to find it. Regards, Daniel Cheers, Jakub OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068951: new upstream (6.x)
Hi, On 4/23/24 13:58, Jakub Ružička wrote: but we've agreed the time has come to get extra testing & feedback through Debian experimental. yay, thanks! [ we use knot-resolver at work for the central resolvers for the university, and we love it. kresd 6 offers some nice improvements for us, so looking forward testing it (via local bookworm-backports we maintain) ] The only blocker for that is missing python3-json-schema-for-humans needed for docs build which I intend to package later - for now I guess I'll just disable the docs build. (just as an offer) I'll maintain a bunch of python modules already and don't mind another, so I can upload that later today if this is any help. I'm hitting boundaries of my Debian knowledge so it's slow. I'm happy to help if you want. For example, upstream package uses meson directly and builds in meson_deb dir, but debian package uses debhelper with obj-x86_64-linux-gnu dir and I don't know howto properly reference it from d/rules without relying on shady strings. I didn't find a branch on the salsa repo, where would I find the current 6.x state to send patches against? Regards, Daniel
Bug#1068951: new upstream (6.x)
Hello, we have a working upstream packages for knot-resolver 6.x alpha at https://pkg.labs.nic.cz/doc/?project=knot-resolver but we've agreed the time has come to get extra testing & feedback through Debian experimental. The only blocker for that is missing python3-json-schema-for-humans needed for docs build which I intend to package later - for now I guess I'll just disable the docs build. I'm working on deep-cleaning the knot-resolver package (silencing the many cries of lintian and such) and syncing it closer with upstream but I'm hitting boundaries of my Debian knowledge so it's slow. For example, upstream package uses meson directly and builds in meson_deb dir, but debian package uses debhelper with obj-x86_64-linux-gnu dir and I don't know howto properly reference it from d/rules without relying on shady strings. I'll take some more time to clean the package properly so that it starts its 6.x life with a clean slate but it's going to hit experimental in upcoming weeks :) Thanks for indicating interest, I'll get it done. Cheers, Jakub Ružička On 4/14/24 08:39, Daniel Baumann wrote: Package: knot-resolver Severity: wishlist Hi, it would be nice if you could upload knot-resolver 6.x to experimental. Regards, Daniel OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068951: new upstream (6.x)
Package: knot-resolver Severity: wishlist Hi, it would be nice if you could upload knot-resolver 6.x to experimental. Regards, Daniel
