from:"kevin"

Bug#1071757: SyntaxWarning: invalid escape sequence with Python 3.12

2024-05-24 Thread Kevin Locke

Package: python3-azext-devops
Version: 1.0.1-1
Severity: normal
Tags: upstream
Forwarded: https://github.com/Azure/azure-devops-cli-extension/pull/1414

Dear Maintainer,

Installing python3-azext-devops 1.0.1-1 produces the following output:

Setting up python3-azext-devops (1.0.1-1) ...
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_0/feed/models.py:101: 
SyntaxWarning: invalid escape sequence '\,'
  """FeedCore.
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_0/feed/models.py:209: 
SyntaxWarning: invalid escape sequence '\,'
  """FeedUpdate.
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_0/feed/models.py:985: 
SyntaxWarning: invalid escape sequence '\,'
  """Feed.
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_1/feed/models.py:101: 
SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_1/feed/models.py:220: 
SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v5_1/feed/models.py:1049:
 SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v6_0/feed/models.py:101: 
SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v6_0/feed/models.py:224: 
SyntaxWarning: invalid escape sequence '\,'
  """
/usr/lib/python3/dist-packages/azext_devops/devops_sdk/v6_0/feed/models.py:1080:
 SyntaxWarning: invalid escape sequence '\,'
  """

I believe this is due to changes in Python 3.12 as a result of
https://github.com/python/cpython/issues/98401.

I have opened a pull request to fix the issue upstream:
https://github.com/Azure/azure-devops-cli-extension/pull/1414

Thanks,
Kevin


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

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

Versions of packages python3-azext-devops depends on:
ii  python33.11.8-1
ii  python3-azure-cli  2.50.0-2
ii  python3-distro 1.9.0-1
ii  python3-keyring25.2.1-1

python3-azext-devops recommends no packages.

python3-azext-devops suggests no packages.

-- no debconf information

Bug#1064543: python3-launchpadlib: Failed to start launchpadlib-cache-clean.service

2024-02-23 Thread Kevin Locke

Package: python3-launchpadlib
Version: 1.11.0-4
Severity: normal

Dear Maintainer,

After upgrading to 1.11.0-4, I have observed the following errors in
my system log:

2024-02-23T15:03:42-07:00 systemd[1538]: launchpadlib-cache-clean.service: 
Failed with result 'exit-code'.
2024-02-23T15:03:42-07:00 systemd[1538]: Failed to start 
launchpadlib-cache-clean.service - Clean up old files in the Launchpadlib cache.

After examining /usr/lib/systemd/user/launchpadlib-cache-clean.service
I suspect that this is because ~/.launchpadlib does not exist for my
user.  It would be nice if the unit only ran when required.  Perhaps

ConditionPathExists=%h/.launchpadlib/api.launchpad.net/cache

could be added to the [Unit] section of launchpadlib-cache-clean.service?

Thanks for considering,
Kevin


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

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

Versions of packages python3-launchpadlib depends on:
ii  init-system-helpers 1.66
ii  python3 3.11.6-1
ii  python3-httplib20.20.4-3
ii  python3-lazr.restfulclient  0.14.6-1
ii  python3-lazr.uri1.0.6-3

python3-launchpadlib recommends no packages.

Versions of packages python3-launchpadlib suggests:
ii  python3-keyring24.3.0-1
ii  python3-pkg-resources  68.1.2-2
pn  python3-testresources  

-- no debconf information

Bug#1063858: False disk set size in README.(html|txt), and a few minor corrections

2024-02-13 Thread Kevin Price

Package: debian-cd
X-Debbugs-Cc: J.A. Bezemer , Steve
McIntyre 
Version: 3.2.1
Severity: minor

Dear maintainers, dear Steve[1]:

In the official current stable (12.5) images, the /README.(html|txt)
files (see att.) seem to miscount the total number of disks in each set.
For instance, in debian-12.5.0-amd64-DLBD-2.iso, section "About This
Disc" says: "[...]this disc is number 2 of a set of 1 discs"

1. This is obviously false, not only in the DLBD images.

While we're at it, could we tidy up the generating script in a few more
minor details, without separate bug reports maybe?

2. Aforementioned sentence's full stop is awkwardly misplaced in the
html (line-break in-between), and it's missing in the txt.

3. I was not quite certain about the version number to file this bug
against, so I took a look at the XHTML header for sth. like 'meta
name="generator"'. Wouldn't that be helpful to include?

4. The html claims to be "XHTML 1.0 Strict", but fails to validate
against https://validator.w3.org/ . AFAICT, that's only due to errors in
the section "Last-Minute Notes":

4.a. The "" beginning with "This is an official release" lacks a
closing "".

4.b. Where it says "https://bugs.debian.org/;>bugs.debian.org" it should
respectively say "a", "href", and "/a" instead.

5. The html header defines the language to be "English". Maybe "en"
would be more preferable?

Please let me know how I could be of any further assistance in resolving
these issues.

[1] FWIW, See also
https://lists.debian.org/debian-user/2024/01/msg00796.html , and please
accept my apology for being slow to file this bug.

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

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

Versions of packages debian-cd depends on:
ii  apt2.6.1
ii  bc 1.07.1-3+b1
ii  bzip2  1.0.8-5+b1
ii  cpp4:12.2.0-3
ii  curl   7.88.1-10+deb12u5
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.21.22
ii  genisoimage9:1.1.11-3.4
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.21.22
ii  libfile-slurp-perl .32-2
ii  libyaml-libyaml-perl   0.86+ds-1
ii  lynx   2.9.0dev.12-1
ii  make   4.3-4.1
ii  perl [libdigest-sha-perl]  5.36.0-7+deb12u1
ii  pigz   2.6-1
ii  tofrodos   1.7.13+ds-6
ii  uuid-runtime   2.38.1-5+b1
ii  wget   1.21.3-1+b2
ii  xorriso1.5.4-4

Versions of packages debian-cd recommends:
ii  dosfstools   4.2-1
ii  hfsutils 3.2.6-15
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.33-1+really4.0.32-1
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

-- no debconf information

HTH, cheers
-- 
Kevin Price   Debian GNU/Linux 12.5.0 "Bookworm" - Official amd64 DLBD Binary-2 with
   firmware 20240210-11:28

 (HTML version in README.html)

  Welcome to the exciting world of
  Debian GNU/Linux

   This is one disc in a set containing the Debian GNU/Linux distribution.
   Debian is a very extensive collection of software. But it is more. It
   is a complete Operating System (OS) for your computer. And it is free
   (as in "freedom").

   CONTENTS:
 * Introduction
 * About This Disc
 * Installing
 * Last-Minute Notes
 * Installing software using Apt
 * CD/DVD Manufacturers
 * More Information
 * Browse This Disc

Introduction


   An operating system is the set of basic programs and utilities that
   make your computer run. At the core of an operating system is the
   kernel. The kernel is the most fundamental program on the computer,
   which does all the basic housekeeping and lets you start other
   programs. Debian is kernel independent. It currently uses either the
   Linux or FreeBSD kernel. Most of the basic operating system tools come
   from the GNU project; hence the name GNU/Linux.

   Debian is available for various kinds of computers ("architectures").
   Check the ports page for more information.

   Read more at:

 https://www.debian.org/intro/about

About Thi

Bug#1061415: devscripts: dscverify "no file spec lines" when verify sig)

2024-01-23 Thread Kevin Ryde

close 1061415
thanks

Oops, an artifact of a distinctly aged gpg2.
(Still don't know that it's a great idea to use verify output
as a file reader.)

Bug#1061415: devscripts: dscverify "no file spec lines" when verify sig

2024-01-23 Thread Kevin Ryde

Package: devscripts
Version: 2.23.7
Severity: normal
File: /usr/bin/dscverify

When running dscverify on one of my own packages,
so the dsc is signed by me and successfully verify the sig,

dscverify --keyring ~/.gnupg/pubring.gpg x2gpm_11-0.1.dsc

I get an error

dscverify: no file spec lines in x2gpm_11-0.1.dsc
Validation FAILED!!

The dsc file does contains "Files:" section and I hoped dscverify
would check the hashes listed.  It did so in the past, for
instance in version 2.20.1.

I suspect this problem is from change at version 2.21.6.
When gpg2 (version 2.0.28) is run without --verify (as dscverify
did previously), gpg prints the dsc contents to stdout, and
dscverify captures that into "$out".  Now with --verify, that
doesn't happen.

Perhaps process_files() shouldn't have depended on gpg output
including the dsc contents, but instead slurp the dsc file
unconditionally at the desired point.

Bug#1050473: I can help

2024-01-11 Thread Kevin Madrid

Hi all,
I can adopt this package if still needed.

Regards,
Kevin Madrid

Bug#984736: Still looking for Maintainers?

2024-01-11 Thread Kevin Madrid

Hi all,

I am interested in collaborating in this project. 
Are Maintainers still needed?

Regards,
Kevin Madrid

Bug#1004589: GNUnet daemon doesn't start successfully

2023-12-17 Thread Kevin

Package: gnunet
Version: 0.20.0-3
Followup-For: Bug #1004589
X-Debbugs-Cc: deb...@kevinsteen.net

Version 0.20.0-3 still fails to start because of the incorrect log path in
/etc/gnunet.conf

By changing it to:

OPTIONS = -l /var/log/gnunet/gnunet.log

I can get the gnunet service to start correctly.

-Kevin


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

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

Versions of packages gnunet depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u3
ii  libcurl3-gnutls7.88.1-10+deb12u4
ii  libextractor3  1:1.11-7
ii  libgcrypt201.10.1-3
ii  libgnunet0.20  0.20.0-3
ii  libgnutls-dane03.8.2-1
ii  libgnutls303.8.2-1
ii  libidn2-0  2.3.3-1+b1
ii  libjansson42.14-2
ii  libmicrohttpd120.9.75-6
ii  libogg01.3.5-3
ii  libopus0   1.3.1-3
ii  libpng16-161.6.39-2
ii  libpq5 15.5-0+deb12u1
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsodium231.0.18-1
ii  libsqlite3-0   3.40.1-2
ii  libunistring5  1.1-2
ii  libzbar0   0.23.92-7
ii  lsb-base   11.6
ii  netbase6.4
ii  passwd 1:4.13+dfsg1-1+b1
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages gnunet recommends:
pn  libnss3-tools  
ii  openssl3.0.11-1~deb12u2

Versions of packages gnunet suggests:
pn  miniupnpc  
pn  texlive

-- Configuration Files:
/etc/gnunet.conf [Errno 2] No such file or directory: '/etc/gnunet.conf'

-- debconf information:
  gnunet/title:
  gnunet/group: gnunet
  gnunet/user: gnunet
  gnunet/autostart: true

Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable

2023-12-11 Thread Kevin Price

Breaking news:

Am 11.12.23 um 19:14 schrieb Salvatore Bonaccorso:
> I have put binary packages for amd64 built in
> https://people.debian.org/~carnil/tmp/linux/1057967/

I confirm this test kernel is working fine for me, even with non-free
broadcom-sta.

(sent from
"
cat /proc/version

Linux version 6.1.0-0.a.test-amd64 (debian-ker...@lists.debian.org)
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian)
2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.66-1a~test (2023-12-11)
"

through

"
modinfo wl

filename:   /lib/modules/6.1.0-0.a.test-amd64/updates/dkms/wl.ko
license:MIXED/Proprietary
alias:  pci:v*d*sv*sd*bc02sc80i*
depends:cfg80211
…"
)

Thank you Salvatore. Let's get this into stable soon.
-- 
Kevin Price

Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable

2023-12-11 Thread Kevin Price

Control: affects -1 + src:broadcom-sta linux-image-6.1.0-15-amd64

@other affected users: What wifi drivers are you using, and do they
taint your kernel?

Am 11.12.23 um 13:27 schrieb Kevin Price:
> Am 11.12.23 um 12:37 schrieb Salvatore Bonaccorso:

> Need any more logfiles or testing?

Is it syslog that might help you better, or any other log? Just let me
know please. I'd love to help figure this out with mutual support.

> I intend to test debian-live-12.4.0-amd64-gnome.iso

*drumroll* Now this comes as a surprise to me.
debian-live-12.4.0-amd64-gnome displays none of the bad behavior, even
when actively using wifi. Apart from firmware, there's no non-free
involved in debian-live.

So could it be just some local configuration choice of mine, and of all
the other affected users? Some years-old but possibly now poor choice of
drivers/firmware maybe? I faintly remember having tried a free driver on
this card at least two debian releases ago, but it worked so bad I had
to switch to a non-free one:
https://packages.debian.org/bookworm/broadcom-sta-dkms

Which since has been upgraded with each debian release.

Another Test: My old hardware has a physical RF kill switch. So I booted
up 6.1.0-15 with it turned off: *drumroll* Works fine. So wifi seems to
be singled out as the culprit in my case. (or possibly bluetooth, but I
strongly doubt)

See attachments regarding my wifi. Shame on me, if anyone ever
suggested: "Never file a bug against a tainted kernel", because I did.
But maybe it was good to do so. Because this bug is still very relevant,
as it affects not only me, but renders multiple people's computers
practically unusable when upgrading to 6.1.0-15. Not like "wifi gone
bad", but "computer gone bad". This shouldn't happen within a stable
debian release IMHO, and thus justifies some fairly high level of
severity, IMHO. "critical", IDK. You own this bug, you decide.

Now I conclude that 6.1.0-15 not only breaks src:broadcom-sta, but also
vice versa. Are there any other wifi drivers affected?

>> I'm right now curious to find out if we see the same as
>> #1057969 and if the upstream commit db46c77f3d51 ("Revert "wifi:
>> cfg80211: fix CQM for non-range use"") in 6.1.67 upstream fixes the
>> issue.

Now that sounds to me like exactly what caused this. Good to know that
upstream has already reverted this regression. Please let me know what
else to test or contribute, so that we can look forward to a debian
stable 6.1 kernel without this bug.

@Salvatore: Thanks a ton for your excellent work. Very much appreciated.

HTH
-- 
Kevin Pricesudo lspci -vvs2:0
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4313 802.11bgn 
Wireless Network Adapter (rev 01)
Subsystem: Broadcom Inc. and subsidiaries BCM4313 802.11bgn Wireless 
Network Adapter
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Address:   Data: 
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 
unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- 
SlotPowerLimit 10W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ 
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L1, Exit Latency 
L1 <64us
ClockPM+ Surprise- LLActRep+ BwNot- ASPMOptComp-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1
TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr-
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr+
AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- 
ECRCChkCap+ ECRCChkEn-
MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
HeaderLog:

Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable

2023-12-11 Thread Kevin Price

Thank you Salvatore!

Am 11.12.23 um 12:37 schrieb Salvatore Bonaccorso:
> It still would be helpfull if you can get to the logs of the previous
> boot. After booting back in the working kernel, do you have anything
> sensible logged in the previous boot log? If so can you share that
> please?

Sure. Here's my boot.log.

The first one at "Mon Dec 11 00:54:03 CET 2023" is the faulty 6.1.0-15.

The 2nd one at "Mon Dec 11 01:13:38 CET 2023" is the working 6.1.0-13.

Need any more logfiles or testing? I intend to test
debian-live-12.4.0-amd64-gnome.iso on my computer, IOT rule out any
local config peculiarities, FWIW.

> I'm right now curious to find out if we see the same as
> #1057969 and if the upstream commit db46c77f3d51 ("Revert "wifi:
> cfg80211: fix CQM for non-range use"") in 6.1.67 upstream fixes the
> issue.

Please let me know what kernel version you want me to test, if they're
provides as debian binaries. I'd be glad to help, probably not only for
my own sake. Bear with me I'm unwilling to build kernel packages myself,
due to lack of computing resources. HTH
-- 
Kevin Price Mon Dec 11 00:54:03 CET 2023 
/: clean, 635496/28696576 files, 99342237/114756608 blocks
 Mounting [0;1;39mproc-sys-fs-binfmt_misc.mount[0m - Arbitrary Executable File Formats File System...
[[0;32m  OK  [0m] Finished [0;1;39msystemd-cryptsetup@cryptswap1.service[0m - Cryptography Setup for cryptswap1.
[[0;32m  OK  [0m] Mounted [0;1;39mproc-sys-fs-binfmt_misc.mount[0m - Arbitrary Executable File Formats File System.
[[0;32m  OK  [0m] Reached target [0;1;39mblockdev@dev-mapper-cryptswap1.target[0m - Block Device Preparation for /dev/mapper/cryptswap1.
[[0;32m  OK  [0m] Reached target [0;1;39mcryptsetup.target[0m - Local Encrypted Volumes.
[[0;32m  OK  [0m] Finished [0;1;39msystemd-binfmt.service[0m - Set Up Additional Binary Formats.
[[0;32m  OK  [0m] Finished [0;1;39msystemd-tmpfiles-setup.service[0m - Create Volatile Files and Directories.
 Starting [0;1;39mmodprobe@dm_mod.service[0m - Load Kernel Module dm_mod...
 Starting [0;1;39mmodprobe@efi_pstore.service[0m - Load Kernel Module efi_pstore...
 Starting [0;1;39mmodprobe@loop.service[0m - Load Kernel Module loop...
 Starting [0;1;39msystemd-resolved.service[0m - Network Name Resolution...
 Starting [0;1;39msystemd-update-utmp.service[0m - Record System Boot/Shutdown in UTMP...
[[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.service[0m - Load Kernel Module dm_mod.
[[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_pstore.service[0m - Load Kernel Module efi_pstore.
[[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel Module loop.
[[0;32m  OK  [0m] Found device [0;1;39mdev-mapper-cryptswap1.device[0m - /dev/mapper/cryptswap1.
 Activating swap [0;1;39mdev-mapper-cryptswap1.swap[0m - /dev/mapper/cryptswap1...
[[0;32m  OK  [0m] Finished [0;1;39msystemd-update-utmp.service[0m - Record System Boot/Shutdown in UTMP.
[[0;32m  OK  [0m] Activated swap [0;1;39mdev-mapper-cryptswap1.swap[0m - /dev/mapper/cryptswap1.
[[0;32m  OK  [0m] Reached target [0;1;39mswap.target[0m - Swaps.
[[0;32m  OK  [0m] Finished [0;1;39mapparmor.service[0m - Load AppArmor profiles.
[[0;32m  OK  [0m] Started [0;1;39msystemd-resolved.service[0m - Network Name Resolution.
[[0;32m  OK  [0m] Reached target [0;1;39mnss-lookup.target[0m - Host and Network Name Lookups.
[[0;32m  OK  [0m] Reached target [0;1;39msysinit.target[0m - System Initialization.
[[0;32m  OK  [0m] Started [0;1;39mcups.path[0m - CUPS Scheduler.
[[0;32m  OK  [0m] Started [0;1;39manacron.timer[0m - Trigger anacron every hour.
[[0;32m  OK  [0m] Started [0;1;39mapt-daily.timer[0m - Daily apt download activities.
[[0;32m  OK  [0m] Started [0;1;39mapt-daily-upgrade.timer[0m - Daily apt upgrade and clean activities.
[[0;32m  OK  [0m] Started [0;1;39mdpkg-db-backup.timer[0m - Daily dpkg database backup timer.
[[0;32m  OK  [0m] Started [0;1;39me2scrub_all.timer[0m - Periodic ext4 Online Metadata Check for All Filesystems.
[[0;32m  OK  [0m] Started [0;1;39mlogrotate.timer[0m - Daily rotation of log files.
[[0;32m  OK  [0m] Started [0;1;39mman-db.timer[0m - Daily man-db regeneration.
[[0;32m  OK  [0m] Started [0;1;39mntpsec-rotate-stats.timer[0m - Rotate ntpd stats daily.
[[0;32m  OK  [0m] Started [0;1;39msystemd-tmpfiles-clean.timer[0m - Daily Cleanup of Temporary Directories.
[[0;32m  OK  [0m] Reached target [0;1;39mpaths.target[0m - Path Units.
[[0;32m  OK  [0m] Reached target [0;1;39mtimers.target[0m - Timer Units.
[[0;32m  OK  [0m] Listening on [0;1;39mavahi-daemon.socket[0m - Avahi mDNS/DNS-SD Stack Activation Socket.
[[0;32m  OK  [0m] Listening on [0;1;39mcups.socket[0m - CUPS Scheduler.
[[0;32m  OK  [0m] Listening on [0;1;39mdbus

Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable

2023-12-10 Thread Kevin Price

Package: linux-image-6.1.0-15-amd64
Version: 6.1.66-1
Severity: critical
Control: -1 notfound 6.1.64-1

When booting 6.1.0-15, my physical amd64/bookworm/gnome computer
misbehaves in many ways, rendering it largely unusable. With kernels up
to 6.1.0-13, and even briefly with the otherwise broken 6.1.0-14, all of
this seemed fine.

Misbehavior includes, not limited to:

1. Most actions take considerably longer than usual.

2. The GDM greeter has an English keyboard layout, which otherwise is
German. (Login works.)

3. There seems to be no network connectivity. No WiFi icon. "ping
8.8.8.8" returns IIRC network unreachable.

4. Launching Firefox does apparently nothing.

5. Launching gnome-terminal does work, but some basic commands just
freeze, such as "ip a" or "sudo dmesg". sudo hangs before prompting for
the passphrase. At that stage, even "sudo -i", I cannot interrupt with "^C".

6. Shutting down takes ages, with systemd waiting for a bunch of
processes (sudo) and services to terminate, most of the latter seem to
be somehow network-related, but you tell me which aren't.

After more that 10 min I used hard power-off, leaving my ext4 dirty, but
being perfectly able to boot any of 6.1.0-12 through -15, with -12 and
-13 working properly, and -15 showing the exact same misbehavior
reproducibly.

I'll attach all I could get out of reportbug running under 6.1.0-15, and
please let me know what further testing I may perform IOT help you.
Please also specify whether you'd like me to do that testing under
6.1.0-15, in which I cannot even invoke sudo, or under 6.1.0-13, which
will do anything fine.

Thanks a lot in advance, and HTH!
-- 
Kevin PriceContent-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Kevin Price 
To: Debian Bug Tracking System 
Subject: linux-image-6.1.0-15-amd64 makes my physical bookworm/gnome system 
vastly unusable
Bcc: Kevin Price 

Package: src:linux
Version: 6.1.66-1
Severity: critical



-- Package-specific info:
** Version:
Linux version 6.1.0-15-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.66-1 (2023-12-09)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-15-amd64 
root=UUID=b1e4af52-2d43-40ab-a468-ca11bf2a3122 ro quiet

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

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

** Model information
sys_vendor: LENOVO
product_name: 1068FQG
product_version: Lenovo B570
chassis_vendor: LENOVO
chassis_version: 0.1
bios_vendor: LENOVO
bios_version: 44CN41WW
board_vendor: LENOVO
board_name: Emerald Lake
board_version: FAB1

** Loaded modules:
cts
uinput
rfcomm
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
xt_CHECKSUM
xt_MASQUERADE
bridge
stp
llc
cmac
algif_hash
algif_skcipher
af_alg
bnep
ip6t_rt
ip6t_REJECT
nf_reject_ipv6
nft_chain_nat
nf_nat
xt_set
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
xt_conntrack
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nft_compat
nf_tables
binfmt_misc
ip_set_hash_ipport
pktcdvd
ip_set
nfnetlink
intel_rapl_msr
intel_rapl_common
x86_pkg_temp_thermal
intel_powerclamp
nls_ascii
nls_cp437
btusb
kvm_intel
btrtl
btbcm
vfat
btintel
btmtk
fat
kvm
bluetooth
irqbypass
crc32_pclmul
crypto_simd
xts
ecb
jitterentropy_rng
dm_crypt
ghash_clmulni_intel
cryptd
snd_hda_codec_hdmi
sha512_ssse3
sha512_generic
isofs
sha256_ssse3
rtsx_usb_sdmmc
sha1_ssse3
snd_hda_codec_realtek
wl(POE)
snd_hda_codec_generic
mmc_core
ledtrig_audio
ctr
rtsx_usb_ms
memstick
snd_hda_intel
snd_intel_dspcfg
snd_intel_sdw_acpi
drbg
snd_hda_codec
iTCO_wdt
intel_pmc_bxt
uvcvideo
iTCO_vendor_support
mei_hdcp
at24
watchdog
videobuf2_vmalloc
snd_hda_core
videobuf2_memops
rtsx_usb
rapl
videobuf2_v4l2
ansi_cprng
videobuf2_common
snd_hwdep
intel_cstate
ecdh_generic
intel_uncore
wmi_bmof
ecc
snd_pcm
videodev
sr_mod
cdrom
r8169
cfg80211
realtek
i2c_i801
snd_timer
mc
pcspkr
i2c_smbus
mei_me
ideapad_laptop
mdio_devres
platform_profile
snd
libphy
mei
lpc_ich
soundcore
sparse_keymap
rfkill
ac
battery
button
joydev
sg
coretemp
parport_pc
ppdev
lp
parport
loop
fuse
efi_pstore
dm_mod
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
efivarfs
raid10
raid456
libcrc32c
crc32c_generic
async_raid6_recov
async_memcpy
async_pq
async_xor
xor
async_tx
raid6_pq
raid1
raid0
multipath
linear
md_mod
sd_mod
t10_pi
crc64_rocksoft
crc64
crc_t10dif
crct10dif_generic
hid_generic
usbhid
hid
i915
i2c_algo_bit
drm_buddy
drm_display_helper
ahci
libahci
drm_kms_helper
libata
cec
rc_core
ehci_pci
ehci_hcd
ttm
scsi_mod
usbcore
crct10dif_pclmul
crct10dif_common
drm
psmouse
evdev
crc32c_intel
scsi_common
serio_raw
usb_common
video
wmi

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor 
Family DRAM Controller [8086:0104] (rev 0

Bug#1025420: exim4: ${run}expansion fail Bug stiill open [TT#2568022]

2023-10-26 Thread SerNet Support Kevin Ivory


oh, well, thanks for analysing that.
Sorry, I didn't notice the change myself.

Am 25.10.23 um 16:24 schrieb Andreas Metzler:

On 2023-10-23 SerNet Support Kevin Ivory  wrote:
[...]

That binary does not fix the problem of quote with space included:



# /usr/sbin/exim4 -be '${run{/usr/bin/echo ${quote:hello world}}}'
Failed: Expansion of "${quote:hello" from command "/usr/bin/echo ${quote:hello 
world}" in ${run} expansion failed: missing } at end of string

[...]

${run expansion changed in 4.96:
"If the option preexpand is not used, the command string is split into
individual arguments by spaces and then each argument is expanded."

i.e.
 /usr/bin/echo ${quote:hello world}
is split into
 /usr/bin/echo
 ${quote:hello
 world}
and the second string yields an expansion error.
Use
/usr/sbin/exim4 -be '${run,preexpand{/usr/bin/echo ${quote:hello world}}}'
to get the old behavior.


Beste Grüße
Kevin Ivory (SerNet Support)
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-37-0, mailto:kont...@sernet.de
Gesch.F.: Dr. Johannes Loxen und Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de
Datenschutz: https://www.sernet.de/datenschutz

Besuchen Sie den SerNet Stammtisch
Nächster Termin, Infos & Anmeldung
unter https://sernet.de/stammtisch

Bug#1025420: exim4: ${run}expansion fail Bug stiill open [TT#2568022]

2023-10-23 Thread SerNet Support Kevin Ivory


Hi Andreas,

I installed the package
https://people.debian.org/~ametzler/tmp/exim4-daemon-heavy_4.96-15+deb12u2+almostu3_amd64.deb

The binary /usr/sbin/exim4 inside is from Sept 3rd:
-rwsr-xr-x 1 root root 1575384 2023-09-03 13:34 /usr/sbin/exim4

That binary does not fix the problem of quote with space included:

# /usr/sbin/exim4 -be '${run{/usr/bin/echo ${quote:hello world}}}'
Failed: Expansion of "${quote:hello" from command "/usr/bin/echo ${quote:hello 
world}" in ${run} expansion failed: missing } at end of string

Am 23.10.23 um 18:06 schrieb Andreas Metzler:

I have uploaded pre built binaries to
https://people.debian.org/~ametzler/tmp/


Best regards
Kevin Ivory (SerNet Support)
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-37-0, mailto:kont...@sernet.de
Gesch.F.: Dr. Johannes Loxen and Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de
Datenschutz: https://www.sernet.de/datenschutz

Bug#1025420: exim4: ${run}expansion fail Bug stiill open [TT#2568022]

2023-10-23 Thread SerNet Support Kevin Ivory


Hello Andreas,

thanks for the info.
I am not familiar with the Repository format at
https://salsa.debian.org/exim-team/exim4/-/tree/12_bookworm?ref_type=heads

Is there a binary or a package that I can test or do
I have to patch and compile?

Am 23.10.23 um 14:29 schrieb Andreas Metzler:

On 2023-10-18 SerNet Support Kevin Ivory  wrote:

Hello Andreas,



I just realized Debian Bug #1025420 is closed even though
we are still running into it in exim 4.96-15+deb12u2



Please try:



# /usr/sbin/exim4 -be '${run{/usr/bin/echo ${quote:hello world}}}'
Failed: Expansion of "${quote:hello" from command "/usr/bin/echo ${quote:hello 
world}" in ${run} expansion failed: missing } at end of string



The bug is only fixed for exactly the version in the bug
report, variables with no space included. We need to use
${quote:$h_subject:} where the subject often includes
spaces.


Hello,

Yes, I now that. I had a stable update pending for the latest point
release but I pulled it because there needed to be DSA for CVE-2023-42114,
CVE-2023-42115, CVE-2023-42116 at basically the same time.

I would appreciate if you could check whether
https://salsa.debian.org/exim-team/exim4/-/tree/12_bookworm?ref_type=heads
works for you.

cu Andreas


Best regards
Kevin Ivory (SerNet Support)
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-37-0, mailto:kont...@sernet.de
Gesch.F.: Dr. Johannes Loxen and Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de
Datenschutz: https://www.sernet.de/datenschutz

Bug#953591: bash: colors should be enabled by default (force_color_prompt)

2023-10-08 Thread Kevin Otte

I wrote a patch to address #1026379 that I feel would be appropriate 
here too. As I noted there, using tput for detection basically means 
having ncurses-bin as a Recommends, so we may want a better way of doing 
this detection.
--- /etc/skel/.bashrc	2020-02-25 06:44:22.0 -0500
+++ .bashrc	2023-09-08 09:51:44.086826241 -0400
@@ -35,33 +35,23 @@
 debian_chroot=$(cat /etc/debian_chroot)
 fi
 
-# set a fancy prompt (non-color, unless we know we "want" color)
-case "$TERM" in
-xterm-color|*-256color) color_prompt=yes;;
-esac
-
-# uncomment for a colored prompt, if the terminal has the capability; turned
-# off by default to not distract the user: the focus in a terminal window
-# should be on the output of commands, not on the prompt
-#force_color_prompt=yes
-
-if [ -n "$force_color_prompt" ]; then
-if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
-	# We have color support; assume it's compliant with Ecma-48
-	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
-	# a case would tend to support setf rather than setaf.)
-	color_prompt=yes
-else
-	color_prompt=
-fi
+# Determine if terminal is color capable
+if [ -x /usr/bin/tput ] && [ $(tput colors) -ge 8 ];
+then
+color_prompt=yes
+else
+color_prompt=
 fi
 
+# Uncomment to force plain prompt
+#color_prompt=no
+
 if [ "$color_prompt" = yes ]; then
 PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
 else
 PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
 fi
-unset color_prompt force_color_prompt
+unset color_prompt
 
 # If this is an xterm set the title to user@host:dir
 case "$TERM" in

Bug#1052116: initscripts: /etc/rcX.d symlinks not created

2023-09-19 Thread Kevin Ruml

   >On Tuesday, September 19, 2023 at 02:17:55 AM CDT, Mark Hindley 
 wrote:  >
 >
 >On Tue, Sep 19, 2023 at 07:29:45AM +0100, Mark Hindley wrote:>> > Setting up 
 >initscripts (3.08-1) ...>> > Setting up udev (254.3-1) ...>> >> The udev 
 >postinst, which removes the update-rc.d symlinks is  run after the>> 
 >initscripts postinst which has created them.>>Just so I can be sure that 
 >there isn't a bug in the initscripts postinst, having>upgraded to initscripts 
 >3.08-1, can you run> >dpkg-reconfigure initscripts>>and verify that the 
 >symlinks are recreated?>>Thanks>>>Mark
I know you sent subsequent messages about a fix, but since you asked me to test 
this and it was easy enough for me to do it, I did.  Downgrading then upgrading 
again left the system without the symlinks.  Running "dpkg-reconfigure 
initscripts" did generate the symlinks.

Thanks,Kevin

Bug#1052116: initscripts: /etc/rcX.d symlinks not created

2023-09-18 Thread Kevin Ruml

Package: initscripts
Version: 3.08-1
Followup-For: Bug #1052116
X-Debbugs-Cc: k_r...@yahoo.com

Dear Maintainer,

   * What led up to the situation?
   Updating udev and sysv-rc package groups
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Updating caused subsequent reboots to fail to make it to GUI login
   * What was the outcome of this action?
   System was not properly booted into the OS
   * What outcome did you expect instead?
   Reboot and taken to GUI login screen

I initially updated udev to 254.3-1 and didn't get a running system.  I 
downgraded udev back to 254.1-3 and the system functioned properly.  That was 
on Saturday so would have been before #1042082 was fixed.  Today I updated both 
udev (to 254.3-1) and sysv-rc (to 3.08-1) package groups and was again left 
with a broken system.  Downgrading both sets of packages returned the system to 
a functioning state.  I found that by looking at differences between updating 
and downgrading that after updating, the /etc/rcX.d symlinks for udev were not 
being created.  It seems the update-rc.d command isn't being run with the init 
script now being in initscripts instead of udev package.


Performing actions...
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 398542 files and directories currently installed.)
Preparing to unpack .../sysvinit-utils_3.08-1_amd64.deb ...
Unpacking sysvinit-utils (3.08-1) over (3.07-1) ...
Setting up sysvinit-utils (3.08-1) ...
(Reading database ... 398542 files and directories currently installed.)
Preparing to unpack .../0-udev_254.3-1_amd64.deb ...
Unpacking udev (254.3-1) over (254.1-3) ...
Preparing to unpack .../1-libudev1_254.3-1_amd64.deb ...
De-configuring libudev1:i386 (254.1-3), to allow configuration of 
libudev1:amd64 (254.3-1) ...
Unpacking libudev1:amd64 (254.3-1) over (254.1-3) ...
Preparing to unpack .../2-libudev1_254.3-1_i386.deb ...
Unpacking libudev1:i386 (254.3-1) over (254.1-3) ...
Preparing to unpack .../3-sysv-rc_3.08-1_all.deb ...
Unpacking sysv-rc (3.08-1) over (3.07-1) ...
Preparing to unpack .../4-initscripts_3.08-1_all.deb ...
Unpacking initscripts (3.08-1) over (3.07-1) ...
Preparing to unpack .../5-sysvinit-core_3.08-1_amd64.deb ...
Unpacking sysvinit-core (3.08-1) over (3.07-1) ...
Setting up libudev1:amd64 (254.3-1) ...
Setting up libudev1:i386 (254.3-1) ...
Setting up sysv-rc (3.08-1) ...
Setting up initscripts (3.08-1) ...
Setting up udev (254.3-1) ...
Setting up sysvinit-core (3.08-1) ...
sysvinit: restarting... done.
Processing triggers for libc-bin (2.37-10) ...
Processing triggers for man-db (2.11.2-3) ...
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.5.0-1-amd64

# updatedb
# locate udev | less

/etc/udev
/etc/init.d/udev
/etc/systemd/system/udev.service
/etc/udev/hwdb.bin
/etc/udev/hwdb.d
/etc/udev/iocost.conf
/etc/udev/rules.d
/etc/udev/udev.conf
/etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/81-canonij_prn.rules


# cd /var/cache/apt/archives/
# dpkg -i libudev1_254.1-3_amd64.deb libudev1_254.1-3_i386.deb 
udev_254.1-3_amd64.deb sysvinit-core_3.07-1_amd64.deb 
sysvinit-utils_3.07-1_amd64.deb sysv-rc_3.07-1_all.deb 
initscripts_3.07-1_all.deb 
dpkg: warning: downgrading libudev1:amd64 from 254.3-1 to 254.1-3
(Reading database ... 398543 files and directories currently installed.)
Preparing to unpack libudev1_254.1-3_amd64.deb ...
De-configuring libudev1:i386 (254.3-1), to allow configuration of 
libudev1:amd64 (254.1-3) ...
Unpacking libudev1:amd64 (254.1-3) over (254.3-1) ...
dpkg: warning: downgrading libudev1:i386 from 254.3-1 to 254.1-3
Preparing to unpack libudev1_254.1-3_i386.deb ...
Unpacking libudev1:i386 (254.1-3) over (254.3-1) ...
dpkg: warning: downgrading udev from 254.3-1 to 254.1-3
Preparing to unpack udev_254.1-3_amd64.deb ...
Unpacking udev (254.1-3) over (254.3-1) ...
Replaced by files in installed package initscripts (3.08-1) ...
dpkg: warning: downgrading sysvinit-core from 3.08-1 to 3.07-1
Preparing to unpack sysvinit-core_3.07-1_amd64.deb ...
Unpacking sysvinit-core (3.07-1) over (3.08-1) ...
dpkg: warning: downgrading sysvinit-utils from 3.08-1 to 3.07-1
Preparing to unpack sysvinit-utils_3.07-1_amd64.deb ...
Unpacking sysvinit-utils (3.07-1) over (3.08-1) ...
dpkg: warning: downgrading sysv-rc from 3.08-1 to 3.07-1
Preparing to unpack sysv-rc_3.07-1_all.deb ...
Unpacking sysv-rc (3.07-1) over (3.08-1) ...
dpkg: warning: downgrading initscripts from 3.08-1 to 3.07-1
Preparing to unpack initscripts_3.07-1_all.deb ...
Unpacking initscripts (3.07-1) over (3.08-1) ...
Setting up libudev1:amd64 (254.1-3) ...
Setting up libudev1:i386 (254.1-3) ...
Setting up udev (254.1-3) ...
Setting up sysvinit-utils (3.07-1) ...
Setting up sysv-rc (3.07-1) ...
Setting up initscripts (3.07-1) ...
Setting up sysvinit-core (3.07-1) ...
sysvinit: restarting... done.
Processing triggers for libc-bin (2.37-10) ...
Processing triggers for

Bug#1052120: mirror submission for mirror.timkevin.us

2023-09-17 Thread Tim Kevin

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

Submission-Type: new
Site: mirror.timkevin.us
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Maintainer: Tim Kevin 
Country: US United States
Location: San Jose, CA
Comment: https://mirror.timkevin.us/debian
 http://mirror.timkevin.us/debian




Trace Url: http://mirror.timkevin.us/debian/project/trace/
Trace Url: http://mirror.timkevin.us/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.timkevin.us/debian/project/trace/mirror.timkevin.us

Bug#1051819: fluidsynth: Consider building with pipewire support

2023-09-12 Thread Kevin Otte

Package: fluidsynth
Version: 2.3.1-2
Severity: wishlist

Dear Maintainer,

Please consider building fluidsynth with pipewire support.
While it is working adequately via the pulseaudio compatibility layer,
it would be nice to utilize the native support added in 2.3.0 as it is
the default sound server in Debian 12.

It looks like all that is needed is a Build-Depends on libpipewire-0.3-dev
to have cmake pick up on it.

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

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

Versions of packages fluidsynth depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u1
ii  libfluidsynth3   2.3.1-2
ii  libglib2.0-0 2.74.6-2
ii  libsdl2-2.0-02.26.5+dfsg-1
ii  libsystemd0  252.12-1~deb12u1

Versions of packages fluidsynth recommends:
ii  qsynth  0.9.9-1

fluidsynth suggests no packages.

-- no debconf information

Bug#1026379: skel.bashrc: detect any color terminal

2023-09-08 Thread Kevin Otte

The problem with checking $TERM is you end up having to add every new 
terminal type that is capable. In addition to foot, I know of kitty, 
alacritty, wezterm, and there are likely more.


The comments around this section of skel.bashrc are unclear, talking 
about setting a "fancy prompt (non-color)" then setting color_prompt=yes.


Given this, I propose to use a color prompt on any terminal that is 
capable of it, with the uncomment override back to a plain prompt. Using 
tput for detection basically means having ncurses-bin as a Recommends, 
so we may want a better way of doing this detection.


Patch attached.--- /etc/skel/.bashrc	2020-02-25 06:44:22.0 -0500
+++ .bashrc	2023-09-08 09:51:44.086826241 -0400
@@ -35,33 +35,23 @@
 debian_chroot=$(cat /etc/debian_chroot)
 fi
 
-# set a fancy prompt (non-color, unless we know we "want" color)
-case "$TERM" in
-xterm-color|*-256color) color_prompt=yes;;
-esac
-
-# uncomment for a colored prompt, if the terminal has the capability; turned
-# off by default to not distract the user: the focus in a terminal window
-# should be on the output of commands, not on the prompt
-#force_color_prompt=yes
-
-if [ -n "$force_color_prompt" ]; then
-if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
-	# We have color support; assume it's compliant with Ecma-48
-	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
-	# a case would tend to support setf rather than setaf.)
-	color_prompt=yes
-else
-	color_prompt=
-fi
+# Determine if terminal is color capable
+if [ -x /usr/bin/tput ] && [ $(tput colors) -ge 8 ];
+then
+color_prompt=yes
+else
+color_prompt=
 fi
 
+# Uncomment to force plain prompt
+#color_prompt=no
+
 if [ "$color_prompt" = yes ]; then
 PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
 else
 PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
 fi
-unset color_prompt force_color_prompt
+unset color_prompt
 
 # If this is an xterm set the title to user@host:dir
 case "$TERM" in

Bug#1043410: efivar: install fails

2023-08-10 Thread kevin

Package: efivar
Severity: normal
X-Debbugs-Cc: kcr...@hotmail.com

Dear Maintainer,

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

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

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

grub-installer:error: Error creating /target/sys/firmware/efi/cfivars
init: starting pid 449, tty '/dev/tty2/: '-/bin/sh'


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

Kernel: Linux 6.1.0-10-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages efivar depends on:
ii  libc62.36-9+deb12u1
ii  libefiboot1  37-6
ii  libefivar1   37-6

efivar recommends no packages.

efivar suggests no packages.

Bug#1023306: baresip v3.3.0 is current

2023-07-30 Thread Kevin Otte


https://github.com/baresip/baresip/releases/tag/v3.3.0
Released 2023-06-05

Packaging the new version would also solve #967266 and likely others

Bug#1038599: graphite-web: RuntimeError logged in stock configuration

2023-06-18 Thread Kevin Otte

Package: graphite-web
Version: 1.1.8-2
Severity: important
Tags: patch

The error
  RuntimeError("populate() isn't reentrant")
is logged in the Apache log file when attempting to use the stock
/usr/share/graphite-web/graphite.wsgi file.

https://wiki.rockstable.it/Icinga2 in the section "Graphite troubleshooting"
contains a workaround to fix the problem, namely changing

os.environ.setdefault('GRAPHITE_SETTINGS_MODULE', 'graphite.local_settings')

to

os.environ.setdefault('GRAPHITE_SETTINGS_MODULE', 'local_settings')

After making this change on my system the package works.


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 graphite-web depends on:
ii  adduser 3.134
ii  python3 3.11.2-1+b1
ii  python3-cairo   1.20.1-5+b1
ii  python3-cairocffi   1.4.0-1
ii  python3-django  3:3.2.19-1
ii  python3-django-tagging  1:0.5.0-4
ii  python3-pyparsing   3.0.9-1
ii  python3-simplejson  3.18.3-1
ii  python3-six 1.16.0-4
ii  python3-tz  2022.7.1-4
ii  python3-urllib3 1.26.12-1
ii  python3-whisper 1.1.4-2.2

graphite-web recommends no packages.

Versions of packages graphite-web suggests:
ii  graphite-carbon  1.1.7-1.1
ii  libapache2-mod-wsgi-py3  4.9.4-1+b2
pn  python3-ldap 
pn  python3-memcache 
pn  python3-mysqldb  

-- Configuration Files:
/etc/graphite/local_settings.py changed [not included]

-- no debconf information

Bug#1037279: Angelfish built-in ad blocker not built due to missing Rust Build-Depends (Corrosion etc.)

2023-06-09 Thread Kevin Kofler


Package: angelfish
Version: 22.11-1+b2

Angelfish has a built-in ad blocker based on the Rust adblock crate from 
the Brave developers. This feature is missing from the Debian package 
because Corrosion and other build-time dependencies are not Build-Depended. 
(They may need to be added to Debian first.)


Just check your build logs, e.g.:
https://buildd.debian.org/status/fetch.php?pkg=angelfish=arm64=22.11-1%2Bb2=1679750090=0

Actual Results:  

-- The following RECOMMENDED packages have not been found:

 * Corrosion, CMake scripts to seamlessly build and link to targets using cargo, 

   Required to build the builtin adblocker


Expected Results:  
The ad blocker is built.


In addition to Corrosion, you will need cargo (though Corrosion should 
already be requiring it), rust-adblock, rust-cxx-build, and rust-cxx. You 
may also need to hack things up so that it can build offline.


See also https://bugzilla.redhat.com/show_bug.cgi?id=2213926 for the exact 
same issue in the Fedora package.

Bug#1036049: cryptsetup-initramfs: support for compressed modules

2023-05-14 Thread Kevin Locke

Package: cryptsetup-initramfs
Version: 2:2.6.1-4~deb12u1
Severity: wishlist
Tags: patch

Dear Maintainer,

When Linux is configured with CONFIG_MODULE_COMPRESS_{GZIP,XZ,ZSTD},
modules are compressed and stored with a .ko.{gz,xz,zst} extension.
This causes the cryptroot hook script not to add the modules to the
initramfs, which can cause boot failures.  Although compression is not
currently enabled in any Debian kernel configuration that I'm aware
of, it would be nice if cryptsetup-initramfs could support this
configuration for downstream distributions and users with custom
kernels.

I've attached a patch to add support, as done by initramfs-tools:
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/8c806b446fab5f5807651a5c7869141837592ecd
Note that the situation has changed a bit since that commit and kmod
now supports zstd (Bug 990092) in addition to xz (Bug 772628).

Thanks for considering,
Kevin

-- Package-specific info:

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

Kernel: Linux 6.4.0-rc1+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptsetup-initramfs depends on:
ii  busybox 1:1.35.0-4+b3
ii  cryptsetup  2:2.6.1-4~deb12u1
ii  debconf [debconf-2.0]   1.5.82
ii  initramfs-tools [linux-initramfs-tool]  0.142

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.220
ii  kbd2.5.1-1+b1

cryptsetup-initramfs suggests no packages.

-- debconf information excluded
>From e52a22ea1ccc9bc66f80d1e3d2eb9ed5e92e4022 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Kevin Locke 
Date: Sat, 13 May 2023 22:37:01 -0600
Subject: [PATCH] initramfs: cryptroot support compressed modules

When Linux is configured with CONFIG_MODULE_COMPRESS_{GZIP,XZ,ZSTD},
modules are compressed and stored with a .ko.{gz,xz,zst} extension. This
causes the cryptroot hook script not to add the modules to the
initramfs, which can cause boot failures.

Match module files with additional extensions, as in
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/8c806b446fab5f5807651a5c7869141837592ecd
for initramfs-tools.  Note that kmod now supports zstd (Bug 990092) in
addition to xz (Bug 772628).

Signed-off-by: Kevin Locke 
---
 debian/initramfs/hooks/cryptroot | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/initramfs/hooks/cryptroot b/debian/initramfs/hooks/cryptroot
index 35577865..7b438593 100644
--- a/debian/initramfs/hooks/cryptroot
+++ b/debian/initramfs/hooks/cryptroot
@@ -266,8 +266,8 @@ populate_CRYPTO_MODULES() {
 add_modules() {
 local glob="$1" found=n
 shift
-for mod in $(find -H "$@" -name "$glob.ko" -type f -printf '%f\n'); do
-manual_add_modules "${mod%.ko}"
+for mod in $(find -H "$@" -name "$glob.ko*" -type f -printf '%f\n'); do
+manual_add_modules "${mod%.ko*}"
 found=y
 done
 [ "$found" = y ] && return 0 || return 1
-- 
2.39.2

Bug#1001440: /usr/bin/foo2zjs: fails to load firmware into printer

2023-05-11 Thread Kevin Goodsell

I'm not sure if it's the same issue, but I'm also seeing firmware failing
to load on my LaserJet 1020 using foo2zjs. My guess is that there's a
conflict between the firmware loading script and udev-configure-printer
trying to access the printer at the same time.

Here is a snippet from journalctl when the printer was turned on:

  May 11 18:02:34 cyclops kernel: usb 2-14: new high-speed USB device
number 14 using xhci_hcd
  May 11 18:02:34 cyclops kernel: usb 2-14: New USB device found,
idVendor=03f0, idProduct=2b17, bcdDevice= 1.00
  May 11 18:02:34 cyclops kernel: usb 2-14: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
  May 11 18:02:34 cyclops kernel: usb 2-14: Product: HP LaserJet 1020
  May 11 18:02:34 cyclops kernel: usb 2-14: Manufacturer: Hewlett-Packard
  May 11 18:02:34 cyclops kernel: usb 2-14: SerialNumber: JL1K941
  May 11 18:02:34 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 14 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 18:02:40 cyclops kernel: usblp1: removed
  May 11 18:02:40 cyclops /lib/udev/hplj1020[162068]: foo2zjs: loading HP
LaserJet 1020 firmware /lib/firmware/hp/sihp1020.dl to CUPS USB device ...
  May 11 18:02:40 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 14 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 18:02:40 cyclops kernel: usblp1: removed
  May 11 18:02:40 cyclops systemd[1]: Started Configure Plugged-In Printer.
  May 11 18:02:40 cyclops udev-configure-printer[162071]: add usb-002-014
  May 11 18:02:40 cyclops udev-configure-printer[162071]: device devpath is
/devices/pci:00/:00:14.0/usb2/2-14
  May 11 18:02:40 cyclops udev-configure-printer[162071]: Device
vendor/product is 03F0:2B17
  May 11 18:02:41 cyclops udev-configure-printer[162071]: failed to claim
interface
  May 11 18:02:41 cyclops systemd[1]: configure-printer@usb-002-014.service:
Main process exited, code=exited, status=1/FAILURE
  May 11 18:02:41 cyclops systemd[1]: configure-printer@usb-002-014.service:
Failed with result 'exit-code'.

And here's a snippet of the same scenario with a work-around in place:

  May 11 17:58:15 cyclops kernel: usb 2-14: new high-speed USB device
number 13 using xhci_hcd
  May 11 17:58:15 cyclops kernel: usb 2-14: New USB device found,
idVendor=03f0, idProduct=2b17, bcdDevice= 1.00
  May 11 17:58:15 cyclops kernel: usb 2-14: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
  May 11 17:58:15 cyclops kernel: usb 2-14: Product: HP LaserJet 1020
  May 11 17:58:15 cyclops kernel: usb 2-14: Manufacturer: Hewlett-Packard
  May 11 17:58:15 cyclops kernel: usb 2-14: SerialNumber: JL1K941
  May 11 17:58:15 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:21 cyclops kernel: usblp1: removed
  May 11 17:58:21 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:21 cyclops /lib/udev/hplj1020[161939]: foo2zjs: loading HP
LaserJet 1020 firmware /lib/firmware/hp/sihp1020.dl to CUPS USB device ...
  May 11 17:58:21 cyclops kernel: usblp1: removed
  May 11 17:58:31 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:31 cyclops /lib/udev/hplj1020[161944]: foo2zjs:
usb://HP/LaserJet%201020?serial=JL1K941... download successful.
  May 11 17:58:31 cyclops systemd[1]: Started Configure Plugged-In Printer.
  May 11 17:58:31 cyclops udev-configure-printer[161953]: add usb-002-013
  May 11 17:58:31 cyclops udev-configure-printer[161953]: device devpath is
/devices/pci:00/:00:14.0/usb2/2-14
  May 11 17:58:31 cyclops udev-configure-printer[161953]:
MFG:Hewlett-Packard MDL:HP LaserJet 1020 SERN:- serial:JL1K941
  May 11 17:58:36 cyclops kernel: usblp1: removed
  May 11 17:58:36 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:37 cyclops kernel: usblp1: removed
  May 11 17:58:37 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional
printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17
  May 11 17:58:38 cyclops udev-configure-printer[161953]: URI contains USB
serial number
  May 11 17:58:38 cyclops udev-configure-printer[161953]: URI match:
usb://HP/LaserJet%201020?serial=JL1K941
  May 11 17:58:38 cyclops udev-configure-printer[161953]: URI of detected
printer: usb://HP/LaserJet%201020?serial=JL1K941, normalized: laserjet 1020
serial jl1k941
  May 11 17:58:38 cyclops udev-configure-printer[161953]: URI of print
queue: usb://HP/LaserJet%201020?serial=JL1K941, normalized: laserjet 1020
serial jl1k941
  May 11 17:58:38 cyclops udev-configure-printer[161953]: Queue
ipp://localhost/printers/HP_LaserJet_1020 has matching device URI
  May 11 17:58:38 cyclops udev-configure-printer[161953]: Re-enabled
printer ipp://localhost/printers/HP_LaserJet_1020
  May 11 17:58:38 cyclops systemd[1]:

Bug#1035836: remmina-plugin-vnc: Segmentation fault when using UNIX socket

2023-05-09 Thread Kevin Otte

Package: remmina-plugin-vnc
Version: 1.4.29+dfsg-1
Severity: normal

When specifying a UNIX socket as a remote VNC server (eg: 
unix:///tmp/wayvnc-ssh.sock)
the program will segfault when trying to connect. This issue has been reported
upstream (https://gitlab.com/Remmina/Remmina/-/issues/2856) and a fix is 
available.

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

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

Versions of packages remmina-plugin-vnc depends on:
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libvncclient10.9.14+dfsg-1
ii  remmina  1.4.29+dfsg-1

remmina-plugin-vnc recommends no packages.

remmina-plugin-vnc suggests no packages.

-- no debconf information

Bug#1035094: udev: /dev/serial/by-id/ symlinks not created anymore for USB devices

2023-05-08 Thread Kevin Hilman

I think it's the same root cause, but I also noticed that the
ID_SERIAL_SHORT attribute has disappeared from `udevadm info` for USB
serial adapters.   ID_USB_SERIAL_SHORT is present, but ID_SERIAL_SHORT
is gone, which has broken some udev rules which use ID_SERIAL_SHORT
for matching.

Bug#993985: wireguard should not depend on wireguard-dkms or wireguard-modules in Debian 11

2023-05-02 Thread Kevin P. Fleming

Package: wireguard-tools
Followup-For: Bug #993985

Dear Maintainer,

In Debian 11 (currently 'testing'), there are no packages which provide
'wireguard-dkms', and 'wireguard-modules' is provided by the standard 'linux-
image-' packages. As a result there is no apparent value in having
'wireguard-tools' recommend either of those.

In fact on a system which intentionally does *not* have the 'linux-
image-' package installed, installing 'wireguard-tools' will pull it in
unless the user tells it not to, and may pull it in in the future when the
'wireguard-tools' package is upgraded and 'apt upgrade' is run... unless the
user once again remember to tell 'apt' to not install recommended packages.


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

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

Versions of packages wireguard-tools depends on:
ii  libc6  2.36-9

Versions of packages wireguard-tools recommends:
ii  iptables   1.8.9-2
ii  linux-image-amd64 [wireguard-modules]  6.1.20-2
ii  nftables   1.0.6-2

Versions of packages wireguard-tools suggests:
pn  openresolv | resolvconf  

-- no debconf information

Bug#1031152: system-config-printer: unlock button in system-config-printer provides no elevated permissions dialog

2023-04-20 Thread Kevin Otte

On my Debian 11 XFCE machine this works correctly. Make sure "PolicyKit 
Authentication Agent" is checked under "Session and Startup" -> 
"Application Autostart".


In Debian 12 under Sway the GNOME Authentication Agent segfaults, but I 
will take this up under separate cover. I was able to work around the 
issue for the moment by using lxpolkit for the authentication agent instead.

Bug#1031152: system-config-printer: unlock button in system-config-printer provides no elevated permissions dialog

2023-04-14 Thread Kevin Otte

Package: system-config-printer
Version: 1.5.18-1
Followup-For: Bug #1031152

Workaround suggested by original reporter (sudo) ineffective on sway due to 
Wayland security model.

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 system-config-printer depends on:
ii  gir1.2-gdkpixbuf-2.0  2.42.10+dfsg-1+b1
ii  gir1.2-glib-2.0   1.74.0-3
ii  gir1.2-gtk-3.03.24.37-2
ii  gir1.2-handy-11.8.1-1
ii  gir1.2-notify-0.7 0.8.1-1
ii  gir1.2-packagekitglib-1.0 1.2.6-3
ii  gir1.2-pango-1.0  1.50.12+ds-1
ii  gir1.2-polkit-1.0 122-3
ii  python3   3.11.2-1+b1
ii  python3-cups  2.0.1-5+b4
ii  python3-cupshelpers   1.5.18-1
ii  python3-dbus  1.3.2-4+b1
ii  python3-gi3.42.2-3+b1
ii  system-config-printer-common  1.5.18-1

Versions of packages system-config-printer recommends:
ii  avahi-utils 0.8-9
ii  system-config-printer-udev  1.5.18-1

Versions of packages system-config-printer suggests:
pn  gnome-software  

-- no debconf information

Bug#1030930: podman: DNS resolution fails in 'podman build' but works in 'podman run'

2023-04-11 Thread Kevin P. Fleming

On Mon, Apr 10, 2023, at 17:52, Reinhard Tartler wrote:
> Control: tag -1 + unreproducible moreinfo
> 
> Hi Kevin,
> 
> great to hear from you in this space!
> 
> On Thu, Feb 9, 2023 at 8:36 AM Kevin P. Fleming  wrote:
>> Package: podman
>> Version: 4.3.1+ds1-5+b1
>> Severity: important
>> 
>> Dear Maintainer,
>> 
>> I am seeing DNS resolution fail when using 'podman build' but succeed when
>> using 'podman run', with a Dockerfile which contains the same commands I run
>> manually in the 'podman run'-launched shell.
>> 
>> Dockerfile
>> --
>> FROM alpine:3.10
>> RUN cat /etc/resolv.conf
>> RUN apk add tar
>  
> Unfortunately, I can't reproduce. Please help me to reproduce this issue. 
> Also, maybe upstream has an idea, can you please report this issue at 
> https://github.com/containers/podman/issues/new/choose. In any case, here is 
> the output that I get:
> 
> siretart@x1:/tmp/dnstest$ cat >> Containerfile
> FROM alpine:3.10
> RUN cat /etc/resolv.conf
> RUN apk add tar
> siretart@x1:/tmp/dnstest$ cat Containerfile
> FROM alpine:3.10
> RUN cat /etc/resolv.conf
> RUN apk add tar
> siretart@x1:/tmp/dnstest$ podman build .
> STEP 1/3: FROM alpine:3.10
> Resolved "alpine" as an alias 
> (/etc/containers/registries.conf.d/shortnames.conf)
> Trying to pull docker.io/library/alpine:3.10...
> Getting image source signatures
> Copying blob 396c31837116 done  
> Copying config e7b300aee9 done  
> Writing manifest to image destination
> Storing signatures
> STEP 2/3: RUN cat /etc/resolv.conf
> search int.tauware.de
> nameserver 10.0.2.3
> nameserver 192.168.88.3
> --> 2ce59772eaf
> STEP 3/3: RUN apk add tar
> fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
> fetch 
> http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
> (1/1) Installing tar (1.32-r1)
> Executing busybox-1.30.1-r5.trigger
> OK: 6 MiB in 15 packages
> COMMIT
> --> 7c1bfd9e030
> 7c1bfd9e030f07b05cc9427a97c0bc5ff73bca5436bce389ad81da1a64f64a11

Confirmed; I can no longer reproduce the problem. Something somewhere in the 
stack got fixed :-)

Bug#1019977: Please add pipewire-pulse as alternative dependency

2023-04-03 Thread Kevin Otte

Package: python3-pulsectl
Followup-For: Bug #1019977

Rather than adding another dep on pipewire-pulse, it probably makes sense to 
change the dependency to the client library libpulse0, which is what this 
module is using for 
its bindings anyway.


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

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

Versions of packages python3-pulsectl depends on:
pn  pulseaudio  
ii  python3 3.11.2-1

python3-pulsectl recommends no packages.

python3-pulsectl suggests no packages.

Bug#1033624: obs-studio: Pipewire capture source not listed

2023-03-28 Thread Kevin Otte

I have xdg-desktop-portal-{wlr,gtk} installed, which is appropriate for 
a wlroots compositor.


On 3/28/23 19:32, Richard B. Kreckel wrote:

On 3/28/23 22:12, Kevin Otte wrote:
When I attempt to add a source to the current scene, I do not see the 
"Screen Capture (Pipewire)" option listed as demonstrated in the 
screenshot at 
https://www.linuxuprising.com/2021/06/obs-studio-27-released-with-wayland-and.html


As such, I am unable to capture the screen under Wayland 
(specifically, sway).


Do you have xdg-desktop-portal-gnome installed? (See bug #1031645.)

   -richy.

Bug#1033624: obs-studio: Pipewire capture source not listed

2023-03-28 Thread Kevin Otte

Package: obs-studio
Version: 29.0.2+dfsg-1+b1
Severity: important

Dear Maintainer,

The release notes for OBS Studio 27 indicate:
Added support for Wayland on Linux. This includes a new PipeWire capture source 
when using Wayland...

When I attempt to add a source to the current scene, I do not see the "Screen 
Capture (Pipewire)" option listed as demonstrated in the screenshot at 
https://www.linuxuprising.com/2021/06/obs-studio-27-released-with-wayland-and.html

As such, I am unable to capture the screen under Wayland (specifically, sway).

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

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

Versions of packages obs-studio depends on:
ii  libavcodec59   7:5.1.2-3
ii  libavdevice59  7:5.1.2-3
ii  libavformat59  7:5.1.2-3
ii  libavutil577:5.1.2-3
ii  libc6  2.36-8
ii  libcurl3-gnutls7.88.1-7
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-4
ii  libgcc-s1  12.2.0-14
ii  libjansson42.14-2
ii  libluajit2-5.1-2   2.1-20230119-1
ii  libmbedcrypto7 2.28.2-1
ii  libmbedtls14   2.28.2-1
ii  libmbedx509-1  2.28.2-1
ii  libobs029.0.2+dfsg-1+b1
ii  libpci31:3.9.0-4
ii  libpulse0  16.1+dfsg1-2+b1
ii  libpython3.11  3.11.2-6
ii  libqt5core5a   5.15.8+dfsg-3
ii  libqt5gui5 5.15.8+dfsg-3
ii  libqt5network5 5.15.8+dfsg-3
ii  libqt5svg5 5.15.8-2
ii  libqt5widgets5 5.15.8+dfsg-3
ii  libqt5xml5 5.15.8+dfsg-3
ii  librist4   0.2.7+dfsg-1
ii  libspeexdsp1   1.2.1-1
ii  libsrt1.5-openssl  1.5.1-1
ii  libstdc++6 12.2.0-14
ii  libswscale67:5.1.2-3
ii  libudev1   252.6-1
ii  libv4l-0   1.22.1-5+b2
ii  libva-drm2 2.17.0-1
ii  libva2 2.17.0-1
ii  libx11-6   2:1.8.4-2
ii  libx264-1642:0.164.3095+gitbaee400-2+b1
ii  libxcb-composite0  1.15-1
ii  libxcb-randr0  1.15-1
ii  libxcb-shm01.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb-xinerama0   1.15-1
ii  libxcb11.15-1
ii  python33.11.2-1
ii  python3.11 3.11.2-6

Versions of packages obs-studio recommends:
ii  obs-plugins  29.0.2+dfsg-1+b1

Versions of packages obs-studio suggests:
ii  pkexec 122-3
ii  policykit-1122-3
pn  v4l2loopback-dkms  

-- no debconf information

Bug#1033532: aptitude: forgets upgrade action(s) to experimental after becoming root

2023-03-26 Thread Kevin Locke

Package: aptitude
Version: 0.8.13-5
Severity: normal

Dear Maintainer,

When running aptitude 0.8.13-5 as a non-root user, if an installed
package is marked for upgrade to a version from experimental, aptitude
forgets about the action after becoming root.  To reproduce, starting
from a fresh installation of Debian testing, as root:

echo 'deb https://deb.debian.org/debian experimental main' 
>/etc/apt/sources.list.d/debian-experimental.list
apt update
apt install aptitude

Then as a non-root user:

1. Run aptitude.
2. Mark an installed package for upgrade to the version from experimental.
   (e.g. upgrade mawk 1.3.4.20200120-3.1 to 1.3.4.20230203-1~exp1)
3. Press g to start an install run.
4. Become root when prompted.

Observe that after becoming root, the package upgrade is no longer
pending and the following message appears:

> No packages are scheduled to be installed, removed or upgraded.

Instead, the upgrade action should still be pending so it can be
completed as root.

Thanks,
Kevin

Note: This issue appears similar to https://bugs.debian.org/398956
where purge actions are forgotten after becoming root.


-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 12.1.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.8
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20221231
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7fff085eb000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fbf327df000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fbf327a5000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fbf32773000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fbf32e2f000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fbf32681000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fbf32522000)
libboost_iostreams.so.1.74.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7fbf3250a000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fbf3220)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fbf32e28000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fbf31e0)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fbf32121000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fbf324ea000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbf31c1f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fbf324cb000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fbf324b8000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fbf32489000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7fbf32463000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fbf32065000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fbf32436000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fbf31b5)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fbf31a09000)
libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7fbf3205)
/lib64/ld-linux-x86-64.so.2 (0x7fbf32e3a000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fbf32046000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7fbf3203a000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fbf319e1000)

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

Kernel: Linux 6.3.0-rc3-dirty (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0 2.6.0
ii  libboost-iostreams1.74.0  1.74.0+ds1-20
ii  libc6 2.36-8
ii  libcwidget4   0.5.18-6
ii  libgcc-s1 12.2.0-14
ii  libncursesw6  6.4-2
ii  libsigc++-2.0-0v5 2.12.0-1
ii  libsqlite3-0  3.40.1-2
ii  libstdc++612.2.0-14
ii  libtinfo6 6.4-2
ii  libxapian30   1.4.22-1

Versions of packages aptitude recommends:

Bug#1033102: Acknowledgement (ntpsec: ntpq -c sysinfo fails with TypeError: 'int' object is not subscriptable)

2023-03-17 Thread Kevin Woldt

Ok, sorry for opening this bug. It is fixed upstream in version 1.2.1
(see commit
https://github.com/ntpsec/ntpsec/commit/2c771b33af3625f11af8a4f4b995b22d9eb15515)


Thank you,
Kevin Woldt

On Fr, 2023-03-17 at 11:21 +, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1033102:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033102.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due
> course.
> 
> Your message has been sent to the package maintainer(s):
>  Richard Laager 
> 
> If you wish to submit further information on this problem, please
> send it to 1033...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>

Bug#1033102: ntpsec: ntpq -c sysinfo fails with TypeError: 'int' object is not subscriptable

2023-03-17 Thread Kevin Woldt

Package: ntpsec
Version: 1.2.0+dfsg1-4
Severity: normal

To reproduce use a clean debian and install ntpsec. Run the daemon with
the default conf file. Afterwards run the command
$ ntpq -c sysinfo

Return code is 1 and the output is

associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
Traceback (most recent call last):
  File "/usr/bin/ntpq", line 1774, in 
interpreter.onecmd(interpreter.precmd(command))
  File "/usr/lib/python3.9/cmd.py", line 217, in onecmd
return func(arg)
  File "/usr/bin/ntpq", line 1412, in do_sysinfo
self.collect_display(associd=0, variables=sysinfo, decodestatus=True)
  File "/usr/bin/ntpq", line 444, in collect_display
if self.showhostnames[0]:
TypeError: 'int' object is not subscriptable



-- 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 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

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

Versions of packages ntpsec recommends:
ii  systemd  247.3-7+deb11u1

Versions of packages ntpsec suggests:
pn  apparmor   
pn  certbot
pn  ntpsec-doc 
pn  ntpsec-ntpviz  

-- no debconf information

Bug#983600: Is there a workaround for this?

2023-03-08 Thread Kevin P. Fleming

This package is a transitive *unused* dependency of something I'm trying to 
cross-build (using pbuilder), and the fact that I can't install it stops the 
entire process. If there's any way I can force this package to be installed 
despite the broken dependency chain I could likely make progress.

Bug#1031382: Re: Bug#1031382: RFS: libkysdk-base/1.0.1-1 [ITP] -- Kylin SDK basic library

2023-02-26 Thread Kevin Duan

Hi！

Thanks for receiving your letter! Based on your suggestion, I've reworked the 
changelog, control and package.install files in the debian directory, adjusted 
the version numbers, dependencies and installation paths of the binary 
packages, etc

I've re-uploaded the adjusted version to mentors, so thank you again for 
reviewing it!

Thanks,
KevinDuan

在2023年02月24 04时44分，"Boyuan Yang"写道：

Hi,

在 2023-02-22星期三的 17:25 +0800，Kevin Duan写道：
> HI!
> 
> Thanks for the heads up, I have fixed this issue in the latest version and
> have also uploaded the latest to mentors.
> URL: https://mentors.debian.net/package/libkysdk-base/
> Version:1.0.1-3
> 
> Thanks！
> KevinDuan

Several issues that need fix:

* Since your package has not entered Debian officially, please do not
increase the revision number. In your next source package provided, please
still use 1.0.1-1 as version number, not 1.0.1-4. Please only increase
revision numbers after your package is officially accepted into Debian
archive.

* For packages that only contains development headers (*-dev), they do not
include shared library files. As a result, the dependency substitution
${shlibs:Depends} is absolutely not needed. Please drop these lines from
debian/control file. However: please do not delete ${shlibs:Depends}
substitution from packages that actually contains shared library file.

* Compared with your previous 1.0.1-1 upload, the current packaging will
directly place header files under /usr/include/ instead of placing them
under subdirectories. While this behavior does not directly conflict with
packaging policy, I will have to let you know that your packaging is likely
to be problematic, buggy and will cause issues in the futures. For example
in the future libkysdk-system packaging
at https://mentors.debian.net/package/libkysdk-system/, some file (e.g.,
src/systeminfo/libkysisinfo.c) will look for header in , not /usr/include/cstring-extension.h. This means
that libkysdk-system will break when being built in the future. Please,
carefully review your packaging decision again; if you are sure that current
packaging is acceptable, I can upload it as-is. Otherwise I recommend you to
review the decision on header file path.

Thanks,
Boyuan Yang

> 在2023年02月22 06时34分，"Boyuan Yang"写道：
> > 
> > Control: tags -1 +moreinfo
> > 
> > Indeed, please fix the error listed below before we can proceed.
> > 
> > Thanks,
> > Boyuan Yang
> > 
> > On Thu, 16 Feb 2023 19:55:44 +0100 Adam Borowski 
> > wrote:
> > > On Thu, Feb 16, 2023 at 11:05:42AM +0800, kevin wrote:
> > > >   * Package name : libkysdk-base
> > > > Version  : 1.0.1-1
> > > 
> > > >   libkysdk-base (1.0.1-1) unstable; urgency=medium
> > > >   .
> > > > * Initial release. (Closes: #1031344)
> > > 
> > > Hi!
> > > Alas, the package fails to build:
> > > 
> > > .
> > > dh_missing: warning: etc/kysdk/kysdk-base/kylog-rotate-default exists
> > > in
> > debian/tmp but is not installed to anywhere (related file:
> > "src/log/kylog-
> > rotate-default")
> > > dh_missing: warning: usr/include/kysdk/kysdk-base/libkylog.h exists in
> > debian/tmp but is not installed to anywhere (related file:
> > "src/log/libkylog.h")
> > > dh_missing: warning: usr/include/kysdk/kysdk-base/listdata.h exists in
> > debian/tmp but is not installed to anywhere (related file:
> > "src/utils/data-
> > structure/linklist/listdata.h")
> > > dh_missing: warning: usr/include/kysdk/kysdk-base/skip_linklist.h
> > > exists
> > in debian/tmp but is not installed to anywhere (related file:
> > "src/utils/data-structure/linklist/skip_linklist/skip_linklist.h")
> > > dh_missing: error: missing files, aborting
> > > 
> > >While detecting missing files, dh_missing noted some files with
> > > a
> > similar name to those
> > >that were missing.  This error /might/ be resolved by replacing
> > references to the
> > >missing files with the similarly named ones that dh_missing
> > > found -
> > assuming the content
> > >is identical.
> > > 
> > >As an example, you might want to replace:
> > > * src/log/kylog-rotate-default
> > >with:
> > > * etc/kysdk/kysdk-base/kylog-rotate-default
> > >in a file in debian/ or as argument to one of the dh_* tools
> > > called
> > from debian/rules.
> > >(Note it is possible the paths are not used verbatim but
> > > instead
> &g

Bug#1031382: Re: Bug#1031382: RFS: libkysdk-base/1.0.1-1 [ITP] -- Kylin SDK basic library

2023-02-22 Thread Kevin Duan

HI!


Thanks for the heads up, I have fixed this issue in the latest version and have 
also uploaded the latest to mentors.
URL: https://mentors.debian.net/package/libkysdk-base/

Version:1.0.1-3


Thanks！

KevinDuan







在2023年02月22 06时34分，"Boyuan Yang"写道：

Control: tags -1 +moreinfo

Indeed, please fix the error listed below before we can proceed.

Thanks,
Boyuan Yang

On Thu, 16 Feb 2023 19:55:44 +0100 Adam Borowski 
wrote:
> On Thu, Feb 16, 2023 at 11:05:42AM +0800, kevin wrote:
> >  * Package name : libkysdk-base
> >Version  : 1.0.1-1
> 
> >  libkysdk-base (1.0.1-1) unstable; urgency=medium
> >  .
> >* Initial release. (Closes: #1031344)
> 
> Hi!
> Alas, the package fails to build:
> 
> .
> dh_missing: warning: etc/kysdk/kysdk-base/kylog-rotate-default exists in
debian/tmp but is not installed to anywhere (related file: "src/log/kylog-
rotate-default")
> dh_missing: warning: usr/include/kysdk/kysdk-base/libkylog.h exists in
debian/tmp but is not installed to anywhere (related file:
"src/log/libkylog.h")
> dh_missing: warning: usr/include/kysdk/kysdk-base/listdata.h exists in
debian/tmp but is not installed to anywhere (related file: "src/utils/data-
structure/linklist/listdata.h")
> dh_missing: warning: usr/include/kysdk/kysdk-base/skip_linklist.h exists
in debian/tmp but is not installed to anywhere (related file:
"src/utils/data-structure/linklist/skip_linklist/skip_linklist.h")
> dh_missing: error: missing files, aborting
> 
>   While detecting missing files, dh_missing noted some files with a
similar name to those
>   that were missing.  This error /might/ be resolved by replacing
references to the
>   missing files with the similarly named ones that dh_missing found -
assuming the content
>   is identical.
> 
>   As an example, you might want to replace:
>* src/log/kylog-rotate-default
>   with:
>* etc/kysdk/kysdk-base/kylog-rotate-default
>   in a file in debian/ or as argument to one of the dh_* tools called
from debian/rules.
>   (Note it is possible the paths are not used verbatim but instead
directories 
>   containing or globs matching them are used instead)
> 
>   Alternatively, add the missing file to debian/not-installed if it
cannot and should not
>   be used.
> 
>   The following debhelper tools have reported what they installed
(with files per package)
>* dh_install: libkysdk-base (0), libkysdk-base-dev (1), libkysdk-
config (2), libkysdk-config-dev (3), libkysdk-log (5), libkysdk-log-dev (3),
libkysdk-timer (2), libkysdk-timer-dev (3), libkysdk-utils (4), libkysdk-
utils-dev (9)
>* dh_installdocs: libkysdk-base (0), libkysdk-base-dev (0),
libkysdk-config (0), libkysdk-config-dev (0), libkysdk-log (0), libkysdk-
log-dev (0), libkysdk-timer (0), libkysdk-timer-dev (0), libkysdk-utils (0),
libkysdk-utils-dev (0)
>   If the missing files are installed by another tool, please file a
bug against it.
>   When filing the report, if the tool is not part of debhelper itself,
please reference the
>   "Logging helpers and dh_missing" section from the "PROGRAMMING"
guide for debhelper (10.6.3+).
> (in the debhelper package:
/usr/share/doc/debhelper/PROGRAMMING.gz)
>   Be sure to test with dpkg-buildpackage -A/-B as the results may vary
when only a subset is built
>   If the omission is intentional or no other helper can take care of
this consider adding the
>   paths to debian/not-installed.
> `
> 
> 
> Meow!
> -- 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
> ⢿⡄⠘⠷⠚⠋⠀
> ⠈⠳⣄
> 
>

Bug#1031382: Re: Bug#1031382: RFS: libkysdk-base/1.0.1-1 [ITP] -- Kylin SDK basic library

2023-02-22 Thread Kevin Duan

HI!

Thanks for the heads up, I have fixed this issue in the latest version and have 
also uploaded the latest to mentors.
URL: https://mentors.debian.net/package/libkysdk-base/

Version:1.0.1-3

Thanks！

KevinDuan

在2023年02月17 02时55分，"Adam Borowski"写道：

On Thu, Feb 16, 2023 at 11:05:42AM +0800, kevin wrote:
>  * Package name : libkysdk-base
>Version  : 1.0.1-1

>  libkysdk-base (1.0.1-1) unstable; urgency=medium
>  .
>* Initial release. (Closes: #1031344)

Hi!
Alas, the package fails to build:

.
dh_missing: warning: etc/kysdk/kysdk-base/kylog-rotate-default exists in 
debian/tmp but is not installed to anywhere (related file: 
"src/log/kylog-rotate-default")
dh_missing: warning: usr/include/kysdk/kysdk-base/libkylog.h exists in 
debian/tmp but is not installed to anywhere (related file: "src/log/libkylog.h")
dh_missing: warning: usr/include/kysdk/kysdk-base/listdata.h exists in 
debian/tmp but is not installed to anywhere (related file: 
"src/utils/data-structure/linklist/listdata.h")
dh_missing: warning: usr/include/kysdk/kysdk-base/skip_linklist.h exists in 
debian/tmp but is not installed to anywhere (related file: 
"src/utils/data-structure/linklist/skip_linklist/skip_linklist.h")
dh_missing: error: missing files, aborting

While detecting missing files, dh_missing noted some files with a 
similar name to those
that were missing.  This error /might/ be resolved by replacing 
references to the
missing files with the similarly named ones that dh_missing found - 
assuming the content
is identical.

As an example, you might want to replace:
 * src/log/kylog-rotate-default
with:
 * etc/kysdk/kysdk-base/kylog-rotate-default
in a file in debian/ or as argument to one of the dh_* tools called 
from debian/rules.
(Note it is possible the paths are not used verbatim but instead 
directories 
containing or globs matching them are used instead)

Alternatively, add the missing file to debian/not-installed if it 
cannot and should not
be used.

The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libkysdk-base (0), libkysdk-base-dev (1), 
libkysdk-config (2), libkysdk-config-dev (3), libkysdk-log (5), 
libkysdk-log-dev (3), libkysdk-timer (2), libkysdk-timer-dev (3), 
libkysdk-utils (4), libkysdk-utils-dev (9)
 * dh_installdocs: libkysdk-base (0), libkysdk-base-dev (0), 
libkysdk-config (0), libkysdk-config-dev (0), libkysdk-log (0), 
libkysdk-log-dev (0), libkysdk-timer (0), libkysdk-timer-dev (0), 
libkysdk-utils (0), libkysdk-utils-dev (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.
`

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1031383: RFS: libkysdk-system/2.0.0-1 [ITP] -- Kylin System Layer Developer Kit

2023-02-15 Thread kevin

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libkysdk-system":

 * Package name : libkysdk-system
   Version  : 2.0.0-1
   Upstream contact : Zhikai Chen 
 * URL  : https://gitee.com/openkylin/libkysdk-system
 * License  : BSL-1.0, Apache-2.0, GPL-2+, BSD-3-clause, LGPL-3+,
BSD-2-clause, Expat
 * Vcs  : https://gitee.com/openkylin/libkysdk-system
   Section  : utils

The source builds the following binary packages:

  libkysdk-system - Kylin System Layer Developer Kit
  libkysdk-system-dev - Kylin System Layer Developer Kit - Development Library
  libkysdk-disk - System Disk Information Acquisition Library
  libkysdk-disk-dev - System Disk Information Acquisition Library - Development
Library
  libkysdk-systime - Library of system time-related operations
  libkysdk-sysinfo - system information acquisition library
  libkysdk-sysinfo-dev - System information acquisition library - Development
Library
  libkysdk-filesystem - File system library
  libkysdk-filesystem-dev - File system library - Development Library
  libkysdk-hardware - Hardware information acquisition library
  libkysdk-hardware-dev - Hardware information acquisition library -
Development Library
  libkysdk-package - Package management library
  libkysdk-package-dev - Package management library - Development Library
  libkysdk-proc - Runtime information acquisition library
  libkysdk-proc-dev - Runtime information acquisition library - Development
Library
  libkysdk-powermanagement - Power management library
  libkysdk-powermanagement-dev - Power managementlibrary - Development Library
  libkysdk-ocr - AI text recognition function
  libkysdk-ocr-dev - AI text recognition function - Development Library
  libkysdk-location - Geographic location library
  libkysdk-location-dev - Geographic location library - Development Library
  libkysdk-net - Network information library
  libkysdk-net-dev - Network information library - Development Library
  libkysdk-realtime - Instantaneous information library
  libkysdk-realtime-dev - Instantaneous information library - Development
Library

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

  https://mentors.debian.net/package/libkysdk-system/

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

  dget -x https://mentors.debian.net/debian/pool/main/libk/libkysdk-
system/libkysdk-system_2.0.0-1.dsc

Changes for the initial release:

 libkysdk-system (2.0.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1031340)

Regards,
--

Bug#1031382: RFS: libkysdk-base/1.0.1-1 [ITP] -- Kylin SDK basic library

2023-02-15 Thread kevin

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libkysdk-base":

 * Package name : libkysdk-base
   Version  : 1.0.1-1
   Upstream contact : Zhikai Chen 
 * URL  : https://gitee.com/openkylin/libkysdk-base
 * License  : LGPL-3
 * Vcs  : https://gitee.com/openkylin/libkysdk-base
   Section  : libs

The source builds the following binary packages:

  libkysdk-base - Kylin SDK basic library
  libkysdk-base-dev - development files for libkysdk-base
  libkysdk-timer - C style timer module
  libkysdk-timer-dev - development files for libkysdk-timer
  libkysdk-config - configuration file module
  libkysdk-config-dev - development files for libkysdk-config
  libkysdk-log - C style log module
  libkysdk-log-dev - development files for libkysdk-log
  libkysdk-utils - Basic tool function module
  libkysdk-utils-dev - development files for libkysdk-utils

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

  https://mentors.debian.net/package/libkysdk-base/

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

  dget -x https://mentors.debian.net/debian/pool/main/libk/libkysdk-
base/libkysdk-base_1.0.1-1.dsc

Changes for the initial release:

 libkysdk-base (1.0.1-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1031344)

Regards,
--

Bug#1031350: ITP: libkysdk-system -- Kylin System Layer Developer Kit

2023-02-15 Thread kevin

Package: wnpp
Severity: wishlist
Owner: KevinDuan 
X-Debbugs-Cc: debian-de...@lists.debian.org, duankai...@ubuntukylin.com


* Package name: libkysdk-system
  Version : 1.0.1-1
  Upstream Author : KevinDuan 
* URL : https://gitee.com/openkylin/libkysdk-system
* License : LGPL-3+, GPL-2+, BSL-1.0, BSD-3-clause, BSD-2-clause,
Apache-2.0
  Programming Lang: C++
  Description : Kylin System Layer Developer Kit

 libkysdk-system is system layer kit that provides API and services such as
system information, disk information and system time, etc.
 .
 This package is metapackage.It provides the kysdk shared basic libraries.

Bug#1031348: ITP: libkysdk-system -- Kylin System Layer Developer Kit

2023-02-15 Thread kevin

Package: wnpp
Severity: wishlist
Owner: KevinDuan 
X-Debbugs-Cc: debian-de...@lists.debian.org, duankai...@ubuntukylin.com

* Package name: libkysdk-system
  Version : 2.0.0-1
  Upstream Author : KevinDuan 
* URL : https://gitee.com/openkylin/libkysdk-system
* License : LGPL-3+, GPL-2+, BSL-1.0, BSD-3-clause, BSD-2-clause,
Apache-2.0
  Programming Lang: C++
  Description : Kylin System Layer Developer Kit

 libkysdk-system is system layer kit that provides API and services
 such as system information, disk information and system time, etc.
 .
 This package is metapackage.It provides the kysdk shared basic libraries.

Bug#1031344: ITP: libkysdk-base -- Kylin SDK basic library

2023-02-15 Thread kevin

Package: wnpp
Severity: wishlist
Owner: KevinDuan 
X-Debbugs-Cc: debian-de...@lists.debian.org, duankai...@ubuntukylin.com

* Package name: libkysdk-base
  Version : 1.0.1-1
  Upstream Author : KevinDuan 
* URL : https://gitee.com/openkylin/libkysdk-base
* License : GPL-3, LGPL-3
  Programming Lang: C++
  Description : Kylin SDK basic library

 It provides common functions in the process of program
 development, including log management, message communication,
 process daemon, thread management, timer, debugging and embedding,
 configuration file reading and writing, etc.
 This package is empty package.

Bug#1031340: ITP: libkysdk-system -- Kylin System Layer Developer Kit

2023-02-15 Thread kevin

Package: wnpp
Severity: wishlist
Owner: KevinDuan 
X-Debbugs-Cc: debian-de...@lists.debian.org, duankai...@ubuntukylin.com

* Package name: libkysdk-system
  Version : 2.0.0-1
  Upstream Author : KevinDuan 
* URL : https://gitee.com/openkylin/libkysdk-system
* License : LGPL-3+, GPL-2+, BSL-1.0, BSD-3-clause, BSD-2-clause,
Apache-2.0
  Programming Lang: C++
  Description : Kylin System Layer Developer Kit

 libkysdk-system is system layer kit that provides API and services
 such as system information, disk information and system time, etc.
 .
 This package is metapackage.It provides the kysdk shared basic libraries.

Bug#1030930: podman: DNS resolution fails in 'podman build' but works in 'podman run'

2023-02-09 Thread Kevin P. Fleming

Package: podman
Version: 4.3.1+ds1-5+b1
Severity: important

Dear Maintainer,

I am seeing DNS resolution fail when using 'podman build' but succeed when
using 'podman run', with a Dockerfile which contains the same commands I run
manually in the 'podman run'-launched shell.

Dockerfile
--
FROM alpine:3.10
RUN cat /etc/resolv.conf
RUN apk add tar

'podman run'
--
kpfleming@nvr21:~/ctr-dns$ podman run --rm -it alpine:3.10 /bin/sh
/ # cat /etc/resolv.conf
nameserver 10.0.2.3
nameserver 2001:470:8afe:255::2
options edns0 trust-ad
/ # apk add tar
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-
cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/1) Installing tar (1.32-r1)
Executing busybox-1.30.1-r5.trigger
OK: 6 MiB in 15 packages
/ # exit

`podman build`
--
kpfleming@nvr21:~/ctr-dns$ podman build .
STEP 1/3: FROM alpine:3.10
STEP 2/3: RUN cat /etc/resolv.conf
--> Using cache
6e684b0a8063a3c6ea051cc28b16ea19cc984ba9f154810cc3235d10e2ad4b2b
--> 6e684b0a806
STEP 3/3: RUN apk add tar
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.10/main: temporary error (try
again later)
WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.10/main: No such file
or directory
fetch http://dl-
cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.10/community: temporary error
(try again later)
WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.10/community: No such
file or directory
ERROR: unable to select packages:
  tar (no such package):
required by: world[tar]
Error: building at STEP "RUN apk add tar": while running runtime: exit status 1

When I add 'strace' to the image and trace the 'apk' invocation, I see that the
DNS queries sent to the servers listed in /etc/resolv.conf both time out, when
using 'podman build'.

I have tested the 4.4 package from 'experimental' with no change in behavior.


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

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

Versions of packages podman depends on:
ii  conmon   2.1.3+ds1-1
ii  crun 1.5+dfsg-1+b1
ii  golang-github-containers-common  0.50.1+ds1-4
ii  libc62.36-8
ii  libdevmapper1.02.1   2:1.02.185-2
ii  libgpgme11   1.18.0-3+b1
ii  libseccomp2  2.5.4-1+b3
ii  libsubid41:4.13+dfsg1-1
ii  runc 1.1.4+ds1-1+b1

Versions of packages podman recommends:
ii  buildah1.28.2+ds1-1
ii  catatonit  0.1.7-1+b1
ii  dbus-user-session  1.14.4-1
ii  fuse-overlayfs 1.9-1
ii  slirp4netns1.2.0-1
ii  uidmap 1:4.13+dfsg1-1

Versions of packages podman suggests:
ii  containers-storage  1.43.0+ds1-7
pn  docker-compose  
ii  iptables1.8.9-2

-- no debconf information

Bug#1029945: systemd-resolved: resolve fails if /etc/hosts is a symlink (and causes spamming of log)

2023-01-29 Thread Kevin

Package: systemd-resolved
Version: 252.4-2
Severity: normal
X-Debbugs-Cc: deb...@kevinsteen.net

Dear Maintainer,

If /etc/hosts is a symlink, 'resolvectl query' fails to resolve names in the
linked file.
The log is also spammed every 2 seconds with the entry :
  "Failed to open /etc/hosts: Permission denied"
Permissions on the path to the linked file aren't the issue (all world-
readable).

Evidence:

Jan 29 11:12:31 shiny systemd-resolved[41798]: Failed to open /etc/hosts:
Permission denied
Jan 29 11:12:33 shiny systemd-resolved[41798]: Failed to open /etc/hosts:
Permission denied
Jan 29 11:12:35 shiny systemd-resolved[41798]: Failed to open /etc/hosts:
Permission denied
Jan 29 11:12:37 shiny systemd-resolved[41798]: Failed to open /etc/hosts:
Permission denied
Jan 29 11:12:39 shiny systemd-resolved[41798]: Failed to open /etc/hosts:
Permission denied
Jan 29 11:12:41 shiny systemd-resolved[41798]: Failed to open /etc/hosts:
Permission denied
Jan 29 11:12:43 shiny systemd-resolved[41798]: Failed to open /etc/hosts:
Permission denied
Jan 29 11:12:45 shiny systemd-resolved[41798]: Failed to open /etc/hosts:
Permission denied
^C
root@shiny ~ [SIGINT]# ll /etc/hosts
lrwxrwxrwx 1 root root 22 May 23  2022 /etc/hosts -> /home/bob/hfiles/hosts
root@shiny ~# ll -d /home
drwxr-xr-x 1 root root 6 May 22  2022 /home/
root@shiny ~# ll -d /home/bob
drwxr-xr-x 1 bob bob 968 Jan 29 10:48 /home/bob/
root@shiny ~# ll -d /home/bob/hfiles
drwxr-xr-x 1 bob bob 606 Jun 22  2022 /home/bob/hfiles/
root@shiny ~# ll -d /home/bob/hfiles/hosts
-rw-r--r-- 1 bob bob 586 Jun 22  2022 /home/bob/hfiles/hosts

Sincerely
-Kevin


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

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

Versions of packages systemd-resolved depends on:
ii  dbus [default-dbus-system-bus]  1.14.4-1
ii  libc6   2.36-8
ii  libssl3 3.0.7-2
ii  libsystemd-shared   252.4-2
ii  systemd 252.4-2

Versions of packages systemd-resolved recommends:
pn  libnss-myhostname  
pn  libnss-resolve 

Versions of packages systemd-resolved suggests:
ii  policykit-1  122-2
ii  polkitd  122-2

-- no debconf information

Bug#1027476: cron: postrm script fails because expected dpkg-statoverride is not present

2023-01-01 Thread Kevin P. Fleming

Package: cron
Version: 3.0pl1-154
Severity: normal

Dear Maintainer,

The postrm script in the current version of the cron package assumes the
presence of a dpkg-statoverride for /usr/bin/crontab, but no such statoverride
is present on my systems. As a result when I try to 'purge' the cron package
the process fails.

Recipe to reproduce the issue:

1) cd /root
2) mkdir foo
3) debootstrap --variant=minbase --include=logrotate,systemd-cron bookworm
4) chroot /root/foo /bin/bash
5) apt remove --purge cron

This results in the following output:

Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  cron*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
(Reading database ... 11054 files and directories currently installed.)
Purging configuration files for cron (3.0pl1-154) ...
dpkg-statoverride: warning: no override present
dpkg: error processing package cron (--purge):
 installed cron package post-removal script subprocess returned error exit
status 2
Errors were encountered while processing:
 cron
E: Sub-process /usr/bin/dpkg returned an error code (1)

Editing /var/lib/dpkg/info/cron.postrm to remove the first section resolves the
issue.


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

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

Versions of packages cron depends on:
ii  cron-daemon-common   3.0pl1-154
ii  init-system-helpers  1.65.2
ii  libc62.36-7
ii  libpam-runtime   1.5.2-5
ii  libpam0g 1.5.2-5
ii  libselinux1  3.4-1+b4
ii  sensible-utils   0.0.17

Versions of packages cron recommends:
ii  msmtp-mta [mail-transport-agent]  1.8.22-1

Versions of packages cron suggests:
pn  checksecurity   
ii  logrotate   3.21.0-1
ii  systemd-cron [anacron]  1.15.19-2+b1

Bug#1025819: util-linux: Move isosize out of /usr/sbin

2022-12-09 Thread Kevin Thibedeau


Package: util-linux
Version: 2.36.1-8+deb11u1
Severity: wishlist

Dear Maintainer,


The isosize program is currently in /usr/sbin and requires root 
permission to
run. This program should be safe for regular users to use and can be 
moved to
/usr/bin. Moreover, the genisoimage package provides the isoinfo program 
which
performs the same access to optical drives without needing root. The 
latter has
more verbose output and isosize is more suitable for scripting that just 
needs to

get a filesystem size.


-- System Information:
Debian Release: 11.5
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-19-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages util-linux depends on:
ii libaudit1 1:3.0-2
ii libblkid1 2.36.1-8+deb11u1
ii libc6 2.31-13+deb11u5
ii libcap-ng0 0.7.9-2.2+b1
ii libcrypt1 1:4.4.18-4
ii libmount1 2.36.1-8+deb11u1
ii libpam0g 1.4.0-9+deb11u1
ii libselinux1 3.1-3
ii libsmartcols1 2.36.1-8+deb11u1
ii libsystemd0 247.3-7+deb11u1
ii libtinfo6 6.2+20201114-2
ii libudev1 247.3-7+deb11u1
ii libuuid1 2.36.1-8+deb11u1
ii login 1:4.8.1-1
ii zlib1g 1:1.2.11.dfsg-2+deb11u2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii dosfstools 4.2-1
ii kbd 2.3.0-3
ii util-linux-locales 2.36.1-8+deb11u1

Bug#1024427: reproducible segfault in bullseye mutt

2022-11-30 Thread Kevin J. McCarthy

Note this was fixed in Mutt 2.2.8.  See 
https://gitlab.com/muttmua/mutt/-/issues/428 for the Mutt bug report.


This important fix is at: 
https://gitlab.com/muttmua/mutt/-/commit/48b6ea32e21db8b580cd3ca8c346c3e2c22756f6.patch


There are two related commits, that may be of interest in backporting 
too, but aren't the cause of this segfault:

https://gitlab.com/muttmua/mutt/-/commit/f0eb3586480c301b66657c7326b6546ef086c7f4.patch
https://gitlab.com/muttmua/mutt/-/commit/b254f2fb44f994c48e2491adaf03d97d3c628283.patch

-Kevin


signature.asc
Description: PGP signature

Bug#1024981: chromium: .remove-on-upgrade [...]/duckduckgo.json: Not found in archive

2022-11-27 Thread Kevin Locke

Package: chromium
Version: 107.0.5304.121-1~deb11u1
Severity: minor

Dear Maintainer,

When the chromium package is upgraded by unattended-upgrades on
Bullseye it produces the following error:

tar: .remove-on-upgrade /etc/chromium/policies/recommended/duckduckgo.json: Not 
found in archive
tar: Exiting with failure status due to previous errors

To reproduce the error on a fresh Bullseye install run (as root):

apt install -y unattended-upgrades chromium=104.0.5112.79-1~deb11u1 
chromium-common=104.0.5112.79-1~deb11u1
unattended-upgrades

Although chromium and chromium-common are upgraded from
104.0.5112.79-1~deb11u1 to 107.0.5304.121-1~deb11u1, the error message
is concerning (and annoying).  It would be nice if it could be fixed
or avoided.

Note: /etc/chromium/policies/recommended/duckduckgo.json does not
exist in either version of the package, as far as I can tell.

Thanks for considering,
Kevin

-- 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/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common107.0.5304.121-1~deb11u1
ii  libasound2 1.2.4-1.1
ii  libatk-bridge2.0-0 2.38.0-1
ii  libatk1.0-02.36.0-2
ii  libatomic1 10.2.1-6
ii  libatspi2.0-0  2.38.0-4
ii  libbrotli1 1.0.9-2+b2
ii  libc6  2.31-13+deb11u5
ii  libcairo2  1.16.0-5
ii  libcups2   2.3.3op2-3+deb11u2
ii  libdbus-1-31.12.24-0+deb11u1
ii  libdouble-conversion3  3.1.5-6.1
ii  libdrm22.4.104-1
ii  libevent-2.1-7 2.1.12-stable-1
ii  libexpat1  2.2.10-2+deb11u5
ii  libflac8   1.3.3-2+deb11u1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1+deb11u1
ii  libgbm120.3.5-1
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libjpeg62-turbo1:2.0.6-4
ii  libjsoncpp24   1.9.4-4
ii  liblcms2-2 2.12~rc1-2
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.29-1
ii  libnss32:3.61-1+deb11u2
ii  libopenjp2-7   2.4.0-3
ii  libopus0   1.3.1-0.1
ii  libpango-1.0-0 1.46.2-3
ii  libpng16-161.6.37-3
ii  libpulse0  14.2-2
ii  libre2-9   20210201+dfsg-1
ii  libsnappy1v5   1.1.8-1
ii  libstdc++6 10.2.1-6
ii  libwebp6   0.6.1-2.1
ii  libwebpdemux2  0.6.1-2.1
ii  libwebpmux30.6.1-2.1
ii  libwoff1   1.0.2-1+b1
ii  libx11-6   2:1.7.2-1
ii  libxcb11.14-3
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.5-2
ii  libxext6   2:1.3.3-1.1
ii  libxfixes3 1:5.0.3-2
ii  libxkbcommon0  1.0.3-2
ii  libxml22.9.10+dfsg-6.7+deb11u3
ii  libxnvctrl0470.141.03-1~deb11u1
ii  libxrandr2 2:1.5.1-1
ii  libxslt1.1 1.1.34-4+deb11u1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backen  1.8.0-1
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

Versions of packages chromium recommends:
ii  chromium-sandbox

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

2022-11-21 Thread Kevin P. Fleming

On Sun, Nov 20, 2022, at 12:56, Kevin P. Fleming wrote:
> On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote:
>
>> If that would be helpful, we have some instructions on "simple
>> patching and building" the kernel with a additional patches on top
>> here:
>>
>> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
>
> I found those via another path, and used them :-) Had a few little 
> issues along the way: failing to set DEBFULLNAME produces a broken 
> changelog entry so then the build won't run (and leaves the tree in a 
> broken state as well). Once I solved that problem I was able to make 
> packages, but the linux-headers-common package didn't get produced, so 
> I had to use --force-depends-version when installing the packages 
> (which I knew was safe since the headers had not changed).
>
> I now have the patched kernel in operation and should know whether the 
> problem is solved in 24-48 hours.

It's been more than 24 hours and connectivity is still in place, and it never 
lasted this long without the patch. I'm comfortable saying that this patch 
resolved the problem.

Bug#990828: mutt can not delete mails due to access rights

2022-11-21 Thread Kevin J. McCarthy


On Mon, Nov 21, 2022 at 02:53:14PM +0100, Juan Pedro Vallejo wrote:

Yes, you were right.

Architecture: i386 (i686)


Thank you Juan.  So you are running the i386 mutt package on an i386 
architecture.  I believe this means something is wrong the package 
building environment.


I've just looked again at the Mutt configure/makefile related to 
mutt_dotlock, and it turns out Mutt always installs as group 'mail' when 
setting sgid:


configure.ac:
=
if test x$mutt_cv_setgid = xyes; then
DOTLOCK_GROUP='mail'
DOTLOCK_PERMISSION=2755
else
DOTLOCK_GROUP=''
DOTLOCK_PERMISSION=755
fi
AC_SUBST(DOTLOCK_GROUP)
AC_SUBST(DOTLOCK_PERMISSION)

Makefile.am:

if test -f $(DESTDIR)$(bindir)/mutt_dotlock && test x$(DOTLOCK_GROUP) 
!= x ; then \
chgrp $(DOTLOCK_GROUP) $(DESTDIR)$(bindir)/mutt_dotlock && \
chmod $(DOTLOCK_PERMISSION) $(DESTDIR)$(bindir)/mutt_dotlock || 
\
{ echo "Can't fix mutt_dotlock's permissions!  This is required to lock 
mailboxes in the mail spool directory." >&2 ; exit 1 ; } \
fi


The content of the various mutt deb files:
==
% for deb in *; do echo $deb; dpkg -c $deb | grep bin/mutt_dotlock; echo; done
mutt_2.2.9-1_amd64.deb
-rwxr-sr-x root/mail 14584 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_arm64.deb
-rwxr-sr-x root/mail 67680 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_armel.deb
-rwxr-sr-x root/root 67108 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_armhf.deb
-rwxr-sr-x root/root 67120 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_i386.deb
-rwxr-sr-x root/root 13804 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_mips64el.deb
-rwxr-sr-x root/mail 68648 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_mipsel.deb
-rwxr-sr-x root/root 67732 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_ppc64el.deb
-rwxr-sr-x root/mail 67760 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_s390x.deb
-rwxr-sr-x root/mail 14432 2022-11-13 09:01 ./usr/bin/mutt_dotlock


I'm not sure what is going wrong, but armel, armhf, i386, and mipsel are 
failing to chgrp to mail during the package building.


Antonio I'll need your help to figure out what is going on in this case. 
Since this renders the program unusable for working with spoolfile mail, 
I think this ought to be bumped to 'serious'.


-Kevin



signature.asc
Description: PGP signature

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

2022-11-20 Thread Kevin P. Fleming

On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote:

> If that would be helpful, we have some instructions on "simple
> patching and building" the kernel with a additional patches on top
> here:
>
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2

I found those via another path, and used them :-) Had a few little issues along 
the way: failing to set DEBFULLNAME produces a broken changelog entry so then 
the build won't run (and leaves the tree in a broken state as well). Once I 
solved that problem I was able to make packages, but the linux-headers-common 
package didn't get produced, so I had to use --force-depends-version when 
installing the packages (which I knew was safe since the headers had not 
changed).

I now have the patched kernel in operation and should know whether the problem 
is solved in 24-48 hours.

Bug#990828: mutt can not delete mails due to access rights

2022-11-20 Thread Kevin J. McCarthy


On Sun, Nov 20, 2022 at 01:50:41PM +0100, Juan Pedro Vallejo wrote:

"mutt_dotlock" is the one to blame:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root root 13804 Nov 13 18:01 /usr/bin/mutt_dotlock

This works for me:

# chown root:mail /usr/bin/mutt_dotlock
# chmod 2755 /usr/bin/mutt_dotlock

Now:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root mail 13804 Nov 13 18:01 /usr/bin/mutt_dotlock


Thanks for the information.  What architecture are you running on?  The 
amd64 package installs properly with sgid mail.


However, I did check the various packages for 2.2.9, and it looks like 
the i386 package does not.  Are you running i386 architecture, or did 
you install the i386 package on an amd64 architecture?


I don't know if this is a bug in the i386 packaging environment, or if 
the mail directories on i386 are different.  I'm Cc'ing Antonio to see 
if he has any input.


-Kevin


signature.asc
Description: PGP signature

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

2022-11-20 Thread Kevin P. Fleming

On Sun, Nov 20, 2022, at 08:15, Salvatore Bonaccorso wrote:
> Hi,
>
> On Sun, Nov 20, 2022 at 02:13:11PM +0100, Salvatore Bonaccorso wrote:
>> Control: tags -1 + moreinfo
>> 
>> Hi,
>> 
>> On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
>> > Package: src:linux
>> > Version: 6.0.7-1
>> > Severity: normal
>> > Tags: ipv6
>> > 
>> > Dear Maintainer,
>> > 
>> > This system has been operating for most of the last 12 months, using
>> > ProxyNDP on its external interface for eight addresses. After
>> > upgrading to the 6.0 kernel series, the kernel stops responding to ND
>> > solicitations for those addresses after startup... it does not happen
>> > immediately, but reliably occurs. When the system is in this state
>> > (not responding to ND solicitations for the proxy addresses), the
>> > proxy addresses are still shown in 'ip neigh show proxy', and the
>> > single non-proxy address on the same interface continues operating
>> > normally.
>> > 
>> > Booting the system with the 5.19.0-2 kernel package cures the problem,
>> > with no other changes.
>> > 
>> > Example output:
>> > 
>> > root@net22:~# ip neigh show proxy
>> > 2607:5300:203:9743::1 dev ve-diw20 proxy 
>> > 2607:5300:203:9743::1 dev ve-matrix20 proxy 
>> > 2607:5300:203:9743::1 dev ve-ns3 proxy 
>> > 2607:5300:203:9743::1 dev ve-ldl20 proxy 
>> > 2607:5300:203:9743::1 dev ve-quassel21 proxy 
>> > 2607:5300:203:9743::1 dev ve-mastodon22 proxy 
>> > 2607:5300:203:9743::1 dev ve-monica21 proxy 
>> > 2607:5300:203:9743::1 dev ve-mail20 proxy 
>> > 2607:5300:203:9743:4::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:1::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:8::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:5::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:3::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:2::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:6::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:7::1 dev enp1s0f0 proxy 
>> > 
>> > The addresses on enp1s0f0 are the ones which stop responding.
>> 
>> Does the following matches your problem?
>> 
>> https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/
>> 
>> Would you be able to test the mentioned patch to verify a fix for your
>> issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
>> proxy_queue.qlen limit per-device") introduced in 6.0-rc2.
>
> For reference, the commit would be v2 as applied in netdev as
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8207f253a097fe15c93d85ac15ebb73c5e39e1e1

While that description does not exactly match my problem, it is so similar as 
to almost certainly be the cause. I would be happy to try applying that patch, 
but it's been a while since I built a patched Debian kernel so it may take a 
couple of days :-)

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

2022-11-14 Thread Kevin P. Fleming

Package: src:linux
Version: 6.0.7-1
Severity: normal
Tags: ipv6

Dear Maintainer,

This system has been operating for most of the last 12 months, using
ProxyNDP on its external interface for eight addresses. After
upgrading to the 6.0 kernel series, the kernel stops responding to ND
solicitations for those addresses after startup... it does not happen
immediately, but reliably occurs. When the system is in this state
(not responding to ND solicitations for the proxy addresses), the
proxy addresses are still shown in 'ip neigh show proxy', and the
single non-proxy address on the same interface continues operating
normally.

Booting the system with the 5.19.0-2 kernel package cures the problem,
with no other changes.

Example output:

root@net22:~# ip neigh show proxy
2607:5300:203:9743::1 dev ve-diw20 proxy 
2607:5300:203:9743::1 dev ve-matrix20 proxy 
2607:5300:203:9743::1 dev ve-ns3 proxy 
2607:5300:203:9743::1 dev ve-ldl20 proxy 
2607:5300:203:9743::1 dev ve-quassel21 proxy 
2607:5300:203:9743::1 dev ve-mastodon22 proxy 
2607:5300:203:9743::1 dev ve-monica21 proxy 
2607:5300:203:9743::1 dev ve-mail20 proxy 
2607:5300:203:9743:4::1 dev enp1s0f0 proxy 
2607:5300:203:9743:1::1 dev enp1s0f0 proxy 
2607:5300:203:9743:8::1 dev enp1s0f0 proxy 
2607:5300:203:9743:5::1 dev enp1s0f0 proxy 
2607:5300:203:9743:3::1 dev enp1s0f0 proxy 
2607:5300:203:9743:2::1 dev enp1s0f0 proxy 
2607:5300:203:9743:6::1 dev enp1s0f0 proxy 
2607:5300:203:9743:7::1 dev enp1s0f0 proxy 

The addresses on enp1s0f0 are the ones which stop responding.

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: GIGABYTE
product_name: MX33-BS1-V1
product_version: 0100
chassis_vendor: GIGABYTE
chassis_version: To be filled by O.E.M.
bios_vendor: GIGABYTE
bios_version: F04a
board_vendor: GIGABYTE
board_name: MX33-BS1-V1
board_version: 

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4c53] (rev 01)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: icl_uncore

00:08.0 System peripheral [0880]: Intel Corporation Device [8086:4c11] (rev 01)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:12.0 Serial controller [0700]: Intel Corporation Tiger Lake-H Integrated 
Sensor Hub [8086:43fc] (rev 11) (prog-if 00 [8250])
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Integrated Sensor 
Hub [1458:1000]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel modules: intel_ish_ipc

00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-H USB 3.2 Gen 2x1 
xHCI Host Controller [8086:43ed] (rev 11) (prog-if 30 [XHCI])
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H USB 3.2 Gen 2x1 
xHCI Host Controller [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-H Shared SRAM 
[8086:43ef] (rev 11)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Shared SRAM 
[1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger Lake-H Serial IO 
I2C Controller #0 [8086:43e8] (rev 11)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Serial IO I2C 
Controller [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:16.0 Communication controller [0780]: Intel Corporation Tiger Lake-H 
Management Engine Interface [8086:43e0] (rev 11)
DeviceName: Onboard - Other
Subsystem: Gigabyte Technology Co., Ltd Tiger Lake-H Management Engine 
Interface [1458:1000]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-

Bug#1023599: mutt: FTBFS due to lack of gpgme-config since gpgme1.0 1.18.0-2

2022-11-12 Thread Kevin J. McCarthy


I've just released mutt 2.2.9, which I believe should fix this problem.

-Kevin


signature.asc
Description: PGP signature

Bug#1023599: mutt: FTBFS due to lack of gpgme-config since gpgme1.0 1.18.0-2

2022-11-07 Thread Kevin J. McCarthy


On Mon, 7 Nov 2022 13:04:04 +0100 Vincent Lefevre  wrote:

The gpgme-config utility was removed in gpgme1.0 1.18.0-2
(because it needs gpg-error-config, which has been removed).

As a consequence the use of --enable-gpgme to build Mutt yields
an error:


Just as a note, with Vincent's help, I've commited two patches to the 
stable branch, updating to the most recent GPGME autoconf files and 
adjusting AM_PATH_GPG_ERROR before AM_PATH_GPGME:


https://gitlab.com/muttmua/mutt/-/commit/012981e8434903e8b5ae5f099b026b9a64426129.patch
https://gitlab.com/muttmua/mutt/-/commit/527537027b0c9134192663c9d3ec01d6cea6c5c2.patch

I will try to get a Mutt release out later this week with these two 
commits, but if you need the fix sooner, please grab the above patches.


-Kevin


signature.asc
Description: PGP signature

Bug#1023426: gnucash: Crash importing a QFX/OFX file

2022-11-03 Thread Kevin McCarthy

Package: gnucash
Version: 1:4.12-1
Severity: important
Tags: patch

Dear Maintainer,

Starting with 4.12-1, gnucash is crashing when trying to import a
QFX/OFX file (for example from my bank).

This has been reported and fixed upstream at:
https://bugs.gnucash.org/show_bug.cgi?id=798629

And a patch has been commited to their maint branch at:
https://github.com/Gnucash/gnucash/commit/14fe4d862f9cd797fb947bc20403b9cf4bb9eece

This is having a severe usability impact (at least for me), so I was 
opening this ticket to ask (or to beg ;-)) if you would consider adding 
the above commit as a patch until 4.13 releases?

Thank you!

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

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

Versions of packages gnucash depends on:
ii  gnucash-common 1:4.12-1
ii  guile-3.0  3.0.8-2
ii  guile-3.0-libs 3.0.8-2
ii  libaqbanking44 6.5.3-1
ii  libboost-filesystem1.74.0  1.74.0-17
ii  libboost-locale1.74.0  1.74.0-17
ii  libboost-program-options1.74.0 1.74.0-17
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu71]  1.74.0-17
ii  libc6  2.35-4
ii  libcairo2  1.16.0-6
ii  libcrypt-ssleay-perl   0.73.06-2+b1
ii  libdate-manip-perl 6.89-1
ii  libdbi10.9.0-6
ii  libfinance-quote-perl  1.53-1
ii  libgcc-s1  12.2.0-3
ii  libgdk-pixbuf-2.0-02.42.9+dfsg-1
ii  libglib2.0-0   2.74.1-1
ii  libgtk-3-0 3.24.34-3
ii  libgwengui-gtk3-79 5.10.1-1
ii  libgwenhywfar795.10.1-1
ii  libhtml-tableextract-perl  2.15-2
ii  libhtml-tree-perl  5.07-2
ii  libicu71   71.1-3
ii  libofx71:0.10.5-1
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangocairo-1.0-01.50.10+ds-1
ii  libpython3.10  3.10.8-1
ii  libsecret-1-0  0.20.5-3
ii  libstdc++6 12.2.0-3
ii  libwebkit2gtk-4.0-37   2.38.0-3
ii  libwww-perl6.67-1
ii  libxml22.9.14+dfsg-1+b1
ii  perl   5.36.0-4
ii  zlib1g 1:1.2.11.dfsg-4.1

Versions of packages gnucash recommends:
pn  gnucash-docs 
ii  python3-gnucash  1:4.12-1
pn  yelp 

Versions of packages gnucash suggests:
pn  libdbd-mysql
pn  libdbd-pgsql
pn  libdbd-sqlite3  

-- no debconf information

Bug#1022810: ddclient: Package installation does not respect systemd preset for disabling service

2022-10-26 Thread Kevin P. Fleming

Package: ddclient
Version: 3.9.1-7.1
Severity: normal

Dear Maintainer,

A systemd preset file is created to ensure that ddclient is not
automatically enabled and started, as in:

/etc/systemd/system-preset/00-ddclient.service.preset

disable ddclient.service


The ddclient package is then installed, and does not get enabled, but
does get started.

The preset file should be respected so that the admin's wishes for managing
the service state are taken into account.

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

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

Versions of packages ddclient depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  init-system-helpers1.65.2
ii  libdata-validate-ip-perl   0.30-1
ii  lsb-base   11.4
ii  perl   5.34.0-5
ii  sysvinit-utils [lsb-base]  3.05-6

Versions of packages ddclient recommends:
pn  libdigest-sha-perl   
ii  libio-socket-inet6-perl  2.73-1
ii  libio-socket-ssl-perl2.075-1
ii  perl [libjson-pp-perl]   5.34.0-5

ddclient suggests no packages.

-- debconf information:
  ddclient/password-repeat: (password omitted)
  ddclient/password: (password omitted)
* ddclient/server:
* ddclient/username: fsfgfdgd
  ddclient/interface:
* ddclient/names: fgfdfds
  ddclient/protocol-other:
  ddclient/proxy:
* ddclient/password-mismatch:
  ddclient/blankhostslist:
  ddclient/run_mode: As a daemon
  ddclient/hostslist:
* ddclient/protocol: dyndns2
  ddclient/daemon_interval: 5m
* ddclient/method: Web-based IP discovery service
  ddclient/web-url: https://api.ipify.org/
  ddclient/fetchhosts: Manually
  ddclient/web: ipify-ipv4 https://api.ipify.org/
* ddclient/service: other

Bug#883126: darkice cannot connect to IPv6 icecast server

2022-10-18 Thread Kevin Otte


This PR has been merged. Unknown when a new release might be made.

On Fri, 29 Jan 2021 12:07:24 -0500 Kevin Otte  wrote:

I finally had a chance to chase this down and filed the issue upstream:
https://github.com/rafael2k/darkice/issues/166

I have also submitted a PR to try and fix the issue:
https://github.com/rafael2k/darkice/pull/167

Bug#1020594: ipxe-qemu: Cannot boot Linux image in UEFI VM

2022-09-23 Thread Kevin Otte

Package: ipxe-qemu
Version: 1.0.0+git-20190125.36a4c85-5.1
Severity: important

When attempting to network boot a UEFI VM, cannot boot the Linux kernel image:

iPXE> ifopen net0
iPXE> dhcp
Configuring (net0 52:54:00:b1:e7:9f).. ok
iPXE> kernel http://gemini.int.home.nivex.net/boot/bullseye/amd64/linux
http://gemini.int.home.nivex.net/boot/bullseye/amd64/linux... ok
Could not select: Exec format error (http://ipxe.org/2e008081)
iPXE>

This works fine in a BIOS based VM.

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

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

-- no debconf information

Bug#1018846: libvirt-daemon: Cannot start QEMU VM when host only has IPv6 address(es)

2022-08-31 Thread Kevin Otte

Package: libvirt-daemon
Version: 8.5.0-1
Severity: important
Tags: ipv6

Dear Maintainer,

When attempting to start a QEMU VM on a host with only IPv6 addresses 
available, qemu-system-x86_64 fails to start:

Aug 31 17:48:33 saratoga libvirtd[3181]: internal error: qemu unexpectedly 
closed the monitor: 2022-08-31T21:48:33.756030Z qemu-system-x86_64: warning: 
Spice: ../server/reds.cpp:2512:reds_init_socket: getaddrinfo(127.0.0.1,5900): 
Address family for hostname not supported#0122022-08-31T21:48:33.756074Z 
qemu-system-x86_64: warning: Spice: ../server/reds.cpp:3390:do_spice_init: 
Failed to open SPICE sockets#0122022-08-31T21:48:33.756100Z qemu-system-x86_64: 
failed to initialize spice server

This seems a bit odd since 127.0.0.1 is still defined on the machine:

kjotte@saratoga:~$ ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp0s25:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
link/ether 54:ee:75:0b:7b:1d brd ff:ff:ff:ff:ff:ff
inet6 2603:6080:a201:f402:941f:faf9:2ab1:9bfd/64 scope global temporary 
dynamic 
   valid_lft 86223sec preferred_lft 14223sec
inet6 2603:6080:a201:f402:56ee:75ff:fe0b:7b1d/64 scope global dynamic 
mngtmpaddr noprefixroute 
   valid_lft 86223sec preferred_lft 14223sec
inet6 fe80::56ee:75ff:fe0b:7b1d/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever
3: wlp3s0:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether b2:d6:78:7b:22:c6 brd ff:ff:ff:ff:ff:ff permaddr 
7c:7a:91:ba:30:24


To work around this problem, defining:
spice_listen = "::1"
in /etc/libvirt/qemu.conf allows the VM to start.

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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.3.1-1
ii  libblkid1   2.38.1-1
ii  libc6   2.34-4
ii  libdevmapper1.02.1  2:1.02.185-1
ii  libgcc-s1   12.2.0-1
ii  libglib2.0-02.72.3-1+b1
ii  libparted2  3.5-1
ii  libpcap0.8  1.10.1-4
ii  libpciaccess0   0.16-3
ii  libselinux1 3.4-1+b1
ii  libtirpc3   1.3.3+ds-1
ii  libudev1251.3-1
ii  libvirt-daemon-driver-qemu  8.5.0-1
ii  libvirt08.5.0-1
ii  libxml2 2.9.14+dfsg-1+b1

Versions of packages libvirt-daemon recommends:
ii  libvirt-daemon-driver-lxc   8.5.0-1
ii  libvirt-daemon-driver-vbox  8.5.0-1
ii  libvirt-daemon-driver-xen   8.5.0-1
ii  libxml2-utils   2.9.14+dfsg-1+b1
ii  lvm22.03.16-1
ii  netcat-openbsd  1.218-5
ii  qemu-system-x86 [qemu-kvm]  1:7.0+dfsg-7+b1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   8.5.0-1
pn  numad   

-- no debconf information

Bug#1017988: bluez: systemd: ConfigurationDirectory 'bluetooth' already exists but the mode is different

2022-08-23 Thread Kevin Locke

Package: bluez
Version: 5.65-1
Severity: minor

Dear Maintainer,

With bluez 5.65-1 and systemd 251.3-1, the following message is logged
on boot:

systemd[1234]: ConfigurationDirectory 'bluetooth' already exists but the mode 
is different. (File system: 755 ConfigurationDirectoryMode: 555)

My understanding is that this occurs because bluez creates the
/etc/bluetooth directory with mode 0755, yet
/lib/systemd/system/bluetooth.service contains

[Service]
ConfigurationDirectory=bluetooth
ConfigurationDirectoryMode=0555

Creating /etc/bluetooth with mode 0555 or setting
ConfigurationDirectoryMode to 0755 should resolve the warning.

Thanks,
Kevin


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

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

Versions of packages bluez depends on:
ii  dbus [default-dbus-system-bus]  1.14.0-2
ii  init-system-helpers 1.64
ii  kmod30+20220630-3
ii  libasound2  1.2.7.2-1
ii  libc6   2.34-4
ii  libdbus-1-3 1.14.0-2
ii  libdw1  0.187-1
ii  libglib2.0-02.72.3-1+b1
ii  libreadline88.1.2-1.2
ii  libudev1251.3-1
ii  lsb-base11.2
ii  udev251.3-1

bluez recommends no packages.

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

-- no debconf information

Bug#1014524: mutt: Mutt depends on moreutils package, but, it is not listed on dependencies, nor suggestions

2022-07-08 Thread Kevin J. McCarthy


On Thu, 7 Jul 2022 08:17:26 -0300 Marcelo Laia  wrote:

Mutt depends on moreutils package, but, it is not listed on dependencies, nor
suggestions.

I see that pee is necessary to open html messages.

With out moreutils package, when I try to open a html messages, it shows:

sh: 1: pee not found


This is most likely a system or user configuration issue.  Mutt uses 
mailcap to decide how to deal with attachments.  See the section in the 
manual <http://www.mutt.org/doc/manual/#mailcap> for more details about 
how that works.


AFAIK, nothing internal to Mutt (or its default shipped configuration) 
is trying to use "pee".  I would check the system mailcap /etc/mailcap 
for the first text/html entry, and also your ~/.mailcap file (if 
present) to see if that gives any hints about what is going on in your 
case.


-Kevin

Bug#1012600:

2022-06-30 Thread Kevin P. Fleming

The 2.1.5 packages have made their way into bookworm, and my system is
now happily running kernel 5.18 with ZFS.

Bug#1011040: postfix: fail TLS connection

2022-06-23 Thread Kevin Walton


Hi

Apologies I suspect this is not the right place to email - but I can't 
find out where to ask.  I also have this error on a brand new mail 
server, and I don't understand the impact of it.  I asked here:


https://askubuntu.com/questions/1411682/how-do-i-fix-postfix-submission-tls-error-unexpected-eof-while-reading-ssl

but have not been able to get any replies.

Any help appreciated

Thanks very much
Kevin

--
Kevin Walton
Mobile: 07867 825 847

Bug#977792: closed by Debian FTP Masters

2022-06-21 Thread Kevin Locke

found 977792 16.15.1+dfsg-1
found 977792 18.3.0+dfsg-1
thanks

On Sun, 2022-05-29 at 19:25 +0200, Jérémy Lal wrote:
> Le dim. 29 mai 2022 à 19:18, Kevin Locke  a écrit :
>> It may also be worth considering adding nodejs.links with content:
>> /usr/share/bash-completion/completions/node
>>  /usr/share/bash-completion/completions/nodejs
>> So that users will get completion for `node ` in addition to
>> `nodejs `.
> 
> Well, exactly !
> And thank you !
> The next update will fix this.

Thanks again for working on this issue and for such quick fixes!  I
must apologize for giving you bad advice.  The line I recommended for
nodejs.links was backward, which causes debhelper to overwrite the
bash-completion script named nodejs with a broken symlink pointing to
a nonexistent file named node.  My intent was to create a link named
node pointing to the bash-completion script named nodejs.  To do this,
the line in debian/nodejs.links should actually be:

/usr/share/bash-completion/completions/nodejs 
/usr/share/bash-completion/completions/node

My apologies,
Kevin

Bug#1012600:

2022-06-19 Thread Kevin P. Fleming

I'm no expert, but since these packages are in 'contrib' I suspect
they don't have the ability to block package upgrades in 'main'.

On Sun, Jun 19, 2022 at 5:51 AM Chris Putnam  wrote:
>
> Apologies if this question is well-answered, but why isn't this package 
> holding back the kernel to 5.17? In my mind an "apt upgrade" should not have 
> pulled 5.18, especially when the net result may well be an unbootable system. 
> Surely there's some way to mark this package as broken in tandem with 5.18?
>
> I'm also quite surprised this wasn't caught in sid before it was pulled into 
> testing. Is there any form of testing for this package going on in sid?

Bug#1013181: freerdp2-wayland: ERRCONNECT_TLS_CONNECT_FAILED with libssl3 and Server 2008 R2

2022-06-18 Thread Kevin Locke

Package: freerdp2-wayland
Version: 2.7.0+dfsg1-1+b1
Severity: normal

Dear Maintainer,

Attempting to connect to a computer running Remote Desktop Services on
Windows Server 2008 R2 (with default settings as far as I am aware)
using FreeRDP 2.7.0+dfsg1-1+b1 with default options fails with:

$ wlfreerdp /v:192.168.0.2
[08:00:38:003] [283611:283611] [ERROR][com.freerdp.core] - 
transport_connect_tls:freerdp_set_last_error_ex ERRCONNECT_TLS_CONNECT_FAILED 
[0x00020008]
[08:00:38:005] [283611:283611] [ERROR][com.freerdp.client.wayland] - Failed to 
connect

Using FreeRDP 2.7.0+dfsg1-1 (or 2.6.1+dfsg1-3+b1) works as expected.

This appears to be the same issue as Debian Bug 912206.  However, it
is now necessary to use seclevel 0 (by adding
/tls-ciphers:DEFAULT@SECLEVEL=0 or /tls-seclevel:0) rather than 1.

Since Server 2008 R2 is no longer generally supported, I wouldn't
recommend decreasing the default seclevel (unless there are other
supported RDP server versions which require it) but it would be nice
if the error message gave users some suggestions for likely causes of
ERRCONNECT_TLS_CONNECT_FAILED and how to address them.

Thanks,
Kevin


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

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

Versions of packages freerdp2-wayland depends on:
ii  libc6 2.33-7
ii  libfreerdp-client2-2  2.7.0+dfsg1-1+b1
ii  libfreerdp2-2 2.7.0+dfsg1-1+b1
ii  libuwac0-02.7.0+dfsg1-1+b1
ii  libwinpr2-2   2.7.0+dfsg1-1+b1

freerdp2-wayland recommends no packages.

freerdp2-wayland suggests no packages.

-- no debconf information

Bug#1011720: python-apt also fails with this error

2022-06-07 Thread Kevin P. Fleming

Building python-apt 2.3.0 also fails with the same error, so I suspect
the cause is in libapt-pkg, not libqapt.

Bug#977792: closed by Debian FTP Masters

2022-05-29 Thread Kevin Locke

found 977792 16.15.0+dfsg-1
thanks

On Fri, 2022-05-27 at 14:54 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the nodejs package:
> 
> #977792: nodejs: install bash-completion script
> 
> It has been closed by Debian FTP Masters  
> (reply to Jérémy Lal ).

Thanks for working on this issue!  Unfortunately, it does not appear
to be fixed in 16.15.0+dfsg-1, as the
/usr/share/bash-completion/completions directory is empty in this
version:

$ dget nodejs=16.15.0+dfsg-1
$ dpkg -c nodejs_16.15.0+dfsg-1_amd64.deb | grep bash-completion
drwxr-xr-x root/root 0 2022-05-27 07:48 ./usr/share/bash-completion/
drwxr-xr-x root/root 0 2022-05-27 07:48 
./usr/share/bash-completion/completions/

The buildd log for amd64[1] includes:

/bin/sh: 1: ./node: not found

in debian/rules override_dh_auto_build-arch on line 1443.  Which
appears be the source of the problem.  Apparently the error is not
fatal because it occurs in a variable substitution?  Was that
intentional?  Perhaps it could be fixed and made fatal with:

--- a/debian/rules
+++ b/debian/rules
@@ -257,7 +257,7 @@ endif

 override_dh_auto_build-arch: deps_build
dh_auto_build
-   $(shell ./node --completion-bash > ./debian/nodejs.bash-completion)
+   ./out/Release/node --completion-bash > ./debian/nodejs.bash-completion

 override_dh_auto_build-indep: deps_links
mkdir -p $(DEBIAN_DOC_DEPS)

It may also be worth considering adding nodejs.links with content:
/usr/share/bash-completion/completions/node 
/usr/share/bash-completion/completions/nodejs
So that users will get completion for `node ` in addition to
`nodejs `.

Thanks again,
Kevin

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=nodejs=amd64=16.15.0%2Bdfsg-1=1653680475=0

Bug#1011399: pipewire: create pipewire group with rlimits for rtprio/priority/memlock

2022-05-21 Thread Kevin Locke

Package: pipewire
Version: 0.3.51-1
Severity: wishlist

Dear Maintainer,

During the investigation of a scheduler priority issue in WirePlumber,
Niklāvs Koļesņikovs lamented Debian's use of RTKit for setting
scheduling priority[1], rather than a group with increased rlimits as
recommended in the Pipewire wiki.[2]  Niklāvs noted some of the
benefits:[3]

1. RTKit does not support Flatpak, whereas RLIMITs do work inside user
   namespaces.
2. RTKit usually does not go above priority 19 (though it should be
   noted that there's some level of disagreement in the pro audio
   community on what the appropriate priority for audio daemons [and
   applications] should be).
3. RTKit is known to sometimes think that its canary thread is
   starving when the system exits S3 sleep state, this will cause
   RTKit to revoke realtime from all clients until at least the
   particular client restarts (possibly also RTKit restart but I'm
   not immediately sure if it's that bad). The exact mechanism is
   unknown but speculated to happen if the canary thread or the
   watchdog ends up frozen at particular point making it perceive a
   huge realtime scheduling delay.
4. RTKit is actually abandoned with no upstream being interested or
   active in fixing bugs such as the previously described canary
   starvation issue. Worst of all the same will likely be true if a
   security issue is discovered.

Additionally:

5. It would allow raising the memlock rlimit, not handled by RTKit.
6. It would allow creating the WirePlumber GLib thread pool threads
   at a nice level matching the main thread and avoiding the
   "Failed to set scheduler settings: Operation not permitted"
   currently printed by wireplumber on startup.[4]

Perhaps it would make sense for the pipewire package to create a
pipewire group, configure the suggested rlimit values in a
/etc/security/limits.d/ file, and document use of the group in
README.Debian?

Thanks for considering,
Kevin

[1]: 
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/255#note_1393924
[2]: 
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance-tuning#rlimits
[3]: 
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/255#note_1394696
[4]: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/255

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

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

Versions of packages pipewire depends on:
ii  init-system-helpers  1.62
ii  libpipewire-0.3-modules  0.3.51-1
ii  pipewire-bin 0.3.51-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

2022-05-18 Thread Kevin J. McCarthy

On Sat, 30 Apr 2022 13:39:07 -0700 "Kevin J. McCarthy"  wrote:

On Thu, Apr 28, 2022 at 01:36:10PM -0700, Kevin J. McCarthy wrote:
>I don't know if you've compiled Mutt from git before, but if you are 
>able and willing to try, I would appreciate hearing it that helped 
>with your problem.

I've just released version 2.2.4 with a fix that I believe will also
address your issue.

When you have a chance to test against 2.2.4, would you mind updating this
ticket to confirm/deny that is the case?

Bob would you mind confirming that 2.2.4 fixes this issue for you?

Thank you,

-Kevin

signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

2022-05-14 Thread Kevin J. McCarthy

I've pushed the fix into the stable branch: 
<https://gitlab.com/muttmua/mutt/-/commit/6688bfbfe4fd1d50512d5a7abbf1bf2314b8095c.patch>, 
and will release 2.2.5 in the next few days.


My apologies for the botched patch file included in my previous email. 
I realized I did this when backing out format=flowed formatting and 
accidentally trimmed a trailing space in the patch itself.


-Kevin


signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

2022-05-13 Thread Kevin J. McCarthy


On Fri, May 13, 2022 at 11:24:44PM +, brian m. carlson wrote:

I built the Debian package with the patch applied below.  It didn't
quite apply cleanly with patch -p1, but I copied and pasted the change.
It does appear to work, and I'm using the patched version to send this.

Thanks so much for the fast turnaround time.


That's fantastic news!  Thank *you* for testing the patch.  Not sure why 
it didn't apply cleanly, but I'm glad you were able to make the changes 
yourself.


I'll give a little more time for Gábor to reply, but unless there is a 
problem, will commit this to stable this weekend, and will try to get a 
release out in the next week.


Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

2022-05-13 Thread Kevin J. McCarthy

On Fri, 13 May 2022 15:02:38 -0700 "Kevin J. McCarthy"  wrote:
> Thanks for the bug report.  Yes, it most definitely is.  I'll take a
> look to see what I can find.  Perhaps I've missed setting up some
> callback information that gsasl needs.
>
> Would you be able to test a patch if/when I create one?  If so, please
> make sure you are subscribed to this ticket and I'll work on something
> this weekend.

Brian and Gábor, I did indeed miss a callback value needed by GSSAPI:
hostname.  The Mutt IMAP/GSSAPI auth code is using the server hostname
for this field, contradicting the gsasl documentation which says to
supply the "local host name".  I'm trying the server hostname below.

If possible could you try either the git branch
'kevin/gsasl-gssapi-fixes' on GitLab
<https://gitlab.com/muttmua/mutt/-/commits/kevin/gsasl-gssapi-fixes> or
alternatively try recompiling the source Debian package with the below
patch applied?

Thank you!

- - - - - - 8< - - - - -

 From 9db29e904d1843a61b3a858d16d400af704fdadf Mon Sep 17 00:00:00 2001
From: Kevin McCarthy 
Date: Fri, 13 May 2022 15:37:58 -0700
Subject: [PATCH] Set gsasl hostname callback value.

This is needed for GSSAPI, and apparently DIGEST-MD5 too.

The documentation is a little vague, saying it "should be the local
host name of the machine", however the imap/auth_gss.c code seems to
be using the server-name.
---
  mutt_sasl_gnu.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/mutt_sasl_gnu.c b/mutt_sasl_gnu.c
index 7ebe4293..37d39657 100644
--- a/mutt_sasl_gnu.c
+++ b/mutt_sasl_gnu.c
@@ -219,6 +219,11 @@ static int mutt_gsasl_callback (Gsasl *ctx, Gsasl_session 
*sctx,
rc = GSASL_OK;
break;

+case GSASL_HOSTNAME:
+  gsasl_property_set (sctx, GSASL_HOSTNAME, conn->account.host);
+  rc = GSASL_OK;
+  break;
+
  default:
break;
}
-- 
GitLab

signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

2022-05-13 Thread Kevin J. McCarthy


On Fri, 13 May 2022 17:54:14 +0200  wrote:

I've run into this issue too, and it is clearly gsasl which is broken:

[2022-05-13 17:40:38] smtp_authenticate: Trying method GSSAPI LOGIN PLAIN
[2022-05-13 17:40:38] mutt_gsasl_get_mech() returned no usable mech
[2022-05-13 17:40:38] No authenticators available


Gabor, there is a problem with gsasl, which I'll try to work on this 
weekend.  If you can help test patches, please make sure you are 
subscribed to this ticket.


However, you'll also need to fix your $smtp_authenticators value - it 
should be colon separated, for example: "GSSAPI:LOGIN:PLAIN".


-Kevin


signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

2022-05-13 Thread Kevin J. McCarthy


On Fri, 13 May 2022 01:58:53 + "brian m. carlson" 
 wrote:

I use Kerberos on my personal network at home, and therefore I use
GSSAPI authentication for IMAP and SMTP.  While GSSAPI with IMAP works
fine, recently, GSSAPI with SMTP stopped working.  I suspect this is
related to the move to gsasl.


Thanks for the bug report.  Yes, it most definitely is.  I'll take a 
look to see what I can find.  Perhaps I've missed setting up some 
callback information that gsasl needs.


Would you be able to test a patch if/when I create one?  If so, please 
make sure you are subscribed to this ticket and I'll work on something 
this weekend.


Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010658: set smtp_authenticators=login works!

2022-05-12 Thread Kevin J. McCarthy


On Thu, May 12, 2022 at 04:57:55PM +0200, Václav Ovsík wrote:

I have added

set smtp_authenticators=login

and things works now!


Great!  Thank you for checking that LOGIN works properly.  I wanted to 
make sure there weren't other problems I needed to address inside Mutt.



So the problem is with the SMTP server side?


Technically it is, but I have made a commit in Mutt to work around the 
bug.  It will be in 2.2.5, or earlier if Antonio decides to add the 
patch to the Debian package.


Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)

2022-05-08 Thread Kevin J. McCarthy


On Fri, 6 May 2022 13:04:50 -0700 "Kevin J. McCarthy"  wrote:
However, in the mean time I've pushed a commit up to branch 
'kevin/gsasl-smtp-plain-workarounds' on gitlab:


I've merged this branch into stable, and it will be a part of 2.2.5 
sometime in the next few weeks.


Antonio if this starts to cause problems for others and 2.2.5 isn't out 
yet, feel free to grab the patch and apply to 2.2.4-2:


https://gitlab.com/muttmua/mutt/-/commit/9d5db7cb7e53be20bb3b87dd5877e7145660b931.patch

-Kevin


signature.asc
Description: PGP signature

Bug#599309: mutt: Reply->Postpone->Recall loses message associations

2022-05-06 Thread Kevin J. McCarthy


On Thu, 30 Dec 2010 13:56:51 + Antonio Radici  wrote:

tag 599309 +confirmed upstream
thanks

Hi Toni,
thanks for your report, I will forward this issue upstream.


The threading issue was fixed upstream in commits

1) 3c44f482
   


2) 31bc8262
   


The second commit was released with Mutt 1.8.0.

This should set reply flag in parent *provided* you are still in the 
same mailbox when you recall the message.


If you believe this addresses the issue adequately, please feel free to 
close it.  Thank you.


signature.asc
Description: PGP signature

Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)

2022-05-06 Thread Kevin J. McCarthy


On Fri, 6 May 2022 11:18:39 -0700 "Kevin J. McCarthy"  wrote:
According to my understanding of RFC4954, the "server challenge" 334 
response must either be blank (i.e., "334 "), or if there is data it 
must be base64 encoded.


I'm still interested to hear if 'set smtp_authenticators=login' works 
for you, just to make sure there isn't another issue I need to be aware 
of.


However, in the mean time I've pushed a commit up to branch 
'kevin/gsasl-smtp-plain-workarounds' on gitlab: 
<https://gitlab.com/muttmua/mutt/-/commit/85379c5a01168154f74a7d9841d1eab152b1b6b0.patch>


Would you be willing to try that patch - either via compiling from git, 
or modifying the deb package and adding the patch to it?


thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)

2022-05-06 Thread Kevin J. McCarthy


On Fri, 06 May 2022 12:03:27 +0200 Vaclav Ovsik  wrote:

after Mutt upgrade from version 2.1.4-1 to version 2.2.3-2 SASL
authentication stopped working.

Debug from Mutt version 2.2.3:
[...]



 [2022-05-06 10:33:39] smtp_auth_gsasl: using mech PLAIN
 [2022-05-06 10:33:39] Authenticating (PLAIN)...
 [2022-05-06 10:33:39] 5> AUTH PLAIN^M
 [2022-05-06 10:33:39] 5< 334 Send base64(login\0login\0password)
 [2022-05-06 10:33:39] gsasl_step64() failed (8): Base 64 coding error in SASL 
library


According to my understanding of RFC4954, the "server challenge" 334 
response must either be blank (i.e., "334 "), or if there is data it 
must be base64 encoded.


The Cyrus SASL library also assumes all data from the server will be 
base64 encoded, but it is smarter and knows it can send an initial 
response with AUTH PLAIN.


What happens if you set smtp_authenticators=login?  Does the server also 
send plain text in the 334 response?


-Kevin



signature.asc
Description: PGP signature

Bug#1010630: libice6: Missing symbolic link libICE.so (to libICE.so.6.3.0)

2022-05-05 Thread Kevin Cole

Package: libice6
Version: 2:1.0.10-1
Severity: normal
Tags: patch
X-Debbugs-Cc: dc.l...@gmail.com

Dear Maintainer,

I was attempting to build the Strawberry Music Player for a Raspberry Pi 4
with a fresh install of Raspberry Pi OS (Bullseye).   
  
The `$ make -j$(nproc)` command chugged along for a while and the eventually  
died with:
  
...   
make[2]: *** No rule to make target \ 
 '/usr/lib/arm-linux-gnueabihf/libICE.so', \  
 needed by 'strawberry'.  Stop.   
```   
  
Adding symbolic links fixed the problem:  

```   
$ sudo -i 
$ cd /usr/lib/arm-linux-gnueabihf/
$ ln -s libICE.so.6.3.0 libICE.so 
```   

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv7l

Kernel: Linux 5.15.32-v7l+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libice6 depends on:
ii  libbsd0 0.11.3-1
ii  libc6   2.31-13+rpt2+rpi1+deb11u2
ii  x11-common  1:7.7+22

libice6 recommends no packages.

libice6 suggests no packages.

-- no debconf information

Bug#1010628: libsm6: Missing symbolic link libSM.so (to libSM.so.6.0.1)

2022-05-05 Thread Kevin Cole

Package: libsm6
Version: 2:1.2.3-1
Severity: normal
Tags: patch
X-Debbugs-Cc: dc.l...@gmail.com

Dear Maintainer,


I was attempting to build the Strawberry Music Player for a Raspberry Pi 4
with a fresh install of Raspberry Pi OS (Bullseye).   
  
The `$ make -j$(nproc)` command chugged along for a while and the eventually  
died with:
  
...   
make[2]: *** No rule to make target \ 
 '/usr/lib/arm-linux-gnueabihf/libSM.so', \  
 needed by 'strawberry'.  Stop.   
```   
  
Adding symbolic links fixed the problem:  

```   
$ sudo -i 
$ cd /usr/lib/arm-linux-gnueabihf/
$ ln -s libSM.so.6.0.1 libSM.so   

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv7l

Kernel: Linux 5.15.32-v7l+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsm6 depends on:
ii  libc6 2.31-13+rpt2+rpi1+deb11u2
ii  libice6   2:1.0.10-1
ii  libuuid1  2.36.1-8+deb11u1

libsm6 recommends no packages.

libsm6 suggests no packages.

-- no debconf information

Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail

2022-05-03 Thread Kevin J. McCarthy


On Tue, May 03, 2022 at 12:00:44PM -0400, ant wrote:

 i don't explicitly set that variable anywhere in any of my mutt
profiles that i know of.  unsetting that does allow mutt to send
mail again using the 2.2.3-2 version so that did take care of the
problem.  thank you!  :)


I'm glad that fixed the problem.  But I think it would be worth 
investigating a bit more where the assignment came from.  From my most 
recent email (which I think arrived after you sent this one), it looks 
like the assignment, wherever it is, is using non-ascii quote-marks.


Mutt is actually *including* the unicode curly-quotes as part of the 
method value.  I think cyrus sasl must have been lax, but the gnu sasl 
code is picky about the value being legal.


So it can't actually find a method '”cram-md5”' in the list 'PLAIN LOGIN 
CRAM-MD5' provided by the server.


I think this bug can be closed, but I'd still like to hear if you found 
where it was coming from.  :-)


Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail

2022-05-03 Thread Kevin J. McCarthy


On Mon, 2 May 2022 20:35:13 -0700 "Kevin J. McCarthy"  wrote:
I'll try to see if I can duplicate the problem, but I don't have access 
to a smtp server supporting cram-md5.  Is the server you are using 
accessible for me to try (and of course fail) authenticating with?


I've just noticed one funny thing in your debug log:

[2022-05-02 19:11:00] smtp_authenticate: Trying method ”cram-md5”

The method name should not include any kind of quoting, and those seem 
to be non-ascii quote marks.


I wonder if you've accidentally copy/pasted non-ascii quotes in your 
muttrc 'set smtp_authenticators' line.  Try deleting the quote marks and 
manually re-type ascii double-quote (or single-quotes) around the value:

  set smtp_authenticators="cram-md5"

-Kevin


signature.asc
Description: PGP signature

Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail

2022-05-02 Thread Kevin J. McCarthy


On Mon, 02 May 2022 19:20:29 -0400 ant  wrote:

Package: mutt
Version: 2.2.3-1


Just checking this is for 2.2.3-2.  That update switched to the gsasl 
library, which unfortunately needs some bugs worked out with its mutt 
implementation.  :-(


From the debug log, it looks like you have $smtp_authenticators set. 
What happens if you unset that variable, does authentication work in 
that case?  What if you explicitly set $smtp_authenticators to "login" 
or "plain"?


I'll try to see if I can duplicate the problem, but I don't have access 
to a smtp server supporting cram-md5.  Is the server you are using 
accessible for me to try (and of course fail) authenticating with?


-Kevin


signature.asc
Description: PGP signature

Bug#1010369: RediSearch Upstream Needs Swapped out from version 1 to version 2

2022-05-02 Thread Kevin Shenk

Gotcha. That's too bad. Thanks much for your clarifications!

--
Kevin Shenk
Avunu LLC
On 4/30/2022 8:17:04 PM, Chris Lamb  wrote:
Hi,

> I see, that's too bad... is it easy to specify what the Redis Ltd would
> need to change to make their license compatible?

Yes, but that's not quite the issue. They are already aware of the
situation and (to reduce a very long and complex discussion into a
single sentence) the license incompatibility is essentially deliberate
and not an accidental oversight.

Regards,

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

[73a1f1d0-fdc7-42dd-9435-5a628e5c55ae]

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

2022-04-30 Thread Kevin J. McCarthy


On Thu, Apr 28, 2022 at 01:36:10PM -0700, Kevin J. McCarthy wrote:
I don't know if you've compiled Mutt from git before, but if you are 
able and willing to try, I would appreciate hearing it that helped 
with your problem.


I've just released version 2.2.4 with a fix that I believe will also
address your issue.

When you have a chance to test against 2.2.4, would you mind updating this
ticket to confirm/deny that is the case?

Thank you,

-Kevin

Bug#1010369: RediSearch Upstream Needs Swapped out from version 1 to version 2

2022-04-29 Thread Kevin Shenk

Package: redis-redisearch
Version: 1.2.2-4

Currently, this package is obviously packaging the now deprecated version 1 
source at https://github.com/goodform/RediSearch.git

This should be swapped out for the new version 2 upstream at 
https://github.com/RediSearch/RediSearch.git


[6c226525-c069-48e9-868b-fcc792609f12]

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

2022-04-28 Thread Kevin J. McCarthy


On Wed, 27 Apr 2022 15:10:09 -0700 "Kevin J. McCarthy"  wrote:
One change in 2.2.x was normalizing Maildir paths when opening them 
(as IMAP does) - removing a trailing delimiter.  This might cause the 
behavior you are describing.


Until I hear otherwise, I've been assuming the problem is because of 
this change.  Nothing of substance changed in the buffy routines that I 
can see.


I've pushed a couple possible commits up to branch 
'kevin/buffy-check-fixes' in the Mutt git repository: 
<https://gitlab.com/muttmua/mutt/-/commits/kevin/buffy-check-fixes>. 
The second commit is a bit more aggressive/dangerous, but may be more 
thorough at fixing other related issues.


I don't know if you've compiled Mutt from git before, but if you are 
able and willing to try, I would appreciate hearing it that helped with 
your problem.


Thank you,

-Kevin

Bug#632570: fails to join RFC 2231 continuations

2022-04-27 Thread Kevin J. McCarthy


On Mon, 13 Dec 2021 19:34:21 -0800 "Kevin J. McCarthy"  wrote:

I believe this was fixed in Mutt 1.6.0, and this ticket can be closed.


Again, this bug should be close-able.  Thank you!

-Kevin


signature.asc
Description: PGP signature

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

2022-04-27 Thread Kevin J. McCarthy


On Sun, 17 Apr 2022 14:20:54 -0600 Bob Proulx  wrote:

Starting with 2.2.3-1 the 'c' change-folder action now prompts with
the *previous folder always* and never prompts with any other folders.
It no longer selects a mailboxes folder with new mail.  It prompts
with the previous folder even if no new mail has arrived there.
Effectively creating a situation where one toggles between two folders
endlessly.


Bob, what type of mailbox are you using (Maildir, mbox, IMAP...)

What do your `mailboxes` lines in your muttrc look like?  Do they have a 
trailing slash?  If so, does the problem go away if you remove the 
trailing slash?


One change in 2.2.x was normalizing Maildir paths when opening them (as
IMAP does) - removing a trailing delimiter.  This might cause the
behavior you are describing.

-Kevin

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 3075 matches

Mail list logo