Bug#1069285: trixie-pu: package flatpak/1.14.6-1~deb13u1
Control: tags -1 confirmed On 19/04/2024 12:49, Simon McVittie wrote: Package: release.debian.org Severity: normal Tags: trixie User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: flat...@packages.debian.org Control: affects -1 + src:flatpak [ Reason ] Fix CVE-2024-32462, a sandbox escape vulnerability, without having to wait for the whole 64-bit time_t transition. [ Impact ] If not fixed, malicious or compromised Flatpak apps can execute arbitrary code on the host system. (Severity: grave) The new upstream release also fixes one high-visibility non-security bug: after some infrastructure changes on Flathub, the flatpak(1) CLI currently mis-displays apps' developer names as though they were the name of the app, for example showing org.chromium.Chromium as "The Chromium Authors" instead of the correct "Chromium Web Browser". The proposed version corrects this. (Severity: important) [ Tests ] Flatpak has a rather large test suite, which still passes. Unfortunately, most tests have to be skipped when running under schroot or lxc because those frameworks don't allow creating a nested user namespace, but I do run the autopkgtest suite under autopkgtest-virt-qemu before uploading. There is new automated test coverage for CVE-2024-32462 and for the mis-display of app names. I'll do a smoke-test on a trixie GNOME VM (install an app, run an app, and verify that CVE-2024-32462 is fixed) before uploading. Please go ahead once you're ready, and let us know so that we can hint it into testing. Cheers, Emilio
Bug#1060407: gtkwave update for {bookworm,bullseye,buster}-security
On 29/03/2024 00:06, Adrian Bunk wrote:
Hi,
attached are proposed debdiffs for updating gtkwave to 3.3.118 in
{bookworm,bullseye,buster}-security for review for a DSA
(and as preview for buster).
General notes:
As suggested by the security team in #1060407, this is a backport of a
new upstream version to fix the 82 CVEs.
I checked a handful CVEs, and they were also present in buster.
If anyone insists that I check for every single CVE whether it is also
in buster I can do that, but that would be a lot of work.
As already mentioned in #1060407, the ghwdump tool (and manpage) was
dropped in 3.3.110 from the upstream sources, and is now in ghdl-tools.
For bullseye and buster it is therefore readded.
As mentioned in #1060407 there are different tarballs for GTK 2 and GTK 3.
Looking closer I realized that this is actually one tarball that
supports GTK 1+2, and one tarball that supports GTK 2+3.
I did stay at the GTK 1+2 tarball that was already used before
for bullseye and buster since there was anyway a different upstream
tarball required for the +really version that is required to avoid
creating file conflicts with ghwdump when upgrading to bookworm.
What does the security team consider the best versioning for bullseye?
In #1060407 I suggested 3.3.104+really3.3.118-0.1, but now I ended up
preferring 3.3.104+really3.3.118-0+deb11u1
I saw this earlier but I couldn't think of a better versioning scheme, though
this looked awkward. Now I have thought of a (possibly) better one, so I'm
stating it here in case we find ourselves in a similar situation in the future
and someone remembers this thread.
I would have gone with
3.3.118-0.1~deb12u1
3.3.118+gtk2-0+deb11u1
3.3.118+gtk2-0+deb10u1
Similar to how we do +dfsg or +repack. The +really is usually used for going
back without adding an epoch, but here we're going forward, so perhaps such a
naming would have made more sense. It also makes it clearer why there's a
different tarball.
Cheers,
Emilio
Bug#1065540: libxdmcp6: Please rebuild to avoid overly huge ELF segment alignment
Hi Mathias, On 06/03/2024 13:06, Mathias Krause wrote: Package: libxdmcp6 Version: 1:1.1.2-3 Severity: normal X-Debbugs-Cc: mini...@grsecurity.net Dear Maintainer, After investigating ELF binaries and libraries on Debian systems, I noticed that libxdmcp6 uses an overly huge alignemnt for its segments. This will lead to an unnecessary ASLR degradation for (transitive) users of this library like xserver-xorg-core, lightdm, cinnamon-session, cinnamon-settings-daemon, pipewire-bin and many others. Below is the relevant output: minipli@bell:~/src/paxtest (master)$ ./contrib/check_align.sh /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 (max align=0x20) minipli@bell:~/src/paxtest (master)$ readelf -Wl /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 | grep -B2 LOAD Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x 0x 0x0046c4 0x0046c4 R E 0x20 LOAD 0x004de0 0x00204de0 0x00204de0 0x000308 0x000310 RW 0x20 The cause for the excessive segment alignment of 2MB instead of the usual 4kB is binutils' ld which did, from versions v2.11 up to v2.30 (in Debian, at least), use a huge default, even if no segment required such a huge alignment. That was fixed in Debian with the release of buster, which makes use of binutils v2.31+. The full technical background behind overly huge alignment was reported here: https://grsecurity.net/toolchain_necromancy_past_mistakes_haunting_aslr Rebuilding the package will implicitly make use of a recent version of ld and thereby fix the issue which is what I'm herby requesting. I don't know if there are many more bugs like this (I only noticed three), if there are, this should have been discussed in debian-devel@, see [1]. The solution to this is to request rebuilds to the Release team. Could you email debian-release@ with a summary of the problem and a list of packages (and possibly architectures) that need to be rebuilt? Cheers, Emilio [1] https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#reporting-lots-of-bugs-at-once-mass-bug-filing
Bug#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el
Hi Simon, On 08/02/2024 21:59, Simon McVittie wrote: On Thu, 08 Feb 2024 at 10:37:33 +, Simon McVittie wrote: Package: libmozjs-115-dev Justification: makes gjs FTBFS (#1063433) I believe mozjs115_115.7.0-3 should fix this. wb-team: Please could someone with wanna-build access schedule gjs on mips64el to be built after the fixed version of mozjs115 becomes available? I believe the correct spelling is: dw gjs_1.78.3-1 . unstable . mips64el . -m 'libmozjs-115-dev (>= 115.7.0-3)' mozjs115 is already built, so I just gave gjs back. Cheers, Emilio
Bug#1053702: NIST data feed to be retired in December 2023
Control: forwarded -1 https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/155 On 02/11/2023 07:01, Salvatore Bonaccorso wrote: Control: tags -1 + confirmed Hi, On Mon, Oct 09, 2023 at 11:48:59AM +0200, Bastian Blank wrote: Package: security-tracker Severity: important The security tracker currently uses the JSON feeds as linked from https://nvd.nist.gov/vuln/data-feeds. Those data feeds will be retired on December, 15th 2023, so in a bit more then two months. After that the information will be only available via the API. See also the announcement: https://nvd.nist.gov/General/News/change-timeline Thanks. TTBOMK, but will have to check, we only nowdays use the NVD feed for the descriptions. If that's the case we will switch to the MITRE provided feeds as we use for the rest already. Done in the above MR. Cheers, Emilio
Bug#1057540: transition: ace
Control: tags -1 confirmed On 05/12/2023 22:45, Sudip Mukherjee wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: sudipm.mukher...@gmail.com Control: affects -1 + src:ace Hi, Small transition with only two affected packages: diagnostics, ivtools, Both of them builds fine with ace 7.1.2+dfsg-1 in experimental. The autogenerated ben tracker looks good. Please consider 'ace' for transition. Thanks in advance. Go ahead. Cheers, Emilio
Bug#1057376: symbols marked as hidden causes FTBFS in pixmap
Control: forwarded -1 https://gitlab.freedesktop.org/xorg/lib/libxpm/-/issues/5 On 04/12/2023 09:05, Paul Slootman wrote: Source: libxpm Version: 1:3.5.17-1 Severity: important Tags: patch commit 7f60f3428aa21d5d643eb75bfd9417cfabf48970 on libxpm hides a number of symbols. However a couple of these symbols are used in pixmap, causing a FTBFS on pixmap. These symbols are xpmReadRgbNames and xpmGetRgbName, xpmFreeRgbNames is related. I have confirmed that applying this patch lets pixmap compile successfully. Those symbols were not exposed in any header, so pixmap using those was rather hackish. See the upstream ticket. Cheers, Emilio
Bug#1056574: transition: ppp
On 23/11/2023 11:54, Chris Boot wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: p...@packages.debian.org Control: affects -1 + src:ppp Hello Release Team friends, I uploaded ppp-2.5.0-1+1 to experimental back in September, and I think it's time to unleash it on unstable, ideally in the next few days. This is an ABI break both due to the new upstream version but there are also significant changes in this release that may break dependent packages. Any way to reduce possible breakage, or to detect and fix it before the transition starts? Like rebuilding rdeps, or checking rdep autopkgtests? The upload I'm planning, 2.5.0-1+2, only has a minor fix for loong64 and a changelog fix. As usual this isn't a traditional library package upload so the Ben file looks a bit foreign. See #890204 for a previous time we did this. I have added a tracker, should appear in an hour or two. Cheers, Emilio
Bug#972761: Please disable telemetry data submission by default
Hi Michael, Boud, On Fri, 23 Oct 2020 11:02:35 +0200 Michael Biebl wrote: Package: thunderbird Version: 1:78.4.0-1 Severity: important Hi, with TB 78, the default configuration of Thunderbird enables telemetry data submission and one has to explicitly opt out of that. See attached screenshot. Please change the default to off and let users opt in instead. I just checked this and tested it on TB 115 and it is completely disabled, without a way to enable it (which I don't see as a problem). It's config key toolkit.temetry.enabled in the config editor. Can you see if that's also the case for you? I think upstream will only enable it for nightlies and maybe alpha/beta releases now, which I think is acceptable for us. Cheers, Emilio
Bug#1055955: transition: perl 5.38
On 14/11/2023 19:28, Niko Tyni wrote: Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: p...@packages.debian.org Hi release team, this has taken me much longer than necessary for various reasons, but I think we're almost ready to push Perl 5.38 to sid now. We should aim to release trixie with 5.40 (which will be released in May 2024 or so), but it's still better to do these transitions one at a time. Indeed. And sounds good about releasing with 5.40. TL;DR: - can we raise the remaining bugs to severity:serious? Go ahead. - I'll request a transition slot once the easy ones are fixed Cool. - should we worry about time64? Let's not block (or even entangle) on that. Cheers, Emilio
Bug#1053657: dhcpcd-base has ineffective Replaces due to /usr-merge and looses files in upgrade
On 08/10/2023 08:15, Helmut Grohne wrote: I'm sorry for not having spotted this before the point release and will now monitor stable p-u suites for similar problems to raise this earlier. Great, thanks. Can I assume that a package sits in p-u for at least three days before migrating to a stable release? Yes, p-u is frozen about 5 or 6 days before the release. Exceptions can happen, but excluding those you can assume that. Cheers, Emilio
Bug#1022759: lintian: don't emit source-nmu-has-incorrect-version-number for stable updates
Control: tags -1 patch On Tue, 25 Oct 2022 11:56:33 +0200 Emilio Pozuelo Monfort wrote: Package: lintian Version: 2.104.0 Severity: normal X-Debbugs-Cc: debian-rele...@lists.debian.org Hi, When preparing stable or security updates, the convention is to use debXuY whether it is a NMU or not, without making it e.g. deb11u1.1. Thus please stop emitting this tag when a stable update is detected. no-nmu-in-changelog should keep being emitted. See https://salsa.debian.org/lintian/lintian/-/merge_requests/481 Emilio
Bug#1052082: bullseye-pu: package rust-cbindgen/0.24.3-2~deb11u1
On 17/09/2023 17:12, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sun, 2023-09-17 at 11:36 +0200, Emilio Pozuelo Monfort wrote: This updates rust-cbindgen to 0.24, as required by Firefox ESR 115. The risk is low as the only (build)rdep of cbindgen are firefox-esr and thunderbird. Attached is a debian/ diff of the update. - * Only build the cbindgen binary. afaict that's still true, so maybe the changelog entry should still be present? Ack. I removed it because the packages are already gone in the current version in bullseye, so there's no change to the status quo. However I see how we're documenting the changes wrt the previous version in d/changelog, so that entry is still relevant. Added back. In any case, please go ahead. Uploaded. Cheers, Emilio
Bug#1019570: librust-cbindgen-dev has been removed from Bullseye
Hi Nick, On 12/09/2022 11:21, Nick Brown wrote: Package: rust-cbindgen Version: 0.23.0-1~deb11u1 Severity: important The NMU of 0.23.0-1~deb11u1 replaced 0.20.0-1~deb11u1 in Debian Bullseye and in doing so removed librust-cbindgen-dev and librust-cbindgen+clap-dev https://tracker.debian.org/news/1345484/accepted-rust-cbindgen-0230-1deb11u1-source-into-proposed-updates-stable-new-proposed-updates/ https://sources.debian.org/src/rust-cbindgen/0.23.0-1~deb11u1/debian/control/#L35 This means that any debian packages (or 3rd party debian packaged) that were built using librust-cbindgen-dev will no longer do so. I had 3rd party debian packages that were being built against ibrust-cbindgen-dev that no longer builds, and only work around is now vendor ibrust-cbindgen-dev. Why was ibrust-cbindgen-dev removed? Can it be restored? Sorry for the delay in answering this. I'm in the process of updating cbindgen again, and remembered that you asked about this. The reason I disabled it is that cbindgen is now embedding all the build-dependencies, since newer versions and new dependencies are added that are not found in bullseye. That means that librust-cbindgen-dev can't depend on those packages, and I'm not sure if we could ship those extra sources in that package and how that would interact with other packages in the ecosystem. If you know of a package that is doing the same thing and still providing a -dev package, I can take a look. Cheers, Emilio
Bug#1052082: bullseye-pu: package rust-cbindgen/0.24.3-2~deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net
Hi,
This updates rust-cbindgen to 0.24, as required by Firefox ESR 115.
The risk is low as the only (build)rdep of cbindgen are firefox-esr
and thunderbird.
Attached is a debian/ diff of the update.
Cheers,
Emilio
diff -ruNp rust-cbindgen-0.23.0/debian/changelog
rust-cbindgen-0.24.3/debian/changelog
--- rust-cbindgen-0.23.0/debian/changelog 2022-07-04 10:53:21.0
+0200
+++ rust-cbindgen-0.24.3/debian/changelog 2023-07-28 14:16:44.0
+0200
@@ -1,32 +1,32 @@
-rust-cbindgen (0.23.0-1~deb11u1) bullseye; urgency=medium
+rust-cbindgen (0.24.3-2~deb11u1) bullseye; urgency=medium
* Non-maintainer upload.
* Backport to bullseye.
* Vendor dependencies, they are not available in bullseye.
- * Only build the cbindgen binary.
* Lower dh-cargo build-dep.
* Build with rust-mozilla.
- -- Emilio Pozuelo Monfort Mon, 04 Jul 2022 10:53:21 +0200
+ -- Emilio Pozuelo Monfort Fri, 28 Jul 2023 14:16:44 +0200
-rust-cbindgen (0.23.0-1) unstable; urgency=medium
+rust-cbindgen (0.24.3-2) unstable; urgency=medium
- * Package cbindgen 0.23.0 from crates.io using debcargo 2.5.0
+ * Team upload.
+ * Package cbindgen 0.24.3 from crates.io using debcargo 2.6.0
+ * Relax dev-dependency on serial-test.
- -- Sylvestre Ledru Fri, 03 Jun 2022 11:20:37 +0200
+ -- Peter Michael Green Thu, 17 Nov 2022 20:11:36 +
-rust-cbindgen (0.20.0-1~deb11u1) bullseye; urgency=medium
+rust-cbindgen (0.24.3-1) unstable; urgency=medium
- * Non-maintainer upload.
- * Backport to bullseye.
+ * Package cbindgen 0.24.3 from crates.io using debcargo 2.5.0
- -- Emilio Pozuelo Monfort Thu, 02 Dec 2021 12:49:31 +0100
+ -- Sylvestre Ledru Sat, 25 Jun 2022 15:27:28 +0200
-rust-cbindgen (0.20.0-1) unstable; urgency=medium
+rust-cbindgen (0.23.0-1) unstable; urgency=medium
- * Package cbindgen 0.20.0 from crates.io using debcargo 2.4.4-alpha.0
+ * Package cbindgen 0.23.0 from crates.io using debcargo 2.5.0
- -- Sylvestre Ledru Sun, 22 Aug 2021 14:26:42 +0200
+ -- Sylvestre Ledru Fri, 03 Jun 2022 11:20:37 +0200
rust-cbindgen (0.19.0-1) experimental; urgency=medium
diff -ruNp rust-cbindgen-0.23.0/debian/control
rust-cbindgen-0.24.3/debian/control
--- rust-cbindgen-0.23.0/debian/control 2022-06-17 13:33:38.0 +0200
+++ rust-cbindgen-0.24.3/debian/control 2023-07-28 14:16:44.0 +0200
@@ -27,9 +27,10 @@ Build-Depends: debhelper (>= 12),
Maintainer: Debian Rust Maintainers
Uploaders:
Sylvestre Ledru
-Standards-Version: 4.5.1
+Standards-Version: 4.6.1
Vcs-Git: https://salsa.debian.org/rust-team/debcargo-conf.git [src/cbindgen]
Vcs-Browser:
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/cbindgen
+X-Cargo-Crate: cbindgen
Rules-Requires-Root: no
#Package: librust-cbindgen-dev
@@ -55,8 +56,8 @@ Rules-Requires-Root: no
# librust-cbindgen+clap-dev (= ${binary:Version})
#Provides:
# librust-cbindgen-0-dev (= ${binary:Version}),
-# librust-cbindgen-0.23-dev (= ${binary:Version}),
-# librust-cbindgen-0.23.0-dev (= ${binary:Version})
+# librust-cbindgen-0.24-dev (= ${binary:Version}),
+# librust-cbindgen-0.24.3-dev (= ${binary:Version})
#Description: Generating C bindings to Rust code - Rust source code
# This package contains the source for the Rust cbindgen crate, packaged by
# debcargo for use with cargo and dh-cargo.
@@ -72,10 +73,10 @@ Rules-Requires-Root: no
# librust-cbindgen+default-dev (= ${binary:Version}),
# librust-cbindgen-0+clap-dev (= ${binary:Version}),
# librust-cbindgen-0+default-dev (= ${binary:Version}),
-# librust-cbindgen-0.23+clap-dev (= ${binary:Version}),
-# librust-cbindgen-0.23+default-dev (= ${binary:Version}),
-# librust-cbindgen-0.23.0+clap-dev (= ${binary:Version}),
-# librust-cbindgen-0.23.0+default-dev (= ${binary:Version})
+# librust-cbindgen-0.24+clap-dev (= ${binary:Version}),
+# librust-cbindgen-0.24+default-dev (= ${binary:Version}),
+# librust-cbindgen-0.24.3+clap-dev (= ${binary:Version}),
+# librust-cbindgen-0.24.3+default-dev (= ${binary:Version})
#Description: Generating C bindings to Rust code - feature "clap" and 1 more
# This metapackage enables feature "clap" for the Rust cbindgen crate, by
pulling
# in any additional dependencies needed by that feature.
diff -ruNp rust-cbindgen-0.23.0/debian/patches/relax-dep.diff
rust-cbindgen-0.24.3/debian/patches/relax-dep.diff
--- rust-cbindgen-0.23.0/debian/patches/relax-dep.diff 1970-01-01
01:00:00.0 +0100
+++ rust-cbindgen-0.24.3/debian/patches/relax-dep.diff 2022-11-17
21:11:36.0 +0100
@@ -0,0 +1,13 @@
+Index: cbindgen/Cargo.toml
+===
+--- cbindgen.orig/Cargo.toml
cbindgen/Cargo.toml
+@@ -89,7 +89,7 @@ version = "3.0"
+ version = "0
Bug#1052027: bullseye-pu: package cargo-mozilla/0.66.0+ds1-1~deb11u1
On 16/09/2023 18:01, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sat, 2023-09-16 at 11:15 +0200, Emilio Pozuelo Monfort wrote: Following up on #1051051, this updates cargo-mozilla for the upcoming Firefox ESR 115. Just like for rustc-mozilla, the risk here is small as this package is only used to build firefox-esr and thunderbird. I have used the resulting package to successfully build and test firefox-esr 115.0.2 on bullseye. Please go ahead. Uploaded. Cheers, Emilio
Bug#1052027: bullseye-pu: package cargo-mozilla/0.66.0+ds1-1~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net Hi, Following up on #1051051, this updates cargo-mozilla for the upcoming Firefox ESR 115. Just like for rustc-mozilla, the risk here is small as this package is only used to build firefox-esr and thunderbird. I have used the resulting package to successfully build and test firefox-esr 115.0.2 on bullseye. Attached is the diff from 0.66 itself so that the changes in the backport are easier to review. A diff from 0.47 is not attached. Cheers, Emilio diff -ruNp cargo-0.66.0+ds1/debian/cargo.bash-completion cargo-mozilla-0.66.0+ds1/debian/cargo.bash-completion --- cargo-0.66.0+ds1/debian/cargo.bash-completion 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo.bash-completion 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -src/etc/cargo.bashcomp.sh cargo diff -ruNp cargo-0.66.0+ds1/debian/cargo.dirs cargo-mozilla-0.66.0+ds1/debian/cargo.dirs --- cargo-0.66.0+ds1/debian/cargo.dirs 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo.dirs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -usr/bin diff -ruNp cargo-0.66.0+ds1/debian/cargo-doc.docs cargo-mozilla-0.66.0+ds1/debian/cargo-doc.docs --- cargo-0.66.0+ds1/debian/cargo-doc.docs 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-doc.docs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -target/doc diff -ruNp cargo-0.66.0+ds1/debian/cargo.manpages cargo-mozilla-0.66.0+ds1/debian/cargo.manpages --- cargo-0.66.0+ds1/debian/cargo.manpages 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo.manpages 1970-01-01 01:00:00.0 +0100 @@ -1,2 +0,0 @@ -src/etc/man/cargo-*.1 -src/etc/man/cargo.1 diff -ruNp cargo-0.66.0+ds1/debian/cargo-mozilla.bash-completion cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.bash-completion --- cargo-0.66.0+ds1/debian/cargo-mozilla.bash-completion 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.bash-completion 2023-01-11 18:55:09.0 +0100 @@ -0,0 +1 @@ +src/etc/cargo.bashcomp.sh cargo diff -ruNp cargo-0.66.0+ds1/debian/cargo-mozilla.dirs cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.dirs --- cargo-0.66.0+ds1/debian/cargo-mozilla.dirs 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.dirs 2023-01-11 18:55:09.0 +0100 @@ -0,0 +1 @@ +usr/bin diff -ruNp cargo-0.66.0+ds1/debian/cargo-mozilla-doc.docs cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla-doc.docs --- cargo-0.66.0+ds1/debian/cargo-mozilla-doc.docs 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla-doc.docs 2023-01-11 18:55:09.0 +0100 @@ -0,0 +1 @@ +target/doc diff -ruNp cargo-0.66.0+ds1/debian/cargo-mozilla.manpages cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.manpages --- cargo-0.66.0+ds1/debian/cargo-mozilla.manpages 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.manpages 2023-01-11 18:55:09.0 +0100 @@ -0,0 +1,2 @@ +src/etc/man/cargo-*.1 +src/etc/man/cargo.1 diff -ruNp cargo-0.66.0+ds1/debian/changelog cargo-mozilla-0.66.0+ds1/debian/changelog --- cargo-0.66.0+ds1/debian/changelog 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/changelog 2023-07-30 10:37:52.0 +0200 @@ -1,3 +1,15 @@ +cargo-mozilla (0.66.0+ds1-1~deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Backport to bullseye as cargo-mozilla. + * Build-dep on rustc-mozilla. + * Don't build the doc package. + * Vendor libgit2 1.5.1, the system one is too old. + * Build-dep on libpcre3-dev, for libgit2. + * Don't use namespaced features. + + -- Emilio Pozuelo Monfort Sun, 30 Jul 2023 10:37:52 +0200 + cargo (0.66.0+ds1-1) unstable; urgency=medium [ Fabian Grünbichler ] diff -ruNp cargo-0.66.0+ds1/debian/control cargo-mozilla-0.66.0+ds1/debian/control --- cargo-0.66.0+ds1/debian/control 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/control 2023-07-30 10:37:52.0 +0200 @@ -1,4 +1,4 @@ -Source: cargo +Source: cargo-mozilla Section: devel Maintainer: Rust Maintainers Uploaders: Luca Bruno , @@ -10,17 +10,18 @@ Priority: optional Build-Depends: debhelper (>= 12~), dpkg-dev (>= 1.17.14), - cargo:native(>= 0.56.0), - rustc:native(>= 1.63), - libstd-rust-dev (>= 1.63), + cargo-mozilla:native(>= 0.56.0), + rustc-mozilla:native(>= 1.63), + libstd-rust-mozilla-dev (>= 1.63), pkg-config, bash-completion, python3:native, libcurl4-gnutls-dev | libcurl4-openssl-dev, libssh2-1-dev, - libgit2-dev (>= 1.5.0), - libgit2-dev (<< 1.6~~), +# libgit2-dev (>= 1.5.0), +# libgit2-dev (<< 1.6~~), libhttp-parser-d
Bug#1051051: bullseye-pu: package rustc-mozilla/1.63.0+dfsg1-2~deb11u1
Hi, On Fri, 01 Sep 2023 18:50:53 +0200 Emilio Pozuelo Monfort wrote: Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: team+pkg-mozi...@tracker.debian.org Hi, The time has come for a new Firefox / Thunderbird ESR release in *stable. This will require rustc/cargo/cbindgen backports as usual. For bookworm we're in a good shape for this update, but for bullseye and buster we'll need all three updates. For rustc-mozilla, I've used the version from bookworm. Hopefully I got all the stage0 binaries this time. Risk is low as this package is only used to build FF/TB. I have successfully built the whole chain up to FF 115 ESR on amd64. I'm attaching a diff from rustc_1.63/bookworm to the proposed update. I don't think there's much value in a 1.59->1.63 diff, but if you want it say so and I'll prepare one. I have just uploaded this to pu-new. I'd be great to get it accepted so that it can be built and I can propose/upload cargo-mozilla and cbindgen, all before Sep 26 when the next round of updates will go out, requiring the newer toolchain packages. Thanks, Emilio
Bug#1051051: bullseye-pu: package rustc-mozilla/1.63.0+dfsg1-2~deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: team+pkg-mozi...@tracker.debian.org
Hi,
The time has come for a new Firefox / Thunderbird ESR release in *stable.
This will require rustc/cargo/cbindgen backports as usual. For bookworm
we're in a good shape for this update, but for bullseye and buster we'll
need all three updates.
For rustc-mozilla, I've used the version from bookworm. Hopefully I got
all the stage0 binaries this time.
Risk is low as this package is only used to build FF/TB. I have
successfully built the whole chain up to FF 115 ESR on amd64.
I'm attaching a diff from rustc_1.63/bookworm to the proposed update. I don't
think there's much value in a 1.59->1.63 diff, but if you want it say so and
I'll prepare one.
Thanks,
Emilio
diff -ruNp debian.rustc/changelog debian/changelog
--- debian.rustc/changelog 2023-01-14 09:38:46.0 +0100
+++ debian/changelog2023-07-28 13:44:06.0 +0200
@@ -1,3 +1,13 @@
+rustc-mozilla (1.63.0+dfsg1-2~deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport to bullseye as rustc-mozilla.
+ * Do a bootstrap build.
+ * Disable wasm.
+ * Disable new binary packages rustfmt, -clippy, -all.
+
+ -- Emilio Pozuelo Monfort Fri, 28 Jul 2023 13:44:06 +0200
+
rustc (1.63.0+dfsg1-2) unstable; urgency=medium
[ Fabian Grünbichler ]
diff -ruNp debian.rustc/control debian/control
--- debian.rustc/control2023-01-14 09:38:46.0 +0100
+++ debian/control 2023-07-28 13:44:06.0 +0200
@@ -1,4 +1,4 @@
-Source: rustc
+Source: rustc-mozilla
Section: devel
Priority: optional
Maintainer: Debian Rust Maintainers
@@ -12,14 +12,14 @@ Build-Depends:
debhelper-compat (= 13),
dpkg-dev (>= 1.17.14),
python3:native,
- cargo:native (>= 0.60.0) ,
- rustc:native (>= 1.62.0+dfsg) ,
- rustc:native (<= 1.63.0++),
- llvm-14-dev:native,
- llvm-14-tools:native,
+# cargo:native (>= 0.60.0) ,
+# rustc:native (>= 1.62.0+dfsg) ,
+# rustc:native (<= 1.63.0++),
+ llvm-13-dev:native,
+ llvm-13-tools:native,
gcc-mingw-w64-x86-64-posix:native [amd64] ,
gcc-mingw-w64-i686-posix:native [i386] ,
- libllvm14 (>= 1:14.0.0),
+ libllvm13 (>= 1:13.0.0),
cmake (>= 3.0) | cmake3,
# needed by some vendor crates
pkg-config,
@@ -38,30 +38,32 @@ Build-Depends:
curl ,
ca-certificates ,
Build-Depends-Indep:
- wasi-libc (>= 0.0~git20220510.9886d3d~~) ,
- wasi-libc (<= 0.0~git20220510.9886d3d++) ,
- clang-14:native,
+# wasi-libc (>= 0.0~git20220510.9886d3d~~) ,
+# wasi-libc (<= 0.0~git20220510.9886d3d++) ,
+ clang-13:native,
Build-Conflicts: gdb-minimal
Standards-Version: 4.2.1
Homepage: http://www.rust-lang.org/
Vcs-Git: https://salsa.debian.org/rust-team/rust.git
Vcs-Browser: https://salsa.debian.org/rust-team/rust
-Package: rustc
+Package: rustc-mozilla
Architecture: any
Multi-Arch: allowed
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends},
- libstd-rust-dev (= ${binary:Version}),
+ libstd-rust-mozilla-dev (= ${binary:Version}),
gcc, libc-dev, binutils (>= 2.26)
Recommends:
cargo (>= 0.64.0~~), cargo (<< 0.65.0~~),
# llvm is needed for llvm-dwp for -C split-debuginfo=packed
- llvm-14,
+ llvm-13,
Suggests:
# lld and clang are needed for wasm compilation
- lld-14, clang-14,
-Replaces: libstd-rust-dev (<< 1.25.0+dfsg1-2~~)
+ lld-13, clang-13,
+Conflicts: rustc
+Provides: rustc (= ${binary:Version})
+Replaces: libstd-rust-dev (<< 1.25.0+dfsg1-2~~), rustc
Breaks: libstd-rust-dev (<< 1.25.0+dfsg1-2~~)
Description: Rust systems programming language
Rust is a curly-brace, block-structured expression language. It
@@ -76,7 +78,7 @@ Description: Rust systems programming la
generic programming and meta-programming, in both static and dynamic
styles.
-Package: libstd-rust-1.63
+Package: libstd-rust-mozilla-1.63
Section: libs
Architecture: any
Multi-Arch: same
@@ -98,12 +100,12 @@ Description: Rust standard libraries
This package contains the standard Rust libraries, built as dylibs,
needed to run dynamically-linked Rust programs (-C prefer-dynamic).
-Package: libstd-rust-dev
+Package: libstd-rust-mozilla-dev
Section: libdevel
Architecture: any
Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends},
- libstd-rust-1.63 (= ${binary:Version}),
+ libstd-rust-mozilla-1.63 (= ${binary:Version}),
Description: Rust standard libraries - development files
Rust is a curly-brace, block-structured expression language. It
visually resembles the C language family, but differs significantly
@@ -121,7 +123,7 @@ Description: Rust standard libraries - d
needed to compile Rust programs. It may also be installed on a system
of another host architecture, for cross-compiling to this architecture.
-Package: libstd-rust-dev-windows
+Package: libstd-rust-mozilla-dev-windows
Section: libde
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi Sean, On 11/05/2023 03:59, Sean Whitton wrote: Hello, On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote: Dear ctte, please consider overruling the dpkg maintainer to include the patch from #994388[1]. Currently dpkg contains code to emit the merged-/usr warning, that's dead code on Debian, but which becomes active when packages from the Debian archive are copied unmodified into derivatives. The heart of the issue is how dpkg is a native package. What we're talking about is not the Debian system, but the Debian archive as it exists independently of the Debian system. dpkg has an upstream existence that's independent of Debian, and it's perfectly legitimate for that version of dpkg to emit the warning. The problem here might be caused by how the Debian archive is implicitly being used to distribute upstream dpkg. This is not in itself a problem -- we distribute a lot of stuff in source packages that does not form part of the Debian system. But in this case, this distribution that's occurring might conflict with how Debian is seeking to provide a product not just to end users, but also to those building derivatives. One simple solution is for dpkg to become a non-native package, carrying Debian-specific patches to do things like remove the warning code. I think you're conflating two independent things. If you override the dpkg maintainer to remove that warning that occurs on derivatives, then anyone could NMU dpkg and the maintainer wouldn't introduce it back, effectively removing the warning from "dpkg upstream". OTOH if the dpkg maintainer switches to non-native packages, anyone could NMU it adding the change as a patch, however the maintainer will just NACK the NMU before or after it happens. So I don't see a problem with dpkg being native, just like e.g. apt is, and that won't magically solve the issue at hand. Cheers, Emilio
Bug#817285: Allow releasing security updates via PGP-signed control messages
Control: forwarded -1 https://salsa.debian.org/ftp-team/dak/-/merge_requests/270 Hi, On Wed, 09 Mar 2016 19:36:02 +0100 Moritz Muehlenhoff wrote: Package: ftp.debian.org Severity: wishlist This was discussed at one of the past security team meetings, but there was never a bug for that: (This is a first high level view, the exact requirements can be hashed out later.) Right now to release a security update one needs shell access on security-master. It would be great to allow the release of a security update via a PGP-signed control message (similar to how changes files need to be signed to allow uploads). The next step would then be an ACL mechanism where trusted DDs can be granted the possibility to release DSAs on their own (after the security team having acked the debdiff). (This also needs some tweaks for the debian-security-announce moderation script, but that's unrelated to this task. There's now a MR at [1] that should address the ACL for dak. Feel free to comment if you have any feedback. Cheers, Emilio [1] https://salsa.debian.org/ftp-team/dak/-/merge_requests/270
Bug#1033704: unblock: ikiwiki-hosting/0.20220716-2
Hi Simon, On 30/03/2023 19:15, Simon McVittie wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ikiwiki-host...@packages.debian.org Control: affects -1 + src:ikiwiki-hosting Please unblock package ikiwiki-hosting The package is not blocked at this stage in the freeze as it's not a key package and has autopkgtests. However I have added an unblock hint anyway and aged it a bit. Cheers, Emilio
Bug#1013872: salt: CVE-2022-22967
On Thu, 1 Sep 2022 08:13:07 +0200 Paul Gevers wrote: Hi, On Sun, 26 Jun 2022 13:55:24 +0200 Salvatore Bonaccorso wrote: > Source: salt > The following vulnerability was published for salt. > > CVE-2022-22967[0]: > | An issue was discovered in SaltStack Salt in versions before 3002.9, > | 3003.5, 3004.2. PAM auth fails to reject locked accounts, which allows > | a previously authorized user whose account is locked still run Salt > | commands when their account is locked. This affects both local shell > | accounts with an active session and salt-api users that authenticate > | via PAM eauth. As much as I'd like to stay away from fixing packages, do you need help with this one? It causing RC issues in testing even though it's removed. https://qa.debian.org/dose/debcheck/src_testing_main/1661922002/packages/pytest-testinfra.html#076c12ad0c0676e354433b4fd854e3d5 There's a new upstream release and I pulled it locally, but there are a lot of changes. So without experience with the package, it's a bit much to go over. The fix for this is very simple. We are ignoring pam_acct_mgmt()'s return value. The upstream fix (with tests) is at: https://github.com/saltstack/salt/commit/e068a34ccb2e17ae7224f8016a24b727f726d4c8 Cheers, Emilio
Bug#1031589: Handling of RC bugs in firefox-esr
On 24/02/2023 09:48, Adrian Bunk wrote: On Fri, Feb 24, 2023 at 09:19:40AM +0100, Emilio Pozuelo Monfort wrote: ... Also note that one of the concerns was for armhf, which is now being built from arm64 buildds. ... On armhf there is a 4 GB FTBFS for the future (like on i386), and a 3 GB FTBFS today that still seems to be present on some buildds. While some armhf buildds have a 4 GB userspace address space that is sufficient at least today, several buildds still run into the debian/rules test for 64bit: https://buildd.debian.org/status/logs.php?pkg=firefox=armhf https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf arm-ubc-0* had out of memory before the debian/rules test for 64bit, so there might be a genuine issue that firefox-esr cannot be built on these buildds and still might have to be blacklisted: https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf=91.11.0esr-1 My understanding was that those buildds were going to be decommissioned. But if that's not going to happen in the short term, a blacklist for firefox-esr and thunderbird would be in order. Cheers, Emilio
Bug#1031589: Handling of RC bugs in firefox-esr
Control: severity 1021810 important Hi, On 19/02/2023 21:23, Sebastian Ramacher wrote: On 2023-02-19 01:03:34 +0200, Adrian Bunk wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: Maintainers of Mozilla-related packages Control: block 1021810 982794 992150 993659 993660 by -1 popcon is no longer a criteria for key packages, which makes firefox-esr subject to autoremoval that would be permanent for bookworm at this point of the freeze. Currently firefox-esr is on the autoremoval list due to 5 RC bugs. While my personal opinion is that Debian should follow Ubuntu which is now providing Chromium and Firefox only as snap (perhaps using a different similar technology like flatpak), not providing Firefox as a package in bookworm due to autoremoval based on some random RC bug would be wrong. If for some reason firefox-esr would intentionally not be shipped in bookworm, then reverse dependencies currently on the autoremoval list should get RC bugs for getting the chance to adapt. It would be good if a release team member could review which RC bugs in firefox-esr should be downgraded/ignored/fixed for bookworm. We are down to #1021810 and #982794 which are both about support for 32 bit architectures. If we end up dropping 32 bit architectures from firefox-esr, #982794 won't be an issue any more. If not, I think we can ignore #982794 as it's not a regression compared to stable. As Emilio commented in #1021801, I would defer to him on these two bugs. As I said on #1021810 about possible build issues due to address space in the future, I think we should tackle those when the time comes. It may be true that some future Firefox updates will fail to build due to needing more memory, however it's also possible that we may be able to fix those issues by reducing the memory usage with some build flags. Also note that one of the concerns was for armhf, which is now being built from arm64 buildds. Thus I don't think removal on those arches based on that is warranted, and I'm downgrading that bug's severity. As for #982794 and #1019246, I'm not sure which way to lean. Currently Firefox is broken on the baseline for i386 and armhf, but that only affects some hardware. We're doing a disservice to some users by shipping software that they can't run, but OTOH we would do a disservice to those other users who can (and do) run it. One option would be to depend on sse2-support / neon-support etc, but that probably leaves the system in a bad state. Note that there's a MR to support the i386 baseline, which doesn't seem too unreasonable. Cheers, Emilio Perhaps a bookworm-ignore is the less evil solution, but I'm open to other options. Cheers, Emilio
Bug#1030785: -ffile-prefix-map option and reproducibility
On 07/02/2023 20:00, Sven Joachim wrote: On 2023-02-07 17:50 +0100, Guillem Jover wrote: On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: When building packages, a -ffile-prefix-map option is automatically injected into CFLAGS. Where does it come from? Since when? This is coming from dpkg-buildflags (in this case probably indirectly via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default, and then switched to enabled by default in dpkg 1.20.6 (see #974087). I suspect this was added to improve reproducibility. Ironically, it makes packages that capture this variable non reproducible, since the build path seems to be randomized (has it always been the case? since when?). It is the case of OCaml (see #1030785), and seemingly of R as well (found by grepping in my /etc). I wouldn't be surprised other packages are affected as well. AFAIR this was considered at the time, yes. If the flag is effectively not fixing anything for the set of packages involved, and is in fact actually making them unreproducible when they would not then, you can disable the fixfilepath feature in the reproducible build flags area, via DEB_BUILD_MAINT_OPTIONS. This does not help for packages which capture all build flags and store them in some file in the package (as is the case here). What is the purpose of having the build flags in a file in the .deb? Cheers, Emilio
Bug#1030672: [pre-approval] unblock: dpkg/1.21.20
Control: tags -1 confirmed Hi, On 06/02/2023 12:43, Guillem Jover wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: d...@packages.debian.org Control: affects -1 + src:dpkg Hi! Please pre-approve the dpkg 1.21.20 upload. [ Reason ] This dpkg release includes the translation updates for the recent Call for Translations, a few test suite fixes to make them pass again due to these translations and a recent cppcheck upload in unstable. A typo fix in the man pages. Updates to the lintian overrides. And fixes a typo in the Build-Depends that made the version too low. [ Impact ] These would give better translation coverage, the rest are not relevant to the final user, but can affect CI systems and downstream users, as they are build/test system fixes. [ Tests ] The various test suite fixes are due to the test suite failing now. The Build-Depends fix should be self-evident and would otherwise make the build fail. The new translations pass the tests too. [ Risks ] These all seem like very low risk changes to me. [ Checklist ] [√] all changes are documented in the d/changelog [√] I reviewed all changes and I approve them [√] attach debdiff against the package in testing [ Other info ] Actually, I've only attached the filtered debdiff, and not the unfiltered one here, as due to the translations it seems a bit big, and I'm afraid it might make the mail not get through. It can be found at: https://people.debian.org/~guillem/dpkg-1.21.19-1.21.20.debdiff.xz That debdiff is unfiltered, you might want to filterdiff with, which should give the same result as the attached one: xzcat dpkg-1.21.19-1.21.20.debdiff.xz | filterdiff --exclude '*.po' --exclude '*.pot' \ --exclude '*/man/*/*.pod' \ --exclude '*/testsuite' --exclude '*/at/*.m4' \ --exclude '*/configure' Alternatively I've pushed all except for the usual update-po and actual release commit and tag to: https://git.dpkg.org/cgit/dpkg/dpkg.git/log/ unblock dpkg/1.21.20 Please go ahead. Late translations are also OK to include. Cheers, Emilio
Bug#1029845: harfbuzz: non-distributable font included in source
On 01/02/2023 09:47, Andres Salomon wrote: Hi Security Team & Jeremy, I had originally planned to ask the release team about fixing #1029845 (the bug below) in bullseye via t-p-u. However, it would appear that there's also an outstanding security bug in harfbuzz (CVE-2022-33068, tracked at #1013673). So instead, maybe it's better if we group the font removal and the security fix together and upload something like what I've attached (a debdiff against 2.7.4-1) to bullseye-security. What do folks think? Jeremy, I created a bullseye branch over in my repo at https://salsa.debian.org/dilinger/harfbuzz/-/commits/bullseye Based on what's decided, I can adjust it and do a MR to whatever your preferred branch name is. Can you also include this change to fix a compiler warning on that security fix? https://github.com/harfbuzz/harfbuzz/commit/e421613e8f825508afa9a0b54d33085557c37441 Cheers, Emilio On Sat, 28 Jan 2023 13:05:01 -0500 Andres Salomon wrote: > Source: harfbuzz > Severity: serious > Version: 6.0.0-1 > Justification: Policy 2.1 > > Harfbuzz includes a nondistributable font in its test suite. I thought > it was just in sid/bookworm, but it's apparently also in bullseye as > well. > > In bullseye: > test/shaping/data/in-house/fonts/641ca9d7808b01cafa9a666c13811c9b56eb9c52.ttf > > In sid: > test/shape/data/in-house/fonts/641ca9d7808b01cafa9a666c13811c9b56eb9c52.ttf > > > dilinger@hm90:~/sid-build/harfbuzz2$ exiftool -Copyright-en-US > test/shape/data/in-house/fonts/641ca9d7808b01cafa9a666c13811c9b56eb9c52.ttf > Copyright (en-US) : The digitally signed machine readable > Typeface(Font) licensed to you is copyrighted ©, (2010), King Fahd > Glorious Quran Printing Complex...ISBN: 978-603-8010-15-0, Accession > No. 1430/7278..All rights reserved. This Font is the property of King > Fahd Glorious Quran Printing Complex, and may not be reproduced, > modified without the express written approval of King Fahd Glorious > Quran Printing Complex. > > > Upstream has removed the font, and Debian should as well: > https://github.com/harfbuzz/harfbuzz/issues/4059 > > > > >
Bug#1026116: Patches not applied in security release deb10u6, FTBFS
On 15/12/2022 20:38, Mihai Moldovan wrote: [Resent to the bug tracker as well] * On 12/15/22 19:15, Emilio Pozuelo Monfort wrote: I'm not sure I understand what the problem is. The patches are in debian/patches/ and are applied during build using quilt. Oh this is about the xorg-server-source binary package, not about src:xorg-server, I misread that. Indeed this is not a regression but a longstanding issue. I'll try to remember to fix this if there's another update soon. Cheers, Emilio
Bug#1026116: Patches not applied in security release deb10u6, FTBFS
On 15/12/2022 18:42, Sven Joachim wrote: Control: forcemerge 989852 -1 Am 15.12.2022 um 01:16 schrieb Mihai Moldovan: Package: xorg-server-source Version: 2:1.20.4-1+deb10u6 Severity: normal Hi It looks like the content of debian/patches/ has not been applied when packaging xorg-server-source. This at least one patch contains a FTBFS fix, it's impossible to build xorg-server out of the box. This is a regression - older versions of the same package (also in buster) had the patches applied just fine. The Debian Security release, however, does not. It seems you are slightly mistaken here, as the same problem had been reported for 2:1.20.4-1+deb10u3 already. It has been fixed post-buster in 2:1.20.6-1. I'm not sure I understand what the problem is. The patches are in debian/patches/ and are applied during build using quilt. From the amd64's build log [1]: dh build-arch --with quilt,autoreconf --parallel dh_quilt_patch -a -O--parallel Applying patch 001_fedora_extramodes.patch patching file hw/xfree86/common/extramodes Applying patch 02_kbsd-input-devd.diff patching file config/Makefile.am patching file config/config-backends.h patching file config/config.c patching file config/devd.c patching file configure.ac Hunk #1 succeeded at 568 (offset 2 lines). Hunk #2 succeeded at 954 (offset 3 lines). Hunk #3 succeeded at 2483 (offset 38 lines). patching file hw/xfree86/common/xf86Config.c Hunk #1 succeeded at 1264 (offset 7 lines). patching file hw/xfree86/common/xf86Globals.c Hunk #1 succeeded at 119 (offset 2 lines). patching file include/dix-config.h.in Hunk #1 succeeded at 424 (offset -9 lines). [...] Cheers, Emilio [1] https://buildd.debian.org/status/fetch.php?pkg=xorg-server=amd64=2%3A1.20.4-1%2Bdeb10u6=1667984267=0
Bug#1022759: lintian: don't emit source-nmu-has-incorrect-version-number for stable updates
Package: lintian Version: 2.104.0 Severity: normal X-Debbugs-Cc: debian-rele...@lists.debian.org Hi, When preparing stable or security updates, the convention is to use debXuY whether it is a NMU or not, without making it e.g. deb11u1.1. Thus please stop emitting this tag when a stable update is detected. no-nmu-in-changelog should keep being emitted. Thanks, Emilio
Bug#1022705: unplanned transition: ghostscript
On 24/10/2022 13:35, Jonas Smedegaard wrote: Quoting Simon McVittie (2022-10-24 13:24:07) Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: d...@jones.dk Forwarded: https://release.debian.org/transitions/html/auto-ghostscript.html Affects: src:ghostscript src:gimp src:dvisvgm src:libspectre src:xfig ghostscript appears to have started an unscheduled transition from libgs9 and libgs9-common to libgs10 and libgs-common. libgs-common Breaks and Replaces libgs9-common, so the affected packages will all have to migrate together. Looking at ghostscript's changelog, it seems this might have been accidental? There's no mention of the experimental version having been intentionally re-uploaded to unstable. https://release.debian.org/transitions/html/auto-ghostscript.html looks like it is tracking the affected packages, so I haven't tried to write a ben file for this. Please coordinate with the release team to either finish or revert this transition. Sorry, I forgot to warn the release team ahead. Ghostscript upstream has bumped its SONAME. There should be no breakage (other than the kind of breakage already done in "9" releases, due to security tightening of the internal Postscript interpreter), but yes it requires a rebuild for those package directly linking with libgs. I am frankly clueless about ben files and other transition magic, and would appreciate if someone more skilled in the art can guide this process. Have you tested if the rdeps build fine against this new version? Also, it would have been nice to disentangle the -common rename from the SONAME bump. Cheers, Emilio
Bug#1022105: pentaho-reporting-flow-engine: ships patches but doesn't apply them
Source: pentaho-reporting-flow-engine Version: 0.9.4-5 Severity: important Hi, pentaho-reporting-flow-engine 0.9.4-5 switched from dpatch to quilt: pentaho-reporting-flow-engine (0.9.4-5) unstable; urgency=medium [...] * drop dependency on dpatch and add dependency on quilt * disable timestamps in javadoc (Closes: #859976) The quilt build-dep was added, but there's no integration of quilt in d/rules. A way to fix this would be to switch to source format 3.0 (quilt), see #1007086. Another would be to add the quilt magic (e.g. via dh_quilt_patch / dh_quilt_unpatch) to d/rules. btw if the reproducible folks haven't complained, perhaps the timestamps patch can be dropped. Cheers, Emilio
Bug#1019353: transition: perl 5.36
Control: tags -1 confirmed Hi Niko, On 05/10/2022 21:50, Niko Tyni wrote: Control: tag -1 - moreinfo Control: block -1 with 1021324 On Wed, Sep 07, 2022 at 09:47:39PM +0300, Niko Tyni wrote: Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Tags: moreinfo X-Debbugs-Cc: p...@packages.debian.org Control: block -1 with 1016761 We'd like to get Perl 5.36 in bookworm. Filing this to get it on the radar properly, but I'd like to do a few more checks first. So tagging 'moreinfo' for now. I'll remove that when I'm done with the checks, hopefully in a couple of weeks at the latest. That was a bit optimistic (no real problems, I just couldn't find the time), but I think we're ready now. I've just test rebuilt the packages needing a binNMU one more time, and the only one failing in testing is redland-bindings (#1021324, should be trivial to fix.) I'm marking that as a blocker, but I haven't checked if it could be removed easily if necessary. #1019757 is still open but I've worked around the one autopkgtest regression that it triggered. I don't think it should be a blocker for the transition. I'm not aware of any other autopkgtest regressions (but I've only tested on amd64.) Hope this addresses any concerns you might have. Please let us know when there is a free transition window. An advance notice of a few days would be appreciated. Thanks for your work as always, That looks good. Please go ahead. Cheers, Emilio
Bug#1021973: iconv: undefined symbol after upgrade
On 18/10/2022 11:59, Guillaume Lefranc wrote:
Yes.
The upgrade was automatically done by unattended-upgrades, but we have
libc6 blacklisted due to issues we encountered previously
What kind of issues? Are they still relevant? Is there a bug report we could
look at?
In this case, I suggest you also block/pin libc-bin to the same version as
libc6.
Helmut, libc-bin could have a depends on libcX (>= ${binary:Version}), although
this is such a corner case that I don't think an update is necessary just for this.
Cheers,
Emilio
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename},label=Debian-Security";
};
Unattended-Upgrade::Package-Blacklist {
"libc6";
};
On Tue, 18 Oct 2022 at 09:23, Emilio Pozuelo Monfort
wrote:
On 18/10/2022 09:13, Guillaume Lefranc wrote:
Package: libc-bin
Version: 2.28-10+deb10u2
Severity: normal
Dear Maintainer,
after upgrading libc-bin from 2.28-10+deb10u1 to 2.28-10+deb10u2, the
following error appeared after running iconv the following way:
iconv -cs -f 'UTF-8' -t 'UTF-8' /tmp/510754/import/import.1
iconv: relocation error: iconv: symbol __gconv_create_spec version
GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
Any particular reason you upgraded libc-bin but not libc6?
Cheers,
Emilio
Bug#1021810: Should firefox-esr be dropped on 32bit architectures in bookworm?
On 15/10/2022 08:27, Adrian Bunk wrote:
Package: firefox-esr
Version: 102.3.0esr-1
Severity: serious
Tags: bookworm sid
X-Debbugs-Cc: Carsten Schoenert ,
debian-rele...@lists.debian.org, t...@security.debian.org, debian-...@lists.debian.org
[ various potentially interested parties are Cc'ed ]
4 GB address space for one process is an absolute limit on 32bit
architectures, including for native building as is done in Debian.[1]
mipsel has 2 GB address space (all Debian buildds have 64bit kernels),
the 2020 Firefox ESR (78) was the last Firefox ESR to build there.
On i386 and 32bit arm:
4 GB address space are available with a 64bit kernel.
3 GB address space are typically available with a 32bit kernel.
All i386 buildds are using a 64bit kernel,
but armhf buildds are currently mixed.
That is about to change (once linux-signed hits bullseye-backports). All armhf
builds will be running on arm64 buildds.
This uncovered that the 2022 ESR of Firefox (102) already needs
more than 3 GB address space on armhf.[2]
There is a new ESR major release of Firefox every summer,
which is being used also in *stable releases of Debian since the
previous ESR branch loses upstream security support soon afterwards.
It is possible to confine building firefox{,-esr} to only the 64bit
buildds on the buildd side to address the current issue,[3] but during
the non-LTS lifetime of bookworm firefox-esr will be upgraded three
times to newer ESR major releses.
One can hope the 2023 ESR might still be buildable with 4 GB address space,
which would cover the non-LTS support time of bullseye.
I would be less optimistic that the 2025 ESR will still be buildable
with 4 GB address space, which implies that it might not be possbile
to provide security support for firefox-esr on i386 and 32bit arm
during the whole non-LTS support time of bookworm.
The above considerations might also apply to whether or not
thunderbird/i386 should be provided in bookworm.
I don't see why we should preemptively remove firefox from architectures for a
build issue that may or may not happen 3 years from now. If it happens and we
can't fix/workaround it, then we can discontinue FF security updates there. But
until then, I think providing FF is better than not providing it.
Cheers,
Emilio
Bug#1021973: iconv: undefined symbol after upgrade
On 18/10/2022 09:13, Guillaume Lefranc wrote: Package: libc-bin Version: 2.28-10+deb10u2 Severity: normal Dear Maintainer, after upgrading libc-bin from 2.28-10+deb10u1 to 2.28-10+deb10u2, the following error appeared after running iconv the following way: iconv -cs -f 'UTF-8' -t 'UTF-8' /tmp/510754/import/import.1 iconv: relocation error: iconv: symbol __gconv_create_spec version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference Any particular reason you upgraded libc-bin but not libc6? Cheers, Emilio
Bug#1021205: transition: simdjson
On 07/10/2022 16:43, M. Zhou wrote: Thanks. It has been uploaded to unstable. binNMUs scheduled. Cheers, Emilio
Bug#1021205: transition: simdjson
Control: tags -1 confirmed On 03/10/2022 19:22, M. Zhou wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, I'd like to start the transition of simdjson. It has only two reverse dependencies in testing: cloudflare-ddns pcm Both of them passed my local test with amd64 host. Go ahead. Cheers, Emilio
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
Hi Santiago, On 15/09/2022 09:52, Emilio Pozuelo Monfort wrote: On 14/09/2022 15:42, Santiago R.R. wrote: El 14/09/22 a las 13:58, Emilio Pozuelo Monfort escribió: On 13/09/2022 16:46, Sylvain Beucler wrote: Hi, IIUC this is about fixing 2 non-security bugs, that were introduced prior to buster's initial release. I personally don't think this fits the LTS project scope. Maybe other LTS members will have a different opinion. We've had bugfix updates from time to time. They are rare, but not forbidden. This should go in a buster suite rather than buster-security, but since there's no such suite for LTS, having it in buster-security is the lesser evil. Of course we shouldn't flood -security with bug fixes, if that was necessary we should consider keeping $stable open and handled by the LTS team (but that doesn't seem necessary at this point). In this case, since the update has been prepared and looks sensible, I'll go ahead with the upload if nobody objects. Thanks, Emilio. Also consider https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961654#15 Haven't tested yet myself. But I suppose I should apply it in unstable. For buster I'd rather use what was proposed for buster-pu, as that's also what is in bullseye. I have uploaded that, with a s/buster/&-security/ in d/changelog, and fixing your name to be UTF-8. Cheers, Emilio
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
On 14/09/2022 15:42, Santiago R.R. wrote: El 14/09/22 a las 13:58, Emilio Pozuelo Monfort escribió: On 13/09/2022 16:46, Sylvain Beucler wrote: Hi, IIUC this is about fixing 2 non-security bugs, that were introduced prior to buster's initial release. I personally don't think this fits the LTS project scope. Maybe other LTS members will have a different opinion. We've had bugfix updates from time to time. They are rare, but not forbidden. This should go in a buster suite rather than buster-security, but since there's no such suite for LTS, having it in buster-security is the lesser evil. Of course we shouldn't flood -security with bug fixes, if that was necessary we should consider keeping $stable open and handled by the LTS team (but that doesn't seem necessary at this point). In this case, since the update has been prepared and looks sensible, I'll go ahead with the upload if nobody objects. Thanks, Emilio. Also consider https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961654#15 Haven't tested yet myself. But I suppose I should apply it in unstable. For buster I'd rather use what was proposed for buster-pu, as that's also what is in bullseye. Cheers, Emilio
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
On 13/09/2022 16:46, Sylvain Beucler wrote: Hi, IIUC this is about fixing 2 non-security bugs, that were introduced prior to buster's initial release. I personally don't think this fits the LTS project scope. Maybe other LTS members will have a different opinion. We've had bugfix updates from time to time. They are rare, but not forbidden. This should go in a buster suite rather than buster-security, but since there's no such suite for LTS, having it in buster-security is the lesser evil. Of course we shouldn't flood -security with bug fixes, if that was necessary we should consider keeping $stable open and handled by the LTS team (but that doesn't seem necessary at this point). In this case, since the update has been prepared and looks sensible, I'll go ahead with the upload if nobody objects. Cheers, Emilio
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
Hi Chris, On 14/09/2022 05:48, Chris Frey wrote: On the other hand, the fix has been known since 2019 and looks like a prime problem for an LTS newbie volunteer like me. I have created the fix based on the Debian/bzip2 repo, the fix is in the debian/buster branch. git clone http://digon.foursquare.net/debian-buster-bzip2/.git Your top-commit looks very similar to the one from Santiago on [1]. I'd rather use that to give him credit as he proposed the fix first (plus using CPPFLAGS seems more correct for this flag). In addition to that, the commit misses his follow-up fix in [2]. I'm going to consider that last debdiff from him for an upload to buster. Thanks in any case for looking at it (and coming up with a similar fix) and for testing the update. Cheers, Emilio [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=961654;filename=bzip2_1.0.6-9.2~deb10u2.debdiff;msg=5 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=961654;filename=bzip2_1.0.6-9.2~deb10u2.debdiff;msg=10 I have tested it on a 32bit buster, and it works on +2g files. I do not have privileges to push this to any server yet, so feel free to tweak the changelog and claim it as your own, whoever wishes to upload it. - Chris On Tue, Sep 13, 2022 at 04:46:14PM +0200, Sylvain Beucler wrote: Hi, IIUC this is about fixing 2 non-security bugs, that were introduced prior to buster's initial release. I personally don't think this fits the LTS project scope. Maybe other LTS members will have a different opinion. Cheers! Sylvain Beucler Debian LTS Team On 13/09/2022 15:27, Santiago R.R. wrote: El 10/09/22 a las 19:11, Adam D. Barratt escribió: On Wed, 2020-05-27 at 11:56 +0200, Santiago R.R. wrote: Since 1.0.6-9, bzip2 was built without the -D_FILE_OFFSET_BITS=64 CPPFLAG, and so it's not able to handle > 2GB files in 32-bit archs. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557 I've uploaded a fixed version to unstable yesterday. It would be great to fix it also in buster. Please, consider the attached debdiff. Would it be OK for you to upload it? Apologies for apparently letting this sit unanswered. (FTR there was a reply from a non-SRM member 18 months ago.) And I am sorry I missed that answer. The final point release for buster has now happened, so any further updates to packages in buster will need to be handled via LTS. I'm therefore going to close this request now. [snip] I am forwarding this to the LTS folks, so they can decide about this change.
Bug#1008062: gnutls28 3.6.7-4+deb10u8 flagged for acceptance
On 17/04/2022 13:22, Adam D Barratt wrote: package release.debian.org tags 1008062 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: gnutls28 Version: 3.6.7-4+deb10u8 Explanation: fix test suite when combined with OpenSSL 1.1.1e or newer After checking with Adam, I have uploaded a deb10u9 (including the deb10u8 changes) with a couple of security fixes to buster-security. deb10u8 should make it into buster, and if any follow-up changes are needed, a deb10u10 update based on deb10u9 could be done to buster-proposed-updates. Cheers, Emilio
Bug#960396: web security flaws in src:adminer/4.7.1-1 in stable?
Hi, On 08/08/2022 14:41, Alexandre Rossi wrote: Hi, We're in the process of arranging the final point release for buster, as support for it moves to the new LTS team. Is this something you're still interested in updating in buster? Yes, I even still have the built package ready for upload on mentors.d.o . In that case please feel free to get it uploaded, bearing in mind the time constraints mentioned. After REJECTED (signature too old), debsign, REJECTED (not allowed as DM), the source upload is awaiting comments or sponsorship at mentors.d.o . https://mentors.debian.net/package/adminer/ https://mentors.debian.net/debian/pool/main/a/adminer/adminer_4.7.1-1+deb10u1.dsc Any issues, do not hesitate to come back to me. I reviewed, smoke-tested, and uploaded this for you. Cheers, Emilio
Bug#1014907: buster-pu: package rustc-mozilla/1.59.0+dfsg1-1~deb10u1
On 28/07/2022 18:23, Emilio Pozuelo Monfort wrote:
On 14/07/2022 11:02, Emilio Pozuelo Monfort wrote:
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net
Hi,
This updates rustc-mozilla in buster, in preparation for Firefox 102.
I'm attaching the debdiff from the bullseye update. The windows target
is disabled because it was already disabled in buster, and is something
we don't really care about for our purpose.
I've uploaded the package already to oldstable-new.
I've added a couple of changes to fix the FTBFS on i386 and arm64. debdiff
attached and package uploaded.
Following the bullseye update, this one adds the mips(el) binaries to buster.
Package uploaded, and debian/ diff attached.
Cheers,
Emiliodiff -ruNp debian.deb10u2/changelog debian.deb10u3/changelog
--- debian.deb10u2/changelog2022-07-28 18:16:59.0 +0200
+++ debian.deb10u3/changelog2022-08-04 09:50:12.0 +0200
@@ -1,3 +1,9 @@
+rustc-mozilla (1.59.0+dfsg1-1~deb10u3) buster; urgency=medium
+
+ * Include mips(el) stage0 binaries.
+
+ -- Emilio Pozuelo Monfort Thu, 04 Aug 2022 09:50:12 +0200
+
rustc-mozilla (1.59.0+dfsg1-1~deb10u2) buster; urgency=medium
* Inline atomics on arm64.
diff -ruNp debian.deb10u2/rules debian.deb10u3/rules
--- debian.deb10u2/rules2022-07-28 18:16:54.0 +0200
+++ debian.deb10u3/rules2022-08-04 09:49:04.0 +0200
@@ -73,7 +73,7 @@ update-version:
# README.Debian for more details of the cases described below.
#
PRECONFIGURE_CHECK = :
-HAVE_BINARY_TARBALL := $(shell ls -1 stage0/*/*$(DEB_HOST_RUST_TYPE)*
2>/dev/null | wc -l)
+HAVE_BINARY_TARBALL := $(shell ls -1 stage0*/*/*$(DEB_HOST_RUST_TYPE)*
2>/dev/null | wc -l)
DOWNLOAD_BOOTSTRAP := false
# allow not using the binary tarball although it exists
#ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armhf i386 powerpc ppc64el
s390x))
@@ -193,6 +193,7 @@ build:
override_dh_clean:
# Upstream contains a lot of these
dh_clean -XCargo.toml.orig
+ rm -f stage0/*/*-mips-* stage0/*/*-mipsel-*
debian/config.toml: debian/config.toml.in debian/rules
u="$(DEB_VERSION_UPSTREAM)"; \
@@ -251,6 +252,12 @@ debian/dh_auto_configure.stamp: debian/c
echo 'fn main() { println!("cargo:rustc-link-lib=lzma"); }' >
vendor/lzma-sys/build.rs
# We don't run ./configure because we use debian/config.toml directly
ln -sf debian/config.toml config.toml
+ # set up links for the mips* tarballs, as bootstrap.py expects them in
stage0/
+ for fmips in stage0-mips/*/*; do \
+ f0="`echo $$fmips | sed 's/stage0-mips/stage0/'`"; \
+ # we use a hardlink here, for some reason bootstrap.py doesn't
like symlinks \
+ ln $$fmips $$f0; \
+ done
touch "$@"
override_dh_auto_configure-arch: debian/dh_auto_configure.stamp
Bug#1014324: bullseye-pu: package rustc-mozilla/1.59.0+dfsg1-1~deb11u1
On 04/07/2022 10:51, Emilio Pozuelo Monfort wrote: Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net Hi, This updates rustc-mozilla in bullseye from 1.51 to 1.59. I disabled the new binary packages in src:rustc_1.59, there are more packages that we don't really need and could disable but since they are already present I left them be. I'm attaching two diffs for the debian/ dir, one from rustc-mozilla 1.51, and one from rustc 1.59. I have uploaded deb11u2 with the missing binaries for mips(el). Only mipsel is needed here, but the same tarball will be reused in a buster update where those will be used. I'm adding a diff of the debian dirs. The additional diff would be the stage0-mips tarball, which includes these new binaries: cargo-1.58.0-mipsel-unknown-linux-gnu.tar.xz cargo-1.58.0-mips-unknown-linux-gnu.tar.xz rustc-1.58.0-mipsel-unknown-linux-gnu.tar.xz rustc-1.58.0-mips-unknown-linux-gnu.tar.xz rust-std-1.58.0-mipsel-unknown-linux-gnu.tar.xz rust-std-1.58.0-mips-unknown-linux-gnu.tar.xz Cheers, Emiliodiff -ruNp debian.old/changelog debian/changelog --- debian.old/changelog2022-07-03 11:51:30.0 +0200 +++ debian/changelog2022-08-03 12:44:23.0 +0200 @@ -1,3 +1,9 @@ +rustc-mozilla (1.59.0+dfsg1-1~deb11u2) bullseye; urgency=medium + + * Include mips(el) stage0 binaries. + + -- Emilio Pozuelo Monfort Wed, 03 Aug 2022 12:44:23 +0200 + rustc-mozilla (1.59.0+dfsg1-1~deb11u1) bullseye; urgency=medium * Non-maintainer upload. diff -ruNp debian.old/rules debian/rules --- debian.old/rules2022-06-18 11:55:15.0 +0200 +++ debian/rules2022-08-03 12:44:23.0 +0200 @@ -65,7 +65,7 @@ update-version: # README.Debian for more details of the cases described below. # PRECONFIGURE_CHECK = : -HAVE_BINARY_TARBALL := $(shell ls -1 stage0/*/*$(DEB_HOST_RUST_TYPE)* 2>/dev/null | wc -l) +HAVE_BINARY_TARBALL := $(shell ls -1 stage0*/*/*$(DEB_HOST_RUST_TYPE)* 2>/dev/null | wc -l) DOWNLOAD_BOOTSTRAP := false # allow not using the binary tarball although it exists #ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armhf i386 powerpc ppc64el s390x)) @@ -180,11 +180,17 @@ endif .PHONY: build build: + for fmips in stage0-mips/*/*; do \ + f0="`echo $$fmips | sed 's/stage0-mips/stage0/'`"; \ + # we use a hardlink here, for some reason bootstrap.py doesn't like symlinks \ + ln $$fmips $$f0; \ + done $(SYSTEM_WORKAROUNDS) dh $@ --parallel override_dh_clean: # Upstream contains a lot of these dh_clean -XCargo.toml.orig + rm -f stage0/*/*-mips-* stage0/*/*-mipsel-* debian/config.toml: debian/config.toml.in debian/rules u="$(DEB_VERSION_UPSTREAM)"; \
Bug#1014860: buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u1
On 19/07/2022 14:06, Emilio Pozuelo Monfort wrote: On 15/07/2022 14:24, Emilio Pozuelo Monfort wrote: Control: retitle -1 buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u2 On 13/07/2022 12:55, Emilio Pozuelo Monfort wrote: Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-llvm-t...@lists.alioth.debian.org This backports LLVM 13 to buster, for Firefox/Thunderbird ESR 102. The changes from the bullseye backport are minimal, debdiff attached. I have already uploaded the package, but let me know if you have any comments. I have noticed a couple of problems: - there's a build-dep that worked for me because of the alternative, but didn't in the buildds. I have addressed that here. - I brought back mips support The mips changes were incomplete. I have uploaded deb10u3 with an additional fix for mips. Unlikely that there's anyone still using firefox in mips, specially as it hasn't been built in a long time, but the fix is easy so let's go ahead with it. Brown paper bag release, this adds mips in one extra place. Uploaded. Thanks, Emiliodiff -Nru llvm-toolchain-13-13.0.1/debian/changelog llvm-toolchain-13-13.0.1/debian/changelog --- llvm-toolchain-13-13.0.1/debian/changelog 2022-07-19 11:37:05.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/changelog 2022-07-21 09:14:44.0 +0200 @@ -1,3 +1,9 @@ +llvm-toolchain-13 (1:13.0.1-6~deb10u4) buster; urgency=medium + + * Disable libunwind on mips. + + -- Emilio Pozuelo Monfort Thu, 21 Jul 2022 09:14:44 +0200 + llvm-toolchain-13 (1:13.0.1-6~deb10u3) buster; urgency=medium * Disable lldb on mips. diff -Nru llvm-toolchain-13-13.0.1/debian/rules llvm-toolchain-13-13.0.1/debian/rules --- llvm-toolchain-13-13.0.1/debian/rules 2022-07-18 10:16:39.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/rules 2022-07-21 09:14:36.0 +0200 @@ -255,7 +255,7 @@ # Enable libunwind (or not) LIBUNWIND_ENABLE=yes -ifneq (,$(filter $(DEB_HOST_ARCH), s390x armel m68k mipsel hurd-i386 powerpc sparc sparc64 x32)) +ifneq (,$(filter $(DEB_HOST_ARCH), s390x armel m68k mips mipsel hurd-i386 powerpc sparc sparc64 x32)) LIBUNWIND_ENABLE=no # do not use compiler-rt builtins for libcxx (libcxxabi) when libunwind is # disabled since the gnu implementation in libgcc_s will then be required
Bug#1014907: buster-pu: package rustc-mozilla/1.59.0+dfsg1-1~deb10u1
On 14/07/2022 11:02, Emilio Pozuelo Monfort wrote:
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net
Hi,
This updates rustc-mozilla in buster, in preparation for Firefox 102.
I'm attaching the debdiff from the bullseye update. The windows target
is disabled because it was already disabled in buster, and is something
we don't really care about for our purpose.
I've uploaded the package already to oldstable-new.
I've added a couple of changes to fix the FTBFS on i386 and arm64. debdiff
attached and package uploaded.
Thanks,
Emiliodiff -ruNp debian/changelog rustc-mozilla-1.59.0+dfsg1/debian/changelog
--- debian/changelog2022-07-12 00:18:55.0 +0200
+++ rustc-mozilla-1.59.0+dfsg1/debian/changelog 2022-07-28 18:17:01.281355462
+0200
@@ -1,3 +1,10 @@
+rustc-mozilla (1.59.0+dfsg1-1~deb10u2) buster; urgency=medium
+
+ * Inline atomics on arm64.
+ * Increase allowed test failures on i386.
+
+ -- Emilio Pozuelo Monfort Thu, 28 Jul 2022 18:16:59 +0200
+
rustc-mozilla (1.59.0+dfsg1-1~deb10u1) buster; urgency=medium
* Backport to buster.
diff -ruNp debian/patches/d-aarch64-inline-atomics.patch
rustc-mozilla-1.59.0+dfsg1/debian/patches/d-aarch64-inline-atomics.patch
--- debian/patches/d-aarch64-inline-atomics.patch 1970-01-01
01:00:00.0 +0100
+++ rustc-mozilla-1.59.0+dfsg1/debian/patches/d-aarch64-inline-atomics.patch
2022-07-28 13:39:58.740551614 +0200
@@ -0,0 +1,40 @@
+--- a/compiler/rustc_target/src/spec/aarch64_be_unknown_linux_gnu.rs
b/compiler/rustc_target/src/spec/aarch64_be_unknown_linux_gnu.rs
+@@ -8,7 +8,6 @@ pub fn target() -> Target {
+ data_layout:
"E-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128".to_string(),
+ arch: "aarch64".to_string(),
+ options: TargetOptions {
+-features: "+outline-atomics".to_string(),
+ max_atomic_width: Some(128),
+ mcount: "\u{1}_mcount".to_string(),
+ endian: Endian::Big,
+--- a/compiler/rustc_target/src/spec/aarch64_be_unknown_linux_gnu_ilp32.rs
b/compiler/rustc_target/src/spec/aarch64_be_unknown_linux_gnu_ilp32.rs
+@@ -12,7 +12,6 @@ pub fn target() -> Target {
+ arch: "aarch64".to_string(),
+ options: TargetOptions {
+ abi: "ilp32".to_string(),
+-features: "+outline-atomics".to_string(),
+ mcount: "\u{1}_mcount".to_string(),
+ endian: Endian::Big,
+ ..base
+--- a/compiler/rustc_target/src/spec/aarch64_unknown_linux_gnu.rs
b/compiler/rustc_target/src/spec/aarch64_unknown_linux_gnu.rs
+@@ -7,7 +7,6 @@ pub fn target() -> Target {
+ data_layout:
"e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128".to_string(),
+ arch: "aarch64".to_string(),
+ options: TargetOptions {
+-features: "+outline-atomics".to_string(),
+ mcount: "\u{1}_mcount".to_string(),
+ max_atomic_width: Some(128),
+ supported_sanitizers: SanitizerSet::ADDRESS
+--- a/compiler/rustc_target/src/spec/aarch64_unknown_linux_gnu_ilp32.rs
b/compiler/rustc_target/src/spec/aarch64_unknown_linux_gnu_ilp32.rs
+@@ -8,7 +8,6 @@ pub fn target() -> Target {
+ arch: "aarch64".to_string(),
+ options: TargetOptions {
+ abi: "ilp32".to_string(),
+-features: "+outline-atomics".to_string(),
+ max_atomic_width: Some(128),
+ mcount: "\u{1}_mcount".to_string(),
+ ..super::linux_gnu_base::opts()
diff -ruNp debian/patches/series
rustc-mozilla-1.59.0+dfsg1/debian/patches/series
--- debian/patches/series 2022-03-29 15:18:33.0 +0200
+++ rustc-mozilla-1.59.0+dfsg1/debian/patches/series2022-07-28
13:38:45.892372838 +0200
@@ -52,3 +52,4 @@ d-rustc-i686-baseline.patch
# Experimental patch not yet working
#d-rustc-prefer-dynamic.patch
d-rustdoc-disable-embedded-fonts.patch
+d-aarch64-inline-atomics.patch
diff -ruNp debian/rules rustc-mozilla-1.59.0+dfsg1/debian/rules
--- debian/rules2022-07-12 00:18:55.0 +0200
+++ rustc-mozilla-1.59.0+dfsg1/debian/rules 2022-07-28 18:16:54.829342634
+0200
@@ -51,6 +51,14 @@ RUSTBUILD_TEST = $(RUSTBUILD) test --no-
# See src/bootstrap/README.md for more options.
RUSTBUILD_TEST_FLAGS =
+ifneq (,$(filter buster%, $(DEB_DISTRIBUTION)))
+ifeq ($(DEB_HOST_ARCH), arm64)
+# https://github.com/rust-lang/rust/issues/93166
+RUSTFLAGS = -Ctarget-feature=-outline-atomics
+export RUSTFLAGS
+endif
+endif
+
# https://github.com/rust-lang/rust/issues/89744
# TODO: remove when we update cargo to 1.55 / 0.56
# upstream bug still exists and is under investigation, but is hidden by newer
cargo
@@ -285,7 +293,7 @@ TEST_LOG
Bug#1014860: buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u1
On 15/07/2022 14:24, Emilio Pozuelo Monfort wrote: Control: retitle -1 buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u2 On 13/07/2022 12:55, Emilio Pozuelo Monfort wrote: Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-llvm-t...@lists.alioth.debian.org This backports LLVM 13 to buster, for Firefox/Thunderbird ESR 102. The changes from the bullseye backport are minimal, debdiff attached. I have already uploaded the package, but let me know if you have any comments. I have noticed a couple of problems: - there's a build-dep that worked for me because of the alternative, but didn't in the buildds. I have addressed that here. - I brought back mips support The mips changes were incomplete. I have uploaded deb10u3 with an additional fix for mips. Unlikely that there's anyone still using firefox in mips, specially as it hasn't been built in a long time, but the fix is easy so let's go ahead with it. Cheers, Emiliodiff -Nru llvm-toolchain-13-13.0.1/debian/changelog llvm-toolchain-13-13.0.1/debian/changelog --- llvm-toolchain-13-13.0.1/debian/changelog 2022-07-15 11:10:37.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/changelog 2022-07-19 11:37:05.0 +0200 @@ -1,3 +1,9 @@ +llvm-toolchain-13 (1:13.0.1-6~deb10u3) buster; urgency=medium + + * Disable lldb on mips. + + -- Emilio Pozuelo Monfort Tue, 19 Jul 2022 11:37:05 +0200 + llvm-toolchain-13 (1:13.0.1-6~deb10u2) buster; urgency=medium * Don't build-dep on llvm-spirv, it's not available in buster diff -Nru llvm-toolchain-13-13.0.1/debian/rules llvm-toolchain-13-13.0.1/debian/rules --- llvm-toolchain-13-13.0.1/debian/rules 2022-07-15 11:10:37.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/rules 2022-07-18 10:16:39.0 +0200 @@ -328,7 +328,7 @@ endif LLDB_ENABLE=yes -LLDB_DISABLE_ARCHS := hurd-i386 ia64 powerpc powerpcspe ppc64 riscv64 sparc64 mips64el mipsel +LLDB_DISABLE_ARCHS := hurd-i386 ia64 powerpc powerpcspe ppc64 riscv64 sparc64 mips mips64el mipsel # hurd has threading issues ifeq (,$(filter-out $(LLDB_DISABLE_ARCHS), $(DEB_HOST_ARCH))) # Disable LLDB for this arch.
Bug#1014909: buster-pu: package rust-cbindgen/0.23.0-1~deb10u1
On 14/07/2022 11:27, Emilio Pozuelo Monfort wrote:
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net
Hi,
This updates rust-cbindgen to 0.23 for FF 102. FF/TB are the only users
of this package, so that should be fine.
The debdiff against bullseye adds a missing build-dep on the new rustc.
I have pushed a fix to buster, which fixes the file timestamps. The debhelper
target fixing them was introduced in debhelper 12.8, so it didn't work in deb10u1.
Cheers,
Emiliodiff -Nru rust-cbindgen-0.23.0/debian/changelog
rust-cbindgen-0.23.0/debian/changelog
--- rust-cbindgen-0.23.0/debian/changelog 2022-07-14 10:52:44.0
+0200
+++ rust-cbindgen-0.23.0/debian/changelog 2022-07-18 10:24:11.0
+0200
@@ -1,7 +1,15 @@
+rust-cbindgen (0.23.0-1~deb10u2) buster; urgency=medium
+
+ * Use override_ target instead of execute_after_, the latter is not
+supported in buster's debhelper. This fixes files with too old
+timestamps.
+
+ -- Emilio Pozuelo Monfort Mon, 18 Jul 2022 10:24:11 +0200
+
rust-cbindgen (0.23.0-1~deb10u1) buster; urgency=medium
* Non-maintainer upload.
- * Backport to bullseye.
+ * Backport to buster.
* Bump rustc-mozilla build-deps to 1.59.
-- Emilio Pozuelo Monfort Thu, 14 Jul 2022 10:52:44 +0200
diff -Nru rust-cbindgen-0.23.0/debian/rules rust-cbindgen-0.23.0/debian/rules
--- rust-cbindgen-0.23.0/debian/rules 2022-06-17 13:13:13.0 +0200
+++ rust-cbindgen-0.23.0/debian/rules 2022-07-18 10:20:56.0 +0200
@@ -17,5 +17,6 @@
help2man debian/cbindgen/usr/bin/cbindgen > debian/cbindgen.1
dh_installman -O--buildsystem=cargo
-execute_after_dh_testdir:
+override_dh_testdir:
+ dh_testdir
find . ! -newermt "jan 01, 2000" -exec touch {} +
Bug#1014860: buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u1
Control: retitle -1 buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u2 On 13/07/2022 12:55, Emilio Pozuelo Monfort wrote: Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-llvm-t...@lists.alioth.debian.org This backports LLVM 13 to buster, for Firefox/Thunderbird ESR 102. The changes from the bullseye backport are minimal, debdiff attached. I have already uploaded the package, but let me know if you have any comments. I have noticed a couple of problems: - there's a build-dep that worked for me because of the alternative, but didn't in the buildds. I have addressed that here. - I brought back mips support I have uploaded deb10u2, debdiff attached. Let's see if that works better. Cheers, Emiliodiff -Nru llvm-toolchain-13-13.0.1/debian/changelog llvm-toolchain-13-13.0.1/debian/changelog --- llvm-toolchain-13-13.0.1/debian/changelog 2022-07-06 16:28:45.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/changelog 2022-07-15 11:10:37.0 +0200 @@ -1,3 +1,11 @@ +llvm-toolchain-13 (1:13.0.1-6~deb10u2) buster; urgency=medium + + * Don't build-dep on llvm-spirv, it's not available in buster +and having an alternative doesn't work on the buildds. + * Add support for mips in various places. + + -- Emilio Pozuelo Monfort Fri, 15 Jul 2022 11:10:37 +0200 + llvm-toolchain-13 (1:13.0.1-6~deb10u1) buster; urgency=medium * Non-maintainer upload. diff -Nru llvm-toolchain-13-13.0.1/debian/clang-tools-X.Y.install.in llvm-toolchain-13-13.0.1/debian/clang-tools-X.Y.install.in --- llvm-toolchain-13-13.0.1/debian/clang-tools-X.Y.install.in 2022-06-04 15:29:01.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/clang-tools-X.Y.install.in 2022-07-15 11:10:37.0 +0200 @@ -55,7 +55,7 @@ usr/lib/llvm-@LLVM_VERSION@/libexec/intercept-c++ usr/lib/llvm-@LLVM_VERSION@/libexec/intercept-cc -[!armel !armhf !ppc64el !hurd-any !s390x !powerpc !ppc64 !mipsel !mips64el !sparc64 !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/bin/hwasan_symbolize +[!armel !armhf !ppc64el !hurd-any !s390x !powerpc !ppc64 !mips !mipsel !mips64el !sparc64 !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/clang/@LLVM_VERSION_FULL@/bin/hwasan_symbolize clang/tools/scan-build-@LLVM_VERSION@ usr/share/clang/ clang/tools/scan-view-@LLVM_VERSION@ usr/share/clang/ diff -Nru llvm-toolchain-13-13.0.1/debian/control llvm-toolchain-13-13.0.1/debian/control --- llvm-toolchain-13-13.0.1/debian/control 2022-06-04 15:30:01.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/control 2022-07-15 11:10:37.0 +0200 @@ -14,7 +14,7 @@ libxml2-dev, libjsoncpp-dev, pkg-config, lcov, procps, help2man, zlib1g-dev, -g++-multilib [amd64 i386 kfreebsd-amd64 mips64 mips64el mipsel powerpc ppc64 s390 s390x sparc sparc64 x32], +g++-multilib [amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel powerpc ppc64 s390 s390x sparc sparc64 x32], libjs-mathjax, python3-recommonmark, doxygen, gfortran, ocaml-base [amd64 arm64 armhf ppc64el riscv64 s390x] | ocaml-nox [amd64 arm64 armhf ppc64el riscv64 s390x], @@ -22,12 +22,12 @@ libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x], dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x], libpfm4-dev [linux-any], python3-setuptools, libz3-dev, -llvm-spirv [ amd64 arm64 armel armhf mips64el mipsel ppc64el s390x ] | hello [!i386], +#llvm-spirv [ amd64 arm64 armel armhf mips mips64el mipsel ppc64el s390x ] | hello [!i386], spirv-tools [ linux-any ] | hello [ !i386], -libgrpc++-dev [amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x], -protobuf-compiler-grpc [amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x], -libprotobuf-dev [amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x], -protobuf-compiler [amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] +libgrpc++-dev [amd64 arm64 armel armhf mips mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x], +protobuf-compiler-grpc [amd64 arm64 armel armhf mips mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x], +libprotobuf-dev [amd64 arm64 armel armhf mips mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x], +protobuf-compiler [amd64 arm64 armel armhf mips mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] # "| hello" is for older buster/bionic distros without spirv support Build-Conflicts: oprofile Standards-Version: 4.2.1 @@ -465,7 +465,7 @@ # - lld - Package: lld-13 -Architecture: amd64 arm64 armel armhf i386 mipsel mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 s390 s390x sparc alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32 riscv64 +Architecture: amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el kfreebsd-amd64 kfreebsd-i386 s390 s390x sparc
Bug#1014912: buster-pu: package cargo-mozilla/0.57.0-7~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net Hi, This updates cargo-mozilla in buster. The debdiff against the bullseye update is trivial, I bumped the rustc-mozilla build-deps to avoid a FTBFS if this is built before rustc. Cheers, Emilio diff -Nru cargo-mozilla-0.57.0/debian/changelog cargo-mozilla-0.57.0/debian/changelog --- cargo-mozilla-0.57.0/debian/changelog 2022-07-01 12:25:10.0 +0200 +++ cargo-mozilla-0.57.0/debian/changelog 2022-07-14 12:00:57.0 +0200 @@ -1,3 +1,11 @@ +cargo-mozilla (0.57.0-7~deb10u1) buster; urgency=medium + + * Non-maintainer upload. + * Backport to buster. + * Bump rustc-mozilla build-dep. + + -- Emilio Pozuelo Monfort Thu, 14 Jul 2022 12:00:57 +0200 + cargo-mozilla (0.57.0-7~deb11u1) bullseye; urgency=medium * Non-maintainer upload. diff -Nru cargo-mozilla-0.57.0/debian/control cargo-mozilla-0.57.0/debian/control --- cargo-mozilla-0.57.0/debian/control 2022-07-01 12:25:10.0 +0200 +++ cargo-mozilla-0.57.0/debian/control 2022-07-14 12:00:57.0 +0200 @@ -11,8 +11,8 @@ debhelper (>= 12~), dpkg-dev (>= 1.17.14), cargo:native(>= 0.17.0), - rustc-mozilla:native(>= 1.16), - libstd-rust-mozilla-dev (>= 1.16), + rustc-mozilla:native(>= 1.59), + libstd-rust-mozilla-dev (>= 1.59), pkg-config, bash-completion, python3:native,
Bug#1014909: buster-pu: package rust-cbindgen/0.23.0-1~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net Hi, This updates rust-cbindgen to 0.23 for FF 102. FF/TB are the only users of this package, so that should be fine. The debdiff against bullseye adds a missing build-dep on the new rustc. Cheers, Emilio diff -Nru rust-cbindgen-0.23.0/debian/changelog rust-cbindgen-0.23.0/debian/changelog --- rust-cbindgen-0.23.0/debian/changelog 2022-07-04 10:53:21.0 +0200 +++ rust-cbindgen-0.23.0/debian/changelog 2022-07-14 10:52:44.0 +0200 @@ -1,3 +1,11 @@ +rust-cbindgen (0.23.0-1~deb10u1) buster; urgency=medium + + * Non-maintainer upload. + * Backport to bullseye. + * Bump rustc-mozilla build-deps to 1.59. + + -- Emilio Pozuelo Monfort Thu, 14 Jul 2022 10:52:44 +0200 + rust-cbindgen (0.23.0-1~deb11u1) bullseye; urgency=medium * Non-maintainer upload. diff -Nru rust-cbindgen-0.23.0/debian/control rust-cbindgen-0.23.0/debian/control --- rust-cbindgen-0.23.0/debian/control 2022-06-17 13:33:38.0 +0200 +++ rust-cbindgen-0.23.0/debian/control 2022-07-14 10:52:18.0 +0200 @@ -4,8 +4,8 @@ Build-Depends: debhelper (>= 12), dh-cargo (>= 17), cargo:native, - rustc-mozilla:native, - libstd-rust-mozilla-dev, + rustc-mozilla:native (>= 1.59), + libstd-rust-mozilla-dev (>= 1.59), # librust-clap-3+default-dev (>= 3.1-~~), # librust-heck-0.4+default-dev, # librust-indexmap-1+default-dev,
Bug#1014907: buster-pu: package rustc-mozilla/1.59.0+dfsg1-1~deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net
Hi,
This updates rustc-mozilla in buster, in preparation for Firefox 102.
I'm attaching the debdiff from the bullseye update. The windows target
is disabled because it was already disabled in buster, and is something
we don't really care about for our purpose.
I've uploaded the package already to oldstable-new.
Cheers,
Emilio
diff -ruNp rustc-mozilla-1.59.0+dfsg1/debian/changelog
buster/rustc-mozilla-1.59.0+dfsg1/debian/changelog
--- rustc-mozilla-1.59.0+dfsg1/debian/changelog 2022-07-03 11:51:30.0
+0200
+++ buster/rustc-mozilla-1.59.0+dfsg1/debian/changelog 2022-07-12
00:18:55.0 +0200
@@ -1,3 +1,12 @@
+rustc-mozilla (1.59.0+dfsg1-1~deb10u1) buster; urgency=medium
+
+ * Backport to buster.
+ * Lower debhelper compat to 12. Stop using env variables in debhelper
+install files.
+ * Disable windows target.
+
+ -- Emilio Pozuelo Monfort Tue, 12 Jul 2022 00:18:55 +0200
+
rustc-mozilla (1.59.0+dfsg1-1~deb11u1) bullseye; urgency=medium
* Non-maintainer upload.
diff -ruNp rustc-mozilla-1.59.0+dfsg1/debian/control
buster/rustc-mozilla-1.59.0+dfsg1/debian/control
--- rustc-mozilla-1.59.0+dfsg1/debian/control 2022-06-17 17:51:59.0
+0200
+++ buster/rustc-mozilla-1.59.0+dfsg1/debian/control2022-07-11
16:52:06.0 +0200
@@ -9,7 +9,7 @@ Rules-Requires-Root: no
# :native annotations are to support cross-compiling, see README.Debian
Build-Depends:
debhelper (>= 9),
- debhelper-compat (= 13),
+ debhelper-compat (= 12),
dpkg-dev (>= 1.17.14),
python3:native,
# cargo:native (>= 0.40.0) ,
@@ -17,8 +17,8 @@ Build-Depends:
# rustc:native (<= 1.59.0++),
llvm-13-dev:native,
llvm-13-tools:native,
- gcc-mingw-w64-x86-64-posix:native [amd64] ,
- gcc-mingw-w64-i686-posix:native [i386] ,
+# gcc-mingw-w64-x86-64-posix:native [amd64] ,
+# gcc-mingw-w64-i686-posix:native [i386] ,
libllvm13 (>= 1:13.0.0),
cmake (>= 3.0) | cmake3,
# needed by some vendor crates
@@ -123,34 +123,34 @@ Description: Rust standard libraries - d
needed to compile Rust programs. It may also be installed on a system
of another host architecture, for cross-compiling to this architecture.
-Package: libstd-rust-mozilla-dev-windows
-Section: libdevel
-Architecture: amd64 i386
-Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends:
- gcc-mingw-w64-x86-64-posix [amd64],
- gcc-mingw-w64-i686-posix [i386],
-Conflicts: libstd-rust-dev-windows
-Replaces: libstd-rust-dev-windows
-Build-Profiles:
-Description: Rust standard libraries - development files
- Rust is a curly-brace, block-structured expression language. It
- visually resembles the C language family, but differs significantly
- in syntactic and semantic details. Its design is oriented toward
- concerns of "programming in the large", that is, of creating and
- maintaining boundaries - both abstract and operational - that
- preserve large-system integrity, availability and concurrency.
- .
- It supports a mixture of imperative procedural, concurrent actor,
- object-oriented and pure functional styles. Rust also supports
- generic programming and meta-programming, in both static and dynamic
- styles.
- .
- This package contains the standard Rust libraries including development files,
- needed to cross-compile Rust programs to the *-pc-windows-gnu target
- corresponding to the architecture of this package.
-
+#Package: libstd-rust-mozilla-dev-windows
+#Section: libdevel
+#Architecture: amd64 i386
+#Multi-Arch: same
+#Depends: ${shlibs:Depends}, ${misc:Depends}
+#Recommends:
+# gcc-mingw-w64-x86-64-posix [amd64],
+# gcc-mingw-w64-i686-posix [i386],
+#Conflicts: libstd-rust-dev-windows
+#Replaces: libstd-rust-dev-windows
+#Build-Profiles:
+#Description: Rust standard libraries - development files
+# Rust is a curly-brace, block-structured expression language. It
+# visually resembles the C language family, but differs significantly
+# in syntactic and semantic details. Its design is oriented toward
+# concerns of "programming in the large", that is, of creating and
+# maintaining boundaries - both abstract and operational - that
+# preserve large-system integrity, availability and concurrency.
+# .
+# It supports a mixture of imperative procedural, concurrent actor,
+# object-oriented and pure functional styles. Rust also supports
+# generic programming and meta-programming, in both static and dynamic
+# styles.
+# .
+# This package contains the standard Rust libraries including development
files,
+# needed to cross-compile Rust programs to the *-pc-windows-gnu target
+# corresponding to the architecture of this package.
+#
#Package: libstd-rust-mozilla-dev-wasm32
#Section: libdevel
#Architecture: all
diff -ruNp rustc-mozilla-1.59.0+dfsg1/debian/libstd-rust-mozilla-1.59.install
bu
Bug#1014860: buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u1
On 13/07/2022 12:55, Emilio Pozuelo Monfort wrote: debdiff attached. Now for real (thanks Paul). Cheers, Emiliodiff -Nru llvm-toolchain-13-13.0.1/debian/changelog llvm-toolchain-13-13.0.1/debian/changelog --- llvm-toolchain-13-13.0.1/debian/changelog 2022-06-16 12:00:08.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/changelog 2022-07-06 16:28:45.0 +0200 @@ -1,3 +1,11 @@ +llvm-toolchain-13 (1:13.0.1-6~deb10u1) buster; urgency=medium + + * Non-maintainer upload. + * Backport to buster. + * Don't install libclang grpc proto libs, they are not built in buster. + + -- Emilio Pozuelo Monfort Wed, 06 Jul 2022 16:28:45 +0200 + llvm-toolchain-13 (1:13.0.1-6~deb11u1) bullseye; urgency=medium * Non-maintainer upload. diff -Nru llvm-toolchain-13-13.0.1/debian/libclang-X.Y-dev.install.in llvm-toolchain-13-13.0.1/debian/libclang-X.Y-dev.install.in --- llvm-toolchain-13-13.0.1/debian/libclang-X.Y-dev.install.in 2022-06-04 15:29:01.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/libclang-X.Y-dev.install.in 2022-07-06 16:28:17.0 +0200 @@ -7,8 +7,3 @@ usr/lib/llvm-@LLVM_VERSION@/lib/libclang.so usr/lib/llvm-@LLVM_VERSION@/lib/libclang-@LLVM_VERSION@*.so usr/lib/llvm-@LLVM_VERSION@/lib/libfindAllSymbols.a - -# clangd grpc architectures -[amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] usr/lib/llvm-@LLVM_VERSION@/lib/libRemoteIndexProto.a -[amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] usr/lib/llvm-@LLVM_VERSION@/lib/libRemoteIndexServiceProto.a -[amd64 arm64 armel armhf mips64el mipsel ppc64 ppc64el powerpc riscv64 s390x] usr/lib/llvm-@LLVM_VERSION@/lib/libMonitoringServiceProto.a
Bug#1014860: buster-pu: package llvm-toolchain-13/1:13.0.1-6~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-llvm-t...@lists.alioth.debian.org This backports LLVM 13 to buster, for Firefox/Thunderbird ESR 102. The changes from the bullseye backport are minimal, debdiff attached. I have already uploaded the package, but let me know if you have any comments. Cheers, Emilio
Bug#1014327: bullseye-pu: package cargo-mozilla/0.57.0-7~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net This brings cargo 0.57 into bullseye as src:cargo-mozilla, following the packaging changes done in previous releases (e.g. cargo-mozilla 0.47.0 in buster). This is needed for the upcoming Firefox 102 ESR. I'm attaching a diff from cargo 0.57. Since this is a separate source and binary, it won't affect the rust ecosystem, unless you intentionally install this in place of bin:cargo. Cheers, Emilio diff -ruNp cargo-0.57.0/debian/cargo.bash-completion cargo-mozilla-0.57.0/debian/cargo.bash-completion --- cargo-0.57.0/debian/cargo.bash-completion 2022-03-15 13:09:01.0 +0100 +++ cargo-mozilla-0.57.0/debian/cargo.bash-completion 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -src/etc/cargo.bashcomp.sh cargo diff -ruNp cargo-0.57.0/debian/cargo.dirs cargo-mozilla-0.57.0/debian/cargo.dirs --- cargo-0.57.0/debian/cargo.dirs 2022-03-15 13:09:01.0 +0100 +++ cargo-mozilla-0.57.0/debian/cargo.dirs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -usr/bin diff -ruNp cargo-0.57.0/debian/cargo-doc.docs cargo-mozilla-0.57.0/debian/cargo-doc.docs --- cargo-0.57.0/debian/cargo-doc.docs 2022-03-15 13:09:01.0 +0100 +++ cargo-mozilla-0.57.0/debian/cargo-doc.docs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -target/doc diff -ruNp cargo-0.57.0/debian/cargo.manpages cargo-mozilla-0.57.0/debian/cargo.manpages --- cargo-0.57.0/debian/cargo.manpages 2022-03-15 13:09:01.0 +0100 +++ cargo-mozilla-0.57.0/debian/cargo.manpages 1970-01-01 01:00:00.0 +0100 @@ -1,2 +0,0 @@ -src/etc/man/cargo-*.1 -src/etc/man/cargo.1 diff -ruNp cargo-0.57.0/debian/cargo-mozilla.bash-completion cargo-mozilla-0.57.0/debian/cargo-mozilla.bash-completion --- cargo-0.57.0/debian/cargo-mozilla.bash-completion 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.57.0/debian/cargo-mozilla.bash-completion 2022-03-15 13:09:01.0 +0100 @@ -0,0 +1 @@ +src/etc/cargo.bashcomp.sh cargo diff -ruNp cargo-0.57.0/debian/cargo-mozilla.dirs cargo-mozilla-0.57.0/debian/cargo-mozilla.dirs --- cargo-0.57.0/debian/cargo-mozilla.dirs 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.57.0/debian/cargo-mozilla.dirs 2022-03-15 13:09:01.0 +0100 @@ -0,0 +1 @@ +usr/bin diff -ruNp cargo-0.57.0/debian/cargo-mozilla-doc.docs cargo-mozilla-0.57.0/debian/cargo-mozilla-doc.docs --- cargo-0.57.0/debian/cargo-mozilla-doc.docs 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.57.0/debian/cargo-mozilla-doc.docs 2022-03-15 13:09:01.0 +0100 @@ -0,0 +1 @@ +target/doc diff -ruNp cargo-0.57.0/debian/cargo-mozilla.manpages cargo-mozilla-0.57.0/debian/cargo-mozilla.manpages --- cargo-0.57.0/debian/cargo-mozilla.manpages 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.57.0/debian/cargo-mozilla.manpages 2022-03-15 13:09:01.0 +0100 @@ -0,0 +1,2 @@ +src/etc/man/cargo-*.1 +src/etc/man/cargo.1 diff -ruNp cargo-0.57.0/debian/changelog cargo-mozilla-0.57.0/debian/changelog --- cargo-0.57.0/debian/changelog 2022-05-02 22:57:46.0 +0200 +++ cargo-mozilla-0.57.0/debian/changelog 2022-07-03 21:40:34.725134208 +0200 @@ -1,3 +1,15 @@ +cargo-mozilla (0.57.0-7~deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Backport to bullseye as cargo-mozilla. + * Build-dep on rustc-mozilla. + * Don't build the doc package. + * Vendor libgit2 1.3.0, the system one is too old. + * Build-dep on libpcre3-dev, for libgit2. + * Disable build::close_output_during_drain test as it hangs in bullseye. + + -- Emilio Pozuelo Monfort Fri, 01 Jul 2022 12:25:10 +0200 + cargo (0.57.0-7) unstable; urgency=medium * Team upload. diff -ruNp cargo-0.57.0/debian/control cargo-mozilla-0.57.0/debian/control --- cargo-0.57.0/debian/control 2022-05-02 22:57:07.0 +0200 +++ cargo-mozilla-0.57.0/debian/control 2022-07-02 20:43:20.894722653 +0200 @@ -1,4 +1,4 @@ -Source: cargo +Source: cargo-mozilla Section: devel Maintainer: Rust Maintainers Uploaders: Luca Bruno , @@ -11,16 +11,17 @@ Build-Depends: debhelper (>= 12~), dpkg-dev (>= 1.17.14), cargo:native(>= 0.17.0), - rustc:native(>= 1.16), - libstd-rust-dev (>= 1.16), + rustc-mozilla:native(>= 1.16), + libstd-rust-mozilla-dev (>= 1.16), pkg-config, bash-completion, python3:native, libcurl4-gnutls-dev | libcurl4-openssl-dev, libssh2-1-dev, - libgit2-dev (>= 1.3.0), - libgit2-dev (<< 1.4~~), +# libgit2-dev (>= 1.3.0), +# libgit2-dev (<< 1.4~~), libhttp-parser-dev, + libpcre3-dev, libssl-dev, zlib1g-dev, git @@ -29,7 +30,7 @@ Standards-Version: 4.2.1 Vcs-Git: https://salsa.debian.org/rust-team/cargo.git Vcs-Browser: https://salsa.debian.org/rust-team/cargo -Package: cargo +Package: cargo-mozilla Architecture: any Multi-Arch: allowed Dep
Bug#1014326: bullseye-pu: package rust-cbindgen/0.23.0-1~deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net
Hi,
This is an update for rust-cbindgen, needed to build Firefox/Thunderbird.
We need 0.23 to build FF/TB 102. This update vendors the dependencies (as
we have done in the past with other versions, e.g. on buster/stretch).
I'm attaching a diff of the debian dir excluding the vendor dir.
Thanks,
Emilio
diff -ruNp rust-cbindgen-0.20.0/debian/changelog
rust-cbindgen-0.23.0/debian/changelog
--- rust-cbindgen-0.20.0/debian/changelog 2021-12-02 12:49:31.0
+0100
+++ rust-cbindgen-0.23.0/debian/changelog 2022-07-04 10:59:17.608005927
+0200
@@ -1,3 +1,20 @@
+rust-cbindgen (0.23.0-1~deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport to bullseye.
+ * Vendor dependencies, they are not available in bullseye.
+ * Only build the cbindgen binary.
+ * Lower dh-cargo build-dep.
+ * Build with rust-mozilla.
+
+ -- Emilio Pozuelo Monfort Mon, 04 Jul 2022 10:53:21 +0200
+
+rust-cbindgen (0.23.0-1) unstable; urgency=medium
+
+ * Package cbindgen 0.23.0 from crates.io using debcargo 2.5.0
+
+ -- Sylvestre Ledru Fri, 03 Jun 2022 11:20:37 +0200
+
rust-cbindgen (0.20.0-1~deb11u1) bullseye; urgency=medium
* Non-maintainer upload.
diff -ruNp rust-cbindgen-0.20.0/debian/control
rust-cbindgen-0.23.0/debian/control
--- rust-cbindgen-0.20.0/debian/control 2021-08-22 14:26:42.0 +0200
+++ rust-cbindgen-0.23.0/debian/control 2022-06-17 13:33:38.349338635 +0200
@@ -2,27 +2,27 @@ Source: rust-cbindgen
Section: utils
Priority: optional
Build-Depends: debhelper (>= 12),
- dh-cargo (>= 24),
+ dh-cargo (>= 17),
cargo:native,
- rustc:native,
- libstd-rust-dev,
- librust-clap-2+default-dev,
- librust-heck-0.3+default-dev,
- librust-indexmap-1+default-dev,
- librust-log-0.4+default-dev,
- librust-proc-macro2-1+default-dev,
- librust-quote-1+default-dev,
- librust-serde-1+derive-dev (>= 1.0.103-~~),
- librust-serde-json-1+default-dev,
- librust-syn-1+clone-impls-dev (>= 1.0.3-~~),
- librust-syn-1+extra-traits-dev (>= 1.0.3-~~),
- librust-syn-1+full-dev (>= 1.0.3-~~),
- librust-syn-1+parsing-dev (>= 1.0.3-~~),
- librust-syn-1+printing-dev (>= 1.0.3-~~),
- librust-tempfile-3+default-dev,
- librust-toml-0.5+default-dev,
+ rustc-mozilla:native,
+ libstd-rust-mozilla-dev,
+# librust-clap-3+default-dev (>= 3.1-~~),
+# librust-heck-0.4+default-dev,
+# librust-indexmap-1+default-dev,
+# librust-log-0.4+default-dev,
+# librust-proc-macro2-1+default-dev,
+# librust-quote-1+default-dev,
+# librust-serde-1+derive-dev (>= 1.0.103-~~),
+# librust-serde-json-1+default-dev,
+# librust-syn-1+clone-impls-dev (>= 1.0.88-~~),
+# librust-syn-1+extra-traits-dev (>= 1.0.88-~~),
+# librust-syn-1+full-dev (>= 1.0.88-~~),
+# librust-syn-1+parsing-dev (>= 1.0.88-~~),
+# librust-syn-1+printing-dev (>= 1.0.88-~~),
+# librust-tempfile-3+default-dev,
+# librust-toml-0.5+default-dev,
help2man,
- librust-serial-test-dev,
+# librust-serial-test-dev,
cython3
Maintainer: Debian Rust Maintainers
Uploaders:
@@ -32,55 +32,55 @@ Vcs-Git: https://salsa.debian.org/rust-t
Vcs-Browser:
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/cbindgen
Rules-Requires-Root: no
-Package: librust-cbindgen-dev
-Architecture: any
-Multi-Arch: same
-Depends:
- ${misc:Depends},
- librust-heck-0.3+default-dev,
- librust-indexmap-1+default-dev,
- librust-log-0.4+default-dev,
- librust-proc-macro2-1+default-dev,
- librust-quote-1+default-dev,
- librust-serde-1+derive-dev (>= 1.0.103-~~),
- librust-serde-json-1+default-dev,
- librust-syn-1+clone-impls-dev (>= 1.0.3-~~),
- librust-syn-1+extra-traits-dev (>= 1.0.3-~~),
- librust-syn-1+full-dev (>= 1.0.3-~~),
- librust-syn-1+parsing-dev (>= 1.0.3-~~),
- librust-syn-1+printing-dev (>= 1.0.3-~~),
- librust-tempfile-3+default-dev,
- librust-toml-0.5+default-dev
-Recommends:
- librust-cbindgen+clap-dev (= ${binary:Version})
-Provides:
- librust-cbindgen-0-dev (= ${binary:Version}),
- librust-cbindgen-0.20-dev (= ${binary:Version}),
- librust-cbindgen-0.20.0-dev (= ${binary:Version})
-Description: Generating C bindings to Rust code - Rust source code
- This package contains the source for the Rust cbindgen crate, packaged by
- debcargo for use with cargo and dh-cargo.
-
-Package: librust-cbindgen+clap-dev
-Architecture: any
-Multi-Arch: same
-Depends:
- ${misc:Depends},
- librust-cbindgen-dev (= ${binary:Version}),
- librust-clap-2+default-dev
-Provides:
- librust-cbindgen+default-dev (= ${binary:Version}),
- librust-cbindgen-0+clap-dev (= ${binary:Version}),
- librust-cbindgen-0+default-dev (= ${binary:Version}),
- librust-cbindgen-0.20+clap-dev (= ${binary:Version}),
- librust-cbindgen-0.20+default-dev (= ${binary:Version}),
- librust-cbindgen-0.20.0+clap-dev (= ${binary:Version}),
- librust-cbindgen-0.20.0+default-dev
Bug#1014308: bullseye-pu: package llvm-toolchain-13/1:13.0.1-6~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-llvm-t...@lists.alioth.debian.org Hi, This is the first of a series of backports needed for the upcoming Firefox/Thunderbird 102 ESR. This backport is pretty straightforward, and is a requirement for the new rustc. I have already uploaded the package, but if you have any comments do let me know. Thanks, Emilio diff -Nru llvm-toolchain-13-13.0.1/debian/changelog llvm-toolchain-13-13.0.1/debian/changelog --- llvm-toolchain-13-13.0.1/debian/changelog 2022-06-04 15:30:38.0 +0200 +++ llvm-toolchain-13-13.0.1/debian/changelog 2022-06-16 12:00:08.0 +0200 @@ -1,3 +1,10 @@ +llvm-toolchain-13 (1:13.0.1-6~deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Backport to bullseye. + + -- Emilio Pozuelo Monfort Thu, 16 Jun 2022 12:00:08 +0200 + llvm-toolchain-13 (1:13.0.1-6) unstable; urgency=medium [ John Paul Adrian Glaubitz ]
Bug#1013178: transition: ceres-solver
Control: tags -1 confirmed On 18/06/2022 15:29, Francois Mazen wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: franc...@mzf.fr Dear release team, I and Pierre Gruet (pgt@d.o) would like to transition ceres-solver to the new SOVERSION (3). The upstream changed the SOVERSION of the package without changing the major version number (2.1.0). That's why we missed this ABI change, and Pierre reverted the upload by uploading a new package with the +really suffix (2.1.0+really2.0.0). Upstream does not follow semantic versioning and confirmed that this behavior is intentional [1]. So, a transition process is needed for the Debian package to handle this SOVERSION update. This transition clashes with the ongoing onetbb through openturns, however those two have already migrated to testing so that shouldn't be a blocker. All reverse dependencies are building fine at least on amd64 [2]. That link doesn't tell me if the rdeps build against the new SONAME. Have you tested that? If so, go ahead. Cheers, Emilio
Bug#1012533: ftp.debian.org: Please consider a firmware component for bookworm
Hi Ansgar, On 11/06/2022 19:08, Ansgar wrote: Hi, On Wed, 2022-06-08 at 21:48 +0200, Jonathan Carter wrote: Recently, Steve McIntyre initiated a discussion[1] on debian-devel on the future of firmware in Debian, and how we want to address it as a project. [ Request to add non-free-firmware ] Okay, I'm fine with adding non-free-firmware. I assume the other members of the ftp team are also still fine with this. Should we add it to testing/unstable/experimental in one go? Or does the release team prefer to wait with adding it to testing? We can always revert the addition temporarily if we find bugs that take a while to fix. I did a quick grep in britney and it may be ok as is, so I'd say go ahead with it and if things break we can look at them. The transition tracker & ben may need the new component added in its config files, and the release-tools will need extra changes, though that shouldn't block those as that is mostly used for (old)stable. Cheers, Emilio
Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1
On 13/06/2022 19:12, Adam D. Barratt wrote: On Mon, 2022-06-13 at 10:55 +0800, Shengjing Zhu wrote: X-Debbugs-CC: siret...@debian.org, t...@security.debian.org Hi, On Sun, Jun 12, 2022 at 05:33:48PM -0400, Reinhard Tartler wrote: diff -Nru runc-1.0.0~rc93+ds1/debian/changelog runc- 1.0.0~rc93+ds1/debian/changelog --- runc-1.0.0~rc93+ds1/debian/changelog2022-06-12 14:49:36.0 -0400 +++ runc-1.0.0~rc93+ds1/debian/changelog2021-05-19 14:46:14.0 -0400 @@ -1,10 +1,3 @@ -runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium - - * Team upload. - * backport upstream patch: Honor seccomp defaultErrnoRet, Closes: #1012030 - - -- Reinhard Tartler Sun, 12 Jun 2022 14:49:36 -0400 - Could you include the patch for CVE-2022-29162? https://security-tracker.debian.org/tracker/CVE-2022-29162 If you don't have time, I can work on this later in this week. The Security Tracker says it's not fixed in unstable - is that correct? If so, that needs addressing first before it can be considered for p-u. The tracker is corrected now, the issue was fixed in 1.1.2. Cheers, Emilio
Bug#1006932: fontconfig: new upstream version 2.13.96 available
On 08/03/2022 14:22, Vincent Lefevre wrote: Source: fontconfig Version: 2.13.1-4.2 Severity: wishlist A new upstream version 2.13.96 is available. Upstream says that "2.13.96 has some improvements around mutex lock", so that it might fix bug 1006720 (though I could not find the cause and could not reproduce the issue yet). Note that unless I have new information, bug 1006720 could be closed at the same time as a new release, even though the code hasn't changed much. Isn't that an 'unstable' release? Ideally we would have a 2.14 release. Although I just went to the git repo and saw 2.14 got released 6 days ago. So yeah, I'll prepare an update to that. Cheers, Emilio
Bug#1006182: buster-pu: package qtbase-opensource-src/5.11.3+dfsg1-1+deb10u5
On 18/03/2022 12:28, Adam D. Barratt wrote: On Fri, 2022-03-18 at 12:24 +0100, Emilio Pozuelo Monfort wrote: On 18/03/2022 11:48, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sun, 2022-02-20 at 21:13 +0300, Dmitry Shachnev wrote: One of our users requested a new upload to fix this bug: https://bugs.debian.org/1001082. [ Impact ] This bug causes various applications to segfault on exit. Please go ahead; thanks. There are a couple of CVEs open (one of them a no-dsa, DOS one). Perhaps they can be addressed in this update as well, provided the patches (which seem rather small) are fine for the buster version? I know the deadline for the point release is just around the corner, so if there's not enough time to address those then that'd be alright. Well, we'd need to see a diff. :-) Heh sure. This was more meant for Dmitry... (Was Dmitry intentionally not CCed on your mail?) My bad, I hit reply rather than reply to all... Dmitry, see my comments above regarding the couple CVEs open in buster, in case they can be included in this update. Cheers, Emilio
Bug#1006182: buster-pu: package qtbase-opensource-src/5.11.3+dfsg1-1+deb10u5
On 18/03/2022 11:48, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sun, 2022-02-20 at 21:13 +0300, Dmitry Shachnev wrote: One of our users requested a new upload to fix this bug: https://bugs.debian.org/1001082. [ Impact ] This bug causes various applications to segfault on exit. Please go ahead; thanks. There are a couple of CVEs open (one of them a no-dsa, DOS one). Perhaps they can be addressed in this update as well, provided the patches (which seem rather small) are fine for the buster version? I know the deadline for the point release is just around the corner, so if there's not enough time to address those then that'd be alright. Cheers, Emilio
Bug#1007703: spip: recommend php-gd
Package: spip Version: 4.0.5-1 Severity: normal Hi, spip uses the GD module for image processing (see ecrire/inc/filtres_images_lib_mini.php). Thus, php-gd should be recommended or depended on so that basic functionality works out of the box. Cheers, Emilio
Bug#987266: preinst check for kernel release > 255 may no longer be needed
On 04/03/2022 09:50, Aurelien Jarno wrote: On 2022-03-04 09:19, Emilio Pozuelo Monfort wrote: Hi, On Sun, 26 Sep 2021 09:57:02 +0200 Salvatore Bonaccorso wrote: Hi Aurelien, On Tue, Apr 20, 2021 at 06:36:33PM +0200, Andras Korn wrote: Package: libc6 Version: 2.31-11 Severity: normal Hi, due to https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f (a commit from 2004) the preinst script for glibc checks whether the "z" in the "x.y.z" of the kernel version is less than 255. If yes, the package refuses to install. I hit this problem on a box with a custom 4.9.266 kernel. Based on this lkml thread: https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/, the check is no longer needed because the kernel caps the version code it reports to 255, even if uname prints a higher number. Of course, you could conceivably still hit the problem with earlier kernels, so I suppose the logic of the check should be modified, not removed entirely, to be technically correct. If forced at gunpoint to make a guess, I would guess, though, that removing the check would have very little actual impact; it also doesn't protect the user from installing a kernel with an unsupported version number after having installed glibc. Prompted by https://lore.kernel.org/stable/yvaholtsb0nk0...@kroah.com/T/#t and given this was addressed with https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900 is this something we should do consider as well for the older releases where it is not acutally needed for people compiling their own custom kernels? Another stretch user brought this up [1]. I suppose there are and as time passes (with current stable kernel versions getting higher) there will be more users affected by this in buster and bullseye. Have you further considered including this fix in a proposed-update? Yep I have submitted #1005906 for bullseye, and I have committed the fix to the buster branch, but not yet submitted the bug. I was wondering what docker had to do with all this, until I realized you meant #1005949 :) Stretch is going to be more complicated as we still support 2.6.32 kernels, which means the third version level actually still makes sense. I'm surprised we support that. However in any case we wouldn't need to backport [1], we could just backport [2] and support both 2.6.32 as well as e.g. 4.14.264. Wouldn't that work? Cheers, Emilio [1] https://salsa.debian.org/glibc-team/glibc/-/commit/5452b62ded81132ebedf3db82577de5277479b27 [2] https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900
Bug#987266: preinst check for kernel release > 255 may no longer be needed
Hi, On Sun, 26 Sep 2021 09:57:02 +0200 Salvatore Bonaccorso wrote: Hi Aurelien, On Tue, Apr 20, 2021 at 06:36:33PM +0200, Andras Korn wrote: > Package: libc6 > Version: 2.31-11 > Severity: normal > > Hi, > > due to > https://salsa.debian.org/glibc-team/glibc/-/commit/6ddfa57577af0d96df9ddd7be401f5ce9a9bcc0f > (a commit from 2004) the preinst script for glibc checks whether the > "z" in the "x.y.z" of the kernel version is less than 255. If yes, > the package refuses to install. > > I hit this problem on a box with a custom 4.9.266 kernel. > > Based on this lkml thread: > https://lore.kernel.org/lkml/7pR0YCctzN9phpuEChlL7_SS6auHOM80bZBcGBTZPuMkc6XjKw7HUXf9vZUPi-IaV2gTtsRVXgywQbja8xpzjGRDGWJsVYSGQN5sNuX1yaQ=@protonmail.com/T/, > the check is no longer needed because the kernel caps the version > code it reports to 255, even if uname prints a higher number. > > Of course, you could conceivably still hit the problem with earlier > kernels, so I suppose the logic of the check should be modified, not > removed entirely, to be technically correct. > > If forced at gunpoint to make a guess, I would guess, though, that > removing the check would have very little actual impact; it also > doesn't protect the user from installing a kernel with an > unsupported version number after having installed glibc. Prompted by https://lore.kernel.org/stable/yvaholtsb0nk0...@kroah.com/T/#t and given this was addressed with https://salsa.debian.org/glibc-team/glibc/-/commit/b3c76cf1cd0c8b6e4844c6362a45143c136a2900 is this something we should do consider as well for the older releases where it is not acutally needed for people compiling their own custom kernels? Another stretch user brought this up [1]. I suppose there are and as time passes (with current stable kernel versions getting higher) there will be more users affected by this in buster and bullseye. Have you further considered including this fix in a proposed-update? Cheers, Emilio [1] https://lists.debian.org/debian-lts/2022/03/msg2.html
Bug#1005907: Info received (Bug#1005907: closed by Emilio Pozuelo Monfort (Re: Bug#1005907: xdg-utils: "man open" gives the manpage of "xdg-open"))
On 18/02/2022 12:40, Dr. Nikolaus Klepp wrote: So you agree this happened out of pure fun and the lust to break things. Well, ok, that's surely a worthwile and well justified argument. Thank you. I'm amazed that's what you understood from my message. It's certainly not what I wrote, but if you can't argue what the problem is I can't really help. I have wasted too much time already here, so this is my last email. If for whatever reason you refuse to specify the section when calling man open, I'm sure you can remove (e.g. dpkg-divert) open.1.gz. Have fun, Emilio
Bug#1005907: Info received (Bug#1005907: closed by Emilio Pozuelo Monfort (Re: Bug#1005907: xdg-utils: "man open" gives the manpage of "xdg-open"))
On 18/02/2022 11:38, Dr. Nikolaus Klepp wrote: Let me rephrase this: Debian introduced the erratic behaviour just recently: xdg-utils (1.1.3-3) unstable; urgency=medium [...] [ Nicholas Guriev ] * Link to /usr/bin/open through alternatives mechanism. LP: #342584. What justifies this breakage? Just out of pure fun? What's broken about that? That `man open` doesn't open open.2 ? Are you seriously calling that breakage? And fwiw it was discussed in debian-devel a while ago and coordinated with other package maintainers. Cheers, Emilio
Bug#1005907: closed by Emilio Pozuelo Monfort (Re: Bug#1005907: xdg-utils: "man open" gives the manpage of "xdg-open")
On 17/02/2022 14:27, Nikolaus Klepp wrote: "man open" did give the the mapage of "open" sonce the beginning of time - it eve did last year. Now it does not, but "man open" goves the manpage og "xdg-open". Is this expected? Why? You could enlighten me with your view of how the manual system should work to justify this kind of brakage. There's no breakage here. There's a new command 'open' in /usr/bin/, handled through alternatives in Debian, with xdg-open being one of the alternatives (and the default in your system). Because of that, there's also a new manpage in section 1 for open, handled by alternatives as well. Thus man will prefer the manpage in section 1 to the one in section 2 if you don't specify a section. There's really no bug here. It's really no different to `man printf` giving you the manual for /usr/bin/printf rather than the one for printf(). Cheers, Emilio
Bug#1005907: closed by Emilio Pozuelo Monfort (Re: Bug#1005907: xdg-utils: "man open" gives the manpage of "xdg-open")
On 17/02/2022 11:21, Nikolaus Klepp wrote: Could it be that you do not understand the problem? Sure, it could be. It could also be that you didn't describe it properly, or even that you don't understand how the manual system works. Cheers, Emilio
Bug#1003085: small transition: libportal 0.5
On 03/01/2022 20:19, Simon McVittie wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I'd like to upgrade libportal from 0.4 (currently in testing) to 0.5 (in experimental). It currently only has two rdeps: * xdg-desktop-portal only uses it for tests, and can be binNMU'd * gnome-builder needs a sourceful upload, which is on its way to experimental Go ahead. Cheers, Emilio
Bug#1001749: rust-cbindgen 0.20.0-1~deb10u1 flagged for acceptance
Hi,
As discussed on irc, I have just uploaded a new revision fixing a problem with
some file timestamps that caused an autoreject on the binary packages. It was
caused by the new version using some debhelper features not supported on buster.
Debdiff attached.
Cheers,
Emilio
diff -Nru rust-cbindgen-0.20.0/debian/changelog
rust-cbindgen-0.20.0/debian/changelog
--- rust-cbindgen-0.20.0/debian/changelog 2021-12-15 10:16:03.0
+0100
+++ rust-cbindgen-0.20.0/debian/changelog 2021-12-21 13:04:55.0
+0100
@@ -1,3 +1,12 @@
+rust-cbindgen (0.20.0-1~deb10u2) buster; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix file timestamps from orig tarball by using a supported debhelper
+target in buster (execute_after_dh_* is not supported in dh 12.1).
+ * debian/copyright: rename license paragraph to please lintian.
+
+ -- Emilio Pozuelo Monfort Tue, 21 Dec 2021 13:04:55 +0100
+
rust-cbindgen (0.20.0-1~deb10u1) buster; urgency=medium
* Non-maintainer upload.
diff -Nru rust-cbindgen-0.20.0/debian/copyright
rust-cbindgen-0.20.0/debian/copyright
--- rust-cbindgen-0.20.0/debian/copyright 2021-12-15 10:02:31.0
+0100
+++ rust-cbindgen-0.20.0/debian/copyright 2021-12-21 13:04:55.0
+0100
@@ -26,7 +26,7 @@
License: MPL-2.0
Debian systems provide the MPL 2.0 in /usr/share/common-licenses/MPL-2.0
-License: Apache
+License: Apache-2.0
Debian systems provide the Apache 2.0 license in
/usr/share/common-licenses/Apache-2.0
diff -Nru rust-cbindgen-0.20.0/debian/rules rust-cbindgen-0.20.0/debian/rules
--- rust-cbindgen-0.20.0/debian/rules 2021-12-03 13:13:43.0 +0100
+++ rust-cbindgen-0.20.0/debian/rules 2021-12-21 13:03:30.0 +0100
@@ -17,5 +17,6 @@
help2man debian/cbindgen/usr/bin/cbindgen > debian/cbindgen.1
dh_installman -O--buildsystem=cargo
-execute_after_dh_testdir:
+override_dh_testdir:
+ dh_testdir
find . ! -newermt "jan 01, 2000" -exec touch {} +
Bug#1001752: buster-pu: package cargo-mozilla/0.47.0-3~deb10u1
On 15/12/2021 20:09, Adam D. Barratt wrote: Control: tags -1 + confirmed On Wed, 2021-12-15 at 11:38 +0100, Emilio Pozuelo Monfort wrote: This update to cargo (with a renamed name to avoid disruption in the rust/cargo ecosystem) is needed by the firefox / thunderbird updates. It's a backport of the version in bullseye, which is enough for our purposes. I've had to embed a newer version of libgit2, just like we've done in previous cargo updates for buster and stretch. This time I've used the tarball from a debian upload so that it's dfsg and easy to verify. I've used this to build and test firefox ESR 91.3 on amd64. Please go ahead, thanks. binary-full upload done as this needs to go through NEW. Thanks, Emilio
Bug#1001692: bullseye-pu: package rust-cbindgen/0.17.0-4
On 15/12/2021 20:16, Adam D. Barratt wrote: Please go ahead, thanks. Uploaded. Thanks, Emilio
Bug#1001752: buster-pu: package cargo-mozilla/0.47.0-3~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net, team+pkg-mozi...@tracker.debian.org Hi, This update to cargo (with a renamed name to avoid disruption in the rust/cargo ecosystem) is needed by the firefox / thunderbird updates. It's a backport of the version in bullseye, which is enough for our purposes. I've had to embed a newer version of libgit2, just like we've done in previous cargo updates for buster and stretch. This time I've used the tarball from a debian upload so that it's dfsg and easy to verify. I've used this to build and test firefox ESR 91.3 on amd64. Cheers, Emilio diff -Nru cargo-0.47.0/debian/cargo.bash-completion cargo-mozilla-0.47.0/debian/cargo.bash-completion --- cargo-0.47.0/debian/cargo.bash-completion 2019-01-24 05:34:05.0 +0100 +++ cargo-mozilla-0.47.0/debian/cargo.bash-completion 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -src/etc/cargo.bashcomp.sh cargo diff -Nru cargo-0.47.0/debian/cargo.dirs cargo-mozilla-0.47.0/debian/cargo.dirs --- cargo-0.47.0/debian/cargo.dirs 2018-11-04 12:47:23.0 +0100 +++ cargo-mozilla-0.47.0/debian/cargo.dirs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -usr/bin diff -Nru cargo-0.47.0/debian/cargo-doc.docs cargo-mozilla-0.47.0/debian/cargo-doc.docs --- cargo-0.47.0/debian/cargo-doc.docs 2018-11-04 12:47:23.0 +0100 +++ cargo-mozilla-0.47.0/debian/cargo-doc.docs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -target/doc diff -Nru cargo-0.47.0/debian/cargo.manpages cargo-mozilla-0.47.0/debian/cargo.manpages --- cargo-0.47.0/debian/cargo.manpages 2018-11-04 12:47:23.0 +0100 +++ cargo-mozilla-0.47.0/debian/cargo.manpages 1970-01-01 01:00:00.0 +0100 @@ -1,2 +0,0 @@ -src/etc/man/cargo-*.1 -src/etc/man/cargo.1 diff -Nru cargo-0.47.0/debian/cargo-mozilla.bash-completion cargo-mozilla-0.47.0/debian/cargo-mozilla.bash-completion --- cargo-0.47.0/debian/cargo-mozilla.bash-completion 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.47.0/debian/cargo-mozilla.bash-completion 2019-01-24 05:34:05.0 +0100 @@ -0,0 +1 @@ +src/etc/cargo.bashcomp.sh cargo diff -Nru cargo-0.47.0/debian/cargo-mozilla.dirs cargo-mozilla-0.47.0/debian/cargo-mozilla.dirs --- cargo-0.47.0/debian/cargo-mozilla.dirs 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.47.0/debian/cargo-mozilla.dirs 2018-11-04 12:47:23.0 +0100 @@ -0,0 +1 @@ +usr/bin diff -Nru cargo-0.47.0/debian/cargo-mozilla-doc.docs cargo-mozilla-0.47.0/debian/cargo-mozilla-doc.docs --- cargo-0.47.0/debian/cargo-mozilla-doc.docs 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.47.0/debian/cargo-mozilla-doc.docs 2018-11-04 12:47:23.0 +0100 @@ -0,0 +1 @@ +target/doc diff -Nru cargo-0.47.0/debian/cargo-mozilla.manpages cargo-mozilla-0.47.0/debian/cargo-mozilla.manpages --- cargo-0.47.0/debian/cargo-mozilla.manpages 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.47.0/debian/cargo-mozilla.manpages 2018-11-04 12:47:23.0 +0100 @@ -0,0 +1,2 @@ +src/etc/man/cargo-*.1 +src/etc/man/cargo.1 diff -Nru cargo-0.47.0/debian/changelog cargo-mozilla-0.47.0/debian/changelog --- cargo-0.47.0/debian/changelog 2020-12-08 02:43:58.0 +0100 +++ cargo-mozilla-0.47.0/debian/changelog 2021-12-14 13:46:50.0 +0100 @@ -1,3 +1,16 @@ +cargo-mozilla (0.47.0-3~deb10u1) buster; urgency=medium + + * Non-maintainer upload. + * Backport to buster. + * Vendor libgit2 1.0.1, the system one is too old. + * Build-dep on rustc-mozilla. + * Build-dep on libpcre3-dev, for libgit2. + * Fix tests that now have execution time in the output. + * Rename to cargo-mozilla to avoid disruption in the rustc/cargo ecosystem, +and don't build the doc package. + + -- Emilio Pozuelo Monfort Tue, 14 Dec 2021 13:46:50 +0100 + cargo (0.47.0-3) unstable; urgency=medium * Disable close_output test for now, it is flaky. This is a test problem not diff -Nru cargo-0.47.0/debian/control cargo-mozilla-0.47.0/debian/control --- cargo-0.47.0/debian/control 2020-12-06 13:32:13.0 +0100 +++ cargo-mozilla-0.47.0/debian/control 2021-12-14 13:46:50.0 +0100 @@ -1,4 +1,4 @@ -Source: cargo +Source: cargo-mozilla Section: devel Maintainer: Rust Maintainers Uploaders: Luca Bruno , @@ -10,16 +10,17 @@ Build-Depends: debhelper (>= 12~), dpkg-dev (>= 1.17.14), cargo:native(>= 0.17.0), - rustc:native(>= 1.16), - libstd-rust-dev (>= 1.16), + rustc-mozilla:native(>= 1.16), + libstd-rust-mozilla-dev (>= 1.16), pkg-config, cmake, bash-completion, python3:native, libcurl4-gnutls-dev | libcurl4-openssl-dev, libssh2-1-dev, -
Bug#1001692: bullseye-pu: package rust-cbindgen/0.17.0-4
On 14/12/2021 13:36, Emilio Pozuelo Monfort wrote: Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net Hi, This is an update of cbindgen to 0.20.0, as required by firefox and thunderbird ESR 91 updates. Since cbindgen is only used by those two packages, the risk of the update is minimal. For bullseye, we can just backport the version from sid. I'm attaching a sid -> bullseye-pu debdiff, obviously one from the bullseye version is significantly larger, but I don't think it's too useful here. However if you'd like to take a look at it let me know. Now with the diff. Cheers, Emilio diff -Nru rust-cbindgen-0.20.0/debian/changelog rust-cbindgen-0.20.0/debian/changelog --- rust-cbindgen-0.20.0/debian/changelog 2021-08-22 14:26:42.0 +0200 +++ rust-cbindgen-0.20.0/debian/changelog 2021-12-02 12:49:31.0 +0100 @@ -1,3 +1,10 @@ +rust-cbindgen (0.20.0-1~deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Backport to bullseye. + + -- Emilio Pozuelo Monfort Thu, 02 Dec 2021 12:49:31 +0100 + rust-cbindgen (0.20.0-1) unstable; urgency=medium * Package cbindgen 0.20.0 from crates.io using debcargo 2.4.4-alpha.0
Bug#1001692: bullseye-pu: package rust-cbindgen/0.17.0-4
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net Hi, This is an update of cbindgen to 0.20.0, as required by firefox and thunderbird ESR 91 updates. Since cbindgen is only used by those two packages, the risk of the update is minimal. For bullseye, we can just backport the version from sid. I'm attaching a sid -> bullseye-pu debdiff, obviously one from the bullseye version is significantly larger, but I don't think it's too useful here. However if you'd like to take a look at it let me know. Cheers, Emilio
Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1
On 12/12/2021 22:39, Mike Hommey wrote: On Sat, Dec 11, 2021 at 05:04:17PM -0500, Roberto C. Sánchez wrote: On Sun, Dec 12, 2021 at 06:34:01AM +0900, Mike Hommey wrote: On Sat, Dec 11, 2021 at 01:54:21PM +, Adam D. Barratt wrote: On Tue, 2021-11-30 at 13:36 -0500, Roberto C.Sánchez wrote: On Tue, Nov 30, 2021 at 06:00:57PM +, Adam D. Barratt wrote: On Tue, 2021-11-30 at 09:37 -0500, Roberto C.Sánchez wrote: If there are no objections, I will proceed with uploading within the next 24 hours. I'd like to ensure that the new FF/TB make it into the next point release if at all possible and that work is currently blocked by the need for the updated rustc. I was assuming the plan was for the Firefox and Thunderbird updates to be released via the security archive. That's certainly how basically every other update to both packages occurs. Quite right. I conflated the fact that LLVM and rustc are not going in via security update. Apologies for the confusion. As a quick follow-up to this, with the 11.2 point release being next weekend, and thus the p-u freeze this weekend, I note that the rustc- mozilla upload is not yet in NEW, so we're starting to get quite close timing wise. Relatedly, what's the plan for cargo in buster? Firefox ESR needs at least 0.47, bullseye has 0.47, but buster has 0.43.1. Emilio is working on that. There were some tweaks needed to the rustc-mozilla packages I prepared in order to support his work. As of this morning he identified some small additional tweaks, but he was able to work around the issues in order to get a FF build completed. As soon as he gives me the thumbs up, then I will make the final tweaks and upload the rustc-mozilla packages. Will it be cargo-mozilla in buster? How about cbindgen? Will it be cbindgen-mozilla or is cbindgen just going to be updated? cbindgen will just be updated, firefox is the only rdep anyway. As for cargo, it's in the same situation as rustc, so perhaps we're better off renaming it as well. Cheers, Emilio
Bug#1000342: bullseye-pu: package mariadb-10.5 10.5.13-0+deb11u1
On 21/11/2021 21:44, Otto Kekäläinen wrote: Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu I propose that the latest version of MariaDB 10.5.13 would be included in the upcoming stable release update of Debian. Package is ready at https://salsa.debian.org/mariadb-team/mariadb-10.5 Before I submit the final debdiff and changelog I will wait for the release date to show up at https://release.debian.org/ Why? The longer you wait, the fewer changes you have to actually get the update into the next point release. It'd be better to send those debdiffs early and give more time for ACKs or comments. Cheers, Emilio
Bug#998344: buster-pu: package llvm-toolchain-11/1:11.0.1-2~deb10u1
On 10/11/2021 15:03, Roberto C. Sánchez wrote: On Wed, Nov 10, 2021 at 09:00:50AM +0100, Emilio Pozuelo Monfort wrote: On 09/11/2021 21:00, Roberto C. Sánchez wrote: Hi Adam, On Wed, Nov 03, 2021 at 02:20:35PM +, Adam D. Barratt wrote: On Tue, 2021-11-02 at 13:28 -0400, Roberto C. Sanchez wrote: In order to support the update of rustc in buster, which in turn is needed to support the updates of firefox-esr and thunderbird, I am proposing an update of llvm-toolchain-11 in buster. The attached diff represents the change from the current package in the buster- backports repository. That diff appears to be between the git branches, rather than the generated packages. Would it be possible to have a source debdiff between your base and the package you're planning to upload? I rebased my changes on 11.0.1-2 from buster. The debdiff attached to this email represents the updated packge I am proposing for upload. I think you mean from bullseye? Yes, quite right. I did in fact mean bullseye. The target suite is buster, but the source package I am basing the update on is from bullseye. I must have confused myself. Note that I also updated the version of the proposed package to 11.0.1-2+deb10u1. That should be 11.0.1-2~deb10u1, to be lower than the version in bullseye. Again, it appears I successfully confounded myself :-/ I have updated the version to 11.0.1-2~deb10u1 and attached an updated debdiff that reflects the corrected version. Thanks for catching this, Emilio. As a side note, the version I have for the stretch upload is 11.0.1-2~deb9u1. Thanks for the updated debdiff. Do you have an eta for the mips build? It'd be nice to have confirmation that that indeed builds fine. btw minor nitpick, but the clang-tools install change isn't mentioned in the changelog. Would be nice to have that fixed before the actual upload, but no need to send another debdiff just for that. Cheers, Emilio
Bug#998344: buster-pu: package llvm-toolchain-11/1:11.0.1-2~deb10u1
On 09/11/2021 21:00, Roberto C. Sánchez wrote: Hi Adam, On Wed, Nov 03, 2021 at 02:20:35PM +, Adam D. Barratt wrote: On Tue, 2021-11-02 at 13:28 -0400, Roberto C. Sanchez wrote: In order to support the update of rustc in buster, which in turn is needed to support the updates of firefox-esr and thunderbird, I am proposing an update of llvm-toolchain-11 in buster. The attached diff represents the change from the current package in the buster- backports repository. That diff appears to be between the git branches, rather than the generated packages. Would it be possible to have a source debdiff between your base and the package you're planning to upload? I rebased my changes on 11.0.1-2 from buster. The debdiff attached to this email represents the updated packge I am proposing for upload. I think you mean from bullseye? Note that I also updated the version of the proposed package to 11.0.1-2+deb10u1. That should be 11.0.1-2~deb10u1, to be lower than the version in bullseye. Cheers, Emilio
Bug#657390: Proposed mass bug filing: packages without support for build-arch and build-indep
On 06/11/2021 12:40, Simon McVittie wrote: On Sat, 06 Nov 2021 at 11:31:25 +0100, Emilio Pozuelo Monfort wrote: On 05/11/2021 21:22, Lucas Nussbaum wrote: build-arch and build-indep are required targets according to Debian Policy section 4.9. ... Unfortunately this is only a warning in lintian, which might explain why so many packages are still affected. lintian should move those targets to the debian-rules-missing-required-target tag. That request is #657390 (in cc). When this was discussed some years ago, Niels Thykier pointed out that debian-rules-missing-required-target is on the ftp team's list of Lintian tags that cause automatic rejection[1], so making that change in Lintian would make it impossible to do a sourceful upload of the affected packages (for example to fix some unrelated RC issue) without also adding the required targets. This does not necessarily mean the Lintian change is a bad idea, it's just something we should be aware of - expanding the scope of autorejections should be intentional rather than accidental. Ack, in that case let's wait until this mbf is done and some time is given for the packages to get fixed. After that, I think this should become an error and autorejection. Cheers, Emilio
Bug#976148: lxml: enable test suite during build
On 19/05/2021 10:01, Matthias Klose wrote: On 11/30/20 2:36 PM, Emilio Pozuelo Monfort wrote: Source: lxml Version: 4.6.1-1 Severity: normal Tags: patch Hi, The attached patch runs the test suite for each supported python version. It'd be good to do that to ensure lxml's funcionality. The patch needs to do an in-tree build so that etree.so can be found. I couldn't find a workaround for that but if that's a blocker I could investigate further to avoid that in-tree build. do we get that "for free" when using pybuild for the build? pybuild also does out of tree builds (for py3.* and for py3.*-dbg). The same problem arises, I somehow can't get the out of tree etree.so picked up (setting up PYTHONPATH), perhaps because some files are being read from src/lxml/*.py (package lxml), while others (etree.so) need to be read from .pybuild/cpython3_3.9/build/lxml/ (also package lxml). This seems to work: cp .pybuild/cpython3_3.9/build/lxml/etree.cpython-39-x86_64-linux-gnu.so src/lxml/etree.so cp .pybuild/cpython3_3.9/build/lxml/objectify.cpython-39-x86_64-linux-gnu.so src/lxml/objectify.so python3.9 ./test.py Skipping tests in lxml.cssselect - external cssselect package is not installed Comparing with ElementTree 1.3.0 TESTED VERSION: 4.6.1 Python: sys.version_info(major=3, minor=9, micro=2, releaselevel='final', serial=0) lxml.etree: (4, 6, 1, 0) libxml used: (2, 9, 10) libxml compiled: (2, 9, 10) libxslt used: (1, 1, 34) libxslt compiled: (1, 1, 34) FS encoding: utf-8 Default encoding: utf-8 Max Unicode: 1114111 -- Ran 1938 tests in 3.742s ...but it's still somewhat hacky. Perhaps more modules need to be listed in setupinfo.py, and not just the compiled ones, so that src/*.py end up in .pybuild/cpython3_3.9/build/ and we don't have compiled and non-compiled modules split across two dirs? Or maybe there's something else I have missed that can be done to load the extension. Cheers, Emilio
Bug#988046: bind9: does not honor CPPFLAGS
On 08/05/2021 20:43, Ondřej Surý wrote:
Emilio,
could you please post this to the upstream gitLab.isc.org? Ping me when you
create the account, I will have to bump the project limit, so you can fork.
I would be happy to merge this upstream.
Thanks! Can you apply the attached patch? I'd prefer to not create that extra
account if I don't have to, but if it's somehow required then I can do it.
Fortunately, I’ve already changed the build system to use automake in the
development branch, but it was quite an effort, so I didn’t make it in time for
9.16, but the next stable (9.18) will be pretty standard.
Nice!
Cheers,
Emilio
>From 6748327732af53ee2dd6660a34bac5f15f73f812 Mon Sep 17 00:00:00 2001
From: Emilio Pozuelo Monfort
Date: Tue, 8 Jun 2021 12:16:41 +0200
Subject: [PATCH] Honor CPPFLAGS
---
make/rules.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/make/rules.in b/make/rules.in
index 5dd9130062..ac214fba17 100644
--- a/make/rules.in
+++ b/make/rules.in
@@ -105,6 +105,7 @@ install uninstall clean distclean maintainer-clean doc docclean man manclean::
CC = @CC@
CFLAGS = @CFLAGS@
+CPPFLAGS = @CPPFLAGS@
LDFLAGS = @LDFLAGS@
STD_CINCLUDES = @STD_CINCLUDES@
STD_CDEFINES = @STD_CDEFINES@
@@ -160,7 +161,7 @@ ALWAYS_DEFINES = @ALWAYS_DEFINES@
ALWAYS_WARNINGS =
ALL_CPPFLAGS = \
- ${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \
+ ${CPPFLAGS} ${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \
${ALWAYS_DEFINES} ${CDEFINES} ${STD_CDEFINES}
ALL_CFLAGS = ${EXT_CFLAGS} ${ALL_CPPFLAGS} ${CFLAGS} \
--
2.30.2
Bug#988781: hurfbuzz: please package harfbuzz-subset
On 19/05/2021 16:44, Mattia Rizzolo wrote:
Source: harfbuzz
Version: 2.7.4-1
Severity: wishlist
Dear maintainer,
I'm packaging the latest scribus 1.5.7, and they have added an
(optional) dependency on harfbuzz-subset.
+# OpenType subsetting support
+pkg_check_modules(HARFBUZZ_SUBSET harfbuzz-subset>=2.4.0)
+if (HARFBUZZ_SUBSET_FOUND)
+ message("Harfbuzz subset library Found OK")
+ set (HAVE_HARFBUZZ_SUBSET ON)
+endif()
Looking, it seems that you are explicitly not packaging it:
override_dh_install:
dh_install --exclude=subset
Could you please consider including it in the Debian packaging?
It's not packaged because the API was (maybe still is) unstable. From the NEWS
file:
| Overview of changes leading to 1.7.6
| Wednesday, March 7, 2018
| - New experimental harfbuzz-subset library. All of hb-subset.h
| is experimental right now and API WILL change.
|
| Overview of changes leading to 1.7.7
| Tuesday, June 5, 2018
| - Significant libharfbuzz-subset changes. API subject to change.
I think we can package it, as hopefully the API is (somewhat) stable now and we
don't need transitions without SONAME changes (and with conflicting, renamed
packages).
MRs welcome.
Cheers,
Emilio
Bug#988832: unblock: libx11/2:1.7.1-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debia...@lists.debian.org
Please unblock package libx11
This fixes CVE-2021-31535, a bug in libX11 which could lead to the
execution of additional X requests due to insufficient buffer checks.
I have done some manual tests (run an X server with various applications)
The risks are minor as the changes are pretty much limited to the security
fix, with minor changes aside of 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
The debdiff is a little large due to the autotools version the tarball
was generated with. I'm attaching a debdiff filtered with
filterdiff -x '*/Makefile.in' -x '*.man' -x '*/aclocal.m4' -x '*/configure'
(the *.man changes are actual manpage syntax fixes, but make it harder to review
the actually important code fixes in this update, so I filtered them).
unblock libx11/2:1.7.1-1
diff -Nru libx11-1.7.0/compile libx11-1.7.1/compile
--- libx11-1.7.0/compile2020-11-20 20:08:19.0 +0100
+++ libx11-1.7.1/compile2021-05-18 16:14:45.0 +0200
@@ -3,7 +3,7 @@
scriptversion=2018-03-07.03; # UTC
-# Copyright (C) 1999-2020 Free Software Foundation, Inc.
+# Copyright (C) 1999-2018 Free Software Foundation, Inc.
# Written by Tom Tromey .
#
# This program is free software; you can redistribute it and/or modify
@@ -53,7 +53,7 @@
MINGW*)
file_conv=mingw
;;
- CYGWIN* | MSYS*)
+ CYGWIN*)
file_conv=cygwin
;;
*)
@@ -67,7 +67,7 @@
mingw/*)
file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'`
;;
- cygwin/* | msys/*)
+ cygwin/*)
file=`cygpath -m "$file" || echo "$file"`
;;
wine/*)
diff -Nru libx11-1.7.0/configure.ac libx11-1.7.1/configure.ac
--- libx11-1.7.0/configure.ac 2020-11-20 20:08:11.0 +0100
+++ libx11-1.7.1/configure.ac 2021-05-18 16:14:20.0 +0200
@@ -1,7 +1,7 @@
# Initialize Autoconf
AC_PREREQ([2.60])
-AC_INIT([libX11], [1.7.0],
+AC_INIT([libX11], [1.7.1],
[https://gitlab.freedesktop.org/xorg/lib/libx11/issues], [libX11])
AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_HEADERS([src/config.h include/X11/XlibConf.h])
diff -Nru libx11-1.7.0/debian/changelog libx11-1.7.1/debian/changelog
--- libx11-1.7.0/debian/changelog 2021-05-20 10:05:15.0 +0200
+++ libx11-1.7.1/debian/changelog 2021-05-20 10:05:15.0 +0200
@@ -1,3 +1,16 @@
+libx11 (2:1.7.1-1) unstable; urgency=medium
+
+ [ Julien Cristau ]
+ * libx11-6 Breaks old libx11-xcb1, as further mitigation for bug
+ #979590.
+
+ [ Emilio Pozuelo Monfort ]
+ * New upstream release.
+ * CVE-2021-31535: X protocol command injection due to missing request
+ length checks (closes: #988737)
+
+ -- Emilio Pozuelo Monfort Wed, 19 May 2021 17:22:09 +0200
+
libx11 (2:1.7.0-2) unstable; urgency=medium
* Set a strict dependency of libx11-xcb1 on libx11-6, as internal ABI
diff -Nru libx11-1.7.0/debian/control libx11-1.7.1/debian/control
--- libx11-1.7.0/debian/control 2021-05-20 10:05:15.0 +0200
+++ libx11-1.7.1/debian/control 2021-05-20 10:05:15.0 +0200
@@ -28,6 +28,8 @@
${misc:Depends},
libx11-data,
Pre-Depends: ${misc:Pre-Depends}
+Breaks:
+ libx11-xcb1 (<< 2:1.7.0-2),
Multi-Arch: same
Description: X11 client-side library
This package provides a client interface to the X Window System, otherwise
diff -Nru libx11-1.7.0/depcomp libx11-1.7.1/depcomp
--- libx11-1.7.0/depcomp2020-11-20 20:08:19.0 +0100
+++ libx11-1.7.1/depcomp2021-05-18 16:14:46.0 +0200
@@ -3,7 +3,7 @@
scriptversion=2018-03-07.03; # UTC
-# Copyright (C) 1999-2020 Free Software Foundation, Inc.
+# Copyright (C) 1999-2018 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
diff -Nru libx11-1.7.0/include/X11/Xlib.h libx11-1.7.1/include/X11/Xlib.h
--- libx11-1.7.0/include/X11/Xlib.h 2020-11-20 20:08:11.0 +0100
+++ libx11-1.7.1/include/X11/Xlib.h 2021-05-18 16:14:20.0 +0200
@@ -367,7 +367,7 @@
int bitmap_bit_order; /* LSBFirst, MSBFirst */
int bitmap_pad;/* 8, 16, 32 either XY or ZPixmap */
int depth; /* depth of image */
-int bytes_per_line;/* accelarator to next line */
+int bytes_per_line;/* accelerator to next line */
int bits_per_pixel;/* bits per pixel (ZPixmap) */
unsigned long red_mask;/* bits in z arrangement */
unsigned long green_mask;
diff -Nru libx11-1.7.0/install-sh libx11-1.7.1/install-sh
--- libx11-1.7.0/inst
Bug#988449: redmine: run the testsuite during the build
Package: redmine Version: 4.0.7-1 Severity: normal Tags: patch Hi, While backporting security fixes for redmine in stretch, I have enabled the test suite during the build process, which has helped catch some issues in the backports (such as usage of APIs from ruby 2.4+, not available in stretch). The test suite seems quite reliable, so it'd be nice to get it running (and eventually abort on test errors). Here's the patch I used for stretch, I tried to make a patch for sid, but unfortunately there's a FTBFS issue right now due to rails 6, so I couldn't. Thanks, Emilio diff -Nru redmine-3.3.1/debian/changelog redmine-3.3.1/debian/changelog --- redmine-3.3.1/debian/changelog 2019-11-18 22:46:42.0 +0100 +++ redmine-3.3.1/debian/changelog 2021-05-11 10:17:30.0 +0200 @@ -1,3 +1,10 @@ +redmine (3.3.1-4+deb9u3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload by the LTS team. + * Run the testsuite during the build. + + -- Emilio Pozuelo Monfort Tue, 11 May 2021 10:17:30 +0200 + redmine (3.3.1-4+deb9u3) stretch-security; urgency=high * Fix CVE-2019-17427: persistent XSS exists due to textile formatting diff -Nru redmine-3.3.1/debian/control redmine-3.3.1/debian/control --- redmine-3.3.1/debian/control2019-11-18 22:46:42.0 +0100 +++ redmine-3.3.1/debian/control2021-05-11 10:17:30.0 +0200 @@ -26,7 +26,10 @@ ruby-redcarpet, ruby-request-store, ruby-rmagick, - ruby-roadie-rails + ruby-roadie-rails, +# for the test suite + ruby-mocha, + ruby-sqlite3, Build-Depends-Indep: po-debconf Standards-Version: 3.9.8 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-ruby-extras/redmine.git diff -Nru redmine-3.3.1/debian/database.test.yml redmine-3.3.1/debian/database.test.yml --- redmine-3.3.1/debian/database.test.yml 1970-01-01 01:00:00.0 +0100 +++ redmine-3.3.1/debian/database.test.yml 2021-05-11 10:17:30.0 +0200 @@ -0,0 +1,3 @@ +test: + adapter: sqlite3 + database: testdb/redmine.sqlite3 diff -Nru redmine-3.3.1/debian/rules redmine-3.3.1/debian/rules --- redmine-3.3.1/debian/rules 2019-11-18 22:46:42.0 +0100 +++ redmine-3.3.1/debian/rules 2021-05-11 10:17:30.0 +0200 @@ -4,11 +4,25 @@ %: dh $@ +override_dh_auto_clean: + rm -rf instances/default/config/ testdb/ + dh_auto_clean + override_dh_auto_configure: ./debian/check-locales bundle --local --quiet rm -f Gemfile.lock +override_dh_auto_test: +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) + mkdir -p instances/default/config/ + mkdir -p testdb/ + cp debian/database.test.yml instances/default/config/database.yml + bin/rake db:migrate RAILS_ENV=test + bin/rake test RAILS_ENV=test || true + rm db/schema.rb +endif + override_dh_install: dh_install
Bug#988083: unblock: micro-evtd/3.4-6
On 05/05/2021 07:26, Ryan Tandy wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package micro-evtd [ Reason ] One-line patch to fix FTBFS (#987631). Also taking the opportunity to update the Maintainer field; I hope that's OK. [ Impact ] The package currently in bullseye (same as buster) works, however it FTBFS with bullseye's glibc. [ Tests ] There are no automated tests. I have been running the updated daemon for a few days, and I tested an installation with the updated udeb (using a d-i daily image). [ Risks ] I built the package on buster with and without the patch, to see what would change. The disassembly (objdump -d) was the same before and after, so I think I can be confident the header was not actually used and the patch should not change its behaviour. However, the package had not been rebuilt since before buster was released, so there could be unknown risks arising from rebuilding with the newer toolchain. [ Checklist ] [✔] all changes are documented in the d/changelog [✔] I reviewed all changes and I approve them [✔] attach debdiff against the package in testing [ Other info ] Very low popcon. The package provides hardware support for a specific subset of armel/orion5x NAS devices with few remaining users. The package builds a udeb. I tested an installation using a daily d-i image that includes the update. Cyril, can you (n)ack for d-i? Thanks, Emilio
Bug#988185: unblock (pre-approval): gnome-settings-daemon/3.38.2-1
Control: tags -1 confirmed On 07/05/2021 10:38, Simon McVittie wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org I'd like permission to upload a new upstream stable release of gnome-settings-daemon. We already have most of its changes applied via debian/patches. [ Reason ] * Better compatibility with future kernels * Replace patch series with upstream release * Translation update [ Impact ] The only code change fixes a bug: the g-s-d currently in bullseye would report meaningless rfkill events (Bluetooth/WWAN/WLAN/etc. killswitch) on certain kernel versions due to incorrectly treating /dev/rfkill as a bytestream. It should have been treating the device as packet-oriented, one struct per read(), so that the kernel could add extra fields to the end of the struct and have g-s-d ignore them. Some kernels actually did expand the struct, but this was reverted because it broke user-space (both in g-s-d and elsewhere). Bringing in the new upstream release also drops our patches, making future updates easier if they are needed, and makes it more obvious what we're actually shipping. [ Tests ] Manual testing only. I use GNOME regularly. I haven't attempted to find a kernel that would provoke the rfkill bug. [ Risks ] This is a key package, but the changes are simple. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach diff against the package in testing [ Other info ] Because most of the upstream changes were previously in debian/patches, a debdiff would be misleadingly large. The attached diff is patched tree in bullseye vs. proposed patched tree, with the content of the removed patches excluded. I normally upload using dgit, so what I upload and what's in git are the same. unblock gnome-settings-daemon/3.38.2-1 Please go ahead. Emilio
Bug#988184: unblock: gnome-desktop3/3.38.5-2
Control: tags -1 confirmed On 07/05/2021 10:33, Simon McVittie wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org I'd like to update gnome-desktop3 in bullseye. [ Reason ] Fix bad UI for keyboard layouts in gnome-control-center, caused by a regression in changes backported from GNOME 40. [ Impact ] If not fixed, when users add a keyboard layout in gnome-control-center, all keyboard layouts not already in use are listed in a very large "Other" category. The intended UI is that if the user already has at least one English keyboard layout, then English (GB), English (US), English (Dvorak), etc. are more conveniently available as an "English" category, and similar for other languages. [ Tests ] Manually tested: I can reproduce the bug with 3.38.5-1 and it is fixed with 3.38.5-2. The same patch is also in Ubuntu 21.04 already. [ Risks ] Key package, but a simple and obvious change. [ 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 unblock gnome-desktop3/3.38.5-2 Please go ahead and let us know once the package has been accepted. Thanks, Emilio
Bug#988070: unblock: libxml2/2.9.10+dfsg-6.5 (pre-approval)
Control: tags -1 confirmed Hi Salvatore, On 06/05/2021 10:56, Salvatore Bonaccorso wrote: Control: retitle -1 unblock: libxml2/2.9.10+dfsg-6.6 (pre-approval) On Tue, May 04, 2021 at 11:04:52PM +0200, Salvatore Bonaccorso wrote: Hi, On Tue, May 04, 2021 at 09:19:20PM +0200, Salvatore Bonaccorso wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: car...@debian.org Dear release team This is a pre-approval request to please unblock package libxml2 (not yet uploaded to unstable, but to experimental so far as 2.9.10+dfsg-6.4). Please unblock package libxml2 [ Reason ] The update would fix three CVEs recently reported, CVE-2021-3516 (#987739), CVE-2021-3517 (#987738) and CVE-2021-3518 (#987737). Which are not very severe but we still wanted to try to get fixes into bullseye. [ Impact ] Package still affected by those CVEs. [ Tests ] For those three CVEs pocs are available, which I had tested before and with the fix, except CVE-2021-3516, which I could not trigger the issue, but the change is simple. Furthermore given I uploaded to experimental there was additional exposure by the autopkgtests. From those as you can see from https://release.debian.org/britney/pseudo-excuses-experimental.html three marked regressions, but both balsa and kopanocore were already before failing. For libreoffice the tests somehow are flapping where they fail, I do not see a relation to the libxml2 here. libreoffice failed there in the last run for uicheck-sc test (triggered by python3.9), but in the libxml2 case it failed for the uicheck-sw test and for the prvious failure it was again one other test. To confirm: And in fact just one other run did not fail: https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/12125523/log.gz Another CVE popped up, which I have included in a new upload, thus retitling the bug and attaching the new debdiff. Please go ahead and let us know once the package has been accepted. Cheers, Emilio
Bug#988046: bind9: does not honor CPPFLAGS
Package: bind9
Severity: normal
Hi,
While doing a bind9 update for stretch LTS, Anton Gladky added a salsa
pipeline which had a blhc (build log hardening check) test that was
failing.
I have investigated it and found that bind9 is not using automake and while
it tries to honor most *FLAGS variables, it ignores CPPFLAGS. The attached
patch makes it honor CPPFLAGS, so that Debian's default flags (e.g.
-D_FORTIFY_SOURCE=2) get passed. A small diff from the build logs:
-libtool: compile: gcc -include /build/bind9-9.16.13/config.h
-I/build/bind9-9.16.13 -I../../.. -I./include -I./../unix/include
-I./../pthreads/include -I../include -I./../include -I./..
-I/usr/include/json-c -I/usr/include/libxml2 -g -O2
-ffile-prefix-map=/build/bind9-9.16.13=. -fstack-protector-strong -Wformat
-Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks
-DNO_VERSION_DATE -DDIG_SIGCHASE -pthread -fPIC -W -Wall -Wmissing-prototypes
-Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith
-Wno-missing-field-initializers -fno-strict-aliasing -c tlsdns.c -o tlsdns.o
>/dev/null 2>&1
+libtool: compile: gcc -Wdate-time -D_FORTIFY_SOURCE=2 -include
/build/bind9-9.16.13/config.h -I/build/bind9-9.16.13 -I../../.. -I./include
-I./../unix/include -I./../pthreads/include -I../include -I./../include -I./..
-I/usr/include/json-c -I/usr/include/libxml2 -g -O2
-ffile-prefix-map=/build/bind9-9.16.13=. -fstack-protector-strong -Wformat
-Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks
-DNO_VERSION_DATE -DDIG_SIGCHASE -pthread -fPIC -W -Wall -Wmissing-prototypes
-Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith
-Wno-missing-field-initializers -fno-strict-aliasing -c tlsdns.c -o tlsdns.o
>/dev/null 2>&1
I have not tested the resulting package, but it should probably be alright
to add this after the current freeze.
Thanks,
Emilio
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (200, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-5-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bind9 depends on:
ii adduser3.118
ii bind9-libs 1:9.16.13-1
pn bind9-utils
ii debconf [debconf-2.0] 1.5.75
ii dns-root-data 2021011101
ii init-system-helpers1.60
ii iproute2 5.10.0-4
ii libc6 2.31-11
ii libcap21:2.44-1
ii libfstrm0 0.6.0-1+b1
ii libjson-c5 0.15-2
ii liblmdb0 0.9.24-1
ii libmaxminddb0 1.5.2-1
ii libprotobuf-c1 1.3.3-1+b2
ii libssl1.1 1.1.1k-1
ii libuv1 1.40.0-1
ii libxml22.9.10+dfsg-6.3+b1
ii lsb-base 11.1.0
ii netbase6.2
ii zlib1g 1:1.2.11.dfsg-2
bind9 recommends no packages.
Versions of packages bind9 suggests:
pn bind-doc
ii bind9-dnsutils [dnsutils] 1:9.16.13-1
ii dnsutils 1:9.16.13-1
pn resolvconf
pn ufw
diff -Nru bind9-9.16.13/debian/changelog bind9-9.16.13/debian/changelog
--- bind9-9.16.13/debian/changelog 2021-03-18 14:23:49.0 +0100
+++ bind9-9.16.13/debian/changelog 2021-05-04 10:39:27.0 +0200
@@ -1,3 +1,10 @@
+bind9 (1:9.16.13-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Pass CPPFLAGS down to make.
+
+ -- Emilio Pozuelo Monfort Tue, 04 May 2021 10:39:27 +0200
+
bind9 (1:9.16.13-1) unstable; urgency=medium
* New upstream version 9.16.13
diff -Nru bind9-9.16.13/debian/patches/preserve-cppflags.patch
bind9-9.16.13/debian/patches/preserve-cppflags.patch
--- bind9-9.16.13/debian/patches/preserve-cppflags.patch1970-01-01
01:00:00.0 +0100
+++ bind9-9.16.13/debian/patches/preserve-cppflags.patch2021-05-04
10:39:27.0 +0200
@@ -0,0 +1,23 @@
+Preserve CPPFLAGS
+
+Author: Emilio Pozuelo Monfort
+
+--- a/make/rules.in
b/make/rules.in
+@@ -105,6 +105,7 @@ install uninstall clean distclean mainta
+
+ CC = @CC@
+ CFLAGS = @CFLAGS@
++CPPFLAGS =@CPPFLAGS@
+ LDFLAGS = @LDFLAGS@
+ STD_CINCLUDES = @STD_CINCLUDES@
+ STD_CDEFINES =@STD_CDEFINES@
+@@ -160,7 +161,7 @@ ALWAYS_DEFINES = @ALWAYS_DEFINES@
+ ALWAYS_WARNINGS =
+
+ ALL_CPPFLAGS = \
+- ${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \
++ ${CPPFLAGS} ${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \
+ ${ALWAYS_DEFINES} ${CDEFINES} ${STD_CDEFINES}
+
+ ALL_CFLAGS = ${EXT_CFLAGS} ${ALL_CPPFLAGS} ${CFLAGS} \
diff -Nru bind9-9.16.13/debian/p
Bug#986066: unblock: terminator/2.1.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package terminator
[ Reason ]
Small fix (actually a revert), applied upstream, to fix terminals
going white when unfocused.
[ Impact ]
Can't see what's in the (last) terminal if it's not focused.
[ Tests ]
No automated tests afaik. However I have been running this patch for over
two months without issues.
[ Risks ]
Small change that reverts a patch included in 2.1.0, so it basically restores
code back to what we had previously that was working fine, so the risk is
minimal. Also this is not a key package.
[ 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
unblock terminator/2.1.0-2
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (200, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru terminator-2.1.0/debian/changelog terminator-2.1.0/debian/changelog
--- terminator-2.1.0/debian/changelog 2021-01-06 11:40:53.0 +0100
+++ terminator-2.1.0/debian/changelog 2021-03-22 09:20:01.0 +0100
@@ -1,3 +1,11 @@
+terminator (2.1.0-2) unstable; urgency=medium
+
+ * fix-white-background.patch: fix a bug where having multiple tabs
+causes the last terminal in the tab to become fully white.
+ * Add myself to Uploaders.
+
+ -- Emilio Pozuelo Monfort Mon, 22 Mar 2021 09:20:01 +0100
+
terminator (2.1.0-1) unstable; urgency=medium
* [7c08e04] d/changelog: Add missing change
diff -Nru terminator-2.1.0/debian/control terminator-2.1.0/debian/control
--- terminator-2.1.0/debian/control 2021-01-06 11:38:08.0 +0100
+++ terminator-2.1.0/debian/control 2021-03-22 09:20:01.0 +0100
@@ -2,7 +2,8 @@
Section: misc
Priority: optional
Maintainer: Debian Python Team
-Uploaders: Markus Frosch
+Uploaders: Markus Frosch ,
+ Emilio Pozuelo Monfort ,
Build-Depends: debhelper-compat (= 13),
dh-python,
intltool,
diff -Nru terminator-2.1.0/debian/patches/fix-white-background.patch
terminator-2.1.0/debian/patches/fix-white-background.patch
--- terminator-2.1.0/debian/patches/fix-white-background.patch 1970-01-01
01:00:00.0 +0100
+++ terminator-2.1.0/debian/patches/fix-white-background.patch 2021-03-22
09:20:01.0 +0100
@@ -0,0 +1,171 @@
+From 4b6753746271ac0faa166d9f92a099befeea140e Mon Sep 17 00:00:00 2001
+From: Emilio Pozuelo Monfort
+Date: Fri, 15 Jan 2021 09:54:38 +0100
+Subject: [PATCH] Revert "fix issue #74"
+
+This reverts commit 77696aa2cdc95c356501a1ba971684ee1aee857b.
+---
+ terminatorlib/terminal.py | 94 ++-
+ 1 file changed, 52 insertions(+), 42 deletions(-)
+
+diff --git a/terminatorlib/terminal.py b/terminatorlib/terminal.py
+index c76cd9a8..da49338c 100644
+--- a/terminatorlib/terminal.py
b/terminatorlib/terminal.py
+@@ -6,7 +6,6 @@
+ import os
+ import signal
+ import gi
+-import cairo
+ from gi.repository import GLib, GObject, Pango, Gtk, Gdk, GdkPixbuf
+ gi.require_version('Vte', '2.91') # vte-0.38 (gnome-3.14)
+ from gi.repository import Vte
+@@ -32,32 +31,6 @@ from . import plugin
+ from terminatorlib.layoutlauncher import LayoutLauncher
+ from . import regex
+
+-class Overpaint(Vte.Terminal):
+-def __init__(self):
+-Vte.Terminal.__init__(self)
+-self.config = Config()
+-### inactive_color_offset is the opposite of alpha level
+-self.dim_p = float(self.config['inactive_color_offset'])
+-self.dim_l = round(1.0 - self.dim_p,3)
+-def dim(self,b):
+-self.overpaint = b
+-
+-def do_draw(self,cr):
+-### get_color_background_for_draw is not available in older
+-### versions of vte
+-try:
+-bgc = Vte.Terminal.get_color_background_for_draw(self)
+-except AttributeError as e:
+-bgc = Gdk.RGBA()
+-bgc.parse(self.config['background_color'])
+-Vte.Terminal.do_draw(self,cr)
+-if self.overpaint:
+-bgc.alpha = self.dim_l
+-cr.set_operator(cairo.Operator.OVER)
+-Gdk.cairo_set_source_rgba(cr,bgc)
+-
cr.rectangle(0.0,0.0,self.get_allocated_width(),self.get_allocated_height())
+-cr.paint()
+-
+ # pylint: disable-msg=R0904
+ class Terminal(Gtk.VBox):
+ """Class implementing the VTE widget and its wrappings"""
+@@ -132,8 +105,10 @@ class Terminal(Gtk.VBox):
+ is_held_open = False
+
+ fgcolor_active = None
++fgcolor_inactive = None
+
Bug#985056: unblock: pygments/2.7.1+dfsg-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: team+pyt...@tracker.debian.org
Please unblock package pygments
[ Reason ]
Fixes CVE-2021-20270: infinite loop in the SML lexer
[ Impact ]
CPU exhaustion via crafted SML files in services using pygments
[ Tests ]
There's a simple test case in the upstream bug that I used to
verify that -1 is vulnerable (100% CPU usage) and -2 fixes the
issue.
[ Risks ]
Low risk: minimal change addressing a targeted issue via a patch,
worst case we can unapply the patch if a regression is found.
[ 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
unblock pygments/2.7.1+dfsg-2
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (200, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru pygments-2.7.1+dfsg/debian/changelog
pygments-2.7.1+dfsg/debian/changelog
--- pygments-2.7.1+dfsg/debian/changelog2020-10-09 00:54:38.0
+0200
+++ pygments-2.7.1+dfsg/debian/changelog2021-03-12 10:54:46.0
+0100
@@ -1,3 +1,15 @@
+pygments (2.7.1+dfsg-2) unstable; urgency=medium
+
+ * Team upload.
+
+ [ Sandro Tosi ]
+ * Use the new Debian Python Team contact name and address
+
+ [ Emilio Pozuelo Monfort ]
+ * CVE-2021-20270: infinite loop in the SML lexer (Closes: #984664).
+
+ -- Emilio Pozuelo Monfort Fri, 12 Mar 2021 10:54:46 +0100
+
pygments (2.7.1+dfsg-1) unstable; urgency=medium
[ Emmanuel Arias ]
diff -Nru pygments-2.7.1+dfsg/debian/control pygments-2.7.1+dfsg/debian/control
--- pygments-2.7.1+dfsg/debian/control 2020-10-09 00:54:38.0 +0200
+++ pygments-2.7.1+dfsg/debian/control 2021-03-12 10:54:46.0 +0100
@@ -2,7 +2,7 @@
Section: python
Priority: optional
Maintainer: Piotr Ożarowski
-Uploaders: Debian Python Modules Team
+Uploaders: Debian Python Team
Build-Depends: debhelper-compat (= 13)
Build-Depends-Indep: dh-python,
python3-all,
diff -Nru pygments-2.7.1+dfsg/debian/patches/CVE-2021-20270.patch
pygments-2.7.1+dfsg/debian/patches/CVE-2021-20270.patch
--- pygments-2.7.1+dfsg/debian/patches/CVE-2021-20270.patch 1970-01-01
01:00:00.0 +0100
+++ pygments-2.7.1+dfsg/debian/patches/CVE-2021-20270.patch 2021-03-12
10:54:46.0 +0100
@@ -0,0 +1,45 @@
+From f91804ff4772e3ab41f46e28d370f57898700333 Mon Sep 17 00:00:00 2001
+From: Georg Brandl
+Date: Thu, 10 Dec 2020 08:19:21 +0100
+Subject: [PATCH] fixes #1625: infinite loop in SML lexer
+
+Reason was a lookahead-only pattern which was included in the state
+where the lookahead was transitioning to.
+---
+ CHANGES | 8
+ pygments/lexers/ml.py | 12 ++--
+ 2 files changed, 14 insertions(+), 6 deletions(-)
+
+diff --git a/pygments/lexers/ml.py b/pygments/lexers/ml.py
+index 8ca8ce3eb..f2ac367c5 100644
+--- a/pygments/lexers/ml.py
b/pygments/lexers/ml.py
+@@ -142,7 +142,7 @@ def id_callback(self, match):
+ (r'#\s+(%s)' % symbolicid_re, Name.Label),
+ # Some reserved words trigger a special, local lexer state change
+ (r'\b(datatype|abstype)\b(?!\')', Keyword.Reserved, 'dname'),
+-(r'(?=\b(exception)\b(?!\'))', Text, ('ename')),
++(r'\b(exception)\b(?!\')', Keyword.Reserved, 'ename'),
+ (r'\b(functor|include|open|signature|structure)\b(?!\')',
+ Keyword.Reserved, 'sname'),
+ (r'\b(type|eqtype)\b(?!\')', Keyword.Reserved, 'tname'),
+@@ -315,15 +315,14 @@ def id_callback(self, match):
+ 'ename': [
+ include('whitespace'),
+
+-(r'(exception|and)\b(\s+)(%s)' % alphanumid_re,
++(r'(and\b)(\s+)(%s)' % alphanumid_re,
+ bygroups(Keyword.Reserved, Text, Name.Class)),
+-(r'(exception|and)\b(\s*)(%s)' % symbolicid_re,
++(r'(and\b)(\s*)(%s)' % symbolicid_re,
+ bygroups(Keyword.Reserved, Text, Name.Class)),
+ (r'\b(of)\b(?!\')', Keyword.Reserved),
++(r'(%s)|(%s)' % (alphanumid_re, symbolicid_re), Name.Class),
+
+-include('breakout'),
+-include('core'),
+-(r'\S+', Error),
++default('#pop'),
+ ],
+
+ 'datcon': [
diff -Nru pygments-2.7.1+dfsg/debian/patches/series
pygments-2.7.1+dfsg/debian/patches/series
--- pygments-2.7.1+dfsg/debian/patches/series 2020-10-09 00:54:38.0
+0200
+++ pygments-2.7.1+dfsg/debian/patches/series 2021-03-12 10:54:46.0
+0100
@@ -1,3 +1,4
Bug#981422: xdg-utils: autopkgtest failure: make: dh: No such file or directory
On 30/01/2021 22:22, Nicholas Guriev wrote:
Hello!
On Sat, 2021-01-30 at 21:54 +0100, Paul Gevers wrote:
You recently added an autopkgtest to your package xdg-utils, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?
There are several ways to fix the failure.
1. Replace `debian/rules patch` line in a test script with `chmod +x
autotests/tty{on,off}`.
--- a/debian/tests/entry
+++ b/debian/tests/entry
@@ -13,6 +13,6 @@ fi
BASH_XTRACEFD=1
set -x
·
-debian/rules patch
./configure
+chmod +x autotests/tty{on,off}
make autotest SHELL="${1:-/bin/sh}"
https://salsa.debian.org/freedesktop-team/xdg-utils/-/commit/9928933504932f19fb39a0f671cdc7be78aada29
2. Put the "patch" target back as it was in -3 revision, and fix arch-
independent build.
https://salsa.debian.org/freedesktop-team/xdg-utils/-/merge_requests/4/diffs?commit_id=0617f9284ae4d79b51c4ad4bc7d781e93561cb23
I still prefer the later option with the "patch" target. Because that
chmod fixes flaws of quilt and dpkg and this solutions is more
universal. I hope someone will choose to upload another one-liner fix.
You can ship the files directly in the debian.tar by adding them to
debian/source/include-binaries, and that way you don't need to call chmod as
their mode will be preserved. That would probably help with this autopkgtest
patch issue.
Cheers,
Emilio
Bug#938666: thunderbird: Python2 removal in sid/bullseye
Version: 1:78.0.1-1 On Fri, 30 Aug 2019 07:55:49 + Matthias Klose wrote: Package: src:thunderbird Version: 1:60.8.0-2 Severity: normal Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: py2removal Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Your package either build-depends, depends on Python2, or uses Python2 in the autopkg tests. Please stop using Python2, and fix this issue by one of the following actions. thunderbird (1:78.0.1-1) experimental; urgency=medium * [5450d8d] d/control: increase B-D for libnss3 * [9749d1d] d/control: drop B-D on python2 and move over to python3 [...] -- Carsten Schoenert Wed, 22 Jul 2020 20:11:25 +0200 Cheers, Emilio
Bug#976148: lxml: enable test suite during build
Source: lxml Version: 4.6.1-1 Severity: normal Tags: patch Hi, The attached patch runs the test suite for each supported python version. It'd be good to do that to ensure lxml's funcionality. The patch needs to do an in-tree build so that etree.so can be found. I couldn't find a workaround for that but if that's a blocker I could investigate further to avoid that in-tree build. We could further enable autopkgtests to detect if a dep introduces a regression, I could look into writing a patch for that if that'd be desired. Thanks, Emilio diff -Nru lxml-4.6.1/debian/changelog lxml-4.6.1/debian/changelog --- lxml-4.6.1/debian/changelog 2020-10-22 18:02:16.0 +0200 +++ lxml-4.6.1/debian/changelog 2020-11-30 13:56:20.0 +0100 @@ -1,3 +1,9 @@ +lxml (4.6.1-2) UNRELEASED; urgency=medium + + * Run the test suite during the build. + + -- Emilio Pozuelo Monfort Mon, 30 Nov 2020 13:56:20 +0100 + lxml (4.6.1-1) unstable; urgency=medium * New upstream version. diff -Nru lxml-4.6.1/debian/rules lxml-4.6.1/debian/rules --- lxml-4.6.1/debian/rules 2020-07-17 11:16:59.0 +0200 +++ lxml-4.6.1/debian/rules 2020-11-30 13:56:20.0 +0100 @@ -20,7 +20,7 @@ build-indep: build build: build3-stamp -build3-stamp: $(PY3VERS:%=build3-python%) $(PY3VERS:%=dbg-build3-python%) +build3-stamp: $(PY3VERS:%=build3-python%) $(PY3VERS:%=dbg-build3-python%) $(PY3VERS:%=check-python%) touch $@ build3-python%: prebuild python$* setup.py build @@ -28,6 +28,12 @@ dbg-build3-python%: prebuild python$*-dbg setup.py build touch $@ +check-python%: + python$* setup.py build_ext -i + python$* test.py -vv + #python$*-dbg setup.py build_ext -i + #python$*-dbg test.py -vv + touch $@ clean: dh_testdir
