XPost: linux.debian.devel

Package: wnpp
Severity: whishlist

* Package name : gtk-gnutella
Version : 1.2.3
Upstream Author : Raphael Manfredi
* URL : https://gtk-gnutella.sourceforge.io
* License : GPL
Programming Lang: C++
Description : P2P Gnutella server/client

This is the follow-up of bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065479

gtk-gnutella is a server/client for the Gnutella peer-to-peer network.
It was previously included in Debian repository.
The source code is hosted in Github: https://github.com/gtk-gnutella/gtk-gnutella
I already prepared the .deb package here: https://sourceforge.net/projects/gtk-gnutella/files/gtk-gnutella/1.2.3/

--
Lucio Marinelli

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel

On Wed Mar 13, 2024 at 6:52 PM GMT, Lucio Marinelli wrote:

gtk-gnutella is a server/client for the Gnutella peer-to-peer network.
It was previously included in Debian repository.
The source code is hosted in Github: https://github.com/gtk-gnutella/gtk-gnutella
I already prepared the .deb package here: https://sourceforge.net/projects/gtk-gnutella/files/gtk-gnutella/1.2.3/

I took a peek, out of curiosity. I was surprised not to find a
orig.tar.gz / debian.tar.gz split; the package version scheme
properly reflects a normal (non-native) package (1.2.3-1), but
the source tarball has "./debian" in it; and indeed, it looks
like you're managing the debian packaging in the upstream repo.
It's advisable to keep the two separate.

The debian/copyright file doesn't conform to spec[1], and doesn't
describe the copyright of the debian files in particular. I couldn't
easily answer the question: is your packaging based on the previous
iteration of the debian package? Do the previous packagers hold
copyright?


