Bug#998087: arm64+virtio: "No device for installation media was detected" error

[Jean-Marc Ranger]

Package: debian-installer
Severity: normal
Tags: d-i
X-Debbugs-Cc: jmran...@hotmail.com

Dear Maintainer,

Environment:
- physical hardware is a Mac with an M1 processor, running MacOS
- VM provided by QEMU-6.1.0 + patches for that processor, hidden in the hombrew 
installer for QEMU
- using qemu-system-aarch64 - so arm64 VM on an arm64 physical CPU
- reproduced with both debian-11.1.0-arm64-netinst.iso and today's 
debian-testing-arm64-netinst.iso
- the ISO is made visible inside QEMU via its "-cdrom" command-line argument, 
which makes it visible under /dev/vda in Debian's installer
- for simplification, no other virtual hard disk exist
- Debian's normal "non-graphical, non-expert" install mode is used

Error:
- At installation step 4 (Detect and mount installation media), the installer 
fails to detect the ISO, and states "No device for installation media was 
detected".

Solution:
- to "Load drivers from removable media?", answer no
- to "Manually select a module and device for installation media, answer yes
- to "Module needed for accessing the installation media", select "none"
- enter "/dev/vda" (or "/dev/vda1") as the device file to use
- installation media is now detected, and installation continues.

Would it make sense to add the various /dev/vd? to the list of locations 
already automatically probed?

Thanks.

Bug#997942: tomboy-ng: FTBFS with fpc 3.2.2

[David Bannon]

On Wed, 2021-10-27 at 14:11 +0200, Graham Inggs wrote:
> Source: tomboy-ng
> Version: 0.32-2
> Severity: serious
> Tags: ftbfs bookworm sid

Thanks Graham. I noticed the same problem myself a few days ago. Its a
very simple fix but as I am very close to releasing a new version
anyway, maybe we can wait until them ?

I am waiting on an upstream fix to kcontrols that appears to have some
issues depending on locale.

Due to Debian dropping libappindicator3 and replacing it with
libayatana (and the name change), the current version of tomboy-ng in
debian is not a good solution anyway.

And the new one is bigger and better !   ;-)

Davo
   
> 
> Hi Maintainer
> 
> tomboy-ng fails to build from source since fpc 3.2.2 was uploaded to
> unstable.  I've copied what I hope is the relevant part of the log
> below.
> 
> Regards
> Graham
> 
> 
> make[1]: Entering directory '/build/1st/tomboy-ng-0.32'
> == We have compiled [tomboy-ng]
> == $BIN_DIR is [/usr/bin]
> bash ./buildit.bash
> /usr/bin/which: this version of `which' is deprecated; use `command
> -v' in scripts instead.
> /usr/bin/which: this version of `which' is deprecated; use `command
> -v' in scripts instead.
> Compiler reported [3.2.2]
> Unclear about your compiler, maybe edit script to support new one,
> exiting ...
> make[1]: *** [Makefile:36: tomboy-ngx86_64] Error 1

Bug#985946: patch proposal

[David Bannon]

Topic : Lazarus on a ppc64el

Hi Paul, Abou. Thats great timing, I deleted my PPC image about a week
ago to save some diskspace. :-)

I was initially approached to help get tomboy-ng built on ppc64el and,
as an old IBM Power user I thought that would be fun. But I quickly
found I would need some debugging and for Lazarus users, that means the
Lazarus IDE, there I struck some problems and it appeared Debian people
also lost interest.

Personally, I would quite like to be involved here (but the usual time
constraints apply, we all know about that ...) 

I am not sure what I told (Abou ?) earlier this year but here is a
summary of my notes going back to then (current comments following the
"Further -" point.

1. The debian package has some problem with the version numbers. It has
been given a version number in ide/version.inc of 2.0.10+dfsg-4, says
"welcome to 2.0.10+dfsg-4+b2" but is nicely tucked away
/usr/lib/lazarus/2.0.10 and the IDE is rightly confused.  And it did
not install libqt5pas-dev.

Further - I notice (only yesterday) that Lazarus on Debian Bullseye
amd64 has a similar problem, the deb install thinks it has one version
number and the Lazarus source code another. As the Lazarus IDE is
routinely rebuilt, that causes problems until the user bites the bullet
and edits the source code. Generally, many Lazarus users prefer
building from SRC. 

2. So, I built from source and the bigide version will not build due to
a strange error in PascalScript, while lots of warnings about pointer
not portable, it appears to fail at the end of the file without a
specific error message. Not seen anything like that.

Further - sadly I don't remember the details here. Pointer not being
portable on x86 is not an issue, "might" be here.

3. Will build without 'bigide'. However, the simplest app crashes at
exit with a floating point error when run with the debugger. Does not
crash outside debugger ?

Further - being unable to work with gdb is a problem. But newer
releases of Lazarus include a built in debugger, may be interesting to
try that ? I generally use Lazarus trunk/main but understand that
Debian frowns on such approaches (for good reason).

4. Qt5 version of Lazarus IDE does not show component and tool bars.

Further - Generally, Lazarus users use the GTK2 version, it will make a
Qt5 a application and life is just a touch simpler using GTK2 Lazarus.
I understand that Debian wants to downplay GTK2 right now but I suspect
getting the whole thing going with GTK2 initially might be easier. 

This is using above command line, appears to give me a POWER8 with VGA.
Cannot find any qemu docs about what machine is what, so, maybe a trial
and error approach with other machines ?  The XFCe terminal does not
seem to get me any copy and paste or screen dump capabilities (within
the machine) so if I am to do any more I think I will have to try a
Mate install.

Further - by "above command line, I meant -

qemu-img create -f qcow2 ppc64le.img 15G

qemu-system-ppc64le  -machine pseries-2.12  -m 2048 -boot d  -net nic
-net user -hda ppc64le.img -cdrom debian-bullseye-DI-alpha3-ppc64el-
netinst.iso

It is quite possible, given my inexperience with qemu and current power
processors that the above is quite, quite wrong !

I am, of course, willing to listen to any suggestion !

Davo
 

On Thu, 2021-10-28 at 14:49 +0200, Paul Gevers wrote:
> Hi David,
> 
> I was just pointed to this bug.
> 
> On Tue, 6 Apr 2021 10:21:43 +1000 David Bannon
>  wrote:
> [...]
> 
> > then I built Lazarus from source (my prefered model) and found more
> > issues that relate, I think, to LCL, particularly under Qt5.  So,
> > in my
> > very uneducated opinion, Lazarus is not yet ready for ppc64el and
> > as its
> > not on the Lazarus's supported list, they won't be very interested
> > in
> > finding out why that is.  They would definitely accept patches but
> > a bug
> > report with no solution will not attract a lot of attention.
> > 
> > I suggest its not really a very good idea to list Lazarus as a
> > supported
> > Debian package on ppc64el. FPC is fine, but not Lazarus. Just my
> > opinion.
> 
> I think Abou (on the list in CC) would love to discuss your
> experience.
> The Debian FreePascal team likes to support Lazarus (and FPC) on all
> Debian supported architectures where feasible, but we need to be made
> aware of issues before we can fix them.
> 
> Paul
> 

Bug#998084: python3-numpy adds unnecessary link `/usr/include/python3.9/numpy`

[Sandro Tosi]

control: tags -1 +moreinfo

On Fri, Oct 29, 2021 at 6:27 PM Sebastian Berg
 wrote:
> Environments that use a version different from the system one
> (e.g. for development purposes, or pip installed versions) seem
> to pick up the included link in:
>
> /usr/include/python3.9
>
> Rather than the correct headers as reported by NumPy (using 
> `np.get_include()`).
> Removing the link fixes these compiles.

i'm not sure supporting a mixed environment of debian packages and pip
installed modules is the debian maintainer's responsibility: once
users install software outside of Debian, they usually are on their
own.

> The link seems like it should be unnecessary, although, I suppose it may work
> around incorrectly set-up packages, so maybe there is a reason for having it?

I did some digging, and this seems to be rooted in 10+ changes, but
i'm not willing to remove that symlink since in a pure debian setup it
does no harm and likely it's the way custom/old/outdated extensions
find the numpy headers.

If you feel strongly this symlink needs to be removed, please conduct
a thorough analysis of the impact that such removal would cause and
report back on this report, else i'm inclined to just close it out.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#992313: hexedit: please add non-superficial autopkgtest

[Eriberto Mota]

Control: tags 992313 moreinfo

Em ter., 17 de ago. de 2021 às 01:33, Paul Wise  escreveu:
>
> Source: hexedit
> Severity: wishlist
>
> Please add this autopkgtest that tests editing both non-empty and empty
> files by passing keys via terminal escape sequences and bytes. You will
> need to test-depend on colorized-logs for pipetty and ansi2txt. It
> should be possible to add more scenarios by typing keys into hexdump
> and converting those to the corresponding printf sequences.
>
>#!/bin/sh
>set -e
>rm -f nonempty empty result
>echo nonempty > nonempty
>touch empty
>echo result > result
>for f in nonempty empty ; do
>  echo "Editing $f in hexedit"
>  printf "$f"'\n\tresult\x18y' |
>  pipetty hexedit 2>&1 |
>  ansi2txt |
>  tr '\r' '\n'
>done
>head -vn-0 nonempty empty result
>for f in nonempty empty ; do
>  cmp "$f" result
>done

Hi Paul,

Thanks for your help. Unfortunately, your script ends with 'pipetty:
can't allocate a pseudo-terminal: No such file or directory'.

If possible, to create an empty file in Bash, use '> file' instead of
'touch file'.

Regards,

Eriberto

Bug#799354: gnome-shell segfault libgjs

[Calum McConnell]

Package: gnome-shell
Version: 3.38.6-1~deb11u1
Followup-For: Bug #799354
X-Debbugs-Cc: calumlikesapple...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I can confirm that this still exists in the current version.  

Error messages:
Oct 29 21:56:17 CalumsBeastlyLaptop kernel: show_signal_msg: 81 callbacks 
suppressed
Oct 29 21:56:17 CalumsBeastlyLaptop kernel: gnome-shell[5343]: segfault at 31 
ip 7f26690661c0 sp 7ffdeeeda358 error 4 in libgjs.so.0.0.0[7f26>
Oct 29 21:56:17 CalumsBeastlyLaptop kernel: Code: c0 74 07 48 8b 40 18 c3 66 90 
53 48 89 fb 48 8b 7f 28 e8 e3 06 00 00 48 8b 43 28 5b c3 66 66 2e 0f >

While I don't recall the exact details of what caused this, I can provide more 
of the log if desired

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  evolution-data-server3.38.3-1
ii  gir1.2-accountsservice-1.0   0.6.55-3
ii  gir1.2-atspi-2.0 2.38.0-4
ii  gir1.2-freedesktop   1.66.1-1+b1
ii  gir1.2-gcr-3 3.38.1-2
ii  gir1.2-gdesktopenums-3.0 3.38.0-2
ii  gir1.2-gdm-1.0   3.38.2.1-1
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gnomebluetooth-1.03.34.3-2
ii  gir1.2-gnomedesktop-3.0  3.38.5-3
ii  gir1.2-gstreamer-1.0 1.18.4-2.1
ii  gir1.2-gtk-3.0   3.24.24-4
ii  gir1.2-gweather-3.0  3.36.1-3
ii  gir1.2-ibus-1.0  1.5.23-2
ii  gir1.2-mutter-7  3.38.6-2~deb11u1
ii  gir1.2-nm-1.01.30.0-2
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-polkit-1.00.105-31
ii  gir1.2-rsvg-2.0  2.50.3+dfsg-1
ii  gir1.2-soup-2.4  2.72.0-2
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.66.2-1
ii  gnome-backgrounds3.38.0-1
ii  gnome-settings-daemon3.38.2-1
ii  gnome-shell-common   3.38.6-1~deb11u1
ii  gsettings-desktop-schemas3.38.0-2
ii  gstreamer1.0-pipewire0.3.19-4
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo21.16.0-5
ii  libecal-2.0-13.38.3-1
ii  libedataserver-1.2-253.38.3-1
ii  libgcr-base-3-1  3.38.1-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgirepository-1.0-11.66.1-1+b1
ii  libgjs0g 1.66.2-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.8-1
ii  libglib2.0-bin   2.66.8-1
ii  libgnome-autoar-0-0  0.2.4-3
ii  libgnome-desktop-3-193.38.5-3
ii  libgraphene-1.0-01.10.4+dfsg1-1
ii  libgtk-3-0   3.24.24-4
ii  libical3 3.0.9-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libmutter-7-03.38.6-2~deb11u1
ii  libnm0   1.30.0-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpolkit-agent-1-0  0.105-31
ii  libpolkit-gobject-1-00.105-31
ii  libpulse-mainloop-glib0  14.2-2
ii  libpulse014.2-2
ii  libsecret-1-00.20.4-2
ii  libsystemd0  247.3-6
ii  libwayland-server0   1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxfixes3   

Bug#998079: mrtg: [INTL:pt] Updated Portuguese translation - debconf messages

[Eriberto Mota]

Em sex., 29 de out. de 2021 às 17:39, Américo Monteiro
 escreveu:
>
> Package: mrtg
> Version: 2.17.8+git20211022.f52e91e-1
> Tags: l10n, patch
>
> Severity: wishlist
>
>
> Updated Portuguese translation for mrtg's debconf messages
>
> Translator: Américo Monteiro 
>
> Feel free to use it.

Hi Américo,

Thanks for your work. I already sent the pt.po to Salsa[1].

[1] 
https://salsa.debian.org/debian/mrtg/-/commit/3bd05b3d77c103414aa783e02c7b52a2432b9c61

Regards,

Eriberto

Bug#998086: update d/control for console-setup

[Osamu Aoki]

Package: kbd
Version: 2.3.0-3
Severity: normal
Tags: patch

As reported to merge request 4
  https://salsa.debian.org/debian/kbd/-/merge_requests/4

Previous description caused impression that the installation of
console-data is desirable thing to do.  This updates removes
such impression and guides people to use console-setup without
worry.

Background:

Thisroposal comes from discussion:
  https://lists.debian.org/debian-doc/2021/10/msg00017.html

We now recommend console-setup as the primary recommendation now
in the package dependency.

Since around 2010, the use of console-setup has declined and the new
installation seems to install console-setup as the default.

  * https://qa.debian.org/popcon.php?package=console-setup
  * https://qa.debian.org/popcon.php?package=console-data

FYI: I still see a merge request is still open
  https://salsa.debian.org/debian/kbd/-/merge_requests/3

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

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

Versions of packages kbd depends on:
ii  libc6  2.32-4

Versions of packages kbd recommends:
ii  console-setup  1.205

kbd suggests no packages.

-- no debconf information

Bug#998045: Missing RuntimeDirectory in my workaround

[Jaime Hablutzel]

My previous systemd drop-in workaround was incomplete. This is the complete
version of
/etc/systemd/system/nagios4.service.d/10-fix-for-incorrect-pid-management.conf:

[Service]
ExecStartPost=/bin/sh -c 'umask 022; pgrep nagios4 >
/var/run/nagios4/nagios4.pid'
RuntimeDirectory=nagios4
PIDFile=/run/nagios4/nagios4.pid

Where RuntimeDirectory=nagios4 is required for /var/run/nagios4 to be
automatically created.

-- 
Jaime Hablutzel -  +51 994690880

Bug#997818: [Pkg-utopia-maintainers] Bug#997818: wireplumber: Failed to preset unit, file /etc/systemd/user/pipewire-session-manager.service already exists

[Michael Biebl]

Am 30.10.2021 um 01:21 schrieb Laurent Bigonville:
That also looks RC to me, leaving a dangling symlink is never good, not 
too sure how to fix this.


This preserves the enablement state of the service, similar to how 
conffiles are removed on "apt remove".
Only if you purge a package, its conffiles are removed (and its systemd 
enablement state)


Are you saying this is not the correct way?

Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator

[wferi]

Seunghun Han  writes:

>>>   swtpm - Libtpms-based TPM emulator
>>>   swtpm-dev - Include files for the TPM emulator's CUSE interface
>>>   swtpm-libs - Common libraries for TPM emulators
>>
>> Why do you deviate from the usual libswtpm-dev/libswtpm0 package names?
>> Including the SO version in the package name enables installing
>> incompatible versions side-by-side, which is useful.
>>
>> Also, shipping static libraries (like libswtpm_libtpms.a) is generally
>> recommended against in Debian.  Does this package warrant it?
>
> The upstream version already has some debian-related files, and I
> changed them to adopt the package. The author of it wants to name it
> like libswtpm0, so I used the name. The static libraries are also
> involved in upstream debian files. Should I change the name like
> libswtpm instead of libswtpm0 and remove static libraries from the
> package?

I questioned the package name, not the names of the shared object
within.  After a closer look, though, libswtpm_libtpms.so.0.0.0 looks
more like an internal convenience library than something which other
projects call into.  If this is so, the package name loses its
relevance, I wonder why it's packaged separately, even.  Or why it isn't
compiled straight into the single binary (swtpm) linked against it.

>>>   swtpm-tools - Tools for the TPM emulator
>>
>> Why do you put swtpm-create-tpmca, swtpm-create-user-config-files and
>> swtpm-localca into /usr/share/swtpm instead of /usr/bin?  (This emits
>> several Lintian information tags.)
>
> The author of the upstream project wanted to put them to
> /usr/share/swtpm. The files are just for the initialization and don't
> be used for TPM operations directly, so maybe he wanted to put
> /usr/share/swtpm instead of /usr/bin. Should I move them to /usr/bin?

That they have man pages suggests that they are meant for human use.
That their man pages are in section 8 suggests that they should live in
/usr/sbin.  But this is unreliable, since even the *.conf man pages are
in section 8, while those belong to section 5.  This actually depends on
whether the executables are generally used by the system administrator
or nonprivileged users (or only internally, in which case the scripts
would indeed belong into /usr/share/swtpm).  I started to suspect that
the current decision wasn't based on the expected usage pattern, but
rather on the implementation method (interpreted script or compiled
binary), which isn't very useful.  But I know too little about the swtpm
ecosystem to be sure about the best filesystem layout for the future.
-- 
Regards,
Feri

Bug#997818: wireplumber: Failed to preset unit, file /etc/systemd/user/pipewire-session-manager.service already exists

[Laurent Bigonville]

On Mon, 25 Oct 2021 15:44:31 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= 
 wrote:

> Hi Chris,
>
> Thanks for your report!
>
> Le lun. 25 oct. 2021 à 12:30, Chris Halls  a écrit :
> >
> > Setting up wireplumber (0.4.4-1) ...
> > Failed to preset unit, file 
/etc/systemd/user/pipewire-session-manager.service already exists and is 
a symlink to /lib/systemd/user/pipewire-media-session.service.
> > Created symlink 
/etc/systemd/user/pipewire.service.wants/wireplumber.service → 
/usr/lib/systemd/user/wireplumber.service.
> > /usr/bin/deb-systemd-helper: error: systemctl preset failed on 
wireplumber.service: No such file or directory

> >
>
> That was introduced by this commit:
> > 
https://gitlab.freedesktop.org/pipewire/wireplumber/-/commit/1b48e068cee

>

That looks like a debian bug, not an upstream one, 
pipewire-media-session package should cleaned up that symlink on purge, 
but here, the package is "just" removed.


That also looks RC to me, leaving a dangling symlink is never good, not 
too sure how to fix this.

Bug#998085: ITP: python-rdata -- parses R dataset (.rda) files

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: python-rdata -- parses R dataset (.rda) files
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-rdata
  Version : 0.5
  Upstream Author : Carlos Ramos Carreño 
* URL : https://github.com/vnmabus/rdata
* License : Expat
  Programming Lang: Python
  Description : parses R dataset (.rda) files
 The common way of reading an R dataset consists on two steps:
 . 
  * First, the file is parsed using the function parse_file. This provides
a literal description of the file contents as a hierarchy of Python
objects representing the basic R objects. This step is unambiguous
and always the same.
  * Then, each object must be converted to an appropriate Python
object. In this step there are several choices on which Python type
is the most appropriate as the conversion for a given R object. Thus,
we provide a default convert routine, which tries to select Python
objects that preserve most information of the original R object. For
custom R classes, it is also possible to specify conversion routines
to Python objects.
 .
 The basic convert routine only constructs a SimpleConverter objects and
 calls its convert method. All arguments of convert are directly passed
 to the SimpleConverter initialization method.
 .
 It is possible, although not trivial, to make a custom Converter object
 to change the way in which the basic R objects are transformed to
 Python objects. However, a more common situation is that one does not
 want to change how basic R objects are converted, but instead wants
 to provide conversions for specific R classes. This can be done by
 passing a dictionary to the SimpleConverter initialization method,
 containing as keys the names of R classes and as values, callables
 that convert a R object of that class to a Python object. By default,
 the dictionary used is DEFAULT_CLASS_MAP, which can convert commonly
 used R classes such as data.frame and factor.

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-rdata

Bug#996204: transition: numerical library stack

[Drew Parsons]

On 2021-10-22 14:35, Sebastian Ramacher wrote:

On 2021-10-12 13:09:02, Drew Parsons wrote:

...

I'd like to proceed with a transition of the numerical library stack.

...

(along with other fenics components). There is currently some problem
with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386, armel, armhf.


I've got dolfinx passing (or skipping) its own tests on 32-bit.

There's a problem with 32-bit MPI though. i386 and armhf are failing to 
run pytest over python unit tests in MPI 
(fenics-dolfinx/debian/tests/test-dolfinx-python-unittests).  The error 
is reproducible from the command line on an i386 porterbox,

  $ cd fenics-dolfinx-0.3.0/python/test/unit
  $ mpirun -n 2 pytest-3 -v
  ...
  rootdir: /home/dparsons/fenics/fenics-dolfinx-0.3.0/python, 
configfile: setup.cfg

  plugins: mpi-0+unknown
  collecting 0 items / 1 error
  
--
  "MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD with 
errorcode 59."


I haven't been able to coax any more detail out of it than that.

Might be something more insidious going on with 32-bit python and MPI.  
mpi4py is also failing i386 tests, see

https://ci.debian.net/packages/m/mpi4py/testing/i386/
https://github.com/mpi4py/mpi4py/issues/105

On the other hand fenics-dolfinx demo_elasticity.py is passing fine in 
MPI (though I did have to disable the helmholtz, condensation and 
poisson demos).


pytest-mpi is passing its tests on i386 and armhf.

What's best for us?  Just skip the fenics-dolfinx python units tests in 
MPI on 32-bit machines?
Or configure the migration tool to ignore these i386/armhf test 
failures, so that we can keep monitoring the tests in debci?


Drew

Bug#983770: Acknowledgement (rnp: FTBFS on 32-bit platforms (test suite failures))

[Daniel Kahn Gillmor]

Version: 0.15.2-4

rnp upstream version 0.15 fixed the timestamp issues that were causing
https://bugs.debian.org/983770 on 32-bit architectures.

0.15.2-4 is the latest version of rnp in debian; if the builds are
successful, it should not be prohibited from migration to testing.

--dkg


signature.asc
Description: PGP signature

Bug#996724: ruby3.0: FTBFS on ppc64el: Segmentation fault

[Lucas Nussbaum]

Hi,

ruby 3.0 3.0.2-4:
- builds fine in Debian stable
- fails in unstable
- builds fine in unstable snapshotted on 20210930T210616Z
- fails in unstable snapshotted on 20211014T215029Z

The differences in terms of packages between the two last builds are:

14c14
< ii  bash 5.1-3+b1   ppc64el   
   GNU Bourne Again SHell
---
> ii  bash 5.1-3+b2   ppc64el   
>GNU Bourne Again SHell
18c18
< ii  bison2:3.8.1+dfsg-1 ppc64el   
   YACC-compatible parser generator
---
> ii  bison2:3.8.2+dfsg-1 ppc64el   
>YACC-compatible parser generator
23c23
< ii  ca-certificates  20210119   all   
   Common CA certificates
---
> ii  ca-certificates  20211004   all   
>Common CA certificates
25c25
< ii  cpp  4:10.2.1-1 ppc64el   
   GNU C preprocessor (cpp)
---
> ii  cpp  4:11.2.0-2 ppc64el   
>GNU C preprocessor (cpp)
26a27
> ii  cpp-11   11.2.0-9   ppc64el   
>GNU C preprocessor
43c44
< ii  g++  4:10.2.1-1 ppc64el   
   GNU C++ compiler
---
> ii  g++  4:11.2.0-2 ppc64el   
>GNU C++ compiler
45c46,47
< ii  gcc  4:10.2.1-1 ppc64el   
   GNU C compiler
---
> ii  g++-11   11.2.0-9   ppc64el   
>GNU C++ compiler
> ii  gcc  4:11.2.0-2 ppc64el   
>GNU C compiler
48c50,51
< ii  gcc-11-base:ppc64el  11.2.0-8   ppc64el   
   GCC, the GNU Compiler Collection (base package)
---
> ii  gcc-11   11.2.0-9   ppc64el   
>GNU C compiler
> ii  gcc-11-base:ppc64el  11.2.0-9   ppc64el   
>GCC, the GNU Compiler Collection (base package)
63,64c66,67
< ii  libasan6:ppc64el 11.2.0-8   ppc64el   
   AddressSanitizer -- a fast memory error detector
< ii  libatomic1:ppc64el   11.2.0-8   ppc64el   
   support library providing __atomic built-in functions
---
> ii  libasan6:ppc64el 11.2.0-9   ppc64el   
>AddressSanitizer -- a fast memory error detector
> ii  libatomic1:ppc64el   11.2.0-9   ppc64el   
>support library providing __atomic built-in functions
66,67c69,70
< ii  libaudit-common  1:3.0.5-1  all   
   Dynamic library for security auditing - common files
< ii  libaudit1:ppc64el1:3.0.5-1  ppc64el   
   Dynamic library for security auditing
---
> ii  libaudit-common  1:3.0.6-1  all   
>Dynamic library for security auditing - common files
> ii  libaudit1:ppc64el1:3.0.6-1  ppc64el   
>Dynamic library for security auditing
80c83
< ii  libcc1-0:ppc64el 11.2.0-8   ppc64el   
   GCC cc1 plugin for GDB
---
> ii  libcc1-0:ppc64el 11.2.0-9   ppc64el   
>GCC cc1 plugin for GDB
97c100
< ii  libffi-dev:ppc64el   3.4.2-2ppc64el   
   Foreign Function Interface library (development files)
---
> ii  libffi-dev:ppc64el   3.4.2-3ppc64el   
>Foreign Function Interface library (development files)
99c102
< ii  libffi8:ppc64el  3.4.2-2ppc64el   
   Foreign Function Interface library runtime
---
> ii  libffi8:ppc64el  3.4.2-3ppc64el   
>Foreign Function Interface library runtime
102c105,106
< ii  libgcc-s1:ppc64el11.2.0-8   ppc64el   
   GCC support library
---
> ii  libgcc-11-dev:ppc64el11.2.0-9   ppc64el   
>GCC support library (development files)
> ii  libgcc-s1:ppc64el11.2.0-9   ppc64el   
>GCC support library
112c116
< ii  libgomp1:ppc64el 11.2.0-8   ppc64el   
   GCC OpenMP (GOMP) support library
---
> ii  libgomp1:ppc64el 11.2.0-9   ppc64el   
>GCC OpenMP (GOMP) support library
119,120c123,124
< ii  libisl23:ppc64el 0.23-1 ppc64el   
   manipulating sets and relations of integer points bounded by linear 
constraints
< ii  libitm1:ppc64el  11.2.0-8   ppc64el   
   GNU Transactional Memory Library
---
> ii  

Bug#998084: python3-numpy adds unnecessary link `/usr/include/python3.9/numpy`

[Sebastian Berg]

Package: python3-numpy
Version: 1:1.19.5-1
Severity: normal
X-Debbugs-Cc: sebastian-debian-b...@sipsolutions.net

Dear Maintainer,

Environments that use a version different from the system one
(e.g. for development purposes, or pip installed versions) seem
to pick up the included link in:

/usr/include/python3.9

Rather than the correct headers as reported by NumPy (using `np.get_include()`).
Removing the link fixes these compiles.

The link seems like it should be unnecessary, although, I suppose it may work
around incorrectly set-up packages, so maybe there is a reason for having it?

Cheers,

Sebastian


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

Kernel: Linux 5.14.0-2-amd64 (SMP w/12 CPU threads)
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

Versions of packages python3-numpy depends on:
ii  libblas3 [libblas.so.3]3.10.0-1
ii  libc6  2.32-4
ii  liblapack3 [liblapack.so.3]3.10.0-1
ii  libopenblas0-pthread [liblapack.so.3]  0.3.18+ds-1
ii  python33.9.2-3
ii  python3-pkg-resources  58.2.0-1
ii  python3.9  3.9.7-4

python3-numpy recommends no packages.

Versions of packages python3-numpy suggests:
ii  gcc4:10.2.1-1
ii  gfortran   4:10.2.1-1
pn  python-numpy-doc   
ii  python3-dev3.9.2-3
pn  python3-numpy-dbg  
ii  python3-pytest 6.2.5-1

-- no debconf information

Bug#993876: Crash after recent glibc update

[Vincent Danjean]

Package: aide
Version: 0.17.3-4+b2
Followup-For: Bug #993876

  I also observe the problem on a stable (bullseye) machine.
Aide cannot be used at all (is the 'important' severity enough?)

Here is the backtrace I got (after installing aide-dbgsym):
# gdb --args /usr/bin/aide -c /etc/aide/aide.conf --init
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/aide...
Reading symbols from 
/usr/lib/debug/.build-id/ea/8fe32c919bb19a555ef52a2da196698550752c.debug...
(gdb) r
Starting program: /usr/bin/aide -c /etc/aide/aide.conf --init
[Detaching after fork from child process 25736]
[Detaching after fork from child process 25769]
[Detaching after fork from child process 25796]
[Detaching after fork from child process 25798]
[Detaching after fork from child process 25800]
[Detaching after fork from child process 25803]
[Detaching after fork from child process 25804]
[Detaching after fork from child process 25805]
[Detaching after fork from child process 25806]
[Detaching after fork from child process 25807]
[Detaching after fork from child process 25808]
[Detaching after fork from child process 29842]
[Detaching after fork from child process 29843]
[Detaching after fork from child process 29844]
[Detaching after fork from child process 29845]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x77a77350 in _nss_systemd_is_blocked () from 
/usr/lib/x86_64-linux-gnu/libnss_systemd.so.2
(gdb) bt
#0  0x77a77350 in _nss_systemd_is_blocked () from 
/usr/lib/x86_64-linux-gnu/libnss_systemd.so.2
#1  0x77a78507 in _nss_systemd_getpwuid_r () from 
/usr/lib/x86_64-linux-gnu/libnss_systemd.so.2
#2  0x004f28a3 in getpwuid_r ()
#3  0x004f2253 in getpwuid ()
#4  0x00479aed in __acl_to_any_text ()
#5  0x00415361 in acl2line (line=line@entry=0x1c52b20) at 
../src/do_md.c:465
#6  0x00416ff6 in get_file_attrs (filename=filename@entry=0x1c52e20 
"/media/bernard", attr=273806774206, fs=fs@entry=0x7fffe320, 
dry_run=dry_run@entry=false)
at ../src/gen_list.c:608
#7  0x004113ed in db_readline_disk (dry_run=dry_run@entry=false) at 
../src/db_disk.c:239
#8  0x004172b5 in populate_tree (tree=0x6018e0, 
dry_run=dry_run@entry=false) at ../src/gen_list.c:694
#9  0x0040282f in main (argc=4, argv=0x7fffe5f8) at 
../src/aide.c:663


  Regards
