Bug#776917: fails to debootstrap without systemd

[Lyndon Brown]

reopen -1
retitle -1 cannot switch init to sysvinit
thanks

Fixing #992916 ([1]) was made more complicated by the fact that this
bug still exists in debootstrap. On sid, if I use the following
command, the chroot ends up with both sysvinit and systemd packages
installed.

sudo debootstrap --arch=amd64 --include=sysvinit-core 
--exclude=systemd,systemd-sysv,systemd-timesyncd --components=main --verbose 
sid chroot http://deb.debian.org/debian/

$ sudo chroot chroot dpkg --list | grep systemd
ii  libsystemd0:amd64247.9-1  amd64systemd 
utility library
ii  systemd  247.9-1  amd64system 
and service manager
ii  systemd-timesyncd247.9-1  amd64
minimalistic service to synchronize local time with NTP servers
$ sudo chroot chroot dpkg --list | grep sysv
ii  sysv-rc  2.96-7   all  
System-V-like runlevel change mechanism
ii  sysvinit-core2.96-7   amd64
System-V-like init
ii  sysvinit-utils   2.96-7   amd64
System-V-like utilities

I had to spend significant additional time implementing a hack based
upon [2] to get around this.

Re-opening - It's been ~5 years since this was closed upon a basis that
a separate bit of work was being undertaken that would supposedly solve
it. I have not had the time to investigate what happened to that work,
but it clearly has not worked out in some way. A perfect demonstration
of why bugs should not be closed under such circumstances.  

[1]: https://salsa.debian.org/live-team/live-build/-/merge_requests/257
[2]: 
https://www.notinventedhere.org/articles/linux/debootstrapping-debian-jessie-without-systemd.html

Bug#992920: proftpd-mod-crypto: sftp connection aborts with "Corrupted MAC on input"

[Miguel Cruz]

Package: proftpd-mod-crypto
Version: 1.3.7a+dfsg-12
Severity: important

Dear Maintainer,

Since upgrading to bullseye, proftpd's sftp server fails with some MAC 
algorithms.

This works:

  sftp -o MACs=hmac-sha2-256 user@proftpd-server

This fails:

  sftp -o MACs=umac...@openssh.com user@proftpd-server

The failure manifests as an aborted connection after a few KB of data traffic. 
The debian CLI sftp client will display the message:

   Corrupted MAC on input.
   ssh_dispatch_run_fatal: Connection to x.x.x.x port 22: message 
authentication code incorrect

This means that some clients can no longer constructively use the server with 
their standard options.


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

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

Versions of packages proftpd-mod-crypto depends on:
ii  libc6 2.31-13
ii  libpam0g  1.4.0-9
ii  libsodium23   1.0.18-1
ii  libssl1.1 1.1.1k-1+deb11u1
ii  proftpd-core  1.3.7a+dfsg-12
ii  zlib1g1:1.2.11.dfsg-2

proftpd-mod-crypto recommends no packages.

proftpd-mod-crypto suggests no packages.

-- no debconf information

Bug#992918: gwenview: fails to save jpg/jpeg image

[Fufu Fang]

Package: gwenview
Version: 4:20.12.3-2
Severity: normal

Dear Maintainer,
I opened an image in Gwenview (it can be any format), then I go to the "File"
menu, and click on the "Save As..." menu option. If I select "JPEG image" as
the file type, then press the "Save" button, two modal dialogs pop up.

One dialog has the title "Error -- Gwenview", with the text "Unsupported image
format".

The other dialog has the title "Warning -- Gwenview", with the text "Saving
'x.jpg' failed: Unspported image format". I am offered to save it as
another format.


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

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

Versions of packages gwenview depends on:
ii  kinit  5.78.0-2
ii  kio5.78.0-5
ii  libc6  2.31-13
ii  libcfitsio93.490-3
ii  libexiv2-270.27.3-3+deb11u1
ii  libgcc-s1  10.2.1-6
ii  libjpeg62-turbo1:2.0.6-4
ii  libkf5activities5  5.78.0-2
ii  libkf5baloo5   5.78.0-3
ii  libkf5completion5  5.78.0-3
ii  libkf5configcore5  5.78.0-4
ii  libkf5configgui5   5.78.0-4
ii  libkf5configwidgets5   5.78.0-2
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5filemetadata35.78.0-2
ii  libkf5i18n55.78.0-2
ii  libkf5iconthemes5  5.78.0-2
ii  libkf5itemmodels5  5.78.0-2
ii  libkf5itemviews5   5.78.0-2
ii  libkf5jobwidgets5  5.78.0-2
ii  libkf5kdcraw5  20.12.0-1
ii  libkf5kiocore5 5.78.0-5
ii  libkf5kiofilewidgets5  5.78.0-5
ii  libkf5kiowidgets5  5.78.0-5
ii  libkf5kipi32.0.0   4:20.12.1-1
ii  libkf5notifications5   5.78.0-2
ii  libkf5parts5   5.78.0-3
ii  libkf5purpose-bin  5.78.0-2
ii  libkf5purpose5 5.78.0-2
ii  libkf5service-bin  5.78.0-2
ii  libkf5service5 5.78.0-2
ii  libkf5solid5   5.78.0-2
ii  libkf5widgetsaddons5   5.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  liblcms2-2 2.12~rc1-2
ii  libphonon4qt5-44:4.11.1-4
ii  libpng16-161.6.37-3
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5printsupport55.15.2+dfsg-9
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libqt5x11extras5   5.15.2-2
ii  libstdc++6 10.2.1-6
ii  libtiff5   4.2.0-1
ii  libx11-6   2:1.7.2-1
ii  perl   5.32.1-4+deb11u1
ii  phonon4qt5 4:4.11.1-4

Versions of packages gwenview recommends:
ii  kamera 4:20.12.0-1
pn  kio-extras 
ii  qt5-image-formats-plugins  5.15.2-2

gwenview suggests no packages.

Bug#992885: mksh: buggy ignored trap handling on subshell with only one command

[Thorsten Glaser]

Vincent Lefevre dixit:

>Perhaps because of this optimization, the wrong set of signals are
>restored?

Hrm, this sounds plausible. I don’t have the bandwidth to investigate
this at the moment, though — sorry :/ but should you, or someone else,
be interested… be my guest.

>But I wonder why the signals are restored (and what this does
>exactly).

You’ll have to trace this through pdksh, I’m afraid.

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#992669: python3.9-dev: python3.9-config --cflags includes -specs=/usr/share/dpkg/no-pie-compile.specs

[Mark Watts]

Matthias,

I've added the --embed flag to the python3.9-config options in my
Dockerfile example above, but have the same result. Apparently the
specs file comes from libdpkg-perl. I don't understand what the specs
file actually does, but I was able to build with or without it. If it
*is* supposed to be in the flags for something, libdpkg-perl should at
least be a "suggests" if not "recommends", right?

On Mon, Aug 23, 2021 at 5:09 AM Matthias Klose  wrote:
>
> On 8/22/21 5:59 AM, Mark Watts wrote:
> > Package: python3.9-dev
> > Version: 3.9.2-1
> > Severity: normal
> > X-Debbugs-Cc: watts.mark2...@gmail.com
> >
> > Dear Maintainer,
> >
> > I'm using the python3.9-config --cflags to provide flags for building a
> > program that embeds python. I'm doing this in a Docker container with
> > the essential parts described by the Dockerfile excerpt below. I would
> > expect that any files referenced in the CFLAGS would be installed along
> > with python3.9-config. Instead, I have to install another package to get
> > this file or do a sed on cflags to remove the -specs argument.
>
> your expectations are unexpected. You have to call python3-config with the
> --embed options for the embedded case.  That will get you the complete options
> needed for embedding an interpreter.  I'm not sure I want to have these extra
> dependencies as part of the python3.9-dev package.
>
> You also don't write which options are missing from your build.



-- 
Cheers,

Mark W.

Bug#992885: mksh: buggy ignored trap handling on subshell with only one command

[Vincent Lefevre]

On 2021-08-24 16:51:28 +, Thorsten Glaser wrote:
> Vincent Lefevre dixit:
> 
> >This is incorrect, because SIGINT should be ignored.
> >
> >This issue disappears when the subshell has several commands:
> >
> >$ mksh -c 'trap "" INT; trap; ( :; sleep 3; ); echo $?'
> >trap -- '' INT
> >^C0
> 
> Consider this:
> 
> $ mksh -c 'trap "" INT; trap; ( :; exec sleep 3; ); echo $?'
> trap -- '' INT
> ^C130
> 
> The “one” command run in the subshell is exec’d so you’re hitting
> the parent shell’s INT handler… I think.
> 
> Feel free to have a look at the source and see if you come up with
> what exactly seems to be the problem.

This seems to be due to

restoresigs();

in exec.c and the fact that if a subshell contains only one command,
there is an optimization to avoid a fork, as if there were an exec.
Perhaps because of this optimization, the wrong set of signals are
restored?

But I wonder why the signals are restored (and what this does
exactly).

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

Bug#982907: init-system-helpers: use new needs-reload/needs-restart unit interface

[Felipe Sateler]

Hi!

On Tue, Aug 24, 2021 at 2:38 PM Niels Thykier  wrote:

> Control: reassign -1 init-system-helpers
>
> Reassigning to init-system-helpers, quoting in full for the
> init-system-helpers maintainer's sake.
>
> On Tue, 16 Feb 2021 21:46:28 +0100 Niels Thykier 
> wrote:
> > Luca Boccassi:
> > > Source: debhelper
> > > Priority: wishlist
> > > Tags: bookworm
> > > X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org
> > >
> > > Dear Maintainer(s),
> > >
> > > systemd v248 will ship with a new dbus/systemctl interface to mark a
> > > unit as needing reload/restart, and a new dbus/systemctl to queue all
> > > reload/restart jobs in a single command.
> > > The RPM packaging/scripts are changing to use this instead of custom
> > > batching.
> > >
> > > I'm opening this ticket to explore whether it would be
> > > possible/good/desirable to switch the debhelper tools to use this as
> > > well in the future.
> > >
> > > It looks like this:
> > >
> > > systemctl set-property foo.service Markers=needs-restart
> > > systemctl set-property bar.service Markers=needs-reload
> > > ...
> > > systemctl reload-or-restart --marked
> > >
> > > (or equivalent DBUS calls)
> > >
> > > References:
> > >
> > >
> https://github.com/systemd/systemd/commit/ff68472a20c208121b69ea13586f3105a219bc14
> > >
> https://github.com/systemd/systemd/commit/c9615f73521986b3607b852c139036d58973043c
> > > https://github.com/systemd/systemd/pull/18481/commits
> > >
> > > The advantage being, you can mark a unit inline, but then batch the
> > > actual jobs later/asynchronously.
> > >
> > > Note that, given the interface has just been merged and is not yet
> > > released, there is scope for improvements if there are debhelper-
> > > specific concerns to address, given the feature first use is the RPM's
> > > side of things.
> > >
> > > Thoughts?
> > >
> >
> > By the sound of it, this is something that might need to go into the
> > init system helpers that debhelper invokes in the maintscripts (possibly
> > with a trigger in the systemd side to do the batch reload/restart).
> >
> > @Michael: What is your view?
> >
>

Not Michael, but if I can offer my thoughts, this is not something that
could be done in i-s-h (or at least, not something that we could do
transparently). This is because presumably there are postinst scripts that
assume post-debhelper-block the new version is already running. So I
believe what would be needed is:

1. Support in i-s-h to activate this mode, probably via a new flag.
2. Support in debhelper to enable/disable this new method.
3. A trigger in systemd to do the final reload.

I believe requiring the new daemon version to be already updated by
postinst time would be quite rare, so I think point 2 could be enabled by
default in a new compat level.

Thoughts?

-- 

Saludos,
Felipe Sateler

Bug#905014: I'm adopting dhcpy6d

[Axel Beckert]

Control: retitle -1 RFA: dhcpy6d -- MAC address aware DHCPv6 server written in 
Python
Control: noowner -1

Hi Moritz,

Moritz Schlarb wrote in March 2019:
> Control: retitle -1 ITA: dhcpy6d -- MAC address aware DHCPv6 server written 
> in Python
> Control: owner -1 !
[…]
> I'm willing to adopt dhcpy6d.
> 
> I will create a project in the Salsa PAPT namespace for it.

despite there was quite some more discussion in this bug report, I
unfortunately haven't read or seen any further activity of you in this
matter in the past 2.5 years. (I though see other Debian activity from
you, so you don't seem MIA. :-)

To allow others to adopt this package as well, I'm herewith setting it
back to RFA. Feel free to change it back to ITA if you still intend to
adopt this package. (It though would be nice to see some activity of
you towards that direction, too.)

To any potential adopter of this package, be it Moritz or someone
else:

As of 21st of August, the package in Debian Unstable and Testing is
again up to date with upstream after the freeze for the Debian 11
Bullseye release. https://salsa.debian.org/debian/dhcpy6d is up to
date as well as and all contain the package version 1.0.5-1.

Since I have a minimal test environment at home, I can rudimentarily
test the package and will do further updates of the package. But it
still holds true that I don't use it anymore in production — which is
suboptimal for a package maintainer. Accordingly I would like to see
someone adopting it who actually uses it in production — and who
preferably knows more Python than me. ;-)

But since Henri is a very helpful and responsive upstream, the amount
Python knowledge actually isn't such a hard adoption criteria. :-)

P.S.: Please be aware that the project's homepage URL (mainly the
domain) as well as upstream's e-mail address changed. With the upload
from yesterday, the package is also up to date with regards to this.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#992919: lebiniou: Upgrade fails: trying to overwrite '/usr/share/lebiniou/etc/schemes.json', which is also in package lebiniou-data 3.54.1-1

[Axel Beckert]

Package: lebiniou
Version: 3.61.1-1
Severity: serious