[1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel

On Fri, Mar 29, 2024 at 09:28:44AM +0800, Sean Whitton wrote:

On Thu 14 Mar 2024 at 01:29pm GMT, Jonathan Dowland wrote:

I took a peek, out of curiosity. I was surprised not to find a
orig.tar.gz / debian.tar.gz split; the package version scheme
properly reflects a normal (non-native) package (1.2.3-1), but
the source tarball has "./debian" in it; and indeed, it looks
like you're managing the debian packaging in the upstream repo.
It's advisable to keep the two separate.

Not everyone agrees with this. I think that same repo, non-native
versioning is often what's best for a package.

While it's true that some people do hold that position, the problem with
it has always been that it gets extremely cumbersome the moment that maintenance of the Debian packaging passes to somebody who doesn't have upstream commit access. This event is traditionally followed by
cursing.

--
Colin Watson (he/him) [cjwatson@debian.org]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel

Hello,

On Thu 14 Mar 2024 at 01:29pm GMT, Jonathan Dowland wrote:

On Wed Mar 13, 2024 at 6:52 PM GMT, Lucio Marinelli wrote:

gtk-gnutella is a server/client for the Gnutella peer-to-peer network.
It was previously included in Debian repository.
The source code is hosted in Github:
https://github.com/gtk-gnutella/gtk-gnutella
I already prepared the .deb package here:
https://sourceforge.net/projects/gtk-gnutella/files/gtk-gnutella/1.2.3/

I took a peek, out of curiosity. I was surprised not to find a
orig.tar.gz / debian.tar.gz split; the package version scheme
properly reflects a normal (non-native) package (1.2.3-1), but
the source tarball has "./debian" in it; and indeed, it looks
like you're managing the debian packaging in the upstream repo.
It's advisable to keep the two separate.

Not everyone agrees with this. I think that same repo, non-native
versioning is often what's best for a package.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmYGGUwZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQFxKD/9bi5wbrrQG1TxcxpgikXn9 WMTICIHFogwmKQNoVZU2zNJciwIbJxjOh+jOxX8d7BILWdU4Bj2gs039i1Er3j6Z jgpdt5UH+hjQYcEngf/v5ek22VZU0v1HUYnYL8yG12E5K6HfDVdslU5C7hGdnIm/ 0QxIjEpQtAzAtR1CuDF+fJxIm1eoGajBGtnODs35YQKb+3r+yLT7ST2VDsIn0Tkv Ft+fTSjk8Qmt+KNW2Sq+DxyPA4LoO9sXLNYMVqyW6vwrT65hwGyZrNT1zqf7GkrS fUwFkLOnPSD9dnc2lszGCOA85OOgKVDAjvihzCY6O3uOdgToMZ1MC74atrKoJB5b 3/bJmVWr2OLx3kizgL3dUnKj0AXeB8cCeF/DlSJl47tHcJpkhSzSX4aSRHrCu8KP deNQ4CJKaS1xmYudWzW6uzCjJ5KNneh5duTssKKNVv60Yk96r9mZGo7FHqhjC0li OpfQJQdo8yOvNkMVYPzrdjMuvxGbPrI65SeGwTZD4eCKQOocc6fSDg4LmJ0cOrAt 6DxnuR4cqTp0eU6OGx0UmJdGlxY6cVuVsR5tX/NCHJRbckWQQkY0inzI8FUgQHG5 kkbXEUdcQlcAS8rAgzUFJHxrH7amiqD/dJbHyTE2XLRlacr3jKXp/wCIoy+/1hmQ VrvCqGh3j4GqX35eWYjbOA==l3H8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

XPost: linux.debian.devel

Hello,

On Fri 29 Mar 2024 at 01:44am GMT, Colin Watson wrote:

On Fri, Mar 29, 2024 at 09:28:44AM +0800, Sean Whitton wrote:

On Thu 14 Mar 2024 at 01:29pm GMT, Jonathan Dowland wrote:

I took a peek, out of curiosity. I was surprised not to find a
orig.tar.gz / debian.tar.gz split; the package version scheme
properly reflects a normal (non-native) package (1.2.3-1), but
the source tarball has "./debian" in it; and indeed, it looks
like you're managing the debian packaging in the upstream repo.
It's advisable to keep the two separate.

Not everyone agrees with this. I think that same repo, non-native
versioning is often what's best for a package.

While it's true that some people do hold that position, the problem with
it has always been that it gets extremely cumbersome the moment that maintenance of the Debian packaging passes to somebody who doesn't have upstream commit access. This event is traditionally followed by
cursing.

I've been on both sides of this -- upstream maintainer doing Debian
packaging, and adopting a package previously maintained by its
upstream -- and I really appreciated the simplicity in the former role,
and found it just one of the various small tasks involved in adopting
the package in the latter role. I think it's easier now we treat source packages as an output format, thanks to git.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmYGPa8ZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQKcCD/9xC2hJFi7cGqhKowjBAoQK hYDa2AoMDKo7ziS5JLW0uDRB57YsE/DEIumVmckAaAa88gwcze6M2hzNwzOC5qPE MV/pbd1wjpEw2YqgOaDmi6Y8brktwM09oXWXxxoSoAZNDgmc7ScT2NDOqSAACayN /c+rxTchQSCi8LFmF0QF7tBBtsWbh2iZFvHk17szbJkx2Y6+JHkwIaM0ucO0vpBJ QK4479TJDNh06xpSNU8uOv4/bEA82ZIAcVUoDqfSwTHk6X9n3psDiVmgC30hOeIe KzrpiDQQFG50QS91IRKyDlJijIaj+Z/l+lKRni084ML7/c48Y/Jwe7UmMpH8awhL TCPdRqJzKmlS+A/vZPDR5gJ2uW7N1/Jm8oX/hZQELzdQxNK0fQ57UsDX8fkFM88P h7lwKr9SFbHr7ymX4YxN10ddUldPUb1FYjG8zp79Tq7aHuoSxdSZTeDkpLh+OKj9 sSg2ug5KQHb/1VvgLvnqHyCkZuTSVw8YOC4reAJ0P8Q8P1ycvvxpR10xWbPWPWFR W9WjLXg+jaaoRFX0P0w20zzM47hbfEgbAj0oMRWyAb4vQEi5xeZrGCdTsRgVn5wO i3h/RR3MHEx4QcQeJsQnT5xmSSUoxJ6kJ+LjAiGz6PHtujBtV8yscYIxMt1d6FFc LeMyDjnb9MFUH9bUWoRR+g==WVnn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us