Bug#1060922: Status of debian-ports

[Dave Vasilevsky]

Hi Christoph,

Were you able to look into restoring some of the lost period of snapshots
for debian-ports? I've found a Debian derivative, MintPPC, that currently
seems to only be usable with snapshots from between Sep 2023 and Jan 2024,
so it would be very helpful.

Thanks,
vasi

Bug#1079725: linux: powerpc: 6.9+ kernel fails to boot from Open Firmware with CONFIG_CRASH_DUMP=y

[Dave Vasilevsky]

Package: src:linux
Version: 6.10.4-1
Severity: normal
File: linux
X-Debbugs-Cc: d...@vasilevsky.ca

Debian kernels 6.9 and higher fail to boot on most PowerPC 32-bit systems.
These kernels have CONFIG_CRASH_DUMP=y set. This yields the message:

> Error: You can't boot a kdump kernel from OF!

See discussion on the debian-powerpc list:

* Initial report: https://lists.debian.org/debian-powerpc/2024/07/msg1.html
* Verification that CONFIG_CRASH_DUMP is indeed the problem: 
https://lists.debian.org/debian-powerpc/2024/08/msg00018.html

This occurs due to a change upstream, that makes CRASH_DUMP enabled by default.
We're working on fixing this upstream: 
https://lore.kernel.org/lkml/87frqsghws.fsf@mail.lhotse/T/

In the meantime, Debian's kernel config should explicitly disable 
CONFIG_CRASH_DUMP on
32-bit powerpc.

-- Package-specific info:

** Kernel log: boot messages should be attached

Error: You can't boot a kdump kernel from OF!

** Model information
revision: 2.9 (pvr 000c 0209)
platform: PowerMac
model   : PowerMac3,1
machine : PowerMac3,1
motherboard : PowerMac3,1 MacRISC MacRISC2 Power Macintosh
Device Tree model: PowerMac3,1

** PCI devices:
00:0b.0 Host bridge [0600]: Apple Inc. UniNorth PCI [106b:001f]
Subsystem: Red Hat, Inc. Device [1af4:1100]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- 
SERR- 

Versions of packages linux-image-6.10.4-powerpc suggests:
pn  debian-kernel-handbook  
pn  firmware-linux-free 
ii  grub-ieee1275   2.12-5
pn  linux-doc-6.10  
pn  mkvmlinuz   

Versions of packages linux-image-6.10.4-powerpc is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1079048: unattended-upgrades: configuration ammendments

[Dave Love]

Package: unattended-upgrades
Version: 2.9.1+nmu3
Severity: normal
X-Debbugs-Cc: none, Dave Love 

The commented-out recipe for backports is wrong, confusing codename
and suite.  I corrected that in the attached patch and added a codename
variant.  I'm reporting against stable, but it's unchanged in the repo.

-- System Information:
Debian Release: 12.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bookworm-fasttrack'), (51, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12+bpo-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, 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 unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  lsb-release12.0-1
ii  python33.11.2-1+b1
ii  python3-apt2.6.0
ii  python3-dbus   1.3.2-4+b1
ii  python3-distro-info1.5+deb12u1
ii  sysvinit-utils [lsb-base]  3.06-4
ii  ucf3.0043+nmu1
ii  xz-utils   5.4.1-0.2

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-36
ii  cron [cron-daemon]  3.0pl1-162
ii  systemd-sysv252.26-1~deb12u2

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx   8.1.2-0.20220412cvs-1
ii  needrestart 3.6-4+deb12u1
ii  postfix [mail-transport-agent]  3.7.11-0+deb12u1
ii  powermgmt-base  1.37
ii  python3-gi  3.42.2-3+b1

-- debconf information:
* unattended-upgrades/enable_auto_updates: true

