Bug#1026335: Squashing the last carl9170fw issues: ready for sponsorship
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#948842: nm.debian.org should get OpenPGP keys for applicants not yet in the project keyring from Salsa
I have a crazy idea I haven't seen here yet. Folks are already using Salsa to authenticate themselves and log in to nm.debian.org, so why not just allow importing key(s) from Salsa? You can find my current key and a long obsolete key at https://salsa.debian.org/jscott.gpg and this URL convention works for getting the key for anybody. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1026335: Review of the initial packaging of the carl9170 firmware
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#1040960: gcc-sh-elf fix is on the way
Control: owner -1 John Scott Control: tags -1 pending I made a boo boo. An explanation and fix will be ready shortly signature.asc Description: This is a digitally signed message part
Bug#1042935: Sage test timeouts probably fixed upstream
Control: tags -1 fixed-upstream Control: block -1 by 1010735 I think this is fixed upstream. Apparently they were made aware that this particular failing test just takes a long time, but if you give it a couple minutes it does pass. signature.asc Description: This is a digitally signed message part
Bug#1022702: Debian GnuPG maintenance
Dear dkg, I see you were active on Salsa not long ago, which is why I thought I'd try and reach out again. A lot of people care about GnuPG in Debian and want to help, including me. The packages are in collaborative maintenance, but they're also key packages, so in all honesty folks are hesitant to make an upload without an acknowledgment from you. If you want to take a step back then we shall have an opportunity to learn, but otherwise we would love to have your expertise. Please respond. Sincerely, A concerned user and hacker signature.asc Description: This is a digitally signed message part
Bug#1043445: gdb-source should be Multi-Arch: foreign (I think)
Source: gdb Severity: normal Control: affects -1 src:gcc-sh-elf I chatted with Helmut about this some time ago, but I think gdb-source is supposed to be Multi-Arch: foreign. Right now it stops gcc-sh-elf from being cross buildable. Please consider marking gdb-source Multi-Arch: foreigh so I can cross compile my cross compiler :) -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable-debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, 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 -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#996432: Newlib salvaging
On Thu, 13 Jul 2023 12:58:31 +0200 Bastian Germann wrote: > what is the state of this? Do you have a newlib 4.* draft ready? Oops, I forgot about this, thanks for the poke! I'm going to do the new Newlib package from scratch; there's not much in the existing package worth keeping. I'm about to get to work on making a new Newlib package and prepare changes for the ARM toolchain. Would someone from the Electronics Team please give me Developer permissions on the Salsa repository I just made at https://salsa.debian.org/electronics-team/toolchains/newlib/ so I can manage Salsa CI and project settings? I'm going to prepare changes to the ARM toolchain first to make it responsible for building its own copy of Newlib. I'll also work my magic and incorporate a simulator and autopkgtests from gcc-sh-elf. That will not be a radical change, so it can probably go straight to unstable, but it'll have to clear NEW since we'll be adding a new libnewlib-arm-none-gnueabihf-dev package. What will be a radical change is not only switching source packages for Newlib, but also uploading a radically new version of Newlib. We'll have to be very careful. Rebuilding all build reverse dependencies, running autopkgtests, and such will be the minimum effort required. We might not even get this done for Trixie to be honest depending on how long everything takes to clear NEW. signature.asc Description: This is a digitally signed message part
Bug#980900: New watch file for Graphviz package v2
Thanks to Matt for clearing up the situation, I've written a new watch file. Matt said that there is no longer a distinction between stable and unstable releases, so please accept this watch file for the next upload and attribute me in the changelog as John Scott: version=4 https://graphviz.org/download/source/ .*/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ https://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=gitlab_releases/graphviz/graphviz \ .*/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ opts="searchmode=plain" https://gitlab.com/api/v4/projects/4207231/releases \ [^"]*/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ This checks for the tarball in three different ways, so that if one method breaks, the others will be fallback options. (For example, if upstream makes a new upstream release and accidentally publishes it at only one place.) First, we check the Graphviz downloads page directly. This is obviously the preferred discovery option. If that fails, we use qa.debian.org's fakeupstream.cgi service to get the latest GitLab release. If that fails, we'll do more or less what the fakeupstream.cgi service is doing anyway without the dependence on that infrastructure, which is fetch the JSON from the GitLab API and parse that in a crude fashion. By default, uscan will check all three of these sources and see which directs it to the newest source. Note that the actual tarball URL discovered should be the same in all three cases. I hope this could be helpful :) signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1042848: bookworm-pu: package curl/7.88.1-10+deb12u2
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org Control: affects -1 + src:curl [ Reason ] This upload is to address a regression in CURL, an undesirable change in behavior as compared to Bullseye which works correctly. This upload contains a cherry-picked fix that allows CURL to be built with OpenLDAP-specific code instead of unmaintained fallback code as intended. Basically, the Autotools build system only would fail to detect OpenLDAP properly (Debian uses OpenLDAP). The fallback code, besides being unmaintained, has numerous incidental issues. [ Impact ] If this update isn't approved, then not only will advanced LDAP functionality not work, but fetching binary LDAP attributes will completely spoil CURL's output by injecting binary bytes into what's supposed to be a text file. This is the biggest fallout of using the unmaintained code. I don't think this issue is security-relevant, but it does make the LDAP functionality somewhat useless. The number of CURL LDAP users is hard to predict; LDAP is used frequently in internal-only business environments. [ Tests ] I manually tested the package against real-world LDAP servers; that's how I ran into the bug in the first place and noticed that it was a regression from the Bullseye behavior. Furthermore, I have added an autopkgtest validating that fetching binary attributes now works correctly. This test works by spinning up a real LDAP server and then using libcurl to fetch binary data from it. I verified that the autopkgtest fails without the upstream CURL patch, and passes with the CURL patch. [ Risks ] No libcurl code is touched; it's merely a change of a few lines so that the Autotools build system builds the OpenLDAP-using code. With the new autopkgtest especially, the risks are very small. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] The changes consist of updating the package changelog, adding the upstream CURL patch to the patch series, and then the biggest change is the new autopkgtest. (I chose to write it in C, so you could say it's rather verbose.) The OpenLDAP maintainers are aware of the new autopkgtest and do not have reservations. [ Other info ] I do not have uploading privileges and this is not an NMU; this upload was prepared with the assistance and supervision of DD Samuel Henrique who has been maintaining CURL lately. He will upload the package when this unblock request is approved. diff -Nru curl-7.88.1/debian/changelog curl-7.88.1/debian/changelog --- curl-7.88.1/debian/changelog 2023-07-23 17:43:52.0 -0400 +++ curl-7.88.1/debian/changelog 2023-07-25 08:11:34.0 -0400 @@ -1,3 +1,13 @@ +curl (7.88.1-10+deb12u2) bookworm; urgency=medium + + * Team upload. + * LDAP backend: correct the usage of OpenLDAP-specific functionality being +disabled with an upstream patch (Closes: #1041964) +This corrects the improper fetching of binary attributes. + * debian/tests: add a DEP-8 test that getting binary LDAP attributes works now + + -- John Scott Tue, 25 Jul 2023 08:11:34 -0400 + curl (7.88.1-10+deb12u1) bookworm-security; urgency=medium * Team upload. diff -Nru curl-7.88.1/debian/patches/series curl-7.88.1/debian/patches/series --- curl-7.88.1/debian/patches/series 2023-07-23 17:43:52.0 -0400 +++ curl-7.88.1/debian/patches/series 2023-07-25 08:11:34.0 -0400 @@ -31,3 +31,4 @@ # Used to generate packages for the other crypto libraries. 90_gnutls.patch 99_nss.patch +Use-OpenLDAP-specific-functionality.patch diff -Nru curl-7.88.1/debian/patches/Use-OpenLDAP-specific-functionality.patch curl-7.88.1/debian/patches/Use-OpenLDAP-specific-functionality.patch --- curl-7.88.1/debian/patches/Use-OpenLDAP-specific-functionality.patch 1969-12-31 19:00:00.0 -0500 +++ curl-7.88.1/debian/patches/Use-OpenLDAP-specific-functionality.patch 2023-07-25 08:11:34.0 -0400 @@ -0,0 +1,35 @@ +Description: Fix Autotools not enabling OpenLDAP-specific functionality + The non-OpenLDAP code paths are less tested, less featureful, less secure, + and omitted in the build system by accident. It has been discovered that this + also mitigates curl not being able to make LDIF output when attributes have + binary values. +Origin: upstream, https://github.com/curl/curl/commit/0ac6108856b9d500bc376d1d7e0b648d15499837.patch|commit:) +Bug: https://github.com/curl/curl/issues/11372 +Applied-Upstream: 8.2.0, https://github.com/curl/curl/commit/0ac6108856b9d500bc376d1d7e0b648d15499837 +Reviewed-By: John Scott +Last-Update: 2023-07-25 + +--- curl-7.88.1.orig/configure.ac curl-7.88.1/configure.ac +@@ -1663,16 +1663,19 @@ if test x$CURL_DISABLE_LDAP != x1 ; then + fi + + if test
Bug#976991: I am stepping up to help with the GnuTLS → OpenSSL switch in OpenLDAP
On Thu, 2023-07-27 at 12:25 -0400, Sergio Durigan Junior wrote: > > > I'll write some TLS autopkgtests, we'll rebuild reverse dependencies > > > and see how they fare, it'll be great. > > > > That's an excellent first step, thanks for looking into it! > > +1, thanks for helping with this, John. Thank you for your encouragement! I have sent a merge request here that checks that TLS works, it should work without change for GnuTLS and OpenSSL: https://salsa.debian.org/openldap-team/openldap/-/merge_requests/8 Note that this only uses TLS for the server-side (what most people think of when they think of TLS), the test could be extended to test client certificates too I suppose but let's do one thing at a time. I know you just made an upload, obviously there's no hurry to get this in the archive. I like that working on this package forces me to learn about LDAP one step at a time. If now is not a good time to stage the OpenSSL switch, please let me know if there is other low-hanging fruit to work on. I'm sure you saw my announcement email that I'm putting together an LDAP CURL autopkgtest, and am happy to report that I've also prepared an autopkgtest testing that gpgsm can fetch S/MIME certificates over LDAP. Yay, I love autopkgtests! signature.asc Description: This is a digitally signed message part
Bug#976991: I am stepping up to help with the GnuTLS → OpenSSL switch in OpenLDAP
A lot of arguments have been made for switching to OpenSSL, and I can think of some arguments that haven't even been made yet. I just wrote two OpenLDAP autopkgtests that interact with other packages to prove my merit as a knowledgeable contributor, even if I did just learn today the majority of what I know. Debian Experimental is currently at the latest upstream release which is awesome. I think we should seize this opportunity and start staging changes in Experimental. I'll write some TLS autopkgtests, we'll rebuild reverse dependencies and see how they fare, it'll be great. If you want me to make these changes, I can prepare a Merge Request keeping them small. But I think someone who is more familiar with OpenLDAP besides libldap (my forte) should do that. signature.asc Description: This is a digitally signed message part
Bug#1022702: I volunteer to maintain GnuPG and friends in the long-term
On Tue, 2023-07-25 at 09:42 +0100, Jonathan McDowell wrote: > The longer term question is whether any of us are stepping up to help > out with full package maintenance, which I believe should be a > prerequisite of an upload to unstable if we don't hear from Eric or dkg. I'm neither a DD nor a DM, but I do believe I have some qualifications. I'd like to join the team and stick around for the long-haul. - I'm familiar with MinGW, C, and cross-compilers, so I can help build the binaries that target Windows. I'm familiar with best practices with building for foreign (non-Debian) architectures in Debian packages, maintaining bare-metal toolchains with the Electronics+Kernel teams to support firmware. - I program with GPGME and like writing small utilities with it. - I use niche features such as LDAP searching for S/MIME certificates, gpgsm generally, multiple smartcard support, TOFU, DANE, and more, so I can test that these work. - I love autopkgtests and want to write more. I have a lot to learn, but one of my ideas is to install slapd (the OpenLDAP directory server) and check that the GnuPG suite can fetch certificates and OpenPGP keys. I'm familiar with LDAP programming, so my idea is to write some OpenLDAP glue to upload the keys, then call GPGME functions to fetch them again and see they're the same. signature.asc Description: This is a digitally signed message part
Bug#1041964: flaky LDAP behavior due to not taking proper OpenLDAP code paths
Source: curl Version: 7.85.0-1 Severity: important Tags: patch upstream fixed-upstream bookworm Forwarded: https://github.com/curl/curl/commit/0ac6108856b9d500bc376d1d7e0b648d15499837 Dear curl Debianites, I have discovered that curl is not taking OpenLDAP-specific code paths, and is instead using older deprecated functions that are also buggier and less tested in curl. Aside from the obvious security implications, this also means that, to my understanding, there is no support for forcing StartTLS, no support for SASL authentication, and hence credentials might have to be sent in the clear if this is not addressed. This issue also only appears to've affected the Autotools build system. Another bug I ran into---one that still needs fixed in CURL in the non-OpenLDAP code path---is that attributes with binary values are put exactly as-is into the LDIF, which is supposed to be a text file format, and hence the LDIF output is useless. Although there aren't a ton of LDAP CURL users, I think the fix is small, targeted, tested by me, and appropriate for Bookworm, and so I've tagged the bug accordingly. Note that this bug also affects the version of curl in experimental as of this writing. -- System Information: Debian Release: trixie/sid APT prefers testing-debug had a brief chat with Daniel the curl author who said that there are already very few users of LDAP with curl, and seeing as there are no existing Debian bug reports on the matter, one could say APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable-debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, 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 -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#1037904: Xournal++ GCC 13 FTBFS fixed upstream
Control: forwarded -1 https://github.com/xournalpp/xournalpp/commit/9172ee831f4dfbb88dfeb13b66862e80e64a0d3f Control: tags -1 fixed-upstream It looks like this has been fixed upstream, so I'm setting the bug metadata as such. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1040788: RFS: gcc-sh-elf/7 -- GNU C compiler for embedded SuperH devices
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
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#999785: Bogus Lintian warning built-using-field-on-arch-all-package affects prospective package firmware-carl9170
Lintian asserts that having Built-Using on an Arch: all package is always incorrect. Debian Policy permits and often requires having Built-Using on an Arch: all package. This is the situation with carl9170fw, a GPL-2.0-only-licensed binary that bakes in several static libraries that need to have their sources kept around. This is a firmware package, however, so it's Arch: all despite being written in C and producing a bare-metal binary. I am concerned that this Lintian warning may cause false alarm by my sponsors or even cause rejection in the NEW queue. Please remove it from Lintian. Furthermore, the far more likely problem with Built-Using is that a package forgets to use it when it should. So when a package *does* remember to set the Built-Using field, it's typically the result of long consideration and the maintainer should be given the benefit of the doubt. 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
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
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#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
> I do not indend to hijack/adopt gnupg2, so I am very reluctant to upload > without some kind of go from Daniel or Eric. (Even to experimental.) > > However I have updated the GIT branches to 2.4.1 today. Thanks for your hard work Andreas! Those packages do indeed solve issues for me and bring desirable features, especially as a user of OpenPGP cards. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1035321: parsing of 'git log' seems to break when commits are signed
Package: dh-make-golang Version: 0.6.0-2+b5 Severity: normal Control: block 1035318 by -1 It looks like dh-make-golang fails when the commits are signed, and this makes me unable to package the rtltcp library: $ dh-make-golang make -type "library" github.com/bemasher/rtltcp 2023/04/30 15:46:18 Starting "dh-make-golang v0.6.0 linux/amd64" 2023/04/30 15:46:18 Downloading "github.com/bemasher/rtltcp/..." 2023/04/30 15:46:21 Determining upstream version number 2023/04/30 15:46:21 Could not create a tarball of the upstream source: get package version from Git: parse last commit date: strconv.ParseInt: parsing "gpg: Signature made Sun 30 Apr 2023 03:27:39 PM EDT\ngpg:using RSA key 4AEE18F83AFDEB23\ngpg: Good signature from \"GitHub (web-flow commit signing) \" [marginal]\ngpg: nore...@github.com: Verified 120 signatures in the past 2 years. Encrypted\n 0 messages.\ngpg: Warning: you have yet to encrypt a message to this key!\ngpg: WARNING: This key is not certified with sufficiently trusted signatures!\ngpg: It is not certain that the signature belongs to the owner.\n 5DE3E0509C47EA3CF04A42D34AEE18F83AFDEB23\n1682882859": invalid syntax If this is not a trivial fix, if anyone knows of a workaround so I can do my packaging, that would be nice. -- System Information: Debian Release: 12.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable-debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, 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 Versions of packages dh-make-golang depends on: ii git 1:2.39.2-1.1 ii git-buildpackage 0.9.30 ii golang-any 2:1.19~1 ii libc6 2.36-8 ii pristine-tar 1.50 Versions of packages dh-make-golang recommends: ii golang-golang-x-tools 1:0.5.0+ds-1 ii msmtp-mta [mail-transport-agent] 1.8.23-1 dh-make-golang suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1035318: ITP: golang-github-bemasher-rtltcp -- Go library interface to an rtltcp daemon
Package: wnpp Severity: wishlist Owner: John Scott X-Debbugs-Cc: debian-de...@lists.debian.org Control: block 1025210 by -1 * Package name: golang-github-bemasher-rtltcp * URL : https://github.com/bemasher/rtltcp * License : AGPLv3 Programming Lang: Go Description : Go library interface to an rtltcp daemon This is a Go library that allows programs a high-level means of interacting with rtltcp, a daemon that allows for remote control of an RTL-SDR (if you're familiar with SoapyRemote, it's similar). This is the last remaining dependency for packaging rtlamr, a program from the same author. Note that this library is under the AGPLv3, not the ordinary GPL, so applications that use it need to be AGPL-compatible (generally means AGPL or GPL), and then the final binary is subject to the AGPL. I'm aware of the recent discussions around Berkeley DB and how problematic this can be for programs that aren't traditionally thought of as being network-facing, but since rtlamr is by the same author under the same license and thought to be its only user, my opinion is that this is pretty insignificant. If other programs use this library someday, of course, we'll have to check that they are respectful of the license. I will maintain this in the Debian Go Team's umbrella and in accordance with their practices because it's written in Go, but it will be used mostly by ham radio folks. I'm not a Debian Developer or Maintainer, so I'm grateful to have already identified a possible sponsor who is knowledgeable in both areas. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1034574: uscan: support OpenPGP signature verification without requiring a saved upstream signing key
Package: devscripts Version: 2.23.3 Severity: wishlist I know if you're looking at the subject line alone you'll think I'm proposing introducing a security vulnerability, but let me explain. There are some problems with storing an upstream signing key inside the package. It might get stale, not incorporating additional subkeys necessary for signature verification or revocations. Also, it requires manual work on the part of the maintainer and can't be done automatically. Folks outside the OpenPGP ecosystem might not know this, but the Web of Trust is now not the only way of doing things. There are ways, like Web Key Directory, DANE, and LDAP, to not only discover an OpenPGP key, but also verify that it really belongs to the person in the user ID. First, we save in some metadata file somewhere (debian/upstream/metadata?) the user IDs (aka names and email addresses) of upstream, or perhaps mappings of key IDs to email addresses. When uscan goes to verify the signature, it will know the key ID of the signer but might not know their user ID, so it will look in the mapping table. Then it will fetch the key using an authenticated method and use it to verify the signature. I hope that makes sense. Unfortunately I only know C, so I don't think I'll be able to contribute this. Thanks -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- DEBSIGN_KEYID=A23F3CA5BD39D9EB18AC7F35B3F4DD2861F4CDBA! DEBSIGN_MAINT="John Scott" BTS_MAIL_READER="evolution %s" BTS_INTERACTIVE=yes BTS_CACHE=yes BTS_CACHE_MODE=full DEBCOMMIT_SIGN_TAGS=yes DEBCOMMIT_SIGN_COMMITS=yes WHOUPLOADS_DATE=yes DSCVERIFY_KEYRINGS=/home/john/.gnupg/pubring.kbx DEBCHANGE_RELEASE_HEURISTIC=changelog DEBCHANGE_MULTIMAINT_MERGE=yes DEBCHANGE_MAINTTRAILER=yes -- System Information: Debian Release: 12.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable-debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, 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 Versions of packages devscripts depends on: ii dpkg-dev 1.21.21 ii fakeroot 1.31-1.1 ii file 1:5.44-3 ii gnupg 2.2.40-1.1 ii gpgv 2.2.40-1.1 ii libc6 2.36-8 ii libfile-dirlist-perl 0.05-3 ii libfile-homedir-perl 1.006-2 ii libfile-touch-perl 0.12-2 ii libfile-which-perl 1.27-2 ii libipc-run-perl 20220807.0-1 ii libmoo-perl 2.005005-1 ii libwww-perl 6.68-1 ii patchutils 0.4.2-1 ii perl 5.36.0-7 ii python3 3.11.2-1 ii sensible-utils 0.0.17+nmu1 ii wdiff 1.2.2-5 Versions of packages devscripts recommends: ii apt 2.6.0 ii curl 7.88.1-7 ii dctrl-tools 2.24-3+b1 ii debian-keyring 2022.12.24 ii dput 1.1.3 ii equivs 2.3.1 ii libdistro-info-perl 1.5 ii libdpkg-perl 1.21.21 ii libencode-locale-perl 1.05-3 ii libgit-wrapper-perl 0.048-2 ii libgitlab-api-v4-perl 0.26-3 ii liblist-compare-perl 0.55-2 ii liblwp-protocol-https-perl 6.10-1 ii libsoap-lite-perl 1.27-3 ii libstring-shellquote-perl 1.04-3 ii libtry-tiny-perl 0.31-2 ii liburi-perl 5.17-1 ii licensecheck 3.3.5-1 ii lintian 2.116.3 ii man-db 2.11.2-2 ii patch 2.7.6-7 ii pristine-tar 1.50 ii python3-apt 2.5.3 ii python3-debian 0.1.49 ii python3-magic 2:0.4.26-3 ii python3-requests 2.28.1+dfsg-1 ii python3-unidiff 0.7.3-1 ii python3-xdg 0.28-2 ii strace 6.1-0.1 ii unzip 6.0-28 ii wget 1.21.3-1+b2 ii xz-utils 5.4.1-0.2 Versions of packages devscripts suggests: pn adequate ii at 3.2.5-1+b1 ii autopkgtest 5.28 ii bls-standalone 0.20151231+b1 ii build-essential 12.9 ii check-all-the-things 2017.05.20+nmu1 pn cvs-buildpackage ii debhelper 13.11.4 ii diffoscope 238 ii disorderfs 0.5.11-3 ii dose-extra 7.0.0-1+b2 ii duck 0.14.1 pn elpa-devscripts ii faketime 0.9.10-2.1 ii gnuplot-x11 [gnuplot]
Bug#1034385: please package new upstream release in experimental
Source: rust-sequoia-sq Severity: wishlist Hi, It would be nice to have a new upstream version with support for fetching keys via DANE. -- System Information: Debian Release: 12.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable-debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) 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
Bug#1034201: support DANE for HTTPS authentication
Package: apt Version: 2.6.0 Severity: wishlist apt-transport-https only supports the traditional certificate authority model. However, APT uses GnuTLS, which has a convenient interface for validating certificates with DANE. GnuTLS should be used to provide an alternative to the certificate authorities. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "true"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Sandbox::Seccomp "true"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "tasks"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Periodic ""; APT::Periodic::Download-Upgradeable-Packages "1"; APT::Periodic::Unattended-Upgrade "0"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i"; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a -e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || true; fi"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null; fi"; APT::Update::Post-Invoke ""; APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || true"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Architectures:: "i386"; APT::Architectures:: "arm64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "zstd"; APT::Compressor::zstd::Cost "60"; APT::Compressor::zstd::CompressArg ""; APT::Compressor::zstd::CompressArg:: "-19"; APT::Compressor::zstd::UncompressArg ""; APT::Compressor::zstd::UncompressArg:: "-d"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "lz4"; APT::Compressor::lz4::Cost "50"; APT::Compressor::lz4::CompressArg ""; APT::Compressor::lz4::CompressArg:: "-1"; APT::Compressor::lz4::UncompressArg ""; APT::Compressor::lz4::UncompressArg:: "-d"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--format=lzma"; APT::Compressor::lzma::UncompressArg:: "-d"; Dir "/"; Dir::State "var/lib/apt"; Dir::State::lists "lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::extended_states
Bug#1031439: gcc-sh-elf FTBFS: mystery solved?
Hi, I'm doing the build right now and it got past the part where it's been failing, so I'm pretty sure we're good! Adrian, would you be willing to sponsor my upload? I'll send a second mail when it's ready. The change is extremely small, and to be frank I'll probably skip running the test suite, but I believe the software will be sound. signature.asc Description: This is a digitally signed message part
Bug#1008573: GnuPG ssh-agent emulation smartcard issues when connecting to server running newer OpenSSH
Hi José and Vagrant, It seems bugs #998728, 1008573, and #1032907 are all the same. Perhaps the maintainers would like to merge them. Thanks for your workaround, Vagrant; I found that adding KexAlgorithms -sntrup761x25519-sha...@openssh.com to my ~/.ssh/config allows me to connect to a Bookworm machine, from Bookworm, and also to hosts running a newer OpenSSH daemon. A similar issue upstream is here: https://dev.gnupg.org/T6250 Werner K. hints that it might be fixed in the GnuPG 2.3 series. As soon as the maintainers upload it to experimental, I will be happy to test it. Thanks everyone for your attention. signature.asc Description: This is a digitally signed message part
Bug#1033911: please enable the experimental Xtensa backend in LLVM and Clang 16+
I believe the backend name is Xtensa. I wasn't able to try doing an LLVM build myself and do not have a patch because I ran out of disk space. I think setting -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=Xtensa will do the right thing, but again I was not able to test this. signature.asc Description: This is a digitally signed message part
Bug#1033911: please enable the experimental Xtensa backend in LLVM and Clang 16+
Source: llvm-toolchain-16 Version: 1:16.0.0-1~exp5 Severity: normal X-Debbugs-Cc: debian-ker...@lists.debian.org Control: affects -1 src:open-ath9k-htc-firmware Please enable the experimental Xtensa backend in LLVM 16 and newer and make a new upload to experimental. A lot of prominent firmware, including free firmware such as my open- ath9k-htc-firmware package, requires an Xtensa cross toolchain. Using GCC is a pain because the compiler has to be custom-tailored to the target, and in ath9k_htc we do this with patches that inevitably get out-of-date. We are taking a bold step by enabling a backend deemed experimental, but it's necessary to advance free software. This will also be helpful should anyone wish to build Intel's open sound firmware too (although on most machines that enforces a digital signature check to my understanding). -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable-debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, 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
Bug#1033888: ITP: usbscale -- read weight data from a USB scale
Package: wnpp Severity: wishlist Owner: John Scott Tags: newcomer X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : usbscale Upstream Contact: Eric Jiang * URL : https://github.com/erjiang/usbscale * License : GPL 3.0 or any later version Programming Lang: C Description : read weight data from a USB scale This package provides a utility one can use to read data from various USB scales, ones which are sold as postage scales in particular. Even though the program is very small, I still think it belongs in Debian. As far as I know, there are no applications in Debian that are capable of reading this sort of data. With usbscale, it's easy for medium-volume mailers to have scripts or utilities that talk to usbscale and, say, do automatic postage price computation. I use this application sometimes. I'm not a Debian Developer and will need a sponsor. I can't think of any pertinent teams to maintain it in, but since it's a small package, I see no problem with maintaining it on my own. I am familiar with Debian Packaging and will probably be able to get this out in the next few days. signature.asc Description: This is a digitally signed message part
Bug#951465: new source package for Meson documentation?
It doesn't make sense to use a patch to add the Meson documentation to this source package. I wonder if a new source package providing Meson documentation (because it is maintained separately) would be welcome? I would be willing to prepare this, but as I am not a Debian Developer, I will need a sponsor. signature.asc Description: This is a digitally signed message part
Bug#1033742: [PATCH] backport fix to keylisting operations to Debian Stable
Source: gpgme1.0 Version: 1.14.0-1 Severity: normal Tags: patch upstream bullseye X-Debbugs-Cc: gni...@fsij.org Hi, Please consider uploading this to bullseye-proposed-updates. This is a fix that allows the keylisting operations as documented. The regression risk is extremely small and I wrote an autopkgtest that fails with the old version and passes with the new. I am CC'ing Gniibe since he authored the upstream change and he just so happens to be a Debian Developer too; I'd be delighted if he would sponsor this. A patch is attached or you can pull in the OpenPGP-signed commit from the debian-stable-fix branch of https://salsa.debian.org/jscott/gpgme.git -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) 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 From 611fab84c0b6b0156d4e5d0a72da2c420c5bdddc Mon Sep 17 00:00:00 2001 From: John Scott Date: Fri, 31 Mar 2023 12:19:03 -0400 Subject: [PATCH] Backport a fix to the keylisting operations and prepare for release to Bullseye --- debian/changelog | 9 ++ debian/copyright | 4 + ...GPGME-keylist-from-data-ignores-sigs.patch | 88 + debian/patches/series | 1 + debian/tests/control | 4 + debian/tests/find-signature-from-data.c | 99 +++ 6 files changed, 205 insertions(+) create mode 100644 debian/patches/GPGME-keylist-from-data-ignores-sigs.patch create mode 100644 debian/tests/find-signature-from-data.c diff --git a/debian/changelog b/debian/changelog index c7bedbb9..9ab80b04 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +gpgme1.0 (1.14.0-1+deb11u1) bullseye; urgency=medium + + [ John Scott ] + * Backport an upstream fix so that the functions for listing keys from data +can return signature information if the application so requests. + * Add DEP-8 test ensuring that the fix works. + + -- Debian GnuPG Maintainers Fri, 31 Mar 2023 11:35:22 -0400 + gpgme1.0 (1.14.0-1) unstable; urgency=medium * new upstream release diff --git a/debian/copyright b/debian/copyright index d5b34af4..f2bdfdd4 100644 --- a/debian/copyright +++ b/debian/copyright @@ -10,6 +10,10 @@ Copyright: Werner Koch License: LGPL-2.1+ +Files: debian/tests/find-signature-from-data.c +Copyright: 2023 John Scott +License: GPL-3+ + Files: src/argparse.* Copyright: 1998-2001, 2006-2008, 2012 Free Software Foundation, Inc., diff --git a/debian/patches/GPGME-keylist-from-data-ignores-sigs.patch b/debian/patches/GPGME-keylist-from-data-ignores-sigs.patch new file mode 100644 index ..f94b2035 --- /dev/null +++ b/debian/patches/GPGME-keylist-from-data-ignores-sigs.patch @@ -0,0 +1,88 @@ +Description: fix GPGME's keylisting from data functions ignoring request for signatures + When requesting signature information, the functions to iterate over keys in specified + data does not return it. This is an oversight corrected in this change. Note that + the majority of applications don't request signature information (the default); this + change only serves to benefit those that do request it and hadn't been getting it. +Origin: upstream, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=patch;h=b2a2158384a9f048ff61ee0cebef8346055f0454 +Author: NIIBE Yutaka +Bug: https://dev.gnupg.org/T5438 +Applied-Upstream: 1.18.0, commit:b2a2158384a9f048ff61ee0cebef8346055f0454 +Reviewed-By: John Scott +Last-Update: 2023-03-31 +--- + +--- gpgme1.0-1.14.0.orig/src/engine-backend.h gpgme1.0-1.14.0/src/engine-backend.h +@@ -103,7 +103,8 @@ struct engine_ops + int secret_only, int reserved, + gpgme_keylist_mode_t mode, + int engine_flags); +- gpgme_error_t (*keylist_data) (void *engine, gpgme_data_t data); ++ gpgme_error_t (*keylist_data) (void *engine, gpgme_keylist_mode_t mode, ++ gpgme_data_t data); + gpgme_error_t (*keysign) (void *engine, + gpgme_key_t key, const char *userid, + unsigned long expires, unsigned int flags, +--- gpgme1.0-1.14.0.orig/src/engine-gpg.c gpgme1.0-1.14.0/src/engine-gpg.c +@@ -3115,7 +3115,7 @@ gpg_keylist_ext (void *engine, const cha + + + static gpgme_error_t +-gpg_keylist_data (void *engine, gpgme_data_t data) ++gpg_keylist_data (void *engine, gpgme_keylist_mode_t mode, gpgme_data_t data) + { + engine_gpg_t gpg = engine; + gpgme_error_t err; +@@ -3134,6 +3134,9 @@ gpg_keylist_data (void *engine, gpgme_da + err = add_arg
Bug#1016470: I want to help add autopkgtests to Muon
Hi Andrea, When the Muon package starts coming along, can you give me a poke? I have a few autopkgtest ideas I'd like to lend a hand in implementing. signature.asc Description: This is a digitally signed message part
Bug#1026362: Upload of binutils-sh-elf
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#983539: Lintian bug causes non-overridable rejection of packages
Control: affects -1 ftp.debian.org This caused my package to get rejected, and Lintian overrides cannot be used to mitigate it. signature.asc Description: This is a digitally signed message part
Bug#1026362: RFS: binutils-sh-elf/2 -- GNU binary utilities for embedded SuperH devices
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
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
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
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
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#994625: ITP: carl9170fw -- libre firmware for AR9170 USB wireless adapters
On Mon, 29 Aug 2022 18:36:23 +0200 Bastian Germann wrote: > Do you still want to get carl9170fw into Debian? Hi Bastain! Sorry I didn't notice your email until now. Yes, I'm still very interested in getting this package into Debian. I'm almost finished with the copyright review and will have a package uploaded to mentors.debian.net soon. Are you interested in being a sponsor, or are you just dropping by? :) Thanks for sponsoring my last upload on the closely-related ath9k_htc package as well. signature.asc Description: This is a digitally signed message part
Bug#1024626: Blender removal for 32-bit architectures
Hi, I see from previous mails that Blender upstream has decided not to support 32-bit architectures anymore. This is a friendly ping that the maintainer will request its removal so it may migrate into Bookworm. Thanks, John signature.asc Description: This is a digitally signed message part
Bug#1025210: ITP: rtlamr -- RTL-SDR receiver for smart utility meters
Package: wnpp Severity: wishlist Owner: John Scott X-Debbugs-Cc: debian-de...@lists.debian.org, debian-h...@lists.debian.org, debian...@lists.debian.org * Package name : rtlamr Version : 0.9.1 Upstream Author : Douglas Hall * URL : https://github.com/bemasher/rtlamr * License : AGPLv3 only Programming Lang: Go Description : RTL-SDR receiver for smart utility meters rtlamr is a program for using an RTL-SDR (and maybe other SDRs?) to receive readings from smart utility meters. I use this software, an willing to maintain it, and will make sure it stays in good shape. I have confirmed that it works with commonly available meters. This is useful for a variety of creative purposes, such as analyzing one's own energy usage, or even energy usage within a community, or to identify water leaks. As far as I know, no other packages provide similar functionality. The closest package is rtl_433, and it doesn't support these devices. I'm neither DD nor DM and will need a sponsor. I will maintain this either within the Go Team or the Ham Radio Team. I've CC'ed both of them to see if it piques their interest or if they have a preference. I would really like it if a fellow ham would see about getting it to work with an alternate SDR. signature.asc Description: This is a digitally signed message part
Bug#1024979: please consider enabling gpsd support
On Tue, 2022-11-29 at 06:44 +0900, Mike Hommey wrote: > Support compiled in would make libgpsd a hard requirement, which some > other people would probably complain about. But anyways, the main > problem is that, as far as I know, it doesn't actually work. Your reasoning is sound. Thanks for your consideration. I have a proposition for you. Let's suppose I can get it to work on my local system (I haven't tried yet; as I'm sure you know, rebuilding Firefox takes a long time). In that case, would you be willing to entertain a merge request which adds an opt-in build profile to enable gpsd support? This would make it a little easier for Debianites to experiment with it, and then we can revisit whether to enable it by default later down the road. signature.asc Description: This is a digitally signed message part
Bug#1024979: please consider enabling gpsd support
Package: firefox-esr Version: 102.4.0esr-1 Severity: normal Hi, Firefox has opt-in support for gpsd to determine user location. However, the Debian package doesn't compile in support for it. It should be as easy as configuring with --enable-gpsd and adding the Build-Depends. Even when support is compiled in, this feature is opt-in for the user. Thanks for your consideration. -- Package-specific info: -- Addons package information -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable-debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.0.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) 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 Versions of packages firefox-esr depends on: ii debianutils 5.7-0.3 ii fontconfig 2.13.1-4.5 ii libasound2 1.2.7.2-1 ii libatk1.0-0 2.46.0-3 ii libc6 2.36-4 ii libcairo-gobject2 1.16.0-6 ii libcairo2 1.16.0-6 ii libdbus-1-3 1.14.4-1 ii libdbus-glib-1-2 0.112-2 ii libevent-2.1-7 2.1.12-stable-5+b1 ii libffi8 3.4.4-1 ii libfontconfig1 2.13.1-4.5 ii libfreetype6 2.12.1+dfsg-3 ii libgcc-s1 12.2.0-9 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libglib2.0-0 2.74.1-2 ii libgtk-3-0 3.24.34-3 ii libnspr4 2:4.35-1 ii libnss3 2:3.85-1 ii libpango-1.0-0 1.50.10+ds-1 ii libstdc++6 12.2.0-9 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.1-2 ii libx11-xcb1 2:1.8.1-2 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1.1 ii procps 2:3.3.17-7.1 ii zlib1g 1:1.2.11.dfsg-4.1 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.4.2-1+b3 ii libavcodec59 7:5.1.2-1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.005-1 ii fonts-stix [otf-stix] 1.1.1-4.1 ii libcanberra0 0.30-10 ii libgssapi-krb5-2 1.20-1+b1 ii pulseaudio 16.1+dfsg1-2+b1 -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#1023931: NULL pointer dereference when device UUID list is empty
Package: bluez-tools Version: 2.0~20170911.0.7cb788c-4 Severity: normal Tags: patch upstream Hi, There is a NULL pointer dereference in bt-device.c. Since upstream is not very active, please apply this patch downstream. It should be apparent that the only case in which behavior will differ is in the case that NULL would be dereferenced. --- src/bt-device.c.2 2022-11-12 11:59:49.948223308 -0500 +++ src/bt-device.c 2022-11-12 11:57:55.264211619 -0500 @@ -622,7 +622,7 @@ g_print(" Connected: %d\n", device_get_connected(device, )); g_print(" UUIDs: ["); const gchar **uuids = device_get_uuids(device, ); -for (int j = 0; uuids[j] != NULL; j++) +for (int j = 0; uuids && uuids[j] != NULL; j++) { if (j > 0) g_print(", "); g_print("%s", uuid2name(uuids[j])); I hope we can get this in Bookworm. Thanks! -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable-debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) 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 Versions of packages bluez-tools depends on: ii libc6 2.36-4 ii libglib2.0-0 2.74.1-1 ii libreadline8 8.2-1.1 Versions of packages bluez-tools recommends: ii bluez-obexd 5.65-1+b1 bluez-tools suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#1017367: glibc's inappropriate mbstowcs() attribute causes Binutils builds to fail
Package: binutils-source,libc6-dev Severity: important Tags: upstream Control: block 1016253 by -1 Control: block 1016224 by -1 Control: affects -1 src:binutils-sh-elf src:binutils-z80 Hi, See https://sourceware.org/bugzilla/show_bug.cgi?id=29447 and https://sourceware.org/bugzilla/show_bug.cgi?id=29265 for the sleuthing, but basically glibc has an inappropriate attribute on mbstowcs() that, when building recent binutils, causes build failures. This affects packages such as binutils-sh-elf. A workaround has already been applied on Binutils's Git, but this hasn't been uploaded to Debian yet; no released version of Binutils has the workaround yet. Due to the nature of this issue, I've filed it against both glibc and Binutils. Could a workaround be applied to at least one of these packages, or preferably both? -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable-debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, 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
Bug#1015901: ocrfeeder-cli is completely broken: AttributeError: type object 'IconSize' has no attribute 'SMALL_TOOLBAR'
Package: ocrfeeder Version: 0.8.3-3 Severity: normal ocrfeeder-cli doesn't work at all: $ ocrfeeder-cli -h /usr/lib/python3/dist-packages/ocrfeeder/util/lib.py:25: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '4.0') before import to ensure that the right version gets loaded. from gi.repository import Gtk Traceback (most recent call last): File "/usr/bin/ocrfeeder-cli", line 33, in from ocrfeeder.util.graphics import getImageResolution, convertMultiImagesInList File "/usr/lib/python3/dist-packages/ocrfeeder/util/graphics.py", line 20, in from .lib import getNonExistingFileName File "/usr/lib/python3/dist-packages/ocrfeeder/util/lib.py", line 35, in def getIconOrLabel(icon_name, label_text, icon_size = Gtk.IconSize.SMALL_TOOLBAR): AttributeError: type object 'IconSize' has no attribute 'SMALL_TOOLBAR' -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, 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 Versions of packages ocrfeeder depends on: ii ghostscript 9.56.1~dfsg-1 ii gir1.2-goocanvas-2.0 2.0.4-1+b1 ii gir1.2-gtk-3.0 3.24.34-1 ii gir1.2-gtkspell3-3.0 3.0.10-1 ii iso-codes 4.10.0-1 ii python3 3.10.4-1+b1 ii python3-enchant 3.2.2-1 ii python3-gi 3.42.1-1 ii python3-lxml 4.8.0-1 ii python3-odf 1.4.2-1 ii python3-pil 9.1.1-1 ii python3-reportlab 3.6.9-1 ii python3-sane 2.9.1-2+b1 ii tesseract-ocr 5.1.0-2 Versions of packages ocrfeeder recommends: ii unpaper 6.1-2+b2 ii yelp 42.1-2 ocrfeeder suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#967313: distccmon ported to GTK 3
Control: tags -1 fixed-upstream Control: forwarded -1 https://github.com/distcc/distcc/pull/407 It would be nice to see a release of distcc 3.4 so we can migrate away from GTK 2. signature.asc Description: This is a digitally signed message part
Bug#1014708: please package DejaGnu 1.6.3
Source: dejagnu Version: 1.6.2-1 Severity: wishlist Hi, DejaGnu 1.6.3 includes baseboards/riscv-sim.exp, the configuration for the RISC V simulator. This version of DejaGnu will be necessary to run the GCC test suite for gcc-riscv32-elf. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) 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
Bug#1014696: [PATCH] add a DEP-8 autopkgtest
Source: libiberty Version: 20211102-1 Severity: wishlist Tags: patch Hi, Attached is a patch that adds an autopkgtest to libiberty that exercises some of its functionality. I agree to keep this up-to-date with new releases. Thanks for your consideration -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) 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 diff -wruN a/debian/changelog b/debian/changelog --- a/debian/changelog 2021-11-02 09:09:37.0 -0400 +++ b/debian/changelog 2022-07-10 10:17:53.840907340 -0400 @@ -1,3 +1,10 @@ +libiberty (20211102-2) UNRELEASED; urgency=medium + + [ John Scott ] + * Add a DEP-8 test leveraging some functionality of libiberty. + + -- Debian GCC Maintainers Sun, 10 Jul 2022 10:17:31 -0400 + libiberty (20211102-1) unstable; urgency=medium * Update to 20210106. diff -wruN a/debian/copyright b/debian/copyright --- a/debian/copyright 2017-09-13 06:48:31.0 -0400 +++ b/debian/copyright 2022-07-10 10:24:34.296994497 -0400 @@ -135,6 +135,7 @@ Files: debian/* Copyright: 2013-2014 Matthias Klose + 2022 John Scott License: GPL-2+ This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by diff -wruN a/debian/tests/control b/debian/tests/control --- a/debian/tests/control 1969-12-31 19:00:00.0 -0500 +++ b/debian/tests/control 2022-07-10 10:23:05.448979031 -0400 @@ -0,0 +1,2 @@ +Test-Command: gcc debian/tests/libiberty.c -liberty -o "$AUTOPKGTEST_TMP"/liberty && "$AUTOPKGTEST_TMP"/liberty +Depends: gcc, libc-dev, libiberty-dev diff -wruN a/debian/tests/libiberty.c b/debian/tests/libiberty.c --- a/debian/tests/libiberty.c 1969-12-31 19:00:00.0 -0500 +++ b/debian/tests/libiberty.c 2022-07-10 10:18:06.384910899 -0400 @@ -0,0 +1,68 @@ +#define _POSIX_C_SOURCE 200809L +#include +#include +#include +#include +#include +#include +#include +#include + +int main(void) { + char *s = concat("foo", "bar", "bat", "baz", "cat", "ding", "dong", NULL); + if(puts(s) == EOF) { + perror("Failed to print string"); + abort(); + } + free(s); + + if(faccessat(AT_FDCWD, "/proc/self/fd/0", R_OK, AT_EACCESS) != -1) { + const int zerofd = open("/proc/self/fd/0", O_RDONLY); + if(zerofd == -1) { + perror("Failed to open /proc/self/fd/0"); + abort(); + } + if(!fdmatch(0, zerofd)) { + fputs("fds do not match!\n", stderr); + abort(); + } + if(close(zerofd) == -1) { + perror("Failed to close file descriptor"); + abort(); + } + } + + if(puts(getpwd()) == EOF) { + perror("Failed to print working directory"); + abort(); + } + if(EINVAL != strtoerrno("EINVAL")) { + fputs("strtoerrno failed\n", stderr); + abort(); + } + if(strcmp("ERANGE", strerrno(ERANGE))) { + fputs("strerrno failed\n", stderr); + abort(); + } + if(strcmp("SIGSEGV", strsigno(SIGSEGV))) { + fputs("strsigno failed\n", stderr); + abort(); + } + if(SIGABRT != strtosigno("SIGABRT")) { + fputs("strtosigno failed\n", stderr); + abort(); + } + + s = xasprintf("%d", 0); + if(puts(s) == EOF) { + perror("Failed to print string"); + abort(); + } + if(strcmp("0", s)) { + fputs("xasprintf gave unexpected results\n", stderr); + abort(); + } + free(s); + + +} 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
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
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
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
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#1008033: please make a new upload leveraging recent Poppler
Source: okular Version: 4:21.12.3-1 Severity: wishlist Okular and the version of Poppler now in unstable both support digital signing of PDFs, which is awesome. However, Okular checks at build time whether Poppler provides the functions necessary for PDF signing. It is sufficient to make a new no-change upload of Okular for it to build against the version of Poppler currently in unstable, and hence for it to support PDF signing automagically. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-1-amd64 (SMP w/2 CPU threads; PREEMPT) 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
Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters
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,
Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters
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
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#1002455: bison should recommend or suggest libbison-dev
Package: bison Version: 2:3.8.2+dfsg-1 Severity: wishlist I think that when beginners install Bison to use as yacc, they expect to find the Bison/yacc library installed as well. Even if it's not suited for Recommends, it would be nice to have libbison-dev in the Suggests, so that libbison-dev may be marked automatically installed and potentially autoremovable when Bison is removed. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_USER, 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 Versions of packages bison depends on: ii libc6 2.33-1 ii m4 1.4.18-5 bison recommends no packages. Versions of packages bison suggests: pn bison-doc -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#995157: libfido2: OpenSSL 3.0 support added upstream?
libfido2 1.9.0 was released a few days ago, and it seems like it might have all of the necessary changes to support OpenSSL 3.0, for example https://github.com/Yubico/libfido2/pull/357 I haven't tried building it though. signature.asc Description: This is a digitally signed message part
Bug#997767: open-ath9k-htc-firmware: FTBFS: patching fails
The fix is currently waiting in the NEW queue. signature.asc Description: This is a digitally signed message part
Bug#980889: RFP: binutils-sh-elf -- cross binary utilities for SuperH bare-metal systems
On Fri, 2021-10-22 at 11:18 +0200, John Paul Adrian Glaubitz wrote: > I had a look at the package and it throws a number of lintian errors. Are you > planning to address these or are they common for all binutils-$ARCH-elf > packages > we currently have in Debian? I believe you're referring to debian-rules-missing-required-target and debian-rules-missing-recommended-target. In this case, Lintian seems to not recognize that I'm using Debhelper via the .DEFAULT target in the Makefile. I've filed a Lintian bug for this (#983539). If it's really bothersome, I could switch debian/rules from .DEFAULT: dh $@ to %: dh $@ but I personally prefer the former as a stylistic choice, and this would cover up an area where Lintian should be smarter. As for debian-rules-sets-DH_COMPAT, which is merely a warning, Lintian has this to say: > As of debhelper version 4, the DH_COMPAT environment variable is only > to be used for temporarily overriding debian/compat. Any line in > debian/rules that sets it globally should be deleted and a separate > debian/compat file created if needed. I don't set DH_COMPAT globally; I use it as a temporary override for dh_auto_configure, and my source comments explain why I do this. I would consider filing a Lintian bug, and still would if you'd like me to, but frankly I'd like to keep the warning around as a reminder that we should drop this hack when we're able. signature.asc Description: This is a digitally signed message part
Bug#996639: Epiphany crashes when opening PDF in new tab (NULL pointer dereference)
Package: epiphany-browser Version: 41.0-2 Severity: normal Here is a proof-of-concept file you can open, assuming you have bash- doc installed: Proof of concept Link Clicking the link will try to open a new tab to view the PDF file in, but this causes Epiphany to crash. Here is the backtrace for the relevant thread: #0 0x7f6619804608 in decide_policy_cb (decision_type=WEBKIT_POLICY_DECISION_TYPE_RESPONSE, user_data=, decision=0x7f6600017e10 [WebKitResponsePolicyDecision], web_view=0x55a90c7f9230 [EphyWebView]) at ../embed/ephy-web-view.c:962 #1 decide_policy_cb (web_view=0x55a90c7f9230 [EphyWebView], decision=0x7f6600017e10 [WebKitResponsePolicyDecision], decision_type=, user_data=) at ../embed/ephy-web-view.c:919 #2 0x7f66126af9da in ffi_call_unix64 () at ../src/x86/unix64.S:105 #3 0x7f66126aeb21 in ffi_call_int (cif=0x7ffd473cb370, fn=0x7f66198044b0 , rvalue=, avalue=, closure=) at ../src/x86/ffi64.c:672 #8 0x7f6618cb92cf in (instance=, signal_id=, detail=) at ../../../gobject/gsignal.c:3553 #4 0x7f6618ca0edc in g_cclosure_marshal_generic (closure=closure@entry=0x55a90c7ef070, return_gvalue=return_gvalue@entry=0x7ffd473cb510, n_param_values=n_param_values@entry=3, param_values=param_values@entry=0x7ffd473cb570, invocation_hint=invocation_hint@entry=0x7ffd473cb4f0, marshal_data=marshal_data@entry=0x0) at ../../../gobject/gclosure.c:1534 #5 0x7f6618ca06cf in g_closure_invoke (closure=0x55a90c7ef070, return_value=return_value@entry=0x7ffd473cb510, n_param_values=3, param_values=param_values@entry=0x7ffd473cb570, invocation_hint=invocation_hint@entry=0x7ffd473cb4f0) at ../../../gobject/gclosure.c:830 #6 0x7f6618cb2a8b in signal_emit_unlocked_R (node=, detail=detail@entry=0, instance=instance@entry=0x55a90c7f9230, emission_return=emission_return@entry=0x7ffd473cb670, instance_and_params=instance_and_params@entry=0x7ffd473cb570) at ../../../gobject/gsignal.c:3742 #7 0x7f6618cb88e9 in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=var_args@entry=0x7ffd473cb720) at ../../../gobject/gsignal.c:3507 #9 0x7f661551ee8c in webkitWebViewMakePolicyDecision(_WebKitWebView*, WebKitPolicyDecisionType, _WebKitPolicyDecision*) () at ./Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:2627 #10 0x7f66154fcd18 in NavigationClient::decidePolicyForNavigationResponse(WebKit::WebPageProxy&, WTF::Ref >&&, WTF::Ref >&&, API::Object*) () at ./Source/WebKit/UIProcess/API/glib/WebKitNavigationClient.cpp:150 #11 0x7f661544ae33 in WebKit::WebPageProxy::decidePolicyForResponseShared(WTF::Ref >&&, WTF::ObjectIdentifier, WTF::ObjectIdentifier, WebKit::FrameInfoData&&, WebCore::PolicyCheckIdentifier, unsigned long, WebCore::ResourceResponse const&, WebCore::ResourceRequest const&, bool, WTF::String const&, bool, WebCore::BrowsingContextGroupSwitchDecision, unsigned long, unsigned long, WebKit::UserData const&) () at ./Source/WebKit/UIProcess/WebPageProxy.cpp:5681 #12 0x7f661544af3e in WebKit::WebPageProxy::decidePolicyForResponse(WTF::ObjectIdentifier, WebKit::FrameInfoData&&, WebCore::PolicyCheckIdentifier, unsigned long, WebCore::ResourceResponse const&, WebCore::ResourceRequest const&, bool, WTF::String const&, bool, WebCore::BrowsingContextGroupSwitchDecision, unsigned long, unsigned long, WebKit::UserData const&) () at ./Source/WebKit/UIProcess/WebPageProxy.cpp:5625 #13 0x7f6615184d0d in IPC::callMemberFunctionImpl, WebKit::FrameInfoData&&, WebCore::PolicyCheckIdentifier, unsigned long, WebCore::ResourceResponse const&, WebCore::ResourceRequest const&, bool, WTF::String const&, bool, WebCore::BrowsingContextGroupSwitchDecision, unsigned long, unsigned long, WebKit::UserData const&), std::tuple, WebKit::FrameInfoData, WebCore::PolicyCheckIdentifier, unsigned long, WebCore::ResourceResponse, WebCore::ResourceRequest, bool, WTF::String, bool, WebCore::BrowsingContextGroupSwitchDecision, unsigned long, unsigned long, WebKit::UserData>, 0ul, 1ul, 2ul, 3ul, 4ul, 5ul, 6ul, 7ul, 8ul, 9ul, 10ul, 11ul, 12ul>(WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(WTF::ObjectIdentifier, WebKit::FrameInfoData&&, WebCore::PolicyCheckIdentifier, unsigned long, WebCore::ResourceResponse const&, WebCore::ResourceRequest const&, bool, WTF::String const&, bool, WebCore::BrowsingContextGroupSwitchDecision, unsigned long, unsigned long, WebKit::UserData const&), std::tuple, WebKit::FrameInfoData, WebCore::PolicyCheckIdentifier, unsigned long, WebCore::ResourceResponse, WebCore::ResourceRequest, bool, WTF::String, bool, WebCore::BrowsingContextGroupSwitchDecision, unsigned long, unsigned long, WebKit::UserData>&&, std::integer_sequence) () at ./Source/WebKit/Platform/IPC/HandleMessage.h:43 #14 IPC::callMemberFunction, WebKit::FrameInfoData&&, WebCore::PolicyCheckIdentifier, unsigned long,
Bug#996552: RFS: newlib/3.3.0-1.2 [NMU] -- C library and math library for embedded systems
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
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
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
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
Bug#996432: ITS: newlib
Source: newlib Version: 3.3.0-1.1 Severity: important X-Debbugs-Cc: debian-toolch...@lists.debian.org, pkg-electronics-de...@alioth-lists.debian.net, m...@qa.debian.org The Newlib package is, in my opinion, currently in a poor state of affairs. * The upstream release 4.1.0 has yet to be packaged. * It currently uses an obsolete Debhelper compatibility level, which puts it at risk of being removed in the Bookworm release cycle (#965746). * Ports to new systems, such as riscv64-unknown-elf, are wanted (#980918). * There is at least one credible security issue which hasn't been addressed (#984446). I believe this package is eligible for salvaging based on these facts: * My previous NMU of Newlib went unacknowledged. * The maintainers have been unresponsive to my attempts at contact. * There has been no visible work on the package for 18 months. Here is my game plan for Newlib, which I have alluded to on the pkg- electronics-devel list and not gotten any pushback on: * It provides multiple benefits, including avoiding the bootstrap problem and enabling running of the GCC test suite, for the GCC packages for various ports to also be responsible for building Newlib. This can be done using a combined tree; an initial upload of gcc-sh-elf is imminent which will demonstrate this technique. * I will accordingly make gcc-arm-none-eabi responsible for building its own Newlib port by preparing a merge request soon. * libnewlib-dev is a misnomer; this package should really be called libnewlib-arm-none-eabi-dev. I will turn libnewlib-dev into a transitional package. * Only after the dust has settled will I upload Newlib 4.1.0. The "downstream consumers" (gcc-sh-elf, gcc-arm-none-eabi, gcc-riscv64- none-elf) will be able to migrate to this version at their own pace whenever they get rebuilt. * In the end, I plan for the Newlib source package to provide only two binaries: newlib-source, and libnewlib-doc. I expect that my work will be most welcome within the Electronics Team, but if they'd prefer, I could also maintain this under my own namespace. In any case, I'm not a project member and will require sponsorship, so I will not be able to upload this package on my own. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-2-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_USER, 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
Bug#996092: superficial autopkgtests not marked as superficial
Source: gpgme1.0 Version: 1.16.0-1.1 Severity: important In my opinion, this smells like a Policy violation, but I'm setting the severity at non-RC since it's not my judgment that matters, but that of the CI team. Because DEP-8 tests (autopkgtests) speed up migration and have other consequences on the release process, any tests that do not exercise a significant amount of functionality must be marked with Restrictions: superficial. I was wondering whether GPGME had any autopkgtests because I was interested in writing one. The Python test only checks that the gpg module can be imported and a context obtained, but doesn't do anything with it. Only checking if a module can be imported is the go-to example of a superficial test. The checky2106 test likewise doesn't actually exercise any actual functionality from GPGME, or even include the appropriate header. If you'd like a significant autopkgtest, I'd be glad to write one, but I'd like to bring to your attention that these existing tests really ought to be marked superficial. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-1-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_USER, 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
Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614
On Thu, 2021-09-30 at 09:18 -0400, John Scott wrote: > Outside a minimal chroot, on my desktop system, zbarimg seems to > process SVGs just fine. So this may be a case of a Recommends > (somewhere) not being installed wreaking havok, but in my opinion > zbarimg should still not behave this way when a Recommends is > missing. I've found the culprit: if libmagickcore-6.q16-6-extra is not installed, then this cryptic error occurs. I've reported this issue (the lack of a helpful error message) at https://github.com/mchehab/zbar/issues/202 . I'll leave it to the maintainer to decide what they'd like to do: either hardcode a dependency on libmagickcore-6.q16-6-extra, or switch zint's output format to PNG (I personally would prefer the latter). signature.asc Description: This is a digitally signed message part
Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614
Control: reassign -1 zbar-tools Control: notfound -1 zint/2.10.0-1 Control: owner -1 ! I think I've partially identified what is happening. It turns out that the version of zint in testing, despite being passed the --filetype=SVG flag, actually produces a PNG, which in the past has been happily processed by zbar. This bug in zint seems to have been fixed in the new version, so that specifying --filetype=SVG actually produces an SVG now. And it appears that the error is coming from zbarimg, which as a matter of fact gives the same error in a minimal chroot trying to process any SVG. Outside a minimal chroot, on my desktop system, zbarimg seems to process SVGs just fine. So this may be a case of a Recommends (somewhere) not being installed wreaking havok, but in my opinion zbarimg should still not behave this way when a Recommends is missing. I'll debug this more later, but for now I'm reassigning the bug to zbar-tools, since I see this is not an issue in zint. signature.asc Description: This is a digitally signed message part
Bug#986778: ITP: gcc-sh-elf -- GNU C compiler for embedded SuperH devices
On Sun, 2021-09-26 at 18:55 +0200, John Paul Adrian Glaubitz wrote: > I'm willing to sponsor this as I am Debian's primary maintainer of the sh4 > port. Thanks for your consideration! FYI, I just pushed a small fix for the Binutils autopkgtest to both Git and mentors.debian.net. I would appreciate any critique you have about the packaging. I'm on #debian- ports (my nick is pert) if you'd prefer discussion there as well. signature.asc Description: This is a digitally signed message part
Bug#977835: Please package the lastest version >= 3.5.2
On Tue, 22 Dec 2020 00:42:36 + (UTC) Thorsten Glaser wrote: > >thanks for considering > > Not before bullseye. There are many regressions and problems > with the new releases. I plan on doing (at least) one more > upload with more individual fixes backported, though ☺ > > My current plan is to package 3.6.x after bullseye, providing > them to users via bullseye-backports and buster-backports-sloppy > as usual. > > With enough time I’ll begin packaging these in experimental. Hi Thorsten, It's been a little while. Do you still plan on working on this? signature.asc Description: This is a digitally signed message part
Bug#994933: please revert the changes in 2.69-3 and re-add the add-runstatedir backport
Package: autoconf2.69 Version: 2.69-3 Severity: important Justification: breaking change, not in NEWS, makes draft packages FTBFS Control: block 994770 by -1 Control: block 985563 by -1 Hi, I'm working on packaging binutils-sh-elf, and I know of someone else working on updating binutils-m68hc1x. We're trying to provide these Binutils builds using the best practices recommended at https://wiki.debian.org/PackagingLessCommonBinutilsTargets (which I realize you did not write). To avoid reinventing the wheel, our packages have been using Debhelper, which passes --runstatedir via dh_auto_configure. The most recent changelog entry doesn't indicate that the backport was dropped to resolve any sort of bug, so could it please be reverted for the buildability of our packages? If this won't be reverted, feel free to mark it wontfix and close it. -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (2, 'unstable- debug'), (2, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_USER, 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 Versions of packages autoconf2.69 depends on: ii autoconf 2.71-2 ii debianutils 4.11.2 ii m4 1.4.18-5 ii perl 5.32.1-5 ii perl-base [libfile-temp-perl] 5.32.1-5 autoconf2.69 recommends no packages. autoconf2.69 suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#994625: ITP: carl9170fw -- libre firmware for AR9170 USB wireless adapters
Package: wnpp Severity: wishlist Owner: John Scott X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ker...@lists.debian.org Control: block -1 by 986778 Control: block 890601 by -1 Control: affects -1 linux-firmware-free * Package name : carl9170fw Version : 1.9.9-399-gcd480b9 Upstream Author : Linux wireless maintainers * URL : https://github.com/chunkeey/carl9170fw * License : mostly GPLv2-only Programming Lang: C Description : libre firmware for AR9170 USB wireless adapters This is carl9170, the libre firmware for Qualcomm Atheros's AR9170 802.11n USB wireless adapters that complements the carl9170 Linux driver. carl9170 is already shipped in firmware-linux-free, but the primary objective of transitioning it into this new source package is to get it building from source. This is possible with the SuperH bare-metal cross toolchain I'm packaging. I will need sponsorship for this package (and am currently seeking sponsors for the cross toolchain too); the Kernel Team may help with the former. Regardless, co-maintainers/uploaders are welcome and I'd be glad to help prospective contributors get adapters, as they can be a little tricky to find. 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
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#992689: dino crashing with new gnome 40
On Sun, 2021-08-22 at 13:43 -0400, Taowa wrote: > I'm planning on doing an upload this week to fix it- ideally today. Do you still got this, Taowa? signature.asc Description: This is a digitally signed message part
Bug#990618: Patch for GNOME Maps failing to start in Bullseye
Control: tags -1 patch Dear GNOME Team, I've attached a patch that's ready to address this issue in Bullseye. I'd have sent a merge request, but there's no Git branch for Bullseye yet. Unfortunately, the issue is tricky to reproduce organically because aerial view is no longer provided by the mapping service, not even using the version of GNOME Maps in Bullseye. However, the change is quite small, documented well upstream, and this change has already been cherrypicked in Ubuntu. For those reasons, I nevertheless think this is appropriate for integration in a point release. Description: mapView: Don't try to set aerial tiles if not available Safe-guard against setting the aerial tile source if it's not available in the service file. This avoid a crash if aerial was saved as last-used map type in gsettings and at next startup the service has dropped support. Author: Marcus Lundblad Origin: upstream, https://gitlab.gnome.org/GNOME/gnome-maps/-/commit/84fc4b2ae319ea155de52adceaa83a4da9f82c92.patch Bug: https://gitlab.gnome.org/GNOME/gnome-maps/-/issues/377 Bug-Debian: https://bugs.debian.org/990618 Bug-Ubuntu: https://launchpad.net/bugs/1930699 Applied-Upstream: 3.36.7, commit:84fc4b2ae319ea155de52adceaa83a4da9f82c92 Reviewed-By: John Scott Last-Update: 2021-08-30 --- gnome-maps-3.38.2.orig/src/mapView.js +++ gnome-maps-3.38.2/src/mapView.js @@ -401,15 +401,17 @@ var MapView = GObject.registerClass({ this._mapType = mapType; if (mapType !== MapType.LOCAL) { -if (mapType === MapType.AERIAL) { -if (Service.getService().tiles.hybridAerial && +let tiles = Service.getService().tiles; + +if (mapType === MapType.AERIAL && tiles.aerial) { +if (tiles.hybridAerial && Application.settings.get('hybrid-aerial')) { this.view.map_source = MapSource.createHybridAerialSource(); } else { this.view.map_source = MapSource.createAerialSource(); } } else { -if (Service.getService().tiles.streetDark && +if (tiles.streetDark && Application.settings.get('night-mode')) { this.view.map_source = MapSource.createStreetDarkSource(); } else { signature.asc Description: This is a digitally signed message part
Bug#984901: open-ath9k-htc-firmware upload is now release-critical
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
Bug#967797: Viking 1.9 supports GTK 3
Control: forwarded -1 https://github.com/viking-gps/viking/issues/111 Control: tags -1 upstream fixed-upstream I haven't tried it, but Viking 1.9 appears to support building with GTK 3 and deprecates GTK 2. signature.asc Description: This is a digitally signed message part
Bug#984404: zxing-cpp: ftbfs with GCC-11
This seems to be fixed in the version in experimental. signature.asc Description: This is a digitally signed message part
Bug#912271: newlib: diff for NMU version 3.3.0-1.1
Control: tags 912271 + pending Dear maintainer, I've prepared an NMU for newlib (versioned as 3.3.0-1.1) and uploaded it to DELAYED/15 via sponsorship. Please feel free to tell me if I should delay it longer. Regards. diff -Nru newlib-3.3.0/debian/changelog newlib-3.3.0/debian/changelog --- newlib-3.3.0/debian/changelog 2020-02-29 08:35:41.0 -0500 +++ newlib-3.3.0/debian/changelog 2021-06-08 17:17:43.0 -0400 @@ -1,3 +1,11 @@ +newlib (3.3.0-1.1) experimental; urgency=medium + + * Non-maintainer upload. + * Add newlib-source binary package to aid building for new targets. +(Closes: #912271) + + -- John Scott Tue, 08 Jun 2021 17:17:43 -0400 + newlib (3.3.0-1) unstable; urgency=medium [ Agustin Henze ] diff -Nru newlib-3.3.0/debian/control newlib-3.3.0/debian/control --- newlib-3.3.0/debian/control 2020-02-29 08:35:41.0 -0500 +++ newlib-3.3.0/debian/control 2021-02-03 10:05:40.0 -0500 @@ -56,3 +56,14 @@ . This package contains the newlib library compiled for Cortex-A*, Cortex-R4/R5/R7 and Cortex-M0/M0+/M3/M4 targets. + +Package: newlib-source +Architecture: all +Section: libdevel +Description: C library and math library for embedded systems (source) + Newlib is a C library and math library intended for use on embedded systems. + It is a conglomeration of several library parts, all under free software + licenses that make them easily usable on embedded products. + . + This package contains the upstream source code suitable for targeting + new platforms. diff -Nru newlib-3.3.0/debian/newlib-source.install newlib-3.3.0/debian/newlib-source.install --- newlib-3.3.0/debian/newlib-source.install 1969-12-31 19:00:00.0 -0500 +++ newlib-3.3.0/debian/newlib-source.install 2021-02-03 10:02:42.0 -0500 @@ -0,0 +1 @@ +debian/newlib-*.tar.xz usr/src/newlib/ diff -Nru newlib-3.3.0/debian/rules newlib-3.3.0/debian/rules --- newlib-3.3.0/debian/rules 2020-02-29 08:35:41.0 -0500 +++ newlib-3.3.0/debian/rules 2021-02-11 19:59:47.0 -0500 @@ -66,11 +66,14 @@ %: dh $@ -B$(BUILD_DIR) --with autotools-dev --parallel +debian/newlib-$(DEB_VERSION_UPSTREAM).tar.xz: + tar -acf $@ --exclude=debian --exclude-vcs --exclude='*.dh-orig' `pwd`/../`basename $(TOP_DIR)` + override_dh_clean: dh_clean - rm -rf $(BUILD_DIR) $(BUILD_NANO_DIR) $(TMP_NANO_DIR) + rm -rf $(BUILD_DIR) $(BUILD_NANO_DIR) $(TMP_NANO_DIR) debian/newlib-*.tar.xz -override_dh_auto_configure: +override_dh_auto_configure: debian/newlib-$(DEB_VERSION_UPSTREAM).tar.xz dh_auto_configure -B$(BUILD_DIR) -- $(CONFIGURE_FLAGS) dh_auto_configure -B$(BUILD_NANO_DIR) -- $(CONFIGURE_FLAGS_NANO)
Bug#992049: please build an API documentation package
Source: zbar Version: 0.23.90-1 Severity: wishlist The zbar headers appear to have Doxygen annotations, and the doc folder of the source tree has a doxygen.conf.in file. Please figure out how to build the zbar documentation and put it in a libzbar-doc package, since pre-built API documentation appears to be scarce on the web. -- System Information: Debian Release: 11.0 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-8-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
Bug#934916: libss7: FTBFS on x32 (time_t sprintf format mismatch)
Another (untested) way to fix this issue is to craft the format string using _Generic: strcpy(p, mtp3_timer2str(x)); p += strlen(p); -sprintf(p, "(%lis)%c", ss7->ss7_sched[ss7->links[i]->mtp3_timer[x]].when.tv_sec - time(NULL), +#define FORMAT _Generic((time_t){0}, long int: "(%lis)%c", long long int: "(%llis)%c") +sprintf(p, FORMAT, ss7->ss7_sched[ss7->links[i]->mtp3_timer[x]].when.tv_sec - time(NULL), ss7->ss7_sched[ss7->links[i]->mtp3_timer[x]].callback ? ' ' : '!');
Bug#981702: RFS: privacybadger/2021.2.2-1 -- browser extension automatically learns to block invisible trackers
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#990679: unblock: [pre-approval] privacybadger/2021.6.8-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: 981...@bugs.debian.org Control: block 981702 by -1 Please unblock package privacybadger [ Reason ] Privacy Badger is unique and different from other anti-tracking extensions in that instead of using artificial whitelists and blacklists, it learns based on one's browsing behavior. However, it was privately disclosed by Google's Security Team that Privacy Badger's learning, which is unique to each user, can itself enable fingerprinting: https://www.eff.org/deeplinks/2020/10/privacy-badger-changing-protect-you-better To address this, newer versions of Privacy Badger work by everyone using the same whitelists, yellowlists, and blacklists, which are aggregated from everyone's learning data. [ Impact ] If this unblock isn't granted, or it's not possible for Privacy Badger to be shipped in bullseye-updates during the release cycle, then users would be left more vulnerable to fingerprinting, as they could be identified based on their older Privacy Badger versions. Upstream has indicated that this situation would be unacceptable (and I concur), so it would be better to remove the package altogether then. This situation is not unlike the need to ship up-to-date ClamAV data in stable-updates. [ Tests ] Since this is a browser extension it's difficult to automate testing. I have tested with Firefox ESR, Firefox non-ESR, and Chromium that it works. [ Risks ] This package is a leaf package, and if this package were to be instead removed from Bullseye, users would need to install it manually by fetching the extension from another source. The debdiff is quite large, but consists mostly of changes to the website data and translations. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing This is a request for pre-approval since I need to seek a sponsor to update the package anyway. My debdiff was detected as malware so you'll have to fetch it from https://salsa.debian.org/-/snippets/549/raw/master/privacybadger.diff unblock privacybadger/2021.6.8-1 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
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
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#986735: add some superficial DEP-8 tests to libstrophe
On Sun, 20 Jun 2021 19:22:52 + John Scott wrote: > I've spruced up the patch a little bit and and made it work on > systems not running systemd. The new patch which may be applied with > 'git am' to debian/experimental is attached Forgot to close the bug in the changelog entry... From 7871954461d561f3bdd76d236085b992052cbc6a Mon Sep 17 00:00:00 2001 From: John Scott Date: Sun, 20 Jun 2021 15:30:31 -0400 Subject: [PATCH] Add two superficial DEP-8 tests to test the installed package. --- debian/changelog | 10 ++ debian/tests/build-examples | 5 + debian/tests/control | 7 +++ debian/tests/in-band-registration | 27 +++ 4 files changed, 49 insertions(+) create mode 100755 debian/tests/build-examples create mode 100644 debian/tests/control create mode 100755 debian/tests/in-band-registration diff --git a/debian/changelog b/debian/changelog index b4318ae..303aa36 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +libstrophe (0.11.0~git20210323.d7a28f9-2) UNRELEASED; urgency=medium + + [ John Scott ] + * Add two superficial DEP-8 tests to test the installed package: +- check that the installed examples can be compiled +- try making a user using in-band registration on a local server +(Closes: #986735) + + -- John Scott Sun, 20 Jun 2021 15:30:31 -0400 + libstrophe (0.11.0~git20210323.d7a28f9-1) experimental; urgency=medium * Team upload diff --git a/debian/tests/build-examples b/debian/tests/build-examples new file mode 100755 index 000..115ed22 --- /dev/null +++ b/debian/tests/build-examples @@ -0,0 +1,5 @@ +#!/bin/sh +set -e +cd "$AUTOPKGTEST_TMP" +find /usr/share/doc/libstrophe-dev/examples -name '*.c' -exec \ + sh -c 'gcc {} $(pkg-config --cflags --libs libstrophe) -o $(basename {} .c)' \; diff --git a/debian/tests/control b/debian/tests/control new file mode 100644 index 000..3cd62c9 --- /dev/null +++ b/debian/tests/control @@ -0,0 +1,7 @@ +Tests: build-examples +Depends: libstrophe-dev, gcc, pkg-config +Restrictions: superficial + +Tests: in-band-registration +Depends: libstrophe-dev, gcc, pkg-config, prosody +Restrictions: isolation-container, needs-root, superficial diff --git a/debian/tests/in-band-registration b/debian/tests/in-band-registration new file mode 100755 index 000..75a2684 --- /dev/null +++ b/debian/tests/in-band-registration @@ -0,0 +1,27 @@ +#!/bin/sh +set -e + +# Allow in-band registration +sed -i 's/allow_registration.*$/allow_registration = true/' /etc/prosody/prosody.cfg.lua + +# We're probably using an auto-generated self-signed certificate; don't require that clients trust it. +sed -i 's/c2s_require_encryption.*$/c2s_require_encryption = false/' /etc/prosody/prosody.cfg.lua +prosodyctl check config +service prosody restart + +cd "$AUTOPKGTEST_TMP" +cp /usr/share/doc/libstrophe-dev/examples/register.c . + +# Delete the block that tries TLS; it may not be trusted. +sed -i '/child = xmpp_stanza_get_child_by_name(stanza, "starttls")/,/}/d' register.c + +gcc register.c -o register $(pkg-config --cflags --libs libstrophe) +printf "foo\nbar\n" | (./register foo@localhost 2>&1) + +prosodyctl deluser foo@localhost + +# As an assertion check, let's validate that trying to delete a non-existent user returns failure. +prosodyctl deluser nonexistent@localhost 2>&1 || FAILED=1 +if [ "$FAILED" != "1" ] +then exit 1 +fi -- 2.30.2 signature.asc Description: This is a digitally signed message part
Bug#986735: add some superficial DEP-8 tests to libstrophe
I've spruced up the patch a little bit and and made it work on systems not running systemd. The new patch which may be applied with 'git am' to debian/experimental is attached From a0ec674ae155d4e4596078f286e4f2c29e3aca27 Mon Sep 17 00:00:00 2001 From: John Scott Date: Sat, 10 Apr 2021 12:38:10 -0400 Subject: [PATCH] Add two superficial DEP-8 tests to test the installed package. --- debian/changelog | 9 + debian/tests/build-examples | 5 + debian/tests/control | 7 +++ debian/tests/in-band-registration | 27 +++ 4 files changed, 48 insertions(+) create mode 100755 debian/tests/build-examples create mode 100644 debian/tests/control create mode 100755 debian/tests/in-band-registration diff --git a/debian/changelog b/debian/changelog index b4318ae..6f661b1 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +libstrophe (0.11.0~git20210323.d7a28f9-2) UNRELEASED; urgency=medium + + [ John Scott ] + * Add two superficial DEP-8 tests to test the installed package: +- check that the installed examples can be compiled +- try making a user using in-band registration on a local server + + -- Debian XMPP Maintainers Sun, 20 Jun 2021 14:41:49 -0400 + libstrophe (0.11.0~git20210323.d7a28f9-1) experimental; urgency=medium * Team upload diff --git a/debian/tests/build-examples b/debian/tests/build-examples new file mode 100755 index 000..115ed22 --- /dev/null +++ b/debian/tests/build-examples @@ -0,0 +1,5 @@ +#!/bin/sh +set -e +cd "$AUTOPKGTEST_TMP" +find /usr/share/doc/libstrophe-dev/examples -name '*.c' -exec \ + sh -c 'gcc {} $(pkg-config --cflags --libs libstrophe) -o $(basename {} .c)' \; diff --git a/debian/tests/control b/debian/tests/control new file mode 100644 index 000..3cd62c9 --- /dev/null +++ b/debian/tests/control @@ -0,0 +1,7 @@ +Tests: build-examples +Depends: libstrophe-dev, gcc, pkg-config +Restrictions: superficial + +Tests: in-band-registration +Depends: libstrophe-dev, gcc, pkg-config, prosody +Restrictions: isolation-container, needs-root, superficial diff --git a/debian/tests/in-band-registration b/debian/tests/in-band-registration new file mode 100755 index 000..75a2684 --- /dev/null +++ b/debian/tests/in-band-registration @@ -0,0 +1,27 @@ +#!/bin/sh +set -e + +# Allow in-band registration +sed -i 's/allow_registration.*$/allow_registration = true/' /etc/prosody/prosody.cfg.lua + +# We're probably using an auto-generated self-signed certificate; don't require that clients trust it. +sed -i 's/c2s_require_encryption.*$/c2s_require_encryption = false/' /etc/prosody/prosody.cfg.lua +prosodyctl check config +service prosody restart + +cd "$AUTOPKGTEST_TMP" +cp /usr/share/doc/libstrophe-dev/examples/register.c . + +# Delete the block that tries TLS; it may not be trusted. +sed -i '/child = xmpp_stanza_get_child_by_name(stanza, "starttls")/,/}/d' register.c + +gcc register.c -o register $(pkg-config --cflags --libs libstrophe) +printf "foo\nbar\n" | (./register foo@localhost 2>&1) + +prosodyctl deluser foo@localhost + +# As an assertion check, let's validate that trying to delete a non-existent user returns failure. +prosodyctl deluser nonexistent@localhost 2>&1 || FAILED=1 +if [ "$FAILED" != "1" ] +then exit 1 +fi -- 2.30.2 signature.asc Description: This is a digitally signed message part
Bug#986527: sagemath: FTBFS: addressing for Bullseye & newcomer suggestions
On Wed, 09 Jun 2021 00:32:02 + John Scott wrote: > I believe it's in the best interest of Debian users that this bug be > downgraded for Bullseye so Sage can be used in the mostly-wholesome > shape it's in, but since I lack expertise in maintaining it I too > will leave this to someone else. If you're looking for someone that can be committed to fixing issues in SageMath for the duration of the stable release cycle, I think I can step up to the plate, with the caveat that I will have to learn as I go since I don't yet know Python, but would like to learn and could seize this opportunity. (C is my forte, so perhaps I can help with some dependencies.) I've sent a merge request to add a superficial autopkgtest checking that 'sage -v' works, as it has broken in the past, and would appreciate if it could be merged (I believe this is appropriate during the freeze): https://salsa.debian.org/science-team/sagemath/-/merge_requests/14 Please let me know if there is any other low-hanging fruit I could work on as a newcomer to get acquainted with the package. signature.asc Description: This is a digitally signed message part
Bug#986527: sagemath: FTBFS: how to address for Bullseye
On Tue, 08 Jun 2021 17:15:44 +0200 Julien Puydt wrote: > I've been convinced that getting a fragile sagemath in next stable > wouldn't be a good thing. You've put much more effort than I have into maintaining scientific software in Debian, so I respect your opinion, but is it really accurate to say that SageMath is fragile as a whole? With respect to this particular issue, I'd like to share my perspective wrangling with a package that poses a similar dilemma: GCC (I'm working on packaging gcc-sh-elf). Like the status quo with SageMath in Debian, GCC has a test suite where failures are normal, and in general it takes an individual to watch out for what number of failures counts as "too many." Rather than hardcode an arbitrary threshold for what number of failing tests is acceptable, it seems that it's much better, and in the interest of Debian ports and alternative build environments, to just let the tests run for informative purposes. This, I believe, is what the GCC team actually does; the test results get sent to the team mailing list IIRC. Perhaps we should take a similar philosophy towards the tests. At least with GCC and DejaGnu, the test results get written out to a file, so before a new upload, say, one can do a diff on the old and new test results and see if any new regressions were introduced. In this same respect, SageMath test results may be best consulted before new uploads by hand. I believe it's in the best interest of Debian users that this bug be downgraded for Bullseye so Sage can be used in the mostly-wholesome shape it's in, but since I lack expertise in maintaining it I too will leave this to someone else. 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
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#989392: wmcpu+wmmatrix FTCBFS -- uses the build architecture compiler
On Wed, 2021-06-02 at 20:33 +0530, Nilesh Patra wrote: > wmcpu Fails to cross build because it hardcodes gcc as build > compiler in CC=gcc. > Simply removing this line would do the trick for us, however I've > replaced this with CC ?= gcc > Although this is a no-op for us, but this will help getting this > upstreamed. > Please consider applying the attched patch > > PS: Since this package hasn't been uploaded for more than 13 years, > which is a *really really* long time, I intend to NMU it post bullseye > release, with this patch applied - if not uploaded on time ofcourse. > > --- a/Makefile > +++ b/Makefile > @@ -1,4 +1,4 @@ > -CC = gcc > +CC ?= gcc But doesn't this line always do nothing, not just in Debian, but upstream as well? Per POSIX, CC is always pre-defined to a suitable C compiler such as 'c99', so the ?= operator will always leave the variable untouched. I think what you're looking for, borrowed from a wiki page describing the problem [1], is this GNU Make-specific syntax: ifeq ($(origin CC),default) CC = gcc endif This means "if CC is still its GNU Make default of 'cc' or (in POSIX mode) 'c99' and hasn't been set by the user, set it to gcc." This ought to be more suitable for upstream. If they're willing to do it they should, in my opinion, just rely on the preset value of $(CC) and not bother with setting it to gcc at all, unless they genuinely rely on gcc-specific features like warnings. Note: I've not taken a look at the packages, but believe the foregoing advice applies in general to upstream Makefile build systems. [1] https://wiki.debian.org/CrossBuildPackagingGuidelines 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
Control: tags -1 -moreinfo On Mon, 2021-05-31 at 20:25 +0200, Tobias Frost wrote: > I've took a look at your package: Awesome, thanks. > - d/copyright: > - The word "Comment:" went missing after the Files-Exlucded section. I don't believe this is an error. The Files-Excluded field is currently not specified by the machine-readable copyright specification (this is bug #685506), but at least the mk-origtargz manual page specifies that this should be what the spec calls 'formatted text', i.e. the current syntax should be valid: > (In debian/copyright, the Files-Excluded and Files-Excluded-component > stanzas are a part of the first paragraph and there is a blank line > before the following paragraphs which contain Files and other > stanzas. See uscan(1) "COPYRIGHT FILE EXAMPLE".) > - Please review the file. I see e.g the section for "Files: *" be > gone, not sure if that is intentional (I did not a d/copyright > review) This was intentional. > Lintian is the same oppionion that there is something missing: > > W: open-ath9k-htc-firmware source: file-without-copyright-information > .gitignore > W: open-ath9k-htc-firmware source: file-without-copyright-information > NOTICE.TXT > W: open-ath9k-htc-firmware source: file-without-copyright-information > README Those files have no copyright information, but they are so small they're probably not copyrightable. There s no copyright status to associate with them, so it's better that the copyright file say nothing at all with respect to them. > - 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. > 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. signature.asc Description: This is a digitally signed message part
Bug#988964: please demote diffoscope to Recommends
Package: reprotest Version: 0.7.16 Severity: minor On my system, reprotest has the following Depends/Recommends: Depends: diffoscope (>= 112~), python3-distro, python3-rstr, python3:any, python3-debian, apt-utils, libdpkg-perl, procps, python3-pkg-resources Recommends: disorderfs, faketime, locales-all, sudo Reprotest should really recommend Diffoscope so that users don't need to install it whom only want to check if packages are reproducible; this is what the --no-diffoscope argument is for. I would send a Merge Request, but I frankly can't figure out where this comes from. The applicable section in debian/control says Depends: ${python3:Depends}, python3-debian, apt-utils, libdpkg-perl, procps, python3-pkg-resources, python3-rstr, ${misc:Depends} Recommends: diffoscope (>= 112~), disorderfs, faketime, locales-all, sudo, so my only guess is that Diffoscope gets pulled into ${python3:Depends}? -- System Information: Debian Release: 11.0 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-6-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 Versions of packages reprotest depends on: ii apt-utils 2.2.3 ii diffoscope 172 ii libdpkg-perl 1.20.9 ii procps 2:3.3.17-5 ii python3 3.9.2-3 ii python3-debian 0.1.39 ii python3-distro 1.5.0-1 ii python3-pkg-resources 52.0.0-3 ii python3-rstr 2.2.6-2 Versions of packages reprotest recommends: ii disorderfs 0.5.11-1 ii faketime 0.9.8-9 ii locales-all 2.31-12 ii sudo 1.9.5p2-3 Versions of packages reprotest suggests: ii autodep8 0.24 pn qemu-system ii qemu-utils 1:5.2+dfsg-10 pn schroot -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#809443: autopkgtest: support systemd-nspawn as an isolation-container level virtualization tool
I'd like to report that another reason to support systemd-nspawn, which really is an upgraded version of chroot, is that it Just Does The Right Thing. For example, using autopkgtest-virt-chroot without further preparation besides calling debootstrap causes my test to fail due to not having /dev/ set up. But systemd-nspawn takes care to mount the /dev filesystem. signature.asc Description: This is a digitally signed message part
Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found
Has anyone been able to reproduce this? Attempting to build Sage in a fresh unstable environment succeeds for me; perhaps the build failure was spurious. signature.asc Description: This is a digitally signed message part