Bug#1069895: [debian-mysql] Bug#1069895: mariadb-server: InnoDB to hang on systems with very intensive write loads when running out of I/O slots. This problem is fixed with MariaDB Server 10.11.7. Can

[Oliver Werner]

Hello,
I wanted to ask if the status is with version 10.11.7 or newer? We also have 
the problem due to this bug on one system.

Kind regards
Oliver

Bug#1069705: lilypond man-page has defective link on Debian

[Werner LEMBERG]

> on https://manpages.debian.org/testing/lilypond/abc2ly.1.en.html is a
> reference to the abc standard applicable for this software. The related
> sentence is 
> 
> "abc2ly converts ABC music files (see
> http://abcnotation.com/abc2mtex/abc.txt) to LilyPond input."
> 
> The correct link is "http://abcnotation.com/abc2mtex/abc.txt; which
> leads the reader to a wiki page and a text file.

`abc2ly`'s man page of LilyPond's development version gets created
with `help2man` version 1.47.4, which gives

```
abc2ly converts ABC music files
(see https://abcnotation.com/standard/abc_v1.6.txt) to LilyPond input.
```

> On Debian the link is "http://abcnotation.com/abc2mtex/abc.txt)".

I guess that the Debian people use another version of `help2man` that
tries to convert URLs like the above to real hyperlinks, and that this
version uses a regular expression that accepts `(` and `)` as part of
URLs.  While this is technically correct, it might fail for situations
like the one under discussion where a human reader can easily deduce
that the final, closing parenthesis is actually *not* part of the URL.

Anyway, I've fixed this in LilyPond's git repository.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2309


 Werner

Bug#1063441: NO EFI entry created when installing with weekly Mate Live CD

[Brandon Werner]

I just discovered that a MR is already open that will fix this bug and wanted 
to add the link here.
https://salsa.debian.org/live-team/calamares-settings-debian/-/merge_requests/3
It would be great to get this merged to fix live installs of testing. Thanks.
Brandon

Bug#1063441: NO EFI entry created when installing with weekly Mate Live CD

[Brandon Werner]

I found the solution to this bug, and was able to successfully install a 
testing live image and boot it. The problem is actually in the 
calamares-settings-debian package.
The problem is caused by changes in the syntax of an upstream Calamares 
configuration file. Calamares has a mounts.conf which mounts additional 
filesystems needed for the chroot to work correctly, like /sys, /dev, and 
/proc. This file includes a way to indicate that filesystems should only be 
mounted on uefi systems, and this has changed.
IN the old config syntax, there were two groups of filesystems, "extraMounts:" 
and "extraMountsEfi:". In the new config syntax, "extraMountsEfi:" was removed, 
with all filesystems instead being listed under "extraMounts:". An additional 
key value pair is added to each entry which must be mounted for uefi systems 
"efi: true".
After deleting extraMountsEfi from mounts.conf on the live image, and adding 
"efi: true" at the end of the file in the "efivarfs" entry, the install worked 
with an efi variable being created in my firmware.
The file that needs to be updated is in the calamares-settings-debian package 
"calamares/modules/mount.conf". The file containing corrected syntax in 
upstream calamares is "src/modules/mount/mount.conf". It may be worth 
synchronizing the other changes in this file as well.

Bug#1063441: NO EFI entry created when installing with weekly Mate Live CD

[Brandon Werner]

package: calamares
version 3.3.1-1

Hi:
I attempted to install testing using the Debian live Mate CD. The install 
completes, however, no boot entry is added to the efi firmware. A partial 
install of grub is occurring, since the grub files are installed to the efi 
partition.
I tried to determine why the installer isn't creating the entry by examining 
the log file at /root/.cache/calamares/session.log on the live cd. I can see 
the grub-install command being run there, however, the output from the command 
isn't being recorded in the file, and I haven't found this output yet somewhere 
else to determine why things might be failing. I'll keep looking and update 
this bug if I find more info on this
On systems with secure boot turned off, the system might boot if no other 
operating system is installed, because the firmware will load the default path 
/boot/bootx64.efi on one of the disks in the system. I was able to produce this 
on a system with secure boot turned off (in my case, the installed Debian 
booted, because my ssd was the only disk in the system). When secure boot is 
turned on, boot will fail, since no firmware entry has been created pointing to 
shimx64.efi. I was able to reproduce this failing boot scenario by enabling 
secure boot. One thing worth noting is that when I boot into the system with 
secure boot off, and run grub-install, the firmware entry pointing to 
shimx64.efi is correctly created at that point, so this is definitely a problem 
in the installer. After installing grub from the installed system, I can then 
enable secure boot, and boot the installed Debian successfully.

Bug#1059227: Firmware Missing from recent live builds (I think due to usr transition)

[Brandon Werner]

package: live-build
version: 1:20230502

I noticed that in recent weekly builds, many firmware packages are missing from 
the live desktop images. I believe that the problem is in this file 
https://salsa.debian.org/live-team/live-build/-/blob/master/functions/firmwarelists.sh.
 Its logic depends on firmware being in /lib/firmware, however, firmware has 
moved as a part of the usr transition to /usr/lib/firmware. I didn't have a 
chance to test, however, it seems likely that updating this path to 
/usr/lib/firmware in that file would get detection for firmware packages 
working again.

Bug#1058572: [pkg-gnupg-maint] Bug#1058572: Bug#1058572: gnupg2.4: fail to initialize homedir and generate key due to keyboxd

[Werner Koch]

Hi!

On Fri, 15 Dec 2023 09:22, NIIBE Yutaka said:

> is created.  Note that keyboxd just works with systemd by socket
> activation.

Why do you think so.  keyboxd is started on demand by gpg or gpgsm.
There is no --supervised option as we still have for dirmngr and
gpg-agent.

In case Debian added this option this will the cause of the problem
because two keyboxd might show up and one takes the database lock.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature

Bug#1041681: Solution: Clear Django Static Files Cache

[Tilo Werner]

See: https://gitlab.com/mailman/django-mailman3/-/issues/68#note_1662411617




--
mail t...@moosbee.de
xmpp t...@moosbee.de
gpgp https://moosbee.de/tilo/pub.asc

.~°*._.*°~.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041681: Confirmation

[Tilo Werner]

I can confirm this bug. The admin interface is unusable, so it's not 
possible to change or add a new site, which in turn renders the whole 
installation unusable.


Please fix, thanks!


--
mail t...@moosbee.de
xmpp t...@moosbee.de
gpgp https://moosbee.de/tilo/pub.asc

.~°*._.*°~.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055541: In Trixie, /etc/localtime incorrectly set to UTC in some cases due to the installer including mappings to removed legacy timezones

[Brandon Werner]

package: tzsetup

In bug #1040997 legacy symlinks were moved out of the tzdata package to 
tzdata-legacy. The "post-base-installer.d/05tzsetup" script does not set the 
/etc/localtime symlink because db_get is returning these legacy time zones that 
no longer exist in the tsdata package.

I think the fix is to modify the mappings in debian/common.templates.in to 
remove the legacy time zones and replace them with the versions shipped in the 
new version of tzdata.

Bug#1039883: The issue impacts SSD disks as well

[Hervé Werner]

Hello

I'm sorry for the delay.

> Are you able to reliably preoeduce the issue and can bisect it to the 
> introducing commit?
I faced this issue on real data but I struggled to find a reliable scenario to 
reproduce it. Here is what I just came up with:
  sudo mkfs -t ext4 -O fast_commit,inline_data /dev/sdb
  sudo mount /dev/sdb /mnt/
  sudo install -d -o myuser /mnt/annex
  cd /mnt/annex
  git init && git annex init
  for i in {1..2}; do
for i in {1..1}; do
  dd if=/dev/urandom of=file-${i} bs=1K count=1 2>/dev/null
done
git annex add -J cpus . >/dev/null && git annex sync -J cpus && git annex 
fsck -J cpus >/dev/null
git rm * && git annex sync  && git annex dropunused all
  done

Then at some point the following error appears:
  EXT4-fs error (device sdb): ext4_map_blocks:577: inode #3942343: block 4: 
comm git-annex:w: lblock 1 mapped to illegal pblock 4 (length 1)

Some observations:
  - Contrary to what I implied in my first message, using the option 
inline_data alone doesn't seem to trigger the error.
  - Working with less than 10K files doesn't seem to trigger the error
  - Sometimes the commands just run fine that's why I run the whole thing twice
  - I also tried with various file size, in particular 1B, but it does not seem 
to have any impact
  - The disk I was using is a 5400RPM HDD

I'm running the kernel 6.5.0-3-amd64.
I'm also getting this issue on Debian stable's kernel (6.1.0-13-amd64) so I'm 
not aware of any working kernel version.

Regards
Hervé

Bug#1055353: Debian installer not setting locale in Trixie daily builds

[Brandon Werner]

On Sat, Nov 4, 2023, at 2:27 PM, Brandon Werner wrote:
> 
> 
> Hi,
> After installing via the daily images, my locale isn't set. I took a brief 
> look, and my best guess is the trouble is being caused in the file 
> post-base-installer.d/05localechooser. There, I noticed
> "DESTFILE="/target/etc/default/locale"".
> I believe this file was retired recently in Debian.
I tried a reinstall, changing the above line to
"DESTFILE="/target/etc/locale.conf""
in the installer after I booted the daily netinst, and my locale was set in the 
installed system

Bug#1055353: Debian installer not setting locale in Trixie daily builds

[Brandon Werner]

package: locale-chooser

Hi,
After installing via the daily images, my locale isn't set. I took a brief 
look, and my best guess is the trouble is being caused in the file 
post-base-installer.d/05localechooser. There, I noticed
"DESTFILE="/target/etc/default/locale"".
I believe this file was retired recently in Debian.

If I manually set my locale in /etc/locale.conf, things work as expected.

Bug#1053531: [pkg-gnupg-maint] Bug#1053531: gnupg/gpg-agent/pinentry: timeout

[Werner Koch]

Hi Thorsten,

> distracted by being asked a question, and it had terminated the
> pinentry and agent, asking me for a password on stderr/tty without
> pinentry, but as soon as I went to type it there, it ended up with:

The second one is the usual ssh prompt in a failed ssh-agent.

> IMHO the pinentry form shouldn’t time out (or at least be reasonable
> about it, e.g. time out after one hour, at the earliest, or so).

Put a pinentry-timeout into gpg-agent.conf

--pinentry-timeout n

   This option asks the Pinentry to timeout after n seconds with no user
   input.  The default value of 0 does not ask the pinentry to timeout,
   however a Pinentry may use its own default timeout value in this
   case.  A Pinentry may or may not honor this request.

The default is 60 seconds, iirc. No timeout is not a good idea either
because you will run into a related problem when you request a second
action requiring a pinentry - that will then wait for the already open
pinentry somewhere on another desktop.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature

Bug#1053484: tclodbc: Off-by-one error in SQLDescribeParam() call

[Christian Werner]

Package: tclodbc
Version: any
Severity: important
X-Debbugs-Cc: christian.wer...@t-online.de

Dear Maintainer,

according to its description, the SQLDescribeParam() ODBC API counts
the parameter numbers starting with 1. However, in the statemnt.cxx
a loop over the parameters of a query is run starting with 0 as
parameter number. In consequence, data type mapping of the client
parameters to the query might become wrong heavily depending on the
actual query itself. Problem can be easily resolved by changing

 SQLDescribeParam(..., i, ...);

to

 SQLDescribeParam(..., i+1, ...);

BR,
Christian

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

Kernel: Linux 5.10.0-25-amd64 (SMP w/4 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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tclodbc depends on:
ii  libc62.31-13+deb11u6
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libgcc1  1:8.3.0-6
ii  libodbc1 2.3.6-0.1+b1
ii  libstdc++6   10.2.1-6
ii  odbcinst1debian2 2.3.6-0.1+b1
ii  tcl  8.6.11+1

tclodbc recommends no packages.

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: I volunteer to maintain GnuPG and friends in the long-term

[Werner Koch]

Hi!

On Thu, 27 Jul 2023 15:24, NIIBE Yutaka said:

> - ... and default keyserver choice:
>   debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch

FWIW, if you need to change the default, the proper location is
/etc/gnupg/dirmngr.conf and not a source code patch.

> - And for the specific keyserver, there are local changes:
>   debian/patches/import-merge-without-userid/

Which breaks the gnupg policy and are harmful for the entire ecosystem.
There is a reason that we we use a syncing keyserver instead of the x-th
attempt to for a "verifying" keyserver onto PGP users.

> - Upstream deprecates systemd support, which was originally introduced
>   in Debian version.  Perhaps, we will need a Debian local patch for
>   this.

The problem here is that GnuPG has its own way to start its agents.
Using systemd activation here introduces races because you can't have
two (advisory) locking systems where each does not know about the other.
For an engineering POV we can't switch to socket activation for
portability reasons.  Keep in mind that the heaviest desktop users of
gpg are on Windows and we tried hard to keep changes as small as
possible.  That benefits all users: On Linux, AIX, *BSD and Windows.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein


openpgp-digital-signature.asc
Description: PGP signature

Bug#1039883: The issue impacts SSD disks as well

[Hervé Werner]

I've just faced this issue on the SSD disk as well, so it seems that the 
probability is just lower on a speedier disk.

Bug#986821: freecad: Garbled menu makes freecad unusable

[Werner Mayer]

Hi tobi,


It is still garbled when running it with QT_SCALE_FACTOR=0.9

Setting a value < 1 doesn't only cause problems with FreeCAD but with
other Qt applications, too.

For example, Qt Designer's user interface is completely garbled, not
only the menus. For other Qt based applications (assistant, linguist,
cmake-gui, vlc) it doesn't look much better.

So, there are two causes to get a garbled user interface:

* Changing the DPI value of the system. This is fixed with the
suggestion of my last mail.
Alternatively, this can be tested by setting the environment variable
QT_FONT_DPI (e.g. QT_FONT_DPI=80)

* Setting a value < 1 for QT_SCALE_FACTOR. This is not specific to
FreeCAD but is a general Qt issue that affects many other applications.

BR,
Werner

Bug#1021112:

[Marcus Werner]

Dear maintainer,

I've the same bug in debian bullseye, evolution 3.38.3-1+deb11u1 ,
Workaround to read my mails : Open it as "Als neue Nachricht
bearbeiten" (Edit as new message)

kind regards
M.WER

Bug#986821: freecad: Garbled menu makes freecad unusable

[Werner Mayer]

Hi everybody,

I have tested it on my XFCE system to decrease the DPI value to e.g. 80
and then I can confirm that FreeCAD's menus and toolbars are unusable.
Looking through the code I found this line

QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);

