Bug#1070852: transition: gdal
On 24/05/2024 11:02, Sebastiaan Couwenberg wrote: On 5/24/24 9:30 AM, Emilio Pozuelo Monfort wrote: If that's the case, gdal should probably break older versions of libgdal-grass so that that combination is not possible. That will also make britney happy, otherwise it will block gdal due to the test regression. gdal, grass, and libgdal-grass just need to be tested together. I'd rather drop the autopkgtest test than having to maintain the Breaks in gdal. *shrug*. If that's a runtime check, then there's an issue with the dependencies/breaks, as one could have old libgdal-grass with newer gdal (as is happening in the autopkgtest) and then libgdal-grass is broken. If it's a check that's being done in libgdal-grass, then maybe that check can be dropped? With the information that autopkgtest has, the current situation is broken and testing migration will be (rightly) blocked. Cheers, Emilio
Bug#1069679: Debian Bugs information: logs for Bug#1069679
Hi Mike, On 24/05/2024 09:39, Hector Oron wrote: Hello Mike, On Fri, 24 May 2024 at 08:57, Mike Gabriel wrote: If noone plans to fix Ofono in Debian within the next 1-2 weeks, I'd like to do a team upload. In that case, could any of you give me access to https://salsa.debian.org/telepathy-team (or just the ofono repo in there). I tried but I do not have enough permissions to add you. You'll need Emilio or Laurent for that. I'm not really active on the telepathy stack anymore. I have granted you access to the team, feel free to take a look at ofono and any other stuff that needs some love. Cheers, Emilio
Bug#1070852: transition: gdal
On 22/05/2024 21:25, Sebastiaan Couwenberg wrote: On 5/22/24 8:40 AM, Emilio Pozuelo Monfort wrote: Go ahead. Thanks. gdal (3.9.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. binNMUs scheduled. libdal-grass autopkgtests are failing for the version in testing with gdal from sid, apparently there's some runtime detection preventing that combination[1]: 32s autopkgtest [16:10:14]: test gdalinfo-ogrinfo: [--- 35s ERROR 1: OGR/GRASS driver was compiled against GDAL 3.8, but the current library version is 3.9 35s ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.8, but the current library version is 3.9 35s ERROR 4: `./spearfish60_grass7/PERMANENT/cellhd/geology' not recognized as being in a supported file format. [1] https://ci.debian.net/packages/libg/libgdal-grass/testing/amd64/46934033/ If that's the case, gdal should probably break older versions of libgdal-grass so that that combination is not possible. That will also make britney happy, otherwise it will block gdal due to the test regression. Cheers, Emilio
Bug#1071620: libchicken-dev: depends on obsolete libpcre3-dev package
Package: libchicken-dev Version: 5.3.0-1.1 Severity: serious Hi, pcre3 is being removed. libchicken-dev depends on libpcre3-dev, however it looks like that dependency is unused. The headers don't mention it and pcre3 support was removed in version 4.8.0.5-1 (bug #729144). Looks like libpcre3-dev was only removed from build-depends but not from libchicken-dev's depends. Cheers, Emilio
Bug#1071618: kannel-dev: depends on obsolete libpcre3-dev
Package: kannel-dev Version: 1.4.5-16 Severity: serious Hi, kannel-dev depends on libpcre3-dev, which is going to be removed. Given pcre3 support was removed in 1.4.5-13, that dependency can probably just go away. Cheers, Emilio
Bug#1071476: neochat: Neochat will not start, due to old kirigami-addons
On Mon, 20 May 2024 01:04:01 +0200 "Salvo \"LtWorf\" Tomaselli" wrote: Package: neochat Version: 23.08.5-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: ltw...@debian.org Dear Maintainer, neochat won't start. I have uploaded kirigami-addons, and made a new upload of neochat. This bug is so that it will not migrate. Should this be marked as fixed in 23.08.5-2 ? Cheers, Emilio
Bug#1070977: transition: snappy
On 13/05/2024 17:42, László Böszörményi (GCS) wrote: On Mon, May 13, 2024 at 2:04 PM Emilio Pozuelo Monfort wrote: Why is there a libsnappy1v5 transitional package? Serves several purposes. As noted, upstream soname is _not_ changed, so I can't let the old library package be present as it would contain the same named library file conflicting with the one in the new, normally named library package name. In short, I must do a file move between packages. Then the old libsnappy1v5 package has a conflict with the then old libsnappy1 package name. Thus this conflict needs to be removed. Also has upstream been contacted in order to do a proper SONAME bump? Otherwise libsnappy1 will have to conflict with libsnappy1v5, and that will make both the transition and upgrades harder, as they have to be done in lockstep. If they broke the ABI, then a SONAME bump is in order, and that will make it easier for us too. Yup, in such cases a soname bump is needed. Then upstream is Google and as I remember years back I had a somewhat similar problem with one of their library package. If I'm correct, I got a similar answer that in such cases they just recompile the dependent sources and don't change the soname. Then the public source tree is hosted on GitHub [1] without the issues (report) area enabled. The AUTHORS file contains a general email address (opensou...@google.com) [2] meaning I'm not sure if I get any answer or I will get one soon. But I can try it if you insist. Looks like this got reported upstream and the symbols got re-added: https://github.com/google/snappy/issues/183 https://github.com/google/snappy/commit/465b5b60ca410436fa663700c4656ea8f7bf2a95 If that's enough, I assume the package renaming in experimental can be reverted and we just update to snappy 1.2.1, keeping the old library package name. Cheers, Emilio
Bug#1070659: transition: re2
Control: tags -1 confirmed On 06/05/2024 19:09, Stefano Rivera wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: r...@packages.debian.org Control: affects -1 + src:re2 User: release.debian@packages.debian.org Usertags: transition Control: block -1 with 1070649 1053409 It has taken a while to prepare the next re2 transition, because it included a new dependency on abseil. This broke most of the reverse-dependencies. It also means that transitions will get more frequent, as every abseil transition will change re2's ABI. I think the state of the reverse-dependencies is reasonable, now. I just did a rebuild of them all, and got these failures: Go ahead. Cheers, Emilio
Bug#1071473: transition: opencascade
Control: tags -1 confirmed On 19/05/2024 23:08, Tobias Frost wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: opencasc...@packages.debian.org Control: affects -1 + src:opencascade User: release.debian@packages.debian.org Usertags: transition Control: block 1071284 by -1 Control: block 1071223 by -1 Control: block 1071470 by -1 Control: block 1071451 by -1 Control: block 1071471 by -1 Hi Release team, opencascade has a new release with breaking ABI, upstream versionied them as 7.8. The transition tracker [1] correctly picked it up already after the upload to experimental. [1] https://release.debian.org/transitions/html/auto-opencascade.html building the reverse depenencies most FTBFS due to library naming changes, but I was able to come up with patches for most, but they will require sourceful uploads. Freecad will require either backporting the upstream fixes or package a new upstream snapshot. This is the result of the compilation tests: Dependency level 2: f3d ✔ freecad (sid only) FTBFS, fixed in upstream git. horizon-eda patch available, #1071284 kicad ✔ netgen patch available, #1071223 slic3r-prusa (sid only) patch available, #1071470 Dependency level 3: gmshpatch available, #1071451 Dependency level 4: deal.ii patch available, #1071471 Will you help upload those fixes? Perhaps through delayed NMUs or team uploads? If so, go ahead. Cheers, Emilio
Bug#1071577: transition: libcamera 0.3.0
Control: tags -1 confirmed On 21/05/2024 15:25, Dylan Aïssi wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:libcamera Dear Release Team, Please schedule a transition slot for libcamera 0.3.0. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-libcamera.html The unique reverse dep (pipewire 1.0.6-1) builds fine with libcamera 0.3.0 in experimental. Go ahead. Cheers, Emilio
Bug#1070852: transition: gdal
Control: tags -1 confirmed On 10/05/2024 16:09, Bas Couwenberg wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gdal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html For the Debian GIS team I'd like to transition to GDAL 3.8.0. All reverse dependencies except python-django and facet-analyser rebuilt successfully with GDAL 3.9.0 from experimental as summarized below. python-django (3:4.2.11-1) FTBFS due to unrelated test failures. (#1042637) facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS due to uninstallable build dependencies. (#1040334) Bugreports can be found using the gdal-3.9 usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=gdal-3.9 Transition: gdal libgdal34t64 (3.8.5+dfsg-1) -> libgdal35 (3.9.0~beta1+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7.1) OK fiona (1.9.6-1) OK gmt (6.5.0+dfsg-3)OK grass (8.3.2-1) OK libcitygml (2.5.2-1) OK libgeo-gdal-ffi-perl(0.11-2) OK libosmium (2.20.0-1)OK mapcache(1.14.0-4)OK mapnik (3.1.0+ds-7) OK mapproxy(2.0.2+dfsg-1)OK mapserver (8.0.1-4) OK merkaartor (0.19.0+ds-5) OK mysql-workbench (8.0.32+dfsg-2) OK ncl (6.6.2.dfsg.1-7) OK octave-mapping (1.4.2-3) OK openorienteering-mapper (0.9.5-3.1) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.2+dfsg-6) OK pgsql-ogr-fdw (1.1.4-3) OK pktools (2.6.7.6+ds-6)OK postgis (3.4.2+dfsg-1)OK python-django (3:4.2.11-1) FTBFS (#1042637) qmapshack (1.17.1-1)OK r-cran-sf (1.0-15+dfsg-1) OK r-cran-terra(1.7-65-1)OK rasterio(1.3.10-2)OK saga(9.4.0+dfsg-1)OK vtk9(9.1.0+really9.1.0+dfsg2-7.1) OK facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS (#1040334) libgdal-grass (1:1.0.2-7) OK opencv (4.6.0+dfsg-13.1) OK osmcoastline(2.4.0-2) OK qgis(3.34.6+dfsg-1) OK sumo(1.18.0+dfsg-3) OK Go ahead. Emilio
Bug#1071558: gst-plugins-bad1.0-contrib: rebuild against t64 libraries
Source: gst-plugins-bad1.0-contrib Version: 1.20.0-1 Severity: normal Hi, While this package only builds on i386 and amd64, where t64 libs also provide the old names, it'd still be nice to have this package rebuilt to ease the transitions, as it shows on the cruft reports when trying to remove e.g. libglib2.0-0 which is no longer built. Thanks, Emilio
Bug#1071557: RM: maptool [armel armhf i386] -- RoQA; not built on 32-bit arches
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: na...@packages.debian.org Control: affects -1 + src:navit Hi, maptool isn't built on 32-bit arches, but it hasn't been detected by the cruft report, perhaps because it still has 'Architecture: any' and relies on a dh option in d/rules to skip that binary. Please remove the package from those architectures. Cheers, Emilio
Bug#1071502: RM: gssdp-tools [i386] -- ROM; no longer built on i386
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: gs...@packages.debian.org Control: affects -1 + src:gssdp Hi, gssdp-tools hasn't been built on i386 for a while. Please drop the binary which has no rdeps afaict. Thanks, Emilio
Bug#1068915: RM: libgrss - dead upstream, depends on obsolete libsoup2.4, not needed
reassign 1068915 ftp.debian.org user ftp.debian@packages.debian.org usertags 1068915 remove thanks Hi Alexandre, On Sat, 13 Apr 2024 12:21:43 +0200 Alexandre Detiste wrote: Source: libgrss Version: 0.7.0-2.1 Severity: normal X-Debbugs-Cc: debian...@lists.debian.org, Graham Inggs Hi, Everything is in the title :-) Here are more pointers: https://release.debian.org/transitions/html/libsoup3.html https://qa.debian.org/popcon.php?package=libgrss https://gitlab.gnome.org/GNOME/libgrss/-/commits/master This looks like a RM bug. Thus it should be assigned to the ftp.debian.org pseudo-package. Cheers, Emilio
Bug#1071121: transition: clamav
Control: tags -1 moreinfo On 14/05/2024 19:49, Sebastian Andrzej Siewior wrote: Package: release.debian.org Control: affects -1 + src:clamav X-Debbugs-Cc: cla...@packages.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal ClamAV 1.3.x has a new soname. I have the in package in experimental with libclamav12t64. I would like to go back to libclamav12 (there is already libclamav11t64 so I don't think there is a need to keep the t64 suffix any longer). The impact is small, three packages in main which I test-built and libclamunrar in non-free which I need to upload manually. I can pre-upload the libclamav12 to experimental to avoid the new queue if this is preferred. Yes, go through experimental if you want to rename it. You'll have to add proper conflicts/etc. Let us know once the package is accepted in experimental. Cheers, Emilio
Bug#1061188: transition: python3-defaults (making python3.12 the default python3 version)
Hi Matthias, On 20/01/2024 15:41, Matthias Klose wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please setup a tracker for the python3-defaults transition, making 3.12 the default Python version. What's the current status? Has a mass-build been done with python3-defaults from experimental? Cheers, Emilio
Bug#1071148: python3-rpm: only builds for the default python version
Package: python3-rpm Version: 4.19.1.1+dfsg-1 Severity: normal Hi, Looking at the python 3.12 transition tracker, I noticed that python3-rpm was listed as being incomplete. Upon inspection of the build log, I saw that while rpm build-depends on python3-all-dev (which is normally done in order to build for all supported python3 versions) rpm only builds for the default one. It'd help to build for all supported versions, but if that's not realistic, then the package should just build-dep on python3-dev. Cheers, Emilio
Bug#1071147: bluez: autopkgtests fail due to lack of devices
Package: bluez Version: 5.73-1 Severity: serious Hi, The new autopkgtests added in 5.73-1 are failing on ci.debian.net: autopkgtest [03:11:41]: test bluez-response: [--- testAdapter (__main__.TestBluezResponse.testAdapter) ... Can't open HCI socket.: Address family not supported by protocol skipped 'No bluetooth devices available for testing' testDevice (__main__.TestBluezResponse.testDevice) ... Can't open HCI socket.: Address family not supported by protocol skipped 'No bluetooth devices available for testing' This is blocking testing migration. If this can't be fixed in the short term by adding some type of restriction to the autopkgtest or by mocking the devices, then the tests should be removed until they can be made to work on our infrastructure. Cheers, Emilio
Bug#1071145: lxqt-menu-data: breaks lxqt-panel
Package: lxqt-menu-data Version: 1.4.1-2 Severity: serious Hi, Your package breaks/replaces lxqt-panel (<< 1.4), however the latest lxqt-panel in sid is 1.3.0-1. This means that those packages cannot be co-installed atm, which is making lxqt-core uninstallable now. If the reason for this breaks/replaces was to take over some files from lxqt-panel, then a new version of lxqt-panel should be uploaded with a high enough version and without those files. In a fresh sid chroot: root@andromeda:/# apt install lxqt-core Unsatisfied dependencies: lxqt-menu-data : Breaks: lxqt-panel (< 1.4) but 1.3.0-1+b1 is to be installed Cheers, Emilio
Bug#1069536: glib-d: FTBFS on armel: unsatisfiable build-dependencies: dh-dlang (>= 0.6.2), gir-to-d (>= 0.23.2)
Control: found -1 2.4.3-1 Hi, On Sat, 20 Apr 2024 15:22:43 +0200 Lucas Nussbaum wrote: Source: glib-d Version: 2.4.3-2 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel Hi, During a rebuild of all packages in sid, your package failed to build on armel. Relevant part (hopefully): > sbuild-build-depends-main-dummy : Depends: dh-dlang (>= 0.6.2) but it is not going to be installed >Depends: gir-to-d (>= 0.23.2) but it is not installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. This is because dh-dlang / gir-to-d no longer support armel and have been removed, see #1068983. I guess glib-d should be removed from armel as well. Cheers, Emilio
Bug#1071110: libjson-glib-dev: ships installed tests, causing b-d cycles
Package: libjson-glib-dev
Version: 1.8.0-2
Severity: serious
Hi,
libjson-glib-dev ships tests in /usr/lib/x86_64-linux-gnu/installed-tests/,
which makes the package get a dependency on libglib2.0-0t64 through
shlibs:Depends. That in turn causes b-d cycles, e.g. for fcitx-kkc on
arm{el,hf}:
fcitx-kkc build-depends on:
- libjson-glib-dev:armel
libjson-glib-dev depends on:
- libglib2.0-0t64:armel (>= 2.77.0)
fcitx-kkc build-depends on:
- libkkc-dev:armel
libkkc-dev depends on:
- libkkc2:armel (= 0.3.5-8)
libkkc2 depends on:
- libglib2.0-0:armel (>= 2.38.0)
libglib2.0-0t64 conflicts with:
- libglib2.0-0:armel (< 2.80.0-7~)
Splitting the tests into a json-glib-tests package would help break this
cycle.
Cheers,
Emilio
Bug#1070447: sdpa: dependency generation does not account for t64 changes
On Sun, 5 May 2024 15:35:40 +0200 Sebastian Ramacher
wrote:
Source: sdpa
Version: 7.3.16+dfsg-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Dependencies on libmumps-seq are produced using ${mumps-seq:Version}
which does not include the changes from the t64 transition. Please adopt
the dependency generation accordingly.
From what I can see, libmumps-seq is statically linked into the sdpa binary.
Why is it not dynamically linked, like everything else? If it needs to be
statically linked, why do we need a dependency on the shared library package?
Instead of that, we should probably add a built-using field to the binary
package, so that rebuilds can be scheduled when libmumps-seq changes, so that
the statically-linked library gets updated.
Cheers,
Emilio
Bug#1070977: transition: snappy
On 12/05/2024 11:36, László Böszörményi (GCS) wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:snappy Hi RMs, Upstream of snappy changed function signatures [1] breaking other applications with the 1.2.0 release. I've added back the original function signatures calling the new ones to restore the immediate problem, to restore the ABI. But then this creates ambiguity in the Compress method signatures [2] making (only) ceph FTBFS. While it can be patched to avoid it, a proper transition should be done. I've renamed back the library name which was done due to the C++11 ABI change with g++ 5.0 back in 2015. Why is there a libsnappy1v5 transitional package? Also has upstream been contacted in order to do a proper SONAME bump? Otherwise libsnappy1 will have to conflict with libsnappy1v5, and that will make both the transition and upgrades harder, as they have to be done in lockstep. If they broke the ABI, then a SONAME bump is in order, and that will make it easier for us too. Cheers, Emilio
Bug#1065281: evolution-data-server: missing dpkg-dev (>= 1.22.5) build dependnecy for time_t transition
Control: notfound -1 3.51.2-1 Control: found -1 3.50.3-2 Control: fixed -1 3.50.3-2.1 On Sat, 2 Mar 2024 11:53:00 +0100 Sebastian Ramacher wrote: Source: evolution-data-server Version: 3.51.2-1 Severity: serious X-Debbugs-Cc: sramac...@debian.org, vor...@debian.org Thank you for uploading the changes required for the time_t transition. Unfortunately, the upload was missing dpkg-dev (>= 1.22.5) in Build-Depends. This leads to two potential issues: * The package is built with the wrong ABI. * The package migrates to testing before the change is enabled in testing and builds there would be produced against the wrong ABI. Please add dpkg-dev (>= 1.22.5) to Build-Depends and upload the new version ASAP. I believe the found version here was wrong. It should have been against the uploaded version to unstable at the time, which was subsequently fixed in 3.50.3-2.1. Updating this to un-confuse the BTS and britney. Cheers, Emilio
Bug#1070799: bullseye-pu: package rustc-web/1.70.0+dfsg1-7~deb11u1
On 12/05/2024 13:09, Jonathan Wiltshire wrote: Control: tag -1 confimed moreinfo Hi, On Thu, May 09, 2024 at 12:36:16PM +0200, Emilio Pozuelo Monfort wrote: rustc-web is needed to keep supporting firefox-esr/thunderbird on bullseye, for the upcoming ESR 128 releases. Instead of updating rustc-mozilla, I decided to backport the newer rustc-web (adopting that name) from bookworm. The backport is clean, just a changelog bump. I'm attaching the debdiff from the bookworm update to this one. Should rustc-mozilla be removed from oldstable as well as rustc-web introduced? Only if we can switch current versions of firefox-esr/thunderbird to use it. Alternatively I could rename this back to rustc-mozilla if that's preferred (again assuming current versions are happy with it, as the new versions won't be uploaded until around September). Cheers, Emilio
Bug#1060019: transition: poppler 24.02
Control: tags -1 confirmed On 05/05/2024 23:33, Jeremy Bícha wrote: Control: retitle -1 transition: poppler 24.02 Control: affects -1 src:poppler Since originally requesting this transition, I have updated the version to 24.02. I believe all reverse dependencies can be binNMU'd for this. Go ahead. Emilio
Bug#1069254: nwipe: FTBFS: configure: error: libconfig library not found
On Mon, 29 Apr 2024 16:56:55 +0200 "M. van Brummelen" wrote: Hi, On 2024-04-29 10:28, Bo YU wrote: > Tags: patch > > hi, > On Thu, Apr 18, 2024 at 10:00:30PM +0200, Sebastian Ramacher wrote: >> >> checking for libconfig... no >> checking for main in -llibconfig... no >> configure: error: libconfig library not found > > It seems it shuold use libconfig-dev. Thanks didn't have the time to test/verify this yet. Will test/fix and upload in a few days. You should also look at doing source-only uploads. The current package, even if it had built fine, wouldn't have migrated to testing due to the source+amd64 upload: $ grep-excuses nwipe [...] Issues preventing migration: ∙ ∙ Updating nwipe would introduce bugs in testing: #1069254 ∙ ∙ Not built on buildd: arch amd64 binaries uploaded by mart...@brumit.nl Cheers, Emilio
Bug#1066831: tagging 1066831
Hi Wouter, On Wed, 03 Apr 2024 14:17:38 +0200 Wouter Verhelst wrote: tags 1066831 + upstream fixed-upstream pending thanks Can we have a fix for this in sid? That would help with some ongoing transitions, and probably with some installability issues on arm* on testing. Thanks, Emilio
Bug#1070799: bullseye-pu: package rustc-web/1.70.0+dfsg1-7~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hi, rustc-web is needed to keep supporting firefox-esr/thunderbird on bullseye, for the upcoming ESR 128 releases. Instead of updating rustc-mozilla, I decided to backport the newer rustc-web (adopting that name) from bookworm. The backport is clean, just a changelog bump. I'm attaching the debdiff from the bookworm update to this one. Package is already uploaded, but if you find any issues feel free to reject it. Hopefully this can make it into the final bullseye point release. I've successfully used this to build a backport of cbindgen and then firefox 125, which works well. A cbindgen pu for both bookworm and bullseye will be proposed later once I verify that it doesn't cause any issues to current ESR 115. Thanks, Emilio diff -Nru rustc-web-1.70.0+dfsg1/debian/changelog rustc-web-1.70.0+dfsg1/debian/changelog --- rustc-web-1.70.0+dfsg1/debian/changelog 2024-03-02 08:23:15.0 +0100 +++ rustc-web-1.70.0+dfsg1/debian/changelog 2024-04-29 11:08:43.0 +0200 @@ -1,3 +1,10 @@ +rustc-web (1.70.0+dfsg1-7~deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Backport to bullseye. + + -- Emilio Pozuelo Monfort Mon, 29 Apr 2024 11:08:43 +0200 + rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium * Non-maintainer upload.
Bug#1070751: transition: libxlsxwriter
Control: tags -1 confirmed On 08/05/2024 15:40, Boyuan Yang wrote: Package: release.debian.org Control: affects -1 + src:libxlsxwriter X-Debbugs-Cc: libxlsxwri...@packages.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: by...@debian.org Severity: normal I would like to launch the transition as listed below: * https://release.debian.org/transitions/html/auto-libxlsxwriter.html The transition is triggered by the SONAME bump. List of all affected packages: * src:deepin-log-viewer (OK) * src:readstat (OK) All reverse build-dependencies can be successfully rebuilt with the new libxlsxwriter. Go ahead. Emilio
Bug#1070703: transition: libunibreak
Control: tags -1 confirmed On 07/05/2024 15:52, Pino Toscano wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libunibr...@packages.debian.org Control: affects -1 + src:libunibreak User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a transition slot for the update of the libunibreak library 5.1 to 6.1. Each new major version bumps the SOVERSION, and in this case there are only few new symbols. There are few users of libunibreak in Debian: - fbreader - krita - libass I verified that all of them build fine using the new version of libunibreak. Go ahead. Emilio
Bug#1070698: transition: ticcutils
Control: tags -1 confirmed On 07/05/2024 14:21, Bastian Germann wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: ticcut...@packages.debian.org Control: affects -1 + src:ticcutils Control: forwarded -1 https://release.debian.org/transitions/html/auto-ticcutils.html User: release.debian@packages.debian.org Usertags: transition I am requesting a transition slot for ticcutils. The experimental version builds libticcutils9 while the unstable version has libticcutils8t64. The referenced tracker is okay. All reverse dependencies build with the experimental version (where an experimental version exists, it is the one that builds with libticcutils9). Go ahead. Emilio
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