Vincent



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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

aide depends on no packages.

Versions of packages aide recommends:
ii  aide-common  0.17.3-4

Versions of packages aide suggests:
pn  figlet  

-- no debconf information

Bug#998083: e2fsprogs: e4defrag hangs up the computer

[Сергей Фёдоров]

Package: e2fsprogs
Version: 1.46.4-1
Severity: normal
X-Debbugs-Cc: serfyo...@yandex.ru

Dear Maintainer,

It was necessary to defragment a 2 Tb disk with 15,592,612 files.

With a 32 Gb swap file, the computer froze somewhere at 9,000,000.
With a 64 Gb swap file, the computer froze somewhere at 14,500,000.
With a 94 Gb swap file, it finally ended normally without
the computer freezing.

It would like e4defrag to send a message about this when there is a lack
of memory, give advice on how to overcome this problem, and not hang up
the computer.


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

Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 e2fsprogs depends on:
ii  libblkid12.37.2-4
ii  libc62.32-4
ii  libcom-err2  1.46.4-1
ii  libext2fs2   1.46.4-1
ii  libss2   1.46.4-1
ii  libuuid1 2.37.2-4
ii  logsave  1.46.4-1

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
ii  gpart  1:0.3-9
ii  parted 3.4-1

-- no debconf information
   

Bug#998082: ITP: kconfiglib -- Flexible Python 2/3 Kconfig implementation and library

[Bastian Germann]

Package: wnpp
Severity: wishlist
Owner: Bastian Germann 

* Package name: kconfiglib
  Version : 14.1.0
  Upstream Author : Ulf "Ulfalizer" Magnusson 
* URL : https://github.com/ulfalizer/Kconfiglib
* License : ISC
  Programming Lang: Python
  Description : Flexible Python 2/3 Kconfig implementation and library

Kconfiglib is a Kconfig implementation in Python 2/3. It started out as a helper
library, but now has a enough functionality to also work well as a standalone
Kconfig implementation (including terminal and GUI menuconfig interfaces and
Kconfig extensions).

I need this as a dependency of kas and will be maintaining it under the Python
Team's umbrella.

Bug#996987: closed by Debian FTP Masters (reply to Drew Parsons ) (Bug#996987: fixed in fenics-dolfinx 1:0.3.0-6)

[Drew Parsons]

On 2021-10-29 23:03, Sebastian Ramacher wrote:

On 2021-10-29 23:59:46 +0300, Adrian Bunk wrote:

On Fri, Oct 29, 2021 at 10:54:21PM +0200, Sebastian Ramacher wrote:

...

>
> Thanks for the heads up. I've added removal hints for basix, ffcx,
> dolfinx, fenics, and fenicsx-performance-tests.
>...

src:fenicsx-performance-tests has not been renamed, and built fine in
the transition.

src:fenics is not part of this transition, I do not know anything
regarding how it is related to all this.


They are reverse dependencies of dolfinx, so their removal is temporary
until the new source packages migrate.



Thanks for clarifying. I was getting worried. I don't want 
fenicsx-performance-tests to have to be redone in the NEW queue.


Is dolfin+mshr clear to proceed with migration to testing?  mshr is not 
supposed to be directly affected by this transition, but for some reason 
which I don't completely understand it needed to be rebuilt anyway (it's 
running fine in unstable now).


Drew

Bug#996987: closed by Debian FTP Masters (reply to Drew Parsons ) (Bug#996987: fixed in fenics-dolfinx 1:0.3.0-6)

[Sebastian Ramacher]

On 2021-10-29 23:59:46 +0300, Adrian Bunk wrote:
> On Fri, Oct 29, 2021 at 10:54:21PM +0200, Sebastian Ramacher wrote:
> > On 2021-10-29 22:47:33 +0300, Adrian Bunk wrote:
> > > Control: reopen -1
> > > 
> > > On Sat, Oct 23, 2021 at 12:06:03AM +, Debian Bug Tracking System 
> > > wrote:
> > > > This is an automatic notification regarding your Bug report
> > > > which was filed against the src:dolfinx package:
> > > > 
> > > > #996987: dolfinx: FTBFS: unsatisfiable Build-Depends
> > > >...
> > > >  fenics-dolfinx (1:0.3.0-6) unstable; urgency=medium
> > > >  .
> > > >* release dolfinx 0.3 to unstable. Closes: #996987.
> > > >...
> > > 
> > > src:dolfinx is still unfixed, and as I understand it it will never get 
> > > fixed since it was replaced with src:fenics-dolfinx.
> > > 
> > > basix/ffcx/dolfinx might all need removal hints and hints to ignore 
> > > their test failures for this transition, since they've all been replaced
> > > with fenics-* source packages.
> > 
> > Thanks for the heads up. I've added removal hints for basix, ffcx,
> > dolfinx, fenics, and fenicsx-performance-tests.
> >...
> 
> src:fenicsx-performance-tests has not been renamed, and built fine in 
> the transition.
> 
> src:fenics is not part of this transition, I do not know anything 
> regarding how it is related to all this.