After commenting it out the problem is gone.

The line once has been added with
https://github.com/FreeCAD/FreeCAD/pull/4605 and is supposed to fix a
scaling problem on Windows.

As a proper fix I suggest to enable this line for Windows only:

#if QT_VERSION >= QT_VERSION_CHECK(5,14,0) && defined(Q_OS_WIN)
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);
#endif



Btw, FreeCAD built with Qt6 doesn't seem to suffer from this problem.

I hope this helps.

BR,
Werner

Bug#1029846: freecad: after upgrading today, not possible to launch the program

[Werner Mayer]

Dear all,

a proper fix has been added with
https://github.com/FreeCAD/FreeCAD/commit/c7a21ecbeecefe7c2dfc9e950b3d6bb42351d476
This means that the function PyConfig_InitPythonConfig must be replaced
with PyConfig_InitIsolatedConfig.

The error occurred because PyConfig_InitPythonConfig parses all program
arguments while the latter method doesn't. So far only builds with
Python 3.11 or higher are affected.

BR,
Werner

Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included

[Brandon Werner]

On Mon, Feb 6, 2023, at 7:34 AM, Cyril Brulebois wrote:
>
> That's not to say I won't try and get a tentative patch before then…
> Would you be happy to test a custom netinst that I would build locally
> (i.e. outside cdimage.debian.org and the official infrastructure)?

I'd be happy to test an image you build locally on your machine to streamline 
the testing process. 

Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included

[Brandon Werner]

On Mon, Feb 6, 2023, at 5:33 AM, Cyril Brulebois wrote:
> Hi Brandon,
>
> Brandon Werner  (2023-02-06):
>> Thanks for your response. I have included the syslog lines from the
>> installer log you requested.
>
> OK, that's basically what I thought was happening, but it's always a
> good idea to check a hypothesis before deciding what to do about it. :)
>
> I think I might have mentioned the following in some discussion, or
> in some commit, but basically:
>  - we have a list of requested files;
>  - we have a list of requesting modules;
>  - some modules get reloaded.
>
> If we maintain a module/file mapping, we could:
>  - decide which modules need to be reloaded, instead of iterating on all
>of them (that's part of the reason why I had this idea in mind in the
>first place, looking around how to “reload dance” was implemented:
>walking through all modules unconditionally);
>  - decide that a module is “good to go” as soon as it's been reloaded
>once, i.e. some of the files it requested have been found.
>
> The second part would make the point about “required” vs. “optional”
> firmware moot, and would prevent extra dialogs. One could argue that
> maybe some other *.deb somewhere could be more recent or could have
> extra files, but then we don't implement anything when it comes to
> multiplicity anyway, so that wouldn't be a regression.
>
> Alternatively, we could keep the unconditionally reload dance, while
> still keeping track of files requested by each module over time.
> When the list gets smaller, its files start getting ignored.
>
>
> Does that make sense to you?
This makes sense, and both solutions seem like they would work. It seems like 
the second solution of keeping the unconditional reload and testing if the list 
of files was smaller after the reload would be easier to implement for 
Bookworm, but I think you and the rest of the installer team are better 
informed to make that decision. :)
I think assuming the module is working if the list of requested files is 
smaller after a reload is a fairly safe bet for network hardware, but If the 
installer team implemented either of these solutions, I could test on a bunch 
of old and new machines that are available at a computer club I attend. I 
unfortunately don't feel like I personally understand the installer well enough 
to fix this properly, and any merge request I would create would be a sad hack. 
Hopefully many folks will be testing Alpha 2 of Bookworm as well, to find any 
problems that would result from a change like this.

Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included

[Brandon Werner]

On Mon, Feb 6, 2023, at 4:36 AM, Cyril Brulebois wrote:
> Hi Brandon,
>
> Brandon Werner  (2023-02-05):
>> I saw the recent work to the installer surrounding firmware handling
>> and thought I would test on my machines to see how this all was
>> working. I used one of the daily sid_d-i netinst cds including
>> firmware. I noticed some problems around the installer asking for
>> firmware that was not neded for ath10k. I first tried on a laptop that
>> had QCA-6174 hw2.1. I noticed the prompt telling me about missing
>> firmware and asking if I wanted to load it from additional media,
>> which was puzzling for the firmware image. If I select no, the
>> installer continues, however, I thought this  could confuse users, so
>> I dug into it.
>
> Thanks for the tests and the report.
>
>> Before firmware atheros was loaded, the kernel tried to load versions
>> 6 through 2 of the firmware files as well as calibration firmware
>> files. After firmware atheros was installed, the card was brought up,
>> and this time, only three files were missing. The cal and pre-cal
>> files appear to be optional according to the driver source, and do not
>> exist in linux-firmware upstream, so I think them missing is no
>> problem. Firmware ver 6 doesn't exist yet in the upstream Linux repo
>> so maybe this is in the driver for future use? I guess the installer
>> still thinks there is missing firmware because of the kernel failing
>> to load these 3 unnecessary files. After version 5 of the firmware was
>> found, the kernel stopped trying to load versions 4 3 2, so there was
>> many fewer missing files on the second run of check-missing-firmware.
>
> We would need to see more of your log file. It starts with mainloop
> iteration #1, while the first check_missing call has happened already.

Thanks for your response. I have included the  syslog lines from the installer 
log you requested.

Feb  5 10:35:26 check-missing-firmware: looking at dmesg for the first time
Feb  5 10:35:26 check-missing-firmware: saving timestamp for a later use: [   
57.345819]
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/pre-cal-pci-:01:00.0.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/pre-cal-pci-:01:00.0.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/cal-pci-:01:00.0.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/cal-pci-:01:00.0.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-6.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-5.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-5.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-4.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-4.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-3.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-3.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-2.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: looking for firmware file 
ath10k/QCA6174/hw2.1/firmware-2.bin requested by ath10k_pci
Feb  5 10:35:26 check-missing-firmware: missing firmware files 
(ath10k/pre-cal-pci-:01:00.0.bin ath10k/pre-cal-pci-:01:00.0.bin 
ath10k/cal-pci-:01:00.0.bin ath10k/cal-pci-:01:00.0.bin 
ath10k/QCA6174/hw2.1/firmware-6.bin ath10k/QCA6174/hw2.1/firmware-6.bin 
ath10k/QCA6174/hw2.1/firmware-5.bin ath10k/QCA6174/hw2.1/firmware-5.bin 
ath10k/QCA6174/hw2.1/firmware-4.bin ath10k/QCA6174/hw2.1/firmware-4.bin 
ath10k/QCA6174/hw2.1/firmware-3.bin ath10k/QCA6174/hw2.1/firmware-3.bin 
ath10k/QCA6174/hw2.1/firmware-2.bin ath10k/QCA6174/hw2.1/firmware-2.bin) for 
ath10k_pci
Feb  5 10:35:26 check-missing-firmware: mainloop iteration #1
Feb  5 10:35:26 check-missing-firmware: lookup with 
/cdrom/firmware/Contents-firmware
Feb  5 10:35:26 check-missing-firmware: installing firmware package 
/cdrom/firmware/firmware-atheros_20221214-5_all.deb (non-free-firmware)
Feb  5 10:35:28 check-missing-firmware: removing and loading kernel module 
ath10k_pci
Feb  5 10:35:28 kernel: [   60.711599] D

Bug#1030636: Debian Installer complains about missing firmware in ath10k, even when using image with firmware included

[Brandon Werner]

package: hw-detect
version: 1.154

Hello,
I saw the recent work to the installer surrounding firmware handling and 
thought I would test on my machines to see how this all was working. I used one 
of the daily sid_d-i netinst cds including firmware. I noticed some problems 
around the installer asking for  firmware that was not neded for ath10k. I 
first tried on a laptop that had QCA-6174 hw2.1. I noticed the prompt telling 
me about missing firmware and asking if I wanted to load it from additional 
media, which was puzzling for the firmware image. If I select no, the installer 
continues, however, I thought this  could confuse users, so I dug into it.

Before firmware atheros was loaded, the kernel tried to load versions 6 through 
2 of the firmware files as well as calibration firmware files. After firmware 
atheros was installed, the card was brought up, and this time, only three files 
were missing. The cal and pre-cal files appear to be optional according to the 
driver source, and do not exist in linux-firmware upstream, so I think them 
missing is no problem. Firmware ver 6 doesn't exist yet in the upstream Linux 
repo so maybe this is in the driver for future use? I guess the installer still 
thinks there is missing firmware because of the kernel failing to load these 3 
unnecessary files. After version 5 of the firmware was found, the kernel 
stopped trying to load versions 4 3 2, so there was many fewer missing files on 
the second run of check-missing-firmware.

I have another laptop with hw3.2 of QCA-6174 and on that machine, only pre-cal 
and cal are missing after firmware-atheros is loaded by the installer. I looked 
at hw-detect, and noticed there was a section in check-missing-firmware.sh 
ignoreing intel wifi debugging firmware, but I think trying to ignore all the 
correct files in that location might be a bit tricky, especially if other net 
drivers try to load optional firmware. It also seems possible that the PCI IDs 
searched by the driver could be different for cal and pre-cal for different 
ath10k hardware although I didn't dig into this. I hope the information I 
provided is enough for package maintainers to determine a correct solution. 
Thanks for all the great work on the installer recently to make  firmware 
handling work better.

Below, a bit of text from the installer log, to show the driver is loading, but 
the installer still thinking there is missing firmware.

Feb  5 10:35:26 check-missing-firmware: mainloop iteration #1
Feb  5 10:35:26 check-missing-firmware: lookup with 
/cdrom/firmware/Contents-firmware
Feb  5 10:35:26 check-missing-firmware: installing firmware package 
/cdrom/firmware/firmware-atheros_20221214-5_all.deb (non-free-firmware)
Feb  5 10:35:28 check-missing-firmware: removing and loading kernel module 
ath10k_pci
Feb  5 10:35:28 kernel: [   60.711599] DMAR: DRHD: handling fault status reg 2
Feb  5 10:35:28 kernel: [   60.711605] DMAR: [DMA Write NO_PASID] Request 
device [01:00.0] fault addr 0x7ee0 [fault reason 0x05] PTE Write access is 
not set
Feb  5 10:35:28 kernel: [   60.711661] ath10k_pci :01:00.0: pci irq msi 
oper_irq_mode 2 irq_mode 0 reset_mode 0
Feb  5 10:35:28 kernel: [   60.977712] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/pre-cal-pci-:01:00.0.bin (-2)
Feb  5 10:35:28 kernel: [   60.977724] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/pre-cal-pci-:01:00.0.bin (-2)
Feb  5 10:35:28 kernel: [   60.977735] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/cal-pci-:01:00.0.bin (-2)
Feb  5 10:35:28 kernel: [   60.977744] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/cal-pci-:01:00.0.bin (-2)
Feb  5 10:35:28 kernel: [   60.977755] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2)
Feb  5 10:35:28 kernel: [   60.977762] ath10k_pci :01:00.0: firmware: 
failed to load ath10k/QCA6174/hw2.1/firmware-6.bin (-2)
Feb  5 10:35:28 kernel: [   60.977973] ath10k_pci :01:00.0: firmware: 
direct-loading firmware ath10k/QCA6174/hw2.1/firmware-5.bin
Feb  5 10:35:28 kernel: [   60.977980] ath10k_pci :01:00.0: qca6174 hw2.1 
target 0x0501 chip_id 0x003405ff sub 144d:4125
Feb  5 10:35:28 kernel: [   60.977986] ath10k_pci :01:00.0: kconfig debug 0 
debugfs 0 tracing 0 dfs 0 testmode 0
Feb  5 10:35:28 kernel: [   60.978697] ath10k_pci :01:00.0: firmware ver 
SW_RM.1.1.1-00157-QCARMSWPZ-1 api 5 features ignore-otp,no-4addr-pad crc32 
10bf8e08
Feb  5 10:35:28 kernel: [   61.040011] ath10k_pci :01:00.0: firmware: 
direct-loading firmware ath10k/QCA6174/hw2.1/board-2.bin
Feb  5 10:35:28 kernel: [   61.040387] ath10k_pci :01:00.0: board_file api 
2 bmi_id N/A crc32 ae2e275a
Feb  5 10:35:29 check-missing-firmware: looking at dmesg again, restarting from 
timestamp: [   57.345819]
Feb  5 10:35:29 check-missing-firmware: timestamp found, truncating dmesg 
accordingly
Feb  5 10:35:29 check-missing-firmware: saving timestamp for a 

Bug#1023330: ghostscript-x: No X11 devices are available even though ghostscript-x is installed

[Werner Frey]

Package: ghostscript-x
Version: 10.0.0~dfsg-6
Followup-For: Bug #1023330

Dear Maintainer,

   * What led up to the situation?
 Automatic update of package ghostscript to version 10.0.0~dfsg-6
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Reinstalling ghostscript and ghostscript-x didn't solve the problem
   * What was the outcome of this action?
 Still no output to X11 devices. Packages 'flpsed' and 'gv' are broken.

