Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4

2022-10-12 Thread Russ Dill
> The package pulling in libz3-4 into the dependency chain is libllvm14.
> I've noticed the ubuntu version of the package does not link against
> libz3-4 and the libz3-4 package can be removed from the system and
> xorg and mesa function just fine. Perhaps a version of libllvm14
> compiled without libz3-4 support that could be installed on instead or
> even along side?

A look at the control file for libllvm14 gives a little more detail:

Z3_FLAG = -DLLVM_ENABLE_Z3_SOLVER=OFF
ifeq ($(shell dpkg --compare-versions $(shell dpkg-query -W -f
'$${Version}' libz3-dev) gt 4.7.0; echo $$?),0)
# no ocaml support in main for Ubuntu
ifneq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
Z3_FLAG = -DLLVM_ENABLE_Z3_SOLVER=ON
endif
endif
STAGE_2_CMAKE_EXTRA += $(Z3_FLAG)

https://www.cambus.net/clang-static-analyzer-and-the-z3-constraint-solver/

I'm pretty sure the "no ocaml support in main for Ubuntu" is in error
and should read "no z3 constraint solver support in main for Ubuntu".
The author seems to have gotten the similarly named z3 constraint
solver and the LLVM backend for ocaml (Z3) confused.

https://github.com/ohmi/Z3



Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4

2022-10-12 Thread Russ Dill
On Tue, Oct 11, 2022 at 4:06 AM karogyoker999  wrote:
>
> > As far as I see your MR just adds a dependency to sse2-support,
> > which I guess just makes the installation abort in case of a CPU
> > not supporting sse2, so I guess this would just make
> > mesa not installable on your hardware?
>
> Exactly.
>
> It will abort the installation as it wouldn't work anyways.
> Mesa now requires SSE2 and therefore Xorg as well.
> The workaround is to use Wayland with GNOME or KDE.
> But KDE requires SSE2 since several months too (and therefore fails to 
> install).
> It is better to have the installation fail rather than
> having an unusable system after install. Because in the latter case,
> it would mean that users would be disappointed, much time would be wasted
> to troubleshoot. Failing the installation with a clear error message
> is a much better solution.

This is a bit of a further pain point for those out there running on
P6 systems as they commonly have video hardware that only supports
DRI1.

> The alternative would be to disable SSE2 for all i386 packages of libz3-4.
> But usually maintainers don't like that since that would have a performance
> impact on Pentium 4 CPUs. So there is a choice to make: disable SSE2 on
> all x86_32 CPUs or fail the install on everything except Pentium 4.

According to the developers of libz4-3, the precision of the FPU x87
registers is not sufficient therefore a libz4-3 package compiled
without SSE2 would be non-functional. It would be far better if
libz3-4 could fail late rather than early. If it could fail later, in
the case that calls to libz3-4 were made I think that would avoid the
current issue. Perhaps if video hardware that requires shader
compilation isn't present, no failures would occur. However the crash
occurs at dlopen time as there are a number of c++ static initializers
that get executed so even if no calls to libz3-4 are even made, or
even calls to the mesa library that links to libllvm14, which links to
libz3-4, everything works fine.

I'm not even certain that libz3-4 is ever even called by mesa. I think
it's just an option feature of libllvm and because mesa links libllvm,
it ends up calling dlopen on the libz3-4 library. The debian changelog
reads:

  * Enable Z3 solver (llvm & clang) to improve the quality of the static
analysis results

This doesn't sound like a feature mesa needs and I can't find any
mention of mesa using the z3 solver.

> There is a Debian patch [1] for the z3 package which does something with SSE2.
> But then why is it still crashing? Maybe z3 has some hardcoded SSE2
> instruction somewhere?
> Or it has been just compiled with the incorrect compiler flags?

Doesn't appear to be disabling SSE2, just trying to make something
work when SSE2 is disabled. Not sure why.

> To have both performance and compatibility, a runtime check would be needed
> to be added, but that would mean a significant amount of work.
>
> Until this work is not done by someone, failing the installation is
> still better than
> crashing and leaving the system in an unbootable state.
>
> [1]: https://sources.debian.org/patches/z3/4.8.12-1/00-intrinsics.patch/

The package pulling in libz3-4 into the dependency chain is libllvm14.
I've noticed the ubuntu version of the package does not link against
libz3-4 and the libz3-4 package can be removed from the system and
xorg and mesa function just fine. Perhaps a version of libllvm14
compiled without libz3-4 support that could be installed on instead or
even along side?



Bug#1021678: [Pkg-rust-maintainers] Bug#1021678: Bug#1021678: rust-object: autopkgtest failure on s390x

2022-10-12 Thread Wolfgang Silbermayr

Am 13.10.22 um 01:23 schrieb Peter Green:


3. Apply the upstream fix as Debian packages, hope any resulting API breakage
    is manageable.


I did a quick regex search on https://codesearch.debian.not/ for
"\bshndx\b package:^rust*", and that only revealed two source packages, namely 
rust-object and rustc. rustc shows up because it has vendored its own copy of 
the rust object library crate. At least at a quick glance it looks as if no 
other package is using the function that gets its signature changed with the 
patch. Any new packages to come would fail building anyway, so don't think 
it's a problem to upload with the upstream patch applied.




Bug#1021693: RFP: buskill -- app for arming/disarming/configuring the BusKill laptop kill cord

2022-10-12 Thread Francois Marier
Package: wnpp
Severity: wishlist

* Package name: buskill
  Version : 0.5.0
  Upstream Author : Michael Altfield 
* URL : https://github.com/BusKill/buskill-app
* License : GPL-3.0
  Programming Lang: Python
  Description : app for arming/disarming/configuring the BusKill laptop 
kill cord

BusKill is a laptop kill cord that can trigger your computer to lock or
shutdown when it's physically separated from you.



Bug#1021692: zint: incorrect Homepage link

2022-10-12 Thread Paul Wise
Source: zint
Version: 2.11.1-1
Severity: minor

The Homepage link points at the zint SourceForge project,
but that points at a different location for its web page.
Please note that the zint website also redirects to https.

$ apt-cache show zint | grep Homepage
Homepage: https://sourceforge.net/projects/zint/

$ curl -s https://sourceforge.net/projects/zint/ | grep -i web.site | 
html2markdown | tr -s '\n' ' '
[Zint Barcode Generator Web Site](http://www.zint.org.uk/ "Zint Barcode 
Generator Web Site")

$ wget -nv -O /dev/null http://www.zint.org.uk/
2022-10-13 11:44:37 URL:https://www.zint.org.uk/ [10698/10698] -> "/dev/null" 
[1]

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1021691: llvm-toolchain-snapshot: mips need some patches

2022-10-12 Thread YunQiang Su
Package: llvm-toolchain-snapshot
Version: 1:16~++20220928062542+48b8dee773f3-1~exp1

The upstream compiler-rt and openmp have some problem,
and we are try to push the patches upstream:

https://reviews.llvm.org/D135552
https://reviews.llvm.org/D135735
https://reviews.llvm.org/D135565
https://reviews.llvm.org/D135553

-- 
YunQiang Su



Bug#1021289: apt-listbugs: automatic pinning is not added under unattended-upgrades

2022-10-12 Thread Paul Wise
On Thu, 2022-10-13 at 00:29 +0200, Francesco Poli wrote:

> Now everything seems to work as intended: the pinnings are saved, even
> when apt-listbugs is run with no controlling terminal.

Excellent, thanks for fixing!


> Thanks again, the debugging session you provided was also pretty useful
> to understand what was going on!

Great :)


> Support for attempting unattended upgrades twice in a row could perhaps
> be added to file '/usr/lib/apt/apt.systemd.daily'.
> There could be better ways.
> 
> Please take a look at it and see whether you like it.
> Maybe you could enhance this rough idea a bit and propose it to APT
> developers...

Hmm. I think I would prefer a protocol for the apt hooks to ask for apt
to restart the current upgrade. Not sure what apt folks think though,
I'll bring it up on their mailing list and CC you.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1021690: RM: r-cran-m2r [mipsel] -- ROM; macaulay2 (in Depends) is not available in mipsel

2022-10-12 Thread Torrance, Douglas

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: dtorra...@piedmont.edu

Hello!

I am an uploader for r-cran-m2r, which is team-mainted by the Debian R Team.
It hasn't transitioned to testing because it originally built on mipsel but
has macaulay2, which is not available in mipsel, in its Depends.

Am I correct that after removing the existing r-cran-m2r package in mipsel,
it should be able to transition to testing?

My latest upload has added macaulay2 to Build-Depends, so it should no longer
build on any architectures where macaulay2 is unavailable.

Thank you!
Doug


signature.asc
Description: PGP signature


Bug#1014619: libstdc++-arm-none-eabi: dpkg-buildflags leak into target build

2022-10-12 Thread Keith Packard

> One way to solve this would be to set DEB_BUILD_OPTIONS=optimize=-lto, to
> exclude the LTO flags specifically so that they don't leak into the target
> builds.  Another thought I had was to use the dpkg-buildflags for armhf as a
> target architecture, since there could be other per-arch flags in the future
> that cause further problems.  I've tried the latter approach in the attached
> patch, which fixes the problem of lto being incorrectly used for the
> arm-none-eabi target.  I've verified that the resulting libstdc++ is usable
> again with this change.

Yeah, neither of these is really appropriate; we're not building Debian
code here. As 'rules' already sets the complete CFLAGS and CXXFLAGS
values save the necessary flags for a reproducible build, how about I
just add `-ffile-prefix-map=$(TOP_DIR)=.` manually and stop using
/usr/share/dpkg/buildflags.mk?

@@ -10,7 +10,6 @@ MULTILIB_LIST="--with-multilib-list=rmprofile"
 GCC_PACKAGE=gcc-arm-none-eabi
 
 include /usr/share/dpkg/pkg-info.mk
-include /usr/share/dpkg/buildflags.mk
 
 SVERSION := $(shell dpkg-query -W -f="\$${Version}\n" $(GCC_PACKAGE)-source)
 DVERSION := $(SVERSION)+$(DEB_VERSION)
@@ -29,6 +28,9 @@ 
BUILD_PICOLIBC_RELEASE_DIR=$(TOP_DIR)/build_picolibc_release/libstdc++
 PNEWLIB=libstdc\+\+-arm-none-eabi-newlib
 PPICOLIBC=libstdc\+\+-arm-none-eabi-picolibc
 
+CFLAGS := -ffile-prefix-map=$(TOP_DIR)=. -Wformat -Werror=format-security
+CXXFLAGS := $(CFLAGS)
+
 BUILDFLAGS=CFLAGS="$(CFLAGS) -g -O2 -ffunction-sections -fdata-sections" 
CXXFLAGS="$(CXXFLAGS) -g -O2 -ffunction-sections -fdata-sections" 
LDFLAGS="$(LDFLAGS)"
 BUILDFLAGS_NANO=CFLAGS="$(CFLAGS) -g -Os -ffunction-sections -fdata-sections 
-fno-exceptions" CXXFLAGS="$(CXXFLAGS) -g -Os -ffunction-sections 
-fdata-sections -fno-exceptions" LDFLAGS="$(LDFLAGS)"
 BUILDFLAGS_PICOLIBC=CFLAGS="--specs=picolibc.specs $(CFLAGS) -g -Os 
-ffunction-sections -fdata-sections" CXXFLAGS="--specs=picolibcpp.specs 
$(CXXFLAGS) -g -Os -ffunction-sections -fdata-sections" 
LDFLAGS="--specs=picolibc.specs $(LDFLAGS)"


-- 
-keith


signature.asc
Description: PGP signature


Bug#1021527: isc-dhcp-server: apt upgrade fails with sed error

2022-10-12 Thread Felix Wong
thanks adi, that was perfect! i had a stray comma in that list for some
reason, probably from some failed copy/pasta error. the rest of the
variable uses spaces.

On Wed, Oct 12, 2022 at 1:07 AM Adi Kriegisch  wrote:

> Hi!
>
> This could happen when there is a comma in the list of interfaces (in
> /etc/default/isc-dhcp-server). Please check the output of
>   | debconf-show isc-dhcp-server
> for commas in the 'isc-dhcp-server/interfaces' variable or the content
> of /etc/default/isc-dhcp-server and look for commas in INTERFACESv4 or
> INTERFACESv6. To specify more interfaces a space between the interfaces
> is sufficient.
>
> best regards,
> Adi Kriegisch
>


Bug#1021689: firefox-esr: regression: Ctrl-Shift-T does not work any more, menu option greyed out

2022-10-12 Thread Mike Hommey
On Thu, Oct 13, 2022 at 01:28:33AM +0200, Thorsten Glaser wrote:
> Package: firefox-esr
> Version: 102.3.0esr-1~deb11u1
> Severity: normal
> X-Debbugs-Cc: t...@mirbsd.de, t...@security.debian.org
> 
> Since the upgrade to 102 in bullseye, Ctrl-Shift-T does not work any more.
> Upon looking in the menu, “Recently Closed Tabs” is greyed out instead of
> listing these as before.

It works for me.

Can you try with a fresh profile? Disabling addons? Diagnostic mode in
about:support?

Mike



Bug#1021689: firefox-esr: regression: Ctrl-Shift-T does not work any more, menu option greyed out

2022-10-12 Thread Thorsten Glaser
Package: firefox-esr
Version: 102.3.0esr-1~deb11u1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de, t...@security.debian.org

Since the upgrade to 102 in bullseye, Ctrl-Shift-T does not work any more.
Upon looking in the menu, “Recently Closed Tabs” is greyed out instead of
listing these as before.


-- Package-specific info:

-- Extensions information
Name: Add-ons Search Detection
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Amazon.co.uk
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark Background and Light Text
Location: ${PROFILE_EXTENSIONS}/jid1-qofqdk4qzuf...@jetpack.xpi
Status: enabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Editable QR Generator
Location: ${PROFILE_EXTENSIONS}/{cd6aaef4-adda-43c6-9222-f6281fc75f23}.xpi
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: System theme — auto theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled


-- Addons package information
ii  firefox-esr102.3.0esr-1~deb11u1 amd64Mozilla Firefox web 
browser - Extended Support Release (ESR)

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

Kernel: Linux 5.10.0-18-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libasound2   1.2.4-1.1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.24-0+deb11u1
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  libxtst6 2:1.2.3-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.4-0+deb11u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
pn  libcanberra0   
ii  libgssapi-krb5-2   1.18.3-6+deb11u2
pn  pulseaudio 

-- no debconf information


Bug#1021684: Dino Mobile Layout in Experimental

2022-10-12 Thread Quinn Stambaugh
No worries, thank you for the information! I just wanted to make sure
it was known.

On Wed, 2022-10-12 at 22:57 +, Martin wrote:
> Dear Quinn,
> 
> On 2022-10-12 16:43, Quinn Stambaugh wrote:
> > The move from libhandy to GTK4 for the Experimental build of Dino
> > broke
> > the mobile layout. It's still somewhat usable, but the main
> > hamburger
> > menu won't open and context menu for copying and pasting won't come
> > up
> > either.
> 
> This is unfortunately true. Upstream plans to integrate libadwaita
> soon
> (but don't hold your breath), which will make Dino mobile friendly,
> again. For the moment, there is no other option than to use the
> previous
> version, e.g. download from here:
> 
> http://snapshot.debian.org/package/dino-im/0.3.0-3%2Bhandy/
> 
> and put it "on hold":
> 
> echo dino-im hold | sudo dpkg --set-selections
> 
> Sorry for the inconvenience!
> 
> I'll close this bug, as soon as libadwaita is used in dino-im.
> 

-- 
Thank you for your time.
Quinn Stambaugh

Phone: +1(316)347-8619
JID: qstamba...@mailbox.org

Social Media: https://mastodon.online/@qstambaugh



Bug#1021678: [Pkg-rust-maintainers] Bug#1021678: rust-object: autopkgtest failure on s390x

2022-10-12 Thread Peter Green

https://ci.debian.net/data/autopkgtest/testing/s390x/r/rust-object/26973632/log.gz

test round_trip::elf::symtab_shndx ... FAILED


I noticed this and filed a bug upstream soon after the package was uploaded.

https://github.com/gimli-rs/object/issues/456

And a fix appeared fairly shortly.

https://github.com/gimli-rs/object/pull/458

However this fix has not yet been included in an upstream release and is
apparently a breaking change. So i'm reluctant to include it as a Debian patch.

Options.

1. Wait for upstream to produce a new release, trouble is I don't know how long
   this will be, upstream said a couple of months ago "It hasn't been long
   since the last release with breaking changes, so I prefer to wait longer
   before doing that."

2. Skip the test on big-endian systems, from my discussions with upstream
   this appears to be a case of a new test rather than an actual regression
   in the codebase.

3. Apply the upstream fix as Debian packages, hope any resulting API breakage
   is manageable.

I was waiting and hoping that upstream would release a fixed version before
something arose that made getting the object etc transition into testing
urgent.



Bug#1021684: Dino Mobile Layout in Experimental

2022-10-12 Thread Martin
Dear Quinn,

On 2022-10-12 16:43, Quinn Stambaugh wrote:
> The move from libhandy to GTK4 for the Experimental build of Dino broke
> the mobile layout. It's still somewhat usable, but the main hamburger
> menu won't open and context menu for copying and pasting won't come up
> either.

This is unfortunately true. Upstream plans to integrate libadwaita soon
(but don't hold your breath), which will make Dino mobile friendly,
again. For the moment, there is no other option than to use the previous
version, e.g. download from here:

http://snapshot.debian.org/package/dino-im/0.3.0-3%2Bhandy/

and put it "on hold":

echo dino-im hold | sudo dpkg --set-selections

Sorry for the inconvenience!

I'll close this bug, as soon as libadwaita is used in dino-im.



Bug#1021352: GOA malfunction for mails

2022-10-12 Thread Osamu Aoki
I can confirm this problem on my Debian testing system .

> gnome-online-accounts 3.46.0-1 

My workaround is:

Settings -> Online accounts -> Open my registered online account panel, 
--> Move Mail slide switch off/on
--> Click X on right top to close window

This trick worked every time

(I suppose changing this may have restated the 
> /usr/libexec/goa-daemon
 as I see "ps axjf".)
[2022-10-02] gnome-online-accounts 3.46.0-1 MIGRATED to testing (Debian testing
watch)

So this matches my experience of this problem.

Osamu



Bug#1021688: debian-edu-config: Broken network setup if LXQt desktop environment is used on main or LTSP server

2022-10-12 Thread Wolfgang Schweer
Package: debian-edu-config
Version: 2.11.56+debu4
Severity: normal

On systems with 'Main server' and/or 'LTSP server' profiles the network 
setup fails to work correctly in case the LXQt desktop environment is 
used.

To fix it locally, replace connman with network-manager-gnome (ConnMan 
is the preferred LXQt network manager). apt install 
network-manager-gnome -y apt purge connman -y

Reboot the system.
Also, if Diskless workstations are used, rebuild the related image:
debian-edu-ltsp-install --diskless_workstation yes 

The fix is easy, see this commit:

https://salsa.debian.org/debian-edu/debian-edu-config/-/commit/3d02cdc270db00ac09f9907a2bd93573e796a559

Wolfgang


signature.asc
Description: PGP signature


Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

2022-10-12 Thread Soren Stoutner
I submitted three upstream bugs.

https://bugreports.qt.io/browse/QTBUG-107599[1]
https://bugreports.qt.io/browse/QTBUG-107600[2]
https://bugreports.qt.io/browse/QTBUG-107601[3]

-- 
Soren Stoutner
so...@stoutner.com



[1] https://bugreports.qt.io/browse/QTBUG-107599
[2] https://bugreports.qt.io/browse/QTBUG-107600
[3] https://bugreports.qt.io/browse/QTBUG-107601


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


Bug#1021687: debian-edu-config: Make sure the ntp package is installed on the main server

2022-10-12 Thread Wolfgang Schweer
Package: debian-edu-config
Version: 2.11.56+deb11u4
Severity: normal

In case Internet connection isn't available, synchronizing clocks on the 
Debian Edu network requires running a local time server (e.g. for 
kerberized services like SSH and NFS).

On the main server, the ntp package should be installed, like 
recommended by the education-main-server package. But due to changes 
some time ago, systemd-timesyncd gets installed earlier and prevents the 
ntp package from being installed.

To fix it, run run as root user on the main server:

'apt install ntp -y' to install the package and
'cf-agent -I -D installation' to adjust the ntp configuration like needed.

This bug has already been fixed in sid/testing (debian-edu-config 2.12.11), see:
https://salsa.debian.org/debian-edu/debian-edu-config/-/commit/69d83ae46c72d4a7b70088f87b38164c09941669

Wolfgang


signature.asc
Description: PGP signature


Bug#1021686: zxing-cpp: FTBFS: error: static assertion failed: Cannot format an argument.

2022-10-12 Thread Andreas Beckmann
Source: zxing-cpp
Version: 1.4.0-1~exp2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

zxing-cpp/experimental recently started to FTBFS (but the version in sid
is not affected).

...
[ 90%] Building CXX object 
test/blackbox/CMakeFiles/ReaderTest.dir/BlackboxTestRunner.cpp.o
cd /build/zxing-cpp-1.4.0/obj-x86_64-linux-gnu/test/blackbox && /usr/bin/c++ 
-DFMT_SHARED -DZX_USE_UTF8 -I/build/zxing-cpp-1.4.0/core/src -isystem 
/usr/include/stb -g -O2 -ffile-prefix-map=/build/zxing-cpp-1.4.0=. 
-fstack-protector-strong -Wformat -Werror=format-security
 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -MD -MT 
test/blackbox/CMakeFiles/ReaderTest.dir/BlackboxTestRunner.cpp.o -MF 
CMakeFiles/ReaderTest.dir/BlackboxTestRunner.cpp.o.d -o 
CMakeFiles/ReaderTest.dir/BlackboxTestRunner.cpp.o -c 
/build/zxing-cpp-1.4.0/test/blackbox/Bla
ckboxTestRunner.cpp
[ 91%] Building CXX object 
example/CMakeFiles/ZXingQtReader.dir/ZXingQtReader_autogen/mocs_compilation.cpp.o
cd /build/zxing-cpp-1.4.0/obj-x86_64-linux-gnu/example && /usr/bin/c++ 
-DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG 
-I/build/zxing-cpp-1.4.0/obj-x86_64-linux-gnu/example/ZXingQtReader_autogen/include
 -I/build/zxing-cpp-1.4.0/core/src -isystem /usr/include/x86_64-linux-gnu/qt
5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -g -O2 
-ffile-prefix-map=/build/zxing-cpp-1.4.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdat
e-time -D_FORTIFY_SOURCE=2 -fPIC -std=c++11 -MD -MT 
example/CMakeFiles/ZXingQtReader.dir/ZXingQtReader_autogen/mocs_compilation.cpp.o
 -MF 
CMakeFiles/ZXingQtReader.dir/ZXingQtReader_autogen/mocs_compilation.cpp.o.d -o 
CMakeFiles/ZXingQtReader.dir/ZXingQtReader_autogen/moc
s_compilation.cpp.o -c 
/build/zxing-cpp-1.4.0/obj-x86_64-linux-gnu/example/ZXingQtReader_autogen/mocs_compilation.cpp
In file included from 
/build/zxing-cpp-1.4.0/test/blackbox/BlackboxTestRunner.cpp:17:
/usr/include/fmt/core.h: In instantiation of 'constexpr 
fmt::v9::detail::value fmt::v9::detail::make_value(T&&) [with Context 
= fmt::v9::basic_format_context; T = 
std::filesystem::__cxx11::path&]':
/usr/include/fmt/core.h:1777:29:   required from 'constexpr 
fmt::v9::detail::value fmt::v9::detail::make_arg(T&&) [with bool 
IS_PACKED = true; Context = fmt::v9::basic_format_context; type  = fmt::v9::detail::type::custom_type
; T = std::filesystem::__cxx11::path&; typename std::enable_if::type  = 0]'
/usr/include/fmt/core.h:1901:77:   required from 'constexpr 
fmt::v9::format_arg_store::format_arg_store(T&& ...) [with T = 
{std::filesystem::__cxx11::path&, int&, long unsigned int&}; Context = 
fmt::v9::basic_format_context; Args =
 {std::filesystem::__cxx11::path, int, long unsigned int}]'
/usr/include/fmt/core.h:1918:31:   required from 'constexpr 
fmt::v9::format_arg_store::type>::type ...> fmt::v9::make_format_args(Args&& 
...) [with Context = basic_format_context; Args
= {std::filesystem::__cxx11::path&, int&, long unsigned int&}]'
/usr/include/fmt/core.h:3294:44:   required from 'void 
fmt::v9::print(format_string, T&& ...) [with T = 
{std::filesystem::__cxx11::path&, int&, long unsigned int}; format_string = basic_format_string]'
/build/zxing-cpp-1.4.0/test/blackbox/BlackboxTestRunner.cpp:214:13:   required 
from here
/usr/include/fmt/core.h:1757:7: error: static assertion failed: Cannot format 
an argument. To make type T formattable provide a formatter specialization: 
https://fmt.dev/latest/api.html#udt
 1757 |   formattable,
  |   ^~~
/usr/include/fmt/core.h:1757:7: note: 'formattable' evaluates to false
[ 92%] Building CXX object 
example/CMakeFiles/ZXingQtReader.dir/ZXingQtReader.cpp.o
cd /build/zxing-cpp-1.4.0/obj-x86_64-linux-gnu/example && /usr/bin/c++ 
-DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG 
-I/build/zxing-cpp-1.4.0/obj-x86_64-linux-gnu/example/ZXingQtReader_autogen/include
 -I/build/zxing-cpp-1.4.0/core/src -isystem /usr/include/x86_64-linux-gnu/qt5 
-isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -g -O2 
-ffile-prefix-map=/build/zxing-cpp-1.4.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -std=c++11 -MD 
-MT example/CMakeFiles/ZXingQtReader.dir/ZXingQtReader.cpp.o -MF 
CMakeFiles/ZXingQtReader.dir/ZXingQtReader.cpp.o.d -o 
CMakeFiles/ZXingQtReader.dir/ZXingQtReader.cpp.o -c 
/build/zxing-cpp-1.4.0/example/ZXingQtReader.cpp
make[3]: *** [test/blackbox/CMakeFiles/ReaderTest.dir/build.make:107: 
test/blackbox/CMakeFiles/ReaderTest.dir/BlackboxTestRunner.cpp.o] Error 1
...

Andreas


zxing-cpp_1.4.0-1~exp2.log.gz
Description: application/gzip


Bug#1021685: upgrading from 40.1-1 to 43.0-2 breaks xfce

2022-10-12 Thread Brent S. Elmer
Package: libwnck3
Version: libwnck-3-0
Severity: normal
X-Debbugs-Cc: webe...@aim.com

When I upgrade from 40.1-1 to 43.0-2 on a debian testing system, xfce breaks.
I see no xfce items at all on the screen(i.e. top bar, application menu, bottom
bar, desktop icons)
I am accessing the machine through x2go.  I am not near the machine to see if
xfce works directly on the machine.  When I downgrade to 40.1-1 then xfce works
again.

I see these lines over and over in syslog.

Oct 12 16:58:49 mj04lv70 x2gogetstatus: db_getstatus called, session ID:
bselme-50-1665611527_stDXFCE_dp32, return value: R
Oct 12 16:58:51 mj04lv70 x2gocleansessions: executing external command
,,/usr/lib/x2go/x2golistsessions_sql'' with args: mj04lv70.ds.xxx.com
Oct 12 16:58:51 mj04lv70 x2golistsessions_sql: executing external command
,,x2gopath'' with args: libexec
Oct 12 16:58:51 mj04lv70 x2golistsessions_sql: executing external command
,,/usr/lib/x2go/libx2go-server-db-sqlite3-wrapper'' with args:
listsessionsroot,mj04lv70.ds.xxx.com


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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



Bug#1021289: apt-listbugs: automatic pinning is not added under unattended-upgrades

2022-10-12 Thread Francesco Poli
Control: tags -1 - moreinfo


On Fri, 07 Oct 2022 08:36:36 +0800 Paul Wise wrote:

[...]
> Refocusing this bug report on the pinning issue.
> 
> On Fri, 2022-10-07 at 00:26 +0200, Francesco Poli wrote:
> 
> > Specifically, when apt-listbugs sees that its stdout is not a terminal,
> > it automatically assume the following options: --quiet --force-pin
> > --force-no
> > This automatic behavior change should ensure that all buggy packages
> > (of the upgrade/installation that is about to happen) are pinned,
> > without any interactive prompt.
> 
> I tested this again and it definitely is not happening, see below.
> 
> Reading the code, it seems the issue is that the save() function is
> only ever called by the view() function when the answer is y/n but
> never when the answer is p which is set by --force-pin.

Paul, I really have to thank you for reporting this bug and for
investigating it (through tests and by reading the code)!
It turns out that this regression was introduced (shame on me!) when I
decided to defer the update of files to the end of the apt-listbugs
session. The deferment was useful to implement the undo ('u') command.
But, unfortunately, I didn't realize that save() would not be called at
all in the force-pin case...   :-(

Now everything seems to work as intended: the pinnings are saved, even
when apt-listbugs is run with no controlling terminal.

[...] 
> > More investigation is needed in order to figure out why you didn't see
> > the pinning added.
> 
> Provided some debugging at the end of this mail.

Thanks again, the debugging session you provided was also pretty useful
to understand what was going on!

[...]
> > I admit that I am not familiar with unattended-upgrades, hence I am not
> > sure how to configure it for the twice-in-a-row upgrade.
> > I hope it's easy enough.
> 
> I can only configure unattended-upgrades to run more often, there is no
> option to ignore failure of a particular upgrade and retry it.
[...]

Support for attempting unattended upgrades twice in a row could perhaps
be added to file '/usr/lib/apt/apt.systemd.daily'.
Please note that this file is shipped in package 'apt'.

One way to implement it is maybe by adding the following code before
line 495:

  if [ "$TwiceInARow" = "true" ]; then
  unattended-upgrade $XUUPOPT
  fi

The surrounding snippet of code would thus become something like:

if command -v unattended-upgrade >/dev/null && check_stamp $UPGRADE_STAMP 
$UnattendedUpgradeInterval; then
if [ "$TwiceInARow" = "true" ]; then
unattended-upgrade $XUUPOPT
fi
if unattended-upgrade $XUUPOPT; then
update_stamp $UPGRADE_STAMP
debug_echo "unattended-upgrade (success)"
else
debug_echo "unattended-upgrade (error)"
fi
else
debug_echo "unattended-upgrade (not run)"
fi


Near line 402 something like the following could be added:

TwiceInARow="false"
eval $(apt-config shell TwiceInARow APT::Periodic::Twice-in-a-Row)


This is totally untested and based on a quick glance at the file.
There could be better ways.

Please take a look at it and see whether you like it.
Maybe you could enhance this rough idea a bit and propose it to APT
developers...





-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp0rKf2ZMpaf.pgp
Description: PGP signature


Bug#1021684: Dino Mobile Layout in Experimental

2022-10-12 Thread Quinn Stambaugh
Package: dino-im
Version: 0.3.0+git20221011.a45280f-1

The move from libhandy to GTK4 for the Experimental build of Dino broke
the mobile layout. It's still somewhat usable, but the main hamburger
menu won't open and context menu for copying and pasting won't come up
either.
-- 
Thank you for your time.
Quinn Stambaugh

Phone: +1(316)347-8619
JID: qstamba...@mailbox.org

Social Media: https://mastodon.online/@qstambaugh


Bug#985749: apt: "apt-mark hold" flag lost on package upgrade using --ignore-hold

2022-10-12 Thread Guillem Jover
Control: reassign -1 apt

Hi!

On Tue, 2021-03-23 at 00:06:21 +0100, Sven-Haegar Koch wrote:
> On Mon, 22 Mar 2021, David Kalnischkies wrote:
> > On Mon, Mar 22, 2021 at 10:21:59PM +0100, Sven-Haegar Koch wrote:
> > > I hold the package, and with normal upgrade/dist-upgrade it works
> > > exactly as expected.
> > > 
> > > But when I then upgrade these single package later using --ignore-hold,
> > > the hold flag is lost afterwards.
> > 
> > holds are stored by dpkg as a "selection state", which e.g. install or
> > deinstall are, too, and which will override the old selection state sort
> > of by design.
> > 
> > It is also this way since the dawn of time, so that is kinda unlikely to
> > change – resolving this bug might be as "simple" as adding a note that
> > holds will be (potentially) lost if they are ignored.
> > 
> > Sorry, as that is probably not what you wanted to hear.
> 
> Thanks.
> 
> I think a note in the apt-get manpage on the options (--ignore-hold and 
> --allow-change-held-packages) would already have helped me a lot - it 
> took very long to figure out that my problem was indeed loosing the 
> mark after upgrading the package - as usually the availability of the 
> next version of a marked package happens weeks or months later.
> 
> And when you discover the mark missing on a dist-upgrade call then, you 
> mostly think "I thought I set it, did I really also on this server?" :)
> 
> Never even got the idea that the hold would not be supposed to 
> survive, neither from apt-get nor from apt-mark manpages.

In dpkg this got clarified with bug #926472, I've just pushed a commit
to dpkg git HEAD to further clarify a confusing wording in the man page
for the --force-hold description, but otherwise I think the stuff in
the «Packages selection states» subsection should be clear enough
already.

Given that you request improvements to the apt documentation, I'm
reassigning back.

Thanks,
Guillem



Bug#1021658: latexml: AutoPKG test suite fails since latest upload of TLive

2022-10-12 Thread Hilmar Preusse
Control: forwarded -1 https://github.com/brucemiller/LaTeXML/issues/1963

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

Dear Maintainer,

> This is just for the records: since the latest upload of
> texlive-base/texlive-lang/texlive-extra snapshot the latexml
> test suite fails to run. The issue is known in upstream.
> 
Mark as forwarded.

H.
-- 
sigmentation fault


signature.asc
Description: PGP signature


Bug#1021622: libwxsqlit3-3.0-dev: not coinstallable

2022-10-12 Thread Olly Betts
On Wed, Oct 12, 2022 at 10:40:29PM +0200, László Böszörményi (GCS) wrote:
> On Wed, Oct 12, 2022 at 10:36 PM Olly Betts  wrote:
> > On Tue, Oct 11, 2022 at 11:28:53PM +0200, Sebastian Ramacher wrote:
> > > The following packages have unmet dependencies:
> > >  libwxsqlite3-3.2-dev : Breaks: libwxsqlite3-3.0-dev but 3.4.1~dfsg-8 is 
> > > to be installed
> > > E: Unable to correct problems, you have held broken packages
> >
> > The problem here is due to this in debian/control in the source package:
> [...]
> > (We've also resolved the only such package in Debian already, but this
> > may be relevant for downstream distros such as Ubuntu if they have
> > packages we don't.)
> [...]
> > Happy to NMU a fix for this.
>  Thanks, but libwxsqlite3-3.0-dev is about to stay for a little
> longer. Then a fixed package is already uploaded and waiting to be
> accepted.

I see, but that's really not the right fix.

We went through this last time too:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741730;msg=79

Cheers,
Olly



Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

2022-10-12 Thread Soren Stoutner
On Wednesday, October 5, 2022 9:38:09 AM MST Soren Stoutner wrote:
> > ++ processing gl_ES.aff
> > gl_ES.dic_delta not found.
> > Reading gl_ES.aff
> > Reading gl_ES.dic
> > Serializing...
> > Verifying...
> > Word does not match!
> > 
> >   Index:2126
> >   Expected: Abū po:antropónimo
> > 
> > is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_a
> > ṣ_ Ṣabiʾ_al_Battānī Actual:   Abū po:antropónimo
> > is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_a
> > ṣ_ Ṣabiʾ_al_Battā ERROR converting, the dictionary does not check out OK.
> I am not exactly sure what is causing this error, but I would assume that it
> is some mismatch between the .aff and the .dic files.  The line it appears
> to be complaining about is 2095 from gl_ES.dic, which reads as follows:
> 
> Abū po:antropónimo
> is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_aṣ_
> Ṣabiʾ_al_Battānī
> 
> However, for some reason it is expecting the line to be shorter.

After thinking about this error a little more, it occurred to me that the most 
likely explanation is probably that the .bdic binary format has a maximum field 
length that is shorter than the field in the original .aff file.  So, when the 
field is read into the .bdic it is truncated, and then, at a later step, when 
it is compared, the lines no longer match.

-- 
Soren Stoutner
so...@stoutner.com

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


Bug#1021620: openssl: CVE-2022-3358

2022-10-12 Thread Salvatore Bonaccorso
Hi,

On Tue, Oct 11, 2022 at 10:56:34PM +0200, Salvatore Bonaccorso wrote:
> Source: openssl
> Version: 3.0.5-4
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: found -1 3.0.5-2
> 
> Hi,
> 
> The following vulnerability was published for openssl.
> 
> CVE-2022-3358[0]:
> | OpenSSL supports creating a custom cipher via the legacy
> | EVP_CIPHER_meth_new() function and associated function calls. This
> | function was deprecated in OpenSSL 3.0 and application authors are
> | instead encouraged to use the new provider mechanism in order to
> | implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly
> | handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(),
> | EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as
> | other similarly named encryption and decryption initialisation
> | functions). Instead of using the custom cipher directly it incorrectly
> | tries to fetch an equivalent cipher from the available providers. An
> | equivalent cipher is found based on the NID passed to
> | EVP_CIPHER_meth_new(). This NID is supposed to represent the unique
> | NID for a given cipher. However it is possible for an application to
> | incorrectly pass NID_undef as this value in the call to
> | EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL
> | encryption/decryption initialisation function will match the NULL
> | cipher as being equivalent and will fetch this from the available
> | providers. This will succeed if the default provider has been loaded
> | (or if a third party provider has been loaded that offers this
> | cipher). Using the NULL cipher means that the plaintext is emitted as
> | the ciphertext. Applications are only affected by this issue if they
> | call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in
> | a call to an encryption/decryption initialisation function.
> | Applications that only use SSL/TLS are not impacted by this issue.
> | Fixed in OpenSSL 3.0.6 (Affected 3.0.0-3.0.5).
> 
> 
> 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-3358
> https://www.cve.org/CVERecord?id=CVE-2022-3358
> [1] https://www.openssl.org/news/secadv/20221011.txt

As 3.0.6 has been retired due to regressions, I guess it's simply best
to wait for 3.0.7.

Regards,
Salvatore



Bug#1021576: Interim gdb log

2022-10-12 Thread ael
Sorry. Had no time to look at this today.

Meanwhile, I attach the gbd log following the suggestion to run linphone
directly under gdb. I suspect that I need some more dbgsym packages
installed to be more useful.

My previous use of gdb was mainly for checking my own programs with
source available etc. Will need to refresh my memory on gdb when I have
time.

Meanwhile the log attached in case in it useful at this stage.

ael

Temporary breakpoint 1 at 0xd9180: file ./linphone-app/src/app/main.cpp, line 
30.
Starting program: /usr/bin/linphone 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe1b8) at 
./linphone-app/src/app/main.cpp:30
30  ./linphone-app/src/app/main.cpp: No such file or directory.
Continuing.
[New Thread 0x7fffe81ff640 (LWP 9424)]
[New Thread 0x7fffe57ff640 (LWP 9425)]
[New Thread 0x7fffe4ffe640 (LWP 9426)]
[New Thread 0x7fffd7dff640 (LWP 9427)]
[New Thread 0x7fffd75fe640 (LWP 9428)]
[New Thread 0x7fffd6dfd640 (LWP 9429)]
[New Thread 0x7fffd65fc640 (LWP 9430)]
[New Thread 0x7fffd5dfb640 (LWP 9431)]
[New Thread 0x7fffd55fa640 (LWP 9432)]
[New Thread 0x7fffd4df9640 (LWP 9433)]
[New Thread 0x7fffa640 (LWP 9434)]
[New Thread 0x7fffaf7fe640 (LWP 9435)]
[New Thread 0x7fffaeffd640 (LWP 9436)]
[New Thread 0x7fffae7fc640 (LWP 9437)]
[Thread 0x7fffae7fc640 (LWP 9437) exited]
[New Thread 0x7fffae7fc640 (LWP 9438)]

Thread 1 "linphone" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.
Continuing.
Couldn't get registers: No such process.
[Thread 0x7fffae7fc640 (LWP 9438) exited]
[Thread 0x7fffaeffd640 (LWP 9436) exited]
[Thread 0x7fffaf7fe640 (LWP 9435) exited]
[Thread 0x7fffd4df9640 (LWP 9433) exited]
[Thread 0x7fffd55fa640 (LWP 9432) exited]
[Thread 0x7fffd5dfb640 (LWP 9431) exited]
[Thread 0x7fffd65fc640 (LWP 9430) exited]
[Thread 0x7fffd6dfd640 (LWP 9429) exited]
[Thread 0x7fffd75fe640 (LWP 9428) exited]
[Thread 0x7fffd7dff640 (LWP 9427) exited]
[Thread 0x7fffe4ffe640 (LWP 9426) exited]
[Thread 0x7fffe57ff640 (LWP 9425) exited]
[Thread 0x7fffe81ff640 (LWP 9424) exited]
[Thread 0x7fffa640 (LWP 9434) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
No stack.
Temporary breakpoint 1 at 0xd9180: file ./linphone-app/src/app/main.cpp, line 
30.
Starting program: /usr/bin/linphone 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe1b8) at 
./linphone-app/src/app/main.cpp:30
30  ./linphone-app/src/app/main.cpp: No such file or directory.
Continuing.
[New Thread 0x7fffe81ff640 (LWP 9459)]
[New Thread 0x7fffe57ff640 (LWP 9460)]
[New Thread 0x7fffe4ffe640 (LWP 9461)]
[New Thread 0x7fffd7dff640 (LWP 9462)]
[New Thread 0x7fffd75fe640 (LWP 9463)]
[New Thread 0x7fffd6dfd640 (LWP 9464)]
[New Thread 0x7fffd65fc640 (LWP 9465)]
[New Thread 0x7fffd5dfb640 (LWP 9466)]
[New Thread 0x7fffd55fa640 (LWP 9467)]
[New Thread 0x7fffd4df9640 (LWP 9468)]
[New Thread 0x7fffa640 (LWP 9469)]
[New Thread 0x7fffa77fe640 (LWP 9470)]
[New Thread 0x7fffaf7fe640 (LWP 9471)]
[New Thread 0x7fffaeffd640 (LWP 9472)]
[Thread 0x7fffaeffd640 (LWP 9472) exited]
[New Thread 0x7fffaeffd640 (LWP 9473)]

Thread 1 "linphone" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.
#0  __pthread_kill_implementation
(threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0)
at ./nptl/pthread_kill.c:44
#1  0x748895df in __pthread_kill_internal (signo=6, threadid=)
at ./nptl/pthread_kill.c:78
#2  0x7483da02 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x74828469 in __GI_abort () at ./stdlib/abort.c:79
#4  0x77d0ca3f in  () at /lib/x86_64-linux-gnu/libbctoolbox.so.1
#5  0x77b37798 in  () at /lib/x86_64-linux-gnu/liblinphone.so.10
#6  0x77b4b5c6 in  () at /lib/x86_64-linux-gnu/liblinphone.so.10
#7  0x77b4cc6a in  () at /lib/x86_64-linux-gnu/liblinphone.so.10
#8  0x77b4d109 in _linphone_core_new_with_config(_LinphoneCoreCbs*, 
_LpConfig*, void*, void*, unsigned char, unsigned char) ()
at /lib/x86_64-linux-gnu/liblinphone.so.10
#9  0x779c3a2c in 
LinphonePrivate::Factory::_createCore(_LinphoneCoreCbs*, char const*, char 
const*, void*, void*, unsigned char) const ()
at /lib/x86_64-linux-gnu/liblinphone.so.10
#10 0x779c3b29 in LinphonePrivate::Factory::createCore(char const*, 
char const*, void*) const () at /lib/x86_64-linux-gnu/liblinphone.so.10
#11 0x77f3c60d in 
linphone::Factory::createCore(std::__cxx11::basic_string, 

Bug#1021683: ITP: qt6-quick3dphysics -- Qt6 Quick 3D Physics module

2022-10-12 Thread Patrick Franz
Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: qt6-quick3dphysics
  Version : 6.4.0
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : GPL-3
  Programming Lang: C++
  Description : Qt6 Quick 3D Physics module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

Qt Quick 3D Physics provides a high-level API for physics simulation.
It supports simulating interactive rigid bodies as well as static meshes
and non-colliding bodies used for detecting overlaps. Every simulated
body can have its own physical properties like mass, density and friction.



Bug#1021682: ITP: qt6-speech -- Qt6 Speech support

2022-10-12 Thread Patrick Franz
Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: qt6-speech
  Version : 6.4.0
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : GPL-2, LGPL-3
  Programming Lang: C++
  Description : Qt6 Speech support

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

QtSpeech provides cross-platform support for real-time text-to-speech output.



Bug#1021681: ITP: qt6-httpserver -- Qt6 HTTP Server module

2022-10-12 Thread Patrick Franz
Package: wnpp
Severity: wishlist
Owner: Patrick Franz 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
delta...@debian.org,debian-qt-...@lists.debian.org

* Package name: qt6-httpserver
  Version : 6.4.0
  Upstream Author : The Qt Company Ltd.
* URL : https://www.qt.io/developers/
* License : GPL-3
  Programming Lang: C++
  Description : Qt6 HTTP Server module

Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.

Qt HTTP Server supports building an HTTP server into an application. It
provides an implementation of the server side of the HTTP protocol, and also
provides security through Transport Layer Security. Because it is designed for
embedding in applications to expose things in a trusted network, and doesn't
have robustness/security as a goal, it is not suitable for being
internet-facing.



Bug#1021680: libmutter-11-0: Segfault when ICC profile of device is garbage

2022-10-12 Thread Emmanuel Fleury

Package: libmutter-11-0
Version: 43.0-2
Severity: important

Dear Maintainer,

I recently stumbled on an old and wacky video-projector device that produce 
garbage ICC profiles. The problem is that it crashes the whole Xserver at once 
with a Segfault.


I tried to understand a bit the bug and I discovered that it was already fixed 
in this MR in the gitlab of mutter:


https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2627

More precisely with this patch:

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2627/diffs?commit_id=a8259240ae3009fd3cd7df4deccefb105b37ba6e

Would it be possible to introduce this patch within the patchsets of the 
debian package?


For now, I built a custom debian package with the patch and I'll test it soon.


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

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

Versions of packages libmutter-11-0 depends on:
ii  adwaita-icon-theme 43-1
ii  gsettings-desktop-schemas  43.0-1
ii  libatk1.0-02.46.0-3
ii  libc6  2.35-3
ii  libcairo-gobject2  1.16.0-6
ii  libcairo2  1.16.0-6
ii  libcanberra0   0.30-10
ii  libcolord2 1.4.6-1
ii  libdrm22.4.113-2
ii  libegl11.5.0-1
ii  libfontconfig1 2.13.1-4.5
ii  libfribidi01.0.8-2.1
ii  libgbm122.2.1-1
ii  libgdk-pixbuf-2.0-02.42.9+dfsg-1
ii  libgl1 1.5.0-1
ii  libglib2.0-0   2.74.0-2
ii  libgnome-desktop-3-20  43-2
ii  libgraphene-1.0-0  1.10.8-1
ii  libgtk-3-0 3.24.34-3
ii  libgudev-1.0-0 237-2
ii  libice62:1.0.10-1
ii  libinput10 1.21.0-1
ii  libjson-glib-1.0-0 1.6.6-1
ii  liblcms2-2 2.13.1-1+b1
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangocairo-1.0-01.50.10+ds-1
ii  libpangoft2-1.0-0  1.50.10+ds-1
ii  libpipewire-0.3-0  0.3.59-1
ii  libsm6 2:1.2.3-1
ii  libstartup-notification0   0.12-6+b1
ii  libsystemd0251.5-2
ii  libudev1   251.5-2
ii  libwacom9  2.4.0-3
ii  libwayland-server0 1.21.0-1
ii  libx11-6   2:1.8.1-2
ii  libx11-xcb12:1.8.1-2
ii  libxau61:1.0.9-1
ii  libxcb-randr0  1.15-1
ii  libxcb-res01.15-1
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.1-1
ii  libxdamage11:1.1.5-2
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxi6 2:1.8-1+b1
ii  libxinerama1   2:1.1.4-3
ii  libxkbcommon-x11-0 1.4.1-1
ii  libxkbcommon0  1.4.1-1
ii  libxkbfile11:1.1.0-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxtst6   2:1.2.3-1.1
ii  mutter-common  43.0-2

libmutter-11-0 recommends no packages.

libmutter-11-0 suggests no packages.

Versions of packages libmutter-11-0 is related to:
ii  libegl-mesa0 [libegl-vendor]  22.2.1-1
ii  libgl1-mesa-dri   22.2.1-1
ii  libglx-mesa0 [libglx-vendor]  22.2.1-1

-- no debconf information


--
Emmanuel Fleury

Maître de conférences,  | Bureau: 261
Univ. Bordeaux, LaBRI,  | Tél: +33 (0)5 4000 69 34
Bât. A30, Domaine Universitaire | Fax: +33 (0)5 4000 66 69
351, Cours de la Libération | Mél: emmanuel.fle...@u-bordeaux.fr
33405 Talence Cedex, France | Web: http://www.labri.fr/~fleury



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1021622: libwxsqlit3-3.0-dev: not coinstallable

2022-10-12 Thread GCS
On Wed, Oct 12, 2022 at 10:36 PM Olly Betts  wrote:
> On Tue, Oct 11, 2022 at 11:28:53PM +0200, Sebastian Ramacher wrote:
> > The following packages have unmet dependencies:
> >  libwxsqlite3-3.2-dev : Breaks: libwxsqlite3-3.0-dev but 3.4.1~dfsg-8 is to 
> > be installed
> > E: Unable to correct problems, you have held broken packages
>
> The problem here is due to this in debian/control in the source package:
[...]
> (We've also resolved the only such package in Debian already, but this
> may be relevant for downstream distros such as Ubuntu if they have
> packages we don't.)
[...]
> Happy to NMU a fix for this.
 Thanks, but libwxsqlite3-3.0-dev is about to stay for a little
longer. Then a fixed package is already uploaded and waiting to be
accepted.

Thanks,
Laszlo/GCS



Bug#1021622: libwxsqlit3-3.0-dev: not coinstallable

2022-10-12 Thread Olly Betts
title -1 libwxsqlite3-3.0-dev: not coinstallable

On Tue, Oct 11, 2022 at 11:28:53PM +0200, Sebastian Ramacher wrote:
> The following packages have unmet dependencies:
>  libwxsqlite3-3.2-dev : Breaks: libwxsqlite3-3.0-dev but 3.4.1~dfsg-8 is to 
> be installed
> E: Unable to correct problems, you have held broken packages

The problem here is due to this in debian/control in the source package:

Package: libwxsqlite3-3.0-dev
Depends: ${misc:Depends}, libwxsqlite3-3.2-dev
Architecture: all
Priority: optional
Section: oldlibs
Description: transitional package
 This is a transitional package. It can safely be removed.

Package: libwxsqlite3-3.2-dev
Architecture: any
Multi-Arch: same
Section: libdevel
Depends:
 libsqlite3-dev,
 libwxgtk3.2-dev,
 libwxsqlite3-3.2-0 (= ${binary:Version}),
 ${misc:Depends}
Recommends:
 pkg-config
Suggests:
 wxsqlite3-doc
Breaks: libwxsqlite3-3.0-dev
Replaces: libwxsqlite3-3.0-dev
Description: Development files for wxSQLite3
 wxSQLite3 is a C++ wrapper around the public domain SQLite 3.x database
 and is specifically designed for use in programs based on the wxWidgets
 3.0 library.
 .
 This package contains the development files for wxSQLite3.

It isn't useful to have a transitional package for libwxsqlite3-3.0-dev
which pulls in libwxsqlite3-3.2-dev - anything which BDs on
libwxsqlite3-3.0-dev will need a source-ful upload to bump it's
wxwidgets build dependencies (typically libwxgtk3.0-gtk3-dev to
libwxgtk3.2-dev).

A package which B-Ds on libwxsqlite3-3.0-dev and libwxgtk3.0-gtk3-dev
but pulls in libwxsqlite3-3.2-dev and libwxgtk3.0-gtk3-dev won't build
(or at least not correctly).

(We've also resolved the only such package in Debian already, but this
may be relevant for downstream distros such as Ubuntu if they have
packages we don't.)

Also, it's not helpful for libwxsqlite3-3.2-dev to break and replace
libwxsqlite3-3.0-dev unless libwxsqlite3-3.2-dev and the
libwxsqlite3-3.0-dev currently in testing genuinely aren't
co-installable.  The lists of installed files don't overlap at least:

https://packages.debian.org/bookworm/amd64/libwxsqlite3-3.0-dev/filelist
https://packages.debian.org/sid/amd64/libwxsqlite3-3.2-dev/filelist

So I think the solution here is to drop the "Package:
libwxsqlite3-3.0-dev" paragraph entirely and drop these from
libwxsqlite3-3.2-dev:

Breaks: libwxsqlite3-3.0-dev
Replaces: libwxsqlite3-3.0-dev

Happy to NMU a fix for this.

Cheers,
Olly



Bug#1021564: RFP: openrocket -- Rocket simulation software

2022-10-12 Thread Bdale Garbee
Petter Reinholdtsen  writes:

> How is this different from the libjogl2-java package with home page
> http://jogamp.org >?  The source seem to be available from
> https://jogamp.org/wiki/index.php/Jogamp_SCM_Repositories >
> pointing to https://github.com/sgothel/ >.

See Debian bug #1011549.  This led to quite some discussion on the
upstream openrocket list openrocket-de...@lists.sourceforge.net, but no
path to resolution yet.  See, for example:

  https://sourceforge.net/p/openrocket/mailman/message/37703498/

Frankly, I don't personally care about 3d rendering in openrocket at
all, so a reasonable path forward for packaging might be to just disable
that functionality entirely.  It's "just for show" and doesn't actually
affect the process of designing and running flight simulations of a
rocket.

Bdale


signature.asc
Description: PGP signature


Bug#932988: dpkg-gensymbols: Please add a option to set the Build-Depends-Package field

2022-10-12 Thread Guillem Jover
Control: user d...@packages.debian.org
Control: usertags -1 dpkg-gensymbols
Control: tag -1 moreinfo

On Thu, 2019-07-25 at 16:59:14 +0200, Jörg Frings-Fürst wrote:
> Package: dpkg-dev
> Version: 1.19.7
> Severity: wishlist
> 
> please add a option to set the Build-Depends-Package meta-information
> field.

This field is supposed to be written into the .symbols file by the
packager. I'm not sure I understand what's being requested here, could
you clarify?

Thanks,
Guillem



Bug#977862: support systems without lchown, perhaps with Gnulib

2022-10-12 Thread Guillem Jover
Control: tag -1 moreinfo

Hi!

On Mon, 2021-08-23 at 22:51:25 +0200, Guillem Jover wrote:
> So, while I'm truly interested in improving portability for dpkg, I'm
> not sure (as in, I've not kept up with times) whether MinGW might be a
> valid target at all? Also AFAIR there's still the problem with its
> GNU system name not being ready to be merged in dpkg.
>·
> dpkg does still make use of fork+exec constructs, which AFAIR were
> problematic on Windows-based systems, and while I'm slowly getting rid
> of them, this is still the case.
>·
> Then there's the dpkg requirements on filesystems
> .
>·
>·
> If lchown() is really the only thing stopping dpkg to be buildable and
> runnable there, I'm happy to consider options here. I think Windows
> gained better symlink support "recently", wouldn't adding lchown()
> support to MinGW be a better option here? But otherwise if there's a
> possibility to add a non-stub version of the function I'd be happy to
> take a patch for it. :)

So given the above, if there's no further input, I think I'll be
closing this in a bit, as this could always be reconsidered once the
arch name situation is solved or a better alternative exists.

Thanks,
Guillem



Bug#1021664: vlc: Automatic hardware acceleration drops most frames

2022-10-12 Thread Miguel A. Vallejo
Rémi Denis-Courmont () wrote:

> That log shows VLC *not* using video acceleration.

But intel-gpu-top shows VLC using the GPU, so it is trying to use
accelerated video. From the very same log I submitted:

libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_15
libva info: va_openDriver() returns 0
[7fd370062690] main generic debug: using hw decoder module
"vdpau_avcodec"
[7fd384c1d9b0] avcodec decoder: Using OpenGL/VAAPI backend for VDPAU
for hardware decoding

> Note that Debian has turned off VA-API support in VLC:

> https://bugs.debian.org/1021601


Any good reason for that decision? It worked wonderfully

Thanks in advance.


Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1

2022-10-12 Thread Francois Le Hir
I have the exact same issue. Installing 0.4.11-5 fixes it.



Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746

2022-10-12 Thread Salvatore Bonaccorso
Hi,

On Wed, Oct 12, 2022 at 07:38:17PM +0200, Moritz Mühlenhoff wrote:
> Source: xen
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerabilities were published for xen.
> 
> CVE-2022-33749[0]:
> | XAPI open file limit DoS It is possible for an unauthenticated client
> | on the network to cause XAPI to hit its file-descriptor limit. This
> | causes XAPI to be unable to accept new requests for other (trusted)
> | clients, and blocks XAPI from carrying out any tasks that require the
> | opening of file descriptors.
> 
> https://xenbits.xen.org/xsa/advisory-413.html

FTR, I think this should not be tracked for src:xen (and upated the
security-tracker already earlier), as it is for xapi (not found in
src:xen but in the earlier removed src:xen-api).

Regards,
Salvatore



Bug#1021672: Cannot reproduce

2022-10-12 Thread Michael Biebl


Control: severity -1 normal
Control: tags -1 unreproducible
Control: close -1

Am 12.10.22 um 21:38 schrieb Matteo Settenvini:

Okay, I retried and I cannot reproduce it now.

I think what happened is:

* my system was hanging at the beginning due to some unrelated problem
with video (mesa).

* I rebooted from a pendrive, and regenerated the initrd with dracut
and hostonly=yes.

* I believe this somehow messed up the kernel modules included in the
initrd by dracut?


That is certainly problematic as the kernel from the pendrive might have 
different modules as builtin.




* Once I rebooted again to a pendrive, I changed the hostonly parameter
to "no", and at the same time downgraded udev.

* Things started working again for the wrong reason.

I apologize for this, it seemed reproducible when I tried at the
beginning. For sure it's a strange bug.

Feel free to downgrade and close this.


Ok


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1021679: tilix: doesn't provide x-terminal-emulator alternative

2022-10-12 Thread realroot
Package: tilix
Version: 1.9.5-2
Severity: minor
X-Debbugs-Cc: scorpion2...@protonmail.com

Dear Maintainer,

This package should provide an alternative for "update-alternatives --config
x-terminal-emulator".

Can I set it manually with some option in ~/.profile meanwhile?


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

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

Versions of packages tilix depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.35-3
ii  libgtkd-3-0  3.10.0-2
ii  libphobos2-ldc-shared100 1:1.30.0-1+b1
ii  libunwind8   1.3.2-2
ii  libvted-3-0  3.10.0-2
ii  libx11-6 2:1.8.1-2
ii  python3-nautilus 1.2.3-3.1+b1
ii  tilix-common 1.9.5-2

tilix recommends no packages.

tilix suggests no packages.

-- no debconf information



Bug#1021678: rust-object: autopkgtest failure on s390x

2022-10-12 Thread Sebastian Ramacher
Source: rust-object
Version: 0.29.0-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://ci.debian.net/data/autopkgtest/testing/s390x/r/rust-object/26973632/log.gz

test round_trip::elf::symtab_shndx ... FAILED

failures:

 round_trip::elf::symtab_shndx stdout 
thread 'round_trip::elf::symtab_shndx' panicked at 'assertion failed: `(left == 
right)`
  left: `Section(SectionIndex(16711680))`,
 right: `Section(SectionIndex(65280))`', tests/round_trip/elf.rs:38:9
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.60.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.60.0/library/core/src/panicking.rs:143:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
 at /usr/src/rustc-1.60.0/library/core/src/panicking.rs:182:5
   4: integration::round_trip::elf::symtab_shndx
 at ./tests/round_trip/elf.rs:38:9
   5: integration::round_trip::elf::symtab_shndx::{{closure}}
 at ./tests/round_trip/elf.rs:10:1
   6: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.60.0/library/core/src/ops/function.rs:227:5
   7: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.60.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.


failures:
round_trip::elf::symtab_shndx

test result: FAILED. 23 passed; 1 failed; 0 ignored; 0 measured; 0 filtered 
out; finished in 1.26s

error: test failed, to rerun pass '--test integration'
autopkgtest [20:36:50]: test librust-object-dev:all: ---]
autopkgtest [20:36:50]: test librust-object-dev:all:  - - - - - - - - - - 
results - - - - - - - - - -
librust-object-dev:all FAIL non-zero exit status 101


Cheers
-- 
Sebastian Ramacher



Bug#1021672: Cannot reproduce

2022-10-12 Thread Matteo Settenvini
Okay, I retried and I cannot reproduce it now.

I think what happened is:

* my system was hanging at the beginning due to some unrelated problem
with video (mesa).

* I rebooted from a pendrive, and regenerated the initrd with dracut
and hostonly=yes.

* I believe this somehow messed up the kernel modules included in the
initrd by dracut?

* Once I rebooted again to a pendrive, I changed the hostonly parameter
to "no", and at the same time downgraded udev.

* Things started working again for the wrong reason.

I apologize for this, it seemed reproducible when I tried at the
beginning. For sure it's a strange bug.

Feel free to downgrade and close this.


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


Bug#1021311: vlc: No sound with some AAC encoded MKV videos

2022-10-12 Thread Sebastian Ramacher
Control: forwarded -1 https://code.videolan.org/videolan/vlc/-/issues/27421

On 2022-10-12 16:05:00 +0200, Miguel A. Vallejo wrote:
> Hello!
> 
> I uploaded a small 10 second long video that shows the problem with VLC:
> 
> https://www.dropbox.com/s/a5p2850q1npw5c6/testvideo.mkv?dl=1
> 
> Video plays fine but no audio with VLC. Other players like mpv or ffplay
> play audio nicely.
> 
> Thanks in advance.

Forwarded upstream.

Cheers
-- 
Sebastian Ramacher



Bug#1021677: bugs.debian.org: Video fails to play in any web browser (chrome, firefox); music fails to play in Spotify

2022-10-12 Thread Steven Zalek
Package: bugs.debian.org
Severity: normal
X-Debbugs-Cc: zalek.ste...@gmail.com

Dear Maintainer,

I attempted to play a video clip on a web news site, on youtube, etc. The video
attempts to load and run but freezes within the first second. This applies to
any clip at any web site.

I attempted to play a song through the Spotify music play. The song attempts to
start, and then the application indicates 'Can't play the current song'. This
applies to any song selected.

This is a very recent situation (about 1-2 days old, at most), probably from a
recent update.

I tested these application on the Windows side of this dual-boot machine -
these applications still work just fine in Windows 10,

Attempts to resolve the situation:
 - removed various security and privacy protocols in the web browsers and tried
video again
 - installed extra codecs via apt
 - installed pipewire-pulseaudio package

Nothing I have done has resolved the issue.

Please let me know what other troubleshooting steps I can take to help resolve
this.



Bug#1021672: udev: No USB (no keyboard nor FIDO token!) at boot after update from udev 251.5-1 to 252.5-2

2022-10-12 Thread Matteo Settenvini
How can I instruct the kernel to save the logs to a file?

The rootfs is not mounted (so the logs cannot be persisted by
journald), and I have no keyboard to be dropped to a init shell and
save e.g. /run/initramfs/rdsosreport.txt or the output of any log in
RAM to an unencrypted partition.

I don't seem able to find a relevant option in the man page, apologies.

Il giorno mer, 12/10/2022 alle 20.23 +0200, Michael Biebl ha scritto:
> Am 12.10.22 um 20:18 schrieb Michael Biebl:
> 
> > Please remove "debug" from the kernel command line and capture the
> > log 
> > messages
> 
> I meant to say "quiet".
> You can also add "systemd.log_level=debug" to increase the verbosity.
> See man kernel-command-line.


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


Bug#1021152: audacity: FTBFS on armel, s390x

2022-10-12 Thread Jochen Sprickerhof

Hi Benjamin,

we discussed this in #debian-devel yesterday and found:

For armel it fails at:

https://github.com/audacity/audacity/blob/master/libraries/lib-utility/MemoryX.h#L622

which was introduced here:

https://github.com/audacity/audacity/pull/3028

And for s390x it is:


 124 | #error All sample block data is little endian...big endian not yet 
supported


Both errors don't seem to be easy to fix so I would propose to remove 
the old build from unstable and downgrade this bug report to lat 
Audacity transition to testing again.


I will do that tomorrow if you don't disagree.

Cheers Jochen

* Scott Talbert  [2022-10-02 17:41]:

Source: audacity
Version: 3.2.0+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

audacity 3.2.0+dfsg-1 FTBFS on armel and s390x.

Tail of log for audacity on armel:
/usr/include/c++/12/bits/stl_vector.h:1287:28: note: parameter passing for argument of type 
‘__gnu_cxx::__normal_iterator >’ changed 
in GCC 7.1
1287 |   _M_realloc_insert(end(), __x);
 |   ~^~~~
In member function ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with 
_Tp = LabelStruct; _Alloc = std::allocator]’,
   inlined from ‘void LabelTrack::Import(wxTextFile&)’ at 
/<>/src/LabelTrack.cpp:592:27:
/usr/include/c++/12/bits/stl_vector.h:1287:28: note: parameter passing for argument of type 
‘__gnu_cxx::__normal_iterator >’ changed 
in GCC 7.1
1287 |   _M_realloc_insert(end(), __x);
 |   ~^~~~
make[3]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[2]: *** [CMakeFiles/Makefile2:1922: src/CMakeFiles/Audacity.dir/all] Error 
2
make[2]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[1]: *** [Makefile:159: all] Error 2
make[1]: Leaving directory '/<>/obj-arm-linux-gnueabi'
dh_auto_build: error: cd obj-arm-linux-gnueabi && make -j8 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:47: binary-arch] Error 25

Tail of log for audacity on s390x:
[ 65%] Building CXX object src/CMakeFiles/Audacity.dir/SseMathFuncs.cpp.o
cd /<>/obj-s390x-linux-gnu/src && /usr/bin/c++ -DAUDACITY_DLL_API="" -DAUDIO_DEVICES_API="" -DAUDIO_GRAPH_API="" -DAudacity_EXPORTS -DBASIC_UI_API="" -DBUILDING_AUDACITY -DCMAKE -DCOMPONENTS_API="" -DEXCEPTIONS_API="" -DEXPERIMENTAL_CRASH_REPORT -DEXPERIMENTAL_DRAGGABLE_PLAY_HEAD -DEXPERIMENTAL_FULL_WASAPI -DEXPERIMENTAL_HALF_WAVE -DEXPERIMENTAL_KEY_VIEW -DEXPERIMENTAL_MIDI_OUT -DEXPERIMENTAL_MODULE_PREFS -DEXPERIMENTAL_NOISE_REDUCTION -DEXPERIMENTAL_NOTETRACK_OVERLAY -DEXPERIMENTAL_NYQUIST_SPLIT_CONTROL -DEXPERIMENTAL_PUNCH_AND_ROLL -DEXPERIMENTAL_SCIENCE_FILTERS -DEXPERIMENTAL_SCROLLING_LIMITS -DEXPERIMENTAL_SCRUBBING_SCROLL_WHEEL -DEXPERIMENTAL_SCRUBBING_SUPPORT -DEXPERIMENTAL_SPECTRAL_EDITING -DEXPERIMENTAL_SYNC_LOCK 
-DEXPERIMENTAL_THEMING -DEXPERIMENTAL_TWO_TONE_TIME_RULER -DEXPERIMENTAL_ZOOM_TOGGLE_BUTTON -DFFMPEG_SUPPORT_API="" -DFILES_API="" -DGRAPHICS_API="" -DHAVE_LRINT -DHAVE_LRINTF -DHAVE_MLOCK -DIPC_API="" -DMATH_API="" -DMODULE_MANAGER_API="" -DPREFERENCES_API="" -DPROJECT_API="" -DPROJECT_HISTORY_API="" -DPROJECT_RATE_API="" -DREGISTRIES_API="" -DSAMPLE_TRACK_API="" -DSCREEN_GEOMETRY_API="" -DSTRINGS_API="" -DSTRING_UTILS_API="" -DTHEME_API="" -DTHEME_RESOURCES_API="" -DTRACK_API="" -DTRANSACTIONS_API="" -DUSE_FFMPEG -DUSE_NYQUIST=1 -DUSE_PORTMIXER=1 -DUTILITY_API="" -DUUID_API="" -DWXUSINGDLL -DXML_API="" 
-D_FILE_OFFSET_BITS=64 -D__WXGTK__ -I/<>/obj-s390x-linux-gnu/src/private -I/<>/include -I/<>/src -I/<>/libraries/lib-string-utils -I/<>/libraries/lib-uuid -I/<>/libraries/lib-project-rate -I/<>/libraries/lib-project -I/<>/libraries/lib-registries -I/<>/libraries/lib-preferences -I/<>/libraries/lib-utility -I/<>/libraries/lib-basic-ui -I/<>/libraries/lib-strings -I/<>/libraries/lib-components -I/<>/libraries/lib-exceptions -I/<>/libraries/lib-xml 
-I/<>/libraries/lib-files -I/<>/libraries/lib-audio-devices -I/<>/lib-src/portmixer/include -I/<>/libraries/lib-math -I/<>/libraries/lib-theme-resources -I/<>/libraries/lib-theme -I/<>/libraries/lib-sample-track -I/<>/libraries/lib-audio-graph -I/<>/libraries/lib-track -I/<>/libraries/lib-module-manager -I/<>/libraries/lib-ipc -I/<>/libraries/lib-project-history -I/<>/libraries/lib-screen-geometry -I/<>/libraries/lib-transactions 
-I/<>/libraries/lib-graphics -I/<>/libraries/lib-ffmpeg-support -I/<>/libraries/lib-sentry-reporting -I/<>/lib-src/libnyquist -isystem /usr/lib/s390x-linux-gnu/wx/include/gtk3-unicode-3.2 -isystem /usr/include/wx-3.2 -isystem /usr/include/lame -isystem /usr/include/lilv-0 -isystem /usr/include/sratom-0 -isystem /usr/include/sord-0 -isystem /usr/include/serd-0 -isystem /usr/include/suil-0 -isystem /usr/include/portSMF -isystem /usr/include/soundtouch -isystem /usr/include/glib-2.0 -isystem /usr/lib/s390x-linux-gnu/glib-2.0/include -isystem /usr/include/gtk-3.0 -isystem 

Bug#1021676: r-cran-leidenbase: autopkgtest failure on several architectures

2022-10-12 Thread Adrian Bunk
Source: r-cran-leidenbase
Version: 0.1.12-1
Severity: serious
Control: block 1019706 by -1

https://ci.debian.net/data/autopkgtest/testing/arm64/r/r-cran-leidenbase/26869942/log.gz

...
BEGIN TEST testthat.R

R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: aarch64-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> testthat::test_check("leidenbase")
Loading required package: leidenbase
[ FAIL 1 | WARN 0 | SKIP 0 | PASS 27 ]

══ Failed tests 
── Failure (test-leidenbase.R:253:5): modularity and significance return values 
──
`t11_v01` not equal to `t11_v01_expect`.
1/1 mismatches
[1] 0.71 - 0.71 == 0.000133

[ FAIL 1 | WARN 0 | SKIP 0 | PASS 27 ]
Error: Test failures
Execution halted
autopkgtest [23:40:06]: test run-unit-test: ---]
autopkgtest [23:40:06]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 1
...


Bug#1021675: ariba: autopkgtest regression and ftbfs with samtools 1.16

2022-10-12 Thread Étienne Mollier
Source: ariba
Version: 2.14.6+ds-3
Severity: serious
Tags: ftbfs upstream help
Justification: fails to build from source (but built successfully in the past)

Greetings,

Following the upgrade of htslib, samtools and bcftools from
versions 1.13 to 1.16, ariba hits autopkgtest regressions which
are preventing migration of python-pysam to testing.  The test
failures are also present during the build time test suite,
causing the package to fail to build from source.

I attempted to begin wrapping up a patch fixing/working around
the problem which looks to be caused by the migration of mpileup
functionalities from samtools to bcftools, but the test suite
then chokes on non-matching command output, for which I don't
know whether the new results are sound and simply need
adjustments, or if errors could have been left over.  Temporary
patch is below for reference, but is not sufficient on his own
to fix the failure:

---8<--8<--8<--8<---
--- a/ariba/samtools_variants.py
+++ b/ariba/samtools_variants.py
@@ -1,6 +1,7 @@
 import os
 import sys
 import pysam
+import pysam.bcftools
 import pyfastaq
 import vcfcall_ariba
 
@@ -36,13 +37,11 @@
 
 tmp_vcf = self.vcf_file + '.tmp'
 with open(tmp_vcf, 'w') as f:
-print(pysam.mpileup(
+print(pysam.bcftools.mpileup(
 '-t', 'INFO/AD,INFO/ADF,INFO/ADR',
 '-L', '',
 '-A',
 '-f', self.ref_fa,
-'-u',
-'-v',
 self.bam,
 ), end='', file=f)
 
---8<--8<--8<--8<---

I already provided upstream with my findings on their issue
tracker[1] in a related entry, but I don't know for sure how
much active they are these days.  This note in debbugs is mostly
to document the issue for Med team members before they spend too
much time debugging this issue in parallel (and also seeking
help if possible).

[1]: https://github.com/sanger-pathogens/ariba/issues/327

Have a nice day,  :)
Étienne.

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

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

-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.
On air: Gazpacho - Valerie's Friend


signature.asc
Description: PGP signature


Bug#1021662: libosip2: CVE-2022-41550

2022-10-12 Thread Aymeric Moizard
Hi,

I made an official version which includes the fix.
http://ftp.gnu.org/gnu/osip/libosip2-5.3.1.tar.gz

Best Regards,
Aymeric

Le mer. 12 oct. 2022 à 17:39, Salvatore Bonaccorso  a
écrit :

> Source: libosip2
> Version: 5.3.0-2
> Severity: important
> Tags: security upstream
> Forwarded: https://savannah.gnu.org/bugs/?63103
> X-Debbugs-Cc: car...@debian.org, Debian Security Team <
> t...@security.debian.org>
>
> Hi,
>
> The following vulnerability was published for libosip2.
>
> CVE-2022-41550[0]:
> | GNU oSIP v5.3.0 was discovered to contain an integer overflow via the
> | component osip_body_parse_header.
>
>
> 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-41550
> https://www.cve.org/CVERecord?id=CVE-2022-41550
> [1] https://savannah.gnu.org/bugs/?63103
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore
>
>

-- 
Antisip - http://www.antisip.com


Bug#1021588: Please apply the proposed fix (revert) for hi-dpi thumbnailing, until glib is properly fixed

2022-10-12 Thread Amr Ibrahim
Am Mittwoch, dem 12.10.2022 um 13:11 -0400 schrieb Jeremy Bicha:
> 
> We'll fix this in glib. My understanding is that the glib fix is
> sufficient to not need to patch Nautilus.
> 

Yes, that's also my understanding.

Best,
Amr



Bug#969202: ITA: binutils-avr -- Binary utilities supporting Atmel's AVR targets

2022-10-12 Thread Steve M
Joshua,

It has been a little over a year since you changed binutils-avr from RFA to ITA.
Do you still intend to proceed with this adoption? If not, please consider
returning it to RFA as I am considering adopting avr-libc, binutils-avr, and
gcc-avr as a group.

Thanks
-Steve



Bug#1010152: emacs-gtk: tries to read a config file from another user's home dir

2022-10-12 Thread Paul Gevers

Control: fixed -1 1:27.2~

On Mon, 25 Apr 2022 15:40:26 +0200 Vincent Lefevre  
wrote:

Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42827

On 2022-04-25 15:37:08 +0200, Vincent Lefevre wrote:
> This is also fixed in upstream's 27.2.

2020-08-17  Robert Pluim  

Fix bug with ~/Emacs file not being read at init

* src/xrdb.c (get_user_app): Put "/" between homedir
and %L or %N (Bug#42827).


So, let's mark this bug as fixed. I'm not closing the bug, I leave that 
to the maintainer and/or bug submitter.


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1021674: src:kpcli: fails to migrate to testing for too long: uploader built arch:all binary

2022-10-12 Thread Paul Gevers

Source: kpcli
Version: 3.7-1
Severity: serious
Control: close -1 3.8.1-1
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

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:kpcli has been trying to migrate for 61 
days [2]. Hence, I am filing this bug.


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.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1021673: Acknowledgement (Wrong __cplusplus definition when using -std=c++20)

2022-10-12 Thread Marco Trevisan
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93821

Upstream commit fixing this is
https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=libcpp/init.c;h=445430e16bd08ade34637d2346ded40dd49de508



Bug#1021672: udev: No USB (no keyboard nor FIDO token!) at boot after update from udev 251.5-1 to 252.5-2

2022-10-12 Thread Michael Biebl

Am 12.10.22 um 20:18 schrieb Michael Biebl:

Please remove "debug" from the kernel command line and capture the log 
messages


I meant to say "quiet".
You can also add "systemd.log_level=debug" to increase the verbosity.
See man kernel-command-line.


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1021672: udev: No USB (no keyboard nor FIDO token!) at boot after update from udev 251.5-1 to 252.5-2

2022-10-12 Thread Michael Biebl
On Wed, 12 Oct 2022 19:39:40 +0200 Matteo Settenvini 
 wrote:

Package: udev
Version: 251.5-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I have a root partition (separate from the boot partition) which is 
encrypted with LUKS and unlocked at boot.


After an upgrade to udev 251.5-2, keyboard, mouse, and FIDO 
token (all three USB devices) are not primed during boot. This is 
easy to see by just attempting to hit BlockNum on the keyboard 
(the light does not come on).


Hence, there is no way anymore for me to unlock the root
filesystem, which renders the whole system unusable.

Note: I use dracut, although I do not think it is to blame here.

Booting from a USB pendrive, and downgrading to udev 251.5-1 
(along with systemd) fixes the issue.


Let me know how I can provider better information to you.


Please remove "debug" from the kernel command line and capture the log 
messages


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1021673: Wrong __cplusplus definition when using -std=c++20

2022-10-12 Thread Marco Trevisan
Package: g++
Version: 4:10.2.1-1

In bullseye:

$ echo | g++ -dM -E -x c++ -std=c++20 - |grep _cplusplus
#define __cplusplus 201709L

It should instead be:

#define __cplusplus 202002L



Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT

2022-10-12 Thread Aurelien Jarno
On 2022-10-12 10:59, Johannes Schauer Marin Rodrigues wrote:
> Quoting Aurelien Jarno (2022-10-11 22:14:31)
> > From what I have understood from your explanation, if the directory exists
> > chroot_canon() will work, so `ldconfig -r` will be able to create the
> > aux-cache file in it.
> 
> I can confirm this conclusion. The following patch makes our CI pass without
> any other changes to glibc.
> 
> --- glibc-2.35/debian/debhelper.in/libc-bin.dirs2022-09-22 
> 22:06:02.0 +0200
> +++ glibc-2.35/debian/debhelper.in/libc-bin.dirs2022-10-12 
> 10:15:46.0 +0200
> @@ -1,2 +1,3 @@
>  usr/lib/locale
>  usr/share/libc-bin
> +var/cache/ldconfig

Thanks for the test. It needs a bit more than that though, as we want a
0700 permission.
 
> > I still think that the bug should be fixed on the glibc upstream side,
> > but that would allow to easy fix it on the package side, and it's
> > probably better to have a closer match of the dpkg database and the file
> > system.
> 
> Though I have heard from some people that they want packages to ship only 
> files
> under /usr and have everything else be created upon instantiation of the
> machine. This change would go the opposite direction.

This would need more changes though, ldconfig also currently does not
work if /var/cache doesn't exist.

Cheers
Aurelien

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


signature.asc
Description: PGP signature


Bug#1021671: shiro: CVE-2022-40664

2022-10-12 Thread Moritz Mühlenhoff
Source: shiro
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for shiro.

CVE-2022-40664[0]:
| Apache Shiro before 1.10.0, Authentication Bypass Vulnerability in
| Shiro when forwarding or including via RequestDispatcher.

https://www.openwall.com/lists/oss-security/2022/10/12/1

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

Please adjust the affected versions in the BTS as needed.



Bug#1021670: nomad: CVE-2022-41606

2022-10-12 Thread Moritz Mühlenhoff
Source: nomad
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for nomad.

CVE-2022-41606[0]:
| HashiCorp Nomad and Nomad Enterprise 1.0.2 up to 1.2.12, and 1.3.5
| jobs submitted with an artifact stanza using invalid S3 or GCS URLs
| can be used to crash client agents. Fixed in 1.2.13, 1.3.6, and 1.4.0.

https://discuss.hashicorp.com/t/hcsec-2022-22-nomad-panics-on-job-submission-with-bad-artifact-stanza-source-url/45420

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

Please adjust the affected versions in the BTS as needed.



Bug#1021669: poppler: CVE-2022-24106

2022-10-12 Thread Moritz Mühlenhoff
Source: poppler
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for poppler.

CVE-2022-24106[0]:
| In Xpdf prior to 4.04, the DCT (JPEG) decoder was incorrectly allowing
| the 'interleaved' flag to be changed after the first scan of the
| image, leading to an unknown integer-related vulnerability in
| Stream.cc.

This was fixed in xpdf, but also seems to affect Poppler, I reported
it upstream at https://gitlab.freedesktop.org/poppler/poppler/-/issues/1297

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

Please adjust the affected versions in the BTS as needed.



Bug#983861: k3b: Permissions of external program should be of group "cdrom" and not "operator"

2022-10-12 Thread Fab Stz
Hello Norbert,

This is still relevant for 22.04.2-1

Would you please add that patch to the package?

Since the "operator" group is present on a fresh install of Debian, and since 
it is prefered to have group "cdrom" used by k3b, I think it would be better 
if the patch was applied.

Rgds
Fab


Le mardi 2 mars 2021, 16:59:35 CEST Fab Stz a écrit :
> Hello,
> 
> > Well, the original code is rather bad indeed, because it relies on the
> > order of groups returned by getgrent, and picks the *last* available
> > one. In your case, if you have an "operator" group, it will be used.
> 
> Ok, this explains it then.
> 
> Well it's a fresh debian install of testing/bullseye to find some bugs
> before the upcoming release. And on a fresh install "operator" group is
> present.
> 
> If k3b's deb could be fixed for the next release of debian so that the
> package conforms debian's policies that would be great. I think this patch
> is sufficient since the group that fits this purpose, according to the
> group definition is "cdrom", so no need to search any other, and on debian
> it does exist.
> 
> Regards
> 
> Le mardi 2 mars 2021, 14:31:12 CET Norbert Preining a écrit :
> > Hi,
> > 
> > not that I am an expert, and cd burning is anyway only for maniacs (like
> > me!!!) who want to get into contact with whom-who-must-not-be-named.
> > 
> > > With k3b, when wanting to set the external program permissions, it wants
> > > to
> > > set them with user "operator" instead of "cdrom" which may be more
> > > adequate
> > > 
> > >  while (::group *g = ::getgrent()) {
> > >  
> > >  const QString groupName = QString::fromLocal8Bit(g->gr_name);
> > > 
> > > -if (groupName == "cdrom" ||
> > > -groupName == "optical" ||
> > > -groupName == "operator" ) {
> > > +if (groupName == "cdrom") {
> > > 
> > >  m_permissionModel->setBurningGroup(groupName);
> > >  
> > >  }
> > >  
> > >  }
> > 
> > Well, the original code is rather bad indeed, because it relies on the
> > order of groups returned by getgrent, and picks the *last* available
> > one. In your case, if you have an "operator" group, it will be used.
> > 
> > I am not sure, maybe this is intended, but I guess there should be
> > either a break out of the loop after the first groupname is found,
> > or something else.
> > 
> > Best
> > 
> > Norbert
> > 
> > --
> > PREINING Norbert  https://www.preining.info
> > Fujitsu Research Labs  +  IFMGA Guide + TU Wien + TeX Live + Debian Dev
> > GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746

2022-10-12 Thread Moritz Mühlenhoff
Source: xen
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for xen.

CVE-2022-33749[0]:
| XAPI open file limit DoS It is possible for an unauthenticated client
| on the network to cause XAPI to hit its file-descriptor limit. This
| causes XAPI to be unable to accept new requests for other (trusted)
| clients, and blocks XAPI from carrying out any tasks that require the
| opening of file descriptors.

https://xenbits.xen.org/xsa/advisory-413.html

CVE-2022-33748[1]:
| lock order inversion in transitive grant copy handling As part of
| XSA-226 a missing cleanup call was inserted on an error handling path.
| While doing so, locking requirements were not paid attention to. As a
| result two cooperating guests granting each other transitive grants
| can cause locks to be acquired nested within one another, but in
| respectively opposite order. With suitable timing between the involved
| grant copy operations this may result in the locking up of a CPU.

https://xenbits.xen.org/xsa/advisory-411.html

CVE-2022-33747[2]:
| Arm: unbounded memory consumption for 2nd-level page tables Certain
| actions require e.g. removing pages from a guest's P2M (Physical-to-
| Machine) mapping. When large pages are in use to map guest pages in
| the 2nd-stage page tables, such a removal operation may incur a memory
| allocation (to replace a large mapping with individual smaller ones).
| These memory allocations are taken from the global memory pool. A
| malicious guest might be able to cause the global memory pool to be
| exhausted by manipulating its own P2M mappings.

https://xenbits.xen.org/xsa/advisory-409.html

CVE-2022-33746[3]:
| P2M pool freeing may take excessively long The P2M pool backing second
| level address translation for guests may be of significant size.
| Therefore its freeing may take more time than is reasonable without
| intermediate preemption checks. Such checking for the need to preempt
| was so far missing.

https://xenbits.xen.org/xsa/advisory-410.html

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-33749
https://www.cve.org/CVERecord?id=CVE-2022-33749
[1] https://security-tracker.debian.org/tracker/CVE-2022-33748
https://www.cve.org/CVERecord?id=CVE-2022-33748
[2] https://security-tracker.debian.org/tracker/CVE-2022-33747
https://www.cve.org/CVERecord?id=CVE-2022-33747
[3] https://security-tracker.debian.org/tracker/CVE-2022-33746
https://www.cve.org/CVERecord?id=CVE-2022-33746

Please adjust the affected versions in the BTS as needed.



Bug#1021667: RFS: ghostwriter/2.1.6 dfsg-1 [RC] -- Distraction-free, themeable Markdown editor

2022-10-12 Thread Sebastien Chavaux
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "ghostwriter":

 * Package name : ghostwriter
   Version  : 2.1.6+dfsg-1
   Upstream contact : wereturtle 
 * URL  : https://ghostwriter.kde.org/
 * License  : Expat, GPL-3.0+, CC-BY-SA-4.0, GPL-3.0, ISC
 * Vcs  : https://salsa.debian.org/seb95-guest/ghostwriter
   Section  : editors

The source builds the following binary packages:

  ghostwriter - Distraction-free, themeable Markdown editor

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

  https://mentors.debian.net/package/ghostwriter/

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

  dget -x
https://mentors.debian.net/debian/pool/main/g/ghostwriter/ghostwriter_2.1.6+dfsg-1.dsc

Changes since the last upload:

 ghostwriter (2.1.6+dfsg-1) unstable; urgency=medium
 .
   * New upstream release.
   * debian/control: set Standards-Version: to 4.6.1
   * debian/control: address correction
   * debian/watch: address correction
   * vulnerability patched in 3rdparty/cmark-gfm CVE-2022-24724,
CVE-2022-39209
   (Closes: #1006757).

Regards,


Bug#1021576: Small update

2022-10-12 Thread Dennis Filder
X-Debbugs-Cc: ael 

On Wed, Oct 12, 2022 at 11:12:07AM +0100, ael wrote:
> A quick note in haste.
>
> Seems that I had ulimit still slightly too small.
>
> Trying to get a backtrace on a full core
> ($ ls -ltrh core
> -rw--- 1 ael ael 229M Oct 12 11:06 core
> )
>
> gives:
> (gdb) bt
> #0  0x7f623be8957c in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fff724b0460

Is there a reason you're not running linphone under GDB directly?
Nowadays there usually no need to mess with coredumps anymore.  Just
run:

  gdb linphone

then type:

  start
  continue
  bt

Regards.



Bug#1021666: mesa: Add wayland-protocols version >= 1.24 to Mesa's Build-Depends

2022-10-12 Thread Christopher Obbard
Source: mesa
Version: 22.2.0-1
Severity: normal

Dear Maintainer,

With older version of wayland-protocols package available (1.20),
the build starts but fails late with:

  Dependency wayland-protocols found: NO found 1.20 but need: '>= 1.24'
  Invalid version of dependency, need 'wayland-protocols' ['>= 1.24'] found 
'1.20'.
  CMake binary for 1 is cached as not found
  CMake binary for machine 1 not found. Giving up.
  Run-time dependency wayland-protocols found: NO
  ../meson.build:2057:2: ERROR: Invalid version of dependency, need 
'wayland-protocols' ['>= 1.24'] found '1.20'.

Can we add a direct version to the wayland-protocols
dependency of >= 1.24 to catch this error earlier?


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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



Bug#1021588: Please apply the proposed fix (revert) for hi-dpi thumbnailing, until glib is properly fixed

2022-10-12 Thread Jeremy Bicha
Control: reassign -1 src:glib2.0 2.74.0-2
Control: affects -1 src:nautilus

We'll fix this in glib. My understanding is that the glib fix is
sufficient to not need to patch Nautilus.

Thank you,
Jeremy Bicha



Bug#1021664: vlc: Automatic hardware acceleration drops most frames

2022-10-12 Thread Rémi Denis-Courmont
Le keskiviikkona 12. lokakuuta 2022, 18.47.05 EEST Miguel A. Vallejo a écrit :
> Package: vlc
> X-Debbugs-Cc: ea4...@gmail.com
> Version: 3.0.18~rc2-1
> Severity: important
> 
> Dear Maintainer,
> 
> The last available versions of VLC have problems displaying h264 video
> using hardware acceleration.
(...)
> vlc -vvv shows this:

That log shows VLC *not* using video acceleration.

Note that Debian has turned off VA-API support in VLC:
https://bugs.debian.org/1021601

-- 
Rémi Denis-Courmont
http://www.remlab.net/



Bug#1021576: linphone-desktop: Core dumped: Program terminated with signal SIGABRT, Aborted.

2022-10-12 Thread Dennis Filder
On Wed, Oct 12, 2022 at 12:31:58PM +0200, Bernhard Schmidt wrote:
> Am 11.10.22 um 18:19 schrieb Dennis Filder:
>
> > The change in 5.0.37-6 was tiny and I doubt it broke something.  But
> > maybe you're running into #1021125: liblinphone10:amd64 5.0.37-6 is
> > already linked against soci/4.0.3-1, but liblime0 5.0.37+dfsg-4 is
> > still linked against soci/4.0.1-5 and there was an ABI break.  You'd
> > have to downgrade to 5.0.37-5 and soci 4.0.1-5 and wait until either
> > that bug gets fixed or lime will be rebuilt and reuploaded.
>
> Shall we just do a new upload of liblime0 then?

That would be nice.

> liblime and linphone are the only reverse dependencies in the archive, and
> linphone has already been rebuilt against the new version/ABI. I doubt one
> can fix the soci ABI bump without breaking linphone again, so we could just
> go forward and rebuild lime.

While it would make addressing #1021125 less urgent, that bug still
needs to be fixed eventually for Bookworm.  Otherwise people might
falsely assume they can stay on soci 4.0.1 while upgrading
liblinphone10 and liblime0 to 5.0.37 (or their 5.1 successors).
Having it fixed before the linphone-stack 5.1/4.4 uploads would save
work.

Regards



Bug#1016047: RFH: chromium -- web browser

2022-10-12 Thread karthek
On Mon, 25 Jul 2022 21:45:33 -0400 Andres Salomon  wrote:
> Package: wnpp
> Severity: normal
> 
> I'm currently the only active maintainer for the chromium package in 
> Debian. This really needs to be maintained by a team, especially since 
> it requires security updates for stable at least two times per month. 
> It is likely that chromium will not be included in the next stable 
> release (bookworm) unless there's an active team maintaining it, as 
> described in . I've done a lot of 
> simplification of the chromium patches and packaging in order to make 
> it easier for people to join the team.
> 
> There are lots of available tasks to do, depending on someone's skill 
> and hardware. I've listed some tasks/roles below, with the most urgent 
> at the top.
> 
> 
> 1) Security updates. These usually only require Debian packaging 
> knowledge, and be pretty simple. Most security updates can be built 
> without having to touch any of the chromium patches, with only a 
> debian/changelog entry update. However, builds take 3 hours on my 8 
> cpu/32gb build machine (45 mins at best with ccache, due to a lot of 
> python and node build stuff that can't be cached), so you'll want 
> access to some good hardware. These can also happen at any time; 
> holidays, weekends, even a day or two before a scheduled release. 
> Ideally several people would be available for packaging security 
> updates.
> 
> 
> 2) Fixing bugs. There's plenty of bugs at
> . 
> Some require simple follow-ups with the reporter to see if it's still 
> an issue, others require in-depth C++ or chromium knowledge or special 
> hardware, and still others require just testing out a build-argument to 
> see if some feature is safe to enable.
> 
> 
> 3) Getting patches upstream. When I took over the package 6mo ago, 
> there were around 70 or 80 debian patches. We're down to 43 patches. 
> Only about 10 of those are debian-specific; the rest are patches that 
> really belong upstream. If you want to actually hack on chromium, this 
> is probably a good way to get started.
> 
> 
> 4) Improving chromium's privacy, as described at 
> .
>  
> It'd be really nice to not have chromium "phone home" to google.
> 
> 
> Please consider helping out! There's surely more stuff that's needed to 
> do as well, that I've forgotten about.
> 
> 
> 
>

I can help. But chromium builds(default config) are taking more than an hour in 
my
machine. I tried helping but got no response last year during the time
Michael Gilbert took a holiday from uploads.

I think i can help with small things here and there.

Like this pull request:
https://salsa.debian.org/mimi8/chromium/-/merge_requests/4



Bug#1021665: lnav: FTBFS on mipsel: cc1plus: out of memory allocating 189688476 bytes after a total of 28327936 bytes

2022-10-12 Thread Salvatore Bonaccorso
Source: lnav
Version: 0.11.1~rc1-1~exp1
Severity: serious
Tags: help
Justification: FTBFS
X-Debbugs-Cc: car...@debian.org,debian-m...@lists.debian.org

Hi

lnav/0.11.1~rc1-1~exp1 in experimental with the new upstream version
0.11.1~rc1 FTBFS on mipsel:

https://buildd.debian.org/status/package.php?p=lnav=experimental

Help from mips* porters would be very welcome!

Regards,
Salvatore



Bug#1021648: buster-pu: package node-xmldom/0.1.27+ds-1+deb10u1

2022-10-12 Thread Salvatore Bonaccorso
Hi,

On Wed, Oct 12, 2022 at 10:12:09AM +0200, Yadd wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> [ Reason ]
> node-xmldom is vulnerable to prototype pollution
> 
> [ Impact ]
> Medium security issue
> 
> [ Tests ]
> No new test, test passed
> 
> [ Risks ]
> Low risk, patch is trivial
> 
> [ Checklist ]
>   [X] *all* changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in (old)stable
>   [X] the issue is verified as fixed in unstable
> 
> [ Changes ]
> Add checks to avoid prototype pollution
> 
> Cheers,
> Yadd

> diff --git a/debian/changelog b/debian/changelog
> index 51d769b..d16e01b 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +node-xmldom (0.1.27+ds-1+deb10u1) buster; urgency=medium
> +
> +  * Team upload
> +  * Fix prototype pollution (Closes: #1021618, CVE-2022-37616)
> +
> + -- Yadd   Wed, 12 Oct 2022 10:07:56 +0200

The last buster point release has happened. But this update could go
via a DLA. I suggest to contact the LTS team (cc'ing the list).

Regards,
Salvatore



Bug#1021588: Fixed in glib

2022-10-12 Thread Amr Ibrahim
Hello,

A fix in glib for the stable release:

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2941

Best,
Amr



Bug#1000313: Bug#975490: u-boot-sunxi: A64-Olinuxino-eMMC boot stuck at "Starting kernel ..."

2022-10-12 Thread Philip Rinn

On 11.10.22 at 23:25, Philip Rinn wrote:

Wild guess; maybe the flash-kernel boot.scr gets the wrong console
settings (e.g. serial vs. hdmi or whatnot), while u-boot-menu just uses
the default console specified in the .dtb?


That might very well be, but how to debug? (Let's continue that discussion in 
#1000313 [CCed already])


I attached a monitor via hdmi and the screen turns blank about 5 seconds after 
"Starting kernel ..." ... so that doesn't seem to be the problem :-/



Best

Philip



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1020081: aft: FTBFS: make: *** [debian/rules:47: binary-indep] Error 25

2022-10-12 Thread Olivier Gayot
Package: aft
Followup-For: Bug #1020081
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

The last upload of aft changed the format of a doc file from HTML to
RTF. The packaging was not updated accordingly.

This prevents the package from building.

In Ubuntu, the attached patch was applied to achieve the following:

  * Fix name of installed doc file (LP: #1992672)

Thanks for considering the patch.


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-48-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru aft-5.098/debian/docs aft-5.098/debian/docs
--- aft-5.098/debian/docs   2022-08-25 17:21:28.0 +0200
+++ aft-5.098/debian/docs   2022-10-12 17:41:56.0 +0200
@@ -1,5 +1,5 @@
 aft-refman.html 
-aft2rtf-doc.html 
+aft2rtf-doc.rtf 
 aft.gif 
 debian/vim
 debian/jed


Bug#1021663: os-release: unstable and testing cannot be identified because of empty VERSION_ID and same VERSION_CODENAME

2022-10-12 Thread Gioele Barabucci

Package: base-files
Version: 12.3

Dear base-files maintainer,

this is a followup to #1008735 to provide 3rd-party software authors 
with better clarity (and confirmations) about Debian's approach to the 
information shipped in `os-release`.


A quick summary: `os-release(5)` is the only currently supported 
cross-distro API to retrieve operating system identification data.


With this in mind, it seems correct, based on the content of the 
`os-release` file shipped by `base-files`, to state that:


1. Debian has no concept of "release version" (codified in `os-release` 
in `VERSION_ID`) for operating systems built using the software 
published in the suites "unstable" and "testing". These operating system 
instances just exist and have no version.


(For comparison, other rolling distros publish version IDs for 
snapshots. For example openSUSE Tumbleweed uses a date like "20220926", 
Fedora rawhide uses the upcoming version number "38".)


2. Debian does not desire to distinguish between OS installations based 
on unstable and those based on testing using their codename (codified in 
`os-release` in `VERSION_CODENAME`). The same string (the name of the 
upcoming stable version) will be thus be used for both versions and it 
should not be possible for 3rd-party software to distinguish between them.


(For comparison, the Release files in the archive use "Codename: sid" 
for unstable.)


Is this a correct reading?

Aside from the current situation summarized in the above points, could 
you please consider again the idea of having the suite name in 
`VERSION_ID` ("testing", "unstable") and meaningful codenames in 
`VERSION_CODENAME` ("bookworm", "sid"), at least to simplify the work of 
3rd-party software authors?


Regards,

--
Gioele Barabucci



Bug#1021662: libosip2: CVE-2022-41550

2022-10-12 Thread Salvatore Bonaccorso
Source: libosip2
Version: 5.3.0-2
Severity: important
Tags: security upstream
Forwarded: https://savannah.gnu.org/bugs/?63103
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libosip2.

CVE-2022-41550[0]:
| GNU oSIP v5.3.0 was discovered to contain an integer overflow via the
| component osip_body_parse_header.


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-41550
https://www.cve.org/CVERecord?id=CVE-2022-41550
[1] https://savannah.gnu.org/bugs/?63103

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#1016272: transient bug in latex

2022-10-12 Thread Hilmar Preuße

Am 12.10.2022 um 11:22 teilte Cédric Boutillier mit:

Hi,


For the record, please find attached one of the latex files produced
with kramdown which was causing the problematic character, together with
the output of the failing compilation log with latex from
texlive-latex-base/2022.20220722-1, and the succeeding compilation with
texlive-latex-base/2022.20220923-1.
Best wishes,


(/usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def
File: utf8x.def 2022/08/07 UCS: Input encoding UTF-8


Package ucs Info: utf8x disabled, assuming standard utf8 processing
(ucs) load ucs package to force utf8x processing.


Seems "utf8x" is finally dead! Yehh!

As of beginning of August utf8x falls back to standard utf8 inputenc and 
hence we don't run into utf8x bugs.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1021661: RFS: hashcash/1.22-1 [ITA] [RC] -- postage payment scheme for email based on hash calculations

2022-10-12 Thread Stefan Kangas
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "hashcash":

 * Package name : hashcash
   Version  : 1.22-1
   Upstream contact : Adam Back 
 * URL  : http://hashcash.org/
 * License  : public-domain, GPL-2 or LGPL-2.1 or BSD-3-clause
or Cypherpunks-CPL, GPL-2+, GPL-2
 * Vcs  : https://salsa.debian.org/skangas/hashcash
   Section  : mail

The source builds the following binary packages:

  hashcash - postage payment scheme for email based on hash calculations

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

  https://mentors.debian.net/package/hashcash/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hashcash/hashcash_1.22-1.dsc

Changes since the last upload:

 hashcash (1.22-1) unstable; urgency=medium
 .
   * New maintainer. (Closes: #831803)
 Thanks to Hubert Chan for previous work.
   * New upstream release. (Closes: #962820)
   * Actually enable hardened build flags. (Closes: #655864)
   * debian/control:
 - Set debhelper-compat version in Build-Depends.
 - Bump Standards-Version to 4.6.1.
 - Set Rules-Requires-Root: no.
   * debian/rules: Update to modern debhelper. (Closes: #999030, #928962)
   * debian/watch:
 - Update watch file format version to 4.
 - Opportunistically check upstream PGP signatures.
   * Use 3.0 (quilt) source format.
   * debian/copyright: Use standard, machine-readable format.
   * Fix typos in hashcash(1) man page.
   * Don't use bundled getopt.
   * Add doc-base entry.

Regards,
-- 
  Stefan Kangas



Bug#863498: Trash: undo for delete files to trash

2022-10-12 Thread Akbarkhon Variskhanov
Control: forwarded -1 gitlab.xfce.org/xfce/thunar/issues/819
Control: severity -1 wishlist
Control: tags -1 upstream

By the looks of it, this feature will be made available in the
upcoming 4.18 version. Please see the provided upstream link.

Cheers,
Akbar.



Bug#1021660: gcc-12-offload-nvptx: offloading to nvidia via nvptx fails with cuda version 11 (default in sid)

2022-10-12 Thread Giacomo Mulas
Package: gcc-12-offload-nvptx
Version: 12.2.0-5
Severity: grave
Justification: renders package unusable for nvidia

Dear Maintainer,

the nvptx plugin for gcc-12 currently available for sid mandates a 
cuda level sm_30, which is no longer available in cuda 11 (the one
now in sid). This means that even a trivial example code like

#include 
#include 
  int main(int argc, char **argv){
#pragma omp target parallel
 {
   int i, j;
   i = omp_get_thread_num();
   j = omp_get_num_threads();
   printf("Hello world! I am thread %d out of %d\n", i, j);
  }
 }

fails to compile with

capitanata:~/test$ gcc-12 -fopenmp test_openmp_2.c
ptxas fatal   : Value 'sm_30' is not defined for option 'gpu-name'
nvptx-as: ptxas returned 255 exit status
mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-12 returned 1 
exit status
compilation terminated.
lto-wrapper: fatal error: 
/usr/lib/gcc/x86_64-linux-gnu/12//accel/nvptx-none/mkoffload returned 1 exit 
status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

even trying to set a specific target gpu arch does not seem to work, e.g.

gmulas@capitanata:~/test$ gcc-12 -fopenmp -foffload-options="-misa=sm_35" 
test_openmp_2.c
ptxas fatal   : Value 'sm_30' is not defined for option 'gpu-name'
nvptx-as: ptxas returned 255 exit status
mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-12 returned 1 
exit status
compilation terminated.
lto-wrapper: fatal error: 
/usr/lib/gcc/x86_64-linux-gnu/12//accel/nvptx-none/mkoffload returned 1 exit 
status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

On the other hand, gcc-11 appears to have sm_35 as default, meaning it works, 
both with and without the -misa option:

capitanata:~/test$ gcc-11 -fopenmp -foffload="-misa=sm_35" test_openmp_2.c
/usr/bin/ld: /tmp/user/1000/ccY5a4YE.crtoffloadtable.o: warning: relocation 
against `__offload_vars_end' in read-only section `.rodata'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE

capitanata:~/test$ gcc-11 -fopenmp test_openmp_2.c
/usr/bin/ld: /tmp/user/1000/ccHibGBc.crtoffloadtable.o: warning: relocation 
against `__offload_vars_end' in read-only section `.rodata'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE

and the resulting code runs:

capitanata:~/test$ ./a.out 
Hello world! I am thread 4 out of 8
Hello world! I am thread 1 out of 8
Hello world! I am thread 6 out of 8
Hello world! I am thread 7 out of 8
Hello world! I am thread 0 out of 8
Hello world! I am thread 5 out of 8
Hello world! I am thread 2 out of 8
Hello world! I am thread 3 out of 8

Would it be possible to change the default -misa of gcc 12 to sm_35, 
to enable gpu offloading to nvidia to work with gcc-12? And/or, is there
some undocumented, or poorly documented, way to actually specify on the 
command line the requested cuda level architecture so that it works with
cuda 11 libraries?

Thanks in advance

Best regards
Giacomo Mulas


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=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 gcc-12-offload-nvptx depends on:
ii  gcc-12 12.2.0-5
ii  gcc-12-base12.2.0-5
ii  libc6  2.35-3
ii  libc6-dev  2.35-3
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libgomp-plugin-nvptx1  12.2.0-5
ii  libmpc31.2.1-2
ii  libmpfr6   4.1.0-3
ii  libzstd1   1.5.2+dfsg-1
ii  nvptx-tools0.20180301-1
ii  zlib1g 1:1.2.11.dfsg-4.1

gcc-12-offload-nvptx recommends no packages.

gcc-12-offload-nvptx suggests no packages.

-- no debconf information



Bug#1011665: [RFC] Updating crowdsec, adding and updating other packages

2022-10-12 Thread Shengjing Zhu
On Wed, Oct 12, 2022 at 11:05 PM Cyril Brulebois  wrote:
>
> Shengjing Zhu  (2022-10-12):
> > On Wed, Oct 12, 2022 at 9:37 PM Shengjing Zhu  wrote:
> > > Thanks for the detailed plan! All look good to me except this.
>
> Many thanks for the review and the few uploads!
>
> > > I think it can just bump to v13 without introducing new package.
> > > I'll try today and if I fail I will let you know.
>
> Good catch!
>
> I think I should have checked my numbers there, instead of staying with
> the “there are a few tricky reverse dependencies” impression I got from
> before I actually dug into the nomad* and packer packages…
>
> There are indeed golang-github-zclconf-go-cty and packer you uploaded:
>
> > Uploaded golang-github-apparentlymart-go-textseg_13.0.0-1,
> > golang-github-zclconf-go-cty_1.5.1-4, and packer_1.6.6+ds1-5.
>
> but also the non-official reverse-dependencies that vendorize
> hashicorp/hcl/v2 (nomad #1021650 and nomad-driver-podman #1021652),
> which seemed like possibly problematic packages initially.
>

They are already not in testing, so I'm just lazy enough to keep
investigating...

-- 
Shengjing Zhu



Bug#1011665: [RFC] Updating crowdsec, adding and updating other packages

2022-10-12 Thread Cyril Brulebois
Shengjing Zhu  (2022-10-12):
> On Wed, Oct 12, 2022 at 9:37 PM Shengjing Zhu  wrote:
> > Thanks for the detailed plan! All look good to me except this.

Many thanks for the review and the few uploads!

> > I think it can just bump to v13 without introducing new package.
> > I'll try today and if I fail I will let you know.

Good catch!

I think I should have checked my numbers there, instead of staying with
the “there are a few tricky reverse dependencies” impression I got from
before I actually dug into the nomad* and packer packages…

There are indeed golang-github-zclconf-go-cty and packer you uploaded:

> Uploaded golang-github-apparentlymart-go-textseg_13.0.0-1,
> golang-github-zclconf-go-cty_1.5.1-4, and packer_1.6.6+ds1-5.

but also the non-official reverse-dependencies that vendorize
hashicorp/hcl/v2 (nomad #1021650 and nomad-driver-podman #1021652),
which seemed like possibly problematic packages initially.

If all they need is golang-github-apparentlymart-go-textseg-dev added to
(Build-|)Depends, and a version bump (/v12 → /v13) in their codebase,
I'll push a patch in the BTS and in master for those.

Of course, since golang-github-zclconf-go-cty will stay with the
existing golang-github-apparentlymart-go-textseg-dev package, the
fallback of the update should be more limited than I anticipated
initially.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature


Bug#940139: nautilus: open files by double clicking or right click "open"

2022-10-12 Thread Jeremy Bicha
Control: severity -1 normal
Control: tags -1 -moreinfo

Are you still experiencing this issue?

Could you make a new user, log in as the new user and verify whether
the new user is affected by this issue?

Thank you,
Jeremy Bicha



Bug#625758: 'adduser --disabled-login' does not behave as documented.

2022-10-12 Thread Vincent Lefevre
On 2022-03-19 11:44:05 +0100, Marc Haber wrote:
> - change and document (adduser(8)) that --disabled-password will behave
>   like --disabled-login and additionally set the shell to
>   /usr/sbin/nologin.
> - --disabled-login and an explicitly set --shell is an error and will be
>   flagged as such.

Hmm... Don't you mean "--disabled-login will behave like
--disabled-password and additionally set the shell to
/usr/sbin/nologin"?

So, since --disabled-login sets the shell to /usr/sbin/nologin,
it must not be used in combination with --shell.

BTW, the issue about the behavior occurred in this context:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021613#45

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



Bug#1011665: [RFC] Updating crowdsec, adding and updating other packages

2022-10-12 Thread Shengjing Zhu
On Wed, Oct 12, 2022 at 9:37 PM Shengjing Zhu  wrote:
>
> Hi,
>
> On Wed, Oct 12, 2022 at 6:30 PM Cyril Brulebois  wrote:
> > New -vN packages:
> > -
> >
> > - golang-github-apparentlymart-go-textseg-v13
> >+ required by (updated) golang-github-zclconf-go-cty
> >+ upstream documents using the /v13 path in `go get`, go.mod, etc.
> >+ golang-github-apparentlymart-go-textseg-dev has a few reverse
> >  dependencies in main
> >+ a few patches were needed to support Unicode 13 / Go 1.19, so
> >  using a new -v13 package seems safer than trying to switch the
> >  existing versionless package to a new upstream release; some
> >  users of /v12 are actually shipping vendorized hashicorp/hcl,
> >  so I'm not sure we could fix anything even if we wanted to…
> >  (see nomad* and packer further down).
>
> Thanks for the detailed plan! All look good to me except this.
> I think it can just bump to v13 without introducing new package. I'll
> try today and if I fail I will let you know.
>

Uploaded golang-github-apparentlymart-go-textseg_13.0.0-1,
golang-github-zclconf-go-cty_1.5.1-4, and packer_1.6.6+ds1-5.

-- 
Shengjing Zhu



Bug#1021311: vlc: No sound with some AAC encoded MKV videos

2022-10-12 Thread Miguel A. Vallejo
Hello!

I uploaded a small 10 second long video that shows the problem with VLC:

https://www.dropbox.com/s/a5p2850q1npw5c6/testvideo.mkv?dl=1

Video plays fine but no audio with VLC. Other players like mpv or ffplay
play audio nicely.

Thanks in advance.


Bug#1021613: systemd: generates too much log for ssh connection

2022-10-12 Thread Vincent Lefevre
On 2022-10-12 14:43:06 +0200, Michael Biebl wrote:
> Apparently you can still use su, sudo etc with --disabled-login. So I wonder
> if there is a real difference in practice to --disabled-password.

In some way, I would regard the command-via-ssh feature to behave
a bit like sudo: this is not a login, one just wants to run a
command (sudo is used to run it as another user, ssh is used to
run it remotely).

> In any case, apparently a "login" under that user has happened (via SSH I
> assume). Otherwise pam_systemd.so and `systemd --user` wouldn't have been
> triggered.

While I wanted to report a bug against adduser to ask for a
clarification, I saw:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625758
  'adduser --disabled-login' does not behave as documented.

reported 11 years ago and still open!

Last comment a few months ago

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625758#72

with in particular:

- change and document (adduser(8)) that --disabled-password will behave
  like --disabled-login and additionally set the shell to
  /usr/sbin/nologin.
- --disabled-login and an explicitly set --shell is an error and will be
  flagged as such.

Using both --disabled-login and --shell was exactly what I did
(setting a shell was necessary to be able to run the command,
even though how the command is run is not mentioned in the sshd
man page).

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



Bug#1021659: freerdp2: Update to 2.8.1

2022-10-12 Thread Jeremy Bicha
Source: freerdp2
Version: 2.8.0+dfsg1-1

Please update freerdp2 to the new version. Because I needed to work on
the update today for Ubuntu 22.10 deadlines, I am submitting merge
proposals for you.

https://github.com/FreeRDP/FreeRDP/releases/tag/2.8.1
https://github.com/FreeRDP/FreeRDP/compare/2.8.0...2.8.1

The changes say that it fixes 2 CVEs, CVE-2022-39282 and CVE-2022-39283

Thank you,
Jeremy Bicha



Bug#1011665: [RFC] Updating crowdsec, adding and updating other packages

2022-10-12 Thread Shengjing Zhu
Hi,

On Wed, Oct 12, 2022 at 6:30 PM Cyril Brulebois  wrote:
> New -vN packages:
> -
>
> - golang-github-apparentlymart-go-textseg-v13
>+ required by (updated) golang-github-zclconf-go-cty
>+ upstream documents using the /v13 path in `go get`, go.mod, etc.
>+ golang-github-apparentlymart-go-textseg-dev has a few reverse
>  dependencies in main
>+ a few patches were needed to support Unicode 13 / Go 1.19, so
>  using a new -v13 package seems safer than trying to switch the
>  existing versionless package to a new upstream release; some
>  users of /v12 are actually shipping vendorized hashicorp/hcl,
>  so I'm not sure we could fix anything even if we wanted to…
>  (see nomad* and packer further down).

Thanks for the detailed plan! All look good to me except this.
I think it can just bump to v13 without introducing new package. I'll
try today and if I fail I will let you know.

-- 
Shengjing Zhu



Bug#1021658: latexml: AutoPKG test suite fails since latest upload of TLive

2022-10-12 Thread Hilmar Preusse
Package: latexml
Version: 0.8.6-4
Severity: important

Dear Maintainer,

This is just for the records: since the latest upload of
texlive-base/texlive-lang/texlive-extra snapshot the latexml
test suite fails to run. The issue is known in upstream.

Hilmar

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 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 latexml depends on:
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b3
ii  libarchive-zip-perl  1.68-1
ii  libfile-which-perl   1.27-1
pn  libimage-magick-perl 
pn  libimage-size-perl   
ii  libio-string-perl1.08-3.1
pn  libjson-xs-perl  
ii  libparse-recdescent-perl 1.967015+dfsg-3
pn  libpod-parser-perl   
ii  libtext-unidecode-perl   1.30-2
ii  liburi-perl  5.14-1
pn  libuuid-tiny-perl
ii  libwww-perl  6.67-1
ii  libxml-libxml-perl   2.0207+dfsg+really+2.0134-1
ii  libxml-libxslt-perl  2.002000-1
ii  libxml2  2.9.14+dfsg-1+b1
ii  libxslt1.1   1.1.35-1
ii  perl 5.34.0-5
ii  tex-common   6.17
ii  texlive-latex-base   2022.20220923-1

latexml recommends no packages.

latexml suggests no packages.

-- 
sigmentation fault


signature.asc
Description: PGP signature


Bug#1021613: systemd: generates too much log for ssh connection

2022-10-12 Thread Michael Biebl


Am 12.10.22 um 14:22 schrieb Vincent Lefevre:

On 2022-10-12 13:42:55 +0200, Michael Biebl wrote:

Am 12.10.22 um 13:15 schrieb Vincent Lefevre:

On 2022-10-12 11:39:40 +0200, Michael Biebl wrote:

What you see here is expected behaviour:
Your login via SSH is apparently done via PAM, which triggers the start of a
systemd --user instance (with all that it entails). And systemd dutifully
logs everything when setting up that user instance (and tearing it down
again on log out).


Well, the account was created by adduser with the --disabled-login
option. So I wonder why a systemd --user instance is started.


disabled-login means disabled password. You can still log in as that user
via other means (su, sudo, SSH keys).
Which mechanism do you use?


No, you are confusing with --disabled-password:

   --disabled-password
   Like --disabled-login, but logins are still possible (for example
   using SSH keys) but not using password authentication.

I really used --disabled-login. But the man page is really unclear.
The intent was to allow SSH connections, but "full" logins (with
additional services such as provided by systemd) are not necessary.


Apparently you can still use su, sudo etc with --disabled-login. So I 
wonder if there is a real difference in practice to --disabled-password.


In any case, apparently a "login" under that user has happened (via SSH 
I assume). Otherwise pam_systemd.so and `systemd --user` wouldn't have 
been triggered.


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1021613: systemd: generates too much log for ssh connection

2022-10-12 Thread Vincent Lefevre
On 2022-10-12 13:52:26 +0200, Michael Biebl wrote:
> 
> Am 12.10.22 um 13:15 schrieb Vincent Lefevre:
> > On 2022-10-12 11:39:40 +0200, Michael Biebl wrote:
> 
> > > If you don't want to constantly start/stop the user instance, you can also
> > > use linger, so the user instance will stick around if you terminate your 
> > > SSH
> > > session.
> > 
> > However, I suppose that this would take useless resources. IMHO,
> 
> Judging from your log, `systemd --user` basically just set's up listening
> sockets. So all you've got is the `systemd --user` process itself + a couple
> of open file descriptors.
> 
> Is that really any issue?

Probably not a real issue.

However, I think that there should be a way to disable systemd (and
perhaps have more control over PAM), e.g. with an authorized_keys
option as I've just suggested, as this is precisely where one can
require a limited use of ssh.

Perhaps this bug could be reassigned to openssh-server (this package
also provides /etc/pam.d/sshd, so it is also concerned by the PAM
configuration).

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



Bug#1021613: systemd: generates too much log for ssh connection

2022-10-12 Thread Vincent Lefevre
On 2022-10-12 13:42:55 +0200, Michael Biebl wrote:
> Am 12.10.22 um 13:15 schrieb Vincent Lefevre:
> > On 2022-10-12 11:39:40 +0200, Michael Biebl wrote:
> > > What you see here is expected behaviour:
> > > Your login via SSH is apparently done via PAM, which triggers the start 
> > > of a
> > > systemd --user instance (with all that it entails). And systemd dutifully
> > > logs everything when setting up that user instance (and tearing it down
> > > again on log out).
> > 
> > Well, the account was created by adduser with the --disabled-login
> > option. So I wonder why a systemd --user instance is started.
> 
> disabled-login means disabled password. You can still log in as that user
> via other means (su, sudo, SSH keys).
> Which mechanism do you use?

No, you are confusing with --disabled-password:

  --disabled-password
  Like --disabled-login, but logins are still possible (for example
  using SSH keys) but not using password authentication.

I really used --disabled-login. But the man page is really unclear.
The intent was to allow SSH connections, but "full" logins (with
additional services such as provided by systemd) are not necessary.

> I wouldn't recommend disable PAM in SSH (I assume you meant "UsePAM no" in
> sshd_config), but use a different login shell for subversion where PAM is
> not involved or rather, which uses a custom PAM profile where you can
> exclude pam_systemd.so.

Yes, I thought that this was the case for /bin/sh, as opposed to
/bin/bash (default for root, unless this has changed) or /bin/zsh.
But see below.

> I don't really know your particular setup, so it's a bit hard to give proper
> advice.
> But if the user used for subversion access is not meant to be a *regular*
> user but some kind of specialized (system) user, it could indeed be an
> option to disable systemd --user for this particular user.

This is certainly true for the special svn user, who has a
.ssh/authorized_keys file with only

command="/usr/bin/svnserve 
...",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty

lines.

BTW, I think that rather than with the login shell, pam_systemd.so
inclusion should be controled by such an option. Something like
"no-systemd" (or perhaps pam-options="..."). But this is a setting
that would need to be forwarded to PAM, I suppose.

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



Bug#1021496: anacron: cron.daily stopped executing a month ago

2022-10-12 Thread Ralf Jung

Dear Lance,


This is a problem, since obviously many things rely on these cron jobs running 
regularly.
For example, one of my SSL certificates expired because of this.




Kind regards,
Ralf


I have merged this bug with #1019554.

The problem was introduced in -33. I've noticed that it resulted in an 
incomplete cleanup on upgrade. It has been fixed in -35 but the service still 
doesn't start due to the cleanup.


Ah, indeed the service was 'disabled'.



My tested working solution is to backup existing cron files, remove anacron, 
manually remove the files and install the -35 version.

Specifically, I removed:
/var/lib/systemd/deb-systemd-helper-*/ ... anacron files
/var/lib/dpkg/info/anacron.* files
/var/spool/anacron
/etc/anacrontab

Sorry for the inconvenience. Please let me know if this works as it seems to 
fix it on my system.


Uh, that sounds pretty scary. I already have the -35 installed so the buggy 
postrm should be gone. Shouldn't it be enough to manually enable and start the 
service and timer? I have done that now.


FWIW I agree with the sentiment in that bug that anacron should not touch any of 
these systemd files in its postrm or purge logic. That's what the 
init-system-helpers are for. They are very well-tested and if they leave behind 
dangling symlinks that should be brought up with them. Fixing it only for 
anacron wouldn't help other packages.


Kind regards,
Ralf



Bug#1014177: qemu-user-static: QEMU aarch64 user mode emulation always segfaults

2022-10-12 Thread Tony Garnock-Jones

On Tue, 13 Sep 2022 23:42:19 +0300 Michael Tokarev  wrote:

I uploaded new upstream release of qemu a few days ago, 7.1, can you verify
if that one makes any difference?


It looks hopeful at least for my use cases!

# dpkg --add-architecture arm64
# apt update
# apt install hello:arm64
# apt install qemu-user-static binfmt-support
# hello
Hello, world!

# apt install docker.io
# docker run -it --rm --platform=linux/arm64 alpine:edge uname -m
aarch64

# dpkg -l qemu-user-static binfmt-support hello
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----==
ii  binfmt-support   2.2.2-1  amd64Support for extra binary 
formats
ii  hello:arm64  2.10-2   arm64example package based on 
GNU hello
ii  qemu-user-static 1:7.1+dfsg-2 amd64QEMU user mode emulation 
binaries (static version)



Thank you!

Regards,
  Tony



Bug#1021603: libpmix2: mca_base_component_repository_open: unable to open mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or directory (ignored)

2022-10-12 Thread Alastair McKinstry
This appears to be fixed locally for me by rebuilding openmpi against 
the latest pmix.


I'm doing a rebuild now


Alastair


On 11/10/2022 16:50, Andreas Beckmann wrote:

Package: libpmix2
Version: 4.2.1-2
Severity: serious

Hi,

the new pmix version in sid causes autopkgtest regressions, e.g.

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openmpi/26943322/log.gz

autopkgtest [01:13:33]: test check_shared_objs: [---
[ci-284-796c5454:01766] mca_base_component_repository_open: unable to open 
mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or 
directory (ignored)
autopkgtest [01:13:34]: test check_shared_objs: ---]
autopkgtest [01:13:34]: test check_shared_objs:  - - - - - - - - - - results - 
- - - - - - - - -
check_shared_objsFAIL non-zero exit status 1

I see similar errors when rebuilding src:p4est while the tests are
running. This works fine with the version in testing.


Andreas


--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry



  1   2   >