Bug#984901: RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 -- firmware for AR7010 and AR9271 USB wireless adapters
Control: tags -1 moreinfo
On Tue, Jun 01, 2021 at 02:22:15AM +0000, John Scott wrote:
> Control: tags -1 -moreinfo
>
> On Mon, 2021-05-31 at 20:25 +0200, Tobias Frost wrote:
> > I've took a look at your package:
> Awesome, thanks.
>
> > - d/copyright:
> > - The word "Comment:" went missing after the Files-Exlucded section.
> I don't believe this is an error. The Files-Excluded field is currently
> not specified by the machine-readable copyright specification (this is
> bug #685506), but at least the mk-origtargz manual page specifies that
> this should be what the spec calls 'formatted text', i.e. the current
> syntax should be valid:
> > (In debian/copyright, the Files-Excluded and Files-Excluded-component
> > stanzas are a part of the first paragraph and there is a blank line
> > before the following paragraphs which contain Files and other
> > stanzas. See uscan(1) "COPYRIGHT FILE EXAMPLE".)
The Files-Excluded section is used by tools like uscan to strip files from the
orig.tar. The formatted text just says that the field can extend over multiple
lines, it does not mean its free text without meaning.
TL;DR: I'm pretty sure you want the Comment: here. A quick test with
uscan --verbose --force-download will convince you too.
> > - Please review the file. I see e.g the section for "Files: *" be
> > gone, not sure if that is intentional (I did not a d/copyright
> > review)
> This was intentional.
>
> > Lintian is the same oppionion that there is something missing:
> >
> > W: open-ath9k-htc-firmware source: file-without-copyright-information
> > .gitignore
> > W: open-ath9k-htc-firmware source: file-without-copyright-information
> > NOTICE.TXT
> > W: open-ath9k-htc-firmware source: file-without-copyright-information
> > README
> Those files have no copyright information, but they are so small
> they're probably not copyrightable. There s no copyright status to
> associate with them, so it's better that the copyright file say nothing
> at all with respect to them.
I'm sorry; no.
You cannot assume that those files are not copyrightable, at minimum
that would be a question for debian-legal. Generally, copyrightabilty is a very low
barrier.
Looking at NOTICE.TXT it is definitly copyrightable and has even a copyright
statement, for example.
Looking at README, it is also definitly beyond that barrier.
*Usually* (I didnt check this particular case) such companion files in the
repo are under the same license that the other files, thereofore usually
the debian/* stanca is fine.
Strictly, if there is no copyright information, it defaults to "all rights
reserved", which means "not even distributeable."
So if in doubt, you need to ask upstream to clarify.
I guess it would be just easier to reinstanciate the * section, as ftp masters
have at least one time looked at it already and found it ok.
> > - W: open-ath9k-htc-firmware source: inconsistent-appstream-
> > metadata-license
> > debian/firmware-ath9k-htc.metainfo.xml (mit != expat)
> In my opinion this is a bug that could be fixed in Lintian. If you're
> not aware, the Expat license is a specific version of what's commonly
> known as the MIT license. The SPDX identifier (and hence the identifier
> used in the AppStream file) is MIT, although the Debian machine-
> readable copyright specification requests that one refer to the Expat
> license when that license is applicable.
>
> Basically, the copyright file referring to the Expat license is
> consistent with the AppStream metadata proclaiming that it is subject
> to the MIT license.
OK, in this case an override and a comment towards the override would
be helpful. Bonus points for filing a bug against lintian.
> > Some patch have fuzz... maybe refresh?
> If you're referring to
> Hunk #1 succeeded at 43 (offset -1 lines).
> Hunk #2 succeeded at 55 (offset -1 lines).
> Hunk #3 succeeded at 99 (offset -1 lines).
> Hunk #4 succeeded at 113 (offset -1 lines).
> Hunk #5 succeeded at 151 (offset -1 lines).
> then I believe this is normal, although refreshing the patches upstream
> shouldn't hurt.
Certainly it does not hurt to refresh.
--
Cheers,
tobi
Reply to: