Bug#1071007: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py
Control: reopen -1 = I see on git that the bug was closed with a Conflicts+Replaces stanza, but that's not the correct solution for this issue. As discussed on this bugreport, the fix is to not ship the file. Reopening to block the problematic package to migrate to testing. Cheers, -- Samuel Henrique
Bug#1070957: nghttp3: Stable backports for nghttp3 and ngtcp2
Source: nghttp3 Severity: wishlist X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org Hello Sakirnth, This is another issue related to HTTP3 support for curl. If we push the newer nghttp3 and ngtcp2 packages to stable-backports, we will be able to enable HTTP3 in curl there too. I would like to upload the current packages we have on testing (for both nghttp3 and ngtcp2) to stable-bpo, so they can clear the NEW queue (it might take a while). Then once the updated packages hit testing, I can update them on bpo and unblock http3 for curl there. Do you see any issues with this or have a preference on not following this approach? Regards, -- Samuel Henrique
Bug#1070079: nghttp3: Update to 1.1.0 or newer
Hello Sakirnth, > I am good and I hope you too. All good on my side too :) > On 4/29/24 22:24, Samuel Henrique wrote: > > So maybe it even makes sense to get the latest releases for the transition. > > I agree. I normaly do both nghttp3 and ngtcp2 the same time, therefore I > didn't want to block the t64 transition. Since ngtcp2 was a reverse > dependency of affected packages. I will try to upload the latest version > this weekend to experimental. Cool, I've already done a test build of curl and spotted no issues, but I will only upload it to experimental once ngtcp2 is also there (curl requires at least 1.2.0, latest is 1.5.0). > > Would you be interested in any kind of help for this? > > Thanks, I will let you know this weekend. Probably in testing the > rebuild of Wireshark with the new version of nghttp3. Sounds good, just let me know. > > If you would like, we could also put the package under the curl team. We are > > not a "real team" in the sense that we don't gate contributions, that's > > just to > > make it more easy and clear that people should feel free to do team-uploads. > > Yes, that would be good. Given that I can put ngtcp2 also under the curl > team. Awesome! Have a nice weekend! -- Samuel Henrique
Bug#1037258: curl -I (HEAD request) fails with HTTP/2 against a Debian Apache instance
I've requested help from upstream on curl-library: https://curl.se/mail/lib-2024-05/0020.html It looks like the regression is partially back on the 8.7.1 as well: > HTTP/2 200 > expires: Fri, 01 Jan 1980 00:00:00 GMT > pragma: no-cache > cache-control: no-cache, max-age=0, must-revalidate > x-content-type-options: nosniff > x-frame-options: sameorigin > referrer-policy: no-referrer > x-xss-protection: 1 > permissions-policy: interest-cohort=() > strict-transport-security: max-age=15552000 > vary: Accept-Encoding > x-clacks-overhead: GNU Terry Pratchett > content-type: text/plain > date: Sat, 11 May 2024 19:33:28 GMT > server: Apache > > curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1) I get both the payload and the error. Regards -- Samuel Henrique
Bug#1070917: pycurl: Please revert back to the GnuTLS libcurl, for HTTP3 support
Source: pycurl Version: 7.45.3-2 Severity: wishlist X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org Hello Scott, On the latest upload of pycurl, the libcurl variant used to link against was switched from GnutTLS to OpenSSL. The request came from #1065007 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065007) but I don't think there were any valid reasons for the switch documented on the request. We are about to enable HTTP3 on the GnutTlS libcurl, and it's very unlikely that we will get HTTP3 support for the OpenSSL libcurl before the next stable release. If you revert the change back to GnutTLS, then pycurl will have support for HTTP3 very soon, otherwise it won't get it until after the next stable release. I also have plans on moving curl (the CLI) to the GnutTLS libcurl so we can get HTTP3 support on the curl command for the next stable release. For reference, this table lists the options which would be missing from GnuTLS, compared to OpenSSL (some of them are OpenSSL-specific so GnuTLS is not really missing): https://curl.se/libcurl/c/tls-options.html Curl upstream has shown interest in helping increase the compatibility for GnutTLS, so we can open a feature request for any option there that's mising. I believe it won't be an issue to revert back to GnuTLS because that's what the package was using before the latest upload. Regards, -- Samuel Henrique
Bug#1070079: nghttp3: Update to 1.1.0 or newer
Source: nghttp3 X-Debbugs-Cc: c...@packages.debian.org, samuel...@debian.org Version: 1.1.0-1 Severity: wishlist Hello Sakirnth, I hope you're doing well. I see that you uploaded nghttp3 1.1.0-1 and ngtcp2 1.1.0-1 to experimental already. Do you have any plans to push those to unstable anytime soon? I would like to enable HTTP3 on libcurl-gnutls and it requires: nghttp3: v1.1.0 ngtcp2: v1.2.0 The latest releases are: nghttp3 v1.2.0 ngtcp2 v1.4.0 So maybe it even makes sense to get the latest releases for the transition. Would you be interested in any kind of help for this? If you would like, we could also put the package under the curl team. We are not a "real team" in the sense that we don't gate contributions, that's just to make it more easy and clear that people should feel free to do team-uploads. Regards, -- Samuel Henrique
Bug#1069258: ruby-curb: test regression with curl 8.7.1: client read function EOF fail, only only 4/5 of needed bytes read
Hello all, > These messages with "only only (n)/(n+1) of needed bytes read" seem to > be characteristic. As well as being a FTBFS, this is also an autopkgtest > regression when upgrading curl, which is one of several factors preventing > curl from migrating; that, in turn, blocks elfutils, which blocks GLib, > which will likely be blocking a significant chunk of the 64-bit time_t > transition. I believe this is an issue on ruby-curb and not on curl, check the following thread on curl-library for details and possible solutions: https://curl.se/mail/lib-2024-03/0054.html Cheers, -- Samuel Henrique
Bug#1065007: pycurl: Please reconsider SSL choice (OpenSSL instead of GnuTLS)
Hello Boyuan and Scott, > I was made aware of issues encountered by multiple users due to pycurl using > GnuTLS instead of OpenSSL. Reviewing https://bugs.debian.org/515200 , it > looks like the > only reason of not using OpenSSL is the old OpenSSL licensing issue in the > past. That bug is 15 years old and you did not mention any details about the issues that you're having. Effectively there is no documented reason to switch to openssl on this bug. Scott, I see that you went ahead and switched to openssl anyway: > I don't have any objections to rebuilding pycurl with openssl. We are close to enabling support to http3 for the gnutls libcurl, so this switch kills any possibility of pycurl supporting http3, at least until openssl gets proper http3 support (might not happen for the next stable release). On the curl side, we are considering switching the default backend used by curl (the cli) for the gnutls one, so we can enable http3. Boyuan, can you provide any details on the issues you found? Otherwise I would recommend staying with gnutls for now and so pycurl will soon make use of a http3-enabled libcurl. Cheers, -- Samuel Henrique
Bug#1065787: 64-bit time_t transition: cargo needs manual intervention
On Sat, 16 Mar 2024 at 14:29, Simon McVittie wrote: > On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote: > > For example curl isn't building on armel/armhf now and numerous packages > > that > > depend of curl are not building on armel/armhf. > > I believe a maintainer upload or NMU of #1066981 and #1066982 would > now be enough to unblock curl, which would hopefully unblock a lot of > the C/C++ ecosystem (in particular fixing the unsatisfiable dependency > libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow > gdb to be installed), while also making life easier for the people trying > to re-bootstrap cargo. I've uploaded curl 8.6.0-4 with the patches from #1066981 and #1066982, thank you for those, Simon! Cheers, -- Samuel Henrique
Bug#1061992: curl: NMU diff for 64-bit time_t transition
Hello Michael, > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > curl as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Can you tell us which case it is? Is it confirmed affected or is this a guess? I know the curl project has put a lot of effort into this issue already but I don't know the specifics enough to understand whether this is a false positive or not. https://daniel.haxx.se/blog/2018/02/01/reducing-2038-problems-in-curl/ https://github.com/curl/curl/issues/2238 > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. The debdiff is reversed, took me a bit to understand it. Does this mean we should hold on pushing new uploads to testing and experimental until this is done? If so, how long will it take? The curl repo is under the debian namespace on salsa, so feel free to push your commits there once the upload is done (debian/experimental branch for experimental). Regards -- Samuel Henrique
Bug#1057855: curl: segmentation fault when connecting to LDAP server
Hello Tianyu, > When using curl 8.5.0-1 performing a request to ldap://db.debian.org, curl > received signal SIGSEGV, Segmentation fault. I have not looked into this yet but our CI test also spotted a regression, the package won't migrate to testing due to that and it's likely it spotted the same issue as you. https://ci.debian.net/packages/c/curl/testing/amd64/40802824/#S13 https://ci.debian.net/packages/c/curl/ Thank you for reporting this. -- Samuel Henrique
Bug#1056719: minizip: CVE-2023-45853
Source: minizip X-Debbugs-CC: t...@security.debian.org, samuel...@debian.org Severity: important Tags: security Version: 1.1-8 Hi, The following vulnerability was published for minizip. CVE-2023-45853[0]: | MiniZip in zlib through 1.3 has an integer overflow and resultant | heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long | filename, comment, or extra field. NOTE: MiniZip is not a supported | part of the zlib product. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-45853 https://www.cve.org/CVERecord?id=CVE-2023-45853 Please adjust the affected versions in the BTS as needed. Cheers, -- Samuel Henrique
Bug#1056718: minizip: CVE-2023-45853
Package: minizip X-Debbugs-CC: t...@security.debian.org, samuel...@debian.org Severity: important Tags: security Version: 1.1-8 Hi, The following vulnerability was published for minizip. CVE-2023-45853[0]: | MiniZip in zlib through 1.3 has an integer overflow and resultant | heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long | filename, comment, or extra field. NOTE: MiniZip is not a supported | part of the zlib product. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-45853 https://www.cve.org/CVERecord?id=CVE-2023-45853 Please adjust the affected versions in the BTS as needed. Cheers, -- Samuel Henrique
Bug#1056670: libairspy0: DEP17 P7: Shared multiarch file loss
Package: libairspy0
Version: 1.0.10-2
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: dep17p7
X-Debbugs-CC: helm...@debian.org
Dear Maintainer,
libairspy0 contains udev rules which are installed to /lib; these files
need to be moved to /usr/lib as part of Debian's usr-merge effort.
Because libairspy0 is Multi-Arch: same, an unfortunate corner-case can
occur whereby shared files (such as the udev rules) may be erroneously
removed on upgrades (please see DEP17[0] P7: Shared multiarch file
loss).
I have raised a Salsa MR[1] and attached an equivalent patch which avoids
the problem by implementating DEP17 M10 (Protective diversions for
shared files) for the affected files.
Please consider applying this patch at your earliest convenience. This
bug will be upgraded to release critical soon, as it blocks the overall
usr-merge effort which is being undertaken for the trixie release.
Cheers,
[0] https://subdivi.de/~helmut/dep17.html
[1] https://salsa.debian.org/bottoms/pkg-airspy-host/-/merge_requests/3
--
Samuel Henrique
>From 88072b72a2a756df85f6760913363af2d23d8272 Mon Sep 17 00:00:00 2001
From: Samuel Henrique
Date: Fri, 24 Nov 2023 16:13:38 +
Subject: [PATCH] DEP17: Install udev rules into /usr
With (M10) protective diversion against possible file loss as exhibited
by Multi-Arch: same packages (P7). Diversion code can be removed in
forky+1.
---
debian/{libairspy0.udev => 60-libairspy0.rules} | 0
debian/changelog| 8
debian/libairspy0.install | 1 +
debian/libairspy0.lintian-overrides | 2 ++
debian/libairspy0.postinst | 9 +
debian/libairspy0.postrm| 15 +++
debian/libairspy0.preinst | 14 ++
7 files changed, 49 insertions(+)
rename debian/{libairspy0.udev => 60-libairspy0.rules} (100%)
create mode 100644 debian/libairspy0.lintian-overrides
create mode 100644 debian/libairspy0.postrm
create mode 100644 debian/libairspy0.preinst
diff --git a/debian/libairspy0.udev b/debian/60-libairspy0.rules
similarity index 100%
rename from debian/libairspy0.udev
rename to debian/60-libairspy0.rules
diff --git a/debian/changelog b/debian/changelog
index 1ae9cf4..5d81bb9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+airspyone-host (1.0.10-3) UNRELEASED; urgency=medium
+
+ * DEP17: Install udev rules into /usr, with (M10) protective diversion
+against possible file loss as exhibited by Multi-Arch: same packages (P7).
+Diversion code can be removed in forky+1.
+
+ -- Samuel Henrique Fri, 24 Nov 2023 14:23:28 +
+
airspyone-host (1.0.10-2) unstable; urgency=medium
* update to v1.0.10-6-g41c439f
diff --git a/debian/libairspy0.install b/debian/libairspy0.install
index a7e6b7c..38ee09d 100644
--- a/debian/libairspy0.install
+++ b/debian/libairspy0.install
@@ -1,2 +1,3 @@
usr/lib/*/lib*.so.*
debian/com.airspy.host.metainfo.xml usr/share/metainfo
+debian/60-libairspy0.rules usr/lib/udev/rules.d
diff --git a/debian/libairspy0.lintian-overrides b/debian/libairspy0.lintian-overrides
new file mode 100644
index 000..9c24985
--- /dev/null
+++ b/debian/libairspy0.lintian-overrides
@@ -0,0 +1,2 @@
+# protective diversion for upgrades of files moved from / to /usr
+libairspy0: diversion-for-unknown-file lib/udev/rules.d/60-libairspy0.rules [preinst:11]
diff --git a/debian/libairspy0.postinst b/debian/libairspy0.postinst
index 21edfc4..ecb72c2 100644
--- a/debian/libairspy0.postinst
+++ b/debian/libairspy0.postinst
@@ -20,6 +20,15 @@ if [ "$1" = "configure" ]; then
# try to update udev now
udevadm control --reload-rules || true ;
fi
+# begin-remove-after: released:forky
+ # protective diversion of files moved from / to /usr, to avoid file loss.
+ # Only for upgrades.
+# At this point, the package will have installed the same file in */usr*.
+dpkg-divert --package usr-is-merged --no-rename \
+--divert /lib/udev/rules.d/60-libairspy0.rules.usr-is-merged \
+--remove /lib/udev/rules.d/60-libairspy0.rules
+# end-remove-after
+
fi
exit 0
diff --git a/debian/libairspy0.postrm b/debian/libairspy0.postrm
new file mode 100644
index 000..e370229
--- /dev/null
+++ b/debian/libairspy0.postrm
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:forky
+# protective diversion of files moved from / to /usr, to avoid file loss.
+# Only for upgrades.
+if [ "$1" = "configure" ]; then
+# At this point, the package will have installed the same file in */usr*.
+dpkg-divert --package usr-is-merged --no-rename \
+--divert /lib/udev/rules.d/60-libairspy0.rules.usr-is-merged \
+--remove /lib/udev/rules.d/60-libairspy0.rules
+fi
+# end-remove-after
+
diff --git a/debian/libairspy0.preinst b/debian/libairspy0.preinst
new file mode 100644
index 000..af1e4a4
---
Bug#1054871: ITP: legba -- A fast multi protocol credential bruteforcer/sprayer/enumerator
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Samuel Henrique Severity: wishlist * Package name: legba Version : 0.2.0 Upstream Contact: Simone Margaritelli * URL : https://github.com/evilsocket/legba * License : GPL-3.0 Programming Lang: Rust Description : A fast multi protocol credential bruteforcer/sprayer/enumerator Legba is a multiprotocol credentials bruteforcer / password sprayer and enumerator built with Rust and the Tokio asynchronous runtime in order to achieve better performances and stability while consuming less resources than similar tools. I plan to maintain this package under the pkg-security[0] and/or rust team[1]. [0] https://tracker.debian.org/teams/pkg-security/ [1] In case it ends up being easier to maintain under the rust team, due to the way Rust crates are packaged. -- Samuel Henrique
Bug#1037258: curl -I (HEAD request) fails with HTTP/2 against a Debian Apache instance
Since 2023-10-02, we have a fixed version of the curl package on stable-backports, so this can serve as a workaround if you're fine with the constraints of the backports repository[0]. The current investigation status is that we know which commit caused the regression and which one fixed it, but we don't know exactly what change in the fixing commit is required (it's changing a lot of things at once). We also don't know exactly what are the conditions that trigger the issue, but we know it has to do with HTTP2 and there are a couple of endpoints we can use for debugging. Regression commit: https://github.com/curl/curl/commit/8c762f59983a3e9e2b80fdb34aa5e08f1d9a1c7d (curl-7_88_0) Fixing commit: https://github.com/curl/curl/commit/744dcf22fac6cf12a9112df106b61864982afef9 (curl-8_1_0) [0]: https://backports.debian.org/ Cheers, -- Samuel Henrique
Bug#1053997: bullseye-pu: package curl/7.74.0-1.3+deb11u11
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] This change provides DEB_VERSION on "--version" output. It's common for curl users to provide the output of "curl --version" when reporting issues, and there have been cases where having the version of the package in that output would have saved time (e.g.: if we don't know which distro the person is using and/or whether the package is up-to-date). Recently, on a Twitter thread, someone was assuming that a server was not patched for "CVE-2023-38545" because they only saw the upstream version. With this change, the "Release-Date" line of the output will change from e.g.: Release-Date: 2020-12-09 to: Release-Date: 2020-12-09, security patched: 7.88.1-10+deb12u4 [ Impact ] // Explained in the "Reason" section. [ Tests ] Curl has an extensive test suite and no failures were detected. [ Risks ] The only affected code is a single "printf" statement, which is changed to include the version: https://github.com/curl/curl/blob/curl-7_74_0/src/tool_help.c#L949-L954 There's a risk that scripts parsing the "Release-Date:" line from "--version" might fail to parse the date if the regex is badly written. I think it's very unlikely that there are scripts parsing that line of the output. Assuming there is one, and that it's using a bad regex, the risk is that it will match more than just the release date. [ 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 ] d/rules is now importing "/usr/share/dpkg/pkg-info.mk" and setting "CURL_PATCHSTAMP" to the value of "DEB_VERSION". Effectively, this only changes the output of "curl --version" (on the "Release-Date" line). [ Other info ] I'm opening -pu bugs against bullseye, bookworm, and I'll check with the LTS team if they accept this change for buster. -- Samuel Henrique curl_7.74.0-1.3+deb11u11.debdiff Description: Binary data
Bug#1053998: bookworm-pu: package curl/7.88.1-10+deb12u5
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bookworm X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] This change provides DEB_VERSION on "--version" output. It's common for curl users to provide the output of "curl --version" when reporting issues, and there have been cases where having the version of the package in that output would have saved time (e.g.: if we don't know which distro the person is using and/or whether the package is up-to-date). Recently, on a Twitter thread, someone was assuming that a server was not patched for "CVE-2023-38545" because they only saw the upstream version. With this change, the "Release-Date" line of the output will change from e.g.: Release-Date: 2020-12-09 to: Release-Date: 2020-12-09, security patched: 7.88.1-10+deb12u4 [ Impact ] // Explained in the "Reason" section. [ Tests ] Curl has an extensive test suite and no failures were detected. [ Risks ] The only affected code is a single "printf" statement, which is changed to include the version: https://github.com/curl/curl/blob/curl-7_88_1/src/tool_help.c#L171-L176 There's a risk that scripts parsing the "Release-Date:" line from "--version" might fail to parse the date if the regex is badly written. I think it's very unlikely that there are scripts parsing that line of the output. Assuming there is one, and that it's using a bad regex, the risk is that it will match more than just the release date. [ 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 ] d/rules is now importing "/usr/share/dpkg/pkg-info.mk" and setting "CURL_PATCHSTAMP" to the value of "DEB_VERSION". Effectively, this only changes the output of "curl --version" (on the "Release-Date" line). [ Other info ] I'm opening -pu bugs against bullseye, bookworm, and I'll check with the LTS team if they accept this change for buster. -- Samuel Henrique curl_7.88.1-10+deb12u5.debdiff Description: Binary data
Bug#1053781: unblock: curl/8.3.0-3
Package: release.debian.org
Control: affects -1 + src:curl
X-Debbugs-Cc: c...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sergi...@debian.org, charlesmel...@riseup.net,
samuel...@debian.org
Severity: important
Please unblock package curl
[ Reason ]
The new package on unstable is fixing two just released CVEs, one low and one
high severity.
The high severity CVE can void the privacy of proxy users, by allowing remote
servers to trigger a local DNS resolution on the user's side.
These 2 CVEs have been fixed on bullseye-security, bullseye-backports,
bookworm-security, bookworm-backports and unstable.
I would like the fix to migrate to testing before running all CI tests and
waiting for the bake period.
[ Impact ]
The fix of the privacy-breaching CVE takes longer to reach testing, and
possibly longer to reach our derivatives as well.
CVE details:
CVE-2023-38545 (High sev)
https://curl.se/mail/lib-2023-10/0018.html
CVE-2023-38546 (Low sev)
https://curl.se/mail/lib-2023-10/0019.html
[ Tests ]
Curl's own testsuite ran and had no errors (we run that on dh_auto_test).
[ Risks ]
There were no considerable changes required to backport the patches, the only
change was a makefile adjustment due to the context having been changed. This
was for the new test and I've confirmed it is running.
The difference between the package on testing (revision -2) and unstable
(revision -3) is minimal too (only the two new patches).
[ 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
[ Other info ]
I purposedly backported the fix instead of packaging 8.4.0 to allow for a
faster migration to testing. Once it migrates, I'll push the pacckaging for
8.4.0.
The security team is about to release the fixes for bookworm-sec and
bullseye-sec. I have pushed the unstable, bookworm-bpo and bullseye-bpo just
now.
unblock curl/8.3.0-3
diff -Nru curl-8.3.0/debian/changelog curl-8.3.0/debian/changelog
--- curl-8.3.0/debian/changelog 2023-10-01 15:01:42.0 +0100
+++ curl-8.3.0/debian/changelog 2023-10-05 22:26:40.0 +0100
@@ -1,3 +1,9 @@
+curl (8.3.0-3) unstable; urgency=high
+
+ * Add patches to fix CVE-2023-38545 and CVE-2023-38546
+
+ -- Samuel Henrique Thu, 05 Oct 2023 22:26:40 +0100
+
curl (8.3.0-2) unstable; urgency=medium
* d/rules: Add test 3102 to TESTS_FAILS_ON_IPV6_ONLY_MACHINES
diff -Nru curl-8.3.0/debian/patches/CVE-2023-38545.patch
curl-8.3.0/debian/patches/CVE-2023-38545.patch
--- curl-8.3.0/debian/patches/CVE-2023-38545.patch 1970-01-01
01:00:00.0 +0100
+++ curl-8.3.0/debian/patches/CVE-2023-38545.patch 2023-10-05
22:26:40.0 +0100
@@ -0,0 +1,130 @@
+From a6c541e709096a09eb3df6a8fbbe058239d63a55 Mon Sep 17 00:00:00 2001
+From: Jay Satiro
+Date: Sat, 30 Sep 2023 03:40:02 -0400
+Subject: [PATCH] socks: return error if hostname too long for remote resolve
+
+Prior to this change the state machine attempted to change the remote
+resolve to a local resolve if the hostname was too long. Unfortunately
+that did not always work as intended, leading to a security issue. And
+when it did it's a privacy violation for users of socks5h that may
+expect their DNS requests will not leak.
+
+Bug: https://curl.se/docs/CVE-2023-38545.html
+
+Backported by: Samuel Henrique
+
+---
+ lib/socks.c | 13 +
+ tests/data/Makefile.inc | 2 +-
+ tests/data/test728 | 64 +
+ 3 files changed, 73 insertions(+), 6 deletions(-)
+ create mode 100644 tests/data/test728
+
+--- a/lib/socks.c
b/lib/socks.c
+@@ -585,11 +585,14 @@ static CURLproxycode do_SOCKS5(struct Cu
+ infof(data, "SOCKS5: connecting to HTTP proxy %s port %d",
+ sx->hostname, sx->remote_port);
+
+-/* RFC1928 chapter 5 specifies max 255 chars for domain name in packet */
++/* RFC1928 chapter 5 specifies max 255 chars for domain name in packet.
++ If remote resolve is enabled and the host is too long then error.
++ The user's resolve setting is not overridden because that could be a
++ privacy violation and unexpected. */
+ if(!socks5_resolve_local && hostname_len > 255) {
+- infof(data, "SOCKS5: server resolving disabled for hostnames of "
+-"length > 255 [actual len=%zu]", hostname_len);
+- socks5_resolve_local = TRUE;
++ failf(data, "SOCKS5: the destination hostname is too long to be "
++"resolved remotely by the proxy.");
++ return CURLPX_LONG_HOSTNAME;
+ }
+
+ if(auth & ~(CURLAUTH_BASIC | CURLAUTH_GSSAPI))
+@@ -903,7 +906,7 @@ CONNECT_RESOLVE_REMOTE:
+ }
+ else {
+ socksreq[len++] = 3;
+-socksreq[len++] = (char) hostname_len; /* one byte address length */
++socksreq[len++] = (unsigned char
Bug#1053344: curl: Block migration to testing until more information is publicly available about last CVE
Package: curl X-Debbugs-Cc: sergi...@debian.org, charlesmel...@riseup.net, samuel...@debian.org Version: 8.3.0-2 Severity: serious Tags: upstream security Due to a recent email on the curl-library mailing list, I want to block the migration of the latest release to testing. https://curl.se/mail/lib-2023-10/0002.html The email mentions: > Due to the discovery of a serious security vulnerability we have now been > forced to immediately close the feature window and instead start preparing for > a cycle-breaking early release. I don't know which versions of curl this "serious security vulnerability" affects, but I'm being extra careful here in blocking the migration of 8.3.0 to testing. In case this CVE only affects 8.3.0, then testing will be safe. If it also affects older releases, then blocking the migration doesn't change anything, but it's still worthy to take this precaution (no harm in keeping with 8.2.1 in testing for a few days). The CVE that's currently fixed by 8.3.0 (CVE-2023-38039) is not serious so we can postpone the fix for that on testing. I usually receive curl CVE details through an embargo process, I haven't received anything yet so this is all based on public information. >From the moment I receive any details under embargo, I'll stop interacting with this in any way that might leak information. This means this migration block will stay in place up until public details are published (even if I might know, under embargo, whether the new vulnerability only affects 8.3.0 or not). Cheers, -- Samuel Henrique
Bug#1043550: llvm-toolchain-(14|15): links against libcurl3-nss which will be dropped in August 2023
Argh, I think the links got merged together, here are the proper ones: llvm-toolchain-14 https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/117 llvm-toolchain-15 https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/118 llvm-toolchain-17 https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/119 Cheers, -- Samuel Henrique
Bug#1043550: llvm-toolchain-(14|15): links against libcurl3-nss which will be dropped in August 2023
Control: tags -1 patch I've opened MRs on salsa: llvm-toolchain-14 https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/117 llvm-toolchain-15 https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/118 llvm-toolchain-17 https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/merge_requests/119 I would really appreciate it if this could be uploaded to unstable in the next couple of days, my wish is for these fixes to get to testing before ~15th September. Cheers, -- Samuel Henrique
Bug#1043550: llvm-toolchain-(14|15): links against libcurl3-nss which will be dropped in August 2023
Control: severity -1 important Hello, Unfortunately the release team denied my request to perform binNMUs, so the build-dependencies will have to be adjusted for llvm-toolchain-14 and llvm-toolchain-15. This would be just like the change done for llvm-toolchain-16 at https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/f47bc1736eb9bc0b0a9cab4130802d9db69fcdcb Could you change that and do a new upload of those packages to unblock curl's migration? binNMU bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050974 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050976 PS.: You might also want to do that change on llvm-toolchain-17, but that one does not block the migration. Cheers, -- Samuel Henrique
Bug#1051235: aircrack-ng: package file and binary reported as malware/mirai by 3 different malware scanners
Hello Hugues, > I obtain almost the same results with a subtle variant (Mirai.A -> > Mirai.qahkj) while scanning the aircrack-ng binary itself, which I > extracted directly from the .deb package: > > file: aircrack-ng/aircrack-ng_1.7-5_amd64/usr/bin/aircrack-ng > sha256: > d58a36fa6360bac0419650786e690f4691a3ba62f3710eb7db24d6d5d90e7c71 > > - bitdefender : Trojan.Linux.Generic.274536 > - avira : SPR/ANDR.Mirai.qahkj > - fsecure : PrivacyRisk.SPR/ANDR.Mirai.qahkj (6, 1, 1) Considering aircrack-ng is open source (and our aircrack-ng packaging too), this seems very unlikely, it would have been caught much earlier by other people. It's also common for scanners to trigger false-positives on security related tools. > I struggle finding evidences of a possible false alert, making me > considering this as a potentially credible issue. I would gladly help > investigate this further on, if you need so. What did you look for when investigating this as a false positive? Do you get the same finding when scanning the package's source code? https://salsa.debian.org/pkg-security-team/aircrack-ng Thank you for the report, -- Samuel Henrique
Bug#1041508: tex-common: Installation fails if system is missing the set locale
> According to https://tracker.debian.org/pkg/texlive-extra the new version > from unstable could migrate to > testing tomorrow This has happened now, every testing user is getting the following error: """ Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.isqbK6Rx Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): installed tex-common package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: tex-common needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) """ We might need to 0-day NMU this with high urgency so it fixes the upgrade breakage, users will be very confused by this. Cheers, -- Samuel Henrique
Bug#1050974: binNMU: Rebuild against curl without NSS support
Hello Sebastian anb Paul, > So let's not just rebuild those. Samuel, please file bugs against those > packages so that the maintainers fix the build dependencies. I have filled bugs already, here's the current situation: eg25-manager: https://bugs.debian.org/1043547 Has been fixed in git already, so the next upload will have the correct B-D. llvm-toolchain-14 and llvm-toolchain-15: https://bugs.debian.org/1043550 https://bugs.debian.org/1043551 I have not explicitly asked for the B-D change for llvm, and I think doing it so will be a waste of time and effort, let me explain. Both llvm-toolchain-14 and llvm-toolchain-15 will be removed from the archive soon, see their ROM bugs: https://bugs.debian.org/1050069 https://bugs.debian.org/1050070 On top of that, those two packages have already been rebuilt for riscv64 (no binNMUs required there), whereas if we force another upload only to solve this, we will trigger a build for every arch and needlessly consume at the very least 77 hours of the riscv builders' time (while we are still rebuilding the archive for riscv, delaying it all). https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-14=riscv64 https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-15=riscv64 Do you think that's a sensible compromise? I'm asking to proceed with binNMUs because eg25-manager has been fixed in git already and the llvm packages are about to be removed (although I want curl to migrate before that), also rebuilding them on riscv takes a lot of effort at a not-so-great time (no binNMUs required for riscv). Note: llvm-toolchain-16, which is going to be the new default, has already fixed the B-D and the package has been uploaded, so that's why there's no action for that one. Thank you, -- Samuel Henrique
Bug#1050974: binNMU: Rebuild against curl without NSS support
Control: tags -1 - moreinfo Hello Sebastian, I'm sending this same response to all 3 bugs related to this. > Why does that require rebuilds? These packages have a build dependency on the virtual package "libcurl4-dev", which is satisfiable by any variant of the curl binaries (openssl, gnutls, nss). Our current builds ended up linking against the nss variant, so now that we've dropped that, a rebuild is needed for the packages to pick either openssl or gnutls. Related bugs: Main one where I'm tracking all changes: libcurl4-nss-dev: NSS support will be dropped in August 2023 https://bugs.debian.org/1038907 Bugs against the packages I'm requesting the binNMUs: llvm-toolchain-14: links against libcurl3-nss which will be dropped in August 2023 https://bugs.debian.org/1043550 llvm-toolchain-15: links against libcurl3-nss which will be dropped in August 2023 https://bugs.debian.org/1043551 eg25-manager: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023 https://bugs.debian.org/1043547 Thank you, -- Samuel Henrique
Bug#1038907: libcurl4-nss-dev: NSS support will be dropped in August 2023
binNMUs scheduled, after they're done, curl 8.2.1-2 (first version without nss support) should migrate to testing. #1050974 nmu: llvm-toolchain-14_1:14.0.6-13 https://bugs.debian.org/1050974 #1050976 nmu: llvm-toolchain-15_1:15.0.7-8 https://bugs.debian.org/1050976 #1050977 nmu: eg25-manager_0.4.6-1 https://bugs.debian.org/1050977 -- Samuel Henrique
Bug#1050977: nmu: eg25-manager_0.4.6-1
Package: release.debian.org Control: affects -1 + src:eg25-manager X-Debbugs-Cc: eg25-mana...@packages.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: samuel...@debian.org Severity: normal nmu eg25-manager_0.4.6-1 . ANY . unstable . -m "Rebuild against curl without NSS support" -- Samuel Henrique
Bug#1050974: nmu: llvm-toolchain-14_1:14.0.6-13
Right, so gmail added breaklines, correct command is: nmu llvm-toolchain-14_1:14.0.6-13 . all amd64 arm64 armel armhf i386 mips64el ppc64el s390x hurd-i386 sparc64 . unstable . -m "Rebuild against curl without NSS support" Cheers, -- Samuel Henrique
Bug#1050976: nmu: llvm-toolchain-15_1:15.0.7-8
Package: release.debian.org Control: affects -1 + src:llvm-toolchain-15 X-Debbugs-Cc: llvm-toolchain...@packages.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: samuel...@debian.org Severity: normal nmu llvm-toolchain-15_1:15.0.7-8 . all amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . -m "Rebuild against curl without NSS support" -- Samuel Henrique
Bug#1050974: nmu: llvm-toolchain-14_1:14.0.6-13
Package: release.debian.org Control: affects -1 + src:llvm-toolchain-14 X-Debbugs-Cc: llvm-toolchain...@packages.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: samuel...@debian.org Severity: normal nmu llvm-toolchain-14_1:14.0.6-13 . all amd64 arm64 armel armhf i386 mips64el ppc64el s390x hurd-i386 sparc64 . unstable . -m "Rebuild against curl without NSS support" -- Samuel Henrique
Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text
> So, many users, and especially newcomers to Debian, follow the instructions > in the > first line and are then surprised when they can't use sudo from their user > from > their newly installed system. I've seen this issue happening so many times. This would be a huge UX improvement for the installation process and I really hope the change is made, thank you for filling this, Jonathan! Cheers, -- Samuel Henrique
Bug#987187: libcurl3-gnutls from debian backports breaks git http operations
> we still have the issue in deb10, i had to revert today to 7.64.0-4+deb10u6 > for > git operation to work again. > Do you think there will be a patch anytime in bpo ? :) > Could you maintainers help make a new package? Unfortunately backports and backports-sloppy are both closed for buster (10). I really wanted to fix this issue (and a lot others that are pending from backports) but that's not possible anymore for buster. Backports is not an officially supported component and so the alternatives you have now are to stick to the package from buster main (not backports) or to update to Debian 11 (consider going to 12). Thank you, -- Samuel Henrique
Bug#1043340: curl -D /foo/bar/baz segfaults instead of exiting with error
Hello, Thank you for reporting this. I could not reproduce with version 8.2.1-1 from testing, and I see that you were running testing when you reported the issue but it was before this version migrated. Can you please check if the same happens for you with an updated curl package? I sill want to give it a go at reproducing this on stable, but wanted to check with you whether the latest version fixes the issue. Thank you, -- Samuel Henrique
Bug#1043552: links against libcurl3-nss which will be dropped in August 2023
Package: llvm-toolchain-16 Tags: trixie sid User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org Control: block 1038907 by -1 Hello, Curl's upstream dropped support for NSS earlier this month: https://curl.se/dev/deprecate.html#nss I plan on removing libcurl4-nss-dev and libcurl3-nss in the next couple of weeks, but this can be delayed if we spot issues (seems like it will be straightforward for llvm though). The llvm-toolchain packages will require minimal changes to allow for libcurl3-nss to be dropped. d/control lists "libcurl4-dev" as a B-D, and it turns out that the build process is linking against libcurl3-nss in some archs. We have two options to deal with this: 1) Explicitly chose a non-nss preferred tls backend on B-D, eg.: "libcurl4-openssl-dev | libcurl-dev,". 2) BinNMUs after curl drops the nss packages. The first option is better for me as the dependency can be removed earlier and it will be less work for me, but number 2 doesn't require any actions from you (thus why this bug is being cut late). What would be your preferred option? Thank you, -- Samuel Henrique
Bug#1043551: links against libcurl3-nss which will be dropped in August 2023
Package: llvm-toolchain-15 Tags: trixie sid User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org Control: block 1038907 by -1 Hello, Curl's upstream dropped support for NSS earlier this month: https://curl.se/dev/deprecate.html#nss I plan on removing libcurl4-nss-dev and libcurl3-nss in the next couple of weeks, but this can be delayed if we spot issues (seems like it will be straightforward for llvm though). The llvm-toolchain packages will require minimal changes to allow for libcurl3-nss to be dropped. d/control lists "libcurl4-dev" as a B-D, and it turns out that the build process is linking against libcurl3-nss in some archs. We have two options to deal with this: 1) Explicitly chose a non-nss preferred tls backend on B-D, eg.: "libcurl4-openssl-dev | libcurl-dev,". 2) BinNMUs after curl drops the nss packages. The first option is better for me as the dependency can be removed earlier and it will be less work for me, but number 2 doesn't require any actions from you (thus why this bug is being cut late). What would be your preferred option? Thank you, -- Samuel Henrique
Bug#1043550: links against libcurl3-nss which will be dropped in August 2023
Package: llvm-toolchain-14 Tags: trixie sid User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org Control: block 1038907 by -1 Hello, Curl's upstream dropped support for NSS earlier this month: https://curl.se/dev/deprecate.html#nss I plan on removing libcurl4-nss-dev and libcurl3-nss in the next couple of weeks, but this can be delayed if we spot issues (seems like it will be straightforward for llvm though). The llvm-toolchain packages will require minimal changes to allow for libcurl3-nss to be dropped. d/control lists "libcurl4-dev" as a B-D, and it turns out that the build process is linking against libcurl3-nss in some archs. We have two options to deal with this: 1) Explicitly chose a non-nss preferred tls backend on B-D, eg.: "libcurl4-openssl-dev | libcurl-dev,". 2) BinNMUs after curl drops the nss packages. The first option is better for me as the dependency can be removed earlier and it will be less work for me, but number 2 doesn't require any actions from you (thus why this bug is being cut late). What would be your preferred option? Thank you, -- Samuel Henrique
Bug#1043547: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023
Package: eg25-manager Tags: trixie sid patch User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org Control: block 1038907 by -1 Hello, This package build-depends on the NSS variant of libcurl "libcurl4-nss-dev". Curl's upstream announced support for NSS is going to be dropped in August 2023: https://curl.se/dev/deprecate.html#nss Please make sure to switch your build-dependency to something else before the due date. You might try switching to "libcurl4-openssl-dev" and in the big majority of the cases this won't cause any issues. Since eg25-manager already accepts libcurl-dev as a build-dependency, I've submitted a PR changing the preferred curl variant to be openssl: https://salsa.debian.org/DebianOnMobile-team/eg25-manager/-/merge_requests/5 This bug is being opened late for eg25-manager as I didn't catch it when doing the initial search for rdeps, the change will be simple for this package due to it already accepting other backends through "libcurl-dev". This is only a matter of changing the prefered one and getting a build that links against something other than the nss variant. Thank you, -- Samuel Henrique
Bug#1043546: tracker.debian.org: tracker.d.o displaying inconsistent information
Package: tracker.debian.org X-Debbugs-Cc: samuel...@debian.org, e...@kiyuko.org, guilherme@gmail.com Severity: important >From the thread on d-devel named "tracker.d.o displaying inconsistent information": On Sat, 12 Aug 2023 at 16:19, Andrea Bolognani wrote: > > Hi, > > if you look at the tracker.d.o page for libvirt[1] you'll see that it > displays inconsistent information. > > Specifically, the "news" sections mentions the recent (2023-08-08) > upload of 9.6.0-1[2], but the "action needed" section still claims > that a new upstream version is available; the vcswatch message is > consistent with this. A security issue is also mentioned as still > open in sid, while in reality the recent upload addressed it and the > security tracker[3] correctly reports this. > > Further down, in the "testing migrations" section, the excuses > reported are for the *9.5.0-2* version, which is an earlier > (2023-07-25) upload. Looking at the current excuses[4] correctly > refer to the 9.6.0-1 version, where migration is apparently held up > because of gnutls28. > > There are more inconsistencies, but you get the point. I'm pretty > sure everything will go back to normal given enough time, but it > looks like the particular set of circumstances around the libvirt > package have fallen through the cracks of tracker.d.o's logic and it > could be interesting to investigate them while the issue is still > manifesting itself. > > Cheers! > > > [1] https://tracker.debian.org/pkg/libvirt > [2] > https://tracker.debian.org/news/1451405/accepted-libvirt-960-1-source-into-unstable/ > [3] https://security-tracker.debian.org/tracker/source-package/libvirt > [4] https://qa.debian.org/excuses.php?package=libvirt > -- > Andrea Bolognani > Resistance is futile, you will be garbage collected. Then my reply: I've noticed issues for other packages[0][1][2][3] and they might all be related. grequests has been accepted 3 days ago and its tracker page is missing data. nmap's migration counter is stuck at 0: "Too young, only 0 of 5 days old". licenseutils and dd-opentracing-cpp both have RC bugs that don't show up on tracker, they likely have already been picked by the autoremoval tool (and might have a removal date set). And noticed just now: both curl and nmap's debci results are not up-to-date on tracker. [0] https://tracker.debian.org/pkg/grequests [1] https://tracker.debian.org/pkg/nmap [2] https://tracker.debian.org/pkg/licenseutils [3] https://tracker.debian.org/pkg/dd-opentracing-cpp I believe there's something wrong with tracker's interface. Cheers, -- Samuel Henrique
Bug#1039613: nmap breaks udptunnel autopkgtest: UDPTunnel communication failed
After some investigation I found out the commit that introduces the regression[0]. I have added a comment to the GitHub issue with the details: https://github.com/nmap/nmap/issues/2685#issuecomment-1650519127 There's also an interesting finding that reproduction can only be achieved through scripts, I wasn't able to reproduce it manually on an interactive bash session. [0] https://github.com/nmap/nmap/commit/4e6c8feb153c0c9ff8a68cd841669d650319ab45 Thank you, everyone! -- Samuel Henrique
Bug#1021339: New upstream (0.8+) available
Upstream stopped providing .deb files after 0.8.3 :( James, let me know if there's anything I can do to help packaging the latest release, in case you have more than one package pending. Thanks for maintaining nvim. -- Samuel Henrique
Bug#1038913: libmsv: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023
Package: libmsv Tags: trixie sid User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org Control: block 1038907 by -1 Hello, This package build-depends on the NSS variant of libcurl "libcurl4-nss-dev". Curl's upstream announced support for NSS is going to be dropped in August 2023: https://curl.se/dev/deprecate.html#nss Please make sure to switch your build-dependency to something else before the due date. You might try switching to "libcurl4-openssl-dev" and in the big majority of the cases this won't cause any issues. Thank you, -- Samuel Henrique
Bug#1038912: libreswan: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023
Package: libreswan Tags: trixie sid User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org Control: block 1038907 by -1 Hello, This package build-depends on the NSS variant of libcurl "libcurl4-nss-dev". Curl's upstream announced support for NSS is going to be dropped in August 2023: https://curl.se/dev/deprecate.html#nss Please make sure to switch your build-dependency to something else before the due date. You might try switching to "libcurl4-openssl-dev" and in the big majority of the cases this won't cause any issues. Thank you, -- Samuel Henrique
Bug#1038911: goldencheetah: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023
Package: goldencheetah Tags: trixie sid User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org Control: block 1038907 by -1 Hello, This package build-depends on the NSS variant of libcurl "libcurl4-nss-dev". Curl's upstream announced support for NSS is going to be dropped in August 2023: https://curl.se/dev/deprecate.html#nss Please make sure to switch your build-dependency to something else before the due date. You might try switching to "libcurl4-openssl-dev" and in the big majority of the cases this won't cause any issues. Thank you, -- Samuel Henrique
Bug#1038910: licenseutils: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023
Package: licenseutils Tags: trixie sid User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org Control: block 1038907 by -1 Hello, This package build-depends on the NSS variant of libcurl "libcurl4-nss-dev". Curl's upstream announced support for NSS is going to be dropped in August 2023: https://curl.se/dev/deprecate.html#nss Please make sure to switch your build-dependency to something else before the due date. You might try switching to "libcurl4-openssl-dev" and in the big majority of the cases this won't cause any issues. Thank you, -- Samuel Henrique
Bug#1038909: dd-opentracing-cpp: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023
Package: dd-opentracing-cpp Tags: trixie sid User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org Control: block 1038907 by -1 Hello, This package build-depends on the NSS variant of libcurl "libcurl4-nss-dev". Curl's upstream announced support for NSS is going to be dropped in August 2023: https://curl.se/dev/deprecate.html#nss Please make sure to switch your build-dependency to something else before the due date. You might try switching to "libcurl4-openssl-dev" and in the big majority of the cases this won't cause any issues. Thank you, -- Samuel Henrique
Bug#1038907: libcurl4-nss-dev: NSS support will be dropped in August 2023
Package: curl Tags: trixie sid User: c...@packages.debian.org Usertags: curl-nss-deprecation X-Debbugs-Cc: samuel...@debian.org, sergi...@debian.org This is for tracking the deprecation of NSS support on curl, which will be dropped in August 2023: https://curl.se/dev/deprecate.html#nss We have to ensure there are no packages on testing blocking the migration of the curl release when that happens. -- Samuel Henrique
Bug#1037258: curl -I (HEAD request) fails with HTTP/2 against a Debian Apache instance
Hello, I'm not able to reproduce the issue on Bookworm with a HTTP2 localhost apache server. There's something specific to the way "https://git.dgit.debian.org/dgit/info/refs; is setup which triggers the issue. The next step is to find a server which can be tested against, ideally finding the configuration that triggers this so we can test locally. Once we get something to reproduce, we can do a bisect to find the commit that introduces the issue and possibly get close to a safe fix. Thank you, -- Samuel Henrique
Bug#1036809: unblock: reaver/1.6.6-0.1
Hey everyone, Considering this will be the only fix we get, leaving the release team to decide between not shipping reaver at all or shipping "1.6.6-0.1", I went ahead and sponsored the upload from Leandro. The debdiff is attached. Thank you, -- Samuel Henrique reaver_1.6.6-0.1.debdiff Description: Binary data
Bug#1036801: unblock: curl/7.88.1-10
Hello Salvatore, > After a short discussion with Paul, wouldn't that imply though that > there is an soname bump needed? Do you know has upstream considered > this and if/or why not? Is there enough assurance nobody (even outside > Debian world) is using that symbol? Those are all good questions, I should have done a better job at explaining this, so let me try doing it now. sergiodj@ did a lot of work investigating this as well, so most of the things I'll be saying here are his findings (although if I say anything wrong here, blame it on me). The "curl_jmpenv" variable declaration was guarded by a "#ifdef HAVE_SIGSETJMP", but the variable would only be used on "#ifdef USE_ALARM_TIMEOUT". For Debian, "HAVE_SIGSETJMP" is true but "USE_ALARM_TIMEOUT" is false, this is because we use the threaded resolver. This means that "curl_jmpenv" was dead code, and double checking for mentions of "curl_jmpenv" on codesearch.d.n only returns packages which bundles curl, nothing using it. Considering the variable was exposed, but not used anywhere (in our builds with threaded resolver), I don't think there was any possible way dependencies could be making use of it in any meaningful way (this is talking about things outside of our official repositories now). It doesn't make sense for upstream to bump SONAME because the variable can still be exposed depending on the build config, it's just that it wasn't supposed to be exposed for threaded resolvers first of all. The CVE that is being fixed by that change should not affect our binaries since we build with the threaded resolver, but I ended up making a decision to still apply the patch to safeguard even the sources. > These are just a couple of question trying to understand what > potential question from release team members my come for your unblock > request. Thank you for reviewing this. > p.s.: note it looks autopkgtest view for curl was still blocking it > because cwltool has a flaky test (on armel). Yeah, curl suffers quite a bit from these since tons of reverse-deps use it to fetch resources over the network and that's always flaky (not sure if it's the case with cwitool specifically, but I'm used to this sort of thing by now). Cheers, -- Samuel Henrique
Bug#1036801: unblock: curl/7.88.1-10
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package curl [ Reason ] 4 CVE fixes: * Add new patches to fix CVEs (closes: #1036239): - CVE-2023-28319: UAF in SSH sha256 fingerprint check - CVE-2023-28320: siglongjmp race condition - CVE-2023-28321: IDN wildcard match - CVE-2023-28322: more POST-after-PUT confusion * d/libcurl*.symbols: Drop curl_jmpenv, not built anymore due to CVE-2023-28320 [ Impact ] The highest CVE severity from upstream is "Moderate". [ Tests ] Curl has an extensive test suite that's run at build time and on autopkgtest, no regressions were detected. [ Risks ] The patches didn't require any changes which would be worrying. Regarding the "curl_jmpenv", there's no package on Debian using that. [ 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 [ Other info ] Please also shorten the bake time in unstable, is possible (and needed). unblock curl/7.88.1-10 -- Samuel Henrique curl_7.88.1-10.debdiff Description: Binary data
Bug#1036591: reaver: segmentation fault
> On Tue, May 23, 2023 at 10:21:35PM +0100, Samuel Henrique wrote: > > Andrey, Leandro meant to use the "patch" tag instead of "fixed", here's his > > fix: > > https://salsa.debian.org/leandrocunha/reaver > Do you think this change will be approved for bookworm, especially at this > point in the freeze? I don't see any other better alternative. I don't think it's worthy to cherry-pick a single possible fix since the package might be broken in other ways as well. The correct action here is to update to 1.6.6, which has been released years ago and is being shipped by a lot of other distros. To be clear, I haven't tried to reproduce the issue myself, but it looks general enough and easy to do so, I'll do it in the next few days, but wanted to make sure we keep moving on fixing this. Cheers, -- Samuel Henrique
Bug#1036591: reaver: segmentation fault
Control: tags -1 patch fixed-upstream Hello Bartosz, We are planning to perform an NMU, changing the package's maintership to the Security Tools team (while keeping you as an Uploader), fixing this RC bug and filling an unblock request so we can ship this package for bookworm. Please let me know if you disagree, we will have to act quickly due to the freeze. Andrey, Leandro meant to use the "patch" tag instead of "fixed", here's his fix: https://salsa.debian.org/leandrocunha/reaver Cheers, -- Samuel Henrique
Bug#1036300: Fwd: bullseye-pu: package curl/7.74.0-1.3+deb11u8
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] * Backport upstream patches to fix 5 CVEs: - CVE-2023-27533: TELNET option IAC injection - CVE-2023-27534: SFTP path ~ resolving discrepancy - CVE-2023-27535: FTP too eager connection reuse - CVE-2023-27536: GSS delegation too eager connection re-use - CVE-2023-27538: SSH connection too eager reuse still * d/p/add_Curl_timestrcmp.patch: New patch to backport Curl_timestrcmp(), required for CVE-2023-27535. [ Impact ] None of the vulnerabilities are critical, but they have already been fixed in buster and we should do the same for bullseye. [ Tests ] curl's testsuite didn't spot any regressions. The same CVEs have also been fixed in buster already. [ Risks ] Regressions on TELNET, SFTP, FTP, GSS and SSH functionalities of curl. [ 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 ] Nothing besides the CVE fixes. The patches were changed to apply cleanly on bullseye, all the changes can be seen here: https://salsa.debian.org/debian/curl/-/commit/4adf0d7c4d47610336294d39f84a8360522a5936 https://salsa.debian.org/debian/curl/-/commit/b3dedba95658cea02405af32f0652f83d87f6eac https://salsa.debian.org/debian/curl/-/commit/6909425ffa87e4c35730ecc2801ef40492239048 https://salsa.debian.org/debian/curl/-/commit/54e6a929643fe14160049ed8d1bda72dd34db9f7 https://salsa.debian.org/debian/curl/-/commit/19c382231a004b45b3096f72fb722f6df5d31902 [ Other info ] I will be working on the latest CVEs that have been published for curl but I'll push those fixes in a different upload. -- Samuel Henrique curl_7.74.0-1.3+deb11u8.debdiff Description: Binary data
Bug#1033721: unblock: curl/7.88.1-8
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sergi...@debian.org, samuel...@debian.org Severity: normal Please unblock package curl [ Reason ] Changes that affect the resulting binaries: * d/rules: Remove -D_DEB_HOST_ARCH from curl-config's CFLAGS We have accidentally introduced a small regression at 7.88.1-3 which would make the dev packages not multi-arch compatible (even though we set Multi-Arch: same). This change fixes that by removing the unneeded build flag that gets set in the curl-config file. Changes that don't affect the resulting binaries: * d/gbp.conf: Push gbp conf with sane defaults * d/salsa-ci.yml: Disable dh_auto_test with DEB_BUILD_OPTIONS * d/rules: Add new build profiles to limit builds to a single TLS backend * d/tests: Add new autopkgtests that runs curl's test suite The most important one from this list is the inclusion of autopkgtests, which run all of curl's test suite for each TLS backend that we support (openssl, gnutls and nss). [ Impact ] One multi-arch bugfix and extra reliability/stability of the package with the inclusion of autopkgtests and salsa-ci (to make stable updates easier). [ Tests ] All build tests passed. [ Risks ] No risks that I can think of. [ 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 [ Other info ] I have also attached a diffoscope diff from the amd64 binary to show the multi-arch fix's delta. I'm not in a rush to get the package in testing, but there's also no harm in removing the bake time for the migration, so I would appreciate it if that could be done (only if that's not too much work for the release team). unblock curl/7.88.1-8 -- Samuel Henrique curl_7.88.1-8.debdiff Description: Binary data --- libcurl4-openssl-dev_7.88.1-7_amd64.deb +++ libcurl4-openssl-dev_7.88.1-8_amd64.deb ├── file list │ @@ -1,3 +1,3 @@ │ --rw-r--r-- 0004 2023-03-21 22:39:05.00 debian-binary │ --rw-r--r-- 000 1672 2023-03-21 22:39:05.00 control.tar.xz │ --rw-r--r-- 000 484468 2023-03-21 22:39:05.00 data.tar.xz │ +-rw-r--r-- 0004 2023-03-26 10:36:24.00 debian-binary │ +-rw-r--r-- 000 1676 2023-03-26 10:36:24.00 control.tar.xz │ +-rw-r--r-- 000 484612 2023-03-26 10:36:24.00 data.tar.xz ├── control.tar.xz │ ├── control.tar │ │ ├── file list │ │ │ @@ -1,3 +1,3 @@ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./ │ │ │ --rw-r--r-- 0 root (0) root (0) 1467 2023-03-21 22:39:05.00 ./control │ │ │ --rw-r--r-- 0 root (0) root (0) 1524 2023-03-21 22:39:05.00 ./md5sums │ │ │ +drwxr-xr-x 0 root (0) root (0)0 2023-03-26 10:36:24.00 ./ │ │ │ +-rw-r--r-- 0 root (0) root (0) 1467 2023-03-26 10:36:24.00 ./control │ │ │ +-rw-r--r-- 0 root (0) root (0) 1524 2023-03-26 10:36:24.00 ./md5sums │ │ ├── ./control │ │ │ @@ -1,14 +1,14 @@ │ │ │ Package: libcurl4-openssl-dev │ │ │ Source: curl │ │ │ -Version: 7.88.1-7 │ │ │ +Version: 7.88.1-8 │ │ │ Architecture: amd64 │ │ │ Maintainer: Alessandro Ghedini │ │ │ Installed-Size: 1763 │ │ │ -Depends: libcurl4 (= 7.88.1-7) │ │ │ +Depends: libcurl4 (= 7.88.1-8) │ │ │ Suggests: libcurl4-doc, libidn-dev, libkrb5-dev, libldap2-dev, librtmp-dev, libssh2-1-dev, libssl-dev, pkg-config, zlib1g-dev │ │ │ Conflicts: libcurl4-gnutls-dev, libcurl4-nss-dev, libssl1.0-dev │ │ │ Provides: libcurl-dev, libcurl-ssl-dev, libcurl3-dev, libcurl3-openssl-dev, libcurl4-dev │ │ │ Section: libdevel │ │ │ Priority: optional │ │ │ Multi-Arch: same │ │ │ Homepage: https://curl.se/ │ │ ├── ./md5sums │ │ │ ├── ./md5sums │ │ │ │┄ Files differ ├── data.tar.xz │ ├── data.tar │ │ ├── file list │ │ │ @@ -1,36 +1,36 @@ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/bin/ │ │ │ --rwxr-xr-x 0 root (0) root (0) 6465 2023-03-21 22:39:05.00 ./usr/bin/curl-config │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/include/ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/include/x86_64-linux-gnu/ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/include/x86_64-linux-gnu/curl/ │ │ │ --rw-r--r-- 0 root (0) root (0) 127742 2023-03-21 22:39:05.00 ./usr/include/x86_64
Bug#1033469: unblock: curl/7.88.1-7
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sergi...@debian.org, samuel...@debian.org Severity: normal Please unblock package curl I would like to push the fix for the recent 6 CVEs disclosed: - CVE-2023-27533: TELNET option IAC injection - CVE-2023-27534: SFTP path ~ resolving discrepancy - CVE-2023-27535: FTP too eager connection reuse - CVE-2023-27536: GSS delegation too eager connection re-use - CVE-2023-27537: HSTS double-free - CVE-2023-27538: SSH connection too eager reuse still I have also prepared the fixes for stable and oldstable and will be requesting a p-u upload for them shortly (already pushed the commits to the repo). I would also appreciate it if the wait time for the migration could be cut short due to the nature of the changes (low risk and the sooner they get to testing the better). [ Reason ] CVE fixes, the security team said no DSAs will be assigned to them. [ Impact ] The highest severity of the CVEs is moderate as per upstream, the security team considered all of them low (thus no DSA). [ Tests ] Curl's test suite passed (the build succeeded on all archs). [ Risks ] Only minimal changes were required in order to backport CVE-2023-27533. There has been no bugfixes related to these CVE fixes in 8.0.1. [ 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 [ Other info ] Other small changes in the debdiff are: Bump Standards-Version to 4.6.2 d/p/06_always-disable-valgrind.patch: Remove unused patch d/patches: Refresh all patches None of these three changes modifies the resulting binaries. I am planning to push 7.88.1-8 after 7.88.1-7 migrates and I will be requesting an unblock for that revision as well, I figured it's better to not bundle the changes together to make the review easier and to let the CVE fixes get to testing sooner. The changes for -8 will be: 1) Inclusion of autopkgtests. 2) Inclusion of new build profiles to limit the builds to certain TLS backends (to be used by manual tests or autopkgtests only). 3) And possibly a fix for the multi-arch issue #913995 (the lintian error that the package has). I would also like to ask the release team to consider unblocking curl' s latest release 8.0.1 due to the delta consisting of mostly bugfixes (biggest change is removal of support for systems that don't have 64 bit data types). Being able to ship 8.0.1 will make maintenance easier on the long term (stable, oldstable...). But I want to first get these CVE fixes and the autopkgtests (coming in rev 8) in testing before asking for 8.0.1's unblock. PS.: I've made a typo in the changelog entry where I mention "5 CVEs" rather than 6, but it's fine since all of the 6 CVEs are listed anyway. unblock curl/7.88.1-7 -- Samuel Henrique curl_7.88.1-7.debdiff Description: Binary data
Bug#1033273: unblock: curl/7.88.1-6
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sergi...@debian.org, samuel...@debian.org Severity: normal Please unblock package curl We have two changes on unstable: 1) Curl's test suite now skips flaky tests and it's critical to the result of the build: This means we get a FTBFS if tests fails, considering curl has a very extensive test-suite (around 1600 tests) and that this will increase the reliability of our backporting of patches throughout stable, oldstable and oldoldstable (hello lts/elts), this is very important. 2) Add support to PEM certificates for libcurl3-nss: When working on having the improved test coverage, we noticed the possibility to fix this long-standing bug. Users of libcurl3-nss are now able to load PEM certificates (like from ca-certificates), which makes it easier to run a safer libcurl with nss. [ Reason ] Major improvements to tests and fix of a long-standing bug related to usage of NSS and PEM certificates. [ Impact ] Maintenance of curl will be much more reliable from now on as we have better test coverage with results which can't be ignored. [ Tests ] I've run at least 8 builds of the curl package in our buildd infrastructure and didn't spot any flaky tests left. Regarding the NSS + PEM change, curl's extensive unit tests passed. [ Risks ] More work and less reliability maintaining curl on trixie (for backporting patches, for example). [ 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 [ Other info ] I would like 7.88.1-6 to migrate as soon as possible (it has been more than 10 days already) because I want to push 6 CVE fixes after this upload. I will also request for the CVE fixes to be unblocked but I would like this version to migrate first so it happens sooner (trying to avoid baking this for an extra 20 days). unblock curl/7.88.1-6 Thank you, -- Samuel Henrique curl_7.88.1-6.debdiff Description: Binary data
Bug#1032539: lnav: FTBFS in testing: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Hello Daniel > > I couldn't find anything in the release notes which look like a > > breaking change[0] > > Lots of people and CI systems run all the tests flawlessly all the time, so > there is reason to suspect that there is something slightly unusual in your > test setup that causes these problems. Meaning that I suspect this is not a > curl problem, this is a curl test problem. > > Are these problems different or the same as the ones already filed at > https://github.com/curl/curl/issues/10682 ? I think it's a different issue, we have good evidence that those failures are triggered by an IPv6-only host and I acknowledge your solution to document that tests require IPv4 support for now. Salvatore can double check but the build logs indicate that the host used to build lnav had an IPv4 address. I also don't think lnav is running any of the curl's tests, but rather making use of the curl library to run their tests, which leads me to believe that whatever issue it is, it has to be something very specific and uncommon (and not related to curl's tests), otherwise there would be more reports. By the way I should have replied on that issue just in case: but feel free to close it if you'd like to track IPv6-only support somewhere else, or to rename it if you'd like to use it to track support for that. Me and sergiodj are thinking about giving it a try at solving that but we're not sure when (in the packaging, for now, we are ignoring those test results). Me and sergiodj are also currently investigating a test issue related to ppc64el, we have got some good insights already, but would like to fully understand what's going on and have a patch ready before reporting. Also that issue only affects curl's own tests so it can't be related to this. Cheers, -- Samuel Henrique
Bug#1032539: lnav: FTBFS in testing: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Hello Salvatore, > -Setting up libcurl3-gnutls:amd64 (7.87.0-2) ... > -Setting up libcurl4-gnutls-dev:amd64 (7.87.0-2) ... > +Setting up libcurl3-gnutls:amd64 (7.88.1-1) ... > +Setting up libcurl4-gnutls-dev:amd64 (7.88.1-1) ... > > In fact if I downgrade the packages to 7.87.0-2 the test suite > succeeds again, would you be able to confirm? 7.88.1-6 as well still > triggers the test failures. > > curl maintainers, is there potential for a regression betweeen 7.87.0 > and 7.88.1 or a incompatible change between the two which can explain > that? I couldn't find anything in the release notes which look like a breaking change[0], I've also looked at the release notes for the next release[1] and the problem is that there are a lot of bugfixes (as usual) but it's hard to understand if any of those are for regressions that could be affecting lnav without a better error message. If you manage to get more details about the error (ideally some error being thrown by curl or which call is returning an unexpected output), we might be able to scope this down. [0] https://curl.se/changes.html [1] https://github.com/curl/curl/blob/c4a89cb153b782bf7be7739e3ca0bafe5a9a14c3/RELEASE-NOTES Regards, -- Samuel Henrique
Bug#1029231: curl_multi_socket_action is broken in curl 7.87 (and 7.74.0-1.3+deb11u5)
> Apologies, this is a duplicate of bug 1029231 and it seems like curl > 7.88 is intended to move to testing? That's right, the fix should migrate to testing in around 3 days (and it's live on stable-security). I appreciate all the bug reports we've got, so thank you Syldra, Marc and Malte :) Cheers, -- Samuel Henrique
Bug#989689: ansible-lint: Unable to resolve tag names
Control: fixed 989689 ansible-lint/6.12.2-1 I'm not sure exactly which version fixed this issue but I know the one on testing and unstable are working. We should still try to identify what's wrong on stable. Thank you for reporting this. -- Samuel Henrique
Bug#1031327: gbp-rpm-ch: Wrong changelog header format (missing dash before version)
Hello Guido, > You need to fixup the tests too though I have updated the Github PR and also attached the new patch with the unit tests fixed. Thank you, -- Samuel Henrique From b2a7100730306d7e333ce84c00ccdaf693e6f081 Mon Sep 17 00:00:00 2001 From: Samuel Henrique Date: Mon, 1 Aug 2022 18:49:19 +0100 Subject: [PATCH] Fix RPM changelog header format (missing dash before version) As stated in the documentation at: https://rpm-packaging-guide.github.io/#working-with-spec-files "... Follow this format for the first line: * Day-of-Week Month Day Year Name Surname - Version-Release ..." --- gbp/rpm/policy.py | 2 +- tests/30_test_rpm_changelog.py | 26 +- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/gbp/rpm/policy.py b/gbp/rpm/policy.py index a2155e20..59989bb8 100644 --- a/gbp/rpm/policy.py +++ b/gbp/rpm/policy.py @@ -85,7 +85,7 @@ class Changelog(object): body_name_re = r'\[(?P.*)\]' # Changelog header format (when writing out changelog) -header_format = "* %(time)s %(name)s <%(email)s> %(revision)s" +header_format = "* %(time)s %(name)s <%(email)s> - %(revision)s" header_time_format = "%a %b %d %Y" header_rev_format = "%(version)s" diff --git a/tests/30_test_rpm_changelog.py b/tests/30_test_rpm_changelog.py index 85142a41..2a0d068d 100644 --- a/tests/30_test_rpm_changelog.py +++ b/tests/30_test_rpm_changelog.py @@ -34,7 +34,7 @@ def test_str_format(self): time = datetime(2014, 1, 29, 12, 13, 14) header = _ChangelogHeader(RpmPkgPolicy, time, name="John Doe", email="u...@host.com", revision="1") -eq_(str(header), "* Wed Jan 29 2014 John Doe 1\n") +eq_(str(header), "* Wed Jan 29 2014 John Doe - 1\n") def test_str_format_err(self): """Test missing properties""" @@ -79,7 +79,7 @@ def setup(self): def test_str_format(self): """Basic test""" section = self.default_sect -eq_(str(section), "* Wed Jan 29 2014 J. D. 1\n- my change\n\n") +eq_(str(section), "* Wed Jan 29 2014 J. D. - 1\n- my change\n\n") def test_append_entry(self): """Test add_entry() method""" @@ -87,7 +87,7 @@ def test_append_entry(self): entry = _ChangelogEntry(RpmPkgPolicy, author="", text="- another\n change") new_entry = section.append_entry(entry) -eq_(str(section), "* Wed Jan 29 2014 J. D. 1\n- my change\n" +eq_(str(section), "* Wed Jan 29 2014 J. D. - 1\n- my change\n" "- another\n change\n\n") eq_(new_entry, section.entries[-1]) @@ -96,25 +96,25 @@ def test_set_header(self): section = self.default_sect time = datetime(2014, 1, 30) section.set_header(time=time, name="Jane", email="u@h", revision="1.1") -eq_(str(section), "* Thu Jan 30 2014 Jane 1.1\n- my change\n\n") +eq_(str(section), "* Thu Jan 30 2014 Jane - 1.1\n- my change\n\n") class TestChangelogParser(object): """Test the default changelog parser""" cl_default_style = """\ -* Wed Jan 29 2014 Markus Lehtonen 0.3-1 +* Wed Jan 29 2014 Markus Lehtonen - 0.3-1 - Version bump - Drop foo.patch -* Tue Jan 28 2014 Markus Lehtonen 0.2 +* Tue Jan 28 2014 Markus Lehtonen - 0.2 - Update to 0.2 -* Mon Jan 27 2014 Markus Lehtonen 0.1 +* Mon Jan 27 2014 Markus Lehtonen - 0.1 - Initial version """ cl_with_authors = """\ -* Wed Jan 29 2014 Markus Lehtonen 0.3-1 +* Wed Jan 29 2014 Markus Lehtonen - 0.3-1 [Markus Lehtonen] - Version bump [John Doe] @@ -122,17 +122,17 @@ class TestChangelogParser(object): """ # Invalid timestamp / name cl_broken_header_1 = """\ -* Wed Jan 29 2014Markus Lehtonen 0.3-1 +* Wed Jan 29 2014Markus Lehtonen - 0.3-1 - Version bump """ # Whitespace before the asterisk in the header cl_broken_header_2 = """\ - * Wed Jan 29 2014 Markus Lehtonen 0.3-1 + * Wed Jan 29 2014 Markus Lehtonen - 0.3-1 - Version bump """ # Invalid timestamp cl_broken_header_3 = """\ -* Wed Jan 32 2014 Markus Lehtonen 0.3-1 +* Wed Jan 32 2014 Markus Lehtonen - 0.3-1 - Version bump """ # Missing email @@ -143,7 +143,7 @@ class TestChangelogParser(object): # Garbage before section header cl_broken_header_5 = """\ ---garbage--- -* Wed Jan 29 2014 Markus Lehtonen 0.3-1 +* Wed Jan 29 2014 Markus Lehtonen - 0.3-1 - Version bump """ @@ -222,5 +222,5 @@ def test_add_section(self): time = datetime(2014, 1, 30) new_section = changelog.add_section(time=time, name="Jane Doe", email="j...@doe.com", revision="1.2") -eq_(str(changelog), "* Thu Jan 30 2014 Jane Doe 1.2\n\n") +eq_(str(changelog), "* Thu Jan 30 2014 Jane Doe - 1.2\n\n") eq_(new_section, changelog.sections[0])
Bug#1026508: ca-certificates: FTBFS: TypeError: argument 'data': 'bytearray' object cannot be converted to 'PyBytes'
Hello Julien, > This is fixed in git, I need to get around to uploading an update. Are you also planning to update the certificates for bookworm? I'm asking as we are already in the freeze and there are a few bugreports about old certificates that need to be dropped[0][1] (and I assume there's also a bunch of new ones we need to get). Are you looking into help maintaining the package as well? [0] https://bugs.debian.org/1021749 [1] https://bugs.debian.org/1023945 Thank you, -- Samuel Henrique
Bug#1031594: os-prober is disabled by default in /etc/default/grub - Windows not found
There have been a few bug reports about this in the past but I don't remember seeing a reply. Here's mine: https://bugs.debian.org/1012865 It would be really unfortunate to release bookwork in this state, we are going one step forward with non-free-firmware and two steps backwards with this change, it underestimates how many users are dual booting Debian and I foresee lots of people not bothering with it (they'll just use something else, especially new users).
Bug#1031327: gbp-rpm-ch: Wrong changelog header format (missing dash before version)
Package: git-buildpackage X-Debbugs-Cc: samuel...@debian.org Version: 0.9.30 Severity: normal Tags: patch As stated in the title, the changelog header has the wrong format. Specfile documentation: https://rpm-packaging-guide.github.io/#working-with-spec-files ... Follow this format for the first line: * Day-of-Week Month Day Year Name Surname - Version-Release ... I have provided a patch on Github at https://github.com/agx/git-buildpackage/pull/89 The patch is also attached to this bug report. Thank you, -- Samuel Henrique From 310db2177f3a43e1584682f21c43ac0de6c495e6 Mon Sep 17 00:00:00 2001 From: Samuel Henrique Date: Mon, 1 Aug 2022 18:49:19 +0100 Subject: [PATCH] Fix RPM changelog header format (missing dash before version) As stated in the documentation at: https://rpm-packaging-guide.github.io/#working-with-spec-files "... Follow this format for the first line: * Day-of-Week Month Day Year Name Surname - Version-Release ..." --- gbp/rpm/policy.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gbp/rpm/policy.py b/gbp/rpm/policy.py index a2155e20..59989bb8 100644 --- a/gbp/rpm/policy.py +++ b/gbp/rpm/policy.py @@ -85,7 +85,7 @@ class Changelog(object): body_name_re = r'\[(?P.*)\]' # Changelog header format (when writing out changelog) -header_format = "* %(time)s %(name)s <%(email)s> %(revision)s" +header_format = "* %(time)s %(name)s <%(email)s> - %(revision)s" header_time_format = "%a %b %d %Y" header_rev_format = "%(version)s"
Bug#1031184: adapta-kde: Development has completely and officially ended
Package: adapta-kde Version: 20180828-2 Severity: serious Tags: upstream X-Debbugs-Cc: samuel...@debian.org This bug report is based on a similar one opened against adapta-gtk-theme: https://bugs.debian.org/1010199 Dear maintainer, development has completely ended in 2018 and the official repository has been archived in 2020. This project was heavily based on adapta-gtk-theme, which had its development stopped at around the same time. I'm setting the severity to "serious" with the intention of keeping this outside of the next stable and then removing it from unstable after it's gone from testing. Regards, -- Samuel Henrique
Bug#1010199: adapta-gtk-theme: Development has completely and officially ended
Control: severity -1 serious Bumping the severity of this bug to block it from going into the next stable release. We should remove it from unstable as well once it's removed from testing. I'm opening a similar bug request for adapta-kde. Regards, -- Samuel Henrique
Bug#1024696: Intent to NMU powerline to fix longstanding l10n bugs
Hello Helge, > Could we make it more simple and straightforward? > > You add me (kreutzm-guest) temporarily to your team and I directly > commit the proposed update to your git repository. Then you review it > and perform the upload? In case you have anything else, you could > easily add it then. Sounds good, I have given you permission to push to the salsa repo. Thanks, -- Samuel Henrique
Bug#1024696: Intent to NMU powerline to fix longstanding l10n bugs
Hello Helge, > Please tell me if you are currently preparing a new release yourself > and would like me to skip the NMU. Since the package is team maintained (under the Python team), I would prefer it if you did a team upload rather than an NMU. Honestly I wouldn't complain if you went with an NMU, but a Team Upload looks better to me, we can also make sure the changes are pushed from Salsa rather than doing a gbp import on the dsc after the NMU is uploaded. If you'd like, you can create an MR on salsa with the changes as a Team Upload and I can merge and sponsor your upload. What do you think? Thanks for looking into this,
Bug#1021812: powerline: Missing vim bindings
Hello Rob, I think the decision not to ship vim bindings happened before I was the maintainer of the package, but your suspicion is correct regarding Debian's vim not being built with python support. I don't think the bindings would work. What I use on my machines is vim-airline, which you can install using apt or pretty much any vim plugin manager. https://tracker.debian.org/pkg/vim-airline https://github.com/vim-airline/vim-airline I don't think it can be enabled by default since vim-airline doesn't enable itself automatically. We could add vim-airline to powerline's Suggests, and mention somewhere that the bindings for vim are in that package (not sure where yet), but it's worth noting that they are two separate projects with their own codebase each (although they look pretty much the same). Thank you for reporting this, -- Samuel Henrique
Bug#1028988: DDPO: Show open security issues (CVEs)
Package: qa.debian.org X-Debbugs-Cc: fds, samuel...@debian.org Severity: wishlist The DDPO page could show open security vulnerabilities tracked on security-tracker.debian.org, just like we see it in tracker.d.o. Example for curl: https://security-tracker.debian.org/tracker/source-package/curl It would be really nice if there was a column for open security issues under DDPO. I'm sure this would result in maintainers being more proactive in fixing security issues on stable, as it's too easy to miss them right now. Thank you, -- Samuel Henrique
Bug#1027118: zabbix: FTBFS: error: invalid use of void expression
This should be fixed by curl 7.87.0-2, which I uploaded just now. curl BTS bug for reference: https://bugs.debian.org/1027564 Thanks, -- Samuel Henrique
Bug#1021266: SOLVED - Re: curl CVE patches applied at curl 7.74.0-1.3+deb11u2 breaks janus package working with RTSP sources
Hello Raimon, > This bug could be closed as reported issue is solved in curl > (7.87.0-1~bpo11+1) I'm happy to hear that the backport package of curl fixes your issue, this is exactly the kind of thing I try to achieve by pushing the newer releases to the backports repo :) Although I'm still worried that there's a real regression in the stable repo with 7.74.0-1.3+deb11u2, which could impact users who do not make use of backports. Unfortunately 7.74.0-1.3+deb11u2 has a lot of patches. It will be hard to track the regression, but I'll review it and check if I can spot any issues. We don't really use this bugtracker for packages in the backports repository, so I'm not sure I can/should tag the bug as closed for "7.87.0-1~bpo11+1", but at least we have this workaround documented here for others. Thanks for helping! -- Samuel Henrique
Bug#955208: rustup on Debian
These two bugs are related, I don't know if the owners want them merged so I'm sending this to at least link them together for the readers. https://bugs.debian.org/955208 https://bugs.debian.org/1026333 Cheers, -- Samuel Henrique
Bug#1026778: ITP: check-jsonschema -- A CLI for jsonschema validation
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Samuel Henrique X-Debbugs-Cc: samuel...@debian.org Severity: wishlist * Package name: check-jsonschema Version : 0.19.2 Upstream Contact: Stephen Rosen * URL : https://github.com/python-jsonschema/check-jsonschema * License : Apache-2.0 Programming Lang: Python Description : A CLI for jsonschema validation A JSON Schema CLI built on python-jsonschema. The schema may be specified as a local or remote (HTTP or HTTPS) file. Remote files are automatically downloaded and cached if possible. I will maintain this file under the Python team. Thank you, -- Samuel Henrique
Bug#1026292: python-jsonschema: Please provide a newer upstream release (>= 4.10.0)
Package: python-jsonschema Version: 4.9.1-3 Severity: wishlist Hello maintainer, It seems like upstream is moving quite quickly with the releasing of new versions of jsonschema (4.17.3 at the time of this writing). The new releases of ansible-lint (> 6.7.0) now depend on python3-jsonschema >= 4.10.0, so I'm opening this bug to track the request to update python-jsonschema. The latest release of ansible-lint as of now is 6.10.0, and it requires jsonschema >= 4.10.0, For reference, previous bug report asking for an update: https://bugs.debian.org/1017629 Thank you! -- Samuel Henrique -- Samuel Henrique
Bug#1025650: ftp.debian.org: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?
Package: ftp.debian.org X-Debbugs-Cc: samuel...@debian.org Severity: serious Justification: Policy 2.1 Hello ftp-master team, I'm opening this bug to request an official position of the team on whether the NPSL license meets the DFSG requirements or not. There's some divergence of opinions on the matter and I think the only next step is to get an evaluation from the ftp-master team. FWIW I'm currently on the opinion that the license should be considered free due to its similarity with GPL2 (and copyleft licenses in general) but Hilko (the other maintainer) is on the side of considering it non-free due to a contamination issue. Sorry if I'm oversimplifying here, Hilko. Both mine and Hilko's points are better written in the references below. Related discussions: Thread on d-legal: https://lists.debian.org/debian-legal/2022/09/msg0.html Upstream discussion: https://github.com/nmap/nmap/issues/2199 Please consider that upstream is usually quite responsive in that Github issue and so we can make follow-up questions. We need to make a decision to understand if the current nmap we are shipping (in all our supported releases[0]) is DFSG-free or not. This decision should be done ideally before the freeze so we can take any required actions. Thank you, [0] At least one issue that I've seen raised is present in all versions of nmap we ship (since the first iteration of NPSL), which would mean even our package in oldstable and stable is non-free. -- Samuel Henrique
Bug#1017629: python-jsonschema: Please provide a newer upstream release (>= 4.9.0)
Hello Thomas, Sending another ping just in case you dropped this (but still, no rush in doing so, feel free to take your time). On Fri, 14 Oct 2022 at 19:09, Samuel Henrique wrote: > > Hello Thomas, I hope you're well, > > Not meaning to rush you, just a heads up in case it was missed (since > it's automated): > > 4.7.2-3 migrated to testing, we should be good to get 4.9.1 on sid. > The experimental excuses page is not showing any regressions, which > means it will probably migrate to testing smoothly: > https://qa.debian.org/excuses.php?experimental=1=python-jsonschema > > Thank you for your work :) -- Samuel Henrique
Bug#1021266: curl CVE patches applied at curl 7.74.0-1.3+deb11u2 breaks janus package working with RTSP sources
Hello Markus, Would you have some time to investigate this issue, please? Thank you, (and thank you Raimon for reporting this) -- Samuel Henrique
Bug#1017629: python-jsonschema: Please provide a newer upstream release (>= 4.9.0)
Hello Thomas, I hope you're well, Not meaning to rush you, just a heads up in case it was missed (since it's automated): 4.7.2-3 migrated to testing, we should be good to get 4.9.1 on sid. The experimental excuses page is not showing any regressions, which means it will probably migrate to testing smoothly: https://qa.debian.org/excuses.php?experimental=1=python-jsonschema Thank you for your work :) -- Samuel Henrique
Bug#1017629: python-jsonschema: Please provide a newer upstream release (>= 4.9.0)
Hello Thomas, > FYI, 4.7.2 is uploaded to Experimental, and will go to Unstable when > OpenStack Zed will be release on the 5th of October. Awesome, thanks for your work. > I would prefer to keep that version if it's not annoying others. > Please let me know. ansible-lint requires jsonschema >=4.9.0 for any release >= 6.4.0 (the latest one being 6.6.1 at this time). Upstream's changelog between 4.7.2 and 4.9.1 seems to only contain bugfixes, although they could surely still trigger issues with jsonschema's deps, but maybe that would be doable?! I would like to try going with 4.9.1 on experimental at least (now that 4.7.2 is on unstable) so we can have an idea of possible breakages. Then we can discuss possibly having 4.9.1 for bookworm if you think that's ok, and I won't push if you still want to stick to 4.7.2. The bump from 3.2 has been quite helpful already and I understand we're dealing with compromises where ideally we would probably want to have more than one version available in the repos. Cheers, -- Samuel Henrique
Bug#1017993: reverse dependencies
Hello Paul, On Wed, 21 Sept 2022 at 19:58, Paul Gevers wrote: > On 21-09-2022 20:50, Samuel Henrique wrote: > > Please let me know if there is anything besides aircrack-ng blocked by > > this, as it increases the priority of fixing this. > > Well, I pinged you because I noticed the bug wasn't forwarded to you. I > looked because aircrack-ng showed up in my out-of-sync script, that I > use to file RC bugs for packages being out-of-sync between unstable and > testing. The reason why I didn't file the bug is because you already > took action to file the RM bug. An RC bug will cause autoremoval in due > time. Got it, I don't wanna cause you more work, but feel free to go ahead with the RC bug, that can serve as a deadline for me to solve the issue. > > [0] Since most of the reverse deps will also have to be removed, I > > think the only one which stays is forensics-all. > > For architecture specific problems we have porters. Have you considered > contacting them? I haven't considered that, no, I'll reach out to them, thanks for the suggestion. Regards, -- Samuel Henrique
Bug#1017993: reverse dependencies
Hey Paul, On Thu, 15 Sept 2022 at 08:43, Paul Gevers wrote: > > there are reverse dependencies that needs to be taken care of: > > > > > > Checking reverse dependencies... > > # Broken Depends: > > bully: bully > > forensics-all: forensics-all > > mdk3: mdk3 > > mdk4: mdk4 > > wifite: wifite > > > > # Broken Build-Depends: > > wifite: aircrack-ng > > > > > > In case they matter, this needs to be addressed first. Please remove the > > moreinfo tag once that is done. > > You may have missed the question from Thorsten as I don't see you in the > TO or CC. Can you have a look? aircrack-ng is out-of-sync between > unstable and testing due to this. Thanks for the ping, I did see Thorsten's replies but I'm still considering what to do, since removing aircrack-ng from s390x is gonna take much more effort than what I was willing to spend on the issue[0], at this stage it might be better to let it stay in s390x with some of the features working, but I would have to address the test failures still. Please let me know if there is anything besides aircrack-ng blocked by this, as it increases the priority of fixing this. Thank you, [0] Since most of the reverse deps will also have to be removed, I think the only one which stays is forensics-all. -- Samuel Henrique
Bug#1017354: coreutils: New upstream releases
CC'ing Michael, Hello Michael, somebody was asking on IRC about coreutils and I noticed that you're still active, so this might just be a miss or you might be looking for help maintaining coreutils. Would you be willing to take people as co-maintainers, or people to work in the newer upstsream releases? Thank you, -- Samuel Henrique
Bug#1018296: ERROR: rejecting unrequested file-list name
Hello, I have uploaded rsync 3.2.6-2 to experimental a few minutes ago, it contains an upstream patch which should fix this as noted on https://github.com/WayneD/rsync/issues/356 Can you try it out and let upstream know if this addressed the issue, please? Thank you. -- Samuel Henrique
Bug#1014867: wolfssl: Update to latest upstream version
I have pinged the maintainer on IRC asking if he's still interested in maintaining WolfSSL (as I've seen a recent email on pkg-haskell-maintainers suggesting he might not be available for it). The newest upstream release 5.5.0 (Aug 30, 2022) adds support to HTTP3: "QUIC support added, for using wolfSSL with QUIC implementations like ngtcp2" https://github.com/wolfSSL/wolfssl/blob/aa036b6ea402e9159d2a9b12c7f05701d44a4f09/ChangeLog.md#new-feature-additions ngtcp2 is packaged on Debian so that opens up the opportunity of having HTTP3 through WolfSSL. Regards, -- Samuel Henrique
Bug#1016188: UDD/lintian: cannot filter only by lintian tag
Not exactly the same thing but too similar for me to create a new bug (although I can do it if you prefer): It would also be useful for me to check which packages have overridden a certain lintian tag, so I can try and spot overrides that should not be there. It's a good metric to figure out lintian findings that people generally override by mistake and also findings that are too prone to false-positives. An example of something that happened a few times with me: A random build gets flagged by lintian with a finding that looks suspicious to me, then I check what are the other packages affected and that can give me an indication that the finding itself is broken or that the issue only affects certain types of packages. In case the finding seems to be broken, I confirm by looking for opened bugs against lintian (and can report it if there's none). Thank you. -- Samuel Henrique
Bug#1017629: python-jsonschema: Please provide a newer upstream release (>= 4.9.0)
Hello Thomas, > There are autopkgtest for most of the reverese depends of jsonschemat. Feel > free to NMU it to experimental, so we can use the pseudo-excuse patch to see > if the transition goes well... Awesome, I started working on a "new" release (upstream made 3 more releases in the meanwhile) and I'm pushing my work to my fork on salsa: https://salsa.debian.org/samueloph/python-jsonschema/-/tree/debian/samueloph/new-release In case anyone looks at it, beware that the branch might be in an ugly state (test commits and stuff) as I'm using that as a backup for my work while I change between laptop and desktop. Also if anyone gets ahead of me, feel free to use what I did and upload it first. The package is building fine, but I still need to write proper commit messages and patch descriptions (besides checking if I broke any doc with the sphinx changes). Thomas, when I'm ready to upload to experimental, how should I proceed with merging the changes? I can always keep them in my fork for you to pick and push, if that's easier. I say this because publishing an MR against debian/yoga doesn't seem like it's enough as the upstream releases are kept in the repo by their tags (not branches). Or maybe you want to keep this outside of the git repo until it reaches experimental? Either way is fine for me. Thank you! -- Samuel Henrique
Bug#1017993: RM: aircrack-ng [s390x] -- ANAIS; s390x not supported by upstream
Package: ftp.debian.org Severity: normal There is an FTBFS for s390x, reported upstream: https://github.com/aircrack-ng/aircrack-ng/issues/2324 But it's unclear whether or not upstream supports it or if the package even works properly. I'm not aware of any use case for aircrack-ng on s390x. The new release (1.7) is blocked on this removal so it can migrate to testing. Thank you, -- Samuel Henrique
Bug#1017629: python-jsonschema: Please provide a newer upstream release (>= 4.9.0)
Package: python-jsonschema Version: 4.6.0-3 Severity: wishlist Hello maintainer, It seems like upstream is moving quite quickly with the releasing of new versions of jsonschema (4.12.1 at the time of this writing), although the new ones seem like less of a bump compared to 3.2.0 -> 4.6.0. The new releases of ansible-lint (>= 6.4.0) now depend on python3-jsonschema >= 4.9.0, so I'm opening this bug to track the request to update python-jsonschema. Thank you! -- Samuel Henrique
Bug#1016543: rsync: CVE-2022-29154
Hello Salvatore, thanks for reporting this. I've been following the discussions around this during the day and I did notice there were multiple commits related to it indeed. My take so far is that we should wait a bit before releasing the fix on unstable, as there might be regressions in the fix itself. There isn't even a proper release with the fix yet (only v3.2.5pre1). After confirming that there's no regressions in 3.2.5, then we can consider backporting it [0]. [0] That is, of course, just a suggestion, if someone from the Security team is willing to do all the investigative work to look out for regressions earlier, they're free to go ahead. Thanks, -- Samuel Henrique
Bug#1012145: bettercap: It looks like the advertised Bluetooth LE function missing
Hello Tino, Thanks for reporting this. I happen to know that the gps functionality had to be disabled due to a licensing issue (which has been solved now): https://github.com/bettercap/bettercap/issues/938 But I don't remember what was the issue with the Bluetooth feature, so I'd like to do some investigation (either myself or someone else) before removing that from the description, since it might be possible to enable it. If we end up too close to the new stable release without this, then we shall remove it from the description. So just to be clear, the gps functionality should appear at some point in the near future, since the licensing issue has been addressed, and the bluetooth one is TODO to figure out why it's disabled. Thanks, -- Samuel Henrique
Bug#990353: readline-common: make autocompletion case insensitive and display suggestions by default
Hello Matthias, > As discussed at DebConf, I'll add these as comments in the inputrc file. I > think that the behavior for the completion on first tab is worse, if you have > too many completions and your complete window is scrolled up. I think this is not correct, we were testing this together and we noticed that whenever there's too many suggestions to show, the user needs to confirm that it really wants to get it, for example: $ cd /proc/ Display all 363 possibilities? (y or n) The user needs to type "y" to get all the suggestions. > Same about the case sensitive option. I'm wondering if this setting could be > automated depending on the locale (e.g. if the locale is case insensitive, > LC_COLLATE?) For case sensitivity the same applies, the user needs to confirm to see all of the suggestions if there are too many. > Are these options really meant to be in the emacs-mode section? No, that was me not paying enough attention on where to put the new settings. I appreciate the consideration, and I would like to have these options enabled by default, as new users are not aware of the existence of them and experienced users will know how to disable it, if they wish. But I also think there's still a benefit for our users if you only want to add these commented out (disabled). If you decide to not make it the default, would you mind leaving this bug open so at least I can keep track of this request and possibly point other people to it if they're interested in following it? Thanks for considering! -- Samuel Henrique
Bug#1008007: O: ieee-data -- OUI and IAB listings
Hello all, Thanks for cc'ing me Bastian, I didn't see this bug was open. > On Tue, 21 Jun 2022 14:51:16 + Ileana Dumitrescu > wrote: > > I intend to adopt the orphaned package ieee-data: Provide the > > Organizationally Unique Identifier (OUI) and Individual Address Block (IAB) > > listings of identifiers assigned by IEEE Standards Association. > > > > Ileana Dumitrescu > > Luciano has orphaned the ieee-data and Ilena has voiced her intend to adopt > the package. > As you are listed as Uploader I would like to have your opinion if you are > okay with that or > if you would like to maintain the package. I will possibly sponsor Ilena's > upload when I have > not received your feedback in a week or so. I have pushed a commit making myself the new maintainer, as I was already taking care of the package for a while now. I'm gonna resolve this bug as the package is not really orphan. Nonetheless, I'm always open to co-maintain packages with other people. Do you have changes pending to be merged in salsa, Ileana? I've got that understanding from Bastian's email but there's no open MR or patches in BTS. Thanks, -- Samuel Henrique
Bug#1011909: shellcheck: FTBFS: dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
The build is now failing with another error, but both FTBFS are not caused by shellcheck, and can't be fixed by it. There's something weird going on with haskell packages, I believe the error will eventually be solved in the next few weeks, let's see... Regards, -- Samuel Henrique
Bug#1012865: grub2: Re-enable discovery of other OSes by default (GRUB_DISABLE_OS_PROBER=false)
Source: grub2 X-Debbugs-Cc: samuel...@debian.org Version: 2.06-1 Severity: normal Hello, Grub's upstream has changed its default behavior regarding discovery of other OSes by disabling the feature (os-prober). This has come to my attention when updating grub2 on testing today: https://salsa.debian.org/grub-team/grub/-/blob/f844128767f947e18f86ba8a32d745f9d7a60b57/debian/NEWS#L1-L5 When briefly discussing this over IRC at debian-devel, I was pointed at another brief discussion, which has a nice summary of the reasonings behind it: https://lists.ubuntu.com/archives/ubuntu-devel/2021-December/041769.html This is my request for us to not follow upstream's default, and stick to discovering other OSes in the system, as it was the previous behavior. I'm worried that not doing so will lead to a lot of frustration for our users, as this basically means shipping Debian without dual boot support out of the box. The users would need to 1st: know about this issue and 2nd: perform a configuration change and grub update. I understand we have the NEWS file in place to warn users upgrading their systems, and also that grub will print a warning about it, but I don't think this is good enough as it will catch a lot of users by surprise. I also don't think there's a worthy trade-off being made here (security vs user experience), the Ubuntu mailing list does discuss better alternatives which would require some more work, but with only 2 options in the table (OS discovery enabled or disabled), I prefer enabled. Regards, -- Samuel Henrique
Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0
Hello Thomas, > Since I added so many autopkgtest, what I can do is upload the latest > version to Experimental, and let the Debian CI run its tests against > what's currently in Unstable. Then the pseudo excuse page will show how > it goes. > > Maybe you can also deal with the latest version of python-jsonschema in > Experimental for a short time too? That would certainly be helpful, the diff on ansible-lint is slowly growing so it would be good to at least have it in experimental. > Note I wrote to the OpenStack list and ask if we can upgrade jsonschema. > Please allow a few days until I get some replies. Awesome, thank you! -- Samuel Henrique
Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0
Hello all, The recent releases of ansible-lint (>= 6.1.0) requires python-jsonschema >= 4.5.1, mainly due to the following bugfix (thought there might be other changes required from that release): https://github.com/python-jsonschema/jsonschema/pull/940 Thomas, are you aware of anything specific which will break openstack or is it because it hasn't been tested yet? Thank you, -- Samuel Henrique
Bug#982653: ansible-lint: Switch dependency from ansible to ansible-base?
> Even after the blocking bug gets addressed I want to consider the > implications of defaulting to ansible-core, it might be better to > stick with ansible to cover for the majority of our users while > allowing them to install ansible-core instead if they want (current > behavior). I'm gonna switch the dependency to ansible-core in the next upload, which is currently pending on python-ansible-compat going through NEW. -- Samuel Henrique
