Hello,Thanks, so now I know I was on the right way with what I did on the Salsa repository [1]. In fact at first my wish was to switch from snapshot versions to released version, but 1.7 is not greater than the actual version. So even if it is not the best solution, it looks I will have to keep using Git snapshot versions...
[1]: https://salsa.debian.org/Nardol/pidgin-skype Best regards, Patrick Le 23/01/2024 à 16:44, Gianfranco Costamagna a écrit :
Hello, You can maybe do something like: download tarball from last master branch https://github.com/EionRobb/skype4pidgin/tarball/master (automatic tarball generation) call it something like 20240123+gitecef199+dfsg-1 20140930+svn665+dfsg-2 $ dpkg --compare-versions 20240123+gitecef199+dfsg-1 gt 20140930+svn665+dfsg-2 && echo true true G. Il martedì 23 gennaio 2024 alle ore 09:40:11 CET, Patrick ZAJDA <patrick@zajda.fr> ha scritto: Hello, Le 23/01/2024 à 01:27, Gianfranco Costamagna a écrit :I intent to adopt pidgin-skype package. The package version is based on last upstream Git main branch commit, to keep same versioning the package has already. To successfully enable hardening, I created a patch I contributed upstream by opening a pull request. The pull request was merged some hours after. What should I do now? Continue with the same version using the patch? Bump new version and in this case, should I only change the actual version in debian/changelog or create a new version to change upstream version and keep the version the RFS is opened for? Thanks and best regards,As first answer? Please ask upstream to release something new, don't make every distribution rely on git snapshots, because it's hard to understand when something is "stable" enough without a tagged release. If this isn't possible, either packaging a new snapshot or applying it as patch and bump Debian revision from N to N+1 is ok. (maybe it depends on the patch size, if small, a patch is ok to avoid import of a new tarball, if the patch is huge, maybe the latter is preferred. Also, there might be other commits between the Debian snapshot and the patch upstream acceptance, so check all the commits for their stability). Sorry for not providing a good answer but "it depends" is probably the right one. G.Firstly, I would really have preferred to avoid these kind of version :-) But the latest release was about three years ago, maybe I could ask the project maintainer to tag a new version... Before the yesterday commit which applies the patch, previous was on July 10, 2023. And because actual package version is an SVN snapshot, I don't know how I could change version chem without using epoch. Woule yyymmdd+realyversion+dfsg be OK? But there is still the fact latest version is very old and a lot of fixes have been applied since. Anyway, if I read you correctly and because my patch modifies only two lines with only one useful for the Debian package, maybe it is OK to wait for a review of the actual package I opened a RFS for. Thanks and best regards,
-- Patrick ZAJDA
Attachment:
OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature