Re: gnulib
Jonas Smedegaard writes: > Quoting Simon Josefsson (2024-04-18 09:34:26) >> Jonas Smedegaard writes: >> >> > That said, you are welcome to try nudge me if some concrete task >> > emerges where you image I might be of help. >> >> Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to >> allow others to help and to allow you from not having to feel a need to >> reply at all :) > > Thanks for releaving me. > > ...but then you bring up licensing, which has my special interest :-D I am terribly sorry :-) >> One of the things that bothered me with the gnulib Debian package that >> I've been too afraid to touch is the debian/copyright file. It triggers >> a lot of lintian errors: >> >> https://udd.debian.org/lintian/?packages=gnulib >> >> For reference here is current debian/copyright: >> >> https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/copyright >> >> I've seen debian/clscan/ and ran the tools there, but I don't yet feel >> comfortable patching things, and it didn't produce clean results even >> for the last version in testing before I started to work on this >> package, so I'm not convinced this toolchain is the best approach going >> forward. > > When I took over maintenance my first thought was also to get rid of the > clscan script, but then I realized how enormous a work it would be to > approach it differently and wrapped my head around the script and > adjusted it. > > Does it sound like you are in a similar situation now as I was, or is > there something in particular that makes you consider abandoning > clscan? Yes you are right. There is nothing in particular that I've found, except that I don't understand how it is supposed to work and I felt uncertain if it was worth wrapping my head around or not. >> One problem is that lintian doesn't like [REF01] in lines like this: >> >> License: FSFAP [REF01] > > I agree with lintian about the above (but we disagree on other things - > see bug#786450). I am confident that the above syntax is incorrect: > copyright format 1.0 requires a single-word shortname. That is good to establish, and I wasn't even certain of that. Then it is clear that it is the gnulib debian/copyright file that should change. And the discussion can move to what it should change into. > If you are simply not fluent in perl, then perhaps reach out to the > Debian perl team for help? Or perhaps look in the git history the tweaks > that I made - perhaps those are of inspiration to whatever issue you are > running into now? I will try to do that -- and will experiment with it to see if I get an improved copyright file out of it, maybe using a Comment: approach instead of the invalid [REF01] approach. /Simon signature.asc Description: PGP signature
Re: gnulib
Quoting Simon Josefsson (2024-04-18 09:34:26) > Jonas Smedegaard writes: > > > That said, you are welcome to try nudge me if some concrete task > > emerges where you image I might be of help. > > Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to > allow others to help and to allow you from not having to feel a need to > reply at all :) Thanks for releaving me. ...but then you bring up licensing, which has my special interest :-D > One of the things that bothered me with the gnulib Debian package that > I've been too afraid to touch is the debian/copyright file. It triggers > a lot of lintian errors: > > https://udd.debian.org/lintian/?packages=gnulib > > For reference here is current debian/copyright: > > https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/copyright > > I've seen debian/clscan/ and ran the tools there, but I don't yet feel > comfortable patching things, and it didn't produce clean results even > for the last version in testing before I started to work on this > package, so I'm not convinced this toolchain is the best approach going > forward. When I took over maintenance my first thought was also to get rid of the clscan script, but then I realized how enormous a work it would be to approach it differently and wrapped my head around the script and adjusted it. Does it sound like you are in a similar situation now as I was, or is there something in particular that makes you consider abandoning clscan? If you are simply not fluent in perl, then perhaps reach out to the Debian perl team for help? Or perhaps look in the git history the tweaks that I made - perhaps those are of inspiration to whatever issue you are running into now? > One problem is that lintian doesn't like [REF01] in lines like this: > > License: FSFAP [REF01] I agree with lintian about the above (but we disagree on other things - see bug#786450). I am confident that the above syntax is incorrect: copyright format 1.0 requires a single-word shortname. > Is the reason why this is done that you want to record a full copy of > the actual text from the particular file AND some more information? > Sometimes there is a file X with the FSFAP license and some additional > text not part of the core FSFAP license, and another file Y that also > uses FSFAP but has some OTHER additional text that you want to record? I guess so. While I maintained the package I did some cleanup of the copyright file, but did not get around to tightening the [REFnn] syntax, and I have not been in touch with the previous maintainer who introduced it, Ian Beckwith, which is why I am only guessing here. > In some other packages, I've used the Comment: field like this for > situations like that. Maybe it is applicable here? > > Files: * > Copyright: 2016 Google LLC. All Rights Reserved. >2022 Trillian Authors. All Rights Reserved. >2016 The Kubernetes Authors. >2017 Google LLC. All Rights Reserved. > License: Apache-2.0 > Comment: Quoting AUTHORS: > # This is the official list of benchmark authors for copyright purposes. > Antonio Marcedone > Google LLC > Internet Security Research Group > Vishal Kuo > > The idea is that from a legal perspective, the copyright notices and > keywords 'FSFAP' and 'Apache-2.0' with full text copy of the license is > sufficient documentation. However, for reasons like proper attribution > and having more background information, it is useful to say something > more than what's legally required, including properly quoting the > relevant files. I think the Comment: section makes for a better place > than License: fields for this. I generally agree with your approach above. Specifically for your concrete example above, I find the Comment superfluous. Also, one detail: I would avoid content in first line of the Comment field - i.e. I would move the text "Quoting AUTORS:" down on a separate line, indented same as the following lines. Arguably the syntax used above is technically permitted, but I have not seen it used. Details on that is here: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#formatted-text - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: gnulib
Jonas Smedegaard writes: > That said, you are welcome to try nudge me if some concrete task > emerges where you image I might be of help. Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to allow others to help and to allow you from not having to feel a need to reply at all :) One of the things that bothered me with the gnulib Debian package that I've been too afraid to touch is the debian/copyright file. It triggers a lot of lintian errors: https://udd.debian.org/lintian/?packages=gnulib For reference here is current debian/copyright: https://salsa.debian.org/debian/gnulib/-/blob/debian/sid/debian/copyright I've seen debian/clscan/ and ran the tools there, but I don't yet feel comfortable patching things, and it didn't produce clean results even for the last version in testing before I started to work on this package, so I'm not convinced this toolchain is the best approach going forward. One problem is that lintian doesn't like [REF01] in lines like this: License: FSFAP [REF01] Is the reason why this is done that you want to record a full copy of the actual text from the particular file AND some more information? Sometimes there is a file X with the FSFAP license and some additional text not part of the core FSFAP license, and another file Y that also uses FSFAP but has some OTHER additional text that you want to record? In some other packages, I've used the Comment: field like this for situations like that. Maybe it is applicable here? Files: * Copyright: 2016 Google LLC. All Rights Reserved. 2022 Trillian Authors. All Rights Reserved. 2016 The Kubernetes Authors. 2017 Google LLC. All Rights Reserved. License: Apache-2.0 Comment: Quoting AUTHORS: # This is the official list of benchmark authors for copyright purposes. Antonio Marcedone Google LLC Internet Security Research Group Vishal Kuo The idea is that from a legal perspective, the copyright notices and keywords 'FSFAP' and 'Apache-2.0' with full text copy of the license is sufficient documentation. However, for reasons like proper attribution and having more background information, it is useful to say something more than what's legally required, including properly quoting the relevant files. I think the Comment: section makes for a better place than License: fields for this. Does anyone have other advice related to gnulib's debian/copyright file? I have yet to fully get a grip on how this file should best reflect reality for a complex package like gnulib, but will try to do my best to resolve lintian complaints and keep it accurate and maintainable. /Simon signature.asc Description: PGP signature