$ gs -h
GPL Ghostscript 10.00.0 (2022-09-21)
Copyright (C) 2022 Artifex Software, Inc.  All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
 -dNOPAUSE   no pause after page   | -q   `quiet', fewer messages
 -gx  page size in pixels   | -r  pixels/inch resolution
 -sDEVICE=  select device | -dBATCH  exit after last file
 -sOutputFile= select output file: - for stdout, |command for pipe,
 embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PostScriptLevel3 PDF
Default output device: bbox
Available devices:
   alc1900 alc2000 alc4000 alc4100 alc8500 alc8600 alc9100 ap3250 appledmp
   appleraster atx23 atx24 atx38 bbox bit bitcmyk bitrgb bitrgbtags bj10e
   bj10v bj10vh bj200 bjc600 bjc800 bjc880j bjccmyk bjccolor bjcgray bjcmono
   bmp16 bmp16m bmp256 bmp32b bmpgray bmpmono bmpsep1 bmpsep8 ccr cdeskjet
   cdj1600 cdj500 cdj550 cdj670 cdj850 cdj880 cdj890 cdj970 cdjcolor cdjmono
   cdnj500 cfax chp2200 cif cljet5 cljet5c cljet5pr coslw2p coslwxl cups
   declj250 deskjet devicen dfaxhigh dfaxlow display dj505j djet500 djet500c
   dl2100 dnj650c epl2050 epl2050p epl2120 epl2500 epl2750 epl5800 epl5900
   epl6100 epl6200 eplcolor eplmono eps2write eps9high eps9mid epson epsonc
   escp escpage faxg3 faxg32d faxg4 fmlbp fmpr fpng fs600 gdi hl1240 hl1250
   hl7x0 hpdj1120c hpdj310 hpdj320 hpdj340 hpdj400 hpdj500 hpdj500c hpdj510
   hpdj520 hpdj540 hpdj550c hpdj560c hpdj600 hpdj660c hpdj670c hpdj680c
   hpdj690c hpdj850c hpdj855c hpdj870c hpdj890c hpdjplus hpdjportable ibmpro
   ijs imagen inferno ink_cov inkcov itk24i itk38 iwhi iwlo iwlq jetp3852
   jj100 jpeg jpegcmyk jpeggray la50 la70 la75 la75plus laserjet lbp310
   lbp320 lbp8 lex2050 lex3200 lex5700 lex7000 lips2p lips3 lips4 lips4v
   lj250 lj3100sw lj4dith lj4dithp lj5gray lj5mono ljet2p ljet3 ljet3d ljet4
   ljet4d ljet4pjl ljetplus ln03 lp1800 lp1900 lp2000 lp2200 lp2400 lp2500
   lp2563 lp3000c lp7500 lp7700 lp7900 lp8000 lp8000c lp8100 lp8200c lp8300c
   lp8300f lp8400f lp8500c lp8600 lp8600f lp8700 lp8800c lp8900 lp9000b
   lp9000c lp9100 lp9200b lp9200c lp9300 lp9400 lp9500c lp9600 lp9600s
   lp9800c lps4500 lps6500 lq850 lxm3200 lxm5700m m8510 md1xMono md2k
   md50Eco md50Mono md5k mgr4 mgr8 mgrgray2 mgrgray4 mgrgray8 mgrmono miff24
   mj500c mj6000c mj700v2c mj8000c ml600 necp6 npdl nullpage oce9050 oki182
   oki4w okiibm oprp opvp paintjet pam pamcmyk32 pamcmyk4 pbm pbmraw pcl3
   pclm pclm8 pcx16 pcx24b pcx256 pcxcmyk pcxgray pcxmono pdfimage24
   pdfimage32 pdfimage8 pdfwrite pdfwrite pdfwrite pgm pgmraw pgnm pgnmraw
   photoex picty180 pj pjetxl pjxl pjxl300 pkm pkmraw pksm pksmraw plan
   plan9bm planc plang plank planm plib plibc plibg plibk plibm png16 png16m
   png16malpha png256 png48 pngalpha pnggray pngmono pngmonod pnm pnmraw ppm
   ppmraw pr1000 pr1000_4 pr150 pr201 ps2write psdcmyk psdcmyk16 psdcmykog
   psdcmyktags psdcmyktags16 psdrgb psdrgb16 pwgraster pxlcolor pxlmono
   r4081 rinkj rpdl samsunggdi sj48 spotcmyk st800 stcolor t4693d2 t4693d4
   t4693d8 tek4696 tiff12nc tiff24nc tiff32nc tiff48nc tiff64nc tiffcrle
   tiffg3 tiffg32d tiffg4 tiffgray tifflzw tiffpack tiffscaled tiffscaled24
   tiffscaled32 tiffscaled4 tiffscaled8 tiffsep tiffsep1 txtwrite uniprint
   urf xcf xcfcmyk xes xpswrite
Search path:
   /usr/share/ghostscript/10.00.0/Resource/Init :
   /usr/share/ghostscript/10.00.0/lib :
   /usr/share/ghostscript/10.00.0/Resource/Font :
   /usr/share/ghostscript/fonts : /var/lib/ghostscript/fonts :
   /usr/share/cups/fonts : /usr/share/ghostscript/fonts :
   /usr/local/lib/ghostscript/fonts : /usr/share/fonts
Ghostscript is also using fontconfig to search for font files
For more information, see /usr/share/doc/ghostscript/Use.htm.
On debian system you may need to install ghostscript-doc package.
Please report bugs to bugs.ghostscript.com.
$

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

Kernel: Linux 5.10.153.x86-64 (SMP w/2 CPU threads)
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 ghostscript-x depends on:
ii  ghostscript  10.0.0~dfsg-6
ii  libc62.36-4
ii  libx11-6 2:1.8.1-2
ii  libxt6   1:1.2.1-1

ghostscript-x recommends no 

Bug#1023952: libfluidsynth-dev: Package should not depend on libsystemd-dev and/or libsystemd0

[Joe Werner]

Package: libfluidsynth-dev
Version: 2.3.0-1
Severity: important
X-Debbugs-Cc: j...@pro-kevin.de

Dear Maintainer,

the package depends on systemd, which (seems) not strictly neccessary, nor 
would it be wanted by several people (myself included - hence the bug report). 
I know the subject is a potential minefield and I do not wish to open the old 
discussions again[*]

Problem: When installing libsdl-mixer2-dev (to build some software) it pulls in 
libfluidsynth-dev. This depends on libsystemd-dev and libsystemd0 - and this in 
turn collides with liblogind-compat.
This makes it difficult to develop (or test) said software on 
non-systemd-systems.

To remedy I did this:
- Got the source via apt-get
- removed systemd-dependencies from debian/control (very ham-fisted, I know)
- rebuilt package and installed it

Apparently this works, at least the software (Widelands) compiled against this 
new package works. Thus my guess is that the whole of systemd is not needed 
here, and it could be remedied with dependencies on alternative packages (like 
liblogind-compat, maybe?).

Cheers,
Joe

[*] And I am very grateful to all developers and maintainers, and submit this 
with the utmost respect for your work.


-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages libfluidsynth-dev depends on:
ii  libasound2-dev1.2.7.2-1
ii  libdbus-1-dev 1.14.4-1devuan1
ii  libfluidsynth32.3.0-1
ii  libinstpatch-dev  1.1.6-1
ii  libjack-jackd2-dev [libjack-dev]  1.9.21~dfsg-1
ii  libpulse-dev  16.1+dfsg1-2+b1
ii  libreadline-dev   8.2-1
ii  libsdl2-dev   2.24.1+dfsg-1
ii  libsndfile1-dev [libsndfile-dev]  1.1.0-3+b1

libfluidsynth-dev recommends no packages.

libfluidsynth-dev suggests no packages.

-- no debconf information

Bug#980838: [pkg-gnupg-maint] Bug#980838: scdaemon

[Werner Koch]

On Mon, 31 Jan 2022 09:52, Christian Weiske said:

> Jan 30 07:39:51 dojo systemd[1076614]: gpgconf: Fehler bei Ausführung
> von `/usr/lib/gnupg/scdaemon': wahrscheinlich nicht installiert

Put

disable-scdaemon

into gpg-agent.conf


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#949761: [pkg-gnupg-maint] Bug#949761: gpgconf: make socketdir configurable to users

[Werner Koch]

On Tue, 21 Dec 2021 15:17, NIIBE Yutaka said:

>> gpg2 and gpg-agent (used by gnupg (1.x) as well) now uses
>> GPG_AGENT_INFO=/run/user/2339/gnupg/S.gpg-agent:0:1 but
>> the directory /run/user/2339 is removed on logout by elogind
>> even if processes are still running.
>
> I happened to find a possible solution for this problem, if a user uses
> systemd.

Another solution is to run

  touch /var/lib/elogin/linger/$(id -un)

once to more or less get standard Unix semantics back.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#1001331: [pkg-gnupg-maint] Bug#1001331: gpg: Provide interface to inspect (detached) signatures

[Werner Koch]

Hi!

> I cannot stop using as I do not know of a publicly supported interface
> to inspect a (detached) signature to get its issuer fingerprint or
> keyid.

You can do this:

  gpg --verify --status-fd 1 x.asc /dev/null 2>/dev/null \
| awk '$1=="[GNUPG:]" && $2=="BADSIG" { print $3}'

which greps for 

[GNUPG:] BADSIG 19CC1C9E085B107A w...@gnupg.org

This shows the keyid but not the newer fingerprint.  Adding something
for the fingerprint would be easy, but it takes some time before it will
be widely enough deployed.  


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#999906: bugs.debian.org: After upgrade to Debian Bullseye, I am not able to burn DVDs.

[Werner]

Package: bugs.debian.org
Severity: important
X-Debbugs-Cc: w_t...@t-online.de

Dear Maintainer,



   * What led up to the situation?
Upgrade from buster to bullseye

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Changed the sources-list, update/upgrade/dist-upgrade

   * What was the outcome of this action?
All burning programs k3b, xfburn, xorriso ignore manual setting of burning
speed
and uses max speed. After burning is complete the software gives an error and
the DVD is not useable.

   * What outcome did you expect instead?
Respect setting manual speed and a functional DVD.

Bug#990761: Sorry to early

[Marcus Werner]

I just tested the behaviour again under wayland: Because of trouble
with another programm I switched these days to Gnome under XOrg
and have forgotten this. Here Evolution runs fine. In Wayland I have
the same bug as before, segfault on start.

So the bug is half alive :(

Bug#990761: Bug is gone

[Marcus Werner]

After some updates (I did not test it on every update) the bug has gone
on 12.7.2021, evolution now starts and works fine.

Please close the Bug ;)!

Bug#990761: evolution crash (segfault) on startup without error msg

[Marcus Werner]

Package: evolution
Version: 3.38.3-1
Severity: normal
X-Debbugs-Cc: bugrep...@holozone.de

(amdgpu-pro installed from amd.com, but everything else runs fine)

Starting program: /usr/bin/evolution
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeb3ac700 (LWP 11754)]
[New Thread 0x7fffeabab700 (LWP 11755)]
[New Thread 0x7fffea373700 (LWP 11756)]
[New Thread 0x7fffe9b61700 (LWP 11757)]

Thread 1 "evolution" received signal SIGSEGV, Segmentation fault.
0x72532903 in XAddExtension () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0  0x72532903 in XAddExtension () at /lib/x86_64-linux-gnu/libX11.so.6
#1  0x7fffd1d5f517 in  () at /usr/lib/x86_64-linux-gnu/dri/amdgpu_dri.so
#2  0x7fffd1d63fd9 in eglInitialize () at /usr/lib/x86_64-linux-
gnu/dri/amdgpu_dri.so
#3  0x7fffef4a7d85 in  () at /lib/x86_64-linux-gnu/libcogl.so.20
#4  0x7fffef4a3f15 in  () at /lib/x86_64-linux-gnu/libcogl.so.20
#5  0x7fffef4597d7 in cogl_renderer_connect () at /lib/x86_64-linux-
gnu/libcogl.so.20
#6  0x7fffef554f82 in  () at /lib/x86_64-linux-gnu/libclutter-1.0.so.0
#7  0x7fffef56e7c3 in  () at /lib/x86_64-linux-gnu/libclutter-1.0.so.0
#8  0x7fffef57f58a in  () at /lib/x86_64-linux-gnu/libclutter-1.0.so.0
#9  0x73ae4a46 in  () at /lib/x86_64-linux-gnu/libclutter-gtk-1.0.so.0
#10 0x77210278 in g_option_context_parse () at /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#11 0x73ae4bc1 in gtk_clutter_init_with_args () at /lib/x86_64-linux-
gnu/libclutter-gtk-1.0.so.0
#12 0x8994 in main ()


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/32 CPU threads)
Kernel taint flags: 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 evolution depends on:
ii  dbus   1.12.20-2
ii  evolution-common   3.38.3-1
ii  evolution-data-server  3.38.3-1
ii  libc6  2.31-12
ii  libcamel-1.2-623.38.3-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.38.3-1
ii  libedataserver-1.2-25  3.38.3-1
ii  libevolution   3.38.3-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4
ii  libical3   3.0.9-2
ii  libnotify4 0.7.9-3
ii  libsoup2.4-1   2.72.0-2
ii  libwebkit2gtk-4.0-37   2.32.1-2
ii  libxml22.9.10+dfsg-6.7
ii  psmisc 23.4-2

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.38.3-1
ii  evolution-plugin-pstimport   3.38.3-1
ii  evolution-plugins3.38.3-1
ii  yelp 3.38.3-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.27-2
ii  network-manager 1.30.0-2

Bug#986230: davfs2: After silent crash of mount.davfs background process, accessing user space program hangs busy

[Werner Baumann]

When the userspace daemon mount.davfs dies before the file system is
unmounted, then the kernel file system fuse will hang forever and it is
not possible to normally unmount. I think this is a bug in fuse and
filed a report to the kernel bug tracker long ago.
https://bugzilla.kernel.org/show_bug.cgi?id=115971
There is always a chance that a userspace process crashes. So the kernel
should be able to handle this gracefully.

The other question is why mount.davfs crashed?

- Is the problem reproducible and can you test whether it only happens
  when managed by systemd?

- mount.davfs may crash silently when it runs out of memory. For every
  file (or directory) it gets to know of it will require about 200 to
  300 bytes of working memory and it will not free any of it before it
  terminates.

- When mount.davfs is stopped with signal SIGTERM or SIGHUB there
  should be a message in daemon.log.

- You could use the debug options to get a lot of debug messages in
  daemon.log which might show at what action the daemon dies. These
  logs may get very lengthy. Option "debug kernel" and "debug cache"
  could be a start.

Werner

Bug#985337: davfs: mount.davfs fails on x-systemd.after=... option in /etc/fstab

[Werner Baumann]

I would prefer to report an error on unknown options to inform the user
about the error. But with fstab there are options that davfs2 has to
ignore because they may be required for other programs. To ignore some
options (but not all) the C-functions used by davfs2 to parse the
options would require a list of the options to ignore. With these
x-something kind of options, whose number may grow indefinitely, this is
no longer possible.
For this reason I gave up. davfs2 will now ignore all unknown options.
The change is in the CVS-sources and will make it into the next release.

Werner

Bug#985158: [pkg-gnupg-maint] Bug#985158: Bug#985158: Bug#985158: gpg: No longer reads .gnupg/options

[Werner Koch]

On Sun, 14 Mar 2021 14:32, Christoph Biedl said:

> Point is, the legacy file ~/.gnupg/options is still being used in
> surprisingly many applications, also in documentation:

Then please file a bug against such documentation.  And maybe even
against any application which read the option filre directly, that is
without using gpgconf.

> https://codesearch.debian.net/search?q=.gnupg%2Foptions=1

Look at the code shown tehre: Almost everywhere it is used as a fallback
from gpg.conf.

> In Debian, revert that commit, and emit a deprecation warning if the
> legacy file is parsed.

Sysadmins will kill you if you do that.  The global conf file has been a
long standing request from many parties.  It comes very hadny for large
installations because it can be used to enforce options on users.  That
is why I took the trouble to actually backported this from master.

Supporting the legacy option file would be a Bad Idea.  In particular
for a new major release it should be not a problem to add release notes
mention that after 18 years the deprecated legacy option file is not
anymore supported.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#985158: [pkg-gnupg-maint] Bug#985158: gpg: No longer reads .gnupg/options

[Werner Koch]

On Sat, 13 Mar 2021 20:40, Kurt Roeckx said:

> It seems that the config file ~/.gnupg/options is no longer read,
> and it's now reading (among others) ~/.gnupg/gpg.conf

Oops. I totally forgot about this this legacy file.  The reason for this
is that we switched to a new option parser which also features global
config files.

Right, that should not have happened.  Fixing this if complicated and
thus I would suggest to use a symlink or way better to get rename the
file.

This 19 year old NEWS entry gives some historic background:

Noteworthy changes in version 1.1.92 (2002-09-11)
-

* [IMPORTANT] The default configuration file is now
  ~/.gnupg/gpg.conf.  If an old ~/.gnupg/options is found it will
  still be used.  This change is required to have a more
  consistent naming scheme with forthcoming tools.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#980768: [pkg-gnupg-maint] Bug#980768: gnupg2: reduce Build-Depends

[Werner Koch]

>  * libcurl4-gnutls-dev is unused. While curl is mentioned in source
>comments and checked for in configure, it is never actually used.

You mean GnuPG's configure?  I can't find it.  It was tested for in
GnuPG 1 and 2.0 but not anymore since 2.1.  I am just a curious
upstream.


Salam-Shalom,

   Werner

-- 
* Free Assange and protect free journalism!
* Germany: Sign the Treaty on the Prohibition of Nuclear Weapons!


signature.asc
Description: PGP signature

Bug#979412: [pkg-gnupg-maint] Bug#979412: pinentry: "--lc-type" in manapges is typo for "--lc-ctype"

[Werner Koch]

FWIW, that was fixed 11 years ago in upstream
(commit 971962116fba3769d8260b5016f93c6f9ebf083f)

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Bug#978630: [pkg-gnupg-maint] Bug#978630: Bug#978630: gnupg: --check-sigs trusts weak digest alg if weak digest was trusted when importing key

[Werner Koch]

It gets cached if it has been checked.  There are some pre-conditions
for this for example the existance of the corresponding public key.

Bug#978630: [pkg-gnupg-maint] Bug#978630: gnupg: --check-sigs trusts weak digest alg if weak digest was trusted when importing key

[Werner Koch]

Hi!

gpg caches key signature verification results.  Use --no-sig-cache to
disable this cache.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#977909: [pkg-gnupg-maint] Bug#977909: Bug#977909: gnupg: `--trust-model always` doesn't trust keys

[Werner Koch]

On Tue, 22 Dec 2020 22:41, Ansgar said:

> The warning is incorrect as GnuPG was told that the key is trusted.

The warning is there for a reasons and it will not be changed.

>> I am not sure what python3-gpg is.
>
> The official Python bindings for GPGME.

Sorry, I did not knew Debian's package name for the GPGME binding.
Anyway, if you think that is a bug in the python binding, please file a
bug a dev.gnupg.org (tag as gpgme and python)


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#977909: [pkg-gnupg-maint] Bug#977909: gnupg: `--trust-model always` doesn't trust keys

[Werner Koch]

> The output then contains:
>
> | gpg: WARNING: Using untrusted key!

Look here:

  if (opt.trust_model == TM_ALWAYS)
{
  if (!opt.quiet)
log_info(_("WARNING: Using untrusted key!\n"));

It is just a warning - use --quiet to silence this warning.

> If I try to use python3-gpg to verify the signature, the signatures

I am not sure what python3-gpg is.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#977123: Aw: Re: Re: Bug#977123: ldapadd: simple authentication works without setting of -x

[Werner . Heuser]

Hi Quanah,

I just did a fresh install on another Debian 10 system and tried

ldapdelete -D "cn=admin,dc=nodomain" -W "cn=admin,dc=nodomain" -n -v
ldap_initialize(  )
Enter LDAP Password:
!deleting entry "cn=admin,dc=nodomain"

Works also without -n of course, and deletes the object actually.
PS: sure it makes no sense to delete the admin object, but
I have just tried to find an example which can be
tried in a few minutes.

Thank you,

Werner

> Gesendet: Dienstag, 15. Dezember 2020 um 18:48 Uhr
> Von: "Quanah Gibson-Mount" 
> An: werner.heu...@web.de
> Cc: 977...@bugs.debian.org
> Betreff: Re: Aw: Re: Bug#977123: ldapadd: simple authentication works without 
> setting of -x
>
>
>
> --On Saturday, December 12, 2020 3:38 PM +0100 werner.heu...@web.de wrote:
>
> > Hi Quanah,
> >
> > thank you for your support. I have double checked again:
> > - I use a static configuration with slapd.conf
> > - slapd was startet from the command line
> > - with no ACLs
> > - no $HOME/.ldaprc
> > - default Debian /etc/ldap/ldap.conf
> > - no aliases for ldap-clients
> >
> > ldapwhoami, ldapsearch _require_ -x for simple binds without SASL
> > ldapadd, and also ldapdelete work _without_ -x (and of course with -x)
> > when I try to connect to a slapd running on the same machine.
>
> Hi Werner,
>
> I installed slapd via: apt install slapd
>
> on my Debian 10 buster system.
>
> I then run:
>
> root@d10build:~# ldapadd
> SASL/DIGEST-MD5 authentication started
> Please enter your password:
>
> So it immediately starts a SASL/DIGEST-MD5 bind, as expected.
>
> Regards,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>

Bug#977046: Aw: Re: Bug#977046: parted: support pattern matching, e.g. parted -s /dev/sd[b-c] "print"

[Werner . Heuser]

Hi Colin,

thank you for your fast and friendly answer. Yes, indeed
my suggestion is only small and it's easy to use
a loop instead, of course.

The idea came to me, when I used parted to
prepare some disks for RAID as well
as for LVM2. Both tools (e.g. mdadm, pvcreate) can
handle a list of devices out of the box. So I just
wondered why  parted (and sfdisk) don't.

Best regards,

Werner

> Gesendet: Freitag, 11. Dezember 2020 um 10:53 Uhr
> Von: "Colin Watson" 
> An: werner.heu...@web.de, 977...@bugs.debian.org
> Betreff: Re: Bug#977046: parted: support pattern matching, e.g. parted -s 
> /dev/sd[b-c] "print"
>
> On Thu, Dec 10, 2020 at 04:51:39PM +0100, Werner Heuser wrote:
> > please consider to support pattern matching, e.g.
> > parted -s /dev/sd[b-c] "print"
>
> The problem with anything like this would be that the shell would expand
> the pattern, so parted itself would see the argument list as:
>
>   parted -s /dev/sdb /dev/sdc print
>
> The only ways I can think of to solve this would be:
>
>  * use a different pattern syntax that doesn't collide with shell
>metacharacters (unlikely to be a good idea)
>  * require users to quote the pattern to protect it from shell expansion
>(clumsy)
>  * allow -s to take multiple device arguments until they stop looking
>like valid devices
>
> But I think this is special-purpose enough that it's unlikely to be
> worth the effort to implement in parted, when you could just use a shell
> loop instead (granted, it's longer, but it composes nicely and the
> meaning is unambiguous):
>
>   for dev in /dev/sd[b-c]; do parted -s "$dev" print; done
>
> You're welcome to file your request directly upstream yourself, but
> since I'm not convinced that it should be implemented given the
> disadvantages, I don't currently plan to forward it.
>
> Thanks,
>
> --
> Colin Watson (he/him)  [cjwat...@debian.org]
>

Bug#977123: Aw: Re: Bug#977123: ldapadd: simple authentication works without setting of -x

[Werner . Heuser]

Hi Quanah,

thank you for your support. I have double checked again:
- I use a static configuration with slapd.conf
- slapd was startet from the command line
- with no ACLs
- no $HOME/.ldaprc
- default Debian /etc/ldap/ldap.conf
- no aliases for ldap-clients

ldapwhoami, ldapsearch _require_ -x for simple binds without SASL
ldapadd, and also ldapdelete work _without_ -x (and of course with -x)
when I try to connect to a slapd running on the same machine.

Best regards,

Werner

> Gesendet: Freitag, 11. Dezember 2020 um 18:02 Uhr
> Von: "Quanah Gibson-Mount" 
> An: werner.heu...@web.de, 977...@bugs.debian.org
> Betreff: Re: Bug#977123: ldapadd: simple authentication works without setting 
> of -x
>
>
>
> --On Friday, December 11, 2020 8:20 AM +0100 David Damago
>  wrote:
>
> > Package: ldap-utils
> > Version: 2.4.47+dfsg-3+deb10u4
> > Severity: minor
> > Tags: upstream
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Hello,
> >
> > ldapadd used without -x and without SASL of course performs
> > a simple bind and add entries to the OpenLDAP server. Other
> > LDAP clients, e.g. ldapsearch, ldapwhoami, .. still
> > require -x for simple authentication.
> >
> > Thank you,
>
> Hi Werner,
>
> I do not see such behavior when using ldapadd against a publicly available
> ldap server:
>
> root@d10build:/var/log# ldapadd -H ldap://ldap.stanford.edu
> ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
> additional info: SASL(-4): no mechanism available: No worthy mechs
> found
>
>
> Instead, without -x, ldapadd immediately moves on to trying a SASL bind.
>
> Are you sure there isn't something providing defaults to the ldap client,
> such as an ~/.ldaprc file or modified /etc/ldap/ldap.conf?
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>

Bug#977046: parted: support pattern matching, e.g. parted -s /dev/sd[b-c] "print"

[Werner Heuser]

Package: parted
Version: 3.2-25
Severity: wishlist
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

please consider to support pattern matching, e.g.
parted -s /dev/sd[b-c] "print"

Best regards,

Werner

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

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

Versions of packages parted depends on:
ii  libc6 2.28-10
ii  libparted23.2-25
ii  libreadline7  7.0-5
ii  libtinfo6 6.1+20181013-2+deb10u2

parted recommends no packages.

Versions of packages parted suggests:
pn  parted-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE5C+AKX3ilVyzT1u+Ib3VvhD/8swFAl/SRAIACgkQIb3VvhD/
8swNhxAAw1TPd/0Jx8cfy+569X6kr0jJtpbE8qR4AB3RK6jmLUGnks6K5Qko+n4f
1vLaZHfim4F8vmyaN3aaGe9TiW4COi2nZXmJPCngyRoFal2bCXZMEcPPDXLTyx90
UxPqPC1+OyPblDXMCi85CORC1yO3E0zC0M1HdbpRhVcZB920KZyxTw9JrW6ZG3dJ
XQkI46kDV9gIoHfmyxLdEKtUyUWcAssDuHNtTCpomAen60pH1fDO0RkQswiRlknB
WXsZBkKaiE79arT90MEUOcn6Hqb/19Kc1ppLakqcjq+VKINaB19mws0hpOAkAToI
b7sjsfRyGN5IKwcUE+XniI1qQKcvq1jTDL4sYYryDazQ0QKr7opN5psNYNmtA4Tm
t587t6PvVFotmaBCrTEKCcuO8e2PUUAp21/AyBwWVKhUQ1U0dHOEVDYclcSsDAOU
KcKfkUf2Rm3FlU5KP0wmidtRV8ySmlhxl5ncRaTWDpyv4VUWK1xPe8+XFUNjRK2O
F43z+n+ebydIAU9FZHl/Knqleh05y19cNmOMXvtazp4GIxnoCO7bKm+XM5qcA0/P
XxdrY7E1c/6ADb+tnx8DmnS9dHnJPuTSSbBGwzn60A7n+3PYJKvKkYHlDYTk7YOJ
qiK4iteUppaSBc8GxtA49YKG1Ht5FllsfyVAMqdaI+XHePEzRGg=
=Ag5o
-END PGP SIGNATURE-

Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded

[Brandon Werner]

On Wed, Nov 4, 2020, at 1:13 AM, Brandon Werner wrote:
> 
> 
> On Tue, Nov 3, 2020, at 10:52 PM, Brandon Werner wrote:
> > package: src:linux
> > 
> > Hi,
> > I downloaded one of the firmware netinstall builds of Debian from today 
> > (11/03/2020) to try installing on my netbook with the 8821ce wifi card 
> > since Debian now has the 5.9 kernel. During the text install with 
> > speech, I received an error that the network card could not be found. I 
> > opened a console and looking at dmesg showed the driver not finding the 
> > firmware with a -2 error, however, I noticed that the requested files 
> > had been unpacked to /lib/firmware. I unloaded rtw88_8821ce and 
> > reloaded it using modprobe and the firmware was found, after which the 
> > network interface was successfully brought up.
> I took a look at the installer logs and found something that looks like 
> it could be the likely problem.
> 
> Nov  3 22:09:17 check-missing-firmware: removing and loading kernel 
> module rtw_8821ce
> 
> I think some substitution is going wrong in the installer because it 
> seems like the module should be called rtw88_8821ce.
It looks like what is happening is that the driver prints its messages to dmesg 
with a different name than what the module is actually called. When it prints 
its messages about missing firmware, it uses rtl_8821ce. The installer matches 
on that when unloading and loading modules to get the missing firmware, which 
results in an incorrect module name being used. Is there a list of cases in the 
installer for this? It needs to use rtw88_8821ce when it unloads and reloads 
the module.
> > I was able to continue through the rest of the install without issue. I am 
> > not sure what logs 
> > would help but would be happy to provide anything requested to diagnose 
> > this issue.

Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded

[Brandon Werner]

On Tue, Nov 3, 2020, at 10:52 PM, Brandon Werner wrote:
> package: src:linux
> 
> Hi,
> I downloaded one of the firmware netinstall builds of Debian from today 
> (11/03/2020) to try installing on my netbook with the 8821ce wifi card 
> since Debian now has the 5.9 kernel. During the text install with 
> speech, I received an error that the network card could not be found. I 
> opened a console and looking at dmesg showed the driver not finding the 
> firmware with a -2 error, however, I noticed that the requested files 
> had been unpacked to /lib/firmware. I unloaded rtw88_8821ce and 
> reloaded it using modprobe and the firmware was found, after which the 
> network interface was successfully brought up.
I took a look at the installer logs and found something that looks like it 
could be the likely problem.

Nov  3 22:09:17 check-missing-firmware: removing and loading kernel module 
rtw_8821ce

I think some substitution is going wrong in the installer because it seems like 
the module should be called rtw88_8821ce.
> I was able to continue through the rest of the install without issue. I am 
> not sure what logs 
> would help but would be happy to provide anything requested to diagnose 
> this issue.

Bug#973733: RTW88_8821ce module fails to find firmware during install and must be reloaded

[Brandon Werner]

package: src:linux

Hi,
I downloaded one of the firmware netinstall builds of Debian from today 
(11/03/2020) to try installing on my netbook with the 8821ce wifi card since 
Debian now has the 5.9 kernel. During the text install with speech, I received 
an error that the network card could not be found. I opened a console and 
looking at dmesg showed the driver not finding the firmware with a -2 error, 
however, I noticed that the requested files had been unpacked to /lib/firmware. 
I unloaded rtw88_8821ce and reloaded it using modprobe and the firmware was 
found, after which the network interface was successfully brought up. I was 
able to continue through the rest of the install without issue. I am not sure 
what logs would help but would be happy to provide anything requested to 
diagnose this issue.

Bug#971628: Whipper: Missing dependency on python3-distutils

[Brandon Werner]

Package: whipper
Version: 0.9.0-4

Hello,
I tried to install and use whipper and got a traceback. Installling the 
python3-distutils package solved the issue.

Bug#968997:

[Hervé Werner]

I'm not using the same hardware and was not upgrading to the same firmware but 
I was also able to successfully update my laptop eventually.
I'm not sure what was the issue, I noticed that fwupd has been updated recently 
as well.

Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot

[Hervé Werner]

Hello
I'm having the exact same issue on a ThinkPad T480 : running Bullseye, worked 
before and no longer since this summer (I assume this might be related to the 
bunch of updates that followed BootHole).

Bug#940911: grub2: add TPM support

[Hervé Werner]

Hello

I'm facing the same issue on Debian Bullseye on a permanent installation (not 
live-CD).
I've noticed that the same bug has been reported and fixed on Ubuntu, but the 
patch has not yet been pulled in Debian: 
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1848892

