Bug#1023585: Request a mailing list for new architecture "loongarch64" (LoongArch 64 bits little-endian)

[张丹丹]

Package: lists.debian.org
Severity: wishlist
User: debian-de...@lists.debian.org
Usertags: loongarch64


Hi,
   The LoongArch architecture is an Instruction Set Architecture (ISA) that has 
Reduced Instruction Set Computer (RISC) style. Loongarch64 is LoongArch 64 bits 
little-endian. 
   Loong64 (abbreviation of loongarch64) is dpkg architecture, based on Debian 
community recommendations.
   We need to apply for a mailing list for the loongarch architecture to 
communicate and archive userstags bugs.

The following information is required:
-Name
debian-loongarch

-Short description
Discussion on the LoongArch port(s) for Debian GNU/Linux.

-Long description
Discussions on the LoongArch port(s) for Debian GNU/Linux.
For more information see: https://wiki.debian.org/LoongArch

-Subscription Policy:
open

-Post Policy
open

-Web Archive
yes

Related Information:
IRC channel is #debian-loongarch,which is been used for communication.

- Please tell me if I've missed something.


Dandan Zhang

Bug#1016903:

[Mathieu Malaterre]

Control: found 1016903 12.2.0-9

See i386:
* 
https://buildd.debian.org/status/fetch.php?pkg=highway=i386=1.0.3%7Egit20221102.4899d11-2=1667806545=0

Bug#1023584: gnome-shell-extension-no-annoyance: please package v2 of this extension

[Andres Salomon]

Package: gnome-shell-extension-no-annoyance
Version: 0+20170928-f21d09a-2
Severity: wishlist

Hi,

Someone forked this extension and is maintaining it as noannoyance v2:

https://extensions.gnome.org/extension/2182/noannoyance/

https://github.com/bdaase/noannoyance

I'd be happy to help with packaging if you're tight on time. If, for 
some reason you think it's better off as a separate package, let me 
know and I'll open an ITP instead.


Thanks,
Andres

Bug#1023583: jove FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: jove
Version: 4.17.4.4-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

jove fails to cross build from source, because it uses the build
architecture compiler. During dh_auto_build, which is passed all the
right tools, does not actually build jove. This only happens during
dh_auto_instal, which lacks the tools. I'm attaching a patch to build
jove during dh_auto_install for your convenience.

Helmut
diff --minimal -Nru jove-4.17.4.4/debian/changelog 
jove-4.17.4.4/debian/changelog
--- jove-4.17.4.4/debian/changelog  2022-06-11 14:28:18.0 +0200
+++ jove-4.17.4.4/debian/changelog  2022-11-06 19:54:34.0 +0100
@@ -1,3 +1,11 @@
+jove (4.17.4.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Do not build jove during dh_auto_install without cross
+tools. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 06 Nov 2022 19:54:34 +0100
+
 jove (4.17.4.4-1) unstable; urgency=low
 
   * New upstream release.
diff --minimal -Nru jove-4.17.4.4/debian/rules jove-4.17.4.4/debian/rules
--- jove-4.17.4.4/debian/rules  2022-06-11 14:28:18.0 +0200
+++ jove-4.17.4.4/debian/rules  2022-11-06 19:54:33.0 +0100
@@ -19,7 +19,7 @@
LDFLAGS="$(LDFLAGS)" \
JOVEHOME=/usr \
JMANDIR=/usr/share/man/man1 \
-   LOCALCC=$(CC_FOR_BUILD) fdocs
+   LOCALCC=$(CC_FOR_BUILD) fdocs all
 
 override_dh_auto_install:
dh_auto_install -- JOVEHOME=/usr JMANDIR=/usr/share/man/man1

Bug#1023582: gnome-remote-desktop nocheck FTBFS: gbm.pc is not actually optional

[Helmut Grohne]

Source: gnome-remote-desktop
Version: 43.1-1
Severity: important
Justification: will be rc after bookworm
Tags: ftbfs

gnome-remote-desktop fails to build from source when built with the
nocheck build profile. While gbm.pc is used from tests/meson.build, it
is not actually implemented in a way such that gbm.pc is optional.
Trying to build without it results in a build failure. Please either
untag libgbm-dev or restructure the meson files such that test
dependencies actually become optional.

Helmut

Bug#1023581: efitools FTCBFS: multiple issues

[Helmut Grohne]

Source: efitools
Version: 1.9.2-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

efitools cannot be cross built from source, because it uses build
architecture aspects. The ARCH variable is detected from uname and LD
and OBJCOPY are also for the build architecture. I'm attaching a patch
to fix these for your conveniecne.

Once fixing these, you can see this:

./cert-to-efi-sig-list -g ----123456789abc PK.crt PK.esl
./cert-to-efi-sig-list: 1: Syntax error: word unexpected (expecting ")")

This looks a little more involved. It is running a tool that has just
been built. It is not clear to me whether this tool behaves in an
architecture-independent way and we can maybe use a self dependency. It
also is not clear to me whether we have to run it at all during build
given that yocto patched this out. Could you shed some light on this
invocation?

Helmut
diff --minimal -Nru efitools-1.9.2/debian/changelog 
efitools-1.9.2/debian/changelog
--- efitools-1.9.2/debian/changelog 2022-06-17 01:53:21.0 +0200
+++ efitools-1.9.2/debian/changelog 2022-11-06 20:33:39.0 +0100
@@ -1,3 +1,10 @@
+efitools (1.9.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Pass ARCH, LD, OBJCOPY. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 06 Nov 2022 20:33:39 +0100
+
 efitools (1.9.2-3) unstable; urgency=medium
 
   [ Bo YU ]
diff --minimal -Nru efitools-1.9.2/debian/rules efitools-1.9.2/debian/rules
--- efitools-1.9.2/debian/rules 2022-05-24 19:48:58.0 +0200
+++ efitools-1.9.2/debian/rules 2022-11-06 20:33:39.0 +0100
@@ -4,6 +4,18 @@
 # Uncomment this to turn on verbose mode.
 export DH_VERBOSE=1
 
+include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/buildtools.mk
+
+ifeq ($(DEB_HOST_ARCH_CPU),i386))
+ARCH=ia32
+else
+ARCH=$(DEB_HOST_GNU_CPU)
+endif
+
+override_dh_auto_build:
+   dh_auto_build -- ARCH=$(ARCH) LD=$(LD) OBJCOPY=$(OBJCOPY)
+
 override_dh_auto_install:
dh_auto_install -- 
EFIDIR="debian/efitools/usr/lib/efitools/${DEB_TARGET_MULTIARCH}"
 

Bug#930641: closed by Debian FTP Masters (Bug#1023560: Removed package(s) from unstable)

[Sergey B Kirpichev]

On Sun, Nov 06, 2022 at 10:12:34PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the guile-2.2-doc package:
> 
> #930641: r5rs.info missing
> 
> It has been closed by Debian FTP Masters .
> 
> Their explanation is attached below along with your original report.
 
> as the package guile-2.2 has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.

Wow.  Brave New Worl^WDebian.  Who cares that the issue is
valid for guile-3.0 as well?

Bug#1023540: snapshot.debian.org: 504 Gateway Time-out

[Vincent Lefevre]

On 2022-11-06 12:47:03 +, Adam D. Barratt wrote:
> On Sun, 2022-11-06 at 11:55 +0100, Vincent Lefevre wrote:
> > Since yesterday at least, snapshot.debian.org has returned the
> > "504 Gateway Time-out" error, at least on
> > 
> >   https://snapshot.debian.org/package/gcc-12/12.2.0-7/
> 
> It looks like the issue was localised to one of the web mirrors. I've
> rebooted that node, which seems to have improved things.

Unfortunately, I still get a 504 Gateway Time-out error.

Regards,

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

Bug#1023440: emacs: native-comp-async always runs, but no eln files are generated.

[Youhei SASAKI]

reopen 1023440

Hi,

On Sun, 06 Nov 2022 14:53:30 -0700 Sean Whitton  
wrote:
> Hello,
>
> > Package: emacs
> > Version: 1:28.2+1-3
> > Severity: important
> > X-Debbugs-Cc: none, Youhei SASAKI 
> >
> > Dear Maintainer,
> >
> > Although native-comp-async is always running in the background and
> > wasting computing resources every time Emacs is invoked,
> > no eln files are generated under ~/.emacs.d/eln-cache/.
>
> I don't know, there isn't really enough information in this bug report
> to do anything.  Closing for now, but if please reopen if you have a
> recipe to reproduce.

Ok.

  mkdir -p /tmp/emacs-test
  env HOME=/tmp/emacs-test emacs -nw --debug-init

then, always running native-compile-async.

I puts async-native-compile-log.txt.gz

Best Wishes,
Youhei

--
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07


async-native-compile-log.txt.gz
Description: Binary data

Bug#1023440: emacs: native-comp-async always runs, but no eln files are generated.

[Youhei SASAKI]

repopen 1023440

Hi, 

On Sun, 06 Nov 2022 14:53:30 -0700 Sean Whitton  
wrote:
> Hello,
> 
> > Package: emacs
> > Version: 1:28.2+1-3
> > Severity: important
> > X-Debbugs-Cc: none, Youhei SASAKI 
> >
> > Dear Maintainer,
> >
> > Although native-comp-async is always running in the background and
> > wasting computing resources every time Emacs is invoked,
> > no eln files are generated under ~/.emacs.d/eln-cache/.
> 
> I don't know, there isn't really enough information in this bug report
> to do anything.  Closing for now, but if please reopen if you have a
> recipe to reproduce.

Ok.

  mkdir -p /tmp/emacs-test
  env HOME=/tmp/emacs-test emacs -nw --debug-init

then, always running native-compile-async.

I puts async-native-compile-log.txt.gz

Best Wishes,
Youhei

--
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07


async-native-compile-log.txt.gz
Description: Binary data

Bug#1022942: xterm: cannot load font "-*-terminus-*-*-*-32-*-*-*-*-*-*-*"

[Thomas Dickey]

On Tue, Nov 01, 2022 at 09:23:55AM +0100, Andreas Tille wrote:
> Am Sun, Oct 30, 2022 at 04:53:24PM -0400 schrieb Thomas Dickey:
> > > > $ grep font /etc/X11/Xresources/xterm  | grep -v ^!
> > > > *VT100.utf8Fonts.font: fixed

what locale settings are you using?

(that might be relevant - or the choice of desktop/window-manager)

> > > > XTerm.VT100.font1: -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> > > > XTerm.VT100.font2: -*-terminus-*-*-*-18-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font3: -*-terminus-*-*-*-20-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font4: -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> > > > XTerm.VT100.font5: -*-terminus-*-*-*-28-*-*-*-*-*-*-*   
> > > >
> > > > XTerm.VT100.font6: -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> > 
> > for the record, xfonts-terminus includes all of these sizes.
> > 
> > > > here.  If I uncomment these settings xterm starts.  However, I think 
> > > > xterm should not
> > > 
> > > Is that "uncomment", or "comment"?
> 
> Sorry its "comment".
> 
> > > (the grep seems to indicate that the latter is meant)
> > > 
> > > > crash with segmentation fault when not finding some specified font.

I suppose the problem is something along the lines of the X server
returning some error in using the fonts.  If it were TrueType fonts,
I'd use strace to verify that they're opened -- but for bitmap
fonts, that's done on the server side.

> > > 
> > > agreed -
> > 
> > I've not been able to reproduce the problem, which I suspect is in
> > the error-recovery section of xterm's xtermLoadFont function.
> > 
> > Perhaps seeing the whole set of resources would help
> > (the output of "xrdb -query", too).
> 
> I have:
> 
> $ xrdb -query
> *VT100.utf8Fonts.font:  fixed
> XTermVT100.faceSize:22
> XTerm*geometry: 111x36
> xterm*vt100.initialFont:6
> YTerm*geometry: 90x50
> xterm*visualBell:   true
> Rxvt.keysym.Delete: \b
> Rxvt.termName:  xterm
> XTerm*decTerminalID:200
> XTerm*color0:   black
> XTerm*color1:   red
> XTerm*color2:   green
> XTerm*color3:   yellow
> XTerm*color4:   blue
> XTerm*color5:   magenta
> XTerm*color6:   cyan
> XTerm*color7:   white
> XTerm*color8:   black
> XTerm*color9:   red
> XTerm*color10:  green
> XTerm*color11:  yellow
> XTerm*color12:  blue
> XTerm*color13:  magenta
> XTerm*color14:  cyan
> XTerm*color15:  white
> XTerm*termName: xterm
> XTerm*title:XTerm
> XTerm*colorMode:on
> XTerm*background:   blue
> XTerm*foreground:   white
> XTerm*loginShell:   true
> XTerm*dynamicColors:on
> 
> 
> The crash happens for
> 
> $ xrdb -query
> *VT100.utf8Fonts.font:  fixed
> XTermVT100.faceSize:22
> XTerm*geometry: 111x36

hmm - I'm still not seeing _this_ problem.
(by the way, the geometry resource is over-broad, making the font-menu
less than useful).

I used xcfe4 for testing, on a virtual machine.

My most recent snapshot (from 2022/11/01) didn't work - some problem
with X and the window manaager), so I upgraded from 2022/10/29,
to get a workable machine.

Given that (I also have the terminus font installed),
I used "xrdb -load" with these resources, and ran xterm
from the Debian package.  It looks okay to me - no crash.

> XTerm.VT100.font1:  -*-terminus-*-*-*-16-*-*-*-*-*-*-*
> XTerm.VT100.font2:  -*-terminus-*-*-*-18-*-*-*-*-*-*-*
> XTerm.VT100.font3:  -*-terminus-*-*-*-20-*-*-*-*-*-*-*
> XTerm.VT100.font4:  -*-terminus-*-*-*-24-*-*-*-*-*-*-*
> XTerm.VT100.font5:  -*-terminus-*-*-*-28-*-*-*-*-*-*-*
> XTerm.VT100.font6:  -*-terminus-*-*-*-32-*-*-*-*-*-*-*
> xterm*vt100.initialFont:6
> YTerm*geometry: 90x50
> xterm*visualBell:   true
> Rxvt.keysym.Delete: \b
> Rxvt.termName:  xterm
> XTerm*decTerminalID:200
> XTerm*color0:   black
> XTerm*color1:   red
> XTerm*color2:   green
> XTerm*color3:   yellow
> XTerm*color4:   blue
> XTerm*color5:   magenta
> XTerm*color6:   cyan
> XTerm*color7:   white
> XTerm*color8:   black
> XTerm*color9:   red
> XTerm*color10:  green
> XTerm*color11:  yellow
> XTerm*color12:  blue
> XTerm*color13:  magenta
> XTerm*color14:  cyan
> XTerm*color15:  white
> XTerm*termName: xterm
> XTerm*title:XTerm
> XTerm*colorMode:on
> XTerm*background:   blue
> XTerm*foreground:   white
> XTerm*loginShell:   true
> XTerm*dynamicColors:on
> 
> 
> I confirm I have installed xfonts-terminus
> 
> $ apt policy xfonts-terminus
> xfonts-terminus:
>   Installiert:   4.48-3.1
>   Installationskandidat: 4.48-3.1
>   Versionstabelle:
>  *** 4.48-3.1 500
> 500 http://deb.debian.org/debian testing/main amd64 Packages
> 500 http://deb.debian.org/debian unstable/main amd64 Packages
> 500 http://ftp.debian.org/debian unstable/main amd64 Packages
> 100 /var/lib/dpkg/status
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de

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


signature.asc

Bug#1019829: pgn2web: diff for NMU version 0.4-3.1

[Olly Betts]

Control: tags 1019829 + patch

Dear maintainer,

I've prepared an NMU for pgn2web (versioned as 0.4-3.1) and
uploaded it to unstable as per the NMU guidelines in the devref:

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

