Bug#1034042: openvswitch: CVE-2023-1668: Remote traffic denial of service via crafted packets with IP proto 0

2023-04-06 Thread Salvatore Bonaccorso
Source: openvswitch
Version: 3.1.0-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for openvswitch.

CVE-2023-1668[0]:
| Remote traffic denial of service via crafted packets with IP proto 0

Thomas and Luca, can you make sure the fix lands in bookworm via a
unblock request. For bullseye I'm not yet sure if we need a DSA or we
can go the near bullseye point release. 

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-1668
https://www.cve.org/CVERecord?id=CVE-2023-1668
[1] https://www.openwall.com/lists/oss-security/2023/04/06/1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Processed: Bookworm is not affected

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 bookworm-ignore
Bug #1032557 {Done: Andreas Tille } [src:freebayes] libvcflib 
breaks freebayes autopkgtest: Error: signal 11
Added tag(s) bookworm-ignore.
> tags -1 - bookworm
Bug #1032557 {Done: Andreas Tille } [src:freebayes] libvcflib 
breaks freebayes autopkgtest: Error: signal 11
Ignoring request to alter tags of bug #1032557 to the same tags previously set

-- 
1032557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1032557: Bookworm is not affected

2023-04-06 Thread Andreas Tille
Control: tags -1 bookworm-ignore
Control: tags -1 - bookworm

Inside bookworm the testing the autopkgtest works.

-- 
http://fam-tille.de



Bug#1016903: Update debian patches for enabling git-updates.diff in gcc-12-12.2.0-14 and 17

2023-04-06 Thread Ricky X. Y. LIU
diff -Narup a/debian/patches/gcc-distro-specs.diff 
b/debian/patches/gcc-distro-specs.diff
--- a/debian/patches/gcc-distro-specs.diff  2022-10-31 21:50:28.0 
+0800
+++ b/debian/patches/gcc-distro-specs.diff  2023-04-07 09:57:08.034297864 
+0800
@@ -1,20 +1,19 @@
 # DP: Add empty distro and hardening specs

 a/src/gcc/gcc.cc
-+++ b/src/gcc/gcc.cc
-@@ -27,6 +27,11 @@ CC recognizes how to compile each input
- Once it knows which kind of compilation to perform, the procedure for
+--- a/src/gcc/gcc.cc   2023-04-06 08:20:07.0 +0800
 b/src/gcc/gcc.cc   2023-04-07 09:54:02.948157378 +0800
+@@ -28,6 +28,10 @@ Once it knows which kind of compilation
  compilation is specified by a string called a "spec".  */

+ #define INCLUDE_STRING
 +/* Inject some default compilation flags which are used as the default.
 +   Done by the packaging build system.  Should that be done in the headers
 +   gcc/config//*.h instead?  */
 +#include "distro-defaults.h"
-+
  #include "config.h"
  #include "system.h"
  #include "coretypes.h"
-@@ -984,6 +989,90 @@ proper position among the other output f
+@@ -986,6 +990,90 @@ proper position among the other output f
  #define LINK_GCC_C_SEQUENCE_SPEC "%G %{!nolibc:%L %G}"
  #endif

@@ -105,7 +104,7 @@
  #ifndef LINK_SSP_SPEC
  #ifdef TARGET_LIBC_PROVIDES_SSP
  #define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
-@@ -1040,7 +1129,7 @@ proper position among the other output f
+@@ -1042,7 +1130,7 @@ proper position among the other output f
  #ifndef LINK_PIE_SPEC
  #ifdef HAVE_LD_PIE
  #ifndef LD_PIE_SPEC
@@ -114,7 +113,7 @@
  #endif
  #else
  #define LD_PIE_SPEC ""
-@@ -1157,6 +1246,7 @@ proper position among the other output f
+@@ -1159,6 +1247,7 @@ proper position among the other output f
 "%{flto|flto=*:%
Subject: Update debian patches for enabling git-updates.diff in 
gcc-12-12.2.0-14 and 17

Dear,

The patch git-updates.diff including bug fixes from release/gcc-12 branch have 
not been enabled in rules.patch, for gcc-12-12.2.0-14 and -17 (sid and exp).
( see  
https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-12-debian/debian/rules.patch
 line 15~17 )

To enable git-updates.diff, some of debian patches need to be updated :

debian/patches/gcc-distro-specs.diff
and
debian/patches/gcc-multilib-multiarch.diff

