Bug#1026335: Squashing the last carl9170fw issues: ready for sponsorship

[John Scott]

On Wed, 2023-08-16 at 12:28 +0800, Paul Wise wrote:
> On Sun, 2023-08-13 at 11:51 +0000, John Scott wrote:
> 
> > Because carl9170 is largely under the GPL and we're obligated to distribute complete sources for our binaries, I've set Static-Built- Using on both gcc (because of libgcc) and Newlib.
> 
> FYI, that wasn't the correct thing to do.
> Built-Using is for license compliance cases:
> [https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using](https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using)
> Static-Built-Using is for other static linking or embedding cases.
> The static linking wiki page needs updates for Static-Built-Using and the predecessors of it used by the Rust and Golang packages.
> [https://wiki.debian.org/StaticLinking](https://wiki.debian.org/StaticLinking)

Apologies for my delayed response on this, it looks like you are absolutely right Paul. Good eye! This isn't an obvious thing, so I will do my part to make sure the dpkg manual page gets clarified. Just to be clear, preparing a second version of a package and uploading to NEW is okay to fix an important issue, right? While I'm at it, I have been informed by the Debian Installer folks that I can remove the udeb: existing practice is that firmware packages are tiny enough already that they don't bother making udebs for the Debian Installer, that's what the d-i folks say.

I'm preparing a fixed package based on a new upstream snapshot, [have uploaded to mentors.debian.net](https://mentors.debian.net/debian/pool/main/c/carl9170fw/carl9170fw_1.9.9-450-gad1c721-1.dsc), and it's in Git too for whoever here is able and willing to nab it.

Thanks everyone

--  
Homepage: [johnscott.me](https://johnscott.me)  
Contact info: [as a vCard](https://johnscott.me/me/me.vcf) and [as an LDAP directory entry](ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me)



signature.asc
Description: This is a digitally signed message part

Bug#1026335: Review of the initial packaging of the carl9170 firmware

[John Scott]

Control: tags -1 -moreinfo

Dear all,

I have uploaded a new version of carl9170fw to mentors.debian.net that 
represents my very best work. Please review it carefully. Building it requires 
the just-uploaded libnewlib-sh-elf-dev version 3.3.0+8. I tend to ramble and 
I've already written at great deal about this peculiar package, so I will just 
speak here on the recent changes.

Note that I do own carl9170 hardware and have tested this package manually.

Because carl9170 is largely under the GPL and we're obligated to distribute 
complete sources for our binaries, I've set Static-Built-Using on both gcc 
(because of libgcc) and Newlib. That's what my recent tweaks in gcc-sh-elf have 
been about.

In addition to Paul Wise, Bastian, and other folks following my libre wireless 
journey, I'd like to thank the Central Indiana Linux Users Group for cheering 
me on.

Note that this package has a udeb. Ben said this is the right thing to do for 
free firmware built from source, but I don't know enough about the Debian 
Installer to make sure it gets integrated.

This upload will generally not be installable; the only goal is to clear NEW so 
we can coordinate the handover of the firmware file from firmware-linux-free to 
firmware-carl9170 with a subsequent upload to unstable.


signature.asc
Description: This is a digitally signed message part

Bug#1040788: RFS: gcc-sh-elf/7 -- GNU C compiler for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net
Control: block 1026335 by -1

Dear mentors,

I am looking for a sponsor for my package "gcc-sh-elf":

 * Package name : gcc-sh-elf
   Version  : 7
 * License  : various
 * Vcs  : 
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf
   Section  : devel

The source builds the following binary packages:

  gcc-sh-elf - GNU C compiler for embedded SuperH devices
  libnewlib-sh-elf-dev - small ISO C standard library for embedded SuperH 
devices

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/gcc-sh-elf/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_7.dsc

Changes since the last upload:

 gcc-sh-elf (7) unstable; urgency=medium
 .
   * Include the full used Newlib source package version number in
 the libnewlib-sh-elf-dev binary package version number.
 This is necessary so we can tell what source package version was used.

This is a one-line change in debian/rules that is necessary for us to set the 
correct Built-Using field for carl9170fw; see that RFS to see the details 
spelled out. By the time you're reading this, if the moreinfo tag is removed 
from carl9170fw, then that's ready to go too and would also appreciate your 
careful review.

I will push changes to Git once this is uploaded.


signature.asc
Description: This is a digitally signed message part


smime.p7s
Description: S/MIME cryptographic signature

Bug#1026335: carl9170 needs to wait on a new gcc-sh-elf upload

[John Scott]

Control: tags -1 moreinfo

I've discovered an issue with how the Built-Using fields are generated.

Specifically, because gcc-sh-elf does not set a Built-Using field for Newlib, 
and because of the way the libnewlib-sh-elf-dev binary package is currently 
versioned, there is no way to precisely tell what version of the Newlib source 
package was used to generate libnewlib-sh-elf-dev and hence which gets baked 
into the carl9170 binaries. That means we can't set the Built-Using field right.

Fortunately this does not have to be fixed in Newlib: it can be fixed 
completely in gcc-sh-elf, so I will simply prepare a new upload that changes 
the format of the version numbers so we can tell what version of the Newlib 
source package was used. When ready, I will send an RFS for that package and 
mark it as blocking this one.


signature.asc
Description: This is a digitally signed message part


smime.p7s
Description: S/MIME cryptographic signature

Bug#1026335: RFS: carl9170fw/1.9.9-450-gad1c721-1 [ITP] -- firmware for AR9170 USB wireless adapters

[John Scott]

Control: retitle -1 RFS: carl9170fw [ITP] -- firmware for AR9170 USB wireless 
adapters

Dear mentors,

I am looking for a sponsor for my package "carl9170fw":

 * Package name : carl9170fw
   Version  : 1.9.9-450-gad1c721-1
   Upstream contact : linux-wirel...@vger.kernel.org
 * URL  : 
https://wireless.wiki.kernel.org/en/users/Drivers/carl9170.fw
 * License  : many, but mostly GPL-2.0-or-later or GPL-2.0-only
 * Vcs  : https://salsa.debian.org/kernel-team/carl9170fw
   Section  : kernel

The source builds the following binary packages:

  firmware-carl9170 - firmware for AR9170 USB wireless adapters

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/carl9170fw/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/carl9170fw/carl9170fw_1.9.9-450-gad1c721-1.dsc

This is a package that's very dear to my heart and which has gone through a 
couple rounds of review already, so I hope to make it great.

carl9170 is a fully libre driver and firmware combo for particular USB wireless 
adapters. carl9170 is already in firmware-linux-free, but this new source 
package is special: it builds the firmware from source using a cross toolchain 
that I've also packaged. Because this is firmware that runs on the CPU inside 
the Wi-Fi adapter instead of on the Debian host, it's an Arch: all package 
despite being written in C.

Because of the situation with this package shipping a file that's already in 
firmware-linux-free, this initial upload will be practically unusable: the only 
goal is to clear NEW so that the second upload (which will have appropriate 
Breaks+Replaces) can be made on a predictable timeframe. (I have, however, 
manually tested that the built firmware works.) I wonder, should I add a 
temporary Conflicts: firmware-linux-free to this initial upload since they will 
not be co-installable? I've decided not to, but let me know if I should.

I'm not very good with Git, so this upload is not in the VCS right now. I'll 
sort that out once we're uploading the package to NEW.

Also, per discussion on #debian-mentors and a recent re-reading of Debian 
Policy, I've added Built-Using fields because carl9170 is GPL and statically 
links in other libraries.

P.S. If any of my seemingly-omniscient regular sponsors are concerned, I'm 
about to fix the FTBFS in the sibling package ath9k_htc, so do not be alarmed 
by that.


signature.asc
Description: This is a digitally signed message part


smime.p7s
Description: S/MIME cryptographic signature

Bug#1038959: RFS: gcc-sh-elf/6 -- GNU C compiler for embedded SuperH devices plus Newlib

[John Scott]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gcc-sh-elf":

 * Package name : gcc-sh-elf
   Version  : 6
 * License  : many, but primarily GPL 3+ for GCC and permissive 
licenses for Newlib
 * Vcs  : 
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf
   Section  : devel

The source builds the following binary packages:

  gcc-sh-elf - GNU C compiler for embedded SuperH devices
  libnewlib-sh-elf-dev - small ISO C standard library for embedded SuperH 
devices

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/gcc-sh-elf/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_6.dsc

Changes since the last upload:

 gcc-sh-elf (6) unstable; urgency=medium
 .
   * Upload to unstable.

Indeed, this is simply an upload of the package from experimental to unstable 
which uses GCC 13. GCC 13 is about to migrate to Trixie, so it's an appropriate 
time.
Even though a rare issue that is unlikely to happen again kept this package (w/ 
GCC 12) from migrating to Bookworm, I'm nevertheless adamant that it's 
appropriate for a stable release, and it's necessary to build carl9170 which 
I'm about to resume my work on after a hiatus. I'm going to be resuming my 
contributions to Debian and figured this would be a good start.

Thanks!


signature.asc
Description: This is a digitally signed message part


smime.p7s
Description: S/MIME cryptographic signature

Bug#1026362: Upload of binutils-sh-elf

[John Scott]

Hi,

So, my package got auto-rejected. I talked to the FTP Masters, and
they'd much rather that a workaround be incorporated into my package
than them having to manually make it pass through. I've uploaded the
one-line change to mentors.debian.net; if you could upload it once more,
there shouldn't be any problems now.

Thank you,
John


signature.asc
Description: This is a digitally signed message part

Bug#1026362: RFS: binutils-sh-elf/2 -- GNU binary utilities for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net 
debian-sup...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "binutils-sh-elf":

 * Package name : binutils-sh-elf
   Version  : 2 (this is a native source package)
 * URL  : https://sourceware.org/binutils/
 * License  : GPL-3+
 * Vcs  : 
https://salsa.debian.org/electronics-team/toolchains/binutils-sh-elf (but see 
below)
   Section  : devel

The source builds the following binary packages:

  binutils-sh-elf - GNU binary utilities for embedded SuperH devices

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/binutils-sh-elf/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/b/binutils-sh-elf/binutils-sh-elf_2.dsc

Changes since the last upload:

 binutils-sh-elf (2) unstable; urgency=medium
 .
   * Bump Standards-Version to 4.6.2, no changes required.
   * Add new dependencies on libdebuginfod and libzstd

I also update the Lintian overrides to match newer Lintian output. I
will push the changes to Git after the upload has been accepted.

This upload does *not* need to go before gcc-sh-elf, they can be done in
any order. None of these changes should affect carl9170 either.

Happy hacking!


signature.asc
Description: This is a digitally signed message part

Bug#1026335: RFS: carl9170fw/1.9.9-427-gecb68a7-1 [ITP] -- firmware for AR9170 USB wireless adapters

[John Scott]

Package: sponsorship-requests
Severity: wishlist
Control: block 994625 by -1
X-Debbugs-CC: debian-ker...@lists.debian.org b...@debian.org

Dear mentors,

I am looking for a sponsor for my package "carl9170fw":

 * Package name : carl9170fw
   Version  : 1.9.9-427-gecb68a7-1
   Upstream contact : linux-wirel...@vger.kernel.org
 * URL  : 
https://wireless.wiki.kernel.org/en/users/Drivers/carl9170.fw
 * License  : many, but mostly GPL 2 or later
 * Vcs  : https://salsa.debian.org/kernel-team/carl9170fw (but see 
below)
   Section  : kernel

The source builds the following binary packages:

  firmware-carl9170 - firmware for AR9170 USB wireless adapters

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/carl9170fw/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/carl9170fw/carl9170fw_1.9.9-427-gecb68a7-1.dsc

Changes for the initial release:

 carl9170fw (1.9.9-427-gecb68a7-1) experimental; urgency=medium
 .
   * Initial release (Closes: #994625)

This package is rather unusual and there is a lot to be said for it.
Currently the carl9170 firmware is already in firmware-linux-free, so
why do we need this package? At the moment firmware-linux-free ships a
pre-built blob. This package builds the firmware from the source using
the gcc-sh-elf cross compiler I've packaged. As of this writing there is
an open RFS for gcc-sh-elf, but that's merely coincidental; the version
of gcc-sh-elf already in the archive is adequate to build this package,
so gcc-sh-elf does 혯혰혵 need to be uploaded first.

I need to nuke the Git repository (which I currently don't have
permission to do) to start fresh and account for the Files-Excluded
(upstream accidentally shipped an unneeded binary, not of the firmware,
in the source tree and it rightfully raises many alarm bells with
Lintian). So for now, please ignore the Git repo.

Unless you manually delete the carl9170 firmware from your system, this
package will not be installable at all. We'll have to do Breaks+Replaces
in order for this package to take over the firmware at a later time.
After we clear NEW, we can prepare an upload to unstable, coordinate
which version of firmware-linux-free will be the one to drop the
firmware, and add the fields appropriately.

I have the appropriate hardware and can confirm this firmware works. If
you don't have the hardware, I suppose you'll just have to take my word
for it. If anyone is interested in co-maintenance of this package, I'll
be glad to send you appropriate hardware however.

Because of what this package is, there's very little we can do quality
assurance-wise; we obviously can't do an autopkgtest to check that a
network connection works, say. I try to make up for this with QA efforts
for gcc-sh-elf.

We ship a Git snapshot because like other firmware projects, the version
number is very significant and doesn't get incremented for non-interface
breaking changes. We do however need to keep up with fixes for building
with newer versions of GCC and Newlib.

Happy hacking!


signature.asc
Description: This is a digitally signed message part

Bug#1026308: RFS: gcc-sh-elf/5 -- GNU C compiler for embedded SuperH devices

[John Scott]

On Sun, 2022-12-18 at 08:49 +0100, John Paul Adrian Glaubitz wrote:
> I assume you're missing libreadline-dev from BuildDepends.
You are, of course, absolutely right. I forgot to build in a clean
environment. This has been fixed in a new upload to mentors.debian.net
and a build in a clean environment succeeds now.


signature.asc
Description: This is a digitally signed message part

Bug#1026308: RFS: gcc-sh-elf/5 -- GNU C compiler for embedded SuperH devices

[John Scott]

Control: owner -1 glaub...@physik.fu-berlin.de

On Sun, 2022-12-18 at 08:09 +0100, John Paul Adrian Glaubitz wrote:
> I can sponsor this upload.

Thanks so much! Please go ahead whenever you're ready.


signature.asc
Description: This is a digitally signed message part

Bug#1026308: RFS: gcc-sh-elf/5 -- GNU C compiler for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net 
debian-sup...@lists.debian.org

Dear mentors and fellow Electronics Team members,

I am looking for a sponsor for my package "gcc-sh-elf":

 * Package name : gcc-sh-elf
   Version  : 5
 * License  : GPL-3+
 * Vcs  : 
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf
   Section  : devel

The source builds the following binary packages:

  gcc-sh-elf - GNU C compiler for embedded SuperH devices
  libnewlib-sh-elf-dev - small ISO C standard library for embedded SuperH 
devices

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/gcc-sh-elf/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_5.dsc

Changes since the last upload:

 gcc-sh-elf (5) experimental; urgency=medium
 .
   * Bump Standards-Version to 4.6.2, no changes required.
   * Switch to GCC 13.

This upload is so we can investigate issues as new GCC 13 snapshots get
uploaded. Furthermore, I expect it will be helpful for the reviewers of
carl9170 when I upload that in a few days. I will push my changes to Git
once the package is uploaded.

I have not yet investigated the test suite regressions, but this package
is going to experimental, so that's okay. The comprehensive autopkgtests
still pass, and those are more important.

Unless you happen to have an AR9170 wireless adapter, you probably don't
have real hardware to test this with. Fortunately this package includes
a Wine-like wrapper called sh-elf-run that enables running the built
binaries, so you can test this package even if you know nothing more
than the basics of C.


signature.asc
Description: This is a digitally signed message part

Bug#1011670: RFS: open-ath9k-htc-firmware/1.4.0-108-gd856466+dfsg1 -- firmware for AR7010 and AR9271 USB wireless adapters

[John Scott]

Thanks for taking a look, Bastian. I believe the changes are
satisfactory now, except that after close inspection I found that those
files specified as being covered by the BSD-3-Clause license are still
covered by it. Please me know if I'm misunderstanding something.



signature.asc
Description: This is a digitally signed message part

Bug#1011670: RFS: open-ath9k-htc-firmware/1.4.0-108-gd856466+dfsg1 -- firmware for AR7010 and AR9271 USB wireless adapters

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-ker...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "open-ath9k-htc-firmware":

 * Package name    : open-ath9k-htc-firmware
   Version : 1.4.0-106-gc583009+dfsg1-2
   Upstream Author : ath9k_htc...@lists.infradead.org
 * URL : https://github.com/qca/open-ath9k-htc-firmware
 * License : BSD-3-Clause-Clear, Expat, BSD-3-Clause-Clear or
GPL-2, GPL-2+-with-linking-exception, GPL-2, FSFAP-with-endorsements-
clause, BSD-3-Clause-Clear or GPL-2, and BSD-4-Clause, BSD-3-Clause or
GPL-2
 * Vcs :
https://salsa.debian.org/jscott/open-ath9k-htc-firmware
   Section : kernel

The source builds the following binary packages:

  firmware-ath9k-htc - firmware for AR7010 and AR9271 USB wireless
adapters

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/open-ath9k-htc-firmware/

Alternatively, you can download the package with 'dget' using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/o/open-ath9k-htc-firmware/open-ath9k-htc-firmware_1.4.0-106-gc583009+dfsg1-2.dsc

Changes since the last upload:

 open-ath9k-htc-firmware (1.4.0-106-gc583009+dfsg1-2) unstable;
urgency=medium
 .
   * Add package version control info.
   * Clean up the copyright file.
 - Distinguish the BSD 3-Clause Clear variant from the conventional
one.
 - Make conformant to DEP-5 specification for machine readability.
   * Build cross toolchain with Binutils 2.36 and GCC 12 with patch.

This package was previously uploaded, but failed to clear NEW because my
introduction of a udeb wasn't fully vetted. This upload drops the udeb
so we can fix the FTBFS; perhaps it can be reintroduced later.

I think Bastian Germann has been watching this package closely, so allow
a little time for him to review this RFS.

I would like to move the Salsa repo into the Debian namespace as he
suggested; could somebody create this for me? My Salsa username is
'jscott'

Thanks everyone!


signature.asc
Description: This is a digitally signed message part

Bug#1011383: RFS: gcc-sh-elf/4 -- GNU C compiler for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net

Dear mentors,

I am looking for a sponsor for my package "gcc-sh-elf":

 * Package name    : gcc-sh-elf
   Version : 4
 * License : various
 * Vcs :
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf
   Section : devel

The source builds the following binary packages:

  gcc-sh-elf - GNU C compiler for embedded SuperH devices
  libnewlib-sh-elf-dev - small ISO C standard library for embedded
SuperH devices

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/gcc-sh-elf/

Alternatively, you can download the package with 'dget' using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_4.dsc

This is just an upload of the existing experimental package to unstable
along with a Standards-Version bump.
It was uploaded to experimental because of a serious regression in GCC
12, but it has since been fixed for the most part and I'm happy to
upload it to unstable now.

Otherwise, I do not believe new test failures deserve additional
attention. I believe the autopkgtests offer very good coverage for this
package; they all pass. Furthermore, I've been able to build carl9170fw
using GCC 12 without a problem. (I'll be resurrecting my RFS for
carl9170fw soon.)

I'll probe the reproducible builds situation soon, but this should not
postpone the migration to GCC 12.


signature.asc
Description: This is a digitally signed message part

Bug#1008891: RFS: gcc-sh-elf/3 -- GNU C compiler for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian-sup...@lists.debian.org
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net

Dear mentors and other interested parties,

I am looking for a sponsor for my package "gcc-sh-elf":

 * Package name    : gcc-sh-elf
   Version : 3
 * License : GPL-3+
 * Vcs :
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf
   Section : devel

The source builds the following binary packages:

  gcc-sh-elf - GNU C compiler for embedded SuperH devices
  libnewlib-sh-elf-dev - small ISO C standard library for embedded
SuperH devices

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/gcc-sh-elf/

Alternatively, you can download the package with 'dget' using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_3.dsc

Changes since the last upload:

 gcc-sh-elf (3) experimental; urgency=medium
 .
   * Switch to GCC 12.
   * Improve reproducibility by using tools in non-usrmerge locations
 with thanks to Vagrant Cascadian for the patch (Closes: #1003500)
   * Switch non-portable usage of echo to printf (Closes: #1003501)
 Thanks again to Vagrant.

Thanks to my running the GCC testsuite, which is uncommon for a cross-
compiler package, I've discovered a serious regression in GCC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
This has not been fixed yet, and hence is why this upload is going to
experimental. When this gets fixed, I will make an additional
autopkgtest for it and tighten the gcc-12-source build-dep so it passes.

The goals of this upload are
 * to allow checking that carl9170fw builds with both GCC 11 and 12 by
reviewers when carl9170fw is ready
 * to see if the package is fully reproducible now, and
 * to catch any FTBFS issues that may arise with new GCC 12 uploads

Before uploading to unstable, I would also like to take additional time
to check for testsuite regressions, which of course anyone is welcome to
help with. Knowledge of GCC internals or its test suite is not needed,
as I've been able to do without.


signature.asc
Description: This is a digitally signed message part

Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters

[John Scott]

Control: tags -1 moreinfo

Hi Paul,

Thanks for your very detailed review of carl9170fw. I'm still making my
changes to the package and will give you a poke and remove the moreinfo
tag once I have an upload ready for re-review.

> I don't think udebs are needed for firmware packages, none of the other
> WiFi firmware packages in Debian have them.
You might like to have a look at this mail from Ben Hutchings:
https://lists.debian.org/msgid-search/179d6d32466dd13962a3aab251c45242fbf2d8ae.ca...@decadent.org.uk
The reason that none of the other Wi-Fi firmware packages have them is
because they're all non-free (with the exception of ath9k_htc).

My understanding—which was most definitely not articulated by Ben—is
that the Debian Installer has a mechanism for loading the (non-free)
firmware from the ordinary .debs. Since the installer needs to have
logic to look for non-free firmware on removable media at runtime
anyway, that's quite a different situation to most that warrant udebs,
where the udeb is a "built-in" of the installer.

FYI, open-ath9k-htc-firmware is in NEW because my most recent upload
likewise adds a udeb for it.

> If the package is actually needed it should be named -udeb not -di,
> since other udebs use -udeb.
I wasn't sure if there was any established convention; my thread "Naming
convention for udebs: -udeb/-installer suffix" didn't garner any
pertinent responses. I've switched the name though.

> Several files have missing/incorrect information in debian/copyright,
> please do a full audit of the code looking for copyright/license info.
> 
>  * tools/include/list.h is LGPL
>  * tools/include/frame.h is partly from Linux, unknown copyright
>  * include/shared/eeprom.h also contains ISC code
These are all good catches, I'm working on incorporating them and doing
a slow and careful review.

> DEB_BUILD_OPTION_PARALLEL doesn't appear to be a standard variable,
> please switch to DEB_BUILD_OPTIONS=parallel=N instead, see Debian
> Policy, section 4.9.1 and debhelper(7) and dpkg-buildpackage(1).
I think you're mistaken here, you should take a look at
/usr/share/dpkg/buildopts.mk which I include via an include directive in
debian/rules. Basically, DEB_BUILD_OPTION_PARALLEL is a helper macro for
the value of parallel from DEB_BUILD_OPTIONS; these are one and the
same.

There's a chance of the DEB_BUILD_OPTION_PARALLEL Makefile macro still
being unset, so what this line does in my Makefile:
DEB_BUILD_OPTION_PARALLEL ?= 1
is set it to 1 if it's not set in one's DEB_BUILD_OPTIONS. That way,
calls like
make -j$(DEB_BUILD_OPTION_PARALLEL)
won't become
make -j
which would be very bad.

> Some things that would be nice to fix at some stage:
> 
> Nothing in debian/rules references .config so you can drop that from
> before the execute_before_dh_auto_configure target.
That's true. My intent was that, since it's a hidden directory, it would
help remind one that that directory gets created. It seems to've only
caused confusion, so I'll pull it.

> It seems like the Homepage should be the carl9170.fw firmware wiki page
> instead of the carl9170 driver wiki page.
> 
> https://wireless.wiki.kernel.org/en/users/drivers/carl9170.fw
Good catch, I will fix that.

> I would express the license of include/shared/fwcmd.h etc as GPL-2-only
> && ISC rather than putting a copy of the ISC license in a comment.
I agree that this is sensible.

> bug-presubj isn't well wrapped. I'm not sure if wrapped or unwrapped is
> the best option for this file though.
Indeed, the documentation is rather old and terse and doesn't address
this issue. I'll probably ask the Reportbug folks and send them a MR
updating the docs.

> Please ask upstream to make a new release, it has been a very long time
> since the last one.
I will do after making some of the following important changes.

> Please ask upstream to update their copies of code from the Linux
> kernel and other external sources to the latest versions.
I can probably help them with this.

> Please ask upstream to send FindUSB-1.0.cmake & libusb-zeropacket.diff
> to libusb upstream and then remove them from carl9170fw.
I will ask, but with all due respect, I think this is lower priority and
that I'll have limited ability to help them.

> Please ask upstream to delete FindPackageHandleStandardArgs.cmake,
> since that is now available from cmake upstream and from Debian cmake.
> Potentially cmake_minimum_required will need to be bumped for this.
Will do.

> Please ask upstream to include the copyright information
> for carlfw/src/memcpy.S and carlfw/src/memset.S in the files.
Especially since it is copyleft, I will definitely prioritize this.

> Please ask upstream to update the COPYRIGHT file.
I will be happy to do this.

> Please send upstream some changes that would allow building the
> upstream source using a pre-packaged toolchain like the Debian one.
> 
> Please also figure out how to eliminate the other debian/rules
> workarounds.
I do not have a grasp, 

Re: Bug#1003306: RFS: mbedtls/2.28.0-0.1 [NMU] -- lightweight crypto and SSL/TLS library

[John Scott]

On Sat, 2022-01-08 at 16:54 +0100, Andrea Pappacoda wrote:
> (correct me if I'm wrong, but I believe that using Apache-2.0 libraries in 
> GPL 
> software is not allowed).
It depends on the version of the GPL at play. If it's GPL 3.0 (or
later), then Apache 2.0 is usually regarded as fully compatible with it,
so that they may be combined in the same work.

However, the Apache 2.0 license is generally regarded as incompatible
with GPL < 3.0. This is due to Apache 2.0 having a patent clause,
meanwhile the GPL before 3.0 doesn't have one.

> MbedTLS is usually released under the terms of the Apache 2.0 license,
> while LTS versions are licensed under the Apache-2.0 OR 
> GPL-2.0-or-later, a thing that many users really appreciate
Indeed, sticking to LTS releases may be quite important for this reason
if there's any GPL-2.0-only software in Debian utilizing mbed TLS.




signature.asc
Description: This is a digitally signed message part

Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters

[John Scott]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-ker...@lists.debian.org

Dear mentors and Kernel Team,

I'm looking for a sponsor for my package "carl9170fw":

 * Package name    : carl9170fw
   Version : 1.9.9-399-gcd480b9-1
   Upstream Author : linux-wirel...@vger.kernel.org
 * URL :  
  https://wireless.wiki.kernel.org/en/users/Drivers/carl9170
 * License : many; the binary is effectively GPL 2.0 only
 * Vcs : https://salsa.debian.org/kernel-team/carl9170fw
   Section : kernel

It builds those binary packages:

  firmware-carl9170 - firmware for AR9170 USB wireless adapters
  firmware-carl9170-di - firmware for AR9170 USB wireless adapters -
udeb

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/carl9170fw/

Alternatively, one can download the package with dget using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/c/carl9170fw/carl9170fw_1.9.9-399-gcd480b9-1.dsc

This is the initial upload of the carl9170 libre wireless firmware.
Although it's already shipped in firmware-linux-free, this package will
build it from source using the already-packaged SuperH cross-compiler.

The package will not yet be installable unless one manually deletes the
carl9170fw binary on their system. The goal of this upload is just to
get the package through NEW. After it clears NEW, we'll be able to do
the handover of the firmware by (in order, hopefully within the span of
a day or so):
 * having firmware-carl9170 add Breaks+Replaces on firmware-linux-free
and uploading to unstable
 * taking the firmware out of firmware-linux-free
 * having firmware-linux-free add Recommends: firmware-carl9170
 * and then uploading firmware-linux-free to unstable

I don't expect that the udeb will be used by the Debian Installer
anytime soon because I still have to learn how to make that happen, but
based on previous discussions I know it will be necessary.

It's not strictly necessary (they can be done in either order), but a
sponsor who wants to help could also upload gcc-sh-elf v2 for me. That
RFS is #1002582.

I own the hardware and can affirm that this package works with it.


signature.asc
Description: This is a digitally signed message part

Bug#1002582: RFS: gcc-sh-elf/2 [RC] -- GNU C compiler for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net

Dear mentors and Electronics Team,

I'm looking for a sponsor for my package "gcc-sh-elf":

 * Package name    : gcc-sh-elf
   Version : 2 (this is a native package)
 * License : GPL-3+
 * Vcs : 
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf
   Section : devel

It builds those binary packages:

  gcc-sh-elf - GNU C compiler for embedded SuperH devices
  libnewlib-sh-elf-dev - small ISO C standard library for embedded
SuperH devices

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/gcc-sh-elf/

Alternatively, one can download the package with dget using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_2.dsc

Changes since the last upload:

 gcc-sh-elf (2) unstable; urgency=medium
 .
   * Disable building libcc1, which is superfluous. (Closes: #1001273)
   * Make new source-only upload to enable testing migration.

In addition, I marked gcc-sh-elf Multi-Arch: foreign and set the
homepages for the respective binary packages instead of the source
package since we build Newlib as well.

There are no regressions in the GCC test suite; there seem to be 42
unique failures (on amd64 and arm64 at least) as determined by
grep -E "^FAIL" ../buildlog.txt | cut -d ' ' -f 2 | uniq | wc -
l
and these are the same ones as for the first upload with GCC 11.2.0-12.
The autopkgtests are numerous and still passing and I don't anticipate
any issues with this building on all architectures as it has before.

Thanks,
John


signature.asc
Description: This is a digitally signed message part

Bug#996552: RFS: newlib/3.3.0-1.2 [NMU] -- C library and math library for embedded systems

[John Scott]

On Fri, 2021-10-15 at 12:24 +0200, John Paul Adrian Glaubitz wrote:
> So, do you want me to upload newlib or do you want Tobias to do it?
I think it would be more appropriate if you would. Just be sure to do
it to a delayed queue for a minimum of two weeks, and send a mail to
996552-d...@bugs.debian.org
to close this RFS once you've done that.

P.S. We don't have to wait on Newlib to get binutils-sh-elf and gcc-sh-
elf through NEW; the latter can clear it via experimental since newlib-
source is already there. If you could find the time, I would really
appreciate if you could sponsor the former (#985563) and the latter
(#993671) as well.

Thank you very much for your time


signature.asc
Description: This is a digitally signed message part

Bug#996552: RFS: newlib/3.3.0-1.2 [NMU] -- C library and math library for embedded systems

[John Scott]

On Fri, 2021-10-15 at 12:07 +0200, John Paul Adrian Glaubitz wrote:
> What about the Salsa repository? Is it going to be updated?
I've sent a merge request, and in fact did so a long time ago before my
first NMU, but since the maintainers have been unresponsive it hasn't
gotten merged. The Git repo is in collaborative maintenance, but since
I'm not a Debian member that means nothing for me.

My Salsa repository I've been working in is at
https://salsa.debian.org/jscott/newlib
and the merge request is
https://salsa.debian.org/debian/newlib/-/merge_requests/20

If necessary, I'll probably ask my sponsor for my first salvaging
upload to grant me Salsa access. Alternatively, I might use an
Electronics Team Salsa repo. It's a relatively unimportant decision in
my opinion and I'm on the LowThresholdNMU list anyway, so I'll deal
with that when the time comes.


signature.asc
Description: This is a digitally signed message part

Bug#996552: RFS: newlib/3.3.0-1.2 [NMU] -- C library and math library for embedded systems

[John Scott]

On Fri, 2021-10-15 at 11:56 +0200, John Paul Adrian Glaubitz wrote:
> Are you planning to adopt the package?
Yes, I'm intending to salvage it and become the maintainer (the ITS is
#996432). I think I'll keep it under the umbrella of the Electronics
Team.


signature.asc
Description: This is a digitally signed message part

Bug#996552: RFS: newlib/3.3.0-1.2 [NMU] -- C library and math library for embedded systems

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net, 
glaub...@physik.fu-berlin.de
Control: affects -1 src:newlib

Dear mentors,

I am looking for a sponsor for my package "newlib":

 * Package name    : newlib
   Version : 3.3.0-1.2
   Upstream Author : various Newlib contributors
 * URL : https://sourceware.org/newlib/
 * License : various non-copyleft licenses
 * Vcs : https://salsa.debian.org/debian/newlib
   Section : devel

It builds those binary packages:

  libnewlib-dev - C library and math library intended for use on embedded 
systems
  libnewlib-doc - C library and math library intended for use on embedded 
systems (doc)
  libnewlib-arm-none-eabi - C library and math library compiled for bare metal 
using Cortex A/R/M
  newlib-source - C library and math library for embedded systems (source)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/newlib/

Alternatively, one can download the package with dget using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/n/newlib/newlib_3.3.0-1.2.dsc

Changes since the last upload:

 newlib (3.3.0-1.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Upload to unstable.

This is merely a re-upload of my previous NMU to unstable, now that it
has cleared NEW in experimental.

For those who aren't in the loop, the purpose of my NMU has been to
introduce a newlib-source binary package. This binary package includes
the source of Newlib so that it can be extracted into a combined tree
at build time of various GCC packages, such as my gcc-sh-elf.

This approach to building Newlib for the various ports brings many
advantages which I shall not espouse in detail here, including
bootstrappability and, when combined with an appropriate simulator from
GDB, being able to run the GCC test suite.

I have filed an Intent To Salvage (ITS) Newlib and have not gotten any
pushback yet, but this is still best dealt with an NMU right now given
that was very recent. This should probably go into a delayed queue to
be on the safe side.

Once this package is in unstable, that'll be the last blocker for
uploading gcc-sh-elf (and hence carl9170fw) to unstable. The latter is
important because the Kernel Team is working to accommodate my new
source package by dropping carl9170.fw from the next firmware-linux-
free upload so I can take it over.

(Well, there's still one other blocker to uploading carl9170fw, but
that's not relevant; I'm waiting to hear back from someone about the
copyright situation.)


signature.asc
Description: This is a digitally signed message part

Handling files with no copyright notices, many contributors

[John Scott]

Hi,

My question is more to do with the practical ramifications of an upload
than the legal ones, so I'm directing my query here rather than debian-
legal.

I'm packaging carl9170fw (which is already present in Debian main, but
not built from source yet), and this includes a header file called
ch9.h that's taken almost verbatim from the Linux kernel source.

It includes a statement that the license is GPL 2 only with system
calls note (basically a GPL exception), and it's already distributed as
part of the kernel, so surely it's free. However, I'm having trouble
figuring out what to put in my DEP-5 copyright file.

Linux Git shows that this file has had too many contributors to
enumerate, and in fact it's been in Linux since before 2.6.12-rc2,
which is the oldest version in the main repo's history.

Documenting everyone that has ever contributed to this file would take
an immense amount of time and is beyond practical. What's the best
remedy that would satisfy the FTP masters as well as satisfy
prospective sponsors? In this statement from the FTP team [1], they
said that further exceptions for cases like this would not be allowed.

[1] https://lists.debian.org/debian-devel-announce/2018/10/msg4.html


signature.asc
Description: This is a digitally signed message part

Bug#994770: RFS: binutils-m68hc1x/1:3 -- GNU binary utilities for Motorola's 68HC11/12 targets

[John Scott]

> I have no idea how we're going to address this. I think I'll file a bug
> and see if they're willing to revert as soon as I can identify all of
> the affected packages.
I've filed a bug and marked it as a blocker of this issue, but in the
admittedly short time since I filed it Wednesday I haven't gotten a
response. If you would prefer to workaround this issue instead, setting
the DH_COMPAT environment variable to 10 when calling dh_auto_configure
(which we have to override anyway) does the right thing. DH_COMPAT=11
is what introduced passing --runstatedir to the configure script.

My changes to binutils-sh-elf are at
https://salsa.debian.org/electronics-team/toolchains/binutils-sh-elf/-/commit/cdccb05b
if you would like to take a look.


signature.asc
Description: This is a digitally signed message part

Bug#994770: RFS: binutils-m68hc1x/1:3 -- GNU binary utilities for Motorola's 68HC11/12 targets

[John Scott]

Hi Vincent,

I'm very glad to see that you've been working on this. From an initial
skim of your package, things look very good, and I'm more pleased to
see that you've based your work off of binutils-sh-elf and the
PackagingLessCommonBinutilsTargets guide.

About the build failure Adam had, I'm afraid a breaking change was
introduced in the autoconf2.69 package (2.69-3) that affects all of our
packages:
> autoconf2.69 (2.69-3) unstable; urgency=medium
> 
>   * Don't apply the add-runstatedir backport, not needed in the
> context of this package, and generates different output not 
> needed for GCC.

I have no idea how we're going to address this. I think I'll file a bug
and see if they're willing to revert as soon as I can identify all of
the affected packages.


signature.asc
Description: This is a digitally signed message part

Bug#993671: RFS: gcc-sh-elf/1 [ITP] -- GNU C compiler for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net, nico...@debian.org
Control: block -1 by 985563
Control: block 986778 by -1

Dear mentors,

I am looking for a sponsor for my package "gcc-sh-elf":

 * Package name    : gcc-sh-elf
   Version : 1
 * License : GPL-3+
 * Vcs : 
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf.git
   Section : devel

It builds those binary packages:

  libnewlib-sh-elf-dev - small ISO C standard library for embedded SuperH 
devices
  gcc-sh-elf - GNU C compiler for embedded SuperH devices

To access further information about this package, please visit the
following URL or check out the ITP (#986778):

  https://mentors.debian.net/package/gcc-sh-elf/

Alternatively, one can download the package with dget using this
command, or use gbp to fetch it from the VCS:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_1.dsc

A few remarks are in order about this package:

 * binutils-sh-elf needs to uploaded either in tandem or before this
package, hence the Blocks relationship, because GCC needs Binutils

 * despite the name, this source package builds not just the GNU C
compiler, but it also builds Newlib plus a simulator from the GDB
sources which gets installed as sh-elf-run. A rationale is in
README.source, but basically this avoids bootstrap problems/circular
dependencies and builds the right parts of GCC and Newlib in order, as
well as enable running the GCC test suite, which isn't normally
possible when building a cross compiler.

 * sh-elf-run is a Wine or qemu-user-style program which allows running
the bare metal binaries. Although there's a lot of functionality not
supported without the aid of an operating system, there is some
functionality that is, and this is tested by extensive DEP-8
autopkgtests.

 * The libnewlib-sh-elf-dev package intentionally does not include a
Built-Using relation on the Newlib source package, because the Newlib
binaries are subject to permissive licenses that do not require
distribution of the source (unlike other parts of the GNU toolchain),
and hence it would actually be a violation of Debian Policy to include
the relation.

 * Nicolas has previously told me that my inclusion of the copyright
information for the binaries in the as-installed copyright files is
unnecessary according to the FTP Team for GCC and GDB, but I choose to
conform to a strict reading of Debian Policy that requires distribution
of it anyway, if nothing else as a courtesy to users.

 * The Debian Electronics team has consented to me using their
namespace, but I haven't found a sponsor from them yet, so I'm seeking
outside sponsors as well.

 * This package is going to experimental because that's the only suite
that currently provides newlib-source, but in all respects I believe
this package is suitable for unstable.

 * My primary motivation for this package is to build the carl9170
libre wireless firmware. It's not ready to share yet, but I can attest
that this package is sufficient to build my draft carl9170fw package
and it works fine. I hope that if one don't have hardware to test with
that the autopkgtests can win over a sponsor's confidence in the
package's correctness.

 * The Lintian warning I: override_dh_auto_test-does-not-check-
DEB_BUILD_OPTIONS does not apply to packages using compatibility level
13. There is already a Lintian bug for this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950455


signature.asc
Description: This is a digitally signed message part

Bug#984901: open-ath9k-htc-firmware upload is now release-critical

[John Scott]

Control: retitle -1 RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 
[RC] -- firmware for AR7010 and AR9271 USB wireless adapters

Thanks to the Reproducible Builds folks for notifying me, the current
package is FTBFS due to the Binutils 2.37 upload to unstable.
Fortunately my package already addressed this, so I've just switched
the changelog to unstable.


signature.asc
Description: This is a digitally signed message part

Help with a syntax error from an autoreconf'ed configure script

[John Scott]

Hello,

It seems that the upload of binutils-source 2.37 has broken my to-be-
uploaded package binutils-sh-elf; it worked fine with binutils-source
2.36. My package is available at
https://mentors.debian.net/package/binutils-sh-elf/

I'm looking for anyone that knows Autoconf wizardry to help sort this
out. The Binutils sources contain many subdirectories that all need
autoreconf-ing, so I call autoreconf on all of these subdirectories,
including libiberty, in debian/rules. This still succeeds.

At configuration time, however, we get
Configuring in ./libiberty
configure: creating cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
...
checking for x86_64-linux-gnu-ranlib... ranlib --plugin 
/usr/lib/gcc/x86_64-linux-gnu/11/liblto_plugin.so
binutils/libiberty/configure: line 2911: syntax error near unexpected token 
`PLUGIN_OPTION'
binutils/libiberty/configure: line 2911: `GCC_PLUGIN_OPTION(PLUGIN_OPTION)'

This seems bizarre. Why would autoreconf produce a script with a syntax
error, or is dash not robust enough to use what construct it's trying
in the script? I could not find an upstream issue about this.

Note that in my build log above, I'm using GCC 11, but I don't think
this is related to the issue at hand. If it were to turn out that GCC
11 is the culprit, this needs to be addressed anyway.

Thanks for your time.
John


signature.asc
Description: This is a digitally signed message part

Bug#981702: RFS: privacybadger/2021.2.2-1 -- browser extension automatically learns to block invisible trackers

[John Scott]

On Wed, 2021-06-09 at 17:07 +0200, Tobias Frost wrote:
> >     * Friendly takeover back into the WebExt team.
> 
> I can't find any documentation about that have been ACKed by the
> current maintainer. (CCing Jonas so that he can response/confirm, to
> put it on record that this is not an hijack…)
I've attached a digitally signed message from him asserting it's okay.

I've applied for an unblock request with the release team to see about
uploading it to unstable.


Re:_Privacy_Badger_WebExtension_package.mbox
Description: application/mbox


signature.asc
Description: This is a digitally signed message part

Bug#984901: RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 -- firmware for AR7010 and AR9271 USB wireless adapters

[John Scott]

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.



signature.asc
Description: This is a digitally signed message part

Bug#987169: RFS: newlib/3.3.0-1.1 [NMU] -- C library and math library for embedded systems

[John Scott]

Control: tags -1 -moreinfo

On Tue, 08 Jun 2021 21:38:56 + John Scott 
wrote:
> On Tue, 2021-06-01 at 07:52 +0200, Tobias Frost wrote:
> > > I haven't encountered the maintainer previously, but believe in
> > > good faith that these changes would be welcome and that the
> > > LowThresholdNmu criterion are met by addressing a bug with
> > > important severity. My interest in this bug, to introduce a 
> > > newlib-source binary package, is to unblock my progress on
> > > gcc-sh-elf, which is otherwise almost ready.
> > Probably still a good idea to CC them or file a bug in the BTS to
> > document your intentions, as adding a binary package is not a usual
> > change, even if the NMU criterias are fulfilled.
> Okay, I made some noise on the bug report today and Cc'ed the debian-
> toolchain mailing list on it. I'm not touching the moreinfo tag yet 
> to give them time to respond.

It's been about two weeks and I've garnered some interest from others,
so I'm removing the moreinfo tag.


signature.asc
Description: This is a digitally signed message part

Bug#987169: RFS: newlib/3.3.0-1.1 [NMU] -- C library and math library for embedded systems

[John Scott]

On Tue, 2021-06-01 at 07:52 +0200, Tobias Frost wrote:
> > I haven't encountered the maintainer previously, but believe in
> > good faith that these changes would be welcome and that the
> > LowThresholdNmu criterion are met by addressing a bug with
> > important severity. My interest in this bug, to introduce a newlib-
> > source binary package, is to unblock my progress on gcc-sh-elf,
> > which is otherwise almost ready.
> Probably still a good idea to CC them or file a bug in the BTS to
> document your intentions, as adding a binary package is not a usual
> change, even if the NMU criterias are fulfilled.
Okay, I made some noise on the bug report today and Cc'ed the debian-
toolchain mailing list on it. I'm not touching the moreinfo tag yet to
give them time to respond.

> Alternatively, you should consider ITS'ing the package.
> At least from your description it sounds as it would be a valid
> candidate, but I didn't check the details.
I do believe it would be a valid candidate, but I don't think it would
be a good idea to salvage it until I get gcc-sh-elf into the archive.
The best way forward for the Newlib package is to only provide a
newlib-source package, and make the respective GCC source packages
(like gcc-sh-elf and gcc-arm-none-eabi) build their own Newlib ports.

For reasons I won't repeat here, this should be best practice, but I am
not yet in a position to where I can assume responsibility for the ARM
packages that are currently built by the Newlib source package.

> please change to experimental. (Its anyway _always_ a good idea to
> clear NEW first via experimental…)
Done.


signature.asc
Description: This is a digitally signed message part

Bug#984901: RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 -- firmware for AR7010 and AR9271 USB wireless adapters

[John Scott]

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

Are these superficial autopkgtests?

[John Scott]

Hello,

I'm working on packaging gcc-sh-elf (ITP #986778) which provides not
just a cross C compiler, but also provides Newlib (the ISO C standard
library) and a simulator, which is a Wine-like wrapper that makes
running the binaries possible on a Debian machine. This seems like a
very good opportunity for DEP-8 tests that can test all the components
in tandem.

One test I have builds a tiny implementation of the echo command and
tries to get it to say 'Hello, world'. Another builds a more
computationally-intensive program to compute the number of primes less
than 2^15 and checks against the correct answer.

Here's what the autopkgtest specification says makes a test
superficial:
> The test does not provide significant test coverage, so if it
> passes, that does not necessarily mean that the package under test
> is actually functional.
My question may boil down to what is "significant," I think.
> If a superficial test fails, it will be treated like any other
> failing test, but if it succeeds, this is only a weak indication of
> success. Continuous integration systems should treat a package where
> all non-superficial tests are skipped as equivalent to a package
> where all tests are skipped.
> For example, a C library might have a superficial test that simply
> compiles, links and executes a "hello world" program against the
> library under test but does not attempt to make use of the library's
> functionality, while a Python or Perl library might have a
> superficial test that runs import foo or require Foo; but
> does not attempt to use the library beyond that.

Note that in their reference to building a 'Hello, world' program, the
specification says that what makes the test superficial is that the
library's functionality isn't used in the 'Hello, world' program, but
merely linking against it is tested. Since I'm testing GCC, Newlib
(which provides the I/O functions), and the simulator in combination,
is building and running such relatively simple programs appropriate to
say that the tests provide good coverage?

Because this is a toolchain for embedded devices, it's not possible to
build mainstream software for it, so I will otherwise probably resign
to not having any non-superficial tests.

All perspectives and thoughts on the matter would be appreciated.


signature.asc
Description: This is a digitally signed message part

Bug#987169: RFS: newlib/3.3.0-1.1 [NMU] -- C library and math library for embedded systems

[John Scott]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for Newlib:

 * Package name    : newlib
   Version : 3.3.0-1.1
   Upstream Author : Red Hat and others
 * URL : https://sourceware.org/newlib/
 * License : various
 * Vcs : https://salsa.debian.org/debian/newlib
   Section : devel

It builds those binary packages:

  newlib-source - C library and math library for embedded systems (source)
  libnewlib-arm-none-eabi - C library and math library compiled for bare metal 
using Cortex A/R/M
  libnewlib-doc - C library and math library intended for use on embedded 
systems (doc)
  libnewlib-dev - C library and math library intended for use on embedded 
systems

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/newlib/

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/n/newlib/newlib_3.3.0-1.1.dsc

Changes since the last upload:

 newlib (3.3.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add newlib-source binary package to aid building for new targets.
 (Closes: #912271)

This change wouldn't normally be appropriate for an NMU, but the
maintainer, Agustin Henze, hasn't been responsive to my attempts for
contact, and is also on the LowThresholdNmu list and keeps the package
in the Debian group on Salsa for collaborative maintenance:
https://wiki.debian.org/LowThresholdNmu

I haven't encountered the maintainer previously, but believe in good
faith that these changes would be welcome and that the LowThresholdNmu
criterion are met by addressing a bug with important severity. My
interest in this bug, to introduce a newlib-source binary package, is
to unblock my progress on gcc-sh-elf, which is otherwise almost ready.

That package will bootstrap a toolchain by building GCC and Newlib
simultaneously in a combined build tree, which in my opinion is best
practice for embedded toolchains going forward.

The changelog is set to unstable in anticipation that I won't manage to
clear NEW before Bullseye is released. If anyone would be so kind to
sponsor me sooner, I could change that to experimental.


signature.asc
Description: This is a digitally signed message part

Bug#985563: RFS: binutils-sh-elf/1 [ITP] -- GNU binary utilities for embedded SuperH devices

[John Scott]

On Fri, 19 Mar 2021 19:30:45 -0400 John Scott  wrote:
> The package should be built against experimental.

I've come to realize that on the buildd's, packages from experimental
aren't pulled in unless required to satisfy the build dependencies.
Disregard this; it's not a big deal, except that the autopkgtest does
require GCC 11, but I don't think those are run for experimental
anyway.


signature.asc
Description: This is a digitally signed message part

Bug#985563: RFS: binutils-sh-elf/1 [ITP] -- GNU binary utilities for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net
Control: block 980889 by -1

Dear mentors,

I am looking for a sponsor for my package "binutils-sh-elf":

 * Package name    : binutils-sh-elf
   Version : 1 (it's a native package)
 * URL : https://sourceware.org/binutils/
 * License : GPL-3+
   Section : devel

It builds those binary packages:

  binutils-sh-elf - GNU binary utilities for embedded SuperH devices

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/binutils-sh-elf/

Alternatively, one can download the package with dget using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/b/binutils-sh-elf/binutils-sh-elf_1.dsc

Changes for the initial release:

 binutils-sh-elf (1) experimental; urgency=low
 .
   * Initial release. (Closes: #980889)

I've been in touch with the Electronics Team about maintaining this
under their umbrella, but it seems they've had their hands full lately.
Perhaps another sponsor would be interested in getting this package
kicked off.

As I've mentioned elsewhere, my primary motivation is to make a
GCC+Newlib SuperH toolchain that can be used to build carl9170.
carl9170 is libre firmware for AR9170 USB wireless dongles. It seems
that SuperH is ubiquitous in other embedded gizmos however.

I've filed a Lintian bug for the bogus warning about missing build
targets. The package should be built against experimental.


signature.asc
Description: This is a digitally signed message part

Bug#984901: RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 -- firmware for AR7010 and AR9271 USB wireless adapters

[John Scott]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "open-ath9k-htc-firmware":

 * Package name    : open-ath9k-htc-firmware
   Version : 1.4.0-106-gc583009+dfsg1-2
   Upstream Author : Qualcomm Atheros and contributors
 * URL : https://github.com/qca/open-ath9k-htc-firmware
 * License : mostly Clear BSD 3 Clause
 * Vcs : https://salsa.debian.org/jscott/open-ath9k-htc-firmware
   Section : kernel

It builds those binary packages:

  firmware-ath9k-htc-udeb - firmware for AR7010 and AR9271 USB wireless
adapters
  firmware-ath9k-htc - firmware for AR7010 and AR9271 USB wireless
adapters

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/open-ath9k-htc-firmware/

Alternatively, one can download the package with dget using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/o/open-ath9k-htc-firmware/open-ath9k-htc-firmware_1.4.0-106-gc583009+dfsg1-2.dsc

Changes since the last upload:

 open-ath9k-htc-firmware (1.4.0-106-gc583009+dfsg1-2) experimental;
urgency=medium
 .
   * Add package version control info.
   * Clean up the copyright file.
 - Distinguish the BSD 3-Clause Clear variant from the conventional
one.
 - Make conformant to DEP-5 specification for machine readability.
   * Add a udeb for incorporation into the Debian Installer.
   * Build cross toolchain with Binutils 2.36 and GCC 11 with patch.

I cleaned up debian/rules somewhat as well. I've also written improved
AppStream metadata, but I'm waiting for that to be accepted upstream.
The principal purpose of this upload is to get the udeb through NEW,
although more work needs to be done in the Kernel Team's tooling before
it can be part of the installer.


signature.asc
Description: This is a digitally signed message part

Bug#981702: RFS: privacybadger/2021.2.2-1 -- browser extension automatically learns to block invisible trackers

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-mozext-maintain...@lists.alioth.debian.org

Dear mentors,

I am looking for a sponsor for my package "privacybadger":

 * Package name: privacybadger
   Version : 2021.2.2-1
   Upstream Author : Electronic Frontier Foundation
 * URL : https://www.eff.org/privacybadger/
 * License : GPL-3+
   Section : web

It builds those binary packages:

  webext-privacy-badger - browser extension automatically learns to block 
invisible trackers

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/privacybadger/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/privacybadger/privacybadger_2021.2.2-1.dsc

Changes since the last upload:

 privacybadger (2021.2.2-1) unstable; urgency=medium
 .
   * Friendly takeover back into the WebExt team.
   * New upstream release.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


signature.asc
Description: This is a digitally signed message part.

Debian Policy and copyright for binary packages made from foo-source

[John Scott]

Hello,

I'm working on packaging binutils-sh-elf, which is a native package which only 
has a debian/ directory. At build time, it extracts the tarball from binutils-
source—whatever version it happens to be—and builds it into binary packages 
with the appropriate options.

For informative purposes, I have this notice in my debian/copyright file:
Comment: This file specifies licensing information only for the
 source package, which merely provides the tooling for the sh-elf
 port. For licensing information about the GNU Binutils binaries,
 consult /usr/share/doc/binutils-common/copyright.

This seems like a convenient solution that satisfies the spirit of Debian 
Policy, since I recommend binutils-common for the translations anyway. This 
doesn't feel much different from referring to /usr/share/common-licenses/. 
However Policy seems to say I ought to include the notices directly:
> However, the copyright notices for any files which are compiled into the
> object code shipped in the binary package must all be included in
> /usr/share/doc/PACKAGE/copyright when the license requires that copyright
> information be included in all copies and/or binary distributions, as most
> do.

I could concatenate my /usr/share/doc/pkg/copyright with the one for the 
Binutils source, but then I'd have to give up having a machine-readable 
copyright file since Binutils doesn't have one, and also seems convoluted.

Does it seem like my comment in my copyright file may satisfy the intent, or 
that I still need to mangle the file? Similar packages don't seem to be as 
meticulous on this issue.

signature.asc
Description: This is a digitally signed message part.

Bug#974856: RFS: klatexformula/4.1.0-1 [RC] -- GUI to easily get an image from a LaTeX formula or equation

[John Scott]

On Friday, December 25, 2020 3:27:25 PM EST Tobias Winchen wrote:
> Did you try drag and drop the images e.g. to libreoffice impress? Via drag 
> and 
> drop I get the correct effects, but not via save.  I reported this behavior 
> upstream:
I had not tried that, but bizarrely it seems to not work for me still and I 
can't really articulate the cause. Until I can get more debugging information 
or you can reproduce, I think this is minor, shouldn't block the upload, and 
could be fixed later if need be. There might be a missing dependency or 
something.

Apologies if I said this before, but at start-up it prints to the CLI
Warning: libpng warning: iCCP: known incorrect sRGB profile
though I can't tell you what that means.

Are effects supposed to show up in the preview window? I've yet to figure out 
what they're supposed to look like. If I click directly on the preview after 
having enabled an effect, I get

Warning: * In function KLFUserScriptExporter::getData()  *
Error: Error running user script imagemagickeffect: User Script /
usr/share/klatexformula/userscripts/imagemagickeffect.klfuserscript 
reported an error (exit status 1). Here is full stderr output:


This script is part of the Python argcomplete package (https://github.com/
kislyuk/argcomplete).
It is used to check if an EASY-INSTALL-SCRIPT wrapper redirects to a script 
that contains the string
"PYTHON_ARGCOMPLETE_OK". If you have enabled global completion in argcomplete, 
the completion hook will run it every
time you press TAB in your shell.

Usage:
python-argcomplete-check-easy-install-script input executable file



It seems like maybe it's not getting command-line arguments due to improper 
quoting?
e.g. "bash --help --foo" will tell you "bash --help --foo: command not found"
It's also unexpected that it prints HTML-style output both to my shell and in 
the user script log.

All of this could be trouble in my usage or with migration, so for lack of 
understanding on my part I think the package is ready if the sleuthing defies 
your understanding as it does mine. This too is probably an upstream issue 
anyhow.


signature.asc
Description: This is a digitally signed message part.

Bug#974856: RFS: klatexformula/4.1.0-1 [RC] -- GUI to easily get an image from a LaTeX formula or equation

[John Scott]

I can't sponsor KLatexFormula but use it and may have spotted issues.

I see this version introduces user scripts, but most of them start with
#!/usr/bin/env python
and the problem is that this doesn't explicitly refer to Python 2 or Python 3. 
At this time, such a script is considered a release-critical bug. The python 
executable has been phased out already.

If these user scripts can be used with Python 3, you should ask upstream to 
change the shebang line or patch it in the package, and add the python3 
dependency (it's Priority: optional and not considered part of the base system 
at the moment). If some only work with Python 2, they should be omitted from 
the final packages.

Of the ones installed, I can only see about five user scripts in the 
KLatexFormula window: custom command, custom template, dvipng, FeynMF, and 
pdflatex. Running them gets errors like
User Script /usr/share/klatexformula/userscripts/dvipng-backend.klfuserscript 
reported an error (exit status 1). Here is full stderr output:

This script is part of the Python argcomplete package (https://github.com/
kislyuk/argcomplete). It is used to check if an EASY-INSTALL-SCRIPT wrapper 
redirects to a script that contains the string "PYTHON_ARGCOMPLETE_OK". If you 
have enabled global completion in argcomplete, the completion hook will run it 
every time you press  in your shell.
Usage:
python-argcomplete-check-easy-install-script 

Dependencies needed for scripts and features to work should probably be 
included in the Recommends.

There's also warnings like
Warning: * In function KLFSettingsPrivate::displayUserScriptConfig()  
12/5/20 10:21 AM *
No value given for config widget "convert"

I don't know if this was introduced in the new version, but the effects like 
'on fire effect' don't work for me, not even when saving as a PNG, but it's 
less 
clear why.

If this seems overwhelming for you and upstream to figure out, it may be wise 
to make a minimal-changes upload of 4.0.0 to ensure KLatexFormula gets into 
Bullseye.

signature.asc
Description: This is a digitally signed message part.

Bug#969453: RFS: solo-python/0.0.26-1 [ITP] -- command line interface for SoloKeys 2FA security keys

[John Scott]

On Thursday, September 3, 2020 4:09:59 AM EDT Ansgar wrote:
> If it is a command-line utility the choice of language for its
> implementation doesn't matter to users and probably shouldn't be part
> of a package's name
It's both a command-line utility and a library, albeit a library applications 
are unlikely to depend on.

To the submitter, thanks for packaging solo-python! I'd been watching the wnpp 
bug and the package works well for me and looks great.

I've identified a minor upstream issue pertaining to not allowing solo to be 
run as root doing 'solo key rng feedkernel', but that's for them to tackle:
https://github.com/solokeys/solo-python/issues/96

signature.asc
Description: This is a digitally signed message part.

Re: Public domain license question

[John Scott]

On Monday, July 20, 2020 11:07:05 AM EDT François Mazen wrote:
> Is there special syntax in debian/changelog file to reopen such bugs?
> I would expect something similar to the (Closes: #123456):
> (Reopens: #123456)?

No, you can't do it in the changelog. Instead, you can send an email to 
cont...@bugs.debian.org with lines like this:
reopen 123456
reopen 123457
reopen 123458
...

and as long as you don't leave a blank line anywhere it will read those 
commands and act on them. Have a look at the control server reference for more
https://www.debian.org/Bugs/server-control#reopen

signature.asc
Description: This is a digitally signed message part.

Re: licensecheck says UNKNOWN

[John Scott]

On Monday, July 13, 2020 10:50:00 AM EDT Ryan Pavlik wrote:
> Unfortunately licensecheck doesn't currently recognize
> SPDX-License-Identifier (I haven't check to see if there's a request
> filed for that).

Fortunately there are issues filed (#904518) and an author assures that support 
will be added. The changelog suggests that there is already preliminary 
support for the GPL at least.

signature.asc
Description: This is a digitally signed message part.

Re: Problem with ftbfs on armel and mipsel with cmake 3.16.3

[John Scott]

On Wednesday, June 3, 2020 4:58:08 PM EDT Håvard Flaget Aasen wrote:
> The beginning of the error message is:
> CMake Error at
> /usr/share/cmake-3.16/Modules/CMakeCompilerIdDetection.cmake:26 (list):
>   list sub-command REMOVE_ITEM requires two or more arguments.

That part of the module says
list(REMOVE_ITEM lang_files ${nonlang_files})
so the error probably has to do with ${nonlang_files} being empty. I reproduced 
on mipsel emulated with qemu-user-static (a wonderful gem [1]), I didn't try 
this on real hardware.

It looks like the part to define nonlang_files immediately preceding is 
file(GLOB nonlang_files
  "${CMAKE_ROOT}/Modules/Compiler/*-${nonlang}-DetermineCompiler.cmake")

Rolling back to CMake to 3.15.4 was the same, but CMake 3.13.2 worked. So I 
looked as to what the difference would be between those paths and got 
files.diff.
I've attached the diff on CMakeCompilerIdDetection.cmake. Both of these 
together seem to be ARM and MIPS-specific, so are probably related to the issue 
somehow.

I'm CC'ing the CMake folks should they have a clue.

[1] https://wiki.debian.org/QemuUserEmulation--- CMakeCompilerIdDetection-3.13.cmake 2020-06-03 22:16:34.014977295 +
+++ CMakeCompilerIdDetection-3.15.cmake 2020-06-03 22:17:14.334981254 +
@@ -57,12 +57,14 @@
   HP
   Compaq
   zOS
+  XLClang
   XL
   VisualAge
   PGI
   Cray
   TI
   Fujitsu
+  GHS
 )
 if (lang STREQUAL C)
   list(APPEND ordered_compilers
@@ -72,21 +74,20 @@
 endif()
 list(APPEND ordered_compilers
   SCO
+  ARMCC
   AppleClang
+  ARMClang
   Clang
   GNU
   MSVC
   ADSP
   IAR
-  ARMCC
 )
 if (lang STREQUAL C)
   list(APPEND ordered_compilers
 SDCC
   )
 endif()
-list(APPEND ordered_compilers
-  MIPSpro)

 #Currently the only CUDA compilers are NVIDIA
 if(lang STREQUAL CUDA)
@@ -97,6 +98,8 @@
   foreach(Id ${ordered_compilers})
 string(APPEND CMAKE_${lang}_COMPILER_ID_CONTENT "# define ${CID_PREFIX}COMPILER_IS_${Id} 0\n")
   endforeach()
+  # Hard-code definitions for compilers that are no longer supported.
+  string(APPEND CMAKE_${lang}_COMPILER_ID_CONTENT "# define ${CID_PREFIX}COMPILER_IS_MIPSpro 0\n")
 endif()

 set(pp_if "#if")
@@ -135,9 +138,6 @@
 /* These compilers are either not known or too old to define an
   identification macro.  Try to identify the platform and guess that
   it is the native compiler.  */
-#elif defined(__sgi)
-# define ${CID_PREFIX}COMPILER_ID \"MIPSpro\"
-
 #elif defined(__hpux) || defined(__hpua)
 # define ${CID_PREFIX}COMPILER_ID \"HP\"
--- $(ls /usr/share/cmake-3.16/Modules/Compiler/ | grep DetermineCompiler)   2020-06-03 22:30:47.193727765 +
+++ $(ls /usr/share/cmake-3.13/Modules/Compiler/ | grep DetermineCompiler)   2020-06-03 22:30:16.825801414 +
@@ -1,5 +1,6 @@
 ADSP-DetermineCompiler.cmake
 ARMCC-DetermineCompiler.cmake
+ARMClang-DetermineCompiler.cmake
 AppleClang-DetermineCompiler.cmake
 Borland-DetermineCompiler.cmake
 Bruce-C-DetermineCompiler.cmake
@@ -18,7 +19,6 @@
 HP-CXX-DetermineCompiler.cmake
 IAR-DetermineCompiler.cmake
 Intel-DetermineCompiler.cmake
-MIPSpro-DetermineCompiler.cmake
 MSVC-DetermineCompiler.cmake
 NVIDIA-DetermineCompiler.cmake
 OpenWatcom-DetermineCompiler.cmake
@@ -35,5 +35,7 @@
 Watcom-DetermineCompiler.cmake
 XL-C-DetermineCompiler.cmake
 XL-CXX-DetermineCompiler.cmake
+XLClang-C-DetermineCompiler.cmake
+XLClang-CXX-DetermineCompiler.cmake
 zOS-C-DetermineCompiler.cmake
 zOS-CXX-DetermineCompiler.cmake


signature.asc
Description: This is a digitally signed message part.

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[John Scott]

> > If there really is a problem with those files I would appreciate your
> > letting me know what I missed. Otherwise I hope you can avoid the 
> > repacking trouble in the future.
> Probably not, but the repacking is not trouble.

Without a good reason, you really shouldn't repack [1]. I do not understand 
your motivation for removing those files since they don't end up in the binary 
packages.

Repacking means that you, collaborators, and volunteers working on quality 
assurance can't
* use tools like uupdate to upgrade to a new upstream version very easily
* can't verify the tarball against upstream's signature
* package those parts being removed from Coreboot later on without duplicating 
effort into another source package

Perhaps you're not aware that it is typical to disregard parts of the package 
that aren't built (yet). Otherwise I would like to know what advantage it has 
for my own potential applications, and you should explain in debian/copyright 
how the source differs [2].

> You can save you that pain. I already stole your watch file, now it
> says:
> E: coreboot source: debian-watch-file-pubkey-file-is-missing

I thought I had sent a merge request, but seeing no trace I must not have. I 
wanted it to have an explanation of how to modify the watch file to do the 
repacking for you.
It's necessary to put the Coreboot team's minimal OpenPGP
key in debian/upstream/signing-key.asc, and I didn't do it because of the 
sensitivity of the key material. The wiki [3] explains what you need to do, 
and to determine the key you need, GnuPG will say or complain which if you try 
verifying the tarball.

[1] https://perl-team.pages.debian.net/howto/repacking.html#0._INTRODUCTION
[2] https://wiki.debian.org/BenFinney/software/repack
[3] https://wiki.debian.org/debian/watch#Cryptographic_signature_verification

signature.asc
Description: This is a digitally signed message part.

Re: Understand Debian Keyring

[John Scott]

On January 5, 2020 12:34:53 PM EST, Wookey  wrote:
>On 2020-01-05 10:01 -0500, Tong Sun wrote:
>> Now, before I redo the upload (and get it stuck again), let me try to
>> understand the situation --
>> 
>> The reason it was stuck might be because my key was *considered*
>> expired. The problem is, I renewed it two or three weeks ago, and sent
>> it to pgp &
>> Ubuntu key servers.
>> 
>> The mentors.debian.net accepted my (renewed) key, but ftp-master
>> didn't. Might that my key on ftp-master.debian.org is somehow not
>> refreshed? Anyway, I tried to fix the issue by refreshing my key to
>> keyring.debian.org. However, on reading https://keyring.debian.org/, I
>> stated to wonder that if it good enough *now*:
>> 
>> > We will include your changed key in our next keyring push (which happens 
>> > approx. monthly).
>> 
>> What does it really mean? Shall I need to wait a month before uploading 
>> again?
>
>One thing is check that you are signing the packages with the new key
>and not the old one (not sure if 'renewing' counts as a new key or
>not?). If both are around (gpg -K will show available secret keys),
>it's very easy to sign with the wrong one, and then ftp-master quietly
>throws away your packages without telling you.
>
>I know this because I've had this problem for some time (my machine
>defaults to using the wrong key despite having default-key set in
>.gnupg/gpg.conf so I have to sign with an expicit key (debsign -k)).
> 
>Wookey

He said his key was expired, so in this context renewing his key means bumping 
the expiration date. That won't be a problem

Bug#946959: RFS: coreboot/4.10-1 -- Coreboot firmware utilities

[John Scott]

The package is in great shape. The only challenge to getting the package in 
the archive seems to be the copyright file. Coreboot's README says
> Some files are licensed under the "GPL (version 2, or any later version)",
> and some files are licensed under the "GPL, version 2". For some parts,
> which were derived from other projects, other (GPL-compatible) licenses may 
apply. Please check the individual source files for details.

debian/copyright says most files are GPL 2+, but it my digging indicates the 
majority are GPL 2 only, and I think I saw additional licenses too.

I believe upstream has recently expressed desire to make listings files with 
respective licenses and/or using SPDX identifiers, rather than their lengthy 
headers in the source. If that's true, checking out the Git version might help 
you parse the licenses.

Speaking of which, you repacked Coreboot with the contents of 3rdparty/ 
removed. As a Libreboot user I thought I understood why, but as best as I can 
tell those files are free. On Coreboot's downloads page they appear to 
distribute the blobs separately which is news to me.

If there really is a problem with those files I would appreciate your letting 
me know what I missed. Otherwise I hope you can avoid the repacking trouble in 
the future.

Lastly, a small enhancement is to add a debian/watch file so that tools can 
check for and utilize new upstream versions automagically. I plan to send a 
Salsa merge request with details shortly.

I hope my feedback is useful for you to help your package.

signature.asc
Description: This is a digitally signed message part.

Bug#945588: RFS: lutris/0.5.4-1 -- open source gaming platform for GNU/Linux

[John Scott]

I'm not a DD and can't sponsor packages, but I hope my feedback can be helpful 
for you.

I see Lutris bundles python-distro. This is available in Debian, so the 
package should use it rather than installing a bundled copy. Debian's 
Winetricks should be used also.
Since Winetricks is in contrib, depending or recommending it means that Lutris 
needs to go to contrib or non-free also.

Lutris's description mentions Linux. Does it use any Linux-specific 
functionality, or should it build and work on other kenels like the Hurd and 
kFreeBSD also? If so the Architecture: any is fine.

I see from the TODO and your GitHub issue that you're aware of the copyright 
problems, but as the package currently stands it's not suitable even for non-
free.
Files: share/lutris/icons/hicolor/symbolic/apps/nintendods-symbolic.svg
Copyright: Nintendo
License: none-wikipedia
Comment: from 

Files: share/lutris/icons/hicolor/symbolic/apps/sonyplaystation-symbolic.svg
Copyright: Sony Interactive Entertainment
License: none-wikipedia
Comment: from 

License: none-wikipedia
 This image consists only of simple geometric shapes or text. It does not meet
 the threshold of originality needed for copyright protection, and is 
therefore
 in the public domain.

Does upstream get the images from Wikimedia Commons? These logos are almost 
surely encumbered by copyright and/or trademark issues and can't go in main. 
Wikimedia Commons holds neither the copyright nor trademark and Lutris 
shouldn't go on the editors' words. See the disclaimer
> Other restrictions may apply. These may include trademarks,
> patents, personality rights, moral rights, privacy rights, or any of the
> many other legal causes which are independent of copyright and vary greatly
> by jurisdiction.
It's inconceivable that permission from Nintendo and Sony was obtained.
But actually the Flaticon icons are worst of all and keep this from going even 
in non-free:

License: Flaticon
 From :
 What you CANNOT DO:
  -Distribute Flaticon's Contents unless it has been expressly authorized 
by Flaticon.
  -Include Flaticon's Contents in an online or offline database or file.
  -Offering Flaticon's Contents designs (or modified Flaticon Contents versions)
   for download.

...but I just downloaded them. And as though it couldn't be any worse:
  "The complete content of licenses can be consulted in the Terms of Use, that
  will prevail over the content of this document."
so that isn't the license anyway.

That's problematic and I don't see any 'explicit authorization,' so I've 
reported this issue upstream at https://github.com/lutris/lutris/issues/2573
and hope it will be taken care of.

With respect to the Debian-specific parts, the packaging looks good and I hope 
my feedback helps you tackle your last few challenges.

signature.asc
Description: This is a digitally signed message part.

Refresh PGP key with nm.debian.org

[John Scott]

Hello,

I'm working on requesting a guest account, and unfortunately I've had to 
generate new subkeys since starting my application. There doesn't seem to be 
an option to refresh my key. Switching to another fingerprint and back doesn't 
work either.

Could someone help me get my key refreshed, or would I be better off starting a 
new application?

Thanks,
John Scott

signature.asc
Description: This is a digitally signed message part.

Bug#941440: wxMaxima Pandoc problem

[John Scott]

wxMaxima FTBFS's for me with
$ pdf-engine /usr/bin/xelatex not known

I see that the 19.10.0 Debian package builds now by skipping the PDF manual 
when it can't be built. I think I've found the root of the problem with 
Pandoc.

It turns out this is a regression that's been there for ages and fixed in 
Pandoc 2.2.2 [1], just shy of the 2.2.1 version in Buster. wxMaxima doesn't 
build-dep on Pandoc and I'm building in a non-clean environment, but perhaps 
the following check done by CMake should be made aware of the Pandoc bug in 
the upstream part of wxMaxima by bumping the version:
-- pandoc version >= 2 found - using option --pdf-engine

https://github.com/jgm/pandoc/issues/4681#issuecomment-403617849



signature.asc
Description: This is a digitally signed message part.

Bug#941440: FTBFS on Buster

[John Scott]

It doesn't build for me on Buster, it seems this version of Pandoc doesn't 
understand giving the full path to the TeX engine.

make[4]: Entering directory 
'/home/john/wxmaxima/wxmaxima-19.09.1/obj-x86_64-linux-gnu'
cd /home/john/wxmaxima/wxmaxima-19.09.1/obj-x86_64-linux-gnu/info && 
/usr/bin/pandoc --pdf-engine=/usr/bin/xelatex 
/home/john/wxmaxima/wxmaxima-19.09.1/info/wxmaxima.zh_TW.md -o 
wxmaxima.zh_TW.pdf --number-sections --table-of-contents
pdf-engine /usr/bin/xelatex not known

It works fine replacing with --pdf-engine=xelatex

signature.asc
Description: This is a digitally signed message part.

Bug#941440: RFS: wxmaxima/19.09.1-1 -- GUI for the computer algebra system Maxima

[John Scott]

I tried to fetch the source package with dget, but it doesn't seem to like the 
new key it's signed with.

$ dget -x 
https://mentors.debian.net/debian/pool/main/w/wxmaxima/wxmaxima_19.09.1-1.dsc
dscverify: wxmaxima_19.09.1-1.dsc failed signature check:
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: Signature made Mon 30 Sep 2019 10:53:01 AM EDT
gpg:using RSA key 53F047CE66B91B0F724C545D5C86C0E4211D5B8E
gpg:issuer "wxmax...@physikbuch.de"
gpg: Can't check signature: No public key
Validation FAILED!!
$ gpg --keyserver keyring.debian.org --recv-keys 
53F047CE66B91B0F724C545D5C86C0E4211D5B8E
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

signature.asc
Description: This is a digitally signed message part.