Someone just needs to do a technical review to reconcile Debian's patch stack with apalrd's upstream: https://salsa.debian.org/debian/tayga/-/tree/debian/master/debian/patches
Direct people at the existing bug for coordination: https://bugs.debian.org/1107302
@dxld @goetz @tschaefer all of debians patches are incorporated, and bugs in those patches have been fixed. I’m not sure what the holdup is on debians side, now that Trixie released
@apalrd @goetz @tschaefer It's not that simple, we've made changes to the package since to fix issues in Trixie. The upgrade path from that state to your upstream needs a technical analysis.
Anyone is welcome to submit an updated package to mentors.debian.net BTW. If not me or someone will likely get around to it before Forky but it's not a priority for any DDs I know of rn.
Just keep in mind the hard part isn't the package its the technical analysis.
@dxld @goetz @tschaefer the bug in Trixie was caused by modifying an old patch improperly and accepting it without any apparent analysis at all?
I’m not sure what else Debian wants from my end. The makefile respects all of the env vars used by packaging systems as far as I’m aware.
None of the other distro maintainers have had issues changing upstream in their unstable branch. Most distro are not carrying any patches at all now, and just building the release tarball from GitHub or by checking out a specific tag.
@dxld @goetz @tschaefer maybe that’s a bit harsh to Debians maintainers. I have not worked with the package building side of Debian.
I am now the maintainer in Alpine and the Alpine build script is a single file which points to the place to get the tar and the expected hash. Every Tayga release I update these two lines and submit a merge request on their Gitlab and within a day the latest Tayga is built and pushed to testing. The politics and approvals here were not difficult.
Speaking to other maintainers on other distros, their process is not that different. The package file has some pointer to the git repo + tag or the release tar. Since the package is not carrying any patches, it’s not a complicated process.
@apalrd @goetz @tschaefer Debian just works differently.
Give it time. It'll happen. I'm personally working on CLAT integration by default but takes time and care. Tayga is just the tip of the iceberg of work I can see.
Other ways to contribute: file bugs to make it clear why the newer version is necessary. Right now the BTS does not tell that story.
This will be my last message in this thread. Please contribute to the bug instead: 1107302@bugs.debian.org
@dxld @apalrd @tschaefer
Like so: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107302#20
Sorry for the typo Andrew.
"I'm personally working on CLAT integration by default", which part ? NM CLAT integration is ready to be merged.
or `clatd` by default?
@goetz @apalrd @tschaefer I'm talking about ifupdown which is more relevant than NM for Debian servers.
which ifupdown?
Currently there's a totally unrelated but also big issue with ifupdown2 being unmaintained, in that the source is no longer being shared by nvidia, although it's still used by cumulus linux and nvidia still maintains the git repo without accepting fixes.
afaik 'classic' ifupdown has not had feature development in many years, and does not support most interface types, so the other ifupdowns are more commonly used where any sort of non-default network configuration is required.
That doesn't mean the ifupdown landscape is good, but servers are also not very likely to need a CLAT vs just doing DNS64.
@dxld Thank you for the clarification.
I have typically no need to CLAT on servers and if so, clatd works fine for my use cases.
@apalrd The one(s) I maintain ofc.: https://qa.debian.org/developer.php?login=dxld#:~:text=ifupdown :-)
"has not had feature development" - You might want to update your facts there.
Discourse you probably missed:
- replies
- 0
- announces
- 0
- likes
- 0