Bug#953048: [Pkg-sass-devel] Bug#953048: ruby-sass: sass --watch does not work

[Werner Joss]

Am Mittwoch, 4. März 2020, 17:48:05 CET schrieb Jonas Smedegaard:
> I deliberately wrote "should" because it is outside Debian: I don't 
> really know if and how it might maybe perhaps work and if so then for 
> how long before it maybe perhaps crashes in weird ways.
> 
> I know about Debian, and I chose to avoid that feature because it became 
> difficult to package for Debian and I considered it a low-priority 
> feature (read: I found it more important to ship sass wihtout that 
> feature than to not ship sass at all with Debian).
> 
> Beware: Ruby-based sass is dead upstream.  I recommend to use sassc 
> instead.
> 
> For the --watch feature, I suggest you consider generic tools like 
> fswatch inotify-tools iwatch

Ok, Jonas,
That makes things a little more clear for me - may I propose to just remove the 
--watch option
When it does not work anyway ?
Would be better than a crash, IMHO ;)
And yes, I already thought about writing a script using sass or sassc together 
with some filesystem-watch tool,
as you proposed, but fortunately there is also pyscss: 
https://pythonhosted.org/scss/#python-scss
Which has this watch feature and gets the job done.

Kind regards
Werner

Bug#953048: [Pkg-sass-devel] Bug#953048: ruby-sass: sass --watch does not work

[Werner Joss]

Am Dienstag, 3. März 2020, 21:38:00 CET schrieb Jonas Smedegaard:
> control: tags -1 confirmed
> control: severity -1 low
> 
> Quoting Werner Joss (2020-03-03 20:46:47)
> > sass --watcg does not work - I get the following errors:
> 
> You are right, that feature has been omitted from the Debian packaging 
> of ruby-sass.  It should work if you install the Python module 
> sass-watch locally.

Hi Jonas,
Thanks for fast reply !
But unfortunately, I can't find any package with this name (via aptitude and 
pip/pip3) - installed pysass and python-libsass instead
but no change.
Greetings
Werner

Bug#953048: ruby-sass: sass --watch does not work

[Werner Joss]

Package: ruby-sass
Version: 3.5.6-1
Severity: normal

Dear Maintainer,

sass --watcg does not work - I get the following errors:

sass --watch --trace custom.scss:custom.css
>>> Sass is watching for changes. Press Ctrl-C to stop.
Traceback (most recent call last):
9: from /usr/bin/sass:8:in `'
8: from /usr/lib/ruby/vendor_ruby/sass/exec/base.rb:19:in `parse!'
7: from /usr/lib/ruby/vendor_ruby/sass/exec/base.rb:52:in `parse'
6: from /usr/lib/ruby/vendor_ruby/sass/exec/sass_scss.rb:51:in 
`process_result'
5: from /usr/lib/ruby/vendor_ruby/sass/exec/sass_scss.rb:356:in 
`watch_or_update'
4: from /usr/lib/ruby/vendor_ruby/sass/plugin.rb:109:in `method_missing'
3: from /usr/lib/ruby/vendor_ruby/sass/plugin/compiler.rb:319:in `watch'
2: from /usr/lib/ruby/vendor_ruby/sass/plugin/compiler.rb:380:in 
`create_listener'
1: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot 
load such file -- sass-listen (LoadError)



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

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

Versions of packages ruby-sass depends on:
ii  ruby  1:2.5.1

ruby-sass recommends no packages.

Versions of packages ruby-sass suggests:
pn  ruby-sass-listen  

-- no debconf information

Bug#951025: [pkg-gnupg-maint] Bug#951025: gnupg: GPG tries to get passphrase from wrong place

[Werner Koch]

> my passphrase on my desktop XFCE session. However, I am not at that
> computer, so I cannot provide it with a passphrase.

After having logged into the other box with ssh -X, run in that ssh
session:

  gpg-connect-agent updatestartuptty /bye

This tells gpg-agent on which DISPLAY or tty it should pop up the
pinentry.  In contrast to gpg ssh and the ssh-agent protocol have no way
to convey the DISPLAY and other envvars to gpg-agent, thus you need to
tell it manually.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Werner Mahr]

> > Internal Use - Confidential
> > 
> > In 1.3.2-5 the service is disabled by default (and also this issue should 
be fixed).

> Okay.  So, the bug can be closed, I guess.

I'm sorry, but it seems that it at least was reintroduced somewhen. I have 
1.3.4-1 installed on testing and it fails to start. Unfortunately is is not 
that verbose on the logs.

$ service fwupd-refresh status
● fwupd-refresh.service - Refresh fwupd metadata and update motd
Loaded: loaded (/lib/systemd/system/fwupd-refresh.service; static; vendor 
preset: disabled)
Active: failed (Result: exit-code) since Mon 2019-12-02 09:16:34 CET; 2h 8min 
ago
Docs: man:fwupdmgr(1)
Process: 144751 ExecStart=/usr/bin/fwupdmgr refresh --no-metadata-check 
(code=exited, status=1/FAILURE)
Main PID: 144751 (code=exited, status=1/FAILURE)
Dez 02 09:16:34 werner1 systemd[1]: Starting Refresh fwupd metadata and update 
motd...
Dez 02 09:16:34 werner1 systemd[1]: fwupd-refresh.service: Main process 
exited, code=exited, status=1/FAILURE
Dez 02 09:16:34 werner1 systemd[1]: fwupd-refresh.service: Failed with result 
'exit-code'.
Dez 02 09:16:34 werner1 systemd[1]: Failed to start Refresh fwupd metadata and 
update motd.

Called from cmdline directly it still works.

-- 
MfG usw.

Werner Mahr

Bug#945279: [pkg-gnupg-maint] Bug#945279: gpg-wks-client: --install-key does not create policy file

[Werner Koch]

On Fri, 22 Nov 2019 11:36, Hans-Christoph Steiner said:

> It should create a zero length file, as recommended in the draft: "it
> is sufficient if that file has a zero length".

Good idea.  Tracked upstream as https://dev.gnupg.org/T4753


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#944914: [pkg-gnupg-maint] Bug#944914: libgpgme11: Buffer overflow while using claws-mail

[Werner Koch]

On Tue, 19 Nov 2019 14:50, Bernhard Übelacker said:

> Maybe it is of some help, following seem to be locations with the
> missing symbols:
> ...
> #8  0xb6441a7a in __fdelt_chk (d=194142480) at fdelt_chk.c:25
> #9 0xb27e5281 in () at libgpgme.so.11, in _gpgme_io_select at