Unpacking lebiniou (3.61.1-1) over (3.54.1-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-ryc9hl/423-lebiniou_3.61.1-1_i386.deb (--unpack):
 trying to overwrite '/usr/share/lebiniou/etc/schemes.json', which is also in 
package lebiniou-data 3.54.1-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
dpkg: considering deconfiguration of lebiniou, which would be broken by 
installation of lebiniou-data ...
dpkg: yes, will deconfigure lebiniou (broken by lebiniou-data)
Preparing to unpack .../424-lebiniou-data_3.61.0-2_all.deb ...
De-configuring lebiniou (3.54.1-1) ...
Unpacking lebiniou-data (3.61.0-2) over (3.54.1-1) ...
[…]
Errors were encountered while processing:
 /tmp/apt-dpkg-install-ryc9hl/423-lebiniou_3.61.1-1_i386.deb

This is likely either a file which is accidentially shipped in both
packages or the file was moved from one package to the other and
according Breaks and Replaces headers are missing.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')

Bug#992878: RFS: dune-grid/2.8.0~rc1-1 -- toolbox for solving PDEs -- grid interface (documentation)

[Adam Borowski]

On Tue, Aug 24, 2021 at 04:46:17PM +0200, Lisa Julia Nebel wrote:
> * Package name : dune-grid
> Version : 2.8.0~rc1-1

> dune-grid (2.8.0~rc1-1) experimental; urgency=medium
> .
> * New upstream release.
> * debian/rules: Explicitly set buildsystem to CMake
> * Removed obsolete patches.

Just a heads-up: dune-grid and dune-grid-glue fail tests when built/ran
with the experimental toolchain that is about to be uploaded to unstable.
Both of these packages do work with the toolchain from unstable.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

[Chuck Zmudzinski]

On 8/24/2021 1:12 PM, Ben Hutchings wrote:

On Tue, 2021-08-24 at 10:56 -0400, Chuck Zmudzinski wrote:

On 5/24/2021 3:30 AM, Michael Biebl wrote:

Hi Phillip

Am 24.05.2021 um 06:19 schrieb Cyril Brulebois:

trigger to cold plug all devices.  Both scripts are set -e.  The Xen
Virtual Keyboard driver and at least one other driver have always
failed
to trigger due to having absurdly long modalias, but the error used to
be ignored.  The kernel now returns the error to udevadm

So this is a change in behaviour in the kernel?
What happens if you boot the installed system? Does udevadm trigger
fail there as well?

I feel a bit uneasy changing the udev start script this late in the
release cycle (especially when it appears like covering up an issue
someplace else).

I'll let Marco make the judgement on this though, as he has the most
experience with those udev udeb start scripts as the original author.

Michael


After reviewing Philip's message at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#43

which seems to point to the root cause of this bug, I can add:

On my Xen HVM DomU I see the absurdly long modalias for the Xen
Virtual keyboard that seems to be causing this crash in sysfs at

/sys/devices/virtual/input/input2/modalias

But at /sys/devices/vkbd-0/modalias, I see just 'xen:vkbd', which would
probably not result in an error in the udev script if this was also
written as the modalias at /sys/devices/virtual/input/input2/modalias

So the Xen virtual keyboard appears more than once in sysfs, and
modalias is not the same in the different places. This seems
to be a problem.

They are two different devices, and they should have different
modaliases.

Linux has code for discovering devices on each kind of bus, including
virtual buses, and that code creates "bus devices" such as vkbd-0.  At
this point the kernel doesn't know what the device is capable of.  The
modalias for a bus device carries some identifying information that can
be used to select a driver module for it.

The driver does know what the device is capable of, and how to use it.
It will normally create one or more "class devices" that support a
particular set of operations; in this case input device operations.
Class devices typically don't have modaliases, since they don't need
another layer of drivers on top.  However, for input devices the
modalias carries information about the device's capabilities.  These
may trigger loading of the evdev or joydev module.


I understand the correct way to fix this bug is by modifying the
Xxen virtual keyboard (and any other devices that might cause
this crash) and not the start-udev script on the netinst
installation media, which is so far the only available workaround.
Hopefully Xen will accept a fix if we can come up with a fix.

[...]

I think a proper fix would be one of:

a. If the Xen virtual keyboard driver is advertising capabilities it
doesn't have, stop it doing that.
b. Change the implementation of modalias attributes to allow longer
values.

It's not clear to me whether the Xen driver is advertising correctly or
not.  If it is, then the solution should be b, but that may be too
disruptive a change to the kernel.  So a reasonable workaround might
be:

c. Change the input subsystem to limit the length of the
capabilities part of the modalias.


Ben.



So workaround c would not involve disruptions to the kernel or
systemd? Workaround c seems too disruptive for stable to me,
but maybe could go into unstable and eventually into testing.

A problem with the approach of fixing this bug in the Xen
keyboard driver is that the fix must be implemented in the underlying
Dom0 system, which could be almost anything - another Linux distro
or Debian stable or oldstable. Any fix upstream would probably get into
a bullseye Dom0, but not oldstable Dom0, but perhaps it could be
provided as a backport for anyone who is still on oldstable for their
Xen Dom0.

Anyway, I will look into the Xen virtual keyboard capabilities. The
only capability I can think of that would be useful in this context is that
it supports live migration of a VM through some sort of hot-swapping
capability. If it has that capability, a workaround to support it would be
good. But if it does not have that capability or if such a capability is
not needed for a keyboard, then it should probably stop advertising
itself as being able or needing to do that. Ultimately, it is up to Xen to
decide if they are going to make changes to its virtual keyboard.

Chuck

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

[Ben Hutchings]

On Tue, Aug 24, 2021 at 03:27:19PM -0400, Phillip Susi wrote:
> 
> Ben Hutchings  writes:
> 
> > I think a proper fix would be one of:
> >
> > a. If the Xen virtual keyboard driver is advertising capabilities it
> >doesn't have, stop it doing that.
> > b. Change the implementation of modalias attributes to allow longer
> >values.
> >
> > It's not clear to me whether the Xen driver is advertising correctly or
> > not.  If it is, then the solution should be b, but that may be too
> > disruptive a change to the kernel.  So a reasonable workaround might
> > be:
> >
> > c. Change the input subsystem to limit the length of the
> >capabilities part of the modalias.
> 
> The problem with a) is that the Xen keyboard is not a physical keyboard
> and so it has no way of knowing what keys it actually has.  It is a fake
> input device designed to pass through whatever input the Xen hypervisor
> sends down.  As such, any key could come in.  If it doesn't advertise
> that it has all of these keys, then they would not be accepted by
> libinput when the hypervisor sends them down.

Right, that's what I feared.

xen-kbdfront is setting the bits for keys in the ranges [KEY_ESC,
KEY_UNKNOWN) and [KEY_OK, KEY_MAX), which I think works out to 654
keys and 2362 bytes in the modalias.

> This seems to be the heart of the problem: libinput was designed
> assuming that all keyboards can and must report what keys are actually
> present, and then libinput tries to cram that information into the
> modalias rather than some other sysfs attribute as it should ( or not at
> all... I still don't see how this information is actually supposed to be
> useful to userspace ).

I think modaliases aren't intended to be interpreted by user-space,
other than processing wildcards when matching to modules.

For input devices, the same information is available through other
variables in the uevent, in a more compact form.  The information *is*
useful for user-space; e.g. in initramfs-tools we recognise keyboard
devices and add their drivers to the initramfs but ignore other input
devices.

> As for b), the problem isn't with the modalias attribute itself, but
> when the kernel tries to copy it into the environment block for the udev
> callout.  The environment block is only a single page, and so limited to
> 4 KB.  And that's for everything else that goes into the environment,
> not just the modalias.

Text-based sysfs attributes are limited to a page, but udev receives
uevents through netlink, not sysfs.

The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).  That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390

But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.  Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
 
 #define UEVENT_HELPER_PATH_LEN 256
 #define UEVENT_NUM_ENVP64  /* number of env 
pointers */
-#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */
+#define UEVENT_BUFFER_SIZE 4096/* buffer for the variables */
 
 #ifdef CONFIG_UEVENT_HELPER
 /* path to the userspace helper executed on an event */
--- END ---

?

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


signature.asc
Description: PGP signature

Bug#883932: [pkg-crosswire-devel] Fwd: sword-comm-mhc_2.0-1_amd64.changes REJECTED

[Bastian Germann]

I filed bug https://tracker.crosswire.org/projects/MOD/issues/MOD-421 to 
clarify the Sword module's copyright situation. As long as that is not 
clear, the module can still be added to non-free.


Am 24.08.21 um 22:26 schrieb Roberto C. Sánchez:

It seems that the MHC module was initially prepared when the CCEL site
allowed free download and republication of the plain text format content
(i.e., it was in the public domain) [0].  This seems to have changed
about 1 year ago to the current form that Thorsten referenced :-(

Regards,

-Roberto


[0] 
https://web.archive.org/web/20170206170814/https://www.ccel.org/about/copyright.html

On Tue, Aug 24, 2021 at 10:07:37PM +0200, Teus Benschop wrote:

Met vriendelijke groeten,
With kind regards,

Teus Benschop
https://freesoftwareconsultants.nl
https://bibledit.org


-- Forwarded message -
From: Teus Benschop 
Date: Tue, 24 Aug 2021 at 22:07
Subject: Re: sword-comm-mhc_2.0-1_amd64.changes REJECTED
To: Thorsten Alteholz 


Hi Thorsten,

Thank you for reviewing the copyright of the package, and drawing attention
to the fact that this copyright is not compatible with the DFSG. We
certainly had overlooked that. Sorry for taking your time for this, if we
could have found it out before uploading this package.

Met vriendelijke groeten,
With kind regards,

Teus Benschop
https://freesoftwareconsultants.nl
https://bibledit.org


On Tue, 24 Aug 2021 at 19:00, Thorsten Alteholz <
ftpmas...@ftp-master.debian.org> wrote:



Hi Teus,

according to the CCEL website [1] "these books may be used for personal,
educational, or non-profit purposes"
Unfortunately this is not compatible with the DFSG.

   Thorsten


[1] https://www.ccel.org/about/copyright.html

Bug#992917: grok: FTBFS due to RPC removal from glibc

[Aurelien Jarno]

Source: grok
Version: 1.20110708.1-4.5
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)


The glibc SunRPC implementation has been marked obsolete for some time.
It has been removed upstream from glibc 2.32, and it got disabled in the
recent glibc uploads. The TI RPC implementation should be used instead,
which also brings new features (IPv6, Kerberos support, ...).

For this reason grok now fails to build from source. You will find
attached a patch to switch to the TI RPC implementation, fixing the
FTBFS.

Regards,
Aurelien
--- grok-1.20110708.1/debian/control
+++ grok-1.20110708.1/debian/control
@@ -14,6 +14,7 @@
  libevent-dev,
  libpcre3-dev,
  libtokyocabinet-dev,
+ libtirpc-dev,
 Standards-Version: 3.9.3
 Homepage: http://code.google.com/p/semicomplete/wiki/Grok
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/grok.git
--- grok-1.20110708.1/debian/patches/libtirpc.patch
+++ grok-1.20110708.1/debian/patches/libtirpc.patch
@@ -0,0 +1,19 @@
+Description: use TI RPC implementation instead of removed GNU libc one
+Author: Aurelien Jarno 
+Last-Update: 2021-08-24
+
+--- grok-1.20110708.1.orig/Makefile
 grok-1.20110708.1/Makefile
+@@ -31,6 +31,12 @@ ifeq ($(PLATFORM), GNULinux)
+ LDFLAGS+=-ldl
+ endif
+ 
++# Use TI RPC on GNU/Linux
++ifeq ($(PLATFORM), GNULinux)
++CFLAGS+=-I/usr/include/tirpc
++LDFLAGS+=-ltirpc
++endif
++
+ # For GNU/kFreeBSD, we also need libdl
+ ifeq ($(PLATFORM), GNUkFreeBSD)
+ LDFLAGS+=-ldl
--- grok-1.20110708.1/debian/patches/series
+++ grok-1.20110708.1/debian/patches/series
@@ -7,3 +7,4 @@
 gperf-function-declaration.patch
 move_ldflags.patch
 fix_gcc10.patch
+libtirpc.patch

Bug#992916: [live-build] broken sysvinit support

[Lyndon Brown]

Package: live-build
Version: 1:20210407

As just discussed on the mailing list (see the thread starting at [1]),
the author of the thread would like to use the sysvinit init system
instead of systemd. We already provide an option for selecting this (`-
-initsystem`), however it does not work. All it achieves is to put a
different `live-config-*` package along with `sysvinit-core` into a
live package list.

I expect that the reason why the author cannot build a sysvinit image
currently is because debootstrap is installing `systemd-sysv` and we do
nothing in our `boostrap_debootstrap` script to get debootstrap to
alternatively install `sysvinit-core` like the procedure described at
[2].

[1]: https://lists.debian.org/debian-live/2021/08/msg00014.html
[2]:
https://www.notinventedhere.org/articles/linux/debootstrapping-debian-jessie-without-systemd.html

Bug#992915: grub-legacy: Removing kernel image fails: /usr/sbin/update-grub: line 273: tempfile: command not found

[Axel Beckert]

Package: grub-legacy
Severity: serious
Version: 0.97-77
Tags: patch
Control: affects -1 src:linux

Removing a kernel image fails as follows due to grub-legacy's
update-grub uses the deprecated and now removed tempfile utility:

Removing linux-image-5.10.0-6-amd64 (5.10.28-1) ...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-5.10.0-6-amd64
/etc/kernel/postrm.d/zz-update-grub:
Searching for GRUB installation directory ... found: /boot/grub
/usr/sbin/update-grub: line 273: tempfile: command not found
run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return code 127
dpkg: error processing package linux-image-5.10.0-6-amd64 (--remove):
 installed linux-image-5.10.0-6-amd64 package post-removal script subprocess 
returned error exit status 1
dpkg: too many errors, stopping
Errors were encountered while processing:
 linux-image-5.10.0-6-amd64
Processing was halted because there were too many errors.

This currently blocks all further apt activities.

The following patch seems to fix the issue:

--- /usr/sbin/update-grub~  2018-05-05 14:45:49.0 +0200
+++ /usr/sbin/update-grub   2021-08-25 00:26:21.52990 +0200
@@ -270,7 +270,7 @@
 # Default options to use in a new config file. This will only be used if 
$menu_file
 # doesn't already exist. Only edit the lines between the two "EOF"s. The 
others are
 # part of the script.
-newtemplate=$(tempfile)
+newtemplate=$(mktemp)
 cat > "$newtemplate" <> $buffer
 echo "## lines between the AUTOMAGIC KERNELS LIST markers will be modified" >> 
$buffer
 echo "## by the debian update-grub script except for the default options 
below" >> $buffer
@@ -1034,7 +1034,7 @@
fi
 else
value="$1"
-   newmenu=$(tempfile)
+   newmenu=$(mktemp)
sed -e "s/^[[:blank:]]*default[[:blank:]]*[[:digit:]]*\(.*\)/default
 ${value}\1/;b" $menu > $newmenu
cat $newmenu > $menu
rm -f $newmenu

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages grub-legacy depends on:
ii  grub-common  2.04-20
ii  libc6-i386   2.31-17

grub-legacy recommends no packages.

Versions of packages grub-legacy suggests:
pn  grub-legacy-doc  
pn  mdadm
ii  multiboot0.6.96+20101113-3

-- no debconf information

Bug#970926: Either update or remove dokuwiki from Debian

[R.]

Dear Maintainer,

Debian bullseye is there and still includes an obsolete version of Dokuwiki
(since 2020-07-29)
The dokuwiki officially says that we should not use the outdated Debian
package : https://www.dokuwiki.org/install:debian

Please make a decision : either update the package or remove it from Debian
standard.

Regards,

Romain

Bug#992914: libassa: FTBFS due to RPC removal from glibc

[Aurelien Jarno]

Source: libassa
Version: 3.5.1-7
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

The glibc SunRPC implementation has been marked obsolete for some time.
It has been removed upstream from glibc 2.32, and it got disabled in the
recent glibc uploads. The TI RPC implementation should be used instead.

libassa was already supposed to use libtirpc, but in practice was still
linked to glibc due a missing entry in Makefile.am. Please find attach a
patch fixing the FTBFS.
--- libassa-3.5.1/debian/patches/06-link-with-tirpc.diff
+++ libassa-3.5.1/debian/patches/06-link-with-tirpc.diff
@@ -0,0 +1,18 @@
+Description: Correctly link with libtirpc 
+Author: Aurelien Jarno 
+Forwarded: no
+Last-Update: 2021-08-24
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+--- libassa-3.5.1.orig/assa/Makefile.am
 libassa-3.5.1/assa/Makefile.am
+@@ -111,6 +111,8 @@ libassa_3_5_la_LDFLAGS = \
+   @WIN32_EXTRA_LDFLAGS@ \
+   -version-info @LIBASSA_SO_VERSION@ 
+ 
++libassa_3_5_la_LIBADD = @TIRPC_LIBS@
++
+ # Disable autoheader.
+ AUTOHEADER=echo
+ 
--- libassa-3.5.1/debian/patches/series
+++ libassa-3.5.1/debian/patches/series
@@ -3,3 +3,4 @@
 03-support-hurd.patch
 04-fix-more-spelling.patch
 05-remove-build-path-from-doxygen.patch
+06-link-with-tirpc.diff

Bug#992784: cups: libcupsimage2 not a dependancy

[Brian Potkin]

On Tue 24 Aug 2021 at 22:20:51 +0200, Alain Bertrand wrote:

> Hello,
> 
> Thanks for your answer. The log is attached.
> 
> BTW :
> 
> Canon_LBP113_LBP913_USB_ could print both the test page and a page
> taken from the first pdf file I found,

This is a supported printing situation.

> Canon_LBP113_913_UFRII_LT could not. This is the situation that made
> me install libcupsimage2.

This is not a supported printing situation.
 
> So I guess you'll close the bug for good now. Sorry for wasting your
> time.

Alain, you have not wasted anyone's time. If anything, you have
confirmed the integrity of the printing system with this printer.
Your co-operation has been invaluable.

Many thanks,

Brian.

Bug#992719: Please package elixir >= 1.10.4 and < 1.13.0

[Thomas Goirand]

On 8/24/21 4:52 PM, Evgeny Golyshev wrote:
> Done. The package was uploaded.
> 
> --
> Evgeny

Hi,

Thanks a lot for your prompt action. I was able to upload a fixed
version of RabbitMQ that builds (and should be working with) Erlang v24.

Cheers,

Thomas Goirand (zigo)

Bug#992827: nmu: step_4:21.08.0-1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-08-24 08:13:56 +0900, Norbert Preining wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> X-Debbugs-Cc: debian-qt-...@lists.debian.org
> 
> step depends on the KDE PIM libraries that have recently been uploaded
> in version 21.08. To ensure co-installability, a rebuild is necessary.

I'm not sure I can follow. What issues are you trying to solve with this
binNMU?

Cheers

> 
> nmu step_4:21.08.0-1 . ANY . unstable . -m "Rebuild against KDE Gears 21.08 
> libraries."
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#992913: trickle: FTBFS due to RPC removal from glibc

[Aurelien Jarno]

Package: trickle
Version: 1.07-10.1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

The glibc SunRPC implementation has been marked obsolete for some time.
It has been removed upstream from glibc 2.32, and it got disabled in the
recent glibc uploads. The TI RPC implementation should be used instead,
which also brings new features (IPv6, Kerberos support, ...).

