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 <patr...@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