This is the code at that place (at least in my master but we have not
chnaged it for quite some time)

  else if (fds[i].for_read)
{
> if (FD_ISSET (fds[i].fd, ))
{

Right, the tested FD might be out of range for FD_ISSET but we have an
earlier check for this:

  if (fds[i].for_read)
{
  if (fds[i].fd >= FD_SETSIZE)
{
  TRACE_END (dbg_help, " -BAD- ]");
  gpg_err_set_errno (EMFILE);
  return TRACE_SYSRES (-1);
}

So the code should not be the problem.  Hwoever if the fd table is
corrupt you might run into this but.  Nex step would be looking into
libc - I have no copy handy right now ...

> I found this upstream feature request, which could fit,
> but there is also a change mentioned that should avoid that crash,
> that is already included ...
> Are you maybe hitting this limit?

Nope, see the code above.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#942127: [pkg-gnupg-maint] Bug#942127: bugs in the FILTER EXPRESSIONS section of the gpg man page

[Werner Koch]

On Thu, 10 Oct 2019 18:42, Steve McIntyre said:

> Looks like a simple cut and paste / completion error.

Now fixed upstream.  Thanks for reporting.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#939508: [pkg-gnupg-maint] Bug#939508: scdaemon: scdaemon does not share access with pcscd used by opensc

[Werner Koch]

On Thu,  5 Sep 2019 13:05, robert.grizz...@quoininc.com said:

> I am attempting to use both the gpg and PIV functionaity of a Yubikey 5 
> device, but scdaemon takes exclusive access.  This is the intended behavior 

FWIW: GnuPG master has dedicated support for Yubikeys and since today
allows on-the-fly switching between the PIV and the OpenPGP application
on the Yubikey.  Thus you can use the Yubikey to sign commits with the
OpenPGP key and also use it in Firefox or Thunderbird via the scute.org
(git master) pkcs#11 provider.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#935402: O: mytop

[Werner Detter]

Package: wnpp
Severity: normal

mytop is now part of mariadb-client, therefore the mytop package
doesn't seem to make much sense anymore.

Cheers,
Werner

Bug#935401: RFA: policyd-weight -- Perl policy daemon for the Postfix MTA

[Werner Detter]

Package: wnpp
Severity: normal

I request an adopter for the policyd-weight package, a Perl policy daemon for 
the Postfix MTA.
The package is implemented in Perl. Upstream is inactive since years, features 
have been 
implemented by myself on request and need. The package is in good shape 
although there are a
few open bugs which are easy to fix and will be a good start for a new 
maintainer. Since Postfix
itself has postscreen implemented for the same purpose the usage of this 
package will constantly
decrease, probably. 

The package description is:
 policyd-weight is intended to eliminate forged envelope senders and HELOs
 (i.e. in bogus mails). It allows you to score DNSBLs (RBL/RHSBL), HELO,
 MAIL FROM and client IP addresses before any queuing is done. It allows
 you to REJECT messages which have a score higher than allowed, providing
 improved blocking of spam and virus mails. policyd-weight caches the most
 frequent client/sender combinations (SPAM as well as HAM) to reduce the
 number of DNS queries.

Cheers,
Werner

[1] https://packages.qa.debian.org/p/policyd-weight.html

Bug#935389: O: mytop

[Werner Detter]

Package: wnpp

mytop is now part of mariadb-client, therefore the mytop package
doesn't seem to make much sense anymore.

Bug#935388: RFA: policyd-weight

[Werner Detter]

Package: wnpp
Severity: normal

I request an adopter for the policyd-weight package, a Perl policy daemon for 
the Postfix MTA.
The package is implemented in Perl. 

 policyd-weight is intended to eliminate forged envelope senders and HELOs
 (i.e. in bogus mails). It allows you to score DNSBLs (RBL/RHSBL), HELO,
 MAIL FROM and client IP addresses before any queuing is done. It allows
 you to REJECT messages which have a score higher than allowed, providing
 improved blocking of spam and virus mails. policyd-weight caches the most
 frequent client/sender combinations (SPAM as well as HAM) to reduce the
 number of DNS queries.

Upstream is inactive since years, features have been implemented by myself on 
request and need. 
The package is in good shape although there are a few open bugs which are easy 
to fix and will
be a good start for a new maintainer. Since Postfix itself has postscreen 
implemented for the 
same purpose the usage of this package will constantly decrease, probably. 

Cheers,
Werner

[1] https://packages.qa.debian.org/p/policyd-weight.html



signature.asc
Description: OpenPGP digital signature

Bug#933972: policyd-weight: using IPv6 broken in buster

[Werner Detter]

Addition: should be s-p-u'ed

Am 05.08.19 um 21:04 schrieb Werner Detter:
> Hi,
> 
> thanks for your report. Yes, using "use IO::Socket::INET6" addresses
> the issue. libio-socket-inet6-perl is listed in control / Depends. I
> will fix this in the next version.
> 
> Cheers,
> Werner
> 
> 
> 
> Am 05.08.19 um 18:49 schrieb Markus Gschwendt:
>> Package: policyd-weight
>> Version: 0.1.15.2-12
>>
>> After dist-upgrade from stretch to buster:
>>
>> # service policyd-weight restart 
>> [] Restarting policyd-weight configuration (incl. cache): policyd-
>> weightCan't locate object method "new" via package "IO::Socket::INET6"
>> (perhaps you forgot to load "IO::Socket::INET6"?) at /usr/sbin/policyd-
>> weight line 921.
>>  failed!
>>
>> Solution:
>>
>> File
>> /usr/sbin/policyd-weight
>> is not loading the module IO::Socket::INET6.
>> around line 72 following should be inserted:
>> use IO::Socket::INET6;
>>
>> Maybe th
>> Markus
>>
> 

Bug#933972: policyd-weight: using IPv6 broken in buster

[Werner Detter]

Hi,

thanks for your report. Yes, using "use IO::Socket::INET6" addresses
the issue. libio-socket-inet6-perl is listed in control / Depends. I
will fix this in the next version.

Cheers,
Werner



Am 05.08.19 um 18:49 schrieb Markus Gschwendt:
> Package: policyd-weight
> Version: 0.1.15.2-12
> 
> After dist-upgrade from stretch to buster:
> 
> # service policyd-weight restart 
> [] Restarting policyd-weight configuration (incl. cache): policyd-
> weightCan't locate object method "new" via package "IO::Socket::INET6"
> (perhaps you forgot to load "IO::Socket::INET6"?) at /usr/sbin/policyd-
> weight line 921.
>  failed!
> 
> Solution:
> 
> File
> /usr/sbin/policyd-weight
> is not loading the module IO::Socket::INET6.
> around line 72 following should be inserted:
> use IO::Socket::INET6;
> 
> Maybe th
> Markus
> 

Bug#931339: [pkg-gnupg-maint] Bug#931339: gnupg: Change default keyserver?

[Werner Koch]

On Tue,  2 Jul 2019 15:55, guil...@debian.org said:

> According to the dirmngr(8) man page, the default built-in server is
> «hkps://hkps.pool.sks-keyservers.net». Given the recent attacks, and

Not from upstream.  We have a default keyserver because that is (or
better was) a pool of keyservers which allows to maintain a set of
responsive keyservers without chnages on the client side.
keys.openpgp.org may ask to be included into the pool but I doubt that
this makes sense because it is, like pgp.com, a standalone keyserver
which by design can't synchronize with others.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#931340: dirmngr goes into endless loop if keyserver responses with http error 503

[Werner Koch]

Hi,

this bug was reported on Monday as

  https://dev.gnupg.org/T4600


Salam-Shalom,

   Werner
  
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#931307: linux-image-4.9.0-9-amd64: Problems with Samba Shares?

[Werner Detter]

Hi Ben,

> There is a known regression that will be fixed soon, affecting programs
> that use small socket buffers.
> 
> I think it was once recommended to set the SO_SNDBUF parameter in
> smb.conf, which can trigger this bug.  This parameter is now
> deprecated, and if it is present in your configuration file it should
> be safe to remove it.
> 
> Please let us know if that change fixes the issue.

ACK, removing SO_SNDBUF from smb.conf indeed fixed the problem :)

Thanks,
Werner



signature.asc
Description: OpenPGP digital signature

Bug#931307: linux-image-4.9.0-9-amd64: Problems with Samba Shares?

[Werner Detter]

Package: src:linux
Version: 4.9.168-1+deb9u3
Severity: important

Dear Maintainer,

after upgrading to the latest linux-image-adm64 on stretch we're experiencing 
strange issues on a 
fileserver with samba: directory listings in subfolder of shares don't work 
after upgrading to 
4.9.168-1+deb9u3 on the clients. I've rebooted the machine to 
linux-image-4.9.0-8-amd64 - with that 
version everything is working. 

So I'm wondering if there are other users which experience similar problems 
with the latest 
kernel and samba? 

Thanks,
Werner


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


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.9.0-9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-9-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.9.0-9-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta3-5+deb9u1
pn  linux-doc-4.9   

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

-- no debconf information

Bug#931228: policyd-weight: dead upstream

[Werner Detter]

this is nothing new: Upstream is discontinued since I took over the
package years ago, I took care to fix bugs and implemented things
where needed.

policyd-weight is still used but usage decreases. I'd suggest to leave
the package meanwhile and remove it after usage has significantly
dropped (and users switched to other software e.g. postscreen)

Cheers,
Werner



signature.asc
Description: OpenPGP digital signature

Bug#926268: Discontinued upstream

[Werner Detter]

this is nothing new :) Upstream is discontinued since I took over the
package years ago, we took care to fix bugs and implemented things
where needed.

policyd-weight is still used but usage decreases. I'd suggest to leave
the package meanwhile and remove it after usage has significantly
dropped (and users switched to other software e.g. postscreen)

Cheers,
Werner


Am 02.04.19 um 20:49 schrieb Dominique Fournier:
> Package: policyd-weight
> Version: 0.1.15.2-12
> 
> Hi
> 
> The upstream site www.policyd-weight.org says this software is
> discontinued.
> 
> It will reject users mails as some RBL defined in it are now closed and
> provide wrong state.
> 
> As this, I suggests to remove the package from Debian.
> 
> Dom

Bug#925919: RFT: linux with fix for VMware regression

[Werner Detter]

short update: the system is still up and running.

Cheers,
Werner


Am 30.03.19 um 19:01 schrieb Werner Detter:
> Hi Ben,
> 
> thanks for the updated version. I've installed the new version on one
> affected machine which crashed after some hours with the old kernel.
> It's currently running with the updated version since 9 hours without
> problems. I'll get back to you.
> 
> Cheers,
> Werner




signature.asc
Description: OpenPGP digital signature

Bug#925919: RFT: linux with fix for VMware regression

[Werner Detter]

Hi Ben,

thanks for the updated version. I've installed the new version on one
affected machine which crashed after some hours with the old kernel.
It's currently running with the updated version since 9 hours without
problems. I'll get back to you.

Cheers,
Werner


Am 30.03.19 um 05:15 schrieb Ben Hutchings:
> I've uploaded a new version of linux to:
> https://people.debian.org/~benh/packages/jessie-security/
> which I believe will fix this regression (bug #925919).  Please let me
> know whether it works for you.
> 
> I only included the amd64 linux-image package and sources there, but
> can add i386 linux-image packages if needed.
> 
> Ben.
> 




signature.asc
Description: OpenPGP digital signature

Bug#925919: linux-image-amd64: linux-image-3.16.0-8-amd64 - unpredictable reboots / kernel panics?

[Werner D.]

Package: linux-image-amd64
Version: linux-image-3.16.0-8-amd64
Severity: important

Dear Maintainer,

here we go again, i hope this time we get a bug nummer for this report :) 

after upgrading to the latest linux-image-adm64 on jessie we're experiencing 
several issues which led us 
to downgrade to linux-image-3.16.0-7-amd64 again and deinstall 
linux-image-3.16.0-8-amd64. It's happened
until now on a COROSYNC/DRBD Cluster where standby node has been upgraded and 
after the upgrade the system
froze, see [1]. 

On another MySQL-Slave where we applied this kernel - the system - after 
running some time rebooted due to
a kernel panic. I wasn't fast enough to catch the kernel panic on the screen as 
VMware HA-features instantly 
rebooted the system. Both systems run in a VMware HA-Cluster on different ESXi 
runhosts.

So for me, linux-image-3.16.0-8-amd64 smells fishy and i was wondering if there 
are other users which have
problems? 

Cheers,
Werner



[1]
Mar 28 13:35:38 nfs02 kernel: [  191.925130] block drbd0: helper command: 
/sbin/drbdadm after-resync-target minor-0
Mar 28 13:35:38 nfs02 kernel: [  191.927389] block drbd0: helper command: 
/sbin/drbdadm after-resync-target minor-0 exit code 0 (0x0)
Mar 28 13:35:40 nfs02 kernel: [  194.306334] drbd r0: Wrong magic value 
0x in protocol version 101
Mar 28 13:35:40 nfs02 kernel: [  194.306407] drbd r0: peer( Primary -> Unknown 
) conn( Connected -> ProtocolError ) pdsk( UpToDate -> DUnknown ) 
Mar 28 13:35:40 nfs02 kernel: [  194.306432] drbd r0: asender terminated
Mar 28 13:35:40 nfs02 kernel: [  194.306436] drbd r0: Terminating drbd_a_r0
Mar 28 13:35:40 nfs02 kernel: [  194.306828] drbd r0: Connection closed
Mar 28 13:35:40 nfs02 kernel: [  194.306845] drbd r0: conn( ProtocolError -> 
Unconnected ) 
Mar 28 13:35:40 nfs02 kernel: [  194.306847] drbd r0: receiver terminated
Mar 28 13:35:40 nfs02 kernel: [  194.306848] drbd r0: Restarting receiver thread
Mar 28 13:35:40 nfs02 kernel: [  194.306850] drbd r0: receiver (re)started
Mar 28 13:35:40 nfs02 kernel: [  194.306860] drbd r0: conn( Unconnected -> 
WFConnection ) 
Mar 28 13:35:41 nfs02 kernel: [  194.805238] drbd r0: Handshake successful: 
Agreed network protocol version 101
Mar 28 13:35:41 nfs02 kernel: [  194.805243] drbd r0: Agreed to support TRIM on 
protocol level
Mar 28 13:35:41 nfs02 kernel: [  194.805274] drbd r0: conn( WFConnection -> 
WFReportParams ) 
Mar 28 13:35:41 nfs02 kernel: [  194.805277] drbd r0: Starting asender thread 
(from drbd_r_r0 [1367])
Mar 28 13:35:41 nfs02 kernel: [  194.869215] block drbd0: drbd_sync_handshake:
Mar 28 13:35:41 nfs02 kernel: [  194.869221] block drbd0: self 
E2641EEB9E133204::0DD839919AA45372:0DD739919AA45373 bits:0 
flags:0
Mar 28 13:35:41 nfs02 kernel: [  194.869225] block drbd0: peer 
14F96DC2D3D2E20D:E2641EEB9E133205:0DD839919AA45373:0DD739919AA45373 bits:23 
flags:0
Mar 28 13:35:41 nfs02 kernel: [  194.869228] block drbd0: uuid_compare()=-1 by 
rule 50
Mar 28 13:35:41 nfs02 kernel: [  194.869236] block drbd0: peer( Unknown -> 
Primary ) conn( WFReportParams -> WFBitMapT ) disk( UpToDate -> Outdated ) 
pdsk( DUnknown -> UpToDate ) 
Mar 28 13:35:41 nfs02 kernel: [  194.876039] block drbd0: receive bitmap stats 
[Bytes(packets)]: plain 0(0), RLE 39(1), total 39; compression: 100.0%
Mar 28 13:35:41 nfs02 kernel: [  194.882431] block drbd0: send bitmap stats 
[Bytes(packets)]: plain 0(0), RLE 39(1), total 39; compression: 100.0%
Mar 28 13:35:41 nfs02 kernel: [  194.882445] block drbd0: conn( WFBitMapT -> 
WFSyncUUID ) 
Mar 28 13:35:41 nfs02 kernel: [  194.887016] block drbd0: updated sync uuid 
E2651EEB9E133204::0DD839919AA45372:0DD739919AA45373
Mar 28 13:35:41 nfs02 kernel: [  194.887489] block drbd0: helper command: 
/sbin/drbdadm before-resync-target minor-0
Mar 28 13:35:41 nfs02 kernel: [  194.889641] block drbd0: helper command: 
/sbin/drbdadm before-resync-target minor-0 exit code 0 (0x0)
Mar 28 13:35:41 nfs02 kernel: [  194.889656] block drbd0: conn( WFSyncUUID -> 
SyncTarget ) disk( Outdated -> Inconsistent ) 
Mar 28 13:35:41 nfs02 kernel: [  194.889666] block drbd0: Began resync as 
SyncTarget (will sync 92 KB [23 bits set]).
Mar 28 13:35:41 nfs02 kernel: [  194.900324] drbd r0: Wrong magic value 
0x84a1785a in protocol version 101
Mar 28 13:35:41 nfs02 kernel: [  194.900381] drbd r0: peer( Primary -> Unknown 
) conn( SyncTarget -> ProtocolError ) pdsk( UpToDate -> DUnknown ) 
Mar 28 13:35:41 nfs02 kernel: [  194.900392] drbd r0: asender terminated
Mar 28 13:35:41 nfs02 kernel: [  194.900394] drbd r0: Terminating drbd_a_r0
Mar 28 13:35:41 nfs02 kernel: [  194.911438] drbd r0: Connection closed
Mar 28 13:35:41 nfs02 kernel: [  194.911456] drbd r0: conn( ProtocolError -> 
Unconnected ) 
Mar 28 13:35:41 nfs02 kernel: [  194.911458] drbd r0: receiver terminated
Mar 28 13:35:41 nfs02 kernel: [  194.911460] drbd r0: Restarting receiver thread
Mar 28 13:35:41

Bug#925918: linux-image-amd64: linux-image-3.16.0-8-amd64 - unpredictable reboots / kernel panics?

[Werner D.]

Package: linux-image-amd64
Version: linux-image-3.16.0-8-amd64
Severity: important

Dear Maintainer,

after upgrading to the latest linux-image-adm64 on jessie we're experiencing 
several issues which led us 
to downgrade to linux-image-3.16.0-7-amd64 again and deinstall 
linux-image-3.16.0-8-amd64. It's happened
until now on a COROSYNC/DRBD Cluster where standby node has been upgraded and 
after the upgrade the system
froze, see [1]. 

On another MySQL-Slave where we applied this kernel - the system - after 
running some time rebooted due to
a kernel panic. I wasn't fast enough to catch the kernel panic on the screen as 
VMware HA-features instantly 
rebooted the system. Both systems run in a VMware HA-Cluster on different ESXi 
runhosts.

So for me, linux-image-3.16.0-8-amd64 smells fishy and i was wondering if there 
are other users which have
problems? 

Cheers,
Werner



[1]
Mar 28 13:35:38 nfs02 kernel: [  191.925130] block drbd0: helper command: 
/sbin/drbdadm after-resync-target minor-0
Mar 28 13:35:38 nfs02 kernel: [  191.927389] block drbd0: helper command: 
/sbin/drbdadm after-resync-target minor-0 exit code 0 (0x0)
Mar 28 13:35:40 nfs02 kernel: [  194.306334] drbd r0: Wrong magic value 
0x in protocol version 101
Mar 28 13:35:40 nfs02 kernel: [  194.306407] drbd r0: peer( Primary -> Unknown 
) conn( Connected -> ProtocolError ) pdsk( UpToDate -> DUnknown ) 
Mar 28 13:35:40 nfs02 kernel: [  194.306432] drbd r0: asender terminated
Mar 28 13:35:40 nfs02 kernel: [  194.306436] drbd r0: Terminating drbd_a_r0
Mar 28 13:35:40 nfs02 kernel: [  194.306828] drbd r0: Connection closed
Mar 28 13:35:40 nfs02 kernel: [  194.306845] drbd r0: conn( ProtocolError -> 
Unconnected ) 
Mar 28 13:35:40 nfs02 kernel: [  194.306847] drbd r0: receiver terminated
Mar 28 13:35:40 nfs02 kernel: [  194.306848] drbd r0: Restarting receiver thread
Mar 28 13:35:40 nfs02 kernel: [  194.306850] drbd r0: receiver (re)started
Mar 28 13:35:40 nfs02 kernel: [  194.306860] drbd r0: conn( Unconnected -> 
WFConnection ) 
Mar 28 13:35:41 nfs02 kernel: [  194.805238] drbd r0: Handshake successful: 
Agreed network protocol version 101
Mar 28 13:35:41 nfs02 kernel: [  194.805243] drbd r0: Agreed to support TRIM on 
protocol level
Mar 28 13:35:41 nfs02 kernel: [  194.805274] drbd r0: conn( WFConnection -> 
WFReportParams ) 
Mar 28 13:35:41 nfs02 kernel: [  194.805277] drbd r0: Starting asender thread 
(from drbd_r_r0 [1367])
Mar 28 13:35:41 nfs02 kernel: [  194.869215] block drbd0: drbd_sync_handshake:
Mar 28 13:35:41 nfs02 kernel: [  194.869221] block drbd0: self 
E2641EEB9E133204::0DD839919AA45372:0DD739919AA45373 bits:0 
flags:0
Mar 28 13:35:41 nfs02 kernel: [  194.869225] block drbd0: peer 
14F96DC2D3D2E20D:E2641EEB9E133205:0DD839919AA45373:0DD739919AA45373 bits:23 
flags:0
Mar 28 13:35:41 nfs02 kernel: [  194.869228] block drbd0: uuid_compare()=-1 by 
rule 50
Mar 28 13:35:41 nfs02 kernel: [  194.869236] block drbd0: peer( Unknown -> 
Primary ) conn( WFReportParams -> WFBitMapT ) disk( UpToDate -> Outdated ) 
pdsk( DUnknown -> UpToDate ) 
Mar 28 13:35:41 nfs02 kernel: [  194.876039] block drbd0: receive bitmap stats 
[Bytes(packets)]: plain 0(0), RLE 39(1), total 39; compression: 100.0%
Mar 28 13:35:41 nfs02 kernel: [  194.882431] block drbd0: send bitmap stats 
[Bytes(packets)]: plain 0(0), RLE 39(1), total 39; compression: 100.0%
Mar 28 13:35:41 nfs02 kernel: [  194.882445] block drbd0: conn( WFBitMapT -> 
WFSyncUUID ) 
Mar 28 13:35:41 nfs02 kernel: [  194.887016] block drbd0: updated sync uuid 
E2651EEB9E133204::0DD839919AA45372:0DD739919AA45373
Mar 28 13:35:41 nfs02 kernel: [  194.887489] block drbd0: helper command: 
/sbin/drbdadm before-resync-target minor-0
Mar 28 13:35:41 nfs02 kernel: [  194.889641] block drbd0: helper command: 
/sbin/drbdadm before-resync-target minor-0 exit code 0 (0x0)
Mar 28 13:35:41 nfs02 kernel: [  194.889656] block drbd0: conn( WFSyncUUID -> 
SyncTarget ) disk( Outdated -> Inconsistent ) 
Mar 28 13:35:41 nfs02 kernel: [  194.889666] block drbd0: Began resync as 
SyncTarget (will sync 92 KB [23 bits set]).
Mar 28 13:35:41 nfs02 kernel: [  194.900324] drbd r0: Wrong magic value 
0x84a1785a in protocol version 101
Mar 28 13:35:41 nfs02 kernel: [  194.900381] drbd r0: peer( Primary -> Unknown 
) conn( SyncTarget -> ProtocolError ) pdsk( UpToDate -> DUnknown ) 
Mar 28 13:35:41 nfs02 kernel: [  194.900392] drbd r0: asender terminated
Mar 28 13:35:41 nfs02 kernel: [  194.900394] drbd r0: Terminating drbd_a_r0
Mar 28 13:35:41 nfs02 kernel: [  194.911438] drbd r0: Connection closed
Mar 28 13:35:41 nfs02 kernel: [  194.911456] drbd r0: conn( ProtocolError -> 
Unconnected ) 
Mar 28 13:35:41 nfs02 kernel: [  194.911458] drbd r0: receiver terminated
Mar 28 13:35:41 nfs02 kernel: [  194.911460] drbd r0: Restarting receiver thread
Mar 28 13:35:41 nfs02 kernel: [  194.911461] drbd r0: receiver (re)started
Mar 28 13:35:41 nfs0

Bug#923330: jajuk: Fails to start with Java Runtime Environment 1.7 minimum required. You use a JVM ext.JVM@23fc625e

[Werner Mahr]

Am Mittwoch, 27. Februar 2019, 00:56:12 CET schrieben Sie:
> Am 26.02.19 um 21:34 schrieb Markus Koschany:
> > Thanks for reporting and the hint how to fix this problem. I'll take a
> > closer look soon.
> 
> Unfortunately there is another issue that prevents jajuk from starting.
> This appears to be the same one which affects triplea as well.
> 
> https://bugs.debian.org/911078

That's correct. I've seen your message exactly 1 minute after trying the fix 
from git.

-- 
MfG usw.

Werner Mahr

Bug#923330: jajuk: Fails to start with Java Runtime Environment 1.7 minimum required. You use a JVM ext.JVM@23fc625e

[Werner Mahr]

Package: jajuk
Version: 1:1.10.9+dfsg2-4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Just trying to start jajuk. From the menu just nothing happens, from 
commandline I get the error from the subject.
The installed jre came as a dep of libreoffice.


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

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

Versions of packages jajuk depends on:
ii  default-jre [java8-runtime] 2:1.11-71
ii  entagged0.35-6
ii  java-wrappers   0.3
ii  libbasicplayer-java 3.0-6
ii  libcobra-java   0.98.4-5
ii  libcommons-codec-java   1.11-1
ii  libcommons-collections3-java3.2.2-2
ii  libcommons-io-java  2.6-2
ii  libcommons-lang-java2.6-8
ii  libcommons-logging-java 1.2-2
ii  libdbus-java2.8-9
ii  libguava-java   19.0-1
ii  libjaudiotagger-java2.0.3-3
ii  libjcommon-java 1.0.23-1
ii  libjfreechart-java  1.0.19-2
ii  libjgoodies-animation-java  1.4.3-2
ii  libjhlabs-filters-java  2.0.235-3
ii  libjlayer-java  1.0.1-2
ii  libjmac-java1.74-6
ii  libjna-java 4.5.2-1
ii  libjorbis-java  0.0.17-2
ii  libjspeex-java  0.9.7-4
ii  liblaf-plugin-java  7.3+dfsg3-4
ii  liblaf-widget-java  7.3+dfsg3-4
ii  liblastfm-java  1:0.1.0-2
ii  liblog4j1.2-java1.2.17-8
ii  libmiglayout-java   5.1-2
ii  libmp3spi-java  1.9.5-1
ii  libqdwizard-java5.0.1-1
ii  librhino-java   1.7.7.1-1
ii  libsimple-validation-java   0.9-2
ii  libswingx-java  1:1.6.2-4
ii  libtrident-java 7.3+dfsg3-4
ii  libtritonus-java20070428-14
ii  libvldocking-java   3.0.5-2
ii  libvorbisspi-java   1.0.3-3
ii  libxstream-java 1.4.11.1-1
ii  mplayer 4:1.3.0~20181120.svn38117-dmo3
ii  openjdk-11-jre [java8-runtime]  11.0.2+9-3
ii  substance   7.3+dfsg3-4

jajuk recommends no packages.

jajuk suggests no packages.

-- no debconf information

-- 
MfG usw.

Werner Mahr

Bug#923204: [pkg-gnupg-maint] Bug#923204: gpg-agent has a false dependency on libpam-systemd

[Werner Koch]

On Sun, 24 Feb 2019 16:56, joshud...@gmail.com said:

> gpg-agent --server or directly from .profile (ssh sessions) by
> gpg-agent --daemon.

FWIW, actually gpg-agent is started on-demand from all tools requiring
it.  To explicitly start it "gpgconf --launch agent" can and should be
used.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


signature.asc
Description: PGP signature

Bug#922478: upgrade linux-image-4.9.0-8-686 from 4.9.130 to 4.9.144 on ALIX-Board is unbootable

[Werner Opriel]

Hi all.

I'd like to add that 4.9.0-8-686 Version is broken too.
At least for my ALIX-Board ALIX.2D2 from PC Engines.

(CPU: 500 MHz AMD Geode LX800)

W.O.

Bug#896908: busybox cpio: fails to extract absolute symlinks

[Hervé Werner]

This issue has been fixed in the Ubuntu package : 
https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1753572

Regarding debirf, my workaround for now is to replace busybox by the Ubuntu 
package inside the debirf initrd.
rescue/modules/fix-busybox :
#!/bin/bash -e

latest_version=$(curl -fSsL 
https://fr.archive.ubuntu.com/ubuntu/pool/universe/b/busybox/ | \
awk '/busybox/ {match($0, 
/_([[:digit:]\.]+-[[:digit:]]+ubuntu[[:digit:]\.]+)_amd64/, vers); if (vers[1]) 
print vers[1] }' | \
sort -h | tail -n 1)

curl -fSsL -o "${DEBIRF_ROOT}/tmp/busybox-static.deb" 
https://fr.archive.ubuntu.com/ubuntu/pool/main/b/busybox/busybox-static_${latest_version}_amd64.deb
debirf_exec dpkg -i /tmp/busybox-static.deb && rm -f /tmp/busybox-static.deb

Bug#921491: debirf: Broken on usr merged systems

[Hervé Werner]

dpgk-deb also keeps the permissions of the extracted files, so the fix should 
be :
-debirf_exec dpkg -i /var/cache/apt/archives/"$KPKG"
+debirf_exec apt-get install -y binutils xz-utils
+debirf_exec ar x /var/cache/apt/archives/"$KPKG" data.tar.xz
+debirf_exec tar -xp --keep-directory-symlink -f data.tar.xz
+debirf_exec rm -f data.tar.xz

Bug#921491: debirf: Broken on usr merged systems

[Herve Werner]

Package: debirf
Version: 0.38
Severity: important
Tags: patch

Dear Maintainer,

Since usr merge, Debirf no longer works properly.

The issue lays in the install-kernel script :
debirf_exec dpkg --extract /var/cache/apt/archives/"$KPKG" /

This line installs the kernel by extracting it inside the chroot environment.
For some reason, a classic dpkg install can't be done here.

The package linux-image-4.19.0-1-amd64 embeds directory trees and unfortunately
dpkg --extract overwrite the existing /lib symlink in the chroot with its
directory tree. In that state the system is then completely unusable.

>From reading the source code of dpkg it seems that this way of extracting the
inner tar archive embeded in the package is not configurable.

So as a workaround, we can extract the files ourselves and specify the option
--keep-directory-symlink in the tar command :
-debirf_exec dpkg -i /var/cache/apt/archives/"$KPKG"
+debirf_exec apt-get install -y binutils xz-utils
+debirf_exec ar x /var/cache/apt/archives/"$KPKG" data.tar.xz
+debirf_exec tar -x --keep-directory-symlink -f data.tar.xz
+debirf_exec rm -f data.tar.xz



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

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

Versions of packages debirf depends on:
ii  apt  1.8.0~beta1
ii  cpio 2.12+dfsg-6
ii  debootstrap  1.0.114
ii  fakechroot   2.19-3.2
ii  fakeroot 1.23-1
ii  klibc-utils  2.0.4-15
ii  xz-utils 5.2.2-1.3

Versions of packages debirf recommends:
ii  grub-common  2.02+dfsg1-10
ii  lsb-release  10.2018112800
ii  xorriso  1.5.0-1

Versions of packages debirf suggests:
pn  syslinux-common  

-- no debconf information

Bug#914395: [pkg-gnupg-maint] Bug#914395: dirmngr log

[Werner Koch]

On Sun, 25 Nov 2018 22:22, csm...@debian.org said:
> It seems it needs the SRV record and fails wrong without it.
> Checking on the same system looking up that SRV record I get the
> expected NXDOMAIN error.

That seems to be a Debian specific problem; with a dirmngr started by
the gpg command, I get this with master (and pretty sure also with 2.2.11):

  DBG: chan_7 <- KEYSERVER --clear hkp://keyring.debian.org
  DBG: chan_7 -> OK
  DBG: chan_7 <- KS_GET -- 0xDF50FEA5
  DBG: dns: libdns initialized
  DBG: dns: getsrv(_pgpkey-http._tcp.keyring.debian.org) -> 0 records
  DBG: dns: resolve_dns_name(keyring.debian.org): Success
  resolve_dns_addr for 'keyring.debian.org': 'keyring.debian.org' [already 
known]
  resolve_dns_addr for 'keyring.debian.org': 'keyring.debian.org' [already 
known]
  DBG: dns: resolve_dns_name(keyring.debian.org): Success
  DBG: chan_7 -> S SOURCE http://keyring.debian.org:11371
  DBG: (20847 bytes sent via D lines not shown)

Can you please test with

  standard-resolver
  no-use-tor

in dirmngr.conf ?


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpQo0mPcGr38.pgp
Description: PGP signature

Bug#914395: [pkg-gnupg-maint] Bug#914395: Acknowledgement (gpg recv-key fails with no route to host)

[Werner Koch]

On Fri, 23 Nov 2018 00:23, csm...@debian.org said:
> It appears dirmngr tries to lookup a SRV record and that's the no route to
> host error.

Please put this into ~/.gnupg/dirmngr.conf 

--8<---cut here---start->8---
log-file /whatever
verbose
debug ipc,dns,network
--8<---cut here---end--->8---

and best try also with upstream or Sid and not the heavily patched
Debian version.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpaPYSibvVTj.pgp
Description: PGP signature

Bug#913614: [pkg-gnupg-maint] Bug#913614: Bug#913614: gnupg2 fails with "cannot open '/dev/tty': No such device or address"

[Werner Koch]

On Tue, 13 Nov 2018 16:19, tia...@debian.org said:

> Even for something that shouldn't have a reason to prompt, like
> "--recv-keys" with a full fingerprint?

You are right, this should not be needed.  I recall that we recently
fixed a similar case where we accidentally printed to the tty.

In any case --batch is always a good idea if you don't expect any
interactivity.

I agree that this --batch thing is contrary to standard Unix behavior
where you would explicitly need to to select an interactive option.
However, due to the legacy of of PGP and GPG 1.4 we had to use the tty
anyway to query the passphrase and for the dedicated commands like
--edit-key.  For reasons of syncing prompts with tty input more and more
output had to be send to the tty directly and, well, at some places we
got it wrong.  Now, with gpg-agent and its Pinentry, we could have
inhibited the tty access by default and allow it only for interactive
commands.  But then came the request for --pinentry-loopback and the new
Tofu prompts ...