I made a patch to update these debian patches, so that the build of 
gcc-12-12.2.0-14 and -17 work normally, and PR 106322 is included.
[https://salsa.debian.org/assets/twitter_card-570ddb06edf56a2312253c5872489847a0f385112ddbcd71ccfa1570febab5d2.jpg]
debian/rules.patch · gcc-12-debian · Debian GCC Maintainers / GCC · 
GitLab
Debian Salsa Gitlab
salsa.debian.org




Thanks,
Best Regards,
Ricky X.Y. LIU





CONFIDENTIALITY NOTICE:

The content of this email and any attachments (“Email”) is confidential, may be 
privileged, subject to copyright and may be read, copied and used only by the 
intended recipient.

If you are not the intended recipient, please notify the sender by return email 
or telephone immediately and erase all copies (including any attachments) and 
do not disclose the Email or any part of it to any person. Any use, retention, 
disclosure, copying, printing, forwarding or dissemination of the Email is 
strictly prohibited if you are not the intended recipient.

ASTRI reserve the right to monitor all email communications through ASTRI’s 
networks.




Bug#1016903: Update debian patches for enabling git-updates.diff in gcc-12-12.2.0-14 and 17

2023-04-06 Thread Ricky X. Y. LIU
Dear,

The patch git-updates.diff including bug fixes from release/gcc-12 branch have 
not been enabled in rules.patch, for gcc-12-12.2.0-14 and -17 (sid and exp).
( see  
https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-12-debian/debian/rules.patch
 line 15~17 )

To enable git-updates.diff, some of debian patches need to be updated :

debian/patches/gcc-distro-specs.diff
and
debian/patches/gcc-multilib-multiarch.diff

I made a patch to update these debian patches, so that the build of 
gcc-12-12.2.0-14 and -17 work normally, and PR 106322 is included.
[https://salsa.debian.org/assets/twitter_card-570ddb06edf56a2312253c5872489847a0f385112ddbcd71ccfa1570febab5d2.jpg]
debian/rules.patch · gcc-12-debian · Debian GCC Maintainers / GCC · 
GitLab
Debian Salsa Gitlab
salsa.debian.org




Thanks,
Best Regards,
Ricky X.Y. LIU





CONFIDENTIALITY NOTICE:

The content of this email and any attachments (“Email”) is confidential, may be 
privileged, subject to copyright and may be read, copied and used only by the 
intended recipient.

If you are not the intended recipient, please notify the sender by return email 
or telephone immediately and erase all copies (including any attachments) and 
do not disclose the Email or any part of it to any person. Any use, retention, 
disclosure, copying, printing, forwarding or dissemination of the Email is 
strictly prohibited if you are not the intended recipient.

ASTRI reserve the right to monitor all email communications through ASTRI’s 
networks.


diff -Narup a/debian/patches/gcc-distro-specs.diff b/debian/patches/gcc-distro-specs.diff
--- a/debian/patches/gcc-distro-specs.diff	2022-10-31 21:50:28.0 +0800
+++ b/debian/patches/gcc-distro-specs.diff	2023-04-07 09:57:08.034297864 +0800
@@ -1,20 +1,19 @@
 # DP: Add empty distro and hardening specs
 
 a/src/gcc/gcc.cc
-+++ b/src/gcc/gcc.cc
-@@ -27,6 +27,11 @@ CC recognizes how to compile each input
- Once it knows which kind of compilation to perform, the procedure for
+--- a/src/gcc/gcc.cc	2023-04-06 08:20:07.0 +0800
 b/src/gcc/gcc.cc	2023-04-07 09:54:02.948157378 +0800
+@@ -28,6 +28,10 @@ Once it knows which kind of compilation
  compilation is specified by a string called a "spec".  */
  
+ #define INCLUDE_STRING
 +/* Inject some default compilation flags which are used as the default.
 +   Done by the packaging build system.  Should that be done in the headers
 +   gcc/config//*.h instead?  */
 +#include "distro-defaults.h"
-+
  #include "config.h"
  #include "system.h"
  #include "coretypes.h"
-@@ -984,6 +989,90 @@ proper position among the other output f
+@@ -986,6 +990,90 @@ proper position among the other output f
  #define LINK_GCC_C_SEQUENCE_SPEC "%G %{!nolibc:%L %G}"
  #endif
  
@@ -105,7 +104,7 @@
  #ifndef LINK_SSP_SPEC
  #ifdef TARGET_LIBC_PROVIDES_SSP
  #define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
-@@ -1040,7 +1129,7 @@ proper position among the other output f
+@@ -1042,7 +1130,7 @@ proper position among the other output f
  #ifndef LINK_PIE_SPEC
  #ifdef HAVE_LD_PIE
  #ifndef LD_PIE_SPEC
@@ -114,7 +113,7 @@
  #endif
  #else
  #define LD_PIE_SPEC ""
-@@ -1157,6 +1246,7 @@ proper position among the other output f
+@@ -1159,6 +1247,7 @@ proper position among the other output f
 "%{flto|flto=*:%

Bug#1034032: marked as done (rust-bitflags: autopkgtest regression: error[E0277]: the trait bound `SerdeFlags: Deserialize<'_>` is not satisfied)

2023-04-06 Thread Debian Bug Tracking System
Your message dated Fri, 07 Apr 2023 02:25:07 +
with message-id 
and subject line Bug#1034032: fixed in rust-bitflags 1.3.2-3
has caused the Debian Bug report #1034032,
regarding rust-bitflags: autopkgtest regression: error[E0277]: the trait bound 
`SerdeFlags: Deserialize<'_>` is not satisfied
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.)


-- 
1034032: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034032
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Source: rust-bitflags
Version: 1.3.2-2
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-bitflags/32255138/log.gz

 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=glob 
CARGO_MANIFEST_DIR=/tmp/tmp.u55zB0qp8W/registry/glob-0.3.0 
CARGO_PKG_AUTHORS='The Rust Project Developers' 
CARGO_PKG_DESCRIPTION='Support for matching file paths against Unix 
shell style patterns.
' CARGO_PKG_HOMEPAGE='https://github.com/rust-lang/glob' 
CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE='' 
CARGO_PKG_NAME=glob 
CARGO_PKG_REPOSITORY='https://github.com/rust-lang/glob' 
CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.3.0 
CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=3 
CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/tmp/tmp.u55zB0qp8W/target/debug/deps:/usr/lib' rustc 
--crate-name glob /tmp/tmp.u55zB0qp8W/registry/glob-0.3.0/src/lib.rs 
--error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type 
lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C 
metadata=18ed03da62dd1beb -C extra-filename=-18ed03da62dd1beb --out-dir 
/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -L 
dependency=/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps 
-L dependency=/tmp/tmp.u55zB0qp8W/target/debug/deps --cap-lints warn -C 
debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C 
link-arg=-Wl,-z,relro --remap-path-prefix 
/usr/share/cargo/registry/bitflags-1.3.2=/usr/share/cargo/registry/bitflags-1.3.2 
--remap-path-prefix /tmp/tmp.u55zB0qp8W/registry=/usr/share/cargo/registry`

warning: trait objects without an explicit `dyn` are deprecated
   --> /usr/share/cargo/registry/glob-0.3.0/src/lib.rs:294:32
|
294 | fn cause(&self) -> Option<&Error> {
|^
|
= note: `#[warn(bare_trait_objects)]` on by default
= warning: this is accepted in the current edition (Rust 2015) but 
is a hard error in Rust 2021!
= note: for more information, see 


help: use `dyn`
|
294 - fn cause(&self) -> Option<&Error> {
294 + fn cause(&self) -> Option<&dyn Error> {
|

warning: use of deprecated associated function 
`std::error::Error::description`: use the Display impl or to_string()

   --> /usr/share/cargo/registry/glob-0.3.0/src/lib.rs:291:20
|
291 | self.error.description()
|^^^
|
= note: `#[warn(deprecated)]` on by default

warning: `glob` (lib) generated 2 warnings
   Compiling once_cell v1.17.0
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=once_cell 
CARGO_MANIFEST_DIR=/tmp/tmp.u55zB0qp8W/registry/once_cell-1.17.0 
CARGO_PKG_AUTHORS='Aleksey Kladov ' 
CARGO_PKG_DESCRIPTION='Single assignment cells and lazy values.' 
CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' 
CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=once_cell 
CARGO_PKG_REPOSITORY='https://github.com/matklad/once_cell' 
CARGO_PKG_RUST_VERSION=1.56 CARGO_PKG_VERSION=1.17.0 
CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=17 
CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/tmp/tmp.u55zB0qp8W/target/debug/deps:/usr/l

Bug#1034030: marked as done (rust-async-stream: autopkgtest regression: error[E0658]: yield syntax is experimental)

2023-04-06 Thread Debian Bug Tracking System
Your message dated Fri, 07 Apr 2023 01:18:54 +
with message-id 
and subject line Bug#1034030: fixed in rust-async-stream 0.3.4-1
has caused the Debian Bug report #1034030,
regarding rust-async-stream: autopkgtest regression: error[E0658]: yield syntax 
is experimental
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.)


-- 
1034030: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034030
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Source: rust-async-stream
Version: 0.3.3-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails since December 
2022. Can you please investigate the situation and fix it? I copied some 
of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-async-stream/32102899/log.gz

test tests/ui/yield_in_async.rs ... mismatch

EXPECTED:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^
  |
  = note: see issue #43122 
 for more information


error[E0727]: `async` generators are not yet supported
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^

error[E0271]: type mismatch resolving `<[static 
generator@$DIR/src/lib.rs:201:9: 201:67] as Generator>::Yield 
== ()`

  --> tests/ui/yield_in_async.rs:4:5
   |
4  | / stream! {
5  | | let f = async {
6  | | yield 123;
7  | | };
8  | |
9  | | let v = f.await;
10 | | };
   | |_^ expected `()`, found integer
   |
note: required by a bound in `from_generator`
  --> $RUST/core/src/future/mod.rs
   |
   | T: Generator,
   |^^ required by this bound in 
`from_generator`
   = note: this error originates in the macro `stream` (in Nightly 
builds, run with -Z macro-backtrace for more info)



ACTUAL OUTPUT:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^
  |
  = note: see issue #43122 
 for more information


error[E0727]: `async` generators are not yet supported
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^

error[E0271]: type mismatch resolving `<[static 
generator@$DIR/src/lib.rs:201:9: 201:67] as Generator>::Yield 
== ()`

  --> tests/ui/yield_in_async.rs:4:5
   |
4  | / stream! {
5  | | let f = async {
6  | | yield 123;
7  | | };
8  | |
9  | | let v = f.await;
10 | | };
   | |_^ expected `()`, found integer
   |
note: required by a bound in `std::future::from_generator`
   = note: this error originates in the macro `stream` (in Nightly 
builds, run with -Z macro-backtrace for more info)


note: If the actual output is the correct output you can bless it by 
rerunning

  your test with the environment variable TRYBUILD=overwrite

test tests/ui/yield_in_closure.rs ... mismatch

EXPECTED:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_closure.rs:7:17
  |
7 | yield v;
  | ^^^
  |
  = note: see issue #43122 
 for more information


error[E0277]: expected a `FnOnce<(&str,)>` closure, found 
`[generator@$DIR/src/lib.rs:201:9: 201:67]`

--> tests/ui/yield_in_closure.rs:6:14
 |
6| .and_then(|v| {
 |   expected an `FnOnce<(&str,)>` closure, 
found `[generator@$DIR/src/lib.rs:201:9: 201:67]`

 |
 = help: the trait 

Processed: Re: Bug#1032104: linux: ppc64el iouring corrupted read

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 + moreinfo
Bug #1032104 [src:linux] linux: ppc64el iouring corrupted read
Added tag(s) moreinfo.

-- 
1032104: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032104
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1032104: linux: ppc64el iouring corrupted read

2023-04-06 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

Hi
On Sun, Mar 19, 2023 at 05:02:19PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sat, Mar 18, 2023 at 11:19:29PM -0700, Otto Kekäläinen wrote:
> > Any updates on this one?
> > 
> > I am still seeing the main.index_merge_innodb failure in
> > https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=ppc64el&ver=1%3A10.11.2-2%7Eexp1&stamp=1678728871&raw=0
> > and rebuild 
> > https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=ppc64el&ver=1%3A10.11.2-2%7Eexp1&stamp=1679174850&raw=0.
> > 
> > Logs show: Kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian
> > 5.10.162-1 (2023-01-21) ppc64el (ppc64le)
> 
> Remember that with the 5.10.162 upstream version the io_uring code was
> rebased to the 5.15-stable one. So it is likely, and it maches the
> verison ranges, that the regression was introduced with this
> particular changes. Ideally someone with access to the given
> architecture, can verify that the issue is gone with the current
> 5.10.175 upstream (where there were several followup fixes, in
> particular e.g. a similar one for s390x), and if not, reports the
> problem to upstream.
> 
> Paul Gevers asked if the issues are gone as well with 6.1.12-1
> (or later 6.1.y series versions, which will land in bookworm). That
> would be valuable information to know as well to exclude we do not
> have the issue as well in bookworm.

Were you able to verify this?

Regards,
Salvatore



Processed: tagging 1028371

2023-04-06 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 1028371 - pending
Bug #1028371 [src:bernhard] bernhard: needs rebuilds on top of new protobuf
Removed tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1028371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028371
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1034032: rust-bitflags: autopkgtest regression: error[E0277]: the trait bound `SerdeFlags: Deserialize<'_>` is not satisfied

2023-04-06 Thread Paul Gevers

Source: rust-bitflags
Version: 1.3.2-2
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-bitflags/32255138/log.gz

 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=glob 
CARGO_MANIFEST_DIR=/tmp/tmp.u55zB0qp8W/registry/glob-0.3.0 
CARGO_PKG_AUTHORS='The Rust Project Developers' 
CARGO_PKG_DESCRIPTION='Support for matching file paths against Unix 
shell style patterns.
' CARGO_PKG_HOMEPAGE='https://github.com/rust-lang/glob' 
CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE='' 
CARGO_PKG_NAME=glob 
CARGO_PKG_REPOSITORY='https://github.com/rust-lang/glob' 
CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.3.0 
CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=3 
CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/tmp/tmp.u55zB0qp8W/target/debug/deps:/usr/lib' rustc 
--crate-name glob /tmp/tmp.u55zB0qp8W/registry/glob-0.3.0/src/lib.rs 
--error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type 
lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C 
metadata=18ed03da62dd1beb -C extra-filename=-18ed03da62dd1beb --out-dir 
/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -L 
dependency=/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps 
-L dependency=/tmp/tmp.u55zB0qp8W/target/debug/deps --cap-lints warn -C 
debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C 
link-arg=-Wl,-z,relro --remap-path-prefix 
/usr/share/cargo/registry/bitflags-1.3.2=/usr/share/cargo/registry/bitflags-1.3.2 
--remap-path-prefix /tmp/tmp.u55zB0qp8W/registry=/usr/share/cargo/registry`

warning: trait objects without an explicit `dyn` are deprecated
   --> /usr/share/cargo/registry/glob-0.3.0/src/lib.rs:294:32
|
294 | fn cause(&self) -> Option<&Error> {
|^
|
= note: `#[warn(bare_trait_objects)]` on by default
= warning: this is accepted in the current edition (Rust 2015) but 
is a hard error in Rust 2021!
= note: for more information, see 


help: use `dyn`
|
294 - fn cause(&self) -> Option<&Error> {
294 + fn cause(&self) -> Option<&dyn Error> {
|

warning: use of deprecated associated function 
`std::error::Error::description`: use the Display impl or to_string()

   --> /usr/share/cargo/registry/glob-0.3.0/src/lib.rs:291:20
|
291 | self.error.description()
|^^^
|
= note: `#[warn(deprecated)]` on by default

warning: `glob` (lib) generated 2 warnings
   Compiling once_cell v1.17.0
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=once_cell 
CARGO_MANIFEST_DIR=/tmp/tmp.u55zB0qp8W/registry/once_cell-1.17.0 
CARGO_PKG_AUTHORS='Aleksey Kladov ' 
CARGO_PKG_DESCRIPTION='Single assignment cells and lazy values.' 
CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' 
CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=once_cell 
CARGO_PKG_REPOSITORY='https://github.com/matklad/once_cell' 
CARGO_PKG_RUST_VERSION=1.56 CARGO_PKG_VERSION=1.17.0 
CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=17 
CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/tmp/tmp.u55zB0qp8W/target/debug/deps:/usr/lib' rustc 
--crate-name once_cell --edition=2021 
/tmp/tmp.u55zB0qp8W/registry/once_cell-1.17.0/src/lib.rs 
--error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type 
lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 
--cfg 'feature="alloc"' --cfg 'feature="default"' --cfg 'feature="race"' 
--cfg 'feature="std"' -C metadata=de70ba2dc91f60b7 -C 
extra-filename=-de70ba2dc91f60b7 --out-dir 
/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -L 
dependency=/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps 
-L dependency=/tmp/tmp.u55zB0qp8W/target/debug/deps --cap-lints warn -C 
debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C 
link-arg=-Wl,-z,relro --remap-path-prefix 
/usr/share/cargo/registry/bitflags-1.3.2=/usr/share/cargo/registry/bitflags-1.3.2 
--remap

Processed: rust-bitflags: autopkgtest regression: error[E0277]: the trait bound `SerdeFlags: Deserialize<'_>` is not satisfied

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 bookworm-ignore
Bug #1034032 [src:rust-bitflags] rust-bitflags: autopkgtest regression: 
error[E0277]: the trait bound `SerdeFlags: Deserialize<'_>` is not satisfied
Added tag(s) bookworm-ignore.

-- 
1034032: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034032
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1034030: rust-async-stream: autopkgtest regression: error[E0658]: yield syntax is experimental

2023-04-06 Thread Paul Gevers

Source: rust-async-stream
Version: 0.3.3-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails since December 
2022. Can you please investigate the situation and fix it? I copied some 
of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-async-stream/32102899/log.gz

test tests/ui/yield_in_async.rs ... mismatch

EXPECTED:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^
  |
  = note: see issue #43122 
 for more information


error[E0727]: `async` generators are not yet supported
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^

error[E0271]: type mismatch resolving `<[static 
generator@$DIR/src/lib.rs:201:9: 201:67] as Generator>::Yield 
== ()`

  --> tests/ui/yield_in_async.rs:4:5
   |
4  | / stream! {
5  | | let f = async {
6  | | yield 123;
7  | | };
8  | |
9  | | let v = f.await;
10 | | };
   | |_^ expected `()`, found integer
   |
note: required by a bound in `from_generator`
  --> $RUST/core/src/future/mod.rs
   |
   | T: Generator,
   |^^ required by this bound in 
`from_generator`
   = note: this error originates in the macro `stream` (in Nightly 
builds, run with -Z macro-backtrace for more info)



ACTUAL OUTPUT:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^
  |
  = note: see issue #43122 
 for more information


error[E0727]: `async` generators are not yet supported
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^

error[E0271]: type mismatch resolving `<[static 
generator@$DIR/src/lib.rs:201:9: 201:67] as Generator>::Yield 
== ()`

  --> tests/ui/yield_in_async.rs:4:5
   |
4  | / stream! {
5  | | let f = async {
6  | | yield 123;
7  | | };
8  | |
9  | | let v = f.await;
10 | | };
   | |_^ expected `()`, found integer
   |
note: required by a bound in `std::future::from_generator`
   = note: this error originates in the macro `stream` (in Nightly 
builds, run with -Z macro-backtrace for more info)


note: If the actual output is the correct output you can bless it by 
rerunning

  your test with the environment variable TRYBUILD=overwrite

test tests/ui/yield_in_closure.rs ... mismatch

EXPECTED:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_closure.rs:7:17
  |
7 | yield v;
  | ^^^
  |
  = note: see issue #43122 
 for more information


error[E0277]: expected a `FnOnce<(&str,)>` closure, found 
`[generator@$DIR/src/lib.rs:201:9: 201:67]`

--> tests/ui/yield_in_closure.rs:6:14
 |
6| .and_then(|v| {
 |   expected an `FnOnce<(&str,)>` closure, 
found `[generator@$DIR/src/lib.rs:201:9: 201:67]`

 |
 = help: the trait `FnOnce<(&str,)>` is not implemented for 
`[generator@$DIR/src/lib.rs:201:9: 201:67]`

note: required by a bound in `Resultand_then`
--> $RUST/core/src/result.rs
 |
 | pub fn and_then Result>(self, op: 
F) -> Result {
 |   ^ required by 
this bound in `Resultand_then`



ACTUAL OUTPUT:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_closure.rs:7:17
  |
7 | yield v;
  | ^^^
  |
  = note: see issue #43122 
 for more information


error[E0277]: expected a `FnOnce<(&str,)>` closure, found 
`[generator@$DIR/src/lib.rs:201:9: 201:67]`

 --> tests/ui/yield_in_closure

Processed: rust-async-stream: autopkgtest regression: error[E0658]: yield syntax is experimental

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 bookworm-ignore
Bug #1034030 [src:rust-async-stream] rust-async-stream: autopkgtest regression: 
error[E0658]: yield syntax is experimental
Added tag(s) bookworm-ignore.

-- 
1034030: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034030
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1034028: ruby-rails-assets-jquery: autopkgtest regression: Don't know how to build task 'assets:precompile'

2023-04-06 Thread Paul Gevers

Source: ruby-rails-assets-jquery
Version: 3.5.1+dfsg-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails since November 
2021. Can you please investigate the situation and fix it? I copied some 
of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-rails-assets-jquery/32420365/log.gz

Use `bundle info [gemname]` to see where a bundled gem is installed.
+ cat
+ cat
+ cat
+ cat
+ bundle exec rake assets:precompile
rake aborted!
Don't know how to build task 'assets:precompile' (See the list of 
available tasks with `rake --tasks`)


(See full trace by running task with --trace)


OpenPGP_signature
Description: OpenPGP digital signature


Processed: ruby-rails-assets-jquery: autopkgtest regression: Don't know how to build task 'assets:precompile'

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 bookworm-ignore
Bug #1034028 [src:ruby-rails-assets-jquery] ruby-rails-assets-jquery: 
autopkgtest regression: Don't know how to build task 'assets:precompile'
Added tag(s) bookworm-ignore.

-- 
1034028: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034028
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: Re: The autopkgtests are failing with the current rails version

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 serious
Bug #946846 [ruby-rails-assets-highlightjs] The autopkgtests are failing with 
the current rails version
Severity set to 'serious' from 'normal'
> tags -1 bookworm-ignore
Bug #946846 [ruby-rails-assets-highlightjs] The autopkgtests are failing with 
the current rails version
Added tag(s) bookworm-ignore.

-- 
946846: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946846
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: ruby-rails-assets-fine-uploader: autopkgtest regression: Don't know how to build task 'assets:precompile'

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 bookworm-ignore sid bookworm
Bug #1034027 [src:ruby-rails-assets-fine-uploader] 
ruby-rails-assets-fine-uploader: autopkgtest regression: Don't know how to 
build task 'assets:precompile'
Added tag(s) sid, bookworm-ignore, and bookworm.

-- 
1034027: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034027
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1034027: ruby-rails-assets-fine-uploader: autopkgtest regression: Don't know how to build task 'assets:precompile'

2023-04-06 Thread Paul Gevers

Source: ruby-rails-assets-fine-uploader
Version: 5.13.0-2
Severity: serious
Control: tags -1 bookworm-ignore sid bookworm
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails since November 
2021. Can you please investigate the situation and fix it? I copied some 
of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-rails-assets-fine-uploader/32420363/log.gz

Bundle complete! 3 Gemfile dependencies, 25 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
+ cat
+ cat
+ cat
+ cat
+ bundle exec rake assets:precompile
rake aborted!
Don't know how to build task 'assets:precompile' (See the list of 
available tasks with `rake --tasks`)


(See full trace by running task with --trace)


OpenPGP_signature
Description: OpenPGP digital signature


Processed: Re: Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 pending patch
Bug #1026204 [tar] tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Added tag(s) patch and pending.

-- 
1026204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026204
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

2023-04-06 Thread Paul Gevers

Control: tags -1 pending patch

Hi all,

On Tue, 31 Jan 2023 18:27:27 +0100 Andreas Henriksson  
wrote:

> So, please use this hunk instead. It compiles for me on amd64 and 32-bit hppa.
> 
> export DEB_BUILD_MAINT_OPTIONS = future=+lfs
> export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument

Might be useful to add a comment here saying:

# Workaround gnulib issue: The below three lines can be dropped once tar >= 
1.35 is used.
> ifneq ($(shell dpkg-architecture -qDEB_TARGET_ARCH_BITS),64)
> export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64
> endif
> 
> DPKG_EXPORT_BUILDFLAGS = 1

> include /usr/share/dpkg/buildflags.mk
> ---


I have uploaded the attached debdiff to DELAYED/2 and pushed my changes 
to salsa. If nobody shouts that I understood the intentions correctly 
and/or cancels the upload, it should land in two days in unstable


Paul
diff -Nru tar-1.34+dfsg/debian/changelog tar-1.34+dfsg/debian/changelog
--- tar-1.34+dfsg/debian/changelog  2022-11-20 15:52:41.0 +0100
+++ tar-1.34+dfsg/debian/changelog  2023-04-06 16:25:47.0 +0200
@@ -1,3 +1,11 @@
+tar (1.34+dfsg-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with lfs and -D_TIME_BITS=64 on 32 bits archs (Closes: #1026204)
+Thanks to Andreas Henriksson and Helge Deller
+
+ -- Paul Gevers   Thu, 06 Apr 2023 16:25:47 +0200
+
 tar (1.34+dfsg-1.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru tar-1.34+dfsg/debian/rules tar-1.34+dfsg/debian/rules
--- tar-1.34+dfsg/debian/rules  2022-11-19 16:38:39.0 +0100
+++ tar-1.34+dfsg/debian/rules  2023-04-06 16:25:47.0 +0200
@@ -1,15 +1,23 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
 CONFARGS = --host=$(DEB_HOST_GNU_TYPE)
 endif
 
-CFLAGS = `dpkg-buildflags --get CFLAGS`
-CFLAGS += -Wall -Wno-analyzer-null-argument
-LDFLAGS += `dpkg-buildflags --get LDFLAGS`
-CPPFLAGS = `dpkg-buildflags --get CPPFLAGS`
+export DEB_BUILD_MAINT_OPTIONS = future=+lfs
+export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument
+# Workaround gnulib issue: The below three lines can be dropped once
+# tar >= 1.35 is used.
+ifeq (32,$(DEB_HOST_ARCH_BITS))
+export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64
+endif
+
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
 
 export BUILD_DATE = $(shell dpkg-parsechangelog | sed -n -e 's/^Date: //p')
 


OpenPGP_signature
Description: OpenPGP digital signature


Bug#977027: marked as done (rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]")

2023-04-06 Thread Debian Bug Tracking System
Your message dated Thu, 06 Apr 2023 15:19:28 +
with message-id 
and subject line Bug#977027: fixed in rhino 1.7.14-2.1
has caused the Debian Bug report #977027,
regarding rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to 
"[object Object]"
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.)


-- 
977027: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977027
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: rhino, dojo
Control: found -1 rhino/1.7.7.2-1
Control: found -1 dojo/1.15.3+dfsg1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of rhino the autopkgtest of dojo fails in testing
when that autopkgtest is run with the binary packages of rhino from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
rhino  from testing1.7.7.2-1
dojo   from testing1.15.3+dfsg1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of rhino to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rhino

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dojo/7045098/log.gz
autopkgtest [01:52:16]: test shrinksafe: [---
js: "../../dojo/dojo.js", line 1321: exception from uncaught JavaScript
throw: TypeError: Cannot set property "dojo" of null to "[object Object]"

autopkgtest [01:52:18]: test shrinksafe: ---]




signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: rhino
Source-Version: 1.7.14-2.1
Done: Paul Gevers 

We believe that the bug you reported is fixed in the latest version of
rhino, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 977...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Paul Gevers  (supplier of updated rhino package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 06 Apr 2023 13:10:20 +0200
Source: rhino
Architecture: source
Version: 1.7.14-2.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Paul Gevers 
Closes: 977027
Changes:
 rhino (1.7.14-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload
   * Add versioned Breaks on shrinksafe (Closes: #977027)
Checksums-Sha1:
 3844e5e0901376c699598f9ec92ede714624f215 1807 rhino_1.7.14-2.1.dsc
 5047e73491da66101d422917accb3d7bdb69ef79 17188 rhino_1.7.14-2.1.debian.tar.xz
Checksums-Sha256:
 6e460c3b93d5b1fec093d48db2836cee8ad2d632a3ef8e3ac85c1c4fc9312d4a 1807 
rhino_1.7.14-2.1.dsc
 98412369a7733faa16cd30b8cfa14f51a48c8cb67606fc900469934e15952de6 17188 
rhino_1.7.14-2.1.debian.tar.xz
Files:
 4d47652eccee894efb863762e4c423f8 1807 interpreters optional 
rhino_1.7.14-2.1.dsc
 20a07018b182f557e50cda50d7f0dfc9 17188 interpreters optional 
rhino_1.7.14-2.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmQuqf8ACgkQnFyZ6wW9
dQo5gQf+IZg6jDvpeEm5v4CStn0d+AdzOIZa/sS4w+KjRkV+wRwbNAh/r0BCZIGT
0OLzB9sozc4OacMgpi7MVafOAkEIpyIKM/VG4zhwmH3xcdDlgDqC45oi8rAPIV8t
CEmY6MjN3tvu79/ouQGbFabOFjJ3Buuw8bbnMjNcpCmVwRPnpfGijxxKK4q7K1HN
dRzqhua8Gc/6oeSbu+WbFkaZ9aE5e2CP5tHcc26ioBZQ45SQAeEWkFPyu2DtaRGO
2PIxbv4Ezth5hQVyt6PGCqjEN3yT1qBs/GHo/J0LQR+A0c2uucb5EdHoYpAi7Bjy
lRBEQ4OXSAYQpxQjTHbWPeffB1Sw2A==
=Hwv3
-END PGP SIGNATURE End Message ---


Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

2023-04-06 Thread Paul Gevers

Hi Markus,

Thanks for following-up. It further clarified pieces.

On 06-04-2023 15:14, Markus Koschany wrote:

I always rebuild all reverse-dependencies with ratt before I upload a Java
library package. From my Java experience I know this uncovers almost all
problems. Rhino is not some obscure C/C++ library. It is a Javascript engine
written in Java. You can install reverse-dependencies and run them against the
new rhino version. If the package works, then there is no further action
required. Could I have missed a corner case? Maybe.


If you believe it to be a corner case (that you elaborate on later on), 
then I trust you on that. The corner case just looked like a transition 
from our side (Release Team) of the story.



 From dojo developer documentation:

"Note that the linkage requires the same version of Rhino used to build the
shrinksafe.jar. In versions prior to Dojo 1.3, ShrinkSafe was bundled into
Rhino by way of patch, and shipped as custom_rhino.jar."


Thanks for that piece of info.


We can do a binNMU for all reverse-dependencies but I do not think it is
necessary.


Good to know, I wasn't particularly liking the idea.


Also, given that shrinksafe is from a different source than rhino, this
qualifies as a transition (it *needs* changes in different (binary)
packages).


I cannot remember when we asked for a Java library transition in the past.
shrinksafe is, as I pointed out before, a special case. It was once part of the
rhino distribution and probably should have tightened the dependency on a
specific rhino version in the first place.


Ok, let's have the dojo maintainers tighten the relation then in their 
next upload.



2. shrinksafe has no reverse-dependencies


So it can be easily removed, but that's not a great service to its users.


No, we don't want to remove neither shrinksafe nor any other package. Please
don't exaggerate the problem at hand.


Well, autoremoval was about to do that in a few days if nobody intervened.


The solution is to tighten the dependency on rhino and adjust the autopkgtest
accordingly.


If the dependency is tightened, autopkgtest will do the right thing.


6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable.
Hence
why I tightened the dependency on rhino to 1.7.14. The current version of
rhino
in testing breaks the Javascript application.


Suggesting even more that this is a real transition.


You are misunderstanding the problem. OpenRefine does not work with Rhino in
testing. The new rhino in unstable fixes the problem. Again, rhino 1.7.14 is
the solution, not the cause of the problem.
[...]


Yes, I typed this before I had further insights and forgot to review 
this piece. Indeed, you're right.



I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5
today, where I'll add an appropriate Breaks to src:rhino and an
appropriate versioned Depends to src:dojo. Please let me know if you
object or want to handle this yourself.


Fine with me and thanks!


I'll also reschedule rhino then.

Thanks for your help and contributions for bookworm.

Paul


OpenPGP_signature
Description: OpenPGP digital signature


Processed: bug 1033822 is forwarded to https://github.com/wbond/oscrypto/issues/73

2023-04-06 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> forwarded 1033822 https://github.com/wbond/oscrypto/issues/73
Bug #1033822 [src:oscrypto] oscrypto: autopkgtest regression: certificate 
expired 2023-01-01 00:00:00Z
Set Bug forwarded-to-address to 'https://github.com/wbond/oscrypto/issues/73'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1033822: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033822
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions

2023-04-06 Thread Anton Gladky
Hi Paul,

Yes i will do it.


Paul Gevers  schrieb am Do., 6. Apr. 2023, 14:36:

> Hi,
>
> On Tue, 21 Mar 2023 21:58:11 +0100 Paul Gevers  wrote:
> > On Sun, 08 Jan 2023 00:26:39 +0100 Andreas Beckmann 
> wrote:
> > > This happens with g++-12 but not with g++-11.
> > > It is fixed in the boost version in experimental.
> >
> > Any chance for a *targeted* fix in bookworm?
>
> Ping. (No is also an answer).
>
> Paul
>


Bug#977027: [Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

2023-04-06 Thread Paul Gevers

Hi,

On 06-04-2023 14:50, Bastien ROUCARIES wrote:

On 06-04-2023 12:54, Paul Gevers wrote:

I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5


Please find the debdiffs attached.


Go ahead


Thanks, I have rescheduled dojo to 0 days and it got accepted.

Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#977027: marked as done (rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]")

2023-04-06 Thread Debian Bug Tracking System
Your message dated Thu, 06 Apr 2023 13:20:01 +
with message-id 
and subject line Bug#977027: fixed in dojo 1.17.2+dfsg1-2.1
has caused the Debian Bug report #977027,
regarding rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to 
"[object Object]"
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.)


-- 
977027: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977027
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: rhino, dojo
Control: found -1 rhino/1.7.7.2-1
Control: found -1 dojo/1.15.3+dfsg1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of rhino the autopkgtest of dojo fails in testing
when that autopkgtest is run with the binary packages of rhino from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
rhino  from testing1.7.7.2-1
dojo   from testing1.15.3+dfsg1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of rhino to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rhino

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dojo/7045098/log.gz
autopkgtest [01:52:16]: test shrinksafe: [---
js: "../../dojo/dojo.js", line 1321: exception from uncaught JavaScript
throw: TypeError: Cannot set property "dojo" of null to "[object Object]"

autopkgtest [01:52:18]: test shrinksafe: ---]




signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: dojo
Source-Version: 1.17.2+dfsg1-2.1
Done: Paul Gevers 

We believe that the bug you reported is fixed in the latest version of
dojo, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 977...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Paul Gevers  (supplier of updated dojo package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 06 Apr 2023 12:59:48 +0200
Source: dojo
Architecture: source
Version: 1.17.2+dfsg1-2.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Javascript Maintainers 

Changed-By: Paul Gevers 
Closes: 977027
Changes:
 dojo (1.17.2+dfsg1-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload
   * Add versioned (Build-)Depends on rhino/librhino-java (Closes: #977027)
Checksums-Sha1:
 9aa6800c2d29269a410e3217f90a18c89633d2b4 2122 dojo_1.17.2+dfsg1-2.1.dsc
 2661cd3cee87fa51c4450948e903538022a27884 17508 
dojo_1.17.2+dfsg1-2.1.debian.tar.xz
Checksums-Sha256:
 103d763376406455ff7a29e4af50fc8e067579e376882b4841cef7f7be0f3b7c 2122 
dojo_1.17.2+dfsg1-2.1.dsc
 fef9482a459f3d3ede376c3ff9e5a23ebac2807dd0c98fa246218a330348f519 17508 
dojo_1.17.2+dfsg1-2.1.debian.tar.xz
Files:
 377ceb305c0022405b53fe01d56d0630 2122 javascript optional 
dojo_1.17.2+dfsg1-2.1.dsc
 a0a4396944bf0cfd609dac8f90e721d4 17508 javascript optional 
dojo_1.17.2+dfsg1-2.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmQuqnAACgkQnFyZ6wW9
dQpJygf+II1h1WQPdAY00ALoUi/9qVVsp2GIDzgz9KL1eZ1ry1js7XsWpp0Az0YV
SfB6m9pt9SOYg5WFB3N2dzyjVY8bi5snJVzGQI/GSnZiprmCDTRtbtEx7hplFJz9
8DHxSe8dLGlGbZAlciVDiWr2HOjyeZt4jY0Zj4H4zQ69lI5pZP704oYixemsiqDv
uNEwNgspxmKbBA9tJbyffdkHM3dQk/6HMIGMy2v9OWgLP8aMuSIfNNUP9H3BloEk
bK8/q8+71BsH4Hq/eSYqm7my7nQNtfaDPhjppiEsV+J59Lya/i8RUpKLEo+jF4Qx
4I0W0iIzjfTYYOoGDtUUlj0VFCQyeA==
=SOuF
-END PGP SIGNATURE End Message ---


Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

2023-04-06 Thread Markus Koschany
Hello,

Am Donnerstag, dem 06.04.2023 um 12:54 +0200 schrieb Paul Gevers:
> Hi,
> 
> On Sun, 26 Mar 2023 16:26:00 +0200 Markus Koschany  wrote:
> > 1. There is no transition needed because only shrinksafe is affected by the
> > new
> > rhino version.
> 
> I'm wondering how you know, did you test (without rebuilding) all the 
> reverse dependencies? If so, how did you do that? (I'm worried we're 
> missing cases like src:dojo).

I always rebuild all reverse-dependencies with ratt before I upload a Java
library package. From my Java experience I know this uncovers almost all
problems. Rhino is not some obscure C/C++ library. It is a Javascript engine
written in Java. You can install reverse-dependencies and run them against the
new rhino version. If the package works, then there is no further action
required. Could I have missed a corner case? Maybe. But there is always a risk
whenever you change something. Remember why we did the upgrade in the first
place. We did fix two RC bugs and just hit a special case with a leaf package
(shrinksafe)

From dojo developer documentation:

"Note that the linkage requires the same version of Rhino used to build the
shrinksafe.jar. In versions prior to Dojo 1.3, ShrinkSafe was bundled into
Rhino by way of patch, and shipped as custom_rhino.jar."

We can do a binNMU for all reverse-dependencies but I do not think it is
necessary.

> 
> Also, given that shrinksafe is from a different source than rhino, this 
> qualifies as a transition (it *needs* changes in different (binary) 
> packages).

I cannot remember when we asked for a Java library transition in the past.
shrinksafe is, as I pointed out before, a special case. It was once part of the
rhino distribution and probably should have tightened the dependency on a
specific rhino version in the first place. 

> 
> > 2. shrinksafe has no reverse-dependencies
> 
> So it can be easily removed, but that's not a great service to its users.

No, we don't want to remove neither shrinksafe nor any other package. Please
don't exaggerate the problem at hand.


> > 3. We had the exact same problem before [1]. Back then the fix was to
> > rebuild
> > the package and to fix the shrinksafe tests by setting a specific
> > Javascript
> > version. [2] Since just rebuilding dojo also fixes the problem, I assume
> > that
> > we don't have to change this option.
> 
> Well, rebuilding without fixing the underlying issue is just papering 
> over. I'd like to get a proper (future proof) solution in place, see 
> below. (And yes, we can paper over for bookworm now).

The solution is to tighten the dependency on rhino and adjust the autopkgtest
accordingly. 

> > 4. I have rebuilt all rhino reverse-dependencies successfully.
> 
> Yes, normal transitions are handled that way, we (the Release Team) 
> schedule binNMU's for those (albeit we can't do arch:all that way).

As I said this is standard procedure for Java libraries which I touch. It does
not imply a transition is needed.

> > 6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable.
> > Hence
> > why I tightened the dependency on rhino to 1.7.14. The current version of
> > rhino
> > in testing breaks the Javascript application.
> 
> Suggesting even more that this is a real transition.

You are misunderstanding the problem. OpenRefine does not work with Rhino in
testing. The new rhino in unstable fixes the problem. Again, rhino 1.7.14 is
the solution, not the cause of the problem.
[...]
> 



> 
> I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5 
> today, where I'll add an appropriate Breaks to src:rhino and an 
> appropriate versioned Depends to src:dojo. Please let me know if you 
> object or want to handle this yourself.

Fine with me and thanks!


Markus


signature.asc
Description: This is a digitally signed message part


Bug#977027: [Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

2023-04-06 Thread Bastien ROUCARIES
Le jeu. 6 avr. 2023 à 11:24, Paul Gevers  a écrit :
>
> Control: tags -1 pending patch
>
> On 06-04-2023 12:54, Paul Gevers wrote:
> > I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5
>
> Please find the debdiffs attached.

Go ahead
>
> Paul
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel



Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions

2023-04-06 Thread Paul Gevers

Hi,

On Tue, 21 Mar 2023 21:58:11 +0100 Paul Gevers  wrote:

On Sun, 08 Jan 2023 00:26:39 +0100 Andreas Beckmann  wrote:
> This happens with g++-12 but not with g++-11.
> It is fixed in the boost version in experimental.

Any chance for a *targeted* fix in bookworm?


Ping. (No is also an answer).

Paul


OpenPGP_signature
Description: OpenPGP digital signature


Processed: Re: gffread: autopkgtest regression: test dependency not in testing

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 bookworm-ignore
Bug #1033703 [src:gffread] gffread: autopkgtest regression: test dependency not 
in testing
Added tag(s) bookworm-ignore.
> tags -1 - bookworm
Bug #1033703 [src:gffread] gffread: autopkgtest regression: test dependency not 
in testing
Removed tag(s) bookworm.

-- 
1033703: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033703
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1033703: gffread: autopkgtest regression: test dependency not in testing

2023-04-06 Thread Paul Gevers

Control: tags -1 bookworm-ignore
Control: tags -1 - bookworm

Hi

On Thu, 30 Mar 2023 19:04:08 +0200 Paul Gevers  wrote:

Control: tags -1 bookworm


[Release Team member hat on] Because 
we're currently in the hard freeze, I've marked this bug as 
bookworm-ignore, but targeted fixes are welcome.


Sorry, I had a typo.

Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

2023-04-06 Thread Paul Gevers

Control: tags -1 pending patch

On 06-04-2023 12:54, Paul Gevers wrote:

I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5


Please find the debdiffs attached.

Paul
diff -Nru rhino-1.7.14/debian/changelog rhino-1.7.14/debian/changelog
--- rhino-1.7.14/debian/changelog   2023-02-18 00:46:00.0 +0100
+++ rhino-1.7.14/debian/changelog   2023-04-06 13:10:20.0 +0200
@@ -1,3 +1,10 @@
+rhino (1.7.14-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Add versioned Breaks on shrinksafe (Closes: #977027)
+
+ -- Paul Gevers   Thu, 06 Apr 2023 13:10:20 +0200
+
 rhino (1.7.14-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru rhino-1.7.14/debian/control rhino-1.7.14/debian/control
--- rhino-1.7.14/debian/control 2023-02-18 00:46:00.0 +0100
+++ rhino-1.7.14/debian/control 2023-04-06 13:10:20.0 +0200
@@ -31,6 +31,7 @@
 Section: java
 Architecture: all
 Depends: ${misc:Depends}
+Breaks: shrinksafe (<< 1.17.2+dfsg1-2.1~)
 Suggests: rhino
 Description: Libraries for rhino Java Script Engine
  Rhino is an implementation of the JavaScript language written
diff -Nru dojo-1.17.2+dfsg1/debian/changelog dojo-1.17.2+dfsg1/debian/changelog
--- dojo-1.17.2+dfsg1/debian/changelog  2022-08-13 18:48:08.0 +0200
+++ dojo-1.17.2+dfsg1/debian/changelog  2023-04-06 12:59:48.0 +0200
@@ -1,3 +1,10 @@
+dojo (1.17.2+dfsg1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Add versioned (Build-)Depends on rhino/librhino-java (Closes: #977027)
+
+ -- Paul Gevers   Thu, 06 Apr 2023 12:59:48 +0200
+
 dojo (1.17.2+dfsg1-2) unstable; urgency=medium
 
   * Add jdupes to build-dep
diff -Nru dojo-1.17.2+dfsg1/debian/control dojo-1.17.2+dfsg1/debian/control
--- dojo-1.17.2+dfsg1/debian/control2022-08-13 18:47:45.0 +0200
+++ dojo-1.17.2+dfsg1/debian/control2023-04-06 12:59:48.0 +0200
@@ -6,7 +6,7 @@
   Bastien Roucariès 
 Build-Depends: debhelper-compat (= 13), nodejs,
  javahelper
-Build-Depends-Indep: default-jdk, rhino, rsync , jdupes 
+Build-Depends-Indep: default-jdk, rhino (>= 1.7.14), rsync , jdupes 

 Standards-Version: 4.6.1.0
 Rules-Requires-Root: no
 Homepage: https://dojotoolkit.org
@@ -63,7 +63,7 @@
 
 Package: shrinksafe
 Architecture: all
-Depends: ${misc:Depends}, ${java:Depends}, librhino-java
+Depends: ${misc:Depends}, ${java:Depends}, librhino-java (>= 1.7.14)
 Description: JavaScript compression system
  ShrinkSafe is a JavaScript compression system. It can typically reduce the
  size of your scripts by a third or more, depending on your programming style.


OpenPGP_signature
Description: OpenPGP digital signature


Processed: Re: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

2023-04-06 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 pending patch
Bug #977027 [src:rhino,src:dojo] rhino breaks dojo autopkgtest: Cannot set 
property "dojo" of null to "[object Object]"
Added tag(s) patch and pending.

-- 
977027: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977027
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

2023-04-06 Thread Paul Gevers

Hi,

On Sun, 26 Mar 2023 16:26:00 +0200 Markus Koschany  wrote:

1. There is no transition needed because only shrinksafe is affected by the new
rhino version.


I'm wondering how you know, did you test (without rebuilding) all the 
reverse dependencies? If so, how did you do that? (I'm worried we're 
missing cases like src:dojo).


Also, given that shrinksafe is from a different source than rhino, this 
qualifies as a transition (it *needs* changes in different (binary) 
packages).



2. shrinksafe has no reverse-dependencies


So it can be easily removed, but that's not a great service to its users.


3. We had the exact same problem before [1]. Back then the fix was to rebuild
the package and to fix the shrinksafe tests by setting a specific Javascript
version. [2] Since just rebuilding dojo also fixes the problem, I assume that
we don't have to change this option.


Well, rebuilding without fixing the underlying issue is just papering 
over. I'd like to get a proper (future proof) solution in place, see 
below. (And yes, we can paper over for bookworm now).



4. I have rebuilt all rhino reverse-dependencies successfully.


Yes, normal transitions are handled that way, we (the Release Team) 
schedule binNMU's for those (albeit we can't do arch:all that way).



6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable. Hence
why I tightened the dependency on rhino to 1.7.14. The current version of rhino
in testing breaks the Javascript application.


Suggesting even more that this is a real transition.


7. Summary: I recommend to rebuild dojo to fix the autopkgtests. I suggest to
reconsider the current autopkgtest behavior. At least there should be a warning
or a note for maintainers in the future that dojo requires a rebuild whenever
rhino changes.


In Debian we normally handle that by either real or virtual abi packages 
(although in your other message you mention you didn't know of the 
breakage, so I guess that wouldn't have helped in this particular case, 
but it would have given you the knob to fix it after the discovery of 
the breakage). We have a huge collection of examples in Debian for that. 
If rhino (the binary) were to Provides an abi, than dojo could Depends 
on that (with the right version inserted during the build). The Release 
Team tooling [1] would then pick up when the ABI is bumped such that 
binNMU's can be scheduled (or the appropriate people can be notified in 
case of arch:all).


I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5 
today, where I'll add an appropriate Breaks to src:rhino and an 
appropriate versioned Depends to src:dojo. Please let me know if you 
object or want to handle this yourself.


Normally we would defer the new upstream version and transition at this 
stage of the release, but I want rhino to migrate to bookworm.


Paul

[1] https://release.debian.org/transitions/


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1033778: marked as done (nvidia-graphics-drivers-tesla-450: CVE-2023-0184, CVE-2023-0189, CVE-2023-0180, CVE-2023-0185, CVE-2023-0198, CVE-2023-0199, CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, C

2023-04-06 Thread Debian Bug Tracking System
Your message dated Thu, 06 Apr 2023 08:20:25 +
with message-id 
and subject line Bug#1033778: fixed in nvidia-graphics-drivers-tesla-450 
450.236.01-1
has caused the Debian Bug report #1033778,
regarding nvidia-graphics-drivers-tesla-450: CVE-2023-0184, CVE-2023-0189, 
CVE-2023-0180, CVE-2023-0185, CVE-2023-0198, CVE-2023-0199, CVE-2023-0188, 
CVE-2023-0190, CVE-2023-0194, CVE-2023-0195, CVE-2023-0191
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.)


-- 
1033778: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033778
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: nvidia-graphics-drivers
Severity: serious
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 
Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10
Control: reassign -2 src:nvidia-graphics-drivers-legacy-340xx 340.76-6
Control: retitle -2 nvidia-graphics-drivers-legacy-340xx: CVE-2023-0184, 
CVE-2023-0189, CVE-2023-0180, CVE-2023-0185, CVE-2023-0198, CVE-2023-0199, 
CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, CVE-2023-0195, CVE-2023-0191
Control: tag -2 + wontfix
Control: reassign -3 src:nvidia-graphics-drivers-legacy-390xx 390.48-4
Control: retitle -3 nvidia-graphics-drivers-legacy-390xx: CVE-2023-0184, 
CVE-2023-0189, CVE-2023-0180, CVE-2023-0185, CVE-2023-0198, CVE-2023-0199, 
CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, CVE-2023-0195, CVE-2023-0191
Control: tag -3 + wontfix
Control: reassign -4 src:nvidia-graphics-drivers-tesla-418 418.87.01-1
Control: retitle -4 nvidia-graphics-drivers-tesla-418: CVE-2023-0184, 
CVE-2023-0189, CVE-2023-0180, CVE-2023-0185, CVE-2023-0198, CVE-2023-0199, 
CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, CVE-2023-0195, CVE-2023-0191
Control: tag -4 + wontfix
Control: reassign -5 src:nvidia-graphics-drivers-tesla-450 450.51.05-1
Control: retitle -5 nvidia-graphics-drivers-tesla-450: CVE-2023-0184, 
CVE-2023-0189, CVE-2023-0180, CVE-2023-0185, CVE-2023-0198, CVE-2023-0199, 
CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, CVE-2023-0195, CVE-2023-0191
Control: reassign -6 src:nvidia-graphics-drivers-tesla-460 460.32.03-1
Control: retitle -6 nvidia-graphics-drivers-tesla-460: CVE-2023-0184, 
CVE-2023-0189, CVE-2023-0180, CVE-2023-0185, CVE-2023-0187, CVE-2023-0198, 
CVE-2023-0199, CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, CVE-2023-0195, 
CVE-2023-0191
Control: tag -6 + wontfix
Control: close -6 460.106.00-3
Control: reassign -7 src:nvidia-graphics-drivers-tesla-470 470.57.02-1
Control: retitle -7 nvidia-graphics-drivers-tesla-470: CVE-2023-0184, 
CVE-2023-0189, CVE-2023-0180, CVE-2023-0185, CVE-2023-0187, CVE-2023-0198, 
CVE-2023-0199, CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, CVE-2023-0195, 
CVE-2023-0191
Control: reassign -8 src:nvidia-graphics-drivers-tesla-510 510.47.03-1
Control: retitle -8 nvidia-graphics-drivers-tesla-510: CVE-2023-0184, 
CVE-2023-0189, CVE-2023-0180, CVE-2023-0183, CVE-2023-0185, CVE-2023-0187, 
CVE-2023-0198, CVE-2023-0199, CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, 
CVE-2023-0195, CVE-2023-0191
Control: tag -8 + wontfix
Control: close -8 510.85.02-2
Control: reassign -9 src:nvidia-graphics-drivers-tesla 510.85.02-1
Control: retitle -9 nvidia-graphics-drivers-tesla: CVE-2023-0184, 
CVE-2023-0189, CVE-2023-0180, CVE-2023-0183, CVE-2023-0185, CVE-2023-0187, 
CVE-2023-0198, CVE-2023-0199, CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, 
CVE-2023-0195, CVE-2023-0191
Control: found -9 515.48.07-1
Control: found -9 525.60.13-1
Control: reassign -10 src:nvidia-open-gpu-kernel-modules 515.43.04-1
Control: retitle -10 nvidia-open-gpu-kernel-modules: CVE-2023-0184, 
CVE-2023-0189, CVE-2023-0180, CVE-2023-0183, CVE-2023-0185, CVE-2023-0187, 
CVE-2023-0198, CVE-2023-0199, CVE-2023-0188, CVE-2023-0190, CVE-2023-0194, 
CVE-2023-0195, CVE-2023-0191
Control: found -10 520.56.06-1
Control: found -10 525.85.12-1
Control: found -10 530.30.02-1
Control: found -1 340.24-1
Control: found -1 343.22-1
Control: found -1 396.18-1
Control: found -1 430.14-1
Control: found -1 455.23.04-1
Control: found -1 465.24.02-1
Control: found -1 495.44-1
Control: found -1 515.48.07-1
Control: found -1 520.56.06-1
Control: found -1 525.53-1
Control: found -1 530.30.02-1
Control: fixed -1 530.41.03-1

https://nvidia.custhelp.com/app/answers/detail/a_id/5452

CVE-2023-0189   NVIDIA GPU Display Driver for Linux contains a
vulnerability in the kernel mode layer handler, which may lead to code
execution, denial of service, escalation of privileges, information
disclosure, and data tampering.

CVE-2023-0184   NVIDIA GPU Display Driver for Windows and Linux contains
a vulnerability in the kernel mode layer h

Bug#1032392: python3-scikit-rf: import fails: AttributeError: module 'collections' has no attribute 'Sequence'

2023-04-06 Thread Theppitak Karoonboonyanan
Uploaded Josef Schneider's NMU to DELAYED/2-day queue.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/



Processed: severity of 1006718 is serious, notfixed 981941 in 1.3.5, tagging 981941, reassign 1031656 to mariadb ...

2023-04-06 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> severity 1006718 serious
Bug #1006718 [src:nvidia-graphics-drivers-tesla-418] 
nvidia-graphics-drivers-tesla-418: EoL (03/2022) driver should not be released 
with bookworm
Severity set to 'serious' from 'normal'
> notfixed 981941 1.3.5
Bug #981941 [sysuser-helper] sysuser-helper: Merged-usr transition
No longer marked as fixed in versions dh-sysuser/1.3.5 and sysuser-helper/1.3.5.
> tags 981941 + sid trixie experimental
Bug #981941 [sysuser-helper] sysuser-helper: Merged-usr transition
Added tag(s) experimental, sid, and trixie.
> reassign 1031656 mariadb 1:10.11.1-1
Bug #1031656 {Done: Debian FTP Masters } 
[mariadb-10.6,mariadb] MariaDB autopkgtest upstream test suite fails on disk / 
data corruption on ppc64el
Warning: Unknown package 'mariadb-10.6'
Bug reassigned from package 'mariadb-10.6,mariadb' to 'mariadb'.
Ignoring request to alter found versions of bug #1031656 to the same values 
previously set
No longer marked as fixed in versions 1:10.6.11-2+rm.
Bug #1031656 {Done: Debian FTP Masters } 
[mariadb] MariaDB autopkgtest upstream test suite fails on disk / data 
corruption on ppc64el
There is no source info for the package 'mariadb' at version '1:10.11.1-1' with 
architecture ''
Unable to make a source version for version '1:10.11.1-1'
Marked as found in versions 1:10.11.1-1.
> reopen 1031656
Bug #1031656 {Done: Debian FTP Masters } 
[mariadb] MariaDB autopkgtest upstream test suite fails on disk / data 
corruption on ppc64el
Bug reopened
Ignoring request to alter fixed versions of bug #1031656 to the same values 
previously set
> tags 984056 + experimental
Bug #984056 {Done: David da Silva Polverari } 
[src:ifhp] ifhp: ftbfs with GCC-11
Added tag(s) experimental.
> tags 1033428 + experimental
Bug #1033428 [src:tycho] tycho: FTBFS in testing: make[1]: *** [debian/rules:9: 
override_dh_auto_build] Error 25
Added tag(s) experimental.
> retitle 1033428 tycho: FTBFS: incompatible types: 
> org.osgi.framework.BundleContext cannot be converted to 
> javax.xml.parsers.SAXParserFactory
Bug #1033428 [src:tycho] tycho: FTBFS in testing: make[1]: *** [debian/rules:9: 
override_dh_auto_build] Error 25
Changed Bug title to 'tycho: FTBFS: incompatible types: 
org.osgi.framework.BundleContext cannot be converted to 
javax.xml.parsers.SAXParserFactory' from 'tycho: FTBFS in testing: make[1]: *** 
[debian/rules:9: override_dh_auto_build] Error 25'.
> found 1033865 0.0~git20170207.0.428b7c6-6
Bug #1033865 [src:golang-github-go-macaron-csrf] Don't release with bookworm
Marked as found in versions 
golang-github-go-macaron-csrf/0.0~git20170207.0.428b7c6-6.
> retitle 1030905 sardana: FTBFS with python3.11 (cannot import name 
> 'getargspec' from 'sphinx.util.inspect')
Bug #1030905 [src:sardana] sardana: FTBFS (cannot import name 'getargspec' from 
'sphinx.util.inspect')
Changed Bug title to 'sardana: FTBFS with python3.11 (cannot import name 
'getargspec' from 'sphinx.util.inspect')' from 'sardana: FTBFS (cannot import 
name 'getargspec' from 'sphinx.util.inspect')'.
> tags 1030905 + sid bookworm
Bug #1030905 [src:sardana] sardana: FTBFS with python3.11 (cannot import name 
'getargspec' from 'sphinx.util.inspect')
Added tag(s) bookworm and sid.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1006718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006718
1030905: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030905
1031656: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031656
1033428: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033428
1033865: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033865
981941: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981941
984056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984056
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1033761: nautilus-scripts-manager: nautilus-script-manager throws exception under bookworm

2023-04-06 Thread Andreas Beckmann
Followup-For: Bug #1033761

Actually, the problem starts even earlier:

# nautilus-scripts-manager
Traceback (most recent call last):
  File "/usr/bin/nautilus-scripts-manager", line 21, in 
from gi.repository import Pango, Gtk, GLib
  File "/usr/lib/python3/dist-packages/gi/importer.py", line 131, in load_module
raise ImportError('cannot import name %s, '
ImportError: cannot import name Pango, introspection typelib not found

nautilus-scripts-manager has insufficient dependencies, for bullseye
(and buster and stretch) this can be solved by a dependency on
gir1.2-gtk-3.0 (maybe with alternatives), for bookworm one could also
depend on gir1.2-gtk-4.0 as
alternative.


Andreas