Bug#986658: unblock: polymake/4.3-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Please unblock package polymake
[ Reason ]
This fixes #986381, which could be classified severity important
[ Impact ]
There is no 3D visualization facility in the version in testing.
[ Tests ]
I have manually tested that the fix in the package (proposed by
upstream) restores the visualization facility.
[ Risks ]
This is low risk. The visualization facility is seperate pile of JS
from the rest of project, so even if I botched that, it won't affect
the previously working functionality. Polymake is of course a non-key,
leaf package.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock polymake/4.3-4
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmBvkh4ACgkQA0U5G1Wq
FSFPfw/8CIiriDj2S4KSnSrsOgklKJc+d32QgCa8oHgMtL5hfSRVOP0DHpNAPjHb
4Y7xSKCqiT/sgIdt8AYlyM7Dfk/O86mlagZC6bNYGcK1x/XZqOQ6YPW6/ARaQrny
CC1vstSrFNFsXLP+P2TvSgVxNBONm34pnVi582CEs/MSIjzICj+RbT6oQR63cA6E
6NH3FLK5TRKLW9OcS9xzwEB1J94tPvrd/nMQAv2UHpI283symjyrxilBNat/CT1q
2r2fWDtx1Qv0C+8vHi7rpSiViDRgGsjyjAf3aKEpBXoUKMrJE5o8lhSrV+3tt23t
vpVzaEZHxPHNIClpu3ioKBpEe24SVqy0HB1ixxBiSv+9UpsBtOxFmyfeL2U+shfH
A5w+fD07E4LYs8x09UZjrC7MJwc2MWExBF8JNs7v5oC8zzUnWWa6zm91x2fFnyXj
lD6fdA5flivEiEh9JjfZqaSfnNqOHTZn4rAp/3TYn0nEUMP6UpZw8A75feHOKaUT
12T2MLGqm2oV1Wj7elT7LqqfoT/jaEB4pGtJWy5dCh6hx0g5Jp9RWaBii9XY0zHv
TDK6hqFr2QdzcdVl7Te9PuJMmoz1kxXTD2vVMS8INAciecwXLZt6OSPrdnFZIFGG
ZuiY6A63nmMhML5AnbOjrK8SeN+GaHWbkEkZr77DO8JCkj5SfLY=
=l6KS
-END PGP SIGNATURE-
diff -Nru polymake-4.3/debian/changelog polymake-4.3/debian/changelog
--- polymake-4.3/debian/changelog 2021-01-29 20:45:56.0 -0400
+++ polymake-4.3/debian/changelog 2021-04-07 11:56:59.0 -0300
@@ -1,3 +1,10 @@
+polymake (4.3-4) unstable; urgency=medium
+
+ * Bug fix: "VISUAL with threejs fails", thanks to Joachim Zobel (Closes:
+#986381).
+
+ -- David Bremner Wed, 07 Apr 2021 11:56:59 -0300
+
polymake (4.3-3) unstable; urgency=medium
* Disable relative volume test when flint is missing (Closes: #981252).
diff -Nru polymake-4.3/debian/rules polymake-4.3/debian/rules
--- polymake-4.3/debian/rules 2021-01-29 20:45:56.0 -0400
+++ polymake-4.3/debian/rules 2021-04-07 11:56:59.0 -0300
@@ -28,7 +28,7 @@
export CFLAGS CXXFLAGS CPPFLAGS LDFLAGS
-JS:= OrbitControls.js Projector.js SVGRenderer.js three.js
TrackballControls.js WebGL.js
+JS:= three.js OrbitControls.js Projector.js SVGRenderer.js
TrackballControls.js WebGL.js
JSSOURCE=$(addprefix external/js/,${JS})
build build-arch build-indep binary binary-arch binary-indep clean:
Bug#986628: unblock: r-cran-rcdklibs/2.3+dfsg-6
Hi Andreas, On 08-04-2021 21:52, Andreas Tille wrote: > Ahhh, I assumed that basic autopkgtest-pkg-r is consider superficial. That's an interesting point. Should they (they're not)? Maybe with R packages autopkgtest-pkg-r may or may not be very extensive? If that's true, than it's currently basically up to individual packages to mark themselves superficial when using autopkgtest-pkg-r. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986628: unblock: r-cran-rcdklibs/2.3+dfsg-6
Hi Sebastian, On Thu, Apr 08, 2021 at 05:47:04PM +0200, Sebastian Ramacher wrote: > > > > unblock r-cran-rcdklibs/2.3+dfsg-6 > > This package will need another: > > Not built on buildd: arch all binaries uploaded by tille, a new source-only > upload is needed to allow migration Aaaargh, stupid mistake - thanks for watching me. > Since the package is not a key package and has autopkgtests, an unblock > is not required. Ahhh, I assumed that basic autopkgtest-pkg-r is consider superficial. Kind regards Andreas. -- http://fam-tille.de
Bug#986625: unblock: grub2/2.04-17
Control: tags -1 d-i confirmed
Hi,
Putting kibi in CC for the d-i ACK, just to be sure.
Paul
On 08-04-2021 12:25, Colin Watson wrote:
> Please unblock grub2 2.04-17. The --sbat fix will be needed for d-i
> builds once various bits of work on shim are finished, and the verifiers
> module change helps core images fit in the constrained space that's
> often all that's available on BIOS systems.
>
> You may need to manually unblock grub-efi-{amd64,arm64,ia32}-signed as
> well to match, since these four source packages must all have matching
> versions - I'm not sure exactly how the tools work from your end.
>
> diff -Nru grub2-2.04/debian/.git-dpm grub2-2.04/debian/.git-dpm
> --- grub2-2.04/debian/.git-dpm2021-03-02 18:00:00.0 +
> +++ grub2-2.04/debian/.git-dpm2021-03-19 10:41:41.0 +
> @@ -1,6 +1,6 @@
> # see git-dpm(1) from git-dpm package
> -9cd32c57605b7ad713e108e0b98ebd504caa532e
> -9cd32c57605b7ad713e108e0b98ebd504caa532e
> +3d246c561a2c6aa18b78eae69e5100a2347dc7aa
> +3d246c561a2c6aa18b78eae69e5100a2347dc7aa
> 578bb115fbd47e1c464696f1f8d6183e5443975d
> 578bb115fbd47e1c464696f1f8d6183e5443975d
> grub2_2.04.orig.tar.xz
> diff -Nru grub2-2.04/debian/build-efi-images
> grub2-2.04/debian/build-efi-images
> --- grub2-2.04/debian/build-efi-images2021-03-02 18:00:00.0
> +
> +++ grub2-2.04/debian/build-efi-images2021-03-19 10:41:41.0
> +
> @@ -224,6 +224,8 @@
> "$grub_mkimage" -O "$platform" -o "$outdir/grubnet$efi_name-installer.efi" \
> -d "$grub_core" -c "$workdir/grub-bootstrap.cfg" \
> -m "$workdir/memdisk-netboot.fat" \
> - -p "/${efi_vendor}-installer/$deb_arch/grub" $NET_MODULES
> + -p "/${efi_vendor}-installer/$deb_arch/grub" \
> + --sbat "$sbat_csv" \
> + $NET_MODULES
>
> exit 0
> diff -Nru grub2-2.04/debian/changelog grub2-2.04/debian/changelog
> --- grub2-2.04/debian/changelog 2021-03-02 18:00:00.0 +
> +++ grub2-2.04/debian/changelog 2021-03-19 10:41:41.0 +
> @@ -1,3 +1,11 @@
> +grub2 (2.04-17) unstable; urgency=medium
> +
> + * Pass --sbat when building the d-i netboot image as well.
> + * i386-pc: build verifiers API as module (thanks, Michael Chang; closes:
> +#984488, #985374).
> +
> + -- Colin Watson Fri, 19 Mar 2021 10:41:41 +
> +
> grub2 (2.04-16) unstable; urgency=medium
>
>* Fix broken advice in message when the postinst has to bail out (thanks
> diff -Nru grub2-2.04/debian/patches/pc-verifiers-module.patch
> grub2-2.04/debian/patches/pc-verifiers-module.patch
> --- grub2-2.04/debian/patches/pc-verifiers-module.patch 1970-01-01
> 01:00:00.0 +0100
> +++ grub2-2.04/debian/patches/pc-verifiers-module.patch 2021-03-19
> 10:41:41.0 +
> @@ -0,0 +1,167 @@
> +From 3d246c561a2c6aa18b78eae69e5100a2347dc7aa Mon Sep 17 00:00:00 2001
> +From: Michael Chang
> +Date: Thu, 18 Mar 2021 19:30:26 +0800
> +Subject: i386-pc: build verifiers API as module
> +
> +Given no core functions on i386-pc would require verifiers to work and
> +the only consumer of the verifier API is the pgp module, it looks good
> +to me that we can move the verifiers out of the kernel image and let
> +moddep.lst to auto-load it when pgp is loaded on i386-pc platform.
> +
> +This helps to reduce the size of core image and thus can relax the
> +tension of exploding on some i386-pc system with very short MBR gap
> +size. See also a very comprehensive summary from Colin [1] about the
> +details.
> +
> +[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00240.html
> +
> +V2:
> +Drop COND_NOT_i386_pc and use !COND_i386_pc.
> +Add comment in kern/verifiers.c to help understanding what's going on
> +without digging into the commit history.
> +
> +Reported-by: Colin Watson
> +Reviewed-by: Colin Watson
> +Signed-off-by: Michael Chang
> +
> +Origin: other,
> https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00251.html
> +Bug-Debian: https://bugs.debian.org/984488
> +Bug-Debian: https://bugs.debian.org/985374
> +Last-Update: 2021-03-18
> +
> +Patch-Name: pc-verifiers-module.patch
> +---
> + grub-core/Makefile.am | 2 ++
> + grub-core/Makefile.core.def | 8 +++-
> + grub-core/kern/main.c | 4
> + grub-core/kern/verifiers.c | 17 +
> + include/grub/verify.h | 9 +
> + 5 files changed, 39 insertions(+), 1 deletion(-)
> +
> +diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
> +index 5308caa7b..4900265a4 100644
> +--- a/grub-core/Makefile.am
> b/grub-core/Makefile.am
> +@@ -92,7 +92,9 @@ KERNEL_HEADER_FILES +=
> $(top_srcdir)/include/grub/partition.h
> + KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/stack_protector.h
> + KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/term.h
> + KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/time.h
> ++if !COND_i386_pc
> + KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/verify.h
> ++endif
> + KERNEL_HEADER_FILES
Processed: Re: Bug#986625: unblock: grub2/2.04-17
Processing control commands: > tags -1 d-i confirmed Bug #986625 [release.debian.org] unblock: grub2/2.04-17 Added tag(s) d-i and confirmed. -- 986625: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986625 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 986572
Processing commands for cont...@bugs.debian.org: > tags 986572 - moreinfo Bug #986572 [release.debian.org] unblock: osm2pgsql/1.4.1+ds-2 (pre-approval) Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 986572: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986572 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#986572: unblock: osm2pgsql/1.4.1+ds-2 (pre-approval)
Control: trags -1 - moreinfo On 4/8/21 8:31 PM, Sebastian Ramacher wrote: > On 2021-04-07 16:17:45 +0200, Bas Couwenberg wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> To fix two important issues affecting the version in bullseye, >> I would like to upload these changes to unstable. >> >> Do you agree that these changes are appropriate for a freeze exception? > > Assuming that the upload happens soon, please go ahead. Please remove > the moreinfo tag once the version is available in unstable. Thanks for the feedback, the package was just uploaded to unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#986602: unblock: mkvtoolnix/54.0.0-2
On 2021-04-08 17:45:41 +0200, Mattia Rizzolo wrote: > On Thu, Apr 08, 2021 at 05:34:40PM +0200, Sebastian Ramacher wrote: > > * Mark #986520 as bullseye-ignore and if a there is a need to fix > > another issues in a bullsey-pu upload, switch CXX to g++-9 in that > > upload. From what I understand, this workaround is supposed to also > > work for 52.0.0. > > Something like that usually is approved for a p-u, as release team > member is your right to decide what to tag bullseye-ignore, but that > would also pretty much hide the bugs from the list of bullseye bugs. If > you really went down that route I'd rather see you use your usertags to > hide it from the udd view only during the release process rather tha > ignore it forever. > And, since this is p-u material in stable, couldn't one upload > 52.0.0-1+deb11u1 to t-p-u just changing CXX? We prefer not to use tpu for such cases. This issue can be fixed via unstable by reverting to 52.0.0 with the +really dance as well. So there is no need to upload the fix via tpu. Cheers > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > More about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- -- Sebastian Ramacher signature.asc Description: PGP signature
Processed: Re: Bug#986572: unblock: osm2pgsql/1.4.1+ds-2 (pre-approval)
Processing control commands: > tags -1 confirmed moreinfo Bug #986572 [release.debian.org] unblock: osm2pgsql/1.4.1+ds-2 (pre-approval) Added tag(s) confirmed and moreinfo. -- 986572: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986572 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#986572: unblock: osm2pgsql/1.4.1+ds-2 (pre-approval)
Control: tags -1 confirmed moreinfo
On 2021-04-07 16:17:45 +0200, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> To fix two important issues affecting the version in bullseye,
> I would like to upload these changes to unstable.
>
> Do you agree that these changes are appropriate for a freeze exception?
Assuming that the upload happens soon, please go ahead. Please remove
the moreinfo tag once the version is available in unstable.
Cheers
>
> [ Reason ]
> Fixes important issues.
>
> [ Impact ]
> Poor performance and errors.
>
> [ Tests ]
> Upstream CI.
>
> [ Risks ]
> Low.
>
> [ Checklist ]
> [x] all changes are documented in the d/changelog
> [x] I reviewed all changes and I approve them
> [x] attach debdiff against the package in testing
>
> [ Other info ]
> N/A
>
> unblock osm2pgsql/1.4.1+ds-2
>
> Kind Regards,
>
> Bas
> diff -Nru osm2pgsql-1.4.1+ds/debian/changelog
> osm2pgsql-1.4.1+ds/debian/changelog
> --- osm2pgsql-1.4.1+ds/debian/changelog 2021-02-04 05:23:03.0
> +0100
> +++ osm2pgsql-1.4.1+ds/debian/changelog 2021-04-07 15:59:14.0
> +0200
> @@ -1,3 +1,14 @@
> +osm2pgsql (1.4.1+ds-2) unstable; urgency=medium
> +
> + * Update watch file for GitHub URL changes.
> + * Add upstream patches:
> +- 0001-Bugfix-Disable-expire-in-flex-output-when-not-used.patch
> + Important performance fix.
> +- 0001-Bug-fix-Remove-schema-name-from-CREATE-INDEX.patch
> + Fix CREATE INDEX failure.
> +
> + -- Bas Couwenberg Wed, 07 Apr 2021 15:59:14 +0200
> +
> osm2pgsql (1.4.1+ds-1) unstable; urgency=medium
>
>* New upstream release.
> diff -Nru
> osm2pgsql-1.4.1+ds/debian/patches/0001-Bugfix-Disable-expire-in-flex-output-when-not-used.patch
>
> osm2pgsql-1.4.1+ds/debian/patches/0001-Bugfix-Disable-expire-in-flex-output-when-not-used.patch
> ---
> osm2pgsql-1.4.1+ds/debian/patches/0001-Bugfix-Disable-expire-in-flex-output-when-not-used.patch
>1970-01-01 01:00:00.0 +0100
> +++
> osm2pgsql-1.4.1+ds/debian/patches/0001-Bugfix-Disable-expire-in-flex-output-when-not-used.patch
>2021-04-07 15:56:01.0 +0200
> @@ -0,0 +1,31 @@
> +Description: Bugfix: Disable expire in flex output when not used
> + If we don't have expire enabled we never need to create an expire list.
> + But as a side effect of the two-stage processing we created such a list
> + which costs a lot of time and RAM. This commit disables this which
> + speeds up processing considerably.
> +Author: Jochen Topf
> +Origin: https://github.com/openstreetmap/osm2pgsql/issues/1436
> +Bug: https://github.com/openstreetmap/osm2pgsql/issues/1436
> +
> +--- a/src/expire-tiles.hpp
> b/src/expire-tiles.hpp
> +@@ -60,6 +60,8 @@ struct expire_tiles
> + expire_tiles(uint32_t maxzoom, double maxbbox,
> + const std::shared_ptr );
> +
> ++bool enabled() const noexcept { return maxzoom != 0; }
> ++
> + int from_bbox(double min_lon, double min_lat, double max_lon,
> + double max_lat);
> + void from_wkb(char const *wkb, osmid_t osm_id);
> +--- a/src/output-flex.cpp
> b/src/output-flex.cpp
> +@@ -1289,7 +1289,7 @@ void output_flex_t::delete_from_table(ta
> + assert(table_connection);
> + auto const id = table_connection->table().map_id(type, osm_id);
> +
> +-if (table_connection->table().has_geom_column()) {
> ++if (m_expire.enabled() && table_connection->table().has_geom_column()) {
> + auto const result = table_connection->get_geom_by_id(type, id);
> +
> + if (result.num_tuples() == 0) {
> diff -Nru
> osm2pgsql-1.4.1+ds/debian/patches/0001-Bug-fix-Remove-schema-name-from-CREATE-INDEX.patch
>
> osm2pgsql-1.4.1+ds/debian/patches/0001-Bug-fix-Remove-schema-name-from-CREATE-INDEX.patch
> ---
> osm2pgsql-1.4.1+ds/debian/patches/0001-Bug-fix-Remove-schema-name-from-CREATE-INDEX.patch
> 1970-01-01 01:00:00.0 +0100
> +++
> osm2pgsql-1.4.1+ds/debian/patches/0001-Bug-fix-Remove-schema-name-from-CREATE-INDEX.patch
> 2021-04-07 15:56:19.0 +0200
> @@ -0,0 +1,21 @@
> +Description: Bug fix: Remove schema name from CREATE INDEX
> + Indexes are always created in the same schema as the table.
> +Author: Jochen Topf
> +Origin: https://github.com/openstreetmap/osm2pgsql/issues/1436
> +Bug: https://github.com/openstreetmap/osm2pgsql/issues/1447
> +
> +--- a/src/middle-pgsql.cpp
> b/src/middle-pgsql.cpp
> +@@ -714,9 +714,9 @@ static table_sql sql_for_ways(bool has_b
> + " SELECT ARRAY(SELECT DISTINCT"
> + "unnest($1) >> {way_node_index_id_shift})\n"
> + "$$ LANGUAGE SQL IMMUTABLE;\n"
> +-"CREATE INDEX {schema}{prefix}_ways_nodes_bucket_idx"
> +-" ON {schema}{prefix}_ways"
> +-" USING GIN ({schema}{prefix}_index_bucket(nodes))"
> ++"CREATE INDEX \"{prefix}_ways_nodes_bucket_idx\""
> ++
Bug#986646: unblock: vala/0.48.16-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ric...@ubuntu.com
Please unblock package vala
[ Reason ]
Vala 0.48.x series is a Long-Term support version and receives important bug
fixes and binding fixes.
It is part of GNOME SDK and improves the stability of the vala compiler shipped
in Debian.
Upstream summary at
https://gitlab.gnome.org/GNOME/vala/-/commit/429b7194a9a520dc4a057db8aa1257520e686fdd
[ Impact ]
Vala is a compiler and affects every reverse-dependency.
[ Tests ]
The vala 0.48.x series is constantly used by current package set of Debian
testing.
The upstream test suite is extended with every release.
http://ci.vala-project.org:8010/builders/vala-0.48/builds/43
[ Risks ]
Vala is a compiler and affects every reverse-dependency.
[ Other info ]
Upstream between 0.48.14 and 0.48.15
https://gitlab.gnome.org/GNOME/vala/-/compare/10166000cbf8963cfebae5e15fa0f13b15791308...429b7194a9a520dc4a057db8aa1257520e686fdd
unblock vala/0.48.16-1
diff --git a/NEWS b/NEWS
index e78d744d0..4bf72f071 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,26 @@
+Vala 0.48.16
+
+ * Various improvements and bug fixes:
+ - codegen:
++ Improve handling of ellipsis parameter in get_ccode_name()
++ Fix default value of get_ccode_destroy_notify_pos()
++ Don't override valid target/destroy of previous lambda argument [#59]
++ Don't call *_instance_init() in compact class chainup
+ - vala: Mark tranformed static member-access as qualified [#270]
+ - girwriter: namespace expects "c:symbol-prefixes" attribute [#1038]
+ - girwriter: Don't use instance-parameter inside callback [#1167]
+ - girparser,libvaladoc/girimporter: Don't guess length of xml header, iterate
+forward to
+ - libvaladoc/girimporter: parse_constant() use "c:identifier" attribute first
+
+ * Bindings:
+ - rest-0.7: Fix OAuthProxyAuthCallback binding
+ - gtk+-3.0: Fix ModuleInitFunc binding
+ - gio-2.0: Fix TlsPassword.get_value() binding
+ - Fix several bindings which lead to invalid code by using them in:
+javascriptcoregtk-4.0, libusb, libusb-1.0, pixman-1,
+webkit2gtk-web-extension-4.0, x11, zlib,
+
Vala 0.48.15
* Various improvements and bug fixes:
diff --git a/codegen/valaccode.vala b/codegen/valaccode.vala
index 7671b2c50..9b1da33f7 100644
--- a/codegen/valaccode.vala
+++ b/codegen/valaccode.vala
@@ -365,12 +365,7 @@ namespace Vala {
if (a != null && a.has_argument ("destroy_notify_pos")) {
return a.get_double ("destroy_notify_pos");
}
- if (node is Parameter) {
- unowned Parameter param = (Parameter) node;
- return get_ccode_pos (param) + 0.1;
- } else {
- return -3;
- }
+ return get_ccode_delegate_target_pos (node) + 0.01;
}
public static bool get_ccode_delegate_target (CodeNode node) {
diff --git a/codegen/valaccodearraymodule.vala
b/codegen/valaccodearraymodule.vala
index 851778171..9bfe9db59 100644
--- a/codegen/valaccodearraymodule.vala
+++ b/codegen/valaccodearraymodule.vala
@@ -606,7 +606,7 @@ public class Vala.CCodeArrayModule : CCodeMethodCallModule {
ccode.add_return (new CCodeIdentifier ("result"));
ccode.close ();
- ccode.add_return (new CCodeIdentifier ("NULL"));
+ ccode.add_return (new CCodeConstant ("NULL"));
} else {
// only dup if length > 0, this deals with negative
lengths and returns NULL
var length_check = new CCodeBinaryExpression
(CCodeBinaryOperator.GREATER_THAN, new CCodeIdentifier ("length"), new
CCodeConstant ("0"));
@@ -644,7 +644,7 @@ public class Vala.CCodeArrayModule : CCodeMethodCallModule {
}
ccode.close ();
- ccode.add_return (new CCodeIdentifier ("NULL"));
+ ccode.add_return (new CCodeConstant ("NULL"));
}
// append to file
diff --git a/codegen/valaccodeattribute.vala b/codegen/valaccodeattribute.vala
index e647b4152..b1e84583e 100644
--- a/codegen/valaccodeattribute.vala
+++ b/codegen/valaccodeattribute.vala
@@ -771,7 +771,18 @@ public class Vala.CCodeAttribute : AttributeCache {
}
} else if (sym is Signal) {
return Symbol.camel_case_to_lower_case
(sym.name).replace ("_", "-");;
- } else if (sym is LocalVariable || sym is Parameter) {
+ } else if (sym is LocalVariable) {
+ unowned string name = sym.name;
+ if
(CCodeBaseModule.reserved_identifiers.contains (name)) {
+ return
Bug#986602: unblock: mkvtoolnix/54.0.0-2
On 08 avril 2021 19:13, Christian Marillat wrote: > On 08 avril 2021 17:45, Mattia Rizzolo wrote: > >> On Thu, Apr 08, 2021 at 05:34:40PM +0200, Sebastian Ramacher wrote: >>> * Mark #986520 as bullseye-ignore and if a there is a need to fix >>> another issues in a bullsey-pu upload, switch CXX to g++-9 in that >>> upload. From what I understand, this workaround is supposed to also >>> work for 52.0.0. >> >> Something like that usually is approved for a p-u, as release team >> member is your right to decide what to tag bullseye-ignore, but that >> would also pretty much hide the bugs from the list of bullseye bugs. If >> you really went down that route I'd rather see you use your usertags to >> hide it from the udd view only during the release process rather tha >> ignore it forever. >> And, since this is p-u material in stable, couldn't one upload >> 52.0.0-1+deb11u1 to t-p-u just changing CXX? > > Really good idea and probably the best solution. > > If release team agree, should I upload to unstable or t-p-u ? Answer to myself t-p-u Christian
Bug#986602: unblock: mkvtoolnix/54.0.0-2
On 08 avril 2021 17:45, Mattia Rizzolo wrote: > On Thu, Apr 08, 2021 at 05:34:40PM +0200, Sebastian Ramacher wrote: >> * Mark #986520 as bullseye-ignore and if a there is a need to fix >> another issues in a bullsey-pu upload, switch CXX to g++-9 in that >> upload. From what I understand, this workaround is supposed to also >> work for 52.0.0. > > Something like that usually is approved for a p-u, as release team > member is your right to decide what to tag bullseye-ignore, but that > would also pretty much hide the bugs from the list of bullseye bugs. If > you really went down that route I'd rather see you use your usertags to > hide it from the udd view only during the release process rather tha > ignore it forever. > And, since this is p-u material in stable, couldn't one upload > 52.0.0-1+deb11u1 to t-p-u just changing CXX? Really good idea and probably the best solution. If release team agree, should I upload to unstable or t-p-u ? Christian
Bug#986617: marked as done (unblock: node-rollup-pluginutils/4.1.0+~2.8.2-3)
Your message dated Thu, 08 Apr 2021 15:48:19 +
with message-id
and subject line unblock node-rollup-pluginutils
has caused the Debian Bug report #986617,
regarding unblock: node-rollup-pluginutils/4.1.0+~2.8.2-3
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
986617: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986617
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package node-rollup-pluginutils
[ Reason ]
node-rollup-pluginutils has a broken symlink due to
node-typescript-types deprecation. This patch updates dependencies to
package that ship the good @types/* files (#985702)
[ Impact ]
A broken symlink and maybe missing dependencies when using
node-rollup-pluginutils with tsc (node-typescript)
[ Tests ]
Tests passed because some build dependencies are updated
[ Risks ]
Trivial patch, just updates dependencies (node-typescript-types is now a
transitional package that points to virtual node-types-node)
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock node-rollup-pluginutils/4.1.0+~2.8.2-3
diff --git a/debian/changelog b/debian/changelog
index ff4da4b..68603db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-rollup-pluginutils (4.1.0+~2.8.2-3) unstable; urgency=medium
+
+ * Team upload
+ * Replace deprecated dependency to node-typescript-types by dependencies to
+node-types-estree and node-types-node (Closes: #979762, #979775, #985702)
+
+ -- Yadd Mon, 22 Mar 2021 12:45:55 +0100
+
node-rollup-pluginutils (4.1.0+~2.8.2-2) unstable; urgency=medium
* Team upload
diff --git a/debian/control b/debian/control
index 6f6f43d..c5ab2ea 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
, node-rollup-plugin-node-resolve
, node-rollup-plugin-typescript
, node-typescript (>= 3.7~)
- , node-typescript-types
+ , node-types-estree
, nodejs (>= 10~)
, dh-sequence-nodejs
, rollup (>= 1)
@@ -31,7 +31,8 @@ Depends:
${misc:Depends}
, node-estree-walker
, node-micromatch (>= 4.0~)
- , node-typescript-types
+ , node-types-estree
+ , node-types-node
Breaks: rollup (<< 1)
Suggests: node-rollup-plugin-typescript
Description: Base functionality for rollup plugins
--- End Message ---
--- Begin Message ---
Unblocked.--- End Message ---
Bug#986628: marked as done (unblock: r-cran-rcdklibs/2.3+dfsg-6)
Your message dated Thu, 8 Apr 2021 17:47:04 +0200
with message-id <20210408154704.gb28...@ramacher.at>
and subject line Re: Bug#986628: unblock: r-cran-rcdklibs/2.3+dfsg-6
has caused the Debian Bug report #986628,
regarding unblock: r-cran-rcdklibs/2.3+dfsg-6
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
986628: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986628
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 986...@bugs.debian.org
Please unblock package r-cran-rcdklibs
[ Reason ]
Fixing bug #986467.
[ Impact ]
The package would be unusable due to a missing Dependency.
[ Tests ]
Testsuite: autopkgtest-pkg-r
[ Risks ]
The package is a dependency of some leaf packages with a low
popcon value.
[ Checklist ]
[*] all changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in testing
unblock r-cran-rcdklibs/2.3+dfsg-6
diff -Nru r-cran-rcdklibs-2.3+dfsg/debian/changelog
r-cran-rcdklibs-2.3+dfsg/debian/changelog
--- r-cran-rcdklibs-2.3+dfsg/debian/changelog 2020-11-18 11:35:15.0
+0100
+++ r-cran-rcdklibs-2.3+dfsg/debian/changelog 2021-04-08 10:46:24.0
+0200
@@ -1,3 +1,10 @@
+r-cran-rcdklibs (2.3+dfsg-6) unstable; urgency=medium
+
+ * Add missing Depends libcdk-java
+Closes: #986467
+
+ -- Andreas Tille Thu, 08 Apr 2021 10:46:24 +0200
+
r-cran-rcdklibs (2.3+dfsg-5) unstable; urgency=medium
* Versioned (Build-)Depends to libcdk-java (>= 2.3.134.g1bb9a64587)
diff -Nru r-cran-rcdklibs-2.3+dfsg/debian/control
r-cran-rcdklibs-2.3+dfsg/debian/control
--- r-cran-rcdklibs-2.3+dfsg/debian/control 2020-11-18 11:35:15.0
+0100
+++ r-cran-rcdklibs-2.3+dfsg/debian/control 2021-04-08 10:46:24.0
+0200
@@ -8,7 +8,7 @@
dh-r,
r-base-dev,
r-cran-rjava,
- libcdk-java
+ libcdk-java (>= 2.3.134.g1bb9a64587)
Standards-Version: 4.5.1
Vcs-Browser: https://salsa.debian.org/r-pkg-team/r-cran-rcdklibs
Vcs-Git: https://salsa.debian.org/r-pkg-team/r-cran-rcdklibs.git
@@ -18,7 +18,8 @@
Package: r-cran-rcdklibs
Architecture: all
Depends: ${R:Depends},
- ${misc:Depends}
+ ${misc:Depends},
+ libcdk-java (>= 2.3.134.g1bb9a64587)
Recommends: ${R:Recommends}
Suggests: ${R:Suggests}
Description: Chemistry Development Kit (CDK) libraries packaged for GNU R
--- End Message ---
--- Begin Message ---
Hi Andreas
On 2021-04-08 13:18:06, Andreas Tille wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: 986...@bugs.debian.org
>
> Please unblock package r-cran-rcdklibs
>
> [ Reason ]
> Fixing bug #986467.
>
> [ Impact ]
> The package would be unusable due to a missing Dependency.
>
> [ Tests ]
> Testsuite: autopkgtest-pkg-r
>
> [ Risks ]
> The package is a dependency of some leaf packages with a low
> popcon value.
>
> [ Checklist ]
> [*] all changes are documented in the d/changelog
> [*] I reviewed all changes and I approve them
> [*] attach debdiff against the package in testing
>
>
> unblock r-cran-rcdklibs/2.3+dfsg-6
This package will need another:
Not built on buildd: arch all binaries uploaded by tille, a new source-only
upload is needed to allow migration
Since the package is not a key package and has autopkgtests, an unblock
is not required.
Cheers
> diff -Nru r-cran-rcdklibs-2.3+dfsg/debian/changelog
> r-cran-rcdklibs-2.3+dfsg/debian/changelog
> --- r-cran-rcdklibs-2.3+dfsg/debian/changelog 2020-11-18 11:35:15.0
> +0100
> +++ r-cran-rcdklibs-2.3+dfsg/debian/changelog 2021-04-08 10:46:24.0
> +0200
> @@ -1,3 +1,10 @@
> +r-cran-rcdklibs (2.3+dfsg-6) unstable; urgency=medium
> +
> + * Add missing Depends libcdk-java
> +Closes: #986467
> +
> + -- Andreas Tille Thu, 08 Apr 2021 10:46:24 +0200
> +
> r-cran-rcdklibs (2.3+dfsg-5) unstable; urgency=medium
>
>* Versioned (Build-)Depends to libcdk-java (>= 2.3.134.g1bb9a64587)
> diff -Nru r-cran-rcdklibs-2.3+dfsg/debian/control
> r-cran-rcdklibs-2.3+dfsg/debian/control
> --- r-cran-rcdklibs-2.3+dfsg/debian/control 2020-11-18 11:35:15.0
> +0100
> +++ r-cran-rcdklibs-2.3+dfsg/debian/control 2021-04-08 10:46:24.0
> +0200
> @@ -8,7 +8,7 @@
> dh-r,
> r-base-dev,
> r-cran-rjava,
> - libcdk-java
>
Bug#986631: marked as done (unblock: darktable/3.4.1-2)
Your message dated Thu, 08 Apr 2021 15:45:15 +
with message-id
and subject line unblock darktable
has caused the Debian Bug report #986631,
regarding unblock: darktable/3.4.1-2
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
986631: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986631
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Please unblock package darktable
[ Reason ]
This fixes a FTBFS.
[ Impact ]
A rebuild with DEB_BUILD_OPTIONS=parallel=1 will fail for the version
currently in testing. This is arguably RC.
[ Tests ]
I installed and ran the updated binary packgge in my development bullseye
system.
[ Risks ]
It's a leaf package. I added en extra dependency rule to the upstream
build system, so I guess given I'm not really a cmake expert that
could fail under some unforseen circumstances.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
A bullseye-ignore tag for the bug #986574 might also make sense (in
lieu of an unblock).
unblock darktable/3.4.1-2
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmBu+zIACgkQA0U5G1Wq
FSFMeBAAp3kAQnPjaDCqwqpKbSWUkLvLCqookAbq5+y0YF7fFPfoUCIqs7PfDF4h
DoQGkc43sYjQbHH5/LVwnL8wJqX7+960GsHk3IkGcFmsOFBfoeeSuVcZISsLzsbP
4L52nRWJ5Lvf2ncEIcZHuWYLZqXZSDInQWL5bejBOf/qtWteAJoBiNxQAxmSmzzZ
WTc088W6F0ovMlC9TYnMJxICpZyVzVs3HPPELRaqYKp1GYmqCiCZ56r1jOpApGap
gmXrG9j6wXloj5Iv1sJH7GrMcL5+tWd/OOCiX9h1oVxIVbMa27R98ssTBHNn3Sef
zPYPZT42ROXw7S6np7v+2y91U55nVbzvGo7wu8SoDePfErfDQyjx6Fn7zFq+LapG
F1jDpBTjbz3HPjnctmYzsGMhHZs2ciU4q+/Blj36OKjMzcedwmrYt72kCUVonSJq
QIGZIEFf3jCf1fUQg0a6VRNzTr1LqAP52mRXOsi6Jar9CjImipac12nYGo/eK5Sx
KqbMFAka1zC37zE3Vm/NrPDzoLZLaK9icpw3wNCSV7iFkw7fww0sKxdQgzvEW33k
B84BPDtPUQ7o3CPUAEi6dHdsnvE9N3o28946a5nXZAf+RO1FIaTMJlPMLb2lZP5N
+RThFF9RIEvJ7nufAO9vApiefkTw7DRoEjI0yuEn+NAHGLoob3Q=
=NrQ2
-END PGP SIGNATURE-
diff -Nru darktable-3.4.1/debian/changelog darktable-3.4.1/debian/changelog
--- darktable-3.4.1/debian/changelog2021-02-06 12:42:43.0 -0400
+++ darktable-3.4.1/debian/changelog2021-04-08 07:58:21.0 -0300
@@ -1,3 +1,11 @@
+darktable (3.4.1-2) unstable; urgency=medium
+
+ * Bug fix: "darktable FTBFS with DEB_BUILD_OPTIONS=parallel=1", thanks
+to Helmut Grohne (Closes: #986574). As Helmut guessed, the fix is to
+add a dependency to the CMake configuration.
+
+ -- David Bremner Thu, 08 Apr 2021 07:58:21 -0300
+
darktable (3.4.1-1) unstable; urgency=medium
* Update to new upstream version 3.4.1.
diff -Nru
darktable-3.4.1/debian/patches/0001-add-explicit-dependency-on-generate_conf.patch
darktable-3.4.1/debian/patches/0001-add-explicit-dependency-on-generate_conf.patch
---
darktable-3.4.1/debian/patches/0001-add-explicit-dependency-on-generate_conf.patch
1969-12-31 20:00:00.0 -0400
+++
darktable-3.4.1/debian/patches/0001-add-explicit-dependency-on-generate_conf.patch
2021-04-08 07:58:21.0 -0300
@@ -0,0 +1,22 @@
+From: David Bremner
+Date: Thu, 8 Apr 2021 07:54:49 -0300
+Subject: add explicit dependency on generate_conf
+
+Weirdly, this missing dependency seems to only show up when running
+"make -j1".
+---
+ src/CMakeLists.txt | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
+index f415ae8..5c40b17 100644
+--- a/src/CMakeLists.txt
b/src/CMakeLists.txt
+@@ -863,6 +863,7 @@ add_library(lib_darktable SHARED
${DARKTABLE_BINDIR}/preferences_gen.h ${DARKTAB
+ # since this isn't the same directory we do have to manually set it
+ set_source_files_properties(${DARKTABLE_BINDIR}/version_gen.c PROPERTIES
GENERATED TRUE)
+
++add_dependencies(lib_darktable generate_conf)
+ add_dependencies(lib_darktable generate_version)
+ add_dependencies(lib_darktable generate_preferences)
+
diff -Nru darktable-3.4.1/debian/patches/series
darktable-3.4.1/debian/patches/series
--- darktable-3.4.1/debian/patches/series 1969-12-31 20:00:00.0
-0400
+++ darktable-3.4.1/debian/patches/series 2021-04-08 07:58:21.0
-0300
@@ -0,0 +1 @@
+0001-add-explicit-dependency-on-generate_conf.patch
--- End Message ---
--- Begin Message ---
Unblocked.--- End Message ---
Bug#986602: unblock: mkvtoolnix/54.0.0-2
On Thu, Apr 08, 2021 at 05:34:40PM +0200, Sebastian Ramacher wrote: > * Mark #986520 as bullseye-ignore and if a there is a need to fix > another issues in a bullsey-pu upload, switch CXX to g++-9 in that > upload. From what I understand, this workaround is supposed to also > work for 52.0.0. Something like that usually is approved for a p-u, as release team member is your right to decide what to tag bullseye-ignore, but that would also pretty much hide the bugs from the list of bullseye bugs. If you really went down that route I'd rather see you use your usertags to hide it from the udd view only during the release process rather tha ignore it forever. And, since this is p-u material in stable, couldn't one upload 52.0.0-1+deb11u1 to t-p-u just changing CXX? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Processed: Re: Bug#986602: unblock: mkvtoolnix/54.0.0-2
Processing control commands: > tags -1 moreinfo Bug #986602 [release.debian.org] unblock: mkvtoolnix/54.0.0-2 Added tag(s) moreinfo. -- 986602: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986602 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#986602: unblock: mkvtoolnix/54.0.0-2
Control: tags -1 moreinfo On 2021-04-07 23:12:01, Christian Marillat wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package mkvtoolnix > > This package was stuck in unstable since january 2021 due to gcc-10 bugs > (See #980429 and #986520). > > I was waiting for a new gcc-10 release to unstable but the gcc-10 maintainer > tell me today : > > Please work around it by using gcc-9 for bullseye. I'm not going to > cherry-pick single patches from the branch. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986520#15 > > I know that we have 52.0.0-1 in testing and I did new uploads (53 and 54) > when testing was not hard frozen and now I'm unable to upload a 52.0.0-2 > package build with gcc-9 to unstable, this explain the 54.0.0-2 upload. > > I've not seen any bug with 54.0.0-2 and this package is safe for me. > > unblock mkvtoolnix/54.0.0-2 The diff between testing and unstable is: 746 files changed, 89826 insertions(+), 59919 deletions(-) That doesn't appear to be an upstream release with only targetted fixes. I'm also quite surprised that new upstream releases were uploaded to unstable while gcc-10 was not fixed. Indeed, all builds starting from 52.0.0-2 to 54.0.0-1 failed on amd64, i386, mipsel, ppc64el (on the other architectures some of them failed, but not all). So here we are. Possbile courses for action: * Implement non-trivial autopkgtests that test the functionality of the installed binaries. The new upstream releases would still not comply with the freeze policy, but we wouldn't block it in this stage of the freeze. * Mark #986520 as bullseye-ignore and if a there is a need to fix another issues in a bullsey-pu upload, switch CXX to g++-9 in that upload. From what I understand, this workaround is supposed to also work for 52.0.0. Cheers -- Sebastian Ramacher
Re: gavodachs2-server broken in unstable
Hi Markus, On 08-04-2021 13:29, Markus Demleitner wrote: > With "show" you're thinking of > mentioning that in the changelog? No, I meant in the communication with us, in this thread and in the potentially upcoming unblock request. >> Not saying I'd unblock this, but it's not hopeless. > > So, you're saying I should file an unblocking bug with a debdiff with > d/copyright fixed? Please, if you do, copy/paste all the relevant parts of this discussion to that bug too and link this thread. reportbug has a nice template for unblock requests, please use it. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986595: marked as done ([pre-approval] unblock: alien/ 8.95.4)
Your message dated Thu, 08 Apr 2021 13:52:23 +
with message-id
and subject line unblock alien
has caused the Debian Bug report #986595,
regarding [pre-approval] unblock: alien/ 8.95.4
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
986595: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986595
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I am preparing a targeted fix for package alien and would like to get
reviewed by the Release team first to see if everything is OK before
uploading onto unstable.
[ Reason ]
Current version of package alien in Debian Testing (8.95.3) is
affected by several important (including a RC) bugs:
* #985835: alien incorrectly replicates filepaths
When converting rpm packages to deb packages, files under /usr/ were
incorrectly placed under /.
* #983492: alien incorrectly generates debian/rules
This is a regression caused by one of my previous upload. When
hardcoding "dh $@" in generated debian/rules, the symbol "$" and "@"
were not escaped so they disappeared in generated debian/rules file,
causing all rpm2deb package build to fail (only "dh", no "dh $@").
* #985808: alien: cannot convert aarch64 rpm packages to arm64 deb
Previously alien did not include the matching between aarch64 (rpm) to
arm64 (deb).
[ Impact ]
If #985835 is not fixed, all output deb packages will be ususable if
there should be any files under /usr/.
If #983492 is not fixed, the conversion from rpm to deb will be
completely broken.
If #985808 is not fixed, conversion of arm64 packages will be
unavailable.
[ Tests ]
I tested locally on my local machines (arm64 and amd64) to verify the
correctness of those bugfixes.
[ Risks ]
The risk of introducing new regression should be limited. I have
personally reviewed the coding of all patches as well.
[ Checklist ]
[Y] all changes are documented in the d/changelog
[Y] I reviewed all changes and I approve them
[Y] attach debdiff against the package in testing
[ Other info ]
Package alien has been orphaned for a while. This is actually part of
the QA work.
Full debdiff in the attachment.
unblock alien/8.95.4
diff -Nru alien-8.95.3/Alien/Package/Deb.pm alien-8.95.4/Alien/Package/Deb.pm
--- alien-8.95.3/Alien/Package/Deb.pm 2020-11-01 13:35:34.0 -0500
+++ alien-8.95.4/Alien/Package/Deb.pm 2021-04-07 12:15:06.0 -0400
@@ -472,7 +472,7 @@
PACKAGE=\$(shell dh_listpackages)
%:
- dh $@
+ dh \$\@
override_dh_clean:
dh_clean -d
@@ -482,9 +482,11 @@
override_dh_auto_build:
override_dh_auto_install:
+ mkdir -p debian/\$(PACKAGE)
# Copy the packages's files.
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \\
- xargs -0 -r -i cp -a {} debian/\$(PACKAGE)
+ sed -e s#'./'##g | \\
+ xargs -0 -r -i cp -a ./{} debian/\$(PACKAGE)/{}
#
# If you need to move files around in debian/\$(PACKAGE) or do some
# binary patching, do it here
diff -Nru alien-8.95.3/Alien/Package/Rpm.pm alien-8.95.4/Alien/Package/Rpm.pm
--- alien-8.95.3/Alien/Package/Rpm.pm 2020-11-01 13:35:34.0 -0500
+++ alien-8.95.4/Alien/Package/Rpm.pm 2021-04-07 12:13:27.0 -0400
@@ -744,6 +744,10 @@
# Treat armv7l as armel.
$arch='armel';
}
+ elsif ($arch eq 'aarch64') {
+ # Treat aarch64 as arm64.
+ $arch='arm64';
+ }
elsif ($arch eq 'parisc') {
$arch='hppa';
}
diff -Nru alien-8.95.3/debian/changelog alien-8.95.4/debian/changelog
--- alien-8.95.3/debian/changelog 2021-02-11 15:02:09.0 -0500
+++ alien-8.95.4/debian/changelog 2021-04-07 12:15:06.0 -0400
@@ -1,3 +1,19 @@
+alien (8.95.4) unstable; urgency=high
+
+ * QA upload.
+ * Alien/Package/Deb.pm: Fix incorrect debian/rules template by
+properly escaping special characters (dh \$\@ instead of dh $@).
+Closes: #983492.
+ * Alien/Package/Deb.pm: Fix incorrect file installation path.
+This fixes the bug in manual override_dh_auto_install that files
+are placed under / instead of /usr/ (default prefix).
+Closes: #985835.
+ * Alien/Package/Rpm.pm: Also map aarch64 in rpm to arm64 in deb.
+This fixes conversion of aarch64 rpm packages.
+Closes: #985808.
+
+ -- Boyuan Yang Wed, 07 Apr 2021 12:15:06 -0400
+
alien (8.95.3) unstable; urgency=medium
* QA upload.
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
Unblocked.--- End Message ---
Bug#985228: unblock: petsc/3.14.5+dfsg1-2
On 2021-04-08 15:25, Paul Gevers wrote: Hi Drew, On 08-04-2021 15:01, Drew Parsons wrote: While petsc and release is close to mind, I'd like to request preauthorization for petsc/3.14.5+dfsg1-3 to make a minimal update to fix Bug#985659 (fixing broken symlinks in docs). You stretched us already quite a bit with -2. What we were missing is an explanation from you of all the changes in the release in an effort to convince us that the upstream release was a targeted fix. Graham spend quite some time to convince himself that this is a bug fix release (apparently he wanted to help you). I rather want the maintainer to do that work as it's really not sustainable to do this as Release Team for the whole Debian archive (we get lots of requests). Please read the FAQ [1]. Please, make a good judgement call and consider that we can only spend our time once. unblock request that are *not* clearly in line with our freeze policy take more time and energy from us. Having to judge corner cases is mentally straining. Denying an unblock request isn't nice. Follow the rules and you make our lives as Release Managers a lot easier. I hear you Paul, I'll take that as a general no on 3.14.6. I appreciate yours and Graham's effort with 3.14.5-2. I'll cherry-pick some specific, targetted fixes from 3.14.6. A couple of them do look unambiguously important. The fix for Bug#985659 will be trivial. Drew
Bug#985228: unblock: petsc/3.14.5+dfsg1-2
Hi Drew, On 08-04-2021 15:01, Drew Parsons wrote: > While petsc and release is close to mind, I'd like to request > preauthorization for petsc/3.14.5+dfsg1-3 to make a minimal update to > fix Bug#985659 (fixing broken symlinks in docs). You stretched us already quite a bit with -2. What we were missing is an explanation from you of all the changes in the release in an effort to convince us that the upstream release was a targeted fix. Graham spend quite some time to convince himself that this is a bug fix release (apparently he wanted to help you). I rather want the maintainer to do that work as it's really not sustainable to do this as Release Team for the whole Debian archive (we get lots of requests). Please read the FAQ [1]. Please, make a good judgement call and consider that we can only spend our time once. unblock request that are *not* clearly in line with our freeze policy take more time and energy from us. Having to judge corner cases is mentally straining. Denying an unblock request isn't nice. Follow the rules and you make our lives as Release Managers a lot easier. Paul [1] https://release.debian.org/bullseye/FAQ.html OpenPGP_signature Description: OpenPGP digital signature
Bug#985228: unblock: petsc/3.14.5+dfsg1-2
On 2021-04-08 14:29, Graham Inggs wrote: Unblocked. Thanks Graham. While petsc and release is close to mind, I'd like to request preauthorization for petsc/3.14.5+dfsg1-3 to make a minimal update to fix Bug#985659 (fixing broken symlinks in docs). Beyond that, what is your mood with respect to petsc 3.14.6, released a week ago? Again fixes a handful of small bugs, perhaps less important than the 3.14.5 patch. https://gitlab.com/petsc/petsc/-/commits/v3.14.6 3.15.0 was also just released, so 3.14.6 would be the last bugfix release in petsc 3.14. Perhaps bullseye will have to manage without it. Drew
Bug#986631: unblock: darktable/3.4.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Please unblock package darktable
[ Reason ]
This fixes a FTBFS.
[ Impact ]
A rebuild with DEB_BUILD_OPTIONS=parallel=1 will fail for the version
currently in testing. This is arguably RC.
[ Tests ]
I installed and ran the updated binary packgge in my development bullseye
system.
[ Risks ]
It's a leaf package. I added en extra dependency rule to the upstream
build system, so I guess given I'm not really a cmake expert that
could fail under some unforseen circumstances.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
A bullseye-ignore tag for the bug #986574 might also make sense (in
lieu of an unblock).
unblock darktable/3.4.1-2
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmBu+zIACgkQA0U5G1Wq
FSFMeBAAp3kAQnPjaDCqwqpKbSWUkLvLCqookAbq5+y0YF7fFPfoUCIqs7PfDF4h
DoQGkc43sYjQbHH5/LVwnL8wJqX7+960GsHk3IkGcFmsOFBfoeeSuVcZISsLzsbP
4L52nRWJ5Lvf2ncEIcZHuWYLZqXZSDInQWL5bejBOf/qtWteAJoBiNxQAxmSmzzZ
WTc088W6F0ovMlC9TYnMJxICpZyVzVs3HPPELRaqYKp1GYmqCiCZ56r1jOpApGap
gmXrG9j6wXloj5Iv1sJH7GrMcL5+tWd/OOCiX9h1oVxIVbMa27R98ssTBHNn3Sef
zPYPZT42ROXw7S6np7v+2y91U55nVbzvGo7wu8SoDePfErfDQyjx6Fn7zFq+LapG
F1jDpBTjbz3HPjnctmYzsGMhHZs2ciU4q+/Blj36OKjMzcedwmrYt72kCUVonSJq
QIGZIEFf3jCf1fUQg0a6VRNzTr1LqAP52mRXOsi6Jar9CjImipac12nYGo/eK5Sx
KqbMFAka1zC37zE3Vm/NrPDzoLZLaK9icpw3wNCSV7iFkw7fww0sKxdQgzvEW33k
B84BPDtPUQ7o3CPUAEi6dHdsnvE9N3o28946a5nXZAf+RO1FIaTMJlPMLb2lZP5N
+RThFF9RIEvJ7nufAO9vApiefkTw7DRoEjI0yuEn+NAHGLoob3Q=
=NrQ2
-END PGP SIGNATURE-
diff -Nru darktable-3.4.1/debian/changelog darktable-3.4.1/debian/changelog
--- darktable-3.4.1/debian/changelog2021-02-06 12:42:43.0 -0400
+++ darktable-3.4.1/debian/changelog2021-04-08 07:58:21.0 -0300
@@ -1,3 +1,11 @@
+darktable (3.4.1-2) unstable; urgency=medium
+
+ * Bug fix: "darktable FTBFS with DEB_BUILD_OPTIONS=parallel=1", thanks
+to Helmut Grohne (Closes: #986574). As Helmut guessed, the fix is to
+add a dependency to the CMake configuration.
+
+ -- David Bremner Thu, 08 Apr 2021 07:58:21 -0300
+
darktable (3.4.1-1) unstable; urgency=medium
* Update to new upstream version 3.4.1.
diff -Nru
darktable-3.4.1/debian/patches/0001-add-explicit-dependency-on-generate_conf.patch
darktable-3.4.1/debian/patches/0001-add-explicit-dependency-on-generate_conf.patch
---
darktable-3.4.1/debian/patches/0001-add-explicit-dependency-on-generate_conf.patch
1969-12-31 20:00:00.0 -0400
+++
darktable-3.4.1/debian/patches/0001-add-explicit-dependency-on-generate_conf.patch
2021-04-08 07:58:21.0 -0300
@@ -0,0 +1,22 @@
+From: David Bremner
+Date: Thu, 8 Apr 2021 07:54:49 -0300
+Subject: add explicit dependency on generate_conf
+
+Weirdly, this missing dependency seems to only show up when running
+"make -j1".
+---
+ src/CMakeLists.txt | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
+index f415ae8..5c40b17 100644
+--- a/src/CMakeLists.txt
b/src/CMakeLists.txt
+@@ -863,6 +863,7 @@ add_library(lib_darktable SHARED
${DARKTABLE_BINDIR}/preferences_gen.h ${DARKTAB
+ # since this isn't the same directory we do have to manually set it
+ set_source_files_properties(${DARKTABLE_BINDIR}/version_gen.c PROPERTIES
GENERATED TRUE)
+
++add_dependencies(lib_darktable generate_conf)
+ add_dependencies(lib_darktable generate_version)
+ add_dependencies(lib_darktable generate_preferences)
+
diff -Nru darktable-3.4.1/debian/patches/series
darktable-3.4.1/debian/patches/series
--- darktable-3.4.1/debian/patches/series 1969-12-31 20:00:00.0
-0400
+++ darktable-3.4.1/debian/patches/series 2021-04-08 07:58:21.0
-0300
@@ -0,0 +1 @@
+0001-add-explicit-dependency-on-generate_conf.patch
Bug#985228: marked as done (unblock: petsc/3.14.5+dfsg1-2)
Your message dated Thu, 8 Apr 2021 14:29:01 +0200 with message-id and subject line Re: Bug#985228: unblock: petsc/3.14.5+dfsg1-2 has caused the Debian Bug report #985228, regarding unblock: petsc/3.14.5+dfsg1-2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 985228: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985228 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package petsc [ Reason ] upstream released petsc 3.14.5 with bug fixes only. This will help improve the stability of the package over the lifetime of the bullseye release. This update also fixes Bug#983892, fixing orphaned alternatives after removal of libpetsc64-complex3.14-dev, [ Impact ] If this release is not permitted into stable then some users may encounter the issues addressed by the patch, especially when running under MPI parallelization. A range of bugs have been addressed: - MatBAIJ: Fix specialization for size 9 - Do not use MPI_Bcast() on a single rank. - PCHPDDM: fix for KSPLSQR - DMPlexVTKWriteAll_VTU: a couple of bugfixes - handling error conditions in PetscOptions - handling NULL objects in Fortran interface - bugfix for MatMatMultSymbolic_MPIAIJ_MPIDense() - CPARDISO: stick to OpenMPI BLACS when needed - minor Documentation fixes If the release is not allowed into stable then libpetsc64-complex3.14-dev will leave dangling alternatives links when removed. [ Tests ] debian/tests autopkgtest is enabled. petsc debci tests have passed in unstable. debci tests in client packages are also passing successfully in unstable (petsc4py, slepc, slep4py, deal.ii, dolfin, mshr, dolfinx) sundials continues to build successfully. [ Risks ] The patch fixes a range of bugs, it is not a simple one-line patch. [ Checklist ] [-] all changes are documented in the d/changelog - documented as "New upstream release (bugfixes)" [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing unblock petsc/3.14.5+dfsg1-2 --- End Message --- --- Begin Message --- Unblocked.--- End Message ---
Re: gavodachs2-server broken in unstable
Paul, On Thu, Apr 08, 2021 at 11:19:45AM +0200, Paul Gevers wrote: > our list. Next time, please file a unblock report to discuss such > issues, as they stay on our radar (you can add "pre-approval" to the title). Ok, thanks (I was reluctant because of the large attachment). > On 18-03-2021 12:42, Markus Demleitner wrote: > > put up at https://docs.g-vo.org/dachs2.debdiff for now, as I'm really > > Is there any chance to get that into bullseye? > > The debdiff is mostly big because you added pyparsing.py. Maybe you can > show where it comes from? I understand it is in buster. Are there any > known issues there? Is it identical? I'm also missing the copyright > statement about that file in d/copyright. It's just /usr/lib/python3/dist-packages/pyparsing.py from buster python3-pyparsing (2.2.0+dfsg1-2). With "show" you're thinking of mentioning that in the changelog? That pyparsing is just fine. And yes, I forgot amending d/copyright for the extra file. I'll fix this. > > You see, the package as it's in now really is basically useless for > > what people will want to do with it. > > Why is this not reflected by the severity of the bugs? I assigned them based on the consideration that *some* functionality is ok. Of course, that happens to not be what most people will want to use the software for. > > undertaking; the grammars that are affected have hundreds of symbols, > > and I estimate about 200 non-trivial changes would be necessary to > > make things work. > > I get you're also upstream? Yes. > Not saying I'd unblock this, but it's not hopeless. So, you're saying I should file an unblocking bug with a debdiff with d/copyright fixed? Thanks, Markus
Bug#985721: marked as done (unblock: fossil/1:2.15~rc1-1)
Your message dated Thu, 8 Apr 2021 13:55:36 +0200 with message-id and subject line Re: Bug#985721: unblock: fossil/1:2.15~rc1-1 has caused the Debian Bug report #985721, regarding unblock: fossil/1:2.15~rc1-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 985721: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985721 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package fossil [ Reason ] Marked for autoremoval due to #985124. The issue was fixed upstream. Given the nature of the package, I think tracking their release candidate is better than cherry-picking the change that appears directly related to this issue. They made a number of other safety-related fixes to ensure robustness and security in the face of old or compiled-with-wrong-options versions of SQLITE3. And nothing that looks scary. [ Impact ] Will allow fossil to be in the release. [ Tests ] There is a comprehensive test suite, which can be run automatically. It is disabled in debian/rules because the makefile says it needs to be run in a fossil repo that will be discarded after the test because the tests can corrupt it. Well, it used to say this: the comment is gone, so maybe it's okay now. But in any case, the system passes all tests right now. [ Risks ] This is a leaf package. It ticks various boxes for security sensitivity, sort of the union of the security sensitivity of git and a web server and a wiki. Upstream is extremely responsive and careful. I think the best option is to follow upstream's recommendation, which is to track their releases. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing I'm attaching the debdiff, but it's large. Due mainly to changes in the enclosed sqlite3 (unused unless the debian version is too old or otherwise unsuitable), and tweaks to static material in the integrated wiki. unblock fossil/1:2.15~rc2-1 <#part type="application/octet-stream" filename="~/tmp/ddiff2" disposition=attachment> <#/part> --- End Message --- --- Begin Message --- Hi Barak On Wed, 7 Apr 2021 at 10:24, Barak A. Pearlmutter wrote: > Anyway, I believe the upload I've just pushed has correct autopkgtest > support, explicitly testing the installed binary /usr/bin/fossil. If > this passes muster, please unblock! And if not, I'd very much > appreciate hints as to how I could improve it. Since you added an autopkgtest, an unblock is no longer needed. Regards Graham--- End Message ---
Bug#986628: unblock: r-cran-rcdklibs/2.3+dfsg-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 986...@bugs.debian.org
Please unblock package r-cran-rcdklibs
[ Reason ]
Fixing bug #986467.
[ Impact ]
The package would be unusable due to a missing Dependency.
[ Tests ]
Testsuite: autopkgtest-pkg-r
[ Risks ]
The package is a dependency of some leaf packages with a low
popcon value.
[ Checklist ]
[*] all changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in testing
unblock r-cran-rcdklibs/2.3+dfsg-6
diff -Nru r-cran-rcdklibs-2.3+dfsg/debian/changelog
r-cran-rcdklibs-2.3+dfsg/debian/changelog
--- r-cran-rcdklibs-2.3+dfsg/debian/changelog 2020-11-18 11:35:15.0
+0100
+++ r-cran-rcdklibs-2.3+dfsg/debian/changelog 2021-04-08 10:46:24.0
+0200
@@ -1,3 +1,10 @@
+r-cran-rcdklibs (2.3+dfsg-6) unstable; urgency=medium
+
+ * Add missing Depends libcdk-java
+Closes: #986467
+
+ -- Andreas Tille Thu, 08 Apr 2021 10:46:24 +0200
+
r-cran-rcdklibs (2.3+dfsg-5) unstable; urgency=medium
* Versioned (Build-)Depends to libcdk-java (>= 2.3.134.g1bb9a64587)
diff -Nru r-cran-rcdklibs-2.3+dfsg/debian/control
r-cran-rcdklibs-2.3+dfsg/debian/control
--- r-cran-rcdklibs-2.3+dfsg/debian/control 2020-11-18 11:35:15.0
+0100
+++ r-cran-rcdklibs-2.3+dfsg/debian/control 2021-04-08 10:46:24.0
+0200
@@ -8,7 +8,7 @@
dh-r,
r-base-dev,
r-cran-rjava,
- libcdk-java
+ libcdk-java (>= 2.3.134.g1bb9a64587)
Standards-Version: 4.5.1
Vcs-Browser: https://salsa.debian.org/r-pkg-team/r-cran-rcdklibs
Vcs-Git: https://salsa.debian.org/r-pkg-team/r-cran-rcdklibs.git
@@ -18,7 +18,8 @@
Package: r-cran-rcdklibs
Architecture: all
Depends: ${R:Depends},
- ${misc:Depends}
+ ${misc:Depends},
+ libcdk-java (>= 2.3.134.g1bb9a64587)
Recommends: ${R:Recommends}
Suggests: ${R:Suggests}
Description: Chemistry Development Kit (CDK) libraries packaged for GNU R
Bug#986625: unblock: grub2/2.04-17
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock grub2 2.04-17. The --sbat fix will be needed for d-i
builds once various bits of work on shim are finished, and the verifiers
module change helps core images fit in the constrained space that's
often all that's available on BIOS systems.
You may need to manually unblock grub-efi-{amd64,arm64,ia32}-signed as
well to match, since these four source packages must all have matching
versions - I'm not sure exactly how the tools work from your end.
diff -Nru grub2-2.04/debian/.git-dpm grub2-2.04/debian/.git-dpm
--- grub2-2.04/debian/.git-dpm 2021-03-02 18:00:00.0 +
+++ grub2-2.04/debian/.git-dpm 2021-03-19 10:41:41.0 +
@@ -1,6 +1,6 @@
# see git-dpm(1) from git-dpm package
-9cd32c57605b7ad713e108e0b98ebd504caa532e
-9cd32c57605b7ad713e108e0b98ebd504caa532e
+3d246c561a2c6aa18b78eae69e5100a2347dc7aa
+3d246c561a2c6aa18b78eae69e5100a2347dc7aa
578bb115fbd47e1c464696f1f8d6183e5443975d
578bb115fbd47e1c464696f1f8d6183e5443975d
grub2_2.04.orig.tar.xz
diff -Nru grub2-2.04/debian/build-efi-images grub2-2.04/debian/build-efi-images
--- grub2-2.04/debian/build-efi-images 2021-03-02 18:00:00.0 +
+++ grub2-2.04/debian/build-efi-images 2021-03-19 10:41:41.0 +
@@ -224,6 +224,8 @@
"$grub_mkimage" -O "$platform" -o "$outdir/grubnet$efi_name-installer.efi" \
-d "$grub_core" -c "$workdir/grub-bootstrap.cfg" \
-m "$workdir/memdisk-netboot.fat" \
- -p "/${efi_vendor}-installer/$deb_arch/grub" $NET_MODULES
+ -p "/${efi_vendor}-installer/$deb_arch/grub" \
+ --sbat "$sbat_csv" \
+ $NET_MODULES
exit 0
diff -Nru grub2-2.04/debian/changelog grub2-2.04/debian/changelog
--- grub2-2.04/debian/changelog 2021-03-02 18:00:00.0 +
+++ grub2-2.04/debian/changelog 2021-03-19 10:41:41.0 +
@@ -1,3 +1,11 @@
+grub2 (2.04-17) unstable; urgency=medium
+
+ * Pass --sbat when building the d-i netboot image as well.
+ * i386-pc: build verifiers API as module (thanks, Michael Chang; closes:
+#984488, #985374).
+
+ -- Colin Watson Fri, 19 Mar 2021 10:41:41 +
+
grub2 (2.04-16) unstable; urgency=medium
* Fix broken advice in message when the postinst has to bail out (thanks
diff -Nru grub2-2.04/debian/patches/pc-verifiers-module.patch
grub2-2.04/debian/patches/pc-verifiers-module.patch
--- grub2-2.04/debian/patches/pc-verifiers-module.patch 1970-01-01
01:00:00.0 +0100
+++ grub2-2.04/debian/patches/pc-verifiers-module.patch 2021-03-19
10:41:41.0 +
@@ -0,0 +1,167 @@
+From 3d246c561a2c6aa18b78eae69e5100a2347dc7aa Mon Sep 17 00:00:00 2001
+From: Michael Chang
+Date: Thu, 18 Mar 2021 19:30:26 +0800
+Subject: i386-pc: build verifiers API as module
+
+Given no core functions on i386-pc would require verifiers to work and
+the only consumer of the verifier API is the pgp module, it looks good
+to me that we can move the verifiers out of the kernel image and let
+moddep.lst to auto-load it when pgp is loaded on i386-pc platform.
+
+This helps to reduce the size of core image and thus can relax the
+tension of exploding on some i386-pc system with very short MBR gap
+size. See also a very comprehensive summary from Colin [1] about the
+details.
+
+[1] https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00240.html
+
+V2:
+Drop COND_NOT_i386_pc and use !COND_i386_pc.
+Add comment in kern/verifiers.c to help understanding what's going on
+without digging into the commit history.
+
+Reported-by: Colin Watson
+Reviewed-by: Colin Watson
+Signed-off-by: Michael Chang
+
+Origin: other,
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00251.html
+Bug-Debian: https://bugs.debian.org/984488
+Bug-Debian: https://bugs.debian.org/985374
+Last-Update: 2021-03-18
+
+Patch-Name: pc-verifiers-module.patch
+---
+ grub-core/Makefile.am | 2 ++
+ grub-core/Makefile.core.def | 8 +++-
+ grub-core/kern/main.c | 4
+ grub-core/kern/verifiers.c | 17 +
+ include/grub/verify.h | 9 +
+ 5 files changed, 39 insertions(+), 1 deletion(-)
+
+diff --git a/grub-core/Makefile.am b/grub-core/Makefile.am
+index 5308caa7b..4900265a4 100644
+--- a/grub-core/Makefile.am
b/grub-core/Makefile.am
+@@ -92,7 +92,9 @@ KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/partition.h
+ KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/stack_protector.h
+ KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/term.h
+ KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/time.h
++if !COND_i386_pc
+ KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/verify.h
++endif
+ KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/mm_private.h
+ KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/net.h
+ KERNEL_HEADER_FILES += $(top_srcdir)/include/grub/memory.h
+diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
+index 248835aca..43b3da725 100644
+---
Bug#986411: marked as done (unblock: pristine-lfs/20210404.0-2)
Your message dated Thu, 8 Apr 2021 12:00:08 +0200 with message-id <1cf5ecda-9ecb-f41b-f52c-9d36208e7...@debian.org> and subject line Re: Bug#986411: unblock: pristine-lfs/20210404.0-2 has caused the Debian Bug report #986411, regarding unblock: pristine-lfs/20210404.0-2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 986411: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986411 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please unblock package pristine-lfs [ Reason ] Not knowing that pristine-lfs is considered a key package, I made changes upstream and uploaded a new release into Debian, fixing a few bugs and improving the exported API to make the future integration with git-buildpackage easier. [ Impact ] The direct impact in the event the unblock is not granted is low, since the new features aren’t used yet and the bugs have been previously worked around specifically in Debian bullseye. On the other hand, for the outlined reasons the impact on unblocking will also be very low. [ Tests ] - - There’s a test of tests running upstream on four Python releases (3.7, 3.8, 3.9 and 3.10-rc) and in Debian on the current Python release at build time; these tests cover all features but test them directly in Python - - The Debian package ships autopkgtests testing some of the basic features through the command-line interface. - - The upstream Ci runs mypy static type checks. [ Risks ] The changes are not trivial but OTOH not big and covered by tests; the overall test coverage has increased since the last upload, hence the risks of accepting this package into bullseye should be relatively low. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock pristine-lfs/20210404.0-1 -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQSD3NF/RLIsyDZW7aHoRGtKyMdyYQUCYGsP6AAKCRDoRGtKyMdy Yc+rAQCsmONKT1dDAIwolvhF5uMJXtR9KiqIOyQi1DSosoJ1ZgEA+bf359mV6UDQ +g2N6APILtvME0Agpz62ZKDz4YqI6wo= =5H1H -END PGP SIGNATURE- diff --git a/PKG-INFO b/PKG-INFO index 8db2f11..5b3e484 100644 --- a/PKG-INFO +++ b/PKG-INFO @@ -1,6 +1,6 @@ Metadata-Version: 2.1 Name: pristine-lfs -Version: 20210222.0 +Version: 20210404.0 Summary: a pristine-tar replacement that works with Git LFS Home-page: https://salsa.debian.org/pristine-lfs-team/pristine-lfs Author: Andrej Shadura diff --git a/debian/changelog b/debian/changelog index 9804ad5..1afd619 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +pristine-lfs (20210404.0-1) unstable; urgency=medium + + * New upstream release. + + -- Andrej Shadura Sun, 04 Apr 2021 22:15:42 +0200 + pristine-lfs (20210222.0-1) unstable; urgency=medium * New upstream release. diff --git a/pristine_lfs.egg-info/PKG-INFO b/pristine_lfs.egg-info/PKG-INFO index 8db2f11..5b3e484 100644 --- a/pristine_lfs.egg-info/PKG-INFO +++ b/pristine_lfs.egg-info/PKG-INFO @@ -1,6 +1,6 @@ Metadata-Version: 2.1 Name: pristine-lfs -Version: 20210222.0 +Version: 20210404.0 Summary: a pristine-tar replacement that works with Git LFS Home-page: https://salsa.debian.org/pristine-lfs-team/pristine-lfs Author: Andrej Shadura diff --git a/pristine_lfs.egg-info/SOURCES.txt b/pristine_lfs.egg-info/SOURCES.txt index 70a9467..2f79c38 100644 --- a/pristine_lfs.egg-info/SOURCES.txt +++ b/pristine_lfs.egg-info/SOURCES.txt @@ -6,8 +6,10 @@ pristine-lfs.rst setup.cfg setup.py pristine_lfs/__init__.py +pristine_lfs/errors.py pristine_lfs/gitwrap.py pristine_lfs/gitwrap.pyi +pristine_lfs/log.py pristine_lfs/main.py pristine_lfs/util.py pristine_lfs.egg-info/PKG-INFO diff --git a/pristine_lfs.egg-info/requires.txt b/pristine_lfs.egg-info/requires.txt index b065e88..9a19637 100644 --- a/pristine_lfs.egg-info/requires.txt +++ b/pristine_lfs.egg-info/requires.txt @@ -1,2 +1,2 @@ python-debian -sh +sh>=1.14 diff --git a/pristine_lfs/__init__.py b/pristine_lfs/__init__.py index 6df221a..ded6987 100644 --- a/pristine_lfs/__init__.py +++ b/pristine_lfs/__init__.py @@ -1,5 +1,6 @@ from .main import ( # noqa: F401 do_commit, +do_commit_files, do_checkout, do_list, do_import, diff --git a/pristine_lfs/errors.py b/pristine_lfs/errors.py new file mode 100644 index 000..ca1db96 --- /dev/null +++ b/pristine_lfs/errors.py @@ -0,0 +1,67 @@ +# pristine-lfs +# +# errors for pristine-lfs +# +#
Re: gavodachs2-server broken in unstable
Hi Markus, This mail fell through the cracks because the sheer amount of traffic on our list. Next time, please file a unblock report to discuss such issues, as they stay on our radar (you can add "pre-approval" to the title). On 18-03-2021 12:42, Markus Demleitner wrote: > Fixing these requires something with a humonguos debdiff, which I've > put up at https://docs.g-vo.org/dachs2.debdiff for now, as I'm really > not sure if it's appropriate to attach this kind of thing to an > unfreeze bug. Attaching is OK, although it might not reach the mailing lists, so pinging on the bug may be required. > Is there any chance to get that into bullseye? The debdiff is mostly big because you added pyparsing.py. Maybe you can show where it comes from? I understand it is in buster. Are there any known issues there? Is it identical? I'm also missing the copyright statement about that file in d/copyright. > You see, the package as it's in now really is basically useless for > what people will want to do with it. Why is this not reflected by the severity of the bugs? > I've thought hard about the > alternative, forward-porting to pyparsing 2.4, but that is a *major* > undertaking; the grammars that are affected have hundreds of symbols, > and I estimate about 200 non-trivial changes would be necessary to > make things work. I get you're also upstream? > Getting this right on the first shot is > certainly going to be hard; the pyparsing 2.2-based code, on the > other hand, has matured over ~10 years (and a few previous pyparsing > versions), so I'd *really* like to go carefully on this. > > Now, you can rightfully say "why didn't you properly configure the CI > on salsa"? Mea culpa. But since you need to run a database server > to enable meaningful tests, I've always relied on doing this in local > containers. Perhaps if I do penance and work things out for salsa CI > (hint welcome) -- could that move your hearts to letting in the > patch? Within autopkgtest (with restriction "breaks-testbed") you can setup the database to test against. If you need more help, you can always ask on debian-ci@d.l.o or on #debci. If you have a non-trivial autopkgtest (testing the installed binaries), you don't even need an unblock at this moment. Not saying I'd unblock this, but it's not hopeless. Paul OpenPGP_signature Description: OpenPGP digital signature
Processed: Re: Bug#986213: RM: ansible/2.9.16+dfsg-1.1
Processing control commands: > tags -1 wontfix Bug #986213 [release.debian.org] RM: ansible/2.9.16+dfsg-1.1 Added tag(s) wontfix. -- 986213: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986213 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
Control: tags -1 wontfix Hi, On 08-04-2021 09:54, Christian Kastner wrote: > On 01.04.21 10:49, Raphael Hertzog wrote: >> Shipping bullseye without a core system administration tool like ansible >> is not something that we should do. Our users are the clear losers of this >> situation (and thus Debian as a whole).> >> Graham, can you please reconsider your position in #984557? Maybe have >> some broader discussion within the release team on whether an exception >> is to be made? >> >> I know exceptions are the doors to more arbitrary unblock requests but >> in general I have the feeling that we are too strict with such requests. > I would also greatly appreciate if a alternative solutions could be > discussed. > > Mistakes have been made and the policy is clear on the consequences. > However, from a user's perspective, strictly adhering to policy here > would appear to have an even bigger downside, in the sense that a 2.10.x > ansible of at least certain quality would be better than no ansible. > > If there is room for discussion and if there is any way that I can help > with this effort (especially with testing), please let me know. There's a way. ansible is not a key package, so, with passing (non-trivial) autopkgtest and src:ansible-base merged into src:ansible you have a way to carry this into bullseye. Yes, not conforming our freeze policy, but we won't block you. However, we *also* set freeze rules to make the release process manageable for the release team. ansible clearly missed to follow the rules. Making an exception is opening the doors for much more request for an exception that we just can't handle appropriately. We'll not act on this RM now as there's already the autoremoval process in place for bug 983140 which ensure that maintainers of reverse dependencies are warned and can help out if they want. Can we please stop this discussion? It's draining our energy. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
On 01.04.21 10:49, Raphael Hertzog wrote: > Shipping bullseye without a core system administration tool like ansible > is not something that we should do. Our users are the clear losers of this > situation (and thus Debian as a whole).> > Graham, can you please reconsider your position in #984557? Maybe have > some broader discussion within the release team on whether an exception > is to be made? > > I know exceptions are the doors to more arbitrary unblock requests but > in general I have the feeling that we are too strict with such requests. I would also greatly appreciate if a alternative solutions could be discussed. Mistakes have been made and the policy is clear on the consequences. However, from a user's perspective, strictly adhering to policy here would appear to have an even bigger downside, in the sense that a 2.10.x ansible of at least certain quality would be better than no ansible. If there is room for discussion and if there is any way that I can help with this effort (especially with testing), please let me know. Best, Christian
Bug#986311: SRM input requested: Re Bug#986311: unblock: debian-cloud-images/0.0.4
Dear SRM colleagues, Your input/confirmation is appreciated on the following issue. tl;dr; are you OK with updating debian-cloud-images in the stable release? On 03-04-2021 21:29, Paul Gevers wrote: > Hi Noah, > > On 03-04-2021 17:44, Noah Meyerhans wrote: >> It is sufficient for the Depends packages to be available in the next >> release. > > Unfortunately, our package handling goes per source package, not by > binary packages. > >>> Should the current package in testing be released with bullseye if we >>> don't update it? >> >> IMO, debian-cloud-images should never have been packaged in Debian in >> the first place, given that there was no plan to maintain it in the >> archive and that a "stable" packaged version of it bears only a passing >> relationship to the cloud images we actually ship, but it's too late for >> that. > > What do you mean with "it's too late for that"? We *could* (not saying > we should) drop the package. > >> In an ideal world, the debian-cloud-images package in the stable release >> would match what generates the images for that release. However, it >> moves relatively quickly in order to keep up with changes implemented by >> the cloud services, so that would require us to update the stable >> package frequently. The ability to update cloud related packages for >> this reason was discussed with the SRMs some time ago, and I understand >> that they were supportive of allowing such updates in stable point >> releases. Practically speaking, we've only ever applied this agreement >> once, to update cloud-init in buster. >> >> If we can't keep the debian-cloud-images package up-to-date in stable >> releases, then it should not be included. It's the worst of both worlds >> and can only cause confusion for users. I'd be in favor of removing it >> from buster, too, if that's the case, where it's most definitely out of >> sync with what's generating the cloud images today. > > If the SRM's are fine with updating the package in stable, I'm happy to > unblock it. I'll point them to this bug to have them weight in. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986617: unblock: node-rollup-pluginutils/4.1.0+~2.8.2-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package node-rollup-pluginutils
[ Reason ]
node-rollup-pluginutils has a broken symlink due to
node-typescript-types deprecation. This patch updates dependencies to
package that ship the good @types/* files (#985702)
[ Impact ]
A broken symlink and maybe missing dependencies when using
node-rollup-pluginutils with tsc (node-typescript)
[ Tests ]
Tests passed because some build dependencies are updated
[ Risks ]
Trivial patch, just updates dependencies (node-typescript-types is now a
transitional package that points to virtual node-types-node)
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock node-rollup-pluginutils/4.1.0+~2.8.2-3
diff --git a/debian/changelog b/debian/changelog
index ff4da4b..68603db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-rollup-pluginutils (4.1.0+~2.8.2-3) unstable; urgency=medium
+
+ * Team upload
+ * Replace deprecated dependency to node-typescript-types by dependencies to
+node-types-estree and node-types-node (Closes: #979762, #979775, #985702)
+
+ -- Yadd Mon, 22 Mar 2021 12:45:55 +0100
+
node-rollup-pluginutils (4.1.0+~2.8.2-2) unstable; urgency=medium
* Team upload
diff --git a/debian/control b/debian/control
index 6f6f43d..c5ab2ea 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
, node-rollup-plugin-node-resolve
, node-rollup-plugin-typescript
, node-typescript (>= 3.7~)
- , node-typescript-types
+ , node-types-estree
, nodejs (>= 10~)
, dh-sequence-nodejs
, rollup (>= 1)
@@ -31,7 +31,8 @@ Depends:
${misc:Depends}
, node-estree-walker
, node-micromatch (>= 4.0~)
- , node-typescript-types
+ , node-types-estree
+ , node-types-node
Breaks: rollup (<< 1)
Suggests: node-rollup-plugin-typescript
Description: Base functionality for rollup plugins
