Bug#1021295: nmu: libtrexio_2.2.3-2 parmed_3.4.3+dfsg-1 xtb_6.5.1-1

[Andrius Merkys]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hello,

I want to request binNMU on amd64 for recently accepted new packages.

  nmu libtrexio_2.2.3-2 . amd64 . unstable . -m "Rebuild on buildd"
  nmu parmed_3.4.3+dfsg-1 . amd64 . unstable . -m "Rebuild on buildd"
  nmu xtb_6.5.1-1 . amd64 . unstable . -m "Rebuild on buildd"

Thanks,
Andrius

Bug#1021294: ITP: ocaml-uunf -- Unicode text normalization form library

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: debian-de...@lists.debian.org, jpu...@debian.org, 
debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-uunf
  Version : 15.0.0
  Upstream Author : Daniel Bünzli 
* URL : https://erratique.ch/software/uunf/
* License : ISC
  Programming Lang: OCaml
  Description : Unicode text normalization form library
 Library to normalize Unicode text, supporting all forms. It is
 independent of IO mechanism or Unicode text data structure,
 and can process text without a complete in-memory representation.

It is a dep of a new dep for ocaml-cohttp. I plan to maintain it within the
Debian OCaml Maintainers team.

Cheers,

J.Puydt

Bug#1021293: ITP: ocaml-uucd -- decode data on Unicode characters off XML

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: debian-de...@lists.debian.org, jpu...@debian.org, 
debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-uucd
  Version : 15.0.0
  Upstream Author : Daniel Bünzli 
* URL : https://erratique.ch/software/uucd
* License : ISC
  Programming Lang: OCaml
  Description : decode data on Unicode characters off XML
 This OCaml module decodes data from the Unicode character database
 from their XML representation, to provide high-level access so
 that efficient representations can be extracted.

It's a dep for a new dep for ocaml-cohttp ; I plan to maintain it within the
Debian OCaml Maintainers team.

Cheers,

J.Puydt

Bug#1021259: closed by Debian FTP Masters (reply to Santiago Ruano Rincón ) (Bug#1021259: fixed in ifupdown 0.8.39)

[Sven Joachim]

On 2022-10-04 15:39 +, Debian Bug Tracking System wrote:

>  ifupdown (0.8.39) unstable; urgency=low
>  .
>* Add execution permission on resolved scripts. Thanks to Vincent Lefèvre
>  (Closes: #1021259)

You should also add the executable bits in ifupdown's postinst script
when upgrading from 0.8.3[89], because dpkg leaves permissions of
conffiles alone.  See #192981.

Cheers,
   Sven

Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system

[Aurelien Jarno]

Hi,

On 2022-10-04 08:51, Aurelien Jarno wrote:
> Hi
> 
> On 2022-09-25 13:43, Aurelien Jarno wrote:
> > > Running a quick diff against old procinfo reveals that "flags" has the
> > > following new entries now:
> > > 
> > > tsc_deadline_timer ssbd ibrs ibpb stibp bmi1 bmi2 md_clear flush_l1d
> > > 
> > > > it looks like that the BMI2
> > > > instructions support has been added in a microcode update
> > > 
> > > As such it does appear that indeed this is the case.
> > 
> > Thanks for the confirmation, it seems that the microcode update is also
> > useful for security reasons in order to mitigate the speculative
> > execution side channel issues (the famous spectre/meltdown).
> > 
> > Neverthless the AVX2 code should not use BMI2 instructions if they are
> > not available.
> 
> This has been fixed upstream and in the sid package. Next step is to get
> it fixed for stable.

Please find a test version here for people who have the possibility to
try:

https://people.debian.org/~aurel32/glibc/

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#1021288: josm-installer: FTBFS with flake8 errors

[Sebastiaan Couwenberg]

Control: tags -1 pending

Thanks for reporting this issue.

On 10/5/22 02:12, Andreas Beckmann wrote:

./josm-installer.py:38:7: E275 missing whitespace after keyword
./josm-installer.py:130:7: E275 missing whitespace after keyword


This is fixed in git and a new upload will follow shortly.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1021292: dpkg-dev: Please add support for pointer authentication on arm64

[Wookey]

Package: dpkg-dev
Version: 1.19.7
Severity: wishlist
Tags: patch

As discussed in the below-linked thread on dpkg-dev, we should enable PAC and 
BTI
on arm64 as a standard hardening flag.
https://lists.debian.org/debian-dpkg/2022/05/msg00022.html

Attached is Guillem's proposed patch which does the trick, updated for
current dpkg (I opened this bug file in June, but forgot to actually
press send, so now updated for the current 1.21.9)

Despite this delay, I hope we can can have this in for bookworm.

-- 
Wookey
diff -Nru dpkg-1.21.9/debian/changelog dpkg-1.21.9+1/debian/changelog
--- dpkg-1.21.9/debian/changelog2022-07-01 09:25:58.0 +
+++ dpkg-1.21.9+1/debian/changelog  2022-10-04 15:28:43.0 +
@@ -1,3 +1,9 @@
+dpkg (1.21.9+1) unstable; urgency=medium
+
+  * Add 'branch' hardening support for amd64 and arm64
+
+ -- Wookey   Tue, 04 Oct 2022 16:28:43 +0100
+
 dpkg (1.21.9) unstable; urgency=medium
 
   [ Guillem Jover ]
diff -Nru dpkg-1.21.9/scripts/Dpkg/Vendor/Debian.pm 
dpkg-1.21.9+1/scripts/Dpkg/Vendor/Debian.pm
--- dpkg-1.21.9/scripts/Dpkg/Vendor/Debian.pm   2022-06-30 23:46:56.0 
+
+++ dpkg-1.21.9+1/scripts/Dpkg/Vendor/Debian.pm 2022-10-04 15:13:28.0 
+
@@ -129,6 +129,7 @@
 format => 1,
 relro => 1,
 bindnow => 0,
+branch => 1,
 },
 );
 
@@ -364,6 +365,11 @@
# relro not implemented on ia64, hppa, avr32.
$use_feature{hardening}{relro} = 0;
 }
+if ($cpu !~ /^(?:amd64|arm64)$/) { 
   
+# On amd64 use -fcf-protection.
   
+# On arm64 use -mbranch-protection=standard.   
   
+$use_feature{hardening}{branch} = 0;   
   
+} 
 
 # Mask features that might be influenced by other flags.
 if ($opts_build->has('noopt')) {
@@ -430,6 +436,17 @@
$flags->append('LDFLAGS', '-Wl,-z,now');
 }
 
+# Branch protection
   
+if ($use_feature{hardening}{branch}) { 
   
+my $flag;  
   
+if ($cpu eq 'arm64') { 
   
+$flag = '-mbranch-protection=standard';
   
+} elsif ($cpu eq 'amd64') {
   
+$flag = '-fcf-protection'; 
   
+}  
   
+$flags->append($_, $flag) foreach @compile_flags;  
   
+}  
   
+
 ## Commit
 
 # Set used features to their builtin setting if unset.
diff -Nru dpkg-1.21.9/scripts/t/Dpkg_BuildFlags.t 
dpkg-1.21.9+1/scripts/t/Dpkg_BuildFlags.t
--- dpkg-1.21.9/scripts/t/Dpkg_BuildFlags.t 2022-06-18 17:57:44.0 
+
+++ dpkg-1.21.9+1/scripts/t/Dpkg_BuildFlags.t   2022-10-04 15:28:06.0 
+
@@ -55,6 +55,7 @@
 ) ],
 hardening => [ qw(
 bindnow
+branch
 format
 fortify
 pie

Bug#983675: wev: Emits "invalid version" error at startup and consumes 100% CPU

[Dominique MARTINET]

I'd also like to use wev under weston.

For this particular error (invalid version for global xdg_wm_base (18):
have 1, wanted 2), we don't actually need xdg_wm_base version two in wev
(the only API we use here is xdg_wm_base_get_xdg_surface()) and the API
is backwards compatible, so just downgrading the requested version from
2 to 1 as follow fixes wev for me:


>From bdbad4e1e58d090654e2f5e804659bb8709f2f45 Mon Sep 17 00:00:00 2001
From: Dominique Martinet 
Date: Wed, 5 Oct 2022 11:19:27 +0900
Subject: [PATCH] protocols: lower xdg_wm_base requirement to 1

We do not need anything in API v2, and using the older v1 API makes wev
work on weston <= 9

diff --git a/wev.c b/wev.c
index 9d25491ba4b5..b0e7005b166b 100644
--- a/wev.c
+++ b/wev.c
@@ -811,7 +811,7 @@ static void registry_global(void *data, struct wl_registry 
*wl_registry,
{ _compositor_interface, 4, (void **)>compositor },
{ _seat_interface, 6, (void **)>seat },
{ _shm_interface, 1, (void **)>shm },
-   { _wm_base_interface, 2, (void **)>wm_base },
+   { _wm_base_interface, 1, (void **)>wm_base },
{ _data_device_manager_interface, 3,
(void **)>data_device_manager },
};


Note upgrading weston to version 10 or above would also fix the issue.

I'm not bothering to send this patch upstream as it would likely be
rejected (on the grounds of upstream weston already been upgraded), but
it would be great if we could add this patch to the debian stable
package.
(it's not needed for testing onwards, but it won't cause any harm there
either as far as I understand)


Thank you,
-- 
Dominique

Bug#1021291: sord: broken Homepage link

[Paul Wise]

Source: sord
Version: 0.16.14-2
Severity: minor
User: debian...@lists.debian.org
Usertags: duck

I noticed that the upstream website is missing and
the new location is available at this address:

   https://drobilla.net/software/sord.html

   $ apt-cache showsrc sord | grep Homepage
   Homepage: https://drobilla.net/software/sord/
   
   $ chronic apt source sord
   
   $ cd sord-0.16.14/
   
   $ duck 2>&1 | grep -A1 ^E:  
   E: debian/control: Homepage: https://drobilla.net/software/sord/: ERROR 
(Certainty:certain)
  Curl:0 HTTP:404 No error 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1021290: apt-listbugs: pinning explanation: add requester and apt command-line

[Paul Wise]

Package: apt-listbugs
Version: 0.1.36
Severity: wishlist

The explanation for apt pinning currently looks like the one below.

   Explanation: Pinned by apt-listbugs at 2022-10-05 09:10:39 +0800
   Explanation:   #1021062: bash: non existent locale crashes bash
   Package: libreadline8
   Pin: version 8.2~rc2-2
   Pin-Priority: 3

It would be useful to sysadmins if the apt Commandline/Requested-By
fields from the apt history.log were present too, something like this:

   Explanation: Pinned by apt-listbugs at 2022-10-05 09:10:39 +0800
   Explanation: Pinning requested by pabs (1000) during command: apt upgrade
   Explanation:   #1021062: bash: non existent locale crashes bash
   Package: libreadline8
   Pin: version 8.2~rc2-2
   Pin-Priority: 3

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii  apt 2.5.3
ii  ruby1:3.0+3.1
ii  ruby-debian 0.3.10+b7
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-5
ii  ruby-unicode0.4.4.4-1+b4
ii  ruby-xmlparser  0.7.3-4+b3

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3+git20211122.4658227-1

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser] 106.0.5249.91-1
ii  dillo [www-browser]3.0.5-7+b1
ii  elinks [www-browser]   0.13.2-1+b3
ii  firefox [www-browser]  105.0.1-1
ii  firefox-esr [www-browser]  102.3.0esr-1
ii  links [www-browser]2.27-1+b1
ii  lynx [www-browser] 2.9.0dev.10-1+b1
ii  netsurf-gtk [www-browser]  3.10-1+b3
ii  reportbug  11.5.1
ii  sensible-utils 0.0.17
ii  w3m [www-browser]  0.5.3+git20220429-1+b1
ii  xdg-utils  1.1.3-4.1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#999923: Porting XML Copy Editor to PCRE2

[Miriam Ruiz]

Cool!!

Lots of thanks!!

Miry

El mar, 4 oct 2022 a las 13:54, Zane Ji () escribió:
>
> Hi Miry,
>
> After your patch is applied, I just set matchArray to
> pcre2_get_ovector_pointer(patternMatchData) each time when pcre2_match is
> called, then regex searching/replacing works.
>
> The source code has been updated:
> https://sourceforge.net/p/xml-copy-editor/code/ci/3d17bca4196670183ad45c0af369acf4acdc7d7e/
>
> Regards,
> Zane

Bug#1021289: apt-listbugs: behaviour under unattended-upgrades is suboptimal; do pinning in `apt update` step?

[Paul Wise]

Package: apt-listbugs
Version: 0.1.36
Severity: normal

The behaviour of apt-listbugs under unattended-upgrades is suboptimal:

 * It causes the apt run to abort before it can start.
    - With minimal steps mode some packages may be upgraded, but once a
  bug is found, no subsequent package upgrade steps can be run.
 * The messages say that pinning is being added but they are not added.

Since unattended-upgrades are not interactive the user can never
interact with apt-listbugs to add pinning and cannot restart the apt
session, which is currently required for the pinning to take effect.

For this reason I suggest that when in non-interactive mode, a hook for
APT::Update::Post-Invoke (run by `apt update`) is added that will
invoke apt-listbugs and add pinning for any packages that need pinning
added and removing any that no longer apply. At this point apt-listbugs
should not do any prompting or errors, since it is not running in the
interactive mode. Then when `apt upgrade` is run the apt-listbugs hook
will see pinning, not abort the upgrade and the upgrade will complete,
minus the packages that could not be upgraded due to bugs.

Please set the Explanation field to say that the package pin was added
automatically, so that sysadmins reading it understand that the pin was
added by apt-listbugs rather than being set by a sysadmin.

-- System Information:
Debian Release: bookworm/sid
 APT prefers testing-debug
 APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), 