They are reverse dependencies of dolfinx, so their removal is temporary
until the new source packages migrate.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996987: closed by Debian FTP Masters (reply to Drew Parsons ) (Bug#996987: fixed in fenics-dolfinx 1:0.3.0-6)

[Adrian Bunk]

On Fri, Oct 29, 2021 at 10:54:21PM +0200, Sebastian Ramacher wrote:
> On 2021-10-29 22:47:33 +0300, Adrian Bunk wrote:
> > Control: reopen -1
> > 
> > On Sat, Oct 23, 2021 at 12:06:03AM +, Debian Bug Tracking System wrote:
> > > This is an automatic notification regarding your Bug report
> > > which was filed against the src:dolfinx package:
> > > 
> > > #996987: dolfinx: FTBFS: unsatisfiable Build-Depends
> > >...
> > >  fenics-dolfinx (1:0.3.0-6) unstable; urgency=medium
> > >  .
> > >* release dolfinx 0.3 to unstable. Closes: #996987.
> > >...
> > 
> > src:dolfinx is still unfixed, and as I understand it it will never get 
> > fixed since it was replaced with src:fenics-dolfinx.
> > 
> > basix/ffcx/dolfinx might all need removal hints and hints to ignore 
> > their test failures for this transition, since they've all been replaced
> > with fenics-* source packages.
> 
> Thanks for the heads up. I've added removal hints for basix, ffcx,
> dolfinx, fenics, and fenicsx-performance-tests.
>...

src:fenicsx-performance-tests has not been renamed, and built fine in 
the transition.

src:fenics is not part of this transition, I do not know anything 
regarding how it is related to all this.

cu
Adrian

Bug#996987: closed by Debian FTP Masters (reply to Drew Parsons ) (Bug#996987: fixed in fenics-dolfinx 1:0.3.0-6)

[Sebastian Ramacher]

On 2021-10-29 22:47:33 +0300, Adrian Bunk wrote:
> Control: reopen -1
> 
> On Sat, Oct 23, 2021 at 12:06:03AM +, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the src:dolfinx package:
> > 
> > #996987: dolfinx: FTBFS: unsatisfiable Build-Depends
> >...
> >  fenics-dolfinx (1:0.3.0-6) unstable; urgency=medium
> >  .
> >* release dolfinx 0.3 to unstable. Closes: #996987.
> >...
> 
> src:dolfinx is still unfixed, and as I understand it it will never get 
> fixed since it was replaced with src:fenics-dolfinx.
> 
> basix/ffcx/dolfinx might all need removal hints and hints to ignore 
> their test failures for this transition, since they've all been replaced
> with fenics-* source packages.

Thanks for the heads up. I've added removal hints for basix, ffcx,
dolfinx, fenics, and fenicsx-performance-tests. Drew, please file
removal bugs to get those that got replaced from unstable as well.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#998081: gnome-software: crashes when clicking on a category on 32bit systems

[Silejonu]

Package: gnome-software
Version: 3.38.1-1
Severity: important
X-Debbugs-Cc: erwan.am...@gmail.com

Dear Maintainer,


Clicking on any category in GNOME Software will result in the program crashing 
immediatly.


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-9-686 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 gnome-software depends on:
ii  appstream0.14.4-1
ii  apt-config-icons 0.14.4-1
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gnome-software-common3.38.1-1
ii  gsettings-desktop-schemas3.38.0-2
ii  libappstream-glib8   0.7.18-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo21.16.0-5
ii  libfwupd21.5.7-4
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgspell-1-21.8.4-1
ii  libgtk-3-0   3.24.24-4
ii  libgtk3-perl 0.038-1
ii  libgudev-1.0-0   234-1
ii  libjson-glib-1.0-0   1.6.2-1
ii  libmalcontent-0-00.10.0-2
ii  libpackagekit-glib2-18   1.2.2-2
ii  libpolkit-gobject-1-00.105-31
ii  libsoup2.4-1 2.72.0-2
ii  libxmlb1 0.1.15-2
ii  packagekit   1.2.2-2
ii  software-properties-gtk  0.96.20.2-2.1

Versions of packages gnome-software recommends:
ii  fwupd  1.5.7-4

Versions of packages gnome-software suggests:
ii  apt-config-icons-hidpi 0.14.4-1
ii  gnome-software-plugin-flatpak  3.38.1-1
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#998080: libglib2.0-doc: package is marked 'Arch: all' but has different contents if built on 32-bit or 64-bit host

[Arnaud Ferraris]

Package: libglib2.0-doc
Version: 2.70.0-1
Severity: normal
X-Debbugs-Cc: arnaud.ferra...@gmail.com

Dear Maintainer,

While re-building glib2.0 I noticed that the generated libglib2.0-doc was
different depending on whether it was built on a 32-bit system or a 64-bit one.

This is due to the documentation quoting C code relying on different base types
('long' vs. 'int', or 'long long' vs. 'long') or macros ('GUINT64_TO_BE' vs.
'GUINT32_TO_BE') depending on the target arch's register width.

As a result, libglib2.0-doc contains erroneous information on 32-bit
architectures, and might benefit from being marked 'Arch: any'.

Attached is a diff showing the differences between a package generated on arm64
and one generated on armhf. I assume other differences would result from a
build performed on a big-endian machine but didn't had the opportunity to
verify this assumption so far.

Best regards,
Arnaud


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

Kernel: Linux 5.14.0-2-amd64 (SMP w/64 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

libglib2.0-doc depends on no packages.

libglib2.0-doc recommends no packages.

Versions of packages libglib2.0-doc suggests:
ii  devhelp  41.2-1

-- no debconf information
diff -ur arm64/usr/share/doc/libglib2.0-doc/glib/glib-Basic-Types.html 
armhf/usr/share/doc/libglib2.0-doc/glib/glib-Basic-Types.html
--- arm64/usr/share/doc/libglib2.0-doc/glib/glib-Basic-Types.html   
2021-10-29 13:01:17.0 +0200
+++ armhf/usr/share/doc/libglib2.0-doc/glib/glib-Basic-Types.html   
2021-10-29 13:01:17.0 +0200
@@ -405,7 +405,7 @@
 Functions
 
 G_GINT64_CONSTANT()
-#define G_GINT64_CONSTANT(val) (val##L)
+#define G_GINT64_CONSTANT(val) (G_GNUC_EXTENSION 
(val##LL))
 
 This macro is used to insert 64-bit integer literals
 into the source code.
@@ -428,7 +428,7 @@
 
 
 G_GUINT64_CONSTANT()
-#define G_GUINT64_CONSTANT(val) (val##UL)
+#define G_GUINT64_CONSTANT(val) (G_GNUC_EXTENSION 
(val##ULL))
 
 This macro is used to insert 64-bit unsigned integer
 literals into the source code.
@@ -860,7 +860,7 @@
 
 
 gint64
-typedef signed long gint64;
+G_GNUC_EXTENSION typedef signed long long gint64;
 
 A signed integer guaranteed to be 64 bits on all platforms.
 Values of this type can range from G_MININT64
@@ -886,7 +886,7 @@
 
 
 G_GINT64_MODIFIER
-#define G_GINT64_MODIFIER "l"
+#define G_GINT64_MODIFIER "ll"
 
 The platform dependent length modifier for conversion specifiers
 for scanning and printing values of type gint64 or guint64.
@@ -899,7 +899,7 @@
 
 
 G_GINT64_FORMAT
-#define G_GINT64_FORMAT "li"
+#define G_GINT64_FORMAT "lli"
 
 This is the platform dependent conversion specifier for scanning
 and printing values of type gint64. See also G_GINT16_FORMAT.
@@ -913,7 +913,7 @@
 
 
 guint64
-typedef unsigned long guint64;
+G_GNUC_EXTENSION typedef unsigned long long 
guint64;
 
 An unsigned integer guaranteed to be 64-bits on all platforms.
 Values of this type can range from 0 to G_MAXUINT64
@@ -931,7 +931,7 @@
 
 
 G_GUINT64_FORMAT
-#define G_GUINT64_FORMAT "lu"
+#define G_GUINT64_FORMAT "llu"
 
 This is the platform dependent conversion specifier for scanning
 and printing values of type guint64. See also G_GINT16_FORMAT.
@@ -993,7 +993,7 @@
 
 
 gsize
-typedef unsigned long gsize;
+typedef unsigned int gsize;
 
 An unsigned integer type of the result of the sizeof operator,
 corresponding to the size_t type defined in C99.
@@ -1007,7 +1007,7 @@
 
 
 G_MAXSIZE
-#define G_MAXSIZE G_MAXULONG
+#define G_MAXSIZE G_MAXUINT
 
 The maximum value which can be held in a gsize.
 Since: 2.4
@@ -1015,7 +1015,7 @@
 
 
 G_GSIZE_MODIFIER
-#define G_GSIZE_MODIFIER "l"
+#define G_GSIZE_MODIFIER ""
 
 The platform dependent length modifier for conversion specifiers
 for scanning and printing values of type gsize. It
@@ -1025,7 +1025,7 @@
 
 
 G_GSIZE_FORMAT
-#define G_GSIZE_FORMAT "lu"
+#define G_GSIZE_FORMAT "u"
 
 This is the platform dependent conversion specifier for scanning
 and printing values of type gsize. See also G_GINT16_FORMAT.
@@ -1034,7 +1034,7 @@
 
 
 gssize
-typedef signed long gssize;
+typedef signed int gssize;
 
 A signed variant of gsize, corresponding to the
 ssize_t defined on most platforms.
@@ -1046,7 +1046,7 @@
 
 
 G_MINSSIZE
-#define G_MINSSIZE G_MINLONG
+#define G_MINSSIZE G_MININT
 
 The minimum value which can be held in a gssize.
 Since: 2.14
@@ -1054,7 +1054,7 @@
 
 
 G_MAXSSIZE
-#define G_MAXSSIZE G_MAXLONG
+#define G_MAXSSIZE G_MAXINT
 
 The maximum value which can be held in a gssize.
 Since: 2.14
@@ -1062,7 +1062,7 @@
 
 
 G_GSSIZE_MODIFIER
-#define G_GSSIZE_MODIFIER "l"
+#define G_GSSIZE_MODIFIER ""
 
 The platform dependent length modifier for conversion specifiers
 for scanning and 

Bug#998079: mrtg: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: mrtg
Version: 2.17.8+git20211022.f52e91e-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for mrtg's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-



mrtg 2.17.8+git20211022.f52e91e-1_pt.po.gz
Description: application/gzip

Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator

[Bastian Germann]

On Fri, 29 Oct 2021 15:37:12 +0900 Seunghun Han  wrote:

Control: tags -1 - moreinfo

Thank you for your help, Bastian. I just uploaded a new package [1] to
mentors.debian.net. Please check it if there are any other issues.


I have created https://salsa.debian.org/debian/swtpm and granted you 
maintainer access. Please use that repo from now on.


The upstream branch is a mix of upstream's git commits and gbp imports. 
Please fix that if you know how to do it.


The watch file still needs work. See the uversionmangle in Feri's comment.

The build fails. See https://salsa.debian.org/debian/swtpm/-/jobs/2129890

Bug#993835: rnp FTBFS: rnp_tests.test_key_add_userid (Failed)

[Daniel Kahn Gillmor]

Version: 0.15.2-1

The RNP test suite no longer fails on test_key_add_userid as of version
0.15.2-1.

There are new failures on armel and armhf with
test_sym_encryption__rnp_aead, sigh, but i'll try to diagnose those in a
separate bug report.

  --dkg

On Tue 2021-09-07 05:52:14 +0300, Adrian Bunk wrote:
> Source: rnp
> Version: 0.14.0-6
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=rnp=sid
>
> ...
> test 135
> Start 135: rnp_tests.test_key_add_userid
>
> 135: Test command: /<>/build/src/tests/rnp_tests 
> "--gtest_filter=rnp_tests.test_key_add_userid" 
> "--gtest_also_run_disabled_tests"
> 135: Environment variables: 
> 135:  RNP_TEST_DATA=/<>/src/tests/data
> 135: Test timeout computed to be: 3000
> 135: Note: Google Test filter = rnp_tests.test_key_add_userid
> 135: [==] Running 1 test from 1 test suite.
> 135: [--] Global test environment set-up.
> 135: [--] 1 test from rnp_tests
> 135: [ RUN  ] rnp_tests.test_key_add_userid
> 135: unknown file: Failure
> 135: C++ exception with description "rnp_exception" thrown in the test body.
> 135: [  FAILED  ] rnp_tests.test_key_add_userid (31 ms)
> ...
>
> 99% tests passed, 1 tests failed out of 213
>
> Total Test time (real) = 650.07 sec
>
> The following tests FAILED:
>   135 - rnp_tests.test_key_add_userid (Failed)
> Errors while running CTest
> make[1]: *** [Makefile:129: test] Error 8


signature.asc
Description: PGP signature

Bug#998078: reportbug: linux-headers-cloud-arm64 from buster-backports can't be satisfied

[Rich Ercolani]

Package: linux-headers-cloud-arm64
Severity: normal

Dear Maintainer,

linux-headers-cloud-arm64 and linux-image-cloud-arm64 point to 
-5.10.0-0.bpo.8-cloud-arm64, except...
while linux-image-5.10.0-0.bpo.8-cloud-arm64 is still around, linux-headers-... 
is not.

So you can't install the headers for the cloud-arm64 image without reaching out 
to snapshot.debian.org.

Presumably because the bpo.9 version hasn't produced a signed image yet, but 
the old one got expired because the new headers package made it in?

You can see this if you check out:
https://packages.debian.org/search?keywords=5.10.0-0.bpo.8-cloud-arm64
https://packages.debian.org/search?keywords=5.10.0-0.bpo.9-cloud-arm64

Thanks,
- Rich

-- System Information:
Debian Release: 10.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-18-arm64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-headers-cloud-arm64 depends on:
pn  linux-headers-5.10.0-0.bpo.8-cloud-arm64  

linux-headers-cloud-arm64 recommends no packages.

linux-headers-cloud-arm64 suggests no packages.

Bug#996987: closed by Debian FTP Masters (reply to Drew Parsons ) (Bug#996987: fixed in fenics-dolfinx 1:0.3.0-6)

[Adrian Bunk]

Control: reopen -1

On Sat, Oct 23, 2021 at 12:06:03AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:dolfinx package:
> 
> #996987: dolfinx: FTBFS: unsatisfiable Build-Depends
>...
>  fenics-dolfinx (1:0.3.0-6) unstable; urgency=medium
>  .
>* release dolfinx 0.3 to unstable. Closes: #996987.
>...

src:dolfinx is still unfixed, and as I understand it it will never get 
fixed since it was replaced with src:fenics-dolfinx.

basix/ffcx/dolfinx might all need removal hints and hints to ignore 
their test failures for this transition, since they've all been replaced
with fenics-* source packages.

cu
Adrian

Bug#984157: closed by Debian FTP Masters (reply to bott...@debian.org (A. Maitland Bottoms)) (Bug#984157: fixed in uhd 3.15.0.0-5)

[Adrian Bunk]

On Fri, Oct 22, 2021 at 06:06:06AM +, Debian Bug Tracking System wrote:
>...
> /usr/include/uhd/property_tree.ipp:26:50: error: expected ‘)’ before ‘mode’
>26 | property_impl(property_tree::coerce_mode_t mode) : 
> _coerce_mode(mode)
>   | ~^
>   |  )
> /usr/include/uhd/property_tree.ipp:33:5: error: template-id not allowed for 
> destructor
>33 | ~property_impl(void)
>   | ^
>...

This part appears to still need fixing:
https://buildd.debian.org/status/logs.php?pkg=gnss-sdr=0.0.15-1%2Bb1

cu
Adrian

Bug#998077: package "sfdisk" recommended but "sfdisk" purely virtual

[Evan Pitstick]

Package: salt-minion
Version: 3002.6+dfsg1-4

salt-minion recommends the "sfdisk" package but this is an empty
virtual package.
The "fdisk" package contains the sfdisk bin so it is probably the
correct replacement.


% uname -a
Linux sql-secondary 5.10.0-9-cloud-amd64 #1 SMP Debian 5.10.70-1
(2021-09-30) x86_64 GNU/Linux
% cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

Bug#996569: OT: Roland Puntaier / "getmail6" drama

[Charles Cazabon]

Sudip Mukherjee  wrote:
> 
> Marking this bug as serious and the binary packages should be removed
> in the next 30 days.

Thank you.

Charles
-- 
--
Charles Cazabon  
Software, consulting, and services available at http://pyropus.ca/
--

Bug#994443: [R-pkg-team] Bug#994443: marked as done (r-bioc-deseq2: autopkgtest regression)

[Nilesh Patra]

control: fixed -1 1.32.0+dfsg-3

Hi Graham,


r-bioc-deseq2's autopkgtests started to again pass in testing on
2021-09-29, once r-bioc-tximportdata migrated.
However, the autopkgtests in stable continue to fail [1].



I think you are doing something wrong if a change in a package in
unstable affects a package in testing and stable.


I think this has got nothing to do with our changes in unstable -- I'd be very 
surprised if so,
since essentially atleast stable is disconnected, unless some other package has 
been on-purpose updated there.
As I can see, tests in stable were always failing[1]
This is due to missing dep, see Michael's mail below.

So I'm marking this bug as fixed in the latest version to avoid autoremoval. 
Hope that is okay.

[1]: https://ci.debian.net/packages/r/r-bioc-deseq2/stable/amd64/

Nilesh

On Fri, 22 Oct 2021 14:05:45 +0200 "Michael R. Crusoe"  
wrote:

On Thu, 21 Oct 2021 15:15:52 +0200 Graham Inggs  wrote:
 > Control: reopen -1
 >
 > r-bioc-deseq2's autopkgtests started to again pass in testing on
 > 2021-09-29, once r-bioc-tximportdata migrated.
 > However, the autopkgtests in stable continue to fail [1].

Correct, because the package r-bioc-tximportdata does not exist in stable.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998076: darkslide: contains embedded fonts with licenses that aren't accounted for

[Daniel Kahn Gillmor]

Package: darkslide
Version: 6.0.0-2

darkslide contains:

 /usr/share/doc/darkslide/examples/_assets/SourceSansPro.woff2

this appears to be the SourceSansPro font, which is otherwise only
referenced (and also distributed?) in debian in texlive-fonts-extra
package.  (i can't figure out what licensing is appropriate for
SourceSansPro from a quick scan of
/usr/share/doc/texlive-fonts-extra/copyright)

and the following files appear to embed base64-encoded versions fonts in
the Alegreya Sans family in the following files:

/usr/lib/python3/dist-packages/darkslide/themes/abyss/css/theme.css
/usr/lib/python3/dist-packages/darkslide/themes/default/css/theme.css
/usr/lib/python3/dist-packages/darkslide/themes/white/css/theme.css
/usr/lib/python3/dist-packages/darkslide/themes/void/css/theme.css

Alegreya Sans is in the fonts-alegreya-sans package, but
/usr/share/doc/fonts-alegreya-sans/copyright claims it is licensed under
OFL-1.1, while /usr/share/doc/darkslide/copyright makes no mention of
OFL-1.1

i also note that these embedded fonts end up taking up more than 75% of
the darkslide package (on the order of 400KiB each, i think).

Not sure what the right resolution here is.  it'd be nice to reduce the
weight of the package by stripping them, which would also significantly
reduce the size of any slideshow generated using darkslide --embed
(though it might not render the same on a machine that doesn't have the
associated fonts available).

Thanks for maintaining darkslide in debian!

--dkg


signature.asc
Description: PGP signature

Bug#996569: OT: Roland Puntaier / "getmail6" drama

[Sudip Mukherjee]

Control: severity -1 serious
--

On Fri, Oct 29, 2021 at 3:09 AM Charles Cazabon
 wrote:
>
> Gary R. Schmidt  wrote:
> >



>
> And Debian, you're supposed to be about doing the ethical thing.  "getmail6"
> and having it as a silent "upgrade" that replaces getmail betrays the trust of
> getmail's users, and drags the good reputation of getmail through the mud.

Marking this bug as serious and the binary packages should be removed
in the next 30 days.
Feel free to close this bug when you and Roland have resolved your
differences and users start complaining about getmail not available in
Debian.


-- 
Regards
Sudip

Bug#997976: podman suggests iptables, but "podman run" does not appear to work without it

[Reinhard Tartler]

Control: forwarded -1 https://github.com/containers/podman/issues/12134
Control: reassign -1 containernetworking-plugins

On Thu, Oct 28, 2021 at 11:26 AM Reinhard Tartler 
wrote:

>  I'd like to hear upstream's opinion on this.
>

Thanks for reaching out to upstream. I agree with Paul's assessment, and am
re-assigning this accordingly.

-- 
regards,
Reinhard

Bug#996642: FTBFS with glibc 2.32

[Nilesh Patra]

Hi Alastair,

On Tue, 26 Oct 2021 at 13:27, Alastair McKinstry <
alastair.mckins...@sceal.ie> wrote:

> Hi Nilesh
>
>
>
> Just uploaded a patched csh now.
>
> Apologies I was trying to port a later snapshot of csh but ran into
> porting issues.
>

No worries, and thanks for the upload. But one odd thing that I noticed in
this upload is (from debdiff):

-Maintainer: Alastair McKinstry 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Alastair McKinstry 

Is this really intended? Did you somehow make an (non-intended)
ubuntu-specific change in the Debian package?

Let me know.
Thanks,

Nilesh

Bug#973313: lintian: Salsa CI jobs fail for many sources hosted there

[Felix Lechner]

There was a valuable discussion of Salsa here. [1] It included this
valuable information:

[1] https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/312

Santiago R.R. commented:

I think some of you already knew it, but I confirmed this is something
related to the running environment, meaning the salsa.d.o runners.
With the following .gitlab-ci.yml:

image: 'debian:unstable'

test:
  script:
- locale
- locale -a
- apt-get update ; apt-get -y install lintian
- LANG=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8
-l -Tutf8 -Z /usr/share/man/man1/grep.1.gz > /dev/null
- lintian -i --display-info --pedantic --allow-root
debian/output/*.changes | tee lintian.output

there is still the warning on salsa:
https://salsa.debian.org/santiago/sandbox/-/jobs/2128420

but it runs OK on gitlab.com:
https://gitlab.com/topodelapradera/sandbox/-/jobs/1729096914

I'd suggest to close this MR, since it doesn't solve the issue, and
continue discussing on the BTS.

I don't know what can be done on the Salsa CI side, for the moment,
and it is kind of frustrating.

Bug#994750: RFS: mazeofgalious/0.63-1 [ITA] -- The Maze of Galious

[Parodper]

O 22/10/21 ás 12:40, Bastian Germann escribiu:

On Mon, 4 Oct 2021 00:11:58 +0200 Bastian Germann  wrote:
Please have a look at the package repacking history. There are 
graphics, sounds, and konami.pcx excluded. You must not reintroduce 
them without any good reason (like license change).


Thanks for noticing. Unfortunately, I am not able to find neither the 
files that need to be removed, nor any other discussion about it (other 
than #341501, of course).


To be safe I will do as the previous maintainer did, and put links to 
naramura and jorito in all graphics/sound sets


Also, it would be nice if you handed in the next version under the Games 
Team umbrella.


Please remove the moreinfo tag when you are done.


Will send a message. Thanks.

Bug#997913: OVMF-ia32 does not provide file usable by -bios

[Glenn Washburn]

On Thu, 28 Oct 2021 12:00:09 -0600
dann frazier  wrote:

> On Thu, Oct 28, 2021 at 11:19:06AM -0500, Glenn Washburn wrote:
> > On Thu, 28 Oct 2021 07:46:11 -0600
> > dann frazier  wrote:
> > > On Tue, Oct 26, 2021 at 07:31:38PM -0500, Glenn Washburn wrote:
> > > > Package: ovmf-ia32
> > > > Version: 2020.11-4
> > > > 
> > > > Hello Maintainers,
> > > > 
> > > > I'd like ovmf-ia32 to install a file useable by QEMU's -bios option.
> > > > Currently the package only installs OVMF32_CODE_4M.secboot.fd and
> > > > OVMF32_VARS_4M.fd, but I believe I need a file that combines both code
> > > > and vars. According to the wiki[1], I believe I can use the existing
> > > > files using "-drive if=pflash,..." options, but that is not a great
> > > > option for me.
> > > 
> > > Can you elaborate more on your use case? While we do provide such an
> > > image for X64, that is for backwards-compatibility only.
> > 
> > I'm working on GRUB2's test suite and it has tests that use QEMU for
> > many of its tests.
> 
> edk2's autopkgtest has a testing framework that tests OVMF32, and all
> the other archs, using -pflash. It also does tests with GRUB images
> (e.g. making sure signed versions work w/ SecureBoot enabled, unsigned
> versions do not). Let me know if it'd be useful to collaborate on that
> framework. Here's the main bit:
> 
> https://salsa.debian.org/qemu-team/edk2/-/blob/debian/debian/python/UEFI/Qemu.py

Thanks for the reference, this will be helpful in converting grub tests
to use the pflash instead of -bios option. I'm wondering by the paths
are hard-coded, when it seems that the purpose of the json files in
/usr/share/qemu/firmware is to provide these paths. I'm guessing this
code assumes a debian system and that the paths won't change much.
Using the json files in the grub tests is more problematic because they
are in bash. And yes, I could use jq, but I'm reluctant to add another
dependency. I'm still mulling it over.

> > Specifically, I need the combined firmware file when testing the
> > i386-efi target.
> 
> Why? I mean, why can't that testing use a throw-away pflash image for
> VARS like we do in edk2 autopkgtesting?

Ok, actually, I can use the pflash. I was wanting to avoid that because
it makes things more complicated. I thought it might be easier to get
the combined file included and that it might be useful to others. I
have now tesed using pflash and it does work.

The issue is that I'd like to have the tests use paths standardized
across distros. When using -bios, the -L option can be used to add to a
search path to find the firmware file. Of course, this doesn't work if
the filenames of the firmware aren't standardized. For ARM/ARM64, it
looks like debian's path for the code and vars is fairly standard
across distros, and to a lesser extent x86_64, but for i386 it looks
like filenames and where they are on the filesystem vary widely. 

I'm seeing now that a good resolution to my issue may lie at the
conjunction of QEMU, OVMF, and distro packaging.

> > Perhaps, I don't need a binary with combined code and vars. On the ARM
> > and ARM64 EFI targets, I can pass the AAVMF32_CODE.fd to -bios just
> > fine. So perhaps the IA32 firmware is built in such a way that the code
> > file requires the vars, but could be build to not require it? IOW, why
> > can't I just send the firmware CODE file to QEMU using -bios like I can
> > with ARM and ARM64?
> 
> I don't know if or why OVMF*_CODE doesn't work with -bios. Separate
> CODE/VARS is the most flexible build (and what people should use
> in production), so that's what we provide. I'd need to be convinced
> that there's a good reason to increase the size of the ovmf-ia32 deb
> for all users to support -bios mode.

The best of both worlds would be to get a version of OVMF*_CODE that
works with -bios. According to this (old?) document[1], builds using -D
SECURE_BOOT_ENABLE, which I presume is the case here, must use pflash.
So perhaps the best of both worlds isn't possible now. Is a build
without secureboot equivalent to the file released in the original bug
report? 

Yes the pflash mechanism is more flexible, and thus good to have, but
the -bios option was nice because it was easier to use from a user
perspective. Perhaps, QEMU really needs a -uefi option that's like the
-bios option, which would set everything up based on defaults and
looking through a search path like -bios. (yes, not a Debian issue)

For my purposes, I don't need a writable vars, which I've tested by
setting readonly to "on" for the vars pflash. So while adding extra
flexibility, it also adds extra complexity (ie another point of
failure).

I'm not sure what you might need to be convinced, but I notice that
both Arch and Fedora are shipping a 32-bit OVMF with and without
secureboot.

> > Also, I  don't need the secure boot feature of the firmware. The wiki
> > leaves me with the suspicion that I may need to configure some of the
> > firmware variables before I can boot successfully. 

Bug#989155: dh_installinit: when upgrading to a version that adds --no-restart-after-upgrade, the service is not restarted

[Ryan Tandy]

Hi Michael,

On Fri, Oct 29, 2021 at 09:51:46AM +0200, Michael Biebl wrote:

If you use "--no-restart-after-upgrade", why do you expect the service to be
restarted?


The man page describes --no-restart-after-upgrade:

 Undo a previous --restart-after-upgrade (or the default of compat 10).  
 If no other options are given, this will cause the service to be 
 stopped in the prerm script and started again in the postinst script.



Isn't the point of "--no-restart-after-upgrade" to *not* stop any
processes on upgrades.


I think the one you're talking about is -r, --no-stop-on-upgrade, 
--no-restart-on-upgrade.


thanks,
Ryan

Bug#966826: RFS: libmobi/0.6-1 [ITP] -- Tools for handling Mobipocket/Kindle ebook format documents

[Bastian Germann]

On 29.10.21 19:12, Bartek Fabiszewski wrote:

On 29 Oct 2021, at 17:16, Bastian Germann  wrote:


On Sun, 2 Aug 2020 22:36:51 +0200 Bartek Fabiszewski wrote:

It builds those binary packages:
  libmobi0-tools - Tools for handling Mobipocket/Kindle ebook format documents
  libmobi0 - C library for handling Mobipocket/Kindle ebook format documents
  libmobi-dev - Development files for libmobi
To access further information about this package, please visit the following 
URL:
  https://mentors.debian.net/package/libmobi/


It is discouraged to intermingle debian and upstream changes. Also, it is 
discouraged to have the complete upstream git history in the salsa repo (see 
your debian branch). I have created a master and an upstream branch that you 
can use with git-buildpackage going forward. You can drop the debian branch.

Please use the same email address in d/changelog and in d/control (Maintainer) 
else you get those lintian warnings about an NMU happening.

Please read the thread in 
https://lists.debian.org/debian-legal/2017/08/msg0.html and find out if you 
were right about Project Gutenberg license (I have not yet read it). Maybe 
there are other Debian threads about it.


Regarding the license.
According to the thread you mention, the Gutenberg Project license fails the 
DFSG, so my assumption was wrong.

At the same time, according to the license there are no restrictions to 
distributing the ebooks if the Project Gutenberg license and all references to 
Project Gutenberg are removed from distributed material. This is confirmed by 
the thread in legal list.

There are three ebook samples in source tarball that were downloaded from 
Project Gutenberg website. One of the samples was later modified, so that there 
are no references to Project Gutenberg. The other ones have reference to the 
Project inside the ebook.

To comply with DFSG I will remove the Project Gutenberg license from 
d/copyright, so that the Project Gutenberg trademark is not used anywhere.
I will also remove two of the samples. The ones that still have references to 
the Project in ebook text.



This means a repack of the upstream sources. Please make yourself 
familiar with how to handle that in the d/copyright file with 
Files-Excluded and in the d/watch file (man uscan). You want to have a 
+dfsg repack suffix.

Bug#995365: (no subject)

[Jean Baptiste Favre]

Dear maintainer,

The fix you added solve the ImportError: cannot import name 'ENOENT'.

However, it still prevent manpages build for trafficserver package.
Using the latest release of sphinxcontrib.plantuml allows the build.

Version 0.5 of the package is now 7 years old. Please consider packaging 
last release ?


Thanks,
Jean Baptiste


OpenPGP_signature
Description: OpenPGP digital signature

Bug#939405: Waypipe packaging

[Birger Schacht]

Hi Gard,

On 10/29/21 5:38 PM, Gard Spreemann wrote:


Gard Spreemann  writes:


Hi Birger,

In 2019 you filed an ITP for Waypipe (#939405 [1]). It doesn't seem that
the packaging was finished. I would be more than happy to take over the
packaging and maintenance, or to assist you, if you need any help.

Let me know!

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939405



I've prepared a package here that works well:

  https://salsa.debian.org/gspr/waypipe/

I won't upload until/if I get your blessing, I don't wanna step on your
feet here :-)


no need to worry, feel free to upload ;) thanks for taking care of the 
package!


cheers,
Birger




  Best,
  Gard
  

Bug#998075: deborphan: should not report packages providing plugins

[Vincent Lefevre]

Package: deborphan
Version: 1.7.35
Severity: wishlist

deborphan should not report packages providing plugins.

Example: libspa-0.2-bluetooth, which is in section libs, but may
be needed even though no packages depend on it, because it provides
plugins:

Description: libraries for the PipeWire multimedia server - bluetooth plugins

I suppose that deborphan should search for "plugin" in the description
(not sure whether there can be false positives).

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

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

Versions of packages deborphan depends on:
ii  libc6  2.32-4

Versions of packages deborphan recommends:
ii  apt   2.3.11
ii  gettext-base  0.21-4

deborphan suggests no packages.

-- no debconf information

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

Bug#998073: pipewire-pulse: fails to automatically switch to headphones when connected

[Vincent Lefevre]

Package: pipewire-pulse
Version: 0.3.39-3
Severity: important

I use bluetooth speakers by default. When I connect my bluetooth
headphones, I want the system to automatically switch from the
speakers to the headphones. This is how it behaved before the upgrade
and the replacement of pipewire-media-session by pipewire-pulse,
libspa-0.2-bluetooth and wireplumber. Note that this is particularly
important when one isn't in front of the computer. But just after the
upgrade, this no longer works.

https://www.reddit.com/r/archlinux/comments/o87qx9/pipewire_automatically_switch_audioport_when/
mentions

  https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/758
  "media-session: switch to the route when availability changed"

which says:

"When a user plugs in headphones, they expect to hear an audio through
them. Currently, that usecase might or might not work with pipewire
depending on the user's luck, because pipewire instead uses port
priorities, and those apparently rarely have sane default values."

It was merged 4 months ago. Now, I don't know the status. Was it a
pipewire-media-session thing like the title suggests?

This could also be this bug, still open:

  https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/533

In any case, if there is still an issue compared to pulseaudio
(which was working fine), the replacement is a terrible idea.

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

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

Versions of packages pipewire-pulse depends on:
ii  init-system-helpers  1.60
ii  libc62.32-4
ii  libpipewire-0.3-00.3.39-3
ii  pipewire 0.3.39-3

pipewire-pulse recommends no packages.

pipewire-pulse suggests no packages.

-- no debconf information

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

Bug#998072: ntpsec: Stuffed up markup in ntpq.1 makes large parts difficult to read

[maney]

Package: ntpsec
Version: 1.2.0+dfsg1-4
Severity: normal
Tags: a11y patch

While configuring ntpsec which has recently replaced plain ntp, I had
occasion to look for information I needed in ntpq's man page.  I found this
was much more difficult than it ought to have been due to stuffed up markup
that left some large swaths of the text underlined.  See for example:

  $ man ntpq
  {search for mrulist}

and see how the underlining gets out of hand.  I found, while getting the
man page into usable shape for myself, a couple places where the markup was
weirdly inconsistent around the saem word - perhaps a global replace that
worked for other places went awry in these spots and it wasn't noticed?

I've had a brief look at the upstream source, and they seem to have moved to
using a very different "adoc" markup, so I don't know how this applies to
later versions in Debian.

Aside from this the switch from old ntp went very smoothly!

Thanks.

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

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

Versions of packages ntpsec depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13+deb11u2
ii  libcap2  1:2.44-1
ii  libssl1.11.1.1k-1+deb11u1
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  python3  3.9.2-3
ii  python3-ntp  1.2.0+dfsg1-4
ii  tzdata   2021a-1+deb11u1

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-137
ii  systemd 247.3-6

Versions of packages ntpsec suggests:
ii  apparmor   2.13.6-10
pn  certbot
ii  ntpsec-doc 1.2.0+dfsg1-4
pn  ntpsec-ntpviz  

-- Configuration Files:
/etc/default/ntpsec changed [not included]
/etc/letsencrypt/renewal-hooks/deploy/ntpsec [Errno 2] No such file or 
directory: '/etc/letsencrypt/renewal-hooks/deploy/ntpsec'
/etc/ntpsec/ntp.conf changed [not included]

-- no debconf information
--- ntpq.1  2021-10-20 10:41:55.064526186 -0500
+++ ntpq.1.fixed2021-10-20 10:40:55.174663167 -0500
@@ -510,7 +510,7 @@
 .RE
 .sp
 \f(CRmrulist\fP [\f(CRlimited\fP | \f(CRkod\fP | \f(CRmincount=\fP\fIcount\fP 
| \f(CRmindrop=\fP\fIdrop\fP | \f(CRminscore=\fP\fIscore\fP | 
\f(CRmaxlstint=\fP\fIseconds\fP | \f(CRminlstint=\fP\fIseconds\fP | 
\f(CRladdr=\fP\fIlocaladdr\fP | \f(CRsort=\fP\fIsortorder\fP | 
\f(CRresany=\fP\fIhexmask\fP | \f(CRresall=\fP\fIhexmask\fP | 
\f(CRlimit=\fP\fIlimit\fP |
-\f(CRaddr.\fInum\fP=\fP\fIaddress\fP]::
+\f(CRaddr.\fP\fInum\fP=\fIaddress\fP]::
 Obtain and print traffic counts collected and maintained by the
 monitor facility. This is useful for tracking who \fIuses\fP or
 \fIabuses\fP your server.
@@ -520,9 +520,9 @@
 filter the list returned by \f(CRntpd\fP. The \f(CRlimited\fP and \f(CRkod\fP 
options
 return only entries representing client addresses from which the last
 packet received triggered either discarding or a KoD response.
-the \f(CRaddr.\fInum\fP=\fP option adds specific addresses to retrieve when
+the \f(CRaddr.\fP\fInum\fP= option adds specific addresses to retrieve when
 \f(CRlimit=\fP\fI1\fP. Values of 0 to 15 are supported for \fInum\fP. Also, 
used
-internally with \f(CRlast.\fInum\fP=\fP\fIhextime\fP to select the starting 
point
+internally with \f(CRlast.\fP\fInum\fP=\fIhextime\fP to select the starting 
point
 for retrieving continued response.
 the \f(CRfrags=\fP\fIfrags\fP option limits the number of datagrams
 (fragments) in response.  Used by newer ntpq versions instead

Bug#997429: ycm-cmake-modules: FTBFS: Could not import extension cmake (exception: cannot import name 'htmlescape' from 'sphinx.util.pycompat' (/usr/lib/python3/dist-packages/sphinx/util/pycompat.py))

[Nilesh Patra]

Hi Daniele,

On Sat, 23 Oct 2021 22:33:30 +0200 Lucas Nussbaum  wrote:

Source: ycm-cmake-modules
Version: 0.13.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs


I did a fix for this and uploaded.
The patch is here in salsa[1] -- if you think it is okay, could you please 
forward it upstream?

[1]: 
https://salsa.debian.org/science-team/ycm-cmake-modules/-/blob/master/debian/patches/fix-sphinx-build.patch

Thanks,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#998071: plasma-desktop: krunner won't show when using shortcuts

[mando]

Package: plasma-desktop
Version: 4:5.23.0-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I migrated from Debian testing (bookworm) to Debian sid (in short, some KDE 
packages -including libkdecorations*) in sid are not consistent and make KDE 
unusable in debian testing).
After this update, krunner was not showing anymore when pressing Alt+F2 or 
Alt+space.
However:
- krunner was running fine from a terminal (e.g. konsole).
- the shortcuts related to krunner were correctly set/modifiable in 
systemsettings5.


The bug is due to conflicting sections related to KRunner in 
~/.config/kglobalshortcutsrc.
The new key is [org.kde.krunner.desktop].
The one(s) are obsolete and breaks krunner related shortcuts.

  * How to solve the problem

The easiest way to solve the bug is just to regenerate this file.

rm ~/.config/kglobalshortcutsrc.

... so that a new file is regenerated without the wrong keys.

I guess that removing the obsolete keys would also work.

   * What outcome did you expect instead?

It would be nice to automatically migrate this file automatically migrated (or 
maybe, to update krunner so that it works depsite obsolete sections in 
~/.config/kglobalshortcutsrc.)

Thanks,
Best regards


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

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

Versions of packages plasma-desktop depends on:
ii  accountsservice  0.6.55-3
ii  breeze   4:5.23.0-2
ii  kactivitymanagerd5.23.0-1
ii  kde-cli-tools4:5.23.0-2
ii  kded55.86.0-1
ii  kio  5.86.0-1
ii  kpackagetool55.86.0-1
ii  libaccounts-qt5-11.16-2
ii  libc62.32-4
ii  libcrypt11:4.4.25-2
ii  libglib2.0-0 2.70.0-3
ii  libibus-1.0-51.5.25-2
ii  libkaccounts24:21.08.0-1
ii  libkf5activities55.86.0-1
ii  libkf5activitiesstats1   5.86.0-1
ii  libkf5authcore5  5.86.0-1
ii  libkf5baloo5 5.86.0-1
ii  libkf5codecs55.86.0-1
ii  libkf5completion55.86.0-1
ii  libkf5configcore55.86.0-1
ii  libkf5configgui5 5.86.0-1
ii  libkf5configwidgets5 5.86.0-1
ii  libkf5coreaddons55.86.0-1
ii  libkf5crash5 5.86.0-1
ii  libkf5dbusaddons55.86.0-1
ii  libkf5declarative5   5.86.0-1
ii  libkf5globalaccel-bin5.86.0-1
ii  libkf5globalaccel5   5.86.0-1
ii  libkf5guiaddons5 5.86.0-1
ii  libkf5i18n5  5.86.0-1
ii  libkf5iconthemes55.86.0-1
ii  libkf5itemviews5 5.86.0-1
ii  libkf5jobwidgets55.86.0-1
ii  libkf5kcmutils5  5.86.0-1
ii  libkf5kdelibs4support5   5.86.0-1
ii  libkf5kiocore5   5.86.0-1
ii  libkf5kiofilewidgets55.86.0-1
ii  libkf5kiogui55.86.0-1
ii  libkf5kiowidgets55.86.0-1
ii  libkf5newstuff5  5.86.0-3
ii  libkf5newstuffcore5  5.86.0-3
ii  libkf5notifications5 5.86.0-1
ii  libkf5notifyconfig5  5.86.0-1
ii  libkf5package5   5.86.0-1
ii  libkf5plasma55.86.0-1
ii  libkf5plasmaquick5   5.86.0-1
ii  libkf5quickaddons5   5.86.0-1
ii  libkf5runner55.86.0-1
ii  libkf5service-bin5.86.0-1
ii  libkf5service5   5.86.0-1
ii  libkf5solid5 5.86.0-1
ii  libkf5sonnetcore55.86.0-1
ii  libkf5sonnetui5  5.86.0-1
ii  libkf5wallet-bin 5.86.0-1
ii  libkf5wallet55.86.0-1
ii  libkf5widgetsaddons5 5.86.0-1
ii  libkf5windowsystem5  5.86.0-1
ii  libkf5xmlgui55.86.0-1
ii  libkuserfeedbackcore11.0.0-3
ii  libkworkspace5-5 4:5.23.0-3
ii  libnotificationmanager1  

Bug#939405: Waypipe packaging

[Gard Spreemann]

Gard Spreemann  writes:

> Hi Birger,
>
> In 2019 you filed an ITP for Waypipe (#939405 [1]). It doesn't seem that
> the packaging was finished. I would be more than happy to take over the
> packaging and maintenance, or to assist you, if you need any help.
>
> Let me know!
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939405


I've prepared a package here that works well:

 https://salsa.debian.org/gspr/waypipe/

I won't upload until/if I get your blessing, I don't wanna step on your
feet here :-)


 Best,
 Gard
 


signature.asc
Description: PGP signature

Bug#966826: RFS: libmobi/0.6-1 [ITP] -- Tools for handling Mobipocket/Kindle ebook format documents

[Bastian Germann]

On Sun, 2 Aug 2020 22:36:51 +0200 Bartek Fabiszewski wrote:

It builds those binary packages:

  libmobi0-tools - Tools for handling Mobipocket/Kindle ebook format documents
  libmobi0 - C library for handling Mobipocket/Kindle ebook format documents
  libmobi-dev - Development files for libmobi

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

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



It is discouraged to intermingle debian and upstream changes. Also, it 
is discouraged to have the complete upstream git history in the salsa 
repo (see your debian branch). I have created a master and an upstream 
branch that you can use with git-buildpackage going forward. You can 
drop the debian branch.


Please use the same email address in d/changelog and in d/control 
(Maintainer) else you get those lintian warnings about an NMU happening.


Please read the thread in 
https://lists.debian.org/debian-legal/2017/08/msg0.html and find out 
if you were right about Project Gutenberg license (I have not yet read 
it). Maybe there are other Debian threads about it.

Bug#997995: RFS: ghostwriter/2.0.2-1 -- Distraction-free, themeable Markdown editor

[Sebastien CHAVAUX]

Hello,

"The actual changelog is: << "\ n \ n \ n", with two entries. The older 
one has


never been in Debian, and it doesn't appear to have a special reason to 
keep its entry. It'd be good if you could delete it."


The entry of version 2.0.0 was a leftover, I had done it for myself, 
suddenly I am deleting it.




"A more serious problem, however, is the mess caused by adding a menu 
entry. Thisdoes not work (not a valid xpm, etc.), and in window managers 
thatsupport it, it will show duplicate - because the .desktop file is 
also present.Could you please drop it again? It has been obsolete for ages."



The file is deleted.


Thank you for sharing.
Cordialy.

Bug#994833: OpenCL programs abort when intel-opencl-icd is installed

[Andreas Beckmann]

Control: block -1 with 998058
Control: fixed -1 intel-graphics-compiler/1.0.8744-2

On 29/10/2021 16.33, Jonas Smedegaard wrote:

Reopening, since seemingly the detail about coordinated upload is still
missing: Currently (in sid) intel-opencl-icd is flagged breaking its own
dependencies and therefore impossible to install.


There is a new FTBFS (also in the unmodified package currently in sid) 
due to some failing tests, otherwise I would have uploaded the second 
part of the fix today :-(


Andreas

Bug#995838: [htcondor-debian] Bug#995838: Should condor be removed?

[Tim Theisen]

I plan to upload a new version this weekend.

--
Tim Theisen (he, him, his)
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736

From: htcondor-debian  on behalf of Moritz 
Muehlenhoff 
Sent: Wednesday, October 6, 2021 12:01 PM
To: Debian Bug Tracking System 
Subject: [htcondor-debian] Bug#995838: Should condor be removed?

Source: condor
Severity: serious

condor came up as a candidate for removal from Debian:

- Last upload was in 2018
- Three RC bugs, including various toolchain issues (GCC, Python 2)
- Open security issues

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz
___
htcondor-debian mailing list
htcondor-deb...@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian

Bug#997521: freedict: FTBFS: Failed to create secure directory (/sbuild-nonexistent/.config/pulse): No such file or directory

[Sebastian Humenda]

Hi

Due to the way the FreeDict stylesheets are written, a lot of memory is used.
Could you provide the amount of RAM that is used for the failed build? If it
is below 16G, could it be increased, somehow?


Thanks
Sebastian


signature.asc
Description: PGP signature

Bug#997971: FWD: Bug#997971: [Beolingus] Bug#997971: Monat ist männlich!

[shumenda]

Hallo Peter Mueller,

Peter Mueller schrieb am 28.10.2021, 21:02 +:
>reopen 997971
>thanks
>> From your original source file it becomes apparent that Monat is listed as 
>> being neutral in Austrian German.
>But only colloquially! In written Austrian German (in fact, in any written 
>German), Monat is masculine, consistent with https://dict.tu-chemnitz.de and 
>opposed to what dict says.
>> The formatting is suboptimal, but that's a different story :).
>It's not about formatting. Taking a careful look, it's an omission of 
>extremely important information, namely, a tag such as [ugs.] or [coll.].

Agreed, though it is *still* the wrong place to report this. It is at FreeDict
that this should be filed. I took care of contacting the Author of the
importer.

Cheers
Sebastian


signature.asc
Description: PGP signature

Bug#996998: libconfig-model-dpkg-perl: scan-copyrights fails for package rust-coreutils

[Vignesh Raman]

On Fri, 29 Oct 2021 15:46:38 +0200 Dominique Dumont 
 wrote:

> I'm not sure which commit did fix this issue.
>
> I'll let you bisect libconfig-model-dpkg-perl.
>

Sure :) Will check and update.

Bug#996998: libconfig-model-dpkg-perl: scan-copyrights fails for package rust-coreutils

[Dominique Dumont]

On Friday, 29 October 2021 14:48:29 CEST you wrote:
> Please could you provide the commit which fixes the crash with
> rust-coreutils package. Thank you.

I'm not sure which commit did fix this issue. 

I'll let you bisect libconfig-model-dpkg-perl.

All the best

Bug#995587: transition: ruby3.0-add

[Lucas Kanashiro]

On Thu, 28 Oct 2021 23:34:28 +0200 Sebastian Ramacher 
 wrote:

> Yes, please go ahead

I just uploaded ruby-defaults/1:2.7.6 to unstable adding ruby3.0 as an 
alternative interpreter, it should be available soon. Below you can find 
a list of binNMUs for the dependency level 1:


dislocker
epic5
graphviz
hivex
kamailio
klayout
kross-interpreters
libprelude
libselinux
marisa
mecab
ngraph-gtk
notmuch
protobuf
qdbm
raspell
redland-bindings
remctl
rrdtool
ruby-atomic
ruby-augeas
ruby-bcrypt
ruby-bcrypt-pbkdf
ruby-bert
ruby-bindex
ruby-binding-ninja
ruby-cairo
ruby-cbor
ruby-character-set
ruby-charlock-holmes
ruby-concurrent
ruby-cool.io
ruby-curb
ruby-curses
ruby-damerau-levenshtein
ruby-dataobjects-postgres
ruby-dataobjects-sqlite3
ruby-debian
ruby-debug-inspector
ruby-eb
ruby-ed25519
ruby-enumerable-statistics
ruby-escape-utils
ruby-eventmachine
ruby-exif
ruby-fast-blank
ruby-fast-stemmer
ruby-fast-xs
ruby-fcgi
ruby-ffi
ruby-ffi-yajl
ruby-filesystem
ruby-fusefs
ruby-gitlab-pg-query
ruby-god
ruby-gpgme
ruby-hiredis
ruby-hitimes
ruby-jaro-winkler
ruby-kgio
ruby-ldap
ruby-levenshtein
ruby-libxml
ruby-liquid-c
ruby-murmurhash3
ruby-mysql2
ruby-narray
ruby-ncurses
ruby-nfc
ruby-nio4r
ruby-nokogiri
ruby-odbc
ruby-oily-png
ruby-oj
ruby-ox
ruby-pcaprub
ruby-pg
ruby-posix-spawn
ruby-prof
ruby-prometheus-client-mmap
ruby-rblineprof
ruby-rbtree
ruby-rdiscount
ruby-re2
ruby-redcarpet
ruby-redcloth
ruby-regexp-property-values
ruby-rinku
ruby-rjb
ruby-rmagick
ruby-rpam-ruby19
ruby-rpatricia
ruby-rugged
ruby-sdl
ruby-sequel-pg
ruby-serialport
ruby-shadow
ruby-stackprof
ruby-strptime
ruby-termios
ruby-thrift
ruby-timfel-krb5-auth
ruby-tioga
ruby-tokyocabinet
ruby-uconv
ruby-unf-ext
ruby-unicode
ruby-version-sorter
ruby-vmstat
ruby-websocket-driver
ruby-xmlhash
ruby-xmlparser
ruby-yajl
ruby-zoom
spglib
stfl
subtle
subversion
uwsgi
vim-command-t
weechat
xapian-bindings


The following packages are also part of the dependency level 1 but they 
are still FTBFSes, let's skip them for now.


obexftp
ruby-byebug
ruby-ferret
ruby-dataobjects-mysql
ruby-gd
ruby-json
ruby-kyotocabinet
ruby-libvirt
ruby-mmap2
ruby-psych
ruby-ruby-magic-static
ruby-sigar

--
Lucas Kanashiro

Bug#991678: new upstream versions

[Pierre-Elliott Bécue]

Le 29 octobre 2021 14:49:46 GMT+02:00, Antonio Terceiro  a 
écrit :
>On Fri, Oct 29, 2021 at 12:42:19AM +0200, Pierre-Elliott Bécue wrote:
>> reopen 991678
>> notfixed 991678 1:4.0.10-1
>> thanks
>> 
>> Hi,
>> 
>> Le vendredi 29 octobre 2021 à 00:31:06+0200, Diederik de Haas a écrit :
>> > Version: 1:4.0.10-1
>> > 
>> > On 30 Jul 2021 09:47:14 +0200 Harald Dunkel  
>> > wrote:
>> > > Package: lxc
>> > > Version: 1:4.0.6-2
>> > > Severity: wishlist
>> > > 
>> > > Upstream provides a new version 4.0.10 and 4.0.9LTS, see
>> > 
>> > Version 4.0.10-1 has been uploaded to the archives, thus closing this bug.
>> 
>> Please before doing so, especially if you're not the bug submitter or a
>> maintainer of the package, consider carefully whether or not closing the
>> bug is appropriate.
>> 
>> Here, the request is to provide lxc 4.0.10 in bullseye. While having it
>> in unstable is a requirement, this bug is not solved because it have
>> entered unstable.
>
>Yes, but are we really going to provide 4.0.10 _in bullseye_?

I intend to ask the release team if they would accept it, yes.

It is mostly security and severe bug fixes, I think it would be worth including 
here.

Cheers ! 
--
Pierre-Elliott Bécue
From my phone

Bug#961138: autodep8 uses host APT packages to generate dependencies for pkg-r-autopkgtest tests

[Antonio Terceiro]

On Fri, Oct 29, 2021 at 07:46:30AM +0200, Andreas Tille wrote:
> Control: tags -1 help
> 
> Hi,
> 
> any hint from debian-ci list how to solve this?

Quoting Paul from
https://salsa.debian.org/ci-team/autodep8/-/merge_requests/10#note_279588,
I think the right way to solve this is:

> Maybe instead of querying, the code could just unconditionally add all
> packages in the Suggests and for each add an alternative that's always
> installed? I recall that apt will install the first alternative if it
> easily can.



signature.asc
Description: PGP signature

Bug#991678: new upstream versions

[Antonio Terceiro]

On Fri, Oct 29, 2021 at 12:42:19AM +0200, Pierre-Elliott Bécue wrote:
> reopen 991678
> notfixed 991678 1:4.0.10-1
> thanks
> 
> Hi,
> 
> Le vendredi 29 octobre 2021 à 00:31:06+0200, Diederik de Haas a écrit :
> > Version: 1:4.0.10-1
> > 
> > On 30 Jul 2021 09:47:14 +0200 Harald Dunkel  
> > wrote:
> > > Package: lxc
> > > Version: 1:4.0.6-2
> > > Severity: wishlist
> > > 
> > > Upstream provides a new version 4.0.10 and 4.0.9LTS, see
> > 
> > Version 4.0.10-1 has been uploaded to the archives, thus closing this bug.
> 
> Please before doing so, especially if you're not the bug submitter or a
> maintainer of the package, consider carefully whether or not closing the
> bug is appropriate.
> 
> Here, the request is to provide lxc 4.0.10 in bullseye. While having it
> in unstable is a requirement, this bug is not solved because it have
> entered unstable.

Yes, but are we really going to provide 4.0.10 _in bullseye_?


signature.asc
Description: PGP signature

Bug#996998: libconfig-model-dpkg-perl: scan-copyrights fails for package rust-coreutils

[Vignesh Raman]

On Thu, 28 Oct 2021 17:44:05 +0200 Dominique Dumont 
 wrote:


> I've got no crash with libconfig-model-dpkg-perl 2.153.
>

Please could you provide the commit which fixes the crash with 
rust-coreutils package. Thank you.


Regards,

Vignesh

Bug#994833: OpenCL programs abort when intel-opencl-icd is installed

[Jonas Smedegaard]

Control: reopen -1

Andreas Beckmann wrote:
> Commits are pushed to both packages in git, they need a coordinated 
> upload due to the Depends/Breaks added.

Reopening, since seemingly the detail about coordinated upload is still 
missing: Currently (in sid) intel-opencl-icd is flagged breaking its own 
dependencies and therefore impossible to install.

 - Jonas

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

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

signature.asc
Description: signature

Bug#995587: transition: ruby3.0-add

[Antonio Terceiro]

On Thu, Oct 28, 2021 at 11:34:28PM +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2021-10-20 09:45:10 -0300, Antonio Terceiro wrote:
> > Control: tag -1 - moreinfo
> > 
> > On Sat, Oct 16, 2021 at 03:46:11PM +0200, Sebastian Ramacher wrote:
> > > Control: tags -1 moreinfo
> > > 
> > > On 2021-10-15 06:44:36 -0300, Antonio Terceiro wrote:
> > > > Hi,
> > > > 
> > > > On Sat, Oct 02, 2021 at 03:14:39PM -0300, Antonio Terceiro wrote:
> > > > > Package: release.debian.org
> > > > > Severity: normal
> > > > > User: release.debian@packages.debian.org
> > > > > Usertags: transition
> > > > > 
> > > > > We would like to add support for ruby3.0 in ruby-defaults.
> > > > > 
> > > > > Ben file:
> > > > > 
> > > > > title = "ruby3.0-add";
> > > > > is_affected = (.depends ~ /ruby2.7 | .depends ~ /ruby3.0/) & !.source 
> > > > > ~ /^(ruby2.7|ruby3.0|ruby-defaults)$/);
> > > > > is_good = .depends ~ /ruby3.0/;
> > > > > is_bad = .depends ~ /ruby2.7/ & !.depends ~ /ruby3.0/;
> > > > > 
> > > > > We already did a mass rebuild some time ago, and the results don't 
> > > > > look
> > > > > bad. We should be doing a new one soon, and will come up with a list 
> > > > > of
> > > > > binNMUs
> > > > 
> > > > This is a friendly ping. We would like to make the switch in unstable
> > > > soon and start doing binNMUs.
> > > > 
> > > > We have these bugs related to this transition:
> > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ruby3.0;users=debian-r...@lists.debian.org
> > > > 
> > > > Most of those bugs are for leaf libraries. We already started fixing the
> > > > ones that block a lof of other (e.g. the ones with C extensions that
> > > > FTBFS with ruby3.0) so they are ready to be binNMUed.
> > > 
> > > ruby3.0 isn't in testing yet - it currently fails to build on ppc64el.
> > > So let's at least wait until it migrated.
> > 
> > ruby3.0 is now in testing. Can we go ahead with this?
> 
> Yes, please go ahead

Thanks, we will upload ruby-defaults shortly.

Note that we do not necessarily want/need to block involved packages
from migrating, as adding ruby3.0 support does not break anything since
the default is still unchanged.


signature.asc
Description: PGP signature

Bug#998064: sm: fails to display text containing letter 'e' due to errors in libfreetype after upgrade

[Dirk Eddelbuettel]

On 29 October 2021 at 18:14, Paul Wise wrote:
| Package: sm, libfreetype6
| Version: 0.26-1, 2.11.0+dfsg-1
| Severity: important
| File: /usr/games/sm
| Usertags: regression

Maintainer of _source package_ sm here: bad habit, 15 years ago binary
packages like r-cran-sm used their upstream source name as their Debian
source name.  You wanted _source package_ screen-message for binary package
sm.

Dirk

| 
| Not sure if this issue is a bug in sm or freetype, please reassign.
| 
| Since the upgrade of freetype from 2.10.4+dfsg-1 to 2.11.0+dfsg-1,
| whenever I attempt to display a string in sm containing letter e,
| either via the command-line or by typing it into the text input,
| the entire string does not display, I get errors in the terminal
| and I cannot type any more input except for pressing Esc twice.
| 
|$ sm e
|(sm:2529177): Gtk-WARNING **: 13:23:34.553: drawing failure for widget 
'GtkDrawingArea': error occurred in libfreetype
|
|(sm:2529177): Gtk-WARNING **: 13:23:34.574: drawing failure for widget 
'GtkBox': error occurred in libfreetype
|
|(sm:2529177): Gtk-WARNING **: 13:23:34.574: drawing failure for widget 
'GtkWindow': error occurred in libfreetype
| 
| The problem stops happening if I downgrade freetype to 2.10.4+dfsg-1.
| 
| The problem happens with some fonts but not every single font.
| 
| The problem happens for rotating 180° or 360° but not 90° or 270°.
| 
| The problem happens with "e" "ea" "eaa" "eaaa" but not "e".
| 
| The problem happens for me with GNOME Wayland and if I force X11.
| 
| The problem only happens with my existing user account, not a new one.
| 
| The problem still happens if I delete my fontconfig cache files.
| 
| Folks on IRC say this does not happen in X11 KDE/MATE/Xfce/openbox/dwm
| and Wayland/X11 GNOME. One person found it does happen in X11 LXQt.
| 
| When I compare the ltrace output, when the issue occurs, the function
| pango_cairo_show_layout returns 40 while it returns 0 otherwise.
| 
| I tried recompiling freetype with support for the FT2_DEBUG environment
| variable but I can't find the error in the log output.
| 
| -- System Information:
| Debian Release: bookworm/sid
|   APT prefers testing-debug
|   APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
| Architecture: amd64 (x86_64)
| 
| Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
| Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
| Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
| Shell: /bin/sh linked to /bin/dash
| Init: systemd (via /run/systemd/system)
| LSM: AppArmor: enabled
| 
| Versions of packages sm depends on:
| ii  libc62.32-4
| ii  libcairo21.16.0-5
| ii  libglib2.0-0 2.70.0-1+b1
| ii  libgtk-3-0   3.24.30-3
| ii  libpango-1.0-0   1.48.10+ds1-1
| ii  libpangocairo-1.0-0  1.48.10+ds1-1
| 
| sm recommends no packages.
| 
| sm suggests no packages.
| 
| -- no debconf information
| 
| Versions of packages libfreetype6 depends on:
| ii  libbrotli1   1.0.9-2+b2
| ii  libc62.32-4
| ii  libpng16-16  1.6.37-3
| ii  zlib1g   1:1.2.11.dfsg-2
| 
| libfreetype6 recommends no packages.
| 
| libfreetype6 suggests no packages.
| 
| -- no debconf information
| 
| -- 
| bye,
| pabs
| 
| https://wiki.debian.org/PaulWise
| 
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#998062: Please change default dbus implementation to dbus-broker

[Luca Boccassi]

retitle -1 Allow using dbus-broker if the user installed it

On Fri, 2021-10-29 at 12:11 +0200, Michael Biebl wrote:
> Package: at-spi2-core
> Version: 2.42.0-1
> Severity: wishlist
> Tags: patch
> X-Debbugs-Cc: bl...@debian.org, s...@debian.org
> 
> Hi,
> 
> I currently have dbus-broker installed and enabled:
> 
> michael@pluto:~$ apt-cache policy dbus-broker
> dbus-broker:
>   Installed: 29-2
>   Candidate: 29-2
>   Version table:
>  *** 29-2 500
> 500 http://ftp.debian.org/debian sid/main amd64 Packages
> 100 /var/lib/dpkg/status
> michael@pluto:~$ systemctl status dbus.service
> * dbus-broker.service - D-Bus System Message Bus
>  Loaded: loaded (/lib/systemd/system/dbus-broker.service; enabled; vendor 
> preset: enabled)
>  Active: active (running) since Fri 2021-10-29 10:58:51 CEST; 13min ago
> TriggeredBy: * dbus.socket
>    Docs: man:dbus-broker-launch(1)
>    Main PID: 591 (dbus-broker-lau)
>   Tasks: 2 (limit: 19028)
>  Memory: 5.8M
> CPU: 622ms
>  CGroup: /system.slice/dbus-broker.service
>  |-591 /usr/bin/dbus-broker-launch --scope system --audit
>  `-596 dbus-broker --log 4 --controller 9 --machine-id 
> 567a68a5c2672114bcf5192d0008 --max-bytes 536870912 --max-fds >
> 
> Oct 29 10:58:51 pluto systemd[1]: Starting D-Bus System Message Bus...
> Oct 29 10:58:51 pluto systemd[1]: Started D-Bus System Message Bus.
> Oct 29 10:58:51 pluto dbus-broker-launch[591]: AppArmor enabled, but not 
> supported. Ignoring.
> Oct 29 10:58:51 pluto dbus-broker-lau[591]: Ready
> 
> 
> 
> Yet, I still see that at-spi2-core launches a dbus-daemon instance
> itself:
> 
> michael@pluto:~$ ps aux | grep dbus
> message+ 591  0.0  0.0   9744  4232 ?Ss   10:58   0:00 
> /usr/bin/dbus-broker-launch --scope system --audit
> message+ 596  0.0  0.0   6988  4468 ?S10:58   0:00 
> dbus-broker --log 4 --controller 9 --machine-id 
> 567a68a5c2672114bcf5192d0008 --max-bytes 536870912 --max-fds 4096 
> --max-matches 131072 --audit
> michael 1643  0.0  0.0   9540  3804 ?Ss   10:59   0:00 
> /usr/bin/dbus-broker-launch --scope user
> michael 1711  0.0  0.0   7080  4616 ?S10:59   0:00 
> dbus-broker --log 4 --controller 10 --machine-id 
> 567a68a5c2672114bcf5192d0008 --max-bytes 100 --max-fds 
> 25 --max-matches 50
> michael 2062  0.0  0.0   8024  4256 ?S10:59   0:00 
> /usr/bin/dbus-daemon 
> --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork 
> --print-address 3
> 
> 
> This can be fixed by building at-spi2-core with
> -Ddefault_bus=dbus-broker
> This way, bus/at-spi-bus-launcher.c will first try to use dbus-broker
> and if not available fall back to dbus-daemon.
> 
> I rebuilt the package with the attached patch and applied and
> successfully tested
> - dbus-broker installed: → dbus-broker is used
> - dbus-broker not installed → dbus-daemon is used
> 
> I've CCed Simon and Luca as maintainers of dbus and dbus-broker, in case
> they have some input on this matter.
> 
> 
> Regards,
> Michael

Nice find, and for reference the fallback is here:

https://sources.debian.org/src/at-spi2-core/2.42.0-1/bus/at-spi-bus-launcher.c/?hl=405#L489

So given the default implementation is dbus-daemon it should be indeed
safe to try first dbus-broker, and fallback to dbus-daemon if not
installed.

I have taken the liberty to retitle slightly, to ensure it's clear that
the request is not to force to change to dbus-broker, but simply to
allow it to be used if the user chose it for their system.

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#998069: openssh-server: sshd_config(5) documentation of ListenAddress refers to OpenBSD only option "rdomain"

[Bjørn Mork]

Package: openssh-server
Version: 1:8.4p1-5
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The sshd_config(5) manual page refers to an optional "[rdomain domain]"
qualifier for ListenAddress, with a pointer to the non-existing
rdomain(4) manual page for further informaion.

This is leaking OpenBSD only features and should be removed from any
Linux build.  See https://bugzilla.mindrot.org/show_bug.cgi?id=3126
for more information


Bjørn

- -- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (700, 'stable-security'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  libaudit1  1:3.0-2
ii  libc6  2.31-13+deb11u2
ii  libcom-err21.46.2-2
ii  libcrypt1  1:4.4.18-4
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
ii  libkrb5-3  1.18.3-6+deb11u1
ii  libpam-modules 1.4.0-9+deb11u1
ii  libpam-runtime 1.4.0-9+deb11u1
ii  libpam0g   1.4.0-9+deb11u1
ii  libselinux13.1-3
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libsystemd0247.3-6
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0
ii  openssh-client 1:8.4p1-5
ii  openssh-sftp-server1:8.4p1-5
ii  procps 2:3.3.17-5
ii  runit-helper   2.10.3
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  247.3-6
ii  ncurses-term 6.2+20201114-2
ii  xauth1:1.1-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

- -- debconf information:
  openssh-server/password-authentication: true
  openssh-server/permit-root-login: false

-BEGIN PGP SIGNATURE-

iIQEARYKACwWIQRoe+CASfFh7aZ6shIiBE7Lv6RhXQUCYXvilw4cYmpvcm5AbW9y
ay5ubwAKCRAiBE7Lv6RhXQHBAP0Yq4s3PrY+kYCZ23zGXcvRudCWprq1XVDTgHyH
LpbxYgEAgmAATmPssszolOQW9SscIujGWFkye7ZhjS+zuSN2GQo=
=gfU+
-END PGP SIGNATURE-

Bug#905350: libvirt-daemon: LXC Memory limit dosent work

[Alexis Huxley]

Package: libvirt-daemon
Version: 5.0.0-4+deb10u1
Followup-For: Bug #905350

Dear Maintainer,

Markus is quite right regarding this bug and it is documented at
https://discuss.linuxcontainers.org/t/memory-limits-no-longer-being-applied/7429

However, I recently upgraded to Debian 11 and the bug is no
longer present.

Hope that helps you Markus!

Alexis

Bug#998068: debconf values not populated on initial install (like debootstrap) since 1.5.78

[Stephan Sürken]

Package: debconf
Version: 1.5.78
Severity: important

Dear Maintainer,

on initial install (for example via deboostrap), debconf values are not 
populated, i.e.,

debconf-show debconf

is empty.

Maybe due to fix for #989567, which seems to actually remove postinst
for good w/o actually producing debhelper's default postinst?

Thx!

Stephan

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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages debconf depends on:
ii  perl-base  5.32.1-6

Versions of packages debconf recommends:
ii  apt-utils 2.3.11
ii  debconf-i18n  1.5.78

Versions of packages debconf suggests:
ii  debconf-doc1.5.78
pn  debconf-kde-helper 
pn  debconf-utils  
pn  libgtk3-perl   
pn  libnet-ldap-perl   
pn  libterm-readline-gnu-perl  
ii  perl   5.32.1-6
ii  whiptail   0.52.21-5

-- debconf information excluded

Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus

[Simon McVittie]

On Fri, 29 Oct 2021 at 12:40:34 +0200, Adam Borowski wrote:
> On Fri, Oct 29, 2021 at 11:12:03AM +0100, Simon McVittie wrote:
> > * dbus, the portable reference implementation
> > * dbus-broker, a Linux-specific reimplementation
> > 
> > so it seems like a good time to introduce {default-,}dbus-system-bus
> > virtual packages, mirroring {default-,}dbus-session-bus.
> 
> > * default-dbus-system-bus | dbus-system-bus:
> >   the well-known system bus, as required by e.g. Avahi, polkit, udisks2
> 
> I wonder, perhaps it would be better to hijack the name "dbus", renaming
> the current bin:dbus package?  That'd allow avoid changing around a hundred
> packages.

"Depends: dbus" implies all the functionality of what's now referred
to as dbus-system-bus, dbus-bin and dbus-daemon, which is a strict superset
of what I am proposing that dbus-system-bus implies. Packages with
Depends: dbus have always been able to assume that they can run dbus-send,
or dbus-run-session, or dbus-daemon, among other executable entry points,
but dbus-system-bus does not guarantee that functionality.

We should not require reimplementations like dbus-broker to provide
(or more likely, depend on) dbus-daemon(1), dbus-send(1) and all the
other executables that "Depends: dbus" has historically given you.

This is not a "hard" transition, and I don't think changing those packages
will ever need to be RC: dbus-broker and dbus can coexist (dbus-broker
will "win" in this case), so the worst-case scenario is that an excessive
dependency wastes some disk space.

Some of the packages that depend on dbus could benefit from some review
anyway, because some of them seem to be GUI applications for which
the dbus package is neither necessary nor sufficient: packages like
rhythmbox and evolution probably don't strictly need the system bus, but
probably *do* need the well-known session bus (represented by
default-dbus-session-bus | dbus-session-bus, as implemented by
dbus-user-session | dbus-launch) which is not implied by dbus.

smcv

Bug#998067: transition: libsepol and libsemanage

[Laurent Bigonville]

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

Hello,

libsepol and libsemanage have both bumped their soname from 1 to 2, the
packages already went through the NEW queue and are in experimental.

The transition trackers are already created:

https://release.debian.org/transitions/html/auto-libsepol.html
https://release.debian.org/transitions/html/auto-libsemanage.html

Most of the packages are from the same upstream.

For libsemanage, sssd and shadow will have to adjust their build-dependencies

For libsepol, dmraid must remove the build-dependency, this is useless,
see #929484. Note that dmraid already has a RC bug, for other reasons.

Kind regards,
Laurent Bigonville

Bug#996387: FTBFS - also with ruby 2.7.4

[Sven Mueller]

Hi.

I get the same "rpc/rpc.h" error while rebuilding against (at least
essentially) debian-testing and ruby 2.7.4.


gcc -fdebug-prefix-map=/<>=. -I.
-I/usr/include/x86_64-linux-gnu/ruby-2.7.0
-I/usr/include/ruby-2.7.0/ruby/backward -I/usr/include/ruby-2.7.0 -I.
-Wdate-time -D_FORTIFY_SOURCE=2   -I../../include -I../../src/os/linux
-U_FILE_OFFSET_BITS -DRB_HAS_RE_ERROR -DRB_RUBY_19 -fPIC -g -O2
-ffile-prefix-map=/build/ruby2.7-5goTBM/ruby2.7-2.7.4=.
-fstack-protector-strong -Wformat -Werror=format-security -fPIC  -o
sigar_util.o -c sigar_util.c
sigar_util.c: In function ‘sigar_proc_list_procfs_get’:
sigar_util.c:167:5: warning: ‘readdir_r’ is deprecated
[-Wdeprecated-declarations]
  167 | while (readdir_r(dirp, , ) == 0) {
  | ^
In file included from sigar_util.c:31:
/usr/include/dirent.h:183:12: note: declared here
  183 | extern int readdir_r (DIR *__restrict __dirp,
  |^
sigar_util.c: In function ‘sigar_proc_fd_count’:
sigar_util.c:210:5: warning: ‘readdir_r’ is deprecated
[-Wdeprecated-declarations]
  210 | while (readdir_r(dirp, , ) == 0) {
  | ^
In file included from sigar_util.c:31:
/usr/include/dirent.h:183:12: note: declared here
  183 | extern int readdir_r (DIR *__restrict __dirp,
  |^
sigar_util.c: At top level:
sigar_util.c:742:10: fatal error: rpc/rpc.h: No such file or directory
  742 | #include 
  |  ^~~
compilation terminated.
make[1]: *** [Makefile:245: sigar_util.o] Error 1

+--+
| Build environment
   |
+--+

Kernel: Linux 5.10.40-1-amd64 #1 SMP Debian 5.10.40-1 (2021-06-22) amd64
(x86_64)
Toolchain package versions: binutils_2.37-7 dpkg-dev_1.20.9
g++-10_10.3.0-11 gcc-10_10.3.0-11 libc6-dev_2.32-4
libstdc++-10-dev_10.3.0-11 libstdc++6_11.2.0-9 linux-libc-dev_5.10.46-5
Package versions: adduser_3.118 apt_2.3.11 autoconf_2.71-2
automake_1:1.16.4-2 autopoint_0.21-4 autotools-dev_20180224.1+nmu1
base-files_12 base-passwd_3.5.52 bash_5.1-3 binutils_2.37-7
binutils-common_2.37-7 binutils-x86-64-linux-gnu_2.37-7
bsdextrautils_2.37.2-3 bsdutils_1:2.37.2-3 build-essential_12.9
bzip2_1.0.8-4 ca-certificates_20210119 coreutils_8.32-4 cpp_4:10.2.1-1
cpp-10_10.3.0-11 dash_0.5.11+git20210120+802ebd4-1 debconf_1.5.77
debhelper_13.5.2 debian-archive-keyring_2021.1.1 debianutils_4.11.2
devscripts_2.21.4 dh-autoreconf_20 dh-strip-nondeterminism_1.12.0-2
diffutils_1:3.7-5 dirmngr_2.2.27-2 dpkg_1.20.9 dpkg-dev_1.20.9 dwz_0.14-1
e2fsprogs_1.46.4-1 eatmydata_130-2 fakeroot_1.25.3-1.1 file_1:5.39-3
findutils_4.8.0-1 g++_4:10.2.1-1 g++-10_10.3.0-11 gcc_4:10.2.1-1
gcc-10_10.3.0-11 gcc-10-base_10.3.0-11 gcc-11-base_11.2.0-9
gcc-8-base_8.4.0-7+build1 gcc-9-base_9.4.0-2 gem2deb_1.6
gem2deb-test-runner_1.6 gettext_0.21-4 gettext-base_0.21-4 gnupg_2.2.27-2
gnupg-l10n_2.2.27-2 gnupg-utils_2.2.27-2 goobuntu-base_29 gpg_2.2.27-2
gpg-agent_2.2.27-2 gpg-wks-client_2.2.27-2 gpg-wks-server_2.2.27-2
gpgconf_2.2.27-2 gpgsm_2.2.27-2 gpgv_2.2.27-2 grep_3.7-1
groff-base_1.22.4-7 gzip_1.10-4 hostname_3.23 init-system-helpers_1.60
intltool-debian_0.35.0+20060710.5 libacl1_2.3.1-1 libapt-pkg6.0_2.3.11
libarchive-zip-perl_1.68-1 libasan6_11.2.0-9 libassuan0_2.5.5-1
libatomic1_11.2.0-9 libattr1_1:2.5.1-1 libaudit-common_1:3.0.6-1
libaudit1_1:3.0.6-1 libb-hooks-op-check-perl_0.22-1 libbinutils_2.37-7
libblkid1_2.37.2-3 libboost-filesystem1.74.0_1.74.0-9
libboost-iostreams1.74.0_1.74.0-9 libboost-program-options1.74.0_1.74.0-9
libbsd0_0.11.3-1 libbz2-1.0_1.0.8-4 libc-bin_2.32-4 libc-dev-bin_2.32-4
libc6_2.32-4 libc6-dev_2.32-4 libcap-ng0_0.7.9-2.2 libcap2_1:2.44-1
libcc1-0_11.2.0-9 libclass-method-modifiers-perl_2.13-1
libcom-err2_1.46.4-1 libcrypt-dev_1:4.4.25-2 libcrypt1_1:4.4.25-2
libctf-nobfd0_2.37-7 libctf0_2.37-7 libdb5.3_5.3.28+dfsg1-0.8
libdebconfclient0_0.260 libdebhelper-perl_13.5.2
libdevel-callchecker-perl_0.008-1 libdpkg-perl_1.20.9
libdynaloader-functions-perl_0.003-1.1 libeatmydata1_130-2
libedit2_3.1-20210910-1 libelf1_0.185-2 libencode-locale-perl_1.05-1.1
libexpat1_2.4.1-2 libext2fs2_1.46.4-1 libfakeroot_1.25.3-1.1
libffi8_3.4.2-2 libfile-dirlist-perl_0.05-2 libfile-homedir-perl_1.006-1
libfile-listing-perl_6.14-1 libfile-stripnondeterminism-perl_1.12.0-2
libfile-touch-perl_0.12-1 libfile-which-perl_1.23-1 libgcc-10-dev_10.3.0-11
libgcc-s1_11.2.0-9 libgcrypt20_1.9.4-3 libgdbm-compat4_1.22-1
libgdbm6_1.22-1 libgmp-dev_2:6.2.1+dfsg-2 libgmp10_2:6.2.1+dfsg-2
libgmpxx4ldbl_2:6.2.1+dfsg-2 libgnutls30_3.7.2-2 libgomp1_11.2.0-9
libgpg-error0_1.42-3 libgssapi-krb5-2_1.18.3-7 libhogweed6_3.7.3-1
libhtml-parser-perl_3.76-1 libhtml-tagset-perl_3.20-4
libhtml-tree-perl_5.07-2 libhttp-cookies-perl_6.10-1
libhttp-date-perl_6.05-1 libhttp-message-perl_6.33-1
libhttp-negotiate-perl_6.01-1 libicu67_67.1-7 libidn2-0_2.3.2-2
libimport-into-perl_1.002005-1 libio-html-perl_1.004-2

Bug#720096: rsyslog ignores rotated log file

[Grueninger, Tobias]

Reason is probably that rsyslog is started with NONE pid-file

/lib/system/system/rsyslog.service
ExecStart=/usr/sbin/rsyslogd -n -iNONE

While most postrotate snippets in /etc/logrotate.d/* may expect that rsyslog 
uses a pid file like the init.d script suggests:
/etc/init.d/rsyslog
PIDFILE=/run/rsyslogd.pid
The root cause then is that logrotate can rotate away logfiles but is not able 
to send a SIGHUP to rsyslog that it must use a new file handle
Regards
Tobias

Bug#996814: Missing import and export in Kaddressbook

[Rico Rommel]

Hi,

I think, package kdepim-addons needs libkpimaddressbookimportexport-dev as 
build-dependency.

quote from kdepim-addons-21.08.1/kaddressbook/CMakeLists.txt:

add_subdirectory( editorpages )
add_subdirectory( plugins )
if (KPimAddressbookImportExport_FOUND)
add_subdirectory( importexportplugins )
else()
MESSAGE(STATUS "You need to build kaddressbook first and add install 
it on distro before building kdepim-addons. Otherwise import/export will be 
missing in kaddressbook")   
endif() 

I think, package kdepim-addons needs libkpimaddressbookimportexport-dev as 
build-dependency

Rico

Bug#998066: Request for removal of the "Download Package" button in Gdebi UI

[Abhishek Deshpande]

Package: gdebi
Version: 0.9.5.7+nmu5


Gdebi shows a "Download Package" button when we try to install a package
that is already available in some repository added in the system.
It seems that this button does nothing in current versions of Gdebi, and
therefore can be removed from it. The use of this button was not documented
anywhere.
Also, if it is a feature, it seems probably broken.

So, I would suggest to remove this button and underlying broken code.

Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus

[Adam Borowski]

On Fri, Oct 29, 2021 at 11:12:03AM +0100, Simon McVittie wrote:
> * dbus, the portable reference implementation
> * dbus-broker, a Linux-specific reimplementation
> 
> so it seems like a good time to introduce {default-,}dbus-system-bus
> virtual packages, mirroring {default-,}dbus-session-bus.

> * default-dbus-system-bus | dbus-system-bus:
>   the well-known system bus, as required by e.g. Avahi, polkit, udisks2

I wonder, perhaps it would be better to hijack the name "dbus", renaming
the current bin:dbus package?  That'd allow avoid changing around a hundred
packages.


-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄ the maternity ward.

Bug#998065: freetype2-doc: restore donations by using a button instead of an image

[Paul Wise]

Package: freetype2-doc
Version: 2.11.0+dfsg-1
Severity: wishlist
Tags: patch

The lintian privacy tags are not meant to hide donations information
from the documentation. I suggest replacing the existing patch that
hides the donation information with the attached patch that replaces
the donations image with a simple submit button with the text Donate.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
Description: Use a button for donations instead of an image.
Author: Paul Wise
Bug-Debian: https://bugs.debian.org/873432
--- a/ft2docs/docs/design/design-1.html
+++ b/ft2docs/docs/design/design-1.html
@@ -169,8 +169,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/design/design-2.html
+++ b/ft2docs/docs/design/design-2.html
@@ -224,8 +224,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/design/design-3.html
+++ b/ft2docs/docs/design/design-3.html
@@ -376,8 +376,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/design/design-4.html
+++ b/ft2docs/docs/design/design-4.html
@@ -338,8 +338,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/design/design-5.html
+++ b/ft2docs/docs/design/design-5.html
@@ -480,8 +480,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/design/design-6.html
+++ b/ft2docs/docs/design/design-6.html
@@ -346,8 +346,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/design/index.html
+++ b/ft2docs/docs/design/index.html
@@ -171,8 +171,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/documentation.html
+++ b/ft2docs/docs/documentation.html
@@ -117,8 +117,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/ft2faq.html
+++ b/ft2docs/docs/ft2faq.html
@@ -626,8 +626,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/glyphs/glyphs-1.html
+++ b/ft2docs/docs/glyphs/glyphs-1.html
@@ -204,8 +204,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/glyphs/glyphs-2.html
+++ b/ft2docs/docs/glyphs/glyphs-2.html
@@ -412,8 +412,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/glyphs/glyphs-3.html
+++ b/ft2docs/docs/glyphs/glyphs-3.html
@@ -461,8 +461,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/glyphs/glyphs-4.html
+++ b/ft2docs/docs/glyphs/glyphs-4.html
@@ -216,8 +216,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/glyphs/glyphs-5.html
+++ b/ft2docs/docs/glyphs/glyphs-5.html
@@ -384,8 +384,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/glyphs/glyphs-6.html
+++ b/ft2docs/docs/glyphs/glyphs-6.html
@@ -468,8 +468,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/glyphs/glyphs-7.html
+++ b/ft2docs/docs/glyphs/glyphs-7.html
@@ -366,8 +366,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/glyphs/index.html
+++ b/ft2docs/docs/glyphs/index.html
@@ -221,8 +221,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/index.html
+++ b/ft2docs/docs/index.html
@@ -273,8 +273,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/tutorial/index.html
+++ b/ft2docs/docs/tutorial/index.html
@@ -159,8 +159,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/tutorial/step1.html
+++ b/ft2docs/docs/tutorial/step1.html
@@ -1035,8 +1035,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/tutorial/step2.html
+++ b/ft2docs/docs/tutorial/step2.html
@@ -1551,8 +1551,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   
--- a/ft2docs/docs/tutorial/step3.html
+++ b/ft2docs/docs/tutorial/step3.html
@@ -130,8 +130,8 @@
 
-https://www.paypalobjects.com/en_US/i/btn/btn_donateCC_LG.gif;
+
   


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

Bug#998064: sm: fails to display text containing letter 'e' due to errors in libfreetype after upgrade

[Paul Wise]

Package: sm, libfreetype6
Version: 0.26-1, 2.11.0+dfsg-1
Severity: important
File: /usr/games/sm
Usertags: regression

Not sure if this issue is a bug in sm or freetype, please reassign.

Since the upgrade of freetype from 2.10.4+dfsg-1 to 2.11.0+dfsg-1,
whenever I attempt to display a string in sm containing letter e,
either via the command-line or by typing it into the text input,
the entire string does not display, I get errors in the terminal
and I cannot type any more input except for pressing Esc twice.

   $ sm e
   (sm:2529177): Gtk-WARNING **: 13:23:34.553: drawing failure for widget 
'GtkDrawingArea': error occurred in libfreetype
   
   (sm:2529177): Gtk-WARNING **: 13:23:34.574: drawing failure for widget 
'GtkBox': error occurred in libfreetype
   
   (sm:2529177): Gtk-WARNING **: 13:23:34.574: drawing failure for widget 
'GtkWindow': error occurred in libfreetype

The problem stops happening if I downgrade freetype to 2.10.4+dfsg-1.

The problem happens with some fonts but not every single font.

The problem happens for rotating 180° or 360° but not 90° or 270°.

The problem happens with "e" "ea" "eaa" "eaaa" but not "e".

The problem happens for me with GNOME Wayland and if I force X11.

The problem only happens with my existing user account, not a new one.

The problem still happens if I delete my fontconfig cache files.

Folks on IRC say this does not happen in X11 KDE/MATE/Xfce/openbox/dwm
and Wayland/X11 GNOME. One person found it does happen in X11 LXQt.

When I compare the ltrace output, when the issue occurs, the function
pango_cairo_show_layout returns 40 while it returns 0 otherwise.

I tried recompiling freetype with support for the FT2_DEBUG environment
variable but I can't find the error in the log output.

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

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

Versions of packages sm depends on:
ii  libc62.32-4
ii  libcairo21.16.0-5
ii  libglib2.0-0 2.70.0-1+b1
ii  libgtk-3-0   3.24.30-3
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1

sm recommends no packages.

sm suggests no packages.

-- no debconf information

Versions of packages libfreetype6 depends on:
ii  libbrotli1   1.0.9-2+b2
ii  libc62.32-4
ii  libpng16-16  1.6.37-3
ii  zlib1g   1:1.2.11.dfsg-2

libfreetype6 recommends no packages.

libfreetype6 suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#998062: Please change default dbus implementation to dbus-broker

[Michael Biebl]

Package: at-spi2-core
Version: 2.42.0-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: bl...@debian.org, s...@debian.org

Hi,

I currently have dbus-broker installed and enabled:

michael@pluto:~$ apt-cache policy dbus-broker
dbus-broker:
  Installed: 29-2
  Candidate: 29-2
  Version table:
 *** 29-2 500
500 http://ftp.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
michael@pluto:~$ systemctl status dbus.service
* dbus-broker.service - D-Bus System Message Bus
 Loaded: loaded (/lib/systemd/system/dbus-broker.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Fri 2021-10-29 10:58:51 CEST; 13min ago
TriggeredBy: * dbus.socket
   Docs: man:dbus-broker-launch(1)
   Main PID: 591 (dbus-broker-lau)
  Tasks: 2 (limit: 19028)
 Memory: 5.8M
CPU: 622ms
 CGroup: /system.slice/dbus-broker.service
 |-591 /usr/bin/dbus-broker-launch --scope system --audit
 `-596 dbus-broker --log 4 --controller 9 --machine-id 
567a68a5c2672114bcf5192d0008 --max-bytes 536870912 --max-fds >

Oct 29 10:58:51 pluto systemd[1]: Starting D-Bus System Message Bus...
Oct 29 10:58:51 pluto systemd[1]: Started D-Bus System Message Bus.
Oct 29 10:58:51 pluto dbus-broker-launch[591]: AppArmor enabled, but not 
supported. Ignoring.
Oct 29 10:58:51 pluto dbus-broker-lau[591]: Ready



Yet, I still see that at-spi2-core launches a dbus-daemon instance
itself:

michael@pluto:~$ ps aux | grep dbus
message+ 591  0.0  0.0   9744  4232 ?Ss   10:58   0:00 
/usr/bin/dbus-broker-launch --scope system --audit
message+ 596  0.0  0.0   6988  4468 ?S10:58   0:00 dbus-broker 
--log 4 --controller 9 --machine-id 567a68a5c2672114bcf5192d0008 
--max-bytes 536870912 --max-fds 4096 --max-matches 131072 --audit
michael 1643  0.0  0.0   9540  3804 ?Ss   10:59   0:00 
/usr/bin/dbus-broker-launch --scope user
michael 1711  0.0  0.0   7080  4616 ?S10:59   0:00 dbus-broker 
--log 4 --controller 10 --machine-id 567a68a5c2672114bcf5192d0008 
--max-bytes 100 --max-fds 25 --max-matches 50
michael 2062  0.0  0.0   8024  4256 ?S10:59   0:00 
/usr/bin/dbus-daemon 
--config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork 
--print-address 3


This can be fixed by building at-spi2-core with
-Ddefault_bus=dbus-broker
This way, bus/at-spi-bus-launcher.c will first try to use dbus-broker
and if not available fall back to dbus-daemon.

I rebuilt the package with the attached patch and applied and
successfully tested
- dbus-broker installed: → dbus-broker is used
- dbus-broker not installed → dbus-daemon is used

I've CCed Simon and Luca as maintainers of dbus and dbus-broker, in case
they have some input on this matter.


Regards,
Michael



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

Kernel: Linux 5.14.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages at-spi2-core depends on:
ii  libatspi2.0-0  2.42.0-1
ii  libc6  2.32-4
ii  libdbus-1-31.12.20-3
ii  libglib2.0-0   2.70.0-3
ii  libsystemd0249.5-1
ii  libx11-6   2:1.7.2-2+b1
ii  libxtst6   2:1.2.3-1

at-spi2-core recommends no packages.

at-spi2-core suggests no packages.

-- no debconf information
diff -Nru at-spi2-core-2.42.0/debian/rules at-spi2-core-2.42.0/debian/rules
--- at-spi2-core-2.42.0/debian/rules2021-09-19 01:23:16.0 +0200
+++ at-spi2-core-2.42.0/debian/rules2021-10-29 11:05:43.0 +0200
@@ -7,8 +7,10 @@
 
 override_dh_auto_configure:
ac_cv_lib_ICE_IceConnectionNumber=no \
-   dh_auto_configure -- -Dintrospection=yes \
-   -Ddocs=true
+   dh_auto_configure -- \
+   -Dintrospection=yes \
+   -Ddocs=true \
+   -Ddefault_bus=dbus-broker
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))

Bug#998039: ITP: makedeb -- The modern packaging tool for Debian archives.

[Guillem Jover]

Hi!

On Thu, 2021-10-28 at 15:02:19 -0700, Leo Puvilland wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Leo Puvilland 
> 
> * Package name: makedeb
>   Version : 7.1.2+bugfix1
>   Upstream Author : Hunter Wittenborn 
> * URL : https://makedeb.hunterwittenborn.com
> * License : GPLv2
>   Programming Lang: Bash
>   Description : The modern packaging tool for Debian archives.

Hmm, I think I take issue with this description. :)

While I can agree there's much that can be changed in dpkg and
related tooling such as debhelper to improve packaging workflows and
make this a more integrated and easy thing to approach for new people,
I'm not seeing how makedeb is neither "The" nor "modern" tool for
this. I feel it suffers from pretty much the same problems as fpm
(see  or
).

> makedeb is a packaging tool for Debian-based systems that aims to be
> simple and easy to use, whilst still remaining just as powerful as
> standard Debian tooling.

I'm afraid, simple here implies potentially incorrect (see the comments
on the links about ignoring dependency information from shlibs/symbols
files f.ex), checking the upstream repo I see dependencies are being
hardcoded, which seem even worse than I'd expect. This also implies much
of the current automatic handling found in, say, debhelper and related
tools is skipped, which does not look would make it easier to generate
properly integrated packages.

> makedeb uses a packaging format that's aiming to be simpler and easier
> to get a hold of than standard Debian packaging, so adding this
> program would help more users begin packaging for Debian.

I think this makes the packaging experience even more confusing, as
these people might still need to have to deal with proper Debian
packaging anyway.

Thanks,
Guillem

Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus

[Simon McVittie]

Package: debian-policy
Version: 4.6.0.1
Severity: wishlist

We now have two implementations of the D-Bus well-known system bus
available in Debian:

* dbus, the portable reference implementation
* dbus-broker, a Linux-specific reimplementation

so it seems like a good time to introduce {default-,}dbus-system-bus
virtual packages, mirroring {default-,}dbus-session-bus.

At the moment, dbus is the default for all architectures. It is possible
that dbus-broker might take over as the default on Linux architectures
in some future release (but it is explicitly not portable, so dbus will
probably always be the default on kFreeBSD and Hurd, similar to how we
choose dbus-user-session vs. dbus-launch).

Packages depending on "dbus" can currently count on having most aspects of
the reference implementation available (except for the session bus, which
requires either dbus-user-session or dbus-launch), but I would prefer to
move towards packages explicitly declaring a dependency on one or more of:

* default-dbus-system-bus | dbus-system-bus:
  the well-known system bus, as required by e.g. Avahi, polkit, udisks2
* dbus-daemon: ability to run the dbus-daemon(1) and dbus-run-session(1)
  executables, or rely on having the D-Bus machine ID /var/lib/dbus/machine-id
  (dbus-session-bus and dbus-system-bus both imply some sort of machine
  ID, but it might be systemd's /etc/machine-id)
* dbus-bin: ability to run assorted CLI tools such as dbus-send(1) and
  dbus-monitor(1)

Proposed wording attached.

Thanks,
smcv
>From cc65839b65e9a41ca0e9e633ac32a085cec66fa2 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 29 Oct 2021 10:58:13 +0100
Subject: [PATCH] virtual-package-names-list: Add dbus-system-bus,
 default-dbus-system-bus

This is the same as dbus-session-bus, but for the well-known system bus
described in the D-Bus Specification[1].

dbus, the reference implementation of D-Bus, Provides these since
bullseye. dbus-broker, an independent reimplementation, also Provides
dbus-system-bus in unstable.

The mention of "including service activation" is intended to make it
clearer that some implementation of /usr/share/dbus-1/system-services/
activation is required, for example via dbus' setuid helper and
conditional handoff to systemd, or dbus-broker's unconditional handoff
to systemd.

[1] https://dbus.freedesktop.org/doc/dbus-specification.html

Signed-off-by: Simon McVittie 
---
 virtual-package-names-list.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/virtual-package-names-list.yaml b/virtual-package-names-list.yaml
index 2a9857a..eb5ace2 100644
--- a/virtual-package-names-list.yaml
+++ b/virtual-package-names-list.yaml
@@ -118,6 +118,10 @@ virtualPackages:
description: provides the D-Bus well-known session bus for most or all user login sessions
  - name: default-dbus-session-bus
description: Debian's preferred implementation of dbus-session-bus, possibly architecture-specific
+ - name: dbus-system-bus
+   description: provides the D-Bus well-known system bus as a system service, including service activation
+ - name: default-dbus-system-bus
+   description: Debian's preferred implementation of dbus-system-bus, possibly architecture-specific
  - name: logind
description: an org.freedesktop.login1 D-Bus API implementation (versioned)
  - name: default-logind
-- 
2.33.1

Bug#994008: debian-policy: Clarify relationship between source and binary packages' archive areas

[Simon McVittie]

On Thu, 09 Sep 2021 at 21:15:06 +0200, Ansgar wrote:
> On Thu, 2021-09-09 at 17:39 +0100, Simon McVittie wrote:
> > In the form of a table, the allowed source/binary combinations are:
> > 
> >   |    binary   |
> >   | main  contrib  non-free |
> >  -|-|
> >  main |  yes    yes  -  |
> >  source  contrib  |   - yes  -  |
> >  non-free |   -  -  yes |
> > 
> > ftp team: is this correct?
> 
> Yes. But source packages in main must also produce at least one binary
> package in main[1].

Here are some updated patches for Policy, incorporating this requirement.

I have not attempted to incorporate the corner case involving
build-profiles. I think if we were going to do that, it would require
documenting build-profiles first (#757760), and maybe even then it's too
much of a corner-case to be documenting unless/until it actually happens.

> I personally would prefer if we would avoid using this feature too much
> if possible.

I've added some wording to try to express that.

smcv
>From a332e4e787837cac0856c9c36d6e87e9f19197e2 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 9 Sep 2021 15:43:20 +0100
Subject: [PATCH 1/2] archive: Point out that mixed main/contrib source
 packages can exist

Most source packages produce only binary packages in the same archive
area, but a few source packages in main (such as bumblebee) produce
a mixture of main and contrib binary packages.

If an upstream project is in this situation (for example a program with
optional plugins that have non-free dependencies) it isn't entirely
obvious how to package it; clarify that a single source package in main
is considered to be appropriate in this case, as long as no non-free
build-dependencies are required.

Signed-off-by: Simon McVittie 
Closes: #994008
---
 policy/ch-archive.rst | 21 +
 1 file changed, 21 insertions(+)

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index ab04261..3d40f55 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -130,6 +130,27 @@ In addition, the packages in *main*
 
 - must meet all policy requirements presented in this manual.
 
+If a source package is in the *main* archive area, then at least one of
+the binary packages that it produces must be in the *main* archive area,
+and each of the remaining packages must be in either the *main* or *contrib*
+archive area. Each binary package's archive area is indicated by its
+``Section`` field: see :ref:`s-subsections`.
+
+Source packages in *main* with a mixture of *main* and *contrib* binary
+packages should be limited to situations where it would be inconvenient
+to split the source package. If it is straightforward to split the source
+package into a *main* part and a *contrib* part that are compiled
+separately, then those parts should be represented as separate source
+packages.
+
+When a *main* source package has a mixture of *main* and *contrib*
+binary packages, the source package and the *main* binary packages must
+follow the requirements for *main* packages, but the *contrib* binary
+packages may follow the weaker requirements for *contrib* packages.
+In particular, build-dependencies outside *main* are not allowed in
+these source packages, but the *contrib* binary packages may have runtime
+dependencies outside *main*.
+
 .. _s-contrib:
 
 The contrib archive area
-- 
2.33.1

>From 14cd80454fc2ef8122315a1edcc05eed43106583 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 9 Sep 2021 15:53:20 +0100
Subject: [PATCH 2/2] archive: Clarify binaries produced by contrib and
 non-free source

A source package outside main cannot produce main binary packages, because
we want main to be self-contained: if you download all main source
packages, that should give you the source code of all main binary
packages.

A source package in contrib cannot produce non-free binary packages,
because by definition contrib only contains free software (with non-free
dependencies, but those are not part of the source code).

A source package in non-free cannot produce contrib binary packages,
because we want main + contrib to be self-contained: if you download
all main or contrib source packages, that should give you the source
code of all main and contrib binary packages.

Signed-off-by: Simon McVittie 
---
 policy/ch-archive.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index 3d40f55..0979d87 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -177,6 +177,10 @@ Examples of packages which would be included in *contrib* are:
 -  wrapper packages or other sorts of free accessories for non-free
programs.
 
+If a source package is in the *contrib* archive area, then each of the
+binary packages that it produces must also be in the *contrib* archive
+area.
+
 .. _s-non-free:
 
 The 

Bug#984511: debian-policy: please clarify how archive areas can be combined in source packages

[Simon McVittie]

Control: forcemerge 994008 984511

On Thu, 04 Mar 2021 at 13:09:04 +, Simon McVittie wrote:
> Package maintainers (including me, most of the time) tend to assume that
> each source package has to exist in exactly one archive area, and all
> of its binary packages have to go into that same archive area. However,
> Ansgar tells me this is not actually true.

Looks like I opened this bug twice, 6 months apart. #994008 has more
discussion so let's treat that one as the main bug.

smcv

Bug#998061: ITP: tryton-modules-stock-shipment-cost -- Stock Shipment Cost Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 


* Package name: tryton-modules-stock-shipment-cost
  Version : 6.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/6.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Stock Shipment Cost Module)
  Tryton is a high-level general purpose application
  platform. It is the base of a complete business solution as well as a
  comprehensive health and hospital information system (GNUHealth).
  .
  This module adds shipment costs on the outgoing moves. These costs
  are added to the product margin reports.



This package is another base module published by the Tryton project. 


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#997995: RFS: ghostwriter/2.0.2-1 -- Distraction-free, themeable Markdown editor

[Adam Borowski]

On Thu, Oct 28, 2021 at 01:47:44PM +0200, Sebastien CHAVAUX wrote:
> * Package name : ghostwriter
> Version : 2.0.2-1

> Changes since the last upload:
> 
> ghostwriter (2.0.2-1) unstable; urgency=low

The actual changelog is: <<"\n\n\n", with two entries.  The older one has
never been in Debian, and it doesn't appear to have a special reason to
keep its entry.  It'd be good if you could delete it.

+ghostwriter (2.0.2-1) unstable; urgency=low
+
+  * New upstream release.
+
+ -- Sebastien CHAVAUX   Thu, 28 Oct 2021 13:24:15 +0200
+
+ghostwriter (2.0.0-1) unstable; urgency=medium
+
+  * New upstream release
+
+ -- Sebastien CHAVAUX   Mon, 10 May 2021 17:39:39 +0200


A more serious issue, though, is mess caused by adding a menu entry.  It
doesn't work (not a valid xpm, etc), and in window managers that still
support it it'll show double -- as the .desktop file is also present.

Could you please just drop it again?  It's been deprecated for ages.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Sometimes you benefit from delegating stuff.  For example,
⣾⠁⢠⠒⠀⣿⡁ this way I get to be a vegetarian.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#998060: ITP: tryton-modules-web-user -- Web User Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 


* Package name: tryton-modules-web-user
  Version : 6.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/6.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Sale Subscription Module)
  Tryton is a high-level general purpose application
  platform. It is the base of a complete business solution as well as a
  comprehensive health and hospital information system (GNUHealth).
  .
  This module provides facilities to manage external users accessing from
  the web.


This package is another base module published by the Tryton project. 


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#998059: sphinx: LANGUAGE environement variable inconsistently affects output of objects.inv

[Chris Lamb]

Package: sphinx
Version: 4.2.0-5
Severity: normal
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

An update has rendered a lot of packages that use Sphinx
unreproducible — as in, generating different output regardless of
the surrounding environment.

I'm not entirely sure where the bug is here, but it seems like there is
something up with language handling and generating the objects.inv
file.

In particular, if we compare a 'first' build with LANGUAGE="en_GB:en"
and the 'second' with LANGUAGE="et_EE:et" environment variable, what
happens is that all of the documentation is identical *except* a
single entry in the objects.inv file which appears to be translated.

Decoding the zlib-encoded objects.inv file, I can see that the
difference is a translation one:

  # Sphinx inventory version 2
  # Project: OpenDrop
  # Version: 
  # The remainder of this file is compressed using zlib.

  developers/index std:doc -1 developers/index.html Developer notes
  -genindex std:label -1 genindex.html Index
  +genindex std:label -1 genindex.html Indeks
  getting_started/index std:doc -1 getting_started/index.html Getting Started
  index std:doc -1 index.html Overview
  modindex std:label -1 py-modindex.html Module Index
  py-modindex std:label -1 py-modindex.html Python Module Index

This is despite the output including the following logging message in
both builds:

  dumping search index in English (code: en)... done
  dumping object inventory... done

(Note the "code: en" here in both builds)

The curious thing is why 'Indeks' was translated and not, for
instance, 'Module Index'. Indeed, I've dumped some more info upstream
here, but filing a Debian bug as, as mentioned, it's causing a lot of
reproducibility issues.

  https://github.com/sphinx-doc/sphinx/issues/9778


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#998058: intel-compute-runtime: FTBFS due to 2 failing tests

[Andreas Beckmann]

Source: intel-compute-runtime
Version: 21.32.20609-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

while trying to rebuild the package with my llvm dependency updates
(#994833), I noticed that it does FTBFS with some failing tests now:

./opencl/test/unit_test/kernel/kernel_arg_info_tests.cpp:157: Failure
Expected equality of these values:
  0
  result
Which is: -12
[  FAILED  ][ RKL ][ 84512 ] 
KernelArgInfoTest.GivenParamWhenGettingKernelTypeNameThenCorrectValueIsReturned

./opencl/test/unit_test/kernel/kernel_tests.cpp:423: Failure
Value of: pKernelInfo->getArgDescriptorAt(0).isReadOnly()
  Actual: false
Expected: true
[  FAILED  ][ TGLLP ][ 84530 ] 
KernelFromBinaryTests.givenArgumentDeclaredAsConstantWhenKernelIsCreatedThenArgumentIsMarkedAsReadOnly

The tests seem to fail several times in different scenarios, full
build log (rebuilding the unmodified -1 from sid in sid) attached.


Andreas


intel-compute-runtime_21.32.20609-1.sid.build.xz
Description: application/xz

Bug#998057: transition: r-api-bioc-3.14

[Dylan Aïssi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debia...@lists.debian.org


Hi,
Bioconductor 3.14 was released [1].

[1] https://bioconductor.org/news/bioc_3_14_release/

Like for previous r-api-bioc transitions, all reverse dependencies
need a manual upgrade to the new upstream releases, they are not
binNMU-able. The Debian R Packages team will do so.

Please set up a tracker manually, since this is a transition of a
virtual package name.

Ben file:
-
title = "r-api-bioc-3.14";
is_affected = .depends ~ /r-api-bioc/;
is_good = .depends ~ "r-api-bioc-3.14";
is_bad = .depends ~ "r-api-bioc-3.13";
-

Best,
Dylan

Bug#998056: ITP: tryton-modules-account-statement-rule -- Account Statement Rule Module for the Tryton Application Platform

[Mathias Behrle]

X-Debbugs-CC: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Debian Tryton Maintainers 


* Package name: tryton-modules-account-statement-rule
  Version : 6.0.0
  Upstream Author : Tryton project (www.tryton.org)
* URL : http://downloads.tryton.org/6.0/
* License : GPL-3+
  Programming Lang: Python
  Description : Tryton Application Platform (Sale Subscription Module)
  Tryton is a high-level general purpose application
  platform. It is the base of a complete business solution as well as a
  comprehensive health and hospital information system (GNUHealth).
  .
  This module allows one to define rules for automatic processing of statement
  lines from imported files.



This package is another base module published by the Tryton project. 


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#984093: libcifpp_1.0.1-4_amd64.changes REJECTED

[Andreas Tille]

Am Fri, Oct 29, 2021 at 08:06:07AM +0200 schrieb Maarten L. Hekkelman:
> See: https://www.wwpdb.org/about/usage-policies
> 
> Now, if you look at the text of this license, it is huge. Should that really
> go into the debian/copyright file?

Yes, the length of the text does not matter.  If you find it on some web page
something like

   lynx -dump > copyright.tmp
   vi copyright.tmp
remove some lines
:s/^/ /
:s/^[[:space:]]*$/ ./

comes very handy to bring the text into the required shape.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#997901: Update to the ITP

[Roland Mas]

Since mcstas and mcxtrace are maintained in the same upstream 
repository, I'm going to package both at the same time in a single 
source package (but there will be multiple binaries, of course).


Roland.

Bug#994275: Reverting breaking changes in debianutils

[Raphael Hertzog]

On Sun, 24 Oct 2021, Clint Adams wrote:
> > In any case, a message saying that which is deprecated when in fact
> > `which` will stay around (but maintained in another packages) is not
> > helpful.
> 
> Tell me, what would be helpful?

A coordinated take over of the binary with a proper transition as
recommended by the tech-ctte.

I have sympathy with your reasoning and I can certainly relate to things
that we did 20 years ago, where we happily broke unstable after a release
but we have changed.

Yes, on some aspects we have become more conservative. I certainly wish
to change that, but not by going backwards, but by providing new avenues
to experiment and make large-scale changes without breaking unstable/testing.

> On Mon, Oct 18, 2021 at 11:50:32AM -0700, Sean Whitton wrote:
> > As Raphael has mentioned, it's unlikely that when debianutils' which(1)
> > has been replaced with one in another essential or transitively
> > essential package that the new which(1), whether it's the same code or
> > something else, will print deprecation warnings.  And then it seems odd
> > to print them for a while and then stop printing them.
> 
> I find this to be a curious statement.  This implies a contract of
> future behavior that does not exist.

Right, but that's we are doing in Debian when we discuss together and make
plans for further changes and then try to stick to the plan. You seem to
consider Debian as a more "organic entity" that is not controllable and
that you have no chance to influence.

And as often, the reality is somewhere in the middle.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#998051: initscripts: /dev/ptmx and /dev/pts/ptmx have wrong permissions after boot in lxc container

[Anton Khirnov]

Quoting Adam Borowski (2021-10-29 09:53:43)
> On Fri, Oct 29, 2021 at 08:47:38AM +0200, Anton Khirnov wrote:
> > upon booting with sysvinit in an LXC container, /dev/ptmx and
> > /dev/pts/ptmx have the permissions of 000, making them unusable
> > (typically they should be 666).
> 
> Data point: it Works For Me™, on:
> * unstable host, unstable guest
> * unstable host, bullseye guest
> * bullseye host, unstable guest
> * bullseye host, bullseye guest
> 
> (I haven't investigated more yet, busy at work.)

Interesting...
- are those privileged or unprivileged containers?
- can you look at the relevant mountinfo lines?

Thanks,

-- 
Anton Khirnov

Bug#998054: libxstream-java: vulnerable to CVE-2021-391{{39..41},{44..54}}

[Alex Thiessen]

Package: libxstream-java
Version: 1.4.15-3
Severity: important
X-Debbugs-Cc: alex.thiessen.de+deb...@gmail.com

Dear Maintainer,

   * What led up to the situation?
 Package installed, the machine scanned by the IT department and
 found vulnerable to a set of CVEs. According to
 https://x-stream.github.io/security.html, it's:

 - CVE-2021-39139   XStream is vulnerable to an Arbitrary Code Execution 
attack.
 - CVE-2021-39140   XStream can cause a Denial of Service.
 - CVE-2021-39141   XStream is vulnerable to an Arbitrary Code Execution 
attack.
 - CVE-2021-39144   XStream is vulnerable to a Remote Command Execution 
attack.
 - CVE-2021-39145   XStream is vulnerable to an Arbitrary Code Execution 
attack.
 - CVE-2021-39146   XStream is vulnerable to an Arbitrary Code Execution 
attack.
 - CVE-2021-39147   XStream is vulnerable to an Arbitrary Code Execution 
attack.
 - CVE-2021-39148   XStream is vulnerable to an Arbitrary Code Execution 
attack.
 - CVE-2021-39149   XStream is vulnerable to an Arbitrary Code Execution 
attack.
 - CVE-2021-39150   A Server-Side Forgery Request can be activated 
unmarshalling with XStream to access data streams from an arbitrary URL 
referencing a resource in an intranet or the local host.
 - CVE-2021-39151   XStream is vulnerable to an Arbitrary Code Execution 
attack.
 - CVE-2021-39152   A Server-Side Forgery Request can be activated 
unmarshalling with XStream to access data streams from an arbitrary URL 
referencing a resource in an intranet or the local host.
 - CVE-2021-39153   XStream is vulnerable to an Arbitrary Code Execution 
attack.
 - CVE-2021-39154   XStream is vulnerable to an Arbitrary Code Execution 
attack.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Checked Debian website for security fixes of the package. Checked
 the changelog to see if the CVEs were fixed by a patch.

   * What was the outcome of this action?
 No newer version with CVEs fixed available for Debian stable to
 insntall out of the box.

   * What outcome did you expect instead?
 A package with the CVEs fixed.


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

Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libxstream-java depends on:
ii  libxpp3-java  1.1.4c-3

libxstream-java recommends no packages.

Versions of packages libxstream-java suggests:
pn  libcglib-nodep-java  
pn  libdom4j-java
pn  libjdom1-java
pn  libjdom2-java
pn  libjettison-java 
pn  libjoda-time-java
pn  libkxml2-java
pn  libwoodstox-java 
pn  libxom-java  

-- no debconf information

Bug#989155: dh_installinit: when upgrading to a version that adds --no-restart-after-upgrade, the service is not restarted

[Michael Biebl]

On Wed, 26 May 2021 20:44:24 -0700 Ryan Tandy  wrote:

Package: debhelper
Version: 13.3.4
Severity: normal
Control: affects -1 slapd

Dear maintainer,

It looks like if I currently use dh_installinit --restart-after-upgrade 
(the default), and in a newer version I change it to use 
--no-restart-after-upgrade, then when I upgrade to that newer version, 
the service is not restarted and the old version is still running.




If you use "--no-restart-after-upgrade", why do you expect the service 
to be restarted? Isn't the point of "--no-restart-after-upgrade" to 
*not* stop any processes on upgrades.


I'm a bit confused and must be missing something.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998051: initscripts: /dev/ptmx and /dev/pts/ptmx have wrong permissions after boot in lxc container

[Adam Borowski]

On Fri, Oct 29, 2021 at 08:47:38AM +0200, Anton Khirnov wrote:
> upon booting with sysvinit in an LXC container, /dev/ptmx and
> /dev/pts/ptmx have the permissions of 000, making them unusable
> (typically they should be 666).

Data point: it Works For Me™, on:
* unstable host, unstable guest
* unstable host, bullseye guest
* bullseye host, unstable guest
* bullseye host, bullseye guest

(I haven't investigated more yet, busy at work.)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Polexit is brewing?  Let's skip that smelly Polsha and reactivate
⢿⡄⠘⠷⠚⠋⠀ the Free City of Danzig and/or reapply to the Hansa.
⠈⠳⣄