> Would it make sense to detect that there's no TTY present and assume
> batch mode?  (apologies if something like that's been proposed before)

You can't do that in a reliable way.  But let me check whether it is
possible to turn this into a non-fatal error and terminate only when an
input is requested.  Nothing for 2.2, though.

Given dkg's comments, your best choice is to use --no-tty or no-tty in
gpg.conf.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp3Tkj3qXLv1.pgp
Description: PGP signature

Bug#913614: [pkg-gnupg-maint] Bug#913614: gnupg2 fails with "cannot open '/dev/tty': No such device or address"

[Werner Koch]

On Tue, 13 Nov 2018 14:18, be...@debian.org said:

> Passing "--no-tty" to gpg works around this issue.

For any script use you should anyway use --batch which disables the use
of the tty as a side-effect.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpEKDPn6XMXr.pgp
Description: PGP signature

Bug#911559: kicad: pcbnew crashes on reading a eeschema generated netlist

[Werner Frey]

Package: kicad
Version: 5.0.1+dfsg1-2
Severity: important
Tags: upstream

Dear Maintainer,

pcbnew crashes every time when I try to import a netlist generated by eeschema.
Therefore I cannot layout the PCB from my newly developped schematic.
I followed the usual PCB developement path and created a schematic using 
eeschema.
After assigning footprints using CvPcb I generated the netlist (Pcbnew,Standard 
Format).
Then I started Pcbnew (empty board) and tried to read the netlist. Pcbnew 
crashed
immediately and also terminated the whole kicad process.
I'm using a 64-bit kernel on a 32-bit Installation. Using a 32-bit kernel 
(4.4.7) doesn't improve the situation.

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

Kernel: Linux 4.9.134.carme64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kicad depends on:
ii  libc6   2.27-6
ii  libcairo2   1.15.12-1
ii  libcurl47.61.0-1
ii  libfreeimage3   3.17.0+ds1-5+b5
ii  libfreetype62.8.1-2
ii  libgcc1 1:8.2.0-7
ii  libgl1  1.1.0-1
ii  libglew2.0  2.0.0-6
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libice6 2:1.0.9-2
ii  liboce-foundation11 0.18.2-3
ii  liboce-modeling11   0.18.2-3
ii  liboce-ocaf-lite11  0.18.2-3
ii  liboce-ocaf11   0.18.2-3
ii  liboce-visualization11  0.18.2-3
ii  libpixman-1-0   0.34.0-2
ii  libpython2.72.7.15-4
ii  libsm6  2:1.2.2-1+b3
ii  libssl1.1   1.1.0h-4
ii  libstdc++6  8.2.0-7
ii  libwxbase3.0-0v53.0.4+dfsg-4
ii  libwxgtk3.0-0v5 3.0.4+dfsg-4
ii  libx11-62:1.6.7-1
ii  libxext62:1.3.3-1+b2
ii  python  2.7.15-3
ii  python-wxgtk3.0 3.0.2.0+dfsg-8

Versions of packages kicad recommends:
ii  kicad-demos  5.0.1+dfsg1-2
ii  kicad-libraries  5.0.1+dfsg1-2
pn  xsltproc 

Versions of packages kicad suggests:
pn  extra-xdg-menus   
ii  kicad-doc-en  5.0.1+dfsg1-2
pn  kicad-packages3d  

-- no debconf information
GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from pcbnew...Reading symbols from 
/usr/lib/debug/.build-id/cd/9d49317bd89a1819cb648e05e7114723a6bc62.debug...done.
done.
(gdb) run
Starting program: /usr/bin/pcbnew 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
20:49:36: Debug: Checking template path '/usr/share/kicad/template' exists
[New Thread 0xf1b05b40 (LWP 1510)]
[New Thread 0xefe4eb40 (LWP 1511)]
[New Thread 0xef64db40 (LWP 1512)]
[Thread 0xefe4eb40 (LWP 1511) exited]
[New Thread 0xefe4eb40 (LWP 1513)]
[Thread 0xef64db40 (LWP 1512) exited]
[New Thread 0xef64db40 (LWP 1514)]
[Thread 0xefe4eb40 (LWP 1513) exited]
[Thread 0xef64db40 (LWP 1514) exited]
[New Thread 0xef64db40 (LWP 1525)]
[New Thread 0xefe4eb40 (LWP 1526)]
[New Thread 0xe82ffb40 (LWP 1527)]
[New Thread 0xe78ffb40 (LWP 1528)]
[Thread 0xe78ffb40 (LWP 1528) exited]
[Thread 0xe82ffb40 (LWP 1527) exited]
[New Thread 0xe78ffb40 (LWP 1529)]
[New Thread 0xe82ffb40 (LWP 1530)]
[Thread 0xe78ffb40 (LWP 1529) exited]
[Thread 0xe82ffb40 (LWP 1530) exited]
[New Thread 0xe82ffb40 (LWP 1531)]
[New Thread 0xe78ffb40 (LWP 1532)]
[Thread 0xefe4eb40 (LWP 1526) exited]
[Thread 0xe82ffb40 (LWP 1531) exited]
[New Thread 0xe82ffb40 (LWP 1533)]
[Thread 0xe82ffb40 (LWP 1533) exited]
[New Thread 0xe82ffb40 (LWP 1534)]
[New Thread 0xefe4eb40 (LWP 1535)]
[Thread 0xe82ffb40 (LWP 1534) exited]
[New Thread 0xe82ffb40 (LWP 1536)]
[Thread 0xefe4eb40 (LWP 1535) exited]
[New Thread 0xefe4eb40 (LWP 1537)]
[Thread 0xe82ffb40 (LWP 1536) exited]
[Thread 0xefe4eb40 (LWP 1537) exited]
20:50:20: Debug: Loading project 
'/home//kicad/project/RS485_RS232/Converter.pro' settings.
[New Thread 0xefe4eb40 (LWP 1538)]
[New Thread 0xe82ffb40 (LWP 1539)]
[Thread 0xefe4eb40 (LWP 1538) exited]
[New Thread 0xefe4eb40 (LWP 1540)]
[Thread 0xe82ffb40 (LWP 1539) exited]
[New Thread 0xe82ffb40 (LWP 1541)]
[Thread 0xefe4eb40 (LWP 1540) exited]
[Thread 

Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[Werner Koch]

On Tue, 16 Oct 2018 09:51, s...@debian.org said:

> However, none of this solves co-installability in Debian:
> libgpg-error-dev:amd64 and libgpg-error-dev:armhf can't be
> installed at the same time, because they have different content in
> /usr/bin/gpg-error-config, and that will be a problem for as long as

/usr/bin/gpg-error-config should only be used for native building.  For
cross-building it is expected that a dedicated gpg-error-config script
is installed in the root directory of the host platform (e.g. as
/usr/i686-w64-mingw32/bin/gpg-error-config) and only that
gpg-error-config should ever be considered.  In past this required
manual configuration but meanwhile SYSROOT seems to be an accepted
standard and we can make use of it.  This means to only look there for
the config script to get the right version and not take whatever we find
and only print a warning if the platform is wrong.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp3e0bdhz6hy.pgp
Description: PGP signature

Bug#909693: [pkg-gnupg-maint] Bug#909693: gpgsm: seems to be dead slow when verifying pkcs7-signatures from within Sylpheed

[Werner Koch]

On Fri, 28 Sep 2018 00:57, invernom...@paranoici.org said:

> It's clear that the CRL revocation check is the step that takes a long
> time.

Right.  And it depends on the certificate issuer and how they maintain
CRLs.  If they release CRLs only once a week, things should be okay
becuase GnuPG caches them.  However, some CAs are creating new CRLs
every hour or even more often and if they are really long (e.g. by
including expired certifciates, which is silly, but some did this) this
is an effective DoS.

> The man page states that disabling CRL checks is especially intended
> for off-line operations (which is not my case, except for infrequent

Yes, that is the theory.  But in practise CRLs don't work and OCSP is
also not much better.

> So, is disabling CRL checks advisable or not?

How often do you run a "gpg --refresh-key" which is basically the
OpenPGP way for checking for revocations?  Does anyone actually revoke
X.509 certifciates.  Weel, some organisations have their in-house use of
C.509 and they can implement everything properly.  But everything else?
I can't decide.

It might be worth to add a black- or whitelist to our CRL checks or add
an option to violate the nextUpdate field (expiration time) of a CRL and
trigger an update only every few days.  


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp584PyiqB6u.pgp
Description: PGP signature

Bug#909693: [pkg-gnupg-maint] Bug#909693: gpgsm: seems to be dead slow when verifying pkcs7-signatures from within Sylpheed

[Werner Koch]

On Wed, 26 Sep 2018 22:44, invernom...@paranoici.org said:

> While verifying an OpenPGP signature with gpg is definitely fast,
> verifying a pkcs7-signature with gpgsm is super slow.

Sure that it is the verification and not the CRL or OCSP revocation
check?  It dependes on the issuer of the certifciate.  Try with
"disable-crl-checks" in gpgsm.conf?  OCSP check are disabled by default.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpTh1s2D8jTD.pgp
Description: PGP signature

Bug#907810: [pkg-gnupg-maint] Bug#907810: gpg --no-verbose --verify is too verbose

[Werner Koch]

On Mon,  3 Sep 2018 12:52, vinc...@vinc17.net said:

> So, do you mean that it is a bug in Mutt, which doesn't filter them
> out?

Yes, if you don't want to see them.  IIRC, tlr once used a wrapper
process to invoke the actual tool.  I have not used the direct
invocation for 15 years.

Anyway it is better to use crypt_set_gpgme ;-)


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpZScnCNO2b5.pgp
Description: PGP signature

Bug#907810: [pkg-gnupg-maint] Bug#907810: gpg --no-verbose --verify is too verbose

[Werner Koch]

On Sun,  2 Sep 2018 15:18, vinc...@vinc17.net said:

> outputs many [GNUPG:] debugging messages, partly hiding useful output.

These ain't no debugging messages but the required information for any
program or script to interact with gpg.  You have requested them using
the --status-fd option.  Which is the Right Thing to do.  The human
readable output is, well, for humans and not for machine consumption.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpAsr4T6T_sU.pgp
Description: PGP signature

Bug#905221: kicad: pcbnew immediately crashes after invocation without showing a GUI (failed assertion)

[Werner Frey]

Package: kicad
Version: 5.0.0+dfsg1-1
Severity: important
Tags: upstream

Dear Maintainer,

pcbnew aborts immediately after invocation on my i386 Debian Buster 
installation.
The kicad package was freshly installed for the first time.
There were no changes to the default configuration of the package.
When I started pcbnew the very first time a hint window pops up, saying that I 
am
using pcbnew the first time using the new search method for footprints. After I
confirmed the popup by clicking the OK button, the messages below appeared and
pcbnew aborted. On later invocations the popup window doesn't appear and pcbnew
aborts immediatly showing the messages below.

As this behaviour also kills eeschema without any warning  when searching for 
footprints
from within eeschema the complete kicad package is unusable for me.

-
$ pcbnew
16:43:53: Debug: Checking template path '/usr/share/kicad/template' exists
16:43:53: Debug: wxColour::Set - couldn't set to colour string 'NONE'
   ... message repeated 70 times
16:43:53: Debug: wxColour::Set - couldn't set to colour string 'NONE'
pcbnew: /build/kicad-0u70G2/kicad-5.0.0+dfsg1/include/geometry/rtree.h:1643: 
void RTree::Classify(int, int, RTree::PartitionVars*) [with DATATYPE = KIGFX::VIEW_ITEM*; 
ELEMTYPE = int; int NUMDIMS = 2; ELEMTYPEREAL = float; int TMAXNODES = 8; int 
TMINNODES = 4]: Zusicherung !a_parVars->m_taken[a_index] nicht erfllt.
Abgebrochen
-

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.9.116.phobos (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kicad depends on:
ii  libc6   2.27-5
ii  libcairo2   1.15.10-3
ii  libcurl47.60.0-2
ii  libgcc1 1:8.1.0-12
ii  libglew2.0  2.0.0-6
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libglx0 1.0.0+git20180308-3
ii  libgomp18.1.0-12
ii  libopengl0  1.0.0+git20180308-3
ii  libpixman-1-0   0.34.0-2
ii  libpython2.72.7.15-3
ii  libssl1.1   1.1.0h-4
ii  libstdc++6  8.1.0-12
ii  libwxbase3.0-0v53.0.4+dfsg-4
ii  libwxgtk3.0-0v5 3.0.4+dfsg-4
ii  python  2.7.15-3
ii  python-wxgtk3.0 3.0.2.0+dfsg-8

Versions of packages kicad recommends:
ii  kicad-demos  5.0.0+dfsg1-1
ii  kicad-libraries  5.0.0+dfsg1-1
pn  xsltproc 

Versions of packages kicad suggests:
ii  extra-xdg-menus   1.0-4
ii  kicad-doc-en  5.0.0+dfsg1-1
pn  kicad-packages3d  

-- no debconf information

Bug#901498: [pkg-gnupg-maint] Bug#901498: FTBFS on stretch, needs newer libgpg-error

[Werner Koch]

On Thu, 14 Jun 2018 09:14, daniel.baum...@progress-linux.org said:

> when locally backporting gnupg2, I noticed that 2.2.8-1 now FTBFS on
> stretch due to old libgpg-error. Would you mind bumping build-depends

Please apply the attached patch to GnuPG 2.2.8 as suggested by
https://dev.gnupg.org/T4012


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
From 18274db32b5dea7fe8db67043a787578c975de4d Mon Sep 17 00:00:00 2001
From: Werner Koch 
Date: Fri, 8 Jun 2018 22:01:10 +0200
Subject: [PATCH GnuPG] gpg: Allow building with older libgpg-error.

* g10/mainproc.c (proc_encrypted): Use constant from logging.h
--

Because the log levels are enums I had to change there names in
libgpg-error to avoid clashes.  Master uses the new names but 2.2
needs to stick to the old names.

Fixes-commit: 825909e9cd5f344ece6c0b0ea3a9475df1d643de
Signed-off-by: Werner Koch 
---
 g10/mainproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g10/mainproc.c b/g10/mainproc.c
index 72b0dd828..f5cc4532a 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -683,7 +683,7 @@ proc_encrypted (CTX c, PACKET *pkt)
* are rare in practice we print a hint on how to decrypt
* such messages.  */
   log_string
-(GPGRT_LOGLVL_INFO,
+(GPGRT_LOG_INFO,
  _("Hint: If this message was created before the year 2003 it is\n"
"likely that this message is legitimate.  This is because back\n"
"then integrity protection was not widely used.\n"));
-- 
2.11.0



pgpjcNzLcqdEE.pgp
Description: PGP signature

Bug#900247: [pkg-gnupg-maint] Bug#900247: gpg-check-pattern.1: Some formatting changes in the manual

[Werner Koch]

Hi!

The man pages for gnupg are generated from texinfo source using the
yat2m tool.  This is part of GnuPG but we are in the progress of moving
it to libgpg-error (which is a common dependency of all GnuPG stuff).

Thus it would would be better to assign this bug to libgpg-error and
bonus points for adding an issue to dev.gnupg.org.


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp5hwkOjjYnU.pgp
Description: PGP signature