Cheers,
Olly
diff -Nru pgn2web-0.4/debian/changelog pgn2web-0.4/debian/changelog
--- pgn2web-0.4/debian/changelog	2019-10-17 08:13:27.0 +1300
+++ pgn2web-0.4/debian/changelog	2022-11-07 12:06:09.0 +1300
@@ -1,3 +1,11 @@
+pgn2web (0.4-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Update to build with wxwidgets-3.2 (new patch
+wx3.2-compat.patch) (Closes: #1019829)
+
+ -- Olly Betts   Mon, 07 Nov 2022 12:06:09 +1300
+
 pgn2web (0.4-3) unstable; urgency=medium
 
   * debian/control:
diff -Nru pgn2web-0.4/debian/control pgn2web-0.4/debian/control
--- pgn2web-0.4/debian/control	2019-10-17 08:13:27.0 +1300
+++ pgn2web-0.4/debian/control	2022-11-07 11:58:56.0 +1300
@@ -2,7 +2,7 @@
 Section: web
 Priority: optional
 Maintainer: Jose G. López 
-Build-Depends: debhelper-compat (= 12), libwxgtk3.0-gtk3-dev
+Build-Depends: debhelper-compat (= 12), libwxgtk3.2-dev
 Standards-Version: 4.4.1
 Rules-Requires-Root: no
 Homepage: http://sourceforge.net/projects/pgn2web/
diff -Nru pgn2web-0.4/debian/patches/series pgn2web-0.4/debian/patches/series
--- pgn2web-0.4/debian/patches/series	2019-10-17 08:13:27.0 +1300
+++ pgn2web-0.4/debian/patches/series	2022-11-07 12:05:17.0 +1300
@@ -2,3 +2,4 @@
 makefile.patch
 install-location.patch
 wx3.0-compat.patch
+wx3.2-compat.patch
diff -Nru pgn2web-0.4/debian/patches/wx3.2-compat.patch pgn2web-0.4/debian/patches/wx3.2-compat.patch
--- pgn2web-0.4/debian/patches/wx3.2-compat.patch	1970-01-01 12:00:00.0 +1200
+++ pgn2web-0.4/debian/patches/wx3.2-compat.patch	2022-11-07 12:06:04.0 +1300
@@ -0,0 +1,17 @@
+Description: Fixes for compatibility with wxWidgets 3.2
+Author: Olly Betts 
+Bug-Debian: https://bugs.debian.org/1019829
+Forwarded: no
+Last-Update: 2022-11-06
+
+--- pgn2web-0.4.orig/gui.cpp
 pgn2web-0.4/gui.cpp
+@@ -367,7 +367,7 @@ void p2wFrame::do_layout()
+   buttonsSizer->Add(convertButton, 0, wxALL, 5);
+   buttonsSizer->Add(quitButton, 0, wxALL, 5);
+   rootSizer->Add(buttonsSizer, 0,
+-		 wxLEFT|wxRIGHT|wxBOTTOM|wxALIGN_CENTER_HORIZONTAL|wxADJUST_MINSIZE, 5);
++		 wxLEFT|wxRIGHT|wxBOTTOM|wxALIGN_CENTER_HORIZONTAL, 5);
+   rootPanel->SetAutoLayout(true);
+   rootPanel->SetSizer(rootSizer);
+   panelSizer->Add(rootPanel, 1, wxEXPAND, 0);

Bug#1021032: vlc: playing videos results in a black screen

[Alexis Murzeau]

Hi,

On Sat, 08 Oct 2022 14:30:43 +0300 =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont 
 wrote:

Le lauantaina 8. lokakuuta 2022, 12.40.56 EEST KeyofBlueS a écrit :
> Hi all. Let's continue here from #1021140
> 
> 
> It seems this issue it's not completely fixed. Before it was always

> reproducible under any circumstance, when now there are at least two ways
> to always trigger it:

I believe that the issue is not fixed at all.

The symptoms started showing up after Debian updated Qt, and affect only the Qt 
GUI. The last attempt to fix it affected the VA-API video decoding path in such 
a way that it will still *fail* at a different pace than it did before the fix. 
Then it will fallback to VDPAU or to software decoding path.


[...]


I'm jumping in to add information, I also get black screen issue after updating 
Qt from 5.15.4 to 5.15.6.

I also get graphical issues in the playlist, when resizing the VLC window. 
These graphical issues appear also in virtualbox-qt.

I've already created a bug on qt: #1023580
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023580

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Bug#1010404: (no subject)

[Daniel Swarbrick]

This bug report is pretty difficult to make sense of, due to the 
spelling mistakes and lack of punctuation.


Why is docker.io mentioned in the bug report? The Debian package of 
prometheus-node-exporter is not intended to be run in docker.


If you run a system with sid / unstable configured in apt sources, you 
have to expect a certain amount of breakage from time to time, and 
package maintainers are unlikely to take bug reports seriously unless 
the issue can be reproduced on a stable or testing install.


Please write a clearer description of the bug. I don't know where to 
begin with this one.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023005: A recent Bookworm upgrade broke video playback in the VLC player

[Alexis Murzeau]

On Sat, 29 Oct 2022 07:51:03 +0200 (CEST) local10  wrote:

Tried other video players (haruna, smplayer, mpv) and every single one of them 
works without issues, so the problem seems to be specific only to vlc.


Are you getting something like in the videos attached in the bug: #1023580 ?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023580

I personally also have vlc graphical issues and black screen when playing a 
video after Qt update to 5.15.6.
So maybe what you have is related.

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Bug#962476: (no subject)

[Daniel Swarbrick]

Such a change is unlikely to be met with enthusiasm by the vast majority 
of users, and would likely be the source of many subsequent bug reports 
requesting the change to be reverted.


Whilst I acknowledge that node_exporter provides a wealth of information 
which could potentially be useful to attackers, the main purpose of the 
daemon is to be queried via the network by a Prometheus instance.


Many other network-based services will bind to the wildcard address by 
default, since they are functionally pretty useless if they don't do that.


The upstream Prometheus developers have long maintained the position 
that security is out of scope for Prometheus and its related exporters, 
since there is no "one size fits all", and end users are encouraged to 
weigh up what security precautions make sense in their specific environment.


If you are concerned about drive-by probes of node_exporter or other 
services for that matter, I suggest that you look into running a 
firewall on your host.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023579: lomiri-clock-app: autopkgtest depends on non-existing packages

[Adrian Bunk]

Source: lomiri-clock-app
Version: 3.13~git20221027.60c85a4-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/l/lomiri-clock-app/27859719/log.gz

...
E: Unable to locate package autopilot-touch
E: Unable to locate package libautopilot-qt
E: Unable to locate package python3-autopilot
E: Package 'qt5-default' has no installation candidate
E: Unable to locate package lomiri-ui-toolkit-autopilot
make-testFAIL badpkg


qt5-default was removed some time ago,
I do not know the situation regarding the other packages.

Bug#1023578: nethack-common: please #define DUMPLOG

[Ian Charlesworth]

Package: nethack-common
Version: 3.6.6-3+b1
Severity: wishlist

Dear Maintainer,

Could you please add the compile flag DUMPLOG? This enables logs to be
dumped at the end of a game, showing information like the final screen.
The compile option DUMPLOG_FILE might also need a reasonable default; I
think in previous versions (3.4.*) there was a patch added which saved
things in /var/games/nethack/dumps by default.

I notice that the current nethack lists end-of-game disclosure files as
not supported, so (I believe!) this is not just a case of me
mis-configuring:

$ nethack --showpaths
Variable playground locations:
[hackdir   ]="not set"
[leveldir  ]="not set"
[savedir   ]="not set"
[bonesdir  ]="not set"
[datadir   ]="not set"
[scoredir  ]="/var/games/nethack/"
[lockdir   ]="not set"
[sysconfdir]="not set"
[configdir ]="not set"
[troubledir]="not set"
/usr/lib/games/nethack/nethack-console's system configuration file (in 
sysconfdir):
"/etc/nethack/sysconf"
The loadable symbols file:
"/usr/lib/games/nethack/symbols"
Basic data files (in datadir) are collected inside:
"nhdat"
No end-of-game disclosure file (not supported).
Your personal configuration file (in configdir):
"/home//.nethackrc"


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (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 nethack-common depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libc6  2.35-4

Versions of packages nethack-common recommends:
ii  nethack-console  3.6.6-3+b1

nethack-common suggests no packages.

-- Configuration Files:
/etc/nethack/sysconf changed:
WIZARDS=root games
EXPLORERS=*
GENERICUSERS=play player game games nethack nethacker
MAXPLAYERS=10
DUMPLOGFILE=/tmp/nethack.%n.%d.log
GDBPATH=/usr/bin/gdb
GREPPATH=/bin/grep
PANICTRACE_GDB=1
PANICTRACE_LIBC=2
OPTIONS=disclose:ni ya yv yg yc yo


-- debconf information:
* nethack-common/recover-setgid: true

Bug#1023577: RM: python-matrix-nio/0.16.0-1

[Jochen Sprickerhof]

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

Hi,

please remove python-matrix-nio from stable as it has an open security
bug (CVE-2022-39254) and no longer works as reported in [1] and I tested
myself.

Please also remove it's downstream dependencies, i.e. pantalaimon and
weechat-matrix.

Thanks

Jochen

[1] https://github.com/poljar/weechat-matrix/issues/335

Bug#1023576: raku-json-class: trying to overwrite '/usr/lib/perl6/vendor/precomp/B956FE95EA2D10BBA53021A509C172354487B37C/C1/C1DA909DAD9BF713751A74EBF038C545A1EA6ECC', which is also in package raku-js

[Adrian Bunk]

Package: raku-json-class
Version: 0.0.19-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:raku-license-spdx

https://piuparts.debian.org/sid/fail/raku-json-class_0.0.19-1.log

...
  Unpacking raku-json-class (0.0.19-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-EBPyxP/19-raku-json-class_0.0.19-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/perl6/vendor/precomp/B956FE95EA2D10BBA53021A509C172354487B37C/C1/C1DA909DAD9BF713751A74EBF038C545A1EA6ECC',
 which is also in package raku-json-marshal 0.0.24-1
...


This looks similar to #1019579, but the fixed dh-raku was used for
building these packages

Bug#1017872: RFA: ocrmypdf -- add an OCR text layer to PDF files

[Sean Whitton]

control: retitle -1 O: ocrmypdf -- add an OCR text layer to PDF files

Hello,

On Sun 21 Aug 2022 at 02:53PM -07, Sean Whitton wrote:

> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: debian-pyt...@lists.debian.org, barlow@gmail.com
> Control: affects -1 src:ocrmypdf
>
> I request an adopter for the ocrmypdf package.  I don't use it as often
> as I did (hardly ever the past couple of years), and anyway it would be
> better for a Python programmer to maintain it.

I hereby orphan ocrmypdf.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017873: RFA: pikepdf

[Sean Whitton]

control: retitle -1 O: pikepdf -- Python library to read and write PDFs with 
QPDF

Hello,

On Sun 21 Aug 2022 at 02:55PM -07, Sean Whitton wrote:

> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: debian-pyt...@lists.debian.org, barlow@gmail.com
> Control: affects -1 src:pikepdf
>
> I request an adoptor for the pikepdf package.  It would be better if
> someone with more knowledge of either or both Python and PDFs were to
> maintain it.  I have also filed an RFA for ocrmypdf, the most important
> reverse dependency.

I here by orphan pikepdf.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1023474: ITP: check-logfiles -- Nagios plugin check_logfiles

[Hilmar Preusse]

Control: retitle -1 ITP: monitoring-plugins-check-logfiles -- Nagios plugin 
check_logfiles


On 04.11.22 Hilmar Preusse (hill...@web.de) wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Hilmar Preusse 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: check-logfiles
>
I'm afraid the name is to generic.  Maybe better adapt it to the
other icinga / nagios related packages.

Package name: monitoring-plugins-check-logfiles

H.

--
sigmentation fault

Bug#1023575: neo-cli: charset=runic includes pseudo-runes

[Adam Borowski]

Package: neo-cli
Version: 0.6.1-1
Severity: normal

Hi!
If you run neo with --charset=runic, besides of actual runes (ie, letters
that have been used in various historical periods), the program also uses
a bunch of symbols that had no real-life use (U+16F1..U+16F8):
 * Tolkien:
   * U+16F1 included in The Hobbit when Tolkien found no way to spell his
 name within Anglo-Saxon runes
   * U+16F2 and U+16F3 from a personal letter
 * Franks Casket:
   * U+16F4..U+16F8 (these at least come from 8th century) are weird
 variant letters not attested anywhere else, for reasons not
 known despite generations of research but conjectured to be unique
 numerologic rune magic.

But you probably care less about actual historical reasons.  A practical
one is that the rest of runes come from Unicode 3.0 (1999) while the
U+16F1..U+16F8 symbols were added only in Unicode 7.0 (2014) and thus
are missing from most fonts we ship.  This results in ugly replacement
symbols marring the display.

Also: eg. cyrillic uses actual letters only, not a medieval scribe's
doodles like "multiocular o" that was drawn in a single copy of a book
from 1429 -- yet got encoded in Unicode anyway.


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

Kernel: Linux 6.1.0-rc3-00018-g38bb0e6b7ef0 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages neo-cli depends on:
ii  libc6 2.36-4
ii  libgcc-s1 12.2.0-9
ii  libncursesw6  6.3+20220423-2
ii  libstdc++612.2.0-9
ii  libtinfo6 6.3+20220423-2

neo-cli recommends no packages.

neo-cli suggests no packages.

-- no debconf information

Bug#1023446: libhdf5-openmpi-dev: h5pcc configured as static build

[Drew Parsons]

On 2022-11-06 15:22, Gilles Filippini wrote:

Hi Drew,

...

h5pcc is showing an unexpected default configuration:

...

Note how it includes static linking to libhdf5_hl.a and libhdf5.a


This is the expected behavior as documented by upstream:

   -shlib Compile with shared HDF5 libraries [default for hdf5
built without static libraries]

   -noshlib
  Compile with static HDF5 libraries [default for hdf5
built with static libraries]



I agree, we should stick with upstream's documented behaviour.  There 
could be room for some discussion or interpretation, unless I'm 
misunderstanding upstream's intent here.  In our case we're providing 
hdf5 built both with and without static libraries. In that case we could 
argue for setting -shlib as default, if we expect client programs 
normally to use the shared library (are there  arguments in favour of 
using the static library even if the shared library is available?)


On the other hand, the h5pcc documentation for the HDF5_USE_SHLIB 
environment variable is a bit less ambiguous:
"default: no except when built with only shared libraries". That makes 
it more clear that upstream expects the static library to be used when 
available, even if the shared library is available.


...


As far as I can tell, the default static linking is causing the RC
Bug#1020054 reported against h5py.


Could be fixed using `HDF5_USE_SHLIB=yes`:
 PYBUILD_NAME=$(PYBUILD_NAME_MPI) CC=h5pcc HDF5_USE_SHLIB=yes
HDF5_MPI=ON HDF5_PKGCONFIG_NAME=hdf5-mpi H5PY_SYSTEM_LZF=1
dh_auto_build -D $(BUILD_DIR_MPI)



Should the default configuration of h5pcc be changed to confirm with
the -shlib configuration?


I don't think so since the current behavior is the documented one.


Fair, especially since the HDF5_USE_SHLIB documentation makes upstream's 
intention clear.


It's strange that Bug#1020054 was only recently reported.  h5py was 
building happily until now. Would it be the upgrade to gcc-12 that 
changed the behaviour?



I'll update the h5py configuration in any case as you recommend 
(assuming we still want to be using the shared library for debian 
packages).

Bug#1010406: kexec-tools: add trivial support for restart/reload via stop/start

[Lars Kruse]

Package: kexec-tools
Version: 1:2.0.24-1+b1
Followup-For: Bug #1010406
Control: tags -1 patch

Dear Maintainer,

here on my system I replaced the content of the "restart" branch with
a simple stop/start sequence:

restart|reload|force-reload)
"$0" stop
"$0" start
;;

This works fine here (the "start" operation is a no-op, anyway).

Attached you find a patch with the above change applied to both init
scripts.

Thanks for providing an init script for this package!

Cheers,
Lars
--- /etc/init.d/kexec.orig  2022-11-06 21:26:18.670086639 +0100
+++ /etc/init.d/kexec   2022-11-06 21:27:52.981249908 +0100
@@ -37,8 +37,8 @@
# No-op
;;
   restart|reload|force-reload)