(800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 
'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii apt 2.5.3
ii ruby 1:3.0+3.1
ii ruby-debian 0.3.10+b7
ii ruby-gettext 3.3.3-2
ii ruby-soap4r 2.0.5-5
ii ruby-unicode 0.4.4.4-1+b4
ii ruby-xmlparser 0.7.3-4+b3

Versions of packages apt-listbugs recommends:
ii ruby-httpclient 2.8.3+git20211122.4658227-1

Versions of packages apt-listbugs suggests:
ii chromium [www-browser] 106.0.5249.91-1
ii dillo [www-browser] 3.0.5-7+b1
ii elinks [www-browser] 0.13.2-1+b3
ii firefox [www-browser] 105.0.1-1
ii firefox-esr [www-browser] 102.3.0esr-1
ii links [www-browser] 2.27-1+b1
ii lynx [www-browser] 2.9.0dev.10-1+b1
ii netsurf-gtk [www-browser] 3.10-1+b3
ii reportbug 11.5.1
ii sensible-utils 0.0.17
ii w3m [www-browser] 0.5.3+git20220429-1+b1
ii xdg-utils 1.1.3-4.1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#673004: does not connect to HP iLO 2

[Matt Taggart]

tags 673004 wontfix
close 673004
thanks

This bug is from 2012. I'm not sure what the problem was at the time, 
but by now any such old HP iLO device identifying as version 
"mpSSH_0.1.0" is unlikely to support a set of ciphers/Kex/MACs/etc to 
allow a recent version of openssh in debian to be able to connect to it, 
even with work-arounds. The world has moved on.


If you are on a current version of debian and encounter problems 
connecting to such a device, first ensure that your devices firmware is 
the latest version and then open a new bug with detailed debugging info 
(and know that the answer still might be "sorry, the manufacturer 
stopped updating it and we can't support connecting to it").


Good luck,

--
Matt Taggart
m...@lackof.org

Bug#903999: ITP: php-doc -- Documentation for PHP

[Paul Wise]

On Tue, 2022-10-04 at 09:20 -0300, Athos Ribeiro wrote:

> While I am working on packaging details, I still want to make sure it is
> OK to re-introduce the package due to the PHP-3.0 issues I pointed
> before.

OK. To be clear, I have no interest in PHP or php-doc, I mainly wanted
to make you aware of the steps for reintroduction of old packages.

> Finally, I did go through the bugs closed with +rm, and am commenting on
> each of them here to ensure we have notes for when we un-archive them.

Thanks for working on this.

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821695
>    This one is regarding the PHP 7 transition. It was the reason the
>    package was removed and it is fixed in the new proposed package.

You'll need to unarchive/reopen this and then either close it in the
debian/changelog of your package or close the bug with the new version:

https://www.debian.org/Bugs/Developer#closing

Since you probably don't want to notify the submitter of the closing,
probably you should use the close command with the new version number:

https://www.debian.org/Bugs/server-control#close

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737713
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766882
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734145
>    These are all regarding broken links and missing files. They are fixed
>    in the new proposed package and I also added an autopkgtest to ensure
>    there will be no regressions here.

Great! Same advice as above, although maybe versioned -done instead.

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766816
>    This is a request to add additional links for aliases.  It is still
>    valid and should be dealt with upstream.

This you could unarchive/reopen, file upstream and mark as forwarded:

https://www.debian.org/Bugs/server-control#forwarded

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606081
>    This is a request to improve an specific function behavior
>    documentation. I will probably forward this upstream to be handled
>    there.

Same as above.

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288744
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348512
>    These are requests to package different language translations.
>    Unfortunatelly, most PHP translations are far from complete and I am
>    not sure they'd be ready for packaging, with exception of one
>    language. I could package that one __if__ there is interest for that
>    in the long run. Otherwise, we should keep these open until the docs
>    get more translated contents.

These you could unarchive/reopen and state your position on the bugs.

Since both of them request Spanish, German and French, maybe the
translations for those are complete enough to be packaged,
if so then you could close the bugs when packaging them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1021243: xterm: different font size after upgrading from 372-1 to 373-1

[Thomas Dickey]

On Tue, Oct 04, 2022 at 11:36:50AM +0200, Emanuele Rocca wrote:
> Package: xterm
> Version: 373-1
> Severity: important
> 
> Hi,
> 
> the upgrade from xterm 372-1 to 373-1 changes font size on my system.
> 
> See what the fonts used to look like with 372-1 vs 373-1 in the attached
> screenshots.

thanks (I had a similar report yesterday, and am investigating)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#1021288: josm-installer: FTBFS with flake8 errors

[Andreas Beckmann]

Source: josm-installer
Version: 0.0.1+svn18515
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

josm-installer recently started to FTBFS.
A previous rebuild on August 4 still succeeded.

 debian/rules build
dh build
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/josm-installer-0.0.1+svn18515'
# Create man page from DocBook XML
for x in /build/josm-installer-0.0.1+svn18515/josm-installer.1.xml ; do \
docbook2x-man --string-param header-3="02 August 2022" $x ; \
done
error : xmlAddEntity: invalid redeclaration of predefined entity
make[1]: Leaving directory '/build/josm-installer-0.0.1+svn18515'
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/josm-installer-0.0.1+svn18515'
python3 -m flake8
./josm-installer.py:38:7: E275 missing whitespace after keyword
./josm-installer.py:130:7: E275 missing whitespace after keyword
make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/josm-installer-0.0.1+svn18515'
make: *** [debian/rules:10: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


Andreas


josm-installer_0.0.1+svn18515.log.gz
Description: application/gzip

Bug#774711: openssh-server: insecure algorithms reported by ssh-audit

[Matt Taggart]

Thanks for the ssh-audit report output!
There has been a very long discussion of default settings in #774711 
(which now includes ssh-audit's recommendations)


Since you generated this report the following has happened:

* 1:8.8p1-1:
  "This release disables RSA signatures using the SHA-1 hash algorithm
   by default.  (Existing RSA keys may still be used and do not need
   to be replaced; see NEWS.Debian if you have problems connecting to
   old SSH servers.)"
* 1:8.9p1-1:
  "ssh(1): stricter UpdateHostkey signature verification logic on the
   client-side. Require RSA/SHA2 signatures for RSA hostkeys except when
   RSA/SHA1 was explicitly negotiated during initial KEX.
   ssh(1), sshd(8): fix signature algorithm selection logic for
   UpdateHostkeys on the server side. The previous code tried to prefer
   RSA/SHA2 for hostkey proofs of RSA keys, but missed some cases. This
   will use RSA/SHA2 signatures for RSA keys if the client proposed
   these algorithms in initial KEX."
* 1:9.0p1-1:
  "use the hybrid Streamlined NTRU Prime + x25519 key exchange method
   by default ("sntrup761x25519-sha...@openssh.com"). The NTRU algorithm
   is believed to resist attacks enabled by future quantum computers and
   is paired with the X25519 ECDH key exchange (the previous default) as
   a backstop against any weaknesses in NTRU Prime that may be
   discovered in the future. The combination ensures that the hybrid
   exchange offers at least as good security as the status quo."
* sk-ssh-ed25...@openssh.com is the defaults lists now

The rest of ssh-audit's recommendations from your report are still 
valid, see #774711 for more info


--
Matt Taggart
m...@lackof.org

Bug#1021287: mk-origtargz: empty directories left when using Files-Included

[Olek Wojnar]

If it helps, the empty directory tag from lintian is: 
https://lintian.debian.org/tags/package-contains-empty-directory


I'm not sure how many, if any, of the packages currently triggering the 
tag are related to this bug in mk-origtargz.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006962: nvidia-cuda-toolkit: nvcc chokes on g++ 11.2's bits/std_function.h

[Andreas Beckmann]

Followup-For: Bug #1006962
Control: fixed -1 11.6.1-1

This seems to be resolved in 11.6.1, except for some new problems in the
 header, but I'll ignore that (unless it also shows up in
some rdepends).

/usr/include/c++/11/coroutine:294:23: error: default member initializer for 
'std::__n4861::coroutine_handle::__frame::__r'
 required before the end of its enclosing class
  294 |   static __frame _S_fr;
  |   ^
/usr/include/c++/11/coroutine:289:26: note: defined here
  289 | void (*__r)() = __dummy_resume_destroy;
  |  ^~   
/usr/include/c++/11/coroutine:294:23: error: default member initializer for 
'std::__n4861::coroutine_handle::__frame::__d'
 required before the end of its enclosing class
  294 |   static __frame _S_fr;
  |   ^
/usr/include/c++/11/coroutine:290:26: note: defined here
  290 | void (*__d)() = __dummy_resume_destroy;
  |  ^~   
/usr/include/c++/11/coroutine:304:60: error: redefinition of 
'std::__n4861::coroutine_handle::__frame 
std::__n4861::coroutine_handle::_S_fr'
  304 |   noop_coroutine_handle::_S_fr{};
  |^

/usr/include/c++/11/coroutine:294:23: note: 
'std::__n4861::coroutine_handle::__frame 
std::__n4861::coroutine_handle::_S_fr' 
previously declared here
  294 |   static __frame _S_fr;
  |   ^


Andreas

Bug#1021287: mk-origtargz: empty directories left when using Files-Included

[Olek Wojnar]

Package: devscripts
Version: 2.22.2
Severity: normal

Dear Maintainer,

While using the Files-Included functionality for the first time, I noticed
that linitian was giving me errors about empty directories in my package.
Upon investigation, I realized that the Files-Included process was only
removing the *files* in Files-Excluded directories that had a nested
Files-Included stanza, but leaving the empty sub-directories in place.

For example, assume a d/copyright with:
Files-Excluded: removesome
Files-Included: removesome/keepme

and the following directory structure:
removesome/
removesome/file1
removesome/subdir/
removesome/subdir/file2
removesome/keepme/
removesome/keepme/file3

Currently, the following will be kept:
removesome/
removesome/subdir/
removesome/keepme/
removesome/keepme/file3

However, I believe that the expected behavior of the tool should result in
only the following kept:
removesome/
removesome/keepme/
removesome/keepme/file3

Looking into the relevant source code, I noticed that testGoVendorIncludeIgnore
was *expecting* the empty directory to be left behind. I believe this is an
error in the test. I suggested a fix [1] but, unfortunately, I don't know Perl
well enough to submit a fix to the root issue.

That being said, I'm happy to help in any other way. Thanks in advance for
looking into this issue!

-Olek

[1] https://salsa.debian.org/debian/devscripts/-/merge_requests/285

Bug#1021286: prody downloads from the internet during the build

[Adrian Bunk]

Source: prody
Version: 2.2.0+dfsg-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=prody=i386=2.2.0%2Bdfsg-1=1664908079=0

...
==
ERROR: testCompressed (prody.tests.proteins.test_wwpdb.TestFTP)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.10_prody/build/prody/proteins/wwpdb.py", 
line 178, in fetchPDBviaFTP
ftp = FTP(ftp_host)
  File "/usr/lib/python3.10/ftplib.py", line 121, in __init__
self.connect(host)
  File "/usr/lib/python3.10/ftplib.py", line 158, in connect
self.sock = socket.create_connection((self.host, self.port), self.timeout,
  File "/usr/lib/python3.10/socket.py", line 845, in create_connection
raise err
  File "/usr/lib/python3.10/socket.py", line 833, in create_connection
sock.connect(sa)
OSError: [Errno 101] Network is unreachable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.10_prody/build/prody/tests/proteins/test_wwpdb.py",
 line 33, in testCompressed
self.fns = self.fetch(*self.pdb, folder=TEMPDIR)
  File 
"/<>/.pybuild/cpython3_3.10_prody/build/prody/proteins/wwpdb.py", 
line 180, in fetchPDBviaFTP
raise type(error)('FTP connection problem, potential reason: '
OSError: FTP connection problem, potential reason: no internet connectivity

==
ERROR: testDecompressed (prody.tests.proteins.test_wwpdb.TestFTP)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.10_prody/build/prody/proteins/wwpdb.py", 
line 178, in fetchPDBviaFTP
ftp = FTP(ftp_host)
  File "/usr/lib/python3.10/ftplib.py", line 121, in __init__
self.connect(host)
  File "/usr/lib/python3.10/ftplib.py", line 158, in connect
self.sock = socket.create_connection((self.host, self.port), self.timeout,
  File "/usr/lib/python3.10/socket.py", line 845, in create_connection
raise err
  File "/usr/lib/python3.10/socket.py", line 833, in create_connection
sock.connect(sa)
OSError: [Errno 101] Network is unreachable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.10_prody/build/prody/tests/proteins/test_wwpdb.py",
 line 49, in testDecompressed
self.fns = self.fetch(*self.pdb, folder=TEMPDIR, compressed=False)
  File 
"/<>/.pybuild/cpython3_3.10_prody/build/prody/proteins/wwpdb.py", 
line 180, in fetchPDBviaFTP
raise type(error)('FTP connection problem, potential reason: '
OSError: FTP connection problem, potential reason: no internet connectivity

--
Ran 937 tests in 36.733s

FAILED (errors=2, skipped=32)
E: pybuild pybuild:379: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.10_prody/build; python3.10 -m unittest 
discover -v 
dh_auto_test: error: pybuild --test -i python{version} -p 3.10 returned exit 
code 13
make: *** [debian/rules:6: binary-arch] Error 25

Bug#1021285: cmus 2.9.1 freezes when playing ape files

[Nelson G]

Package: cmus
Version: 2.9.1-1
Severity: wishlist

hello,

cmus 2.9.1 freezes when playing ape files,  but cmus 2.10.0 doesn't.  It would
be great to either backport the fix to 2.9.1 (or cmus 2.10.0 completely) to
debian 11.

have a nice day


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-18-amd64 (SMP w/8 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8),
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cmus depends on:
ii  libao4  1.2.2+20180113-1.1
ii  libasound2  1.2.4-1.1
ii  libc6   2.31-13+deb11u4
ii  libcddb21.3.2-6+b1
ii  libcdio-cdda2   10.2+2.0.0-1+b2
ii  libcdio19   2.1.0-2
ii  libdiscid0  0.6.2-3
ii  libfaad22.10.0-1
ii  libflac81.3.3-2+deb11u1
ii  libmad0 0.15.1b-10
ii  libmodplug1 1:0.8.9.0-3
ii  libmpcdec6  2:0.1~r495-2
ii  libncursesw66.2+20201114-2
ii  libopusfile00.9+20170913-1.1
ii  libsystemd0 247.3-7+deb11u1
ii  libtinfo6   6.2+20201114-2
ii  libvorbisfile3  1.3.7-1
ii  libwavpack1 5.4.0-1

Versions of packages cmus recommends:
ii  cmus-plugin-ffmpeg  2.9.1-1

Versions of packages cmus suggests:
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libpulse0 14.2-2
pn  libroar2  
ii  libsamplerate00.2.1+ds0-1

Bug#1007832: vulkaninfo,vkcube seg-faults on remote access.

[Alois Schlögl]

Control: reassign 1007832 mesa 20.3.5-1


Further testing shows that this bug is related to mesa 20.3.5-1 (on 
bullseye). Therefore, this bug should be assigned to the mesa package.


The issue goes away when a more recent version of mesa is compiled from 
source and the resulting libGL.so is preloaded on the remote machine.
Then, vulkan-tools, vulkaninfo will not crash. This suggests the problem 
is caused by libgl1 from mesa 20.3.5-1.

Most likely, libGL.so from libgl1 package is the culprit.

The test was successful test, when using using
   mesa/22.1.5 (and later versions including 22.2.0)
   libdrm/2.4.112 and llvm/13.0.1
and configuring mesa with the following options
    -Degl=disabled \
    -Dgles1=enabled \
    -Dgles2=enabled \
    -Dshared-glapi=enabled \
    -Dglx=xlib \
    -Dgallium-drivers=swrast \
    -Dvulkan-drivers=intel,swrast \
    -Dplatforms=x11 \
    -Ddri3=enabled \
    -Ddri-drivers="" \
    -Dswr-arches=avx,avx2,skx \
    -Dcpp_rtti=false \

The test is also successful when compiling mesa/22.2.0 with the 
following configuration

    -Dcpp_rtti=false \
    -Ddri3=enabled \
    -Ddri-drivers="" \
    -Degl=disabled \
    -Dgallium-drivers=swrast,virgl,svga,d3d12,zink,iris,crocus,i915 \
    -Dgallium-xa=enabled \
    -Dgles1=enabled \
    -Dgles2=enabled \
    -Dglx=xlib \
    -Dosmesa=true \
    -Dplatforms=x11 \
    -Dshared-glapi=enabled \
-Dvulkan-drivers=intel,swrast,virtio-experimental,imagination-experimental \

Maybe this helps to bisect the issue.

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Sean Whitton]

Hello,

On Sun 02 Oct 2022 at 09:03PM +02, Niels Thykier wrote:

> Here is my view in short: As I see it, only the values `no` and
> `binary-targets` for `Rules-Requires-Root` makes sense for the *policy defined
> targets*[1] at the moment.  Accordingly, Debian policy can probably reduce the
> field to only cover `binary-targets` and `no` (and describe the remaining
> values as "[they] will mostly behave like `no`, but read more in the dpkg
> documentation for concrete the non-policy relevant use-case")
>
> In theory, you could use `Rules-Requires-Root` to cover the static ownership
> cases (where you need to chown files and store that ownership in the deb).
> However, that would require people to consistently use fakeroot with -l + -s
> (which, to my knowledge, no one does) - failure to do so would just silently
> loose the ownership and the files would end up with the wrong owner.
>
> On a related note, both Guillem and I agreed a while back that ownership
> (among other) should ideally be specifiably without using chown.  While a
> concrete method has not yet materialized, I am not working on supporting
> static ownership via chown in debhelper (nor do I plan to do so), so in
> practice `binary-targets` is the only reliable way to setup static ownership
> for any package built via debhelper[2].
>
> So in summary, with the current tooling, only `no` and `binary-targets` make
> sense for *policy defined targets* and I am not aware of anything that would
> change that.

Many thanks for the input.

Could you just confirm that there isn't any info in Policy which isn't
also in dpkg documentation?

If so, then if someone particularly wants to see this gone from the
manual they can prepare a patch for seconding.

> PS: As for the adding a recommendation to use `Rules-Requires-Root: no` where
> possible. I would second such as change. Over half of all Debian source
> packages in testing have the value, and adoption has been quite fast despite
> very little push from Guillem and I on it.  For me, the recommendation would
> be documenting public sentiment on this topic.
>
> Source: https://trends.debian.net/rulesreqroot_testing-percent.png

Cool.  I think that would be fine too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1021284: unifrac-tools seems to be an unintentional hijack of src:unifrac

[Adrian Bunk]

Source: unifrac-tools
Version: 1.1.1-1
Severity: serious

unifrac-tools seems to be an unintentional hijack of src:unifrac,
which is also maintained by Debian Med and RFA (#996921).

Package name differences:
- libssu-tools -> unifrac-tools
- python3-unifrac -> none

Bug#774711: update of debian openssh crypto defaults

[Matt Taggart]

It has been a while since I reviewed the state of #774711 compared to 
upstream. First here are the relevant changelog entries since I last did.


7.5
ssh(1), sshd(8): Support "=-" syntax to easily remove methods from
  algorithm lists, e.g. Ciphers=-*cbc.

7.6
ssh(1): Delete SSH protocol version 1 support, associated
  configuration options and documentation (LP: #1584321).
ssh(1)/sshd(8): Remove support for the hmac-ripemd160 MAC.
ssh(1)/sshd(8): Remove support for the arcfour, blowfish and CAST
  ciphers.
Refuse RSA keys <1024 bits in length and improve reporting for keys 
  that do not meet this requirement.

ssh(1): Do not offer CBC ciphers by default.

7.8
ssh(1)/sshd(8): Add new signature algorithms "rsa-sha2-256-cert-
  v...@openssh.com" and "rsa-sha2-512-cert-...@openssh.com" to 
explicitly

  force use of RSA/SHA2 signatures in authentication.

8.0
ssh-keygen(1): Increase the default RSA key size to 3072 bits,
  following NIST Special Publication 800-57's guidance for a 128-bit
  equivalent symmetric security level (LP: #1445625).

8.1
ssh(1), sshd(8): Allow prepending a list of algorithms to the default
  set by starting the list with the '^' character, e.g.
  "HostKeyAlgorithms ^ssh-ed25519".

8.2
ssh(1), sshd(8), ssh-keygen(1): this release removes the "ssh-rsa"
  (RSA/SHA1) algorithm from those accepted for certificate signatures
  (i.e. the client and server CASignatureAlgorithms option) and 
will use
  the rsa-sha2-512 signature algorithm by default when the 
ssh-keygen(1)

  CA signs new certificates.
ssh(1), sshd(8): Remove diffie-hellman-group14-sha1 from the default
  key exchange proposal for both the client and server.

8.5 


ssh(1), sshd(8): change the first-preference signature algorithm from
  ECDSA to ED25519.
ssh(1), sshd(8): remove the pre-standardization cipher
  rijndael-...@lysator.liu.se.

8.8
This release disables RSA signatures using the SHA-1 hash algorithm by
  default.  (Existing RSA keys may still be used and do not need to be
  replaced; see NEWS.Debian if you have problems connecting to old SSH
  servers.)

8.9
ssh(1), ssh(8): since DSA keys are deprecated, move them to the end of
  the default list of public keys so that they will be tried last.

From my last comparison on 20 Apr 2018, the following unsafe things are 
still supported in 9.0 and debian:


==
Keys:
* NIST curves (ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, 
ecdsa-sha2-nistp521)


Kex:
* NIST curves (ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521)
* diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1
(supported, but no longer in the default set))

MACs:
* umac-64
==

Those are the things remaining from the original "stribika" analysis. 
The new ssh-audit.com recommendations are similar and disable the following:


==
Ciphers:
* 3des-cbc
* aes128-cbc aes192-cbc aes256-cbc
* rijndael-...@lysator.liu.se

Kex:
* ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521
* diffie-hellman-group14-sha256
* diffie-hellman-group1-sha1 diffie-hellman-group14-sha1

MACs
* umac-64-...@openssh.com umac...@openssh.com
* hmac-sha1-...@openssh.com hmac-sha1
* umac-...@openssh.com  (prefers umac-128-...@openssh.com)
* hmac-sha2-256 (prefers hmac-sha2-256-...@openssh.com)
* hmac-sha2-512 (prefers hmac-sha2-512-...@openssh.com)


HostKeyAlgorithms:
* ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521
* ecdsa-sha2-nistp256-cert-...@openssh.com
  ecdsa-sha2-nistp384-cert-...@openssh.com
  ecdsa-sha2-nistp521-cert-...@openssh.com
* sk-ecdsa-sha2-nistp256-cert-...@openssh.com
  sk-ecdsa-sha2-nistp...@openssh.com
* ssh-rsa-cert-...@openssh.com ssh-rsa

==

This mostly matches the original "stribika" which it is based on, here 
are some observations:


* The Ciphers they recommend removing:
  3des rijndael-...@lysator.liu.se aes128-cbc aes192-cbc aes256-cbc
dropped off the radar here because are all disabled by default, but it 
is now well past the time to disable them completely in the server (and 
possibly the client)
* Similarly, Kex:diffie-hellman-group*-sha1 and MAC:umac-64 should be 
fully disabled in the server, and soon the client.
* HostKeyAlgorithms:ssh-rsa/ssh-rsa-cert-...@openssh.com are dropped in 
8.2. They should go away but I am unsure when.
* In some cases they prefer the longer "@openssh.com" version, and don't 
explicitly list the short name, I don't know why.
* Why are NIST curves still enabled? They've been proven harmful for 8+ 
years.



Using the new '=-','^','+','-','*' syntax, it is possible to specify 
configuration changes relative to the default, in a way that 
future-proofs the config for 

Bug#1021283: simgrid FTBFS on mipsel

[Adrian Bunk]

Source: simgrid
Version: 3.32-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=simgrid=mipsel=3.32-1=1664920617=0

...
-- Checking for modules 
'ns3-core>=3.28;ns3-csma;ns3-point-to-point;ns3-internet;ns3-network;ns3-applications;ns3-wifi'
--   No package 'ns3-core' found
--   No package 'ns3-csma' found
--   No package 'ns3-point-to-point' found
--   No package 'ns3-internet' found
--   No package 'ns3-network' found
--   No package 'ns3-applications' found
--   No package 'ns3-wifi' found
-- Looking for ns3/core-module.h - not found
-- Looking for lib ns3-core
-- Looking for lib ns3-core - not found
-- Warning: Please install ns-3 (version 3.22 or higher -- 
http://www.nsnam.org/releases/) or disable this feature.
CMake Error at CMakeLists.txt:237 (message):
  Cannot find ns-3.  Please install it (apt-get install ns3 libns3-dev) or
  disable that cmake option


-- Configuring incomplete, errors occurred!
...


ns3 is already building on mipsel again, please don't exclude
mipsel in the build dependencies.

Bug#1020244: fonts-urw-base35: A monospaced font shouldn't have ligatures

[James Cloos]

as a side note (i can't see the proposed patch, so ignore this if the
patch does this already), but do be sure not to remove the lig glyphs
from the fonts, but rather just any gsub (or the like) features which
replace char sequences with the ligs.

ie, anything which replaces f i with fi, etc, should go, but the fi glyph,
the mapping from U+FB01 to that glyph, and so on for the others, should
all remain.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#1021282: haskell-charset: FTBFS on hppa - profiling libraries for package hashable-1.3.5.0

[John David Anglin]

Source: haskell-charset
Version: 0.3.9-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

The build fails here:
[4 of 9] Compiling Data.CharSet.Posix.Ascii ( src/Data/CharSet/Posix/Ascii.hs, 
dist-ghc/build/Data/CharSet/Posix/Ascii.p_o )
Failed to load interface for ‘Data.Hashable.Generic.Instances’
Perhaps you haven't installed the profiling libraries for package 
‘hashable-1.3.5.0’?
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
-e: error: debian/hlibrary.setup build --builddir=dist-ghc returned exit code 1
 at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 852.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup build 
--builddir=dist-ghc returned exit"...) called at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 596
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup build 
--builddir=dist-ghc") called at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm 
line 470
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "build", 
"--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 650
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=haskell-charset=hppa=0.3.9-1%2Bb2=1664915625=0

For some reason, only libghc-hashable-dev is installed. The profile package
libghc-hashable-prof is not installed.

Some other haskell packages fail in a similar way on hppa.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.13+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#916605: RE torbrowser-launcher: I can't start torbrowser-launcher

[OmegaPhil]

Joey: Thanks for your post in 2019 - I had the same problem of the 
browser not starting up when requested through the application menu - 
investigating it seems to be a bad symbols problem:


==

/home/omega/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/start-tor-browser 
-v
./firefox.real: ./TorBrowser/Tor/libstdc++.so.6: version 
`GLIBCXX_3.4.21' not found (required by ./firefox.real)


==

Removing the local installation and having the launcher reinstall it worked:

==

rm -rf /home/omega/.local/share/torbrowser

==

Bug#1021280: RFP: gamescope -- Gaming utility for window upscaling and sharpening with AMD FSR 1.0, NVIDIA Image Scaling 1.0.2 or integer

[Krock]

Package: wnpp
Severity: wishlist

* Package name: gamescope
  Version : 3.11.47
  Upstream Author : Valve
* URL : https://github.com/Plagman/gamescope/
* License : BSD-2 Clause
  Programming Lang: C++
  Description : Gaming utility for window upscaling and sharpening with AMD 
FSR 1.0, NVIDIA Image Scaling 1.0.2 or integer

See project URL for a long description.

This utility application offers fast upscaling/downscaling of any window,
independent of the active graphics environment. Intel, AMD and NVIDIA GPUs
are supported. To my knowledge there is no comparable alternative.

Bug#1021275: hipcc cannot find ROCm device library and HIP runtime

[Étienne Mollier]

Control: tags -1 pending

Hi Witold,

Witold Baryluk, on 2022-10-04:
> Thanks for packaging ROCm components. But it still looks is a bit off being 
> fully usable out of the box.
[…]
> I managed to compile it using
> 
> hipcc --rocm-path=/ 
> --rocm-device-lib-path=/usr/lib/x86_64-linux-gnu/amdgcn/bitcode 
> MatrixTranspose.cpp
> 
> but it took some time to figure out, and is not nice putting these paths
> directly in makefiles, and such.

That's true, for the moment there are still several settings
that are not completely automatic.  Cordell Bloor has introduced
a patch series in ROCm 5.2.3-1~0exp0 which should land in debian
experimental soon to address these needs.

If you stick to ROCm 5.0.0 as packaged by Debian, then you have
also the option to use environment variables ROCM_PATH, and
DEVICE_LIB_PATH; note also HIP_CLANG_PATH which is used in
early versions of hipcc reverse dependencies, set to /usr/bin.

Thank you for your interest in ROCm!

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/0, please excuse my verbosity.
On air: Savatage - Prelude To Madness/Hall Of The Mountain King


signature.asc
Description: PGP signature

Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system

[Aurelien Jarno]

Hi,

On 2022-10-04 19:44, debian-bug-rep...@p0358.net wrote:
> > Is there an easy way to unbrick a system affected by the issue? such as
> > a kernel-line option or a configuration file in /etc? I don't see how I
> > can set a GLIBC_TUNABLES environment variable for the whole system.
> 
> I was trying during my testing to set such option globally somehow, but
> failed, though maybe some method for this exists. As it stands I only see
> two possibilities of unbricking a system, both assuming you can access the
> partition externally from some bootable system:
> 
> 1. Downgrade the affected libc6 package to a version before the one causing
> issues (either chroot and dpkg, or just extract and physically replace the
> files), after booting apt-mark hold libc6 to prevent faulty update from
> being installed until the issue is fixed
> 
> 2. Or install intel-microcode package, assuming the microcode update adds
> the missing instructions in particular case, basically coincidentally fixing
> this issue (the updated CPU microcode is loaded on every bootup)

Please note that the microcode update might also be done through a
BIOS/firmware update if available.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1021279: flask-security: CVE-2021-23385

[Moritz Mühlenhoff]

Source: flask-security
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for flask-security.

CVE-2021-23385[0]:
| This affects all versions of package Flask-Security. When using the
| get_post_logout_redirect and get_post_login_redirect functions, it is
| possible to bypass URL validation and redirect a user to an arbitrary
| URL by providing multiple back slashes such as \\\evil.com/path. This
| vulnerability is only exploitable if an alternative WSGI server other
| than Werkzeug is used, or the default behaviour of Werkzeug is
| modified using 'autocorrect_location_header=False. **Note:** Flask-
| Security is not maintained anymore.

https://security.snyk.io/vuln/SNYK-PYTHON-FLASKSECURITY-1293234

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-2021-23385
https://www.cve.org/CVERecord?id=CVE-2021-23385

Please adjust the affected versions in the BTS as needed.

Bug#1021278: pngcheck: CVE-2020-35511

[Moritz Mühlenhoff]

Source: pngcheck
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for pngcheck.

CVE-2020-35511[0]:
| A global buffer overflow was discovered in pngcheck function in
| pngcheck-2.4.0(5 patches applied) via a crafted png file.

Only reference here is SuSE bugzilla:
https://bugzilla.suse.com/show_bug.cgi?id=1202662#c2

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-2020-35511
https://www.cve.org/CVERecord?id=CVE-2020-35511

Please adjust the affected versions in the BTS as needed.

Bug#1021277: strongswan: CVE-2022-40617

[Moritz Mühlenhoff]

Source: strongswan
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for strongswan.

CVE-2022-40617[0]:
https://www.strongswan.org/blog/2022/10/03/strongswan-vulnerability-(cve-2022-40617).html

Patch: https://download.strongswan.org/security/CVE-2022-40617/

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-2022-40617
https://www.cve.org/CVERecord?id=CVE-2022-40617

Please adjust the affected versions in the BTS as needed.

Bug#1021276: snort: CVE-2020-3315 CVE-2021-1223 CVE-2021-1224 CVE-2021-1494 CVE-2021-1495 CVE-2021-34749 CVE-2021-40114

[Moritz Mühlenhoff]

Source: snort
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for snort.

These all lack details, but all boil down to the fact Snort needs
to be updated:

CVE-2020-3315[0]:
| Multiple Cisco products are affected by a vulnerability in the Snort
| detection engine that could allow an unauthenticated, remote attacker
| to bypass the configured file policies on an affected system. The
| vulnerability is due to errors in how the Snort detection engine
| handles specific HTTP responses. An attacker could exploit this
| vulnerability by sending crafted HTTP packets that would flow through
| an affected system. A successful exploit could allow the attacker to
| bypass the configured file policies and deliver a malicious payload to
| the protected network.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort_filepolbypass-m4X5DgOP

CVE-2021-1223[1]:
| Multiple Cisco products are affected by a vulnerability in the Snort
| detection engine that could allow an unauthenticated, remote attacker
| to bypass a configured file policy for HTTP. The vulnerability is due
| to incorrect handling of an HTTP range header. An attacker could
| exploit this vulnerability by sending crafted HTTP packets through an
| affected device. A successful exploit could allow the attacker to
| bypass configured file policy for HTTP packets and deliver a malicious
| payload.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort-filepolbypass-67DEwMe2

CVE-2021-1224[2]:
| Multiple Cisco products are affected by a vulnerability with TCP Fast
| Open (TFO) when used in conjunction with the Snort detection engine
| that could allow an unauthenticated, remote attacker to bypass a
| configured file policy for HTTP. The vulnerability is due to incorrect
| detection of the HTTP payload if it is contained at least partially
| within the TFO connection handshake. An attacker could exploit this
| vulnerability by sending crafted TFO packets with an HTTP payload
| through an affected device. A successful exploit could allow the
| attacker to bypass configured file policy for HTTP packets and deliver
| a malicious payload.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort-tfo-bypass-MmzZrtes

CVE-2021-1494[3]:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-http-fp-bp-KfDdcQhc

CVE-2021-1495[4]:
| Multiple Cisco products are affected by a vulnerability in the Snort
| detection engine that could allow an unauthenticated, remote attacker
| to bypass a configured file policy for HTTP. The vulnerability is due
| to incorrect handling of specific HTTP header parameters. An attacker
| could exploit this vulnerability by sending crafted HTTP packets
| through an affected device. A successful exploit could allow the
| attacker to bypass a configured file policy for HTTP packets and
| deliver a malicious payload.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-http-fp-bp-KfDdcQhc

CVE-2021-34749[5]:
| A vulnerability in Server Name Identification (SNI) request filtering
| of Cisco Web Security Appliance (WSA), Cisco Firepower Threat Defense
| (FTD), and the Snort detection engine could allow an unauthenticated,
| remote attacker to bypass filtering technology on an affected device
| and exfiltrate data from a compromised host. This vulnerability is due
| to inadequate filtering of the SSL handshake. An attacker could
| exploit this vulnerability by using data from the SSL client hello
| packet to communicate with an external server. A successful exploit
| could allow the attacker to execute a command-and-control attack on a
| compromised host and perform additional data exfiltration attacks.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sni-data-exfil-mFgzXqLN

CVE-2021-40114[6]:
| Multiple Cisco products are affected by a vulnerability in the way the
| Snort detection engine processes ICMP traffic that could allow an
| unauthenticated, remote attacker to cause a denial of service (DoS)
| condition on an affected device. The vulnerability is due to improper
| memory resource management while the Snort detection engine is
| processing ICMP packets. An attacker could exploit this vulnerability
| by sending a series of ICMP packets through an affected device. A
| successful exploit could allow the attacker to exhaust resources on
| the affected device, causing the device to reload.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort-dos-s2R7W9UU

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-3315
https://www.cve.org/CVERecord?id=CVE-2020-3315
[1] 

Bug#1021275: hipcc cannot find ROCm device library and HIP runtime

[Witold Baryluk]

Package: hipcc
Version: 5.0.0-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

Thanks for packaging ROCm components. But it still looks is a bit off being 
fully usable out of the box.

user@debian:~/s$ wget -nv 
https://raw.githubusercontent.com/ROCm-Developer-Tools/HIP/develop/samples/2_Cookbook/0_MatrixTranspose/MatrixTranspose.cpp
2022-10-04 19:41:01 
URL:https://raw.githubusercontent.com/ROCm-Developer-Tools/HIP/develop/samples/2_Cookbook/0_MatrixTranspose/MatrixTranspose.cpp
 [3860/3860] -> "MatrixTranspose.cpp" [1]
user@debian:~/s$ hipcc MatrixTranspose.cpp
clang: error: cannot find ROCm device library; provide its path via 
'--rocm-path' or '--rocm-device-lib-path', or pass '-nogpulib' to build without 
ROCm device library
clang: error: cannot find HIP runtime; provide its path via '--rocm-path', or 
pass '-nogpuinc' to build without HIP runtime
clang: error: cannot find HIP runtime; provide its path via '--rocm-path', or 
pass '-nogpuinc' to build without HIP runtime
user@debian:~/s$ 


I managed to compile it using

hipcc --rocm-path=/ 
--rocm-device-lib-path=/usr/lib/x86_64-linux-gnu/amdgcn/bitcode 
MatrixTranspose.cpp

but it took some time to figure out, and is not nice putting these paths
directly in makefiles, and such.

(Also resulting binary segfault:
Device name �C�xU
Segmentation fault
)

but that is another story.

Regards,
Witold

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-rc5 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hipcc depends on:
ii  clang-141:14.0.6-2
ii  clang-tools-14  1:14.0.6-2
ii  libamdhip64-dev 5.0.0-1
ii  libfile-which-perl  1.27-1
ii  liburi-encode-perl  1.1.1-2
ii  lld-14  1:14.0.6-2
ii  rocm-device-libs5.1.0-1

hipcc recommends no packages.

hipcc suggests no packages.

-- no debconf information

Bug#1021274: python-opcua: CVE-2022-25304

[Moritz Mühlenhoff]

Source: python-opcua
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for python-opcua.

CVE-2022-25304[0]:
| All versions of package opcua; all versions of package asyncua are
| vulnerable to Denial of Service (DoS) due to a missing limitation on
| the number of received chunks - per single session or in total for all
| concurrent sessions. An attacker can exploit this vulnerability by
| sending an unlimited number of huge chunks (e.g. 2GB each) without
| sending the Final closing chunk.

https://github.com/FreeOpcUa/python-opcua/issues/1466
https://security.snyk.io/vuln/SNYK-PYTHON-OPCUA-2988730

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-2022-25304
https://www.cve.org/CVERecord?id=CVE-2022-25304

Please adjust the affected versions in the BTS as needed.

Bug#1021272: keystone: CVE-2022-2447

[Moritz Mühlenhoff]

Source: keystone
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for keystone.

CVE-2022-2447[0]:
| A flaw was found in Keystone. There is a time lag (up to one hour in a
| default configuration) between when security policy says a token
| should be revoked from when it is actually revoked. This could allow a
| remote administrator to secretly maintain access for longer than
| expected.

The only reference so far seems from Red Hat Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=2105419

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-2022-2447
https://www.cve.org/CVERecord?id=CVE-2022-2447

Please adjust the affected versions in the BTS as needed.

Bug#1021273: nomad: CVE-2021-37218 CVE-2021-43415 CVE-2022-24683 CVE-2022-24684 CVE-2022-24685 CVE-2022-24686

[Moritz Mühlenhoff]

Source: nomad
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for nomad.

CVE-2021-37218[0]:
| HashiCorp Nomad and Nomad Enterprise Raft RPC layer allows non-server
| agents with a valid certificate signed by the same CA to access
| server-only functionality, enabling privilege escalation. Fixed in
| 1.0.10 and 1.1.4.

https://discuss.hashicorp.com/t/hcsec-2021-21-nomad-raft-rpc-privilege-escalation/29023
https://github.com/hashicorp/nomad/pull/11089 (main)
https://github.com/hashicorp/nomad/commit/768d7c72a77e9c0415d92900753fc83e8822145a
 (release-1.1.4)
https://github.com/hashicorp/nomad/commit/61a922afcf12784281757402c8e0b61686ff855d
 (release-1.0.11)

CVE-2021-43415[1]:
| HashiCorp Nomad and Nomad Enterprise up to 1.0.13, 1.1.7, and 1.2.0,
| with the QEMU task driver enabled, allowed authenticated users with
| job submission capabilities to bypass the configured allowed image
| paths. Fixed in 1.0.14, 1.1.8, and 1.2.1.

https://discuss.hashicorp.com/t/hcsec-2021-31-nomad-qemu-task-driver-allowed-paths-bypass-with-job-args/32288
https://github.com/hashicorp/nomad/issues/11542
https://github.com/hashicorp/nomad/pull/11554
https://github.com/hashicorp/nomad/commit/40de248b940eb7babbd4a08ebe9d6874758f5285
 (v1.2.1)

CVE-2022-24683[2]:
| HashiCorp Nomad and Nomad Enterprise 0.9.2 through 1.0.17, 1.1.11, and
| 1.2.5 allow operators with read-fs and alloc-exec (or job-submit)
| capabilities to read arbitrary files on the host filesystem as root.

https://discuss.hashicorp.com/t/hcsec-2022-02-nomad-alloc-filesystem-and-container-escape/35560

CVE-2022-24684[3]:
| HashiCorp Nomad and Nomad Enterprise 0.9.0 through 1.0.16, 1.1.11, and
| 1.2.5 allow operators with job-submit capabilities to use the spread
| stanza to panic server agents. Fixed in 1.0.18, 1.1.12, and 1.2.6.

https://discuss.hashicorp.com/t/hcsec-2022-04-nomad-spread-job-stanza-may-trigger-panic-in-servers/35562
https://github.com/hashicorp/nomad/issues/12039
https://github.com/hashicorp/nomad/commit/c49359ad58f0af18a5697a0b7b9b6cca9656d267
 (v1.2.6)

CVE-2022-24685[4]:
| HashiCorp Nomad and Nomad Enterprise 1.0.17, 1.1.11, and 1.2.5 allow
| invalid HCL for the jobs parse endpoint, which may cause excessive CPU
| usage. Fixed in 1.0.18, 1.1.12, and 1.2.6.

https://discuss.hashicorp.com/t/hcsec-2022-03-nomad-malformed-job-parsing-results-in-excessive-cpu-usage/35561
https://github.com/hashicorp/nomad/issues/12038

CVE-2022-24686[5]:
| HashiCorp Nomad and Nomad Enterprise 0.3.0 through 1.0.17, 1.1.11, and
| 1.2.5 artifact download functionality has a race condition such that
| the Nomad client agent could download the wrong artifact into the
| wrong destination. Fixed in 1.0.18, 1.1.12, and 1.2.6

https://discuss.hashicorp.com/t/hcsec-2022-01-nomad-artifact-download-race-condition/35559

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-37218
https://www.cve.org/CVERecord?id=CVE-2021-37218
[1] https://security-tracker.debian.org/tracker/CVE-2021-43415
https://www.cve.org/CVERecord?id=CVE-2021-43415
[2] https://security-tracker.debian.org/tracker/CVE-2022-24683
https://www.cve.org/CVERecord?id=CVE-2022-24683
[3] https://security-tracker.debian.org/tracker/CVE-2022-24684
https://www.cve.org/CVERecord?id=CVE-2022-24684
[4] https://security-tracker.debian.org/tracker/CVE-2022-24685
https://www.cve.org/CVERecord?id=CVE-2022-24685
[5] https://security-tracker.debian.org/tracker/CVE-2022-24686
https://www.cve.org/CVERecord?id=CVE-2022-24686

Please adjust the affected versions in the BTS as needed.

Bug#1021270: libmodbus: CVE-2022-0367

[Moritz Mühlenhoff]

Source: libmodbus
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for libmodbus.

CVE-2022-0367[0]:
| A heap-based buffer overflow flaw was found in libmodbus in function
| modbus_reply() in src/modbus.c.

https://bugzilla.redhat.com/show_bug.cgi?id=2045571
https://github.com/stephane/libmodbus/issues/614
Fixed by: 
https://github.com/stephane/libmodbus/commit/b4ef4c17d618eba0adccc4c7d9e9a1ef809fc9b6
 (v3.1.7)

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-2022-0367
https://www.cve.org/CVERecord?id=CVE-2022-0367

Please adjust the affected versions in the BTS as needed.

Bug#1021271: strongswan: CVE-2022-40617

[Salvatore Bonaccorso]

Source: strongswan
Version: 5.9.6-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 5.9.1-1+deb11u2
Control: found -1 5.9.1-1
Control: found -1 5.5.1-4

Hi,

The following vulnerability was published for strongswan.

CVE-2022-40617[0]:
| Using Untrusted URIs for Revocation Checking

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-2022-40617
https://www.cve.org/CVERecord?id=CVE-2022-40617
[1] 
https://www.strongswan.org/blog/2022/10/03/strongswan-vulnerability-(cve-2022-40617).html
[2] https://download.strongswan.org/security/CVE-2022-40617

Regards,
Salvatore

Bug#1021269: ITP: ocaml-afl-persistent -- use afl-fuzz in persistent mode

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: debian-de...@lists.debian.org, jpu...@debian.org, 
debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-afl-persistent
  Version : 1.3
  Upstream Author : Stephen Dolan 
* URL : https://github.com/stedolan/ocaml-afl-persistent
* License : MIT
  Programming Lang: OCaml
  Description : use afl-fuzz in persistent mode
 Makes it possible to run the afl-fuzz provided by the
 OCaml compiler in persistent mode.

I plan to maintain it within the Debian OCaml Maintainers team ; it's a dep for
a new dep of ocaml-cohttp.

Cheers,

J.Puydt

Bug#1021268: should recommend/depend on libqt5multimedia5-plugins

[Ryan Kavanagh]

Package: js8call
Version: 2.2.0+ds-3
Severity: normal
X-Debbugs-Cc: r...@debian.org

I have an Icom IC-7300 connected to my laptop via USB and am using
pulseaudio. js8call did not list any audio devices (regardless of
whether pulse was running) in its configuration menu until I installed
libqt5multimedia5-plugins. It should be added as a dependency or at
least as a recommends.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages js8call depends on:
ii  libc6  2.34-8
ii  libfftw3-single3   3.3.8-2
ii  libgcc-s1  12.2.0-2
ii  libgfortran5   12.2.0-2
ii  libgomp1   12.2.0-2
ii  libhamlib-utils4.3.1-1+b3
ii  libhamlib4 4.3.1-1+b3
ii  libqcustomplot2.0  2.0.1+dfsg1-6
ii  libqt5core5a   5.15.4+dfsg-5
ii  libqt5gui5 5.15.4+dfsg-5
ii  libqt5multimedia5  5.15.4-2
ii  libqt5network5 5.15.4+dfsg-5
ii  libqt5serialport5  5.15.4-2
ii  libqt5widgets5 5.15.4+dfsg-5
ii  libsqlite3-0   3.39.3-1
ii  libstdc++6 12.2.0-2
ii  wsjtx-data 2.6.0~rc3+repack-1

js8call recommends no packages.

js8call suggests no packages.

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A

Bug#989705: closing 989705

[Computer Enthusiastic]

Hello Salvatore,

Il giorno mar 20 set 2022 alle ore 12:32 Salvatore Bonaccorso
 ha scritto:
>
> Hi,
[..]
> >
> > What could be done to make the patch land in the current Debian Stable
> > (Bullseye) kernel release ?
>
> It should land in the 5.10.y stable series which we will then pick up
> automatically on next rebases. But what is puzzling is that the commit
> has been marked for stable only v5.15+. If you were able to confirm it
> is actually present in 5.10.y as well then it needs a followup to be
> picked as well for the 5.10.y stable series.
>
> Regards,
> Salvatore

Yes, the patch is marked as only v5.15+, but the issue is still there
in kernel 5.10, too.

As you suggested, I have tested the vanilla kernel 5.10.145 with and
without kernel patches, as reported here [0].

Thanks.

[0] https://lists.freedesktop.org/archives/nouveau/2022-September/041182.html

Bug#1021256: gtkmm4: autopkgtest failure: Failed to locate “gtk-logo.webm” in any source directory

[Jeremy Bicha]

On Tue, Oct 4, 2022 at 3:05 PM Adrian Bunk  wrote:
>
> On Tue, Oct 04, 2022 at 02:57:07PM -0400, Jeremy Bicha wrote:
> > On Tue, Oct 4, 2022 at 2:54 PM Adrian Bunk  wrote:
> > > On Tue, Oct 04, 2022 at 02:49:37PM -0400, Jeremy Bicha wrote:
> > > > Control: severity -1 important
> > > >
> > > > Since gtkmm4.0 is new to Debian, a broken autopkgtest isn't a
> > > > regression and doesn't block migration to Testing.
> >
> > I think that's a bug in the testing migration. I don't believe it's
> > supposed to block in this case.
>
> autopkgtest failures in testing are release critical bugs,
> blocking prevents an RC bug from entering testing.

I don't think so? I believe there are autopkgtests that have always
failed in Testing.

Anyway, here's the current failure:

gtktest.cc: In function ‘void {anonymous}::do_quit()’:
gtktest.cc:10:10: error: ‘Gtk::Main’ has not been declared
   10 | Gtk::Main::quit();
  |  ^~~~
gtktest.cc: In function ‘int main(int, char**)’:
gtktest.cc:18:10: error: ‘Main’ is not a member of ‘Gtk’
   18 | Gtk::Main main_instance (, );
  |  ^~~~
gtktest.cc:24:10: error: ‘Gtk::Main’ has not been declared
   24 | Gtk::Main::run();
  |  ^~~~

The gtkmm4 documentation provides an example ("Hello, world") app but
it works differently. I don't have much experience with gtkmm coding
or C++. We'll need to decide whether we want to just use their example
or tweak what we copied from gtkmm3. Or just drop our custom basic
app.

Jeremy Bicha

Bug#989705: closing 989705

[Salvatore Bonaccorso]

Hi,

On Tue, Oct 04, 2022 at 07:39:23PM +0200, Computer Enthusiastic wrote:
> Hello Salvatore,
> 
> Il giorno mar 20 set 2022 alle ore 12:32 Salvatore Bonaccorso
>  ha scritto:
> >
> > Hi,
> [..]
> > >
> > > What could be done to make the patch land in the current Debian Stable
> > > (Bullseye) kernel release ?
> >
> > It should land in the 5.10.y stable series which we will then pick up
> > automatically on next rebases. But what is puzzling is that the commit
> > has been marked for stable only v5.15+. If you were able to confirm it
> > is actually present in 5.10.y as well then it needs a followup to be
> > picked as well for the 5.10.y stable series.
> >
> > Regards,
> > Salvatore
> 
> Yes, the patch is marked as only v5.15+, but the issue is still there
> in kernel 5.10, too.
> 
> As you suggested, I have tested the vanilla kernel 5.10.145 with and
> without kernel patches, as reported here [0].

Seen that, and thanks for having taken the time to test the case with
and without patch with newest 5.10.y version. This will hopefully help
to get the patch applied to 5.10.y as well so we can pick it up.

Regards,
Salvatore

Bug#1021256: gtkmm4: autopkgtest failure: Failed to locate “gtk-logo.webm” in any source directory

[Adrian Bunk]

On Tue, Oct 04, 2022 at 02:57:07PM -0400, Jeremy Bicha wrote:
> On Tue, Oct 4, 2022 at 2:54 PM Adrian Bunk  wrote:
> > On Tue, Oct 04, 2022 at 02:49:37PM -0400, Jeremy Bicha wrote:
> > > Control: severity -1 important
> > >
> > > Since gtkmm4.0 is new to Debian, a broken autopkgtest isn't a
> > > regression and doesn't block migration to Testing.
> 
> I think that's a bug in the testing migration. I don't believe it's
> supposed to block in this case.

autopkgtest failures in testing are release critical bugs,
blocking prevents an RC bug from entering testing.

> Thank you,
> Jeremy Bicha

cu
Adrian

Bug#1021267: RM: openbsc -- ROM; Dead upstream

[Thorsten Alteholz]

Package: ftp.debian.org
Severity: normal

openBSC is a legacy all-in-one implementation of the Osmocom BSC + MSC + 
HLR. It is no longer developed upstream, instead refer to packages 
OsmoBSC, OsmoMSC, OsmoHLR.


  Thorsten

Bug#1021256: gtkmm4: autopkgtest failure: Failed to locate “gtk-logo.webm” in any source directory

[Jeremy Bicha]

On Tue, Oct 4, 2022 at 2:54 PM Adrian Bunk  wrote:
> On Tue, Oct 04, 2022 at 02:49:37PM -0400, Jeremy Bicha wrote:
> > Control: severity -1 important
> >
> > Since gtkmm4.0 is new to Debian, a broken autopkgtest isn't a
> > regression and doesn't block migration to Testing.

I think that's a bug in the testing migration. I don't believe it's
supposed to block in this case.

Thank you,
Jeremy Bicha

Bug#1021256: gtkmm4: autopkgtest failure: Failed to locate “gtk-logo.webm” in any source directory

[Adrian Bunk]

On Tue, Oct 04, 2022 at 02:49:37PM -0400, Jeremy Bicha wrote:
> Control: severity -1 important
> 
> Since gtkmm4.0 is new to Debian, a broken autopkgtest isn't a
> regression and doesn't block migration to Testing.
>...

That's not true:
https://tracker.debian.org/pkg/gtkmm4.0

> Thank you,
> Jeremy Bicha

cu
Adrian

Bug#1021266: curl CVE patches applied at curl 7.74.0-1.3+deb11u2 breaks janus package working with RTSP sources

[Raimon Alba]

Package: curl
Version: 7.74.0-1.3+deb11u2
Severity: important

Dear Maintainer,


   * What led up to the situation? Updating system to lastest official
packages for Debian bullseye upgraded curl/libcurl first to
7.74.0-1.3+deb11u2 and later to 7.74.0-1.3-deb11u3 both resulting in
package janus using RTSP sources stop working with zoneminder.
   * What exactly did you do (or not do) that was effective (or
ineffective)? Downgrading to 7.74.0-1.3+deb11u1 made it work again without
touching any thing.
   * What was the outcome of this action?. Simply downgrading maintainer
version made it work. So should be anything between deb11u1 and deb11u2
version.
   * What outcome did you expect instead?



-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-18-amd64 (SMP w/6 CPU threads)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages curl depends on:
ii  libc6 2.31-13+deb11u4
ii  libcurl4  7.74.0-1.3+deb11u2
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

curl recommends no packages.

curl suggests no packages.

-- no debconf information

--1664908316-eximdsn-417993741--

Bug#1021256: gtkmm4: autopkgtest failure: Failed to locate “gtk-logo.webm” in any source directory

[Jeremy Bicha]

Control: severity -1 important

Since gtkmm4.0 is new to Debian, a broken autopkgtest isn't a
regression and doesn't block migration to Testing.

I've fixed the one line seen in the autopkgtest failure, but…

We need to either port the minimal gtkmm app to gtkmm4 or drop it and
just use the included demos apps to test whether simple gtkmm apps
build and work.

Thank you,
Jeremy Bicha

Bug#1014815: kiwipy initial packaging

[Guilherme de Paula Xavier Segundo]

Hi Bastian,

I'm working on packaging kiwipy.
I've packaged several dependencies on it so far but it currently depends
on python-aio-pika <6.8.2 but the version we have on Debian is 8.1.1

On 22/10/04 02:01, Andrius Merkys wrote:
> Hi Bastian,
> 
> On 2022-10-04 02:12, Bastian Germann wrote:
> > What is the status on kiwipy?
> 
> For some time kiwipy was blocked by pytray, but pytray is in unstable
> now. I will revisit kiwipy.
> 
> Best,
> Andrius


signature.asc
Description: PGP signature

Bug#1021215: Kind request for backports of libtraceevent and libtracefs

[Sudip Mukherjee]

On Mon, Oct 3, 2022 at 11:45 PM Hans van Kranenburg  wrote:
>
> Package: src:libtraceevent
> Version: 1:1.1.2-1
>
> Hi maintainer, :)
>
> Linux commit fe4d0d5dde ("rtla/Makefile: Properly handle dependencies")
> helps making the dependency on libtraceevent and libtracefs more
> explicit, so that the users run into less weird problems on the go.
>
> Linux 5.19 is in Debian unstable now, and for the stable-backports
> packages that our kernel team is providing, this means that it will
> FTBFS, unless we either:
> - exclude rtla for bullseye-backports
> - have backports for libtraceevent and libtracefs present
>
> So, the question for you is: Do you want to also provide
> bullseye-backports packages for libtraceevent and libtracefs?

Sure, will do it over this weekend.


-- 
Regards
Sudip

Bug#1021186: bullseye-pu: package debmirror/1:2.35+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-10-03 at 14:05 +0100, Colin Watson wrote:
> Support mirroring of the new non-free-firmware section.  See
> https://lists.debian.org/debian-boot/2022/10/msg00026.html.
> 
> [ Impact ]
> The non-free-firmware section will be absent from debmirror-managed
> mirrors, unless the list of sections is specified explicitly.
> 
[...]
> +debmirror (1:2.35+deb11u1) UNRELEASED; urgency=medium
> +
> +  * Add non-free-firmware to the default sections.
> 

With the presumed s/UNRELEASED/bullseye/, please go ahead.

Regards,

Adam

Bug#1021264: haskell-hdf5 FTBFS in unregistered builds: unknown RTS option: -N

[Adrian Bunk]

Source: haskell-hdf5
Version: 1.8.10-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-hdf5=1.8.10-1

...
Linking dist-ghc/build/hdf5-test/hdf5-test ...
touch build-ghc-stamp
perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \
-E 'check_recipe'
Running dh_listpackages
libghc-hdf5-dev
libghc-hdf5-prof
libghc-hdf5-doc
Running 1 test suites...
Test suite hdf5-test: RUNNING...
hdf5-test: unknown RTS option: -N
hdf5-test: 
hdf5-test: Usage:   [+RTS  | -RTS ] ... --RTS 
hdf5-test: 
hdf5-test:+RTSIndicates run time system options follow
hdf5-test:-RTSIndicates program arguments follow
hdf5-test:   --RTSIndicates that ALL subsequent arguments will be given to 
the
hdf5-test:program (including any of these RTS flags)
hdf5-test: 
hdf5-test: The following run time system options are available:
hdf5-test: 
hdf5-test:   -?   Prints this message and exits; the program is not executed
hdf5-test:   --info   Print information about the RTS used by this program
hdf5-test: 
hdf5-test:   --nonmoving-gc
hdf5-test: Selects the non-moving mark-and-sweep garbage collector 
to
hdf5-test: manage the oldest generation.
hdf5-test:   --copying-gc
hdf5-test: Selects the copying garbage collector to manage all 
generations.
hdf5-test: 
hdf5-test:   -K  Sets the maximum stack size (default: 80% of the heap)
hdf5-test: Egs: -K32k -K512k -K8M
hdf5-test:   -ki Sets the initial thread stack size (default 1k)  Egs: 
-ki4k -ki2m
hdf5-test:   -kc Sets the stack chunk size (default 32k)
hdf5-test:   -kb Sets the stack chunk buffer size (default 1k)
hdf5-test: 
hdf5-test:   -A  Sets the minimum allocation area size (default 1m) Egs: 
-A20m -A10k
hdf5-test:   -AL Sets the amount of large-object memory that can be 
allocated
hdf5-test: before a GC is triggered (default: the value of -A)
hdf5-test:   -F Sets the collecting threshold for old generations as a 
factor of
hdf5-test: the live data in that generation the last time it was 
collected
hdf5-test: (default: 2.0)
hdf5-test:   -n  Allocation area chunk size (0 = disabled, default: 0)
hdf5-test:   -O  Sets the minimum size of the old generation (default 1M)
hdf5-test:   -M  Sets the maximum heap size (default unlimited)  Egs: 
-M256k -M1G
hdf5-test:   -H  Sets the minimum heap size (default 0M)   Egs: -H24m  
-H1G
hdf5-test:   -xb Sets the address from which a suitable start for the 
heap memory
hdf5-test: will be searched from. This is useful if the default 
address
hdf5-test: clashes with some third-party library.
hdf5-test:   -xn   Use the non-moving collector for the old generation.
hdf5-test:   -m Minimum % of heap which must be available (default 3%)
hdf5-test:   -G Number of generations (default: 2)
hdf5-test:   -c Use in-place compaction instead of copying in the oldest 
generation
hdf5-test:when live data is at least % of the maximum heap size 
set with
hdf5-test:-M (default: 30%)
hdf5-test:   -c   Use in-place compaction for all oldest generation 
collections
hdf5-test:(the default is to use copying)
hdf5-test:   -w   Use mark-region for the oldest generation (experimental)
hdf5-test:   -I  Perform full GC after  idle time (default: 0.3, 0 == 
off)
hdf5-test: 
hdf5-test:   -T Collect GC statistics (useful for in-program statistics 
access)
hdf5-test:   -t[] One-line GC statistics (if  omitted, uses stderr)
hdf5-test:   -s[] Summary  GC statistics (if  omitted, uses stderr)
hdf5-test:   -S[] Detailed GC statistics (if  omitted, uses stderr)
hdf5-test: 
hdf5-test: 
hdf5-test:   -Z Don't squeeze out update frames on context switch
hdf5-test:   -B Sound the bell at the start of each garbage collection
hdf5-test:   -h   Heap residency profile (output file .hp)
hdf5-test:   -hT  Produce a heap profile grouped by closure type
hdf5-test:   -i  Time between heap profile samples (seconds, default: 0.1)
hdf5-test: 
hdf5-test:   -C  Context-switch interval in seconds.
hdf5-test: 0 or no argument means switch as often as possible.
hdf5-test: Default: 0.02 sec.
hdf5-test:   -V  Master tick interval in seconds (0 == disable timer).
hdf5-test: This sets the resolution for -C and the heap profile 
timer -i,
hdf5-test: and is the frequency of time profile samples.
hdf5-test: Default: 0.01 sec.
hdf5-test: 
hdf5-test:   --install-signal-handlers=
hdf5-test: Install signal handlers (default: yes)
hdf5-test:   --io-manager=
hdf5-test: The I/O manager subsystem to use. (default: posix)
hdf5-test:   -e Maximum number of outstanding local sparks (default: 
4096)
hdf5-test:   -xq   The allocation limit given to a thread after it receives
hdf5-test: an AllocationLimitExceeded exception. (default: 100k)

Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system

[Samuel Thibault]

Hello,

Is there an easy way to unbrick a system affected by the issue? such as
a kernel-line option or a configuration file in /etc? I don't see how I
can set a GLIBC_TUNABLES environment variable for the whole system.

Samuel

Bug#1014815: kiwipy initial packaging

[Bastian Germann]

Am 04.10.22 um 19:45 schrieb Guilherme de Paula Xavier Segundo:

Hi Bastian,

I'm working on packaging kiwipy.
I've packaged several dependencies on it so far but it currently depends
on python-aio-pika <6.8.2 but the version we have on Debian is 8.1.1


So we should wait until https://github.com/aiidateam/kiwipy/pull/113 has 
settled?


On 22/10/04 02:01, Andrius Merkys wrote:

Hi Bastian,

On 2022-10-04 02:12, Bastian Germann wrote:

What is the status on kiwipy?


For some time kiwipy was blocked by pytray, but pytray is in unstable
now. I will revisit kiwipy.

Best,
Andrius

Bug#1014815: kiwipy initial packaging

[Bastian Germann]

Am 04.10.22 um 20:20 schrieb Guilherme de Paula Xavier Segundo:

Yes,
I believe it is the best solution. If there is any other suggestion
I am available.


Another solution would be downgrading. Is the package used by something else in 
the archive?

Bug#1021265: golang-github-libgit2-git2go ftbfs with libgit2 1.5

[Pirate Praveen]

Package: golang-github-libgit2-git2go
Version: 33.0.9-2
Severity: serious
Control: forwarded -1 https://github.com/libgit2/git2go/pull/929

This is also seen in autopkgtest failure 
https://ci.debian.net/data/autopkgtest/unstable/amd64/g/golang-github-libgit2-git2go/26651971/log.gz


Upstream recently merged https://github.com/libgit2/git2go/pull/929 and 
hopefully they will release a new version.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system

[debian-bug-report]

Is there an easy way to unbrick a system affected by the issue? such as
a kernel-line option or a configuration file in /etc? I don't see how I
can set a GLIBC_TUNABLES environment variable for the whole system.


I was trying during my testing to set such option globally somehow, but 
failed, though maybe some method for this exists. As it stands I only 
see two possibilities of unbricking a system, both assuming you can 
access the partition externally from some bootable system:


1. Downgrade the affected libc6 package to a version before the one 
causing issues (either chroot and dpkg, or just extract and physically 
replace the files), after booting apt-mark hold libc6 to prevent faulty 
update from being installed until the issue is fixed


2. Or install intel-microcode package, assuming the microcode update 
adds the missing instructions in particular case, basically 
coincidentally fixing this issue (the updated CPU microcode is loaded on 
every bootup)

Bug#1020765: Does Debian 11.x 32 bit support NVDIMM?

[Williams, Dan J]

Comments inline below

On Mon, 26 Sep 2022 08:26:56 + Winnie Yue  wrote:
> Package: ndctl
> Version: 71.1-1
> Severity: serious
>
> For Debian 11.5 32 bit, I got below info:
>
> apt-cache search ndctl
>
> libndctl-dev - Development files for libndctl
>
> libndctl6 - Utility library for managing the libnvdimm subsystem
>
> ndctl - Utility for managing the nvdimm subsystem
>
> It is same to what I got from Debian 11.5 64 bit:
>
> apt-cache search ndctl
>
> libndctl-dev - Development files for libndctl
>
> libndctl6 - Utility library for managing the libnvdimm subsystem
>
> ndctl - Utility for managing the nvdimm subsystem
>
>
> From https://lists.debian.org/debian-devel/2016/12/msg00330.html, 
> https://lists.debian.org/debian-devel/2016/12/msg00343.html, NVDIMM will be 
> fully supported once OS has the package ndctl.
>
> But I found that Debian 11.5 32 bit vm couldn’t recognize the NVDIMM device:
>
>
> #cat /etc/debian_version
>
> 11.5
>
>
>
> #uname -m
>
> i686
>
>
>
> # dmesg | grep -i bios-e820 | grep persistent
>
> [ 0.00] BIOS-e820: [mem 0x00024000-0x00043fff] persistent 
> (type 7)

Note that this is not sufficient for advertising NVDIMM resources. A Type-7 
memory range still requires an ACPI NFIT to advertise the memory range.

That said, why are you trying to run a 32-bit environment. If you need a 32-bit 
userspace you can still use a 64-bit kernel. 32-bit x86 is not well looked 
after by the kernel community in general these days.

Bug#1014815: kiwipy initial packaging

[Guilherme de Paula Xavier Segundo]

Yes,
I believe it is the best solution. If there is any other suggestion
I am available.

On 22/10/04 08:02, Bastian Germann wrote:
> Am 04.10.22 um 19:45 schrieb Guilherme de Paula Xavier Segundo:
> > Hi Bastian,
> > 
> > I'm working on packaging kiwipy.
> > I've packaged several dependencies on it so far but it currently depends
> > on python-aio-pika <6.8.2 but the version we have on Debian is 8.1.1
> 
> So we should wait until https://github.com/aiidateam/kiwipy/pull/113 has 
> settled?
> 
> > On 22/10/04 02:01, Andrius Merkys wrote:
> > > Hi Bastian,
> > > 
> > > On 2022-10-04 02:12, Bastian Germann wrote:
> > > > What is the status on kiwipy?
> > > 
> > > For some time kiwipy was blocked by pytray, but pytray is in unstable
> > > now. I will revisit kiwipy.
> > > 
> > > Best,
> > > Andrius
> 

Bug#1021263: more test

[Adam D. Barratt]

Control: severity -1 minor

Bug#1021263: more test

[Adam D. Barratt]

Control: severity -1 wishlist

Bug#1021263: exim test bug

[Adam D. Barratt]

Package: bugs.debian.org

This is a test of exim after the bullseye upgrade

Bug#1019453: ibus: IBus doesn't work correctly in apps that don't support surrounding text

[Eberhard Beilharz]

My fault. I created a local package with the upstream changes and fell 
in the ibus link trap - the upstream repo uses links for ibusimcontext.c 
for gtk2/gtk3/gtk4 whereas the source package uses three different 
files. When I imported the patches I forgot to make the changes for gtk3 
and gtk4. With the correct patches that match upstream everything works 
as expected. 


Attached are patches for the three related upstream commits (I tested 
with all three commits, although probably only 0002 would be needed for 
this bug).


Gunnar Hjalmarsson wrote on 2022-09-27 15:53:

On 2022-09-27 15:16, Eberhard Beilharz wrote:

AFAICT the problem in Firefox has been fixed in Firefox 99.


In that case, did Takao Fujiwara misunderstand it when he wrote in the 
781119be commit message that "the special issue should be fixed in 
firefox"?



I'll report back once I have an idea what would make sense regarding
patching ibus.


Great; I'll await your next step then.

From ddead515d9d53fc692af252f610b009660494e21 Mon Sep 17 00:00:00 2001
From: fujiwarat 
Date: Wed, 21 Sep 2022 21:08:33 +0900
Subject: [PATCH 3/3] client/gtk2: Update surrounding text properties by focus
 in

ibus_input_context_set_surrounding_text() should be succeeded
if input contexts are different so that ibus engines can
update surrounding text properties with focus in event.

When an input context is created newly, RequireSurroundingText D-Bus
signal could not be received yet and set_surrounding_text() is failed.
Now "require-surrounding-text" signal is added to IBusInputContext
and clients can call set_surrounding_text() later.

BUG=https://github.com/ibus/ibus/issues/2423
---
 client/gtk2/ibusimcontext.c | 25 +
 src/ibusinputcontext.c  | 29 -
 2 files changed, 53 insertions(+), 1 deletion(-)

--- a/client/gtk2/ibusimcontext.c
+++ b/client/gtk2/ibusimcontext.c
@@ -70,6 +70,7 @@
 #endif
 
 IBusInputContext *ibuscontext;
+IBusInputContext *ibuscontext_needs_surrounding;
 
 /* preedit status */
 gchar   *preedit_string;
@@ -985,6 +986,7 @@
 ibusimcontext->cursor_area.height = 0;
 
 ibusimcontext->ibuscontext = NULL;
+ibusimcontext->ibuscontext_needs_surrounding = NULL;
 ibusimcontext->has_focus = FALSE;
 ibusimcontext->time = GDK_CURRENT_TIME;
 #ifdef ENABLE_SURROUNDING
@@ -2184,6 +2186,18 @@
 }
 
 static void
+_ibus_context_require_surrounding_text_cb (IBusInputContext *ibuscontext,
+   IBusIMContext*ibusimcontext)
+{
+IDEBUG ("%s", __FUNCTION__);
+g_assert (ibusimcontext->ibuscontext == ibuscontext);
+if (ibusimcontext->ibuscontext_needs_surrounding == ibuscontext) {
+_request_surrounding_text (ibusimcontext);
+ibusimcontext->ibuscontext_needs_surrounding = NULL;
+}
+}
+
+static void
 _ibus_context_destroy_cb (IBusInputContext *ibuscontext,
   IBusIMContext*ibusimcontext)
 {
@@ -2249,6 +2263,11 @@
   "hide-preedit-text",
   G_CALLBACK (_ibus_context_hide_preedit_text_cb),
   ibusimcontext);
+g_signal_connect (
+ibusimcontext->ibuscontext,
+"require-surrounding-text",
+G_CALLBACK (_ibus_context_require_surrounding_text_cb),
+ibusimcontext);
 g_signal_connect (ibusimcontext->ibuscontext, "destroy",
   G_CALLBACK (_ibus_context_destroy_cb),
   ibusimcontext);
@@ -2265,6 +2284,12 @@
 
 ibus_input_context_focus_in (ibusimcontext->ibuscontext);
 _set_cursor_location_internal (ibusimcontext);
+if (ibus_input_context_needs_surrounding_text (
+ibusimcontext->ibuscontext)) {
+_request_surrounding_text (ibusimcontext);
+} else {
+ibusimcontext->ibuscontext_needs_surrounding = ibusimcontext->ibuscontext;
+}
 }
 
 if (!g_queue_is_empty (ibusimcontext->events_queue)) {
--- a/client/gtk3/ibusimcontext.c
+++ b/client/gtk3/ibusimcontext.c
@@ -70,6 +70,7 @@
 #endif
 
 IBusInputContext *ibuscontext;
+IBusInputContext *ibuscontext_needs_surrounding;
 
 /* preedit status */
 gchar   *preedit_string;
@@ -985,6 +986,7 @@
 ibusimcontext->cursor_area.height = 0;
 
 ibusimcontext->ibuscontext = NULL;
+ibusimcontext->ibuscontext_needs_surrounding = NULL;
 ibusimcontext->has_focus = FALSE;
 ibusimcontext->time = GDK_CURRENT_TIME;
 #ifdef ENABLE_SURROUNDING
@@ -2184,6 +2186,18 @@
 }
 
 static void
+_ibus_context_require_surrounding_text_cb (IBusInputContext *ibuscontext,
+   IBusIMContext*ibusimcontext)
+{
+IDEBUG ("%s", __FUNCTION__);
+g_assert (ibusimcontext->ibuscontext == ibuscontext);
+if (ibusimcontext->ibuscontext_needs_surrounding == 

Bug#1021262: ruby-stackprof FTBFS on 32bit

[Adrian Bunk]

Source: ruby-stackprof
Version: 0.2.21-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=ruby-stackprof=0.2.21-1

...
Finished in 0.379613s, 79.0278 runs/s, 237.0833 assertions/s.

  1) Failure:
StackProfTest#test_raw [/<>/test/test_stackprof.rb:153]:
Expected 498034323 to be > 859491493514.

30 runs, 90 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1): [ruby -w -I"test" 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb
 "test/test_middleware.rb" "test/test_report.rb" "test/test_stackprof.rb" 
"test/test_truffleruby.rb" -v]
/usr/share/rubygems-integration/all/gems/rake-13.0.6/exe/rake:27:in `'
Tasks: TOP => default
(See full trace by running task with --trace)
ERROR: Test "ruby3.0" failed. Exiting.
dh_auto_install: error: dh_ruby --install 
/<>/debian/ruby-stackprof returned exit code 1
make: *** [debian/rules:7: binary-arch] Error 25

Bug#1021261: ITP: gap-browse -- browsing applications and ncurses interface

[Joachim Zobel]

Package: wnpp
Severity: wishlist
Owner: Joachim Zobel 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name    : gap-browse
  Version : 1.8.17
  Upstream Author : Thomas.Breuer ,
Frank.Lübeck 
* URL : https://www.gap-system.org/Packages/browse.html
* License : GPL-3+
  Programming Lang: C, GAP 4
  Description : browsing applications and ncurses interface

 .
 The Browse package provides three levels of functionality
 * A GAP interface to the C-library ncurses.
 * A generic function for interactive browsing through two-
dimensional
   arrays of data.
 * Several applications of the first two, e.g., a method for
browsing
   character tables, browsing through the content of some data
   collections, or some games.

Bug#1021260: libdumbnet: FTBFS on hurd-i386

[Svante Signell]

Source: libdumbnet
Version: 1.16.1-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

Currently libdumbnet FTBFS on GNU/Hurd due to some failing symbols for
libdumbnet1 in the Hurd build compared to Linux. I built in the past. Latest
successful build was: 1.14-2.

The attached patch, debian_libdumbnet1.symbols.patch, fixes the build problem.

Thanks!





--- a/debian/libdumbnet1.symbols	2022-05-04 19:18:23.0 +0200
+++ b/debian/libdumbnet1.symbols	2022-10-04 13:27:47.0 +0200
@@ -72,7 +72,7 @@
  ndisc_close@Base 1.16.1
  ndisc_delete@Base 1.16.1
  ndisc_get@Base 1.16.1
- ndisc_modify@Base 1.16.1
+ (arch=!hurd-any)ndisc_modify@Base 1.16.1
  ndisc_open@Base 1.16.1
  nsidc_loop@Base 1.16.1
  rand_add@Base 1.8
@@ -84,10 +84,10 @@
  rand_uint16@Base 1.8
  rand_uint32@Base 1.8
  rand_uint8@Base 1.8
- route6_add@Base 1.16.1
- route6_delete@Base 1.16.1
+ (arch=!hurd-any)route6_add@Base 1.16.1
+ (arch=!hurd-any)route6_delete@Base 1.16.1
  route_add@Base 1.8
- route_add_dev@Base 1.16.1
+ (arch=!hurd-any)route_add_dev@Base 1.16.1
  route_close@Base 1.8
  route_delete@Base 1.8
  route_get@Base 1.8

Bug#1019140: unbound-resolvconf.service will always be in failed state when you set RESOLVCONF=false

[Thomas Deutschmann]

Hi,

may I suggest to apply the following changes?


$ diff -u /usr/libexec/unbound-helper.ori /usr/libexec/unbound-helper
--- /usr/libexec/unbound-helper.ori 2022-10-04 17:25:48.531922943 +0200
+++ /usr/libexec/unbound-helper 2022-10-04 17:26:58.143255583 +0200
@@ -24,7 +24,7 @@
 fi

 do_resolvconf_start() {
-[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
+[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0

 unbound-checkconf $CHROOT_DIR/$UNBOUND_CONF -o interface | {
 default=yes
@@ -44,13 +44,13 @@
 }

 do_resolvconf_stop() {
-[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return
+[ false != "$RESOLVCONF" -a -x /sbin/resolvconf ] || return 0

 /sbin/resolvconf -d lo.unbound
 }

 do_chroot_setup() {
-[ -n "$CHROOT_DIR" -a -d "$CHROOT_DIR" ] || return
+[ -n "$CHROOT_DIR" -a -d "$CHROOT_DIR" ] || return 0
 if [ "$CHROOT_DIR" != "$UNBOUND_BASE_DIR" ]; then
 # we probably should not do the force-recreate but just a refresh
 rm -rf   "$CHROOT_DIR/$UNBOUND_BASE_DIR"
@@ -79,7 +79,7 @@
 do_root_trust_anchor_update() {
 [ false != "$ROOT_TRUST_ANCHOR_UPDATE" -a \
   -n "$ROOT_TRUST_ANCHOR_FILE"  -a \
-  -r "$DNS_ROOT_KEY_FILE" ] || return
+  -r "$DNS_ROOT_KEY_FILE" ] || return 0

 if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" ] ||
# we do not want to copy if unbound's file is more recent


Without a return value, return would return the result of the previous 
if clause which is set to FALSE when the feature or condition isn't met.


Thanks!


--
Regards,
Thomas

Bug#799543: dh_doxygen: fails if no docs found, even in binary-only builds

[Andrea Pappacoda]

Hi Helmut, I've added the dh-sequence-doxygen sequence and submitted it 
as a [Salsa MR]; it has been simpler than expected, as the doxygen.pm 
addon was already there. One issue I noticed though is that when 
building a package using dh_doxygen with `dpkg-buildpackage 
--build=binary` nothing happens, and I get the following warning:


   dh_doxygen: warning: No packages to build. Possible architecture 
mismatch: amd64, want: all any


Everything works as expected when using `--build=all`.

This is probably not directly related to the new dh-sequence-doxygen 
package, as it also happens when building [cubeb], a package I 
maintain; as you have some experience with cross builds, profiles, etc, 
I hope you might have an idea about what's going on :)


[Salsa MR]: https://salsa.debian.org/debian/doxygen/-/merge_requests/8
[cubeb]: 
https://salsa.debian.org/debian/cubeb/-/blob/7a17dcc60f413187b1e39c35bafd21d6bfaf3978/debian/rules#L38-43


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1014456: unbound: Please enable cachedb and redis support

[Thomas Deutschmann]

On Fri, 12 Aug 2022 12:53:39 +0300 Michael Tokarev  wrote:

What does cachedb/redis bring us, how these can be used?


It will allow us to keep cache during reboot.

For example:

I set up a new Debian bookworm box where I am using unbound as resolver 
(default configuration; apt-get install unbound && systemctl start unbound):



$ cat /etc/resolv.conf
nameserver 127.0.0.1


With primed cache,


$ time ping -q -c 1 google.com
PING google.com(fra24s06-in-x0e.1e100.net (2a00:1450:4001:829::200e)) 56 data 
bytes

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.730/3.730/3.730/0.000 ms

real0m0.007s
user0m0.000s
sys 0m0.003s


If I do the same after reboot when unbound service has started:


$ time ping -q -c 1 google.com
PING google.com(fra24s07-in-x0e.1e100.net (2a00:1450:4001:82a::200e)) 56 data 
bytes

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.621/3.621/3.621/0.000 ms

real0m3.254s
user0m0.003s
sys 0m0.000s


Keep in mind that you will experience this delay for _every_ TLD due to 
DNSSEC records.


Or imagine a remote box where you try to SSH into which will be delayed 
for ~3s because this box has to do PTR lookup for your IP address.


Configuring cache db feature in unbound would allow me to store unbound 
cache in Redis for example so unbound can provide fast answers directly 
after boot.



--
Regards,
Thomas

Bug#1021179: pipewire-pulse: KDE Plasma+ALC4080 onboard card: unable to select working profile

[Maurizio Avogadro]

Interesting enough, there is an interesting difference between Pulseaudio and 
Pipewire in the output of


$ pactl list cards | grep -E '(Profile|available:)'

With Pulseaudio:
Profiles:
HiFi: Play HiFi quality Music (sinks: 3, sources: 2, priority:
8000, available: yes)
off: Spento (sinks: 0, sources: 0, priority: 0, available: yes)
Active Profile: HiFi

With Pipewire:
Profiles:
off: Spento (sinks: 0, sources: 0, priority: 0, available: yes)
HiFi: Play HiFi quality Music (sinks: 3, sources: 2, priority:
8000, available: no)
Active Profile: off

The "HiFi" profile is not available with Pipewire; the profile can still be 
selected manually with the command


$ pacmd set-card-profile alsa_card.usb-Generic_USB_Audio-00 HiFi

which makes the card work perfectly.

As I described in my first message, in Gnome the working profile is not 
automatically selected (but can be selected manually: Gnome allows the 
selection of "not available" profiles), while in KDE Plasma only available 
profiles can be selected.

Bug#1021250: libcom-err2: sudo apt install wine32 fail to install

[Theodore Ts'o]

On Tue, Oct 04, 2022 at 01:45:31PM +0200, David Gonzalo Rodriguez wrote:
> Package: libcom-err2
> Version: 1.46.5-2~bpo11+2
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: z80u...@gmail.com

What is the error message when you run "sudo apt install wine32"?

What is the reason for believing this is caused by libcom-err2?  I
don't see dependencies on libcom-err2 by the wine package.

 - Ted

Bug#1017654: oclgrind: Please upgrade to llvm-toolchain-14

[Andreas Beckmann]

Control. tag -1 upstream
Message-ID: 
<166489405811.13977.313971761409325000.report...@zam504.zam.kfa-juelich.de>
X-Mailer: reportbug 7.5.3~deb10u1
Date: Tue, 04 Oct 2022 16:34:18 +0200

Followup-For: Bug #1017654
Control: found -1 21.10-1

oclgrind does not build out-of-the-box with llvm-14, it needs upstream changes.


Andreas

Bug#1020517: scrcpy: Does not display the Android window.

[Xerxes]

Package: scrcpy
Followup-For: Bug #1020517
X-Debbugs-Cc: xerxesl...@gmail.com

Today I ran "scrcpy" on both xorg and wayland. And in both it worked without
problems. The problem no longer exists.

But I don't know what solved the problem, because since when I reported the
bug, I performed the "apt upgrade" a few times.

What I noticed of difference, however, is that in the output of the command it
appears:

mesa 22.2.0

scrcpy 1.24 
/usr/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 3.7 MB/s (40683
bytes in 0.011s)
[server] INFO: Device: samsung SM-A730F (Android 9)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6 (Compatibility Profile) Mesa 22.2.0
INFO: Trilinear filtering enabled
INFO: Initial texture: 1080x2216


And before, when the bug existed, it appeared:

mesa 22.2.0-rc3

scrcpy dependencies have also been updated since then and it could be that
these updates explain the bug fix.

Thanks!


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages scrcpy depends on:
ii  libavcodec59   7:5.1.2-1
ii  libavdevice59  7:5.1.2-1
ii  libavformat59  7:5.1.2-1
ii  libavutil577:5.1.2-1
ii  libc6  2.35-1
ii  libsdl2-2.0-0  2.24.0+dfsg-1
ii  libusb-1.0-0   2:1.0.26-1
ii  scrcpy-server  1.24-1

Versions of packages scrcpy recommends:
ii  adb  1:29.0.6-21

scrcpy suggests no packages.

-- no debconf information

Bug#1019974: uim: FTBFS on armhf: [Makefile:871: installed-modules.scm] Segmentation fault

[Dmitry Shachnev]

On Tue, Oct 04, 2022 at 03:37:36PM +0300, Adrian Bunk wrote:
> I cannot reproduce this, but I can NMU to build with -O1 everywhere.

Thank you very much. I have just closed by RM bug.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1012078: groff-base: eqn breaks tbl spacing/layout with inline equations, but not in T{ T}; nroff only?

[Colin Watson]

On Tue, Oct 04, 2022 at 07:30:58AM -0500, G. Branden Robinson wrote:
> At 2022-10-04T11:55:41+0100, Colin Watson wrote:
> > This is because the preprocessor line at the top of the page is:
> > 
> >   '\" et
> 
> Ah, you're trusting man page authors.  A dangerous practice... ;-)
> 
> > man(1) deals with these in the order given.
> 
> Nothing I've learned about the troff ecosystem suggests to me that this
> is a good approach.

Yeah, just to be clear, I'm not saying this is desirable, just how it
currently is.  To tell you the truth I hadn't previously looked at that
aspect of the code in detail.  I'm sure I can fix it - just wanted to
check on the best approach.

> > Should I have man(1) rearrange things into a canonical order?
> 
> You could, but I am wondering why you manage the pipeline yourself
> instead of handing off to groff(1) (with appropriate options) when it is
> the formatter.  For consistency when the formatter isn't groff?

Exactly that, I think.  It's simpler to have the same code paths
involved either way.

> > If so, I guess I should rearrange everything rather than just tbl(1)
> > and eqn(1), to match what groff(1) does?
> 
> There is the problem that you support vgrind, and groff doesn't know
> anything about that program.  I've never even used it myself so I don't
> know where in the sequence it should go.

I think I may have added it in a fit of youthful enthusiasm rather than
out of practical need, but it's there now.  I expect I can figure
something out.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1020244: fonts-urw-base35: A monospaced font shouldn't have ligatures

[fabian]

Hi Markus,

Am 03.10.2022 23:43, schrieb Markus Hitter:

That's an odd reasoning. So you want to keep the bug, because removing
it would solve the problem not only for one, but for many applications
and thousands of users? For me, such a huge impact would encourage me
even more (and was actually the reason why I filed a bug at all and
spent 3 days to find not only a simple works-for-me fix, but the best
possible solution I could find).


of course I don't *want* to keep the bug open. It's just that I won't 
apply a "Debian only" solution.


I won't package a different font than the one that Ghostscript uses.

This isn't just merely a bug fix in a program. As you stated yourself, 
the sheer impact of this change is massive, as it affects how certain 
documents are rendered. This needs a coordinated approach and you have 
already done the best that could be done by posting a detailed solution 
to the upstream bug tracker. Let's just hope it gets picked up, either 
by URW++ themselves or by Artifex at least.


Thanks,

 - Fabian

Bug#1021002: ftp.halifax.rwth-aachen: intermittent dns failures

[Carsten Otto]

On Tue, Oct 04, 2022 at 02:53:58PM +0200, Julien Cristau wrote:
> These aren't the IP addresses of the debian.org name servers, they
> serve the www.debian.org zone only.

Ah, OK. Then I'll wait for further information from your side.
-- 
Dr. Carsten Otto
http://verify.rwth-aachen.de/otto/


signature.asc
Description: PGP signature

Bug#1012078: groff-base: eqn breaks tbl spacing/layout with inline equations, but not in T{ T}; nroff only?

[наб]

Hi!

I can't really squeeze out enough time or focus to really read through
this thread fully, but I think my opinion as a Stupid User may influence
this in the right direction here.

On Tue, Oct 04, 2022 at 11:55:41AM +0100, Colin Watson wrote:
> On Mon, Oct 03, 2022 at 10:36:32PM -0500, G. Branden Robinson wrote:
> > The problem is therefore that man(1) is running the preprocessors in the
> > wrong order.  This can be solved by pipelining eqn(1) before tbl(1), or
> > passing the "-e" and "-t" flags to groff and letting it sort them out.
> 
> This is because the preprocessor line at the top of the page is:
> 
>   '\" et
> 
> man(1) deals with these in the order given.

I would /never/ have guessed that.

Bullseye man(1) (groff-base 1.22.4-6) says:
-- >8 --
To contain a valid preprocessor string, the first line must resemble
   '\" 
where string can be any combination of letters described by option -p below.

If none of the above methods provide any filter information, a default set is 
used.
-- >8 --

Nothing suggests this would have any bearing on the order ‒
these appear to function just like flags.

> Should I have man(1) rearrange things into a canonical order?  If so, I
> guess I should rearrange everything rather than just tbl(1) and eqn(1),
> to match what groff(1) does?

tbl(1) says:
-- >8 --
INTERACTION WITH EQN
   tbl(1) should always be called before eqn(1) (groff(1) automatically 
takes care of the correct order of preprocessors).
-- >8 --

All signs (to me, noted dumbass; grain-of-salt) point to
"just put the groff preprocessor-enabling flags you need here".
It's not an outlandish assumption that they'd function the same?
Or that if they didn't, and running the preprocessors out of order is
known to break stuff, there would be a note of this?
So idk, I did assume they functioned the same because nothing I saw
says they wouldn't?

So I think that'd be nice, yeah.

As a point of reference, DCS has 454 pages
(all of which manpages-l10n) of '\" et:
  https://codesearch.debian.net/search?q=%27%5C%22+et=1
and the same of ^'\\".*e.*t
(with a lot of normal text-comment false-positives):
  https://codesearch.debian.net/search?q=%5E%27%5C%5C%22.*e.*t=0

> -- 
> Colin Watson (he/him)  [cjwat...@debian.org]

Best,
наб


signature.asc
Description: PGP signature

Bug#1021259: ifupdown: The if-down / if-up script resolved is not executable, thus it is skipped by run-parts

[Vincent Lefevre]

Package: ifupdown
Version: 0.8.38
Severity: normal

The if-down / if-up script resolved is not executable:

-rw-r--r-- 1 root root  759 2022-09-27 15:09:29 /etc/network/if-down.d/resolved
-rw-r--r-- 1 root root 4663 2022-09-27 15:09:29 /etc/network/if-up.d/resolved

Thus it is skipped by run-parts.

-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

--- /etc/network/interfaces.d/*:
cat: '/etc/network/interfaces.d/*': No such file or directory

--- up and down scripts installed:
/etc/network/if-down.d:
total 4
-rw-r--r-- 1 root root 759 2022-09-27 15:09:29 resolved
lrwxrwxrwx 1 root root  32 2022-05-15 12:22:46 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 0
lrwxrwxrwx 1 root root 32 2022-05-15 12:22:46 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 4
-rwxr-xr-x 1 root root 344 2014-09-22 01:13:29 ethtool
lrwxrwxrwx 1 root root  32 2022-05-15 12:22:46 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 20
-rwxr-xr-x 1 root root 1685 2014-09-22 01:22:24 ethtool
-rwxr-xr-x 1 root root 4938 2020-08-14 01:44:47 mountnfs
-rw-r--r-- 1 root root 4663 2022-09-27 15:09:29 resolved
lrwxrwxrwx 1 root root   32 2022-05-15 12:22:46 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ifupdown depends on:
ii  adduser   3.129
ii  iproute2  5.19.0-1
ii  libc6 2.35-1

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.3-2

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- Configuration Files:
/etc/default/networking changed [not included]

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993806: Fwd: Bug#993806: kodi: No audio on DVD playback, AC3 Support

[Vasyl Gello]

Dear colleagues,

I have a monthly break in the travels and I am going to package Alpha3/4 and 
sort the issues spotted by all of you.
Please prepare your 19.4 profile backups before testing 20. There will be 
probably several rounds of unofficial builds
signed with my GPG key that will be replaced by official upload once the bugs 
are fixed.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1021201: vulkan-loader: new upstream stable point release 1.3.224.1

[Timo Aaltonen]

Simon McVittie kirjoitti 3.10.2022 klo 18.43:

Source: vulkan-loader
Version: 1.3.224.0-1
Severity: wishlist

vulkan-loader is currently at upstream version 1.3.224.0, but upstream's
sdk-1.3.224 stable branch now has a 1.3.224.1 point release with these
release notes:


Enable layer interception of unknown functions

Re-add previously reverted behavior that allows layers to setup
dispatch chains for unknown physical device and device functions during
vkCreateInstance. Previously, functions not known to the loader could
not be queried by a layer during vkCreateInstance (when dispatch tables
should be setup). The change adds support for unknown functions in the
trampolines of vkGetInstanceProcAddr and vkGetPhysicalDeviceProcAddr.


If I'm reading correctly, this is a backport of part of
https://github.com/KhronosGroup/Vulkan-Loader/pull/999,
which seems to be a fix for bugs seen with the RenderDoc and
GFXReconstruct development tools.

 smcv



Only vulkan-validationlayers had actual changes in .1, -loader is 
unchanged. Is this what you're after?


git log1 sdk-1.3.224.0..sdk-1.3.224.1
2995230d4eb3aff (tag: sdk-1.3.224.1) tests: Add tests for VK_REMAINING_*
e78782f28adde30 layers: Fix VK_REMAINING_* on Z-Cull tracking
05199e2928e7c4b tests: Add test in OneTimeSubmit
4a8a6a14be9971c layers: Fix one-time-submit


--
t

Bug#1021258: gtksourceview5: FTBFS on riscv64 and hppa (test failure)

[Eric Long]

Source: gtksourceview5
Version: 5.6.0-1
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainers,

gtksourceview5 failed to build on riscv64 and hppa platforms due to test failure
in `test-regex`:

```
=== 12/26 
test: test-regex
start time:   22:18:43
duration: 1.75s
result:   killed by signal 6 SIGABRT
command:  G_TEST_BUILDDIR=/<>/obj-riscv64-linux-gnu/testsuite 
G_DEBUG=gc-friendly GSETTINGS_BACKEND=memory 
G_TEST_SRCDIR=/<>/testsuite MALLOC_PERTURB_=79 MALLOC_CHECK_=2 
/<>/obj-riscv64-linux-gnu/testsuite/test-regex
--- stdout ---
# random seed: R02S5fe677acf2b7253d812a2f17f9a5fade
1..3
# Start of Regex tests
ok 1 /Regex/slash-c
# GLib-DEBUG: JIT compilation was requested with G_REGEX_OPTIMIZE, but JIT 
support is not available. Falling back to interpretive code.
# ...
Bail out! 
GtkSourceView:ERROR:../testsuite/test-regex.c:135:compare_impl_regex_to_g_regex:
 assertion failed (r1 == r2): (0 == 1)
--- stderr ---
**
GtkSourceView:ERROR:../testsuite/test-regex.c:135:compare_impl_regex_to_g_regex:
 assertion failed (r1 == r2): (0 == 1)
==
```

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=gtksourceview5=riscv64=5.6.0-1=1663798763=0

It turns out a certain set of test parameter is problematic, according to GDB 
on my riscv64 QEMU machine:

```
Thread 1 "test-regex" hit Breakpoint 1, compare_impl_regex_to_g_regex 
(subject=subject@entry=0xab0c10 "\342\200\223aa", 
pattern=pattern@entry=0xab0c00 "\\baa\\b", 
match_flags=G_REGEX_MATCH_NOTEMPTY, compile_flags=8195) at 
../testsuite/test-regex.c:135
135 in ../testsuite/test-regex.c
1: subject = 0xab0c10 "\342\200\223aa"
2: pattern = 0xab0c00 "\\baa\\b"
**
GtkSourceView:ERROR:../testsuite/test-regex.c:135:compare_impl_regex_to_g_regex:
 assertion failed (r1 == r2): (0 == 1)
Bail out! 
GtkSourceView:ERROR:../testsuite/test-regex.c:135:compare_impl_regex_to_g_regex:
 assertion failed (r1 == r2): (0 == 1)

Thread 1 "test-regex" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:43
```

Attached is a patch that disables that line of test on riscv64 only, since I
haven't tested it on hppa yet. If there is a better way than disabling tests,
please let me know so I can help.

Cheers,
Eric
--- a/testsuite/test-regex.c
+++ b/testsuite/test-regex.c
@@ -195,7 +195,9 @@
   compare_impl_regex_to_g_regex ("hello\nworld\n", "(.*\\n)*", compile, match);
 
   compare_impl_regex_to_g_regex ("", "\\baa\\b", compile, match);
+#if !defined(__riscv)
   compare_impl_regex_to_g_regex ("\342\200\223aa", "\\baa\\b", compile, match);
+#endif
 
   compare_impl_regex_to_g_regex ("12\n", "(?<=1)23", compile, match);
   compare_impl_regex_to_g_regex ("\n23\n", "(?<=1)23", compile, match);

Bug#1021002: ftp.halifax.rwth-aachen: intermittent dns failures

[Julien Cristau]

Hi Carsten,

On Tue, Oct  4, 2022 at 13:06:27 +0200, Carsten Otto wrote:

> Dear all,
> 
> On Fri, Sep 30, 2022 at 06:49:48PM +0200, Carsten Otto wrote:
> > I escalated this to the university staff managing DNS for
> > rwth-aachen.de.
> 
> Bernd Kohler of RWTH Aachen university investigated and found something
> interesting.
> 
> The CNAME ftp2.de.debian.org -> ftp.halifax.rwth-aachen.de resolves for
> public DNS servers like 8.8.8.8, but it does not resolve for those used
> by Debian.
> 
> date -R; for i in "82.195.75.105" "2001:41b8:202:deb:1a1a:0:52c3:4b69" 
> "209.87.16.31" "2607:f8f0:614:1::1274:31" "194.177.211.201" 
> "2001:648:2ffc:deb::211:201"; do for j in "a" ""; do dig +noall +answer 
> @${i} ftp2.de.debian.org ${j}; done; echo -e "\n###\n"; 
> done
> 
> Maybe this is related to the issues you are seeing?
> 
These aren't the IP addresses of the debian.org name servers, they serve
the www.debian.org zone only.

Cheers,
Julien

Bug#1021257: imagemagick-6.q16: import renders X unresponsive

[Cédric Hannotier]

Package: imagemagick-6.q16
Version: 8:6.9.11.60+dfsg-1.3+b3
Severity: important

Dear Maintainer,

Using import (symlink to import-im6.q16) freezes the whole X session.
Only exit door is to go to another tty and kill the process.

Steps:
$ import my_file_name

-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
compare:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
convert:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
composite:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
conjure:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
display:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
identify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
import:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
mogrify:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
montage:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
stream:  ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.17-2
ii  libc6  2.35-1
ii  libmagickcore-6.q16-6  8:6.9.11.60+dfsg-1.3+b3
ii  libmagickwand-6.q16-6  8:6.9.11.60+dfsg-1.3+b3

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.56.1~dfsg-1
pn  libmagickcore-6.q16-6-extra  
ii  netpbm   2:10.97.00-2

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace
ii  cups-bsd [lpr]   2.4.2-1+b1
ii  curl 7.85.0-1
pn  enscript 
ii  ffmpeg   7:5.1.2-1
ii  fig2dev [transfig]   1:3.2.8b-3
ii  gimp 2.10.32-1+b1
pn  gnuplot  
pn  grads
ii  graphviz 2.42.2-7
ii  groff-base   1.22.4-8
pn  hp2xx
pn  html2ps  
pn  imagemagick-doc  
ii  libwmf-bin   0.2.12-5
pn  mplayer  
pn  povray   
pn  radiance 
ii  sane-utils   1.1.1-5
ii  texlive-binaries [texlive-base-bin]  2022.20220321.62855-4
pn  ufraw-batch  
ii  xdg-utils1.1.3-4.1

-- no debconf information

-- 

Cédric Hannotier

Bug#1019974: uim: diff for NMU version 1:1.8.8-9.2

[Adrian Bunk]

Dear maintainer,

I've prepared an NMU for uim (versioned as 1:1.8.8-9.2) and uploaded
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru uim-1.8.8/debian/changelog uim-1.8.8/debian/changelog
--- uim-1.8.8/debian/changelog	2022-06-26 17:40:31.0 +0300
+++ uim-1.8.8/debian/changelog	2022-10-04 15:38:11.0 +0300
@@ -1,3 +1,10 @@
+uim (1:1.8.8-9.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with -O1 to workaround #1019974.
+
+ -- Adrian Bunk   Tue, 04 Oct 2022 15:38:11 +0300
+
 uim (1:1.8.8-9.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru uim-1.8.8/debian/rules uim-1.8.8/debian/rules
--- uim-1.8.8/debian/rules	2021-07-24 13:06:11.0 +0300
+++ uim-1.8.8/debian/rules	2022-10-04 15:38:07.0 +0300
@@ -8,6 +8,9 @@
 
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
+# workaround for #1019974
+export DEB_CFLAGS_MAINT_APPEND += -O1
+
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 

Bug#1021245: linux-image-5.10.0-18-rt-amd64: can't access EFIVARS when using rt version of kernel

[Bastian Blank]

On Tue, Oct 04, 2022 at 11:46:39AM +0200, niek nooijens wrote:
> when Using the normal linux-image 5.10.0-18 I can use efibootmgr to change 
> boot variables and /sys/firmware/efi/efivars is populated.
> when using the real-time variant efibootmgr and efivar report "efi variables 
> are not supported on this system" and /sys/firmware/efi/efivars is empty.
> trying to insert the /lib/modules/kernel/fs/efivarfs/efivarfs.ko kernel 
> module will result in a FAIL "no such file or directory" as well as modprobe.
> I therefore conclude this is a bug, and problematic since I need to load 
> signed kernel-modules for our industrial etherCAT stack and really need the 
> whole EFI/secure-boot/mok chain to work on the rt_kernel.

This is no bug.  The EFI runtime services are explicitly disabled.  The
reason is:

| The EFI runtime services are disabled by default when PREEMPT_RT is enabled,
| because measurements have shown that some EFI functions calls might take too
| much time to complete, causing large latencies which is an issue for Real-Time
| kernels.

You can enable it by adding "efi=runtime" to the kernel command line.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3

Bug#1019974: uim: FTBFS on armhf: [Makefile:871: installed-modules.scm] Segmentation fault

[Adrian Bunk]

On Tue, Oct 04, 2022 at 11:28:27AM +0300, Dmitry Shachnev wrote:
> Hi Adrian!
> 
> On Mon, Oct 03, 2022 at 07:48:08PM +0300, Adrian Bunk wrote:
> > The workaround below fixes the build.
> >
> > I looked through the backtrace in gdb, but debugging a Scheme 
> > interpreter is outside of what I am feeling comfortable doing.
> 
> Thank you for the patch. Can you go ahead and upload it as NMU?
> 
> If you do it, I will withdraw my RM request (#1021102).
> 
> And I would also include arm64 to the list because currently uim
> segfaults during installation there:
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/u/uim/26665072/log.gz
> 
>   Setting up uim (1:1.8.8-9.1+b1) ...
>   Segmentation fault
>   dpkg: error processing package uim (--configure):
>installed uim package post-installation script subprocess returned error 
> exit status 139

I cannot reproduce this, but I can NMU to build with -O1 everywhere.

> Dmitry Shachnev

cu
Adrian

Bug#913985: thunar: Thunar do not open as root

[Akbarkhon Variskhanov]

Control: tags -1 moreinfo unreproducible

On Sat, 17 Nov 2018 19:47:03 -0500 Awtul  wrote:
> I have inserted 'false' instead of 'true' in  
> '/usr/share/polkit-1/actions/org.xfce.thunar.policy'
>
> ( false )
>
> but thunar still won't open as root via 'pkexec'.

As long as the value of this key is nonempty, the application is
allowed access to DISPLAY and XAUTHORITY environment variables (even
if it's set to false, 0 or the likes). When it's empty, `pkexec` will
still offer a dialog and proceed as usual, but the calling program
(Thunar, in our case) won't be able to start due to not having access
to those two environment variables. The diagnostic message will look
like this:

> thunar: Failed to initialize Xfconf: Cannot autolaunch D-Bus without X11 
> $DISPLAY

"Won't open" doesn't say much. Do you have the root account set up?
Does `pkexec` have the setuid set: check with `stat -c %A
/usr/bin/pkexec`? Does it show the dialog at least? Can you enter the
password? Can you run non-GUI or other apps with pkexec? Have you
modified the policy file? You may try `apt reinstall thunar`. This
will return your local modifications to defaults.

The policy was added 7 years ago and hasn't been changed since.

Tagging as unreproducible for now.

Bug#1020779: slic3r-prusa: FTBFS on 32-bit arches

[Chow Loong Jin]

reassign 1020779 libcereal-dev 1.3.2+dfsg-2
thanks

From the build log in [1], it looks like the build error is:

CMake Warning at cmake/modules/Findcereal.cmake:6 (find_package):
  Could not find a configuration file for package "cereal" that is compatible
  with requested version "".

  The following configuration files were considered but not accepted:

/usr/share/cmake/cereal/cerealConfig.cmake, version: 1.3.2 (64bit)

Call Stack (most recent call first):
  CMakeLists.txt:448 (find_package)

I think this is because
/usr/share/cmake/cereal/cerealConfigVersion.cmake is not actually
architecture-dependent despite being shipped in an arch:all package 
(libcereal-dev).

[1] 
https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=i386=2.5.0%2Bdfsg-1=1663915166=0

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#1021256: gtkmm4: autopkgtest failure: Failed to locate “gtk-logo.webm” in any source directory

[Adrian Bunk]

Source: gtkmm4.0
Version: 4.8.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gtkmm4.0/26657367/log.gz

...
autopkgtest [03:40:13]: test build: [---
+ mktemp -d
+ WORKDIR=/tmp/tmp.aaoH7slRso
+ trap rm -rf /tmp/tmp.aaoH7slRso 0 INT QUIT ABRT PIPE TERM
+ mkdir /tmp/tmp.aaoH7slRso/gtk-demo
+ cp demos/gtk-demo/demowindow.cc demos/gtk-demo/example_appwindow.cc 
demos/gtk-demo/example_builder.cc demos/gtk-demo/example_colorsel.cc 
demos/gtk-demo/example_dialog.cc demos/gtk-demo/example_drawingarea.cc 
demos/gtk-demo/example_dropdown.cc demos/gtk-demo/example_flowbox.cc 
demos/gtk-demo/example_gestures.cc demos/gtk-demo/example_glarea.cc 
demos/gtk-demo/example_headerbar.cc demos/gtk-demo/example_iconbrowser.cc 
demos/gtk-demo/example_iconview.cc demos/gtk-demo/example_images.cc 
demos/gtk-demo/example_listview_applauncher.cc 
demos/gtk-demo/example_listview_columnview.cc demos/gtk-demo/example_overlay.cc 
demos/gtk-demo/example_panes.cc demos/gtk-demo/example_pixbufs.cc 
demos/gtk-demo/example_shortcuts.cc demos/gtk-demo/example_sizegroup.cc 
demos/gtk-demo/example_stack.cc demos/gtk-demo/example_stacksidebar.cc 
demos/gtk-demo/example_textview.cc 
demos/gtk-demo/example_treeview_editable_cells.cc 
demos/gtk-demo/example_treeview_liststore.cc 
demos/gtk-demo/example_treeview_treestore.cc demos/gtk-demo/main.cc 
demos/gtk-demo/textwidget.cc /tmp/tmp.aaoH7slRso/gtk-demo
+ cp demos/gtk-demo/floppybuddy.gif demos/gtk-demo/gtk-logo-rgb.gif 
/tmp/tmp.aaoH7slRso/gtk-demo
+ cp demos/gtk-demo/glarea-gl.fs.glsl demos/gtk-demo/glarea-gl.vs.glsl 
demos/gtk-demo/glarea-gles.fs.glsl demos/gtk-demo/glarea-gles.vs.glsl 
/tmp/tmp.aaoH7slRso/gtk-demo
+ cp demos/gtk-demo/demos.h demos/gtk-demo/demowindow.h 
demos/gtk-demo/textwidget.h /tmp/tmp.aaoH7slRso/gtk-demo
+ cp demos/gtk-demo/background.jpg /tmp/tmp.aaoH7slRso/gtk-demo
+ cp demos/gtk-demo/alphatest.png demos/gtk-demo/apple-red.png 
demos/gtk-demo/gnome-applets.png demos/gtk-demo/gnome-calendar.png 
demos/gtk-demo/gnome-foot.png demos/gtk-demo/gnome-fs-directory.png 
demos/gtk-demo/gnome-fs-regular.png demos/gtk-demo/gnome-gimp.png 
demos/gtk-demo/gnome-gmush.png demos/gtk-demo/gnome-gsame.png 
demos/gtk-demo/gnu-keys.png /tmp/tmp.aaoH7slRso/gtk-demo
+ cp demos/gtk-demo/example_builder.ui demos/gtk-demo/example_shortcuts.ui 
demos/gtk-demo/example_shortcuts_boxes.ui 
demos/gtk-demo/example_shortcuts_builder.ui 
demos/gtk-demo/example_shortcuts_clocks.ui 
demos/gtk-demo/example_shortcuts_gedit.ui /tmp/tmp.aaoH7slRso/gtk-demo
+ cp demos/gtk-demo/demo.gresource.xml /tmp/tmp.aaoH7slRso/gtk-demo
+ cd /tmp/tmp.aaoH7slRso
+ cat
+ gtk_demo_deps=gtkmm-3.0 epoxy
+ gtktest_deps=gtkmm-3.0
+ glib-compile-resources --target=gtk-demo/demo_resources.c 
--sourcedir=gtk-demo --generate-source gtk-demo/demo.gresource.xml
gtk-demo/demo.gresource.xml: Failed to locate “gtk-logo.webm” in any source 
directory.
+ rm -rf /tmp/tmp.aaoH7slRso
autopkgtest [03:40:14]: test build: ---]
autopkgtest [03:40:14]: test build:  - - - - - - - - - - results - - - - - - - 
- - -
buildFAIL non-zero exit status 1
...

Bug#903999: ITP: php-doc -- Documentation for PHP

[Athos Ribeiro]

On Wed, Sep 28, 2022 at 08:11:14AM +0800, Paul Wise wrote:

On Mon, 2022-09-26 at 16:23 -0300, Athos Ribeiro wrote:


As mentioned in the original report (RFP), this package was
originally removed from the archive due to Bug #821695, when it was
not updated during the PHP 7 transition.


If you weren't already aware, please note the extra steps needed when
reintroducing packages that were removed from Debian (e.g. bug reopen):

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs


Hi Paul, Thanks for the pointers.

While I am working on packaging details, I still want to make sure it is
OK to re-introduce the package due to the PHP-3.0 issues I pointed
before.

On top of that, I needed to change one of the build time internal
dependencies so we wouldn't end up with (hundreds of) broken links. This
led to the need of clarification on
https://github.com/php/web-php/issues/711 by the upstream project.
If the stylesheets provided are indeed proprietary, I will need to write
our own.

Finally, I did go through the bugs closed with +rm, and am commenting on
each of them here to ensure we have notes for when we un-archive them.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821695
  This one is regarding the PHP 7 transition. It was the reason the
  package was removed and it is fixed in the new proposed package.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737713
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766882
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734145
  These are all regarding broken links and missing files. They are fixed
  in the new proposed package and I also added an autopkgtest to ensure
  there will be no regressions here.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766816
  This is a request to add additional links for aliases.  It is still
  valid and should be dealt with upstream.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606081
  This is a request to improve an specific function behavior
  documentation. I will probably forward this upstream to be handled
  there.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288744
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348512
  These are requests to package different language translations.
  Unfortunatelly, most PHP translations are far from complete and I am
  not sure they'd be ready for packaging, with exception of one
  language. I could package that one __if__ there is interest for that
  in the long run. Otherwise, we should keep these open until the docs
  get more translated contents.



--
bye,
pabs

https://wiki.debian.org/PaulWise


--
Athos Ribeiro

Bug#1021252: RM: spirv-llvm-translator-11 -- ROM; NPOASR; no longer used; targets obsolete llvm version

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal
Control: clone -1 -2 -3 -4
Control: retitle -2 spirv-llvm-translator-12 -- ROM; NPOASR; no longer used; 
targets obsolete llvm version
Control: retitle -3 opencl-clang-11 -- ROM; NPOASR; no longer used; targets 
obsolete llvm version
Control: retitle -4 opencl-clang-12 -- ROM; NPOASR; no longer used; targets 
obsolete llvm version

Please remove some obsolete versions of spirv-llvm-translator and
opencl-clang from the archive. They are no longer needed for the current
versions of intel-graphics-compiler/intel-compute-runtime. Removing them
also reduces the number of packages blocking removal of llvm-11/llvm-12.

Andreas

Bug#1021251: SuicidalProcess unit test causes build failures

[Guido Berhoerster]

Package: libqtdbustest
Version: 0.2+bzr42+repack1-13

Currently, TestSuicidalProcess checks whether the launched process

has the correct arguments and is still alive via ps, the value of

argv[0] depends on how the process is exec'd which is an

implementation detail and the used ps arguments as well as the

resulting output are non-portable. This leads to build failures,

thus the test should be disabled until it gets reimplemented

upstream by the UBports project.


Attached patch should replace the existing patch
1001_use-full-path-when-executing-sleep.patch.
--
Guido BerhoersterDescription: Disable SuicidalProcess unit test
Author: Guido Berhoerster 
Abstract:
 The test checks whether the process has the correct arguments and is still
 alive via ps, the value of argv[0] depends on how the process is exec'd which
 is an implementation detail and the used ps arguments as well as the resulting
 output are non-portable. This leads to build failures, disable the test until
 it gets reimplemented upstream by the UBports project.
--- libqtdbustest-0.2+bzr42.orig/tests/libqtdbustest/TestSuicidalProcess.cpp
+++ libqtdbustest-0.2+bzr42/tests/libqtdbustest/TestSuicidalProcess.cpp
@@ -27,13 +27,13 @@ using namespace QtDBusTest;
 
 namespace {
 
-class TestSuicidalProcess: public Test {
+class DISABLED_TestSuicidalProcess: public Test {
 protected:
-	TestSuicidalProcess() {
+	DISABLED_TestSuicidalProcess() {
 		process.setWatchdogCommand(TEST_QTDBUSTEST_WATCHDOG_BIN);
 	}
 
-	virtual ~TestSuicidalProcess() {
+	virtual ~DISABLED_TestSuicidalProcess() {
 		process.kill();
 		process.waitForFinished();
 	}
@@ -41,7 +41,7 @@ protected:
 	SuicidalProcess process;
 };
 
-TEST_F(TestSuicidalProcess, BehavesLikeNormalQProcess) {
+TEST_F(DISABLED_TestSuicidalProcess, BehavesLikeNormalQProcess) {
 	process.start("sleep", QStringList() << "5");
 
 	QProcess pgrep;

Bug#999923: Porting XML Copy Editor to PCRE2

[Zane Ji]

Hi Miry,

After your patch is applied, I just set matchArray to
pcre2_get_ovector_pointer(patternMatchData) each time when pcre2_match is
called, then regex searching/replacing works.

The source code has been updated:
https://sourceforge.net/p/xml-copy-editor/code/ci/3d17bca4196670183ad45c0af369acf4acdc7d7e/

Regards,
Zane
diff --git a/configure.ac b/configure.ac
index d0ab3af..1c1f0dd 100755
--- a/configure.ac
+++ b/configure.ac
@@ -72,8 +72,7 @@ AC_ARG_ENABLE(debug,
 ])
 
 # Check pcre is available
-AC_CHECK_HEADER(pcre.h, ,
-	AC_MSG_ERROR([PCRE headers not found]))
+PKG_CHECK_MODULES([PCRE2], [libpcre2-8])
 
 # Check boost::shared_ptr is available
 AC_LANG(C++)
diff --git a/src/Makefile.am b/src/Makefile.am
index 7b0c81c..15bf572 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -83,7 +83,8 @@ xmlcopyeditor_LDADD = $(WX_LIBS) \
 	$(ENCHANT_LIBS) \
 	$(GTK_LIBS) \
 	$(XSLT_LIBS) \
-	-lexpat -lpcre -lxerces-c
+	$(PCRE2_LIBS) \
+	-lexpat -lxerces-c
 
 nobase_dist_xmlcopyeditor_DATA = $(srcdir)/catalog/catalog \
 	$(srcdir)/dtd/*.* \
@@ -133,5 +134,5 @@ EXTRA_DIST = \
 	$(srcdir)/xmlcopyeditor.rc \
 	$(srcdir)/xmlschemaparser.cpp
 
-AM_CPPFLAGS = $(XML2_CFLAGS) $(ENCHANT_CFLAGS) $(GTK_CFLAGS)
+AM_CPPFLAGS = $(XML2_CFLAGS) $(ENCHANT_CFLAGS) $(GTK_CFLAGS) $(PCRE2_CFLAGS)
 
diff --git a/src/rule.cpp b/src/rule.cpp
index 487a364..37bfe3c 100644
--- a/src/rule.cpp
+++ b/src/rule.cpp
@@ -26,12 +26,11 @@ using namespace std;
 Rule::Rule (
 const string& pattern,
 bool matchCase,
-const string& replace,
-const int arrayLength ) : WrapRegex (
+const string& replace
+	) : WrapRegex (
 		pattern,
 		matchCase,
-		replace,
-		arrayLength )
+		replace )
 {
 	adjustCaseAttribute = tentativeAttribute = false;
 }
diff --git a/src/rule.h b/src/rule.h
index a89289e..1abfbab 100644
--- a/src/rule.h
+++ b/src/rule.h
@@ -32,8 +32,7 @@ class Rule : public WrapRegex
 		Rule (
 		const string& pattern,
 		bool matchCase,
-		const string& replace = "",
-		const int arrayLength = 60 );
+		const string& replace = "");
 		bool getAdjustCaseAttribute();
 		bool getTentativeAttribute();
 		string getReport();
diff --git a/src/wrapregex.cpp b/src/wrapregex.cpp
index ff8d622..99d2a7c 100644
--- a/src/wrapregex.cpp
+++ b/src/wrapregex.cpp
@@ -31,40 +31,39 @@ using namespace std;
 WrapRegex::WrapRegex (
 const string& pattern,
 bool matchCase,
-const string& replaceParameter,
-const int arrayLengthParameter ) :
+const string& replaceParameter ) :
 		replace ( replaceParameter ),
-		arrayLength ( arrayLengthParameter ),
 		returnValue ( 0 )
 {
 	if ( pattern.empty() || pattern == ".*" )
 	{
 		disabled = true;
-		matchArray = NULL;
-		patternStructure = NULL;
-		patternExtraStructure = NULL;
+		patternCode = NULL;
+		patternMatchData = NULL;
+		patternMatchContext = NULL;
 		return;
 	}
 	disabled = false;
 
-	matchArray = new int[arrayLength];
-
 	// compile
-	int optionsFlag = ( matchCase ) ? PCRE_UTF8 : PCRE_CASELESS | PCRE_UTF8;
-	const char *errorPointer;
-	int errorOffset;
-
-	if ( ( patternStructure = pcre_compile (
-	  pattern.c_str(),
-	  optionsFlag,
-	  ,
-	  ,
-	  NULL ) ) == NULL )
+	uint32_t optionsFlag = ( matchCase ? 0 : PCRE2_CASELESS ) | PCRE2_UTF | PCRE2_NO_UTF_CHECK;
+	int errorCode;
+	PCRE2_SIZE errorOffset;
+
+	if ( ( patternCode = pcre2_compile (
+		(PCRE2_SPTR)pattern.c_str(), // pattern
+		PCRE2_ZERO_TERMINATED, // pattern is zero-terminated
+		optionsFlag, // options
+		, // error number
+		, // error offset
+		NULL ) ) == NULL ) // default compile context
 	{
-		throw runtime_error ( errorPointer );
+		char buf[256];
+		pcre2_get_error_message ( errorCode, (PCRE2_UCHAR *)buf, sizeof(buf) );
+		throw runtime_error ( string(buf) );
 	}
-
-	patternExtraStructure = pcre_study ( patternStructure, 0,  );
+	patternMatchData = pcre2_match_data_create_from_pattern ( patternCode, NULL );
+	patternMatchContext = pcre2_match_context_create ( NULL );
 }
 
 WrapRegex::~WrapRegex()
@@ -72,9 +71,9 @@ WrapRegex::~WrapRegex()
 	if ( disabled )
 		return;
 
-	pcre_free ( patternStructure );
-	pcre_free ( patternExtraStructure );
-	delete[] matchArray;
+	pcre2_match_data_free ( patternMatchData );
+	pcre2_code_free ( patternCode );
+	pcre2_match_context_free ( patternMatchContext );
 }
 
 int WrapRegex::matchPatternGlobal (
@@ -108,18 +107,18 @@ string WrapRegex::replaceGlobal (
 	string output, match;
 
 	output.reserve ( buffer.size() );
-	while ( ( returnValue = pcre_exec (
-	patternStructure,
-	patternExtraStructure,
-	s,
-	strlen ( s ),
-	0,
-	0,
-	matchArray,
-