Re: Maintaing proxytunnel through the team
Hello Samuel, thanks a lot for assigning the access rights to me. I will drop the ".1." from the version. @Julian + Marcos: Thank you for the enlightening debate. Regards, Sven Am Donnerstag, den 23.04.2020, 01:06 +0100 schrieb Samuel Henrique: > Hello all, > > Sorry I don't have much time to add some meaningful into the > conversation, I also think it's better to remove the ".1." as the > date > + commit id already fulfills its role. > > Sven, I gave you Developer access to the repo, feel free to push when > you'd like to, the package does not need to be ready/working, I just > called it out in case you haven't noticed or you'd like to rewrite > the > history. Feel free to pick the version format you think it's best, we > don't enforce a format in the team and I can see there is a good > discussion about it in this thread so I'm fine with whatever you > pick. > > Also, thanks for your inputs Marcos and Julian, > > Regards, > signature.asc Description: This is a digitally signed message part
Re: Maintaing proxytunnel through the team
Hello all, Sorry I don't have much time to add some meaningful into the conversation, I also think it's better to remove the ".1." as the date + commit id already fulfills its role. Sven, I gave you Developer access to the repo, feel free to push when you'd like to, the package does not need to be ready/working, I just called it out in case you haven't noticed or you'd like to rewrite the history. Feel free to pick the version format you think it's best, we don't enforce a format in the team and I can see there is a good discussion about it in this thread so I'm fine with whatever you pick. Also, thanks for your inputs Marcos and Julian, Regards, -- Samuel Henrique
Re: Maintaing proxytunnel through the team
On Wed, Apr 22, 2020 at 08:52:19PM +0200, Sven Geuer wrote: > Hi Samuel, Julian and Marco > > Regarding > >But I agree that the '.1.' is excessive (even though I have been > > guilty of it myself - I was just copying what someone else had done > > and presumed that it had a good reason...). > > The '.1.' helps to keep the version numbers monotonically increasing if > there should be another version for the same date. For instance > > 1.2.3+git20200422.ef8a32b > 1.2.3+git20200422.2193ffa > > is not monotonically increasing, but one enforces it this way > > 1.2.3+git20200422.1.ef8a32b > 1.2.3+git20200422.2.2193ffa > > I agree you will really need this quite rarely. While the commit > fingerprint is a must as it serves to uniquely identify a commit. Rare indeed! You can always wait <24 hours and then upload a new version instead ;-) Best wishes, Julian
Re: Maintaing proxytunnel through the team
Hi Samuel, please find my replies inline below. Am Mittwoch, den 22.04.2020, 01:34 +0100 schrieb Samuel Henrique: > Hello Sven, > > I believe the package is a fit for our team yes. > > The repository is created at > https://salsa.debian.org/pkg-security-team/proxytunnel > But before the push I'd like to ask you about the latest upstream > release imported: 1.9.1+git20200123.1.eff4d41 > > What's up with the "1.eff4d41" part? I didn't investigate but I > assume > the last one is part of the git commit hash, but I don't know about > the ".1.". > I feel like I'm missing something, generally I prefer to use only a > date for tarballs coming from git snapshots, and I believe they are > more clean, though I recognize it's not as precise as having the > commit id. It guarantees monotonically increasing version numbers. Please have a look at my previous post for details. > > The package is also not building for me, and I believe it's a general > issue, it's better if you take a look at that before we push it to > the > team's repo as you can freely mess with the git history for now. The package is work in progress. Even the patches were not adopted yet to the new upstream version. If you prefer I can continue to work on it as a personal project first, and come back to you when I have it ready to be reviewed. > > Thanks for your work, > Regards Sven signature.asc Description: This is a digitally signed message part
Re: Maintaing proxytunnel through the team
Hi Samuel, Julian and Marco Regarding >But I agree that the '.1.' is excessive (even though I have been > guilty of it myself - I was just copying what someone else had done > and presumed that it had a good reason...). The '.1.' helps to keep the version numbers monotonically increasing if there should be another version for the same date. For instance 1.2.3+git20200422.ef8a32b 1.2.3+git20200422.2193ffa is not monotonically increasing, but one enforces it this way 1.2.3+git20200422.1.ef8a32b 1.2.3+git20200422.2.2193ffa I agree you will really need this quite rarely. While the commit fingerprint is a must as it serves to uniquely identify a commit. @Samuel: If the teams prefers a different way to construct the version, I am happy to adopt this. Regards, Sven Am Mittwoch, den 22.04.2020, 16:55 +0100 schrieb Julian Gilbey: > On Wed, Apr 22, 2020 at 03:09:16PM +0200, Marcos Fouces wrote: > > Hi Julian and Samuel > > > > I found that there is 1493 binary packages that use the "git" > > string in > > the release number. There is some exotic variations (like this one > > 0.0~GOTK3~0~2~0+git20170418.0.96d4110-3) > > > > I believe that ".1." refered by Samuel could be considered as a > > kind of > > an epoch. This is useful because the characters of the commit > > cannot be > > used to sort releases. > > > > IMHO, there is no strong need to insert the date, some characters > > of > > commit id, a custom epoch... Using "git+date" should be enough in > > most > > cases. > > Hi Marcos, > > I have found that having a commit id in the package version can be > helpful: > > - sometimes there is more than one upstream commit in a day > > - sometimes the commit date is somewhat ambiguous, especially if the > commit was on a different branch and then merged into the master > branch at a later date - what is the date that should then be used? > Different maintainers have used different choices, but the commit > id > is unambiguous. > > These have arisen when I've been trying to compare a Debian package > to > the upstream original to track down some issue or other. > > But I agree that the '.1.' is excessive (even though I have been > guilty of it myself - I was just copying what someone else had done > and presumed that it had a good reason...). > > > If you add some more commits, you can add them as patches in > > d/patches > > and refer it in d/changelog. > > Or just release a new version? Or do you mean cherry-picking later > commits? > > Best wishes, > >Julian > signature.asc Description: This is a digitally signed message part
Re: Maintaing proxytunnel through the team
On Wed, Apr 22, 2020 at 07:17:28PM +0200, Marcos Fouces wrote: > > > If you add some more commits, you can add them as patches in > > > d/patches > > > and refer it in d/changelog. > > > > Or just release a new version? Or do you mean cherry-picking later > > commits? > > > > Yes, you can cherry-pick all the commits you want and add them to > d/patches. I am thinking about forks on Github that could also contains > interestings commits. > > This kind of situation would be near to imposible to reflect this way. Yes, indeed; I wasn't imagining trying to contain that information in the version number. I was thinking of keeping the short commit id in the upstream version number to help identify the commit that is stored in the .orig.tar; everything in the d/patches is applied to that commit. Best wishes, Julian
Re: Maintaing proxytunnel through the team
> > If you add some more commits, you can add them as patches in > > d/patches > > and refer it in d/changelog. > > Or just release a new version? Or do you mean cherry-picking later > commits? > Yes, you can cherry-pick all the commits you want and add them to d/patches. I am thinking about forks on Github that could also contains interestings commits. This kind of situation would be near to imposible to reflect this way. Greetings, Marcos
Re: Maintaing proxytunnel through the team
On Wed, Apr 22, 2020 at 03:09:16PM +0200, Marcos Fouces wrote: > Hi Julian and Samuel > > I found that there is 1493 binary packages that use the "git" string in > the release number. There is some exotic variations (like this one > 0.0~GOTK3~0~2~0+git20170418.0.96d4110-3) > > I believe that ".1." refered by Samuel could be considered as a kind of > an epoch. This is useful because the characters of the commit cannot be > used to sort releases. > > IMHO, there is no strong need to insert the date, some characters of > commit id, a custom epoch... Using "git+date" should be enough in most > cases. Hi Marcos, I have found that having a commit id in the package version can be helpful: - sometimes there is more than one upstream commit in a day - sometimes the commit date is somewhat ambiguous, especially if the commit was on a different branch and then merged into the master branch at a later date - what is the date that should then be used? Different maintainers have used different choices, but the commit id is unambiguous. These have arisen when I've been trying to compare a Debian package to the upstream original to track down some issue or other. But I agree that the '.1.' is excessive (even though I have been guilty of it myself - I was just copying what someone else had done and presumed that it had a good reason...). > If you add some more commits, you can add them as patches in d/patches > and refer it in d/changelog. Or just release a new version? Or do you mean cherry-picking later commits? Best wishes, Julian
Re: Maintaing proxytunnel through the team
Hi Julian and Samuel I found that there is 1493 binary packages that use the "git" string in the release number. There is some exotic variations (like this one 0.0~GOTK3~0~2~0+git20170418.0.96d4110-3) I believe that ".1." refered by Samuel could be considered as a kind of an epoch. This is useful because the characters of the commit cannot be used to sort releases. IMHO, there is no strong need to insert the date, some characters of commit id, a custom epoch... Using "git+date" should be enough in most cases. If you add some more commits, you can add them as patches in d/patches and refer it in d/changelog. Greetings, Marcos. El mié, 22-04-2020 a las 09:33 +0100, Julian Gilbey escribió: > On Wed, Apr 22, 2020 at 01:34:32AM +0100, Samuel Henrique wrote: > > Hello Sven, > > > > I believe the package is a fit for our team yes. > > > > The repository is created at > > https://salsa.debian.org/pkg-security-team/proxytunnel > > But before the push I'd like to ask you about the latest upstream > > release imported: 1.9.1+git20200123.1.eff4d41 > > > > What's up with the "1.eff4d41" part? I didn't investigate but I > > assume > > the last one is part of the git commit hash, but I don't know about > > the ".1.". > > I feel like I'm missing something, generally I prefer to use only a > > date for tarballs coming from git snapshots, and I believe they are > > more clean, though I recognize it's not as precise as having the > > commit id. > > Hello Samuel, > > There is no particular consensus for git-based version numbers. > > egrep 'Package:|Version:' /var/lib/apt/lists/ > ftp.uk.debian.org_debian_dists_testing_main_binary-amd64_Packages | > grep -B 1 '+git' | less > > shows a wide variety. But it is very common to include the first 7 > characters of the commit id. > > Best wishes, > >Julian >
Re: Maintaing proxytunnel through the team
On Wed, Apr 22, 2020 at 01:34:32AM +0100, Samuel Henrique wrote: > Hello Sven, > > I believe the package is a fit for our team yes. > > The repository is created at > https://salsa.debian.org/pkg-security-team/proxytunnel > But before the push I'd like to ask you about the latest upstream > release imported: 1.9.1+git20200123.1.eff4d41 > > What's up with the "1.eff4d41" part? I didn't investigate but I assume > the last one is part of the git commit hash, but I don't know about > the ".1.". > I feel like I'm missing something, generally I prefer to use only a > date for tarballs coming from git snapshots, and I believe they are > more clean, though I recognize it's not as precise as having the > commit id. Hello Samuel, There is no particular consensus for git-based version numbers. egrep 'Package:|Version:' /var/lib/apt/lists/ftp.uk.debian.org_debian_dists_testing_main_binary-amd64_Packages | grep -B 1 '+git' | less shows a wide variety. But it is very common to include the first 7 characters of the commit id. Best wishes, Julian
Re: Maintaing proxytunnel through the team
Hello Sven, I believe the package is a fit for our team yes. The repository is created at https://salsa.debian.org/pkg-security-team/proxytunnel But before the push I'd like to ask you about the latest upstream release imported: 1.9.1+git20200123.1.eff4d41 What's up with the "1.eff4d41" part? I didn't investigate but I assume the last one is part of the git commit hash, but I don't know about the ".1.". I feel like I'm missing something, generally I prefer to use only a date for tarballs coming from git snapshots, and I believe they are more clean, though I recognize it's not as precise as having the commit id. The package is also not building for me, and I believe it's a general issue, it's better if you take a look at that before we push it to the team's repo as you can freely mess with the git history for now. Thanks for your work, -- Samuel Henrique
Re: Maintaing proxytunnel through the team
Re-sent with link [2] fixed. Am Dienstag, den 21.04.2020, 22:01 +0200 schrieb Sven Geuer: > Hello Samuel, > Hello Team, > > I've started to adopt the proxytunnel package [1] from Julian [2]. > > I believe it fits into the range of packages the team is maintaining > and like to suggest to introduce it to our repository. > > This is what proxytunnel's description says: > > Create tcp tunnels trough HTTPS proxies, for using with SSH > Proxytunnel is a program that connects stdin and stdout > to an origin server somewhere in the Internet through an industry > standard HTTPS proxy. It was originally written to be used > as an extension to SSH, to be used to SSH to a box at home. It's > possible to use proxytunnel along with other applications as well. > > I am currently working on the package as a personal project [3]. > Would > you mind to import it? > > Let me know what you think about my request. > > Thanks, > Sven > > [1] https://tracker.debian.org/pkg/proxytunnel > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958177 > [3] https://salsa.debian.org/sven-geuer-guest/proxytunnel signature.asc Description: This is a digitally signed message part
