Mateusz, Thank you for the quick turnaround.
On Monday, June 10, 2024 3:09:43 PM MST Mateusz Łukasik wrote: > I do this for last 18 years. Maybe time to be DD. I would highly encourage you to become a DD. At a minimum, you can easily become a Debian Maintainer, which would allow you to receive permission to update just your packages. > > 5. vimb.metainfo.xml lists the project_license as GPL-3.0-only. This > > appears to be an error as all the other copyright information I can find in > > the source code indicates the project license is GPL-3.0+. You should > > check with upstream and update the file accordingly. > > I have downgraded the licence versions to GPL-3 without the plus. I think this is a more complicated situation than that. The files I checked in https://github.com/fanglingsu/vimb/tree/master/src all list the GPLv3+ in the headers of the files themselves. But vimb.metainfo.xml lists GPL-3.0-only. This appears to be a situation where the upstream developer has represented that his files are available under two (slightly) different licenses. My guess is that the GPL-3.0-only in vimb.metainfo.xml is a typo, and the intention was for it to be GPL-3.0+. But it isn’t possible to know that without confirmation from the upstream developer. There is also the possibility there is one file somewhere in the tree that I didn’t find that is licensed explicitly as GPLv3. If such is the case, then the entire project does need to be GPLv3 and vimb.metainfo.xml is correct. In that case, debian/copyright would need to enumerate which files are GPLv3 and which are GPLv3+, so that a user would know both what the entire project license is as well as the license for each individual file that is different from (but compatible with) the main project license. I would recommend you file a bug report upstream (or otherwise contact the upstream developer) for clarification of his intentions. My guess is that he will rectify the situation by changing the license in vimb.metainfo.xml. If he does, you can cherry pick that patch and apply it to your package until the next upstream release. The key to this issue is that only the copyright holder can change the license. And with conflicting upstream information, it isn’t possible to know what it should be until clarified by upstream. > Also I see reported by lintian this experimental issue: > > X: vimb source: prefer-uscan-symlink filenamemangle > s%v?@ANY_VERSION@%@PACKAGE@-$1.tar.gz% [debian/watch:5] > N: > N: Please consider setting USCAN_SYMLINK=rename in your ~/.devscripts > N: configuration file instead of using the option filenamemangle in > N: debian/watch. > N: > N: Please check with your team before making changes to sources you > maintain > N: together. There are circumstances when the filenamemangle option is > N: better. > N: > N: Please refer to the uscan(1) manual page for details. > N: > N: Visibility: pedantic > N: Show-Always: no > N: Check: debian/watch > N: This tag is experimental. > N: > > I get watch file config from here: > https://wiki.debian.org/debian/watch#GitHub Lintian experimental and pedantic tags are not considered consensus decisions in the Debian project, or contain so many false positives that they should not be enforced generally. If they are helpful to you, feel free to use them. If they are not helpful, feel free to ignore them. Generally, it isn’t considered necessary to override an experimental or pedantic tag if you don’t feel it applies to your package. From lintian’s man page: "If a tag is marked experimental, this means that the code that generates this message is not as well tested as the rest of Lintian, and might still give surprising results. Feel free to ignore Experimental messages that do not seem to make sense, though of course bug reports are always welcome (particularly if they include fixes).” "Pedantic tags are Lintian at its most pickiest and include checks for particular Debian packaging styles and checks that many people disagree with. Expect false positives and Lintian tags that you don't consider useful if you use this option. Adding overrides for pedantic tags is probably not worth the effort." I noticed this tag when I was reviewing the project, but I didn’t consider that it merited consideration. I use filenamemangel all the time in my watch files. However, as the package maintainer, you are always welcome to chase it down if you feel it would be a good idea. > Hi Mateusz, > > Additionally to the advice/tips of Soren, I did a build test that that is > performed as part of reproducibility testing[1] - Build after successful > build. > > When using pbuilder it can be done by adding the argument '--twice' e.g. > > sudo pbuilder build --twice <package>.dsc > > If you do this build test on vimb, it will fail showing two generated files > not being cleaned prior to a second build being configured and built. To fix > this, add a file called 'clean' to your debian directory. In that file add > the two lines below this paragraph, generate your new package and run the > pbuilder build --twice build again. It should now complete without error. > > src/config.h > version.h > > Note: This is the way I do it in this particular case, but other may have > other solutions. > > [1] https://wiki.debian.org/ReproducibleBuilds > > Regards > > Phil Phil, Thanks for catching this. I probably need to incorporate reproducible builds into my standard build pipeline. Are you aware of a simple way to add it to sbuild (like how you have with the pbuilder command above)? -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
