Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same

[Dima Kogan]

Hi Aaron. Thank you for looking at this. I'm trying to build the latest
as of right now (8acc5c51eb81d701a36df1d5b9466b1df9ef9f2c). I see this:


  $ dpkg-buildpackage -us -uc -b

  dpkg-buildpackage: info: source package fltk1.3
  dpkg-buildpackage: info: source version 1.3.8-1
  ...
  dh_auto_clean
  make -j4 distclean
  make[2]: Entering directory '/home/dima/debianstuff/fltk1.3'
  rm -f core *.o
  for dir in examples  src  fluid test documentation; do\
  echo "=== cleaning $dir ===";\
  (cd $dir; make -w -j4 --jobserver-auth=3,4 clean) || exit 1;\
  done
  === cleaning examples ===
  make[3]: Entering directory '/home/dima/debianstuff/fltk1.3/examples'
  make[3]: warning: -j4 forced in submake: resetting jobserver mode.
  make[3]: ../fltk-config: No such file or directory
  make[3]: Leaving directory '/home/dima/debianstuff/fltk1.3/examples'
  === cleaning src ===
  make[3]: Entering directory '/home/dima/debianstuff/fltk1.3/src'
  make[3]: warning: -j4 forced in submake: resetting jobserver mode.
  /bin/sh: 1: test: =: unexpected operator
  /bin/sh: 1: test: =: unexpected operator
  /bin/sh: 1: test: =: unexpected operator
  /bin/sh: 1: test: =: unexpected operator
  /bin/sh: 1: test: =: unexpected operator

The "unexpected operator" stuff can be reproduced like this:

  fltk1.3/src$ make clean

The problem is in src/Makefile in the definition of MMFILES: it's
looking at $(MMFILES), but that variable isn't defined, which evaluates
to an empty token. Putting $(USEMMFILES) in "" is one way to fix this.

Other than this, it looks like things are working. Thanks!

Bug#1002850: udev fails to create a symlink for a SDHC card connected to a Sharp Mebius laptop.

[Michael Biebl]

Control: tags -1 + moreinfo

On 30.12.21 03:10, pe...@easthope.ca wrote:


* What led up to the situation?
  Attempted to use a SDHC card in a Sharp Mebius PC-CB1-M1.
  
* What exactly did you do (or not do) that was effective (or

  ineffective)?
  Attempted to use a SDHC card in a Sharp Mebius PC-CB1-M1.
  Followed the same procedure as used with previous Debians
  and in Debian 11 on other machines.


What procedures?


* What was the outcome of this action?
  The symlink was not created as in other cases.


What symlink? Please be more specific.
Have you created custom udev rules or what?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002148: qwertone: FTBFS: unsatisfiable build-dependencies

[plugwash]

The rust gtk stack is now installable again, but it looks like qwertone 
needs some work to build with

the new version of the stack.

It looks like upstream has updated the code for 0.14 but attempting to 
grab the upstream commit and
apply it as a patch resulted in a bunch of hunks failling, so it may be 
better to just update to a new

upstream version.

Bug#1000336: Upgrading tbb

[Diane Trout]

On Thu, 2021-12-23 at 11:03 -0500, M. Zhou wrote:
> Hi all,
> 
> I'm back.
> 
> I've just finished my final exams so I could do something during
> the holiday. That TBB repository is still work-in-progress and
> FTBFS from the master branch is something expected. I will finalize
> it soon. Andreas said in previous posts that we prefer a faster
> NEW queue process. I understand that but we cannot bypass NEW process
> this time as upstream has bumped the SONAME. So I'm changing the
> source name as well following the upstream since NEW is inevitable.
> 
> As for llvmlite, the latest upstream RC release v0.38.0rc1 seems
> to support python 3.10 . Should I upload the RC release?
> 
> BTW, what else should I do? I've been out of sync from the mailing
> list for a long while.


Have you managed to make much progress?

I fiddled with the packaging and got it to build and trying to run the
autopkgtests with 2021.4.0-1

What'd help me is to have a package I could build locally and test
numba against. If you got it working could you commit what you have to
a salsa branch and let me know where it is?

Thanks,
Diane

Bug#996875: aide: 31_aide_spamassassin needs update for SpamAssassin 3.4.6

[Marc Haber]

On Mon, Dec 13, 2021 at 08:50:13PM +0100, Marc Haber wrote:
> I have committed the change to git.

I have also made it easier to override the Spamassassin Version Number
from an earlier configuration file or snippet. That way, local admins
can establish local measures to keep up with Spamassassin versioning.

Greetings
Marc

Bug#1002852: shorwall: Couldn't load target `LIBVIRT_PRT':No such file or directory (fixed in version 5.2.3.6+)

[Raoul Bhatia]

Package: shorewall
Version: 5.2.3.4-1

Shorewall fails to restart when configured to support DOCKER
and running libvirtd at the same time.

The issues seems to be that
LIBVIRT_PRT is handled as part of the DOCKER integration
but should be ignored by shorewall.

shorewall operations like stop or restart might fail with
iptables-restore v1.8.4 (legacy): Couldn't load target `LIBVIRT_PRT':No 
such file or directory



Applying the upstream patch to filter out "LIBVIRT" in 
save_docker_rules($) solves this problem.


PS. I am currently running Ubuntu 20.04,
but judging by the versions, my suggestion is to fix this in Debian.


Referenes:
* 
https://sourceforge.net/p/shorewall/mailman/shorewall-users/thread/76d7724c-2507-ba6c-243a-6f82e0313ba3%40shorewall.net/#msg36925220
* 
https://gitlab.com/shorewall/code/-/commit/31b558b7f9ce0becf775edc4e21dd6eff82aac09
* 
https://gitlab.com/shorewall/release/-/blob/5.2.8/releasenotes.txt#L1051



Package versions:

ii  shorewall5.2.3.4-1
ii  shorewall-core   5.2.3.4-1
ii  shorewall6   5.2.3.4-1

ii  libvirt-clients  6.0.0-0ubuntu8.15
ii  libvirt-daemon   6.0.0-0ubuntu8.15
ii  libvirt-daemon-driver-qemu   6.0.0-0ubuntu8.15
ii  libvirt-daemon-system6.0.0-0ubuntu8.15
ii  libvirt-daemon-system-systemd6.0.0-0ubuntu8.15
ii  libvirt0:amd64   6.0.0-0ubuntu8.15


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# iptables-save | grep LIBVIRT_PRT
:LIBVIRT_PRT - [0:0]
-A POSTROUTING -j LIBVIRT_PRT
-A LIBVIRT_PRT -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM 
--checksum-fill

:LIBVIRT_PRT - [0:0]
-A POSTROUTING -j LIBVIRT_PRT
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j 
MASQUERADE --to-ports 1024-65535
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j 
MASQUERADE --to-ports 1024-65535

-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# shorewall restart
Stopping Shorewall
Preparing iptables-restore input...
Running /usr/sbin/iptables-restore --wait 60...
iptables-restore v1.8.4 (legacy): Couldn't load target `LIBVIRT_PRT':No 
such file or directory


Error occurred at line: 16
Try `iptables-restore -h' or 'iptables-restore --help' for more 
information.

   ERROR: /usr/sbin/iptables-restore --wait 60 Failed.
IPv4 Forwarding Enabled
done.
Starting Shorewall
Initializing...
Setting up Route Filtering...
Setting up Martian Logging...
Preparing iptables-restore input...
Running /usr/sbin/iptables-restore --wait 60...
iptables-restore v1.8.4 (legacy): Couldn't load target `LIBVIRT_PRT':No 
such file or directory