diff --git a/apt/apt.conf.d/50unattended-upgrades b/apt/apt.conf.d/50unattended-upgrades
index 1036e10..899f3ce 100644
--- a/apt/apt.conf.d/50unattended-upgrades
+++ b/apt/apt.conf.d/50unattended-upgrades
@@ -31,6 +31,7 @@ Unattended-Upgrade::Origins-Pattern {
 "origin=Debian,codename=${distro_codename},label=Debian";
 "origin=Debian,codename=${distro_codename},label=Debian-Security";
 "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
+//  "origin=Debian Backports,codename=${distro_codename}-backports,label=Debian Backports";
 
 // Archive or Suite based matching:
 // Note that this will silently match a different release after
@@ -39,7 +40,7 @@ Unattended-Upgrade::Origins-Pattern {
 //  "o=Debian,a=stable";
 //  "o=Debian,a=stable-updates";
 //  "o=Debian,a=proposed-updates";
-//  "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
+//  "o=Debian Backports,a=stable-backports,l=Debian Backports";
 };
 
 // Python regular expressions, matching packages to exclude from upgrading

Bug#1043037: mlmmj NMU into experimental (Was: Reasonable fork of MLMMJ available now)

[Dave Hibberd]

Hi all,

Is there any progress or another set of hands required on this?

I’d quite like to make use of the package over setting up mailman3!

Cheers
H 

--
  Hibby
  Debian Developer
  Packet Radioist
  MM0RFN

Bug#1078091: git: Unable to use git bisect run

[Dave Johansen]

Package: git
Version: 1:2.39.2-1.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
   - Trying to use git bisect run to find the cause of a bug
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   - Errors out whenever it's used
   * What was the outcome of this action?
   - Impossible to use git bisect run
   * What outcome did you expect instead?
   - git bisect run to work like other versions of Debian


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

Kernel: Linux 6.6.32-linuxkit (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages git depends on:
ii  git-man  1:2.39.2-1.1
ii  libc62.36-9+deb12u7
ii  libcurl3-gnutls  7.88.1-10+deb12u6
ii  liberror-perl0.17029-2
ii  libexpat12.5.0-1
ii  libpcre2-8-0 10.42-1
ii  perl 5.36.0-7+deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages git recommends:
ii  ca-certificates  20230311
pn  less 
ii  patch2.7.6-7
pn  ssh-client   

Versions of packages git suggests:
pn  gettext-base  
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

Bug#1077817: chirp: Reading from Quansheng causes logout

[Dave Hibberd]

Hi there, thanks for the bug! I’ll replicate it this afternoon and upload the 
latest one as there’s been a few updates to that driver since the last upload 
[1].

When you say the current version installed by python, do you mean installed via 
`pip3 install chirp`?

Are you running the regular firmware or another like egzumer?

[1] 
https://chirp.danplanet.com/projects/chirp/repository/github/changes/chirp/drivers/uvk5.py?rev=master

Cheers,

--
  Hibby
  Debian Developer
  Packet Radioist
  MM0RFN

> On 2 Aug 2024, at 19:05, Hilary Snaden  wrote:
> 
> Package: chirp
> Version: 1:20240413-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: hilary.sna...@zoho.com
> 
> Dear Maintainer,
> 
> Attempting to read the contents of two Quansheng UV-K5(8) transcievers has 
> causes logout, using the Debian package version and the current version 
> installed from Python, and on two different laptops running Debian. The 
> software still works normally with older Baofeng transcievers.
> 
> -- System Information:
> Debian Release: trixie/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.9.12-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages chirp depends on:
> ii  python3   3.12.3-1
> ii  python3-requests  2.32.3+dfsg-1
> ii  python3-serial3.5-2
> ii  python3-six   1.16.0-7
> ii  python3-yattag1.15.2-1
> ii  wxpython-tools4.2.1+dfsg-4
> 
> Versions of packages chirp recommends:
> ii  python3-suds  1.1.2-1
> 
> chirp suggests no packages.
> 
> -- no debconf information
> 

Bug#1076824: mirror listing update for debian.cs.binghamton.edu

[Dave Hall]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: debian.cs.binghamton.edu
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Dave Hall 
Country: US United States
Location: New York
Comment: Changing maintainer email.  It was daveh...@cs.binghamton.edu.
 
 Also, our mirror is fully accessible via HTTPS as well as HTTP.  However, we 
are not permitted to rsync.




Trace Url: http://debian.cs.binghamton.edu/debian/project/trace/
Trace Url: 
http://debian.cs.binghamton.edu/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.cs.binghamton.edu/debian/project/trace/debian.cs.binghamton.edu

Bug#1074250: ifupdown2 not working with python3.12

[Dave B]

Package: ifupdown2
Version: 3.0.0-1.1
Severity: grave
Tags: ipv6
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation? The upgrade to python3.12 which replaced 
"readfp" with "read_file)
   * What exactly did you do (or not do) that was effective (or ineffective)? I 
replaced "readfp" to read_file in /usr/share/ifupdown2/ifupdown/main.py and it 
fixed the problem.
   * What was the outcome of this action? ifup and ifdown started working 
properly.

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

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

Versions of packages ifupdown2 depends on:
ii  iproute2  6.9.0-1
ii  python3   3.12.2-1

ifupdown2 recommends no packages.

Versions of packages ifupdown2 suggests:
ii  bridge-utils 1.7.1-2
ii  ethtool  1:6.9-1
pn  isc-dhcp-client  
pn  python3-gvgen
pn  python3-mako 

-- no debconf information

Bug#1073790: cqrlog should depend on mariadb instead of mysql

[Dave Hibberd]

I got curious, as I can’t replicate the bug! I did an install of cqrlog on my 
dev machine - it ran first time. 

I checked and it has installed mariadb - cqrlog Depends: on 
default-mysql-client-core and default-mysql-server-core which are metapackages 
depending on mariadb-client-core and mariadb-server-core. 
There’s also a Recommends: on default-mysql-server which is a meta package 
depending on mariadb.

I went hunting through https://packages.ubuntu.com/noble/cqrlog and 
subsequently https://packages.ubuntu.com/noble/default-mysql-server-core to see 
ubuntu shipping mysql 8 series for these packages.

Something didn’t quite add up so I went digging further - it turns out that 
Ubuntu is shipping mysql-* as mysql-* and Debian is shipping mariadb-* as 
mysql-*, see:
https://salsa.debian.org/mariadb-team/mysql/-/blob/mysql-defaults/debian/master/debian/rules
 for the specific exception.

Maybe this is one the Ubuntu team need to solve?

Cheers,

--
  Hibby
  Debian Developer
  Packet Radioist
  MM0RFN

> On 18 Jun 2024, at 13:18, asciiw...@seznam.cz wrote:
> 
> Package: cqrlog
> Version: 2.5.2-4
> 
> CQRLOG seems to be incompatible with mysql-server and require mariadb-server. 
> There is an "Error during connection to database" message displayed on 
> startup and application exits. CQRLOG starts working correctly after running 
> "sudo apt install mariadb-server" (replacing the mysql server with mariadb).
> 
> Downstream Ubuntu issue: 
> https://bugs.launchpad.net/ubuntu/+source/cqrlog/+bug/1872002
> 

Bug#1072936: colordiff: Please package new upstream release 1.0.21

[Dave Ewart]

On Monday, 10.06.2024 at 11:58 -0400, Boyuan Yang wrote:

> A new upstream release of package colordiff 1.0.21 is now available.  Please
> consider packaging it in Debian. I can provide package upload sponsorship if
> you need it.

There weren't many changes between 1.0.20 and 1.0.21 so I didn't bother with the
build, especially since it was going to require a mentor upload like 1.0.20.

However if you're happy to do the sponsorship, that would be most helpful. I
keep having to remind myself how to do the builds, but will aim to get to it
when I have time at the weekend.

Thanks :-)

Dave.

-- 
Dave Ewart, da...@sungate.co.uk



signature.asc
Description: PGP signature

Bug#1072924: mirror submission for mirror.webworld.ie

[Dave Geoghegan]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.webworld.ie
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Dave Geoghegan 
Country: IE Ireland
Location: Dublin, Ireland
Sponsor: WebWorld https://www.webworld.host




Trace Url: http://mirror.webworld.ie/debian/project/trace/
Trace Url: http://mirror.webworld.ie/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.webworld.ie/debian/project/trace/mirror.webworld.ie

Bug#1069279: loading /etc/profile.d scripts should enforce consistent ordering

[Dave Holland]

On Fri, 19 Apr 2024 at 10:51, Santiago Vila  wrote:
> Thanks for the report. Is this not already addressed by the proposed
> patch in Bug #885414, in which we explicitly use run-parts --list
> to get the files to be processed?

Hi,

Thanks for the quick reply. I had only read the first few entries in
#885414 and assumed from the dates that it wasn't making progress. Now
I read to the end, I see it is active, and that using run-parts does
seem like it will cover this. Great!

I saw in #604918 that /etc/profile is deliberately not treated as a
conffile. Is there any way to get the new version installed on package
upgrade, other than an external configuration management system such
as Ansible?

Cheers,
Dave

Bug#1069279: loading /etc/profile.d scripts should enforce consistent ordering

[Dave Holland]

Package: base-files
Version: 12.4+deb12u5

The fragment in /etc/profile (copied from
/usr/share/base-files/profile) does not enforce a particular locale
when generating the list of /etc/profile.d/*.sh files to load. This
means that the ordering of those scripts is not predictable, but
depends on the locale (LC_ALL environment variable) of the user
logging in, when passed by sshd. This can lead to subtle misbehaviour
at best, or outright breakage at worst. A user should not be able to
influence the admin-configured script ordering which is set by those
filenames.

Suggested fix: explicitly set LC_ALL=C, to match the sort behaviour of
run-parts, and if necessary reset it afterwards.

thanks,
Dave

Bug#1067687: lcov: Missing runtime dependency on libtimedate-perl

[Dave Jones]

Source: lcov
Version: 1.15-1
Severity: important

Dear Maintainer,

While libtimedate-perl is included as a build dependency, it's missing 
from the runtime dependencies. However, the genhtml binary relies upon 
Date/Parse.pm which is provided by libtimedate-perl, hence it needs to 
be in the runtime dependencies too.

I suspect many users haven't noticed this as libtimedate-perl is pulled 
in by many other things too, but on a minimal cloud image this results 
in the following output when attempting to run genhtml:

   $ genhtml -o /tmp/i3-coverage/ i3.info
   Can't locate Date/Parse.pm in @INC (you may need to install the 
   Date::Parse module) (@INC contains: /etc/perl 
   /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 
   /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 
   /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
   /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 
   /usr/local/lib/site_perl) at /usr/bin/genhtml line 89.

Bug#1054130: It probably was trivial

[Dave Vehrs]

> It looks as if the URI may have changed. Anyway adding
> OPT_CONTENT_DISPOSITION
> to the entry works and the remainder of the list now completes.
> So a minor bug I guess

I noticed from the first email that the version of Podget that you are
reporting the bug for is 0.9.1-1 and the system is using Trixie/Sid.

I also notice that the bug was submitted on October 17, 2023.  Since
then a new version of Podget has been released that addressed a few
issues like this one.

Now it is possible that I forgot to close this bug when I published the
latest release.  You might even say probable.

I tested the serverlist entry you gave in the first email with the
0.9.3-1 and didn't see any issues.

I will look into closing this report.

Thanks for the update.
Dave


-- 
Dave VehrsEmail: dve...@gmail.com

Bug#1061692: chirp fails to start with 'No module named 'chirp.stock_configs'

[Dave Hibberd]

Hi there,

Thanks for the bug and turning around a patch so quickly - it didn't show up in 
my test, I wonder what was different about my config!

I'll build and test in a clean environment later on and upload when I can!

Cheers,
DH

-- 
  Hibby
  MM0RFN

On Mon, 29 Jan 2024, at 2:57 AM, Harlan Lieberman-Berg wrote:
> tag 1061692 +patch
> thanks
>
> I've tested it, and it seems that manually adding the path to
> d/install fixes the problem fine.  Patch attached.
>
> Sincerely,
>
> -- 
> Harlan Lieberman-Berg
> ~hlieberman
>
> Attachments:
> * 0001-Ensure-stock-configs-are-installed-Closes-1061692.patch

Bug#1004844: games-finest: Consider adding endless-sky

[Dave Vasilevsky]

Hi again. It looks like endless-sky 0.10.2 has been in testing for awhile,
with no reported bugs. This version is quite new, updated in 2023. What do
you think about adding it to games-finest now?

Cheers,
vasi

On Fri, Aug 11, 2023 at 5:54 PM Dave Vasilevsky  wrote:

> Looks like #944757 is resolved now! Hopefully once the new versions gets
> into testing, this is unblocked.
>

Bug#1057573: linpac: FTBFS: error: invalid use of incomplete type ‘WINDOW’ {aka ‘struct _win_st’}

[Dave Hibberd]

The patch is only on git - no one has yet uploaded it to the archive to formally resolve the bug yet.Before January 16 it needs to be uploaded. I can probably mark it as hold on the bug tracker when I have my reference for tags at home.Between us we should be able to manage! Either I’ll pull something together for a sponsored upload on Sunday or I’ll have an idea on my new member process before then!CheersDHOn 5 Jan 2024, at 17:35, David Ranch  wrote:
  

  
  
Hello Dave,
  
  I received the following email yesterday which gives me the
  impression that your patch wasn't accepted.  What needs to be done
  here by Jan 16th?
  --
linpac 0.28-2 is marked for autoremoval from testing on 2024-01-16

It is affected by these RC bugs:
1057573: linpac: FTBFS: error: invalid use of incomplete type ‘WINDOW’ {aka ‘struct _win_st’}
 https://bugs.debian.org/1057573


This mail is generated by:
https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

Autoremoval data is generated by:
https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
--


On 01/01/2024 08:55 AM, Dave Hibberd
  wrote:


  
  Hi there! 
  
  
  Yeah I’ve pushed his patch already to our git, so if anyone
else on the team wants to upload it they can - I am still
waiting on our account managers to finalise my Debian developer
application before I have free reign to upload things,  and I’ll
switch this package to fall under my ownership like a collection
of other packet things to make life a little easier going
forward.


Cheers
DH

  On 1 Jan 2024, at 16:46, David Ranch
 wrote:

  


  

Hello DaveH,
  
  I have pushed the required fixes to the develop branch of
  Linpac.  I do plan on adding some other enhancements to
  Linpac before publishing an new official release but I
  don't know if getting out this fix is important to the
  Debian release process.  Maybe the similar third party fix
  offered by Sven is good enough for
  now to keep Linpac in the Debian Unstable/Testing repos?
  
  --David
  KI6ZHD
  
  

On 12/18/2023 02:40 AM, Dave
  Hibberd wrote:


  
  Hi
both,
  
  
  
  I'll
prepare a team upload for this in advance of the new
upstream release (thanks David), and upload it
independently or with support depending on the outcome
of the DAM stage of my NM process (https://nm.debian.org/process/1224/)
  
  
  Cheers
  
  DH
  
  
  
  
-- 

  Hibby

  MM0RFN

  
  
  
  On Sat, 16 Dec 2023, at 6:32 PM, David Ranch wrote:
  
  
Hello Sven, Debian
team,

I was about to apply a very similar fix to the
"develop" branch of Linpac at https://sourceforge.net/p/linpac/linpac/ci/develop/tree
though my changes didn't include the "-1" at the end
of the changes.  Not sure if that's needed /
important.  Regardless, I am planning to eventually
merge the develop branch into the Master branch and
releae 0.29 in the near future which will include
this and other fixes.

--David
KI6ZHD

  
On 12/16/2023 10:01 AM,
  Sven Joachim wrote:


  Control: tags -1 + patch

On 2023-12-05 23:07 +0100, Santiago Vila wrote:



  
Package: src:linpac
Version: 0.28-2
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:


[...]
g++ -DHAVE_CONFIG_H -I. -I../../..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c -o mail_screen.o mail_screen.cc
mail_screen.cc: In function ‘void init_main_scr

Bug#1059387: exim4: CVE-2023-51766

[Dave Page]

On Sun, 31 Dec 2023 13:21:09 +0100 Andreas Metzler  wrote:

> Disable CHUNKING advertisement for incoming connections.
> Disable PIPELINING advertisement for incoming connections.

It's worth noting in this bug report that these can be achieved by the 
following lines in an Exim config:


chunking_advertise_hosts =
pipelining_advertise_hosts =

Cheers,
Dave

Bug#1057573: linpac: FTBFS: error: invalid use of incomplete type ‘WINDOW’ {aka ‘struct _win_st’}

[Dave Hibberd]

Hi there! 

Yeah I’ve pushed his patch already to our git, so if anyone else on the team 
wants to upload it they can - I am still waiting on our account managers to 
finalise my Debian developer application before I have free reign to upload 
things,  and I’ll switch this package to fall under my ownership like a 
collection of other packet things to make life a little easier going forward.

Cheers
DH

> On 1 Jan 2024, at 16:46, David Ranch  wrote:
> 
>  Hello DaveH,
> 
> I have pushed the required fixes to the develop branch of Linpac.  I do plan 
> on adding some other enhancements to Linpac before publishing an new official 
> release but I don't know if getting out this fix is important to the Debian 
> release process.  Maybe the similar third party fix offered by Sven is good 
> enough for now to keep Linpac in the Debian Unstable/Testing repos?
> 
> --David
> KI6ZHD
> 
> 
> 
> On 12/18/2023 02:40 AM, Dave Hibberd wrote:
>> Hi both,
>> 
>> I'll prepare a team upload for this in advance of the new upstream release 
>> (thanks David), and upload it independently or with support depending on the 
>> outcome of the DAM stage of my NM process 
>> (https://nm.debian.org/process/1224/)
>> 
>> Cheers
>> DH
>> 
>> -- 
>>   Hibby
>>   MM0RFN
>> 
>> On Sat, 16 Dec 2023, at 6:32 PM, David Ranch wrote:
>>> Hello Sven, Debian team,
>>> 
>>> I was about to apply a very similar fix to the "develop" branch of Linpac 
>>> at https://sourceforge.net/p/linpac/linpac/ci/develop/tree though my 
>>> changes didn't include the "-1" at the end of the changes.  Not sure if 
>>> that's needed / important.  Regardless, I am planning to eventually merge 
>>> the develop branch into the Master branch and releae 0.29 in the near 
>>> future which will include this and other fixes.
>>> 
>>> --David
>>> KI6ZHD
>>> 
>>> On 12/16/2023 10:01 AM, Sven Joachim wrote:
>>>> Control: tags -1 + patch
>>>> 
>>>> On 2023-12-05 23:07 +0100, Santiago Vila wrote:
>>>> 
>>>> 
>>>>> Package: src:linpac
>>>>> Version: 0.28-2
>>>>> Severity: serious
>>>>> Tags: ftbfs
>>>>> 
>>>>> Dear maintainer:
>>>>> 
>>>>> During a rebuild of all packages in unstable, your package failed to 
>>>>> build:
>>>>> 
>>>>> 
>>>>> [...]
>>>>> g++ -DHAVE_CONFIG_H -I. -I../../..   -Wdate-time -D_FORTIFY_SOURCE=2  -g 
>>>>> -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
>>>>> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
>>>>> -c -o mail_screen.o mail_screen.cc
>>>>> mail_screen.cc: In function ‘void init_main_screen()’:
>>>>> mail_screen.cc:39:16: error: invalid use of incomplete type ‘WINDOW’ {aka 
>>>>> ‘struct _win_st’}
>>>>>39 |   maxx = stdscr->_maxx;
>>>>>   |^~
>>>>> In file included from mail_screen.cc:13:
>>>>> /usr/include/curses.h:442:16: note: forward declaration of ‘WINDOW’ {aka 
>>>>> ‘struct _win_st’}
>>>>>   442 | typedef struct _win_st WINDOW;
>>>>>   |^~~
>>>>> mail_screen.cc:40:16: error: invalid use of incomplete type ‘WINDOW’ {aka 
>>>>> ‘struct _win_st’}
>>>>>40 |   maxy = stdscr->_maxy;
>>>>>   |^~
>>>>> /usr/include/curses.h:442:16: note: forward declaration of ‘WINDOW’ {aka 
>>>>> ‘struct _win_st’}
>>>>>   442 | typedef struct _win_st WINDOW;
>>>>>   |^~~
>>>>> mail_screen.cc: In function ‘void redraw()’:
>>>>> mail_screen.cc:70:15: error: invalid use of incomplete type ‘WINDOW’ {aka 
>>>>> ‘struct _win_st’}
>>>>>70 |main_window->_clear = TRUE;
>>>>>   |   ^~
>>>>> /usr/include/curses.h:442:16: note: forward declaration of ‘WINDOW’ {aka 
>>>>> ‘struct _win_st’}
>>>>>   442 | typedef struct _win_st WINDOW;
>>>>> 
>>>> The attached patch, which can be added to the series file fixes, these
>>>> errors and two additional ones in src/linpac.cc, but I have only tested
>>>> that the package builds, not if it works.  Note that getmaxx(win)
>>>> returns win->_maxx + 1, and similar for getmaxy.
>>>> 
>>>> Cheers,
>>>>Sven
>>>> 
>>>> 
>> 
> 

Bug#1057573: linpac: FTBFS: error: invalid use of incomplete type ‘WINDOW’ {aka ‘struct _win_st’}

[Dave Hibberd]

Hi both,

I'll prepare a team upload for this in advance of the new upstream release 
(thanks David), and upload it independently or with support depending on the 
outcome of the DAM stage of my NM process (https://nm.debian.org/process/1224/)

Cheers
DH

-- 
  Hibby
  MM0RFN

On Sat, 16 Dec 2023, at 6:32 PM, David Ranch wrote:
> Hello Sven, Debian team,
> 
> I was about to apply a very similar fix to the "develop" branch of Linpac at 
> https://sourceforge.net/p/linpac/linpac/ci/develop/tree though my changes 
> didn't include the "-1" at the end of the changes.  Not sure if that's needed 
> / important.  Regardless, I am planning to eventually merge the develop 
> branch into the Master branch and releae 0.29 in the near future which will 
> include this and other fixes.
> 
> --David
> KI6ZHD
> 
> On 12/16/2023 10:01 AM, Sven Joachim wrote:
>> Control: tags -1 + patch
>> 
>> On 2023-12-05 23:07 +0100, Santiago Vila wrote:
>> 
>> 
>>> Package: src:linpac
>>> Version: 0.28-2
>>> Severity: serious
>>> Tags: ftbfs
>>> 
>>> Dear maintainer:
>>> 
>>> During a rebuild of all packages in unstable, your package failed to build:
>>> 
>>> 
>>> [...]
>>> g++ -DHAVE_CONFIG_H -I. -I../../..   -Wdate-time -D_FORTIFY_SOURCE=2  -g 
>>> -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
>>> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
>>> -c -o mail_screen.o mail_screen.cc
>>> mail_screen.cc: In function ‘void init_main_screen()’:
>>> mail_screen.cc:39:16: error: invalid use of incomplete type ‘WINDOW’ {aka 
>>> ‘struct _win_st’}
>>>39 |   maxx = stdscr->_maxx;
>>>   |^~
>>> In file included from mail_screen.cc:13:
>>> /usr/include/curses.h:442:16: note: forward declaration of ‘WINDOW’ {aka 
>>> ‘struct _win_st’}
>>>   442 | typedef struct _win_st WINDOW;
>>>   |^~~
>>> mail_screen.cc:40:16: error: invalid use of incomplete type ‘WINDOW’ {aka 
>>> ‘struct _win_st’}
>>>40 |   maxy = stdscr->_maxy;
>>>   |^~
>>> /usr/include/curses.h:442:16: note: forward declaration of ‘WINDOW’ {aka 
>>> ‘struct _win_st’}
>>>   442 | typedef struct _win_st WINDOW;
>>>   |^~~
>>> mail_screen.cc: In function ‘void redraw()’:
>>> mail_screen.cc:70:15: error: invalid use of incomplete type ‘WINDOW’ {aka 
>>> ‘struct _win_st’}
>>>70 |main_window->_clear = TRUE;
>>>   |   ^~
>>> /usr/include/curses.h:442:16: note: forward declaration of ‘WINDOW’ {aka 
>>> ‘struct _win_st’}
>>>   442 | typedef struct _win_st WINDOW;
>>> 
>> The attached patch, which can be added to the series file fixes, these
>> errors and two additional ones in src/linpac.cc, but I have only tested
>> that the package builds, not if it works.  Note that getmaxx(win)
>> returns win->_maxx + 1, and similar for getmaxy.
>> 
>> Cheers,
>>Sven
>> 
>> 

Bug#516152: Patch to fix the documentation

[Dave Jones]

Attaching an updated patch based on the current state of unstable. Some 
bits of the prior patch already appeared in the documentation, other 
bits needed a little re-working, but the intent is the same: the 
behaviour of bash is unchanged, this just changes the documentation to 
match the behaviour.


Best regards,

Dave Jones.
diff --git a/debian/changelog b/debian/changelog
index cd2b7c6d..b645fec8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+bash (5.2.15-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/man-bashrc.diff: Correct the bash(1) man-page to note that --rcfile
+does not prevent the execution of the system-wide /etc/bash.bashrc file.
+Closes: #516152.
+
+ -- Dave Jones   Tue, 14 Nov 2023 11:31:40 +
+
 bash (5.2.15-2) unstable; urgency=medium
 
   * Remove one more pdf file without source. Closes: #1024598.
diff --git a/debian/patches/man-bashrc.diff b/debian/patches/man-bashrc.diff
index 300d3ebf..1602a98c 100644
--- a/debian/patches/man-bashrc.diff
+++ b/debian/patches/man-bashrc.diff
@@ -2,17 +2,17 @@
 
 --- a/doc/bash.1
 +++ b/doc/bash.1
-@@ -187,7 +187,9 @@ Display a usage message on standard outp
- .PD
- Execute commands from
- .I file
--instead of the standard personal initialization file
-+instead of the system wide initialization file
-+.I /etc/bash.bashrc
-+and the standard personal initialization file
- .I ~/.bashrc
+@@ -192,7 +192,9 @@ instead of the standard personal initial
  if the shell is interactive (see
  .SM
+ .B INVOCATION
+-below).
++below). Note that the system wide initialization file
++.I /etc/bash.bashrc
++is still executed.
+ .TP
+ .B \-\-login
+ Equivalent to \fB\-l\fP.
 @@ -218,7 +220,9 @@ reads these files when it is invoked as
  below).
  .TP
@@ -36,13 +36,12 @@
  option.
  The \fB\-\-rcfile\fP \fIfile\fP option will force
  .B bash
--to read and execute commands from \fIfile\fP instead of \fI~/.bashrc\fP.
-+to read and execute commands from \fIfile\fP instead of
-+\fI/etc/bash.bashrc\fP and \fI~/.bashrc\fP.
+ to read and execute commands from \fIfile\fP instead of \fI~/.bashrc\fP.
++Note that \fI/etc/bash.bashrc\fP will still be read.
  .PP
  When
  .B bash
-@@ -426,8 +432,8 @@ or the secure shell daemon \fIsshd\fP.
+@@ -426,14 +432,15 @@ or the secure shell daemon \fIsshd\fP.
  If
  .B bash
  determines it is being run non-interactively in this fashion,
@@ -53,7 +52,15 @@
  It will not do this if invoked as \fBsh\fP.
  The
  .B \-\-norc
-@@ -11581,6 +11587,9 @@ The \fBbash\fP executable
+ option may be used to inhibit this behavior, and the
+ .B \-\-rcfile
+-option may be used to force another file to be read, but neither
++option may be used to force another file to be read instead of
++\fI~/.bashrc\fP, but neither
+ \fIrshd\fP nor \fIsshd\fP generally invoke the shell with those options
+ or allow them to be specified.
+ .PP
+@@ -11672,6 +11679,9 @@ The \fBbash\fP executable
  .FN /etc/profile
  The systemwide initialization file, executed for login shells
  .TP

Bug#1055468: [3dprinter-general] Bug#1055468: python3-charon: Warning during boot about "Unknown username "ultimaker" in message bus configuration file"

[Dave Williams]

Hi Gregor,

Thanks for looking into it and the quick response. As it's benign I might just 
leave it be... I'm considering moving that machine forward to Testing anyway.

Best regards,
Dave

On 8 Nov 2023, 07:45, at 07:45, Gregor Riepl  wrote:
>Hi Dave,
>
>> Since it's just a warning, I wouldn't touch it. Stable updates are
>> possible, but need poking the stable release managers who have more
>> interesting problems to fix.
>
>In that case, I recommend comparing the list of files and removing
>what's not needed:
>
>https://packages.debian.org/bookworm/all/python3-charon/filelist
>->
>https://packages.debian.org/trixie/all/python3-charon/filelist
>
>You can basically delete /lib/systemd/system/charon.service and
>/usr/share/dbus-1/system.d/nl.ultimaker.charon.conf on your system to
>get rid of the warning.
>
>It's not a persistent change, but it's unlikely that there will be an
>update to the package in stable.
>
>Regards,
>Gregor

Bug#1055468: python3-charon: Warning during boot about "Unknown username "ultimaker" in message bus configuration file"

[Dave Williams]

Package: python3-charon
Version: 4.13.0-2
Severity: normal

Dear Maintainer,

During boot, I get a warning about a missing username "ultimaker". As far as I 
can tell this stems from the dbus configuration file packaged with 
python3-charon (/usr/share/dbus-1/system.d/nl.ultimaker.charon.conf) (I don't 
think it's the systemd configuration file that mentions the same user 
(/lib/systemd/system/charon.service), as I'm running Devuan with OpenRC).
I guess the easy fix for this would be to add the username - maybe that should 
be part of the package installation scripts though?

I've not noticed any other conseqences, so I'm assuming this is pretty trivial, 
but I don't have an ultimaker printer.

Hope this is useful. If not, no worries.


-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages python3-charon depends on:
ii  python33.11.2-1+b1
ii  python3-dbus   1.3.2-4+b1
ii  python3-gi 3.42.2-3+b1
ii  python3-pyqt5  5.15.9+dfsg-1

python3-charon recommends no packages.

python3-charon suggests no packages.

-- no debconf information

Bug#1014017: soundmodem: Fails to build with HID support

[Dave Hibberd]

Hi Alan,

I'm part of quite an active packet communtiy (https://ukpacketradio.network/) - 
DINAH looks like a cool item a number of folks would be itnerested in! Not many 
of our users are on soundmodem - direwolf, G8BPQ's QtSoundmodem (which I plan 
to upload to Debian) and (in hardware) NinoTNC are the flavour of the month for 
us.

I know of a few CM108 mods (our sister communtiy even has a guide - 
https://wiki.oarc.uk/cm108_sound_interface_smd) 
, so extending 
functionality to more people would be generally of benefit to all.

Soundmodem is a little old, but it's also not moving very fast so I don't see 
too much overhead in maintaining a patch for it unless it's likely to degrade 
the experience for other users?

Cheers
DH

-- 
  Hibby
  MM0RFN

On Thu, 2 Nov 2023, at 2:45 PM, Alan Crosswell wrote:
> Hey Daniele,
> 
> It's been about a year and I've just now gotten around to building a 
> Raspberry Pi connected to a DINAH and can confirm that this PTT patch still 
> works on the latest Raspi Bullseye distro. I don't know if there's any 
> interest in carrying this forward to a committed patch for soundmodem. I can 
> always keep patching it myself if I'm the only one who still thinks 
> soundmodem is a nice small tool for AX.25.
> 
> Regarding many more CM108's, I wonder how many of them are integrated such 
> that a spare GPIO pin is used for PTT? Given it's probably not a lot, I 
> wouldn't think removing the device test entirely would be a huge issue. Would 
> you like me to submit a revised PR to do that?
> 
> 73 de N2YGK
> 
> On Mon, 24 Oct 2022 09:14:23 -0400 Alan Crosswell  wrote:
> > Yeah I don't know that ignoring the device code would be much of a problem.
> > It's not like it searches available devices to see which one to use; the
> > specific device to use is specified.
> > 
> > On Sun, Oct 23, 2022 at 3:10 PM Daniele Forsi  wrote:
> > 
> > > Hello Alan,
> > >
> > > I committed your patch to configure.ac in a branch and I think that we
> > > should merge it to master:
> > > https://salsa.debian.org/debian-hamradio-team/soundmodem/-/tree/hidraw
> > >
> > > I didn't commit your patch to ptt.c yet.
> > > What happens if we drop the check for hiddevinfo.product for C-Media
> > > entirely?
> > >
> > > You changed the test to work with your hardware, which is fine, but it
> > > seems that there are many more CM108s out there (I have one with ID
> > > 0d8c:013c).
> > > I'm copying the list from https://usb-ids.gowdy.us/read/UD/0d8c so it
> > > is archived with this bug report.
> > >
> > > Id Name
> > > 0001 Audio Device
> > > 0002 Composite Device
> > > 0003 Sound Device
> > > 0004 CM6631A Audio Processor
> > > 0005 Blue Snowball
> > > 0006 Storm HP-USB500 5.1 Headset
> > > 000c Audio Adapter
> > > 000d Composite Device
> > > 000e Audio Adapter (Planet UP-100, Genius G-Talk)
> > > 0012
> > > 0014 Audio Adapter (Unitek Y-247A)
> > > 001f CM108 Audio Controller
> > > 0029
> > > 0102 CM106 Like Sound Device
> > > 0103 CM102-A+/102S+ Audio Controller
> > > 0104 CM103+ Audio Controller
> > > 0105 CM108 Audio Controller
> > > 0107 CM108 Audio Controller
> > > 010f CM108 Audio Controller
> > > 0115 CM108 Audio Controller
> > > 0134
> > > 0139 Multimedia Headset [Gigaware by Ignition L.P.]
> > > 013c CM108 Audio Controller
> > > 0201 CM6501
> > > 5000 Mass Storage Controller
> > > 5200 Mass Storage Controller(0D8C,5200)
> > > b213 USB Phone CM109 (aka CT2000,VPT1000)
> > >
> > > --
> > > 73 de IU5HKX Daniele
> > >

Bug#1053985: pass-otp: HOTP counter update is broken

[Dave Love]

Package: pass-otp
Version: 1.2.0-7
Severity: important
X-Debbugs-Cc: none, Dave Love 
Tags: patch

With bookworm's version of bash, updating the HOTP counter after
generating a code stores an invalid URI -- missing an "&" --
e.g. "&counter=1counter=2" as reported, but not fixed, upstream.  I'm
attaching a fix, hoping a diff of the packaging is a suitable form.

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

Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, 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 pass-otp depends on:
ii  pass  1.7.4-6

Versions of packages pass-otp recommends:
ii  oathtool  2.6.7-3.1
ii  qrencode  4.1.1-1

Versions of packages pass-otp suggests:
pn  zbar-tools  

-- no debconf information

diff -rN -u old-pass-otp-1.2.0-7/debian/changelog new-pass-otp-1.2.0-7/debian/changelog
--- old-pass-otp-1.2.0-7/debian/changelog	2023-10-14 17:12:09.721677669 +0100
+++ new-pass-otp-1.2.0-7/debian/changelog	2023-10-14 17:12:09.721677669 +0100
@@ -1,3 +1,9 @@
+pass-otp (1.2.0-8) unstable; urgency=medium
+
+  * Fix broken HOTP counter updating with bash 5.2
+
+ -- Dave Love   Sat, 14 Oct 2023 14:33:51 +0100
+
 pass-otp (1.2.0-7) unstable; urgency=medium
 
   * Bump Standards-Version to 4.6.2 (no changes necessary)
diff -rN -u old-pass-otp-1.2.0-7/debian/patches/bash5.2.patch new-pass-otp-1.2.0-7/debian/patches/bash5.2.patch
--- old-pass-otp-1.2.0-7/debian/patches/bash5.2.patch	1970-01-01 01:00:00.0 +0100
+++ new-pass-otp-1.2.0-7/debian/patches/bash5.2.patch	2023-10-14 17:12:09.721677669 +0100
@@ -0,0 +1,19 @@
+Description: Fix broken HOTP counter updating with bash 5.2
+Forwarded: no
+Bug: https://github.com/tadfisher/pass-otp/issues/171
+Author: Dave Love 
+Last-Update: 2023-10-14
+
+Index: pass-otp-1.2.0/otp.bash
+===
+--- pass-otp-1.2.0.orig/otp.bash
 pass-otp-1.2.0/otp.bash
+@@ -357,7 +357,7 @@ cmd_otp_code() {
+ 
+   if [[ "$otp_type" == "hotp" ]]; then
+ # Increment HOTP counter in-place
+-local line replaced uri=${otp_uri/&counter=$otp_counter/&counter=$counter}
++local line replaced uri=${otp_uri/&counter=$otp_counter/\&counter=$counter}
+ while IFS= read -r line; do
+   [[ "$line" == otpauth://* ]] && line="$uri"
+   [[ -n "$replaced" ]] && replaced+=$'\n'
diff -rN -u old-pass-otp-1.2.0-7/debian/patches/mark_test_bash5.2.patch new-pass-otp-1.2.0-7/debian/patches/mark_test_bash5.2.patch
--- old-pass-otp-1.2.0-7/debian/patches/mark_test_bash5.2.patch	2023-10-14 17:12:09.721677669 +0100
+++ new-pass-otp-1.2.0-7/debian/patches/mark_test_bash5.2.patch	1970-01-01 01:00:00.0 +0100
@@ -1,24 +0,0 @@
-Author: Philip Rinn 
-Description: Mark tests failing that are buggy with bash 5.2~rc2
-Forwarded: not-needed
-Last-update: 2022-09-05
 a/test/code.t
-+++ b/test/code.t
-@@ -19,7 +19,7 @@
-   [[ ${#code} -eq 6 ]]
- '
- 
--test_expect_success 'Generates HOTP code and increments counter' '
-+test_expect_failure 'Generates HOTP code and increments counter' '
-   uri="otpauth://hotp/Example:al...@google.com?secret=JBSWY3DPEHPK3PXP&counter=10&issuer=Example"
-   inc="otpauth://hotp/Example:al...@google.com?secret=JBSWY3DPEHPK3PXP&counter=11&issuer=Example"
- 
-@@ -30,7 +30,7 @@
-   [[ $("$PASS" otp uri passfile) == "$inc" ]]
- '
- 
--test_expect_success 'HOTP counter increments and preserves multiline contents' '
-+test_expect_failure 'HOTP counter increments and preserves multiline contents' '
-   uri="otpauth://hotp/Example:al...@google.com?secret=JBSWY3DPEHPK3PXP&counter=10&issuer=Example"
-   inc="otpauth://hotp/Example:al...@google.com?secret=JBSWY3DPEHPK3PXP&counter=11&issuer=Example"
- 
diff -rN -u old-pass-otp-1.2.0-7/debian/patches/series new-pass-otp-1.2.0-7/debian/patches/series
--- old-pass-otp-1.2.0-7/debian/patches/series	2023-10-14 17:12:09.721677669 +0100
+++ new-pass-otp-1.2.0-7/debian/patches/series	2023-10-14 17:12:09.721677669 +0100
@@ -1 +1 @@
-mark_test_bash5.2.patch
+bash5.2.patch

Bug#1051914:

[Dave Vasilevsky]

(Sorry for filing the bug report on an Ubuntu box, my Debian machine is
currently under repair. But the bug really does apply to Debian.)

Note also that this feature relies on switcheroo-control, which should
probably be a Recommends now.

Bug#1051914: kio: Update kio to 5.109+

[Dave Vasilevsky]

Package: kio
Version: 5.107.0-1
Severity: wishlist
X-Debbugs-Cc: d...@vasilevsky.ca

Version 5.110 of kio is out now. In 5.109, we added support in kio for
launching apps in KDE using hybrid GPUs, which significantly improves the
usability of games such as supertuxkart.


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

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

Versions of packages kio depends on:
ii  kded5 5.92.0-0ubuntu1
ii  libacl1   2.3.1-1
ii  libc6 2.35-0ubuntu3.1
ii  libgcc-s1 12.3.0-1ubuntu1~22.04
ii  libgssapi-krb5-2  1.19.2-2ubuntu0.2
ii  libkf5archive55.92.0-0ubuntu1
ii  libkf5authcore5   5.92.0-0ubuntu1
ii  libkf5codecs5 5.92.0-0ubuntu1
ii  libkf5configcore5 5.92.0-0ubuntu1
ii  libkf5configwidgets5  5.92.0-0ubuntu1
ii  libkf5coreaddons5 5.92.0-0ubuntu1
ii  libkf5dbusaddons5 5.92.0-0ubuntu1
ii  libkf5doctools5   5.92.0-0ubuntu1
ii  libkf5i18n5   5.92.0-0ubuntu2
ii  libkf5itemviews5  5.92.0-0ubuntu1
ii  libkf5kiocore55.92.0-0ubuntu1
ii  libkf5kiogui5 5.92.0-0ubuntu1
ii  libkf5kiontlm55.92.0-0ubuntu1
ii  libkf5kiowidgets5 5.92.0-0ubuntu1
ii  libkf5notifications5  5.92.0-0ubuntu1
ii  libkf5service-bin 5.92.0-0ubuntu1
ii  libkf5service55.92.0-0ubuntu1
ii  libkf5solid5  5.92.0-0ubuntu1
ii  libkf5textwidgets55.92.0-0ubuntu1
ii  libkf5wallet-bin  5.92.0-0ubuntu1
ii  libkf5wallet5 5.92.0-0ubuntu1
ii  libkf5widgetsaddons5  5.92.0-0ubuntu1
ii  libkf5windowsystem5   5.92.0-0ubuntu1
ii  libqt5core5a  5.15.3+dfsg-2ubuntu0.2
ii  libqt5dbus5   5.15.3+dfsg-2ubuntu0.2
ii  libqt5gui55.15.3+dfsg-2ubuntu0.2
ii  libqt5network55.15.3+dfsg-2ubuntu0.2
ii  libqt5qml55.15.3+dfsg-1
ii  libqt5widgets55.15.3+dfsg-2ubuntu0.2
ii  libqt5x11extras5  5.15.3-1
ii  libqt5xml55.15.3+dfsg-2ubuntu0.2
ii  libstdc++612.3.0-1ubuntu1~22.04
ii  libxml2   2.9.13+dfsg-1ubuntu0.3
ii  libxslt1.11.1.34-4ubuntu0.22.04.1

kio recommends no packages.

kio suggests no packages.

-- no debconf information

Bug#1004844: games-finest: Consider adding endless-sky

[Dave Vasilevsky]

Looks like #944757 is resolved now! Hopefully once the new versions gets
into testing, this is unblocked.

Bug#1041447: comitup: fails to install, remove, distupgrade, and install again

[Dave Steele]

On Tue, Jul 18, 2023 at 10:39 PM Andreas Beckmann  wrote:
>
> Package: comitup
> Version: 1.38-1.1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package failed to install
> (in 'bullseye'), remove (but not purge), distupgrade to 'bookworm',
> and install again.
> Before the second installation the package is in config-files-remaining
> state. The configuration is remaining from the last version that was
> successfully configured - which is from the previous release.
>

What piuparts section is this?

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

[Dave Jones]

Hi Vagrant,

Heinrich Schuchardt and I were just having a look at this area for the 
ubuntu packaging, specifically whether to include 
u-boot-sunxi-with-spl.bin in the u-boot-sunxi build (and whether to poke 
upstream to update the README that gets included by u-boot-sunxi.docs), 
and ran across this bug while seeing if anything had been considered in 
this area up in Debian.


Is this still on the cards post-bookworm?

Thanks!

Dave Jones.

Bug#1037612: control

[Dave Steele]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/cryfs/cryfs/issues/458

Bug#1036795: ITP: sphinx-design -- sphinx extension for creating responsive web components

[Dave Jones]

An initial attempt at packaging is now available in the following repo 
on salsa:


https://salsa.debian.org/python-team/packages/sphinx-design

The one stumbling block was that sphinx-design relies on FontAwesome for 
some of its icon styles. That's fine for docs built for the web, but for 
the offline docs package (python-sphinx-design-doc) that brings up an 
obvious privacy-breach-generic tag on lintian.


After reading through bug #902981 I patched around this by adding a dep 
on fonts-fork-awesome and patching the docs/conf.py to use the 
fork-awesome CSS in the local docs build instead. Please note this won't 
affect output built with the main package (python3-sphinx-design); it 
simply ensures that the offline copy of the docs really is offline.

Bug#1036795: ITP: sphinx-design -- sphinx extension for creating responsive web components

[Dave Jones]

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

* Package name: sphinx-design
  Version : 0.4.1
  Upstream Author : Executable Books
* URL : https://sphinx-design.readthedocs.io/en/latest/
* License : MIT
  Programming Lang: Python
  Description : sphinx extension for creating responsive web components

This is the intended successor [1] to the sphinx-panels extension, which 
is currently in Debian. The intent is to maintain it from the python 
team.

[1]: 
https://sphinx-design.readthedocs.io/en/latest/get_started.html#migrating-from-sphinx-panels

Bug#1004844: games-finest: Consider adding endless-sky

[Dave Vasilevsky]

Makes sense! That's being worked on in bug 944757

On Sat, May 6, 2023 at 5:52 PM Markus Koschany  wrote:

> Hi,
>
> thanks for the suggestion!
>
> On Wed, 02 Feb 2022 03:58:43 -0500 Dave Vasilevsky 
> wrote:
> > Package: games-finest
> > Version: 4
> > Severity: wishlist
> > X-Debbugs-Cc: d...@vasilevsky.ca
> >
> > Hi,
> >
> > Thanks for all your work maintaining debian-games.
> >
> > It's been a few years since we've added anything new to games-finest,
> and I
> > think endless-sky would be a great choice.
>
> [...]
>
> endless-sky looks really good and seems to be a fun game. However there
> haven't
> been any Debian uploads from the maintainer in almost six years and
> several new
> versions of endless-sky have been released since then. If we can fix this
> situation, then I would include it in games-finest. At the moment that
> would be
> premature.
>
> Regards,
>
> Markus
>

Bug#1033631: papi FTBFS on ppc64el with LTO enabled

[Dave Love]

For what it's worth, Fedora re-enabled the default LTO for papi,
presumably after fixing the toolchain.

Bug#1032595: krfb keyboard Wayland

[Dave Maxwell]

Package: krfb
Version: 4:22.12.3-1

krfb will not accept keyboard input from a vnc client under Wayland.

There is a two line fix for the issue upstream:

https://invent.kde.org/network/krfb/-/merge_requests/44/diffs?commit_id=01c775f2e89b705d8375c0ccc0543fc82be53414



I applied it to a krfb source deb and built it.  It does enable keyboard
input under Wayland.




-- 

Dave Maxwell
Network Administrator
Big Walnut Local Schools

-- 


_This email may contain confidential and/or privileged information and is 
covered by the Electronic Communications Privacy Act, 18 USC SS 2510-2521. 
If it does not contain privileged information concerning a BWLSD employee 
or student, this email and responses are subject to Ohio public records 
requests. If you are not the intended recipient (or have this email in 
error) please notify the sender immediately and destroy this email. Any 
unauthorized copying, disclosure or distribution of the material in this 
email is strictly forbidden._

Bug#1019701: RFP: rpi-imager -- Raspberry Pi Imaging Utility

[Dave Jones]

Hi Francois, Lin,

I'm the maintainer for the current Ubuntu packaging of rpi-imager [1]. 
If Debian's interested in adding this, there's a few changes in the 
Ubuntu packaging that *might* interest Debian (in particular the bits 
that include the JSON schema documentation, and patch out the privacy 
violations that lintian then warns about, and possibly the d/watch file 
as well).


I'm currently prepping the packaging for 1.7.4 but it's a little 
complicated by the new "no-big-endian" check [2] which obviously breaks 
the s390x build. I should probably just disable that build but a part of 
me is tempted to "just fix it"!


Oh, and 1.7.4 also includes the man-page that I previously patched into 
1.7.3 [3].


Anyway, do feel free to grab anything from there if it's wanted!

[1]: https://launchpad.net/ubuntu/+source/rpi-imager/1.7.3+noembed-0ubuntu1

[2]: 
https://github.com/raspberrypi/rpi-imager/commit/142ddfc0370e75a2f49e8c119e5b467f38e6f839

[3]: https://github.com/raspberrypi/rpi-imager/pull/491

Best regards,

Dave Jones.

Bug#1032223: fbb: Segmentation fault when listing subdirectories using FBBDOS

[Dave Hibberd]

Hi there Mike,

Thanks for this patch.

I have built it on my devbox and it compiles fine. I’ve not tested it as I 
don’t have the means to at the moment!

I shall look at committing this properly when I’m reunited with my yubikey 
unless someone else wants to do it first

Cheers
H


> On 2 Mar 2023, at 17:12, Mike Quin  wrote:
> 
> Revised 05-fix-compile-warnings patch attached.
> 
> —
> Mike Quin
> <05-fix-compile-warnings>

Bug#1032255: pulseaudio: sound keeps dying (on Tiger Lake)

[Dave Love]

Severity: normal

Bug#1032255: pulseaudio: sound keeps dying (on Tiger Lake)

[Dave Love]

Package: pulseaudio
Severity: serious
X-Debbugs-Cc: none, Dave Love 

I kept losing sound and had to restart applications.  In contrast to
#1022143, removing pipewire packages didn't help, but after replacing
pulseaudio with pipewire, things are working fine.  (I'm using the
bullseye-backports version, but I don't know if that's necessary.)

This is probably hardware-related, since I found it after replacing a
Thinkpad with a "HP EliteBook 840 G8 Notebook PC (19X36AV)" which has a
"Tiger Lake-LP Smart Sound Technology Audio Controller".  I can't see
any similar reports in a web search, though.

Sorry I can't report the actual package versions now, but recent, and
pulseaudio doesn't seems to have changed recently, and perhaps the
solution helps others.

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
Kernel taint flags: 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

Bug#1031702: mailutils: (locale-dependent) SEGV reading mail

[Dave Love]

Package: mailutils
Version: 1:3.10-3+b1
Severity: normal
X-Debbugs-Cc: none, Dave Love 

I get a consistent SEGV if I try to read mail with mailutils mail(1),
which is sometimes useful.  It turns out to be a function of the locale,
which will affect all Debian versions.  I sent a patch to bug-mailutils
which would be useful to add:
https://lists.gnu.org/archive/html/bug-mailutils/2023-02/msg0.html

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
Kernel taint flags: 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 mailutils depends on:
ii  libc6 2.31-13+deb11u5
ii  libcrypt1 1:4.4.18-4
ii  libfribidi0   1.0.8-2+deb11u1
ii  libgnutls30   3.7.1-5+deb11u3
ii  libgsasl7 1.10.0-4+deb11u1
ii  libldap-2.4-2 2.4.57+dfsg-3+deb11u1
ii  libmailutils7 1:3.10-3+b1
ii  libncurses6   6.2+20201114-2
ii  libpam0g  1.4.0-9+deb11u1
ii  libreadline8  8.1-1
ii  libtinfo6 6.2+20201114-2
ii  libunistring2 0.9.10-4
ii  mailutils-common  1:3.10-3

Versions of packages mailutils recommends:
ii  postfix [mail-transport-agent]  3.5.17-0+deb11u1

Versions of packages mailutils suggests:
pn  mailutils-doc  
pn  mailutils-mh   

-- no debconf information

Bug#939615: rtkit: Flooding syslog

[Dave Love]

Modifying the systemd message level, as suggested in
https://github.com/heftig/rtkit/pull/26#issuecomment-1361251871 seems to
do the trick.  I think that should be shipped in the absence of upstream
movement.

Bug#1027121: Got an error: Error in line 2978: file not found

[Dave Vehrs]

On Wed, Dec 28, 2022 at 12:43:16AM +0100, Joerg Schiermeier, Bielefeld/Germany 
wrote:
> Package: podget
> Version: 0.9.0-1
> Severity: normal
> 
> At the end of running a download of new podcasts I get this error message:
> Command line:
> $ podget
> 
> - ---[Message]---
> Cleanup old tracks.
> Deleting tracks from :
> /usr/bin/podget: Zeile 2978: : Datei oder Verzeichnis nicht gefunden
> 
> Error:
>   Script: podget
>   At line:2944
>   Exit Status:1
> 
> Context:
> 2941fi
> 2942fi
> 2943if (( VERBOSITY >= 2 )) ; then
> 2944 >>>echo "Deleting tracks from ${FILE}:"
> 2945fi
> 2946while read -r LINE ; do
> 2947if [[ -f "${DIR_LIBRARY}/${LINE}" ]]; then
> 
> Closing session and removing lock file.
> podget  55,45s user 136,96s system 12% cpu 25:33,64 total
> - ---[/Message]---

OK, it appears this error was actually triggered in the while read loop
2 lines below where it was reported but was actually caused by a
separate while read loop about 9 lines above it.  The bug appears to
have been when no M3U playlists were found and so it was attempting to
parse a file that didn't exist, which we learn from the "Deleting tracks
from  :" line in the output.  The fact that it is missing a filename
reveals that the problem occurs before the error is triggered.

I've added a fix that checks for when ${FILE} is unset or null that
allows its while loop to continue prior to the parts that failed.

The fix has been uploaded to the 'dev' branch on Podget's Github
repository and will be included in the next version.

I'm currently testing a rather large idea that may be able to use the
TITLE tag from RSS feeds to name the files rather than just what the
downloaded filename is.  So it may be a little while before the next
version is actually released.

Thanks for the report and I will updated this when I do publish a new
version.

Dave

-- 
Dave VehrsEmail: dve...@gmail.com

Bug#1026394: postfix: no warning about chroot change that may break configuration

[Dave Love]

Package: postfix
Version: 3.5.17-0+deb11u1
Severity: normal
X-Debbugs-Cc: none, Dave Love 

This may be too late to be useful, but:

I got an auto-update of postfix last night which has broken incoming
mail.  A milter blacklist file which previously needed to be in the
chroot directory (/var/spool/postfix) is no longer found there and needs
to be moved relative to /.  The changelog has:

- Cleanup (problem introduced: Postfix 2.7): milter_header_checks
  maps are now opened before the cleanup server enters the
  chroot jail.

but there's no installation warning about the changed behaviour.

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

Kernel: Linux 5.10.0-19-amd64 (SMP w/8 CPU threads)
Kernel taint flags: 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 postfix depends on:
ii  adduser3.118
ii  cpio   2.13+dfsg-4
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.12
ii  e2fsprogs  1.46.5-2~bpo11+2
ii  libc6  2.31-13+deb11u5
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libicu67   67.1-7
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.27+dfsg-2.1+deb11u1
ii  libssl1.1  1.1.1n-0+deb11u3
ii  lsb-base   11.1.0
ii  netbase6.3
ii  ssl-cert   1.1.0+nmu1

Versions of packages postfix recommends:
ii  ca-certificates  20210119
ii  python3  3.9.2-3

Versions of packages postfix suggests:
ii  emacs-gtk [mail-reader]1:27.1+1-3.1
ii  evolution [mail-reader]3.38.3-1
ii  libsasl2-modules   2.1.27+dfsg-2.1+deb11u1
ii  mailutils [mail-reader]1:3.10-3+b1
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
pn  postfix-sqlite 
pn  procmail   
pn  resolvconf 
ii  thunderbird [mail-reader]  1:102.5.0-1~deb11u1
ii  ufw0.36-7.1

-- debconf information:
  postfix/relay_restrictions_warning:
  postfix/tlsmgr_upgrade_warning:
  postfix/compat_conversion_warning: true
  postfix/retry_upgrade_warning:
  postfix/procmail:
  postfix/main_cf_conversion_warning: true
  postfix/mailbox_limit: 0
  postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
  postfix/sqlite_warning:
  postfix/recipient_delim: +
  postfix/relayhost:
  postfix/destinations:
  postfix/chattr: false
  postfix/protocols:
  postfix/kernel_version_warning:
  postfix/dynamicmaps_conversion_warning:
  postfix/root_address:
* postfix/main_mailer_type: No configuration
  postfix/bad_recipient_delimiter:
  postfix/rfc1035_violation: false
  postfix/lmtp_retired_warning: true
  postfix/not_configured:
  postfix/mailname: /etc/mailname
  postfix/newaliases: false
  postfix/mydomain_warning:

Bug#638256: Bug 638256 Update - Still Exists

[Dave]

TO: 638...@bugs.debian.org


And... Still a bug.  Since at least 2010...

As of December 2022 this is still an issue in 3.1.23.1-1

ii  at 3.1.23-1.1   arm64Delayed job execution and 
batch processing


ls -l /usr/sbin/atd
-rwxr-xr-x 1 root root 26568 Sep 25  2020 /usr/sbin/atd


/var/log/syslog (and/or /var/log/cron) filled with:
...
Dec  5 21:11:36 mysys atd[17889]: File a006e001a8bf99 is in wrong format 
- aborting
Dec  5 21:11:36 mysys atd[17890]: File a006e001a8bf99 is in wrong format 
- aborting
Dec  5 21:11:36 mysys atd[17891]: File a006e001a8bf99 is in wrong format 
- aborting
Dec  5 21:11:36 mysys atd[17892]: File a006e001a8bf99 is in wrong format 
- aborting

...

/var/spool/cron/atjobs contained:
drwxrwx--T 2 daemon daemon 4096 Dec  5 21:11  .
drwxr-xr-x 5 root   root   4096 Dec  4 11:30  ..
-rw--- 1 daemon daemon6 Dec  4 13:18  .SEQ
-rwx-- 2 dabdaemon0 Dec  4 13:18 '=006e001a8bf99'
-rwx-- 2 dabdaemon0 Dec  4 13:18  a006e001a8bf99

Deleting these zero-sized files/jobs and restarting atd resolved the issue.

I'm not a developer, but a possible quick fix would be to add:
  find /var/spool/cron/atjobs/ -type f -empty -print -delete
to the /etc/init.d/atd start stanza

Although this would only cover instances when/where atd is (re)started.

Bug#1019208: Fwd: ITP: viagee -- support for Gmail as the preferred email application in GNOME

[Dave Steele]

Package: wnpp
Severity: wishlist
Owner: David Steele 

* Package name: viagee
  Version : 3.0-1
  Upstream Author : David Steele 
* URL : https://github.com/davesteele/viagee/tree/debian
* License : GPL
  Programming Lang: Python
  Description : support for Gmail as the preferred email
application in GNOME

This is a rename of the existing package "gnome-gmail". The name had
to be changed due to branding contention.

A transitional gnome-gmail package is included in the repository [1].

[1]: https://github.com/davesteele/viagee/tree/debian

Bug#695835: Partnerstwo wewnetrzne

[Dave E. Ramsden]

Mam dla Ciebie poufna propozycje biznesowa, która jest warta znaczna kwote 
(13,5 mln GBP). Jesli jestes zainteresowany, odpowiedz, aby uzyskac wiecej 
informacji.
 
Jesli to mozliwe, wskaz swoje zainteresowanie jezykiem angielskim dla lepszej 
komunikacji.
 
Z powazaniem,
Dave Ramsden
__
Sekretarz: Chantal Salvi

Bug#785356: Interne Partnerschaft

[Dave E. Ramsden]

Ich habe einen Geschäftsvorschlag für Sie, der einen beträchtlichen Betrag wert 
ist (GBP 13,5 Mio.). Bei Interesse antworten Sie für weitere Details.
 
Geben Sie, wenn möglich, Ihr Interesse an Englisch an, um besser kommunizieren 
zu können.
 
Mit freundlichen Grüßen,
David Ramsden

Sekretärin: Chantal Salvi

Bug#785356: Interne Partnerschaft

[Dave E. Ramsden]

Ich habe einen Geschäftsvorschlag für Sie, der einen beträchtlichen Betrag wert 
ist (GBP 13,5 Mio.). Bei Interesse antworten Sie für weitere Details.
 
Geben Sie, wenn möglich, Ihr Interesse an Englisch an, um besser kommunizieren 
zu können.
 
Mit freundlichen Grüßen,
David Ramsden

Sekretärin: Chantal Caniggia

Bug#1014684: FTBFS with fmtlib 9.0.0

[Dave Steele]

Control: forwarded -1 https://github.com/cryfs/cryfs/issues/432

Bug#1014684: FTBFS with fmtlib 9.0.0

[Dave Steele]

Control: -1 forwarded https://github.com/cryfs/cryfs/issues/432
Thanks

On Sun, Jul 10, 2022 at 5:33 AM Shengjing Zhu  wrote:
> I have uploaded fmtlib 9.0.0 to experimental. During rebuild the reverse
> dependencies, your package FTBFS.
>

Bug#695835: Projekt

[Dave Ramsden]

Mam projekt/biznes do omówienia z toba. Jesli jestes zainteresowany, odpowiedz 
po wiecej szczególów, jesli to mozliwe, w jezyku angielskim.
  
Z powazaniem,
Dave Ramsden
_
Sekretarka: Vanni Gilbert

Bug#695835: Projekt

[Dave E. Ramsden]

Mam projekt do omówienia z tobą. Jeśli jesteś zainteresowany, odpowiedz po 
więcej szczegółów, jeśli to możliwe, w języku angielskim.
   
Z poważaniem,
Dave Ramsden
_
Sekretarz: Vanni Gilbert

Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian OldStable 10.x/Buster

[Dave Ewart]

On Tuesday, 21.06.2022 at 17:29 +0200, gregor herrmann wrote:

> On Tue, 21 Jun 2022 16:21:07 +0100, Dave Ewart wrote:
> 
> > This bug has been closed but there is still no update in the oldstable
> > repository as far as I can see.
> > 
> > # dpkg -l|grep tzdata
> > ii  tzdata   2021a-0+deb10u3
> >all  time zone and daylight-saving time data
> 
> That's not the repository but your local installation :)
> 
> % rmadison tzdata
> tzdata | 2018e-0+deb8u1  | oldoldoldstable| source, all
> tzdata | 2020a-0+deb9u1  | oldoldstable   | source, all
> tzdata | 2021a-0+deb10u3 | oldstable  | source, all
> tzdata | 2021a-0+deb10u5 | buster-updates | source, all
> tzdata | 2021a-0+deb10u5 | oldstable-proposed-updates | source, all
> tzdata | 2021a-1+deb11u2 | stable | source, all
> tzdata | 2021a-1+deb11u4 | proposed-updates   | source, all
> tzdata | 2021a-1+deb11u4 | stable-updates | source, all
> tzdata | 2022a-1 | testing| source, all
> tzdata | 2022a-1 | unstable   | source, all
> 
> So you have 2021a-0+deb10u3 from oldstable installed, and the fixed
> version 2021a-0+deb10u5 is in buster-updates, which you seem to miss
> in your sources.list.
> 
> (I assume it will end up in oldstable proper in the next point
> release but for inbetween updates, {old}stable-updates is needed.) 

I know that's my version, I was simply trying to demonstrate (perhaps
poorly) that the updated version hadn't reached my system. :-)

I have never used the 'updates' or 'proposed-updates' for a production
stable system because my understanding is that those repositories were
not necessary, nor recommended, for a purely 'stable' installation.
"Don't add extra repositories" etc.

I see the point you're making: will have to make an exception here, I
guess.

Thanks,

Dave.

-- 
Dave Ewart, da...@sungate.co.uk



signature.asc
Description: PGP signature

Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian OldStable 10.x/Buster

[Dave Ewart]

This bug has been closed but there is still no update in the oldstable
repository as far as I can see.

# dpkg -l|grep tzdata
ii  tzdata   2021a-0+deb10u3   
all  time zone and daylight-saving time data

# grep zoneinfo /var/log/syslog
Jun 21 15:17:20 equinox ntpd[25270]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 7 days

Have I missed something or is this update still waiting to hit the
repository?

Dave.

-- 
Dave Ewart, da...@sungate.co.uk



signature.asc
Description: PGP signature

Bug#1003496: Relinquish

[Dave Steele]

Control: noowner -1

I no longer intend to package this software.

Bug#1012272: colordiffrc: using apt-get to upgrade system I recieve error

[Dave Ewart]

Following discussion with the bug submitter offline, I've reassigned
this bug from colordiff to apt-listdifferences

The error message comes from /usr/bin/colordiff-git which is included in
the apt-listdifferences package -- colordiff-git stalled on the newer
colordiff option 'difffile' in /etc/colordiffrc (where /etc/colordiffrc
is provided by colordiff package).

Maybe apt-listdifferences should just depend on colordiff directly
rather than bundling a (potentially out of date) copy?

Dave.


-- 
Dave Ewart, da...@sungate.co.uk



signature.asc
Description: PGP signature

Bug#1012400: fakeroot: FAKEROOTDONTTRYCHOWN isn't documented

[Dave Love]

Package: fakeroot
Version: 1.25.3-1.1
Severity: normal
X-Debbugs-Cc: none, Dave Love 

The man page doesn't document the use of environment variable
FAKEROOTDONTTRYCHOWN, which turns out to be useful at least for the next
version of charliecloud.  (It looks as if that's the only one.)

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

Kernel: Linux 5.10.0-14-amd64 (SMP w/4 CPU threads)
Kernel taint flags: 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 fakeroot depends on:
ii  libc62.31-13+deb11u3
ii  libfakeroot  1.25.3-1.1

fakeroot recommends no packages.

fakeroot suggests no packages.

-- no debconf information

Bug#1012272: colordiffrc: using apt-get to upgrade system I recieve error

[Dave Ewart]

The 'Unknown option' error message arises when running colordiff, but there
is no explicit call to colordiff during package installation or upgrade.

However ... is it possible that you have diff and colordiff aliased or
symlinked? If so and the package installation calls a 'diff' this would in
turn call 'colordiff'. (I haven't checked, but presumably the package
installation script may use 'diff' to check whether /etc/colordiffrc is up
to date)

In which I can see how this message might arise, since it would maybe be
running an older version of colordiff for that diff (until the install is
completed). The 'difffile' option was introduced in colordiff 1.0.19 and,
if you are running Debian/testing, you'd have been updating from colordiff
1.0.18 to colordiff 1.0.20.

Might that explain what you see?

Dave.

-- 
Dave Ewart, da...@sungate.co.uk

Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian OldStable 10.x/Buster

[Dave Ewart]

Package: tzdata
Version: 2021a-0+deb10u3
Severity: normal

ntpd has begun reporting that /usr/share/zoneinfo/leap-seconds.list is
approaching expiry (28 June 2022):

>> May 31 15:17:20 [...] ntpd[25270]: leapsecond file 
>> ('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 28 days

Is there an updated package with updated expiry date available?

This bug is with 'oldstable', I'm unclear whether I would expect this package to
be updated or not any more.

-- System Information:
Debian Release: 10.12
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.71+deb10u1

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information:
  tzdata/Zones/Arctic:
  tzdata/Zones/SystemV:
  tzdata/Zones/Australia:
  tzdata/Zones/Antarctica:
  tzdata/Zones/Indian:
  tzdata/Zones/Asia:
  tzdata/Zones/Etc:
  tzdata/Zones/America:
* tzdata/Areas: Europe
  tzdata/Zones/Africa:
* tzdata/Zones/Europe: London
  tzdata/Zones/Pacific:
  tzdata/Zones/Atlantic:
  tzdata/Zones/US:

Bug#1011311: RFS: colordiff/1.0.20-1 -- tool to colorize 'diff' output

[Dave Ewart]

Thanks for uploading, I see the package has entered unstable.

What is the convention now, with this RFS bug? Should I mark it as
closed/done?

Dave.

-- 
Dave Ewart, da...@sungate.co.uk

Bug#1011311: RFS: colordiff/1.0.20-1 -- tool to colorize 'diff' output

[Dave Ewart]

Dear mentors,

Rebuild package following suggestions from Bastian Germann.

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

 * Package name: colordiff
   Version : 1.0.20-1
   Upstream Author : Dave Ewart da...@sungate.co.uk
 * URL : http://www.colordiff.org/
 * License : GPL-2+
 * Vcs : https://github.com/daveewart/colordiff
   Section : text

The source builds the following binary packages:

  colordiff - tool to colorize 'diff' output

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/colordiff/colordiff_1.0.20-1.dsc

Changes since the last upload:

 colordiff (1.0.20-1) unstable; urgency=medium
 .
   * New upstream release.
   * debhelper-compat updated to version 13.
   * Updates standards version to 4.6.0, added Rules-Require-Root.

Regards,

-- 
Dave Ewart, da...@sungate.co.uk

Bug#1011129: gridengine: FTBFS with OpenJDK 17 due to JDK detection error

[Dave Love]

I thought it failed with earlier openjdk than that because of jgdi being
removed, but I think it needs to use

  aimk -no-java ...

I don't know what JDK versions it needs to check for, but it's probably
not worth any effort to get that right.  I'm not sure whether you can
still build jdrmaa, at least.

I look at it immediately, but can probably can in a bit as I need to
resurrect rpm builds anyway.

Bug#1011311: RFS: colordiff/1.0.20-1 -- tool to colorize 'diff' output

[Dave Ewart]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: colordiff
   Version : 1.0.20-1
   Upstream Author : Dave Ewart da...@sungate.co.uk
 * URL : http://www.colordiff.org/
 * License : GPL-2+
 * Vcs : https://github.com/daveewart/colordiff
   Section : text

The source builds the following binary packages:

  colordiff - tool to colorize 'diff' output

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/colordiff/colordiff_1.0.20-1.dsc

Changes since the last upload:

 colordiff (1.0.20-1) unstable; urgency=medium
 .
   * New upstream release.
   * Minor packaging tidying.
   * Updates standards version to 4.6.0, added Rules-Require-Root.

Background: I've been developing 'colordiff' for more than 20 years, but in the
Debian ecosystem I've never uploaded the packages myself.  Rather I've been
building the packages and various individuals have sponsored the uploads.
However my most recent sponsor Colin Tuckley (since 2007) is no longer able to
do so.


Regards,
-- 
Dave Ewart, da...@sungate.co.uk

Bug#1011273: sbuild: autopkgtest unshare is not running dscverify

[Dave Jones]

Package: sbuild
Version: 0.79.0-1ubuntu1
Severity: normal
Tags: patch

Dear Maintainer,

While working on merging the current sbuild from Debian unstable to 
Ubuntu I noticed something a bit odd in the "unshare" test (both in our 
delta with Debian, but also in the Debian original):

At the top of verify() in unshare [1], the routine attempts to assign 
its arguments to some variables:

verify_src="${1+no}"
verify_bin="${1+no}"

Unfortunately, there's a couple of errors here. Firstly only the first
argument is used ($2 never gets a look in). But secondly, the "+" 
expansion ("use alternative value") means that, if $1 is "" the result 
is "" but otherwise the result is "no". So verify_src and verify_bin can 
only *ever* be "no"; they can never be "yes". This means the dscverify 
sections later on never get called.

Our delta in Ubuntu compounds these mistakes by also making the orig and 
deb sections optional and ... also using $1 and the "+" expansion [2].
Oops!

Firstly, instead of relying on a bunch of boolean yes/no parameters I 
think it might be nicer to simply list the things we'd like verify to 
check (e.g. "verify orig deb dsc"), which I've done in a local branch. 
Once that change was in place I also discovered that dscverify still 
never ran because it never gets installed in the system setup by the 
qemu-wrapper script because devscripts is missing from EXTRA_DEPS there.

Finally, once this was all working I discovered that the .dsc file 
should *not* be checked when sbuild is run *without* the "--source" 
option because, although the .dsc file is produced in this case, it 
isn't signed (presumably because it doesn't get listed in the .changes) 
file. To fix this I separated the .dsc and .changes checks into their 
own sub-routines and modified the calls to verify() accordingly.

I'm attaching a patch which fixes the issue, but once I've got a bug 
number I'll propose the changes as an MR on salsa for convenience.

[1]: 
https://salsa.debian.org/debian/sbuild/-/blob/main/debian/tests/unshare#L71

[2]: 
https://git.launchpad.net/ubuntu/+source/sbuild/tree/debian/tests/unshare?h=applied/ubuntu/devel&id=23ce4fa3e9bbe83ca70a23224c2c3f8829078227#n80


Best regards,

Dave Jones.
diff --git a/debian/tests/unshare b/debian/tests/unshare
index 2c45a1fe..b9013eb1 100755
--- a/debian/tests/unshare
+++ b/debian/tests/unshare
@@ -20,6 +20,7 @@ chmod 700 "${AUTOPKGTEST_TMP}/gpghome"
 export GNUPGHOME="${AUTOPKGTEST_TMP}/gpghome"
 
 verify_orig() {
+   echo "verifying test-pkg_1.0.tar.xz" >&2
 cat << END | base64 -d > "${AUTOPKGTEST_TMP}/expected"
 /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/BBZdADoZSs4dfiUjFYSOxzYxnd+/m6AlVEVOGf2j
 nT6NK0F9XZ7LLydbY3I//WjMOM2RFpGUqZ8R8Q8lLmydB5SLN5ZQSPW3OJjHlzxVQmv2v3KUyPxo
@@ -47,6 +48,7 @@ END
 }
 
 verify_deb() {
+   echo "verifying test-pkg_1.0_all.deb" >&2
 cat << END | base64 -d > "${AUTOPKGTEST_TMP}/expected"
 ITxhcmNoPgpkZWJpYW4tYmluYXJ5ICAgMTQ2NzMxMDUxMiAgMCAgICAgMCAgICAgMTAwNjQ0ICA0
 ICAgICAgICAgYAoyLjAKY29udHJvbC50YXIueHogIDE0NjczMTA1MTIgIDAgICAgIDAgICAgIDEw
@@ -68,26 +70,31 @@ END
rm "${AUTOPKGTEST_TMP}/expected"
 }
 
-verify() {
-   verify_src="${1+no}"
-   verify_bin="${1+no}"
-   echo "verifying test-pkg_1.0.tar.xz" >&2
-   verify_orig
-   echo "verifying test-pkg_1.0_all.deb" >&2
-   verify_deb
+verify_dsc() {
# we shouldn't have to manually pass the keyring because the path is an
# implementation detail of gnupg (it used to be named pubring.gpg in
# the past) but dscverify ignores GNUPGHOME, see Debian bug #981008
-   if [ "$verify_bin" = "yes" ]; then
-   echo "verifying test-pkg_1.0.dsc" >&2
-   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" 
"${AUTOPKGTEST_TMP}/test-pkg_1.0.dsc"
-   echo "verifying test-pkg_1.0_${nativearch}.changes" >&2
-   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" 
"${AUTOPKGTEST_TMP}/test-pkg_1.0_${nativearch}.changes"
-   fi
-   if [ "$verify_src" = "yes" ]; then
-   echo "verifying test-pkg_1.0_source.changes" >&2
-   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" 
"${AUTOPKGTEST_TMP}/test-pkg_1.0_source.changes"
-   fi
+   echo "verifying test-pkg_1.0.dsc" >&2
+   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" \
+   "${AUTOPKGTEST_TMP}/test-pkg_1.0.dsc"
+}
+
+verify_bin_chang

Bug#1009921: procenv: apparmor not reported (outdated release)

[Dave Love]

Package: procenv
Version: 0.51-0.2
Severity: normal
X-Debbugs-Cc: none, Dave Love 

I'm reporting this since it's somewhat Debian(/Ubuntu)-specific.

There's currently no report of the apparmor status (or, I think selinux)
due to an autoconf bug which was fixed in v0.60.  There are various
enhancements in recent versions that would be worth an update too.

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

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN, 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 procenv depends on:
ii  libc62.31-13+deb11u3
ii  libcap2  1:2.44-1
ii  libnuma1 2.0.12-1+b1
ii  libselinux1  3.1-3

procenv recommends no packages.

procenv suggests no packages.

-- no debconf information

Bug#1007924: RFS: rshell/0.0.31-1 [ITP] -- Remote shell for working with MicroPython boards

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: rshell
   Version : 0.0.31-1
   Upstream Author : https://github.com/dhylands/rshell
 * URL : https://github.com/dhylands/rshell
 * License : MIT
 * Vcs : https://salsa.debian.org/python-team/packages/rshell
   Section : python

The source builds the following binary packages:

  python3-rshell - Remote shell for working with MicroPython boards - python3 
library
  rshell - Remote shell for working with MicroPython boards

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/r/rshell/rshell_0.0.31-1.dsc

Changes for the initial release:

 rshell (0.0.31-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1007924)

Thanks for you consideration!

--
  Dave Jones



signature.asc
Description: PGP signature

Bug#802260: gnome-gmail: Installation experience on KDE

[Dave Steele]

Control: severity -1 wishlist
thanks

Bug#1007924: ITP: rshell -- A remote shell for working with MicroPython boards

[Dave Jones]

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

* Package name: rshell
  Version : 0.0.31-1
  Upstream Author : https://github.com/dhylands/rshell
* URL : https://pypi.org/project/rshell/
* License : MIT
  Programming Lang: Python
  Description : A remote shell for working with MicroPython boards

A simple shell which runs on the host and uses MicroPython's raw-REPL to 
send Python snippets to the board in order to get file-system 
information, to copy files to and from MicroPython's file-system. It 
also has the ability to invoke the MicroPython REPL, so rshell can be 
used as a terminal emulator as well.

Currently, the standard method for installing this is to use pip3. 
However, given it has minimal dependencies (pyserial and pyudev) which 
are already packaged nicely in Debian, there's no particular reason this 
shouldn't be deb-packaged too. The only other (direct) means of 
manipulating the file-system on a MicroPython device currently available 
in Debian (that I'm aware of) is the Thonny editor. However, Thonny 
requires a graphical environment, whilst rshell is also suitable for 
console only environments.

I'm happy to maintain this package as part of the Python team.

Bug#1006787: rsync: fails to honour a tilde (~) in --log-file option

[Dave]

Package: rsync
Version: 3.1.3-6
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Normal rsync local system directory copying/archiving using the '--log-file' 
option

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

1. Executing "rsync -a --verbose --log-file=~/xx/mylog ~/ ~/xx"
Resulted in:
 rsync: failed to open log-file ~/xx/mylog: No such file or directory (2)
 Ignoring "log file" setting.
 sending incremental file list
 /
 /20211230171244.mkv
...snip normal output...
 /xx/20220212123456-mask2.xcf

 sent 2,687,537 bytes  received 222 bytes  5,375,518.00 bytes/sec
 total size is 2,686,183  speedup is 1.00

Note the error output and 'Ignoring "log file" setting.' line when the 
--logfile option contained a tilde: '--log-file=~/xx/mylog'
Also note that the source and destination directories do contain the tilde (~).
No log file was produced anywhere on the local system. (The directory archive 
was successful.)

2. Executing "rsync -a --verbose --log-file=xx/mylog ~/ ~/xx" (relative 
directory)
or with '--log-file=/home/myid/xx/mylog' (fully qualified path) resulted in the 
expected logging operation. 


If the tilde is honoured in the arguments, shouldn't it also be honoured in the 
options?


Thanx.

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 3 (beowulf)
Release:3
Codename:   beowulf
Architecture: x86_64

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

Versions of packages rsync depends on:
ii  base-files   10.3+devuan3.5
ii  init-system-helpers  1.56+nmu1+devuan3
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libpopt0 1.16-12
ii  lsb-base 10.2019051400

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.9p1-10+deb10u2
ii  openssh-server  1:7.9p1-10+deb10u2

-- no debconf information

Bug#1006614: libccid: support for Solo2 and Nitrokey 3

[Dave Love]

You wrote: 

> I can't fix or upgrade packages in Debian stable, unless that is a security 
> issue.
>
> What you can do instead is backport the libccid package from unstable
> to stable. That is what you did.
> This is also handled by the Debian backports project 
> https://backports.debian.org/

OK, thanks.  Sorry to bother you when I couldn't find info on the policy
on changes in stable; also I didn't know the backports site.  I should
fix being a Fedora maintainer and not a Debian one when I personally run
Debian.

Bug#1006614: libccid: support for Solo2 and Nitrokey 3

[Dave Love]

Package: libccid
Version: 1.4.34-1~solo2+1
Severity: wishlist
X-Debbugs-Cc: none, Dave Love 

Various functions of the new free software/hardware Solo 2 security key
don't work in Debian 11 because libccid doesn't support it.  The same
probably goes for the Nitrokey 3 when it's available as it shares basic
firmware.  It seems worth supporting them since they're free devices,
either by backporting from unstable or patching the version in stable.
I don't know which is the best solution (or whether patching for extra
support is within policy), but I've tried both with success.

I built 1.5 from unstable on buster and bullseye (lowering the debhelper
version so it would also work on 10, and also Ubuntu 18.04 and 20.04).
Installing it solves at least that part of problems with the solo2 cli.
Then I tried the version from bullseye plus the /etc/libccid_Info.plist
from 1.5, which works; I'll probably post it for Solo 2 users.  As that
worked I rebuilt the bullseye version with a patch for
readers/supported_readers.txt to add Solo2 and Nitrokey entries, though
I guess it could have all the additions from the 1.5 version.  The
results are under <https://build.opensuse.org/repositories/home:fx>.
Obviously I can send a patch if that's helpful.

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

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, 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 libccid depends on:
ii  libc6 2.31-13+deb11u2
ii  libusb-1.0-0  2:1.0.24-3

libccid recommends no packages.

Versions of packages libccid suggests:
pn  pcmciautils  

-- no debconf information

Bug#1006147: Merge request

[Dave Jones]

I've now submitted the following merge request for this issue:

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


Best regards,

Dave Jones.

Bug#1006147: debconf: dpkg-reconfigure fails to restart services after #994204

[Dave Jones]

Package: debconf
Version: 1.5.73
Severity: important

Dear Maintainer,

As part of fixing an issue with restarting services in debhelper 
(#994204), I proposed a patch [1] that, in certain circumstances (when 
--no-restart-after-upgrade is specified) moves the duty of stopping 
services from the prerm maintainer script to the preinst maintainer 
script (see #994204 for the reasoning behind this change). That fix has 
been merged in Debian, although not yet released. In Ubuntu, the fix has 
also been merged and is currently in our -proposed pocket.

One issue [2] that arose during the testing of the fix was that, for the 
slapd service (part of the openldap package), dpkg-reconfigure now 
failed to restart the service. The slapd service is indeed declared with 
--no-restart-after-upgrade and, and digging into dpkg-reconfigure's code 
I found that it runs prerm, config, and postinst, but not preinst. 
Hence, with services using --no-restart-after-upgrade, prerm no longer 
stops the service and by the time it gets to postinst, the "start" 
operation there has nothing to do.

My assumption is that prerm was only in that sequence to stop services 
(it's seems a little odd to me for it to be in dpkg-reconfigure 
otherwise? Am I missing something else there?). However, I'm guessing 
that replacing prerm with preinst would lead to breakage in packages 
that assume prerm is still run by dpkg-reconfigure. Instead, I'm 
proposing to add preinst to the list of maintainer scripts run by 
dpkg-reconfigure. I'll propose a merge request to the debconf salsa repo 
that adds preinst to the list, and update this with the link shortly.

Many thanks for any attention you can give this, and for any light you 
can shed on my assumptions above. If you need any more detail on the 
reasoning behind the fix for #994204 (and its related issue #989155), 
please let me know.

[1]: https://salsa.debian.org/debian/debhelper/-/merge_requests/61

[2]: https://bugs.launchpad.net/bugs/1959054 (comment # 15 onwards)


Best regards,

Dave Jones.

Bug#990201: singularity-container: CVE-2021-33622

[Dave Love]

I'm wondering why I'm included, though I was thinking I should offer to
contribute to Debian.

Andreas Tille  writes:

> I updated singularity-container in Salsa to the latest available CE
> release and added some new Build-Depends.  Unfortunately it does not
> build as you can see in salsa-ci[1].  Any help to get the package build
> is welcome.  I personally have no idea about Go language nor singularity
> and really need the help of previous Uploaders / Go team.

[1] is 404 for me, presumably because I don't have access to salsa.
Anyway, is the Fedora packaging any clue
?  I know
it was updated recently, and it includes a patch that isn't in what I
can see at sources.debian.  (I can interpret .spec files if necessary,
but that one isn't Fedora-conforming.)  If that helps, it's only fair,
since I've consulted Debian for Fedora packaging a few times!

(I originally packaged singularity for Fedora, but subsequently disowned
it.)

Bug#994204: Fix merged; package rebuilds needed after release

[Dave Jones]

Thanks to Niels Thykier, the proposed fix [1] was merged over the 
weekend. When debhelper is next released, this should at least deal with 
the issue for future package builds. However, packages built after the 
release of 13.4 (which first incorporated the fix for #989155 which 
caused this issue) ought to have a rebuild in order to correct their 
generated maintainer scripts.


I've had a search of DCS [2] (thanks to Christian for informing me of 
this excellent resource!) and gone through all packages that match 
--no-(stop-after|restart-(on|after))-upgrade in their source (I've 
stripped out those that obviously don't apply like debhelper itself, or 
the odd one that only mentioned these in their historical changelogs, or 
within their code, like dh-runit).


The resulting list is ~80 packages long but please bear in mind that 
this *may not* be comprehensive. In particular, packages might be using 
the short form of these options (-r or -R), but for obvious reasons 
searching for these forms would be impractical. Still, I have a sneaking 
suspicion that most package maintainers tend to stick to the long-form 
of these options so I'd hope the list captures the majority of packages 
that need rebuilding.


Once the fix makes it into a debhelper release, the following packages 
ought to be rebuilt:


aoetools
apcupsd
apparmor
apt
apt-cacher-ng
aumix
bip
buildbot
ceph
chrony
cloud-init
cpufrequtils
dbus
dbus-broker
docker.io
dpdk
drbd-utils
fsprotect
g810-led
ganeti
gdnsd
gpm
h2o
haproxy
ifupdown
ifupdown-ng
iipimage
inetsim
inspircd
iwd
libvirt
live-config
live-tools
lizardfs
lxc
lxcfs
moosefs
nghttp2
nginx
ngtcp2
nodm
ntp
nullmailer
ocfs2-tools
open-infrastructure-compute-tools
open-iscsi
openstack-cluster-installer
open-vm-tools
openvpn
pacemaker
packagekit
pdudaemon
phosh
plymouth
policycoreutils
python-certbot
qcontrol
qemu
quassel
robustirc-bridge
rpcbind
runit
samba
sanlock
sbd
sbuild
slim
sysstat
systemd
tarantool
targetcli-fb
tgt
tlp
ufw
umtp-responder
unscd
wdm
whereami
xrdp
yubikey-luks
zfs-linux

[1]: https://salsa.debian.org/debian/debhelper/-/merge_requests/61

[2]: 
https://codesearch.debian.net/search?q=--no-%28stop-after%7Crestart-%28on%7Cafter%29%29-upgrade&literal=0



Best regards,

Dave Jones.

Bug#994204: MR for #994204

[Dave Jones]

Hi,

I've opened a tentative fix for this [1]. I've included a (hopefully!) 
comprehensive write-up in the description of the MR, but for the sake of 
completeness here's an e-mail friendly copy:


There are two bugs addressed in this request; mostly it undoes the 
original fix for #989155, and then fixes that in such a way that #994204 
does not occur.


The original issue (#989155) dealt with moving a package from the new 
default restart behaviour ("--restart-after-upgrade", indicating 
services should be restarted in a single step after file unpacking) to 
the older restart behaviour ("--no-restart-after-upgrade", indicating 
services should be stopped prior to unpacking, then started again at the 
end of installation. The crux of this issue is, with the 
"--no-restart-after-upgrade" option, *two* versions of the package are 
involved in stopping and restarting the service. Specifically, the 
"prerm" script of the *old* version of the package stops services, then 
the "postinst" script of the *new* version of the package starts 
services.


The original fix for this issue (in commit 6067bc2f [2] and 5b27a541 
[3]), handled this by leaving the stop behaviour in "prerm" and 
modifying the start behaviour in "postinst" to always *restart* (with 
the unfortunate consequence found in #994204).


I think it may be preferable to instead move the stop behaviour to the 
"preinst" script of the *new* version of the package so that both stop 
and start behaviours are encapsulated in a *single* version of the 
package (and hence can be freely moved between). This also means that 
"postinst" script's prior behaviour can be restored.


To that end, the MR first reverts the two commits associated with 
#989155, then adds a third commit that adds a "preinst" script for 
"dh_installinit" and "dh_installsystemd" (and tidies up a little of the 
substitution handling in the former). The test suite still passes for 
me, and in a few test packages I've attempted building with the patched 
version I *think* the restart behaviour is now fixed in the various 
scenarios outlined above ("--no-stop-on-upgrade" for #994204, and moving 
"--restart-after-upgrade" to "--no-restart-after-upgrade" for #989155).


However, my Perl skills are extremely rusty, and this is not an area I'm 
overly familiar with, so any additional scrutiny is very welcome!


[1]: https://salsa.debian.org/debian/debhelper/-/merge_requests/61

[2]: https://salsa.debian.org/debian/debhelper/-/commit/6067bc2f

[3]: https://salsa.debian.org/debian/debhelper/-/commit/5b27a541


Best regards,

Dave Jones.

Bug#1004844: games-finest: Consider adding endless-sky

[Dave Vasilevsky]

Package: games-finest
Version: 4
Severity: wishlist
X-Debbugs-Cc: d...@vasilevsky.ca

Hi,

Thanks for all your work maintaining debian-games.

It's been a few years since we've added anything new to games-finest, and I
think endless-sky would be a great choice. It's pretty polished, and runs
great in Debian even on basic GPUs. It has shown up on several
best-of-open-source lists, eg:

* https://www.makeuseof.com/tag/open-source-video-games/
* https://www.slant.co/topics/1933/~best-open-source-games
* 
https://medium.com/swlh/free-open-source-linux-games-that-are-actually-good-6cb97177c6e6

There aren't many other games in debian main like it: I guess just naev and
oolite (oldstable), and none of those are in games-finest. Also, the popcon
numbers for endless-sky are already ahead of several other simulation games
in games-finest:

   253  bsdgames
   116  openttd
77  unknown-horizons
67  flightgear
47  pinball-data
43  foobillardplus
40  lincity-ng
40  micropolis
--> 38  endless-sky
36  bzflag-client
14  cultivation
14  searchandrescue

I hope I've made a good case! Thanks again.

-V   


-- 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-11-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages games-finest depends on:
ii  games-tasks  4

Versions of packages games-finest recommends:
ii  0ad   0.0.23.1-5+b1
ii  7kaa  2.15.4p1+dfsg-1
ii  a7xpg 0.11.dfsg1-10+b1
ii  abe   1.1+dfsg-4
ii  ace-of-penguins   1.5~rc2-4
ii  alex4 1.1-9
ii  armagetronad  0.2.9.1.0-2
ii  asc   2.6.1.0-7+b2
ii  atomix3.34.0-2
ii  bastet0.43-6+b1
ii  berusky   1.7.2-1
ii  biniax2   1.30-5
ii  blobby1.0-3+b1
ii  bloboats  1.0.2+dfsg-3
ii  blobwars  2.00-1.2
ii  blockattack   2.6.0-1+b1
ii  bsdgames  2.17-28
ii  btanks0.9.8083-9
ii  burgerspace   1.9.3-1
ii  bzflag-client 2.4.20-1
ii  caveexpress   2.5.1-1
ii  cgoban1.9.14-19
ii  chromium-bsu  0.9.16.1-2
ii  cultivation   9+dfsg1-2+b2
ii  dreamchess0.3.0-1
ii  empire1.16-1
ii  enigma1.20-dfsg.1-2.2
ii  epiphany  0.7.0+0-6
ii  extremetuxracer   0.8.0-1
ii  flare-game1.09.01-1
ii  flightgear1:2020.3.6+dfsg-1
ii  foobillardplus3.43~svn170+dfsg-6
ii  freeciv   2.6.3-1
ii  freecol   0.11.6+dfsg2-3
ii  freedroidrpg  0.16.1-6
ii  freeorion 0.4.10.1-1+b2
ii  frozen-bubble 2.212-9+b3
ii  funguloids1.06-14+b1
ii  funnyboat 1.5-11
ii  gnubg 1.06.002-4+b2
ii  gtkatlantic   0.6.3-1
ii  hedgewars 1.0.0-14+b1
ii  holotz-castle 1.3.14-11
ii  hyperrogue11.3o-1
ii  kobodeluxe0.5.1-10
ii  koules1.4-27
ii  lbreakout22.6.5-2
ii  lincity-ng2.9~git20150314-4
ii  liquidwar 5.6.5-2
ii  lmemory   0.6c-10
ii  lugaru1.2-5
ii  manaplus  1.9.3.23-6
ii  marsshooter   0.7.6-5
ii  megaglest 3.13.0-6
ii  micropolis0.0.20071228-10
ii  minetest  5.3.0+repack-2.1
ii  nethack-console   3.6.6-2+b1
ii  nettoe1.5.1-3
ii  neverball 1.6.0+git20180603-3
ii  neverputt 1.6.0+git20180603-3
ii  nexuiz2.5.2+dp-8
ii  numptyphysics 0.2+svn157-0.5
ii  open-invaders 0.3-5
ii  openarena 0.8.8+dfsg-5
ii  openclonk 8.1-2
ii  openttd   1.10.3-1
ii  pacman10-18
ii  parsec47  0.2.dfsg1-9+b2
ii  pathological  1.1.3-16
ii  performous1.1+git20181118-4+b2
ii  pinball   0.3.20201218-4
ii  pingus0.7.6-5.1
ii  pioneers  15.6-1
ii  pokerth   1.1.2-1.1
ii  powermanga0.93.1-4
ii  pybik 3.0-3.1
ii  pysolfc   2.6.4-3
ii  raincat   1.1.1.2-4+b1
ii  redeclipse1.6.0-1
ii  ri-li 2.0.1+ds-10
ii  scorched3d44+dfsg-7
ii  searchandrescue   1.5.0-2.1
ii  sgt-puzzles   20191231.79a5378-3
ii  solarwolf 1.5+dfsg1-3
ii  sopwith   1.8.4-15
ii  springlobby   0.271-1
ii  supertransball2   1.5-10
ii  supertux  0.6.2-1+b2
ii  supertuxkart  1.2+ds2-1
ii  tecnoballz0.93.1-10
ii  teeworlds 0.7.5-1
ii  torcs 1.3.7+dfsg-5
ii  torus-trooper 0.22.dfsg1-12+b1
ii  tuxfootball   0.3.1-7
ii  tuxmath   2.0.3-8
ii  tuxpuck   0.8.2-11
ii  ufoai 2.5-6
ii  unknown-horizons  2019.1-3
ii  warmux1:11.04.1+repack2-4
ii  warzone2100   3.3.0-4
ii  wesnoth   1:1.14.15-1
ii  w

Bug#1004485: spamass-milter: 'Could not retrieve sendmail macro "b"' with postfix

[Dave Love]

Package: spamass-milter
Version: 0.4.0-2
Severity: normal
X-Debbugs-Cc: none, Dave Love 

I see this in syslog when mail is processed with postfix configured
according to README.Debian:

  spamass-milter[673]: Could not retrieve sendmail macro "b"!.  Please add it 
to confMILTER_MACROS_ENVRCPT for better spamassassin results

It goes away if I add b to milter_rcpt_macros, so presumably that should
be added to the README.

I just thought to check the Fedora packaging
<https://src.fedoraproject.org/rpms/spamass-milter/blob/rawhide/f/spamass-milter.README.Postfix>,
and that says

  milter_connect_macros must include the j and _ macros
  milter_rcpt_macrosmust include the b, r, v, and Z macros

(I don't see any other macro warnings.)

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN, 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 spamass-milter depends on:
ii  adduser 3.118
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libmilter1.0.1  8.15.2-22
ii  libstdc++6  10.2.1-6
ii  spamc   3.4.6-1

Versions of packages spamass-milter recommends:
ii  postfix   3.5.6-1+b1
pn  spamassassin  

spamass-milter suggests no packages.

-- no debconf information

Bug#1004014: open-iscsi: Duplicate dh_installsystemd section in d/rules

[Dave Jones]

Source: open-iscsi
Version: 2.1.5-1
Severity: important

Dear Maintainer,

In commit 693da74e, it appears lintian-brush changed both the 
override_dh_systemd_enable and override_dh_systemd_start sections in 
d/rules to override_dh_installsystemd with the result that there are now 
two override_dh_installsystemd rules in the makefile. The first is 
presumably ignored with the result that the postinst/prerm sections for 
the iscsid.service unit are omitted.

Best regards,

Dave Jones.

Bug#1003626: binutils-doc: --as-needed default is wrongly documented

[Dave Love]

Package: binutils-doc
Version: 2.35.2-2
Severity: normal
X-Debbugs-Cc: none, Dave Love 

The Info and man pages for ld say "--no-as-needed restores the default
behaviour", but the default changed at some stage to --as-needed.

  $ cc -shared -lm -o x.so
  $ lddtree x.so
  x.so => ./x.so (interpreter => none)
  $ cc -shared -Wl,--no-as-needed -lm -o x.so
  $ lddtree x.so
  x.so => ./x.so (interpreter => none)
  libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
  ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

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

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

binutils-doc depends on no packages.

binutils-doc recommends no packages.

Versions of packages binutils-doc suggests:
ii  binutils  2.35.2-2

-- no debconf information

Bug#1003616: tpm2-abrmd: systemd complains about syslog

[Dave Love]

Package: tpm2-abrmd
Version: 2.3.3-1+b2
Severity: normal
X-Debbugs-Cc: none, Dave Love 

I see this noise in my logs which might be worth cleaning up:

  /lib/systemd/system/tpm2-abrmd.service:12: Standard output type syslog
  is obsolete, automatically updating to journal. Please update your
  unit file, and consider removing the setting altogether.

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN, 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 tpm2-abrmd depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u2
ii  libglib2.0-0 2.66.8-1
ii  libtss2-mu0  3.0.3-2
ii  libtss2-rc0  3.0.3-2
ii  libtss2-sys1 3.0.3-2
ii  libtss2-tctildr0 3.0.3-2

tpm2-abrmd recommends no packages.

tpm2-abrmd suggests no packages.

-- no debconf information

Bug#1002511: podget: maybe use ugrep as preferred alternative to grep

[Dave Vehrs]

On Thu, Dec 23, 2021 at 04:06:46PM +0100, Jonas Smedegaard wrote:
> Source: podget
> Version: 0.8.10-1
> Severity: wishlist
> 
> I notice that podget depends on grep.
> 
> An alternative to grep, ugrep, should be radically faster and should
> support command-line options of GNU grep, so I encourage testing if it
> works as a drop-in replacement - with a speed gain.
> 
> 
>  - Jonas

Interesting idea.  However Podget is also built for other operating
systems.  I can see ugrep packages for FreeBSD and OpenBSD but not for
NetBSD.  There also appear to be problems with the MacOS version and
making sure it's dependencies are installed.  Don't think this will be a
drop-in replacement given where we expect Podget to work.


-- 
Dave VehrsEmail: dve...@gmail.com

Bug#965379: Sometimes draws hyphens after each word

[Dave]

 I have version 0.12.10dfsg2-5 installed, and suffered the same issue.

 Found a fix for it.  Go to Options, and select the Styles tab.  Under
"Options for", choose "Regular Paragraph".  Click on the "Allow Hyphenations"
checkbox until it looks grey or solid.  Restart fbreader.

 Text in ebook is now no longer filled with hyphens.

 Cheers,
 dave

Bug#1000974: [PATCH xfsprogs-5.14.2 URGENT] libxfs: hide the drainbamaged fallthrough macro from xfslibs

[Dave Chinner]

On Sun, Dec 05, 2021 at 09:49:51AM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong 
> 
> Back in mid-2021, Kees and Gustavo rammed into the kernel a bunch of
> static checker "improvements" that redefined '/* fallthrough */'
> comments for switch statements as a macro that virtualizes either that
> same comment, a do-while loop, or a compiler __attribute__.  This was
> necessary to work around the poor decision-making of the clang, gcc, and
> C language standard authors, who collectively came up with four mutually
> incompatible ways to document a lack of branching in a code flow.
> 
> Having received ZERO HELP porting this to userspace, Eric and I
> foolishly dumped that crap into linux.h, which was a poor decision
> because we keep forgetting that linux.h is exported as a userspace
> header.  This has now caused downstream regressions in Debian[1] and
> will probably cause more problems in the other distros.
> 
> Move it to platform_defs.h since that's not shipped publicly and leave a
> warning to anyone else who dare modify linux.h.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000974
> 
> Fixes: df9c7d8d ("xfs: Fix fall-through warnings for Clang")
> Cc: 1000...@bugs.debian.org, gustavo...@kernel.org, keesc...@chromium.org
> Signed-off-by: Darrick J. Wong 
> ---
>  include/linux.h|   20 ++--
>  include/platform_defs.h.in |   21 +
>  2 files changed, 23 insertions(+), 18 deletions(-)
> 
> diff --git a/include/linux.h b/include/linux.h
> index 24650228..054117aa 100644
> --- a/include/linux.h
> +++ b/include/linux.h
> @@ -360,24 +360,8 @@ fsmap_advance(
>  #endif /* HAVE_MAP_SYNC */
>  
>  /*
> - * Add the pseudo keyword 'fallthrough' so case statement blocks
> - * must end with any of these keywords:
> - *   break;
> - *   fallthrough;
> - *   continue;
> - *   goto ;
> - *   return [expression];
> - *
> - *  gcc: 
> https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#Statement-Attributes
> + * Reminder: anything added to this file will be compiled into downstream
> + * userspace projects!

This comment belongs at the top of the file before all the includes,
not at the end of it. Otherwise looks ok for a quick fix.

Reviewed-by: Dave Chinner 

But I have to wonder - why is this file even exported to userspace?
It's mostly the xfsprogs source build wrapper stuff for linux -
there's no public API in it except for xfsctl()

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Dave Jones]

Hi Bastian,

Thanks for the comments so far! Just one thing to clear up, I think:

On Tue, Nov 16, 2021 at 02:27:11AM +0100, Bastian Germann wrote:
[snip]

d/watch
===
debian-watch-file-is-missing

This is very important when you have several packages to maintain. It keeps 
track of new releases.


Unfortunately in this case, upstream's form of distribution doesn't 
work with Debian's uscan tooling. Specifically, they distribute 
their various libraries and tools (including lg) as a zip file named 
after the project without a version component. The version component 
is stored as an empty file within the root of the zip file.

[snip]


I just checked http://abyz.me.uk/lg/lg.zip against the GitHub 
releases/tags provided archive. They are not bit-by bit identical but 
contain the same source. As .zip cannot be used as an orig tarball 
directly, it is actually preferrable in this case not to get the 
author-uploaded zip but to use the GitHub tar.gz archive.


You can use one of uscan's versionmangle options to add the .0.0 but 
in my opinion you can also just go with the GitHub tag version. So, 
please replace your get-orig-source script by d/watch.


Unfortunately, the Git repo tags only represent a tiny fraction of the 
releases done so far. This should show the set of releases that have 
actually been made:


  $ git clone https://github.com/joan2937/lg
  $ cd lg
  $ for h in $(git rev-list master); do
  > git show $h^{tree} | grep "^v[0-9.]*$"
  > done | uniq
  v0.2.0.0
  v0.1.7.0
  v0.1.6.2
  v0.1.6.1
  v0.1.6.0
  v0.1.5.8
  v0.1.5.7
  v0.1.5.6
  v0.1.5.5
  v0.1.5.4
  v0.1.5.3
  v0.1.5.2
  v0.1.5.1
  v0.1.5.0
  v0.1.4.0
  v0.1.3.0
  v0.1.2.2
  v0.1.2.1
  v0.1.2.0
  v0.1.1.0
  v0.1.0.4
  v0.1.0.3
  v0.1.0.2
  v0.1.0.1
  v0.1.0.0
  v0.0.4.3
  v0.0.4.2
  v0.0.4.1
  v0.0.4.0
  v0.0.3.1
  v0.0.3.0
  v0.0.2.0
  v0.0.1.0

In rather stark contrast to:

  $ git tag
  v0.0
  v0.1
  v0.2

In other words, it would appear the author doesn't create tags for every 
release, just major ones. If that's all Debian would be interested in, I 
can certainly put together a d/watch file but I wonder whether it's 
preferable to have an option that picks up all releases (albeit a 
horribly non-standard one)?


Actually, you are already claiming in d/copyright that Source is 
https://github.com/joan2937/lg.


Ah, I was under the mis-apprehension that was a relatively informal 
field that simply pointed at a "useful" source location rather than a 
specific source (the archive location in this case is rather less useful 
than the git repo, given it's only ever the latest version available). 

Happy to adjust this accordingly, but figured I'd wait on your response 
to the point above about missing versions before going ahead.


Thanks,

Dave.

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Dave Jones]

Hi Bastian,

On Sun, Nov 14, 2021 at 01:58:54AM +0100, Bastian Germann wrote:

On Mon, 1 Nov 2021 14:43:14 + Dave Jones wrote:
Filed bug #998243 against wnpp, and took the opportunity to bump the 
packaging to 0.2.0.0 while doing so; packaging is updated on salsa, 
and the source package is also uploaded to mentors.

d/watch
===
debian-watch-file-is-missing

This is very important when you have several packages to maintain. It 
keeps track of new releases.


Unfortunately in this case, upstream's form of distribution doesn't work 
with Debian's uscan tooling. Specifically, they distribute their various 
libraries and tools (including lg) as a zip file named after the project 
without a version component. The version component is stored as an empty 
file within the root of the zip file.


In other words, it's not possible (or more accurately I couldn't work 
out how) to get uscan to determine a new version is available and 
download it.


However, I agree entirely that this is an important piece of tooling for 
any maintainer, hence my inclusion of a simple "get-orig-source" script 
in the debian/ directory (also referenced as the "get-orig-source" 
target of d/rules) which does the equivalent job to uscan in this case 
(downloads the appropriate zip archive from upstream, checks if it 
matches the present one, and calls mk-origtargz on the result as 
necessary).



d/copyright
===
Please consider relicensing debian/* or at least debian/patches/* to 
the Unlicense as well.
The effective license of your patched package is GPL-3+ now, given 
that your patches are actually copyrightable. Also, upstream would not 
take your patches.


Good point -- certainly happy to relicense the debian/* bits as 
Unlicense (I was surprised to learn that on Debian SQLite, a famously 
public domain piece of software, is likewise GPL licensed as a result of 
this).



Please rename what is now called public-domain to Unlicense.


Fixed (though I'm slightly dis-heartened that unlicensed stuff can't be 
trivially labelled public-domain).



d/control
=
duplicate-short-description liblgpio-dev liblgpio1 python3-lgpio


Fixed.


python3-rgpio: package-contains-no-arch-dependent-files


Ah yes, the rgpio Python bit should indeed be "all". Fixing that caused 
a "not-binnmuable-all-depends-any" tag to pop up in lintian, which is 
something new to me (and led to some "what is binnmu?" googling). I 
*appear* to have fixed that by cargo-culting the tag's recommendation to 
change the dependency to >= source:Version but I wonder if there's some 
subtlety I'm missing. Would be grateful if you (or anyone) could verify 
this is indeed correct now.



d/changelog
===
Why are the .0.0 in your upstream version? I see 0.2 on GitHub.


The GitHub repo doesn't have the definitive list of versions (e.g. 
0.1.6.1 and 0.1.7.0, which were released, are missing); the author's 
versioning scheme (within the source archive) always includes four 
components, so I assumed the upstream component of the debian version 
number should do likewise?


Though, in light of the "not-binnmuable-all-depends-any" tag I 
encountered above, I wonder if they should be left off to permit a 
stronger Depends line for python3-rgpio?



symbols
===
symbols-file-missing-build-depends-package-field liblgpio.so.1 librgpio.so.1


Fixed.


Thanks for the review,

Dave Jones.

Bug#996894: colordiff: Error messages interrupt output

[Dave Ewart]

On Tuesday, 09.11.2021 at 18:26 +, Reuben Thomas wrote:

> On Tue, 9 Nov 2021 at 17:45, Dave Ewart  wrote:
> 
> > To be honest I’m not sure. Feel free to inspect the source :-)
> >
> 
> As far as I can tell, STDOUT in perl is line buffered when connected to a
> terminal anyway (which should have been my case).
> 
> Perhaps therefore the problem is that the diff process, as it's running
> asynchronously, might simply interleave its output in any case, and to fix
> it it would be necessary to capture its stderr…

I must be honest, I can't replicate the issue you are seeing at all,
neither on Debian/10.x nor Ubuntu/20.04 LTS. This is using the packaged
version of colordiff (which happens to be 1.0.18 in both cases).

Testing the commands 'colordiff -r foo bar' and '/usr/bin/diff -r foo
bar' for the artificially-created test case results in this output in
both cases on Debian:

diff -r foo/afile1 bar/afile1
1c1
< Something is here
---
> Something else is here
/usr/bin/diff: foo/baz: No such file or directory
diff -r foo/file1 bar/file1
1c1
< This is a file
---
> This is another file

On Ubuntu I get the same as above for the plain diff invocation and instead:

diff: foo/baz: No such file or directory
diff -r foo/afile1 bar/afile1
1c1
< Something is here
---
> Something else is here
diff -r foo/file1 bar/file1
1c1
< This is a file
---
> This is another file

for the colordiff variant.

None of the above show your original text where the line breaks were
broken up:

-Foo
diff: bar/baz.html+Bar
: No such file or directory

As it stands it seems necessary to understand why different results are
appearing in different contexts, because it seems likely due to
something other than colordiff per se.

Dave.

-- 
Dave Ewart da...@sungate.co.uk

Bug#996894: colordiff: Error messages interrupt output

[Dave Ewart]

To be honest I’m not sure. Feel free to inspect the source :-)

I don’t really know how to address the issue but am open to suggestions!

Dave

On Tue, 9 Nov 2021 at 17:17, Reuben Thomas  wrote:

> On Tue, 9 Nov 2021 at 17:01, Dave Ewart  wrote:
>
>>
>> What platform/OS/etc. does this happen on?
>
>
> Ubuntu 20.04 amd64.
>
> As I asked before, is stdout being flushed before possible stderr output?
>
>
> --
> https://rrt.sc3d.org
>
-- 
Dave Ewart, da...@sungate.co.uk

Bug#996894: colordiff: Error messages interrupt output

[Dave Ewart]

I cannot reproduce the behaviour you reported.

davee@equinox:~/tmp/$ ls -lR
.:
total 8
drwxr-xr-x 2 davee users 4096 Nov  5 13:24 bar
drwxr-xr-x 2 davee users 4096 Nov  5 13:24 foo

./bar:
total 8
-rw-r--r-- 1 davee users 23 Nov  5 13:24 afile1
-rw-r--r-- 1 davee users  0 Nov  5 13:22 baz
-rw-r--r-- 1 davee users 21 Nov  5 13:24 file1

./foo:
total 8
-rw-r--r-- 1 davee users 18 Nov  5 13:24 afile1
lrwxrwxrwx 1 davee users  6 Nov  5 13:23 baz -> ../baz
-rw-r--r-- 1 davee users 15 Nov  5 13:24 file1

$ colordiff -r foo bar
diff -r foo/afile1 bar/afile1
1c1
< Something is here
---
> Something else is here
diff: foo/baz: No such file or directory
diff -r foo/file1 bar/file1
1c1
< This is a file
---
> This is another file

What platform/OS/etc. does this happen on? Apart from not being able to
reproduce the issue it does seem like a *very* unusual scenario where
deliberately-broken links have been introduced.

Dave.

-- 
Dave Ewart da...@sungate.co.uk

Bug#996894: colordiff: Error messages interrupt output

[Dave Ewart]

Just spotted this report, message was spam-trapped. Can you provide an
example where it fails in the manner you indicate?

I don’t understand how you’d get diff output if one of the arguments were
missing, say.

Dave

-- 
Dave Ewart, da...@sungate.co.uk

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Dave Jones]

On Mon, Nov 01, 2021 at 10:55:07AM +, Dave Jones wrote:

On Sun, Oct 31, 2021 at 11:30:30PM +0100, Bastian Germann wrote:

On Thu, 30 Sep 2021 18:30:18 +0200 Bastian Germann  wrote:

Control: tags -1 moreinfo

On Thu, 24 Jun 2021 14:31:00 +0100 Dave Jones  wrote:

Changes for the initial release:

  lg-gpio (0.1.7.0-1) UNRELEASED; urgency=medium

 .
   * Initial Debian release.


You have to close an ITP bug with this. I did not find a RFP or 
ITP bug for this package name in the wnpp pseudo package. So 
please create one and change your changelog accordingly. Also, 
your package should target experimental or unstable.


Ah, I'll get on with fixing this, thanks!


Filed bug #998243 against wnpp, and took the opportunity to bump the 
packaging to 0.2.0.0 while doing so; packaging is updated on salsa, and 
the source package is also uploaded to mentors.

Bug#998243: ITP: lg-gpio -- Control GPIO pins via the kernel's gpiochip device interface

[Dave Jones]

Package: wnpp
Severity: wishlist
Owner: Dave Jones 

* Package name: lg-gpio
  Version : 0.2.0.0-1
  Upstream Author : https://github.com/joan2937/lg
* URL : https://abyz.me.uk/lg
* License : public-domain
  Programming Lang: C, Python
* Vcs : https://salsa.debian.org/python-team/packages/lg-gpio
  Section : electronics
  Description : Control GPIO pins via the kernel's gpiochip device interface

This package provides a comprehensive userspace GPIO interface akin to 
libgpiod (which is already in Debian), but crucially with additional 
methods for performing PWM (and other interfaces).

This makes it a viable replacement for RPi.GPIO (also in Debian) both in 
scripts that directly use that library, as well as those using gpiozero 
(again, already in Debian). In the latter case, the current Debian 
version of gpiozero (1.4 in stable) relies upon RPi.GPIO as its pin 
driver. However from 1.6 onwards (in unstable) it also supports lg-gpio 
as a (preferred) pin driver (though I don't think the patch for 
preferring lg is currently in the Debian version of the packaging).

I'm happy to maintain this package as part of the Python team (although 
the Raspi team might seem more appropriate, there's nothing Raspberry Pi 
specific in lg-gpio).

A request for sponsorship is (possibly prematurely!) open in #990280.

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Dave Jones]

On Sun, Oct 31, 2021 at 11:30:30PM +0100, Bastian Germann wrote:

On Thu, 30 Sep 2021 18:30:18 +0200 Bastian Germann  wrote:

Control: tags -1 moreinfo

On Thu, 24 Jun 2021 14:31:00 +0100 Dave Jones  wrote:

Changes for the initial release:
>   lg-gpio (0.1.7.0-1) UNRELEASED; urgency=medium
  .
* Initial Debian release.


You have to close an ITP bug with this. I did not find a RFP or ITP 
bug for this package name in the wnpp pseudo package. So please 
create one and change your changelog accordingly. Also, your package 
should target experimental or unstable.


Ah, I'll get on with fixing this, thanks!

Also, please explain how you would justify the introduction of this lib 
to Debian when there is libgpiod already.


Certainly -- the TL;DR version is: because libgpiod doesn't provide all 
the facilities required to replace the "legacy" GPIO interfaces 
currently popular on platforms like the Raspberry Pi, while lg-gpio 
does.


The longer version is:

To be a viable replacement for the legacy GPIO interfaces (on which, 
more below), any new interface needs to support the facilities of the 
legacy interfaces. Unfortunately, libgpiod provides no means to perform 
PWM (in software or otherwise) which makes it an unattractive 
replacement for the legacy interfaces. lg-gpio, which is still based on 
the new gpiochip devices, provides this (and quite a few other bits 
besides).


On the Raspberry Pi (and a few other Pi-like platforms) there are 
currently a few popular libraries for manipulating the GPIO pins from 
userspace:


RPi.GPIO -- probably the most popular library, currently in Raspberry Pi 
OS, Debian, and Ubuntu. This is a "legacy" library in that it (mostly) 
bangs directly on the GPIO registers, (mostly) bypassing the kernel. 
Various clones of this library exist for other Pi-like platforms, but 
I'm not sure any of those clones exist in Debian, and they're probably 
not an attractive idea anyway given that things should be moving towards 
using gpiochip (like libgpiod and lg-gpio).


pigpiod -- probably the second most popular library, currently in 
Raspberry Pi OS only. Also bangs directly on the GPIO registers but 
(unlike RPi.GPIO) doesn't require clients to have root authority or 
access to those registers directly (via something like /dev/gpiomem) as 
clients talk to a (root) daemon over a socket instead (which also 
provides the option for remote control of GPIO pins, if the socket is 
bound to something other than localhost). Provides a form of hardware 
PWM (DMA controller banging on the GPIO registers) which is attractive 
to anyone wanting perfect servo control (for example), without 
additional hardware. However, it is *very* architecture specific: 
strictly Raspberry Pi only, and armhf only.


gpiozero -- a high level library providing "device" interfaces (for 
LEDs, buttons, motors, servos, rotary controllers, etc). Exists in 
Raspberry Pi OS, Debian, and Ubuntu (full disclosure: I'm one of the 
developers on this project). This sits on top of "pin drivers" like 
RPi.GPIO, pigpiod, or lg-gpio. I haven't got around to writing a 
libgpiod interface yet (although it is on my to-do list [1]), but when I 
do it won't be able to support things like the Motor class, or Servo, or 
PWMLED because it simply lacks the ability to perform PWM (whilst these 
all work happily with the lg-gpio driver).


Incidentally, lg-gpio (and eventually libgpiod) potentially open 
gpiozero up to being used on more platforms than just the Raspberry Pi 
(although currently, the lg-gpio interface in it is Pi specific as 
that's the only pin layout it knows).


Finally, there's an "rg" (remote GPIO) library that builds on top of 
lg-gpio (by the same author) that fills the same socket-based role that 
pigpiod provides above (perhaps unsurprisingly, the author of pigpiod is 
also the author of lg and rg). I haven't gotten around to writing an rg 
interface layer for gpiozero yet, but it's also on my to-do list.


A more complete write-up of all this (and other aspects) is at [2], but 
hopefully that's enough?


[1] 
https://github.com/gpiozero/gpiozero/issues/840#issuecomment-787521929


[2] 
https://waldorf.waveform.org.uk/2021/the-pins-they-are-a-changin.html



Thanks for your attention,

Dave Jones.

Bug#996472: nspark: Description doesn't say what it does

[Dave Lambley]

> On 14/10/2021 18:45 Justin B Rye  wrote:
>
> Oh, is this another one for my collection of packages where the prefix
> "n-" stands for "new thirty years ago"?

Yes, I'm afraid so.

> My suggestion:
> 
> # de-archiver for !Spark archives
> #
> # nspark ("new spark") supports extracting files from Spark 1 and 2 or
> # ArcFS archives. It is a cross-platform rewrite of David Pilling's
> # original !Spark for RISC OS.
> 
> (assuming I'm interpreting the manual correctly).

Thank you! I have gone for a tweaked version of that (from looking at the 
mentioned packages and the upstream docs) and uploaded it to mentors. Would you 
be able to upload it?

Description: Unarchiver for Spark and ArcFS files
 nspark "New Spark unarchiver" supports extracting from Spark and ArcFS 
files,
 which originate on RISC OS. It is a cross platform rewrite of David 
Pilling's
 original !Spark for RISC OS.

Here is the mentors stuff;

 * Package name: nspark
   Version : 1.7.8B2+git20210317.cb30779-2
   Upstream Author : https://github.com/mjwoodcock
 * URL : https://github.com/mjwoodcock/nspark
 * License : nspark
 * Vcs : https://repo.or.cz/debian-nspark.git
   Section : non-free/utils

It builds those binary packages:

  nspark - Unarchiver for Spark and ArcFS files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/non-free/n/nspark/nspark_1.7.8B2+git20210317.cb30779-2.dsc

Changes since the last upload:

 nspark (1.7.8B2+git20210317.cb30779-2) unstable; urgency=medium
 .
   * Rewrite description (Closes: #996472)

Best regards,
Dave

Bug#992790: Is this fixed in kernel version 5.13?

[Dave Rubie]

One more data point on this issue with this old HP Proliant ML330 G6 - 
installing the Liquorix kernel 5.13.0-14.1-liquorix-amd64 fixed it, the machine 
now boots without having to drop back to the 4.19 kernel.

Bug#985196: on OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working.

[Dave Holland]

I had the same problem when I upgraded my SheevaPlug (armel) from Buster to
Bullseye.

I found this thread:
https://archlinuxarm.org/forum/viewtopic.php?f=15&t=14549

Adding the following service override makes haveged start as expected:

root@puny:~# cat /etc/systemd/system/haveged.service.d/override.conf
[Service]
SystemCallFilter=uname

Please would you consider including that for armel packages?

Cheers,
Dave

Bug#993445: RFS: python-sense-hat/2.2.0-3 -- Sense HAT python library (Python 3)

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-sense-hat":

 * Package name: python-sense-hat
   Version : 2.2.0-3
   Upstream Author : https://github.com/astro-pi/python-sense-hat
 * URL : https://github.com/astro-pi/python-sense-hat
 * License : BSD-3-Clause
 * Vcs : https://salsa.debian.org/raspi-team/python-sense-hat
   Section : python

It builds those binary packages:

  python3-sense-hat - Sense HAT python library (Python 3)

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


  https://mentors.debian.net/package/python-sense-hat/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-sense-hat/python-sense-hat_2.2.0-3.dsc

Changes for the initial release:

 python-sense-hat (2.2.0-3) unstable; urgency=medium
 .
   * Initial Debian release.

Regards,
--
  Dave Jones

Bug#993443: RFS: rtimulib/7.2.1-6 [ITP] -- Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU library (Python 3)

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: rtimulib
   Version : 7.2.1-6
   Upstream Author : https://github.com/RPi-Distro/RTIMULib
 * URL : https://github.com/richards-tech/RTIMULib
 * License : MIT, GPL-3.0+, BSD-2-Clause
 * Vcs : https://salsa.debian.org/python-team/packages/rtimulib
   Section : libs

It builds those binary packages:

  python3-rtimulib - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU 
library (Python 3)
  librtimulib-utils - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU 
library (utilities)
  librtimulib-dev - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU 
library (dev files)
  librtimulib7 - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU library 
(shared library)

These packages are pre-requisites for support of the Raspberry Pi Sense 
HAT in Debian (though RTIMULib is more general as is applicable to many 
different IMUs).


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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/r/rtimulib/rtimulib_7.2.1-6.dsc

Changes for the initial release:

 rtimulib (7.2.1-6) unstable; urgency=medium
 .
   * Initial Debian release.

Regards,
-- Dave Jones