-   echo "Error: argument '$1' not supported" >&2
-   exit 3
+   "$0" stop
+   "$0" start
;;
   stop)
# Systemd has its own kexec service (which will call the kexec
--- /etc/init.d/kexec-load.orig 2022-11-06 21:26:10.545814141 +0100
+++ /etc/init.d/kexec-load  2022-11-06 21:27:58.109421912 +0100
@@ -102,8 +102,8 @@
# No-op
;;
   restart|reload|force-reload)
-   echo "Error: argument '$1' not supported" >&2
-   exit 3
+   "$0" stop
+   "$0" start
;;
   stop)
# If running systemd, we want kexec reboot only if current

Bug#1017871: shiny-server: server-function don't run

[Nilesh Patra]

On Wed, 19 Oct 2022 17:30:50 + =?iso-8859-1?Q?Kr=FCger=2C_Sebastian?=
 wrote:
> Hi all,
> 
> the problem seems to be with the node_sockjs package.
> 
> If I replace the directory/files under /usr/share/nodejs/sockjs with the 
> corresponding JS files created with npm from the official sockjs sources from 
> github, the shiny-server works.
> npm uses CoffeeScript 1.12.7, Debian uses version 2.0.7.
> 
> Possibly the node-sockjs bug 1016732 is still open.

Could you please share some basic reproducer for this?

(I am very very sad to know that this still does not work after putting in a 
lot of efforts :-//)

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1023574: wolfssl: CVE-2022-42961

[Salvatore Bonaccorso]

Source: wolfssl
Version: 5.2.0-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wolfssl.

CVE-2022-42961[0]:
| An issue was discovered in wolfSSL before 5.5.0. A fault injection
| attack on RAM via Rowhammer leads to ECDSA key disclosure. Users
| performing signing operations with private ECC keys, such as in
| server-side TLS connections, might leak faulty ECC signatures. These
| signatures can be processed via an advanced technique for ECDSA key
| recovery. (In 5.5.0 and later, WOLFSSL_CHECK_SIG_FAULTS can be used to
| address the vulnerability.)


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

Regards,
Salvatore

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[Jonas Smedegaard]

Quoting Georges Khaznadar (2022-11-06 19:55:45)
> So, building furo with pure debian tools is possible, and the result
> is efficient. I uploaded a new release of package furo to the NEW queue.

Sounds nice.

I sure hope you went with sassc.  In case you are still in doubt, please
let me quote the package short description for ruby-sass:

> deprecated CSS compiler - use sassc or ruby-sassc instead


Also, I hope you "beautify" CSS files only as part of your examination,
not as part of the packaged build where users either will want compact
or readable _SASS_ sources.


> - you would like to see SASS files distributed under /usr/share/sass; is
>   it sufficient to shape the packaging so it produces two binary
>   packages, "furo" for the sphinx style, and "sass-stylesheets-furo"
>   for SASS stuff? Or would it be sufficient to make a single "furo"
>   binary, which stores SASS files under /usr/share/sass, and provides a
>   virtual package name sass-stylesheets-furo?

Best would be separate packages: I can easily imagine people wanting to
build+serve a custom-styled documentation where content is built using
Furo, without needing to pull in Furo-specific dependencies (Python
libraries, I guess) which is irrelevant for recompiling SASS or hosting
static content.


> - you would like to see gumshoe.js packaged separately in Debian. I can
>   issue an ITP for it. Do you estimate that making a package
>   node-gumshoe is worth the effort, and the storage cost, for debian
>   servers? Remember that the flesh in this package is a 500-liner
>   script.

I recommend to discuss with the JavaScript team if more sensible to
package it standalone or e.g. include in a collection of small scripts.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1023573: hsqldb: CVE-2022-41853

[Salvatore Bonaccorso]

Source: hsqldb
Version: 2.7.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for hsqldb.

CVE-2022-41853[0]:
| Those using java.sql.Statement or java.sql.PreparedStatement in hsqldb
| (HyperSQL DataBase) to process untrusted input may be vulnerable to a
| remote code execution attack. By default it is allowed to call any
| static method of any Java class in the classpath resulting in code
| execution. The issue can be prevented by updating to 2.7.1 or by
| setting the system property "hsqldb.method_class_names" to classes
| which are allowed to be called. For example,
| System.setProperty("hsqldb.method_class_names", "abc") or Java
| argument -Dhsqldb.method_class_names="abc" can be used. From version
| 2.7.1 all classes by default are not accessible except those in
| java.lang.Math and need to be manually enabled.


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-41853
https://www.cve.org/CVERecord?id=CVE-2022-41853
[1] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=50212#c7
[2] 
http://hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html#src_jrt_access_control
[3] https://sourceforge.net/p/hsqldb/svn/6614/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1023572: src:ruby-liquid-c: fails to migrate to testing for too long: Build-Depends on package that can't migrate

[Paul Gevers]

Source: ruby-liquid-c
Version: 4.0.0-2
Severity: serious
Control: close -1 4.1.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1023534

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ruby-liquid-c has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. Your package is stuck 
behind ruby-liquid, which has bug #1023534 filed against it.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=ruby-liquid-c



OpenPGP_signature
Description: OpenPGP digital signature

Bug#863333: upower: Kindly include (german) translation in bookworm

[Helge Kreutzmann]

Hello Michael,
On Sun, Nov 06, 2022 at 09:06:08PM +0100, Michael Biebl wrote:
> On Sun, 6 Nov 2022 14:25:50 +0100 Helge Kreutzmann 
> wrote:
> > Dear upower maintainer(s),
> > The freeze for Debian bookworm is scheduled at the beginning of 2023.
> > Since 2017-05-25 this bug report with a german program translation is open.
> > 
> > For the benefit of the (german speaking) users it would be great if
> > you could perform an upload with this (and other) translations included
> > before the freeze.
> > 
> > If you have any questions regarding the integration of the translation
> > do not hesitate to contact me or the submitter.
> > 
> 
> As already said, this needs to go upstream. We won't patch this in
> downstream.
> 
> Thanks for understanding.

Sure and sorry for not checking on this.

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1023571: php-cas: CVE-2022-39369: Service Hostname Discovery Exploitation

[Salvatore Bonaccorso]

Source: php-cas
Version: 1.3.8-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.3.6-1

Hi,

The following vulnerability was published for php-cas.

CVE-2022-39369[0]:
| phpCAS is an authentication library that allows PHP applications to
| easily authenticate users via a Central Authentication Service (CAS)
| server. The phpCAS library uses HTTP headers to determine the service
| URL used to validate tickets. This allows an attacker to control the
| host header and use a valid ticket granted for any authorized service
| in the same SSO realm (CAS server) to authenticate to the service
| protected by phpCAS. Depending on the settings of the CAS server
| service registry in worst case this may be any other service URL (if
| the allowed URLs are configured to "^(https)://.*") or may be strictly
| limited to known and authorized services in the same SSO federation if
| proper URL service validation is applied. This vulnerability may allow
| an attacker to gain access to a victim's account on a vulnerable
| CASified service without victim's knowledge, when the victim visits
| attacker's website while being logged in to the same CAS server.
| phpCAS 1.6.0 is a major version upgrade that starts enforcing service
| URL discovery validation, because there is unfortunately no 100% safe
| default config to use in PHP. Starting this version, it is required to
| pass in an additional service base URL argument when constructing the
| client class. For more information, please refer to the upgrading doc.
| This vulnerability only impacts the CAS client that the phpCAS library
| protects against. The problematic service URL discovery behavior in
| phpCAS  1.6.0 will only be disabled, and thus you are not impacted
| from it, if the phpCAS configuration has the following setup: 1.
| `phpCAS::setUrl()` is called (a reminder that you have to pass in the
| full URL of the current page, rather than your service base URL), and
| 2. `phpCAS::setCallbackURL()` is called, only when the proxy mode is
| enabled. 3. If your PHP's HTTP header input `X-Forwarded-Host`,
| `X-Forwarded-Server`, `Host`, `X-Forwarded-Proto`, `X-Forwarded-
| Protocol` is sanitized before reaching PHP (by a reverse proxy, for
| example), you will not be impacted by this vulnerability either. If
| your CAS server service registry is configured to only allow known and
| trusted service URLs the severity of the vulnerability is reduced
| substantially in its severity since an attacker must be in control of
| another authorized service. Otherwise, you should upgrade the library
| to get the safe service discovery behavior.


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-39369
https://www.cve.org/CVERecord?id=CVE-2022-39369
[1] https://github.com/apereo/phpCAS/security/advisories/GHSA-8q72-6qq8-xv64

Regards,
Salvatore

Bug#1023570: golang-github-sylabs-sif: CVE-2022-39237

[Salvatore Bonaccorso]

Source: golang-github-sylabs-sif
Version: 2.3.1-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-github-sylabs-sif.

CVE-2022-39237[0]:
| syslabs/sif is the Singularity Image Format (SIF) reference
| implementation. In versions prior to 2.8.1the
| `github.com/sylabs/sif/v2/pkg/integrity` package did not verify that
| the hash algorithm(s) used are cryptographically secure when verifying
| digital signatures. A patch is available in version = v2.8.1 of
| the module. Users are encouraged to upgrade. Users unable to upgrade
| may independently validate that the hash algorithm(s) used for
| metadata digest(s) and signature hash are cryptographically secure.


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-39237
https://www.cve.org/CVERecord?id=CVE-2022-39237
[1] https://github.com/sylabs/sif/security/advisories/GHSA-m5m3-46gj-wch8
[2] 
https://github.com/sylabs/sif/commit/21972852d8783bc93fbf080190de8e1978f1c254
[3] 
https://github.com/sylabs/sif/commit/a854038ce1f18237b81d505a1c3be6a60505db52

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#863333: upower: Kindly include (german) translation in bookworm

[Michael Biebl]

On Sun, 6 Nov 2022 14:25:50 +0100 Helge Kreutzmann 
 wrote:

Dear upower maintainer(s),
The freeze for Debian bookworm is scheduled at the beginning of 2023.
Since 2017-05-25 this bug report with a german program translation is open.

For the benefit of the (german speaking) users it would be great if
you could perform an upload with this (and other) translations included
before the freeze.

If you have any questions regarding the integration of the translation 
do not hesitate to contact me or the submitter.




As already said, this needs to go upstream. We won't patch this in 
downstream.


Thanks for understanding.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Eli Zaretskii]

> Date: Sun, 6 Nov 2022 11:44:43 -0800
> Cc: a...@sdf.org, vinc...@vinc17.net, spwhit...@spwhitton.name,
>  58...@debbugs.gnu.org, 1017...@bugs.debian.org
> From: Paul Eggert 
> 
> On 2022-11-06 11:32, Eli Zaretskii wrote:
> > My question was whether in this scenario, since the parent Emacs
> > exits, the child Emacs can get SIGHUP, simply because its parent
> > exited and the read end of the PTY no longer exists.
> 
> Yes, my sense from the few experiments I tried, is that it's a plausible 
> scenario, though I never observed it actually happening for Emacs doing 
> a subprocess compile.

OK, thanks.  So I hope your suggested patch will solve this issue.

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Paul Eggert]

On 2022-11-06 11:32, Eli Zaretskii wrote:

My question was whether in this scenario, since the parent Emacs
exits, the child Emacs can get SIGHUP, simply because its parent
exited and the read end of the PTY no longer exists.


Yes, my sense from the few experiments I tried, is that it's a plausible 
scenario, though I never observed it actually happening for Emacs doing 
a subprocess compile.

Bug#1023569: librte-net-af-xdp22 is empty after rebuild with 1.0.1

[Adrian Bunk]

Package: librte-net-af-xdp22
Version: 21.11-5
Severity: serious

$ dpkg -L librte-net-af-xdp22
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/librte-net-af-xdp22
/usr/share/doc/librte-net-af-xdp22/changelog.Debian.amd64.gz
/usr/share/doc/librte-net-af-xdp22/changelog.Debian.gz
/usr/share/doc/librte-net-af-xdp22/copyright
$

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Eli Zaretskii]

> Date: Sun, 6 Nov 2022 11:18:03 -0800
> Cc: a...@sdf.org, vinc...@vinc17.net, spwhit...@spwhitton.name,
>  58...@debbugs.gnu.org, 1017...@bugs.debian.org
> From: Paul Eggert 
> 
> On 2022-11-05 22:51, Eli Zaretskii wrote:
> 
> > But is it possible for a program like Emacs to get SIGHUP in such a
> > situation, or is that highly improbable?  We have standard streams of
> > the inferior Emacs process connected via PTYs to the parent process, I
> > believe -- does that deliver SIGHUP or SIGPIPE when the parent exits?
> 
> It depends on the OS and the app that invokes Emacs and how that app 
> itself was invoked. It's a hairy area.
> 
> On a POSIX platform it's certainly *possible* for Emacs to get SIGHUP in 
> that situation, because a user can invoke the shell command 'kill -s HUP 
> P', where P is the process ID of the inferior Emacs. Whether it's 
> *likely* is a bit harder to say. I ran a few little experiments on 
> Fedora 36 and Ubuntu 22.10 and found SIGHUP being sent in a few 
> situations and not others and didn't have the time or patience to suss 
> out exactly why or when.

Thanks.  The scenario that is of primary interest in this case is the
following:

 . user starts Emacs
 . Emacs loads some Lisp package and as results starts a subordinate
   Emacs process in batch mode to native-compile the loaded Lisp
 . user exits Emacs

My question was whether in this scenario, since the parent Emacs
exits, the child Emacs can get SIGHUP, simply because its parent
exited and the read end of the PTY no longer exists.

Bug#1023567: Acknowledgement (systemd-container: systemd-machined segfault 6 ABRT)

[udent]

coredumpctl info 4647
   PID: 4647 (systemd-machine)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Sat 2022-11-05 21:26:17 CET (22h ago)
  Command Line: /lib/systemd/systemd-machined
Executable: /usr/lib/systemd/systemd-machined
 Control Group: /system.slice/systemd-machined.service
  Unit: systemd-machined.service
 Slice: system.slice
   Boot ID: 
Machine ID: 
  Hostname: 
   Storage: 
/var/lib/systemd/coredump/core.systemd-machine.0.7facfe2e2aa94b8f8ac94aea47841804.4647.166767997700.zst
   Message: Process 4647 (systemd-machine) of user 0 dumped core.

Stack trace of thread 4647:
#0  0x72ce4d324ce1 __GI_raise (libc.so.6 + 0x38ce1)
#1  0x72ce4d30e537 __GI_abort (libc.so.6 + 0x22537)
#2  0x72ce4d367768 __libc_message (libc.so.6 + 0x7b768)
#3  0x72ce4d36ea5a malloc_printerr (libc.so.6 + 0x82a5a)
#4  0x72ce4d370055 _int_free (libc.so.6 + 0x84055)
#5  0x5b800903bb41 n/a (systemd-machined + 0xdb41)
#6  0x72ce4d5bf5a2 varlink_process 
(libsystemd-shared-247.so + 0xf25a2)
#7  0x72ce4d5bfc66 n/a (libsystemd-shared-247.so + 0xf2c66)
#8  0x72ce4d68686a n/a (libsystemd-shared-247.so + 0x1b986a)
#9  0x72ce4d686ce1 sd_event_dispatch 
(libsystemd-shared-247.so + 0x1b9ce1)
#10 0x72ce4d688048 sd_event_run (libsystemd-shared-247.so + 
0x1bb048)
#11 0x72ce4d54bb7c bus_event_loop_with_idle 
(libsystemd-shared-247.so + 0x7eb7c)
#12 0x5b80090369c0 n/a (systemd-machined + 0x89c0)
#13 0x72ce4d30fd0a __libc_start_main (libc.so.6 + 0x23d0a)
#14 0x5b8009036f1a n/a (systemd-machined + 0x8f1a)