Error occurred at line: 39
Try `iptables-restore -h' or 'iptables-restore --help' for more 
information.
   ERROR: iptables-restore Failed. Input is in 
/var/lib/shorewall/.iptables-restore-input

Terminated
--
DI (FH) Raoul Bhatia MSc
E-Mail. ra...@bhatia.at
Tel. +43 699 10132530

Bug#1002675: re hubic/pyrax problem

[Alexander Zangerl]

fabrice, upstream has reported that the problem you're encountering
is pretty much certainly not coming from duplicity but pyrax - which is
deprecated and no longer being maintained.

upstream requests the log of a duplicity run with full -v9 logging/debugging
on in order to track this down any further. if you can provide such a log
the chances of getting this sorted out will rise a bit.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Q. what do you get whan you cross a tsetse with a mountain climber?
A. nothing, you can't cross a vector with a scalar.


signature.asc
Description: Digital Signature

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@outlook.com

And it just happened again, on the very first boot of the day, as if nothing
has changed since May. I was right for not upgrading past 5.10.28 all those
months.


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

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

Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same

[Aaron M. Ucko]

u...@debian.org (Aaron M. Ucko) writes:

> Only in the context of package builds; in other contexts (ad-hoc builds
> against system FLTK), it's currently entirely possible to have only
> libfltk1.3-dev installed.  I could perhaps downgrade the dependency to a
> recommendation, but I don't think it would be unreasonable to leave it
> as a full dependency.

At any rate, please try the changes I've pushed to
https://salsa.debian.org/ucko/fltk1.3.  I'm not uploading anything to
the archive quite yet because I'd first like to take care of some
unrelated cleanups that should be quick but for which I'm out of time at
the moment; I'm hoping to get them within the next few days.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#640881: uqm: upstream version updated to 0.7

[Mark Pavlichuk]

On Thu, 08 Sep 2011 09:41:19 +0200 Andreas Wirooks 
 wrote:

> Package: uqm
> Version: 0.6.2.dfsg-9
> Severity: wishlist
> Tags: upstream
>
> As the title says. The new version is online. There is also a sound 
jitter
> problem in squeeze, but i think it is better to wait, maybe it is 
already fixed

> upstream.




...and it looks like another release has been available for a while 
now.  From the website:




Happy 2021, Humans. It has been almost ten years since Version 0.7 was 
released, and a lot has happened since then. UQM 0.8 has now been 
released to catch up with that.


This newest release has a lot of changes in it, but the highlights are:

 * Namable savegames
 * A new save format that should make it easier for mods to coexist and
   should also make it much easier to edit save files
 * A new graphics, sound, and input backend based on SDL2
   , which in turn grants much-improved
   fullscreen support as well as Metal and DirectX support on Mac and
   Windows, or VC4 support on a properly configured Raspberry Pi
 * Nine years of sporadic bugfixes from the community post-0.7
 * TLS support for the Windows installer, which should restore the
   functionality of the net installer
 * Unified build system on Mac, Linux, and Windows, with better
   coexistence with systemwide standard libraries
 * Official support for the final Remix Pack 4, which came out after
   0.7 did
 * A revised /version/ of Remix Pack 4 with some fixed audio mixes

Overall, this release is part "years of deferred maintenance" and part 
"actually release the unpublished work that still fits in well with the 
popular mods".


Get the new release from the downloads page 
, or discuss it on the forum 
!


---

It looks like this could potentially fix other bugs eg. #483637 



--
Mark Pavlichuk

Bug#834724: curl: (35) gnutls_handshake() failed: Public key signature verification has failed.

[Tigi utara]

On Wed, 28 Sep 2016 12:57:49 +0100 Tim Small  wrote:
> Package: curl
> Followup-For: Bug #834724
>
> I fixed this on a sid install by removing libgnutls-deb0-28 which was
> being kept around by an old librtmp1 package version, left over from
> Jessie debian-multimedia.  Possibly libcurl should conflict with this
> package?
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages curl depends on:
> ii  libc62.24-3
> ii  libcurl3-gnutls  7.50.1-1
> ii  zlib1g   1:1.2.8.dfsg-2+b1
>
> curl recommends no packages.
>
> curl suggests no packages.
>
> -- debconf-show failed
>
>

Bug#1002850: Additional information.

[peter]

This message and replies to it contain additional information.

https://lists.debian.org/debian-user/2021/12/msg00937.html

I should have included the link in the original report. Apology for 
the omission.

Thanks,  ... P.

-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

Bug#1002851: xdelta: /usr/bin/xdelta-config moved from libxdelta2-dev to xdelta

[Andreas Beckmann]

Package: xdelta
Version: 1.1.3-10.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../xdelta_1.1.3-10.1_amd64.deb ...
  Unpacking xdelta (1.1.3-10.1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/xdelta_1.1.3-10.1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/xdelta-config', which is also in package 
libxdelta2-dev 1.1.3-9.3
  Errors were encountered while processing:
   /var/cache/apt/archives/xdelta_1.1.3-10.1_amd64.deb

This is a regression in the recent NMU, could be a side effect
of the bumped compat level.
You probably don't want to add Breaks+Replaces, but move the file back.

The git repository is missing the NMUs -9.[1-4], and the package could 
be missing the corresponding changes, I haven't checked.


cheers,

Andreas


libxdelta2-dev=1.1.3-9.3_xdelta=1.1.3-10.1.log.gz
Description: application/gzip

Bug#965685: libropkg-perl: diff for NMU version 0.4-1.4

[Andreas Beckmann]

On Sun, 26 Dec 2021 18:07:52 +0100 gregor herrmann  
wrote:

I've prepared an NMU for libropkg-perl (versioned as 0.4-1.4) and


libropkg-perl is orphaned, so you should rather QA it to -2 than NMU it 
to -1.4 ;-)



Andreas

Bug#1002849: python3-sage: missing Breaks+Replaces: sagemath-common (<< 9.4)

[Andreas Beckmann]

Package: python3-sage
Version: 9.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-sage_9.4-2_amd64.deb ...
  Unpacking python3-sage (9.4-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-sage_9.4-2_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/sage/__init__.py', which 
is also in package sagemath-common 9.2-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-sage_9.4-2_amd64.deb

cheers,

Andreas


sagemath-common=9.2-2_python3-sage=9.4-2.log.gz
Description: application/gzip

Bug#993495: The same here

[Florent DENAT]

I got the same bug.

Thanx for the tip.

I commented out the "User=" line and sddm was able to start correctly.

I don't know which log I must upload. Sorry.

Bug#1002848: python3-zipstream-ng: missing Breaks+Replaces: python3-zipstream (and maybe Provides, too)

[Andreas Beckmann]

Package: python3-zipstream-ng
Version: 1.3.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

If python3-zipstream-ng is supposed to be a drop-in replacement for
python3-zipstream (the matching compat module name suggests this),
you should probably also have Provides: python3-zipstream

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-zipstream-ng_1.3.3-1_all.deb ...
  Unpacking python3-zipstream-ng (1.3.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-zipstream-ng_1.3.3-1_all.deb (--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/zipstream/__init__.py', 
which is also in package python3-zipstream 1.1.4-1
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-zipstream-ng_1.3.3-1_all.deb


cheers,

Andreas


python3-zipstream=1.1.4-1_python3-zipstream-ng=1.3.3-1.log.gz
Description: application/gzip

Bug#982985: RFP: multi-timer -- App to set multiple timers sequentially.

[Bastian Germann]

Control: owner -1 Scorpion2185 
Control: retitle -1 ITP: multi-timer -- App to set multiple timers sequentially
Control: block -1 by 1002295

Bug#1002837: tiledb: diff for NMU version 1.7.7-1.2

[Dirk Eddelbuettel]

Couldn't resist an attempt to send in an 1.7.7-3 attempt but still seeing too
many unit test failures.  Very strange as this works for me on amd64 :-/

Adam, how would you feel about an update to 2.5.3 and catch2 (and no more
tbb-dev) ?  Would you be ok with me sending that up as NMU?

Dirk

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

Bug#1002847: nttcp: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Andreas Beckmann]

Source: nttcp
Version: 1.47-13
Severity: serious
User: nthyk...@master.debian.org
Usertags: compat-5-6-removal

Hi,

The package nttcp uses debhelper with a compat level of 5 or 6,
which is no longer supported [1].

Please bump the debhelper compat at your earliest convenience

  * Compat 13 is recommended (supported in stable-backports)

  * Compat 7 is the bare minimum


Thanks,
Andreas

[1] https://lists.debian.org/debian-devel/2020/07/msg00065.html

Bug#1002834: bugs.debian.org: radeon /dri3/composer vsync/ no browser works/ menu software quits

[Don Armstrong]

Control: reassign -1 xserver-xorg-video-radeon
Control: severity -1 normal
Control: tag -1 moreinfo

I believe bug belongs against the xserver-xorg-video-radeon package.
[It's definitely not a bug in bugs.debian.org]

You should also provide the Xorg.0.log and any kernel logs which show
the behavior that you are seeing (whatever is actually happening).

On Wed, 29 Dec 2021, meh wrote:
> Package: bugs.debian.org
> Severity: important
> X-Debbugs-Cc: inqu...@babyawacs.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> Debian is unusable with Radeon any form of gpu acceleration
> 
> The problem is between Radeon glamor DRI3, composers vsynch/  xrender glx
> 
> no browser works  instant crash any tab firefox , epiphany invisible websites
> but preview brackets show a foto
> 
> dri3 glamor does not launch libreoffice
> 
> ANY DRI or DRIVER: menu software quits after clicking one of the bottom 
> choices
> extensions etc
> 
> 
> all runs only because itis lightdm xfce
> in wayland and gdm3 it would freeze
> before login
> 
> *
> a simple mismatch of desktop renderer with obsolete drivers ?
> 
> all maybe simpler to fix if itis a   set of
> 
> mismatching actuality
> *
> 
> 
> allthebest!

> Dec 26 21:28:43 systemd: Reached target Exit the Session.
> Dec 26 21:28:43 tracker-miner-f: OK
> Dec 26 21:28:43 systemd: Stopped Virtual filesystem metadata service.
> Dec 26 21:28:43 tracker-store: OK
> Dec 26 21:28:43 systemd: evolution-source-registry.service: Succeeded.
> Dec 26 21:28:43 xdg-desktop-por: Caught PipeWire error: connection error
> Dec 26 21:28:43 pipewire-media-: error id:0 seq:191 res:-32 (Broken pipe): 
> connection error
> Dec 26 21:28:43 systemd: Stopping Virtual filesystem service - disk device 
> monitor...
> Dec 26 21:28:43 gvfsd: A connection to the bus can't be made
> Dec 26 21:28:41 systemd: thunar.service: Failed with result 'exit-code'.
> Dec 26 21:28:41 at-spi2-registr: X connection to :0 broken (explicit kill or 
> server shutdown).
> Dec 26 21:19:00 systemd: gnome-terminal-server.service: Consumed 1.720s CPU 
> time.
> Dec 26 21:18:54 sudo: pam_unix(sudo:session): session closed for user root
> Dec 26 21:17:59 systemd: Started VTE child process 1374 launched by 
> gnome-terminal-server process 1326.
> Dec 26 21:17:58 dbus-daemon: [session uid=1000 pid=779] Successfully 
> activated service 'org.gnome.Terminal'
> Dec 26 21:17:57 systemd: Starting GNOME Terminal Server...
> Dec 26 21:17:57 dbus-daemon: [session uid=1000 pid=779] Activating via 
> systemd: service name='org.gnome.Terminal' 
> unit='gnome-terminal-server.service' requested by ':1.81' (uid=1000 pid=1314 
> comm="gnome-terminal --wait ")
> Dec 26 21:17:47 gsf-office-thum: error: The metadata does not have a 
> thumbnail property
> Dec 26 21:17:45 xdg-desktop-por: Failed to get application states: 
> GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list
> Dec 26 21:17:39 systemd: Started Virtual filesystem metadata service.
> Dec 26 21:17:39 dbus-daemon: [session uid=1000 pid=779] Successfully 
> activated service 'org.gtk.vfs.Metadata'
> Dec 26 21:17:39 systemd: Starting Virtual filesystem metadata service...
> Dec 26 21:17:39 dbus-daemon: [session uid=1000 pid=779] Activating via 
> systemd: service name='org.gtk.vfs.Metadata' unit='gvfs-metadata.service' 
> requested by ':1.44' (uid=1000 pid=1041 comm="xfdesktop --display :0.0 
> --sm-client-id 218630644-")
> Dec 26 21:17:39 systemd: Startup finished in 30.986s.
> Dec 26 21:17:38 dbus-daemon: [session uid=1000 pid=779] Successfully 
> activated service 'org.xfce.FileManager'
> Dec 26 21:17:38 systemd: Started Tracker metadata database store and lookup 
> manager.
> Dec 26 21:17:38 dbus-daemon: [session uid=1000 pid=779] Successfully 
> activated service 'org.freedesktop.Tracker1'
> Dec 26 21:17:38 systemd: Starting Tracker metadata database store and lookup 
> manager...
> Dec 26 21:17:38 dbus-daemon: [session uid=1000 pid=779] Activating via 
> systemd: service name='org.freedesktop.Tracker1' unit='tracker-store.service' 
> requested by ':1.75' (uid=1000 pid=1106 comm="/usr/libexec/tracker-miner-fs ")
> Dec 26 21:17:37 systemd: Starting Thunar file manager...
> Dec 26 21:17:37 dbus-daemon: [session uid=1000 pid=779] Activating via 
> systemd: service name='org.xfce.FileManager' unit='thunar.service' requested 
> by ':1.44' (uid=1000 pid=1041 comm="xfdesktop --display :0.0 --sm-client-id 
> 218630644-")
> Dec 26 21:17:37 tumblerd: Registered thumbnailer 
> /usr/bin/gdk-pixbuf-thumbnailer -s %s %u %o
> Dec 26 21:17:36 gst-plugin-scan: r300: driver missing
> Dec 26 21:17:35 systemd: Started 

Bug#1002845: onboard: the status icon does not appear on gnome

[Teo]

Package: onboard
Version: 1.4.1-5+b4
Severity: normal
X-Debbugs-Cc: teodoro777.coluc...@live.com

I'm on debian testing, (but I tried also debian stable) with gnome 41.1, and as
the title, I can't get the status icon to appear.
I've of course the appindicator extension installed, indeed, all other status
icon appear.
Also, I've noticed that in other distros, this works smoothly.
What can I try to make it work on debian too?

Regards
Teo


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

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

Versions of packages onboard depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  gir1.2-gdkpixbuf-2.0 2.42.6+dfsg-2
ii  gir1.2-glib-2.0  1.70.0-2
ii  gir1.2-gtk-3.0   3.24.30-4
ii  gir1.2-pango-1.0 1.48.10+ds1-1
ii  iso-codes4.8.0-1
ii  libc62.33-1
ii  libcairo21.16.0-5
ii  libcanberra0 0.30-8
ii  libdconf10.40.0-2
ii  libgcc-s111.2.0-12
ii  libglib2.0-0 2.70.2-1
ii  libgtk-3-0   3.24.30-4
ii  libhunspell-1.7-01.7.0-4
ii  librsvg2-common  2.50.7+dfsg-2
ii  libstdc++6   11.2.0-12
ii  libudev1 249.7-1
ii  libx11-6 2:1.7.2-2+b1
ii  libxi6   2:1.8-1
ii  libxkbfile1  1:1.1.0-1
ii  libxtst6 2:1.2.3-1
ii  onboard-common   1.4.1-5
ii  python3  3.9.7-1
ii  python3-cairo1.20.1-3
ii  python3-dbus 1.2.18-3+b1
ii  python3-gi-cairo 3.42.0-2+b1

Versions of packages onboard recommends:
ii  gir1.2-atspi-2.0 2.42.0-2
ii  gir1.2-ayatanaappindicator3-0.1  0.5.90-4
ii  onboard-data 1.4.1-5
ii  xdg-utils1.1.3-4.1

Versions of packages onboard suggests:
pn  mousetweaks  

-- no debconf information

Bug#991466: thunar needs gvfs-backends to read phone memory

[Teodoro Coluccio]

Unfortunately I have to note that the "problem" still exists.
Debian 11 does not have the gvfs-backends package installed.

Regards
Teo

Bug#978040: [Pkg-pascal-devel] Bug#978040: Bug#978040: Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)

[Abou Al Montacir]

I have just checked on a new installation of FPC 3.2.2 on ARM and it looks like
the detection of GCC library path is correct.
# path to the gcclib
#ifdef cpuaarch64
-Fl/usr/lib/gcc/arm-linux-gnueabi/11
#endif

The code, internally uses;
gcc --print-libgcc-file-name
So it should work correctly on all targets.

However, it is true that if a new gcc version is installed after FPC then the
logic will fall down.

If this is judged OK, I propose to close this ticket
-- 
Cheers,
Abou Al Montacir


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

Bug#1002835: RFS: zvbi/0.2.35-19 [ITA] -- Vertical Blanking Interval (VBI) utilities

[Bastian Germann]

I have uploaded with minor changes and granted you write rights on the git repo.

Bug#981446: RFA: logcheck -- mails anomalies in the system logfiles to the administrator

[Richard Lewis]

In case it helps, i have pushed some commits here

https://salsa.debian.org/rpil2/logcheck

eg people might want to reuse the autopkgtest or changes to postinst/postrm
which make it "piuparts clean". Or not.

this is not a request to maintain logcheck or to merge anything into debian
- merely an exercise in understanding the existing code (which needs
further simplifications in my view).

if debian goes in another direction i will probably rebase and amend
commits to follow



On Wed, 8 Dec 2021, 19:50 Richard Lewis, <
richard.lewis.deb...@googlemail.com> wrote:

> great idea - is there anyone who will merge (good, sensible)
> contributions?
>
> it seems there are many people interested in this RFA over the years but
> no-one who has the ability (ie a DD) to do the final merge/upload.
>
>
> regatdless, let's not have a competition but get many people involved (im
> sure your intent too, but thought i'd say it explicitly).
>
> (it also occurs to me to ask whether whoever takes over might want to add
> logcheck to the pkg-security team - who i cant speak for but who are highly
> welcoming of new people in my recent experience. )
>
>
> On Wed, 8 Dec 2021, 14:57 Charles,  wrote:
>
>> This RFA is progressing slowly.  Do I rightly understand that it is
>> Hannes' who is to choose the new maintainers?  It must be difficult to
>> choose, knowing little about us volunteers.  Can we progress by having
>> each of the volunteers work on one of the current bugs?  That would
>> usefully fix some bugs, give us volunteers experience of the work and
>> inform Hannes about our capabilities.
>>
>> --
>> To unsubscribe, send mail to 981446-unsubscr...@bugs.debian.org.
>>
>

Bug#1002840: gnome-software: screenshot URLs never update new DEP-11/appstream-data and fail HTTP 404

[Jano John Akim Franke]

Workaround is to download the updated file without 'apt update' to the 
same location and doing an appstream refresh. Screenshots of "Builder" 
are visible after that:


# wget --timestamping 
'https://appstream.debian.org/data/bullseye/main/Components-amd64.yml.gz' -O 
'/var/lib/app-info/yaml/deb.debian.org_debian_dists_bullseye_main_dep11_Components-amd64.yml.gz'

[...]
# ls -l --dereference-command-line 
/var/lib/app-info/yaml/deb.debian.org_debian_dists_bullseye_main_dep11_Components-amd64.yml.gz
-rw-r--r-- 1 root root 6270308 18. Dez 15:25 
/var/lib/app-info/yaml/deb.debian.org_debian_dists_bullseye_main_dep11_Components-amd64.yml.gz

# appstreamcli refresh-cache --force
[...]

The source of these files is configured in 
/etc/apt/apt.conf.d/50appstream of package appstream and can be read for 
example by:
# apt-get indextargets --format '$(URI) $(FILENAME)' 'Component: main' 
'Identifier: DEP-11'
http://deb.debian.org/debian/dists/bullseye/main/dep11/Components-amd64.yml 
/var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_dep11_Components-amd64.yml.gz


APT can not be configured to download single files of an otherwise 
non-repo like https://appstream.debian.org/data/bullseye/main/ so the 
files have to be integrated somewhere in the repo for APT to get them or 
have to be synced not using APT.


The changelog tells the download via APT is probably done since 2015, 
but how where updates supposed to work?


<<<
appstream (0.9.0-1) unstable; urgency=medium

  * New upstream release: 0.9.0
  * Adjust to libappstream ABI break
  * Enable APT support

 -- Matthias Klumpp   Sat, 12 Dec 2015 18:44:38 +0100
>>>

Bug#903773: closed by Debian FTP Masters (reply to Craig Sanders ) (Bug#903773: fixed in dlocate 1.08)

[Axel Beckert]

Control: reopen -1
Control: found -1 1.09
Control: retitle -1 dlocate: -lsbin doesn't work when awk is mawk, missing 
package relation with gawk
Control: tag -1 + patch

Dear Craig,

Debian Bug Tracking System wrote:
>* Closes: #903773 Can not reproduce

A bug which you can't reproduce has no business to get closed in a
debian/changelog entry!

Please tag such bug reports as "unreproducible" and ask the bug report
for more details (and maybe tag it with "moreinfo" as well).

I still can reproduce this issue — at least on one machine. And I
can't reproduce it on another (and probably never could there). And I
now figured out what's the difference between those two machines:

As you might know, there are two awk implementations in Debian: mawk
and gawk. By default only mawk is installed (and is always there due
to "Priority: required") while gawk is optional (but IIRC default if
installed).

On the system where "dlocate -lsbin" works, the symlinks look like this:

  lrwxrwxrwx 1 root root 21 […] /usr/bin/awk -> /etc/alternatives/awk*
  lrwxrwxrwx 1 root root 13 […] /etc/alternatives/awk -> /usr/bin/gawk*

On the system where "dlocate -lsbin" gives no output, the symlinks
look like this:

  lrwxrwxrwx 1 root root 21 […] /usr/bin/awk -> /etc/alternatives/awk*
  lrwxrwxrwx 1 root root 13 […] /etc/alternatives/awk -> /usr/bin/mawk*

Culprit is this call:

  awk '!/^[^-]/ &&  /^-.{2,8}[xs]/ {print $2}'

mawk doesn't know about {x,y} quantifiers in regular expressions, and
since there is never a { at the second column in the output… Proof:

  $ dlocate -L zsh | xargs -d '\n' -r stat -c '%A %n' | gawk '!/^[^-]/ &&  
/^-.{2,8}[xs]/ {print $2}'
  /bin/zsh
  /bin/zsh5
  /usr/share/bug/zsh
  $ dlocate -L zsh | xargs -d '\n' -r stat -c '%A %n' | mawk '!/^[^-]/ &&  
/^-.{2,8}[xs]/ {print $2}'
  $

So "dlocate -lsbin" doesn't work with Debian's default awk
installation. (And btw. the "!/^[^-]/" is redundant as "/^-…/" is
equivalent.)

So I recommend to replace this gawk-ism with the following much
simpler and POSIX compatible pattern and match it only against the
first column so the quantifiers are no more needed:

  $1 ~ /^-.*[xs]/

Proof:

  $ dlocate -L zsh | xargs -d '\n' -r stat -c '%A %n' | gawk '$1 ~ /^-.*[xs]/ 
{print $2}'
  /bin/zsh
  /bin/zsh5
  /usr/share/bug/zsh
  $ dlocate -L zsh | xargs -d '\n' -r stat -c '%A %n' | mawk '$1 ~ /^-.*[xs]/ 
{print $2}'
  /bin/zsh
  /bin/zsh5
  /usr/share/bug/zsh

This is IMHO the better and cleaner alternative to adding a Depends or
at least Recommends on gawk which — with the current code base — is
clearly missing.

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


signature.asc
Description: PGP signature

Bug#1000892: cvise: diff for NMU version 2.4.0-2.1

[Adrian Bunk]

Control: tags 1000892 + patch
Control: tags 1000892 + pending
Control: tags 1001375 + pending

Dear maintainer,

I've prepared an NMU for cvise (versioned as 2.4.0-2.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru cvise-2.4.0/debian/changelog cvise-2.4.0/debian/changelog
--- cvise-2.4.0/debian/changelog	2021-11-02 16:15:02.0 +0200
+++ cvise-2.4.0/debian/changelog	2021-12-29 22:41:49.0 +0200
@@ -1,3 +1,12 @@
+cvise (2.4.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove stale LLVM 9 build dependencies on armel/armhf.
+(Closes: #1000892)
+  * Recommend colordiff. (Closes: #1001375)
+
+ -- Adrian Bunk   Wed, 29 Dec 2021 22:41:49 +0200
+
 cvise (2.4.0-2) unstable; urgency=medium
 
   * (Build-)depend on python3-chardet.
diff -Nru cvise-2.4.0/debian/control cvise-2.4.0/debian/control
--- cvise-2.4.0/debian/control	2021-11-02 16:14:45.0 +0200
+++ cvise-2.4.0/debian/control	2021-12-29 22:41:49.0 +0200
@@ -15,9 +15,6 @@
   python3-pytest ,
   python3-pytest-flake8 ,
   llvm-13-dev, libclang-13-dev, clang-13, clang-format-13,
-#  llvm-12-dev, libclang-12-dev, clang-12, clang-format-12,
-#  llvm-11-dev [!armel !armhf], libclang-11-dev [!armel !armhf], clang-11 [!armel !armhf], clang-format-11 [!armel !armhf],
-  llvm-9-dev [armel armhf], libclang-9-dev [armel armhf], clang-9 [armel armhf], clang-format-9 [armel armhf],
   unifdef,
 Standards-Version: 4.6.0
 Homepage: https://github.com/marxin/cvise
@@ -26,13 +23,12 @@
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends},
   clang-format-13,
-#  clang-format-11 [!armel !armhf],
-#  clang-format-9 [armel armhf],
   python3,
   python3-chardet,
   python3-pebble,
   python3-psutil,
   unifdef,
+Recommends: colordiff
 Description: super-parallel Python port of the C-Reduce project
  C-Vise is a tool that takes a large C, C++ or OpenCL program that has
  a property of interest (such as triggering a compiler bug) and
diff -Nru cvise-2.4.0/debian/rules cvise-2.4.0/debian/rules
--- cvise-2.4.0/debian/rules	2021-11-02 14:45:41.0 +0200
+++ cvise-2.4.0/debian/rules	2021-12-29 22:41:45.0 +0200
@@ -3,11 +3,6 @@
 
 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
-ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf))
-  CLANG_V=9
-else
-  CLANG_V=11
-endif
 CLANG_V=13
 V=$(shell dpkg-parsechangelog -S Version | sed 's/-.*$$//')
 

Bug#964769: postfix: misleading info in error message "Host or domain name not found[...]"

[Vincent Lefevre]

On 2021-12-29 08:41:53 -0500, Scott Kitterman wrote:
> On Fri, 10 Jul 2020 11:32:18 +0200 Vincent Lefevre  wrote:
> > On 2020-07-10 10:11:38 +0200, Vincent Lefevre wrote:
> > > Package: postfix
> > > Version: 3.5.4-1
> > > Severity: important
> > > 
> > > postfix cannot send mail if IPv6 is local only. In /var/log/mail.log
> > > I've got errors like
> > > 
> > > Jul 10 09:53:22 zira postfix/smtp[865322]: 4C24DC218EE: to=, 
> relay=none, delay=2409, delays=2389/0.03/20/0, dsn=4.4.3, status=deferred 
> (Host or domain name not found. Name service error for name=joooj.vinc17.net 
> type=: Host not found, try again)
> > > 
> > > for several dozens of minutes.
> > 
> > I've eventually found the cause of the issue. First the error message
> > is misleading: this has nothing to do with IPv6 (type=); it should
> > be corrected (I'm cloning this bug as: misleading info in error message
> > "Host or domain name not found[...]").
> 
> That's the error message postfix gets from the DNS resolver, so
> there's really nothing postfix can do about this.

There is. I suppose that postfix attempts an IPv4 connection and an
IPv6 connection, and that the mail is deferred only because *both*
are failing. So postfix should output both error messages.

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

Bug#997948: [Pkg-pascal-devel] Bug#997948: Reassign to fp-units-rtl

[Abou Al Montacir]

The build of winff depends on lc-utils which depend on fpc-abi-3.2 that is a
virtual package provided by fp-units-rtl-3.2 (3.2.0)
As I can not access the build log anymore, I can only make suppositions. And I
suppose that what happened at that time was that fp-units-rtl-3.2 was pulled as
3.2.2 due to the the compiler itself was pulled as fp-compiler-3.2 (3.2.2) and
the compiler have a strict dependency (= 3.2.2) on the rtl packages.

So, even if what happened was not the above supposition, we see that the fpc-abi
is not carrying enough information on the version. I would recommend that it
gets an additional digit or two to solve this issue and other similar issues.

I would recommend then to make the fpc-abi be fpc-abi-3.2.2 for now, and if
happen to patch RTL units so that we change interface, then we use fpc-abi-
3.2.2-n with n: Integer > 0.

What do you think?
-- 
Cheers,
Abou Al Montacir


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

Bug#964762: postfix: sometimes cannot send mail if IPv6 is local only

[Vincent Lefevre]

On 2021-12-29 08:37:30 -0500, Scott Kitterman wrote:
> On Fri, 10 Jul 2020 11:32:18 +0200 Vincent Lefevre  wrote:
> > The real issue is that the postfix service was started before the
> > network at boot time, and in particular the DHCP client. Thus qmgr
> > was using an obsolete /etc/resolv.conf file, copied to its chroot
> > (my machine is a laptop, which was using WiFi, and at the last boot,
> > I was using Ethernet).
> > 
> > There should probably be a script to restart postfix when the DHCP
> > client modifies the /etc/resolv.conf file. This is a bit of a hack,
> > but I don't see ay other solution without modify postfix itself.
> 
> There already is one of these, /etc/resolvconf/update-libc.d/postfix.
> Based on what's shipped in that file and the resolvconf
> documentation [1], it looks to me like that should be doing exactly
> what you want.

I don't have resolvconf installed (it is not installed by default).
If you think that this is the way this should be done, then perhaps
postfix should recommend resolvconf.

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

Bug#997947: [Pkg-pascal-devel] Bug#997947: Bug#997947: Bug#997947: doublecmd FTBFS: Fatal: (10022) Can't find unit ExtCtrls used by uCmdBox

[Abou Al Montacir]

After checking the dependency of fp-units-gtk2-3.2.2, it looks really correct:
# aptitude show fp-units-gtk2-3.2.2
Package: fp-units-gtk2-3.2.2 
Version: 3.2.2+dfsg-1
New: yes
State: installed
Automatically installed: yes
Multi-Arch: same
Priority: optional
Section: devel
Maintainer: Pascal Packaging Team 
Architecture: amd64
Uncompressed Size: 9,008 k
Depends: fp-units-fcl-3.2.2 (= 3.2.2+dfsg-1), fp-units-rtl-3.2.2 (= 
3.2.2+dfsg-1), libgtk2.0-dev
Breaks: fpc (<= 3.2.2+dfsg-0), fpc:i386 (<= 3.2.2+dfsg-0)
Replaces: fpc (<= 3.2.2+dfsg-0), fpc:i386 (<= 3.2.2+dfsg-0)
Provides: fp-units-gtk2
Description: Free Pascal - GTK+ 2.x units

As you can seen the dependency between fp-units-gtk2-3.2.2 and fp-units-rtl-
3.2.2 are strict with very same version. So the package manager should have
installed fp-units-rtl-3.2.2 (= 3.2.2+dfsg-1) in any circumstance.

Unfortunately  I could not find the log of that particular build that failed, so
unless someone can provide these logs, I'll close this ticket in the coming
weeks.
-- 
Cheers,
Abou Al Montacir


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

Bug#1002824: lintian/python3-gitlab: Please feel free to reopen

[Axel Beckert]

Control: reopen -1

Hi Felix,

Felix Lechner wrote:
> Please feel free to reopen this bug if your wishlist items for Lintian
> need more work. Thanks!

Meh, didn't notice that Federico closed the wrong bug with his upload.
Thanks for making me aware of it!

Federico: You closed the bug report against Lintian (#1002824) with
your python-gitlab upload while the bug report against python3-gitlab
(#1002822) is still open.

Maybe next time I should just write three separate bug reports instead
of three in one. Thought it would be more clear that way due to the
relations.

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

Bug#998165: debian-policy: document and allow Description in the source paragraph

[Sean Whitton]

Hello Mattia, Russ,

Thank you both for your input on this.

On Mon 27 Dec 2021 at 09:51PM +01, Mattia Rizzolo wrote:

> In my mind I was mostly focusing on being able to provide a
> **description for the source package** (that is, then, relevant to
> everything that source package builds); said description being picked up
> by a substvar and used again later on is more like a nicety that comes
> after describing the source first.

On Mon 27 Dec 2021 at 01:53PM -08, Russ Allbery wrote:

> Mattia Rizzolo  writes:
>
>> |+When used in a source control file in the general paragraph (i.e., the
>> |+first one, for the source package), the text in this field is used to
>> |+describe the source package itself, and consequently all of the binary
>> |+packages built from itself.
>
> What if we just left off that paragraph entirely?  I'm not sure it's
> adding anything.  The new text would then read:
>
>In a source or binary control file, the ``Description`` field contains a
>description of the package, consisting of two parts, the synopsis or
>the short description, and the long description.
>
> If it's in a source control file, it's a description of the source
> package; if it's in a binary control file, it's a description of the
> binary package.  That seems obvious, so I'm not sure we need to say it
> explicitly.

I had actually been thinking that the only point of a Description: field
in the source package paragraph was for the sake of substituting it into
binary package descriptions.

Could those who have been involved in non-Policy discussions of source
package paragraph Description: fields confirm that the purposes here
really is to add descriptions for source packages, as well as to provide
something to substitute?

Introducing descriptions for source packages seems fine, but I want to
be surer of our intent.

> That said, 5.6.13 currently technically doesn't document Description for a
> source package control file, only for source or binary control files or
> (later, with entirely different syntax) for *.changes files.  Maybe that's
> the root of the problem.  In that case, I think the paragraph we need is:
>
>The ``Description`` fields in source package control files are used to
>construct the ``Description`` fields for the source and binary control
>files when the package is built.  Any ``Description`` field in the
>first paragraph of the source package control file becomes the
>description of the source package for the source binary control file.
>``Description`` fields in subsequent paragraphs become the description
>of the corresponding binary packages.  See deb-substvars(5) for some
>substitution variables that may be useful when writing binary package
>descriptions, such as ``source:Synopsis`` and
>``source:Extended-Description``.

Looks good, once my question above is addressed.

> BTW, I think "3.4 The description of the package" may also need some minor
> updates.  At the least, "Every Debian package" should probably say "Every
> Debian binary package" since I don't think we're requiring source packages
> to have descriptions.  It may also be worth adding a paragraph explaining
> that source packages may have descriptions as well, but are not required
> to.

Right.  I don't think we even want to recommend them at this point.  I
would not like to put any pressure on maintainers to write them.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1002831: ITP: lsb-release-minimal -- minimal shell implementation of lsb_release

[Gioele Barabucci]

On 29/12/21 19:37, Thorsten Glaser wrote:

On Wed, 29 Dec 2021, Gioele Barabucci wrote:


Instead of using LSB packages, this version of `lsb_release` uses the
information in `/etc/os-release`. Nevertheless, the output of this version is


/etc/os-release DOES NOT contain enough information for lsb_release:


It must contain enough info, because the current `lsb_release` does get 
all its information from `/usr/lib/os-release`, see 
https://salsa.debian.org/debian/lsb/-/blob/debian/master/lsb_release.py#L318-358


This behavior hasn't changed in the last 3 years (actually 9 years...)

Please note that the code packaged in this ITP takes into account 
/etc/os-release, /usr/lib/os-release and (now also) $LSB_OS_RELEASE.


Regards,

--
Gioele Barabucci 

Bug#1002844: ITP: luma.emulator -- library provides a series of pseudo-display devices for luma.core

[Anton Gladky]

Package: wnpp
Severity: wishlist
Owner: Anton Gladky 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: luma.emulator
  Version : 1.4.0
  Upstream Author : Richard Hull and contributors
* URL : https://github.com/rm-hull/luma.emulator
* License : MIT/X
  Programming Lang: Python
  Description : library provides a series of pseudo-display devices for 
luma.core

Library provides a series of pseudo-display devices which allow the luma.core
components to be used without running a physical device. These include:
  Real-time (pixel) emulator, based on pygame
  LED matrix and 7-segment renderers
  PNG screen capture
  Animated GIF animator
  Real-time ASCII-art & block emulators

The package will be maintained under the umbrella of Debian Electronics Team.

Regards

Anton

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmHMt9cRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/waVMg//TAca1FBtYrMTxfbSWdLE440GWhR4hkyu
5CUWcXUVXG6drK7czesZUtKupQFmE0FYkoJ9Beft+MntGDEQnCUJI3cFDApoBtuJ
kHTRN7vGY0iSYVFk+DHwksi/ITuEKUYHvgO6NxT4JFPYik0+pWwUPJrx5Tjem9FS
Z1OMBv826Yg3GFfRX5W2XMrPCoRFtyTHpHs/ltXThMXe0LNuuZXIGKn+qWD7EVYI
LHAdRQ7VAv0JpoeN660ap0NB5kLuLKNuwkPhs8awSpxmMG1IlGc42DxrQJpjiMNt
xA97/uaVc6UGtrikhx/SBeHnlHjlZWvK9sXoxWsAyx7BaPvDFfBtU5MGOqerYc0w
73qeVmeu3KBVMPU+wyiVdoADqZJrPEOJx3RJP9XJ3abvFdmoJUBUWsOmGgSz1ZDW
HhZr+2rKYbiwnWCEXXTyYYOHLZoZImdUfPxmT1JnzhokGJSQdmjukbkgZNiUWrSP
RbRK2o5jtSNQmiCy4wbZlG7c5bN0mwTliylUur6y90FJpjdHVAkWaEdLko6TqvFX
p7XhtLac7ZPDxGRC3TTcrRpcuIVp1y1/xLbKaF0dp3BUgYwXo4D0U6YR5WL/jy5k
sRx9jzdKbf9tQsqY93gEewdvnRe1OKyxWuq/UGquwHLvaGO47F5mZacPdRH1Kow4
plRPWlhlTpI=
=15fo
-END PGP SIGNATURE-

Bug#1002831: ITP: lsb-release-minimal -- minimal shell implementation of lsb_release

[Patrice Duroux]

Hi,

Just my 2 cents on that:

> VERSION_ID=unstable

Already in an issue to base-files:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197

> VERSION_CODENAME=sid

Does this have been/have-to-be reported to base-files?

But regarding 'man os-release', they are both optional, isn't it?

Regards,
Patrice

Bug#951284: ITA: zvbi -- Vertical Blanking Interval (VBI) utilities

[Bastian Germann]

Control: retitle -1 ITA: zvbi -- Vertical Blanking Interval (VBI) utilities
Control: owner -1 Ileana Dumitrescu 
Control: block -1 by 1002835

On Wed, 29 Dec 2021 16:10:30 + Ileana Dumitrescu 
 wrote:

I intend to adopt the orphaned package zvbi -- Vertical Blanking Interval (VBI) 
utilities.

Bug#1002831: ITP: lsb-release-minimal -- minimal shell implementation of lsb_release

[Thorsten Glaser]

On Wed, 29 Dec 2021, Gioele Barabucci wrote:

> Instead of using LSB packages, this version of `lsb_release` uses the
> information in `/etc/os-release`. Nevertheless, the output of this version is

/etc/os-release DOES NOT contain enough information for lsb_release:

(sid-amd64)tglase@tglase:~ $ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

I do have a self-written…

$ cat /usr/lib/os-release.sid
PRETTY_NAME="Debian GNU/Linux sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;
VERSION_ID=unstable
VERSION_CODENAME=sid

… which I divert to /usr/lib/os-release (which /etc/os-release is
a symlink to) on some systems, ever since lsb_release broke looking
up the override information from /etc/lsb-release, but the default
file is insufficient ☹

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1002843: RM: node-mbtiles -- ROM; Useless and unmaintained

[Yadd]

Package: ftp.debian.org
Severity: normal

Hi all,

node-sphericalmercator, node-tilelive and node-mbtiles are useless in Debian
and upstrem change their name to @mapbox/tilelive, @mapbox/sphericalmercator 
and @mapbox/mbview. So current versions should be considered as unmaintained.

Debian GIS Project is OK with this removals [1].

Cheers,
Yadd

[1]: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-December/060859.html

Bug#1002837: tiledb: diff for NMU version 1.7.7-1.2

[Dirk Eddelbuettel]

Thank you both for quick thumbs-up!  1.7.7-1.2 was just shipped, fingers
crossed about how it'll do with the builders.

Dirk

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

Bug#1002842: RM: node-tilelive -- ROM; Useless and unmaintained

[Yadd]

Package: ftp.debian.org
Severity: normal

Hi all,

node-sphericalmercator, node-tilelive and node-mbtiles are useless in Debian
and upstrem change their name to @mapbox/tilelive, @mapbox/sphericalmercator 
and @mapbox/mbview. So current versions should be considered as unmaintained.

Debian GIS Project is OK with this removals [1].

Cheers,
Yadd

[1]: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-December/060859.html

Bug#1002841: RM: node-sphericalmercator -- ROM; Useless and unmaintained

[Yadd]

Package: ftp.debian.org
Severity: normal

Hi all,

node-sphericalmercator, node-tilelive and node-mbtiles are useless in Debian
and upstrem change their name to @mapbox/tilelive, @mapbox/sphericalmercator
and @mapbox/mbview. So current versions should be considered as unmaintained.

Debian GIS Project is OK with this removals [1].

Cheers,
Yadd

[1]: 
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-December/060859.html

Bug#1002840: gnome-software: screenshot URLs never update new DEP-11/appstream-data and fail HTTP 404

[Jano John Akim Franke]

Package: gnome-software
Version: 3.38.1-1
Severity: normal
X-Debbugs-Cc: debian@jjaf.de

Dear Maintainer,


   * What led up to the situation?
Opening gnome-software showed "Unsere Empfehlungen" (en: recommendation) for 
applications "Builder". When selected all screenshots fail with "Bildschirmfoto 
nicht gefunden". Builder is just an example. It also applies to other 
applications.

   * What outcome did you expect instead?
Screenshots should be displayed.

I tracked it down to the usage of the following file which has a date 
2021-08-08:
16:48:20:0682 XbSilo compiling 
/var/lib/app-info/yaml/deb.debian.org_debian_dists_bullseye_main_dep11_Components-amd64.yml.gz:ctime=1640794691.680796:func-id=AddIcons@2:func-id=AppStreamUpgrade2@3:func-id=AddOriginKeyword@1:scope=system:filename=/var/lib/app-info/yaml/deb.debian.org_debian_dists_bullseye_main_dep11_Components-amd64.yml.gz…
$ ls -l --dereference-command-line 
/var/lib/app-info/yaml/deb.debian.org_debian_dists_bullseye_main_dep11_Components-amd64.yml.gz
-rw-r--r-- 1 root root 6213469  8. Aug 10:16 
/var/lib/app-info/yaml/deb.debian.org_debian_dists_bullseye_main_dep11_Components-amd64.yml.gz

All resized images in this fail:
$ wget --no-verbose --spider --input-file=<(appstreamcli dump 
org.gnome.Builder.desktop | grep image | egrep --only-matching 'https?://[^<]*')
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-1_1248x702.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-1_752x423.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-1_624x351.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-1_224x126.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
2021-12-29 19:01:08 URL: 
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-1_orig.png
 200 OK
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-2_1248x702.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-2_752x423.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-2_624x351.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-2_224x126.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
2021-12-29 19:01:08 URL: 
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-2_orig.png
 200 OK
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-3_1248x702.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-3_752x423.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-3_624x351.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-3_224x126.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
2021-12-29 19:01:09 URL: 
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-3_orig.png
 200 OK
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-4_1248x702.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-4_752x423.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!
https://appstream.debian.org/media/bullseye/org/gnome/Builder.desktop/80ccb2db1c02d5a6749463723e614f20/screenshots/image-4_624x351.png:
Die Datei auf dem Server existiert nicht -- Verweis ist nicht gültig!

Bug#1002837: tiledb: diff for NMU version 1.7.7-1.2

[Utkarsh Gupta]

Hi Dirk,

On Wed, Dec 29, 2021 at 10:59 PM Dirk Eddelbuettel  wrote:
> Thanks for the *very* prompt response. I may still wait a day or two to also
> hear from Utkarsh who last NMUed.

+1 to what Adam said. Please upload directly, thanks for asking. :D

For the backstory, I was just a sponsor-er to Adam for src:tiledb and
did an NMU for a source-only upload to help it migrate but it got
blocked later. :/


- u

Bug#1002837: tiledb: diff for NMU version 1.7.7-1.2

[Dirk Eddelbuettel]

Hi Adam,

On 29 December 2021 at 17:51, Adam Cecile wrote:
| Hello Dirk,
| 
| You're obviously a person of choice to perform any change on tiledb so please 
go ahead for a non-delayed upload !

Thanks for the *very* prompt response. I may still wait a day or two to also
hear from Utkarsh who last NMUed.

Do you still use the package?  If so, do you need hdfs?  I wouldn't mind
upgrading to release 2.5.3 which is current and turning on a feature or two
but I was getting some noise from the unit tests in non-vanilla mode so may
hold off.

Best,  Dirk

| Regards, Adam.
| 
| On December 29, 2021 5:42:33 PM GMT+01:00, Dirk Eddelbuettel 
 wrote:
| >Package: tiledb
| >Version: 1.7.7-1.1
| >Severity: normal
| >Tags: patch  pending
| >
| >Dear maintainer,
| >
| >I have prepared an NMU for tiledb (versioned as 1.7.7-1.2) and
| >can uploaded it to DELAYED/10. Please feel free to tell me if I
| >should delay it longer.
| >
| >In the NMU, I propose to not package tiledb-doc (sphinx bombs on me)
| >and to not package the hdfs extension to have a more miminal package
| >with a chance to build on all platforms which 1.7.7-1 and 1.7.7-1.1 
| >have trouble with.
| >
| >Regards, Dirk
| >
| >-- 
| >https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Bug#1002738: redis-server: Default systemd unit file system protection settings prevent writing of logfiles, crashing redis

[Chris Lamb]

Hi,

>> Ah, perhaps your version of systemd is newer? 
> I am running systemd 247.3-6 on the affected systems, but Kernel
> 5.15.8-1-default. On Kernel 5.14 and older it seems to work fine.
[..]
> My only guess is that it's some issue with (Kernel) namespaces either
> on my System specifically or with Kernel 5.15 in general.

Hm, which makes me think the bug is elsewhere and not in the Redis
systemd unit. Unless I'm missing something, the configuration
directives used here should 'just work'. Or rather: you are likely to
encounter (or are already encountering!) other breakages on your system
if this is not working.

Thoughts?

Chris

ps. I assume you are using bullseye? (redis 6.0.15-1 is the version
available there)

Bug#1002839: default clearances are set to a compiled in value

[Johann Klammer]

Package: pcb-lesstif
Version: 20140316-3



Hello,

I was just trying to get a layout ready to fab with a boardhouse and tried to 
get the defaults for polygon and solder mask clearance adjusted. 

I was using some old style footprints without the Pin clearances specified.
> Pin(25 42 40 24 "1" 0x101)

As it turns out this is not possible through the settings file. The program 
just assumes something. After some digging in the source file, I found:

parse_y.y:1605
> 2*GROUNDPLANEFRAME
> 2*MASKFRAME

a header.. globalconst.h
> /* ---
>  * frame between the groundplane and the copper
>  */
> #define GROUNDPLANEFRAMEMIL_TO_COORD(15)
> #define MASKFRAME   MIL_TO_COORD(3)

The obvious workaround is to change all the footprints manually, but parameters 
change from bardhouse to boardhouse. There are no sane defaults.

Is it possible to have those read from the settings file?

Johann

Bug#1002782: libconfig-model-backend-augeas-perl: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255

[Dominique Dumont]

On Tuesday, 28 December 2021 21:16:18 CET you wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Ack. These tests are broken by augeas 1.13.0.

I'll fix this upstream.

Thanks for the report.

Dod

Bug#1002838: pdfarranger: Error "Can't convert ObjectHelper" when saving

[Erich Schubert]

Package: pdfarranger
Version: 1.8.0-1
Severity: important

When trying to join multiple PDF using pdfarranger, I get the following 
error

when trying to save the result:

Can't convert ObjectHelper to Object (or subclass) implicitly.
Use .obj to get access to the underlying object.

As this looks like a programmer error message, maybe some dependency has
changed, and ".obj" needs to be inserted somewhere in the code?


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to de_DE.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 pdfarranger depends on:
ii gir1.2-glib-2.0 1.70.0-2
ii gir1.2-gtk-3.0 3.24.31-1
ii gir1.2-poppler-0.18 21.11.0-1
ii python3 3.9.8-1
ii python3-cairo 1.20.1-3
ii python3-dateutil 2.8.1-6
ii python3-gi 3.42.0-3
ii python3-gi-cairo 3.42.0-3
ii python3-pikepdf 4.2.0+dfsg-1
ii python3-pkg-resources 59.6.0-1

Versions of packages pdfarranger recommends:
ii python3-img2pdf 0.4.2-1

pdfarranger suggests no packages.

-- no debconf information

Bug#1002837: tiledb: diff for NMU version 1.7.7-1.2

[Adam Cecile]

Hello Dirk,

You're obviously a person of choice to perform any change on tiledb so please 
go ahead for a non-delayed upload !

Regards, Adam.

On December 29, 2021 5:42:33 PM GMT+01:00, Dirk Eddelbuettel  
wrote:
>Package: tiledb
>Version: 1.7.7-1.1
>Severity: normal
>Tags: patch  pending
>
>Dear maintainer,
>
>I have prepared an NMU for tiledb (versioned as 1.7.7-1.2) and
>can uploaded it to DELAYED/10. Please feel free to tell me if I
>should delay it longer.
>
>In the NMU, I propose to not package tiledb-doc (sphinx bombs on me)
>and to not package the hdfs extension to have a more miminal package
>with a chance to build on all platforms which 1.7.7-1 and 1.7.7-1.1 
>have trouble with.
>
>Regards, Dirk
>
>-- 
>https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1002824: lintian/python3-gitlab: Please feel free to reopen

[Felix Lechner]

Hi Alex,

Please feel free to reopen this bug if your wishlist items for Lintian
need more work. Thanks!

Kind regards
Felix Lechner

Bug#1002837: tiledb: diff for NMU version 1.7.7-1.2

[Dirk Eddelbuettel]

Package: tiledb
Version: 1.7.7-1.1
Severity: normal
Tags: patch  pending

Dear maintainer,

I have prepared an NMU for tiledb (versioned as 1.7.7-1.2) and
can uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

In the NMU, I propose to not package tiledb-doc (sphinx bombs on me)
and to not package the hdfs extension to have a more miminal package
with a chance to build on all platforms which 1.7.7-1 and 1.7.7-1.1 
have trouble with.

Regards, Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
diff -Nru tiledb-1.7.7/debian/changelog tiledb-1.7.7/debian/changelog
--- tiledb-1.7.7/debian/changelog	2021-02-04 10:46:36.0 -0600
+++ tiledb-1.7.7/debian/changelog	2021-12-29 09:55:15.0 -0600
@@ -1,10 +1,19 @@
+tiledb (1.7.7-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Turn hdfs off for a more minimal build, also remove sphinx
+  * debian/control: Remove Build-Depends: on hdfs
+  * debian/control: Set Standards-Version: 2.6.0
+
+ -- Dirk Eddelbuettel   Wed, 29 Dec 2021 09:55:15 -0600
+
 tiledb (1.7.7-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
   * Source-only upload for migration.
 
  -- Utkarsh Gupta   Thu, 04 Feb 2021 22:16:36 +0530
-
+ 
 tiledb (1.7.7-1) unstable; urgency=medium
 
   * Initial release (Closes: #951122).
diff -Nru tiledb-1.7.7/debian/control tiledb-1.7.7/debian/control
--- tiledb-1.7.7/debian/control	2021-02-04 10:46:13.0 -0600
+++ tiledb-1.7.7/debian/control	2021-12-29 09:55:15.0 -0600
@@ -17,15 +17,13 @@
  clang-format,
  chrpath,
 # help2man,
-# Required to test the HDFS extension, see
- default-jre-headless  | default-jre ,
  catch ,
- python3 , python3-sphinx , python3-sphinx-rtd-theme , python3-breathe ,
-Standards-Version: 4.5.0
+# python3 , python3-sphinx , python3-sphinx-rtd-theme , python3-breathe ,
+Standards-Version: 4.6.0
 Section: libs
 Homepage: https://tiledb.com/
-Vcs-Browser: https://salsa.debian.org/acecile-guest/tiledb
-Vcs-Git: https://salsa.debian.org/acecile-guest/tiledb.git
+Vcs-Browser: https://salsa.debian.org/debian/tiledb
+Vcs-Git: https://salsa.debian.org/debian/tiledb.git
 Rules-Requires-Root: no
 
 Package: libtiledb-dev
@@ -76,17 +74,17 @@
 # .
 # This package contains command line utility.
 
-Package: libtiledb-doc
-Build-Profiles: 
-Architecture: all
-Section: doc
-Depends: ${sphinxdoc:Depends}, ${misc:Depends}
-Description: Store and access very large multi-dimensional array data (documentation)
- TileDB allows you to store and access very large multi-dimensional array
- data, the data currency of Data Science.
- .
- It is a powerful storage engine that introduces a novel format that can
- effectively store both dense and sparse array data with support for fast
- updates and reads.
- .
- This package contains the documentation.
+# Package: libtiledb-doc
+# Build-Profiles: 
+# Architecture: all
+# Section: doc
+# Depends: ${sphinxdoc:Depends}, ${misc:Depends}
+# Description: Store and access very large multi-dimensional array data (documentation)
+#  TileDB allows you to store and access very large multi-dimensional array
+#  data, the data currency of Data Science.
+#  .
+#  It is a powerful storage engine that introduces a novel format that can
+#  effectively store both dense and sparse array data with support for fast
+#  updates and reads.
+#  .
+#  This package contains the documentation.
diff -Nru tiledb-1.7.7/debian/rules tiledb-1.7.7/debian/rules
--- tiledb-1.7.7/debian/rules	2021-02-04 10:46:13.0 -0600
+++ tiledb-1.7.7/debian/rules	2021-12-29 09:55:15.0 -0600
@@ -18,11 +18,11 @@
 endif
 
 %:
-ifeq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
-	dh $@ --with sphinxdoc
-else
+#ifeq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
+#	dh $@ --with sphinxdoc
+#else
 	dh $@
-endif
+#endif
 
 override_dh_auto_clean:
 	dh_auto_clean
@@ -38,19 +38,20 @@
 	  -DTILEDB_WERROR=0 \
 	  -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) \
 	  -DTILEDB_S3=0 \
-	  -DTILEDB_HDFS=1 \
+	  -DTILEDB_HDFS=0 \
 	  -DTILEDB_TOOLS=0 \
+	  -DCMAKE_INSTALL_PREFIX=/usr \
 	  $(CMAKE_TEST_ARG)
 
 override_dh_auto_build:
 	dh_auto_build
-ifeq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
-	$(MAKE) -C obj-$(DEB_BUILD_GNU_TYPE) doc
-	mkdir -p $(CURDIR)/build
-	mv obj-$(DEB_BUILD_GNU_TYPE)/xml $(CURDIR)/build/
-	PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml doc/source/ build/html
-	rm -rf build/html/.doctrees
-endif
+#ifeq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)
+#	$(MAKE) -C obj-$(DEB_BUILD_GNU_TYPE) doc
+#	mkdir -p $(CURDIR)/build
+#	mv obj-$(DEB_BUILD_GNU_TYPE)/xml $(CURDIR)/build/
+#	PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml doc/source/ build/html
+#	rm -rf build/html/.doctrees
+#endif
 
 override_dh_auto_test:
 ifeq ($(filter nocheck,$(DEB_BUILD_PROFILES)),)

Bug#1002832: cinnamon delays shutdown

[Fabio Fantoni]

Il 29/12/2021 17:15, Jeffrey Ratcliffe ha scritto:

Package: cinnamon
Version: 5.0.6-1
Severity: normal

Dear Maintainer,


I try to shutdown the PC.

* What was the outcome of this action?

I get the error message: "A stop job is running for session 2 of user "

The shutdown process then waits 90s before continuing.

sudo journalctl -b-1

shows the following entries:

Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Stopping timed out.
Killing.
Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Killing process 7577
(cinnamon-launch) with signal SIGKILL.
Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Killing process 7623
(gdbus) with signal SIGKILL.
Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Failed with result
'timeout'.

A workaround is to logout first, and then shutdown from the log-in screen.

* What outcome did you expect instead?

The shutdown process to proceed immediately.

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

thanks for report, this issue was already reported by others users here: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996668


I din't found the exact cause but on one testing vm where I repoduced it 
the bug disappaired after 5.2 packages install, 5.2 packages are ready 
for upload to experimental for weeks but I was unable to find someone 
that can upload them: 
https://lists.debian.org/debian-mentors/2021/12/msg00082.html


if you want do a fast test with them you can install the packages I did 
for testing (on 
http://debomatic-amd64.debian.net/distribution#dpr-cinnamon-unstable), 
you can find istruction here: 
https://lists.debian.org/debian-cinnamon/2021/12/msg6.html




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi

On Wed, Dec 29, 2021 at 02:36:14PM +0100, Harald Dunkel wrote:
> Package: nfs-common
> Version: 1:1.3.4-6
> 
> systemd moans about krb5.keytab at boot time
> 
> ```
> # systemctl --failed
>   UNITLOAD   ACTIVE SUBDESCRIPTION
> * rpc-svcgssd.service loaded failed failed RPC security service for NFS server
> 
> LOAD   = Reflects whether the unit definition was properly loaded.
> ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
> SUB= The low-level unit activation state, values depend on unit type.
> 1 loaded units listed.
> 
> # systemctl status rpc-svcgssd
> * rpc-svcgssd.service - RPC security service for NFS server
>  Loaded: loaded (/etc/systemd/system/rpc-svcgssd.service; static)
>  Active: failed (Result: exit-code) since Wed 2021-12-29 14:00:51 CET; 
> 8min ago
> Process: 301 ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS (code=exited, 
> status=1/FAILURE)
> CPU: 6ms
> 
> Dec 29 14:00:50 nfs00.example.com systemd[1]: Starting RPC security service 
> for NFS server...
> Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: ERROR: GSS-API: error in 
> gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may 
> provide more information) - No key table entry found matching nfs/@
> Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: unable to obtain root 
> (machine) credentials
> Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: do you have a keytab 
> entry for nfs/@ in /etc/krb5.keytab?
> Dec 29 14:00:51 nfs00.example.com systemd[1]: rpc-svcgssd.service: Control 
> process exited, code=exited, status=1/FAILURE
> Dec 29 14:00:51 nfs00.example.com systemd[1]: rpc-svcgssd.service: Failed 
> with result 'exit-code'.
> Dec 29 14:00:51 nfs00.example.com systemd[1]: Failed to start RPC security 
> service for NFS server.
> ```
> 
> Shouldn't svcgssd either exit silently with 0 or become optional? Looking at
> nfs(5) Kerberos authentication for NFS appears to be optional, regardless if
> there is a keytab file with or without NFS credentials.

The rpc-svcgssd.service already has some conditionals:

ConditionPathExists=|!/run/gssproxy.pid
ConditionPathExists=|!/proc/net/rpc/use-gss-proxy
ConditionPathExists=/etc/krb5.keytab

If no /etc/krb5.keytab exists in fact the status will be

○ rpc-svcgssd.service - RPC security service for NFS server
 Loaded: loaded (/usr/lib/systemd/system/rpc-svcgssd.service; static)
 Active: inactive (dead)
  Condition: start condition failed at Tue 2021-12-21 10:28:53 CET; 1 week 1 
day ago

If you have a /etc/krb5.keytab then the condition is met to try to start
rpc-svcgssd.

Regards,
Salvatore

Bug#1002725: evince: printing broken as apparmor denies access to pxgsettings

[Mike Ayers]

Under GNOME desktop evince will print for me in my testing system.

Under Cinnamon evince will hang when I bring up the print dialog.

The following patch seems to help:
--- /etc/apparmor.d/usr.bin.evince- 2021-11-21 13:03:23.0 -0500
+++ /etc/apparmor.d/usr.bin.evince    2021-12-29 11:26:26.187865562 -0500
@@ -67,6 +67,7 @@
   /usr/bin/pcmanfm Cx -> sanitized_helper,  # LXDE
   /usr/bin/krusader Cx -> sanitized_helper, # KDE
   /usr/bin/thunar Cx -> sanitized_helper,   # XFCE
+  /usr/lib/x86_64-linux-gnu/libproxy/0.4.17/pxgsettings Cx -> 
sanitized_helper, # Print Dialog


   # For Xubuntu to launch the browser
   #include 

Bug#1002829: please document how to set nfsv4gracetime and nfsv4leasetime

[Salvatore Bonaccorso]

Source: nfs-utils
Source-Version: 1:2.5.4-1~exp5

Hi,

On Wed, Dec 29, 2021 at 04:53:52PM +0100, Harald Dunkel wrote:
> Package: nfs-kernel-server
> Version: 1:1.3.4-6
> 
> I would like to reduce nfsv4gracetime and nfsv4leasetime from 90 sec
> to something reasonable. Looking through several scripts and systemd
> config files I figured out that I have to set
> 
>   RPCNFSDOPTS
> 
> in /etc/default/nfs-server.conf to make a helper script (called by
> a systemd service) generate another config file in /run setting a
> variable
> 
>   RPCNFSDARGS
> 
> which is then read by the nfs-kernel service to construct the
> rpc.nfsd command line.
> 
> I am quite sure that this construct is not "Debian quality". Could
> you please cleanup this mess for bookworm and improve the
> documentation?
> 
> Thank you very much

I believe this is much better in the 1:2.5.4-1~exp5 where we follow
the upstream introduction of /etc/nfs.conf which has (commented)
settings for the default values for grace-time and lease-time.

We highly would appreciate if this version is tested, before we move
it to unstable, and make it ready for bookworm.

If you think the nfs.conf(5) manpage needs any further improvements,
can you submit those to upstream? We want in future to as less as
possible diverge in the nfs-utils package from upstream, which was as
well part of the cause we lacked behind upstream. In experimental we
now are on track again with upstream, but are not yet ready to move
the version into unstable/testing.

Regards,
Salvatore

Bug#1002834: bugs.debian.org: radeon /dri3/composer vsync/ no browser works/ menu software quits

[meh]

Package: bugs.debian.org
Severity: important
X-Debbugs-Cc: inqu...@babyawacs.com

Dear Maintainer,

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

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

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

Debian is unusable with Radeon any form of gpu acceleration

The problem is between Radeon glamor DRI3, composers vsynch/  xrender glx

no browser works  instant crash any tab firefox , epiphany invisible websites
but preview brackets show a foto

dri3 glamor does not launch libreoffice

ANY DRI or DRIVER: menu software quits after clicking one of the bottom choices
extensions etc


all runs only because itis lightdm xfce
in wayland and gdm3 it would freeze
before login

*
a simple mismatch of desktop renderer with obsolete drivers ?

all maybe simpler to fix if itis a   set of

mismatching actuality
*


allthebest!
Dec 26 21:28:43 systemd: Reached target Exit the Session.
Dec 26 21:28:43 tracker-miner-f: OK
Dec 26 21:28:43 systemd: Stopped Virtual filesystem metadata service.
Dec 26 21:28:43 tracker-store: OK
Dec 26 21:28:43 systemd: evolution-source-registry.service: Succeeded.
Dec 26 21:28:43 xdg-desktop-por: Caught PipeWire error: connection error
Dec 26 21:28:43 pipewire-media-: error id:0 seq:191 res:-32 (Broken pipe): 
connection error
Dec 26 21:28:43 systemd: Stopping Virtual filesystem service - disk device 
monitor...
Dec 26 21:28:43 gvfsd: A connection to the bus can't be made
Dec 26 21:28:41 systemd: thunar.service: Failed with result 'exit-code'.
Dec 26 21:28:41 at-spi2-registr: X connection to :0 broken (explicit kill or 
server shutdown).
Dec 26 21:19:00 systemd: gnome-terminal-server.service: Consumed 1.720s CPU 
time.
Dec 26 21:18:54 sudo: pam_unix(sudo:session): session closed for user root
Dec 26 21:17:59 systemd: Started VTE child process 1374 launched by 
gnome-terminal-server process 1326.
Dec 26 21:17:58 dbus-daemon: [session uid=1000 pid=779] Successfully activated 
service 'org.gnome.Terminal'
Dec 26 21:17:57 systemd: Starting GNOME Terminal Server...
Dec 26 21:17:57 dbus-daemon: [session uid=1000 pid=779] Activating via systemd: 
service name='org.gnome.Terminal' unit='gnome-terminal-server.service' 
requested by ':1.81' (uid=1000 pid=1314 comm="gnome-terminal --wait ")
Dec 26 21:17:47 gsf-office-thum: error: The metadata does not have a thumbnail 
property
Dec 26 21:17:45 xdg-desktop-por: Failed to get application states: 
GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list
Dec 26 21:17:39 systemd: Started Virtual filesystem metadata service.
Dec 26 21:17:39 dbus-daemon: [session uid=1000 pid=779] Successfully activated 
service 'org.gtk.vfs.Metadata'
Dec 26 21:17:39 systemd: Starting Virtual filesystem metadata service...
Dec 26 21:17:39 dbus-daemon: [session uid=1000 pid=779] Activating via systemd: 
service name='org.gtk.vfs.Metadata' unit='gvfs-metadata.service' requested by 
':1.44' (uid=1000 pid=1041 comm="xfdesktop --display :0.0 --sm-client-id 
218630644-")
Dec 26 21:17:39 systemd: Startup finished in 30.986s.
Dec 26 21:17:38 dbus-daemon: [session uid=1000 pid=779] Successfully activated 
service 'org.xfce.FileManager'
Dec 26 21:17:38 systemd: Started Tracker metadata database store and lookup 
manager.
Dec 26 21:17:38 dbus-daemon: [session uid=1000 pid=779] Successfully activated 
service 'org.freedesktop.Tracker1'
Dec 26 21:17:38 systemd: Starting Tracker metadata database store and lookup 
manager...
Dec 26 21:17:38 dbus-daemon: [session uid=1000 pid=779] Activating via systemd: 
service name='org.freedesktop.Tracker1' unit='tracker-store.service' requested 
by ':1.75' (uid=1000 pid=1106 comm="/usr/libexec/tracker-miner-fs ")
Dec 26 21:17:37 systemd: Starting Thunar file manager...
Dec 26 21:17:37 dbus-daemon: [session uid=1000 pid=779] Activating via systemd: 
service name='org.xfce.FileManager' unit='thunar.service' requested by ':1.44' 
(uid=1000 pid=1041 comm="xfdesktop --display :0.0 --sm-client-id 218630644-")
Dec 26 21:17:37 tumblerd: Registered thumbnailer 
/usr/bin/gdk-pixbuf-thumbnailer -s %s %u %o
Dec 26 21:17:36 gst-plugin-scan: r300: driver missing
Dec 26 21:17:35 systemd: Started Evolution address book service.
Dec 26 21:17:35 dbus-daemon: [session uid=1000 pid=779] Successfully activated 
service 'org.gnome.evolution.dataserver.AddressBook10'
Dec 26 21:17:35 systemd: Starting Evolution address book service...
Dec 26 21:17:35 dbus-daemon: [session uid=1000 pid=779] Activating via systemd: 
service name='org.gnome.evolution.dataserver.AddressBook10' 
unit='evolution-addressbook-factory.service' requested by ':1.73' (uid=1000 
pid=1194 comm="/usr/libexec/evolution-calendar-factory ")
Dec 26 21:17:35 systemd: Started Evolution calendar service.
Dec 26 21:17:35 dbus-daemon: 

Bug#1002054: getmail: regression after uprading to buster

[Sudip Mukherjee]

Hi,

On Tue, Dec 21, 2021 at 1:33 AM Dal Blazej  wrote:
>
> Package: getmail
> Version: 6.14-1
> Severity: normal
> X-Debbugs-Cc: dal-bla...@onenetbeyond.org
>
> Dear Maintainer,
>
> getmail used to have a /usr/bin/getmails command. It scanned the .getmail 
> directory
> to look for all configurations available and then get the mails.
>
> After upgrading to buster this command dirapeared. I have only 
> /usr/bin/getmail --without the s.

I think you meant to say "after upgrading to Bullseye".
Can you please install the package from "bullseye-backports"..
Previously it used to be a Debian specific wrapper for getmail, which
was removed when getmail was upgraded to getmail6. But getmail6
upstream has now added it in the source and so its available as part
of getmail6.

-- 
Regards
Sudip

Bug#1002832: cinnamon delays shutdown

[Jeffrey Ratcliffe]

Package: cinnamon
Version: 5.0.6-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I worked normally with the PC

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

I try to shutdown the PC.

   * What was the outcome of this action?

I get the error message: "A stop job is running for session 2 of user "

The shutdown process then waits 90s before continuing.

sudo journalctl -b-1

shows the following entries:

Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Stopping timed out.
Killing.
Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Killing process 7577
(cinnamon-launch) with signal SIGKILL.
Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Killing process 7623
(gdbus) with signal SIGKILL.
Dec 28 19:29:14 saturn systemd[1]: session-2.scope: Failed with result
'timeout'.

A workaround is to logout first, and then shutdown from the log-in screen.

   * What outcome did you expect instead?

The shutdown process to proceed immediately.

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


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

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

Versions of packages cinnamon depends on:
ii  cinnamon-common  5.0.6-1
ii  cinnamon-control-center  5.0.2-2
ii  cinnamon-desktop-data5.0.0-2
ii  cinnamon-screensaver 5.0.7-1
ii  cinnamon-session 5.0.1-3
ii  cinnamon-settings-daemon 5.0.4-2
ii  cjs  5.0.0-2
ii  cups-pk-helper   0.2.6-1+b1
ii  dbus 1.12.20-3
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  gir1.2-accountsservice-1.0   0.6.55-3
ii  gir1.2-caribou-1.0   0.4.21-7.2
ii  gir1.2-clutter-1.0   1.26.4+dfsg-2
ii  gir1.2-cmenu-3.0 5.0.0-2
ii  gir1.2-cogl-1.0  1.22.8-3
ii  gir1.2-cvc-1.0   5.0.0-2
ii  gir1.2-gdkpixbuf-2.0 2.42.6+dfsg-2
ii  gir1.2-gkbd-3.0  3.26.1-1+b1
ii  gir1.2-glib-2.0  1.70.0-2
ii  gir1.2-gnomedesktop-3.0  41.2-1
ii  gir1.2-gtk-3.0   3.24.30-4
ii  gir1.2-gtkclutter-1.01.8.4-4+b1
ii  gir1.2-keybinder-3.0 0.3.2-1.1
ii  gir1.2-nemo-3.0  5.0.5-1
ii  gir1.2-nm-1.01.32.12-1
ii  gir1.2-nma-1.0   1.8.32-1
ii  gir1.2-notify-0.70.7.9-3
ii  gir1.2-pango-1.0 1.48.10+ds1-1
ii  gir1.2-polkit-1.00.105-31
ii  gir1.2-soup-2.4  2.74.2-1
ii  gir1.2-timezonemap-1.0   0.4.6-2+b1
ii  gir1.2-upowerglib-1.00.99.13-1
ii  gir1.2-xapp-1.0  2.2.4-1
ii  gkbd-capplet 3.26.1-1+b1
ii  gnome-backgrounds41.0-1
ii  gnome-themes-extra   3.28-1
ii  gsettings-desktop-schemas41.0-2
ii  iso-flags-png-320x2401.0.2-1.1
ii  libatk-bridge2.0-0   2.38.0-2
ii  libatk1.0-0  2.36.0-3
ii  libc62.33-1
ii  libcairo21.16.0-5
ii  libcinnamon-desktop4 5.0.0-2
ii  libcinnamon-menu-3-0 5.0.0-2
ii  libcjs0  5.0.0-2
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libgirepository-1.0-11.70.0-2
ii  libgl1   1.3.4-2+b1
ii  libglib2.0-0 2.70.2-1
ii  libglib2.0-bin   2.70.2-1
ii  libgstreamer1.0-01.18.5-1
ii  libgtk-3-0   3.24.30-4
ii  libmuffin0   5.0.2-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1
ii  libstartup-notification0 0.12-6+b1
ii  

Bug#830303: mmc0: Unexpected interrupt 0x04000000.

[bakhelit]

I tested multiple SD cards in my laptop (Acer Aspire V3-571G) card 
reader (Broadcom Limited BCM57765/57785). My system uses mostly Debian 
10 packages with a few packages from backports (mainly kernel image, 
systemd, emacs and their dependencies):


kernel: Linux version 5.10.0-0.bpo.9-amd64 
(debian-ker...@lists.debian.org) (gcc-8 (Debian 8.3.0-6) 8.3.0, GNU ld 
(GNU Binutils for Debian) 2.31.1) #1 SMP Debian 5.10.70-1~bpo10+1 
(2021-10-10)


The workaround mentioned above also works on my system. I created the 
"/etc/modprobe.d/sdhci.conf" file containing "options sdhci 
debug_quirks2=0x4" and had to regenerate initrd images using "sudo 
update-initramfs -u -k all".


SAMSUNG EVO 64GB MICRO SDXC CARD (DOESN'T WORK WITHOUT THE WORKAROUND) - 
SYSTEMD JOURNALD - Relevant messages:

kernel: mmc0: new ultra high speed SDR104 SDXC card at address 0001
kernel: mmcblk0: mmc0:0001 EC2QT 59.6 GiB
kernel: mmc0: Timeout waiting for hardware interrupt.
kernel: mmc0: sdhci:  SDHCI REGISTER DUMP ===
kernel: mmc0: sdhci: Sys addr:  0x10c8 | Version:  0x1502
kernel: mmc0: sdhci: Blk size:  0x7200 | Blk cnt:  0x
kernel: mmc0: sdhci: Argument:  0x | Trn mode: 0x003b
kernel: mmc0: sdhci: Present:   0x1fff | Host ctl: 0x001f
kernel: mmc0: sdhci: Power: 0x000f | Blk gap:  0x
kernel: mmc0: sdhci: Wake-up:   0x | Clock:0x0007
kernel: mmc0: sdhci: Timeout:   0x000a | Int stat: 0x
kernel: mmc0: sdhci: Int enab:  0x03ff008b | Sig enab: 0x03ff008b
kernel: mmc0: sdhci: ACmd stat: 0x | Slot int: 0x
kernel: mmc0: sdhci: Caps:  0x176ec8b0 | Caps_1:   0x03002177
kernel: mmc0: sdhci: Cmd:   0x123a | Max curr: 0x
kernel: mmc0: sdhci: Resp[0]:   0x0900 | Resp[1]:  0x0900
kernel: mmc0: sdhci: Resp[2]:   0x0900 | Resp[3]:  0x0900
kernel: mmc0: sdhci: Host ctl2: 0x804b
kernel: mmc0: sdhci: ADMA Err:  0x0001 | ADMA Ptr: 0x000120943204
kernel: mmc0: sdhci: 
kernel: mmc0: Unexpected interrupt 0x0400.
kernel: mmc0: sdhci:  SDHCI REGISTER DUMP ===
kernel: mmc0: sdhci: Sys addr:  0x | Version:  0x1502
kernel: mmc0: sdhci: Blk size:  0x7200 | Blk cnt:  0x
kernel: mmc0: sdhci: Argument:  0x | Trn mode: 0x0033
kernel: mmc0: sdhci: Present:   0x1fff | Host ctl: 0x001f
kernel: mmc0: sdhci: Power: 0x000f | Blk gap:  0x
kernel: mmc0: sdhci: Wake-up:   0x | Clock:0x0007
kernel: mmc0: sdhci: Timeout:   0x000a | Int stat: 0x
kernel: mmc0: sdhci: Int enab:  0x03ff008b | Sig enab: 0x03ff008b
kernel: mmc0: sdhci: ACmd stat: 0x | Slot int: 0x
kernel: mmc0: sdhci: Caps:  0x176ec8b0 | Caps_1:   0x03002177
kernel: mmc0: sdhci: Cmd:   0x0d1a | Max curr: 0x
kernel: mmc0: sdhci: Resp[0]:   0x00400900 | Resp[1]:  0x
kernel: mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
kernel: mmc0: sdhci: Host ctl2: 0x800b
kernel: mmc0: sdhci: ADMA Err:  0x0001 | ADMA Ptr: 0x000120943204
kernel: mmc0: sdhci: 

SAMSUNG EVO 64GB MICRO SDXC CARD (WORKS WITH THE WORKAROUND) - SYSTEMD 
JOURNALD - Relevant messages:

kernel: mmc0: new high speed SDXC card at address 0001
kernel: mmcblk0: mmc0:0001 EC2QT 59.6 GiB
kernel:  mmcblk0: p1
udisksd[597]: Mounted /dev/mmcblk0p1 at /media/USERNAME/disk on behalf 
of uid 1000
udisksd[597]: Cleaning up mount point /media/USERNAME/disk (device 179:1 
is not mounted)

udisksd[597]: Unmounted /dev/mmcblk0p1 on behalf of uid 1000
kernel: mmc0: card 0001 removed

SANDISK ULTRA 16GB MICRO SDHC CARD (DOESN'T WORK WITHOUT THE WORKAROUND) 
- SYSTEMD JOURNALD - Relevant messages:

kernel: mmc0: new ultra high speed DDR50 SDHC card at address 
kernel: mmcblk0: mmc0: SL16G 14.8 GiB
AFTER 1 MINUTE:
systemd-udevd[459]: mmc0:: Worker [493] processing SEQNUM=2742 is 
taking a long time

AFTER 2 MORE MINUTES I REMOVED THE CARD FROM THE READER:
kernel: mmc0: Card removed during transfer!
kernel: mmc0: Resetting controller.
kernel: ldm_validate_partition_table(): Disk read failed.
kernel: Dev mmcblk0: unable to read RDB block 0
kernel:  mmcblk0: unable to read partition table
kernel: mmc0: card  removed

SANDISK ULTRA 16GB MICRO SDHC CARD (WORKS WITH THE WORKAROUND) - SYSTEMD 
JOURNALD - Relevant messages:

kernel: mmc0: new high speed SDHC card at address 
kernel: mmcblk0: mmc0: SL16G 14.8 GiB
kernel:  mmcblk0:
kernel: FAT-fs (mmcblk0): Volume was not properly unmounted. Some data 
may be corrupt. Please run fsck.
udisksd[587]: Mounted /dev/mmcblk0 at /media/USERNAME/disk on behalf of 
uid 1000
udisksd[587]: Cleaning up mount point /media/USERNAME/disk (device 179:0 
is not mounted)

udisksd[587]: Unmounted /dev/mmcblk0 on behalf of uid 1000
kernel: mmc0: card  removed

ADATA 16GB MICRO SDHC CARD (WORKS WITHOUT 

Bug#1002831: ITP: lsb-release-minimal -- minimal shell implementation of lsb_release

[Gioele Barabucci]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-init-divers...@chiark.greenend.org.uk

* Package name: lsb-release-minimal
  Version : 0.1
  Upstream Author : Gioele Barabucci
* URL : https://gioele.io/lsb-release-minimal
* License : ISC
  Programming Lang: POSIX shell
  Description : Linux Standard Base version reporting utility 
(minimal implementation)



The Debian packaging is already available in the `debian` branch, see 
https://github.com/gioele/lsb-release-minimal/tree/debian



From the README:

This repository contains a bare-bones version of the `lsb_release` 
command, implemented as a tiny POSIX shell script (less than 100 
commented lines).


Instead of using LSB packages, this version of `lsb_release` uses the 
information in `/etc/os-release`. Nevertheless, the output of this 
version is byte-for-byte compatible with the Python-based version 
provided by Debian and its derivatives.


Using this implementation it is possible to avoid installing Python in a 
base OS image while still retaining compatibility with older scripts 
that expect `lsb_release` to exist.


--
Gioele Barabucci 

Bug#995996: dump: segfaults on long paths

[наб]

Control: tag -1 + patch

On Tue, Oct 12, 2021 at 05:40:42PM +1000, Alexander Zangerl wrote:
> sorry, but i disagree. yes, it is a bug. but no, it is not severity
> important: a 2000+ levels deep directory hierarchy has no
> practical relevance whatsoever.
> and a workaround exists: don't create ridiculously deep hierarchies ;-)
I mean, yeah, fair enough; I have this explicitly for testing coreutils.

Below you'll find a patch for 0.4b47-2, replacing the static MAXPATHLEN
path buffer in treescan() with a dynamically allocated one. This fixes
both the original bug (down to directory depths I assume no-one
has achieved before), and the 
  ./[very long path redacted]: name exceeds 4096 char
diagnostic I got when I originally bumped ulimit -s.

It does use asprintf(3) ‒ while an extension,
it's universal across the extant Berkeley and Solaris derivatives.

-x mode still panics since the paths *are* longer than PATH_MAX, but you
can't pass those to syscalls anyway and restructuring around that would
be non-trivial (in this case, your workaround should be applied
instead :P).

Best,
наб
Date: Wed, 29 Dec 2021 16:26:07 +0100
From: наб 
Subject: Don't trust MAXPATHLEN in treescan()

Dynamically allocate the path buffer:
this both allows paths longer than PATH_MAX,
and thins the stack frame considerably
(no longer segfaulting on a Very Deep tree
 on Debian-default 8k ulimit -s)

--- dump-0.4b47.orig/restore/dirs.c
+++ dump-0.4b47/restore/dirs.c
@@ -287,9 +287,8 @@ treescan(char *pname, dump_ino_t ino, lo
 {
struct inotab *itp;
struct direct *dp;
-   int namelen;
off_t bpt;
-   char locname[MAXPATHLEN + 1];
+   char *locname;
 
itp = inotablookup(ino);
if (itp == NULL) {
@@ -308,9 +307,6 @@ treescan(char *pname, dump_ino_t ino, lo
 * begin search through the directory
 * skipping over "." and ".."
 */
-   namelen = snprintf(locname, sizeof(locname), "%s/", pname);
-   if (namelen >= (int)sizeof(locname))
-   namelen = sizeof(locname) - 1;
rst_seekdir(dirp, itp->t_seekpt, itp->t_seekpt);
dp = rst_readdir(dirp); /* "." */
if (dp != NULL && strcmp(dp->d_name, ".") == 0)
@@ -328,15 +324,13 @@ treescan(char *pname, dump_ino_t ino, lo
 * a zero inode signals end of directory
 */
while (dp != NULL) {
-   locname[namelen] = '\0';
-   if (namelen + dp->d_namlen >= (int)sizeof(locname)) {
-   fprintf(stderr, "%s%s: name exceeds %ld char\n",
-   locname, dp->d_name, (long)sizeof(locname) - 1);
-   } else {
-   (void) strncat(locname, dp->d_name, (int)dp->d_namlen);
-   treescan(locname, dp->d_ino, todo);
-   rst_seekdir(dirp, bpt, itp->t_seekpt);
+   if (asprintf(, "%s/%.*s", pname, (int)dp->d_namlen, 
dp->d_name) == -1) {
+   panic("Error: %s\n", strerror(errno));
+   abort();
}
+   treescan(locname, dp->d_ino, todo);
+   free(locname);
+   rst_seekdir(dirp, bpt, itp->t_seekpt);
dp = rst_readdir(dirp);
bpt = rst_telldir(dirp);
}


signature.asc
Description: PGP signature

Bug#965739: myspell-fa: diff for NMU version 0.20070816-3.2

[Adrian Bunk]

Control: tags 965739 + patch
Control: tags 965739 + pending
Control: tags 999040 + patch
Control: tags 999040 + pending

Dear maintainer,

I've prepared an NMU for myspell-fa (versioned as 0.20070816-3.2) and 
uploaded it to DELAYED/7. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru myspell-fa-0.20070816/debian/changelog myspell-fa-0.20070816/debian/changelog
--- myspell-fa-0.20070816/debian/changelog	2018-10-30 20:33:51.0 +0200
+++ myspell-fa-0.20070816/debian/changelog	2021-12-29 17:51:27.0 +0200
@@ -1,3 +1,11 @@
+myspell-fa (0.20070816-3.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965739)
+  * debian/rules: Add build-{arch,indep}. (Closes: #999040)
+
+ -- Adrian Bunk   Wed, 29 Dec 2021 17:51:27 +0200
+
 myspell-fa (0.20070816-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru myspell-fa-0.20070816/debian/compat myspell-fa-0.20070816/debian/compat
--- myspell-fa-0.20070816/debian/compat	2007-08-18 12:21:05.0 +0300
+++ myspell-fa-0.20070816/debian/compat	2021-12-29 17:51:27.0 +0200
@@ -1 +1 @@
-5
+7
diff -Nru myspell-fa-0.20070816/debian/rules myspell-fa-0.20070816/debian/rules
--- myspell-fa-0.20070816/debian/rules	2007-08-18 12:21:05.0 +0300
+++ myspell-fa-0.20070816/debian/rules	2021-12-29 17:51:27.0 +0200
@@ -50,5 +50,7 @@
 # Build architecture-dependent files here.
 binary-arch: build install
 
+build-arch: build
+build-indep: build
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure

Bug#1002830: mailman3: Wrong error message when permissions are wrong

[Martin Mares]

Package: mailman3
Version: 3.3.3-1
Severity: minor

Hello!

I was receiving mysterious messages from the out runner:

Cannot connect to SMTP server 127.0.0.1 on port 25

even though the SMTP server was running fine. It turned out that the cause
of the failure is wrong permissions on the template file:


/var/lib/mailman3/templates/lists/test-l.example.org/en/list:member:regular:footer.txt

Could somebody please fix the misleading message?


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads)
Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages mailman3 depends on:
ii  dbconfig-pgsql   2.0.19
ii  debconf [debconf-2.0]1.5.77
ii  init-system-helpers  1.60
ii  logrotate3.18.0-2
ii  lsb-base 11.1.0
ii  python3  3.9.2-3
ii  python3-aiosmtpd 1.2.2-1
ii  python3-alembic  1.4.3-1
ii  python3-authheaders  0.13.1-1
ii  python3-authres  1.2.0-2
ii  python3-click7.1.2-1
ii  python3-dateutil 2.8.1-6
ii  python3-dnspython2.0.0-1
ii  python3-falcon   2.0.0-2+b1
ii  python3-flufl.bounce 3.0.1-1
ii  python3-flufl.i18n   3.0.1-1
ii  python3-flufl.lock   5.0.1-1
ii  python3-gunicorn 20.1.0-1
ii  python3-importlib-resources  5.1.0-1
ii  python3-lazr.config  2.2.3-1
ii  python3-passlib  1.7.4-1
ii  python3-psycopg2 2.8.6-2
ii  python3-public   0.5-1.1
ii  python3-requests 2.25.1+dfsg-2
ii  python3-sqlalchemy   1.3.22+ds1-1
ii  python3-zope.component   4.3.0-3
ii  python3-zope.configuration   4.4.0-1
ii  python3-zope.event   4.4-3
ii  python3-zope.interface   5.2.0-1
ii  ucf  3.0043

Versions of packages mailman3 recommends:
ii  postfix [mail-transport-agent]  3.5.6-1+b1

Versions of packages mailman3 suggests:
ii  elinks [www-browser]0.13.2-1+b1
ii  links2 [www-browser]2.21-1+b1
ii  lynx [www-browser]  2.9.0dev.6-3~deb11u1
ii  mailman3-doc3.3.3-1
ii  mariadb-server-10.5 [virtual-mysql-server]  1:10.5.12-0+deb11u1
ii  w3m [www-browser]   0.5.3+git20210102-6

-- debconf information:
  mailman3/install-error: abort
  mailman3/pgsql/authmethod-admin: ident
  mailman3/db/app-user: mailman3@localhost
  mailman3/remote/port:
  mailman3/pgsql/method: TCP/IP
  mailman3/db/dbname: mailman3
  mailman3/upgrade-backup: true
  mailman3/missing-db-package-error: abort
* mailman3/remote/host: localhost
  mailman3/pgsql/authmethod-user: password
  mailman3/internal/reconfiguring: false
  mailman3/pgsql/no-empty-passwords:
  mailman3/remote/newhost: localhost
  mailman3/mysql/method: Unix socket
  mailman3/pgsql/changeconf: false
* mailman3/dbconfig-install: true
  mailman3/pgsql/admin-user: postgres
  mailman3/dbconfig-reinstall: false
  mailman3/upgrade-error: abort
  mailman3/dbconfig-remove: true
  mailman3/purge: false
  mailman3/pgsql/manualconf:
  mailman3/mysql/authplugin: default
* mailman3/database-type: pgsql
  mailman3/remove-error: abort
  mailman3/db/basepath: /var/lib/mailman3/data
  mailman3/init_service_failed:
  mailman3/mysql/admin-user:
  mailman3/dbconfig-upgrade: true
  mailman3/config_hyperkitty:
  mailman3/passwords-do-not-match:
  mailman3/internal/skip-preseed: false

Bug#1002829: please document how to set nfsv4gracetime and nfsv4leasetime

[Harald Dunkel]

Package: nfs-kernel-server
Version: 1:1.3.4-6

I would like to reduce nfsv4gracetime and nfsv4leasetime from 90 sec
to something reasonable. Looking through several scripts and systemd
config files I figured out that I have to set

RPCNFSDOPTS

in /etc/default/nfs-server.conf to make a helper script (called by
a systemd service) generate another config file in /run setting a
variable

RPCNFSDARGS

which is then read by the nfs-kernel service to construct the
rpc.nfsd command line.

I am quite sure that this construct is not "Debian quality". Could
you please cleanup this mess for bookworm and improve the
documentation?

Thank you very much


Harri

Bug#1002828: lintian: please add rakudo as known interpreter

[Dominique Dumont]

Package: lintian
Version: 2.114.0
Severity: normal

Dear Maintainer,

When building prove6 package, lintian issues this warning:

  W: prove6: unusual-interpreter /usr/bin/raku [usr/bin/prove6]

/usr/bin/raku is Raku (formely Perl6) interpreter provided by rakudo
package.

Could you add raku to the list of known interpreters ?

All the best

Dod


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 lintian depends on:
ii  binutils2.37-10
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.1
ii  dpkg-dev1.21.1
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-3
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.1
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.120-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.26-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.10-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.60-1

-- no debconf information

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

[Simon McVittie]

On Wed, 29 Dec 2021 at 00:07:47 +0100, luca.per...@gmail.com forwarded:
> A couple of the unit tests do some checking
> of collation order, and hence require the tests to be run with a
> specific locale. For annoying technical reasons, that has to be
> en_US.UTF-8, which means support files for that locale need to be
> installed as a build dependency for the tests to succeed.

There are two ways to guarantee an en_US.UTF-8 locale:

- Build-depend on locales-all

- Build-depend on locales|locales-all and generate locale files,
  like src:glib2.0 does

I would personally suggest copying the debian/tests/run-with-locales script
from src:glib2.0 and running that. See glib2.0's debian/rules for an example
of how to use that script.

smcv

Bug#1002047: reportbug: nslcd silently modifies /etc/nslcd.conf on upgrade, breaking authentication

[Arthur de Jong]

Control: tags -1 + pending

On Mon, 2021-12-20 at 22:03 +0100, Thomas Fargeix wrote:
> The postinst script of nslcd silently modifies the configuration file
> /etc/nslcd.conf on package upgrades. It rewrites or adds settings
> without notification to the administrator.

Thanks for this report.

> In my case, the script appended "base dc=olddomain,dc=example,dc=org"
> during the dist-upgrade from Buster to Bullseye. After reboot, remote
> and local login to the server was broken except for root due to this
> change.

The base option is used by nslcd for both the post-login check
(pam_authc_search) as well as the authorisation check
(pam_authz_check). If you don't specify one on start-up nslcd will
contact the LDAP server and try to get one from the server.

It turns out that the debconf scripts were not expecting the base
option to be absent from nslcd.conf causing an old cached version of
the value to be used.

> It also failed to consider the more precise "bases" that were already
> configured.

The debconf configuration does not support changing these options but
they should be retained on any changes that happen through debconf.

> I would have expected the script to not modify the existing
> configuration or at least to warn me it had been modified.

I've had a quick look into adding logging (which would be nice) but
that would require some restructuring in the postinst script because we
now use sed to change nslcd.conf unconditionally. The postinst is
already overly complex and I would like to avoid making it even longer.

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



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

Bug#948020: fix from upstream available

[Alois Schlögl]

This patch in the upstream repository
https://github.com/neurodroid/stimfit/commit/efd90830aa930498e5861f98839228bcf7086237
fixes this bug. The patch is also attached.


Alois
commit efd90830aa930498e5861f98839228bcf7086237
Author: Alois SCHLOEGL 
Date:   Mon Jan 18 12:12:52 2021 +0100

dependency on python3-dev instead of python3-all-dev (closes #972423 #948020)

diff --git a/dist/debian/changelog b/dist/debian/changelog
index 4b8ea1e4..2524f4fb 100644
--- a/dist/debian/changelog
+++ b/dist/debian/changelog
@@ -4,6 +4,7 @@ stimfit (0.16.0-2) unstable; urgency=low
 this ensures that the latest features and data formats of
 libbiosig (v2.1.2 and later) are supported by Stimfit, too.
   * remove dependency on libboost since -std=c++17 (default in gcc-8) is used
+  * dependency on python3-dev instead of python3-all-dev (closes #972423 #948020)
 
  -- Alois Schlögl   Sun, 17 Jan 2021 17:05:41 +0100
 
diff --git a/dist/debian/control b/dist/debian/control
index bb94c817..b3c48306 100644
--- a/dist/debian/control
+++ b/dist/debian/control
@@ -3,7 +3,7 @@ Section: science
 Priority: optional
 Maintainer: Christoph Schmidt-Hieber 
 Uploaders: Yaroslav Halchenko 
-Build-Depends: debhelper (>= 9), dh-python, python3-all-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.0-gtk3-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libbiosig-dev, zlib1g-dev, dh-autoreconf, pkg-config
+Build-Depends: debhelper (>= 9), dh-python, python3-dev, python3-numpy, libhdf5-dev, swig, python3-sip-dev, python3-wxgtk4.0 (>= 4.0.7), libwxgtk3.0-gtk3-dev, libfftw3-dev, liblapack-dev, chrpath, help2man, libbiosig-dev, zlib1g-dev, dh-autoreconf, pkg-config
 Standards-Version: 4.4.1
 Homepage: http://www.stimfit.org
 

Bug#1002605: `apt-get source calendar' downloads the wrong package

[David Kalnischkies]

On Sat, Dec 25, 2021 at 05:43:44PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Stéphane Glondu (2021-12-25 13:36:48)
> > `apt-get source calendar' downloads the bsdmainutils source package
> > instead of calendar. I suspect this is because bsdmainutils is the
> > source package of the calendar binary package.
> > 
> > I think `apt-get source $FOO' should try to download $FOO if $FOO
> > exists as a source package, and only after fallback to downloading the
> > source package of $FOO if it exists only as a binary package.
> 
> I agree and I cannot remember a single time when (in scripts or when running
> apt manually) I wanted 'apt-get source' or 'apt-cache showsrc' to interpret 
> the
> package name as a binary package and not a source package. Because of that I
> have
> 
> APT::Get::Only-Source "true";
> 
> in my system-wide apt config. I've never looked back.

Mind reading of people I never meet is hard, but I assume the initial
authors of apt wanted to avoid teaching users about source packages
(and by extension also apt itself, which is still very ignorant of them
 even if it learned a bit about them in recent years).


The idea probably was that you 'apt-get install foo' and something makes
you want to check out the source code of it, because why not, right?
So you do 'apt-get source foo'. In this interaction it would be
surprising that I am not getting the source of the package I have
installed, but somehow the source of something else?!

I still remember being confused many years ago after running for the
first time into the binary automake built by automake-X and automake-Y
built by source automake… at least, that seems resolved nowadays.


Anyway, I don't see us reversing the default search order and not
dropping binary lookup altogether (what the option does) either.
(or outlawing these collisions as evil – somehow I get the feeling that
 is what initial authors intended but failed as with many other small
 things).

Especially source could use some love though to properly display the VCS
info and in that process perhaps even display/ask about collisions. That
is some longstanding wishlist though, so holding your breath might not
be advisable.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#991609: postfix/postfix-script: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ

[Vincent Lefevre]

On 2021-12-29 08:08:59 -0500, Scott Kitterman wrote:
> Thanks.  Does it come back again?

I've upgraded to 3.6.3-4, and it did not come back.
Even after "postfix stop" and "postfix start".

> When was the postfix package originally installed on the system that
> does this?

The timestamp was the following:

-rw-r--r-- 1 root root 200061 2019-09-20 11:53:51 
/var/spool/postfix/etc/ssl/certs/ca-certificates.crt

This is a bit before postfix 3.4.7-1 (released on 22 Sep 2019) got
installed. So I assume that postfix before 3.4.7-1 was copying
ca-certificates.crt into the chroot and that the above timestamp
corresponded to the last start of postfix before this version
(according to some traces I have kept, it seems that I rebooted this
machine shortly after 11:52 due to the upgrade of intel-microcode).

The postfix 3.4.7-1 changelog says:

- Stop copying smtp_tls_CAfile into chroot, not needed per postfix docs
- Also copy smtpd_tls_CApath files into chroot.  Closes: #579248

This may be related (though I never used smtpd_tls_CA*). So it seems
that postfix 3.4.5-1+b1 did the copy. But I don't know when this
occurred for the first time.

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

Bug#1002827: Should be in contrib; expects an installation of Steam

[Josh Triplett]

Package: proton-caller
Severity: serious
X-Debbugs-Cc: j...@joshtriplett.org

While portions of Proton are Open Source (being based on the LGPLed
Wine), proton-caller appears to specifically expect an installation of
Steam. The description says "Simply configure your Steam and common
directories", and the upstream documentation similarly talks about
configuring the path to a Steam installation.

- Josh


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

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

Versions of packages proton-caller depends on:
ii  libc6  2.33-1
ii  libgcc-s1  11.2.0-13

proton-caller recommends no packages.

proton-caller suggests no packages.

Bug#996910: linphone: Segmentation fault when registering a sip account

[Tiago Bortoletto Vaz]

On Tue, Dec 28, 2021 at 06:21:56PM +0100, Dennis Filder wrote:
> X-Debbugs-CC: Tiago Bortoletto Vaz 
> 
> On Tue, Dec 28, 2021 at 09:45:04AM -0500, Tiago Bortoletto Vaz wrote:
> > gdb log attached. I hope that can be useful :\
> 
> That stacktrace looks very similar to the ones from #983597 which
> already has 3 entries in the Qt bugtracker[0] one of which has an
> Orca-less reproducer.  Thus I'm inclined to mark this as a duplicate.

That's fine. I'll keep an eye and try to provide them with some info if needed.
By the way, it doesn't depend on the domain, neither it gets to the auth step.
 
> Unfortunately, tracking this down would probably require unoptimized
> debug builds of most of the involved libraries, so that's something
> the Qt devs have to solve.

Sure, thanks for the investigation.

Bests,

Bug#1002826: rpc-svcgssd.service fails with "unable to obtain root (machine) credentials"

[Harald Dunkel]

Package: nfs-common
Version: 1:1.3.4-6

systemd moans about krb5.keytab at boot time

```
# systemctl --failed
  UNITLOAD   ACTIVE SUBDESCRIPTION
* rpc-svcgssd.service loaded failed failed RPC security service for NFS server

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.
1 loaded units listed.

# systemctl status rpc-svcgssd
* rpc-svcgssd.service - RPC security service for NFS server
 Loaded: loaded (/etc/systemd/system/rpc-svcgssd.service; static)
 Active: failed (Result: exit-code) since Wed 2021-12-29 14:00:51 CET; 8min 
ago
Process: 301 ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS (code=exited, 
status=1/FAILURE)
CPU: 6ms

Dec 29 14:00:50 nfs00.example.com systemd[1]: Starting RPC security service for 
NFS server...
Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: ERROR: GSS-API: error in 
gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may 
provide more information) - No key table entry found matching nfs/@
Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: unable to obtain root 
(machine) credentials
Dec 29 14:00:50 nfs00.example.com rpc.svcgssd[302]: do you have a keytab entry for 
nfs/@ in /etc/krb5.keytab?
Dec 29 14:00:51 nfs00.example.com systemd[1]: rpc-svcgssd.service: Control 
process exited, code=exited, status=1/FAILURE
Dec 29 14:00:51 nfs00.example.com systemd[1]: rpc-svcgssd.service: Failed with 
result 'exit-code'.
Dec 29 14:00:51 nfs00.example.com systemd[1]: Failed to start RPC security 
service for NFS server.
```

Shouldn't svcgssd either exit silently with 0 or become optional? Looking at
nfs(5) Kerberos authentication for NFS appears to be optional, regardless if
there is a keytab file with or without NFS credentials.


Regards

Harri

Bug#960222: Uploaded a fix for unittest2

[Thomas Goirand]

Hi,

I uploaded a fix for unittest2 so it wouldn't depend on traceback2.
Let's wait until it reaches testing, and then we may attempt to remove
traceback2.

Cheers,

Thomas Goirand (zigo)

Bug#1002825: fails to detect write cache on SATA disks

[Felix Zielcke]

Package: src:linux
Version: 5.15.5-2
Severity: important
Tags: upstream fixed-upstream
Forwarded: https://bugzilla.kernel.org/show_bug.cgi?id=215137

Kernel 5.15.5 fails to detect write cache of SATA disks:

# dmesg|grep sda
[  +0,003954] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 
TB/932 GiB)
[  +0,001724] sd 0:0:0:0: [sda] 4096-byte physical blocks
[  +0,001840] sd 0:0:0:0: [sda] Write Protect is off
[  +0,001796] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[  +0,001795] sd 0:0:0:0: [sda] Asking for cache data failed
[  +0,001782] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  +0,013566]  sda: sda1
[  +0,018629] sd 0:0:0:0: [sda] Attached SCSI disk

This breaks write barriers. And could result in an unmountable btrfs
filesystem on a crash or otherwise unclean shutdown.

It's fixed upstream in 5.15.6 and commit 
c749301ebee82eb5e97dec14b6ab31a4aabe37a6


-- Package-specific info:
** Version:
Linux version 5.15.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.2.0-13) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian 
5.15.5-2 (2021-12-18)

** Command line:
BOOT_IMAGE=/vmlinuz-5.15.0-2-amd64 
root=UUID=de343167-b5ff-4758-aed3-7000e6e9e5d4 ro

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[  124.330665] systemd-journald[1113]: Received client request to flush runtime 
journal.
[  124.331901] RAPL PMU: API unit is 2^-32 Joules, 1 fixed counters, 163840 ms 
ovfl timer
[  124.333070] RAPL PMU: hw unit of domain package 2^-16 Joules
[  124.797362] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input16
[  124.799011] ACPI: button: Power Button [PWRB]
[  124.799069] input: PC Speaker as /devices/platform/pcspkr/input/input17
[  124.800366] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input18
[  124.802592] ACPI: button: Power Button [PWRF]
[  124.805784] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver
[  124.807280] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address
[  124.807729] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  124.808526] sp5100-tco sp5100-tco: Watchdog hardware is disabled
[  124.809826] sd 1:0:0:0: Attached scsi generic sg1 type 0
[  124.812894] sd 2:0:0:0: Attached scsi generic sg2 type 0
[  124.815192] sr 3:0:0:0: Attached scsi generic sg3 type 5
[  124.818088] ccp :09:00.1: enabling device ( -> 0002)
[  124.819510] ccp :09:00.1: ccp: unable to access the device: you might be 
running a broken BIOS.
[  124.862462] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input19
[  124.862611] kvm: Nested Virtualization enabled
[  124.863707] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input20
[  124.864896] SVM: kvm: Nested Paging enabled
[  124.864917] SVM: Virtual VMLOAD VMSAVE supported
[  124.866164] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input21
[  124.867370] SVM: Virtual GIF supported
[  124.868635] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input22
[  124.873679] input: HDA NVidia HDMI/DP,pcm=10 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input23
[  124.875028] input: HDA NVidia HDMI/DP,pcm=11 as 
/devices/pci:00/:00:03.1/:07:00.1/sound/card0/input24
[  124.879082] MCE: In-kernel MCE decoding enabled.
[  124.879273] nvidia: loading out-of-tree module taints kernel.
[  124.879313] nvidia: loading out-of-tree module taints kernel.
[  124.879322] nvidia: module license 'NVIDIA' taints kernel.
[  124.879323] Disabling lock debugging due to kernel taint
[  124.888717] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[  124.911987] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[  124.913593] EDAC amd64: MCT channel count: 2
[  124.915038] EDAC MC0: Giving out device to module amd64_edac controller 
F19h_M20h: DEV :00:18.3 (INTERRUPT)
[  124.916506] EDAC amd64: F19h_M20h detected (node 0).
[  124.917979] EDAC MC: UMC0 chip selects:
[  124.917980] EDAC amd64: MC: 0: 0MB 1: 0MB
[  124.919433] EDAC amd64: MC: 2:  8192MB 3: 0MB
[  124.920980] EDAC MC: UMC1 chip selects:
[  124.920981] EDAC amd64: MC: 0: 0MB 1: 0MB
[  124.922439] EDAC amd64: MC: 2:  8192MB 3: 0MB
[  124.923902] EDAC amd64: using x16 syndromes.
[  124.926016] EDAC PCI0: Giving out device to module amd64_edac controller 
EDAC PCI controller: DEV :00:18.0 (POLLED)
[  124.927542] AMD64 EDAC driver v3.5.0
[  124.936409] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 244

[  124.938591] EXT4-fs (nvme0n1p6): mounted filesystem with ordered data mode. 
Opts: (null). Quota mode: none.
[  124.939494] nvidia :07:00.0: vgaarb: changed VGA decodes: 

Bug#1002822: python3-gitlab: Should likely not ship /usr/lib/python3/dist-packages/docs/conf.py ("trying to overwrite '/usr/lib/python3/dist-packages/docs/conf.py', which is also in package python3-di

[Axel Beckert]

Package: python3-gitlab
Version: 1:2.10.0-1
Severity: serious
Control: clone -1 -2
Control: clone -1 -3
Control: reassign -2 python3-diskcache 5.2.1-2
Control: retitle -2 python3-diskcache: Should likely not ship 
/usr/lib/python3/dist-packages/docs/conf.py ("trying to overwrite 
'/usr/lib/python3/dist-packages/docs/conf.py', which is also in package 
python3-gitlab 1:2.10.0-1")
Control: severity -3 wishlist
Control: reassign -3 lintian
Control: retitle -3 lintian: Should warn about packages installing _any_ file  
directly under /usr/lib/python3/dist-packages/docs/ and similar locations

python3-gitlab 1:2.10.0-1 as well as python3-diskcache 5.2.1-2 both ship
/usr/lib/python3/dist-packages/docs/conf.py which is a serious bug
alone:

Unpacking python3-gitlab (1:2.10.1-1) over (1:2.10.0-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/python3-gitlab_1%3a2.10.1-1_all.deb (--unpack):
 trying to overwrite '/usr/lib/python3/dist-packages/docs/conf.py', which is 
also in package python3-diskcache 5.2.1-2
Errors were encountered while processing:
 /var/cache/apt/archives/python3-gitlab_1%3a2.10.1-1_all.deb


For python3-diskcache, it should very likely not install these files at
all:

/usr/lib/python3/dist-packages/docs/Makefile
/usr/lib/python3/dist-packages/docs/api.rst
/usr/lib/python3/dist-packages/docs/cache-benchmarks.rst
/usr/lib/python3/dist-packages/docs/case-study-landing-page-caching.rst
/usr/lib/python3/dist-packages/docs/case-study-web-crawler.rst
/usr/lib/python3/dist-packages/docs/conf.py
/usr/lib/python3/dist-packages/docs/development.rst
/usr/lib/python3/dist-packages/docs/djangocache-benchmarks.rst
/usr/lib/python3/dist-packages/docs/index.rst
/usr/lib/python3/dist-packages/docs/make.bat
/usr/lib/python3/dist-packages/docs/tutorial.rst

And these files are probably edgy:

/usr/lib/python3/dist-packages/docs/sf-python-2017-meetup-talk.rst (clearly 
belongs to /usr/share/doc/python3-diskcache/)
/usr/lib/python3/dist-packages/docs/_static/core-p1-delete.png
/usr/lib/python3/dist-packages/docs/_static/core-p1-get.png
/usr/lib/python3/dist-packages/docs/_static/core-p1-set.png
/usr/lib/python3/dist-packages/docs/_static/core-p8-delete.png
/usr/lib/python3/dist-packages/docs/_static/core-p8-get.png
/usr/lib/python3/dist-packages/docs/_static/core-p8-set.png
/usr/lib/python3/dist-packages/docs/_static/custom.css
/usr/lib/python3/dist-packages/docs/_static/djangocache-delete.png
/usr/lib/python3/dist-packages/docs/_static/djangocache-get.png
/usr/lib/python3/dist-packages/docs/_static/djangocache-set.png
/usr/lib/python3/dist-packages/docs/_static/early-recomputation-03.png
/usr/lib/python3/dist-packages/docs/_static/early-recomputation-05.png
/usr/lib/python3/dist-packages/docs/_static/early-recomputation.png
/usr/lib/python3/dist-packages/docs/_static/gj-logo.png
/usr/lib/python3/dist-packages/docs/_static/no-caching.png
/usr/lib/python3/dist-packages/docs/_static/synchronized-locking.png
/usr/lib/python3/dist-packages/docs/_static/traditional-caching.png
/usr/lib/python3/dist-packages/docs/_templates/gumroad.html


For python3-gitlab, it should very likely not install these files at
all:

python3-gitlab: /usr/lib/python3/dist-packages/docs/__init__.py
python3-gitlab: /usr/lib/python3/dist-packages/docs/conf.py
python3-gitlab: /usr/lib/python3/dist-packages/docs/ext/__init__.py
python3-gitlab: /usr/lib/python3/dist-packages/docs/ext/docstrings.py


But I suspect that no package at all should ship a file in such a
generic location. So on the one hand not filing these issues against
"python3-gitlab _OR_ python3-diskcache" but against "python3-gitlab
_AND_ python3-diskcache".


And I'm filing this a wishlist bug against lintian as well.

I'd say any file …

* directly in /usr/lib/python3/dist-packages/docs/ should cause at least
  a warning or even an error.

* in a subdirectory of /usr/lib/python3/dist-packages/docs/ which is
  starting with an underscore ("_") should probably get a warning or at
  least a pedantic warning.

* And maybe for shipping any file in
  /usr/lib/python3/dist-packages/docs/ext/ as well.

* And according to #947264, #998820 and #973627 maybe also
  /usr/lib/python3/dist-packages/examples/,
  /usr/lib/python3/dist-packages/scripts/ and
  /usr/lib/python3/dist-packages/benchmarks/.

This likely is an expansion of the what
python-module-has-overly-generic-name already reports.

python-module-has-overly-generic-name is part of the
data/archive/auto-rejection.yaml and since both packages,
python3-diskcache as well as python3-gitlab seem to have no lintian
overrides, the tag seems not to have been triggered by these packages.

Then again, a local lintian run does not confirm this, at least not for
python3-gitlab:

$ lintian python3-gitlab_2.10.1-1_all.deb python3-diskcache_5.2.1-2_all.deb
E: python3-gitlab: python-module-has-overly-generic-name 
usr/lib/python3/dist-packages/docs/__init__.py (docs)
I: python3-diskcache: […]

So I wonder how python3-gitlab could get into 

Bug#1002821: lyx-common: String/Bytes Problem in layout2layout.py

[Leo L. Schwab]

Package: lyx-common
Version: 2.3.6-1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: ew...@ewhac.org

Dear Maintainer,

Discovered this while trying to use Editorium's LyXBook modules.
layout2layout.py was konking out with "TypeError: cannot use a bytes
pattern on a string-like object."  After a bunch of debugging, I found
some strings in the script that hadn't been bytes-ified, which seemed to
fix the problem.  Patch attached.

Schwab


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

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

Versions of packages lyx-common depends on:
ii  python3 3.9.8-1
ii  tex-common  6.17

Versions of packages lyx-common recommends:
ii  lyx  2.3.6-1

lyx-common suggests no packages.

-- no debconf information
--- /usr/share/lyx/scripts/layout2layout.py 2020-12-01 02:33:35.0 
-0800
+++ ./layout2layout.py  2021-12-29 01:04:59.614016427 -0800
@@ -484,8 +484,8 @@
 i += 1
 continue
 col  = match.group(2)
-if col == "collapsable":
-lines[i] = match.group(1) + "collapsible"
+if col == b"collapsable":
+lines[i] = match.group(1) + b"collapsible"
 i += 1
 continue
 
@@ -703,7 +703,7 @@
 # Insert the required number of arguments at the end of the style 
definition
 match = re_End.match(lines[i])
 if match:
-newarg = ['']
+newarg = [b'']
 # First the optionals (this is the required order pre 2.1)
 if opts > 0:
 if opts == 1:
@@ -1153,7 +1153,7 @@
 if latextype == b"item_environment" and label.lower() == 
b"counter_enumi":
 lines[labeltype_line] = 
re_LabelType.sub(b'\\1\\2\\3Enumerate', lines[labeltype_line])
 # Don't add the LabelCounter line later
-counter = ""
+counter = b""
 
 # Replace
 #
@@ -1227,12 +1227,12 @@
 if options.input_file:
 source = open(options.input_file, 'rb')
 else:
-source = sys.stdin
+source = sys.stdin.buffer
 
 if options.output_file:
 output = open(options.output_file, 'wb')
 else:
-output = sys.stdout
+output = sys.stdout.buffer
 
 if options.format > currentFormat:
 error("Format %i does not exist" % options.format);

Bug#1001895: Please ship also iso_week.h and co in libhowardhinnant-date-dev

[David Kalnischkies]

Hi,

On Wed, Dec 22, 2021 at 11:26:58PM +0100, Andrea Pappacoda wrote:
> Those extra headers should definitely get included in the package, I
> did not notice that the CMake script installs only [1] date.h :/

(Perhaps a bit overkill here, but if it is reasonably easy to do, try
 to build a test program as an autopkgtest. Perhaps even the testsuite.
 As a bonus you get faster transitions to testing.)


> I'll patch this in the next revision! It will probably come after the
> holidays though, as I'll busy studying / fixing my mail server /
> partying.

No problem – as somewhat evident by my own reply delay:
A late happy festive days & an upcoming happy new year!
(if applicable)

I work on/use that program once in a year and that was before I reported
this here, so it isn't super urgent to begin with  (it is generating
an ods file for a friend who records daily business statistics in it
[which are then summed up by week and month] – not rocket science, but
wiring 12 months by hand in Libreoffice is just too error prune/tedious).


> Regarding the r-cran-tzdb package, you see my (short) discussion with
> its maintainer in #998331 [2]

Ah, okay. Thanks for discussing it already!

(I tend to be in the "no-embeds" camp, but I see how people can disagree
 on that and this embed in particular isn't so bad to really object)


> As for sponsoring, it would of course be nice, but in the meantime I'd
> like you to ask a quick question about this package: do you think that
> packaging it under libhowardhinnant-date-dev was a good idea? Because
> I patched the project to install CMake config files with the
> "howardhinnant-date" name instead of just "date", but its headers
> still get installed to paths like "date/date.h". My reasoning for this
> was to not pollute the global namespace with such a general name, but
> I also wanted to not break projects correctly including date/date.h.

Yeah, I think it is fine as is. "date" really would have been a bit
short as a package name beside that nobody would know what the package
contains as there are a gazillion things named 'date' (including the
command itself…). Making a package name shorter/more generic is an easy
rename usually, so if it turns out that the world expects it to have
another name that is easy to do. Removing a name conflict on the other
hand tends to be a huge pain for maintainers and users alike: Prior
"art": node (JS and amateur radio), chromium (browser and game),
firebird (browser and database – upstream renamed to firefox quickly), …
So, if that can be avoided, that is a service to everyone.

It is still a very generic term even in /usr/include, but I assume that
at this point nobody in the C/C++ community will try to claim it and
having the same name as upstream here has clear benefits while renaming
would probably mean additional work/patches for every user. So that is
a bridge you better think about crossing only if there is a need. ☺


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#819961: nslcd: package upgrade fails in postinst due to uncommon characters in bindpw config parameter

[Arthur de Jong]

Control: tags -1 + pending

On Mon, 2021-12-20 at 21:07 +0100, Thomas Fargeix wrote:
> /var/lib/dpkg/info/nslcd.postinst chocked on a randomly generated 
> password during my dist-upgrade from Buster to Bullseye, interrupting
> and blocking the dist-upgrade and leaving the system in an unstable 
> state (for that reason, I propose to raise the severity to a 
> release-critical one).

Thanks for pointing this out, the detailed report and the testing you
did.

> I don't understand why the postinst script needs to rewrite the
> existing  configuration file with sed, so I let you decide what can
> be the best fix, however I would suggest avoiding to try to escape a
> random password string and put it in a regex.

The reason nslcd.conf is modified during postinst is because most of
the options are managed through debconf. The nslcd.conf is parsed and
fed into the debconf database and the postinst loads the new values
into the config.

There was also an additional bug in that single-character passwords
were accidentally removed. That shouldn't be that big of an issue but a
fix for unstable is incoming anyway.

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



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

Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

[Raphael Hertzog]

Control: tags -1 + patch
Control: user de...@kali.org
Control: usertag -1 + kali-patch

On Wed, 29 Dec 2021, Raphaël Hertzog wrote:
> I noticed that /etc/apt/preferences.d/autopkgtest-default-release uses
> another syntax that seems to cover more cases:
> 
> Package: *
> Pin: release kali-rolling
> Pin-Priority: 990
> 
> However that syntax doesn't seem to be documented in apt_preferences.
> If it's correct and allows to check on either of the 3 fields, then
> we should likely use the same syntax in both files.

I got confirmation from David Kalnischkies that this syntax is supported
and means exactly this:

12:54  buxy: yeah, its supported and means "Archive/Suite: or
Codename is X". One example in the manpage actually includes it (release
unstable), but it is never explained it seems. It is also the backbone of
commandline flag -t X. Code is in apt-pkg/versionmatch.cc, but its not
much to see.

So I recommend to use this same syntax in files generated for
--pin-packages.

Suggested patch is attached.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
>From 9946e61ed4821aa9c03d42393ea6887dc9337ea7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Wed, 29 Dec 2021 13:23:27 +0100
Subject: [PATCH] Fix APT pinning for --pin-packages to also match on codenames
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

By using “Pin: release foo” instead of “Pin: release a=foo” we match
against all 3 relevant fields (Codename/Suite/Archive) whereas the
latter only matches against Suite and Archive.

Closes: #1002819
---
 lib/adt_testbed.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/adt_testbed.py b/lib/adt_testbed.py
index b37eef4..225eb1f 100644
--- a/lib/adt_testbed.py
+++ b/lib/adt_testbed.py
@@ -1235,10 +1235,10 @@ Description: satisfy autopkgtest test dependencies
 
 # prefer given packages from series, but make sure that other packages
 # are taken from default release as much as possible
-script += 'printf "Package: $PKGS\\nPin: release a=%(release)s\\nPin-Priority: 995\\n" > /etc/apt/preferences.d/autopkgtest-%(release)s; ' % \
+script += 'printf "Package: $PKGS\\nPin: release %(release)s\\nPin-Priority: 995\\n" > /etc/apt/preferences.d/autopkgtest-%(release)s; ' % \
 {'release': release}
 for default in default_releases:
-script += 'printf "\nPackage: *\\nPin: release a=%(default)s\\nPin-Priority: 990\\n" >> /etc/apt/preferences.d/autopkgtest-%(release)s; ' % \
+script += 'printf "\nPackage: *\\nPin: release %(default)s\\nPin-Priority: 990\\n" >> /etc/apt/preferences.d/autopkgtest-%(release)s; ' % \
 {'release': release, 'default': default}
 self.check_exec(['sh', '-ec', script])
 self._set_default_release()
-- 
2.34.1

Bug#1001916: Info received (Bug#1001916: Info received (missing builds are due to compiler bugs))

[Martin Uecker]

GCC bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002505

Bug#1002505: Bug#1001916: Info received (missing builds are due to compiler bugs)

[Martin Uecker]

Minimal test case for armel:

# cat BUG.c 
extern _Complex float g(int N, int dims[N]);

void f(void)
{
int dims[1];
_Complex float val = g(1, dims);
}

# arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Debian 11.2.0-9) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# arm-linux-gnueabi-gcc BUG.c 
during RTL pass: expand
BUG.c: In function 'f':
BUG.c:10:30: internal compiler error: Segmentation fault
   10 | _Complex float val = g(1, dims);
  |  ^~

0xb1393f crash_signal
../../src/gcc/toplev.c:327
0x708398 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1274
0x70c4d4 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1266
0x70c4d4 get_size_range(tree_node*, tree_node**, int)
../../src/gcc/calls.c:1401
0x70c4d4 maybe_warn_rdwr_sizes
../../src/gcc/calls.c:2034
0x70dcb1 initialize_argument_information
../../src/gcc/calls.c:2626
0x70dcb1 expand_call(tree_node*, rtx_def*, int)
../../src/gcc/calls.c:4010
0x8210ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:11287
0x82a9ce expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, 
rtx_def**, bool)
../../src/gcc/expr.c:8519
0x82a9ce store_expr(tree_node*, rtx_def*, int, bool, bool)
../../src/gcc/expr.c:5886
0x82be69 expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5622
0x720bf9 expand_call_stmt
../../src/gcc/cfgexpand.c:2838
0x720bf9 expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3871
0x720bf9 expand_gimple_stmt
../../src/gcc/cfgexpand.c:4035
0x726b97 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:6077
0x726b97 execute
../../src/gcc/cfgexpand.c:6761
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Bug#1001916: Info received (missing builds are due to compiler bugs)

[Martin Uecker]

Minimal test case for armel:

# cat BUG.c 
extern _Complex float g(int N, int dims[N]);

void f(void)
{
int dims[1];
_Complex float val = g(1, dims);
}

# arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Debian 11.2.0-9) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# arm-linux-gnueabi-gcc BUG.c 
during RTL pass: expand
BUG.c: In function 'f':
BUG.c:10:30: internal compiler error: Segmentation fault
   10 | _Complex float val = g(1, dims);
  |  ^~

0xb1393f crash_signal
../../src/gcc/toplev.c:327
0x708398 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1274
0x70c4d4 get_size_range(range_query*, tree_node*, gimple*, tree_node**, int)
../../src/gcc/calls.c:1266
0x70c4d4 get_size_range(tree_node*, tree_node**, int)
../../src/gcc/calls.c:1401
0x70c4d4 maybe_warn_rdwr_sizes
../../src/gcc/calls.c:2034
0x70dcb1 initialize_argument_information
../../src/gcc/calls.c:2626
0x70dcb1 expand_call(tree_node*, rtx_def*, int)
../../src/gcc/calls.c:4010
0x8210ce expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.c:11287
0x82a9ce expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, 
rtx_def**, bool)
../../src/gcc/expr.c:8519
0x82a9ce store_expr(tree_node*, rtx_def*, int, bool, bool)
../../src/gcc/expr.c:5886
0x82be69 expand_assignment(tree_node*, tree_node*, bool)
../../src/gcc/expr.c:5622
0x720bf9 expand_call_stmt
../../src/gcc/cfgexpand.c:2838
0x720bf9 expand_gimple_stmt_1
../../src/gcc/cfgexpand.c:3871
0x720bf9 expand_gimple_stmt
../../src/gcc/cfgexpand.c:4035
0x726b97 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:6077
0x726b97 execute
../../src/gcc/cfgexpand.c:6761
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Bug#1001320: needrestart misdetects socket activated ssh and restarts service instead of socket

[Colin Watson]

On Wed, Dec 29, 2021 at 07:45:11AM +0100, Marc Haber wrote:
> On Tue, Dec 28, 2021 at 10:47:54PM +, Colin Watson wrote:
> > On Sat, Dec 25, 2021 at 08:18:11AM +0100, Marc Haber wrote:
> > > I would also mention that there might be cases of logins no longer
> > > possible regarding library updates and needrestart. This is a serious
> > > situation.
> > 
> > Thanks, I've tweaked the parenthesis a bit more with that in mind.
> 
> Technically, with socket activation, there is no "running sshd" while
> nobody is logged in, but I still can log in. The issue is that if this
> issue appears I can no longer log in because nothing, not even systemd,
> is listening on Port 22.

Fair enough - I've adjusted the documentation a bit further to make that
clear.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1002820: Please document adding keys to /etc/apt/trusted.gpg.d/ in detail

[Lee Garrett]

Package: apt
Version: 2.2.4
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

I noticed that apt-key(8) prominently mentions being deprecated. However, the
alternative is only mentioned in a single sentence under the "add" parameter,
which is easily overseen. It would be great if the knowledge in [0] is poured
into a man page to point users to. Specifically, I'd add a full section about
key management to apt(8) or sources.list(5), and that ascii-armored keys need
the .asc extension, binary encoded keys use need the .gpg extension, which
Debian releases support which, and how to verify that the key is accepted.

Thanks in advance!

Regards,
Lee

[0] https://blog.jak-linux.org/2021/06/20/migrating-away-apt-key/

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/chef-stable.list present, but not submitted) --


-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.27-2
ii  libapt-pkg6.0   2.2.4
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libgnutls30 3.7.1-5
ii  libseccomp2 2.5.1-1+deb11u1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-6

Versions of packages apt recommends:
ii  ca-certificates  20210119

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13-3
ii  dpkg-dev1.20.9
ii  gnupg   2.2.27-2
ii  powermgmt-base  1.36
ii  synaptic0.90.2

-- no debconf information

Bug#1002678: FTBFS with OCaml 4.13.1

[Chris Lamb]

Hi Stéphane,

> Your package FTBFS with OCaml 4.13.1 with the following error:
>> XFAIL tests/comparators/test_apk.py::test_android_manifest
   ^

This is actually an "eXpected failure" and not the root cause of the
build failure we are seeing. I think you just chose the wrong snippet
of the log to quote. *shrugs*

No matter, and this is actually reassuring for me: after all, what does
OCaml have to do with Android manifests? :)  Anyway, looking at the full
log [0] the actual failing test is as follows:


=== FAILURES 
===
__ test_diff 
___

differences = []

@skip_unless_tool_is_at_least("ocamlobjinfo", ocaml_version, "4.12")
def test_diff(differences):
>   assert_diff(differences[0], "ocaml_expected_diff")

differences = []

tests/comparators/test_ocaml.py:77: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ 

difference = 
filename = 'ocaml_expected_diff'

def assert_diff(difference, filename):
# Assign seen and expected values to local variables to improve 
contextual
# information in failed tests.
seen = difference.unified_diff
expected = get_data(filename)
>   assert seen == expected
E   AssertionError

difference = 
expected   = ('@@ -1,5 +1,5 @@\n'
 '-Unit name: Test1\n'
 '+Unit name: Test2\n'
 ' Interfaces imported:\n'
 '-\t69a7449a2ee894ef85f1a4d8645e8051\tTest1\n'
 '+\t187969740b6c403b926a8d81613601ae\tTest2\n'
 ' \t4b04b4eda19aa722df365141895fb347\tStdlib\n'
 ' \tb6c6694955e10001aed267571104a961\tCamlinternalFormatBasics\n')
filename   = 'ocaml_expected_diff'
seen   = ('@@ -1,5 +1,5 @@\n'
 '-Unit name: Test1\n'
 '+Unit name: Test2\n'
 ' Interfaces imported:\n'
 '-\t605070d38b135b920997a99ca17b8a60\tTest1\n'
 '+\t930b7a610c2f7452a7e77b08ef005d36\tTest2\n'
 ' \t2d082666be7fc2ba916e7233397491df\tStdlib\n'
 ' \tc4b583a727ec28f5bc9ba36adc64cfc7\tCamlinternalFormatBasics\n')


Okay. I will upload a version of diffoscope before the weekend that will
build successfully with both the version in unstable (currently
4.11.1) and this new proposed version (4.13.1).

Thanks for the bug report.


Regards,

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

Bug#996833: Please include information whether system is usrmerged or not

[Nis Martensen]

(I've merged #923090 and #996833 since they are asking the same. Adding
Guillem to CC here.)

On 19 Oct 2021 Michael Biebl wrote:
> given the decisions by the CTTE to go with a merged-/usr file system
> layout, I think it would be useful (at least during the transition
> phase), if reportbug included the information whether a system is
> already using such a file system layout or not.
> 
> reportbug already includes:
> 
> Shell: /bin/sh linked to /bin/dash
> 
> One can sort of deduce this information from the above line (on a
> merged-/usr system /bin/sh typically points to /usr/bin/dash)

Yes, I think this existing indicator is already reliable in practice.

(I've grepped through a few thousand random bug reports to see what
other shells besides bash and dash would turn up as link targets for
/bin/sh, and only found a handful instances of /bin/lksh and /bin/pdksh.
Not a problem with regard to detecting merged-/usr.)

Guillem, is this 'good enough' for you? Or does anyone still think there
is value in adding an explicit note about merged-/usr status even if the
actual information is already present?

Bug#1002789: python-pycdlib: FTBFS: failed tests

[Thomas Goirand]

Hi Lucas,

I wasn't able to reproduce the FTBFS. I'm using a normal sbuild
environment, so I don't see what's different from your build. Any clue?

Cheers,

Thomas Goirand (zigo)

Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

[Raphaël Hertzog]

Package: autopkgtest
Version: 5.19
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: hert...@debian.org

Usage of --pin-packages=kali-dev=src:foo results in a file like this
in /etc/apt/preferences.d/autopkgtest-kali-dev

Package:  foo
Pin: release a=kali-dev
Pin-Priority: 995

Unfortunately the "a=kali-dev" only matches on the "Suite" or "Archive"
field in the Release file, and not on the "Codename" field (which in my
caces was the only field available).

I noticed that /etc/apt/preferences.d/autopkgtest-default-release uses
another syntax that seems to cover more cases:

Package: *
Pin: release kali-rolling
Pin-Priority: 990

However that syntax doesn't seem to be documented in apt_preferences.
If it's correct and allows to check on either of the 3 fields, then
we should likely use the same syntax in both files.

Otherwise I would like to suggest to create two entries, one with
"Pin: release a=foo" and one with "Pin: release n=foo" so that
we are sure to match on any of the 3 fields.

Cheers,

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.3.13
ii  libdpkg-perl1.21.1
ii  procps  2:3.3.17-5
ii  python3 3.9.8-1
ii  python3-debian  0.1.42

Versions of packages autopkgtest recommends:
ii  autodep8  0.25

Versions of packages autopkgtest suggests:
pn  fakemachine   
pn  lxc   
pn  lxd   
ii  ovmf  2021.11-1
pn  ovmf-ia32 
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:6.1+dfsg-8+b2
ii  schroot   1.6.10-12
ii  vmdb2 0.24-1

-- no debconf information

Bug#1002795: [Pkg-mailman-hackers] Bug#1002795: mailman3-web: libapache2-mod-proxy-uwsgi is empty

[Pierre-Elliott Bécue]

Geert Stappers  wrote on 29/12/2021 at 00:18:38+0100:

> Package: mailman3-web
> Version: 0+20180916-8
>
>
> Hello pkg-mailman-hack...@lists.alioth.debian.org,
>
>
> In debian/control is `recommends: libapache2-mod-proxy-uwsgi | nginx`,
> but package `libapache2-mod-proxy-uwsgi` is empty. It became
> a _transitional package_.
> ( 
> https://salsa.debian.org/apache-team/apache2/-/blob/master/debian/changelog#L432
>  )
>
> For users of mailman3 with Apache it means that there is NO connection
> between the webserver and the Django app.
>
> Right now I don't know what the new 'recommends: ` should be.
> I'm only reporting "Apache webserver seems to mis a WSGI module".
>
>
> FWIW: I intent to report back when I have a working combination
> of mailman3-web and Apache2 webserver.
>
>
> Groeten

Hi Geert,

Thanks, I admit initially I had no plan on supporting apache2 as I don't
use it. Jonas did that part and therefore I did not follow at all.

Yet the changelogs you quote are back before buster release and I'm
quite sure Jonas had a working thing at that point.

I'm Cc-ing him, so that he can give an input.

Cheers!

-- 
PEB


signature.asc
Description: PGP signature

Bug#995399: bluez: bluetooth disable after few seconds - ADV Monitor

[Stefano Callegari]

Package: bluez
Version: 5.62-2
Followup-For: Bug #995399

Dear Maintainer,

yesterday I switch to win10 (dual boot) and bluetooth works so isn't a
hardware problem (good new!).

Back to Debian I done new tests.

Again the bluetoothd is up when I move the mouse and goes down if not, but
I've noticed a new line in system.log

Dec 29 10:36:43 G5045 bluetoothd[1386]: 
src/adv_monitor.c:btd_adv_monitor_power_down() Unexpected NULL 
btd_adv_monitor_manager object upon power down

after that the bluetooth is definitely disable!

Thanks


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

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

Versions of packages bluez depends on:
ii  dbus 1.12.20-3
ii  init-system-helpers  1.61
ii  kmod 29-1
ii  libasound2   1.2.5.1-1
ii  libc62.33-1
ii  libdbus-1-3  1.12.20-3
ii  libdw1   0.186-1
ii  libglib2.0-0 2.70.2-1
ii  libreadline8 8.1-2
ii  libudev1 249.7-1
ii  lsb-base 11.1.0
ii  udev 249.7-1

bluez recommends no packages.

Versions of packages bluez suggests:
pn  pulseaudio-module-bluetooth  

-- Configuration Files:
/etc/bluetooth/main.conf changed:
[General]
ControllerMode = dual
[BR]
[LE]
EnableAdvMonInterleaveScan=0
[GATT]
[AVDTP]
[Policy]
AutoEnable=true
[AdvMon]

/etc/default/bluetooth changed:
BLUETOOTH_ENABLED=1
HID2HCI_ENABLED=1
HID2HCI_UNDO=1


-- no debconf information

Bug#975300: closed by Thomas Goirand (Fixed)

[Salvatore Bonaccorso]

Source: ceph
Source-Version: 14.2.15-1

On Wed, Dec 29, 2021 at 09:21:07AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:ceph package:
> 
> #975300: ceph: CVE-2020-10753: radosgw: HTTP header injection via CORS 
> ExposeHeader tag
> 
> It has been closed by Thomas Goirand .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Thomas Goirand 
>  by
> replying to this email.
> 
> 
> -- 
> 975300: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975300
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> From: Thomas Goirand 
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
>  Thunderbird/78.14.0
> Date: Wed, 29 Dec 2021 10:20:03 +0100
> To: 975300-d...@bugs.debian.org
> Subject: Fixed
> Message-ID: 
> 
> This was fixed in Bullseye, and in unstable.

Right, TTBOMK, should be with the upload of 14.2.15-1 to unstable. So
marking it as such.

Regards,
Salvatore

Bug#1002803: openssh: typo in alternatives

[Neutron Soutmun]

Package: openssh-client
Version: 1:8.7p1-3
Followup-For: Bug #1002803

Hi,

I can confirm this issue and the patch proposed by Daniel works as expected.
Please consider to apply the patch.

Best regards,
Neutron Soutmun

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

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

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.21.1
ii  libc6 2.33-1
ii  libedit2  3.1-20210910-1
ii  libfido2-11.9.0-1
ii  libgssapi-krb5-2  1.18.3-7
ii  libselinux1   3.3-1+b1
ii  libssl1.1 1.1.1m-1
ii  passwd1:4.8.1-2
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages openssh-client recommends:
ii  xauth  1:1.1-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- Configuration Files:
/etc/ssh/ssh_config changed [not included]

-- no debconf information


signature.asc
Description: PGP signature

Bug#1002817: [openssh-client] package setup error: and can't be the same

[Lyndon Brown]

Package: openssh-client
Version: 1:8.7p1-3

Upgrading to this new version just now on Sid I encountered errors.

Relevant `sudo aptitude upgrade` output:

Preparing to unpack .../openssh-client_1%3a8.7p1-3_amd64.deb ...
Unpacking openssh-client (1:8.7p1-3) over (1:8.7p1-2) ...
Preparing to unpack .../libpipeline1_1.5.4-2_amd64.deb ...
Unpacking libpipeline1:amd64 (1.5.4-2) over (1.5.4-1) ...
Preparing to unpack .../archives/lzip_1.22-5_amd64.deb ...
Unpacking lzip (1.22-5) over (1.22-4) ...
Setting up libpipeline1:amd64 (1.5.4-2) ...
Setting up openssh-client (1:8.7p1-3) ...
update-alternatives:  and  can't be the same

Use 'update-alternatives --help' for program usage information.
dpkg: error processing package openssh-client (--configure):
 installed openssh-client package post-installation script subprocess returned 
error exit status 2
Setting up lzip (1.22-5) ...
update-alternatives: using /usr/bin/lzip.lzip to provide /usr/bin/lzip (lzip) 
in auto mode
update-alternatives: using /usr/bin/lzip.lzip to provide 
/usr/bin/lzip-compressor (lzip-compressor) in auto mode
update-alternatives: using /usr/bin/lzip.lzip to provide 
/usr/bin/lzip-decompressor (lzip-decompressor) in auto mode
Processing triggers for libc-bin (2.33-1) ...
Processing triggers for man-db (2.9.4-4) ...
Processing triggers for install-info (6.8-3) ...
Errors were encountered while processing:
 openssh-client
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up openssh-client (1:8.7p1-3) ...
update-alternatives:  and  can't be the same

Use 'update-alternatives --help' for program usage information.
dpkg: error processing package openssh-client (--configure):
 installed openssh-client package post-installation script subprocess returned 
error exit status 2
Errors were encountered while processing:
 openssh-client
 
Current status: 0 (-3) upgradable

Bug#1002699: libc6: m68k,sh4 readdir not returning filled in dirent pointer

[John Paul Adrian Glaubitz]

Hi Camm!

On 12/28/21 19:52, John Paul Adrian Glaubitz wrote:
> On 12/28/21 19:20, Camm Maguire wrote:
>> Correction, that is current autobuilders on 68k and sh4.
> 
> That's a known issue, see [1]. I will patch the glibc packages for m68k
> and sh4 again to address this issue.

I have uploaded patched versions of glibc for m68k and sh4 and blocked the
autobuild for glibc on the buildds.

You may want to merge the bug with the existing bug report [1] and adjust the
severity to normal.

Adrian


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

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

Bug#991609: postfix/postfix-script: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ

[Vincent Lefevre]

Hi,

On 2021-12-28 23:49:05 -0500, Scott Kitterman wrote:
> As far as I can tell, it's been a long time since postfix installed 
> smtp_tls_CAfile in the chroot and according to the documentation [1], it 
> doesn't look like it needs to be there.  Are you using ca-certificates.crt 
> for 
> anything other than smtp_tls_CAfile or smtpd_tls_CAfile?

I don't use it at all for postfix. It is postfix that chose to
copy it. And there's nothing about it in the postconf output.

> What happens if you manually delete
> /var/spool/postfix/etc/ssl/certs/ca-certificates.crt?

Nothing special.

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

Bug#1002805: systemd: Upon mount, immediately umounts external drives not connected at boot

[Michael Biebl]

Control: tags -1 + moreinfo

Please provide more information how exactly the external drive is 
mounted (e.g. if you mount it via a script, attach the script. If you 
mount it manually, provide the complete command line)


Also include the output of
blkid /dev/

 is what you use in your mount command

Also the complete /etc/fstab.

Also, please attach the journal from when you attach the external drive 
to the moment it is unmounted.






OpenPGP_signature
Description: OpenPGP digital signature