On Mon, 2024-06-10 at 15:58 -0700, Soren Stoutner wrote: > 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, I am not aware of a simple way for sbuild, sorry. Regards Phil -- Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Buy Me A Coffee: https://buymeacoffee.com/kathenasorg
signature.asc
Description: This is a digitally signed message part
