On Tue, 2021-06-01 at 07:07 +0200, Tobias Frost wrote: > 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. Okay, I've restored the Comment: field with the rationale for repacking. > 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. I've reinstated the wildcard section so that the Qualcomm Atheros copyright applies to the README, NOTICES.TXT, and .gitignore. > > > - 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. I've decided that a Lintian override is most appropriate, since this particular case (MIT != Expat) applies to only a couple other packages and it's important for package maintainers to validate that their variant of the MIT license is in fact the Expat license. > > > 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. Unfortunately upstream has been unresponsive and not been accepting of my patch to use GCC 11 and newer Binutils which, however, I will refresh in my merge request. In the longer-term, we'll probably be better off using Clang instead of GCC when LLVM gets Xtensa support: https://reviews.llvm.org/D64830 As soon as those patches are accepted, I plan to experiment with getting it working and spearhead the effort upstream. This would also be of benefit to the OpenBSD Project which also uses this firmware. Xtensa is a CPU architecture that is custom-fabricated for various products, hence why we have to bootstrap our cross toolchain from scratch when building this firmware. This requires patches to the GCC sources so it knows exactly what chip we're targeting. With Clang, no source-level changes will be required.
Attachment:
signature.asc
Description: This is a digitally signed message part