Bug#1023568: onionshare: autopkgtest regression with flask 2.2.2

[Carsten Schoenert]

Package: onionshare
Version: 2.5-2
Severity: important

Dear Maintainer,

with the current version 2.2.2 of flask and werkzeug in experimental
your package fails to run the autopkgtests successfully.

The relevant part that fails lokks like this:

autopkgtest [18:27:55]: test onionshare_help: 
XDG_CONFIG_HOME="$AUTOPKGTEST_TMP" xvfb-run -- onionshare --help
autopkgtest [18:27:55]: test onionshare_help: [---
Traceback (most recent call last):
  File "/usr/bin/onionshare", line 5, in 
from onionshare import main
  File "/usr/lib/python3/dist-packages/onionshare/__init__.py", line 34, in 

from onionshare_cli.common import Common
  File 
"/usr/lib/python3/dist-packages/shiboken2/files.dir/shibokensupport/__feature__.py",
 line 142, in _import
return original_import(name, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/onionshare_cli/__init__.py", line 30, in 

from .web import Web
  File 
"/usr/lib/python3/dist-packages/shiboken2/files.dir/shibokensupport/__feature__.py",
 line 142, in _import
return original_import(name, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/onionshare_cli/web/__init__.py", line 
21, in 
from .web import Web
  File 
"/usr/lib/python3/dist-packages/shiboken2/files.dir/shibokensupport/__feature__.py",
 line 142, in _import
return original_import(name, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/onionshare_cli/web/web.py", line 38, in 

from flask_socketio import SocketIO
  File 
"/usr/lib/python3/dist-packages/shiboken2/files.dir/shibokensupport/__feature__.py",
 line 142, in _import
return original_import(name, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/flask_socketio/__init__.py", line 24, in 

from werkzeug.serving import run_with_reloader
ImportError: cannot import name 'run_with_reloader' from 'werkzeug.serving' 
(/usr/lib/python3/dist-packages/werkzeug/serving.py)

The full log (amd64) is reachable under

https://ci.debian.net/data/autopkgtest/unstable/amd64/o/onionshare/27759203/log.gz

The full list of packages that fail with flask from experimental can be
found here.

https://qa.debian.org/excuses.php?experimental=1=flask

Please fix the autopktest issue, the DPT will increase the severity of
the outstanding autopkgtest issues with flask 2.2.2 probably soon so we
can start the freezing process for the bookworm release for the Python
packages.

There is a new released version 2.6 of onionshare, maybe importing a
newer version can fix the issue of the failed autopkgtest.

Regards
Carsten

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Paul Eggert]

On 2022-11-05 22:51, Eli Zaretskii wrote:


But is it possible for a program like Emacs to get SIGHUP in such a
situation, or is that highly improbable?  We have standard streams of
the inferior Emacs process connected via PTYs to the parent process, I
believe -- does that deliver SIGHUP or SIGPIPE when the parent exits?


It depends on the OS and the app that invokes Emacs and how that app 
itself was invoked. It's a hairy area.


On a POSIX platform it's certainly *possible* for Emacs to get SIGHUP in 
that situation, because a user can invoke the shell command 'kill -s HUP 
P', where P is the process ID of the inferior Emacs. Whether it's 
*likely* is a bit harder to say. I ran a few little experiments on 
Fedora 36 and Ubuntu 22.10 and found SIGHUP being sent in a few 
situations and not others and didn't have the time or patience to suss 
out exactly why or when.

Bug#1023373: [pkg-crosswire-devel] Bug#1023373: Further bug discussion

[Teus Benschop]

[…]
> Then it is not only a non-source file but a non-source file that does not 
> have a public source.

Right, since this file does not have a public source, this is a valid reason to 
remove it.

So here’s the proof how useful the discussion was we’ve just had on this topic.
The usefulness is visible in that now there’s a valid reason to delete this 
file.

I’ve just prepared a new Debian tarball for Bibledit Cloud and uploaded the new 
build to the Debian archives.

It also includes also your recent fixes in Salsa - thank you for that 
contribution.

Then the upload to Bibledit (non-Cloud) should finally fix this bug - coming 
soon.

Bug#1023567: systemd-container: systemd-machined segfault 6 ABRT

[udent]

Package: systemd-container
Version: 247.3-7+deb11u1
Severity: normal
Tags: patch
X-Debbugs-Cc: ud...@mailbox.org

Dear Maintainer,

If you backup the systemd-machined default directory ("/var/lib/machines") with 
borgbackup,
 is one way to segfault systemd-machined.
Systemd State is now: degraded.

Backup the folder without crash, of course.

I test this little patch and it no longer crash:
https://github.com/codepeon/systemd/commit/1600b38cd2029533547f8c3d4abfa12911ca0630.patch
It apply to current stable release without Problems.
i test with "dpkg-source --commit" and "debuild -us -uc"


-- 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-19-amd64 (SMP w/4 CPU threads)
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 systemd-container depends on:
ii  dbus 1.12.24-0+deb11u1
ii  libacl1  2.2.53-10
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u5
ii  libcurl3-gnutls  7.74.0-1.3+deb11u3
ii  libgcrypt20  1.8.7-6
ii  liblzma5 5.2.5-2.1~deb11u1
ii  libseccomp2  2.5.1-1+deb11u1
ii  libselinux1  3.1-3
ii  systemd  247.3-7+deb11u1
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages systemd-container recommends:
ii  libnss-mymachines  247.3-7+deb11u1

systemd-container suggests no packages.

-- no debconf information

Bug#937049: mini-buildd: Python2 removal in sid/bullseye

[Stephan Sürken]

Hi Moritz,

On Fri, 2022-10-28 at 00:12 +0200, Moritz Mühlenhoff wrote:
> Am Fri, Aug 30, 2019 at 07:26:40AM + schrieb Matthias Klose:
> > Package: src:mini-buildd
> > Version: 1.0.41
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> How close is the 2.x branch in experimental from being a replacement?
> python2 will be dropped in bookworm and also removed from the archive.

it's taking way too long already ;), but I am still quite confident to be
able to upload to unstable this year, i.e., before Debian freeze/bookworm.

Hth!

S

Bug#1023565: mopidy-dleyna: depends on orphaned/removed dleyna

[Andreas Henriksson]

Package: mopidy-dleyna
Version: 2.0.2-1
Severity: important

Dear Maintainer,

The dleyna packaging in debian has been orphaned for many years.

Given there was a need for a gssdp/gupnp transition to 1.6 (because
moving to libsoup3) the dleyna packaging was removed, since there
was noone interested in taking care of it.

The mopidy-dleyna package needs dleyna and in now no longer part of
testing as a consequence of dleyna being missing.

The situation with dleyna is that it has a new upstream maintainer
(also maintainer of gssdp/gupnp/rygel/etc). The new dleyna 0.8 release
has been ported to gssdp/gupnp 1.6. The new dleyna 0.8 is now a single
source package (previously dleyna-* was separate source packages).
There are initial debian packaging of src:dleyna available at:
https://salsa.debian.org/debian/dleyna

The next step would be to (re)upload the new dleyna 0.8 packages
to the archive, but someone interested in maintaining them are needed.

Are you interested in maintaining dleyna packages in debian?

Regards,
Andreas Henriksson

PS. grilo-plugins recommends dleyna-server and I've poked berto on IRC
as well. Maybe you could team up?

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[Georges Khaznadar]

Dear Jonas, thank you, as you took the time to reply very precisely to my
interrogations.

I shall add some comments, citing only some parts of the previous
e-mail.

Jonas Smedegaard a écrit :
[ ... some parts are not cited ... ]
> Fine that a source package contains sources for a fork of another
> project, when the fork is intended for use uniquely as part of this
> project.

I compared the fork to its upstream: most of changes are beautification
(better usage of indentation, and so on). The only significant change is
the use of Math.ceil() to ensure that a value will be an integer, where
upstream code does not take that precaution.

> Also, to answer your (inmplied) question: Yes, I do find it beneficial
> that our users could do "apt install libjs-gumshoe".

Gumshoe.js is a rather short script, less than 500 lines. However, its
author has taken the time to distribute it through
https://www.npmjs.com, and the downloads are significant. So, I agree,
it is worth packaging it in Debian.

> Your composing a patch which involves tools like pip and webpack (with
> code-pulling plugins) is the reason for my raising concerns here:
> Essentially that means you get from source to generated code via helper
> code not in Debian.

I managed to build the CSS files with ruby's sass. I compared the
result with the previous non-debianish method, here is a summary of the
difference, after running css-beautify on both CSS outputs:

+---+--+
| debian way|   non-debian way |
+---+--+
| normalize.css is included | normalize.css is embedded|
+---+--+
| nested quotes are nicely rendered | barbarian quotes rendering   |
| example:  | example: |
| url('data:image/svg+xml;  | url("data:image/svg+xml; |
|  charset=utf-8, Nice that you review what the non-Debian helper code did, but still
> unacceptable: The process to get from source to generated form must
> happen purely with Debian tools (or by changes that you can reasonably
> claim to have done by hand, which 213k of auto-generated diff probably
> isn't).

The table above summarizes a manual review for files weighing approx.
60k; "manual" does not imply ineffective, when one uses beautifying
filters and emacs' ediff-buffer tool.

I compared CSS files issued by Ruby's sass and by sassc: they are quite
the same when filtered by the same beautifier; among the few
differences, the most notable is: decimal numbers writtent like .5
instead of 0.5.

The conclusion is that Sass compilers available in Debian miss one
single part of the source SASS code, the part which is about a
"preferred" black theme. I could use furo as a style for sphinx, to
build the latest version of package Sympy, which depends on it. The
result is correct after pure-debian packaging, and I found no difference
between the locally built HTML documentation and the official one,
available from https://docs.sympy.org/latest/index.html :)

So, building furo with pure debian tools is possible, and the result
is efficient. I uploaded a new release of package furo to the NEW queue.

---oOo---

Regarding the other suggestions you made, Jonas, I would like a few more
precisions:

- you would like to see SASS files distributed under /usr/share/sass; is
  it sufficient to shape the packaging so it produces two binary
  packages, "furo" for the sphinx style, and "sass-stylesheets-furo"
  for SASS stuff? Or would it be sufficient to make a single "furo"
  binary, which stores SASS files under /usr/share/sass, and provides a
  virtual package name sass-stylesheets-furo?

- you would like to see gumshoe.js packaged separately in Debian. I can
  issue an ITP for it. Do you estimate that making a package
  node-gumshoe is worth the effort, and the storage cost, for debian
  servers? Remember that the flesh in this package is a 500-liner
  script.

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#1023200: va-driver-all: buggy or unstable behavior on older i965 GPU

[Sebastian Ramacher]

On 2022-10-31 15:04:10 +0100, Eduard Bloch wrote:
> Package: va-driver-all
> Version: 2.16.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> Please dispatch this ticket as you see fit. I report this against 
> va-driver-all
> since it seems to have indirectly lead to the trouble, and there is no README
> in va-driver-all which would explain the rules of the game.
> 
> My system has been working fine with Sid until a couple of months ago. IIRC,
> last year I checked the vainfo config and eventually enabled it even in 
> Firefox
> (Chrome was fine out of the box).
> 
> However, now the CPU consumption in Chrome is back to high in Video playback,
> feels like the GPU acceleration started failing silently. Investigation on the
> issue has caused trobule, see below. And setting popular env. vars like
> MESA_LOADER_DRIVER_OVERRIDE=i965 did not help.
> 
> Hardware:
> 
> Lenovo X250 (older revision)
> 
> 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
> 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
> 00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
> 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI 
> Controller (rev 03)
> 00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI 
> Controller #1 (rev 03)
> 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (3) 
> I218-LM (rev 03)
> 00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition 
> Audio Controller (rev 03)
> 00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port 
> #6 (rev e3)
> 00:1c.1 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port 
> #3 (rev e3)
> 00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI 
> Controller (rev 03)
> 00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
> 00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller 
> [AHCI Mode] (rev 03)
> 00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
> 00:1f.6 Signal processing controller: Intel Corporation Wildcat Point-LP 
> Thermal Management Controller (rev 03)
> 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI 
> Express Card Reader (rev 01)
> 03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 99)
> 
> Situation 1:
> 
> va-driver-all is installed (that installs intel-media-va-driver; see below 
> for intel-media-va-driver-nonfree effects).
> 
> Result:
> 
> on some H264 videos, VLC is not accelerated, framerate is terrible, like 2-5 
> fps.
> On bigger ones, VLC simply crashes. Where? Here:
> 
> Module libudev.so.1 from deb systemd-252~rc3-2.amd64
> Module libsystemd.so.0 from deb systemd-252~rc3-2.amd64
> Stack trace of thread 3269:
> #0  0x7f4eca507730 
> _Z21mos_bo_wait_renderingP12mos_linux_bo (iHD_drv_video.so + 0x107730)
> #1  0x7f4eca718db9 
> _ZN14DdiMediaDecode12CreateBufferE12VABufferTypejjPvPj (iHD_drv_video.so + 
> 0x318db9)
> #2  0x7f4eca6fe0ac 
> _Z21DdiMedia_CreateBufferP15VADriverContextj12VABufferTypejjPvPj 
> (iHD_drv_video.so + 0x2fe0ac)
> #3  0x7f4f38c9e870 vaCreateBuffer (libva.so.2 + 0x6870)
> #4  0x7f4f0060ab85 n/a (libvdpau_va_gl.so.1 + 0xab85)
> #5  0x7f4f0060b2ac n/a (libvdpau_va_gl.so.1 + 0xb2ac)
> #6  0x7f4f0060b879 n/a (libvdpau_va_gl.so.1 + 0xb879)
> #7  0x7f4f1f200f78 n/a (libavcodec.so.59 + 0x800f78)
> #8  0x7f4f1f2028b4 n/a (libavcodec.so.59 + 0x8028b4)
> #9  0x7f4f1ed8a28c n/a (libavcodec.so.59 + 0x38a28c)
> #10 0x7f4f1ed9ff3e n/a (libavcodec.so.59 + 0x39ff3e)
> #11 0x7f4f1f06756b n/a (libavcodec.so.59 + 0x66756b)
> #12 0x7f4f7628784a start_thread (libc.so.6 + 0x8784a)
> #13 0x7f4f7630b2cc __clone3 (libc.so.6 + 0x10b2cc)
> 
> Before it brings:
> 
> VLC media player 3.0.18-rc2 Vetinari (revision 3.0.13-8-g41878ff4f2)
> [55f30ff19610] main libvlc: VLC wird mit dem Standard-Interface 
> ausgeführt. Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden.
> libGL error: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: Kann 
> die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden 
> (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, 
> suffix _dri)
> libGL error: failed to load driver: i965
> [55f30fff2db0] main audio output error: too low audio sample frequency (0)
> [7ff9e4c96810] main decoder error: failed to create audio output
> [55f30fff2db0] vlcpulse audio output error: digital pass-through stream 
> connection failure: Eingabe/Ausgabe-Fehler
> [55f30fff2db0] main audio output error: module not functional
> [7ff9e4c96810] main 

Bug#1023555: fastnetmon: FTBFS with libbpf 1.0

[Sudip Mukherjee]

On Sun, Nov 6, 2022 at 3:51 PM Sebastian Ramacher  wrote:
>
> Source: fastnetmon
> Version: 1.2.3-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org, sudipm.mukher...@gmail.com
>
> https://buildd.debian.org/status/fetch.php?pkg=fastnetmon=amd64=1.2.3-1%2Bb1=1667748889=0

oops, sorry I missed it in my list of packages depending on libbpf. It
seems "fastnetmon" added the dependency on libbpf with the last upload
and I generated my list before that.   :(

Please let me know if you want me to help with a patch to port the
code to libbpf.


-- 
Regards
Sudip

Bug#1023563: linux-image-5.10.0-19-amd64: Ephemeral ports are reused too quickly, even when net.ipv4.tcp_tw_reuse = 0

[Markus Wernig]

Package: linux-image-5.10.0-19-amd64
Version: 5.10.149-2
Severity: important

Dear Maintainer,

Starting with linux-image-5.10.0-15-amd64 (5.10.120-1), it seems that
the kernel is reusing ephemeral tcp ports too quickly, even if
net.ipv4.tcp_tw_reuse is set to 0.

linux-image-5.10.0-14-amd64 (5.10.113-1) and all earlier versions did
not show that behaviour.

The behaviour is the same for IPv4 and IPv6.

* What led up to the situation?

I have a couple of medium-to-fairly busy web servers that open TCP
sessions (~15-20 new connections per second) to a dedicated port on a backend 
server. 
The connections are short-lived and terminated by the backend server
after 1 second on average.
This setup has been working for many years through many Debian releases
and kernel versions.

On July 2 2022 I updated (apt update) the systems, which upgraded the
linux kernel image from 5.10.0-14 to 5.10.0-15. 

Shortly afterwards I noticed an increasing number of connection errors
being reported by the web servers (timeouts).

Further analysis (mostly with tcpdump) showed that the web servers
had started reusing ephemeral TCP ports as shortly as 30 seconds after their
last use. At that time (30 sec) the backend server (which is also Debian) still
had the corresponding sockets in the TIME_WAIT status and replied to the
new SYN packet with an ACK instead of a SYN ACK (this is of course
normal behaviour, since the socket was still open). The web server did
not expect the ACK and discarded it, occasionally resending the SYN,
until a timeout occurred.

The choice of ephemeral source ports appeared quite erratic. For some
seconds they were chosen in ascending order as expected, then
seemed to jump back to some lower position, proceed in ascending order
from there again, then jump back to the higher position from where they
had left off before etc.

* What exactly did you do (or not do) that was effective (or
  ineffective)?

I first raised the port range for the ephemeral ports by setting
net.ipv4.ip_local_port_range=1024 60999 (from the default 32768 60999).
This alleviated the situation (so that the timeouts became less
frequent), but did not solve the problem.

I then set net.ipv4.tcp_tw_reuse = 0 (from the default 2), which did not
change anything (as is expected in this case).

* What was the outcome of this action?

None of the measures I took proved effective. 

So I downgraded the kernel to 5.10.0-14, and the problem immediately
went away. The web servers now cycle through the available ~6
ephemeral ports and come around to reusing them long after the socket
on the backend server has been closed.


I am opening this bug here because I am not knowledgeable enough about
the Debian kernel patches to decide whether or not this issue is already
present in the upstream vanilla kernel.

Thank you for looking into this.

Best regards

Markus Wernig

-- 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-14-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-5.10.0-14-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-14-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-14-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-3~deb11u2
pn  linux-doc-5.10  

Bug#1019610: ruby-ahoy-email: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: cannot load such file -- net/smtp (LoadError)

[Adrian Bunk]

On Fri, Oct 07, 2022 at 02:16:35PM -0300, Antonio Terceiro wrote:
>...
> But nothing in ruby-ahoy-email codebase uses net/smtp explicitly, so
> this is a bit weird.
>...

$ cat 
/usr/share/rubygems-integration/all/gems/actionmailer-6.1.7/lib/action_mailer/mail_with_error_handling.rb
# frozen_string_literal: true

begin
  require "mail"
rescue LoadError => error
  if error.message.match?(/net\/smtp/)
$stderr.puts "You don't have net-smtp installed in your application. Please 
add it to your Gemfile and run bundle install"
raise
  end
end
$


There is also something that might be related in
https://sources.debian.org/src/rails/2%3A6.1.7%2Bdfsg-2/Gemfile/#L140

Is there a bug in rails?

cu
Adrian

Bug#1023564: RFH: libuser -- user and group account administration library

[Boyuan Yang]

Package: wnpp
Severity: normal
X-Debbugs-CC: debian-de...@lists.debian.org
Control: affects -1 libuser

Hi all,

I request help in (co-)maintaining package libuser [1], a user and group
account administration library originated from Fedora side with high popcon
(~1).

The most urgent need is handling the recent FTBFS bug [2] caused by a failed
test. Some knowledge about user account management is needed. Besides,
enabling LDAP support is also a long overdue task. [3]

Any help is welcome, and feel free if you want to be a co-maintainer of this
package or have it moved to any team maintenance.

Thanks,
Boyuan Yang


[1] https://tracker.debian.org/pkg/libuser
[2] https://bugs.debian.org/1022344
[3] https://bugs.debian.org/660847


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

Bug#1016562: [Pkg-pascal-devel] Bug#1016562: fp-compiler-3.2.0: Fails to setup during install due to "Invalid floating point operation"

[Abou Al Montacir]

Hi Graham,

> I was trying to install the Free Pascal Compiler on Debian 11 running under
> VMware Fusion on an Mac
> with an M2 processor.
Can you please tell if you can reproduce using qemu or at least provide
instruction ho to run VMware for that purpose?
Can you confirm this is an ARM Cortex-M2 processor? Do that have an FPU?
-- 
Cheers,
Abou Al Montacir


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

Bug#1023562: dpkg-buildflags: hardening: add stack clash protection

[Christian Göttsche]

Package: dpkg-dev
Version: 1.21.9
Tags: security

Please consider to add stack clash protection to the hardening
options. The related flag, `-fstack-clash-protection`, is supported by
GCC since version 8 and Clang since version 10 (x86 only).
More details on the functionality iself:
https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gcc-part-3
https://blog.llvm.org/posts/2021-01-05-stack-clash-protection/

Bug#941132: 1.3.3-1: Decode now causes file error on external device

[Martijn van Beurden]

The option --force-legacy-wave-format has been added to development
FLAC, not yet in any released FLAC version though. Using this option
on decoding will probably solve this problem.

Bug#1022126: mpt3sas broken with xen dom0

[Radoslav Bodó]

to be a bit more precise (sorry for being a bit sloopy). we don't see 
same error with `swiotlb buffer` but rather


```
mpt3sas_cm0: failure at 
drivers/scsi/mpt3sasg/mpt3sas_scsih.c:11069/_scsih_probe()!

```
as reported in `1023...@bugs.debian.org`



```
# dmesg | grep mpt
[0.233229]   Normal   empty
[0.233231]   Device   empty
[0.642600] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[0.642676] TAA: Vulnerable: Clear CPU buffers attempted, no microcode
[0.642752] MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, 
no microcode

[3.243654] mpt3sas version 35.100.00.00 loaded
[3.244357] mpt3sas_cm0: 32 BIT PCI BUS DMA ADDRESSING SUPPORTED, 
total mem (917052 kB)
[3.302439] mpt3sas_cm0: CurrentHostPageSize is 0: Setting default 
host page size to 4k

[3.302575] mpt3sas_cm0: MSI-X vectors supported: 96
[3.302733] mpt3sas_cm0:  0 40
[3.308666] mpt3sas_cm0: High IOPs queues : disabled
[3.308747] mpt3sas0-msix0: PCI-MSI-X enabled: IRQ 396
[3.308826] mpt3sas0-msix1: PCI-MSI-X enabled: IRQ 397
[3.308905] mpt3sas0-msix2: PCI-MSI-X enabled: IRQ 398
[3.308983] mpt3sas0-msix3: PCI-MSI-X enabled: IRQ 399
[3.309062] mpt3sas0-msix4: PCI-MSI-X enabled: IRQ 400
[3.309141] mpt3sas0-msix5: PCI-MSI-X enabled: IRQ 401
[3.309221] mpt3sas0-msix6: PCI-MSI-X enabled: IRQ 402
[3.309224] mpt3sas0-msix7: PCI-MSI-X enabled: IRQ 403
[3.309466] mpt3sas0-msix8: PCI-MSI-X enabled: IRQ 404
[3.309544] mpt3sas0-msix9: PCI-MSI-X enabled: IRQ 405
[3.309623] mpt3sas0-msix10: PCI-MSI-X enabled: IRQ 406
[3.309703] mpt3sas0-msix11: PCI-MSI-X enabled: IRQ 407
[3.309706] mpt3sas0-msix12: PCI-MSI-X enabled: IRQ 408
[3.309945] mpt3sas0-msix13: PCI-MSI-X enabled: IRQ 409
[3.310024] mpt3sas0-msix14: PCI-MSI-X enabled: IRQ 410
[3.310104] mpt3sas0-msix15: PCI-MSI-X enabled: IRQ 411
[3.310183] mpt3sas0-msix16: PCI-MSI-X enabled: IRQ 412
[3.310186] mpt3sas0-msix17: PCI-MSI-X enabled: IRQ 413
[3.310427] mpt3sas0-msix18: PCI-MSI-X enabled: IRQ 414
[3.310506] mpt3sas0-msix19: PCI-MSI-X enabled: IRQ 415
[3.310585] mpt3sas0-msix20: PCI-MSI-X enabled: IRQ 416
[3.310588] mpt3sas0-msix21: PCI-MSI-X enabled: IRQ 417
[3.310827] mpt3sas0-msix22: PCI-MSI-X enabled: IRQ 418
[3.310906] mpt3sas0-msix23: PCI-MSI-X enabled: IRQ 419
[3.310985] mpt3sas0-msix24: PCI-MSI-X enabled: IRQ 420
[3.310988] mpt3sas0-msix25: PCI-MSI-X enabled: IRQ 421
[3.316842] mpt3sas0-msix26: PCI-MSI-X enabled: IRQ 422
[3.316845] mpt3sas0-msix27: PCI-MSI-X enabled: IRQ 423
[3.317008] mpt3sas0-msix28: PCI-MSI-X enabled: IRQ 424
[3.317011] mpt3sas0-msix29: PCI-MSI-X enabled: IRQ 425
[3.317180] mpt3sas0-msix30: PCI-MSI-X enabled: IRQ 426
[3.317182] mpt3sas0-msix31: PCI-MSI-X enabled: IRQ 427
[3.317384] mpt3sas0-msix32: PCI-MSI-X enabled: IRQ 428
[3.317386] mpt3sas0-msix33: PCI-MSI-X enabled: IRQ 429
[3.317569] mpt3sas0-msix34: PCI-MSI-X enabled: IRQ 430
[3.317572] mpt3sas0-msix35: PCI-MSI-X enabled: IRQ 431
[3.317736] mpt3sas0-msix36: PCI-MSI-X enabled: IRQ 432
[3.317739] mpt3sas0-msix37: PCI-MSI-X enabled: IRQ 433
[3.317929] mpt3sas0-msix38: PCI-MSI-X enabled: IRQ 434
[3.317931] mpt3sas0-msix39: PCI-MSI-X enabled: IRQ 435
[3.318197] mpt3sas_cm0: iomem(0xac40), 
mapped(0xa634eda5), size(65536)

[3.318200] mpt3sas_cm0: ioport(0x6000), size(256)
[3.378171] mpt3sas_cm0: CurrentHostPageSize is 0: Setting default 
host page size to 4k
[3.406933] mpt3sas_cm0: scatter gather: sge_in_main_msg(1), 
sge_per_chain(7), sge_per_io(128), chains_per_io(19)
[3.412485] mpt3sas_cm0: failure at 
drivers/scsi/mpt3sasg/mpt3sas_scsih.c:11069/_scsih_probe()!

```

Bug#1023561: yubico-piv-tool: selfsign-certificate fails nondescriptively, update needed?

[Jamie Lentin]

Package: yubico-piv-tool
Version: 2.2.0-1.1
Severity: normal
X-Debbugs-Cc: j...@lentin.co.uk

Dear Maintainer,

I tried following the instructions to set up a Yubikey 5C Nano, firmware 5.4.3,
with PIV:

  https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PKCS11.html

$ ykman piv reset
WARNING! This will delete all stored PIV data and restore factory settings. 
Proceed? [y/N]: y
Resetting PIV data...
Success! All PIV data have been cleared from the YubiKey.
Your YubiKey now has the default PIN, PUK and Management Key:
PIN:123456
PUK:12345678
Management Key: 010203040506070801020304050607080102030405060708

$ yubico-piv-tool --version
yubico-piv-tool 2.2.0
$ yubico-piv-tool -s 9a -a generate -o public.pem
Successfully generated a new private key.
$ yubico-piv-tool -a verify-pin -a selfsign-certificate -s 9a -S "/CN=SSH key/" 
-i public.pem -o cert.pem
Enter PIN:
Successfully verified PIN.
Failed signing certificate.

Not entirely dissimilar to the upstream issue 185[0], however there is no wait
for a button press. Trying the same commands from upstream master 75188af,
compiling upstream as per README instructions[1], works fine:

$ ./tool/yubico-piv-tool --version
yubico-piv-tool 2.3.0
$ ./tool/yubico-piv-tool -s 9a -a generate -o public.pem
Successfully generated a new private key.
$ ./tool/yubico-piv-tool -a verify-pin -a selfsign-certificate -s 9a -S
"/CN=SSH key/" -i public.pem -o cert.pem
Enter PIN:
Successfully verified PIN.
Successfully generated a new self signed certificate.

NB: The tagged version yubico-piv-tool-2.3.0 fails to compile.

Does the package need updating? Is the Yubikey documentation not valid for
2.2.0, or am I just being dumb?

Cheers,

[0] https://github.com/Yubico/yubico-piv-tool/issues/185
[1] https://github.com/Yubico/yubico-piv-tool

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

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

Versions of packages yubico-piv-tool depends on:
ii  libc6  2.36-4
ii  libssl33.0.7-1
ii  libykpiv2  2.2.0-1.1

yubico-piv-tool recommends no packages.

yubico-piv-tool suggests no packages.

-- no debconf information

Bug#1022126: mpt3sas driver does not load

[Radoslav Bodó]

Hello,

we are facing very same issue (kernel 5.10.149-2 does not load driver 
with same error message) on Dell R440 with ME4012 disk array attached 
via HBA


(taken from working 5.10.136-1)
[3.744036] mpt3sas_cm0: FW Package Ver(15.17.09.06)
[3.744740] mpt3sas_cm0: LSISAS3008: FWVersion(15.15.06.00), 
ChipRevision(0x02), BiosVersion(17.07.01.00)


we are also using xen 4.14.5+24-g87d90d511c-1

I've tried workaround found elsewhere (add kernel parameter 
mpt3sas.max_queue_depth=1) without success.


Any suggestion would be appreciated.
bodik

Bug#1014460: transition: php8.2

[Robin Gustafsson]

The test failures in php-faker are caused by a bug in PHP [1] that has
been fixed since 8.2.0 RC5 [2]. They can be ignored, assuming we're
not shipping RC5.

[1] https://github.com/FakerPHP/Faker/pull/528#issuecomment-1292745178
[2] 
https://github.com/php/php-src/commit/7f0b228f48ad29c13a84dc8c8bc050f34d3a855a

Regards,
Robin

Bug#1023353: [php-faker] Failing tests with PHP 8.2

[Robin Gustafsson]

This is caused by a bug in PHP [1] and has been fixed after 8.2.0 RC5
[2]. I'll wait for the next PHP version.

[1] https://github.com/FakerPHP/Faker/pull/528#issuecomment-1292745178
[2] 
https://github.com/php/php-src/commit/7f0b228f48ad29c13a84dc8c8bc050f34d3a855a

Regards,
Robin

Bug#1023183: mpt3sas driver does not load

[Radoslav Bodó]

Hello,

we are facing very same issue (kernel 5.10.149-2 does not load driver 
with same error message) on Dell R440 with ME4012 disk array attached 
via HBA


(taken from working 5.10.136-1)
[3.744036] mpt3sas_cm0: FW Package Ver(15.17.09.06)
[3.744740] mpt3sas_cm0: LSISAS3008: FWVersion(15.15.06.00), 
ChipRevision(0x02), BiosVersion(17.07.01.00)


we are also using xen 4.14.5+24-g87d90d511c-1

I've tried workaround found elsewhere (add kernel parameter 
mpt3sas.max_queue_depth=1) without success.


Any suggestion would be appreciated.
bodik

Bug#1023560: RM: guile-2.2 -- ROM; replaced by guile-3.0

[Rob Browning]

Package: ftp.debian.org
User: release.debian@packages.debian.org
Usertags: rm 

I think guile-2.2 has already been removed from testing (which is
*great*), and now I'd like to finally remove it from unstable if that's
feasible.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#1023559: show with no arguments

[Dan Jacobson]

Package: aptitude
Version: 0.8.13-5
Severity: wishlist

$ aptitude show
with no arguments should print a usage message.

Bug#1020214: zimlib: diff for NMU version 8.0.0-2.1

[Sebastian Ramacher]

Control: tags 1020214 + patch
Control: tags 1020214 + pending

Dear maintainer,

I've prepared an NMU for zimlib (versioned as 8.0.0-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru zimlib-8.0.0/debian/changelog zimlib-8.0.0/debian/changelog
--- zimlib-8.0.0/debian/changelog	2022-08-28 19:58:55.0 +0200
+++ zimlib-8.0.0/debian/changelog	2022-11-06 18:21:21.0 +0100
@@ -1,3 +1,11 @@
+zimlib (8.0.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Drop unnecessary Conflicts+Replaces on old library
+versions (Closes: #1020214)
+
+ -- Sebastian Ramacher   Sun, 06 Nov 2022 18:21:21 +0100
+
 zimlib (8.0.0-2) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru zimlib-8.0.0/debian/control zimlib-8.0.0/debian/control
--- zimlib-8.0.0/debian/control	2022-08-20 03:05:35.0 +0200
+++ zimlib-8.0.0/debian/control	2022-11-06 18:19:53.0 +0100
@@ -26,8 +26,6 @@
  ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Breaks: python3-libzim (<< 0.0.3-2)
-Conflicts: libzim0, libzim0v5, libzim2, libzim4, libzim5, libzim6, libzim7
-Replaces: libzim0, libzim0v5, libzim2, libzim4, libzim5, libzim6, libzim7
 Description: library implementation of ZIM specifications
  ZIM (Zeno IMproved) is an open file format for storing the contents of
  wiki for offline usage. This file format is primarily focused on

Bug#1023558: dictionaries-common: installation fails with emacs23

[Tatsuya Kinoshita]

Package: dictionaries-common
Version: 1.28.18
Severity: wishlist
Tags: patch

Please skip byte-compilation when emacs23.

This bug is "wishlist", because current official GNU Emacs flavor
is only "emacs".  However, I personally use unofficial flavors,
"emacs-snapshot", "emacs28", "emacs24", "emacs23", and so on.

Installing dictionaries-common with "emacs23" fails with this bug
because of Emacs incompatibility.

```
--- a/debian/emacsen-install
+++ b/debian/emacsen-install
@@ -25,7 +25,7 @@ case "$flavour" in
 xemacs*)
flags="-no-site-file"
;;
-emacs19|emacs20|emacs21|emacs22|emacs-snapshot*)
+emacs19|emacs20|emacs21|emacs22|emacs23|emacs-snapshot*)
# Do not byte-compile anything for above emacsen flavours
echo "install/${package}: Skipping byte-compilation for $flavour"
exit 0
```

Thanks,
--
Tatsuya Kinoshita


pgpo2iRhMLXPN.pgp
Description: PGP signature

Bug#1023557: rygel: consider After=network.target in rygel.service for lingering

[Barak A. Pearlmutter]

Package: rygel
Version: 0.42.0-2

Dear Maintainer,

Thanks for maintaining Rygel. It's made our big TV useful! And tablets!
Everyone on the local network is happy!

To keep everyone happy, I turned on lingering for the involved user (me)

$ loginctl enable-linger $(whoami)

and enabled rygel. This causes rygel to start when the machine boots,
instead of waiting for me to log in.

One tiny problem: rygel starts before the network is up, gets an error
having to do with the network not being set up, and apparently fails
to announce itself on the local network, so nobody can watch videos or
listen to music. Which makes everyone in the house sad until I log in
and

$ systemctl --user restart rygel.service

which is a hassle.

I *think* the right way to solve this is by adding a line

  After=network.target

to the rygel unit file, /usr/lib/systemd/user/rygel.service

Cheers,

--Barak.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (550, 'testing'), (500, 'stable-updates'), (500,
'proposed-updates'), (500, 'stable'), (450, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages rygel depends on:
ii  init-system-helpers 1.65.2
ii  libc6   2.36-4
ii  libgdk-pixbuf-2.0-0 2.42.9+dfsg-1
ii  libgee-0.8-20.20.6-1
ii  libges-1.0-01.20.3-1
ii  libglib2.0-02.74.1-1
ii  libgssdp-1.6-0  1.6.0-3
ii  libgstreamer-plugins-base1.0-0  1.20.3-2
ii  libgstreamer1.0-0   1.20.3-1
ii  libgupnp-1.6-0  1.6.0-3
ii  libgupnp-av-1.0-3   0.14.1-1
ii  libgupnp-dlna-2.0-4 0.12.0-3
ii  libmediaart-2.0-0   1.9.6-1
ii  librygel-core-2.8-0 0.42.0-2
ii  librygel-db-2.8-0   0.42.0-2
ii  librygel-renderer-2.8-0 0.42.0-2
ii  librygel-server-2.8-0   0.42.0-2
ii  libsoup-3.0-0   3.2.1-2
ii  libsqlite3-03.39.4-1
ii  libx11-62:1.8.1-2
ii  libxml2 2.9.14+dfsg-1+b1

Versions of packages rygel recommends:
ii  dbus-user-session  1.14.4-1
ii  gstreamer1.0-libav 1.20.3-1+b1
ii  gstreamer1.0-plugins-base  1.20.3-2
ii  gstreamer1.0-plugins-good  1.20.3-1+b1
ii  gstreamer1.0-plugins-ugly  1.20.3-1

Versions of packages rygel suggests:
ii  rygel-playbin  0.42.0-2
pn  rygel-preferences  
pn  rygel-ruih 
ii  rygel-tracker  0.42.0-2
ii  tumbler4.16.1-1

-- no debconf information

Bug#999296: tagcloud: diff for NMU version 1.4-1.3

[Marcos Talau]

Control: tags 999296 + patch
Control: tags 999296 + pending


Dear maintainer,

I've prepared an NMU for tagcloud (versioned as 1.4-1.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u tagcloud-1.4/debian/changelog tagcloud-1.4/debian/changelog
--- tagcloud-1.4/debian/changelog
+++ tagcloud-1.4/debian/changelog
@@ -1,3 +1,10 @@
+tagcloud (1.4-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999296).
+
+ -- Marcos Talau   Sun, 06 Nov 2022 13:35:39 -0300
+
 tagcloud (1.4-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u tagcloud-1.4/debian/rules tagcloud-1.4/debian/rules
--- tagcloud-1.4/debian/rules
+++ tagcloud-1.4/debian/rules
@@ -67,4 +67,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary

Bug#998965: spew: diff for NMU version 1.0.8-1.1

[Marcos Talau]

Control: tags 998965 + patch
Control: tags 998965 + pending


Dear maintainer,

I've prepared an NMU for spew (versioned as 1.0.8-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u spew-1.0.8/debian/rules spew-1.0.8/debian/rules
--- spew-1.0.8/debian/rules
+++ spew-1.0.8/debian/rules
@@ -105,4 +105,8 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install 
+
+build-arch: build
+build-indep: build
+
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install
diff -u spew-1.0.8/debian/changelog spew-1.0.8/debian/changelog
--- spew-1.0.8/debian/changelog
+++ spew-1.0.8/debian/changelog
@@ -1,3 +1,10 @@
+spew (1.0.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #998965).
+
+ -- Marcos Talau   Sun, 06 Nov 2022 13:31:22 -0300
+
 spew (1.0.8-1) unstable; urgency=low
 
   * New upstream release. ( Closes: #560523 )

Bug#1020258: Bug#1020525: ddskk: fails to install with emacs 1.28

[Tatsuya Kinoshita]

On 2022-09-22 at 19:23 +0200, Andreas Beckmann wrote:
> (This could be another instance of #1020258, but there is no output
> from the actual error available in the log.)

As you say, it seems affected by #1020258.

```
  emacsen-common: Handling install of emacsen flavor emacs
  Install ddskk for emacs
  install/ddskk: Handling install for emacsen flavor emacs
  Loading /usr/share/emacs/site-lisp/ddskk/SKK-CFG...
  *** WARNING: Adding advice to subr keyboard-quit without mirroring its 
interactive spec ***
  Eager macro-expansion failure: (native-compiler-error (lambda () 
(let ((f #'abort-recursive-edit)) (funcall f))) "Loading 
/etc/emacs/site-start.d/00debian.el (source)...
  Loading /etc/emacs/site-start.d/50ddskk.el (source)...
  Compiling 
/root/.emacs.d/eln-cache/28.2-310448e3/subr--trampoline-61626f72742d7265637572736976652d65646974_abort_recursive_edit_0.eln...
  ld: cannot find crti.o: No such file or directory
  libgccjit.so: error: error invoking gcc driver
  Debugger entered--Lisp error: (native-ice \"failed to compile\" 
\"/root/.emacs.d/eln-cache/28.2-310448e3/subr--tramp...\" \"error invoking gcc 
driver\")

comp--compile-ctxt-to-file(\"/root/.emacs.d/eln-cache/28.2-310448e3/subr--tramp...\")

comp-compile-ctxt-to-file(\"/root/.emacs.d/eln-cache/28.2-310448e3/subr--tramp...\")
comp-final1()

load-with-code-conversion(\"/tmp/emacs-int-comp-subr--trampoline-61626f72742d7...\"
 \"/tmp/emacs-int-comp-subr--trampoline-61626f72742d7...\" nil t)
command-line-1((\"-l\" 
\"/tmp/emacs-int-comp-subr--trampoline-61626f72742d7...\"))
command-line()
normal-top-level()
```

>   ld: cannot find crti.o: No such file or directory
>   libgccjit.so: error: error invoking gcc driver

BTW, crti.o is provided by libc6-dev.  When libc6-dev is installed,
this problem doesn't occur.

As a workaround, I've set (setq comp-enable-subr-trampolines nil)
in the install/ddskk script.

Thanks,
--
Tatsuya Kinoshita


pgpVUA9u4NtiI.pgp
Description: PGP signature

Bug#999332: libgcr410: diff for NMU version 2.4.0-9.3

[Marcos Talau]

Control: tags 999332 + patch
Control: tags 999332 + pending


Dear maintainer,

I've prepared an NMU for libgcr410 (versioned as 2.4.0-9.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u libgcr410-2.4.0/debian/changelog libgcr410-2.4.0/debian/changelog
--- libgcr410-2.4.0/debian/changelog
+++ libgcr410-2.4.0/debian/changelog
@@ -1,3 +1,10 @@
+libgcr410 (2.4.0-9.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999332).
+
+ -- Marcos Talau   Sun, 06 Nov 2022 13:24:39 -0300
+
 libgcr410 (2.4.0-9.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u libgcr410-2.4.0/debian/rules libgcr410-2.4.0/debian/rules
--- libgcr410-2.4.0/debian/rules
+++ libgcr410-2.4.0/debian/rules
@@ -41,4 +41,7 @@
 
 binary: binary-indep binary-arch
 
+build-arch: build
+build-indep: build
 
+.PHONY: binary binary-arch binary-indep build build-arch build-indep clean install

Bug#1023556: coreutils: enable all hardening options

[Christian Göttsche]

Source: coreutils
Version: 9.1-1
Tags: patch

The coreutils are currently build with the BINDNOW hardening feature missing.
From b25f20eab82d7544fb9c09b806a1b9e518bc99de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20G=C3=B6ttsche?=
 
Date: Sun, 6 Nov 2022 17:16:16 +0100
Subject: [PATCH] d/rules: enable all hardening flags

In particular the BINDNOW linker flag is current missing.
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index ddb98cb..db2dbdb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,7 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk
 
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DEB_CFLAGS_MAINT_APPEND = -DSYSLOG_SUCCESS -DSYSLOG_FAILURE -DSYSLOG_NON_ROOT
 
 # Renesas SH(sh4) need -mieee option.
-- 
2.38.1

Bug#1023531: utox: autopkgtest regression on s390x: test_chrono fails

[Aurelien Jarno]

On 2022-11-06 08:12, Paul Gevers wrote:
> Source: utox
> Version: 0.18.1-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainer(s),
> 
> Your package has an autopkgtest, great. With a recent upload of glibc it
> started to fail on s390x. Looking at the history [1], I noticed that
> apparently the test can flip from passing for a while to failing for a while
> and back. Unfortunately, we don't keep the logs so long to inspect if
> previous (pre August 2022) failures were due to the same reason.
> Unfortunately, the output of the failure is rather limited (it seems there
> is more info logged, but that log file is not echoed to the autopkgtest log
> or stored as an autopkgtest artifact.
> 
> Can you please investigate the situation? At least this is a autopkgtest
> regression on a release architecture, but maybe (hopefully?) this points at
> more severe issues.
> 
> If you find out that it's really a regression in glibc functionality and the
> upload doesn't "just" trigger faulty behavior in utox, don't hesitate to
> reassign to glibc. Also, don't hesitate to contact the s390x porters if you
> need help figuring out this s390x specific issue.

For the record, this is the contect of the log file:

2/2 Testing: test_chrono
2/2 Test: test_chrono
Command: "/home/aurel32/utox-0.18.1/build/tests/test_chrono"
Directory: /home/aurel32/utox-0.18.1/build/tests
"test_chrono" start time: Nov 06 10:53 UTC
Output:
--
Running suite(s): Chrono

=
==778737==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x3ffa94b9173 in __interceptor_malloc 
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x2aa138068cd in emalloc 
(/home/aurel32/utox-0.18.1/build/tests/test_chrono+0x68cd)

Indirect leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x3ffa94b9173 in __interceptor_malloc 
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x2aa138068cd in emalloc 
(/home/aurel32/utox-0.18.1/build/tests/test_chrono+0x68cd)

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s).

=
==778740==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x3ffa94b9173 in __interceptor_malloc 
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x2aa138068cd in emalloc 
(/home/aurel32/utox-0.18.1/build/tests/test_chrono+0x68cd)

Indirect leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x3ffa94b9173 in __interceptor_malloc 
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x2aa138068cd in emalloc 
(/home/aurel32/utox-0.18.1/build/tests/test_chrono+0x68cd)

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s).
0%: Checks: 2, Failures: 0, Errors: 2
/home/aurel32/utox-0.18.1/tests/test_chrono.c:59:E:chrono_target:test_chrono_target:0:
 (after this point) Early exit with return value 1
/home/aurel32/utox-0.18.1/tests/test_chrono.c:71:E:chrono_callback:test_chrono_callback:0:
 (after this point) Early exit with return value 1

Test time =   0.06 sec
--
Test Failed.
"test_chrono" end time: Nov 06 10:53 UTC
"test_chrono" time elapsed: 00:00:00
--

End testing: Nov 06 10:53 UTC

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#999308: xplot: diff for NMU version 1.19-9.1

[Marcos Talau]

Control: tags 999308 + patch
Control: tags 999308 + pending


Dear maintainer,

I've prepared an NMU for xplot (versioned as 1.19-9.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru xplot-1.19/debian/changelog xplot-1.19/debian/changelog
--- xplot-1.19/debian/changelog	2010-05-27 22:00:50.0 -0300
+++ xplot-1.19/debian/changelog	2022-11-06 13:18:50.0 -0300
@@ -1,3 +1,10 @@
+xplot (1.19-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Add build-{arch,indep} (Closes: #999308).
+
+ -- Marcos Talau   Sun, 06 Nov 2022 13:18:50 -0300
+
 xplot (1.19-9) unstable; urgency=low
 
   * Build against libforms2.
diff -Nru xplot-1.19/debian/rules xplot-1.19/debian/rules
--- xplot-1.19/debian/rules	2010-05-27 21:59:00.0 -0300
+++ xplot-1.19/debian/rules	2022-11-06 13:18:50.0 -0300
@@ -60,4 +60,7 @@
 	$(checkdir)
 	test root = "`whoami`"
 
-.PHONY: binary binary-arch binary-indep clean checkroot
+build-arch: build
+build-indep: build
+
+.PHONY: build-arch build-indep binary binary-arch binary-indep clean checkroot

Bug#1021082: bash: missing BINDNOW build hardening

[Christian Göttsche]

control: tags -1 patch,security
From 753f695a3b51a712fea42b554c719fe16da3b11d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20G=C3=B6ttsche?=
 
Date: Sun, 6 Nov 2022 16:39:50 +0100
Subject: [PATCH] d/rules: enable hardening

In particular the BINDNOW linker flag is currently missing.
---
 debian/changelog | 7 +++
 debian/rules | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 05ccd20..3c29a4c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+bash (5.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Enable all hardening flags. Closes: #1021082.
+
+ -- Christian Göttsche   Sun, 06 Nov 2022 17:01:23 +0100
+
 bash (5.2-2) unstable; urgency=medium
 
   * Apply upstream patches 001 - 002.
diff --git a/debian/rules b/debian/rules
index fb9b6bc..bb397ed 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,7 +41,7 @@ else
 endif
 
 
-dpkg_buildflags = DEB_CFLAGS_MAINT_APPEND="-Wall" dpkg-buildflags
+dpkg_buildflags = DEB_BUILD_MAINT_OPTIONS="hardening=+all" DEB_CFLAGS_MAINT_APPEND="-Wall" dpkg-buildflags
 CFLAGS := $(shell $(dpkg_buildflags) --get CFLAGS)
 CPPFLAGS := $(shell $(dpkg_buildflags) --get CPPFLAGS)
 LDFLAGS := $(shell $(dpkg_buildflags) --get LDFLAGS)
-- 
2.38.1

Bug#992304: possible workaround

[Claude Poitras]

On Fri, 4 Nov 2022 20:55:37 + Dan Stefura  
wrote:
> Try using the kernel parameter:  intel_iommu=off

It's work for me on Dell T140 with  PERC H330 Adapter

root@zurix:~# uname -a
Linux zurix 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/
Linux

Bug#1023555: fastnetmon: FTBFS with libbpf 1.0

[Sebastian Ramacher]

Source: fastnetmon
Version: 1.2.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org, sudipm.mukher...@gmail.com

https://buildd.debian.org/status/fetch.php?pkg=fastnetmon=amd64=1.2.3-1%2Bb1=1667748889=0

/<>/src/xdp_plugin/xdp_collector.cpp: In function ‘void 
start_xdp_collection(process_packet_pointer)’:
/<>/src/xdp_plugin/xdp_collector.cpp:522:5: error: 
‘bpf_prog_load_attr’ was not declared in this scope; did you mean 
‘bpf_prog_load_opts’?
  522 | bpf_prog_load_attr prog_load_attr;
  | ^~
  | bpf_prog_load_opts
/<>/src/xdp_plugin/xdp_collector.cpp:523:5: error: 
‘prog_load_attr’ was not declared in this scope
  523 | prog_load_attr.prog_type = BPF_PROG_TYPE_XDP;
  | ^~
/<>/src/xdp_plugin/xdp_collector.cpp:529:24: error: 
‘bpf_prog_load_xattr’ was not declared in this scope; did you mean 
‘bpf_prog_load_opts’?
  529 | int bpf_load_res = bpf_prog_load_xattr(_load_attr, , 
_fd);
  |^~~
  |bpf_prog_load_opts
/<>/src/xdp_plugin/xdp_collector.cpp:594:28: error: 
‘bpf_set_link_xdp_fd’ was not declared in this scope; did you mean 
‘set_link_xdp_res’?
  594 | int set_link_xdp_res = bpf_set_link_xdp_fd(ifindex, prog_fd, 
opt_xdp_flags);
  |^~~
  |set_link_xdp_res
make[3]: *** [CMakeFiles/xdp_plugin.dir/build.make:79: 
CMakeFiles/xdp_plugin.dir/xdp_plugin/xdp_collector.cpp.o] Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:456: CMakeFiles/xdp_plugin.dir/all] Error 2

Cheers
-- 
Sebastian Ramacher

Bug#1010395: ITP: neom -- desktop IM client for the Matrix protocol

[Jonas Smedegaard]

0.0~git20220504 draft 1 needs embedding 121 crates (77 missing, 1 incomplete, 
17 outdated, 26 ahead); builds in ~35 minutes; basic functions (including 
reading E2EE messages) work

Main tasks now are to keep package up-to-date with upstream releases, and
to package more of the crates currently embedded.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary packages I built - then I will share those.

As developer (but no need to be official member of Debian!), you can
join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/matrix-team/neom/-/blob/debian/latest/debian/TODO


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#680619: nullmailer: The same goes for passwords

[lucio]

Package: nullmailer
Version: 1:2.2-3+b1
Followup-For: Bug #680619
Control: tags -1 ipv6

Same behavior happens with passwords: scripts strip square brackets from them 
too, regardless of the smarthost being an IPv6 address or anything else.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (900, 'stable'), (800, 'unstable'), (500, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 nullmailer depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libc6  2.35-4
ii  libgnutls303.7.8-2
ii  libstdc++6 12.2.0-3
ii  lsb-base   11.4
ii  sysvinit-utils [lsb-base]  3.05-6

nullmailer recommends no packages.

nullmailer suggests no packages.

-- debconf information excluded

Bug#995779: autopkgtest fails with sqlalchemy 1.4.23+ds1

[Charlemagne Lasse]

Control: tags 995779 + patch

This is the upstream merged fix for sqlalchemy 1.4:
https://gitlab.com/mailman/mailman/-/commit/c926e3d54680d4fac0648cde036368c699976038

Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts

[Lorenzo]

Hi,

> Ps. I appreciate all the work you're doing on the runit packages.
> Please don't take my occasionally vehement disagreement with some of
> your ideas personally.

Don't worry about this, feedback are useful to improve the package.
Thanks for taking the time to file bugs and followup, others probably
just don't bother.

>  1. openssh ships its /etc/sv/ssh directory, which gets symlinked to
> /etc/service during installation, but which never worked for me
> (unfortunately I didn't investigate, just replaced the symlink with
> one to my own /var/lib/svn-checkout/services/ssh);

(if I have to guess) please replace your /sbin/start-stop-daemon
(wrapper) with a symlink that points to
/lib/runit/start-stop-daemon.runit and try again the ssh service.
Invoke-run, in the attempt of replace the sysv instance and avoid
conflicts, calls /etc/init.d/foo stop. So when a wrapper is in place
the service down itself. The call is skipped when
/sbin/start-stop-daemon or /etc/init.d/foo are symlinks.

> neither will it pick up a syslogd that is not managed by runit. Maybe
> just try to see if something is listening on /dev/log in "check"?).

great idea, thanks. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023476
in case you have better suggestion than 'lsof'

> If it were possible to disable the "default-syslog" service
> conclusively, permanently, by creating something somewhere during
> installation, or writing a line into a file, that would be great.

Just try
# update-service disable /etc/sv/default-syslog
( what it does is to remove the /etc/service/default-syslog link and
  creates /etc//service/.default-syslog
then reinstall runit, the 'default-syslog' service will stay disabled
until you purge 'runit' package or you remove the .default-syslog link

> Being able to opt out completely of all Debian specific runit glue
> would be even better; I accept that it's convenient for new or casual
> users, but for me in particular it's mostly just frustrating due to
> it being different from upstream runit

I understand this, but please be more specific about 'Debian specific
runit glue' : for stage 1 and 3, I have added switches to use
alternative set of scripts. The intention was to experiment with native
runit scripts[1], but you can also use it to avoid 'run_sysv_scripts'.
For stage 2, you can skip run_svsv_scripts with a
'/etc/runit/no.emulate.sysv' flag file; also, you can use
'/etc/runit/default.runsvdir'. This one will basically prevent any
automation (enable/disable) on a service by any debian package for runit
services; restart of services linked in /etc/service during upgrades
will still work. What else?
(maybe you hope for less switches? I'm well available to discuss this,
but please open a separate bug)

> My first impression is you're trying to solve what is not a problem,
> and introducing unneeded complexity, where part of runit's appeal (at
> least for me) is its simplicity and straightforwardness. You're
> building extra layers around runit so that people who are familiar
> with runit per se aren't able to use the Debian runit packages
> without jumping through hoops. There may be good reasons, but
> personally, I don't like this direction.
> 
> I would just as soon manage my /etc/service/* symlinks without any
> package automation.

Ok, I mentioned the new layout because I thought it could help to solve
your issue but it looks like it's not the case, so let's stop discussing
this here, otherwise the bug becomes hard to follow for readers.

Now, back to the main subject:
> For us, IIUC, the important question now is how to handle explicitly
> disabled services in the runit SysV emulation, right? I'd be fine
> with the following:
> 
> 1. if no /etc/service/foo symlink exists, the admin explicitly
> disabled runit management of service foo. (No argument there, I
> think?)

From your point of view, yes; from the package(r) point of view, a
missing link can be

1. the package that ships the runscript was never installed, so the
link has to be created (the default in Debian is usually to enable a
service at first install)

2. the package that ship the runscript is upgraded, and the admin
removed the link (it want it disabled).

In order to separate this two cases, and allow the admin to say "I
want this to stay disabled and the setting to persist untill purge" the
dot-link convention was created.

> 
> 2. to also explicitly disable SysV instances of foo being started,
> use whatever mechanism the sysvinit package provides to disable the
> sysv-style service startup as well, and have the runit SysV emulation
> honour this.

This is already the case: sysv uses "K-links" (like KNNname) to
mark a service as disabled, while run_sysv_scripts only loop over
"S-links". However this creates unexpected results:
* I disable a native runit service, because I don't want the service to
  run (the service goes down)
* then reboot the system
* now I have an unsupervised instance of the service running

So to really 

Bug#1022724:

[Luc Liranos]

Aidez moi à récupérer mon compte eloto

Bug#1022724:

[Luc Liranos]

Bonsoir j'aimerais vous demander un service mon compte eloto a de problème
pouvez vous m'aider à le récupérer ?

Bug#1023554: glibc: Please build with "--disable-default-pie" on sh3 and sh4 to workaround glibc bug

[John Paul Adrian Glaubitz]

Source: glibc
Version: 2.36-4
Severity: normal
User: debian-sup...@lists.debian.org
Usertags: sh3 sh4
X-Debbugs-Cc: debian-sup...@lists.debian.org,helm...@debian.org

Hello!

Similar to sparc64, sh3 and sh4 are affected by the upstream bug #29575 [1]
which breaks static builds. This is visible on sh4 when the static busybox
binary is being linked which fails with [2]:

(...)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(kill.o)(.text+0x3a):
 unexpected instruction 0XA005 (expected 0xd0??: mov.l)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(kill.o)(.text+0x3c):
 unexpected instruction 0XE0FF (expected 0x0?12: stc)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(kill.o)(.text+0x3e):
 unexpected instruction 0X09 (expected 0x0?ce: mov.l)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(uname.o)(.text+0x3a):
 unexpected instruction 0XA005 (expected 0xd0??: mov.l)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(uname.o)(.text+0x3c):
 unexpected instruction 0XE0FF (expected 0x0?12: stc)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(uname.o)(.text+0x3e):
 unexpected instruction 0X09 (expected 0x0?ce: mov.l)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(alarm.o)(.text+0x3a):
 unexpected instruction 0XA005 (expected 0xd0??: mov.l)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(alarm.o)(.text+0x3c):
 unexpected instruction 0XE0FF (expected 0x0?12: stc)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(alarm.o)(.text+0x3e):
 unexpected instruction 0X09 (expected 0x0?ce: mov.l)
/usr/bin/ld: 
/usr/lib/gcc/sh4-linux-gnu/12/../../../sh4-linux-gnu/libc.a(vfork.o)(.text+0x26):
 unexpected instruction 0XA005 (expected 0xd0??: mov.l)
(...)

Adding

extra_config_options = --disable-default-pie

to debian/sysdeps/sh4.mk fixed the problem for me. On sh3, the change should be
incorporated as well since sh3 is being bootstrapped regularly in Helmut 
Grohne's
rebootstrap project where this issue has shown as well.

Thanks,
Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=29575
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=busybox=sh4=1%3A1.35.0-4=1667730661=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1023373: [pkg-crosswire-devel] Bug#1023373: Further bug discussion

[Bastian Germann]

Am 06.11.22 um 15:58 schrieb Teus Benschop:

I now think that there is not better source file than that available.


Then it is not only a non-source file but a non-source file that does not have 
a public source.

Just get rid of that file. As it violates the users' privacy there is no point 
in searching for its
origin and possible source. And you will spare a lot of time dealing with this.

Bug#1023373: Further bug discussion

[Teus Benschop]

Initially I thought that the file analytics.html is a non-source file.

Then I went to search the Quill source code at GitHub.
https://github.com/quilljs/quill

I expected to find some Typescript or other source that would generate the 
supposedly non-source file “analytics.html”.

Here is search one:

% grep -R GoogleAnalyticsObject *
source/docs/_includes/analytics.html:  
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){

And here is search two:

% grep -R analytics.html *   
source/docs/_layouts/v0.20.html:  {% include analytics.html  %}
source/docs/_layouts/default.html:{% include analytics.html  %}

So from the results of the $ grep, it appears that there is not any source file 
in the GitHub repository that has a more preferred form of modification than 
analytics.html currently has.

So it seems like the Quill upstream developers use analytics.html as their 
source file, even if it contains minified Javascript.

Therefore although I initially thought that analytics.html is a non-source file,
I now think that there is not better source file than that available.

It could have been that the upstream developers of Quill have grabbed some 
minified Javascript code, and put that in analytics.html, and are now treating 
that file as their source.

Any thoughts?

Bug#1023553: uses option --illegal-access=permit, which was removed in OpenJDK17

[Pierre Gruet]

Package: gradle
Version: 4.4.1-16
Severity: minor

Hello,

/usr/bin/gradle invokes a gradle build with, among others,
--illegal-access=permit
Support for --illegal-access has been removed in OpenJDK17.

There is a warning message about it in the build logs of Debian packages every
time gradle is invoked.

Cheers,

-- 
Pierre

Bug#1023552: bumblebee: segfault in libGL.so.1

[Nicolas]

Package: bumblebee
Version: 3.2.1-28+b1
Severity: normal

Dear Maintainer,

Since last dist-upgrade, I can't use nvidia GPU with Optimus.


$ inxi -G
Graphics:
  Device-1: Intel 4th Gen Core Processor Integrated Graphics driver: i915
v: kernel
  Device-2: NVIDIA GM107M [GeForce GTX 850M] driver: N/A
  Device-3: IMC Networks USB2.0 UVC HD Webcam type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 1.21.1.4 with: Xwayland v: 22.1.5 driver: X:
loaded: nvidia dri: crocus gpu: i915 resolution: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 22.2.2 renderer: Mesa Intel HD Graphics 4600 (HSW
GT2)

$ optirun --debug inxi -G
[  307.842673] [DEBUG]Reading file: /etc/bumblebee/bumblebee.conf
[  307.842771] [INFO]Configured driver: nvidia
[  307.842958] [DEBUG]optirun version 3.2.1 starting...
[  307.842968] [DEBUG]Active configuration:
[  307.842972] [DEBUG] bumblebeed config file: /etc/bumblebee/bumblebee.conf
[  307.842979] [DEBUG] X display: :8
[  307.842983] [DEBUG] LD_LIBRARY_PATH: /usr/lib/x86_64-linux-
gnu/nvidia:/usr/lib/i386-linux-gnu/nvidia:/usr/lib/x86_64-linux-
gnu:/usr/lib/i386-linux-gnu
[  307.842989] [DEBUG] Socket path: /var/run/bumblebee.socket
[  307.842994] [DEBUG] Accel/display bridge: auto
[  307.842999] [DEBUG] VGL Compression: proxy
[  307.843009] [DEBUG] VGLrun extra options:
[  307.843014] [DEBUG] Primus LD Path: /usr/lib/x86_64-linux-
gnu/primus:/usr/lib/i386-linux-gnu/primus
[  307.843057] [DEBUG]Using auto-detected bridge primus
[  309.459102] [INFO]Response: Yes. X is active.

[  309.459115] [INFO]Running application using primus.
[  309.459275] [DEBUG]Process inxi started, PID 3792.
Graphics:
  Device-1: Intel 4th Gen Core Processor Integrated Graphics driver: i915
v: kernel
  Device-2: NVIDIA GM107M [GeForce GTX 850M] driver: nvidia v: 510.85.02
  Device-3: IMC Networks USB2.0 UVC HD Webcam type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 1.21.1.4 with: Xwayland v: 22.1.5 driver: X:
loaded: nvidia gpu: i915 resolution: 1920x1080~60Hz
  API: OpenGL Message: No GL data found on this system.
[  309.765970] [DEBUG]SIGCHILD received, but wait failed with No child
processes
[  309.765990] [DEBUG]Socket closed.
[  309.766014] [DEBUG]Killing all remaining processes.


Output logs as I exec: optirun glxgears -info

[  189.797140] bbswitch: enabling discrete graphics
[  190.385877] nvidia-nvlink: Nvlink Core is being initialized, major device
number 241
[  190.385882] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  510.85.02  Tue
Jul 12 16:51:23 UTC 2022
[  190.511621] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for
UNIX platforms  510.85.02  Tue Jul 12 16:42:29 UTC 2022
[  190.514022] [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver
[  190.514025] [drm] Initialized nvidia-drm 0.0.0 20160202 for :01:00.0 on
minor 1
[  191.398476] glxgears[3650]: segfault at 0 ip 7f98c763cd13 sp
7fffab17b3f0 error 4 in libGL.so.1[7f98c762a000+19000]
[  191.398485] Code: 48 89 d3 48 83 ec 28 64 48 8b 04 25 28 00 00 00 48 89 44
24 18 31 c0 e8 6b d9 fe ff 45 89 e0 48 89 d9 ba 14 80 00 00 48 89 c5 <48> 8b 30
48 8b 3d 4b b4 01 00 ff 15 65 b4 01 00 48 8b 6d 00 48 89
[  191.517942] [drm] [nvidia-drm] [GPU ID 0x0100] Unloading driver
[  191.538539] nvidia-modeset: Unloading
[  191.590933] nvidia-nvlink: Unregistered the Nvlink Core, major device number
241
[  191.628706] bbswitch: disabling discrete graphics

Of course, if I can help to fix the issue.

Regards,

Nicolas


-- Package-specific info:
OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root 15 Oct 21 09:42 /etc/alternatives/glx -> /usr/lib/nvidia
lrwxrwxrwx 1 root root 51 Oct 21 09:42 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 48 Aug 24 14:14 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 50 Oct 21 09:42 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 57 Aug 24 14:14 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 54 Oct 21 09:42 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 42 Oct 21 09:42 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
lrwxrwxrwx 1 root root 51 Oct 21 09:42 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root 23 Oct 21 17:31 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root 51 Oct 21 17:31 
/etc/alternatives/nvidia--libcuda.so-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so
lrwxrwxrwx 1 root root 53 Oct 21 17:31 

Bug#1023551: RFS: morse-simulator/1.4-6.1 [NMU] [RC] -- Multi-OpenRobot Simulation Engine

[Bo YU]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "morse-simulator":

 * Package name : morse-simulator
   Version  : 1.4-6.1
   Upstream contact : morse-us...@laas.fr
 * URL  : http://morse-simulator.github.io/
 * License  : BSD-3-clauses, BSD-3-clause-vs
 * Vcs  : https://salsa.debian.org/science-team/morse-simulator
   Section  : science

The source builds the following binary packages:

  morse-simulator - Multi-OpenRobot Simulation Engine
  morse-simulator-data - Multi-OpenRobot Simulation Engine
  morse-simulator-doc - Multi-OpenRobot Simulation Engine - Documentation
  python3-morse-simulator - Multi-OpenRobot Simulation Engine

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/morse-simulator/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/m/morse-simulator/morse-simulator_1.4-6.1.dsc

Changes since the last upload:

 morse-simulator (1.4-6.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix ftbfs on sphinxext. (Closes: #963651)
   * Add disable-examples-sphinx.patch to fix sphinx extension does
 not support example issue.
   * Add fix-find-pythonlib.patch to fix find pythonlib(python3) issue
 (Closes: #1023357).
   * Drop morse-simulator-doc.lintian-overrides
   * Broken symlink issue has disappeared. (Closes: #858958)
   * Drop python3-morse-simulator and morse-simulator-data dependency
 from morse-simulator
   * Removed __pycache__ from dh-python

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1023313: gap-guava-bin: do not hardcode kv7 in path without depend on gap-kernel-7

[Bill Allombert]

On Sun, Nov 06, 2022 at 02:18:52PM +0100, Jerome BENOIT wrote:
> Hello Bill, I got a closer look.
> 
> It appears that [gap-]guava auxiliary binaries do not depend on gap-dev 
> related packages.
> We must discard this dependency a part of resolving the issue.
> However, these auxiliary binaries are C compiled executables, that is to say
> that they are not scripts.

Yes, and as I said the program output is the same on all architectures,
so it does not need to match the gap architecture, so there is no reason to
handle it specially. In particular there is no use to install two version of the
program for two different architectures.

> > > > > > > However only the last dir[ectory] may work on
> > muti-architecture boxes.
> > > > > Here we would need a "/usr/share/gap/pkg/guava/bin/ 
> > > > > between the two current ones:
> > > > > can gap support this ?
> > > > > > GAP does not have the notion of the Debian triplet, so it is
> > difficult to write a patch
> > > > to add /usr/share/gap/pkg/guava/bin/$(DEBIAN_TRIPLET)/
> > > > I guess that a patch can be written to do so.
> > 
> > This probably requires changing the C code to define a new 
> > GAPInfo.DEB_HOST_MULTIARCH field.
> > Do you have a better idea ?
> 
> I am ready to write such a C patch. Is that okay with you ?

Depends on messy it is, I guess ? 
The problem is that once packages start to use that patch, I cannot just drop
the patch if it fails to apply to a new upstream version.

Cheers,
Bill

Bug#1023550: transition: qcustomplot

[Filippo Rusconi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, 
debian-science-maintain...@lists.alioth.debian.org

(please explain about the transition: impacted packages, reason, ...
 for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions)

Greetings,

Fundamental reason: Qt5 and Qt6 are in the archive.

I am requesting a transition from package libqcustomplot2.0 to
libqcustomplot2.1. Source package is qcustomplot. The change involves a change
in the library name itself, from libqcustomplot2.0 to both libQCustomPlot2.1 and
libQCustomPlotQt6.so.2.1.0 (see below).

I have prepared the packaging in the following git repos branch:

https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6

Reason is a new upstream version with soname change and also the fact that the
source package creates two library packages:  one with the lib built against Qt5
and one with the same lib built against Qt6. My own projects (libpappsomspp,
minexpert2) will need to depend on the Qt6-based qcustomplot library.

The new library names are thus:

- libQCustomPlot.so.2.1.0 (Qt5)
- libQCustomPlotQt6.so.2.1.0 (Qt6)

The reverse dependencies:

% apt-cache rdepends libqcustomplot2.0

libqcustomplot2.0

Reverse Depends:
  libqcustomplot-dev
  xtpcpp (under my control)
  minexpert2 (under my control)
  libqcustomplot2.1-qt6
  libqcustomplot2.1-qt6
  libqcustomplot2.1-qt5
  libqcustomplot2.1
  libqcustomplot2.1
  wsjtx
  wfview
  traceshark
  js8call
  polyphone
  nageru
  xtrx-fft
  libpappsomspp-widget0 (under my control)

For the libs under my control, the transition is already prepared and these
projects are going to be linking against the Qt6-built library, contrary to all
the other packages detailed below.

For the other libs listed above, I have already checked that they would build if
some modifications were performed. I have already git branches ready for the
packages under git VCS. For the others (source deb), I have patches available.

The modifications are lean: change -lqcustomplot to -lQCustomPlot for many and
also sometimes use the CMake-based configuration involving first
find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot formalism for
the linker.

That is: almost one- or two-liner patches.

I am eager to help providing patches (ready).

This is my first transition experience, I'll be happy to comply to any
requirement that you may have for me.

Ben file:

title = "qcustomplot";
is_affected = .depends ~ "libqcustomplot2.0" | .depends ~ "libqcustomplot2.1";
is_good = .depends ~ "libqcustomplot2.1";
is_bad = .depends ~ "libqcustomplot2.0";

Sincerely,
Filippo

-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org



signature.asc
Description: PGP signature

Bug#1023549: ITP: r-cran-gbutils -- R CRAN Package with Utilities for Simulation, Plots, Quantile Functions and Programming

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-gbutils
  Version : 0.5
  Upstream Author : Georgi N. Boshnakov
* URL or Web page : https://cran.r-project.org/package=gbutils
* License : GPL (>= 2)
  Description : R CRAN Package with Utilities for Simulation, Plots, 
Quantile Functions and Programming

This package is now a build-dependency of another build-dependency (cvar, to
become r-cran-cvar) of a long-time Debian package (r-cran-fgarch).

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1023548: pyopengl: migrate to libglut3.12

[Sebastian Ramacher]

Source: pyopengl
Version: 3.1.5+dfsg-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Control: block 1023419 by -1

pyopengl hardcodes the dependency on freeglut3. As the transition from
freeglut3 to libglut3.12 is currently ongoing, pyopengl needs to be
fixed.

Cheers
-- 
Sebastian Ramacher

Bug#1023446: libhdf5-openmpi-dev: h5pcc configured as static build

[Gilles Filippini]

Hi Drew,

Drew Parsons a écrit le 04/11/2022 à 11:27 :

Package: libhdf5-openmpi-dev
Version: 1.10.8+repack-1
Severity: important
Control: block 1020054 by -1

h5pcc is showing an unexpected default configuration:

$ h5pcc --showconfig
gcc -I/usr/include/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi 
/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5_hl.a 
/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.a -lcrypto -lcurl -lsz -lz -ldl 
-lm -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/hdf5/openmpi 
-I/usr/lib/x86_64-linux-gnu/openmpi/include 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
-L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi

Note how it includes static linking to libhdf5_hl.a and libhdf5.a


This is the expected behavior as documented by upstream:

   -shlib Compile with shared HDF5 libraries [default for hdf5 
built without static libraries]


   -noshlib
  Compile with static HDF5 libraries [default for hdf5 
built with static libraries]



I would expect the default configuration to use dynamic linking with
shared libraries, as in

$ h5pcc --showconfig -shlib
gcc -I/usr/include/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi 
-lhdf5_hl -lhdf5 -lcrypto -lcurl -lsz -lz -ldl -lm -Wl,-rpath 
-Wl,/usr/lib/x86_64-linux-gnu/hdf5/openmpi

As far as I can tell, the default static linking is causing the RC
Bug#1020054 reported against h5py.


Could be fixed using `HDF5_USE_SHLIB=yes`:
 PYBUILD_NAME=$(PYBUILD_NAME_MPI) CC=h5pcc HDF5_USE_SHLIB=yes 
HDF5_MPI=ON HDF5_PKGCONFIG_NAME=hdf5-mpi H5PY_SYSTEM_LZF=1 dh_auto_build 
-D $(BUILD_DIR_MPI)




Should the default configuration of h5pcc be changed to confirm with
the -shlib configuration?


I don't think so since the current behavior is the documented one.

Best,
_g.

Bug#993393: sensible-utils: Kindly include (german) translation in bookworm

[Helge Kreutzmann]

Dear sensible-utils maintainer(s),
the freeze for Debian bookworm is scheduled at the beginning of 2023.
Since 2021-08-31 this bug report with a german program translation is open.

For the benefit of the (german speaking) users it would be great if
you could perform an upload with this (and other) translations included
before the freeze.

If you have any questions regarding the integration of the translation 
do not hesitate to contact me or the submitter.

Thank you very much!

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1023547: smplayer: leaks privacy info to google when using chromecast feature

[Jonas Smedegaard]

Source: smplayer
Version: 22.7.0~ds0-1
Severity: normal

It seems from reading source code, that smplayer hardcodes the use of
Google DNS resolver 8.8.8.8, and uses that address every time the
Chromecast feature is used.  See file src/chromecast.cpp.

That behaviour leaks privacy information to Google:
https://wiki.debian.org/PrivacyIssues#DNS

Please patch code to skip that problematic step.


 - Jonas

signature.asc
Description: signature

Bug#991488: prometheus-nextcloud-exporter: Kindly include (german) translation in bookworm

[Helge Kreutzmann]

Dear prometheus-nextcloud-exporter maintainer(s),
the freeze for Debian bookworm is scheduled at the beginning of 2023.
Since 2021-07-25 this bug report with a german debconf translation is open.

For the benefit of the (german speaking) users it would be great if
you could perform an upload with this (and other) translations included
before the freeze.

If you have any questions regarding the integration of the translation 
do not hesitate to contact me or the submitter.

Thank you very much!

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#978120: verbiste: Kindly include (german) translation in bookworm

[Helge Kreutzmann]

Dear verbiste maintainer(s),
the freeze for Debian bookworm is scheduled at the beginning of 2023.
Since 2020-12-26 this bug report with a german program translation is open.

For the benefit of the (german speaking) users it would be great if
you could perform an upload with this (and other) translations included
before the freeze.

If you have any questions regarding the integration of the translation 
do not hesitate to contact me or the submitter.

Thank you very much!

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#978116: libapache-mod-musicindex: Kindly include (german) translation in bookworm

[Helge Kreutzmann]

Dear libapache-mod-musicindex maintainer(s),
the freeze for Debian bookworm is scheduled at the beginning of 2023.
Since 2020-12-26 this bug report with a german program translation is open.

For the benefit of the (german speaking) users it would be great if
you could perform an upload with this (and other) translations included
before the freeze.

If you have any questions regarding the integration of the translation 
do not hesitate to contact me or the submitter.

Thank you very much!

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#978119: pdf2djvu: Kindly include (german) translation in bookworm

[Helge Kreutzmann]

Dear pdf2djvu maintainer(s),
the freeze for Debian bookworm is scheduled at the beginning of 2023.
Since 2020-12-26 this bug report with a german program translation is open.

For the benefit of the (german speaking) users it would be great if
you could perform an upload with this (and other) translations included
before the freeze.

If you have any questions regarding the integration of the translation 
do not hesitate to contact me or the submitter.

Thank you very much!

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#977854: fakeroot: Kindly include (german) translation in bookworm

[Helge Kreutzmann]

Dear fakeroot maintainer(s),
The freeze for Debian bookworm is scheduled at the beginning of 2023.
Since 2020-12-21 this bug report with a german po4a translation is open.

For the benefit of the (german speaking) users it would be great if
you could perform an upload with this (and other) translations included
before the freeze.

If you have any questions regarding the integration of the translation 
do not hesitate to contact me or the submitter.

Thank you very much!

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature