Source: razor Version: 1:2.85-4.2 X-Debbugs-Cc: mss@msquadrat.de Control: submitter -1 mss@msquadrat.de The current "upstream" version was uploaded to debian in 2008 currently present in old-old-stable (e.g. two releases prior to the current stable release): https://tracker.debian.org/news/303771/accepted-razor-1285-1-source-amd64/ The best thing might be to actually update to the newest upstream release, if there is indeed one newer than 2.85... and kind of ignore that unfortunate problem... ... though there might be security issues that are not correctly tracked that are fixed in the upstream 2.85, but not in the debian packages because of the version discrepancy; that might be worth confirming and possibly notifying the security team. All that said, not sure I have the energy to tackle this kind of tangled problem at the moment... live well, vagrant
Hi vagrant, thanks for pushing this to bdo. >> […] in https://github.com/toddr/Razor2-Client-Agent/compare/v2.84...v2.85 There even don't seem to be many functional changes, most of the changes are cleanup/build related things. v2.86 also was just a build related thing. The bad news: All the current Debian patches won't apply anymore since there was some excessive reformatting applied upstream. OTOH will some of them not be needed anymore since it looks they were partially incorporated upstream. Would you like help with that? My Debian packaging know how is a bit rusty but I could create a PR on Salsa which * Merges the Upstream repo into the current Salsa repo (ie. switching it over to https://wiki.debian.org/PackagingWithGit#Using_the_upstream_repo without losing any history) at upstream v2.84 * Fixes up the Quilt patches and merge that state with upstream v2.85 * Bump the whole stuff to v2.86 What do I get out of that? I'd like to include my IPv6 patch on top of all of this. Regards, Malte
retitle 1013329 razor 2.85 identifies itself as razor 2.84 thanks Hi. I've adopted this package today. I've checked and the orig.tar.gz that we distribute as 2.85 matches exactly the tar.bz2 that can still be obtained from sourceforge as 2.85. Apparently the author took 2.84, updated the license to "artistic license 2.0" and released it as 2.85 without raising the version number that "razor-check -v" shows. I'm retitling the bug to better reflect the problem. The discrepancy happens only between sourceforge version 2.85 and what the new github repo calls version 2.85 (which is essentially sourceforge 2.85 + perl cleanups). Am I right to think that what you call IPv6 change is the same I see when I do "git show -w a2ec2fb" in the github repo? If yes, that's a very small change and we don't need to switch to the new upstream version for that. Can you backport the change to our current 2.85 version and file a new (wishlist) bug for that? Thanks.
Feel free to report it as a wishlist bug anyway. Will probably apply the change after the release of trixie. Thanks.
Great to hear, thanks for your efforts! So now I understand where the confusion is coming from. I didn't know that on SF there is also a 2.85 since I was primarily looking at CPAN which IMO is the canonical source for anything Perl. And there the 2.85 version is the code from GitHub. Everything taken together I'd still say that this is 2.84, just with an updated license. Maybe the confusion could be cleared by changing the version to 2.85+really2.84? The whole mess will be cleared up with a bump to 2.86 past trixie. Do you need help with that? I looked into that before but got distracted. I think most of the debian patches were obsolete by now. For a variant of one of them there is this stalled PR upstream: https://github.com/toddr/Razor2-Client-Agent/pull/11 Yes, it was this issue I filed and fixed https://github.com/toddr/Razor2-Client-Agent/issues/12 Will do. Thanks, Malte
El 26/5/25 a las 11:06, Malte S. Stretz escribió: The current version is 2.85 and it was meant to be 2.85, it's just that the author forgot to update the version in several other places. Sometimes authors increase the version for minor changes like updated licenses and the like. So, it's not that "it's really 2.84". It just mistakenly identifies itself as 2.84. This is why I changed the bug title, and I don't see the need to change the version at this point. It may be confusing, but not to the point that it needs a version change on our (Debian) side. Yes. I'll keep this open until then. Sometimes an open bug is the best way to document something like this. It would be a "wontfix", which is our way to say that the cure is worse than the disease, but I don't like using the tag, as this will eventually be fixed. Not particularly, but I take note that you can help if required. for trixie, it is likely that I switch to 2.86 anyway in forky. So: No need to backport anything. Just point to your PR in github. The change is very simple anyway so it's trivial to backport in either case. Thanks.