For this reason trickle now fails to build from source. You will find
attached a patch to switch to the TI RPC implementation, fixing the
FTBFS.

Regards,
Aurelien
diff -u trickle-1.07/Makefile.am trickle-1.07/Makefile.am
--- trickle-1.07/Makefile.am
+++ trickle-1.07/Makefile.am
@@ -24,12 +24,12 @@
 
 trickled_SOURCES = trickled.c atomicio.c print.c bwstat.c client.c conf.c \
util.c cleanup.c getopt.c xdr.c
-trickled_LDADD = @EVENTLIB@ -lbsd
+trickled_LDADD = @EVENTLIB@ @TIRPC_LIBS@ -lbsd
 
 tricklectl_SOURCES = tricklectl.c trickledu.c atomicio.c xdr.c
-tricklectl_LDADD = @ERRO@  -lbsd
+tricklectl_LDADD = @ERRO@ @TIRPC_LIBS@ -lbsd
 
-AM_CFLAGS = -Wall -Icompat @EVENTINC@
+AM_CFLAGS = -Wall -Icompat @EVENTINC@ @TIRPC_CFLAGS@
 
 overloaddir = $(libdir)
 #overload_DATA = libtrickle.so
diff -u trickle-1.07/configure.in trickle-1.07/configure.in
--- trickle-1.07/configure.in
+++ trickle-1.07/configure.in
@@ -119,6 +119,9 @@
 AC_SUBST(EVENTINC)
 AC_SUBST(EVENTLIB)
 
+dnl Checks for libtirpc
+PKG_CHECK_MODULES(TIRPC, libtirpc)
+
 dnl check if underscores are needed
 AC_MSG_CHECKING(if underscores are needed for symbols)
 AC_TRY_RUN(
diff -u trickle-1.07/debian/control trickle-1.07/debian/control
--- trickle-1.07/debian/control
+++ trickle-1.07/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Robert Lemmen 
 Build-Depends: debhelper (>= 7.0.0), libevent-dev (>= 0.7b), autoconf,
- libbsd-dev, dh-autoreconf
+ libbsd-dev, dh-autoreconf, pkg-config, libtirpc-dev
 Standards-Version: 3.9.4
 
 Package: trickle

Bug#992908: awesome: autopkgtest regression between 20 and 23 August 2021: Could not resolve keysym

[Reiner Herrmann]

Hi Paul,

On Tue, Aug 24, 2021 at 10:56:25PM +0200, Paul Gevers wrote:
> Your package has an autopkgtest, great! However, since this week
> (somewhere between 20 August and 23 August 2021) it started to fail [1].
> Can you look at it and fix the situation?
[...]
> [1] https://ci.debian.net/packages/a/awesome/testing/amd64/
> 
> autopkgtest [13:23:59]: test integration.sh: [---
> awesome_log: /tmp/tmp.Tu7TMRXwgL/_awesome_test.log
> The XKEYBOARD keymap compiler (xkbcomp) reports:
> > Internal error:   Could not resolve keysym XF86BrightnessAuto
[...]
> > Internal error:   Could not resolve keysym XF86KbdLcdMenu5

Thanks for the information. At a first glance this looks very similar
to a test failure from last year, which was caused by Xorg-related
packages, see #953032. The bug has already been re-opened, as someone
else also noticed that this issue re-appeared.

Below is a diff of installed packages between runs [2] and [3].

I will try to figure out what exactly is causing it.

Kind regards,
  Reiner

[2] 
https://ci.debian.net/data/autopkgtest/testing/amd64/a/awesome/14741180/log.gz
[3] 
https://ci.debian.net/data/autopkgtest/testing/amd64/a/awesome/14793442/log.gz

@@ -16,25 +16,21 @@
 gcc-10 10.2.1-6
 gcc 4:10.2.1-1
 gir1.2-atk-1.0 2.36.0-2
-gir1.2-freedesktop 1.66.1-1+b1
+gir1.2-freedesktop 1.68.0-2
-gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1
+gir1.2-gdkpixbuf-2.0 2.42.6+dfsg-2
-gir1.2-glib-2.0 1.66.1-1+b1
+gir1.2-glib-2.0 1.68.0-2
-gir1.2-gtk-3.0 3.24.24-4
+gir1.2-gtk-3.0 3.24.30-1
 gir1.2-harfbuzz-0.0 2.7.4-1
 gir1.2-pango-1.0 1.46.2-3
-glib-networking 2.66.0-2
-glib-networking-common 2.66.0-2
-glib-networking-services 2.66.0-2
 groff-base 1.22.4-6
-gsettings-desktop-schemas 3.38.0-2
-gtk-update-icon-cache 3.24.24-4
+gtk-update-icon-cache 3.24.30-1
 hicolor-icon-theme 0.17-2
 libasan6 10.2.1-6
 libatk1.0-0 2.36.0-2
 libatk1.0-data 2.36.0-2
 libatk-bridge2.0-0 2.38.0-1
 libatomic1 10.2.1-6
-libatspi2.0-0 2.38.0-4
+libatspi2.0-0 2.40.3-3
 libavahi-client3 0.8-5
 libavahi-common3 0.8-5
 libavahi-common-data 0.8-5
@@ -49,22 +45,22 @@
 libcups2 2.3.3op2-3+deb11u1
 libdatrie1 0.2.13-1
 libdconf1 0.38.0-2
-libdeflate0 1.7-1
+libdeflate0 1.7-2
 libdrm2 2.4.104-1
 libdrm-amdgpu1 2.4.104-1
 libdrm-common 2.4.104-1
 libdrm-intel1 2.4.104-1
 libdrm-nouveau2 2.4.104-1
 libdrm-radeon1 2.4.104-1
-libepoxy0 1.5.5-1
+libepoxy0 1.5.8-1
 libfontconfig1 2.13.1-4.2
 libfontenc1 1:1.1.4-1
 libfreetype6 2.10.4+dfsg-1
 libfribidi0 1.0.8-2
 libgcc-10-dev 10.2.1-6
-libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
+libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
-libgdk-pixbuf2.0-common 2.42.2+dfsg-1
+libgdk-pixbuf2.0-common 2.42.6+dfsg-2
-libgirepository-1.0-1 1.66.1-1+b1
+libgirepository-1.0-1 1.68.0-2
 libgl1 1.3.2-1
 libgl1-mesa-dri 20.3.5-1
 libglapi-mesa 20.3.5-1
@@ -74,8 +70,8 @@
 libglx-mesa0 20.3.5-1
 libgomp1 10.2.1-6
 libgraphite2-3 1.3.14-1
-libgtk-3-0 3.24.24-4
+libgtk-3-0 3.24.30-1
-libgtk-3-common 3.24.24-4
+libgtk-3-common 3.24.30-1
 libharfbuzz0b 2.7.4-1
 libice6 2:1.0.10-1
 libicu67 67.1-7
@@ -83,8 +79,6 @@
 libitm1 10.2.1-6
 libjbig0 2.1-3.1+b2
 libjpeg62-turbo 1:2.0.6-4
-libjson-glib-1.0-0 1.6.2-1
-libjson-glib-1.0-common 1.6.2-1
 liblcms2-2 2.12~rc1-2
 libllvm11 1:11.0.1-2
 liblsan0 10.2.1-6
@@ -100,22 +94,17 @@
 libpipeline1 1.5.3-1
 libpixman-1-0 0.40.0-1
 libpng16-16 1.6.37-3
-libproxy1v5 0.4.17-1
-libpsl5 0.21.0-1.2
 libpthread-stubs0-dev 0.4-1
 libquadmath0 10.2.1-6
-librest-0.7-0 0.8.1-1.1
 libsensors5 1:3.6.0-7
 libsensors-config 1:3.6.0-7
 libsm6 2:1.2.3-1
-libsoup2.4-1 2.72.0-4
-libsoup-gnome2.4-1 2.72.0-4
 libstartup-notification0 0.12-6+b1
 libstdc++-10-dev 10.2.1-6
-libthai0 0.1.28-3
+libthai0 0.1.28-4
-libthai-data 0.1.28-3
+libthai-data 0.1.28-4
 libtiff5 4.2.0-1
-libtirpc-dev 1.3.1-1
+libtirpc-dev 1.3.2-2
 libtsan0 10.2.1-6
 libubsan1 10.2.1-6
 libuchardet0 0.0.7-1
@@ -192,7 +181,7 @@
 menu 2.1.48
 shared-mime-info 2.0-1
 x11-apps 7.7+8
-x11-common 1:7.7+22
+x11-common 1:7.7+23
 x11proto-dev 2020.1-1
 x11-utils 7.7+5
 x11-xkb-utils 7.7+5
@@ -201,8 +190,8 @@
 xfonts-base 1:1.0.5
 xfonts-encodings 1:1.0.4-2.1
 xfonts-utils 1:7.7+6
-xkb-data 2.29-2
+xkb-data 2.33-1
 xorg-sgml-doctools 1:1.11-1.1
 xserver-common 2:1.20.11-1
-xterm 366-1
+xterm 368-2
 xvfb 2:1.20.11-1


signature.asc
Description: PGP signature

Bug#991564: duplicate of #991563

[chriz]

the bug is a duplicate of #991563
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991563) and can
therefore be closed

Bug#992912: mat2: autopkgtests fail with ffmpeg 4.4

[Sebastian Ramacher]

Source: mat2
Version: 0.12.1-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm

=== FAILURES ===
___ TestCleaning.test_all_parametred ___

self = 

def test_all_parametred(self):
for case in self.data:
if 'ffmpeg' in case:
try:
video._get_ffmpeg_path()
except RuntimeError:
raise unittest.SkipTest

print('[+] Testing %s' % case['name'])
target = './tests/data/clean.' + case['name']
shutil.copy('./tests/data/dirty.' + case['name'], target)
p1 = case['parser'](target)

for k, v in p1.get_meta().items():
if k not in case['meta']:
continue
if isinstance(v, dict):
for _k, _v in v.items():
if _k in case['meta'][k]:
self.assertEqual(_v, case['meta'][k][_k])
else:
self.assertEqual(v, case['meta'][k])

p1.lightweight_cleaning = True
self.assertTrue(p1.remove_all())

p2 = case['parser'](p1.output_filename)
for k, v in p2.get_meta().items():
>   self.assertIn(k, case['expected_meta'])
E   AssertionError: 'ColorRepresentation' not found in 
{'CompatibleBrands': ['isom', 'iso2', 'avc1', 'mp41'], 'CompressorID': 'avc1', 
'GraphicsMode': 'srcCopy', 'HandlerDescription': 'SoundHandler', 'HandlerType': 
'Metadata', 'HandlerVendorID': 'Apple', 'MajorBrand': 'MP4  Base Media v1 [IS0 
14496-12:2003]', 'MediaDataOffset': 48, 'MediaDataSize': 379872, 
'MediaHeaderVersion': 0, 'MinorVersion': '0.2.0', 'MovieDataOffset': 48, 
'MovieHeaderVersion': 0, 'NextTrackID': 3, 'PreferredRate': 1, 'Rotation': 0, 
'TimeScale': 1000, 'TrackHeaderVersion': 0, 'TrackID': 1, 'TrackLayer': 0}


From
https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/14794812/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

[Simon McVittie]

On Tue, 24 Aug 2021 at 15:23:24 +0100, Simon McVittie wrote:
> Core packages:
> 
> - gsettings-desktop-schemas (must go first)
> - gnome-settings-daemon
> - gnome-control-center
> - mutter
> - gnome-shell
> - gnome-desktop3
> - this one is not strictly versioned, but it'll be less confusing
>   for everyone if we upload it as part of the same transaction
> - budgie-desktop (non-GNOME package, fixed version in Ubuntu but not
>   experimental)

It looks as though we should be able to limit the libmutter-8-0 transition
to just this cluster of packages.

A suitable budgie-desktop version is available in experimental now (kudos
to its maintainer for doing that so quickly).

> Entanglement that I know about so far:
> 
> - libgweather has some sort of incompatible behaviour changes without
>   a SONAME bump. I need to look into this.

What has happened here is that the network services libgweather relies
on are now requiring more info, which the old libgweather literally did
not have available to it. No symbols have been removed from its ABI,
so no SONAME bump; but to actually get weather information, callers now
need to provide an application ID and developer contact info, by setting
properties that previously didn't exist. Additionally, there is an API
(but not ABI) change as a result of one of the network services being
renamed.

It looks as though we should be able to cut the knot by applying some small
patches to gnome-shell (making it provide the new properties if and only if
it sees a new version) and to gnome-settings-daemon (it doesn't use this
part of the API, and its dependency was bumped because it stopped using
now-deprecated functions; we can add a version-check guard).

The new libgweather is still entangled with the new evolution-data-server,
but that can be for someone else to sort out. It's compile-time-compatible
with either version, but is currently forced to use the new version because
we only have one experimental.

smcv

Bug#992911: rust-grep_0.2.8-1_amd64-buildd.changes REJECTED

[Aurelien Jarno]

Source: rust-grep
Version: 0.2.8-1
Severity: serious

