Bug#992876: RFS: dune-pdelab/2.8~20213108-1 -- toolbox for solving PDEs -- discretization module (documentation)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

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

It builds those binary packages:

libdune-pdelab-doc - toolbox for solving PDEs -- discretization module 
(documentation)
libdune-pdelab-dev - toolbox for solving PDEs -- discretization module 
(development files)


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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dune-pdelab/dune-pdelab_2.8~20213108-1.dsc


Changes since the last upload:

dune-pdelab (2.8~20213108-1) experimental; urgency=medium
.
* New upstream snapshot.
* d/rules: Explicitly set buildsystem to CMake.
* Update patches.

Regards,
Lisa


OpenPGP_0xA793D477D29BC6D6.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#992875: RFS: dune-uggrid/2.8.0~rc1-1 -- software framework for finite element methods (development files)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : dune-uggrid
Version : 2.8.0~rc1-1
Upstream Author : [fill in name and email of upstream]
* URL : https://gitlab.dune-project.org/staging/dune-uggrid/
* License : LGPL-2.1+
* Vcs : https://salsa.debian.org/science-team/dune-uggrid
Section : libs

It builds those binary packages:

libdune-uggrid-dev - software framework for finite element methods 
(development files)


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


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

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

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


Changes since the last upload:

dune-uggrid (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#992874: RFS: dune-localfunctions/2.8.0~rc1-1 -- toolbox for solving PDEs -- local basis (documentation)

[Lisa Julia Nebel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : dune-localfunctions
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-localfunctions
Section : libs

It builds those binary packages:

libdune-localfunctions-doc - toolbox for solving PDEs -- local basis 
(documentation)
libdune-localfunctions-dev - toolbox for solving PDEs -- local basis 
(development files)


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


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

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

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


Changes since the last upload:

dune-localfunctions (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#992784: cups: libcupsimage2 not a dependancy

[Alain Bertrand]

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
matériel pour Canon_LBP113_LBP913 : implicitclass://Canon_LBP113_LBP913/
matériel pour Canon_LBP113_LBP913_USB_ : 
implicitclass://Canon_LBP113_LBP913_USB_/
Canon_LBP113_913_UFRII_LT accepte des requêtes depuis lun. 23 août 2021 
21:19:39

Canon_LBP113_LBP913 accepte des requêtes depuis mar. 24 août 2021 15:51:50
Canon_LBP113_LBP913_USB_ accepte des requêtes depuis mar. 24 août 2021 
00:00:22
printer Canon_LBP113_913_UFRII_LT is idle.  enabled since lun. 23 août 
2021 21:19:39
printer Canon_LBP113_LBP913 is idle.  enabled since mar. 24 août 2021 
15:51:50
printer Canon_LBP113_LBP913_USB_ is idle.  enabled since mar. 24 août 
2021 00:00:22


Best regards,

Alain


On 24/08/2021 15:17, Brian Potkin wrote:

reopen 992784
thanks



On Mon 23 Aug 2021 at 22:45:44 +0200, Alain Bertrand wrote:


Hello,


Thanks for your answer but here apt rdepends libcupsimage2 gives totally
different results :

apt rdepends libcupsimage2
libcupsimage2
Reverse Depends:
   Dépend: libcupsimage2-dev (= 2.3.3op2-3+deb11u1)
   Dépend: printer-driver-splix (>= 1.4.0)
   Dépend: printer-driver-escpr (>= 1.4.0)
   Dépend: printer-driver-dymo (>= 1.4.0)


BTW, a French guy on  Debian-fr  forum had the same problem as I had with a
fresh install, problem that was solved by the manual installation of
libcupsimage2.

Apologies, Alain - you are correct with your apt rdepends command.
I ran mine on buster! I have reopened the report.

What is your printer and do you know what driver (if any) is being
used? Please give 'lpstat -t'.

Cheers,

Brian.

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

[Evgeny Golyshev]

Done. The package was uploaded.

--
Evgeny

On Mon, 23 Aug 2021 at 15:38, Evgeny Golyshev  wrote:

> Hello Thomas
>
> Yes, I started working on the package. I hope it will go smoothly.
>
> --
> Evgeny
>
> On Sun, 22 Aug 2021 at 19:33, Thomas Goirand  wrote:
>
>> Package: elixir
>> Severity: important
>>
>> Hi,
>>
>> The newer version of RabbitMQ-server (ie: one that can be built with
>> Erlang v24 in Unstable) needs Elixir >= 1.10.4 and < 1.13.0. Could you
>> please package this ASAP?
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>

Bug#860890: (no subject)

[c.buhtz]

The described problems still exists.

The problem is transparency. No matter if this is an issue for an admin
and this has to be very complex and nerdy or something like this
because of that.

The problems and issues need to be reported and documented, even for
Debian.

A much more user- and admin-friendly and polite reaction would be to
do the adduser command by default when installing the package.

Is there any good reason why this could not happen by default?

Bug#992873: dhcrelay -6 does not work if there are interface aliases up in the system

[Santiago R.R.]

Package: isc-dhcp-relay
Version: 4.3.5-3+deb9u1
Severity: important
Tags: ipv6, upstream
Forwarded: https://gitlab.isc.org/isc-projects/dhcp/-/issues/204

Hi there,

I've been hitted by this bug on a machine running stretch, but it is
also present in the current version on sid (4.4.1-3).

dchrelay -6 doesn't start if there are interface aliases up in the
system:

# /usr/sbin/dhcrelay -6  -pf /var/run/dhcrelay6.pid -l vlan.881 -u 
2001:db8:cafe::2%vlan.880
Internet Systems Consortium DHCP Relay Agent 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Bound to *:547
Listening on Socket/vlan.881:0
Sending on   Socket/vlan.881:0
Listening on Socket/vlan.880:0
Sending on   Socket/vlan.880:0
Listening on Socket/vlan
Sending on   Socket/vlan
setsockopt: IPV6_JOIN_GROUP: Address already in use

If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug.  These pages explain the proper
process and the information we find helpful for debugging.

exiting.

The above error can be reproduced with inside a container with the
following /etc/network/interfaces:

auto lo
iface lo inet loopback

auto vlan
iface vlan inet dhcp

auto vlan.880
auto vlan.880:0
iface vlan.880 inet static
address 192.168.133.1/24

iface vlan.880 inet6 static
address 2001:db8:cafe::1/64

iface vlan.880:0 inet static
address 10.0.133.1/16

auto vlan.881
auto vlan.881:0
iface vlan.881 inet static
address 192.168.131.1/24

iface vlan.881 inet6 static
address 2001:db8:cafe:1::1/64

iface vlan.881:0 inet static
address 10.1.131.1/16

Just removing (or commenting out) the interface aliases entries makes
dchrelay -6 happy again.

Please note the -l and -u filters do not work. But that's another bug.

Cheers,

 -- Santiago

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.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 isc-dhcp-relay depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  debianutils4.11.2
ii  libc6  2.31-13
ii  libdns-export1104  1:9.11.5.P4+dfsg-5.1+deb10u5
ii  libdns-export1110  1:9.11.19+dfsg-2.1
pn  libdns-export162   
pn  libirs-export141   
ii  libirs-export161   1:9.11.19+dfsg-2.1
ii  libisc-export1100  1:9.11.5.P4+dfsg-5.1+deb10u5
ii  libisc-export1105  1:9.11.19+dfsg-2.1
pn  libisc-export160   
ii  lsb-base   11.1.0

Versions of packages isc-dhcp-relay recommends:
ii  isc-dhcp-common  4.4.1-2.3

isc-dhcp-relay suggests no packages.


signature.asc
Description: PGP signature

Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash

[Florence Birée]

Le Tue, 24 Aug 2021 10:50:19 +0100,
Brian Potkin  a écrit :
> Can you scan with any of these?
> 
> scanimage -d
> "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK" >
> image.pnm
> simple-scan
> "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"
> xsane
> "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"

With some tests, it seems the crash is not always reproducible (sometimes, it's 
working…),
so I run each command 4 times to see (and add hp-scan again, in case it crash 
sometimes too).

Without removing the slash:

$ scanimage -d "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK" > 
image.pnm

-> on 4 runs, 1 give "stack smashing", 3 works well…

$ simple-scan "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"

-> on 4 runs, 4 "stack smashing" crashes. I can see the top of the image 
appearing in simple-scan,
and the program do no crash at the same times (sometimes more of the scan is 
displayed before the
crash)

$ xsane "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"  

-> on 4 runs, 4 "stack smashing" crashes

$ hp-scan

-> on 4 runs, 4 "stack smashing" crash… (but it worked yesterday…)

** after the removal of the slash in os-release:

$ scanimage -d "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK" > 
image.pnm

-> on 4 runs, 1 "stack smashing", 3 works

$ simple-scan "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"

-> on 4 runs, 4 "stack smashing" crashes.

$ xsane "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"  

-> on 4 runs, 4 "stack smashing" crashes (but on some preliminary tests, it 
works sometimes…)

$ hp-scan

-> on 4 runs, 4 "stack smashing" crash, at various percentages of scanning


So… it seems the problem is not 100% reproducible, even if it happens in the 
large majority
of times… And I'm not sure the os-release changes really changes something, 
maybe the times when
hp-scan was working was just luck…

Cheers,
-- 
Florence Birée (elle)
06 52 92 15 32

En ces temps d'état policier, ne les laissons pas lire nos mails,
chiffrons-les ! https://emailselfdefense.fsf.org/fr/index.html


pgprtIMAkFbqw.pgp
Description: Signature digitale OpenPGP

Bug#992872: budgie-desktop: compatibility with mutter 40

[Simon McVittie]

Source: budgie-desktop
Version: 10.5.2-4
Severity: important
Tags: fixed-upstream bookworm sid

Please could you upload a version of budgie-desktop to experimental
that is compatible with experimental's libmutter-8-0? This will let the
GNOME team get ready for the libmutter-7-0 to libmutter-8-0 transition.

The version in Ubuntu seems like it would be suitable.

Thanks,
smcv

Bug#992482: kexec-tools: run-path should be run-parts

[Arthur Marsh]

Package: kexec-tools
Version: 1:2.0.22-2+b1
Followup-For: Bug #992482

Dear Maintainer,

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

   * What led up to the situation?

kexec-tools still tries to use /bin/run-parts whereas run-parts is in /usr/bin
since debianutils 5.x

   * 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 experimental
  APT policy: (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-rc7 (SMP w/4 CPU threads)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kexec-tools depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  libc6  2.31-17
ii  lsb-base   11.1.0

kexec-tools recommends no packages.

kexec-tools suggests no packages.

-- Configuration Files:
/etc/init.d/kexec changed:
PATH=/sbin:/bin
. /lib/lsb/init-functions
test -r /etc/default/kexec && . /etc/default/kexec
if [ -d /etc/default/kexec.d ] ; then
for snippet in $(run-parts --list /etc/default/kexec.d) ; do
. "$snippet"
done
fi
do_stop () {
test "x`cat /sys/kernel/kexec_loaded`y" = "x1y" || exit 0
test -x /sbin/kexec || exit 0
log_action_msg "Will now restart with kexec"
# Clear the screen if possible
# printf "\033[;H\033[2J"
/sbin/kexec -e
log_failure_msg "kexec failed"
}
case "$1" in
  start)
# No-op
;;
  restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
  stop)
# Systemd has its own kexec service (which will call the kexec
# binary), so skip, if running with systemd
if [ ! -d /run/systemd/system ]; then
do_stop
fi
;;
  *)
echo "Usage: $0 start|stop" >&2
exit 3
;;
esac
exit 0


-- debconf information:
* kexec-tools/load_kexec: true
  kexec-tools/use_grub_config: false

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

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: moreinfo
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

We're heading towards the point where GNOME 40 is ready for unstable.
This involves the usual libmutter transition.

In addition, there have been various functionality moves and other
reshuffles among core GNOME packages. I think it will be best if we
deliberately *avoid* uploading some of the core GNOME packages to unstable
until we are fully ready for the transition.

We are *not* ready for a transition slot yet (hence moreinfo tag),
but I'm opening this bug early so we can mark it with its blockers.

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)

Additionally, libgweather entangles the transition with:

- libgweather (has Breaks on lots of things)
- evolution-data-server :-(
- gnome-applets
- gnome-calendar
- gnome-panel
- gnome-weather
- wmforecast (non-GNOME package, fixed version in experimental)

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. I hope this part can be
  broken out into a separate transition or something, perhaps by
  backporting support for the new libgweather into old callers or by
  temporarily adding compatibility with the old libgweather to new
  callers, because it links the mutter and evolution-data-server
  transitions and that doesn't seem ideal.

- Many new packages need the new gsettings-desktop-schemas.

- As usual, the new gnome-shell requires the new mutter, while the old
  gnome-shell requires the old mutter. We have to do this part in lockstep.

- GNOME Shell has changed its workspace layout from vertical to horizontal,
  and the default keybindings in gsettings-desktop-schemas have changed
  Super+PgUp, Super+PgDn to match. The new default keybindings will make
  no sense for the old Shell. I don't think this is necessarily important
  enough to need a Depends/Breaks, but we should minimize the time that
  this situation exists for.

- Mouse settings have moved from gnome-settings-daemon to
  gsettings-desktop-schemas. If we have the new g-s-d and the old g-d-s,
  things will still technically work, but gnome-tweaks will seem broken
  (because it's using the new settings that the old g-s-d ignores).

- Responsibility for audible feedback when taking a screenshot moved from
  gnome-settings-daemon to gnome-shell. Again, this isn't important enough
  to need Depends/Breaks, but we should minimize the skew.

- gnome-control-center configures all the other core packages so its
  version should not diverge.

Ben file for the mutter transition, which is the key thing here:

title = "mutter";
is_affected = .depends ~ "libmutter-7-0" | .depends ~ "libmutter-8-0";
is_good = .depends ~ "libmutter-8-0";
is_bad = .depends ~ "libmutter-7-0";

Bug#983713: Bug#983712: RFS: lebiniou/3.55.0-1 -- user-friendly, powerful music visualization / VJing tool

[Tobias Frost]

On Tue, Aug 24, 2021 at 04:07:40PM +0200, Olivier Girondel wrote:
> On 8/24/21 4:01 PM, Tobias Frost wrote:
> > Control: reopen -1
> > Conteol: forcemerge -1 992797
> > Control: retitle -1 RFS: lebiniou/3.61.1-1 -- user-friendly, powerful music
> > visualization / VJing tool
> > 
> > On Thu, 10 Jun 2021 08:27:38 +0200 Tobias Frost  wrote:
> > > On Wed, Jun 09, 2021 at 10:26:22PM +0200, Olivier Girondel wrote:
> > 
> > > You shouldn not close this RFS if you intend to have 3.60 soon; you would 
> > > then
> > > need to reopen it, as one should "recycle" a RFS until it has been 
> > > sponsored
> > > (to keep history, previous reviews, keep your spot in the queue [2],  
> > > etc…)
> > 
> > *sigh* Reopeing and force-merging then.
> 
> Hi Tobias,
> 
> I don't understand ? I unarchived this bug and retitled it for the 3.60.0-1
> release.

Apologizes, I messed up and missed the upload. Sorry about that...

 
> --
> Olivier

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

[Salvatore Bonaccorso]

Hi

On Tue, Aug 24, 2021 at 03:17:40PM +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.
> 
> Do you have an update as well pending for bullseye?

This should have gone as well to the actual bug, #992863.

Apologies for the doubled message now.

Regards,
Salvatore

Bug#983713: Bug#983712: RFS: lebiniou/3.55.0-1 -- user-friendly, powerful music visualization / VJing tool

[Olivier Girondel]

On 8/24/21 4:01 PM, Tobias Frost wrote:

Control: reopen -1
Conteol: forcemerge -1 992797
Control: retitle -1 RFS: lebiniou/3.61.1-1 -- user-friendly, powerful music
visualization / VJing tool

On Thu, 10 Jun 2021 08:27:38 +0200 Tobias Frost  wrote:

On Wed, Jun 09, 2021 at 10:26:22PM +0200, Olivier Girondel wrote:



You shouldn not close this RFS if you intend to have 3.60 soon; you would then
need to reopen it, as one should "recycle" a RFS until it has been sponsored
(to keep history, previous reviews, keep your spot in the queue [2],  etc…)


*sigh* Reopeing and force-merging then.


Hi Tobias,

I don't understand ? I unarchived this bug and retitled it for the 
3.60.0-1 release.


--
Olivier

Bug#983713: Bug#983712: RFS: lebiniou/3.55.0-1 -- user-friendly, powerful music visualization / VJing tool

[Tobias Frost]

Control: reopen -1
Conteol: forcemerge -1 992797
Control: retitle -1 RFS: lebiniou/3.61.1-1 -- user-friendly, powerful music
visualization / VJing tool

On Thu, 10 Jun 2021 08:27:38 +0200 Tobias Frost  wrote:
> On Wed, Jun 09, 2021 at 10:26:22PM +0200, Olivier Girondel wrote:

> You shouldn not close this RFS if you intend to have 3.60 soon; you would then
> need to reopen it, as one should "recycle" a RFS until it has been sponsored
> (to keep history, previous reviews, keep your spot in the queue [2],  etc…)

*sigh* Reopeing and force-merging then.

--
tobi

Bug#958402: sudo: A password is required for /usr/bin/uptime

[l0f4r0]

Sorry for the late reply...

I've finally identified where the problem is.

It appears it's not related to Conky as I thought but to VeraCrypt 
instead (1.24.23-1 is installed on my Debian 10).


Indeed, everytime I launch VeraCrypt, mount an encrypted volume and then 
fill in the volume password, I get the following line in my systemd 
journal along with a popup asking for my user password:
l0f4r0 : a password is required ; TTY=unknown ; PWD=/home/l0f4r0 ; 
USER=root ; COMMAND=/usr/bin/uptime


Well done Marc with the "sudo -n" hint.

Actually, VeraCrypt invokes `sudo -n uptime` in order to check if the 
user has an active 'sudo' session [1]:


//  Test if the user has an active "sudo" session.
//	This is only done under Linux / FreeBSD by executing the command 
'sudo -n uptime'.
//	In case a "sudo" session is active, the result of the command 
contains the string 'load average'.

//  Otherwise, the result contains "sudo: a password is required".
[...]
FILE* pipe = popen("sudo -n uptime 2>&1 | grep 'load average' | wc -l", 
"r");


I could add to my sudoers file something like the following:
l0f4r0  ALL= NOPASSWD: /usr/bin/uptime, /usr/bin/veracrypt
but I don't think that lower the security is a good idea.

Maybe using  `sudo -n uptime` is simply not the best practice from 
VeraCrypt as it trigers a priority 1 (alert) in my journal each time 
whereas it's just an event/test from a software, not a real security 
issue from my point of view.


I've seen some people recommending another approach [2] like `sudo -l 
/actual/command/to/run ; echo $?` instead but I'm not sure it solves the 
issue as this command only checks theoretical permissions, not if a sudo 
session is already on-going.
While we are at it, would you have a personal advice to VeraCrypt on how 
checking the latter case instead of a sudo on a dummy command please?


Thank you in advance :)

[1]: 
https://www.veracrypt.fr/code/VeraCrypt/commit/?id=9463a628a6315ec89934f81dc9e5d838015ec5ce


[2]: https://dev1galaxy.org/viewtopic.php?pid=23102#p23102

Bug#992869: rsyslog: imuxsock rate limiting is broken and does not work in default installation

[Petr Gajdůšek]

Package: rsyslog
Version: 8.2102.0-2
Severity: important
Tags: patch upstream
X-Debbugs-Cc: petr.gajdu...@egston.com

Dear Maintainer,

By default, imuxscock should rate limit messages with severity 1 and lower.

Related default options are useSpecialParser="true" and ratelimit.severity="1".

However, messages are not rate limited due to a bug in code:

When `useSpecialParser` is set to "true" (the default setting) all messages are
erroneously treated as having severity 0 and therefore are not subjected to the
rate limiting which by default does not affect messages with severity 0.

Debian 11 and unstable is also affected.

Rate limiting works after changing imuxsock options to ratelimit.severity="0"
or useSpecialParser="false".

e.g.

module(load="imuxsock" SysSock.RateLimit.Severity="0")

I have already filled an issue upstream [1] and a pull request [2]. I am
filling this to Debian as well as I would like to see this fixed or at least be
informed about this e.g. by apt-listbugs

1: https://github.com/rsyslog/rsyslog/issues/4667
2: https://github.com/rsyslog/rsyslog/pull/4666

Thank you for your work,

Best regards,
Petr

Bug#992868: transition: schroedinger-coordgenlibs

[Andrius Merkys]

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

Hello,

I would like to request a transition slot for schroedinger-coordgenlibs
(experimental -> unstable) due to soname bump. Current ben tracker [1]
is fine, ratt successfully rebuilds all reverse build dependencies.

Thanks,
Andrius

[1]
https://release.debian.org/transitions/html/auto-schroedinger-coordgenlibs.html

Bug#992867: Stop flooding syslog! You will fill up the disk.

[積丹尼 Dan Jacobson]

Package: x11-xkb-utils
Version: 7.7+5
Severity: grave

Did anybody take a look at syslog recently?

It is flooded with
Internal error:   Could not resolve keysym ...

So much so that the disk will fill up.

Bug#992784: cups: libcupsimage2 not a dependancy

[Brian Potkin]

reopen 992784
thanks



On Mon 23 Aug 2021 at 22:45:44 +0200, Alain Bertrand wrote:

> 
> Hello,
> 
> 
> Thanks for your answer but here apt rdepends libcupsimage2 gives totally
> different results :
> 
> apt rdepends libcupsimage2
> libcupsimage2
> Reverse Depends:
>   Dépend: libcupsimage2-dev (= 2.3.3op2-3+deb11u1)
>   Dépend: printer-driver-splix (>= 1.4.0)
>   Dépend: printer-driver-escpr (>= 1.4.0)
>   Dépend: printer-driver-dymo (>= 1.4.0)
> 
> 
> BTW, a French guy on  Debian-fr  forum had the same problem as I had with a
> fresh install, problem that was solved by the manual installation of
> libcupsimage2.

Apologies, Alain - you are correct with your apt rdepends command.
I ran mine on buster! I have reopened the report.

What is your printer and do you know what driver (if any) is being
used? Please give 'lpstat -t'.

Cheers,

Brian.

Bug#982998: chkrootkit chkproc uses incorrect value for max_pid

[Justin Hallett]

Confirming issue.

Also still present in chkrootkit_0.55-1_amd64.deb

Bug#992610: dh-make-golang make fails when no main, no external module

[Kentaro Hayashi]

 dependency
Message-Id: <20210824220059.fd903aa6fb90557a5d7d4...@xdump.org>
In-Reply-To: <20210821135114.e63a59d4081f25cf08081...@xdump.org>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


In github.com/0xax/notificator case,

If it skip findMains and findDependencies appropriately,
dh-make-golang make github.com/0xax/notificator succeeds.

https://salsa.debian.org/go-team/packages/dh-make-golang/-/blob/debian/sid/make.go#L362-368

Regards,

Bug#992866: Problem with mounting nfs shares after sudden poweroutage, fstab mount procedure jumbles nfs mounts

[Thomas Korimort]

Package: linux-image-5.10.0-8-amd64

Version: 5.10

I am already experiencing this for the second time and i feel that this
is a strange issue: I have an AMD Ryzen desktop PC with Debian Bullseye
(before Buster) and a JBOD disk tower with four fully occupied slots. On
my desktop i mount the 4 disks with ext4 file system as NFS shares via
/etc/fstab, which used to work nicely before the most recent sudden
power outage. After that the drives had to be checked and the inodes
repaired. The file system of one disk in use was destroyed and restored
through backup by copying the backup on the repaired disk. I also
changed the file permissions and ownership after the copy procedure
after a reboot. After that the mount procedure during system startup
happening in /etc/fstab did not mount anymore my nfs shares correctly.
The kernel mount procedure is waiting for 2 drives to mount and then
jumbles the nfs mounts somehow.

My /etc/fstab has this four entries related to the nfs shares:

10.10.10.2:/mnt/WD01     /mnt/WD01    nfs    rw,auto,nofail    0    0
10.10.10.2:/mnt/WD02    /mnt/WD02    nfs    rw,auto,nofail    0    0
10.10.10.2:/mnt/WD03    /mnt/WD03    nfs    rw,auto,nofail    0    0
10.10.10.2:/mnt/WD04    /mnt/WD04    nfs    rw,auto,nofail    0    0

and the actual mount in /proc/mounts lists like this

10.10.10.2:/mnt/WD04 /mnt/WD04 nfs4
rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.1,local_lock=none,addr=10.10.10.2
0 0
10.10.10.2:/mnt/WD03 /mnt/WD03 nfs4
rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.1,local_lock=none,addr=10.10.10.2
0 0
10.10.10.2:/mnt/WD02 /mnt/WD02 nfs4
rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.1,local_lock=none,addr=10.10.10.2
0 0
10.10.10.2:/mnt/WD03 /mnt/WD01 nfs4
rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.1,local_lock=none,addr=10.10.10.2
0 0

One can see that /mnt/WD03 gets mounted under /mnt/WD01 and there is no
mount entry for /mnt/WD01. The content of the two mounts seems to be
that of /mnt/WD01 (WD01 is a hand-maintained mirror of /mnt/WD02). What
is wrong here? Reboot does not change anything. This strange
constellation is carried over from reboot to reboot and i don't know
where i can find the run state or similar file that is jumbled up and
that is transferring the wrong mount information from reboot to reboot.
I looked in /var/run, /tmp aso. for files related to the kernel mount
procedure and fstab.

The mount procedure is waiting for 1,5 minutes for mounting WD01 and
WD03 and then jumbles the mounts. The drives itself are okay on my
Raspberry Pi 4 (Vanilla Debian Bullseye arm64 via image-specs script
some days ago) nfs server 10.10.10.2 and exportfs also lists ok
(10.10.10.1 exports are rw, others ro, other export options are sync and
no_root_squash for all exports):

/mnt/WD01     10.10.10.1
/mnt/WD02     10.10.10.1
/mnt/WD03     10.10.10.1
/mnt/WD04     10.10.10.1
/mnt/WD01     192.168.0.0/24
/mnt/WD01     192.168.1.0/24
/mnt/WD01     10.10.10.0/24

WD01 is exported into multiple IP adress spaces for my different router
and network switch configurations. It was working nicely till yesterday
before the sudden power outage and disk recovery.

Exactly this problem happened to me with my old Debian Buster desktop
installation and led to the same problem, when i had to replace a
harddisk and after a power outage. It seems to be a recurring problem
over the last decade of years as well as the famous pulseaudio sequencer
problem.

Greetings, Thomas Korimort.

Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash

[Florence Birée]

Le Mon, 23 Aug 2021 23:50:45 +0100,
Brian Potkin  a écrit :
>
> > But the problem is still the same for simple-scan and xsane…  
> 
> Is the "stack smashing detected" message given in these cases?

Yes, exactly.

> Please provide
> 
>   scanimage -L

$ scanimage -L
device `hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK' is
a Hewlett-Packard Deskjet_3050A_J611_series all-in-one

Cheers,
-- 
Florence Birée (elle)
06 52 92 15 32

En ces temps d'état policier, ne les laissons pas lire nos mails,
chiffrons-les ! https://emailselfdefense.fsf.org/fr/index.html


pgpLpyiEAaBj7.pgp
Description: Signature digitale OpenPGP

Bug#992865: libtgowt: please use unversioned jpeg libraries

[Gianfranco Costamagna]

Source: libtgowt
Version: 0~git20210627.91d836d+dfsg-3
Severity: important
Tags: patch

Hello, please consider switching to unversioned libjpeg-dev dependecies for 
your package.
This fixes uninstallability of build-deps in Ubuntu.


diff -Nru libtgowt-0~git20210627.91d836d+dfsg/debian/changelog 
libtgowt-0~git20210627.91d836d+dfsg/debian/changelog
--- libtgowt-0~git20210627.91d836d+dfsg/debian/changelog2021-08-19 
18:14:30.0 +
+++ libtgowt-0~git20210627.91d836d+dfsg/debian/changelog2021-08-24 
12:18:10.0 +
@@ -1,3 +1,10 @@
+libtgowt (0~git20210627.91d836d+dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Use unversioned libjpeg-dev dependency to fix an installation failure 
(Closes: #-1).
+
+ -- Gianfranco Costamagna   Tue, 24 Aug 2021 
14:18:10 +0200
+
 libtgowt (0~git20210627.91d836d+dfsg-3) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru libtgowt-0~git20210627.91d836d+dfsg/debian/control 
libtgowt-0~git20210627.91d836d+dfsg/debian/control
--- libtgowt-0~git20210627.91d836d+dfsg/debian/control  2021-08-19 
18:13:38.0 +
+++ libtgowt-0~git20210627.91d836d+dfsg/debian/control  2021-08-24 
12:18:08.0 +
@@ -10,7 +10,7 @@
  libavformat-dev,
  libavutil-dev,
  libglib2.0-dev,
- libjpeg62-turbo-dev | libjpeg62-dev | libjpeg9-dev,
+ libjpeg-dev,
  libopus-dev,
  libpipewire-0.3-dev | libpipewire-0.2-dev,
  libprotobuf-dev,

Bug#983425: add support for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi,

for your convenience, I created a merge request on salsa, fixing #989567 as
well as #983425.

https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/8

Both changes are necessary to support DPKG_ROOT. We verify that chroots created
with DPKG_ROOT and these changes are bit-by-bit identical to chroots created
the normal way in this salsaci job:

https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

Please consider applying these changes to debconf.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames

[Filippo Giunchedi]

On Tue, Aug 24, 2021 at 09:52 AM, Filippo Giunchedi wrote:
> On Tue, Jun 08, 2021 at 10:03 AM, Filippo Giunchedi wrote:
> > Package: swift-container
> > Version: 2.26.0-10
> > Severity: important
> > File: /usr/bin/swift-container-reconciler
> > 
> > Dear Maintainer,
> > I'm experimenting with Swift on Bullseye and came across a problem with
> > container-reconciler (possibly others) when using hostnames in
> > memcache_servers. Namely these errors:
> 
> In the "possibly others" category, swift-dispersion-report is also 100%
> broken in Bullseye:

I was able to get python3-eventlet to play nice with dnspython2 by
integrating https://github.com/eventlet/eventlet/pull/722 from upstream.

See debdiff attached for the result against Bullseye's python-eventlet
diff -Nru python-eventlet-0.26.1/debian/changelog python-eventlet-0.26.1/debian/changelog
--- python-eventlet-0.26.1/debian/changelog	2021-05-11 08:03:43.0 +0200
+++ python-eventlet-0.26.1/debian/changelog	2021-08-24 14:04:54.0 +0200
@@ -1,3 +1,10 @@
+python-eventlet (0.26.1-8~wmf1) bullseye; urgency=medium
+
+  * Fix dnspython 2 compat
+  ** See also https://github.com/eventlet/eventlet/pull/722
+
+ -- Filippo Giunchedi   Tue, 24 Aug 2021 14:04:54 +0200
+
 python-eventlet (0.26.1-7) unstable; urgency=medium
 
   * CVE-2021-21419: Malicious peer may exhaust memory on Eventlet side
diff -Nru python-eventlet-0.26.1/debian/greendns.orig.py python-eventlet-0.26.1/debian/greendns.orig.py
--- python-eventlet-0.26.1/debian/greendns.orig.py	2021-05-11 08:03:43.0 +0200
+++ python-eventlet-0.26.1/debian/greendns.orig.py	2021-08-24 14:04:54.0 +0200
@@ -120,12 +120,13 @@
 return is_ipv4_addr(host) or is_ipv6_addr(host)
 
 
-def compute_expiration(query, timeout):
-# NOTE(ralonsoh): in dnspython v2.0.0, "_compute_expiration" was replaced
-# by "_compute_times".
-if hasattr(query, '_compute_expiration'):
+# NOTE(ralonsoh): in dnspython v2.0.0, "_compute_expiration" was replaced
+# by "_compute_times".
+if hasattr(dns.query, '_compute_expiration'):
+def compute_expiration(query, timeout):
 return query._compute_expiration(timeout)
-else:
+else:
+def compute_expiration(query, timeout):
 return query._compute_times(timeout)[1]
 
 
@@ -669,8 +670,21 @@
 raise dns.exception.Timeout
 
 
+# Test if raise_on_truncation is an argument we should handle.
+# It was newly added in dnspython 2.0
+try:
+dns.message.from_wire("", raise_on_truncation=True)
+except dns.message.ShortHeader:
+_handle_raise_on_truncation = True
+except TypeError:
+# Argument error, there is no argument "raise_on_truncation"
+_handle_raise_on_truncation = False
+
+
 def udp(q, where, timeout=DNS_QUERY_TIMEOUT, port=53,
-af=None, source=None, source_port=0, ignore_unexpected=False):
+af=None, source=None, source_port=0, ignore_unexpected=False,
+one_rr_per_rrset=False, ignore_trailing=False,
+raise_on_truncation=False, sock=None):
 """coro friendly replacement for dns.query.udp
 Return the response obtained after sending a query via UDP.
 
@@ -695,7 +709,21 @@
 @type source_port: int
 @param ignore_unexpected: If True, ignore responses from unexpected
 sources.  The default is False.
-@type ignore_unexpected: bool"""
+@type ignore_unexpected: bool
+@param one_rr_per_rrset: If True, put each RR into its own
+RRset.
+@type one_rr_per_rrset: bool
+@param ignore_trailing: If True, ignore trailing
+junk at end of the received message.
+@type ignore_trailing: bool
+@param raise_on_truncation: If True, raise an exception if
+the TC bit is set.
+@type raise_on_truncation: bool
+@param sock: the socket to use for the
+query.  If None, the default, a socket is created.  Note that
+if a socket is provided, it must be a nonblocking datagram socket,
+and the source and source_port are ignored.
+@type sock: socket.socket | None"""
 
 wire = q.to_wire()
 if af is None:
@@ -717,7 +745,10 @@
 if source is not None:
 source = (source, source_port, 0, 0)
 
-s = socket.socket(af, socket.SOCK_DGRAM)
+if sock:
+s = sock
+else:
+s = socket.socket(af, socket.SOCK_DGRAM)
 s.settimeout(timeout)
 try:
 expiration = compute_expiration(dns.query, timeout)
@@ -765,14 +796,23 @@
 finally:
 s.close()
 
-r = dns.message.from_wire(wire, keyring=q.keyring, request_mac=q.mac)
+if _handle_raise_on_truncation:
+r = dns.message.from_wire(wire, keyring=q.keyring, request_mac=q.mac,
+  one_rr_per_rrset=one_rr_per_rrset,
+  ignore_trailing=ignore_trailing,
+  raise_on_truncation=raise_on_truncation)
+else:
+r = dns.message.from_wire(wire, keyring=q.keyring, request_mac=q.mac,
+  

Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash

[Brian Potkin]

On Tue 24 Aug 2021 at 12:34:19 +0200, Florence Birée wrote:

> Le Tue, 24 Aug 2021 10:50:19 +0100,
> Brian Potkin  a écrit :
> > Can you scan with any of these?
> > 
> > scanimage -d
> > "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK" >
> > image.pnm
> > simple-scan
> > "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"
> > xsane
> > "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"
> 
> With some tests, it seems the crash is not always reproducible (sometimes, 
> it's working…),
> so I run each command 4 times to see (and add hp-scan again, in case it crash 
> sometimes too).
> 
> Without removing the slash:
> 
> $ scanimage -d "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK" > 
> image.pnm
> 
> -> on 4 runs, 1 give "stack smashing", 3 works well…
> 
> $ simple-scan "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"
> 
> -> on 4 runs, 4 "stack smashing" crashes. I can see the top of the image 
> appearing in simple-scan,
> and the program do no crash at the same times (sometimes more of the scan is 
> displayed before the
> crash)
> 
> $ xsane "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"  
> 
> -> on 4 runs, 4 "stack smashing" crashes
> 
> $ hp-scan
> 
> -> on 4 runs, 4 "stack smashing" crash… (but it worked yesterday…)
> 
> ** after the removal of the slash in os-release:
> 
> $ scanimage -d "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK" > 
> image.pnm
> 
> -> on 4 runs, 1 "stack smashing", 3 works
> 
> $ simple-scan "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"
> 
> -> on 4 runs, 4 "stack smashing" crashes.
> 
> $ xsane "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"  
> 
> -> on 4 runs, 4 "stack smashing" crashes (but on some preliminary tests, it 
> works sometimes…)
> 
> $ hp-scan
> 
> -> on 4 runs, 4 "stack smashing" crash, at various percentages of scanning
> 
> 
> So… it seems the problem is not 100% reproducible, even if it happens in the 
> large majority
> of times… And I'm not sure the os-release changes really changes something, 
> maybe the times when
> hp-scan was working was just luck…

That's a lot of work you have done, Florence! Thanks.

We have met this "stack smashing" situation before but in a printing
context. OdyX managed to fix it then. Bug #932246.

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

There is very little more I can do now, apart from suggesting a downgrade
from HPLIP experimental packages to unstable ones. scanimage appears to
be your best bet for scanning for the present.

Good Luck,

Brian.

Bug#992864: ITP: golang-github-emersion-go-imap-sortthread -- SORT and THREAD extensions for go-imap (library)

[Nilesh Patra]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: nil...@debian.org

Subject: ITP: golang-github-emersion-go-imap-sortthread -- SORT and THREAD 
extensions for go-imap (library)
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: golang-github-emersion-go-imap-sortthread
  Version : 1.2.0
  Upstream Author : emersion
* URL : https://github.com/emersion/go-imap-sortthread
* License : Expat
  Programming Lang: Go
  Description : SORT and THREAD extensions for go-imap (library)
 This package presents SORT and THREAD extensions for go-imap
 package (src:golang-github-emersion-go-imap)

Remark: This package is maintained by Debian Go Packaging Team at
   
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-imap-sortthread

Bug#992834: nvidia-driver: No output after sleep

[Andreas Beckmann]

Control: tag -1 + upstream

On 24/08/2021 06.08, Allan Wind wrote:

At night I power off my 3 external monitors.  Next morning, I turn
them on, and press a key to bring laptop out of dpms.  This worked
fine with buster, but after the upgrade to bullseye I often (>75%)
don't get any video at all.  I use ctrl+alt+f1 to shift to a


Please try the 470.xx driver from sid/testing. Unfortunately that came 
out too late for the bullseye release, but we intend to switch to this 
driver version (which is an upstream LTS driver with updates for the 
next three years) in an early buster point release.


Andreas

Bug#975729: isc-dhcp: Please upgrade to latest upstream release 4.4.2

[Santiago Ruano Rincón]

Control: retitle -1 isc-dhcp: Please upgrade to latest upstream release 4.4.2-P1

On Wed, 25 Nov 2020 18:31:41 +0100 Fabio Pedretti  
wrote:
> Source: isc-dhcp
> Version: 4.4.1-2.1
> Severity: wishlist
> X-Debbugs-Cc: pedretti.fa...@gmail.com
> 
> Dear Maintainer,
> 
> please upgrade to latest upstream release 4.4.2, which fixes some issues
> and add some minor features. Release notes:
> https://downloads.isc.org/isc/dhcp/4.4.2/dhcp-4.4.2-RELNOTES
> 
> Thanks.

Hi,

4.4.2 was released on 22 January 2020, followed by a security release
(4.4.2-P1) last May:
http://ftp.isc.org/isc/dhcp/4.4.2-P1/dhcp-4.4.2-P1-RELNOTES
Do you have any news about upgrading the package to the latest release?
Do you need any help?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#992862: libbsd-dev: Overlay mode breaks compilation of xorg server

[Laurent Bigonville]

Package: libbsd-dev
Version: 0.10.0-1
Severity: important

Hello,

On kfreebsd, FTBFS because of the libbsd overlay:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../../dix -I../include 
-I../../../../include -Wdate-time -D_FORTIFY_SOURCE=2 -DPRE_RELEASE=0 
-DLIBBSD_OVERLAY -isystem /usr/include/bsd -DHAVE_DIX_CONFIG_H -Wall 
-Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wbad-function-cast 
-Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized 
-Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls 
-Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main 
-Werror=missing-braces -Werror=sequence-point -Werror=return-type 
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address 
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing 
-fno-strict-aliasing -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN 
-DHAS_STICKY_DIR_BIT -I/usr/include/libdrm -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/X11/dri 
-I../../../../include -I../include -I../../../../Xext -I../../../../composite 
-I../../../../damageext -I../../../../xfixes -I../../../../Xi -I../../../../mi 
-I../../../../miext/sync -I../../../../miext/shadow -I../../../../miext/damage 
-I../../../../render -I../../../../randr -I../../../../fb -I../../../../dbe 
-I../../../../present -fvisibility=hidden -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -pthread -c ../../../../dix/colormap.c  -fPIC -DPIC -o 
.libs/colormap.o
In file included from ../../../../include/os.h:58,
 from ../../../../include/misc.h:117,
 from ../../../../dix/atom.c:55:
/usr/include/bsd/stdlib.h:30:25: error: no include path in which to search for 
stdlib.h
   30 | #include_next 
  | ^
In file included from ../../../../include/os.h:61,
 from ../../../../include/misc.h:117,
 from ../../../../dix/atom.c:55:
/usr/include/bsd/string.h:28:25: error: no include path in which to search for 
string.h
   28 | #include_next 
  | ^
In file included from ../../../../include/os.h:58,
 from ../../../../include/misc.h:117,
 from ../../../../dix/colormap.c:56:
/usr/include/bsd/stdlib.h:30:25: error: no include path in which to search for 
stdlib.h
   30 | #include_next 
  | ^
In file included from ../../../../include/os.h:61,
 from ../../../../include/misc.h:117,
 from ../../../../dix/colormap.c:56:
/usr/include/bsd/string.h:28:25: error: no include path in which to search for 
string.h
   28 | #include_next 
  | ^

https://buildd.debian.org/status/fetch.php?pkg=xorg-server=kfreebsd-amd64=2%3A1.20.9-2=1606590993=0

Removing CFLAGS added by the pkg-config libbsd-overlay file, fixes the
build but getpeereid() is not detected or used anymore

I can reproduce this with a manually built version of 0.11.3-1 too

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages libbsd-dev depends on:
ii  libbsd00.11.3-1
pn  libmd-dev  

libbsd-dev recommends no packages.

libbsd-dev suggests no packages.

Bug#992861: libbsd: FTBFS on kfreebsd

[Laurent Bigonville]

Source: libbsd
Version: 0.11.3-1
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

libbsd FTBFS in the tests on kfreebsd with the following error:

FAIL: md5
=

libbsd: cannot find wrapped symbol MD5Data in libc or libmd
FAIL md5 (exit status: 134)

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#991811: unblock: libapache2-mod-auth-openidc/2.4.9-1

[Paul Gevers]

user release.debian@packages.debian.org
usertag 991811 = pu
tags 991811 = buster
reopen 991811
retitle 991811 buster-pu:package libapache2-mod-auth-openidc/2.4.9-1~deb10u1 
(pre-approval)
thanks

Hi Christoph,

On 24-08-2021 13:10, Christoph Martin wrote:
> @Release Team: What do you recommend?

This bug was closed, so most communication wasn't really visible in the SRM
workflow. I hope I got the meta info right now.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992860: dsh: bash completion errors when some files in ~/.dsh don't exist

[Christoph Anton Mitterer]

Package: dsh
Version: 0.25.10-1.4
Severity: normal



Hi.

There are a number of cases when the bash completion fails, when
some files in ~/.dsh don't exist:

# dsh -g 
bash: cd: /root/.dsh/group/: No such file or directory

=> so I guess if any component in the path misses (group, .dsh) it fails


Af creating an empty dir (mkdir -p ~/.dsh/group) it still fails:

# dsh -g 
find: ‘*’: No such file or directory
dsh: option requires an argument -- 'g'

=> the problem seems to be that if no file exists in the dear, "*" isn't
expanded to anything but stays as a literal "*"


Cheers,
Chris.

Bug#978907: #978907: timbl: ftbfs with autoconf 2.70

[Joost van Baal-Ilić]

tag 978907 +pending
thanks

thanks to Ko van der Sloot: fixed upstream in
https://github.com/LanguageMachines/timbl/commit/63740b

Bye,

Joost

Bug#992842: Slow stop due to killproc in /etc/init.d/nagios4

[Benoit DOLEZ]

Package: nagios4-common Version: 4.3.4-3
Hi,

I have problem with nagios4 on debian 10.9 than is very slow to stop (and 
restart).

# date ; systemctl stop nagios4 ; date
Tue Aug 24 09:13:04 CEST 2021
Tue Aug 24 09:13:19 CEST 2021
# 

=> 15 seconds 

After debug, I think I have found an error in the call to "killproc" than need 
progname as parameter to work.

--- /etc/init.d/nagios4.orig    2021-08-18 01:59:17.172227277 +0200
+++ /etc/init.d/nagios4    2021-08-18 01:58:27.017586384 +0200
@@ -146,7 +146,7 @@
 }
 
 stop () {
-    killproc -p $THEPIDFILE
+    killproc -p $THEPIDFILE $NAME
 ret=$?
 if [ `pidof nagios4 | wc -l ` -gt 0 ]; then
 echo -n "Waiting for $NAME daemon to die.."


Regards

Benoit

-- Benoit DOLEZ, e-mail: bdo...@zenetys.com

Bug#677430: `gio open` exits before its child process does

[Simon McVittie]

Control: reassign -1 libglib2.0-bin 2.56.1-1
Control: retitle -1 `gio open` exits before its child process does
Control: forwarded -1 https://gitlab.gnome.org/GNOME/glib/-/issues/1208
Control: tags -1 = upstream

On Thu, 14 Jun 2012 at 00:28:17 +0200, Vincent Bernat wrote:
> gvfs-open allows one to open a file with the "preferred
> application".

gvfs-open is obsolete and is likely to be removed from Debian 12.
The replacement is `gio open`, which has basically the same design
(and therefore the same issue when opening short-lived files), so I'm
reassigning this to `gio open`.

In Debian 11, gvfs-open is a Debian-specific shell script that wraps
`gio open`.

> I have just provided a patch. Maybe it could go in Debian before being
> applied upstream

Sorry, we are not going to add new "API" in Debian unless it has been
accepted upstream (or at the very least, is well on the way to being
accepted upstream), and new command-line options and behaviours are API.

smcv

Bug#922615: nvidia-driver: Windows not visible on third screen after stable upgrade

[Andreas Ronnquist]

I have just upgraded to Bullseye (and nvidia-driver 460.91.03-1) - and
this problem is gone.

Feel free to close this bug. (I leave this to you, if you want to track
this further, otherwise I am fine with you closing it).

Thanks for packaging and maintaining the Nvidia drivers!

-- Andreas Rönnquist
gus...@debian.org

Bug#991897: removal of the any/local-rtlddir-cross.diff patch broke cross builds

[Aurelien Jarno]

Hi,

On 2021-08-18 15:43, Aurelien Jarno wrote:
> Hi,
> 
> On 2021-08-18 11:02, Matthias Klose wrote:
> > On 8/6/21 10:44 AM, Aurelien Jarno wrote:
> > > control: reassign -1 cross-toolchain-base-ports-46
> > > control: tag -1 + patch
> > > control: tag -1 - moreinfo
> > > control: tag -1 - unreproducible
> > > 
> > > On 2021-08-05 18:59, Aurelien Jarno wrote:
> > >> control: tag -1 + moreinfo
> > >> control: tag -1 + unreproducible
> > >>
> > >> On 2021-08-04 19:03, Matthias Klose wrote:
> > >>> Package: src:glibc
> > >>> Version: 2.31-13
> > >>> Severity: serious
> > >>> Tags: sid bullseye
> > >>>
> > >>> when cross-building glibc in the c-t-b packages, the libc.so linker 
> > >>> file for
> > >>> some non-default multilib builds like the sparc build for sparc64 is 
> > >>> broken,
> > >>> leading to build failures for at least all gcc-N cross multilib 
> > >>> packages at least.
> > >>>
> > >>> $ cat usr/lib32/libc.so
> > >>> /* GNU ld script
> > >>>Use the shared library, but some functions are only in
> > >>>the static library, so try that secondarily.  */
> > >>> OUTPUT_FORMAT(elf32-sparc)
> > >>> GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a  AS_NEEDED (
> > >>> /lib/ld-linux.so.2 ) )
> > >>
> > >> Can you point me where you got that file? It doesn't make sense from the
> > >> path and the content point of view. Also it's not what I get in the
> > >> libc6-sparc-sparc64-cross package generated by building
> > >> cross-toolchain-base-ports in a bullseye chroot. I get instead:
> > >>
> > >> | cat /usr/sparc64-linux-gnu/lib32/libc.so  
> > >> | /* GNU ld script
> > >> |    Use the shared library, but some functions are only in
> > >> |the static library, so try that secondarily.  */
> > >> | OUTPUT_FORMAT(elf32-sparc)
> > >> | GROUP ( /usr/sparc64-linux-gnu/lib32/libc.so.6 
> > >> /usr/sparc64-linux-gnu/lib32/libc_nonshared.a  AS_NEEDED ( 
> > >> /usr/sparc64-linux-gnu/lib/ld-linux.so.2 ) )
> > >>
> > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985617#62 says that 
> > >>> the
> > >>> maintainer is investigating, but apparently this never happened.
> > >>
> > >> I *did* investigate, and checked that the changes in the linker files
> > >> are correct. I have just done that again for both cross-toolchain-base
> > >> and cross-toolchain-base-ports. Here are the differences I observed on
> > >> the linker scripts:
> > > 
> > > I have ran a build of gcc-10-cross and gcc-10-cross-ports over the
> > > night. gcc-10-cross just built fine, but gcc-10-cross-ports indeed
> > > failed to build the sparc64 cross compiler as you reported.
> > > 
> > > It appears that the embedded copy of dpkg-cross decided to map the
> > > multiarch path to /usr/$triplet/lib, leaving lib32, lib64 or libx32 to
> > > the other multilib builds. This causes an issue for the dynamic linker
> > > symlink, which usually follows the upstream way of putting a 64-bit
> > > library in /lib64. At the end, it means the 32-bit dynamic linker
> > > ends-up in the /usr/triplet/lib directory containing the 64 bit
> > > libraries. This is not a big deal for most architectures, except when
> > > the 32- and 64-bit dynamic linkers have the same name like on sparc64.
> > > 
> > > The problem seems to have been identified, as one of the two is just
> > > removed in the debian/rules file, with this associated comment:
> > > 
> > > # FIXME: don't remove these here, but find out why these are left in the 
> > > glibc build
> > > 
> > > The problem is that the removed one is the most useful one, breaking the
> > > assumption that /usr/$triplet/$rtld.so exists. The following patches
> > > fixes the issue for sparc64:
> > > 
> > > 
> > > diff -Nru cross-toolchain-base-ports-45/debian/rules 
> > > cross-toolchain-base-ports-46/debian/rules
> > > --- cross-toolchain-base-ports-45/debian/rules2021-03-03 
> > > 15:22:03.0 +0100
> > > +++ cross-toolchain-base-ports-46/debian/rules2021-08-06 
> > > 10:31:22.0 +0200
> > > @@ -831,7 +831,7 @@
> > >   case "$$pkgname" in \
> > > libc6-mips32-mips64-cross|libc6-mips32-mips64el-cross) \
> > >   rm -f $$tmp/usr/*/lib/ld.so.1;; \
> > > -   libc6-sparc-sparc64-cross) \
> > > +   libc6-sparc64-cross) \
> > >   rm -f $$tmp/usr/*/lib/ld-linux.so.2;; \
> > >   esac; \
> > >   if [ 'lib$(libgcc_base)1-dbg-$${cross_arch}-cross' = $$pkgname ]; then \
> > > 
> > > I guess the same fix is needed for gcc-10-cross-mipsen, but I haven't
> > > been able to build it yet.
> > 
> > this fixes the gcc-N-cross-ports build, but leaves the libc.so with the 
> > wrong
> > path of ld-linux.so.2.
> 
> What do you mean with the wrong path? gcc-N-cross-ports failed to build
> because it was pointing to the wrong ld-linux.so.2. If it builds, I
> believe it points to the correct one.
> 
> > Do you intend to fix that, or should that be worked
> > around in the c-t-b package?
> 
> This is not something to fix in the glibc package. The packages
> generated by cross-compiling glibc have 

Bug#991811: unblock: libapache2-mod-auth-openidc/2.4.9-1

[Christoph Martin]

Hi Salvatore,
dear Release Team,

Am 23.08.21 um 14:46 schrieb Salvatore Bonaccorso:
> Hi Christoph,
> 
> On Mon, Aug 23, 2021 at 01:17:18PM +0200, Christoph Martin wrote:
>> Hi Salvatore,
>>
>> Am 19.08.21 um 21:32 schrieb Salvatore Bonaccorso:
>>> Hi Christoph,
>>>
>>> On Tue, Aug 10, 2021 at 01:42:32PM +0200, Christoph Martin wrote:
 Dear Security Team,

 the fixed version is now in bullseye. Thanks for that.

 What is the plan for buster and stretch? Do you prepare fixes?
>>>
>>> thanks for following up on that. For buster, can you fix those issues,
>>> and ideally as well CVE-2019-14857 (#942165) and CVE-2019-20479 via an
>>> upcoming buster point release?
>>
>> Ok. I prepare that update. That would be a version 2.4.9-1~deb11u1 ?
> 
> Depends (but then ~deb10u1). 

You are right. My fault.

> Why i say depends: buster has currently
> 2.3.10.2-1, and I'm not sure if we can be confident to bump the
> version from 2.3.10.2 upstream to 2.4.9? This has to be acked by the
> release team if suitable.
> 
> If SRM agree on importing the 2.4.9 version: if it is merely a rebuild
> of the bullseye package back for buster, then 2.4.9-1~deb10u1 would be
> good, if it's an import of new upstream on top of the current
> packaging instead I would choose 2.4.9-0+deb10u1.

It would be a rebuild of the bullseye package for buster. As I commented
in the fix for bullseye in Bug 991811:

> The fix to CVE-2021-32791 looks quite big, so that I think it is not
> safe to backport it to 2.4.4.1 like the others could be.

So a backport seams not to be a good solution.
I tested the bullseye package on buster and even that works without a
problem in buster.

> But the most important question here is if SRM agree on bumping the
> version to 2.4.9.
> 
> If feasible to cherry-pick the needed patches then this would be
> 2.3.10.2-1+deb10u1.
> 

@Release Team: What do you recommend?

Christoph



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992855: upgrade-reports: buster to bullseye, nvme logs make ttys messy.

[Paul Gevers]

Control: reassign -1 kernel

Hi,

Although as you said, it may be something else, as it's the kernel
logging this, I reassign to the kernel package, in the hope they are
more able to pinpoint where the problem lies.

Paul

On 24-08-2021 10:53, hox...@noramail.jp wrote:
> Package: upgrade-reports
> Severity: normal
> 
> Dear maintainers,
> 
> I've upgraded one of my buster 10.10 into bullseye 11.
> 
> * Upgrading was mostly successfull.
> 
> * As "buster" GNOME desktop it had almost no problem,
>   and upgraded "bullseye" GNOME session seems fine for now.
> 
> However, after rebooting the issue below stared on ttys.
> 
>   The machine has one NVMe and one SATA SSD (separated /home).
>   The Entire system installed into LUKS2 encrypted LVM volumes.
>   Mostly "main" packages except Intel microcode ("non-free").
> 
> NVMe continual syslog messsage on terminal
> ==
> 
> 1. kernel reports nvme RxErr related messages.
> 2. on any tty (even in rescue.target).
> 3. almost always (I/O access on NVMe seems to be a trigger).
> 
> AFAIK, the reported device (WD BLACK NVMe) works fine
> and "nvme smartlog" have not reported any error in years.
> 
> After bullseye upgrading kernel started this reporting on ttys.
> 
> At the same time, "smartd" seems to have a minor systemd unit problem,
> and it also seems to start tracking NVMe just like below syslog sample
> (at the smartd starting log section).
> "smartd" in buster only monitored SATA SSD.
> 
> I can not tell what actual package and/or whether that device caused this,
> posting this bug report to "upgrade-reports".
> 
> Actual syslog (partially modified; DATETIME/HOSTNAME/SERIAL_NUMBER)
> -
> 
> 1. Cold booted.
> 2. systemctl shows no error.
> 3. target was shifted during this log sampling (graphical, rescue, multiuser, 
> graphical).
> 
> syslog and my comments follow:
> 
> Aug 23 19:50:27 hostname kernel: [0.289634] pci :01:00.0: [15b7:5002] 
> type 00 class 0x010802
> Aug 23 19:50:27 hostname kernel: [0.289657] pci :01:00.0: reg 0x10: 
> [mem 0xdf00-0xdf003fff 64bit]
> Aug 23 19:50:27 hostname kernel: [0.289691] pci :01:00.0: reg 0x20: 
> [mem 0xdf004000-0xdf0040ff 64bit]
> Aug 23 19:50:27 hostname kernel: [0.718254] pci :01:00.0: Adding to 
> iommu group 11
> Aug 23 19:50:27 hostname kernel: [1.020213] nvme nvme0: pci function 
> :01:00.0
> Aug 23 19:50:27 hostname kernel: [1.029047] nvme nvme0: 4/0/0 
> default/read/poll queues
> Aug 23 19:50:27 hostname kernel: [1.031074]  nvme0n1: p1 p2 p3
> 
> This NVMe contains EFI, /boot, and LUKS root filesystem except /home (in SATA 
> SSD).
> 
> Aug 23 19:50:27 hostname kernel: [   15.626412] input: HDA Intel PCH 
> HDMI/DP,pcm=7 as /devices/pci:00/:00:1f.3/sound/card0/input18
> Aug 23 19:50:27 hostname kernel: [   15.626483] input: HDA Intel PCH 
> HDMI/DP,pcm=8 as /devices/pci:00/:00:1f.3/sound/card0/input19
> Aug 23 19:50:27 hostname kernel: [   15.626548] input: HDA Intel PCH 
> HDMI/DP,pcm=9 as /devices/pci:00/:00:1f.3/sound/card0/input20
> 
> The first NVMe RxErr reporting starts after the kernel dmesg (after sound 
> subsystem).
> 
> Aug 23 19:50:27 hostname kernel: [   17.365057] pcieport :00:1b.0: AER: 
> Corrected error received: :01:00.0
> Aug 23 19:50:27 hostname kernel: [   17.365089] nvme :01:00.0: PCIe Bus 
> Error: severity=Corrected, type=Physical Layer, (Receiver ID)
> Aug 23 19:50:27 hostname kernel: [   17.365117] nvme :01:00.0:   device 
> [15b7:5002] error status/mask=0001/e000
> Aug 23 19:50:27 hostname kernel: [   17.365142] nvme :01:00.0:[ 0] 
> RxErr 
> 
> Then, on any tty (regardless the login status),
> it keep showing that messages like this.
> DATETIME was modified but kernel timing is the real log.
> 
> Aug 23 19:51:16 hostname kernel: [   70.416916] pcieport :00:1b.0: AER: 
> Corrected error received: :01:00.0
> Aug 23 19:51:16 hostname kernel: [   70.417029] nvme :01:00.0: PCIe Bus 
> Error: severity=Corrected, type=Physical Layer, (Receiver ID)
> Aug 23 19:51:16 hostname kernel: [   70.417145] nvme :01:00.0:   device 
> [15b7:5002] error status/mask=0001/e000
> Aug 23 19:51:16 hostname kernel: [   70.417268] nvme :01:00.0:[ 0] 
> RxErr 
> Aug 23 19:51:17 hostname kernel: [   71.693968] pcieport :00:1b.0: AER: 
> Corrected error received: :01:00.0
> Aug 23 19:51:17 hostname kernel: [   71.699967] nvme :01:00.0: PCIe Bus 
> Error: severity=Corrected, type=Physical Layer, (Receiver ID)
> Aug 23 19:51:17 hostname kernel: [   71.701511] nvme :01:00.0:   device 
> [15b7:5002] error status/mask=0001/e000
> Aug 23 19:51:17 hostname kernel: [   71.703040] nvme :01:00.0:[ 0] 
> RxErr 
> Aug 23 19:51:19 hostname kernel: [   73.739331] pcieport :00:1b.0: AER: 
> Corrected 

Bug#927379: Debian Bug Report Tracking System

[Vásárhelyi József]

Hi Paul,

Answer to the content of:

/etc/apt/preferences.d/*

Is empty!

Regards,
József

2021. 08. 24. 9:31 keltezéssel, Paul Gevers írta:

Hi József,

First of, any reason why you didn't send this to the bug report? It is
highly recommended to keep the bug report in the loop, such that others
can chime in too. Especially when the bug gets reassigned (which is
likely to happen, see below), they need the same information. I'm *not*
doing that now as you may have had your reasons, but if OK with you,
please send the message from you again to the bug number and reply to my
mail there too.

On 24-08-2021 09:08, Vásárhelyi József wrote:

Please see the requested files attached.

Thanks.


Do you mean by upgrade, which is in the last line of this file that I
make a mistake doing upgrade.

Because some of your .list files have "stable" as the suite name, you
may get upgrades to bullseye from those archives. I *very highly*
recommend to always use the (same) codename in all .list files to avoid
surprises.


At the moment I only wanted to upgrade the
libre office and I did not wanted to upgrade Debian to the new version
Debian 11.

Ack.


However apt it seems to is working, but synaptic not.

There's no mentioning of stable-updates in any of these files. Can you
share the content of /etc/apt/preferences.d/* Also, if apt works, but
synaptic doesn't this feels like a bug in synaptic.


Paul

<>

Bug#992854: digikam: symbol lookup error: undefined symbol: FT_Palette_Select

[Alain Bertrand]

I tried to build digikam from source

usr/bin/ld : /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 : référence 
indéfinie vers « FT_Palette_Select »
/usr/bin/ld : /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 : référence 
indéfinie vers « FT_Get_Color_Glyph_Layer »

collect2: error: ld returned 1 exit status


Best regards


Alain

Bug#992841: obs-studio: fails to ouput to V4L loopback device. Black Screen if loopback device used by video application.

[Frank Ehmsen]

Package: obs-studio
Version: 26.1.2+dfsg1-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
 I wanted to use obs-studio with Zoom or Microsoft Teams. I am also
 a user of the package nvidia-driver.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I installed v4l2loopback-dkms before starting obs-studio,
 configured my scene in obs-studio and hit the button "start virtual
 camera". 

   * What was the outcome of this action?
 The virtual video device appeared in Zoom or Microsoft Teams, but
 shows only a black screen.

   * What outcome did you expect instead?
 The virtual camera device should show the configured scene from
 obs-studio.

-- 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/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages obs-studio depends on:
ii  libavcodec58  7:4.3.2-0+deb11u2
ii  libavdevice58 7:4.3.2-0+deb11u2
ii  libavformat58 7:4.3.2-0+deb11u2
ii  libavutil56   7:4.3.2-0+deb11u2
ii  libc6 2.31-13
ii  libcurl3-gnutls   7.74.0-1.3+b1
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libjansson4   2.13.1-1.1
ii  libluajit-5.1-2   2.1.0~beta3+dfsg-5.3
ii  libmbedcrypto32.16.9-0.1
ii  libmbedtls12  2.16.9-0.1
ii  libmbedx509-0 2.16.9-0.1
ii  libobs0   26.1.2+dfsg1-2
ii  libpulse0 14.2-2
ii  libpython3.9  3.9.2-1
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5svg55.15.2-3
ii  libqt5widgets55.15.2+dfsg-9
ii  libqt5x11extras5  5.15.2-2
ii  libqt5xml55.15.2+dfsg-9
ii  libspeexdsp1  1.2~rc1.2-1.1
ii  libstdc++610.2.1-6
ii  libswscale5   7:4.3.2-0+deb11u2
ii  libudev1  247.3-6
ii  libv4l-0  1.20.0-2
ii  libx11-6  2:1.7.2-1
ii  libx264-160   2:0.160.3011+gitcde9a93-2.1
ii  libxcb-randr0 1.14-3
ii  libxcb-shm0   1.14-3
ii  libxcb-xfixes01.14-3
ii  libxcb-xinerama0  1.14-3
ii  libxcb1   1.14-3
ii  libxcomposite11:0.4.5-1
ii  libxfixes31:5.0.3-2
ii  python3   3.9.2-3
ii  python3.9 3.9.2-1

Versions of packages obs-studio recommends:
ii  obs-plugins  26.1.2+dfsg1-2

Versions of packages obs-studio suggests:
ii  policykit-10.105-31
ii  v4l2loopback-dkms  0.12.5-1

-- no debconf information

Bug#992800: puppet agent breaks after upgrade to bullseye on arm architecture

[CHARD Ian]

I just ran into this and found that it was caused by libfacter being linked to 
two different Boost versions.

Upgrading facter and libfacter to 3.14.12-1+b2 fixed the problem.

Cheers
- Ian

--
Ian Chard mailto:ian.ch...@ed.ac.uk>>
Learning and Information Technology Manager
School of History, Classics and Archaeology, room 1M.09
University of Edinburgh
Tel:  +44 (0)131 651 5044   (internal: 515044)

The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh 
Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.

Bug#992859: RFS: opendmarc/1.4.1.1-1 -- Milter implementation of DMARC

[David Bürgin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opendmarc
   Version : 1.4.1.1-1
   Upstream Author : The Trusted Domain Project
 * URL : http://www.trusteddomain.org/opendmarc
 * License : GPL-3+ with AutoConf exception, BSD-3-clause and SOSL, 
BSD-2-clause
 * Vcs : https://salsa.debian.org/kitterman/opendmarc
   Section : mail

It builds those binary packages:

  libopendmarc-dev - Headers and development libraries for the OpenDMARC library
  libopendmarc2 - Library for DMARC validation and reporting
  opendmarc - Milter implementation of DMARC

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opendmarc/opendmarc_1.4.1.1-1.dsc

Changes since the last upload:

 opendmarc (1.4.1.1-1) unstable; urgency=medium
 .
   [ David Bürgin ]
   * New upstream release
 - Refresh patches, delete patches incorporated upstream
 - Update copyright information
   * Add new patches:
 - hold-quarantined-messages-doc.patch: Correct HoldQuarantinedMessages doc
 - insheader.patch: Insert trace headers at index 0
 - check_domain.patch: Make function check_domain static
 - arcseal-segfaults.patch: Fix segfaults in ARC-Seal headers
 - conf_refcnt.patch: Remove invalid assert statement
 - free-arcdomain.patch: Fix memory leak when evaluating ARC chain
 - arc-override-quarantine.patch: Add ARC override for policy "quarantine"
   * Set "Rules-Requires-Root: no" in d/control
   * Bump Standards-Version to 4.6.0 without further change
 .
   [ Camaleón ]
   * [INTL:es] Spanish translation of the debconf template (Closes: #987480)

The Lintian error and warning are problems of Lintian, not of this
package. (Lintian needs an update for the Standards-Version bump, and
the /usr/lib/systemd/system issue is work in progress #992465.)

Thank you!
David

Bug#992858: RFS: opendkim/2.11.0~beta2-5 -- DomainKeys Identified Mail (DKIM) signing and verifying milter

[David Bürgin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opendkim
   Version : 2.11.0~beta2-5
   Upstream Author : The Trusted Domain Project
 * URL : http://www.opendkim.org/
 * License : ISC, BSD-3-clause and SOSL, GPL-3+ with AutoConf exception
 * Vcs : https://salsa.debian.org/debian/opendkim
   Section : mail

It builds those binary packages:

  miltertest - utility for testing milter applications
  librbl-dev - Real-time Blacklist (RBL) query library (development files)
  librbl1 - Real-time Blacklist (RBL) query library
  libvbr-dev - Vouch By Reference (VBR) library (development files)
  libvbr2 - Vouch By Reference (VBR) library
  libopendkim-dev - DomainKeys Identified Mail (DKIM) library (development 
files)
  libopendkim11 - DomainKeys Identified Mail (DKIM) library
  opendkim-tools - utilities for administering the OpenDKIM milter
  opendkim - DomainKeys Identified Mail (DKIM) signing and verifying milter

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opendkim/opendkim_2.11.0~beta2-5.dsc

Changes since the last upload:

 opendkim (2.11.0~beta2-5) unstable; urgency=medium
 .
   * opendkim-tools: Do not install obsolete opendkim-convert-keylist script.
   * Add new patches:
 - cve-2020-12272.patch: Mitigation for CVE-2020-12272.
 - opendkim-genkey-typo.patch: Correct typo in man page (Closes: #960447).
 - replace-headers.patch: Fix ReplaceHeaders parameter (Closes: #986878).
 - insheader.patch: Insert trace headers at index 0.
 - mlfi_close.patch: Fix segfault due to use-after-free in mlfi_close.
 - conf_refcnt.patch: Remove invalid assert statement.
   * debian/control: Set "Rules-Requires-Root: no".
   * Bump Standards-Version to 4.6.0 without further changes.

The Lintian error and warning are problems of Lintian, not of this
package. (Lintian needs an update for the Standards-Version bump, and
the /usr/lib/systemd/system issue is work in progress #992465.)

Thank you!
David

Bug#992857: wayland-protocols: please release 1.21 to unstable when ready

[Simon McVittie]

Package: wayland-protocols
Version: 1.20-1
Severity: wishlist
Control: fixed -1 1.21-1

I'm looking at what would be needed to get GTK 4 into testing/unstable,
and one of its dependencies is wayland-protocols 1.21. If 1.21 is ready
for wider testing and does not have an unacceptable regression risk,
please upload it to unstable.

Thanks,
smcv

Bug#992856: pulseaudio: Pulseaudio does not automatically start on newer kernel

[Pierre-Yves Luyten]

Package: pulseaudio
Version: 14.2-2
Severity: normal

Since upgrade to bullseye, I noticed pulseaudio is not automatically started.
For example in GNOME preferences sound preferences are empty, pavucontrol does
not start.

If i manually start pulseaudio like below, then i can see the sound
preferences, or use pa related tools.
$ pulseaudio

I run into the default kernel.

# uname -r
5.10.0-8-amd64

I noticed if i boot under an older kernel, pulseaudio is started automatically,
the bug does not happen. I picked a random one for testing, linux-
image-4.19.0-17-amd64.

Please tell me what additional information could i provide to help?


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- 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/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2
ii  libgcc-s110.2.1-6
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.2-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-2
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-6
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.3-6
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.2-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-2
ii  libpam-systemd [logind]  247.3-6
pn  rtkit

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  4.0-2
pn  pavumeter
ii  udev 247.3-6

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; 

Bug#992855: upgrade-reports: buster to bullseye, nvme logs make ttys messy.

[hoxp18]

Package: upgrade-reports
Severity: normal

Dear maintainers,

I've upgraded one of my buster 10.10 into bullseye 11.

* Upgrading was mostly successfull.

* As "buster" GNOME desktop it had almost no problem,
  and upgraded "bullseye" GNOME session seems fine for now.

However, after rebooting the issue below stared on ttys.

  The machine has one NVMe and one SATA SSD (separated /home).
  The Entire system installed into LUKS2 encrypted LVM volumes.
  Mostly "main" packages except Intel microcode ("non-free").

NVMe continual syslog messsage on terminal
==

1. kernel reports nvme RxErr related messages.
2. on any tty (even in rescue.target).
3. almost always (I/O access on NVMe seems to be a trigger).

AFAIK, the reported device (WD BLACK NVMe) works fine
and "nvme smartlog" have not reported any error in years.

After bullseye upgrading kernel started this reporting on ttys.

At the same time, "smartd" seems to have a minor systemd unit problem,
and it also seems to start tracking NVMe just like below syslog sample
(at the smartd starting log section).
"smartd" in buster only monitored SATA SSD.

I can not tell what actual package and/or whether that device caused this,
posting this bug report to "upgrade-reports".

Actual syslog (partially modified; DATETIME/HOSTNAME/SERIAL_NUMBER)
-

1. Cold booted.
2. systemctl shows no error.
3. target was shifted during this log sampling (graphical, rescue, multiuser, 
graphical).

syslog and my comments follow:

Aug 23 19:50:27 hostname kernel: [0.289634] pci :01:00.0: [15b7:5002] 
type 00 class 0x010802
Aug 23 19:50:27 hostname kernel: [0.289657] pci :01:00.0: reg 0x10: 
[mem 0xdf00-0xdf003fff 64bit]
Aug 23 19:50:27 hostname kernel: [0.289691] pci :01:00.0: reg 0x20: 
[mem 0xdf004000-0xdf0040ff 64bit]
Aug 23 19:50:27 hostname kernel: [0.718254] pci :01:00.0: Adding to 
iommu group 11
Aug 23 19:50:27 hostname kernel: [1.020213] nvme nvme0: pci function 
:01:00.0
Aug 23 19:50:27 hostname kernel: [1.029047] nvme nvme0: 4/0/0 
default/read/poll queues
Aug 23 19:50:27 hostname kernel: [1.031074]  nvme0n1: p1 p2 p3

This NVMe contains EFI, /boot, and LUKS root filesystem except /home (in SATA 
SSD).

Aug 23 19:50:27 hostname kernel: [   15.626412] input: HDA Intel PCH 
HDMI/DP,pcm=7 as /devices/pci:00/:00:1f.3/sound/card0/input18
Aug 23 19:50:27 hostname kernel: [   15.626483] input: HDA Intel PCH 
HDMI/DP,pcm=8 as /devices/pci:00/:00:1f.3/sound/card0/input19
Aug 23 19:50:27 hostname kernel: [   15.626548] input: HDA Intel PCH 
HDMI/DP,pcm=9 as /devices/pci:00/:00:1f.3/sound/card0/input20

The first NVMe RxErr reporting starts after the kernel dmesg (after sound 
subsystem).

Aug 23 19:50:27 hostname kernel: [   17.365057] pcieport :00:1b.0: AER: 
Corrected error received: :01:00.0
Aug 23 19:50:27 hostname kernel: [   17.365089] nvme :01:00.0: PCIe Bus 
Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Aug 23 19:50:27 hostname kernel: [   17.365117] nvme :01:00.0:   device 
[15b7:5002] error status/mask=0001/e000
Aug 23 19:50:27 hostname kernel: [   17.365142] nvme :01:00.0:[ 0] 
RxErr 

Then, on any tty (regardless the login status),
it keep showing that messages like this.
DATETIME was modified but kernel timing is the real log.

Aug 23 19:51:16 hostname kernel: [   70.416916] pcieport :00:1b.0: AER: 
Corrected error received: :01:00.0
Aug 23 19:51:16 hostname kernel: [   70.417029] nvme :01:00.0: PCIe Bus 
Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Aug 23 19:51:16 hostname kernel: [   70.417145] nvme :01:00.0:   device 
[15b7:5002] error status/mask=0001/e000
Aug 23 19:51:16 hostname kernel: [   70.417268] nvme :01:00.0:[ 0] 
RxErr 
Aug 23 19:51:17 hostname kernel: [   71.693968] pcieport :00:1b.0: AER: 
Corrected error received: :01:00.0
Aug 23 19:51:17 hostname kernel: [   71.699967] nvme :01:00.0: PCIe Bus 
Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Aug 23 19:51:17 hostname kernel: [   71.701511] nvme :01:00.0:   device 
[15b7:5002] error status/mask=0001/e000
Aug 23 19:51:17 hostname kernel: [   71.703040] nvme :01:00.0:[ 0] 
RxErr 
Aug 23 19:51:19 hostname kernel: [   73.739331] pcieport :00:1b.0: AER: 
Corrected error received: :01:00.0
Aug 23 19:51:19 hostname kernel: [   73.745023] nvme :01:00.0: PCIe Bus 
Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Aug 23 19:51:19 hostname kernel: [   73.746547] nvme :01:00.0:   device 
[15b7:5002] error status/mask=0001/e000
Aug 23 19:51:19 hostname kernel: [   73.748053] nvme :01:00.0:[ 0] 
RxErr 
Aug 23 19:51:20 hostname kernel: [   74.506475] pcieport :00:1b.0: AER: 
Corrected 

Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash

[Brian Potkin]

On Tue 24 Aug 2021 at 11:18:15 +0200, Florence Birée wrote:

> Le Mon, 23 Aug 2021 23:50:45 +0100,
> Brian Potkin  a écrit :
> >
> > > But the problem is still the same for simple-scan and xsane…  
> > 
> > Is the "stack smashing detected" message given in these cases?
> 
> Yes, exactly.
> 
> > Please provide
> > 
> >   scanimage -L
> 
> $ scanimage -L
> device `hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK' is
> a Hewlett-Packard Deskjet_3050A_J611_series all-in-one

Can you scan with any of these?

scanimage -d "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK" > 
image.pnm
simple-scan "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"
xsane "hpaio:/usb/Deskjet_3050A_J611_series?serial=CN31L1CQMP05WK"

You could also try removing the slash from os-release.

Cheers,

Brian.

Bug#927379: Debian Bug Report Tracking System

[Vásárhelyi József]

Sorry I forgot to send the letter to bug report.


2021. 08. 24. 9:08 keltezéssel, Vásárhelyi József írta:

Dear Paul!

Please see the requested files attached.

I also attached an sh file.

Do you mean by upgrade, which is in the last line of this file that I 
make a mistake doing upgrade. At the moment I only wanted to upgrade 
the libre office and I did not wanted to upgrade Debian to the new 
version Debian 11.


However apt it seems to is working, but synaptic not.

Best regards, and thenk you for your support,

József

2021. 08. 23. 14:52 keltezéssel, Paul Gevers írta:

Hi József,

On 23-08-2021 14:38, Vásárhelyi József wrote:

E: The "stable-updates" value is invalid  APT::Default Release
setuting, does not exist in the edition(version) sources

E: _cache->open() failed, please report.

What's the content of your /etc/apt/sources.list file and what's the
content of files in /etc/apt/source.list.d/?

We released a new version of Debian on Saturday 14 August. You seem to
have "stable" listed in your apt sources, which can give you surprises
if you're not expecting a new Debian release. Were you aware we released
a new version and were you expected to upgrade?

Paul

<>

Bug#992854: digikam: symbol lookup error: undefined symbol: FT_Palette_Select

[Alain Bertrand]

Package: digikam
Version: 4:7.1.0-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: alai...@free.fr

Dear Maintainer,

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

   * What led up to the situation?
I upgraded from Buster to Bullseye
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Launching digikam
   * What was the outcome of this action?
digikam: symbol lookup error: /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5: 
undefined symbol: FT_Palette_Select and digikam exits
   * What outcome did you expect instead?
Using digikam




-- 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-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages digikam depends on:
ii  digikam-data  4:7.1.0-2
ii  digikam-private-libs  4:7.1.0-2
ii  libc6 2.31-13
ii  libgcc-s1 10.2.1-6
ii  libkf5configcore5 5.78.0-4
ii  libkf5coreaddons5 5.78.0-4
ii  libkf5i18n5   5.78.0-2
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.3
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5sql55.15.2+dfsg-9
ii  libqt5sql5-mysql  5.15.2+dfsg-9
ii  libqt5sql5-sqlite 5.15.2+dfsg-9
ii  libqt5widgets55.15.2+dfsg-9
ii  libstdc++610.2.1-6
ii  perl  5.32.1-4+deb11u1

Versions of packages digikam recommends:
ii  chromium [www-browser] 90.0.4430.212-1
ii  ffmpegthumbs   4:20.12.0-1
ii  firefox-esr [www-browser]  78.13.0esr-1~deb11u1

Versions of packages digikam suggests:
pn  digikam-doc 
pn  systemsettings  

-- no debconf information

Bug#992528: octave-mapping: FTBFS with GDAL 3.3.1

[Rafael Laboissière]

* Sebastiaan Couwenberg  [2021-08-24 08:57]:


On 8/24/21 8:40 AM, Rafael Laboissière wrote:

P.S.2: In order to not prevent the blocking of the ligdal 28→29
transition, we could transform the failing unit tests in str2angle.m
from "%!test" into "%!xtest". Subsequently, after the transition is done
we could try to fix the problem, which is independent of libgdal. What
do you think?


That's sounds like a good short term workaround.


Ok, I will upload a new version of octave-mapping with the "fix" above 
soon, in order to avoid the blocking of the GDAL transition.


Best,

Rafael Laboissière

Bug#992853: /usr/share/mdadm/mkconf: 98: SOURCE_DATE_EPOCH: parameter not set

[Diederik de Haas]

Control: tag -1 patch

Someone already submitted a MR to fix this issue at
https://salsa.debian.org/lechner/mdadm/-/merge_requests/3

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

Bug#992851: apt-setup generated sources.list differs from sources.list(5)

[Daniel Lewart]

Patch attached
diff -ru apt-setup-0.166/generators/50mirror apt-setup-0.166-new/generators/50mirror
--- apt-setup-0.166/generators/50mirror	2020-07-05 14:34:06.0 -0500
+++ apt-setup-0.166-new/generators/50mirror	2021-08-24 00:00:00.0 -0500
@@ -47,7 +47,7 @@
 	if [ -e /cdrom/.disk/cd_type ]; then
 		cd_type=$(cat /cdrom/.disk/cd_type)
 	fi
-	cd_count=$(grep "^deb cdrom:" $ROOT/etc/apt/sources.list.new | wc -l)
+	cd_count=$(grep -c "^deb cdrom:" $ROOT/etc/apt/sources.list.new)
 
 	no_network=
 	if db_get netcfg/dhcp_options && \
@@ -166,10 +166,12 @@
 db_get mirror/$protocol/hostname
 hostname="$RET"
 db_get mirror/$protocol/directory
-directory="/${RET#/}"
+directory="$RET"
 if [ -z "$hostname" ] || [ -z "$directory" ]; then
 	exit 1
 fi
+directory="${directory#/}"
+directory="${directory%/}"
 
 STATE=1
 while true; do
@@ -204,9 +206,9 @@
 	esac
 
 	if db_go; then
-		STATE=$(($STATE + 1))
+		STATE=$((STATE + 1))
 	else
-		STATE=$(($STATE - 1))
+		STATE=$((STATE - 1))
 	fi
 done
 if [ $STATE -eq 0 ]; then
@@ -232,7 +234,8 @@
 	db_get mirror/$protocol/hostname
 	hostname="$RET"
 	db_get mirror/$protocol/directory
-	directory="/${RET#/}"
+	directory="${RET#/}"
+	directory="${directory%/}"
 
 	case $protocol in
 	http|https)
@@ -246,11 +249,11 @@
 		;;
 	esac
 
-	echo "deb $protocol://$hostname$directory $codename $dists" > $file
+	echo "deb $protocol://$hostname/$directory $codename $dists" > $file
 	if [ -n "${use_unreleased}" ]; then
-		echo "deb $protocol://$hostname$directory unreleased main" >> $file
+		echo "deb $protocol://$hostname/$directory unreleased main" >> $file
 	fi
-	
+
 	if apt-setup-verify --from $PROGRESS_FROM --to $PROGRESS_TO $file; then
 		done=1
 	else
@@ -273,8 +276,8 @@
 	deb_src="# deb-src"
 fi
 
-echo "$deb_src $protocol://$hostname$directory $codename $dists" >> $file
+echo "$deb_src $protocol://$hostname/$directory $codename $dists" >> $file
 if [ -n "${use_unreleased}" ]; then
 	echo "# 'unreleased' does not support sources yet" >> $file
-	echo "# $deb_src $protocol://$hostname$directory unreleased main" >> $file
+	echo "# $deb_src $protocol://$hostname/$directory unreleased main" >> $file
 fi
diff -ru apt-setup-0.166/generators/50mirror.ubuntu apt-setup-0.166-new/generators/50mirror.ubuntu
--- apt-setup-0.166/generators/50mirror.ubuntu	2018-08-10 14:20:36.0 -0500
+++ apt-setup-0.166-new/generators/50mirror.ubuntu	2021-08-24 00:00:00.0 -0500
@@ -21,7 +21,7 @@
 
 	# Set default if no value (see Debian mirror generator)
 	db_get apt-setup/use_mirror
-	[ "$RET" ] || db_set apt-setup/use_mirror true 
+	[ "$RET" ] || db_set apt-setup/use_mirror true
 
 	# Text is variable for Debian
 	db_metaget apt-setup/use/netinst_old description
@@ -75,9 +75,9 @@
 	esac
 
 	if db_go; then
-		STATE=$(($STATE + 1))
+		STATE=$((STATE + 1))
 	else
-		STATE=$(($STATE - 1))
+		STATE=$((STATE - 1))
 	fi
 done
 if [ $STATE -eq 0 ]; then
@@ -97,7 +97,8 @@
 db_get mirror/$protocol/hostname
 hostname="$RET"
 db_get mirror/$protocol/directory
-directory="/${RET#/}"
+directory="${RET#/}"
+directory="${directory%/}"
 
 deb_src="deb-src"
 db_get apt-setup/enable-source-repositories
@@ -109,7 +110,7 @@
 # archive.ubuntu.com, not ports.ubuntu.com.
 if [ "$hostname" = ports.ubuntu.com ]; then
 	srchostname=archive.ubuntu.com
-	srcdirectory=/ubuntu
+	srcdirectory=ubuntu
 else
 	srchostname="$hostname"
 	srcdirectory="$directory"
@@ -131,20 +132,20 @@
 PROPOSED="$RET"
 
 cat >> $file <> $file <> $file > $file
+if [ "$host" = "security.debian.org" ]; then
+	echo "deb http://$host $security_codename $dists" >> $file
+else
+	echo "deb http://$host/debian-security $security_codename $dists" >> $file
+fi
 if db_get netcfg/dhcp_options && \
[ "$RET" = "Do not configure the network at this time" ]; then
 	CODE=9
@@ -59,6 +63,10 @@
 	deb_src="# deb-src"
 fi
 
-echo "$deb_src http://$host/debian-security $security_codename $dists" >> $file
+if [ "$host" = "security.debian.org" ]; then
+	echo "$deb_src http://$host $security_codename $dists" >> $file
+else
+	echo "$deb_src http://$host/debian-security $security_codename $dists" >> $file
+fi
 
 exit $CODE
diff -ru apt-setup-0.166/generators/92updates apt-setup-0.166-new/generators/92updates
--- apt-setup-0.166/generators/92updates	2020-11-01 04:15:39.0 -0600
+++ apt-setup-0.166-new/generators/92updates	2021-08-24 00:00:00.0 -0500
@@ -12,20 +12,17 @@
 
 if db_get mirror/codename && [ "$RET" ]; then
 	codename="$RET"
-	db_get mirror/suite
-	suite="$RET"
 
 	db_get mirror/protocol
 	protocol="$RET"
 	db_get mirror/$protocol/hostname
 	host="$RET"
 	db_get mirror/$protocol/directory
-	directory="/${RET#/}"
+	directory="${RET#/}"
+	directory="${directory%/}"
 else
 	db_get cdrom/codename
 	codename="$RET"
-	db_get cdrom/suite
-	suite="$RET"
 fi
 
 # To determine if non-free and contrib should be included, grep
@@ -42,13 +39,13 @@
 echo "# see 

Bug#992853: /usr/share/mdadm/mkconf: 98: SOURCE_DATE_EPOCH: parameter not set

[Diederik de Haas]

Control: merge -1 992845

On dinsdag 24 augustus 2021 11:13:12 CEST you wrote:
> Someone already submitted a MR to fix this issue at
> https://salsa.debian.org/lechner/mdadm/-/merge_requests/3

That same person also filed bug #992845, so merging these.

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

Bug#992853: /usr/share/mdadm/mkconf: 98: SOURCE_DATE_EPOCH: parameter not set

[Diederik de Haas]

Package: mdadm
Version: 4.2~rc2-3
Severity: important

At the end of today's updates, I got a warning/error msg wrt mdadm:

Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-8-amd64
/usr/share/mdadm/mkconf: 98: SOURCE_DATE_EPOCH: parameter not set
W: mdadm: failed to auto-generate temporary mdadm.conf file.

I don't actively use mdadm, but it seems like this shouldn't happen and
may have big consequences if one relies on mdadm. I can't asses that,
so I set the severity to important, but that may be too low.


-- Package-specific info:
--- mdadm.conf
HOMEHOST 
MAILADDR root

--- /etc/default/mdadm
AUTOCHECK=true
AUTOSCAN=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] 
[raid10] 
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

 2590 1000204632 nvme0n1
 2591   3072 nvme0n1p1
 25922097152 nvme0n1p2
 2593   31457280 nvme0n1p3
 2594  966643712 nvme0n1p5
   80  293036184 sda
   82   20932695 sda2
   84  1 sda4
   858388608 sda5
   86  261953536 sda6

--- LVM physical volumes:
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=32857296k,nr_inodes=8214324,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=6581908k,mode=755)
/dev/nvme0n1p3 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=20970)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl 
(rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
/dev/nvme0n1p2 on /boot type ext4 (rw,relatime)
/dev/nvme0n1p5 on /home type ext4 (rw,relatime)
/dev/sda6 on /home/diederik/media type ext4 (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 
(rw,nosuid,nodev,noexec,relatime)
lxcfs on /var/lib/lxcfs type fuse.lxcfs 
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
tracefs on /sys/kernel/debug/tracing type tracefs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=6581904k,nr_inodes=1645476,mode=700,uid=1000,gid=1000)

--- initrd.img-5.10.0-8-amd64:

gzip: /boot/initrd.img-5.10.0-8-amd64: not in gzip format
cpio: premature end of archive

--- initrd's /conf/conf.d/md:
no conf/md file.

--- /proc/modules:
dm_mod 163840 0 - Live 0xc1406000
raid10 65536 0 - Live 0xc06cb000
raid456 180224 0 - Live 0xc0695000
async_raid6_recov 24576 1 raid456, Live 0xc05af000
async_memcpy 20480 2 raid456,async_raid6_recov, Live 0xc05a9000
async_pq 20480 2 raid456,async_raid6_recov, Live 0xc05a
async_xor 20480 3 raid456,async_raid6_recov,async_pq, Live 0xc0535000
async_tx 20480 5 raid456,async_raid6_recov,async_memcpy,async_pq,async_xor, 
Live 0xc052f000
raid6_pq 122880 4 btrfs,raid456,async_raid6_recov,async_pq, Live 
0xc0676000
libcrc32c 16384 6 xfs,nf_nat,nf_conntrack,nf_tables,btrfs,raid456, Live 
0xc0445000
raid1 53248 0 - Live 0xc0521000
raid0 24576 0 - Live 0xc043e000
multipath 20480 0 - Live 0xc0429000
linear 20480 0 - Live 0xc03f4000
md_mod 184320 6 raid10,raid456,raid1,raid0,multipath,linear, Live 
0xc0648000

--- /var/log/syslog:

--- volume detail:
/dev/sda:
   MBR Magic : aa55
Partition[1] : 41865390 sectors at  3518235 (type 07)
Partition[3] :540688384 sectors at 45383680 (type 05)
--
/dev/sda2:
   MBR Magic : aa55
Partition[0] :   1701990410 sectors at218129509 (type 72)
Partition[1] :543974724 sectors at729050177 (type 74)
Partition[3] :51635 sectors at   2692939776 (type 00)
--
/dev/sda4:
 

Bug#985553: dpkg: RFC use gcc .spec files for fixfilepath/fixdebugpath

[Guillem Jover]

On Mon, 2021-08-23 at 19:22:54 -0700, Vagrant Cascadian wrote:
> Ok, a slightly more complicated workflow pseudocode:
> 
> if DEB_BUILD_PATH && fixfilepath
> then
>   -spec=/usr/share/dpkg/fixfilepath.spec ...
> else if fixfilepath
>   -ffile-prefix-map= build_path ...
> fi

While in theory something like this might work, I'm afraid this is
still a potentially pretty dangerous thing to do. The problem I see is
that we'd be checking for the presence of an envvar deep in a call
stack that is going to be completely independent from the ones that
are going to be evaluating the spec file with its own envvar fetching,
where something could have set the envvar for the first branch but not
the second (or unset it). But see down below…

> In other words, only pass the spec file that requires DEB_BUILD_PATH to
> be set when DEB_BUILD_PATH *is* set, falling back to the previous
> behavior setting ffile-prefix-map directly?
> 
> Another pseudocode idea:
> 
> if fixfilepath
> then
>   setenv DEB_BUILD_PATH $build_path
>   export DEB_BUILD_PATH
>   -spec=/usr/share/dpkg/fixfilepath.spec
> fi

I don't think that's workable, as per the above.


There's also the perennial problem with GNU make not exposing variables
exported within a Makefile into $(shell) directives, but I guess in
those scenarios that might work in our favor in most cases.

  ,--- test.mk ---
  export DEB_BUILD_PATH = something
  all:
echo $(shell dpkg-buildflags | grep something)
  `---

Something I've noticed now is that buildflags.mk is missing passing
DEB_BUILD_PATH explicitly to the dpkg-buildflags call, so I'm merging
the following into git main:

diff --git i/scripts/mk/buildflags.mk w/scripts/mk/buildflags.mk
index 442b7d671..f7ebe8f2c 100644
--- i/scripts/mk/buildflags.mk
+++ w/scripts/mk/buildflags.mk
@@ -31,6 +31,7 @@ endef
 
 $(eval $(call dpkg_buildflags_export_envvar,DEB_BUILD_OPTIONS))
 $(eval $(call dpkg_buildflags_export_envvar,DEB_BUILD_MAINT_OPTIONS))
+$(eval $(call dpkg_buildflags_export_envvar,DEB_BUILD_PATH))
 $(foreach flag,$(DPKG_BUILDFLAGS_LIST),\
   $(foreach operation,SET STRIP APPEND PREPEND,\
 $(eval $(call 
dpkg_buildflags_export_envvar,DEB_$(flag)_MAINT_$(operation)


And after checking with codesearch.d.o, I see only Linux is setting
DEB_BUILD_PATH explicitly from debian/*. But that does not guarantee
build machinery is not resetting envvars f.ex. which would break the
build.

Perhaps a soothing check would be to do an archive rebuild using the
first workflow you proposed above (w/ and w/o setting DEB_BUILD_PATH
externally)? Would that be too cumbersome?

If that's successful, and even though that still has the potential to
break stuff (including non-Debian source packages), at that point it
might be OKish to set it from dpkg-buildpackage because even if it is
not set I'd expect things to be more or less fine.

Thanks,
Guillem

Bug#992852: /lib/systemd/system/shorewall.service: ignores the setting of SAFESTOP

[Dietrich Clauss]

Package: shorewall
Version: 5.2.3.2-1
Severity: normal
File: /lib/systemd/system/shorewall.service

Dear Maintainer,

when setting SAFESTOP=1 in /etc/default/shorewall and doing `service
shorewall stop`, I'd expect the firewall to be safe-stopped (`shorewall
stop`), not cleared (i.e. opened, `shorewall clear`).

With sysvinit this works as expected, but in the systemd.service file,
the ExecStop action is hard-coded to `shorewall clear`, not respecting
the value of the SAFESTOP variable.

This could lead to security issues, as the firewall opens unexpectedly.


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

Kernel: Linux 4.19.0-17-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages shorewall depends on:
ii  bc 1.07.1-2+b1
ii  debconf [debconf-2.0]  1.5.71
ii  iproute2   4.20.0-2+deb10u1
ii  iptables   1.8.2-4
ii  lsb-base   10.2019051400
ii  perl   5.28.1-6+deb10u1
ii  shorewall-core 5.2.3.2-1

Versions of packages shorewall recommends:
ii  libnetfilter-cthelper0  1.0.0-1+b1

Versions of packages shorewall suggests:
ii  make   4.2.1-1.2
pn  shorewall-doc  

-- Configuration Files:
/etc/default/shorewall changed [not included]
/etc/shorewall/conntrack [Errno 13] Keine Berechtigung: 
'/etc/shorewall/conntrack'
/etc/shorewall/params [Errno 13] Keine Berechtigung: '/etc/shorewall/params'
/etc/shorewall/shorewall.conf changed [not included]

-- debconf information excluded

Bug#964089: closed by Chris Hofstaedtler (Re: #964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup)

[Helmut Grohne]

Hi Chris,

On Tue, Aug 24, 2021 at 10:31:39AM +0200, Chris Hofstaedtler wrote:
> Thanks for the info, however I would not know what to use.
> util-linux has a lot of !stage1 Build-Depends today:
>bc ,
>libaudit-dev [linux-any] ,
>libcap-ng-dev [linux-any] ,
>libcryptsetup-dev [linux-any] ,
>libpam0g-dev ,
>libsystemd-dev [linux-any] ,
>libudev-dev [linux-any] ,
>netbase ,
>socat ,
>systemd [linux-any] ,
> 
> And also !stage1 excludes most of the util-linux binary packages,
> except for lib* and lib*-dev. I imagine this was done to allow
> building some reverse-dependencies.

Ah right. util-linux is one of the early adopters introducing stage1.
Extending the existing profile to cover another dependency certainly is
not a regression. However, libcryptsetup-dev may play a different role
here.

> Given this it would "feel" more like a pkg.util-linux.justlibs
> profile...

That sounds about right. Similar examples are pkg.openldap.noslapd and
pkg.unbound.libonly. We can rename stage1 when convenient.

> Is there an overview of the currently in use values in the extension
> namespace?

https://wiki.debian.org/BuildProfileSpec#Registered_profile_names

None of the common build profiles fits your use.

The problem I see here is that presence of libcryptsetup-dev influences
how libmount-dev is built. If you were to add it to a
pkg.util-linux.justlibs profile, your built libraries would differ when
built with or without this profile and that's not what we want. Ideally
profiles just enable/disable packages without changing the contents of
those that are built.

I suggest that util-linux should have distinct profiles here. One for
building only libraries (in a way that reproduces a full build) and
another for disabling functionality inside those libraries that need to
be passed for bootstrap.

In essence, I argue that while stage1 should probably renamed to
something like pkg.util-linux.justlibs, libcryptsetup-dev should not be
part of that profile (renamed or not).

Helmut

Bug#961660: Cause is have() Wrapper Function of Function _have()

[Jürgen Kuri]

Hello Gabriel,

> If I try to complete the second word, then it doesn't work, but that's
> because I don't have the configuration file under /etc and I believe
> that this is unrelated to your problem:

>  $ fsmtool2 showconfig 
>  grep: /etc/fsmd2/fsmd2.conf: No such file or directory
Yes, that's unrelated.


> So, would you be willing to make that change in your scripts? It looks
> like the right thing to do anyway.
I did this already:

1) I removed my old workaround, storing the completion script
   below /etc/bash_completion.d/,

   a) not using anymore the .install files as a workaround

   b) using dh_bash-completion which stores it below
  /usr/share/bash-completion/completions/ which is the
  right way - yes (there is only one completion script
  left from distribution side, "git-prompt")

   c) I removed the broken surrounding "have(){ }" function not
  using it anymore as many other do (look into some completion
  scripts, neither have() nor _have() is used)


It works now for Stretch, Buster and Bullseye. By the way, have() is also 
broken in Bullseye, with _have() it works.

-- 
Thanks
Jürgen

Bug#978774: autossh: ftbfs with autoconf 2.70

[Axel Beckert]

Control: tag -1 + unreproducible moreinfo
Control: severity -1 important

Dear Matthias,

Matthias Klose wrote:
> Package: src:autossh
> Version: 1.4g-1
[…]
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69.

I'm sorry, but I can't reproduce this:

~/autossh/autossh → apt-cache policy autoconf
autoconf:
  Installed: 2.71-2
  Candidate: 2.71-2
  Version table:
 *** 2.71-2 990
990 https://debian.ethz.ch/debian sid/main amd64 Packages
990 https://debian.ethz.ch/debian sid/main i386 Packages
500 https://incoming.debian.org/debian-buildd buildd-unstable/main 
amd64 Packages
500 https://incoming.debian.org/debian-buildd buildd-unstable/main i386 
Packages
100 /var/lib/dpkg/status
 2.69-14 600
600 https://debian.ethz.ch/debian testing/main amd64 Packages
600 https://debian.ethz.ch/debian testing/main i386 Packages
~/autossh/autossh → debuild -j16 -uc -us
 dpkg-buildpackage -us -uc -ui -i -j16 -j16
dpkg-buildpackage: info: source package autossh
dpkg-buildpackage: info: source version 1.4g-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Axel Beckert 
 dpkg-source -i --before-build .
dpkg-buildpackage: info: host architecture amd64
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 010_override_cmdline_port.diff
dpkg-source: info: applying 030_manpage_fix.diff
dpkg-source: info: applying 040_manpage_debian.diff
 debian/rules clean
dh clean
   dh_clean
 dpkg-source -i -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building autossh using existing ./autossh_1.4g.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building autossh in autossh_1.4g-1.debian.tar.xz
dpkg-source: info: building autossh in autossh_1.4g-1.dsc
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
configure.ac:8: warning: The macro `AC_CONFIG_HEADER' is obsolete.
configure.ac:8: You should run autoupdate.
./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from...
configure.ac:8: the top level
configure.ac:19: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:19: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
configure.ac:19: the top level
configure.ac:39: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:39: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:39: the top level
configure.ac:50: warning: The macro `AC_HEADER_TIME' is obsolete.
configure.ac:50: You should run autoupdate.
./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from...
configure.ac:50: the top level
configure.ac:134: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:134: You should run autoupdate.
./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
configure.ac:134: the top level
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/home/abe/autossh/autossh'
dh_auto_configure
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking for ssh... /usr/bin/ssh
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for sys/time.h... yes
checking for vfork.h... no
checking for sys/select.h... yes
checking for sys/socket.h... yes
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for arpa/inet.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for netdb.h... yes
checking for netinet/in.h... yes
checking for paths.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... 

Bug#992851: apt-setup generated sources.list differs from sources.list(5)

[Daniel Lewart]

Package: apt-setup
Version: 1:0.166
Severity: minor
Tags: d-i patch

Debian Install System Team,

sources.list(5) has the following example:
  deb http://deb.debian.org/debian bullseye main contrib non-free
  deb http://security.debian.org bullseye-security main contrib non-free

apt-setup generates a slightly different /etc/apt/sources.list:
  deb http://deb.debian.org/debian/ bullseye main contrib non-free
  deb http://security.debian.org/debian-security bullseye-security main contrib 
non-free

I consider sources.list(5) to be authoritative.
Therefore, I think the two stanzas above should be identical.

Attached is a patch which:
  1) Removes trailing slashes from URIs
  2) Omits /debian-security if host is security.debian.org
  3) Removes unused suite from 92updates and 93backports
  4) Reverts "$hostname$directory" to original "$hostname/$directory"
  5) Cleans up various syntax issues

If the Maintainers do not like any of the above changes,
I would be happy to resubmit an updated patch.

Thank you!
Daniel Lewart
Urbana, Illinois

Bug#992850: RFS: gnss-sdr/0.0.15-1 -- Global navigation satellite systems software defined receiver

[Carles Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gnss-sdr":

 * Package name: gnss-sdr
   Version : 0.0.15-1
   Upstream Author : Carles Fernandez 
 * URL : https://gnss-sdr.org
 * License : GPL-3+, Zlib, Apple-Permissive, Expat, Apache-2.0, 
Permissive, BSD-3-clause, LGPL-3+, BSD-2-clause
 * Vcs : https://salsa.debian.org/debian-hamradio-team/gnss-sdr
   Section : hamradio

It builds those binary packages:

  gnss-sdr - Global navigation satellite systems software defined receiver

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

  https://mentors.debian.net/package/gnss-sdr/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnss-sdr/gnss-sdr_0.0.15-1.dsc

Changes since the last upload:

 gnss-sdr (0.0.15-1) unstable; urgency=medium
 .
   * First release of upstream version 0.0.15
   * Remove gr-iio and libiio-dev for hurd-i386 and sh4
   * Remove libad9361-dev for hurd-i386
   * Update debian/upstream/metadata
   * Add Restrictions: superficial to debian/tests/control (Closes: bug#971469)

Regards,

--

Dr. Carles Fernández Prades

Head of Statistical Inference for Comm. & Positioning Dept.
Communication Systems Division

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Address: Parc Mediterrani de la Tecnologia
  Av. Carl Friedrich Gauss, 7
  08860 Castelldefels, Barcelona, Spain.
Phone: +34 936452900Fax: +34 936452901
http://www.cttc.es/people/cfernandez/ 














signature.asc
Description: Message signed with OpenPGP

Bug#512360: RFH: openldap -- OpenLDAP server, libraries, and utilities

[Max ss]

Hi Ryan,

I would like to be part of the maintainers team(OpenLDAP). I haven't
contributed to debian before, I have worked in Linux based servers for more
than 11 years. If the prior experience in contribution is not mandatory,
please let me know how to proceed.

thanks,
Karthik

On Sat, 5 Dec 2020 12:36:00 -0800 Ryan Tandy  wrote:
> I'm still looking for help with the OpenLDAP packages. I'm not an
> OpenLDAP user any more, and I would like to eventually hand off the
> package to a new maintainer.
>
> The current 2.4 package is in OK shape. It's up-to-date in unstable and
> backports, and I'm able to handle the low volume of security updates and
> bug reports. I'm also responding to Debian-specific issues on the
> upstream support channels (lists/bugs/IRC). The status quo will probably
> be fine for bullseye; however, I'm not making much progress on
> developing or improving the package.
>
> Here are some of the major projects that I would appreciate help with:
>
> * Updating to OpenLDAP 2.5.
>
>   The first 2.5 alpha has been released already. I hope the final
>   release will happen in time that we can transition to it for bookworm.
>   This will include a SONAME transition, which should be mostly painless
>   as the library API has not changed much.
>
>   The bulk of the work will be to support slapd upgrades. The biggest
>   change is that the Berkeley DB backends (BDB and HDB) have been
>   removed. These were the default for Debian installations for a long
>   time and I know not all users have migrated to LMDB yet. We should
>   provide an automated migration from BDB/HDB to LMDB, as was done for
>   LDBM previously. There are also some old bugs in the maintainer
>   scripts for upgrading databases, which still need to be addressed.
>
>   Upstream still supports both slapd.conf and cn=config configuration
>   (though slapd.conf is considered deprecated), so any upgrade path has
>   to support both.
>
> * Overhauling the debian/copyright file.
>
>   The copyright file is old and not in DEP5 format yet. We basically
>   need to do a full copyright review of the upstream source in order to
>   write a complete and correct DEP5 copyright file, and then commit to
>   maintaining it going forward.
>
>   I don't know at all what the license of debian/* is supposed to be. We
>   might have to do some legwork of contacting previous maintainers and
>   trying to obtain copyright statements from them.
>
> * Replacing the slapd init script with a systemd service.
>
>   This is a smaller project, but still not as trivial as it sounds. The
>   init script supports a number of configuration variables, and it also
>   picks up some information dynamically from the slapd configuration.
>   This probably requires extracting some of the init script code to a
>   wrapper script for executing slapd with appropriate arguments.
>
>   Supporting both slapd.conf and cn=config adds complexity here as well.
>
> * Working with upstream on GnuTLS support.
>
>   Upstream still supports GnuTLS, but reluctantly. They expect the
>   Debian maintainer to be actively involved with triaging and fixing
>   GnuTLS issues upstream.
>
>   The autoca overlay is new in 2.5 and only supports OpenSSL right now.

Bug#964089: closed by Chris Hofstaedtler (Re: #964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup)

[Chris Hofstaedtler]

Hi Helmut,

* Helmut Grohne  [210824 10:10]:
> On Mon, Aug 23, 2021 at 03:33:04PM +, Debian Bug Tracking System wrote:
> > 2.35.2-7 disabled the cryptsetup bits. In 2.37.2-2 we will have a
> > !stage1 and dlopen-enabled version of the code.
> 
> This sounds good except for the use of stage1. We've deprecated the
> profile name stage1, because it doesn't tell what it does. Please use a
> functional profile name instead. Most likely, you'll need something
> matching pkg.cryptsetup.*.

Thanks for the info, however I would not know what to use.
util-linux has a lot of !stage1 Build-Depends today:
   bc ,
   libaudit-dev [linux-any] ,
   libcap-ng-dev [linux-any] ,
   libcryptsetup-dev [linux-any] ,
   libpam0g-dev ,
   libsystemd-dev [linux-any] ,
   libudev-dev [linux-any] ,
   netbase ,
   socat ,
   systemd [linux-any] ,

And also !stage1 excludes most of the util-linux binary packages,
except for lib* and lib*-dev. I imagine this was done to allow
building some reverse-dependencies.

Given this it would "feel" more like a pkg.util-linux.justlibs
profile...
Is there an overview of the currently in use values in the extension
namespace?

Chris

Bug#931863: debirf: buster build fails to create initrd

[PetrasL]

The same on debian 10.10 while trying to do:

debirf make minimal

I noticed that this missing file exist in another directory:

/root/DEBIRF/minimal/root/usr/lib/klibc-s9qQdCstNfYRDSY0VN-k2cEOgUE.so

Fixed /usr/bin/debirf, but then getting kernel panic while booting from
that ISO.

Regards
PetrasL

Bug#992849: gnutls28 arch-only FTBFS: Can't exec "gtkdocize": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 293.

[Helmut Grohne]

Source: gnutls28
Version: 3.7.1-5
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

gnutls28 fails to build from source when performing an arch-only build.
A build ends with:

| dh binary-arch --builddirectory=b4deb
|dh_update_autotools_config -a -O--builddirectory=b4deb
|debian/rules override_dh_autoreconf
| make[1]: Entering directory '/<>'
| rm -v `grep -rl gettext-0.20 m4/`
| removed 'm4/po.m4'
| removed 'm4/intlmacosx.m4'
| removed 'm4/gettext.m4'
| dh_autoreconf --verbose -O--builddirectory=b4deb
| find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path 
'*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  
-type f -exec md5sum {} + -o -type l -printf "symlink  %p
| " > debian/autoreconf.before
| grep -q ^XDT_ configure.ac
| autoreconf -f -i
| autopoint: using AM_GNU_GETTEXT_REQUIRE_VERSION instead of 
AM_GNU_GETTEXT_VERSION
| Copying file m4/gettext.m4
| Copying file m4/intlmacosx.m4
| Copying file m4/nls.m4
| Copying file m4/po.m4
| Copying file m4/progtest.m4
| Copying file po/Makefile.in.in
| Copying file po/Makevars.template
| aclocal: overwriting 'm4/pkg.m4' with '/usr/share/aclocal/pkg.m4'
| libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
| libtoolize: copying file 'build-aux/ltmain.sh'
| libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
| libtoolize: copying file 'm4/libtool.m4'
| libtoolize: copying file 'm4/ltoptions.m4'
| libtoolize: copying file 'm4/ltsugar.m4'
| libtoolize: copying file 'm4/ltversion.m4'
| libtoolize: copying file 'm4/lt~obsolete.m4'
| Can't exec "gtkdocize": No such file or directory at 
/usr/share/autoconf/Autom4te/FileUtils.pm line 293.
| autoreconf: error: gtkdocize failed with exit status: 2
| find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path 
'*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  
-type f -exec md5sum {} + -o -type l -printf "symlink  %p
| " > debian/autoreconf.after
| dh_autoreconf: error: autoreconf -f -i returned exit code 2
| make[1]: *** [debian/rules:50: override_dh_autoreconf] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:127: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build does not run into this issue, because gtk-doc-tools is
included in Build-Depends-Indep. I suppose it'll have to be moved to
Build-Depends.

This presently breaks architecture bootstrap.

Helmut

Bug#992848: pam_unix: Treats SHA256 and older hashes as expired

[Mattias Jernberg]

Package: libpam-modules
Version: 1.4.0-9
Severity: important

Dear Maintainer,

When upgrading libxcrypt, I ran into upstream bug
.

This has turned into a bit of a problem since some password hashes are synced 
from
a central management system, meaning it is difficult to stop the problem from
recurring by changing the password hash.

Until a new upstream release is made and migrated into Unstable, perhaps the fix
in  could be added? I
have tested this locally and it applied cleanly and solved the issue.

Thank you in advance, Mattias


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

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

Versions of packages libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libaudit1  1:3.0.5-1
ii  libc6  2.31-17
ii  libcrypt1  1:4.4.25-1
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libnsl21.3.0-2
ii  libpam-modules-bin 1.4.0-9
ii  libpam0g   1.4.0-9
ii  libselinux13.1-3
ii  libtirpc3  1.3.2-2

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- Configuration Files:
/etc/security/group.conf changed [not included]

-- debconf information excluded

Bug#992760: ksystemtray: cannot be started, wrong version

[Erwan David]

De : Norbert Preining [mailto:norb...@preining.info]
Envoyé : lundi 23 août 2021 à 11:24 UTC+2
Pour : Erwan David , 992...@bugs.debian.org
Cc : Debian Kde 
Objet : Bug#992760: ksystemtray: cannot be started, wrong version


Hi Erwan,


kf.plasma.core: 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/applets/org.kde.plasma.systemtray.so"
 : this plugin is compiled against incompatible Plasma version 348928 This build is 
compatible with 5 .0.0 ( 327680 ) to 5.78.0 ( 347708 )
kf.plasma.core: Applet "org.kde.plasma.systemtray" could not be loaded.



ii  libkf5plasma5 5.78.0-3


The problem is that this packages (and several others) from the
frameworks are not updated.

I guess we have to introduce a breaks somewhere ... this incompatibility
is somehow surprising, because it is not documented in the CMakeList
files - at least as far I see...


So better wait for a newer version...


No, wait for all frameworks being updated ...

Best

Norbert


Thanks, everything is OK now. Now, I just have to close the bug I opened.

Bug#992847: systemd: systemctl preset-all fails to handle /lib/systemd -> /usr/lib/systemd transition

[Michael Prokop]

Package: systemd
Version: 247.9-1
Severity: important

Hi,

this seems to be related to the "dh_installsystemd: Prefer
/usr/lib/systemd/ to /lib/systemd" change from debhelper v13.4.

Our daily Grml ISO builds started to fail a few days ago, because in
our chroots we have a symlink for
/etc/systemd/system/syslog.service, which points to
/lib/systemd/system/rsyslog.service (as it used to be in the rsyslog
packaging in the past):

| lrwxrwxrwx 1 root root 35 Aug 24 07:54 /etc/systemd/system/syslog.service -> 
/lib/systemd/system/rsyslog.service

Now, when invoking `systemctl preset-all` this fails as follows:

| # systemctl preset-all
| Unit /lib/systemd/system/cryptdisks.service is masked, ignoring.
| Unit /lib/systemd/system/mdadm-waitidle.service is masked, ignoring.
| Unit /lib/systemd/system/rcS.service is masked, ignoring.
| Unit /lib/systemd/system/sudo.service is masked, ignoring.
| Unit /lib/systemd/system/cryptdisks-early.service is masked, ignoring.
| Unit /lib/systemd/system/x11-common.service is masked, ignoring.
| Unit /lib/systemd/system/screen-cleanup.service is masked, ignoring.
| Unit /lib/systemd/system/rc.service is masked, ignoring.
| Unit /lib/systemd/system/mdadm.service is masked, ignoring.
| Unit /lib/systemd/system/nfs-common.service is masked, ignoring.
| Unit /lib/systemd/system/lvm2.service is masked, ignoring.
| Unit /lib/systemd/system/hwclock.service is masked, ignoring.
| Failed to preset unit, file /etc/systemd/system/syslog.service already exists 
and is a symlink to /lib/systemd/system/rsyslog.service.

When manually removing the /etc/systemd/system/syslog.service symlink,
then it works as expected:

| # rm /etc/systemd/system/syslog.service
| # systemctl preset-all
| Unit /lib/systemd/system/cryptdisks.service is masked, ignoring.
| Unit /lib/systemd/system/mdadm-waitidle.service is masked, ignoring.
| Unit /lib/systemd/system/rcS.service is masked, ignoring.
| Unit /lib/systemd/system/sudo.service is masked, ignoring.
| Unit /lib/systemd/system/cryptdisks-early.service is masked, ignoring.
| Unit /lib/systemd/system/x11-common.service is masked, ignoring.
| Unit /lib/systemd/system/screen-cleanup.service is masked, ignoring.
| Unit /lib/systemd/system/rc.service is masked, ignoring.
| Unit /lib/systemd/system/mdadm.service is masked, ignoring.
| Unit /lib/systemd/system/nfs-common.service is masked, ignoring.
| Unit /lib/systemd/system/lvm2.service is masked, ignoring.
| Unit /lib/systemd/system/hwclock.service is masked, ignoring.
| Created symlink /etc/systemd/system/syslog.service → 
/usr/lib/systemd/system/rsyslog.service.

The issue might have to be fixed from within the rsyslog package
itself, but given that this issue might affect further packages and
whoever relies on `systemctl preset-all`, I decided to report it
against systemd. Feel free to reassign as needed. Maybe also
to be considered RC severity?

regards
-mika-


signature.asc
Description: Digital signature

Bug#992846: src:yash: fails to migrate to testing for too long

[Paul Gevers]

Source: yash
Version: 2.50-1
Severity: serious
Control: close -1 2.51-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:yash has been
trying to migrate for 241 days [2] (of which most were 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 bullseye, 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=yash




OpenPGP_signature
Description: OpenPGP digital signature

Bug#983357: Netinst crashes xen domU when loading kernel

[Chuck Zmudzinski]

On 5/25/2021 2:38 PM, Phillip Susi wrote:

Michael Biebl writes:


So this is a change in behaviour in the kernel?

Yes, this commit fixed the kernel to report the error instead of
silently failing:

commit df44b479654f62b478c18ee4d8bc4e9f897a9844
Author: Peter Rajnoha 
Date:   Wed Dec 5 12:27:44 2018 +0100

 kobject: return error code if writing /sys/.../uevent fails
 
 Propagate error code back to userspace if writing the /sys/.../uevent

 file fails. Before, the write operation always returned with success,
 even if we failed to recognize the input string or if we failed to
 generate the uevent itself.
 
 With the error codes properly propagated back to userspace, we are

 able to react in userspace accordingly by not assuming and awaiting
 a uevent that is not delivered.
 
 Signed-off-by: Peter Rajnoha 

 Signed-off-by: Greg Kroah-Hartman 


What happens if you boot the installed system? Does udevadm trigger fail
there as well?

Yes, it does; that is how I was able to track down the problem.


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.

So far I have been removing the -e from the shbang line in the
start-udev script and remastering the iso so I can get it to boot.  It
would probably be a better idea to just add a || true to the udevadm
trigger call.  I feel fairly certain that no matter what the cause of
the coldplug failure, the user is going to be better off ignoring it and
trying to proceed than a kernel panic.



Hello,

This bug was noticed on the debian-user list recently and I have
been testing various workarounds and instead of removing -e from
the shbang line I came up with prepending the udevadm trigger call
in the start-udev script with

dmesg | grep DMI: | grep 'Xen HVM domU' ||

This causes the offending udevadm trigger call to never be invoked
when running in a Xen HVM DomU. On all other systems, the call
should be invoked like normal. With this hack, I was able to create
a modified ISO and run the bullseye installer from it in a Xen HVM
DomU and complete an install without the crash and reboot.

I also can confirm that I always see the coldplug failure on the installed
system in a Xen HVM DomU, but in that case the failure does not
cause a crash and the system boots normally after reporting the failure.

I also do not see the problem in a Xen PV DomU, which I think is
what the /install.amd/xen folder on the installation media is for.

Chuck Zmudzinski

Bug#989600: /usr/bin/swift-container-reconciler: reconciler's memcache connections fail when using hostnames

[Filippo Giunchedi]

On Tue, Jun 08, 2021 at 10:03 AM, Filippo Giunchedi wrote:
> Package: swift-container
> Version: 2.26.0-10
> Severity: important
> File: /usr/bin/swift-container-reconciler
> 
> Dear Maintainer,
> I'm experimenting with Swift on Bullseye and came across a problem with
> container-reconciler (possibly others) when using hostnames in
> memcache_servers. Namely these errors:

In the "possibly others" category, swift-dispersion-report is also 100%
broken in Bullseye:

$ swift-dispersion-report --dump-json
swift-dispersion-report --dump-json -d
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 435, 
in resolve
return _proxy.query(name, rdtype, raise_on_no_answer=raises,
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 391, 
in query
return end()
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 370, 
in end
raise result[1]
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 351, 
in step
a = fun(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1089, in query
return self.resolve(qname, rdtype, rdclass, tcp, source,
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1043, in resolve
timeout = self._compute_timeout(start, lifetime)
  File "/usr/lib/python3/dist-packages/dns/resolver.py", line 950, in 
_compute_timeout
raise Timeout(timeout=duration)
dns.exception.Timeout: The DNS operation timed out after 5.1069724559783936 
seconds

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/urllib/request.py", line 1346, in do_open
h.request(req.get_method(), req.selector, req.data, headers,
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1310, in request
self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1380, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1301, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1089, in _send_output
self.send(msg)
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1018, in send
self.connect()
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1481, in connect
super().connect()
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
989, in connect
self.sock = self._create_connection(
  File "/usr/lib/python3/dist-packages/eventlet/green/socket.py", line 44, in 
create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 528, 
in getaddrinfo
qname, addrs = _getaddrinfo_lookup(host, family, flags)
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 501, 
in _getaddrinfo_lookup
raise err
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 490, 
in _getaddrinfo_lookup
answer = resolve(host, qfamily, False, use_network=use_network)
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 443, 
in resolve
raise EAI_EAGAIN_ERROR
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 490, 
in _getaddrinfo_lookup
answer = resolve(host, qfamily, False, use_network=use_network)
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 443, 
in resolve
raise EAI_EAGAIN_ERROR
  File "/usr/lib/python3.9/urllib/request.py", line 1346, in do_open
h.request(req.get_method(), req.selector, req.data, headers,
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1310, in request
self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1380, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1301, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1089, in _send_output
self.send(msg)
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1018, in send
self.connect()
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
1481, in connect
super().connect()
  File "/usr/lib/python3/dist-packages/eventlet/green/http/client.py", line 
989, in connect
self.sock = self._create_connection(
  File "/usr/lib/python3/dist-packages/eventlet/green/socket.py", line 44, in 
create_connection
for res in getaddrinfo(host, port, 0, 

Bug#971530: dnspython 2.x breaks all of OpenStack

[Filippo Giunchedi]

On Tue, Jun 01, 2021 at 10:30:38AM +, Filippo Giunchedi wrote:
> Hello,
> 
> On Thu, May 27, 2021 at 04:10:32PM +0200, Thomas Goirand wrote:
> > Hi,
> > 
> > Well, Eventlet itself works. DNSPython itself works too. Just the 2
> > together (ie: resolving with eventlet greedns) doesn't work. This
> > doesn't make any of the packages completely broken and unuseable (so
> > it's not RC), this is just a bug that should be fixed.
> 
> I disagree in the sense that I don't think the package(s) currently are fit 
> for
> release, but it isn't my call either.
> 
> > FYI, since some fixes in Eventlet, OpenStack now works... Though the
> > Eventlet greendns API shall still be fixed.
> 
> Do you have pointers to these fixes I could look at? I ran into this bug while
> testing Swift on Bullseye, specifically container-reconciler + 
> memcache_servers
> with hostnames doesn't seem to work for me (while using ip addresses does 
> work).

For the record I haven't seen the eventlet greendns fixes you mentioned, and
swift-dispersion-report is also broken in Bullseye due to this bug (cfr
#989600)

Bug#964089: closed by Chris Hofstaedtler (Re: #964089: libmount-dev introduced a bootstrap/dependency cycle with src:cryptsetup)

[Helmut Grohne]

On Mon, Aug 23, 2021 at 03:33:04PM +, Debian Bug Tracking System wrote:
> 2.35.2-7 disabled the cryptsetup bits. In 2.37.2-2 we will have a
> !stage1 and dlopen-enabled version of the code.

This sounds good except for the use of stage1. We've deprecated the
profile name stage1, because it doesn't tell what it does. Please use a
functional profile name instead. Most likely, you'll need something
matching pkg.cryptsetup.*.

Helmut

Bug#992646: transition: ace

[Sudip Mukherjee]

On Mon, Aug 23, 2021 at 7:42 PM Sebastian Ramacher  wrote:
>



> >
> > Small transition with only two affected packages: diagnostics, ivtools,
> > Both of them builds fine with ace 7.0.3+dfsg-1 version in experimental.
> >
> > The autogenerated ben tracker looks good. Please consider 'ace' for
> > transition.
> > Thanks in advance.
>
> Please go ahead

Thanks.
Uploaded to unstable.


-- 
Regards
Sudip

Bug#992845: mdadm: broken usage of check for SOURCE_DATE_EPOCH

[Michael Prokop]

Package: mdadm
Version: 4.2~rc2-3
Severity: important

Hi,

since mdadm v4.2~rc2-3, due to the changes for #982607, during
initramfs stage it spills:

/usr/share/mdadm/mkconf: 98: SOURCE_DATE_EPOCH: parameter not set

This is caused by:

  if [ -z $SOURCE_DATE_EPOCH ]; then

.. while the script is running under 'set -u'.

I'll provide a MR on salsa once I've got a bug number from the BTS.

regards
-mika-

Bug#992844: mercurial: FTBFS on s390x (ERROR: test-upgrade-repo.t output changed)

[Julien Cristau]

Source: mercurial
Version: 5.9-1
Severity: serious
Tags: ftbfs

>From the log
https://buildd.debian.org/status/fetch.php?pkg=mercurial=s390x=5.9-1=1629766216=0

> --- /<>/tests/test-upgrade-repo.t
> +++ /<>/tests/test-upgrade-repo.t.err
> @@ -1531,9 +1531,8 @@
>sparserevlog
>store
>$ hg debugsidedata -c 0
> -  2 sidedata entries
> -   entry-0001 size 4
> -   entry-0002 size 32
> +  abort: cannot read from revlog 00changelog-5e69c5d1.sda;  expected 
> 1942585158 bytes from offset 0, data size is 90
> +  [50]
>  
>  downgrade
>  
> @@ -1552,6 +1551,8 @@
>  - changelog
>  - manifest
>
> +  abort: cannot read from revlog data/foo-1335303a.sda;  expected 1942585158 
> bytes from offset 0, data size is 0
> +  [50]
>$ hg debugformat -v
>format-variant repo config default
>fncache:yesyes yes
> @@ -1563,7 +1564,7 @@
>persistent-nodemap:  no no  no (no-rust !)
>persistent-nodemap: yesyes  no (rust !)
>copies-sdc:  no no  no
> -  revlog-v2:   no no  no
> +  revlog-v2:  yes no  no
>changelog-v2:no no  no
>plain-cl-delta: yesyes yes
>compression:zlib   zlibzlib (no-zstd !)
> @@ -1571,14 +1572,16 @@
>compression-level:  default default default
>$ cat .hg/requires
>dotencode
> -  fncache
> +  exp-revlogv2.2
> +  fncache
> +  persistent-nodemap (rust !)
>generaldelta
> -  persistent-nodemap (rust !)
> -  revlog-compression-zstd (zstd !)
> -  revlogv1
> +  revlog-compression-zstd
>sparserevlog
>store
>$ hg debugsidedata -c 0
> +  abort: cannot read from revlog 00changelog-5e69c5d1.sda;  expected 
> 1942585158 bytes from offset 0, data size is 90
> +  [50]
>  
>  upgrade from hgrc
>  
> @@ -1587,20 +1590,8 @@
>> revlogv2=enable-unstable-format-and-corrupt-my-data
>> EOF
>$ hg debugupgraderepo --run --no-backup --quiet
> -  upgrade will perform the following actions:
> -  
> -  requirements
>   preserved: dotencode, fncache, generaldelta, sparserevlog, store 
> (no-zstd !)
> - preserved: dotencode, fncache, generaldelta, revlog-compression-zstd, 
> sparserevlog, store (zstd no-rust !)
>   preserved: dotencode, fncache, generaldelta, persistent-nodemap, 
> revlog-compression-zstd, sparserevlog, store (rust !)
> - removed: revlogv1
> - added: exp-revlogv2.2
> -  
> -  processed revlogs:
> -- all-filelogs
> -- changelog
> -- manifest
> -  
>$ hg debugformat -v
>format-variant repo config default
>fncache:yesyes yes
> @@ -1628,6 +1619,8 @@
>sparserevlog
>store
>$ hg debugsidedata -c 0
> +  abort: cannot read from revlog 00changelog-5e69c5d1.sda;  expected 
> 1942585158 bytes from offset 0, data size is 90
> +  [50]
>  
>  Demonstrate that nothing to perform upgrade will still run all the way 
> through
>  
> 
> ERROR: test-upgrade-repo.t output changed
> !# Ret was: 0 (test-upgrade-repo.t) 

Bug#992843: bullseye-pu: package apr/1.7.0-6+deb11u1

[Yadd]

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

[ Reason ]
An out-of-bounds array read in the apr_time_exp*() functions was fixed in
the Apache Portable Runtime 1.6.3 release (CVE-2017-12613). The fix for
this issue was not carried forward to the APR 1.7.x branch, and hence
version 1.7.0 regressed compared to 1.6.3 and is vulnerable to the same
issue.

[ Impact ]
Medium vulnerability

[ Tests ]
No change in test (test launched only during build, no autopkgtest here)

[ Risks ]
Low risk, patch is trivial

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
This patch just adds some little checks (a month should not be outside
of [1-12]

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 2331e3e..355b51a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+apr (1.7.0-6+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+
+  [ Salvatore Bonaccorso ]
+  * Out-of-bounds array dereference in apr_time_exp*() functions
+(CVE-2021-35940) (Closes: #992789)
+
+ -- Yadd   Tue, 24 Aug 2021 09:18:26 +0200
+
 apr (1.7.0-6) unstable; urgency=medium
 
   [ John Paul Adrian Glaubitz ]
diff --git a/debian/patches/CVE-2021-35940.patch 
b/debian/patches/CVE-2021-35940.patch
new file mode 100644
index 000..6f215fc
--- /dev/null
+++ b/debian/patches/CVE-2021-35940.patch
@@ -0,0 +1,47 @@
+Description: SECURITY: CVE-2021-35940 (cve.mitre.org)
+ Restore fix for CVE-2017-12613 which was missing in 1.7.x branch, though
+ was addressed in 1.6.x in 1.6.3 and later via r1807976.
+ .
+ The fix was merged back to 1.7.x in r1891198.
+ .
+ Since this was a regression in 1.7.0, a new CVE name has been assigned
+ to track this, CVE-2021-35940.
+Origin: upstream, https://svn.apache.org/viewvc?view=revision=1891198
+Bug-Debian: https://bugs.debian.org/992789
+Forwarded: not-needed
+Last-Update: 2021-08-20
+
+--- a/time/unix/time.c
 b/time/unix/time.c
+@@ -142,6 +142,9 @@ APR_DECLARE(apr_status_t) apr_time_exp_g
+ static const int dayoffset[12] =
+ {306, 337, 0, 31, 61, 92, 122, 153, 184, 214, 245, 275};
+ 
++if (xt->tm_mon < 0 || xt->tm_mon >= 12)
++return APR_EBADDATE;
++
+ /* shift new year to 1st March in order to make leap year calc easy */
+ 
+ if (xt->tm_mon < 2)
+--- a/time/win32/time.c
 b/time/win32/time.c
+@@ -54,6 +54,9 @@ static void SystemTimeToAprExpTime(apr_t
+ static const int dayoffset[12] =
+ {0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334};
+ 
++if (tm->wMonth < 1 || tm->wMonth > 12)
++return APR_EBADDATE;
++
+ /* Note; the caller is responsible for filling in detailed tm_usec,
+  * tm_gmtoff and tm_isdst data when applicable.
+  */
+@@ -228,6 +231,9 @@ APR_DECLARE(apr_status_t) apr_time_exp_g
+ static const int dayoffset[12] =
+ {306, 337, 0, 31, 61, 92, 122, 153, 184, 214, 245, 275};
+ 
++if (xt->tm_mon < 0 || xt->tm_mon >= 12)
++return APR_EBADDATE;
++
+ /* shift new year to 1st March in order to make leap year calc easy */
+ 
+ if (xt->tm_mon < 2)
diff --git a/debian/patches/series b/debian/patches/series
index 6d8be19..4003573 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -12,3 +12,4 @@ use_fcntl_locking.patch
 cross.patch
 python3-hashbang.patch
 generic-64bit-atomics.patch
+CVE-2021-35940.patch

Bug#814851: Request For Quotation

[Lucas Thomas]

Good day Sir/Madam,

I am Lucas Thomas, am the purchase manager of Imarc Trading Company United 
States Of American. We have visited your site and would like to try your firm 
as we have been disappointed by our main suppliers with the less quality they 
are settled for, we would like very good quality of product as per whenever we 
place an order.

Kindly send me your latest/current catalogue so we can review your prices, 
please have in mind to give us your best prices and its very urgent as we need 
placing order as soon as possible in order to satisfy our customer requirements.

Hope to hear from you soon,

Thanks.

Lucas Thomas
purchase Department
Overseers Business Unit
30 N Gould St, Ste R Sheridan,
Overseers Business Unit.
Website: https://www.imarcgroup.com
Email: imarc6imp...@hotmail.com

Bug#805557: This bug still exist in Debian 11.0

[肖盛文]

This bug still exist in Debian 11.0

zhcon  version is 1:0.2.6-18


--
肖盛文 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#992704: (no subject)

[Gordon Ball]

Ack, already looking at it.

Unfortunately, there is unlikely to be a quick fix, since upstream has
resolved this by removing their existing html/css sanitizer in favour of
an alternative one from the jupyterlab source tree, which will require
more packaging work before we can utilise it. This is going to be even
more of a problem to backport to stable.

Bug#992528: octave-mapping: FTBFS with GDAL 3.3.1

[Rafael Laboissière]

Control: tags -1 + help

* Bas Couwenberg  [2021-08-19 21:13]:


Source: octave-mapping
Version: 1.4.1-1
Severity: important
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: gdal-3.3

Dear Maintainer,

Your package FTBFS with GDAL 3.3.1:

 [inst/str2angle.m]

/build/octave-mapping-1.4.1/inst/str2angle.m

 * test
 * shared tst, res
  tst = '191E21''3.1"\n12e 22''33.24"\n13E 23'' 33.344"\n14w24'' 33."\n';
  tst = [tst '15S25''33.5"\n16W26''33.64\n17s27''33.744"\n'];
  tst = [tst '18N28''33.8444"\n19d29m33.9s\n20D20M33.0444Se\n'];
  tst = [tst '21??51''4.1"\n22??52''44.25"\n23?? 53''33.34"\n24??54'' 
33.44"N\n'];
  tst = [tst '25?? 55'' 33.544"\n26??56''33.644S\n27??57'' 33.744\n'];
  tst = [tst '28??58''33.844"w'];
  tst = strrep (tst, '\n', char(10));
  res = [191.351, 12.376, 13.393, -14.409, -15.426, -16.443, -17.459, 18.476, 
...
 19.493, 20.343, 21.851, 22.879, 23.893, 24.909, 25.926, 26.943, ...
 27.959, -28.976];
  assert (str2angle (tst), res, 1e-3);
 ! test failed
 ASSERT errors for:  assert (str2angle (tst),res,1e-3)

   Location  |  Observed  |  Expected  |  Reason
  .  O(1x1)  E(1x18)  Dimensions don't match
 shared variables   scalar structure containing the fields:

 tst = [](0x0)
 res = [](0x0)
 * test
  tstc = strsplit (tst, "\n");
  assert (str2angle (tstc), res, 1e-3);
 ! test failed
 strsplit: S and DEL must be string values
 shared variables   scalar structure containing the fields:

 tst = [](0x0)
 res = [](0x0)
 * test
  tstc = strjoin (strsplit (tst, "\n"), "   ");
  assert (str2angle (tstc), res, 1e-3);
 ! test failed
 strsplit: S and DEL must be string values
 shared variables   scalar structure containing the fields:

 tst = [](0x0)
 res = [](0x0)
 * test
  assert (str2angle ('24E77''33"  25W43''57.7"'), [NaN, -25.7333], 1e-3);
 ! test failed
 ASSERT errors for:  assert (str2angle ('24E77'33"  25W43'57.7"'),[NaN, 
-25.7333],1e-3)

   Location  |  Observed  |  Expected  |  Reason
  .  O(1x1)   E(1x2)  Dimensions don't match
 shared variables   scalar structure containing the fields:

 tst = [](0x0)
 res = [](0x0)
 * test
  assert (str2angle ('; aggag'), Inf);
 * warning  str2angle ('24E77''33"', 1);
 * warning  str2angle (' -4D-32''-44.57"', 1);
 * error  str2angle (25);
 8 tests, 5 passed, 0 known failure, 0 skipped


Thanks for this bug report.

This problem seems to be completely unrelated to the upgrade of the GDAL 
library. The bug is exposed by the unit tests in the function str2angle, 
defined in file inst/str2angle.m. This file contains purely Octave 
interpreted code which is not related to libgdal.


I can replicate the bug on an up-to-date unstable chroot, without 
libgdal28, ligdgal29, nor octave-mapping installed. When I run the 
following commands in such a chroot:


sudo apt update
sudo apt dist-upgrade
sudo aptitude install octave
apt-get source octave-mapping
cd octave-mapping-1.4.1/inst
echo "test str2angle" | octave-cli --quiet

I obtain the following:

 * shared tst, res
  tst = '191E21''3.1"\n12e 22''33.24"\n13E 23'' 33.344"\n14w24'' 33."\n';
  tst = [tst '15S25''33.5"\n16W26''33.64\n17s27''33.744"\n'];
  tst = [tst '18N28''33.8444"\n19d29m33.9s\n20D20M33.0444Se\n'];
  tst = [tst '21??51''4.1"\n22??52''44.25"\n23?? 53''33.34"\n24??54'' 
33.44"N\n'];
  tst = [tst '25?? 55'' 33.544"\n26??56''33.644S\n27??57'' 33.744\n'];
  tst = [tst '28??58''33.844"w'];
  tst = strrep (tst, '\n', char(10));
  res = [191.351, 12.376, 13.393, -14.409, -15.426, -16.443, -17.459, 18.476, 
...
 19.493, 20.343, 21.851, 22.879, 23.893, 24.909, 25.926, 26.943, ...
 27.959, -28.976];
  assert (str2angle (tst), res, 1e-3);
 ! test failed
 ASSERT errors for:  assert (str2angle (tst),res,1e-3)

   Location  |  Observed  |  Expected  |  Reason
  .  O(1x1)  E(1x18)  Dimensions don't match
 shared variables   scalar structure containing the fields:

 tst = [](0x0)
 res = [](0x0)

Best,

Rafael Laboissière

P.S.1: I am hereby tagging this bug report "help", since I have no idea 
where the problem comes from. It is probably due to a change in some of 
the dependings libraries related to the upgrade from bullseye to 
bookworm.


P.S.2: In order to not prevent the blocking of the ligdal 28→29 
transition, we could transform the failing unit tests in str2angle.m from 
"%!test" into "%!xtest". Subsequently, after the transition is done we 
could try to fix the problem, which is independent of libgdal. What do 
you think?

Bug#979458: Reassigning, merging and rising severity level of Bugs #979458 and #979459

[Rafael Laboissière]

Control: reassign 979458 src:jed 1:0.99.19-8
Control: reassign 979459 src:jed 1:0.99.19-8
Control: severity 979458 serious
Control: severity 979459 serious
Control: tags 979458 + patch
Control: tags 979459 + patch
Control: merge 979458 979459

With the upload of version 5.3-1 of the package debianutils, the tempfile 
command is definitively gone from Debian. This means that installation of 
the jed, jed-common, and xjed packages does not succeed in bookworm, 
since their postinst scripts invoke tempfile.


I am hereby reassigning the Bugs #979458 and #979459, which were assigned 
to the binary jed and jed-common packages, to the jed source package. I 
am also merging this two bug reports and rising their severity level to 
serious.


The trivial patch that fixes the problem is attached to this message.

Best,

Rafael Laboissière

P.S.: Note that removing the jed-common package from a bookworm system 
also fails because the tempfile command is used in the prerm maintainer 
script. Here is a simple recipe for doing it successfully:


sudo ln -sf /bin/mktemp /usr/bin/tempfile ;  sudo apt remove jed-common ; 
sudo rm /usr/bin/tempfile
diff --git a/debian/jed-common.postinst b/debian/jed-common.postinst
index 415dbde..96b204a 100644
--- a/debian/jed-common.postinst
+++ b/debian/jed-common.postinst
@@ -7,7 +7,7 @@ set -e
 case "$1" in
   configure)
 
-	TEMP=$(tempfile)
+	TEMP=$(mktemp)
 
 	printf "Running /usr/share/jed/compile/jed-common..."
 	if ! /usr/share/jed/compile/jed-common install >$TEMP 2>&1; then
diff --git a/debian/jed-common.prerm b/debian/jed-common.prerm
index 296fd78..ca3e677 100644
--- a/debian/jed-common.prerm
+++ b/debian/jed-common.prerm
@@ -5,7 +5,7 @@ set -e
 case "$1" in
 remove|upgrade|deconfigure)
 
-TEMP=$(tempfile)
+TEMP=$(mktemp)
 printf "Running /usr/share/jed/compile/jed-common..."
 RET=0
 /usr/share/jed/compile/jed-common remove >$TEMP 2>&1 || RET=$?
diff --git a/debian/jed.postinst b/debian/jed.postinst
index 96bb2f9..f3ca2fa 100644
--- a/debian/jed.postinst
+++ b/debian/jed.postinst
@@ -12,7 +12,7 @@ case "$1" in
 	--install /usr/bin/jed-script jed-script /usr/bin/jed 50 \
 	--slave /usr/share/man/man1/jed-script.1.gz jed-script.1.gz /usr/share/man/man1/jed.1.gz;
 
-TEMP=$(tempfile)
+TEMP=$(mktemp)
 RET=0
 printf "Updating precompiled files..."
 run-parts --exit-on-error --arg=install /usr/share/jed/compile/ \
diff --git a/debian/xjed.postinst b/debian/xjed.postinst
index 2648220..47ed8a0 100644
--- a/debian/xjed.postinst
+++ b/debian/xjed.postinst
@@ -12,7 +12,7 @@ case "$1" in
 	--install /usr/bin/jed-script jed-script /usr/bin/xjed 40 \
 	--slave /usr/share/man/man1/jed-script.1.gz jed-script.1.gz /usr/share/man/man1/xjed.1.gz;
 
-TEMP=$(tempfile)
+TEMP=$(mktemp)
 RET=0
 printf "Updating precompiled files..."
 run-parts --exit-on-error --arg=install /usr/share/jed/compile/ \

Bug#992528: octave-mapping: FTBFS with GDAL 3.3.1

[Sebastiaan Couwenberg]

On 8/24/21 8:40 AM, Rafael Laboissière wrote:
> P.S.2: In order to not prevent the blocking of the ligdal 28→29
> transition, we could transform the failing unit tests in str2angle.m
> from "%!test" into "%!xtest". Subsequently, after the transition is done
> we could try to fix the problem, which is independent of libgdal. What
> do you think?

That's sounds like a good short term workaround.

Kind Regards,

Bas

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

Bug#992832: linux-image-5.10.0-8-amd64: please enable CONFIG_AMD_PMC

[Gedalya]

Package: linux-image-5.10.0-8-amd64
Version: 5.10.46-4

Hi,

amd-pmc is needed on recent AMD Ryzen laptops in order to properly enter s2Idle.

Another module apparently relevant on recent Ryzen laptops is 
CONFIG_AMD_SFH_HID, although this PCI device is not present on my laptop.

Thanks,

Gedalya

Bug#983565: coreutils should support DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi,

support for DPKG_ROOT is now present in packages like dpkg, glibc, debhelper
and debianutils. Since the bookworm development just started, I wanted to send
a friendly ping to this bug. We now have set up a script on salsaci that shows
how we can create a bit-by-bit identical chroot using DPKG_ROOT:

https://salsa.debian.org/helmutg/dpkg-root-demo/-/jobs

Please consider applying the patch Helmut proposed in the initial report.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#992800: [Pkg-puppet-devel] Bug#992800: puppet agent breaks after upgrade to bullseye on arm architecture

[stoeni]

Am 24.08.2021 um 00:34 schrieb Thomas Goirand:

On 8/23/21 5:40 PM, stoeni wrote:

Package: puppet
Version: 5.5.22-2
Severity: normal
X-Debbugs-Cc: none

After upgrading some Raspberry Pi (Zero, Model3/4) from buster to
bullseye, the puppet client no longer works on this architecture.

Steps to reproduce this error:

- install rasbian buster on a Raspberry Pi
- upgrade to bullseye
- run e.g. "puppet agent"

running puppet without arguments works:

--<8--
root@moon:~# puppet
See 'puppet help' for help on available puppet subcommands
-->8--

running puppet with arguments aborts:

--<8--
root@moon:~# puppet help
Aborted
-->8--

puppet 5.5.10 runs well on buster with amd64 or arm architecture, 5.5.22
runs on bullseye and amd64, not on arm.

as there are no log entries or any usable output how can i help to track
this thing down? maybe its ruby related?

would some strace output help?


Hi,

Are you *SURE* that the problem is the arch, and not the (very small)
amount of RAM you get on such a small device?

I do remember running puppet agent on 512 MB device, and it was eating a
lot of RAM already. This was 5 years ago... I wouldn't be surprised if
newer ruby and newer puppet agent used more memory...

Maybe you could try adding a lot of SWAP, just to try? (not saying that
a device swapping a lot is usable, but I just want to know if that would
work...)

Cheers,

Thomas Goirand (zigo)



Hi Thomas,

8G of RAM (without swap) on a Pi4 should be sufficient ;-)

--<8--
root@moon:~# free -h
   total   used   free   shared  buff/cache  available
Mem:   7.6Gi   62Mi  7.1Gi0.0Ki   409Mi  7.4Gi
Swap: 0B 0B 0B
--8>--

5.5.10 runs well, but slow on the Pi zeros (512MB).

OOM should be logged via kernel/dmesg? But there is nothing logged

--
cheers,
stoeni

* yes, we scan ! *