On 2021-08-24 21:13, Debian FTP Masters wrote:
> librust-grep-dev_0.2.8-1_amd64.deb: has 6 file(s) with a timestamp too far in 
> the past:
>   usr/share/cargo/registry/grep-0.2.8/COPYING (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/grep-0.2.8/LICENSE-MIT (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/grep-0.2.8/README.md (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/grep-0.2.8/UNLICENSE (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/grep-0.2.8/examples/simplegrep.rs (Thu Nov 29 
> 21:33:09 1973)  usr/share/cargo/registry/grep-0.2.8/src/lib.rs (Thu Nov 29 
> 21:33:09 1973)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#992910: fwupd: binNMUs produce broken Built-Using for fwupd-*-signed

[Sebastian Ramacher]

Source: fwupd
Version: 1.5.7-4
Severity: serious
Tags: sid bookworm
Control: block 981078 by -1
X-Debbugs-Cc: sramac...@debian.org

fwupd was recently binNMUed for the libxmlb transition. Builds of
fwupd-*-signed for the binNMUs were rejeced by dak due to invalid
Built-Using:

fwupd-amd64-signed_1.5.7+4.b1_amd64.deb: Built-Using refers to non-existing 
source package fwupd (= 1.5.7-4+b1)
fwupd-arm64-signed_1.5.7+4.b1_arm64.deb: Built-Using refers to non-existing 
source package fwupd (= 1.5.7-4+b1)
fwupd-armhf-signed_1.5.7+4.b1_armhf.deb: Built-Using refers to non-existing 
source package fwupd (= 1.5.7-4+b1)
fwupd-i386-signed_1.5.7+4.b1_i386.deb: Built-Using refers to non-existing 
source package fwupd (= 1.5.7-4+b1)

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#976235: enlightenment: e switches off screen|monitor

[enno]

Dear Ross,

Long time no see, I have new findings.  By now I'm on 5.9.0-5-amd64, have 
longtime not tried to reactivate e, today found the time, and again, it reacts 
strangely.  Maybe my setup is wrong, I have a ~/.xsession, which is a symbolic 
link to ~/.xsession-enlightenment, which says:

"""citation start"""
#!/bin/bash
if pgrep Xorg >/dev/null 2>&1; then
syndaemon -d -K -R -i 1
exec /usr/bin/enlightenment_start
else
echo "Usage: by X/xdm.  See X(7x)."
fi
"""citation end"""

What happens is that I see an Enlightenment screen showing on my (laptop) 
monitor for about a second, then the screen turns black.

NEW: If I do nothing, screen stays black for quite precisely 30 seconds, no 
matter if on VT7 or VT1-6, then screen comes back.  If in TTY1-6 it stays, if 
in VT7 as soon as I press a key or click a mouse it turns black again.  But 
then sometimes also VT1-6 turn black again, apparently without my influence.

And in .xsession-errors--where I redirect console output, there's:

"""citation start""":
Xsession: X session started for enno at Di Aug 24 22:29:36 CEST 2021
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/
run/user/1000/bus
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting XAUTHORITY=/home/enno/.Xauthority
localuser:enno being added to access control list
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting USER=enno
dbus-update-activation-environment: setting LANGUAGE=de_AT:de
dbus-update-activation-environment: setting XDG_SESSION_TYPE=x11
dbus-update-activation-environment: setting HOME=/home/enno
dbus-update-activation-environment: setting DESKTOP_SESSION=lightdm-xsession
dbus-update-activation-environment: setting XDG_SEAT_PATH=/org/freedesktop/Displ
ayManager/Seat0
dbus-update-activation-environment: setting 
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting LOGNAME=enno
dbus-update-activation-environment: setting XDG_SESSION_CLASS=user
dbus-update-activation-environment: setting 
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
dbus-update-activation-environment: setting GDM_LANG=de_AT.utf8
dbus-update-activation-environment: setting 
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session2
dbus-update-activation-environment: setting XDG_RUNTIME_DIR=/run/user/1000
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting LANG=de_AT.UTF-8
dbus-update-activation-environment: setting XDG_SESSION_DESKTOP=lightdm-xsession
dbus-update-activation-environment: setting XAUTHORITY=/home/enno/.Xauthority
dbus-update-activation-environment: setting 
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/enno
dbus-update-activation-environment: setting SHELL=/bin/bash
dbus-update-activation-environment: setting GDMSESSION=lightdm-xsession
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting 
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
dbus-update-activation-environment: setting PWD=/home/enno
"""citation end"""

I'm at a loss.

--
  //   enno@gmx.net
/\\\   Mag. Enno Deimel
  .\o
 \\  \ _  \Wisely and slow; they stumble that run fast.
\\\ \_/
gpg-fp: eefe b049 6fe6 fc0b 0ec4  f39e af6a c178 eb98 909a

Bug#966483: iptables-netflow: sourcing of external scripts in dkms file?

[Axel Beckert]

Control: tag -1 - confirmed + moreinfo

Hi Gianfranco,

now that Bullseye is released and I'm preparing the upload of a new
upstream release, I've revisited this bug report.

Gianfranco Costamagna wrote:
> > Yeah, and the version.sh call itself can be removed, too. Will do.

Planned to do that(*), but …

> Unfortunately, it became a little difficult to implement, due to the 
> version.sh file
> not being easy to convert into a "sed s/FOO/foo/g < dkms.in > dkms"
> 
> This is what I did before thinking it was not easily upstreamable:

… now you've lost me complete.

Was that meant as patch to apply to the package? Or was it just a
historical digression?

If this was meant as to be included, I assume that file name was still
preliminary:

> --- iptables-netflow-2.5/debian/patches/patch 1970-01-01 01:00:00.0 
> +0100
> +++ iptables-netflow-2.5/debian/patches/patch 2020-08-11 21:00:13.0 
> +0200

And the entry in debian/patches/series seems missing, too.

> Feel free to send it upstream if you like it!

Admittedly it looks more complicated than necessary. And despite
having reread the whole bug report at least twice, I'm no more seeing
the motivation for this, also because dkms itself has been fixed by
you.

Actually I'm not even seeing the motivation to remove that
popd/pushd/version.sh part anymore. Sorry.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#992908: awesome: autopkgtest regression between 20 and 23 August 2021: Could not resolve keysym

[Paul Gevers]

Source: awesome
Version: 4.3-5
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer,

Your package has an autopkgtest, great! However, since this week
(somewhere between 20 August and 23 August 2021) it started to fail [1].
Can you look at it and fix the situation?

Paul

[1] https://ci.debian.net/packages/a/awesome/testing/amd64/

autopkgtest [13:23:59]: test integration.sh: [---
awesome_log: /tmp/tmp.Tu7TMRXwgL/_awesome_test.log
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error:   Could not resolve keysym XF86BrightnessAuto
> Internal error:   Could not resolve keysym XF86DisplayOff
> Internal error:   Could not resolve keysym XF86Info
> Internal error:   Could not resolve keysym XF86AspectRatio
> Internal error:   Could not resolve keysym XF86DVD
> Internal error:   Could not resolve keysym XF86Audio
> Internal error:   Could not resolve keysym XF86ChannelUp
> Internal error:   Could not resolve keysym XF86ChannelDown
> Internal error:   Could not resolve keysym XF86Break
> Internal error:   Could not resolve keysym XF86VideoPhone
> Internal error:   Could not resolve keysym XF86ZoomReset
> Internal error:   Could not resolve keysym XF86Editor
> Internal error:   Could not resolve keysym XF86GraphicsEditor
> Internal error:   Could not resolve keysym XF86Presentation
> Internal error:   Could not resolve keysym XF86Database
> Internal error:   Could not resolve keysym XF86Voicemail
> Internal error:   Could not resolve keysym XF86Addressbook
> Internal error:   Could not resolve keysym XF86DisplayToggle
> Internal error:   Could not resolve keysym XF86SpellCheck
> Internal error:   Could not resolve keysym XF86ContextMenu
> Internal error:   Could not resolve keysym XF86MediaRepeat
> Internal error:   Could not resolve keysym XF8610ChannelsUp
> Internal error:   Could not resolve keysym XF8610ChannelsDown
> Internal error:   Could not resolve keysym XF86Images
> Internal error:   Could not resolve keysym XF86NotificationCenter
> Internal error:   Could not resolve keysym XF86PickupPhone
> Internal error:   Could not resolve keysym XF86HangupPhone
> Internal error:   Could not resolve keysym XF86Fn
> Internal error:   Could not resolve keysym XF86Fn_Esc
> Internal error:   Could not resolve keysym XF86FnRightShift
> Internal error:   Could not resolve keysym XF86Numeric0
> Internal error:   Could not resolve keysym XF86Numeric1
> Internal error:   Could not resolve keysym XF86Numeric2
> Internal error:   Could not resolve keysym XF86Numeric3
> Internal error:   Could not resolve keysym XF86Numeric4
> Internal error:   Could not resolve keysym XF86Numeric5
> Internal error:   Could not resolve keysym XF86Numeric6
> Internal error:   Could not resolve keysym XF86Numeric7
> Internal error:   Could not resolve keysym XF86Numeric8
> Internal error:   Could not resolve keysym XF86Numeric9
> Internal error:   Could not resolve keysym XF86NumericStar
> Internal error:   Could not resolve keysym XF86NumericPound
> Internal error:   Could not resolve keysym XF86NumericA
> Internal error:   Could not resolve keysym XF86NumericB
> Internal error:   Could not resolve keysym XF86NumericC
> Internal error:   Could not resolve keysym XF86NumericD
> Internal error:   Could not resolve keysym XF86CameraFocus
> Internal error:   Could not resolve keysym XF86WPSButton
> Internal error:   Could not resolve keysym XF86CameraZoomIn
> Internal error:   Could not resolve keysym XF86CameraZoomOut
> Internal error:   Could not resolve keysym XF86CameraUp
> Internal error:   Could not resolve keysym XF86CameraDown
> Internal error:   Could not resolve keysym XF86CameraLeft
> Internal error:   Could not resolve keysym XF86CameraRight
> Internal error:   Could not resolve keysym XF86AttendantOn
> Internal error:   Could not resolve keysym XF86AttendantOff
> Internal error:   Could not resolve keysym XF86AttendantToggle
> Internal error:   Could not resolve keysym XF86LightsToggle
> Internal error:   Could not resolve keysym XF86ALSToggle
> Internal error:   Could not resolve keysym XF86Buttonconfig
> Internal error:   Could not resolve keysym XF86Taskmanager
> Internal error:   Could not resolve keysym XF86Journal
> Internal error:   Could not resolve keysym XF86ControlPanel
> Internal error:   Could not resolve keysym XF86AppSelect
> Internal error:   Could not resolve keysym XF86Screensaver
> Internal error:   Could not resolve keysym XF86VoiceCommand
> Internal error:   Could not resolve keysym XF86Assistant
> Internal error:   Could not resolve keysym XF86BrightnessMin
> Internal error:   Could not resolve keysym XF86BrightnessMax
> Internal error:   Could not resolve keysym XF86KbdInputAssistPrev
> Internal error:   Could not resolve keysym XF86KbdInputAssistNext
> Internal error:   Could not resolve keysym XF86KbdInputAssistPrevgroup
> Internal error:   Could not resolve keysym XF86KbdInputAssistNextgroup
> Internal 

Bug#992909: xen-utils-4.14: please stop recommending libc6-xen on i386

[Aurelien Jarno]

Package: xen-utils-4.14
Version: 4.14.2+25-gb6a8c4f72d-2
Severity: minor

Dear maintainer,

Due to the removal of 32-bit PV in Linux kernel 5.9 and the removal of
the "nosegneg" hwcap from glibc 2.32, the libc6-xen package is not build
anymore by the glibc package. This is already the case in experimental,
and will be soon the case in testing. Could you please update
xen-utils-4.14 to stop recommending this package?

Thanks,
Aurelien

Bug#992888: libpam0g: postinst fails on non-systemd services

[Ray Klassen]

This might be a misunderstanding. The problem happens during install of the 
package. If d-i refers to the initial installer then no it isn't a d-i bug


On Tue, 24 Aug 2021 12:31:06 -0600 Sam Hartman  wrote:
> > "Ray" == Ray Klassen  writes:
>
> Ray> Package: libpam0g Version: 1.4.0-9 Severity: important Tags:
> Ray> d-i X-Debbugs-Cc: rklas...@communitascare.com
>
> Ray> Dear Maintainer,
>
> How is this a d-i bug?
>
>

Bug#992092: king: contains a file with a non-free "disparaging to Sun" license

[Pierre Gruet]

Control: tag -1 confirmed


Hi,

For the record, this text concerns 12 icons that are in 
king/resource/king/images. The problematic text is also in a file in 
this folder.


I offer to create DFSG-free icons to replace those ones.

Best,

--
Pierre

Bug#992784: cups: libcupsimage2 not a dependancy

[Alain Bertrand]

Hello,

Thanks for your answer. The log is attached.

BTW :

Canon_LBP113_LBP913_USB_ could print both the test page and a page taken from 
the first pdf file I found,

Canon_LBP113_913_UFRII_LT could not. This is the situation that made me install 
libcupsimage2.

So I guess you'll close the bug for good now. Sorry for wasting your time.

Best regards,


Alain

On 24/08/2021 18:39, Brian Potkin wrote:

On Tue 24 Aug 2021 at 16:54:31 +0200, Alain Bertrand wrote:


Hello,

Thanks for your answer. With libcupsimage2 installed, everything works as it
should. Anyway, you'll find the output you wanted below.

lpstat -t
scheduler is running
no system default destination
matériel pour Canon_LBP113_913_UFRII_LT : socket://192.168.8.105

This print queue uses a netork connection. UFRII indicates a non-free
Canon driver is being used with the queue. Problems involving this
driver are not ours and the queue will not be debugged.


matériel pour Canon_LBP113_LBP913 : implicitclass://Canon_LBP113_LBP913/

This looks like another network queue, auto-setup by cups-browsed.


matériel pour Canon_LBP113_LBP913_USB_ : 
implicitclass://Canon_LBP113_LBP913_USB_/

This queue uses a USB connection and is also auto-setup by cups-browsed.

Let's take the  queue and test, but first

   apt purge libcupsimage2

It can easily be re-installed if needed. Now (as root)

  cupsfilter -p /etc/cups/Canon_LBP113_LBP913_USB_.ppd -m priner/foo -e 
/etc/nsswitch.conf > out.dat 2>log

(Check that I have the correct PPD file name).

Please attach log to your next post here. It may be viewed with 'less'.

Cheers,

Brian.



DEBUG: argv[0]="cupsfilter"
DEBUG: argv[1]="1"
DEBUG: argv[2]="root"
DEBUG: argv[3]="nsswitch.conf"
DEBUG: argv[4]="1"
DEBUG: argv[5]=""
DEBUG: argv[6]="/etc/nsswitch.conf"
DEBUG: envp[0]=""
DEBUG: envp[1]="CONTENT_TYPE=text/plain"
DEBUG: envp[2]="CUPS_DATADIR=/usr/share/cups"
DEBUG: envp[3]="CUPS_FONTPATH=/usr/share/cups/fonts"
DEBUG: envp[4]="CUPS_SERVERBIN=/usr/lib/cups"
DEBUG: envp[5]="CUPS_SERVERROOT=/etc/cups"
DEBUG: envp[6]="LANG=fr_FR.UTF8"
DEBUG: envp[7]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin:/usr/bin"
DEBUG: envp[8]="PPD=/etc/cups/ppd/Canon_LBP113_LBP913_USB_.ppd"
DEBUG: envp[9]="PRINTER_INFO=cupsfilter"
DEBUG: envp[10]="PRINTER_LOCATION=Unknown"
DEBUG: envp[11]="PRINTER=cupsfilter"
DEBUG: envp[12]="RIP_MAX_CACHE=128m"
DEBUG: envp[13]="USER=root"
DEBUG: envp[14]="CHARSET=utf-8"
DEBUG: envp[15]="FINAL_CONTENT_TYPE=application/vnd.cups-pdf"
INFO: texttopdf (PID 3359) started.
INFO: pdftopdf (PID 3360) started.
DEBUG: Page = 595x842; 14,14 to 581,828
ERROR: pdftopdf: Last filter could not get determined, page logging turned off.
DEBUG: pdftopdf: Last filter determined by the PPD: None; FINAL_CONTENT_TYPE: 
application/vnd.cups-pdf => pdftopdf will not log pages in page_log.
INFO: texttopdf (PID 3359) exited with no errors.
DEBUG: PDF interactive form and annotation flattening done via QPDF
INFO: pdftopdf (PID 3360) exited with no errors.

Bug#992892: Please package 0.10.2

[Emmanuel Arias]

Hi, 

I've just push to salsa the new upstream release.

I will need help to upload :)

Cheers, 
eamanu

Bug#988596: akonadi-server: akonadi crashes permanently; akonadiconsole does not start

[Matteo Semplice]

Hi.

Same issue on my machine after upgrading it to Debian 11.

The file .local/share/akonadi/Akonadi.error contains

2021-08-24T18:02:17 [WARN ] default: Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
2021-08-24T18:04:38 [WARN ] org.kde.pim.akonadicontrol: ProcessControl: 
Application '/usr/bin/akonadiserver' returned with exit code 253 (Errore 
sconosciuto)
2021-08-24T18:05:39 [WARN ] org.kde.pim.akonadicontrol: ProcessControl: 
Application '/usr/bin/akonadiserver' returned with exit code 253 (Errore 
sconosciuto)


Thanks,

    Matteo

Bug#992480: debianutils: Translated man pages for which(1) not handled by alternatives

[Clint Adams]

On Tue, Aug 24, 2021 at 03:43:20PM -0400, Boyuan Yang wrote:
> I believe all translated man pages located in /usr/share/man/*/man1/which.1.gz
> will need to be handled by the alternatives system first, which need some more
> changes from the debianutils side.

Correct.

Bug#978794: crac: ftbfs with autoconf 2.70

[Matthias Klose]

On 8/24/21 9:36 PM, Nilesh Patra wrote:
> control: tags -1 moreinfo
> 
> Hi Matthias,
> 
> I admit that I do not get any failures on build, same for several other
> bugs, for instance #978784
> 
> I've triple-checked that my environment is updated, and I'm using
> version 2.71-2 of autoconf
> 
> Are these somehow false-positive in any case?
> If so, will there be a re-build soonish?
> 
> Please do let me know
> Thanks a lot for your work!
> 
> Nilesh
> 


just close.

Bug#992907: gtk4: release to unstable

[Simon McVittie]

Source: gtk4
Version: 4.4.0+ds1-1
Severity: wishlist
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
Control: block -1 by 992857
Control: block -1 by 991964
Control: block -1 by 992906

We should get gtk4 into testing/unstable during the bookworm cycle.
Until a new 4.6.x stable branch starts, I think we should avoid uploading
4.5.x to experimental, and instead get 4.4.x into shape for testing/unstable.

Blockers:

- Needs a new wayland-protocols: #992857

- Needs a new pango: #992906

- We should fix the incomplete move from @substitutions@ to debhelper
  environment variable substitutions: #991964

- For at least initial uploads to unstable, I think we should disable
  FFmpeg and Vulkan, both considered experimental upstream (I've disabled
  FFmpeg for uploads not targeting experimental, and Vulkan entirely)

- Do we want to disable the Broadway backend? It's not clear to me that
  anyone actually uses Broadway - it seems more like a proof of concept
  than something genuinely useful. Perhaps we disable it until someone
  asks for it to be enabled?

Anything else?

smcv

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

[Phillip Susi]

Ben Hutchings  writes:

> I think a proper fix would be one of:
>
> a. If the Xen virtual keyboard driver is advertising capabilities it
>doesn't have, stop it doing that.
> b. Change the implementation of modalias attributes to allow longer
>values.
>
> It's not clear to me whether the Xen driver is advertising correctly or
> not.  If it is, then the solution should be b, but that may be too
> disruptive a change to the kernel.  So a reasonable workaround might
> be:
>
> c. Change the input subsystem to limit the length of the
>capabilities part of the modalias.

The problem with a) is that the Xen keyboard is not a physical keyboard
and so it has no way of knowing what keys it actually has.  It is a fake
input device designed to pass through whatever input the Xen hypervisor
sends down.  As such, any key could come in.  If it doesn't advertise
that it has all of these keys, then they would not be accepted by
libinput when the hypervisor sends them down.

This seems to be the heart of the problem: libinput was designed
assuming that all keyboards can and must report what keys are actually
present, and then libinput tries to cram that information into the
modalias rather than some other sysfs attribute as it should ( or not at
all... I still don't see how this information is actually supposed to be
useful to userspace ).

As for b), the problem isn't with the modalias attribute itself, but
when the kernel tries to copy it into the environment block for the udev
callout.  The environment block is only a single page, and so limited to
4 KB.  And that's for everything else that goes into the environment,
not just the modalias.

Bug#947261: ITP: python-poetry -- Python dependency management and packaging made easy

[Emmanuel Arias]

Hi Tai,

Yes, it is.

Thanks!


On Tue, Aug 17, 2021 at 4:15 PM Taihsiang Ho (tai271828) <
taihsian...@ubuntu.com> wrote:

> Hi Emmanuel,
>
> Thank you for the update. Is this the DPT thread?
> https://lists.debian.org/debian-python/2021/06/msg00017.html
> If yes, I will give it a try and update my progress on the thread.
>
> Cheers,
> Tai
>
> On Sun, Jun 20, 2021 at 12:12 AM Emmanuel Arias 
> wrote:
>
>> Hello!
>>
>> On 6/17/21 6:00 PM, Taihsiang Ho (tai271828) wrote:
>> > Hi Emmanuel,
>> >
>> > I can help as a poetry user for a while if you don't mind. It seems
>> that I
>> > could reproduce the pytest-mock issue by building this poetry deb
>> source[1]
>> > with Ubuntu 21.04. For better communication, I am wondering the
>> following
>>
>> I fixed with this patch [0].
>>
>> I guess I finished a first complete package of poetry. Please look in
>> the DPT
>> mailing list.
>>
>>
>> [0]
>>
>> https://salsa.debian.org/python-team/packages/poetry/-/blob/debian/master/debian/patches/0002-Fix-incompatibility-between-pytest-and-pytest-mock.patch
>>
>> Cheers
>>
>> --
>> Emmanuel Arias
>> @eamanu
>> yaerobi.com
>>
>>

Bug#992480: debianutils: Translated man pages for which(1) not handled by alternatives

[Boyuan Yang]

Hi,

在 2021-08-20星期五的 13:01 +，Clint Adams写道：
> On Thu, Aug 19, 2021 at 01:23:45AM -0400, Boyuan Yang wrote:
> > Thanks for managing /usr/bin/which under alternatives system. However, the
> > translated man pages for which command (such as
> > /usr/share/man/pl/man1/which.1.gz) are not handled by alternatives system.
> > This won't cause issues in near future, but we have a possibility for file
> > collision after different which(1) implementations are packaged.
> > 
> > Currently I don't have a good solution for it. Maybe we can think more?
> 
> If I understand the update-alternatives documentation correctly, it
> won't cause a problem to add the slave links for those translations
> even if your package doesn't provide them.

I have the same understanding. However, according to
https://sources.debian.org/src/debianutils/5.4-2/debian/postinst/ ,
debianutils obviously also did not add slave links for translation files. If
one package uses the alternatives system to handle a file while the other
package does not, there will be some problem.

>  Do you read it differently,
> or were you concerned about something else?

I believe all translated man pages located in /usr/share/man/*/man1/which.1.gz
will need to be handled by the alternatives system first, which need some more
changes from the debianutils side.

Thanks,
Boyuan Yang

Bug#909228: RFP: loop -- "UNIX's missing loop command!"

[Joshua Peisach]

>  Well, then good luck with search of sponsor/maintainer

I don't think you were trying to ride off a "I hope someone will want to pick 
this up", but if you were then he doesn't need any. I'll take care of it. Per 
rust packaging team standards, this should be converted into an ITP. ("Don't 
file ITPs for library crates, but do file them for binary crates.")

In reality I just need to contribute more to Debian so I can do more stuff with 
Cinnamon, but a small package like this should be easy to maintain, and with 
debcargo it should be an easy chore.

Bug#978794: crac: ftbfs with autoconf 2.70

[Nilesh Patra]

control: tags -1 moreinfo

Hi Matthias,

I admit that I do not get any failures on build, same for several other
bugs, for instance #978784

I've triple-checked that my environment is updated, and I'm using
version 2.71-2 of autoconf

Are these somehow false-positive in any case?
If so, will there be a re-build soonish?

Please do let me know
Thanks a lot for your work!

Nilesh


signature.asc
Description: PGP signature

Bug#992906: pango1.0: New upstream release 1.48.x

[Simon McVittie]

Source: pango1.0
Version: 1.46.2-3
Severity: wishlist
Tags: fixed-upstream bookworm sid
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org
Control: fixed -1 1.48.9+ds1-1

We should get pango1.0/1.48.x ready for unstable. This is a blocker for
the upload of GTK 4 to unstable.

Have regressions been seen in Ubuntu?

There is a bug open about upstream reducing what they consider to be
part of the public API/ABI, resulting in incompatible changes to structs
that were formerly public (#974140), which happened between buster and
bullseye but has changed more between bullseye and 1.48.x. I'm sorry,
I don't have enough spoons to either persuade the bug submitter that
they are doing something unsupported, or persuade upstream that they need
to revert changes or bump the SONAME - both seem like unwinnable fights
that I don't want to get involved with. I think it's pretty clear that
we can't stay on last year's version indefinitely, though...

Are there any other known blockers?

smcv

Bug#992905: src:perceptualdiff: fails to migrate to testing for too long due to ftbfs

[Paul Gevers]

Source: perceptualdiff
Version: 1.2-2
Severity: serious
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:perceptualdiff has been trying to migrate for 224 days [2] (yes, I
know, big part during the freeze). Hence, I am filing this bug.

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

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

I have tagged this bug to only affect sid and bookworm, so it doesn't
affect (old-)stable.

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#992901: src:perceptualdiff: fails to migrate to testing for too long due to ftbfs on armel

[Paul Gevers]

Control: reassign -1 src:geary 3.38.1-1

Oops, I mixed two submissions. This text should have gone to geary (the
one for perceptualdiff will follow shortly).

Paul

On Tue, 24 Aug 2021 21:22:16 +0200 Paul Gevers  wrote:
> Source: perceptualdiff
> Version: 1.2-2
> Severity: serious
> Tags: sid bookworm ftbfs
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> As recently announced [1], the Release Team now considers packages that
> are out-of-sync between testing and unstable for more than 60 days as
> having a Release Critical bug in testing. Your package
> src:perceptualdiff has been trying to migrate for 224 days [2] (yes, I
> know, mostly during the freeze). Hence, I am filing this bug.
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on
> other packages, which makes preparing for the release more difficult.
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that
> hamper the migration of their package in a timely manner.
> 
> Your package fails to build on armel [3]:
> Summary of Failures:
> 
> 7/7 geary / client-tests FAIL   33.45s
> (killed by signal 11 SIGSEGV)
> 
> Ok: 6
> Expected Fail:  0
> Fail:   1
> Unexpected Pass:0
> Skipped:0
> Timeout:0
> dh_auto_test: error: cd obj-arm-linux-gnueabi && LC_ALL=C.UTF-8
> MESON_TESTTHREADS=4 meson test returned exit code 1
> xvfb-run: error: problem while cleaning up temporary directory
> make[1]: *** [debian/rules:28: override_dh_auto_test] Error 5
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:21: binary-arch] Error 2
> 
> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.
> 
> I have tagged this bug to only affect sid and bookworm, so it doesn't
> affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to
> issues beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
> [2] https://qa.debian.org/excuses.php?package=perceptualdiff
> [3]
> https://buildd.debian.org/status/fetch.php?pkg=geary=armel=3.38.2-1=1626009864=0
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992904: shut-up build-depends on removed transitional package.

[peter green]

Source: shut-up
Version: 0.3.3-1
Severity: serious
Tags: bookworm, sid

shut-up build-depends on the s-el binary package which has been dropped
by the s-el source package. It is still present in unstable as a
cruft package but is completely gone from testing.

Since this package was previously an empty transitional package
it should be possible to simply update the dependency.

Bug#992903: node-matrix-js-sdk build-depends on removed virtual package node-olm

[peter green]

Package: node-matrix-js-sdk
Version: 9.3.0+~cs9.9.16-2
Severity: serious
Tags: bookworm, sid

node-matrix-js-sdk build-depends on node-olm, afaict this was previously a 
virtual package
provided by libjs-olm but is no longer provided. From reading the changelog it 
looks like
the replacement  virtual package is node-matrix-olm but that some adjustments 
may be needed.


   * update Node.js install path,
 and have libjs-olm provide node-matrix-org-olm (not node-olm)

Bug#992902: lizzie build-depends on removed package

[peter green]

package: lizzie
version: 0.7.4+dfsg1-2
severity: serious

lizzie build-depends on libjuniversalchardet-java-doc which is no longer built 
by the
libjuniversalchardet-java source package. It is still present in unstable as a 
cruft
package but is completely gone from testing.

Bug#992901: src:perceptualdiff: fails to migrate to testing for too long due to ftbfs on armel

[Paul Gevers]

Source: perceptualdiff
Version: 1.2-2
Severity: serious
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:perceptualdiff has been trying to migrate for 224 days [2] (yes, I
know, mostly during the freeze). Hence, I am filing this bug.

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

Your package fails to build on armel [3]:
Summary of Failures:

7/7 geary / client-tests FAIL   33.45s
(killed by signal 11 SIGSEGV)

Ok: 6
Expected Fail:  0
Fail:   1
Unexpected Pass:0
Skipped:0
Timeout:0
dh_auto_test: error: cd obj-arm-linux-gnueabi && LC_ALL=C.UTF-8
MESON_TESTTHREADS=4 meson test returned exit code 1
xvfb-run: error: problem while cleaning up temporary directory
make[1]: *** [debian/rules:28: override_dh_auto_test] Error 5
make[1]: Leaving directory '/<>'
make: *** [debian/rules:21: binary-arch] Error 2

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

I have tagged this bug to only affect sid and bookworm, so it doesn't
affect (old-)stable.

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

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=perceptualdiff
[3]
https://buildd.debian.org/status/fetch.php?pkg=geary=armel=3.38.2-1=1626009864=0



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992200: perl: regen-configure orig tarball file exclusions

[Niko Tyni]

On Sun, Aug 15, 2021 at 08:00:42PM +0300, Niko Tyni wrote:
> Source: perl
> Version: 5.32.1-5

> I'm somewhat at loss. While I'd like to drop the repacking, it seems
> that keeping it is a safer course to make sure we ship things with their
> source.
> 
> If we keep the repacking, we should at least add a sanity check to make
> sure we don't accidentally import pristine tarballs anymore.

FWIW at least for 5.34.0 I'm currently inclined to keep the repacking
and add a sanity check to make sure the recipe was followed. We can
revisit this later if necessary.
-- 
Niko

Bug#914128: perl: usrmerge issues

[Niko Tyni]

On Thu, Jul 15, 2021 at 04:36:10PM -0700, Vagrant Cascadian wrote:
> On 2021-07-15, Vagrant Cascadian wrote:
> > On 2018-11-19, Niko Tyni wrote:
> >> Diffoscoping a perl built on a usrmerged [1] system with
> >> one built on a non-usrmerged system reveals the configure
> >> process hardcoding some paths in the build results,

> With all three patches applied, perl builds reproducibly!

Many thanks!

> Attached patch also fixes these issues, by adjusting libpth and libspath
> in debian/config.over ... it feels a little hackish ... but ...

Yeah. The "pristine" probed values of libpth and libspath on a
non-usrmerged system look messy enough (/lib/../lib and the like) that
it might be more robust to just override them to some cleaner hardcoded
values rather than have more logic that tries to imitate the mess on
usrmerged systems. But I'll see how that works out.

I'll try to get this fixed in 5.34 / experimental soonish, but it might
only enter sid with the 5.34 transition that we should really start
driving. 5.32 is not a development priority at this point. (No need to
rebase the patches or anything though, happy to handle that.)
-- 
Niko Tyni   nt...@debian.org

Bug#992900: epl build-depends on removed transitional package.

[peter green]

Source: epl
Version: 0.9-3
Severity: serious
Tags: bookworm, sid

epl build-depends on the s-el binary package which has been dropped
by the s-el source package. It is still present in unstable as a
cruft package but is completely gone from testing.

Since this package was previously an empty transitional package
it should be possible to simply update the dependency.

Bug#992899: src:dub: fails to migrate to testing for too long

[Paul Gevers]

Source: dub
Version: 1.22.0-1
Severity: serious
Control: close -1 1.24.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:dub has been
trying to migrate for 209 days [2] (yes, I know, mostly during the
freeze). Hence, I am filing this bug.

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#992898: debian-design build-depends on obsolete version of boxer-data

[peter green]

Package: debian-parl
Version: 1.9.27
Severity: serious
Tags: bookworm, sid

Debian-parl has a build-dependency on boxer-data (< 10.9) but testing and 
unstable
have version 10.9.1

Bug#992897: debian-design build-depends on obsolete version of boxer-data

[peter green]

Package: debian-design
Version: 3.0.22
Severity: serious

Debian-design has a build-dependency on boxer-data (< 10.9) but testing and 
unstable
have version 10.9.1

Bug#992896: etbemon: FTBFS due to RPC removal from glibc

[Aurelien Jarno]

Source: etbemon
Version: 1.3.5-7
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

The glibc SunRPC implementation has been marked obsolete for some time.
It has been removed upstream from glibc 2.32, and it got disabled in the
recent glibc uploads. The TI RPC implementation should be used instead,
which also brings new features (IPv6, Kerberos support, ...).

Your recent package upload failed to build in sid for that reason. You
will find attached a patch to switch to the TI RPC implementation,
fixing the FTBFS.

Regards,
Aurelien
diff -u etbemon-1.3.5/debian/control etbemon-1.3.5/debian/control
--- etbemon-1.3.5/debian/control
+++ etbemon-1.3.5/debian/control
@@ -4,7 +4,7 @@
 Maintainer: Debian Mon Maintainers 

 Uploaders: Dario Minnucci ,
  Russell Coker 
-Build-Depends: debhelper (>= 11), perl, libtime-period-perl
+Build-Depends: debhelper (>= 11), perl, libtime-period-perl, libtirpc-dev
 Standards-Version: 4.3.0
 Homepage: https://doc.coker.com.au/projects/etbe-mon/
 Vcs-Git: https://salsa.debian.org/etbe/etbemon.git
only in patch2:
unchanged:
--- etbemon-1.3.5.orig/mon.d/Makefile
+++ etbemon-1.3.5/mon.d/Makefile
@@ -6,7 +6,8 @@
 CC = gcc
 CFLAGS = `dpkg-buildflags --get CFLAGS`
 LDFLAGS = `dpkg-buildflags --get LDFLAGS`
-LDLIBS =
+INCFLAGS = -I/usr/include/tirpc
+LDLIBS = -ltirpc
 # uncomment next line for Solaris
 # LDLIBS = -lnsl -lsocket
 
@@ -20,7 +21,7 @@
 all: $(PROGS)
 
 rpc.monitor: rpc.monitor.c
-   $(CC) -o rpc.monitor $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) rpc.monitor.c 
$(LDLIBS)
+   $(CC) -o rpc.monitor $(CFLAGS) $(CPPFLAGS) $(INCFLAGS) $(LDFLAGS) 
rpc.monitor.c $(LDLIBS)
 
 dialin.monitor.wrap: dialin.monitor.wrap.c
$(CC) -o dialin.monitor.wrap $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) \

Bug#992895: src:python-xarray: fails to migrate to testing for too long

[Paul Gevers]

Source: python-xarray
Version: 0.16.2-2
Severity: serious
Control: close -1 0.19.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:python-xarray
has been trying to migrate for 178 days [2] (yes, most of that time was
during the freeze). Hence, I am filing this bug.

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#991788: Disabling Upower support in xfce4-settings

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: severity -1 normal

On Tue, 2021-08-17 at 22:05 +0200, truetec...@tutanota.com wrote:
> Hello,
> 
> When compiled with --enable-upower-glib, xfce4-power-manager doesn't seem to
> re-enable laptop displays after suspending the system. And, for that reason,
> this is disabled by default upstream... but it was explicitly re-enabled in
> Debian for some reason.  I reported this issue as a critical bug under
> #991788 in xfce4-settings and was told that xfce4 maintainers in Debian
> would have to decide whether or not to change this. However, it has been a
> while and I want to bring attention to it further, especially as an update
> without attention to this feature has already been pushed to unstable.
> 
> Upstream bug report:
> https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/222
> Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991788
> 
Hi Elliot,

thanks for the message, but it's usually best to directly send messages to the
bug report, that way it's archived on the bug tracker (sorry we didn't reply
earlier on it).

That's definitely not a “critical” bug though (thus adjusting the severity).
And unfortunately the “upstream” fix isn't really good because that actually
means just not listening to the lid events, and that's a behavior which I
think we do want.

As far as I can tell it does work fine on other configurations, but maybe
there's an issue with the proprietary NVidia driver (if you can try with
nouveau or something like that, it'd be an interesting data point).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmElQ6kACgkQ3rYcyPpX
RFsP2Qf/aaipVYYhL8CdBZ3oL6xF72n3JNhCPOIvCggH+5BAKHG/xdgROsalKJLd
l0mI8kHqqotc7SBWd6Rlndz26SvxTMgcIZ5rxrevkq05e8zzhystfCtqK8kIGs1+
LzHA+yS1kPrGqx170I4Dkw/EtdLovXOvJFQwGcGZDvqFq1IEAtvwg3m7OaN06xWj
WTYnVPF2ByzC6g3t5VAUglKG8AwKS65fmAJzauv/iCF28QApYcUchQhDu4mLy/Rm
TmdWjT/n0Fv2IZiB6HMbGzB8o0p86niUb4+RgKZ58RV1a89exRG6i7vuVt/BAPpF
BohukQsr4iVsA5+GyWF0gnY3IZR9Pg==
=1nfL
-END PGP SIGNATURE-

Bug#992894: src:mit-scheme: fails to migrate to testing for too long

[Paul Gevers]

Source: mit-scheme
Version: 10.1.11-2
Severity: serious
Control: close -1 11.2-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:mit-scheme
has been trying to migrate for 196 days [2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#983357: Netinst crashes xen domU when loading kernel

[Chuck Zmudzinski]

On 5/24/2021 3:30 AM, Michael Biebl wrote:

Hi Phillip

Am 24.05.2021 um 06:19 schrieb Cyril Brulebois:

trigger to cold plug all devices.  Both scripts are set -e.  The Xen
Virtual Keyboard driver and at least one other driver have always 
failed

to trigger due to having absurdly long modalias, but the error used to
be ignored.  The kernel now returns the error to udevadm


So this is a change in behaviour in the kernel?
What happens if you boot the installed system? Does udevadm trigger 
fail there as well?


I feel a bit uneasy changing the udev start script this late in the 
release cycle (especially when it appears like covering up an issue 
someplace else).


I'll let Marco make the judgement on this though, as he has the most 
experience with those udev udeb start scripts as the original author.


Michael



After reviewing Philip's message at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#43

which seems to point to the root cause of this bug, I can add:

On my Xen HVM DomU I see the absurdly long modalias for the Xen
Virtual keyboard that seems to be causing this crash in sysfs at

/sys/devices/virtual/input/input2/modalias

But at /sys/devices/vkbd-0/modalias, I see just 'xen:vkbd', which would
probably not result in an error in the udev script if this was also
written as the modalias at /sys/devices/virtual/input/input2/modalias

So the Xen virtual keyboard appears more than once in sysfs, and
modalias is not the same in the different places. This seems
to be a problem.

I understand the correct way to fix this bug is by modifying the
Xxen virtual keyboard (and any other devices that might cause
this crash) and not the start-udev script on the netinst
installation media, which is so far the only available workaround.
Hopefully Xen will accept a fix if we can come up with a fix.

I am willing to try to debug this by testing patches to the Xen
virtual keyboard, and anyone who has any tips on how
udev works would be helpful. Is there documentation in udev for
device developers somewhere to consult that explains how to
update old device drivers so they are compatible with the
modern version? Does the Xen virtual keyboard need to be
managed by udev? Is there a simple way to disable incompatible
devices so udev ignores them?

Chuck Zmudzinski

Bug#992863: buster-pu: package modsecurity-crs/3.1.0-1

[Alberto Gonzalez Iniesta]

Hi Salvatore!!

On Tue, Aug 24, 2021 at 03:17:36PM +0200, Salvatore Bonaccorso wrote:
> Hi Alberto,
> 
> On Tue, Aug 24, 2021 at 01:57:26PM +0200, Alberto Gonzalez Iniesta wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: buster
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > Hi,
> > 
> > This [1] security bug was found in modsecurity-crs.
> > As with the previous update (modsecurity-crs_3.1.0-1+deb10u1), a DSA
> > does not seem necessary (security team on Cc:) so I'm targeting buster
> > proposed updates instead.
> > 
> > Here's the debdiff. Hope it's all OK.
> > 
> > I'll wait for your instructions before uploading.
> 
> Correct, we marked the CVE as no-dsa for both buster an bullseye. I
> would suggest to first fix this in unstable, which is sort of
> aprerequisite to get the fix in stable and oldstable via the point
> releases.

Yes, updated package got in unstable today.

> Do you have an update as well pending for bullseye?

Yes, I'll open a new PU request for it too.

Thanks,

Alberto


-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#982907: init-system-helpers: use new needs-reload/needs-restart unit interface

[Niels Thykier]

Control: reassign -1 init-system-helpers

Reassigning to init-system-helpers, quoting in full for the
init-system-helpers maintainer's sake.

On Tue, 16 Feb 2021 21:46:28 +0100 Niels Thykier  wrote:
> Luca Boccassi:
> > Source: debhelper
> > Priority: wishlist
> > Tags: bookworm
> > X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org
> > 
> > Dear Maintainer(s),
> > 
> > systemd v248 will ship with a new dbus/systemctl interface to mark a
> > unit as needing reload/restart, and a new dbus/systemctl to queue all
> > reload/restart jobs in a single command.
> > The RPM packaging/scripts are changing to use this instead of custom
> > batching.
> > 
> > I'm opening this ticket to explore whether it would be
> > possible/good/desirable to switch the debhelper tools to use this as
> > well in the future.
> > 
> > It looks like this:
> > 
> > systemctl set-property foo.service Markers=needs-restart
> > systemctl set-property bar.service Markers=needs-reload
> > ...
> > systemctl reload-or-restart --marked
> > 
> > (or equivalent DBUS calls)
> > 
> > References:
> > 
> > https://github.com/systemd/systemd/commit/ff68472a20c208121b69ea13586f3105a219bc14
> > https://github.com/systemd/systemd/commit/c9615f73521986b3607b852c139036d58973043c
> > https://github.com/systemd/systemd/pull/18481/commits
> > 
> > The advantage being, you can mark a unit inline, but then batch the
> > actual jobs later/asynchronously.
> > 
> > Note that, given the interface has just been merged and is not yet
> > released, there is scope for improvements if there are debhelper-
> > specific concerns to address, given the feature first use is the RPM's
> > side of things.
> > 
> > Thoughts?
> > 
> 
> By the sound of it, this is something that might need to go into the
> init system helpers that debhelper invokes in the maintscripts (possibly
> with a trigger in the systemd side to do the batch reload/restart).
> 
> @Michael: What is your view?
> 
> ~Niels
> 
> 
> 

Bug#992893: ps2ascii: odd option handling

[наб]

Package: ghostscript
Version: 9.53.3~dfsg-7
Severity: minor
Tags: patch

Dear Maintainer,

ps2ascii handles default arguments really oddly, including shelling out
for each test (note the "()") and doesn't quote GS_EXECUTABLE,
unlike the other scripts in lib/; please consider the attached patch,
which also uses symbolic names for the trap signals

Best,
наб

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ghostscript depends on:
ii  libc6   2.28-10
ii  libgs9  9.27~dfsg-2+deb10u4

Versions of packages ghostscript recommends:
ii  gsfonts  1:8.11+urwcyr1.0.7~pre44-4.4

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.27~dfsg-2+deb10u4

-- no debconf information
--- ghostscript-9.53.3~dfsg.orig/lib/ps2ascii
+++ ghostscript-9.53.3~dfsg/lib/ps2ascii
@@ -9,13 +9,6 @@
 # executable name set in the makefile
 GS_EXECUTABLE=gs
 
-trap "rm -f _temp_.err _temp_.out" 0 1 2 15
+trap "rm -f _temp_.err _temp_.out" EXIT HUP INT TERM
 
-OPTIONS="-q -dSAFER -sDEVICE=txtwrite"
-if ( test $# -eq 0 ) then
-$GS_EXECUTABLE $OPTIONS -o - -
-elif ( test $# -eq 1 ) then
-$GS_EXECUTABLE $OPTIONS -o - "$1"
-else
-$GS_EXECUTABLE $OPTIONS -o "$2" "$1"
-fi
+"$GS_EXECUTABLE" -q -dSAFER -sDEVICE=txtwrite -o "${2:--}" "${1:--}"


signature.asc
Description: PGP signature

Bug#992888: libpam0g: postinst fails on non-systemd services

[Sam Hartman]

> "Ray" == Ray Klassen  writes:

Ray> Package: libpam0g Version: 1.4.0-9 Severity: important Tags:
Ray> d-i X-Debbugs-Cc: rklas...@communitascare.com

Ray> Dear Maintainer,

How is this a d-i bug?

Bug#992871: darkplaces: Segfault when using custom texturepack

[Sébastien Noel]

Package: darkplaces
Severity: normal

Dear Maintainer,

The current darkplaces debian packages segfault when using
"Rygel's ultra pack".

  PNG_LoadImage: warning: iCCP: known incorrect sRGB profile
  PNG_LoadImage: warning: Interlace handling should be turned on when 
using png_read_image

  [...]
  PNG_LoadImage: warning: Interlace handling should be turned on when 
using png_read_image

  PNG_fReadData: overrun by 8 bytes
  PNG_LoadImage: error: [00][00][00][00]: invalid chunk type
  libpng error: [00][00][00][00]: invalid chunk type
  Segmentation fault

Since this pack is linked from the original upstream project,
at https://icculus.org/twilight/darkplaces/download.html
under "Quake art enhancement projects", I suspected this was
a tested/validated configuration.

When using a recent upstream snapshot compiled by myself,
everything worked fine. So I started digging...
The problem disapers once I rebuild the debian package & replace
"DP_LINK_PNG=shared" by "DP_LINK_PNG=dlopen" in d/rules.
I wish I could more precisely spot the problem but my knowledge
about dlopen and all its mysteries ends pretty quickly...

Best Regards,
Sébastien

Bug#970926: dokuwiki: Decide to upgrade or remove dokuwiki from debian

[Romain]

Package: dokuwiki
Version: 0.0.20180422.a-2.1
Followup-For: Bug #970926

Dear Maintainer,

Bullseye is there and dokuwiki's version included in it is obsolete since 
2020-07-29.
The dokuwiki team officially says that we should not user any more the debian 
package of dokuwiki : https://www.dokuwiki.org/install:debian

Please make a decision : update or remove from the standard.

Regards

-- System Information:
Debian Release: 11.0
 

Bug#992889: /usr/sbin/update-gsfontmap: overly complicated

[наб]

Hi!

On Tue, Aug 24, 2021 at 07:30:31PM +0200, Jonas Smedegaard wrote:
> Quoting наб (2021-08-24 18:58:36)
> > The current approach that update-gsfontmap takes is very complicated, 
> > to no apparent end, since all it achieves is concatenating all the 
> > files; please consider the attached patch, which applies to every 
> > version since 7e78b19759ab1e47a3636ffd5c922c536e6cad37 (November of 
> > 2018)
> Your assesment is quite likely correct: that script hasn't been touched 
> since ancient times where more complex font registration scripts were 
> used in Debian (something called DeFoMa).
The DeFoMa page on the Debian Wiki and the corresponding manpage are an
interesting look down history lane (ancient history, I seem to've been
around 10 during the transition), thanks!

> Seems your patch is missing, however...
It's attachment 2, debbugs caught it:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=992889;msg=5

I've included it in this mail, too, for good measure.

Best,
наб
diff --git a/debian/update-gsfontmap.orig b/debian/update-gsfontmap
index 5367ff6..c105363 100644
--- a/debian/update-gsfontmap.orig
+++ b/debian/update-gsfontmap
@@ -8,15 +8,7 @@ FONTMAP=/var/lib/ghostscript/fonts/Fontmap
 CIDFDIR=/etc/ghostscript/cidfmap.d/
 FONTMDIR=/etc/ghostscript/fontmap.d/
 
-rm -f "$CIDFMAP" "$FONTMAP"
-touch "$CIDFMAP" "$FONTMAP"
-
-for i in "$CIDFDIR"/*.conf; do
-cat "$i" >> "$CIDFMAP"
-done 2>/dev/null
-
-for i in "$FONTMDIR"/*.conf; do
-cat "$i" >> "$FONTMAP"
-done 2>/dev/null
+cat "$CIDFDIR"/*.conf  > "$CIDFMAP" 2>/dev/null
+cat "$FONTMDIR"/*.conf > "$FONTMAP" 2>/dev/null
 
 exit 0


signature.asc
Description: PGP signature

Bug#992421: dnslookup_relay_to_domains probably needs ignore_target_hosts

[Andreas Metzler]

On 2021-08-18 Marc Haber  wrote:
> Package: exim4-config
> Version: 4.94.2-2~zg100+3
> Severity: normal

> Hi,

> I am not sure whether this is an actual bug. I have observed this
> behaviod on an exim that is backup MX for domain.example. The MX records
> are like:
> domain.example mail is handled by 0 mx.domain.example.
> domain.example mail is handled by 10 myexim.otherdomain.example.

> Both hosts have both IPv4 and IPv6 addresses in DNS; the local resolver
> on myexim.otherdomain.example resolves its own host name to 127.0.1.1 by
> virtue of the normal Debian /etc/hosts file.

> [36/5023]mh@q:~ $ sudo exim -bt lists@domain.example
> R: domain_literal for lists@domain.example
> R: dnslookup_relay_to_domains for lists@domain.example
> lists@domain.example
>   router = dnslookup_relay_to_domains, transport = remote_smtp
>   host mx.domain.example [IPv6 address] MX=0
>   host mx.domain.example [IPv4 address] MX=0
>   host myexim.otherdomain.example  [127.0.1.1]
>  MX=10
> [37/5024]mh@q:~ $

> If mx.domain.example refuses mail, the local exim happily delivers to itself, 
> causing a loop:
> 2021-08-18 08:06:15 1mGEiM-00089y-Vx <= 
> linux-staging+bounces-5545-lists=domain.exam...@lists.linux.dev H=localhost 
> (myexim.otherdomin.example) [127.0.0.1] P=esmtps 
> X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no K 
> S=14699 id=
[...]
> Or is exim supposed to never relay to itself automatically? If that is the
> case, more debugging is needed to find out why this happens here. Advice
> appreciated.

Hello Marc,

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_dnslookup_router.html
says:
| Unless they have the highest priority (lowest MX value), MX records that
| point to the local host, or to any host name that matches
| hosts_treat_as_local, are discarded, together with any other MX records
| of equal or lower priority.
| 
| If the host pointed to by the highest priority MX record, or looked up
| as an address record, is the local host, or matches
| hosts_treat_as_local, what happens is controlled by the generic self
| option.

(and self=  defaults to "freeze")

According to chapter 3, »8. Recognizing the local host« exim uses the
local_interfaces setting (unless it is 0.0.0.0 or ::0) to recognize the
local host. - Are you setting it?

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#992892: Please package 0.10.2

[Andrey Rahmatullin]

Source: python-toml
Version: 0.10.1-1
Severity: wishlist

New python3-ipdb for some reason that I didn't check requires python3-toml >=
0.10.2 so I would be glad if you updated it.
Thank you.

Bug#992891: Please package 1.8.2

[Andrey Rahmatullin]

Source: pydantic
Version: 1.7.4-1
Severity: wishlist


New python3-itemadapter supports pydantic, but only 1.8+ (as it uses
allow_mutation) so I would be glad if it's updated to the latest version.
Thank you.

Bug#992889: /usr/sbin/update-gsfontmap: overly complicated

[Jonas Smedegaard]

Hi наб,

Quoting наб (2021-08-24 18:58:36)
> The current approach that update-gsfontmap takes is very complicated, 
> to no apparent end, since all it achieves is concatenating all the 
> files; please consider the attached patch, which applies to every 
> version since 7e78b19759ab1e47a3636ffd5c922c536e6cad37 (November of 
> 2018)

Your assesment is quite likely correct: that script hasn't been touched 
since ancient times where more complex font registration scripts were 
used in Debian (something called DeFoMa).

Thanks for looking into this!

Seems your patch is missing, however...


 - 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#959145: ITP: protonmail-bridge -- ProtonMail Bridge for e-mail clients.

[Benedikt Ahrens]

It would be fantastic to have this application packaged in Debian.


On Wed, 29 Apr 2020 21:09:24 + Patryk Cisek  wrote:

Package: wnpp
Owner: Patryk Cisek 
Severity: wishlist

* Package name: protonmail-bridge
  Version : 1.2.6
  Upstream Author : Proton Technologies AG (ProtonMail Bridge
developers) 
* URL : https://github.com/ProtonMail/proton-bridge
* License : GPL
  Programming Lang: Go
  Description : ProtonMail Bridge for e-mail clients.

IMAP/SMTP bridge to ProtonMail for paid clients.

ProtonMail stores emails on their servers encrypted with GnuPG key, that
is encrypted with a symmetric cipher, for which the password is your
ProtonMail account password. Those emails can be decrypted only when you
access your account through Web Mail interface (you log in and provide
the password then) and through this bridge (your email client can
download messages through IMAP from the bridge, and it's the bridge that
decrypts those emails).

Bug#992885: mksh: buggy ignored trap handling on subshell with only one command

[Vincent Lefevre]

On 2021-08-24 16:51:28 +, Thorsten Glaser wrote:
> Vincent Lefevre dixit:
> 
> >This is incorrect, because SIGINT should be ignored.
> >
> >This issue disappears when the subshell has several commands:
> >
> >$ mksh -c 'trap "" INT; trap; ( :; sleep 3; ); echo $?'
> >trap -- '' INT
> >^C0
> 
> Consider this:
> 
> $ mksh -c 'trap "" INT; trap; ( :; exec sleep 3; ); echo $?'
> trap -- '' INT
> ^C130
> 
> The “one” command run in the subshell is exec’d so you’re hitting
> the parent shell’s INT handler… I think.

I don't understand. Normally an exec replaces the *current* shell
by the command, not the parent shell.

I'll try to have a look later...

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

Bug#992877: RFS: alberta/3.0.3-1 -- adaptive finite element library (library)

[Adam Borowski]

On Tue, Aug 24, 2021 at 04:49:07PM +0200, Lisa Julia Nebel wrote:
> * Package name : alberta
> Version : 3.0.3-1

> alberta (3.0.3-1) experimental; urgency=medium
> .
> * New upstream release
> * Set compat level to 13
> * Disable dh_missing

Hi!
I'm afraid it fails to build with the toolchain in experimental, failing
with:
checking for rpc/types.h... no
configure: error: Sorry, rpc/types.h is needed.

This is pretty puzzling as that header comes from libc6-dev, which suggests
something is terribad with the build system.

Full log attached.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄


alberta_3.0.3-1_amd64.build.xz
Description: application/xz

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

[Ben Hutchings]

On Tue, 2021-08-24 at 10:56 -0400, Chuck Zmudzinski wrote:
> On 5/24/2021 3:30 AM, Michael Biebl wrote:
> > Hi Phillip
> > 
> > Am 24.05.2021 um 06:19 schrieb Cyril Brulebois:
> > > > trigger to cold plug all devices.  Both scripts are set -e.  The Xen
> > > > Virtual Keyboard driver and at least one other driver have always 
> > > > failed
> > > > to trigger due to having absurdly long modalias, but the error used to
> > > > be ignored.  The kernel now returns the error to udevadm
> > 
> > So this is a change in behaviour in the kernel?
> > What happens if you boot the installed system? Does udevadm trigger 
> > fail there as well?
> > 
> > I feel a bit uneasy changing the udev start script this late in the 
> > release cycle (especially when it appears like covering up an issue 
> > someplace else).
> > 
> > I'll let Marco make the judgement on this though, as he has the most 
> > experience with those udev udeb start scripts as the original author.
> > 
> > Michael
> > 
> 
> After reviewing Philip's message at
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#43
> 
> which seems to point to the root cause of this bug, I can add:
> 
> On my Xen HVM DomU I see the absurdly long modalias for the Xen
> Virtual keyboard that seems to be causing this crash in sysfs at
> 
> /sys/devices/virtual/input/input2/modalias
> 
> But at /sys/devices/vkbd-0/modalias, I see just 'xen:vkbd', which would
> probably not result in an error in the udev script if this was also
> written as the modalias at /sys/devices/virtual/input/input2/modalias
>
> So the Xen virtual keyboard appears more than once in sysfs, and
> modalias is not the same in the different places. This seems
> to be a problem.

They are two different devices, and they should have different
modaliases.

Linux has code for discovering devices on each kind of bus, including
virtual buses, and that code creates "bus devices" such as vkbd-0.  At
this point the kernel doesn't know what the device is capable of.  The
modalias for a bus device carries some identifying information that can
be used to select a driver module for it.

The driver does know what the device is capable of, and how to use it.
It will normally create one or more "class devices" that support a
particular set of operations; in this case input device operations. 
Class devices typically don't have modaliases, since they don't need
another layer of drivers on top.  However, for input devices the
modalias carries information about the device's capabilities.  These
may trigger loading of the evdev or joydev module.

> I understand the correct way to fix this bug is by modifying the
> Xxen virtual keyboard (and any other devices that might cause
> this crash) and not the start-udev script on the netinst
> installation media, which is so far the only available workaround.
> Hopefully Xen will accept a fix if we can come up with a fix.
[...]

I think a proper fix would be one of:

a. If the Xen virtual keyboard driver is advertising capabilities it
   doesn't have, stop it doing that.
b. Change the implementation of modalias attributes to allow longer
   values.

It's not clear to me whether the Xen driver is advertising correctly or
not.  If it is, then the solution should be b, but that may be too
disruptive a change to the kernel.  So a reasonable workaround might
be:

c. Change the input subsystem to limit the length of the
   capabilities part of the modalias.


Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.


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

Bug#992890: subversion: Broken pipe on the diff command with --diff-cmd

[Vincent Lefevre]

Package: subversion
Version: 1.14.1-3
Severity: minor

When I pipe the output of "svn diff --diff-cmd diff" and a broken pipe
occurs on the diff command, I get a "Broken pipe" error:

diff: standard output: Broken pipe
svn: E200012: 'diff' returned 2

The cause is that svn runs the diff command with SIGPIPE ignored,
so that diff gets an EPIPE write error instead of being killed by
the signal. I think that a fix should be to reset SIGPIPE to the
default action just before executing the external diff command.

To reproduce the bug:


#!/bin/sh

set -e

export LC_ALL=C

mkdir my-test-svn
cd my-test-svn

svnadmin create svn
svn co file://`pwd`/svn wc
cd wc

seq 1 > file
svn add file
svn diff | head
svn diff --diff-cmd diff | head

cd ../..
rm -rf my-test-svn


This gives:

Checked out revision 0.
A file
Index: file
===
--- file(nonexistent)
+++ file(working copy)
@@ -0,0 +1,1 @@
+1
+2
+3
+4
+5
Index: file
===
--- file(nonexistent)
+++ file(working copy)
@@ -0,0 +1,1 @@
+1
+2
+3
+4
+5
diff: standard output: Broken pipe
svn: E200012: 'diff' returned 2

No issue with the first "svn diff". The error occurs only with
"svn diff --diff-cmd diff".

I've also reported the bug upstream:

  
https://mail-archives.apache.org/mod_mbox/subversion-dev/202108.mbox/%3C20210824151357.GA3011301%40cventin.lip.ens-lyon.fr%3E

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 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 subversion depends on:
ii  libapr1  1.7.0-6
ii  libaprutil1  1.6.1-5
ii  libc62.31-17
ii  libsvn1  1.14.1-3

subversion recommends no packages.

Versions of packages subversion suggests:
pn  db5.3-util  
pn  libapache2-mod-svn  
ii  patch   2.7.6-7
ii  subversion-tools1.14.1-3

-- no debconf information

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

Bug#935013: Latest upstream (was: new upstream)

[Ernesto Hernández-Novich]

Any progress on this?

I see the patch didn't make it into Debian 11.

I've been using the patch for custom-built packages targeting Debian 10
and Debian 11, the latter with a simple `compat 10` change. There
haven't been any changes to upstream since I provided the patch.
-- 
Prof. Ernesto Hernández-Novich - MYS-220C - @iamemhn
Geek by nature, Linux by choice, Debian of course.
If you can't aptitude it, it isn't useful or doesn't exist.
GPG Key Fingerprint = 0064 ADF5 EB5C DE16 99C1 6C56 F2A3 86B5 A757 E5A1

Bug#992700: fixed in xfig 1:3.2.8b-1

[Roland Rosenfeld]

Hi Adrian!

John Paul Adrian Glaubitz schrieb am Dienstag, den 24. August 2021:

> >* Build test binaries despite of "nocheck" (Closes: #992700).
> 
> Does that mean that the testsuite is now run all the time?

No, it doesn't.
Upstream creates three little test binaries, that are used in the
upstream testsuite.
Since 3.2.8a-1 I place these test binaries in /usr/libexec/xfig on
build to be able to use them in autopkgtest.  This has the advantage,
that autopkgtest uses test binaries that are build in the same
environment as the xfig binary, which is more realistic than building
these test binaries during autopkgtest, which may run in a different
environment than the original build.

So I do not run the testsuite here but only build and package the test
binaries.

> The proper behavior should be that "nocheck" disables the testsuite since
> being able to disable the testsuite is necessary for being able to cross-
> compile a package.

No problem.  But the above mentioned setup allows to run an
autopkgtest on the destination architecture (without need of a
compiler), since the test binaries are packaged.

BTW: https://salsa.debian.org/debian/xfig/-/pipelines/28 shows,
that test-crossbuild-arm64 succeeded in the salsa pipeline :-)

Greetings
Roland

Bug#992885: mksh: buggy ignored trap handling on subshell with only one command

[Thorsten Glaser]

Vincent Lefevre dixit:

>This is incorrect, because SIGINT should be ignored.
>
>This issue disappears when the subshell has several commands:
>
>$ mksh -c 'trap "" INT; trap; ( :; sleep 3; ); echo $?'
>trap -- '' INT
>^C0

Consider this:

$ mksh -c 'trap "" INT; trap; ( :; exec sleep 3; ); echo $?'
trap -- '' INT
^C130

The “one” command run in the subshell is exec’d so you’re hitting
the parent shell’s INT handler… I think.

Feel free to have a look at the source and see if you come up with
what exactly seems to be the problem.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#992888: libpam0g: postinst fails on non-systemd services

[Ray Klassen]

Package: libpam0g
Version: 1.4.0-9
Severity: important
Tags: d-i
X-Debbugs-Cc: rklas...@communitascare.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/32 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 libpam0g depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libaudit1  1:3.0-2
ii  libc6  2.31-13

libpam0g recommends no packages.

Versions of packages libpam0g suggests:
pn  libpam-doc  

-- debconf information:
  libpam0g/xdm-needs-restart:
  libpam0g/restart-failed:
* libraries/restart-without-asking: true
  libpam0g/restart-services:


On upgrading from buster to bullseye, libpam09 postinst script insisted on 
restarting a number of services, but failed on the two services (hylafax and 
exim) 
that had no systemd units but were rather started and stopped via systemd's 
sysv compatibility function. 
This halted the upgrade and left the server in a semi-crippled state. I was 
only able to continue the upgrade 
by extracting the deb and removing references to hylafax and exim from the 
postinst script.

Bug#992700: fixed in xfig 1:3.2.8b-1

[John Paul Adrian Glaubitz]

Hi!

On 8/24/21 6:20 PM, Debian FTP Masters wrote:
>* Build test binaries despite of "nocheck" (Closes: #992700).

Does that mean that the testsuite is now run all the time?

The proper behavior should be that "nocheck" disables the testsuite since
being able to disable the testsuite is necessary for being able to cross-
compile a package.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#992784: cups: libcupsimage2 not a dependancy

[Brian Potkin]

On Tue 24 Aug 2021 at 16:54:31 +0200, Alain Bertrand wrote:

> Hello,
> 
> Thanks for your answer. With libcupsimage2 installed, everything works as it
> should. Anyway, you'll find the output you wanted below.
> 
> lpstat -t
> scheduler is running
> no system default destination
> matériel pour Canon_LBP113_913_UFRII_LT : socket://192.168.8.105

This print queue uses a netork connection. UFRII indicates a non-free
Canon driver is being used with the queue. Problems involving this
driver are not ours and the queue will not be debugged.

> matériel pour Canon_LBP113_LBP913 : implicitclass://Canon_LBP113_LBP913/

This looks like another network queue, auto-setup by cups-browsed.

> matériel pour Canon_LBP113_LBP913_USB_ : 
> implicitclass://Canon_LBP113_LBP913_USB_/

This queue uses a USB connection and is also auto-setup by cups-browsed.

Let's take the Canon_LBP113_LBP913_USB_ queue and test, but first

  apt purge libcupsimage2

It can easily be re-installed if needed. Now (as root)

 cupsfilter -p /etc/cups/Canon_LBP113_LBP913_USB_.ppd -m priner/foo -e 
/etc/nsswitch.conf > out.dat 2>log

(Check that I have the correct PPD file name).

Please attach log to your next post here. It may be viewed with 'less'.

Cheers,

Brian.

Bug#990007: xscreensaver-data-extra: Please fix a typo in glitchpeg.desktop

[Anders Jackson]

This is a trivial error, so might be added for beginners to fix.

Also reported to Ubuntu as "Value in glitchpeg.desktop, "Comment",
divided into two lines" #1940981.

"The value of the key "Comment" in
/usr/share/applications/screensavers/glitchpeg.desktop is divided into
two lines, like this:

Comment=Loads an image, corrupts it, and then displays the corrupted version,

several times a second.  After a while, finds a new image to corrupt.
Written by Jamie Zawinski; 2018.

It should be one single line, without a line break after "version,",
or there will be an error report when installing the desktop file."

Yours,
Anders Jackson

Bug#992887: xball new upstream release

[Jose Da Silva]

Package: xball
Version: 3.0.1

New upstream release of orphaned Debian Package xball v3.0.1 located here:
https://github.com/JoesCat/xball/releases/tag/v3.1.0

git repo located here:
https://github.com/JoesCat/xball/
Note: lacking prior git or SVN history, this git repo is approximate, but 
not historically correct (as was) - the best I was able to do based on the 
existing Debian xball install files.

More information here:
https://lists.debian.org/debian-devel-games/2021/08/msg5.html

Thanks,
Joe

Bug#972537: please add --enable-ros3-vfd to the build options to allow RO access to HDF5 on S3

[Drew Parsons]

Source: hdf5
Followup-For: Bug #972537
Control: affects -1 src:h5py

h5py is now ready for ROS3 support.

Bug#992863: buster-pu: package modsecurity-crs/3.1.0-1

[Alberto Gonzalez Iniesta]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

This [1] security bug was found in modsecurity-crs.
As with the previous update (modsecurity-crs_3.1.0-1+deb10u1), a DSA
does not seem necessary (security team on Cc:) so I'm targeting buster
proposed updates instead.

Here's the debdiff. Hope it's all OK.

I'll wait for your instructions before uploading.

Cheers,

Alberto


[1] https://coreruleset.org/20210630/cve-2021-35368-crs-request-body-bypass/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992000


-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55
diff -Nru modsecurity-crs-3.1.0/debian/changelog 
modsecurity-crs-3.1.0/debian/changelog
--- modsecurity-crs-3.1.0/debian/changelog  2019-11-03 14:34:05.0 
+0100
+++ modsecurity-crs-3.1.0/debian/changelog  2021-08-24 12:37:59.0 
+0200
@@ -1,3 +1,10 @@
+modsecurity-crs (3.1.0-1+deb10u2) buster; urgency=medium
+
+  * Add upstream patch to fix request body bypass
+CVE-2021-35368 (Closes: #992000)
+
+ -- Alberto Gonzalez Iniesta   Tue, 24 Aug 2021 12:37:59 
+0200
+
 modsecurity-crs (3.1.0-1+deb10u1) buster; urgency=medium
 
   * Add upstream patch to fix php script upload rules.
diff -Nru modsecurity-crs-3.1.0/debian/patches/CVE-2021-35368.patch 
modsecurity-crs-3.1.0/debian/patches/CVE-2021-35368.patch
--- modsecurity-crs-3.1.0/debian/patches/CVE-2021-35368.patch   1970-01-01 
01:00:00.0 +0100
+++ modsecurity-crs-3.1.0/debian/patches/CVE-2021-35368.patch   2021-08-24 
12:32:08.0 +0200
@@ -0,0 +1,130 @@
+From d3b116fce6c0dc8c8f6e4fbb4e3304af312b4812 Mon Sep 17 00:00:00 2001
+From: Walter Hop 
+Date: Wed, 30 Jun 2021 12:56:51 +0200
+Subject: [PATCH] Fix CVE-2021-35368 WAF bypass using pathinfo (Christian 
Folini)
+
+---
+diff --git a/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf 
b/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
+index 1f511c38..c9bb8693 100644
+--- a/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
 b/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
+@@ -64,6 +64,14 @@
+ 
+ SecRule :crs_exclusions_drupal|TX:crs_exclusions_drupal "@eq 0" \
+ "id:9001000,\
++phase:1,\
++pass,\
++t:none,\
++nolog,\
++skipAfter:END-DRUPAL-RULE-EXCLUSIONS"
++
++SecRule :crs_exclusions_drupal|TX:crs_exclusions_drupal "@eq 0" \
++"id:9001001,\
+ phase:2,\
+ pass,\
+ t:none,\
+@@ -254,52 +262,58 @@
+ #
+ # Extensive checks make sure these uploads are really legitimate.
+ #
+-SecRule REQUEST_METHOD "@streq POST" \
+-"id:9001180,\
+-phase:1,\
+-pass,\
+-t:none,\
+-nolog,\
+-noauditlog,\
+-chain"
+-SecRule REQUEST_FILENAME "@rx /admin/content/assets/add/[a-z]+$" \
+-"chain"
+-SecRule REQUEST_COOKIES:/S?SESS[a-f0-9]+/ "@rx ^[a-zA-Z0-9_-]+" \
+-"ctl:requestBodyAccess=Off"
+-
+-SecRule REQUEST_METHOD "@streq POST" \
+-"id:9001182,\
+-phase:1,\
+-pass,\
+-t:none,\
+-nolog,\
+-noauditlog,\
+-chain"
+-SecRule REQUEST_FILENAME "@rx /admin/content/assets/manage/[0-9]+$" \
+-"chain"
+-SecRule ARGS:destination "@streq admin/content/assets" \
+-"chain"
+-SecRule REQUEST_HEADERS:Content-Length "@gt 31486341" \
+-"chain"
+-SecRule REQUEST_COOKIES:/S?SESS[a-f0-9]+/ "@rx 
^[a-zA-Z0-9_-]+" \
+-"ctl:requestBodyAccess=Off"
+-
+-SecRule REQUEST_METHOD "@streq POST" \
+-"id:9001184,\
+-phase:1,\
+-pass,\
+-t:none,\
+-nolog,\
+-noauditlog,\
+-chain"
+-SecRule REQUEST_FILENAME "@rx 
/file/ajax/field_asset_[a-z0-9_]+/[ua]nd/0/form-[a-z0-9A-Z_-]+$" \
+-"chain"
+-SecRule REQUEST_HEADERS:Content-Length "@gt 31486341" \
+-"chain"
+-SecRule REQUEST_HEADERS:Content-Type "@streq multipart/form-data" 
\
+-"chain"
+-SecRule REQUEST_COOKIES:/S?SESS[a-f0-9]+/ "@rx 
^[a-zA-Z0-9_-]+" \
+-"ctl:requestBodyAccess=Off"
++# Rule 9001180 was commented out in 2021 in order to fight CVE-2021-35368.
++#
++#SecRule REQUEST_METHOD "@streq POST" \
++#"id:9001180,\
++#phase:1,\
++#pass,\
++#t:none,\
++#nolog,\
++#noauditlog,\
++#chain"
++#SecRule REQUEST_FILENAME "@rx /admin/content/assets/add/[a-z]+$" \
++#"chain"
++#SecRule REQUEST_COOKIES:/S?SESS[a-f0-9]+/ "@rx ^[a-zA-Z0-9_-]+" \
++#"ctl:requestBodyAccess=Off"
++
++# Rule 9001180 was commented out in 2021 in order to fight CVE-2021-35368.
++#
++#SecRule REQUEST_METHOD "@streq POST" \
++#"id:9001182,\
++#phase:1,\
++#pass,\
++#t:none,\
++#nolog,\
++#noauditlog,\
++#chain"
++#SecRule 

Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

[Roger Lynn]

Package: src:linux
Version: 5.10.46-4
Severity: normal
File: /lib/modules/5.10.0-8-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko

I've just upgraded this machine to Bullseye and it seems unable to load the
ethernet driver:

[6.548031] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[6.566607] libphy: r8169: probed
[6.566613] r8169 :02:00.0: no dedicated PHY driver found for PHY ID 
0xc1071002, maybe realtek.ko needs to be added to initramfs?
[6.590372] r8169: probe of :02:00.0 failed with error -49
[6.590412] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[6.592984] libphy: r8169: probed
[6.592987] r8169 :03:00.0: no dedicated PHY driver found for PHY ID 
0xc1071002, maybe realtek.ko needs to be added to initramfs?
[6.626342] r8169: probe of :03:00.0 failed with error -49

This is long after the filesystem has been mounted, so the initramfs should be
irrelevant, but I tried adding the realtek and r8169 modules to the initramfs
and the only difference was that the error was earlier in the boot sequence.

The machine is 12 years old and has worked with every stable Debian release in
that time. The old Buster kernel, 4.19.0-17-amd64, running with Bullseye
reports:

[   10.604259] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[   10.616071] libphy: r8169: probed
[   10.616222] r8169 :02:00.0 eth0: RTL8168d/8111d, 00:24:1d:1e:99:33, XID 
281000c0, IRQ 25
[   10.616223] r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, tx 
checksumming: ko]
[   10.616921] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[   10.619251] libphy: r8169: probed
[   10.619384] r8169 :03:00.0 eth1: RTL8168d/8111d, 00:24:1d:1e:99:31, XID 
281000c0, IRQ 26
[   10.619385] r8169 :03:00.0 eth1: jumbo features [frames: 9200 bytes, tx 
checksumming: ko]
...
[   17.134036] r8169 :02:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168d-1.fw
[   17.134559] Generic PHY r8169-200:00: attached PHY driver [Generic PHY] 
(mii_bus:phy_addr=r8169-200:00, irq=IGNORE)
[   17.285430] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   17.286173] Generic PHY r8169-300:00: attached PHY driver [Generic PHY] 
(mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
[   17.437417] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   20.009162] r8169 :02:00.0 eth0: Link is Up - 100Mbps/Full - flow 
control rx/tx
[   20.009180] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Thanks,

Roger

-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-4 (2021-08-03)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 
root=UUID=cc5ea548-3370-40b7-b244-7fb88e5b310e ro radeon.dpm=1 quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: GA-MA790FXT-UD5P
product_version: 
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: 
bios_vendor: Award Software International, Inc.
bios_version: F8n
board_vendor: Gigabyte Technology Co., Ltd.
board_name: GA-MA790FXT-UD5P
board_version: 

** Loaded modules:
udp_diag
tcp_diag
inet_diag
cpufreq_userspace
cpufreq_powersave
cpufreq_conservative
cpufreq_ondemand
uinput
it87
hwmon_vid
loop
msr
i2c_dev
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
ax88179_178a
usbnet
snd_hda_codec_hdmi
mii
snd_hda_intel
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
snd_soc_core
edac_mce_amd
snd_compress
soundwire_cadence
kvm_amd
snd_hda_codec
ccp
r8169
rng_core
snd_hda_core
kvm
firewire_ohci
firewire_core
snd_hwdep
wmi_bmof
realtek
soundwire_bus
mdio_devres
libphy
sr_mod
crc_itu_t
irqbypass
snd_pcm
snd_timer
cdrom
pcspkr
ohci_pci
ohci_hcd
ata_generic
snd
sg
ehci_pci
ehci_hcd
sp5100_tco
watchdog
pata_atiixp
usbcore
acpi_cpufreq
soundcore
button
usb_common
wmi
i2c_piix4
k10temp
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
radeon
i2c_algo_bit
drm_kms_helper
cec
ahci
ttm
libahci
libata
drm
evdev
psmouse
scsi_mod
serio_raw

** Network interface configuration:
*** /etc/network/interfaces:

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
address 192.168.0.3
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.2
allow-hotplug eth1
iface eth1 inet static
address 192.168.2.1
netmask 255.255.255.0

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft 

Bug#992885: mksh: buggy ignored trap handling on subshell with only one command

[Vincent Lefevre]

Package: mksh
Version: 59c-9+b2
Severity: normal

Consider the following command:

  mksh -c 'trap "" INT; trap; ( sleep 3; ); echo $?'

If I hit Ctrl-C, the sleep is interrupted immediately, with
exit status 130, corresponding to a SIGINT:

$ mksh -c 'trap "" INT; trap; ( sleep 3; ); echo $?'
trap -- '' INT
^C130

This is incorrect, because SIGINT should be ignored.

This issue disappears when the subshell has several commands:

$ mksh -c 'trap "" INT; trap; ( :; sleep 3; ); echo $?'
trap -- '' INT
^C0

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 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 mksh depends on:
ii  libc6  2.31-17

Versions of packages mksh recommends:
ii  ed  1.17-1

mksh 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#935912: Could you supply one patch to fix this bug?

[肖盛文]

Hi, Hu Jiahui 
!


    Could you supply one patch to fix this bug?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935912


--
肖盛文 xiao sheng wen Faris Xiao
微信(wechat)：atzlinux
《铜豌豆 Linux》https://www.atzlinux.com
基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x00186602339240CB



OpenPGP_0x00186602339240CB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992884: RFS: dune-istl/2.8.0~rc1-1 -- toolbox for solving PDEs -- iterative solvers (documentation)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dune-istl":

* Package name : dune-istl
Version : 2.8.0~rc1-1
Upstream Author : [fill in name and email of upstream]
* URL : https://www.dune-project.org/
* License : GPL-2 with DUNE exception
* Vcs : https://salsa.debian.org/science-team/dune-istl
Section : libs

It builds those binary packages:

libdune-istl-doc - toolbox for solving PDEs -- iterative solvers 
(documentation)
libdune-istl-dev - toolbox for solving PDEs -- iterative solvers 
(development files)


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


https://mentors.debian.net/package/dune-istl/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dune-istl/dune-istl_2.8.0~rc1-1.dsc


Changes since the last upload:

dune-istl (2.8.0~rc1-1) experimental; urgency=medium
.
* New upstream release.
* debian/rules: Explicitly set buildsystem to CMake.

Regards,
Lisa


OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992883: RFS: dune-typetree/2.8.0~rc1-1 -- toolbox for solving PDEs -- typed tree template library (documentation)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dune-typetree":

* Package name : dune-typetree
Version : 2.8.0~rc1-1
Upstream Author : [fill in name and email of upstream]
* URL : https://www.dune-project.org/
* License : LGPL-3+ or GPL-2 with runtime exception
* Vcs : https://salsa.debian.org/science-team/dune-typetree
Section : libs

It builds those binary packages:

libdune-typetree-doc - toolbox for solving PDEs -- typed tree template 
library (documentation)
libdune-typetree-dev - toolbox for solving PDEs -- typed tree template 
library (development files)


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


https://mentors.debian.net/package/dune-typetree/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dune-typetree/dune-typetree_2.8.0~rc1-1.dsc


Changes since the last upload:

dune-typetree (2.8.0~rc1-1) experimental; urgency=medium
.
* New upstream release.
* Updated copyright holders from upsteam.

Regards,
Lisa


OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992882: RFS: dune-grid-glue/2.8~20210831-1 -- toolbox for solving PDEs -- compute couplings between grids (documentation)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dune-grid-glue":

* Package name : dune-grid-glue
Version : 2.8~20210831-1
Upstream Author : [fill in name and email of upstream]
* URL : https://www.dune-project.org/modules/dune-grid-glue/
* License : GPL-2+ with dune-grid-glue exception or LGPL-3+
* Vcs : https://salsa.debian.org/science-team/dune-grid-glue
Section : libs

It builds those binary packages:

libdune-grid-glue-doc - toolbox for solving PDEs -- compute couplings 
between grids (documentation)
libdune-grid-glue-dev - toolbox for solving PDEs -- compute couplings 
between grids (development files)


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


https://mentors.debian.net/package/dune-grid-glue/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dune-grid-glue/dune-grid-glue_2.8~20210831-1.dsc


Changes since the last upload:

dune-grid-glue (2.8~20210831-1) experimental; urgency=medium
.
* New upstream snapshot.
* d/patches: Removed obsolet patches

Regards,
Lisa


OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992881: RFS: dune-functions/2.8.0~rc1-1 -- toolbox for solving PDEs -- interface for functions (documentation)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dune-functions":

* Package name : dune-functions
Version : 2.8.0~rc1-1
Upstream Author : [fill in name and email of upstream]
* URL : https://www.dune-project.org/
* License : LGPL-3+ or GPL-2 with DUNE exception
* Vcs : https://salsa.debian.org/science-team/dune-functions
Section : libs

It builds those binary packages:

libdune-functions-doc - toolbox for solving PDEs -- interface for 
functions (documentation)
libdune-functions-dev - toolbox for solving PDEs -- interface for 
functions (development files)


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


https://mentors.debian.net/package/dune-functions/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dune-functions/dune-functions_2.8.0~rc1-1.dsc


Changes since the last upload:

dune-functions (2.8.0~rc1-1) experimental; urgency=medium
.
* New upstream release.
* d/rules: Explicitly set buildsystem to CMake
* d/control: Include libdune-grid-doc in build dependencies

Regards,
Lisa


OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992880: RFS: dune-common/2.8.0~rc1-1 -- toolbox for solving PDEs -- basic classes (documentation)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dune-common":

* Package name : dune-common
Version : 2.8.0~rc1-1
Upstream Author : [fill in name and email of upstream]
* URL : https://www.dune-project.org/
* License : GPL-2 with DUNE exception, other, 
GNU-All-Permissive-License, BSD-3-clause

* Vcs : https://salsa.debian.org/science-team/dune-common
Section : libs

It builds those binary packages:

libdune-common-doc - toolbox for solving PDEs -- basic classes 
(documentation)
libdune-common-dev - toolbox for solving PDEs -- basic classes 
(development files)


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


https://mentors.debian.net/package/dune-common/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dune-common/dune-common_2.8.0~rc1-1.dsc


Changes since the last upload:

dune-common (2.8.0~rc1-1) experimental; urgency=medium
.
* New upstream release.
* Adapt soname.patch to code changes.
* d/rules: Explicitly use cmake buildsystem.
* d/clean: Explicitly clear __pycache__ directory.

Regards,
Lisa


OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992879: RFS: dune-geometry/2.8.0~rc1-1 -- toolbox for solving PDEs -- geometry classes (documentation)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dune-geometry":

* Package name : dune-geometry
Version : 2.8.0~rc1-1
Upstream Author : [fill in name and email of upstream]
* URL : https://www.dune-project.org/
* License : GPL-2 with DUNE exception
* Vcs : https://salsa.debian.org/science-team/dune-geometry
Section : libs

It builds those binary packages:

libdune-geometry-doc - toolbox for solving PDEs -- geometry classes 
(documentation)
libdune-geometry-dev - toolbox for solving PDEs -- geometry classes 
(development files)


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


https://mentors.debian.net/package/dune-geometry/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dune-geometry/dune-geometry_2.8.0~rc1-1.dsc


Changes since the last upload:

dune-geometry (2.8.0~rc1-1) experimental; urgency=medium
.
* New upstream release.
* debian/rules: Explicitly set buildsystem to CMake

Regards,
Lisa



OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992878: RFS: dune-grid/2.8.0~rc1-1 -- toolbox for solving PDEs -- grid interface (documentation)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dune-grid":

* Package name : dune-grid
Version : 2.8.0~rc1-1
Upstream Author : [fill in name and email of upstream]
* URL : https://www.dune-project.org/
* License : GPL-2 with DUNE exception
* Vcs : https://salsa.debian.org/science-team/dune-grid
Section : libs

It builds those binary packages:

libdune-grid-doc - toolbox for solving PDEs -- grid interface 
(documentation)
libdune-grid-dev - toolbox for solving PDEs -- grid interface 
(development files)


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


https://mentors.debian.net/package/dune-grid/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dune-grid/dune-grid_2.8.0~rc1-1.dsc


Changes since the last upload:

dune-grid (2.8.0~rc1-1) experimental; urgency=medium
.
* New upstream release.
* debian/rules: Explicitly set buildsystem to CMake
* Removed obsolete patches.

Regards,
Lisa



OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992877: RFS: alberta/3.0.3-1 -- adaptive finite element library (library)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : alberta
Version : 3.0.3-1
Upstream Author : [fill in name and email of upstream]
* URL : http://www.alberta-fem.de/
* License : LGPL-2.1+, GPL-2+, GPL-2+ and other
* Vcs : https://salsa.debian.org/science-team/alberta
Section : libs

It builds those binary packages:

libalberta4 - adaptive finite element library (library)
libalberta-dev - adaptive finite element library (development files)

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/a/alberta/alberta_3.0.3-1.dsc


Changes since the last upload:

alberta (3.0.3-1) experimental; urgency=medium
.
* New upstream release
* Set compat level to 13
* Disable dh_missing

Regards,
Lisa


OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature