Bug#1058806: HP EliteBook 860 G9 (4C148AV)

[Bjørn Mork]

Paul van der Vlis  writes:

> I've tried it again now and found in the bios an option "use Microsoft
> UEFI CA key". This option was off, when I turn it on the Debian
> installer did start with secure boot on.

Yes, this is a problem with many modern PCs.  Quite frustrating as the
failure mode is without any visible warnings or hints at all.  I hit the
same issue on a Lenovo Thinkpad a while ago:

https://www.mail-archive.com/debian-laptop@lists.debian.org/msg54007.html

I believe this is worth a note in the installation guide.


Bjørn

Bug#990298: conserver-server: console type 'ipmi' is not recognised.

[Bjørn Mork]

Package: conserver-server
Version: 8.2.7-2+b1
Followup-For: Bug #990298
Control: tags -1 patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

I just created a pull request on salsa adding the requested IPMI support:
https://salsa.debian.org/debian/conserver/-/merge_requests/3

Was going to open a wishlist bug with a reference to it when I noticed
that this bug already existed :-)

Good to see that there are others finding this useful.  Please add me
to that list


- -- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (700, 'stable-security'), (700, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages conserver-server depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libc6  2.36-9
ii  libcrypt1  1:4.4.33-2
ii  libgssapi-krb5-2   1.20.1-2
ii  libpam0g   1.5.2-6
ii  libssl33.0.9-1
ii  libwrap0   7.6.q-32
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4

conserver-server recommends no packages.

conserver-server suggests no packages.

- -- Configuration Files:
/etc/conserver/conserver.cf changed [not included]

- -- debconf information:
  conserver-server/upgrade_800_flag: true
  conserver-server/run_as_root: false
  conserver-server/port: 3109
  conserver-server/listen_address:
  conserver-server/base_port:

-BEGIN PGP SIGNATURE-

iGwEARECACwWIQR3fjfc8EF8nPbC0aDXSuqSjBsiyQUCZLJikA4cYmpvcm5AbW9y
ay5ubwAKCRDXSuqSjBsiydNrAJ47d1OMUy+PsfVMOAkGTbNIrnA2RwCff14HGVXB
2xK9Zl+ujgtqDB5ooXg=
=lkL0
-END PGP SIGNATURE-

Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message

[Bjørn Mork]

Salvatore Bonaccorso  writes:

> AFAIK there is no commit upstream with fixes tag on that commit. But
> Bjorn suspects that might be the suspicious commit introducing the
> issue.

Yes, I noticed that, so I could very well be wrong...

But it stood out as the only change to any x86 IOAPIC stuff
since Linux 6.1.0-6-amd64.  That's of course not any guarantee.  But
worth testing.



Bjørn

Bug#1033732: linux-image-6.1.0-7-amd64: The Linux 6.1.0-7-amd64 kernel launching crashes with a panic message

[Bjørn Mork]

Guy Durrieu  writes:

> 
> [ 0.117782] Kernel panic — not syncing: timer doesn’t work through
> Interrupt-
> remapped I0-APIC
> [ 0.117848] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-7-and64 #1
> Debian
> 6.1.20-1
> [ 0.117913] Hardware name: Gigabyte Technology Co., Ltd. ABS50M-Gaming
> 3/AB350M-Gaming 3-CF, BIOS F50d 07/02/2020
> [ 0.117982] Call Trace:
> [ 0.118634] 
> [ 0.118685] dump_stack_lvl+0x44/0x5c
> [ 0.118143] panic+0x118/0x2ed
> [ 0.118198] panic_if_irq_remap.cold+0x5/0x5
> [ 0.118256] setup_I0_APIC+0x3db/0x64b
> [ 0.118313] ? _raw_spin_unlock_irqrestore+0x23/0x40
> [ 0.118372] ? clear_IO_APIC_pin+0x169/0x240
> [ 0.118429] apic_intr_node_init+0x101/0x106
> [ 0.118485] x86_late_time_init+0x20/0x34
> [ 0.118542] start_kerne1+0x667/0x727
> [ 0.118598] secondary_startup_64_no_verify+0xe5/0xeb
> [ 0.118658] 
> [ 0.118711] ---[ end Kernel panic - not syncing: timer doesn’t work through
> Interrupt-remapped IO-APIC J---
> 

Extremely suspiscious commit in the v6.1.15..v6.1.20 update:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=ce7d894bed1a539a8d6cff42f6f78f9db0c9c26b



Bjørn

Bug#1022022: New btusb hardware IDs (MT7922, MT7921, others)

[Bjørn Mork]

Chris Hofstaedtler  writes:
> * Diederik de Haas  [221019 00:07]:
>> On dinsdag 18 oktober 2022 23:44:17 CEST Chris Hofstaedtler wrote:
>> > it appears quite some new btusb hardware was released recently.
>> > linux-next has a lot of simple "Add xyz ID" patches for btusb.c:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/driv
>> > ers/bluetooth/btusb.c
>> > 
>> > Please consider applying 57117d7234dadfba2a83615b2a9369f6f2f9914f
>> > and/or the other patches adding new hwids to btusb.c for the
>> > bookworm kernel.
>> 
>> It's already part of Linux 6.1-rc1 and it is expected that 6.1 will be the
>> next LTS release and I'd guess thus also the Bookworm kernel.
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/bluetooth?h=v6.1-rc1
>
> Right, that'd be good. I've manually applied
> 57117d7234dadfba2a83615b2a9369f6f2f9914f against 5.9.11-1, and that
> works for me; but only after making available
> BT_RAM_CODE_MT7922_1_1_hdr.bin from linux-firmware.git.

If this is a simple device ID addition without any other dependencies,
then it qualifies for Linux stable.  And you'll get it in Debian stable
for free.

New device ID patches are regularily backported to the maintained stable
kernels, and usually picked up automatically by the stable maintainers.
You can request a backport of a specific commit in mainline by sending
an email to sta...@vger.kernel.org

See https://docs.kernel.org/process/stable-kernel-rules.html


Bjørn

Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.

[Bjørn Mork]

Hank Barta  writes:

> ** Kernel log:
> [  723.735217] mmc0: sdhci: Timeout:   0x | Int stat: 0x00018000
> [  723.741743] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
> [  723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001
> [  723.754797] mmc0: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
> [  723.761324] mmc0: sdhci: Cmd:   0x0502 | Max curr: 0x00080008
> [  723.767851] mmc0: sdhci: Resp[0]:   0x01aa | Resp[1]:  0x
> [  723.774379] mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
> [  723.780905] mmc0: sdhci: Host ctl2: 0x
> [  723.785404] mmc0: sdhci: ADMA Err:  0x | ADMA Ptr: 0x
> [  723.791930] mmc0: sdhci: 
> [  733.923993] mmc0: Timeout waiting for hardware cmd interrupt.

These repeated messages are normal on the RPi4 if you boot it without an
SD card.  E.g. from USB or network.  If that's what you intend to do,
then you can avoid the repeated messages by adding

 dtparam=sd_poll_once=on

to the config.txt file in your firmware partition.  Often mounted as
/boot/firmware/.

The effect depends on which device-tree you are using.  I believe it
will only work with the ones coming with the Raspberry Pi firmware.  See

https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README

for docs.


Bjørn

Bug#1008829: pysrs-bin: envfrom2srs and srs2envtol fails with ModuleNotFoundError: No module named 'ConfigParser'

[Bjørn Mork]

Hefee  writes:

>> Why do you insist on keeping broken packages in Debian?
>
> because pysrs is more than these two scripts - the core part is the python 
> library supporting handle SRS.

Please read the subject and/or "Package" field before replying.  This is
what I reported as broken:

 Package: pysrs-bin
 Version: 1.0.3-2
 Severity: grave
 Justification: renders package unusable


The bug report is against pysrs-bin. This package contains nothing but
those two "examples":

bjorn@miraculix:~$ apt-file show pysrs-bin
pysrs-bin: /usr/bin/envfrom2srs   
pysrs-bin: /usr/bin/srs2envtol
pysrs-bin: /usr/share/doc/pysrs-bin/NEWS.Debian.gz
pysrs-bin: /usr/share/doc/pysrs-bin/changelog.Debian.gz
pysrs-bin: /usr/share/doc/pysrs-bin/changelog.gz
pysrs-bin: /usr/share/doc/pysrs-bin/copyright
pysrs-bin: /usr/share/man/man1/envfrom2srs.1.gz
pysrs-bin: /usr/share/man/man1/srs2envtol.1.gz


>> Sorry.  What's the less offensice way to describe broken and untested?
>
> Just telling it is broken is fine. But saying it is crap and ask directly for 
> removal is offensive.

Sure.  Which is one of the reasons I did NOT say that it is crap. I find
your usage of such straw-man arguments extremely offensive.  "crap" is
your description and yours only.

Your package is broken. It contains nothing but two broken scripts.
This is a simple fact and I don't know how else to express it.

"Untested" is my assumption only. and I should probably not have made
that.  But it's really an assumption of good faith in this context.  The
only alternative I see is that you're packaging known failing scripts.

Removal of a package conaining ONLY broken scripts and nothing else is a
no-brainer.  It's Debian policy.

> I try not to ship broken packages on purpose, but I'm just a human make 
> mistakes and don't have the time to test everything.

Well, that's simple:  You do not have to package everything.

I do not have time to install, test and then remove broken packages.
Assumng that I and other Debian users should do testing for you is
arrogant.  Your time is not worth more than mine.

Reporting this bug wasted even more time.  I did that to help other
Debian users avoid the same problem.  Your package is a policy
violation. You have so far not done anything to fix that, which is
very disappointing.


Bjørn

Bug#1008829: pysrs-bin: envfrom2srs and srs2envtol fails with ModuleNotFoundError: No module named 'ConfigParser'

[Bjørn Mork]

Hefee  writes:

> Control: severity -1 normal

Why do you insist on keeping broken packages in Debian?

>> # envfrom2srs
>> Traceback (most recent call last):
>>   File "/usr/bin/envfrom2srs", line 14, in 
>> from ConfigParser import ConfigParser, DuplicateSectionError
>> ModuleNotFoundError: No module named 'ConfigParser'
>> 
>> # srs2envtol
>> Traceback (most recent call last):
>>   File "/usr/bin/srs2envtol", line 14, in 
>> from ConfigParser import ConfigParser, DuplicateSectionError
>> ModuleNotFoundError: No module named 'ConfigParser'
>>
>> No need to clutter the archive with broken and untested packages.
>> Please remove
>
> can you please use a less offensive language. 

Sorry.  What's the less offensice way to describe broken and untested?

> It is only the two example scripts, that are not properly ported to Python 3.

You are installing known broken examples in $PATH? But why!  

Well, whatever.  Thanks for not caring about quality


Bjørn

Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)

[Bjørn Mork]

Cyril Brulebois  writes:

> Cyril Brulebois  (2022-04-29):
>> > I'll try and pinpoint when it broke using the various intermediary
>> > versions:
>> > 
>> >  - 5.17~rc3-1~exp1
>> 
>> The first attempt was sufficient: it breaks as early as that version.
>
> Using the same base image as before, and only updating the kernel: I've
> tested upstream builds, starting from the .config found in the Debian
> 5.16.18-1 package, using oldconfig and accepting everything by default:
>
>  - v5.16 is confirmed a first good;
>  - v5.17-rc1 is confirmed a first bad;
>  - the culprit seems to be 3ceff4ea07410763d5d4cccd60349bf7691e7e61

But that's a merge commit. Not likely the real cuplrit, unless there's a
merge bug.

I looked briefly at what was merged there, and I believe this commit
stands out as suspicious:

bjorn@miraculix:/usr/local/src/git/linux$ git show f59f6aaead97
commit f59f6aaead975f0ec4d8ff2d59c4ffb8cf0127b2
Author: Arnd Bergmann 
Date:   Mon Nov 22 23:21:56 2021 +0100

mmc: bcm2835: stop setting chan_config->slave_id

The field is not interpreted by the DMA engine driver, as all the data
is passed from devicetree instead. Remove the assignment so the field
can eventually be deleted.

Reviewed-by: Nicolas Saenz Julienne 
Signed-off-by: Arnd Bergmann 
Acked-by: Ulf Hansson 
Acked-by: Mark Brown 
Link: https://lore.kernel.org/r/2021112203.4103644-5-a...@kernel.org
Signed-off-by: Vinod Koul 

diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
index 8c2361e66277..463b707d9e99 100644
--- a/drivers/mmc/host/bcm2835.c
+++ b/drivers/mmc/host/bcm2835.c
@@ -1293,14 +1293,12 @@ static int bcm2835_add_host(struct bcm2835_host *host)
 
host->dma_cfg_tx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
host->dma_cfg_tx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   host->dma_cfg_tx.slave_id = 13; /* DREQ channel */
host->dma_cfg_tx.direction = DMA_MEM_TO_DEV;
host->dma_cfg_tx.src_addr = 0;
host->dma_cfg_tx.dst_addr = host->phys_addr + SDDATA;
 
host->dma_cfg_rx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
host->dma_cfg_rx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   host->dma_cfg_rx.slave_id = 13; /* DREQ channel */
host->dma_cfg_rx.direction = DMA_DEV_TO_MEM;
host->dma_cfg_rx.src_addr = host->phys_addr + SDDATA;
host->dma_cfg_rx.dst_addr = 0;


But I'm basing that only on it being related to the bcm28/27xx SoCs and
a bit unexpected in the sound merge...  I cannot explain why this mmc
host driver change should affect your display.  Could be completely
wrong.  But migt be worth testing?



Bjørn

Bug#1008829: pysrs-bin: envfrom2srs and srs2envtol fails with ModuleNotFoundError: No module named 'ConfigParser'

[Bjørn Mork]

Package: pysrs-bin
Version: 1.0.3-2
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

# envfrom2srs
Traceback (most recent call last):
  File "/usr/bin/envfrom2srs", line 14, in 
from ConfigParser import ConfigParser, DuplicateSectionError
ModuleNotFoundError: No module named 'ConfigParser'

# srs2envtol
Traceback (most recent call last):
  File "/usr/bin/srs2envtol", line 14, in 
from ConfigParser import ConfigParser, DuplicateSectionError
ModuleNotFoundError: No module named 'ConfigParser'

No need to clutter the archive with broken and untested packages.
Please remove

- -- System Information:
Debian Release: 11.3
  APT prefers stable-security
  APT policy: (700, 'stable-security'), (700, 'stable'), (699, 'stable-updates')
Architecture: amd64 (x86_64)

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

Versions of packages pysrs-bin depends on:
ii  python3  3.9.2-3
ii  python3-srs  1.0.3-2

pysrs-bin recommends no packages.

pysrs-bin suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iGwEARECACwWIQR3fjfc8EF8nPbC0aDXSuqSjBsiyQUCYkgktA4cYmpvcm5AbW9y
ay5ubwAKCRDXSuqSjBsiyUJdAJ4zvzZBL6hIfzScL01SNMcAQDNSEQCfZZJU9yuy
jyC6TtdcMxqBEPpi278=
=yarJ
-END PGP SIGNATURE-

Bug#1008828: python3-spf-engine: fails with ImportError: cannot import name 'own_socketfile' from 'spf_engine.util'

[Bjørn Mork]

Package: python3-spf-engine
Version: 2.9.2-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

Installing pyspf-milter with default dependencies and settings results
in

# journalctl -u pyspf-milter
- -- Journal begins at Sat 2022-03-26 15:26:01 CET, ends at Sat 2022-04-02 
12:11:13 CEST. --
Apr 02 12:04:07 canardo systemd[1]: Started pySPF Milter.
Apr 02 12:04:07 canardo pyspf-milter[372481]: Traceback (most recent call last):
Apr 02 12:04:07 canardo pyspf-milter[372481]: Traceback (most recent call last):
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File "/usr/bin/pyspf-milter", 
line 11, in 
Apr 02 12:04:07 canardo pyspf-milter[372481]: 
load_entry_point('spf-engine==2.9.2', 'console_scripts', 'pyspf-milter')()
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 474, in 
load_entry_point
Apr 02 12:04:07 canardo pyspf-milter[372481]: return 
get_distribution(dist).load_entry_point(group, name)
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2846, in 
load_entry_point
Apr 02 12:04:07 canardo pyspf-milter[372481]: return ep.load()
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2450, in load
Apr 02 12:04:07 canardo pyspf-milter[372481]: return self.resolve()
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2456, in 
resolve
Apr 02 12:04:07 canardo pyspf-milter[372481]: module = 
__import__(self.module_name, fromlist=['__name__'], level=0)
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/spf_engine/milter_spf.py", line 40, in 
Apr 02 12:04:07 canardo pyspf-milter[372481]: from spf_engine.util import 
own_socketfile
Apr 02 12:04:07 canardo pyspf-milter[372481]: ImportError: cannot import name 
'own_socketfile' from 'spf_engine.util' 
(/usr/lib/python3/dist-packages/spf_engine/util.py)
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File "/usr/bin/pyspf-milter", 
line 11, in 
  
load_entry_point('spf-engine==2.9.2', 'console_scripts', 'pyspf-milter')()
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 474, in 
load_entry_point
  return 
get_distribution(dist).load_entry_point(group, name)
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2846, in 
load_entry_point
  return ep.load()
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2450, in load
  return self.resolve()
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2456, in 
resolve
  module = 
__import__(self.module_name, fromlist=['__name__'], level=0)
Apr 02 12:04:07 canardo pyspf-milter[372481]:   File 
"/usr/lib/python3/dist-packages/spf_engine/milter_spf.py", line 40, in 
  from spf_engine.util import 
own_socketfile
Apr 02 12:04:07 canardo pyspf-milter[372481]: ImportError: cannot import name 
'own_socketfile' from 'spf_engine.util' 
(/usr/lib/python3/dist-packages/spf_engine/util.py)
Apr 02 12:04:07 canardo systemd[1]: pyspf-milter.service: Main process exited, 
code=exited, status=1/FAILURE
Apr 02 12:04:07 canardo systemd[1]: pyspf-milter.service: Failed with result 
'exit-code'.


No need to clutter the archive with completely broken and untested packages.


- -- System Information:
Debian Release: 11.3
  APT prefers stable-security
  APT policy: (700, 'stable-security'), (700, 'stable'), (699, 'stable-updates')
Architecture: amd64 (x86_64)

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

Versions of packages python3-spf-engine depends on:
ii  python3  3.9.2-3
ii  python3-authres  1.2.0-2
ii  python3-spf  2.0.14-2

python3-spf-engine recommends no packages.

python3-spf-engine suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iGwEARECACwWIQR3fjfc8EF8nPbC0aDXSuqSjBsiyQUCYkgi8Q4cYmpvcm5AbW9y
ay5ubwAKCRDXSuqSjBsiyarCAKCAzlYvQ8KoeYFTwu57/rcZUaVWZgCeJh9IDyHM
qzAsx/mDicjW7tkbafU=
=TY8J
-END PGP SIGNATURE-

Bug#1006729: nullmailer: Add "AUTH EXTERNAL" option for certificate authentication

[Bjørn Mork]

Package: nullmailer
Version: 1:2.2-3
Severity: wishlist
Tags: upstream patch
Forwarded: https://github.com/bruceg/nullmailer/pull/80

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please implement AUTH EXTERNAL so that nullmailer can be used against smarthosts
using client certificate authentication.

- -- System Information:
Debian Release: 11.2
  APT prefers stable-security
  APT policy: (700, 'stable-security'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages nullmailer depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.33-7
ii  libgnutls303.7.1-5
ii  libstdc++6 12-20220302-1
ii  lsb-base   11.1.0

nullmailer recommends no packages.

nullmailer suggests no packages.

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iIQEARYKACwWIQRoe+CASfFh7aZ6shIiBE7Lv6RhXQUCYiEKFA4cYmpvcm5AbW9y
ay5ubwAKCRAiBE7Lv6RhXcLDAP9Z0NUpxoKfy36rRhvDIjm8F2+aJTNNaafT0WJv
/7igrAD9GHVq8kfxD5jw+E2yf5luSxqEilDsBZv4SZlf45VfvAg=
=KDfF
-END PGP SIGNATURE-

Bug#1002465: /boot/vmlinuz-5.10.0-10-amd64: btusb: CSR clone fails with "debugfs: File 'dut_mode' in directory 'hci1' already present!"

[Bjørn Mork]

Package: src:linux
Version: 5.10.84-1
Severity: normal
File: /boot/vmlinuz-5.10.0-10-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Just got a couple of CSR clones of a type I haven't tried before.  Unfortunately
they fail with  the error message:

  "debugfs: File 'dut_mode' in directory 'hci1' already present!"

Kernel log after plugging in:

usb 1-1: new high-speed USB device number 7 using xhci_hcd
usb 1-1: New USB device found, idVendor=0fce, idProduct=31f4, bcdDevice= 4.04
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: G8441
usb 1-1: Manufacturer: Sony
usb 1-1: SerialNumber: BH901MPJ9E
usb 1-1: USB disconnect, device number 7
usb 1-1: new high-speed USB device number 8 using xhci_hcd
usb 1-1: New USB device found, idVendor=0fce, idProduct=51f4, bcdDevice= 4.04
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: G8441
usb 1-1: Manufacturer: Sony
usb 1-1: SerialNumber: BH901MPJ9E
usb 1-1: USB disconnect, device number 8
8021q: adding VLAN 0 to HW filter on device wwan0
input: WH-1000XM4 (AVRCP) as /devices/virtual/input/input29
usb 1-3: new full-speed USB device number 9 using xhci_hcd
usb 1-3: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
usb 1-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 1-3: Product: BT DONGLE10
Bluetooth: hci1: CSR: Unbranded CSR clone detected; adding workarounds...

Controller shows up:

root@miraculix:/tmp# hciconfig hci1
hci1:   Type: Primary  Bus: USB
BD Address: 00:1A:7D:DA:71:13  ACL MTU: 679:8  SCO MTU: 48:16
DOWN 
RX bytes:734 acl:0 sco:0 events:24 errors:0
TX bytes:74 acl:0 sco:0 commands:24 errors:0

But trying to bring it up results in:

root@miraculix:/tmp# hciconfig hci1 up
Can't init device hci1: Invalid argument (22)


and the workaround messages is repeated in the kernel log along with the
new error message:

 Bluetooth: hci1: CSR: Unbranded CSR clone detected; adding workarounds...
 debugfs: File 'dut_mode' in directory 'hci1' already present!

The debugfs file *is* already present prior to this. Trying to trick the
system by unmounting debugfs does not help - as expected, I guess.  The
duplicate file registration is still running.

Looks like the adapter initialisation is running twice for some reason?

This is the full lsusb -v dump for this device:



Bus 001 Device 009: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle 
(HCI mode)
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  224 Wireless
  bDeviceSubClass 1 Radio Frequency
  bDeviceProtocol 1 Bluetooth
  bMaxPacketSize064
  idVendor   0x0a12 Cambridge Silicon Radio, Ltd
  idProduct  0x0001 Bluetooth Dongle (HCI mode)
  bcdDevice   88.91
  iManufacturer   0 
  iProduct2 BT DONGLE10
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x00b1
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   224 Wireless
  bInterfaceSubClass  1 Radio Frequency
  bInterfaceProtocol  1 Bluetooth
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   224 

Bug#998308: /usr/bin/drill: drill does not respect the /etc/resolv.conf nameserver order

[Bjørn Mork]

Package: ldnsutils
Version: 1.7.1-2+b1
Severity: normal
File: /usr/bin/drill

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

NetworkManager will add nameservers for all connected links to /etc/resolv.conf
using the same priority given to the associated default routes.  Name servers
are often only usable on the link they are associated with.  But this scheme
works fine with libc since it strictly obeys the order given in /etc/resolv.conf
It will therefore only use the topmost entries, which happen to be associated
with the link with the lowest default route metric.

This is the documented behaviour in debian.  Quoting from resolv.conf(5)

   nameserver Name server IP address
  Internet address of a name server that the resolver should query, 
either
  an IPv4 address (in dot notation), or an IPv6 address in colon 
(and pos‐
  sibly dot) notation as per RFC 2373.  Up to MAXNS (currently 3, 
see ) name servers may be listed, one per keyword.  If there 
are mul‐
  tiple  servers,  the  resolver library queries them in the order 
listed.

However, drill seems to use all entries in a random(?) order.  Or at least in 
an order
which changes from one run to another, causing failures which come and go 
depending on
whether the nameserver works on the primary link or not.

Simple example from my laptop, having both wlan0 and wwan0 connected:

bjorn@miraculix:~$ cat /etc/resolv.conf
# Generated by NetworkManager
search corp.telenor.no
nameserver 148.122.16.253
nameserver 148.122.164.253
nameserver 2001:4600:4:fff::52
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2001:4600:4:1fff::52
nameserver 193.213.112.4
nameserver 130.67.15.198
bjorn@miraculix:~$ ip route
default via 10.168.72.1 dev wlan0 proto dhcp metric 600 
default via 10.213.245.177 dev wwan0 proto static metric 700 
10.168.72.0/24 dev wlan0 proto kernel scope link src 10.168.72.206 metric 600 
10.213.245.160/27 dev wwan0 proto kernel scope link src 10.213.245.176 metric 
700 
bjorn@miraculix:~$ ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2a02:2121:283:c2fb::/64 dev wwan0 proto kernel metric 256 pref medium
2a02:2121:283:c2fb::/64 dev wwan0 proto kernel metric 700 pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
fe80::/64 dev tap0.42 proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 600 pref medium
default via 2a02:2121:283:c2fb:89c8:30a8:6eff:bb2e dev wwan0 proto static 
metric 700 pref medium
default via fe80::89c8:30a8:6eff:bb2e dev wwan0 proto ra metric 1024 expires 
61681sec hoplimit 255 pref medium


stracing drill shows that it uses name servers from the whole list, including
entries below the 3 server cutoff,  in an arbitrary order:

bjorn@miraculix:~$ strace -f -e sendto /usr/bin/drill -S debian.org
;; Number of trusted keys: 1
sendto(3, "\373\213\1\20\0\1\0\0\0\0\0\1\6debian\3org\0\0\1\0\1\0\0)\20"..., 
39, 0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("193.213.112.4")}, 16) = 39
;; Chasing: debian.org. A
sendto(3, "\347\212\1\20\0\1\0\0\0\0\0\1\6debian\3org\0\\0\1\0\0)\20"..., 
39, 0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("130.67.15.198")}, 16) = 39
sendto(3, "\357@\1\20\0\1\0\0\0\0\0\1\6debian\3org\0\0+\0\1\0\0)\20"..., 39, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("148.122.164.253")}, 
16) = 39
sendto(3, "!\317\1\20\0\1\0\0\0\0\0\1\3org\0\\0\1\0\0)\20\0\0\0\200\0\0\0", 
32, 0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("148.122.16.253")}, 16) = 32
sendto(3, "\327$\1\20\0\1\0\0\0\0\0\1\3org\0\0+\0\1\0\0)\20\0\0\0\200\0\0\0", 
32, 0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("148.122.164.253")}, 16) = 32
sendto(3, "\320\300\1\20\0\1\0\0\0\0\0\1\0\\0\1\0\0)\20\0\0\0\200\0\0\0", 
28, 0, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("193.213.112.4")}, 16) = 28
sendto(3, "\212\177\1\20\0\1\0\0\0\0\0\1\0\0+\0\1\0\0)\20\0\0\0\200\0\0\0", 28, 
0, {sa_family=AF_INET6, sin6_port=htons(53), sin6_flowinfo=htonl(0), 
inet_pton(AF_INET6, "2001:4600:4:fff::52", _addr), sin6_scope_id=0}, 28) = 
28
sendto(3, "

Bug#998069: openssh-server: sshd_config(5) documentation of ListenAddress refers to OpenBSD only option "rdomain"

[Bjørn Mork]

Package: openssh-server
Version: 1:8.4p1-5
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The sshd_config(5) manual page refers to an optional "[rdomain domain]"
qualifier for ListenAddress, with a pointer to the non-existing
rdomain(4) manual page for further informaion.

This is leaking OpenBSD only features and should be removed from any
Linux build.  See https://bugzilla.mindrot.org/show_bug.cgi?id=3126
for more information


Bjørn

- -- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (700, 'stable-security'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  libaudit1  1:3.0-2
ii  libc6  2.31-13+deb11u2
ii  libcom-err21.46.2-2
ii  libcrypt1  1:4.4.18-4
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
ii  libkrb5-3  1.18.3-6+deb11u1
ii  libpam-modules 1.4.0-9+deb11u1
ii  libpam-runtime 1.4.0-9+deb11u1
ii  libpam0g   1.4.0-9+deb11u1
ii  libselinux13.1-3
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libsystemd0247.3-6
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0
ii  openssh-client 1:8.4p1-5
ii  openssh-sftp-server1:8.4p1-5
ii  procps 2:3.3.17-5
ii  runit-helper   2.10.3
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  247.3-6
ii  ncurses-term 6.2+20201114-2
ii  xauth1:1.1-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

- -- debconf information:
  openssh-server/password-authentication: true
  openssh-server/permit-root-login: false

-BEGIN PGP SIGNATURE-

iIQEARYKACwWIQRoe+CASfFh7aZ6shIiBE7Lv6RhXQUCYXvilw4cYmpvcm5AbW9y
ay5ubwAKCRAiBE7Lv6RhXQHBAP0Yq4s3PrY+kYCZ23zGXcvRudCWprq1XVDTgHyH
LpbxYgEAgmAATmPssszolOQW9SscIujGWFkye7ZhjS+zuSN2GQo=
=gfU+
-END PGP SIGNATURE-

Bug#992997: milter-greylist: segfault in libGeoIP

[Bjørn Mork]

Sudip Mukherjee  writes:

> I just updated the package to latest 4.6.4, can you please try with that
> and check if you still get the same problem. If you still the same problem
> the a coredump or some way to reproduce the problem will be needed.

Thanks. I've not seen the problem since I installed version 4.6.4-1 so
you may close this bug as you find appropriate.

Looking at the upstream changelog I noticted this entry under 4.6.3:
..
Fix crash when GeoIP for IPv6 is not configured (Paul Howarth)

And that could very well have been the issue.  The server is dual-stack,
but I only had

 geoipdb "/usr/share/GeoIP/GeoIP.dat"

in /etc/milter-greylist/greylist.conf and no geoipv6db entry.



Bjørn

Bug#990868: lenovo T460 Shutdown Problem

[Bjørn Mork]

Faustin Lammler  writes:

> Hi!
> I seem to have the same problem on my T460s and it is impossible to
> suspend the laptop (lid close or systemctl suspend).
>
> As far as I can remember, the problem appeared with kernel 5 branch (bpo
> on buster).
>
> At that time I did not wanted to open a bug report because I was not
> sure of my installation (dist-upgrade from buster, plus lots of bpo
> kernel installation and test) and I had found a workaround for the
> suspend problem, using those commands after reboot:
> | echo reboot >/sys/power/disk
> | echo disk >/sys/power/state
>
> Now I have a clean Debian 11 installation and both suspend and poweroff
> does not work anymore.

This sounds like https://bugs.debian.org/949020

Short version: Disable TPM 2.0 (select 1.2) i BIOS, or disable IOMMU by
booting with intel_iommu=off on the command line.


Bjørn

Bug#992723: rtl-433: spewing debug log in a tight loop on USB errors

[Bjørn Mork]

Package: rtl-433
Version: 20.11-1
Severity: normal

Dear Maintainer,

This version of rtl-433 will spew out two log lines in a very tight loop
after some USB cable issues.  This is
https://github.com/merbanan/rtl_433/issues/1581
which was fixed by
https://github.com/merbanan/rtl_433/commit/405df88533d3f10ed0f348c2b77d8e531f4f3c04
in 21.05.

I still think the issue is severe enough to warrant a backport to the current
stable version.  I just had an episode causing a steady 40 Mbits/s stream of
log messages to my syslog server...  That's not nice.



-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, 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)

Versions of packages rtl-433 depends on:
ii  libc6   2.31-13
ii  librtlsdr0  0.6.0-3
ii  libsoapysdr0.7  0.7.2-2
ii  libusb-1.0-02:1.0.24-3

rtl-433 recommends no packages.

rtl-433 suggests no packages.

-- no debconf information

Bug#992400: fetchmail: segfault with specific .fetchmailrc

[Bjørn Mork]

Package: fetchmail
Version: 6.4.16-4
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

fetchmail started SEGFAULTing after upgrading from buster to
bullseye. This is an example config which causes this: 


test@canardo:~$ cat .fetchmailrc 
set invisible
defaults
  proto pop3
  uidl
  no envelope
poll pop.example.com
  user foo with pass bar is test here


Note that the example can be uses as-is.  The server and
user does not need to exist.  fetchmail crashes on parsing
before trying to lookup servername or anything:

test@canardo:~$ strace -f fetchmail 2>&1|tail -10
openat(AT_FDCWD, "/home/test/.fetchmailrc", O_RDONLY) = 3
ioctl(3, TCGETS, 0x7ffdf5799df0)= -1 ENOTTY (Inappropriate ioctl for 
device)
fstat(3, {st_mode=S_IFREG|0600, st_size=116, ...}) = 0
read(3, "set invisible\ndefaults\n  proto p"..., 8192) = 116
read(3, "", 4096)   = 0
read(3, "", 8192)   = 0
ioctl(3, TCGETS, 0x7ffdf5799df0)= -1 ENOTTY (Inappropriate ioctl for 
device)
close(3)= 0
- --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
si_addr=0xffe0} ---
+++ killed by SIGSEGV +++



Moving the settings from "defaults" to the server section
works around the issue.  But this is a regression since that
exact configuration has worked for 5+ years over several
earlier fetchmail versions.  An incomplete list of versions
where this used to work:

6.3.26-1+b1
6.3.26-3
6.4.0~beta4-3
6.4.0~beta4-3+deb10u1


Bjørn

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

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

Versions of packages fetchmail depends on:
ii  adduser   3.118
ii  debianutils   4.11.2
ii  libc6 2.31-13
ii  libcom-err2   1.46.2-2
ii  libgssapi-krb5-2  1.18.3-6
ii  libkrb5-3 1.18.3-6
ii  libssl1.1 1.1.1k-1
ii  lsb-base  11.1.0

Versions of packages fetchmail recommends:
ii  ca-certificates  20210119

Versions of packages fetchmail suggests:
pn  fetchmailconf
pn  resolvconf   
ii  sendmail-bin [mail-transport-agent]  8.15.2-22

- -- Configuration Files:
/etc/default/fetchmail [Errno 13] Permission denied: '/etc/default/fetchmail'

- -- no debconf information

-BEGIN PGP SIGNATURE-

iGwEARECACwWIQR3fjfc8EF8nPbC0aDXSuqSjBsiyQUCYRy0dw4cYmpvcm5AbW9y
ay5ubwAKCRDXSuqSjBsiyVCTAJ4v7DrZ98/7DtKupSW4SBJpCAzUpACeIgMHjYv1
rWGfcVwz9Tlly+d30L4=
=iC7Z
-END PGP SIGNATURE-

Bug#987778: texlive-latex-extra: fails to declare dependency on libspreadsheet-parseexcel-perl

[Bjørn Mork]

Package: texlive-latex-extra
Version: 2020.20210202-3
Severity: serious
Justification: Policy 3.5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


libspreadsheet-parseexcel-perl is required to run the exceltex
binary, but is not declared as a dependency. 

 bjorn@miraculix:~$ exceltex 
 Can't locate Spreadsheet/ParseExcel.pm in @INC (you may need to install the 
Spreadsheet::ParseExcel module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 
/usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 
/usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/bin/exceltex line 738.
 BEGIN failed--compilation aborted at /usr/bin/exceltex line 738.


- -- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

lrwxrwxrwx 1 root root 31 Feb 17 21:30 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
- -rw-r--r-- 1 root root 475 Feb 23 16:50 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb 17 21:30 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Feb 17 21:30 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
- -rw-r--r-- 1 root root 2763 Apr  5 10:45 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
- -rw-r--r-- 1 root root 283 Feb 22  2016 mktex.cnf
- -rw-r--r-- 1 root root 475 Feb 23 16:50 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-latex-extra depends on:
ii  libcommons-logging-java1.2-2
ii  libpdfbox-java 1:1.8.16-2
ii  preview-latex-style12.2-1
ii  python33.9.2-3
ii  tex-common 6.16
ii  texlive-base   2020.20210202-3
ii  texlive-binaries   2020.20200327.54578-7
ii  texlive-latex-recommended  2020.20210202-3
ii  texlive-pictures   2020.20210202-3

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2020.20210202-3
ii  texlive-plain-generic  2020.20210202-3

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.23-1
ii  libspreadsheet-parseexcel-perl  0.6500-1.1
ii  python3-pygments2.7.1+dfsg-2
pn  texlive-latex-extra-doc 

Versions of packages tex-common depends on:
ii  dpkg  1.20.9
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.3.4

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.16
ii  texlive-binaries  2020.20200327.54578-7

- -- no debconf information

Bug#977804: xscreensaver: systemd integration conflicts with existing Xsession based activation

[Bjørn Mork]

Package: xscreensaver
Version: 5.44+dfsg1-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The latest xsreensaver is broken, failing to start on a system where it was
configured to start without the systemd unit.

I endend up with a zombie instead of the expected daemon:

 bjorn@miraculix:~$ ps aux|grep xscreen
 bjorn   2784  0.0  0.0  0 0 ?ZDec20   0:00 
[xscreensaver] 


FWFW, I have "always" been running xscreensaver from a script in
/etc/X11/Xsession.d/ with automatic activation on suspend controlled by
some power manager application.  This has worked fine both before and
after switching to systemd.  

Masking the unnecessary systemd unit fixes the issue for me. This
should probably be the default as long as there is no way to do
systemd integration without breaking existing configurations.


Bjørn

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.60
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-5
ii  libcrypt11:4.4.17-1
ii  libglade2-0  1:2.6.4-2.3
ii  libglib2.0-0 2.66.3-2
ii  libgtk2.0-0  2.24.32-5
ii  libpam0g 1.3.1-5
ii  libpango-1.0-0   1.46.2-3
ii  libsystemd0  247.1-3
ii  libx11-6 2:1.6.12-1
ii  libxext6 2:1.3.3-1+b2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxmu6  2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxt6   1:1.2.0-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.44+dfsg1-2

Versions of packages xscreensaver recommends:
ii  libjpeg-turbo-progs   1:2.0.5-1.1
ii  perl  5.32.0-5
ii  wamerican [wordlist]  2019.10.06-1

Versions of packages xscreensaver suggests:
ii  chromium [www-browser] 83.0.4103.116-3.1+b2
ii  firefox [www-browser]  84.0-3
ii  firefox-esr [www-browser]  78.5.0esr-1
pn  fortune
pn  gdm3 | kdm-gdmcompat   
ii  lynx [www-browser] 2.9.0dev.6-1
pn  qcam | streamer
ii  w3m [www-browser]  0.5.3-38+b1
pn  xdaliclock 
pn  xfishtank  
pn  xscreensaver-data-extra
pn  xscreensaver-gl
pn  xscreensaver-gl-extra  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIQEARYKACwWIQRoe+CASfFh7aZ6shIiBE7Lv6RhXQUCX+BTFA4cYmpvcm5AbW9y
ay5ubwAKCRAiBE7Lv6RhXX8CAP96e9hG5HeBZkbwNHndpc+Xx6TzUA421VQ1QkDm
3ohN0wD/TO3y/Um2sVV3fPrkMeIVtdFU3ibEFv6VC7qtL/Xtzgk=
=opJA
-END PGP SIGNATURE-

Bug#965074: Patches to make multicast proccesing on CDC NCM drivers

[Bjørn Mork]

Santiago Ruano Rincón  writes:
> El 02/09/20 a las 17:45, Greg KH escribió:
>> On Wed, Sep 02, 2020 at 03:27:28PM +0200, Santiago Ruano Rincón wrote:
>>
>> > This:
>> > 
>> > 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6
>> > e10dcb1b6ba714243ad5a35a11b91cc14103a9a9
>> > e506addeff844237d60545ef4f6141de21471caf
>> > 0226009ce0f6089f9b31211f7a2703cf9a327a01
>> 
>> These do not look like bugfixes, but a new feature being added for this
>> driver.  So why not just use a newer kernel version for this feature?
>
> From my point of view as user these are bugfixes, since IPv6 NDP or any
> other protocol relying on multicast do not work without them. In other
> words, my computer's networking is broken.

I was in doubt when I submitted these, but ended up specfying net-next
instead of net+stable as the target for a reason.  This is a new feature
as Greg says. Even if the feature is essential for your use case, it is
still new. "Has never been supported" isn't really a bug.

And I am still convinced that my decision was correct.  The patches are
a bit more intrusive than I'd be comfortable submitting to stable, as
was demonstrated by the stupid build bug I added... Fixed by commit
5fd99b5d9950 ("net: cdc_ncm: Fix build error") BTW.

> I want to have them in linux stable releases because that would make
> easier to include them in Debian stable release.

This has not been an absolute requirement in the past. Distros tend to
have a more relaxed stable policy.

Using a newer kernel until Debian moves on is obviously also an option.



Bjørn

Bug#969365: USB-C dock lacks multicast Ethernet functionality (so IPv6 is broken)

[Bjørn Mork]

"Santiago R.R."  writes:

> The patches proposed by Miguel Rodríguez have been merged upstream, and
> are part of 5.9-rc1 now. C.f. commits:
> 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6
> e10dcb1b6ba714243ad5a35a11b91cc14103a9a9
> e506addeff844237d60545ef4f6141de21471caf
> 0226009ce0f6089f9b31211f7a2703cf9a327a01

Note that

 5fd99b5d9950 ("net: cdc_ncm: Fix build error")

should be included in this series for completeness.

It won't make any difference with the default Debian configuration,
where cdc_ether always is enabled, but it was an unfortunate glitch on
my side.


Bjørn

Bug#969144: systemd: serial-getty@.service should support 57600 baud

[Bjørn Mork]

Package: systemd
Version: 241-7~deb10u4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

My BIOS provides pre-boot access to the system over serial, and sets
the port up for 57600.  So I have configured the client (conserver)
to use that speed.  This has happened to work by accident with the
systemd serial-getty@.service because of the  --keep-baud
parameter to agetty.

But today I ended up changing the speed of the port while temporarily
testing another client.  And was surprised to learn that it is
impossible to switch back to 57600 with the default serial-getty@.service 


I see no reason why this standard baud rate should be excluded from
the list of rates.  Please fix

- --- a/lib/systemd/system/serial-getty@.service   2020-04-27 
19:02:57.0 +0200
+++ b/etc/systemd/system/serial-getty@.service   2020-08-28 09:45:03.0 
+0200
@@ -31,7 +31,7 @@
 # The '-o' option value tells agetty to replace 'login' arguments with an
 # option to preserve environment (-p), followed by '--' for safety, and then
 # the entered username.
- -ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,38400,9600 %I $TERM
+ExecStart=-/sbin/agetty -o '-p -- \\u' --keep-baud 115200,57600,38400,9600 %I 
$TERM
 Type=idle
 Restart=always
 UtmpIdentifier=%I



- -- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4+deb10u5
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-7~deb10u4
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.20-0+deb10u1
pn  libpam-systemd  

Versions of packages systemd suggests:
pn  policykit-1
ii  systemd-container  241-7~deb10u4

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  udev 241-7~deb10u4

- -- no debconf information

-BEGIN PGP SIGNATURE-

iGwEARECACwWIQR3fjfc8EF8nPbC0aDXSuqSjBsiyQUCX0i4ew4cYmpvcm5AbW9y
ay5ubwAKCRDXSuqSjBsiyTR3AKCE+AQuZPknH3Y2vn2d8fItnwI/TQCfcIIszZay
MMmlVssL2UW+e/vQIIo=
=mJoh
-END PGP SIGNATURE-

Bug#967115: refind: unexpected and unwanted boot order changes on upgrade

[Bjørn Mork]

Package: refind
Version: 0.12.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The postinst script unconditionally deletes and recreates the existing
NVRAM entry for rEFInd on upgrades if "install_to_esp" is enabled. This
moves the rEFInd entry first in the boot order, regardless of the
previous setting.

The existing boot order should not change if there is an existing
rEFInd NVRAM entry.  The postinst script should save and restore
the previous boot order in this case, taking any changes to the
rEFInd bootnum into consideration.

Fixing refind-install to support rEFInd NVRAM entry updates might be
easier and less confusing.  This would also be a useful feature by
itself for those running refind-install manually.


- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages refind depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  efibootmgr 17-1
ii  gdisk  1.0.5-1
ii  openssl1.1.1g-1

Versions of packages refind recommends:
ii  python3 3.8.2-3
ii  sbsigntool  0.9.2-2

refind suggests no packages.

- -- Configuration Files:
/etc/refind.d/keys/README.txt [Errno 13] Permission denied: 
'/etc/refind.d/keys/README.txt'
/etc/refind.d/keys/SLES-UEFI-CA-Certificate.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/SLES-UEFI-CA-Certificate.cer'
/etc/refind.d/keys/SLES-UEFI-CA-Certificate.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/SLES-UEFI-CA-Certificate.crt'
/etc/refind.d/keys/altlinux.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/altlinux.cer'
/etc/refind.d/keys/canonical-uefi-ca.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/canonical-uefi-ca.cer'
/etc/refind.d/keys/canonical-uefi-ca.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/canonical-uefi-ca.crt'
/etc/refind.d/keys/canonical-uefi-ca.der [Errno 13] Permission denied: 
'/etc/refind.d/keys/canonical-uefi-ca.der'
/etc/refind.d/keys/centos.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/centos.cer'
/etc/refind.d/keys/centos.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/centos.crt'
/etc/refind.d/keys/fedora-ca.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/fedora-ca.cer'
/etc/refind.d/keys/fedora-ca.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/fedora-ca.crt'
/etc/refind.d/keys/microsoft-kekca-public.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-kekca-public.cer'
/etc/refind.d/keys/microsoft-kekca-public.der [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-kekca-public.der'
/etc/refind.d/keys/microsoft-pca-public.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-pca-public.cer'
/etc/refind.d/keys/microsoft-pca-public.der [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-pca-public.der'
/etc/refind.d/keys/microsoft-uefica-public.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-uefica-public.cer'
/etc/refind.d/keys/microsoft-uefica-public.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-uefica-public.crt'
/etc/refind.d/keys/microsoft-uefica-public.der [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-uefica-public.der'
/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.cer [Errno 13] Permission 
denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.cer'
/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.crt [Errno 13] Permission 
denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.crt'
/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.cer [Errno 13] Permission 
denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.cer'
/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.crt [Errno 13] Permission 
denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.crt'
/etc/refind.d/keys/refind.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/refind.cer'
/etc/refind.d/keys/refind.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/refind.crt'

- -- debconf information:
* refind/install_to_esp: false

-BEGIN PGP SIGNATURE-

iIQEARYKACwWIQRoe+CASfFh7aZ6shIiBE7Lv6RhXQUCXykfmQ4cYmpvcm5AbW9y
ay5ubwAKCRAiBE7Lv6RhXcfcAP9nU9yc5T8d6dIlcgXOLWxL1/cokIgo/DG1UJsp
oG6jrgEAt4S3qfRTisPfyK+a5P+Fvcogknl5PT2SFWoM4XSe2gQ=
=BbH3
-END PGP SIGNATURE-

Bug#965074: cdc_ncm: ethernet multicast traffic is filtered out

[Bjørn Mork]

FWIW, I made an attempt resubmitting these patches since it looked like
I was part of the problem back in 2018 ;-)

I'd CCed you, and would appreciate it if you could test the series.  I
don't have any cdc_ncm devices with multicast filter support AFAIK.


Bjørn

Bug#964480: linux: ath9k (USB) broken in upstresm linux 5.7.3 after commit 6602f080cb

[Bjørn Mork]

Juergen  writes:

> In 5.7 reverting 6602f080cb is known to fix the problem, but it hasn't yet 
> been
> analyzed by an expert, therefore I'd like to report my findings to perhaps get
> an expert interested:-)
>
> At least one problem is in function ath9k_hif_usb_reg_in_cb(). In the call to
> usb_fill_int_urb() it should be rx_buf instead of nskb as penultimate
> parameter.

Yes, that's an obvious killer bug.  That patch should definitely be
reverted, and replaced with a proper and tested fix.

IMHO, it would be much safer and simpler to validate the expected
descriptors when probing these devices instead of allocating new helper
structs and making changes all over the place.  There is no reason to
add support for the syzbot simulated device.  Returning -ENODEV on probe
is fine, and is much less likely to add new and critical bugs.

And it's not like the fix actually took care of all the hard coded well
known descriptor values in this driver anyway.  We still have stuff like

 usb_sndintpipe(hif_dev->udev, USB_REG_OUT_PIPE)

and

 usb_sndbulkpipe(hif_dev->udev, USB_WLAN_TX_PIPE)

These will not crash the driver, but are still solid indications that
the driver is written for a very specific USB device configuration.  It
will not work with arbitrary descriptors.

I assume the "0" interface is just as fixed as those endpoints, so that
simply validating the values in ath9k_hif_usb_probe() is a perfectly
fine and safe solution.  Without the need to mess up the rest of the
driver.



Bjørn

Bug#949020: linux-image-5.6.0-2-amd64: Lenovo poweroff/suspend failure

[Bjørn Mork]

Package: src:linux
Followup-For: Bug #949020

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Just confirming that this issue is still present, causing a terrible
user experience when upgrading from Buster to Bullseye on a Lenovo
laptop. Verified on a 4th Gen Thinkpad X1 Carbon.

Setting intel_iommu=off is confirmed as workaround.

I understand from the upstream discussion that this is mostly a
Lenovo firmware issue.  But I still believe something needs to be
done in Debian to avoid every Lenovo user having to discover this
bug report and implement the workaround manually.  After first
experiencing a complete system failure when trying to suspend 
the system.  A feature which worked without a flaw on Debian
Buster.


- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
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 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iIQEARYKACwWIQRoe+CASfFh7aZ6shIiBE7Lv6RhXQUCXvSVXQ4cYmpvcm5AbW9y
ay5ubwAKCRAiBE7Lv6RhXd/GAQCIsozUqKlBr9BkIXoOXp7lFk9WouEh0QSYMm1F
oqluMwEA34mOpMqJL7bZWRAydIEctD1rWSAg7r1kpPAel1IwxAc=
=hTTU
-END PGP SIGNATURE-

Bug#961459: linux-signed-arm64: option that might support raspberry pi 4 usb

[Bjørn Mork]

Rob Browning  writes:

> If I get a chance and figure out how, I can try to build a local kernel
> with that option and test it, or I could fairly quickly test any version
> uploaded somewhere like experimental.

I have done this, and verified that the USB ports work if
CONFIG_PCIE_BRCMSTB is enabled.  See

https://bugs.debian.org/960129



Bjørn

Bug#961130: ethtool can read DOM values

[Bjørn Mork]

Ben Hutchings  writes:
> On Wed, 2020-05-20 at 13:09 +, Yannis Aribaud wrote:
>> Package: ethtool
>> Version: 1:4.19-1
>> Severity: important
>> The command ethtool -m  is unable to read the transceiver DOM values.
>
> Again, this is a driver or hardware issue, not a bug in ethtool.
>
> [...]
>> As you can see all mesuring values are zeros.
>> I am using Debian GNU/Linux 10 (buster), kernel 4.19.0-9-amd64 #1 SMP
>> Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux and libc6 2.28-10
>> 
>> FYI, I get correct values using SystemRescueCD 6 (ethtool 5.0, kernel
>> 4.19.34-1-lts) on this same hardware, using the same command.
>
> I see no changes to ethtool between 4.19 and 5.0 that would explain
> that.

I assume you're aware of this, but there are some interesting changes in
that driver between v4.19.34 and v4.19.118

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=7da11d6a5d85ab3f4d28fa660d8c90566fdaa1e6
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=935f39807a7e95678e5bda50757af326691a211c


The net effect seems to be that they removed the part that actually made
DOM reading work. Makes me wonder what happens if you revert both those
patches?  I don't have the hardware, so I can't test..

This issue might also be fixed in mainline with the more generic high
page support for QSFP28 and QSFP+?


Bjørn

Bug#960702: ethtool -m values change when output is redirected

[Bjørn Mork]

"Yannis Aribaud"  writes:

> Package: ethtool
> Version: 1:4.19-1
> Severity: important
> I'm facing a very strange behavior. The command ethtool -m  report the 
> transceiver DOM values correctly, but when the command output is redirected 
> to an other program, values change to somthing else.

AFAICS, your SFP+ is reporting strange values in either case.  I do not
think any of these are correct.  Looking at the non-redirected one:

>  Laser output power : 3.0768 mW / 4.88 dBm

This is insanely high.

>  Receiver signal average optical power : 1.2298 mW / 0.90 dBm
>  Module temperature : 48.47 degrees C / 119.24 degrees F
>  Module voltage : 1.2336 V

Should be 3.3 V

>  Laser bias current high alarm threshold : 4.744 mA
>  Laser bias current low alarm threshold : 49.896 mA

Right...

>  Laser output power high alarm threshold : 2.5701 mW / 4.10 dBm

I don't think this can be trusted either, but I do note that it is lower
than your current output.

>  Laser output power low alarm threshold : 0.8224 mW / -0.85 dBm
>  Laser output power high warning threshold : 0.8224 mW / -0.85 dBm
>  Laser output power low warning threshold : 0.8224 mW / -0.85 dBm

Strange limits.  There are too many -0.85 dBm values here.

>  Module temperature high alarm threshold : 0.00 degrees C / 32.00 degrees F
>  Module temperature low alarm threshold : 0.00 degrees C / 32.00 degrees F
>  Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
>  Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F

Makes no sense at all.

>  Module voltage high alarm threshold : 0.4356 V
>  Module voltage low alarm threshold : 0. V
>  Module voltage high warning threshold : 0. V
>  Module voltage low warning threshold : 0. V

Makes even less sense.  


>  Laser rx power high alarm threshold : 0.8224 mW / -0.85 dBm
>  Laser rx power low alarm threshold : 0.8224 mW / -0.85 dBm
>  Laser rx power high warning threshold : 0.8224 mW / -0.85 dBm
>  Laser rx power low warning threshold : 0.8224 mW / -0.85 dBm

...



To me it looks like you are just reading arbitrary numbers from the
SFP+.  Try replacing it and see if the results are more reliable.



Bjørn

Bug#960390: x86_64: No serial port output

[Bjørn Mork]

Geert Stappers  writes:

> Virtual Machines (Qemu, KVM, Xen, ... ) and OCI containters ( "Docker
> images") are the new serial port only computers.
>
> In other words: There are many servers without video hardware.

(Un)fortunately, depending how you look at it, running a remote qemu
machine with full desktop access is easy. You'll just add

 -vnc localhost:$displaynum

and then connect to it from a remote client over ssh using

 vncviewer -via $vmhost :$displaynum

I definitely agree wrt the usefulness of serial console, but I don't
think virtual machines are going to increase the demand much.  Getting
full desktop access in qemu is so much easier than any "Lights Out" or
other remote "keyboard, video and mouse" solution I've tried on bare
metal.


Bjørn

Bug#960390: x86_64: No serial port output

[Bjørn Mork]

john doe  writes:

> Unless I'm missing something, it does work for me with something like:
>
> -nographic -cdrom *.iso -kernel  kernel-path -append
> "console=ttyS0,115200n8 ..."
>
>
> '-serial' might also be needed.

Try repeating that when installing on bare metal without a monitor.

The lack of serial console support is a very long standing bug in the
Debian installer.  See for example https://bugs.debian.org/309223
opened 15 years ago, and closed 10 years ago without any attempt to fix
the problem.

The bug has been carefully forward ported from syslinux to grub, keeping
the intended(?) non-working default.

I believe most users have given up.  After all, you rarely need to
install Debian more than once one a system. And you easily live with
having to modify the installer slightly.


Bjørn

Bug#960129: linux-image-5.6.0-1-arm64: please enable CONFIG_PCIE_BRCMSTB in the arm64 kernel for Raspberry Pi 4

[Bjørn Mork]

Bjørn Mork  writes:

> Note that I found that I had to remove the cma=xx option raspi-firmware
> wants to put into the cmdline.txt.  This messed up mailbox access to the
> firmware, and took several drivers/devices with it in the fall.  Don't
> think the SD card was one one them.  But still worth trying.  Makes the
> sound driver load at least, and allows vcgencmd to talk to the firmware.


Sorry about all the mails.. Should have tested this myself before
sending the previous one.

I do believe this is the problem. I just tested with 'cma=64M' on the
command line, like raspi-firmware wants to put there, and it fails to
load the mmc driver too:


[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.6.0-1-arm64 (debian-ker...@lists.debian.org) 
(gcc version 9.3.0 (Debian 9.3.0-11)) #1 SMP Debian 5.6.7-1 (2020-04-29)
[0.00] Machine model: Raspberry Pi 4 Model B Rev 1.2
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] Reserved memory: bypass linux,cma node, using cmdline CMA params 
instead
[0.00] OF: reserved mem: node linux,cma compatible matching fail
[0.00] cma: Reserved 64 MiB at 0xf800
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x-0xfbff]
[0.00] NUMA: NODE_DATA [mem 0xf781d0c0-0xf781efff]
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x3fff]
[0.00]   DMA32[mem 0x4000-0xfbff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x3b3f]
[0.00]   node   0: [mem 0x4000-0xfbff]
[0.00] Initmem setup node 0 [mem 0x-0xfbff]
[0.00] percpu: Embedded 32 pages/cpu s93976 r8192 d28904 u131072
[0.00] Detected PIPT I-cache on CPU0
[0.00] CPU features: detected: EL2 vector hardening
[0.00] CPU features: kernel page table isolation forced ON by KASLR
[0.00] CPU features: detected: Kernel page table isolation (KPTI)
[0.00] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
[0.00] CPU features: detected: ARM erratum 1319367
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 996912
[0.00] Policy zone: DMA32
[0.00] Kernel command line:  dma.dmachans=0x71f5 
bcm2709.boardrev=0xc03112 bcm2709.serial=0xf5ccdafc bcm2709.uart_clock=4800 
bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 
smsc95xx.macaddr=DC:A6:32:77:E5:5E vc_mem.mem_base=0x3ec0 
vc_mem.mem_size=0x4000  console=tty0 console=ttyS1,115200 
root=/dev/mmcblk1p3 ro net.ifnames=0 cma=64M apparmor=0 rootwait
[0.00] Dentry cache hash table entries: 524288 (order: 10, 4194304 
bytes, linear)
[0.00] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.00] software IO TLB: mapped [mem 0x3740-0x3b40] (64MB)
[0.00] Memory: 1925100K/4050944K available (10108K kernel code, 1836K 
rwdata, 3752K rodata, 5184K init, 557K bss, 174912K reserved, 65536K 
cma-reserved)
[0.00] random: get_random_u64 called from 
__kmem_cache_create+0x44/0x5c8 with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 36361 entries in 143 pages
[0.00] ftrace: allocated 143 pages with 5 groups
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 
jiffies.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[0.00] GIC: Using split EOI/Deactivate mode
[0.00] arch_timer: cp15 timer(s) running at 54.00MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[0.06] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 
4398046511102ns
[0.000184] Console: colour dummy device 80x25
[0.000554] printk: console [tty0] enabled
[0.000683] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 108.00 BogoMIPS (lpj=216000)
[0.000708] pid_max: default: 32768 minimum: 301
[0.000871] LSM: Security Framework initializing
[0.000944] Yama: disabled by default; enable with sysctl kernel.yama.*
[0.000983] SELinux:  Initializing.
[0.001067] TOMOYO Linux initialized
[0.001202] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, 
linear)
[0.001273] Mountpoint-cache hash table entries:

Bug#960129: linux-image-5.6.0-1-arm64: please enable CONFIG_PCIE_BRCMSTB in the arm64 kernel for Raspberry Pi 4

[Bjørn Mork]

Lucas Nussbaum  writes:

> I am trying to boot a RPI4 with the 5.6 kernel from unstable, but it
> fails to boot (while it worked with 5.5 from unstable).
>
> What I'm seeing with 5.5, but not with 5.6, is:
> [4.500333] mmc1: SDHCI controller on fe34.emmc2 [fe34.emmc2] 
> using ADMA
> [4.500585] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [4.577842] mmc0: new high speed SDIO card at address 0001
> [4.610694] mmc1: new ultra high speed DDR50 SDHC card at address 
> [4.618812] mmcblk1: mmc1: SC16G 14.8 GiB
> [4.629268]  mmcblk1: p1 p2
>
> Did you also see that issue? Was it fixed by enabling
> CONFIG_PCIE_BRCMSTB, or is that a different issue?

Tested now, both with my kernel with CONFIG_PCIE_BRCMSTB=y and with the
current kernel from sid (version 5.6.7-1).  Either seems to work fine
(except for USB of course).

I am attaching the full boot log from the 5.6.7-1 kernel for reference.

Note that I found that I had to remove the cma=xx option raspi-firmware
wants to put into the cmdline.txt.  This messed up mailbox access to the
firmware, and took several drivers/devices with it in the fall.  Don't
think the SD card was one one them.  But still worth trying.  Makes the
sound driver load at least, and allows vcgencmd to talk to the firmware.

My cmdline.txt and config.txt while doing this SD card test:

root@buster-rpi4:/boot/firmware# cat cmdline.txt 
console=tty0 console=ttyS1,115200 root=/dev/mmcblk1p3 ro net.ifnames=0 
apparmor=0 rootwait

root@buster-rpi4:/boot/firmware# cat config.txt 
# Switch the CPU from ARMv7 into ARMv8 (aarch64) mode
arm_64bit=1

enable_uart=1
upstream_kernel=1

kernel=vmlinuz-5.6.0-1-arm64
# For details on the initramfs directive, see
# https://www.raspberrypi.org/forums/viewtopic.php?f=63=10532
initramfs initrd.img-5.6.0-1-arm64


Maybe you somehow have removed one of the necessary modules from the
initramfs? I have these loaded after a full boot:

root@buster-rpi4:~# lsmod
Module  Size  Used by
cmac   16384  1
bnep   28672  2
nls_ascii  16384  1
nls_cp437  20480  1
btsdio 20480  0
brcmfmac  311296  0
hci_uart  135168  0
brcmutil   16384  1 brcmfmac
btqca  20480  1 hci_uart
btrtl  24576  1 hci_uart
bcm2835_v4l2   65536  0
btbcm  24576  1 hci_uart
btintel28672  1 hci_uart
cfg80211  716800  1 brcmfmac
snd_bcm283528672  0
videobuf2_vmalloc  20480  1 bcm2835_v4l2
bluetooth 606208  28 btrtl,btqca,btsdio,btintel,hci_uart,btbcm,bnep
videobuf2_memops   20480  1 videobuf2_vmalloc
snd_pcm   126976  1 snd_bcm2835
videobuf2_v4l2 28672  1 bcm2835_v4l2
videobuf2_common   53248  2 videobuf2_v4l2,bcm2835_v4l2
snd_timer  45056  1 snd_pcm
snd98304  3 snd_bcm2835,snd_timer,snd_pcm
videodev  270336  3 videobuf2_v4l2,bcm2835_v4l2,videobuf2_common
soundcore  20480  1 snd
mc 53248  3 videodev,videobuf2_v4l2,videobuf2_common
cpufreq_dt 20480  0
overlay   122880  1
vfat   28672  1
fat90112  1 vfat
ext4  712704  1
mbcache24576  1 ext4
jbd2  135168  1 ext4
crc32c_generic 16384  2
nfsv3  53248  0
nfs_acl20480  1 nfsv3
nfs   331776  1 nfsv3
lockd 106496  2 nfsv3,nfs
grace  20480  1 lockd
sunrpc442368  5 lockd,nfsv3,nfs_acl,nfs
fscache   397312  1 nfs
autofs453248  2
ip_tables  32768  0
x_tables   36864  1 ip_tables
crc16  16384  2 bluetooth,ext4
rfkill 32768  5 bluetooth,cfg80211
ecdh_generic   16384  2 bluetooth
ecc28672  1 ecdh_generic
ansi_cprng 20480  1
broadcom   24576  1
bcm_phy_lib16384  1 broadcom
mdio_bcm_unimac20480  0
dwc2  241664  0
udc_core   49152  1 dwc2
genet  65536  0
usbcore   286720  2 dwc2,brcmfmac
vchiq 360448  2 snd_bcm2835,bcm2835_v4l2
bcm2835_wdt20480  0
sdhci_iproc20480  0
of_mdio24576  3 mdio_bcm_unimac,genet
sdhci_pltfm16384  1 sdhci_iproc
fixed_phy  16384  2 genet,of_mdio
raspberrypi_cpufreq16384  0
usb_common 16384  3 dwc2,usbcore,udc_core
watchdog   36864  1 bcm2835_wdt
sdhci  69632  2 sdhci_pltfm,sdhci_iproc
libphy 94208  6 
mdio_bcm_unimac,genet,of_mdio,broadcom,fixed_phy,bcm_phy_lib
iproc_rng200   16384  0
i2c_bcm283520480  0
pwm_bcm283516384  0
rng_core   24576  1 iproc_rng200
leds_gpio  

Bug#960129: linux-image-5.6.0-1-arm64: please enable CONFIG_PCIE_BRCMSTB in the arm64 kernel for Raspberry Pi 4

[Bjørn Mork]

Lucas Nussbaum  writes:
> On 09/05/20 at 20:44 +0200, Bjørn Mork wrote:
>> Please enable CONFIG_PCIE_BRCMSTB on arm64.
>> 
>> The Raspberry Pi 4 has a VL805 xhci controller connected to the
>> PCIe bus on the SoC.  All USB ports are connected to this controller.
>> CONFIG_PCIE_BRCMSTB is therefore necessary for USB support.
>
> I am trying to boot a RPI4 with the 5.6 kernel from unstable, but it
> fails to boot (while it worked with 5.5 from unstable).
>
> What I'm seeing with 5.5, but not with 5.6, is:
> [4.500333] mmc1: SDHCI controller on fe34.emmc2 [fe34.emmc2] 
> using ADMA
> [4.500585] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
> [4.577842] mmc0: new high speed SDIO card at address 0001
> [4.610694] mmc1: new ultra high speed DDR50 SDHC card at address 
> [4.618812] mmcblk1: mmc1: SC16G 14.8 GiB
> [4.629268]  mmcblk1: p1 p2
>
> Did you also see that issue?

No, I didn't.  I am netbooting, so I wouldn't have noticed...

Don't think I've tried booting any Debian kernels from an SD card yet.
Will try to find some time to test it.  But I find using SD cards more
quite a hassle :-)

> Was it fixed by enabling
> CONFIG_PCIE_BRCMSTB, or is that a different issue?

Probably different.  I believe this driver just enables the PCIe
controller, which should be independent of anything else except the PCIe
connected xhci controller.


Bjørn

Bug#960129: linux-image-5.6.0-1-arm64: please enable CONFIG_PCIE_BRCMSTB in the arm64 kernel for Raspberry Pi 4

[Bjørn Mork]

Package: src:linux
Version: 5.6.7-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

Please enable CONFIG_PCIE_BRCMSTB on arm64.

The Raspberry Pi 4 has a VL805 xhci controller connected to the
PCIe bus on the SoC.  All USB ports are connected to this controller.
CONFIG_PCIE_BRCMSTB is therefore necessary for USB support.

I tested rebuilding the current Debian 5.6 kernel in sid with just
this change, and it is enough to enable the USB port on the RPi4:

root@buster-rpi4:~# lspci -nn
00:00.0 PCI bridge [0604]: Broadcom Limited Device [14e4:2711] (rev 10)
01:00.0 USB controller [0c03]: VIA Technologies, Inc. VL805 USB 3.0 Host 
Controller [1106:3483] (rev 01)
root@buster-rpi4:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@buster-rpi4:~# dmesg |egrep -i 'pci|usb|xhci'
[0.877939] PCI: CLS 0 bytes, default 64
[1.359321] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[1.359879] brcm-pcie fd50.pcie: host bridge /scb/pcie@7d50 ranges:
[1.359905] brcm-pcie fd50.pcie:   No bus range found for 
/scb/pcie@7d50, using [bus 00-ff]
[1.359943] brcm-pcie fd50.pcie:  MEM 0x06..0x0603ff -> 
0x00f800
[1.359978] brcm-pcie fd50.pcie:   IB MEM 0x00..0x00bfff -> 
0x00
[1.409038] brcm-pcie fd50.pcie: link up, 5 GT/s x1 (SSC)
[1.409257] brcm-pcie fd50.pcie: PCI host bridge to bus :00
[1.409277] pci_bus :00: root bus resource [bus 00-ff]
[1.409296] pci_bus :00: root bus resource [mem 0x6-0x603ff] 
(bus address [0xf800-0xfbff])
[1.409340] pci :00:00.0: [14e4:2711] type 01 class 0x060400
[1.409442] pci :00:00.0: PME# supported from D0 D3hot
[1.411585] pci :00:00.0: bridge configuration invalid ([bus 00-00]), 
reconfiguring
[1.411761] pci :01:00.0: [1106:3483] type 00 class 0x0c0330
[1.411849] pci :01:00.0: reg 0x10: [mem 0x-0x0fff 64bit]
[1.412028] pci :01:00.0: PME# supported from D0 D3cold
[1.424884] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
[1.424924] pci :00:00.0: BAR 14: assigned [mem 0x6-0x6000f]
[1.424947] pci :01:00.0: BAR 0: assigned [mem 0x6-0x60fff 
64bit]
[1.424975] pci :00:00.0: PCI bridge to [bus 01]
[1.424991] pci :00:00.0:   bridge window [mem 0x6-0x6000f]
[1.425165] pcieport :00:00.0: enabling device ( -> 0002)
[1.425312] pcieport :00:00.0: PME: Signaling with IRQ 40
[1.425631] pcieport :00:00.0: AER: enabled with IRQ 40
[1.425806] pci :01:00.0: enabling device ( -> 0002)
[3.189692] usb_phy_generic phy: phy supply vcc not found, using dummy 
regulator
[3.278169] usbcore: registered new interface driver usbfs
[3.284814] usbcore: registered new interface driver hub
[3.291153] usbcore: registered new device driver usb
[3.336101] dwc2 fe98.usb: fe98.usb supply vusb_d not found, using 
dummy regulator
[3.344668] dwc2 fe98.usb: fe98.usb supply vusb_a not found, using 
dummy regulator
[3.459118] dwc2 fe98.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[   15.946055] xhci_hcd :01:00.0: xHCI Host Controller
[   15.954077] xhci_hcd :01:00.0: new USB bus registered, assigned bus 
number 1
[   15.967736] xhci_hcd :01:00.0: hcc params 0x002841eb hci version 0x100 
quirks 0x0090
[   15.989621] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, 
bcdDevice= 5.06
[   15.998076] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   16.005520] usb usb1: Product: xHCI Host Controller
[   16.010535] usb usb1: Manufacturer: Linux 5.6.0-2-arm64 xhci-hcd
[   16.016722] usb usb1: SerialNumber: :01:00.0
[   16.023171] hub 1-0:1.0: USB hub found
[   16.033311] xhci_hcd :01:00.0: xHCI Host Controller
[   16.039381] xhci_hcd :01:00.0: new USB bus registered, assigned bus 
number 2
[   16.039400] xhci_hcd :01:00.0: Host supports USB 3.0 SuperSpeed
[   16.039510] usb usb2: We don't know the algorithms for LPM for this host, 
disabling LPM.
[   16.039578] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, 
bcdDevice= 5.06
[   16.039581] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   16.039584] usb usb2: Product: xHCI Host Controller
[   16.039587] usb usb2: Manufacturer: Linux 5.6.0-2-arm64 xhci-hcd
[   16.039589] usb usb2: SerialNumber: :01:00.0
[   16.039938] hub 2-0:1.0: USB hub found
[   16.197384] usbcore: registered new interface driver brcmfmac
[   16.443015] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[   16.601666] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, 
bcdDevice= 4.21
[   16.613530] usb 1-1: New USB device strings: 

Bug#951744: raspi-firmware: current cmdline defaults prevents RPi4 from working

[Bjørn Mork]

Package: raspi-firmware
Followup-For: Bug #951744

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

Adding this info here since it is really about having a more flexible cmdline
generator, with fewer hardcoded defaults.

The current CMA=64M prevents the 4GB RPi4 from working properly:

[4.776351] raspberrypi-firmware soc:firmware: Request 0x0001 returned 
status 0x
[4.785055] raspberrypi-firmware soc:firmware: Request 0x00030046 returned 
status 0x
[4.794006] raspberrypi-firmware soc:firmware: Request 0x00030007 returned 
status 0x
[4.802622] raspberrypi-clk raspberrypi-clk: Failed to get pllb min freq: -22
[4.809891] raspberrypi-clk raspberrypi-clk: Failed to initialize pllb, -22
[4.816989] raspberrypi-clk: probe of raspberrypi-clk failed with error -22
[4.824476] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.833090] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 0 
config (-22 80)
[4.841381] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.849988] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 1 
config (-22 81)
[4.858270] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.866876] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 2 
config (-22 82)
[4.875157] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.883759] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 3 
config (-22 83)
[4.892041] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.900644] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 4 
config (-22 84)
[4.908926] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.917528] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 5 
config (-22 85)
[4.925807] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.934409] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 6 
config (-22 86)
[4.942690] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.951294] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 7 
config (-22 87)
[4.960190] raspberrypi-firmware soc:firmware: Request 0x00030030 returned 
status 0x
[4.969229] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.977837] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 1 
config (-22 81)
[4.986124] raspberrypi-firmware soc:firmware: Request 0x00030043 returned 
status 0x
[4.994746] raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 1 
config (-22 81)
[5.003004] pwrseq_simple: probe of wifi-pwrseq failed with error -22
[5.010323] hctosys: unable to open rtc device (rtc0)


This failure to communicate with the VideoCore firmware prevents many of the SoC
devices from working. E.g sound and the vchiq character deviice.  Removing the
unnecessary  "cma=xx" option from the command line fixes the issue:

[4.742103] raspberrypi-firmware soc:firmware: Attached to firmware from 
2020-03-26 17:18
[4.751121] raspberrypi-clk raspberrypi-clk: CPU frequency range: min 
6, max 15
[4.765035] hctosys: unable to open rtc device (rtc0)


But the raspi-firware scripts do not allow removal of the cma=XX parameter,
only changing its value.  This should be up to the user to decide. And any
default setting should at least work on all supported platforms.

I'd really prefer obscure tuning options like this to be left to expert
users, and not arbitrarily changed by distro scripts.  Change the upstream
kernel defaults instead if necessary.

Specifying nfs root is possible, but unnecessarily hard.  Had to cheat with:

 ROOTPART="/dev/nfs nfsroot=192.168.2.1:/var/nfsroot/buster-bcm27xx"

And then there is no way to prevent the now unnecessary "fsck.repair=yes.  Or
or changing the rootfs to "ro".

The hard coded default "elevator=deadline" is pointless, as pointed out by
current kernels:

[0.00] Kernel parameter elevator= does not have any effect anymore.
[0.00] Please use sysfs to set IO scheduler for individual devices.


I do want the "net.ifnames=0", but this is again not something that should
be hard coded in the script.  It will create issues for anyone wanting the
odd systemd names. Which is the documented Debian default, whether we like
it or not.

In short: make the default line completely configurable.  Remove all
optional parameters from defaults.  Possibly leaving them as proposed
settings.


Bjørn


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 

Bug#949370: Info received (Bug#949370: Acknowledgement (spamass-milter: synthesized received header sometimes use the sendmail start time instead of current time))

[Bjørn Mork]

Control: tag -1 +patch

Although I believe sendmail is functioning as designed and documented,
this bug makes it clear that milters expect and depend on several
sendmail macros in the milter_envrpct() stage. The macros which are set
and updated by initsys() can easily be made available by simply
reordering the calls, as implemented in the attached patch.

This improves the milter API by making the macros consistent between the
first and subsequent milter_envrpct() calls for an envelope.


Bjørn
From a31dd4ba69b14e92e3920020efa59b4ae3ca26af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 
Date: Tue, 21 Jan 2020 13:04:55 +0100
Subject: [PATCH] milter: update macros before calling milter_envrcpt
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Bjørn Mork 
---
 sendmail/srvrsmtp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/sendmail/srvrsmtp.c b/sendmail/srvrsmtp.c
index b05348d4b2e2..0526205b7627 100644
--- a/sendmail/srvrsmtp.c
+++ b/sendmail/srvrsmtp.c
@@ -3059,6 +3059,10 @@ smtp(nullserver, d_flags, e)
 	}
 }
 
+/* make macros available for milter_envrcpt() */
+if (smtp.sm_nrcpts == 0)
+	initsys(e);
+
 response = milter_envrcpt(args, e, ,
 			Errors > 0);
 milter_cmd_done = true;
@@ -3070,8 +3074,6 @@ smtp(nullserver, d_flags, e)
 			e->e_to = a->q_paddr;
 			if (!(Errors > 0) && !QS_IS_BADADDR(a->q_state))
 			{
-if (smtp.sm_nrcpts == 0)
-	initsys(e);
 message("250 2.1.5 Recipient ok%s",
 	QS_IS_QUEUEUP(a->q_state) ?
 		" (will queue)" : "");
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#949370: Acknowledgement (spamass-milter: synthesized received header sometimes use the sendmail start time instead of current time)

[Bjørn Mork]

Based on my understanding of the milter API docs, I believe this is a
spamass-milter bug aided by confusing sendmail docs and API.

I looked at the sendmail code and did some additional milter tests.
Both confirm the root cause: The "$b" macro is not necessarily updated
the when the first envrcpt milter call is made.

Experimenting with the "$p" macro was enlightening.  This is supposed to
be the current pid.  Both "$b" and "$p" macros are set by initsys() in
envelope.c.  But "$p" is always unset the first time the milter envrcpt
is called.  If the mail has multiple recipients, then the "$p" macro
will be correct for the remaining envrcpt calls.  And so will the "$b"
macro.

The reason is obvious from the sendmail/srvrsmtp.c smtp() function:


response = milter_envrcpt(args, e, ,
Errors > 0);
milter_cmd_done = true;
MILTER_REPLY("to");
}
#endif /* MILTER */

/* no errors during parsing, but might be a duplicate */
e->e_to = a->q_paddr;
if (!(Errors > 0) && !QS_IS_BADADDR(a->q_state))
{
if (smtp.sm_nrcpts == 0)
initsys(e);
message("250 2.1.5 Recipient ok%s",
QS_IS_QUEUEUP(a->q_state) ?
" (will queue)" : "");
smtp.sm_nrcpts++;
}




So initsys(e) is called *after* the first milter_envrcpt() call.  Which
means that macros set by initsys() are generally invalid in envrcpt
context. We can obviously not depend on the mail having more than one
recipient.

The issue with the "$b" macro, making this a bit more confusing, is that
it appears to be inherited from the parent.  So it does have a value.
It's just not meaningful.  This might be a sendmail bug?

The issue could probably be fixed in sendmail by moving the initsys(e)
call in front of milter_envrcpt().  But reading the milter docs, I am
not convinced this is the "most correct" fix.  I believe the bug really
is in spamass-milter assuming that the "$b" macro value is valid at this
stage.


I base my conclusion on the smfi_getsymval() API docs saying

  The macro list can be changed using the confMILTER_MACROS_* options in
  sendmail.mc. The scopes of such macros will be determined by when they
  are set by sendmail. For descriptions of macros' values, please see
  the "Sendmail Installation and Operation Guide" provided with your
  sendmail distribution.


This makes it clear that the macro scopes are limited by when sendmail
set the macros.  It is possible to add any macro to the macro list for
any stage without considering the scope, but that's futile.

Macros which are set or updated by initsys() are outside the
milter_envrcpt scpoe and should not be added to the
confMILTER_MACROS_ENVRCPT list.  This includes the "$b" macro.



Bjørn



signature.asc
Description: PGP signature

Bug#949370: Acknowledgement (spamass-milter: synthesized received header sometimes use the sendmail start time instead of current time)

[Bjørn Mork]

Control: clone -1 -2
Control: reassign -2 sendmail
Control: severity -2 normal
Control: retitle -2 sendmail: milter expansion of "$b" macro is unreliable
Control: found -2 8.15.2-14~deb10u1

The underlying bug appears to be in sendmail. But I'm keeping the
spamass-milter bug open since the use of the "$b" macro there make this
a major problem.

The bug is that sendmail returns sendmail process start time instead of
current time when milters request the "$b" macro ("The current date in
RFC822 format").  This happens often, but not on every milter excution.
Sometimes the correct current time is returned. I do not know the exact
trigger...

The bug is easily reproduced using this simple noop python milter:

import Milter
import time

class DbgMilter(Milter.Base):
  @Milter.noreply
  def envrcpt(self, to, *str):
print("envrcpt() expanded 'b' to '", self.getsymval("b"), "' at ", 
time.strftime("%Y-%m-%d %H:%M:%S"))
return Milter.CONTINUE

if __name__ == "__main__":
  Milter.factory = DbgMilter
  Milter.runmilter("dbgmilter", "/tmp/dbgmilter", 600)


configured as


 INPUT_MAIL_FILTER(`dbg', `S=local:/tmp/dbgmilter, F=, T=S:4m;R:30m;E:40m')dnl
 define(`confMILTER_MACROS_ENVRCPT', `{rcpt_mailer}, {rcpt_host}, {rcpt_addr}, 
{auth_type}, b, i, j, r, v, Z, _, {greylist}')dnl


Running this milter for a while I get:

bjorn@canardo:~/scripts/bjorn-scripts$ python3 pymilter-dbg.py
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
13:50:56
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:51:02 +0100 ' at  2020-01-20 
13:51:02
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
13:52:17
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
13:52:23
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
13:52:28
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:52:51 +0100 ' at  2020-01-20 
13:52:52
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:53:05 +0100 ' at  2020-01-20 
13:53:06
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:53:25 +0100 ' at  2020-01-20 
13:53:28
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:54:48 +0100 ' at  2020-01-20 
13:54:48
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:55:36 +0100 ' at  2020-01-20 
13:55:36
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:57:07 +0100 ' at  2020-01-20 
13:57:07
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:57:12 +0100 ' at  2020-01-20 
13:57:12
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 14:00:05 +0100 ' at  2020-01-20 
14:00:05
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 14:00:50 +0100 ' at  2020-01-20 
14:00:50
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:01:22
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 14:02:02 +0100 ' at  2020-01-20 
14:02:02
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 14:03:14 +0100 ' at  2020-01-20 
14:03:17
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 14:06:48 +0100 ' at  2020-01-20 
14:06:49
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:07:00
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:07:11
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:07:22
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:07:30
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:07:41
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:07:43
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:07:54
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:07:55
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:08:03
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 14:13:24 +0100 ' at  2020-01-20 
14:13:25
envrcpt() expanded 'b' to ' Mon, 20 Jan 2020 13:22:50 +0100 ' at  2020-01-20 
14:13:36


As you can see, a significant number of requests get "13:22:50" instead
of the actual current. This is the time sendmail was started:

bjorn@canardo:~$ ls --full-time /proc/$(pidof "sendmail: MTA: accepting 
connections")/cmdline
-r--r--r-- 1 root root 0 2020-01-20 13:22:50.429438748 +0100 /proc/25911/cmdline


-- Package-specific info:
Output of /usr/share/bug/sendmail/script:

ls -alR /etc/mail:
/etc/mail:
total 464
drwxr-sr-x  10 smmta  smmsp   4096 Jan 20 13:22 .
drwxr-xr-x 212 root   root   24576 Jan 20 06:53 ..
drwxr-xr-x   2 root   smmsp   4096 Jan 13 18:59 CVS
-rwxr-xr--   1 root   smmsp  12980 Jan 20 13:22 Makefile
drwxr-sr-x   2 root   smmsp   4096 Sep  6  2005 OLD
-rw-r--r--   1 root   root4437 Jan 13 18:59 access
-rw-r-   1 smmta  smmsp  12288 Jan 13 18:59 access.db
-rw-r--r--   1 root   root 281 Sep 21  2004 address.resolve
-rw-r--r--   1 root   root1758 Dec  6 11:45 aliases
-rw-r--r--   1 smmta  smmsp  12288 Dec  6 11:45 aliases.db
-rw-r--r--   1 root   smmsp   3735 Jan 20 13:22 databases
-rw-r-   1 smmta  smmsp 31 

Bug#949370: spamass-milter: synthesized received header sometimes use the sendmail start time instead of current time

[Bjørn Mork]

Package: spamass-milter
Version: 0.4.0-1+b1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

I recently became aware that spamassassin reports a large number of false
DATE_IN_FUTURE_96_Q positives.  Being a pretty good spam indicator, this
test has a relatively high score, causing many non-spam messages to be
classified as spam.

But I was unable to reproduce the problem when running spamc from the
command line, using the same input emails spamass-milter had rejected.

Looking further into this, I found that the problem is caused by the
Received header synthesized by spamass-milter. I enabled "-d spamc"
and captured these 5 examples:

 Jan 20 10:37:01 canardo spamass-milter[15003]: Received header for spamc: 
Received: from mxphxpool1028.ebay.com (mxphxpool1028.ebay.com 
[66.211.184.94])#015#012#011by canardo.mork.no (8.15.2/8.15.2) with ESMTPS id 
00K9b03T015037#015#012#011Mon, 13 Jan 2020 18:59:12 
+0100#015#012#011(envelope-from );#015
 Jan 20 10:37:17 canardo spamass-milter[15003]: Received header for spamc: 
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])#015#012#011by 
canardo.mork.no (8.15.2/8.15.2) with ESMTP id 00K9bHZv015075#015#012#011Mon, 20 
Jan 2020 10:37:17 +0100#015#012#011(envelope-from 
);#015
 Jan 20 10:38:39 canardo spamass-milter[15003]: Received header for spamc: 
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])#015#012#011by 
canardo.mork.no (8.15.2/8.15.2) with ESMTP id 00K9cdBm015126#015#012#011Mon, 20 
Jan 2020 10:38:39 +0100#015#012#011(envelope-from 
);#015
 Jan 20 10:38:48 canardo spamass-milter[15003]: Received header for spamc: 
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])#015#012#011by 
canardo.mork.no (8.15.2/8.15.2) with ESMTP id 00K9cdBn015126#015#012#011Mon, 13 
Jan 2020 18:59:12 +0100#015#012#011(envelope-from 
);#015
 Jan 20 10:40:40 canardo spamass-milter[15003]: Received header for spamc: 
Received: from puck.nether.net (puck.nether.net [204.42.254.5])#015#012#011by 
canardo.mork.no (8.15.2/8.15.2) with ESMTPS id 00K9edpQ017980#015#012#011Mon, 
13 Jan 2020 18:59:12 +0100#015#012#011(envelope-from 
);#015


It is pretty clear from the above that only 2 of the headers use the correct
current time, matching the log time.  The 3 other mails all got a header
with a completely bogus "Mon, 13 Jan 2020 18:59:12" date.

But the bogus date is not arbitrary.  Looking closer I noticed that
the date is the start time for the sendmail process:

 bjorn@canardo:~$ ls --full-time /proc/$(pidof "sendmail: MTA: accepting 
connections")/cmdline
 -r--r--r-- 1 root root 0 2020-01-13 18:59:12.097744044 +0100 
/proc/13048/cmdline


This bug has caused my mail server to reject a large number of non-spam
email, using tests which are enabled by default and having default scores.
I do therefore consider it important.

spamass-milter cannot currently not be used without either disabling the
received date tests or setting the scores to 0.



Bjørn

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

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

Versions of packages spamass-milter depends on:
ii  adduser 3.118
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libmilter1.0.1  8.15.2-14~deb10u1
ii  libstdc++6  8.3.0-6
ii  spamc   3.4.2-1+deb10u1

Versions of packages spamass-milter recommends:
ii  sendmail  8.15.2-14~deb10u1
ii  spamassassin  3.4.2-1+deb10u1

spamass-milter suggests no packages.

- -- Configuration Files:
/etc/default/spamass-milter changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iGwEARECACwWIQR3fjfc8EF8nPbC0aDXSuqSjBsiyQUCXiV7Ag4cYmpvcm5AbW9y
ay5ubwAKCRDXSuqSjBsiyTB4AJ0dttXUYFUadh/5ulYmh6k/NAFsUQCdEXpqv4MH
VPvo/jnPF/28b6y1dWo=
=bOCA
-END PGP SIGNATURE-

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_XXXXXXX/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[Bjørn Mork]

Pierrick CHANTEUX  writes:

> This bug resulted in complete system breakage and I couldn't boot
> anymore (systemd failing to load Kernel modules). I can guarantee that
> this isn't only cosmetic.
>
> I believe this isn't related to initramfs-tools, because downgrading
> kmod and libkmod2 from version 26+20191223-1 to version 26-3 fixes the
> issue. Initramfs now build (and run) correctly.

IMHO this is probably an unrelated bug in the same kmod upgrade.  You
should report it as such, which the full log output and a subject
decribing the issue instead of the bogus error message.

The logspam caused by the lookup_builtin_file() bug makes it hard to
spot real errors, but hopefully there is some clue to your problem there
too.



Bjørn

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[Bjørn Mork]

Bjørn Mork  writes:
> Marco d'Itri  writes:
>
>> Control: severity -1 normal
>> Control: tags -1 patch
>> Control: reassign -1 initramfs-tools
>>
>> On Jan 06, crvi  wrote:
>>
>>>* What outcome did you expect instead?
>>> 
>>> Successful ramfs generation
>> Do you have any reason to believe that the initrfamfs was not generated 
>> successfully?
>>
>> This is only cosmetic, and it needs to be fixed in /usr/sbin/mkinitramfs
>> by copying modules.builtin.bin too:
>>
>> -for x in modules.builtin modules.order; do
>> +for x in modules.builtin modules.builtin.bin modules.order; do
>
> modules.builtin.bin is created, and always regenerated, by depmod based
> on modules.builtin.  Requiring modules.builtin.bin to exist before
> running depmod makes no sense at all.
>
> So what change made depmod spit out this pointless warning?  You should
> fix that bug instead insisting that some other package paper over it.

FYI: the bug is Debian-specific and introduced long ago with this patch:

bjorn@miraculix:/tmp/kmod-26+20191223$ cat debian/patches/verbose_missing_bin 
Description: Report an error when some .bin files do not exist
Author: Marco d'Itri 
Bug-Debian: http://bugs.debian.org/684901
---

--- a/libkmod/libkmod.c
+++ b/libkmod/libkmod.c
@@ -503,7 +503,7 @@ static char *lookup_builtin_file(struct
 
idx = index_file_open(fn);
if (idx == NULL) {
-   DBG(ctx, "could not open builtin file '%s'\n", fn);
+   ERR(ctx, "could not open builtin file '%s'\n", fn);
return NULL;
}
 
@@ -575,7 +575,7 @@ char *kmod_search_moddep(struct kmod_ctx
 
idx = index_file_open(fn);
if (idx == NULL) {
-   DBG(ctx, "could not open moddep file '%s'\n", fn);
+   ERR(ctx, "could not open moddep file '%s'\n", fn);
return NULL;
}
 




Non-existing files is expected for libkmod in some situations, like the
current example when depmod is looking up a module while generating
dependencies for it.



Bjørn

Bug#948257: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_N1a1Mk/lib/modules/5.4.0-1-amd64/modules.builtin.bin'

[Bjørn Mork]

Marco d'Itri  writes:

> Control: severity -1 normal
> Control: tags -1 patch
> Control: reassign -1 initramfs-tools
>
> On Jan 06, crvi  wrote:
>
>>* What outcome did you expect instead?
>> 
>> Successful ramfs generation
> Do you have any reason to believe that the initrfamfs was not generated 
> successfully?
>
> This is only cosmetic, and it needs to be fixed in /usr/sbin/mkinitramfs
> by copying modules.builtin.bin too:
>
> -for x in modules.builtin modules.order; do
> +for x in modules.builtin modules.builtin.bin modules.order; do

modules.builtin.bin is created, and always regenerated, by depmod based
on modules.builtin.  Requiring modules.builtin.bin to exist before
running depmod makes no sense at all.

So what change made depmod spit out this pointless warning?  You should
fix that bug instead insisting that some other package paper over it.


Bjørn

Bug#903161: changing socket permissions seems to be the best solution for now

[Bjørn Mork]

I tried the different methods suggested in this bug report, but had
no success with any of them.

Using

  stats_writer_socket_path=

causes "doveadm index" to fail with

 bjorn@canardo:~$ doveadm index -q -u bjorn INBOX.Spam
 doveadm(bjorn): Error: net_connect_unix() failed: Connection refused

This can probably be worked around.  But I'd prefer too many hacks just
to make stuff work again...

For now I ended up using:

service stats {
  unix_listener stats-writer {
mode = 0666
  }
}


I don't want to add mail users to the dovecot group. It's unclear to me
what privileges this will result in now and in the future. And I don't
want to maintain yet another mail user group anyway.

This mess should really be sorted out.  Either there should be a way to
easily disable the stats service, or using it should be allowed for all
currently unprivileged operations.  By default.



Bjørn

Bug#939753: systemd fails to deactivate swap on reboot

[Bjørn Mork]

Michael Biebl  writes:

> I'd say fixing up your GPT information is what you should do.

Sure. If I only knew how.  What's wrong with my GPT?


Bjørn

Bug#939753: systemd fails to deactivate swap on reboot

[Bjørn Mork]

Michael Biebl  writes:

> Control: tags -1 moreinfo
>
> Can you attach the output of blkid please.

canardo:/tmp# blkid
/dev/nvme0n1: PTUUID="397e5dc0-a3b9-42b1-a964-55fa71c8f070" PTTYPE="gpt"
/dev/nvme0n1p1: UUID="0759-95BE" TYPE="vfat" 
PARTUUID="6750d885-492b-4e6b-9ee1-2db6762b28e2"
/dev/nvme0n1p2: UUID="e3e2ae9b-c1a6-cc88-35ec-82a4f47a014f" 
UUID_SUB="2c5602e8-de14-8bcc-4108-d3a83274bfb7" LABEL="canardo:0" 
TYPE="linux_raid_member" PARTUUID="7af46f06-063f-469c-a886-11ee0c1ec6a2"
/dev/nvme0n1p3: UUID="2f3d4dc9-3580-1397-d3a0-07e9fdfd1576" 
UUID_SUB="d9aa3a60-ae9f-c67e-dc02-baeccd8acd0c" LABEL="canardo:1" 
TYPE="linux_raid_member" PARTUUID="0a170f26-360a-4bcb-9852-4cbab0729a8d"
/dev/nvme0n1p4: UUID="9e11359b-8347-4b75-a351-5edfbf843af6" TYPE="swap" 
PARTUUID="d482741d-2685-4206-b409-54708d2ff7b0"
/dev/md0: UUID="a01a8a4a-11be-4702-9e8f-abc2d5248134" TYPE="ext4"
/dev/md1: UUID="607785b3-2cd6-4030-a10d-16598229ec25" TYPE="ext4"
/dev/sda1: UUID="2EF6-0DDF" TYPE="vfat" 
PARTUUID="622d2b94-0276-4099-8801-a47fa03eb781"
/dev/sda2: UUID="e3e2ae9b-c1a6-cc88-35ec-82a4f47a014f" 
UUID_SUB="9cb747f5-dae9-89c7-d94a-e62c27e9d44b" LABEL="canardo:0" 
TYPE="linux_raid_member" PARTUUID="402e3a83-3030-4cf7-aedf-8da5864a1cb2"
/dev/sda3: UUID="2f3d4dc9-3580-1397-d3a0-07e9fdfd1576" 
UUID_SUB="e9d4b8c5-7410-d24c-9447-5976a8ffaaf6" LABEL="canardo:1" 
TYPE="linux_raid_member" PARTUUID="3fe8c3ff-4d49-4935-a965-02d83c6c38cf"
/dev/sdc1: UUID="799c6a0b-bb58-7d81-30fc-5d3f6e4ad2e5" 
UUID_SUB="36348661-d47b-3215-7ff0-51d7e1909696" LABEL="canardo:2" 
TYPE="linux_raid_member" PARTUUID="3e907e5f-bf8b-49f3-a2bb-052711c8e6f2"
/dev/sdb1: UUID="799c6a0b-bb58-7d81-30fc-5d3f6e4ad2e5" 
UUID_SUB="70d19626-6e1e-a269-db58-7df0f13a7bb8" LABEL="canardo:2" 
TYPE="linux_raid_member" PARTUUID="d153854a-25a1-4fac-a906-56a516489a50"
/dev/md2: UUID="5d7e8f84-08c8-42cb-86cf-c725a296cba1" TYPE="ext4"

> I suspect it is systemd-gpt-auto-generator which generates this swap
> unit based on the GPT information it finds (man 8
> systemd-gpt-auto-generator)
>
> You can of course disable that generator if you so desire.

Thanks.  Sounds like a good idea.

> First I'd like to figure out though why it finds a swap partitions which
> you say doesn't exist.

The partition exists.  But a swap partition isn't swap more than a Linux
partition is ext4


> If you run systemd-analyze set-log-level-debug; systemctl daemon-reload
> do you get any journal log messages from systemd-gpt-auto-generator ?

Can't get that to work

canardo:/tmp# systemd-analyze set-log-level-debug; systemctl daemon-reload
Unknown operation set-log-level-debug.


Bjørn

Bug#935589: cdimage.debian.org: xserver-xorg-input-synaptics package missing in xfce-CD-1 iso

[Bjørn Mork]

Julien Cristau  writes:

> Users shouldn't have to think about it.  It's our job to make our
> install process do the right thing in the first place.

Well, it doesn't, and most users are aware of that.  DTRT is hard. It's
almost impossible when hardware is part of the equation.  Debian is
good, but will for example fail to install support for 3G/LTE modems if
you happen to select the LXDE task, because lxde recommends

 wicd | network-manager-gnome

Just one example where a user will have to look for packages supporting
their specific hardware after installation.  I'm sure there are plenty
of similar edge cases.  Users expect it and act accordingly. The
existense of an "obsolete" package like xserver-xorg-input-synaptics,
with no indication that it is obsolete, is therefore a problem.

As shown by this completely unnecessary bug and discussion.



Bjørn

Bug#935589: cdimage.debian.org: xserver-xorg-input-synaptics package missing in xfce-CD-1 iso

[Bjørn Mork]

Julien Cristau  writes:

> The synaptics Xorg driver is obsolete and should not be installed by
> default.

Maybe the xserver-xorg-input-synaptics package could hint about this and
point to xserver-xorg-input-libinput?  As it is now, I don't understand
how anyone is supposed to figure out that this is an obsolete package;

Package: xserver-xorg-input-synaptics
Version: 1.9.1-1
Installed-Size: 324
Maintainer: Debian X Strike Force 
Architecture: amd64
Replaces: xorg-driver-synaptics
Provides: xorg-driver-input, xorg-driver-synaptics
Depends: libc6 (>= 2.15), libevdev2 (>= 1.3), libx11-6, libxi6 (>= 2:1.2.0), 
libxtst6, xorg-input-abi-24, xserver-xorg-core (>= 2:1.18.99.901)
Suggests: gpointing-device-settings, touchfreeze
Conflicts: xorg-driver-synaptics
Breaks: kde-config-touchpad (<< 0.8.1-2~)
Description-en: Synaptics TouchPad driver for X.Org server
 This package provides an input driver for the X.Org X server to enable
 advanced features of the Synaptics Touchpad including:
 .
  * Movement with adjustable, non-linear acceleration and speed
  * Button events through short touching of the touchpad
  * Double-Button events through double short touching of the touchpad
  * Dragging through short touching and holding down the finger on the touchpad
  * Middle and right button events on the upper and lower corner of the touchpad
  * Vertical scrolling (button four and five events) through moving the finger
on the right side of the touchpad
  * The up/down button sends button four/five events
  * Horizontal scrolling (button six and seven events) through moving the finger
on the lower side of the touchpad
  * The multi-buttons send button four/five events, and six/seven events for
horizontal scrolling
  * Adjustable finger detection
  * Multifinger taps: two finger for middle button and three finger for right
button events. (Needs hardware support. Not all models implement this
feature.)
  * Run-time configuration using shared memory. This means you can change
parameter settings without restarting the X server (see synclient(1)).
  * It also provides a daemon to disable touchpad while typing at the keyboard
and thus avoid unwanted mouse movements (see syndaemon(1)).
Description-md5: 6f7a84d9a52f4dc44fd0ad7cc265853b
Tag: hardware::input, hardware::laptop, implemented-in::c, role::plugin,
 role::program, use::driver, x11::xserver
Section: x11
Priority: optional
Filename: 
pool/main/x/xserver-xorg-input-synaptics/xserver-xorg-input-synaptics_1.9.1-1_amd64.deb
Size: 219712
MD5sum: 6f95416d63be90a95acf862dc12b8904
SHA256: 36bb385f930b1731a6a39f9aedab474942d779b5c1fda33c5814eec9f5923752



Compare that to the rather sparse description of the replacement:


Package: xserver-xorg-input-libinput
Version: 0.28.2-2
Installed-Size: 138
Maintainer: Debian X Strike Force 
Architecture: amd64
Provides: xorg-driver-input
Depends: libc6 (>= 2.7), libinput10 (>= 1.11.1), xorg-input-abi-24, 
xserver-xorg-core (>= 2:1.18.99.901)
Description-en: X.Org X server -- libinput input driver
 This package provides the driver for input devices using libinput library.
 It can handle keyboards, mice and touchpads, and essentially replaces the
 separate -evdev and -synaptics drivers.
 .
 This package is built from the X.org xf86-input-libinput driver module.
Description-md5: f8bfd1aa5c6b0f14ea81809036429317
Homepage: https://www.x.org
Section: x11
Priority: optional
Filename: 
pool/main/x/xserver-xorg-input-libinput/xserver-xorg-input-libinput_0.28.2-2_amd64.deb
Size: 61472
MD5sum: 1a4f2f8168f4995c98c71a8640e729a0
SHA256: 96ed7234dec3aea8bec57850064ad2258ada2d53cbf3741da1490799b073f69b



Exactly which packages does it replace?  And "essentially"?  Does it
replace them, or not?  If so, then why isn't there any "Replaces" field?

But you can't really expect users to look at xserver-xorg-input-libinput
at all.  Why should they?  There is no pointer to it from the "obsolete"
package.  What kind of deprecation is that? Most users will probably
read the first lines of the verbose xserver-xorg-input-synaptics
description, see "enable advanced features of the Synaptics Touchpad",
and think "YES! I want that!".




Bjørn

Bug#926261: closed by Ben Hutchings (Re: Bug#926261: linux-image-4.19.0-4-amd64: fan continiously spinning above 6900 RPM after resume on lenovo carbon x1 thinkpad with isa adap

[Bjørn Mork]

Not going to argue against this being a firmware bug.  I'm sure that is
true.  But Linux must deal with buggy firmware.  Else it cannot run on
any real system :-)

And this bug (or at least the bad effect on Linux) is a regression
introduced by commit c3a696b6e8f8 ("ACPI / EC: Use busy polling mode
when GPE is not enabled"), which again was an attempt to work around
firmware bugs in other systems.

This has been reported upstream, but AFAICS it is still only partially
fixed.  Ref the thread ending here:
https://spinics.net/lists/stable/msg214463.html


Bjørn

Bug#914495: linux-image-4.18.0-3-amd64: does not boot here

[Bjørn Mork]

Bjørn Mork  writes:
> Given this, there is an extremely suspicious commit added in v4.18.20: 
>
>  06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for 
> gen4/gen5")
>
> I do have an old laptop with an affected chipset generation, and
> verified that it had the same symptoms.  But never got the time to
> actually test any further.  Still, I do think that there is good reason
> to simply try a revert of that commit.

FWIW, I have now verified that reverting commit 06e562e7f515
("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5") fixes
this issue for me.



Bjørn

Bug#914495: linux-image-4.18.0-3-amd64: does not boot here

[Bjørn Mork]

Ben Hutchings  writes:
> On Mon, 2018-12-03 at 23:08 +0100, TS wrote:
>
>> Just out of curiosity since linux-image-amd64 4.18+100 has been uploaded to
>> unstable. This issue here seems not to be wide spread, or reproducible?
>
> Hard to tell.  There are a few people that reported the same *symptom*,
> but that doesn't mean they found the same bug.

True of course.  But in this case there seems to be a very strong
correlation with Gen4 Intel GPUs. I believe every one of the reports
have had at least a lspci dump showing one of those. And a couple of
the reports had stack traces pointing to gen4_render_ring_flush as well.

Given this, there is an extremely suspicious commit added in v4.18.20: 

 06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5")

I do have an old laptop with an affected chipset generation, and
verified that it had the same symptoms.  But never got the time to
actually test any further.  Still, I do think that there is good reason
to simply try a revert of that commit.



Bjørn

Bug#906593: Crash with intel 8265

[Bjørn Mork]

Hugo Mercier  writes:

> It seems I have a similar problem on a Thinkpad X1 4th generation.

So, since I also run Debian sid on one of those, and haven't got any
issues, I thought I would compare firmware versions etc


> $ lspci -v
> 04:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 88)
>   Subsystem: Intel Corporation Wireless 8265 / 8275 (Dual Band
> Wireless-AC 8265)


But this didn't match...

> Nov 19 10:42:20 mhugo kernel: [ 5007.023990] Hardware name: LENOVO 
> 20HRCTO1WW/20HRCTO1WW, BIOS N1MET39W (1.24 ) 09/27/2017

And neither did this.

Which is becuase this isn't a log from a 4th gen.  You have a 5th gen
X1.  Not that I think it matters, since you got the 8265 right.  But
still.  Best to have correct info in the bug report.



Bjørn

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[Bjørn Mork]

Phil  writes:

> Hi, I hope you're all doing well.
>
> Shall we/I maybe reopen a new issue?

I believe so.  I am almost sure we fixed the original memset BUG in
cdc_ncm_fill_tx_frame. Or at least one of them...

So you are probably seeing another issue if you still have problems with
that fix in place.  Although the issues may or may not be related.  But
still, aother bug report would make it easier to track given that we
alread have one fix for 893393.

> I'm still affected by this and I'd could use some advice how to debug
> the issue a little bit better, especially since the kexec kernel
> crashdumps appear not to be helpful. Can I maybe compile the module with
> special debug flags and load it via. dkms or something?

Crash reports of some sort are best.  But any info is useful.  Like what
device is this really and what mode is in currently in?  What driver
does it use?  Most Huawei firmwares will support many different modes
using different USB drivers. But laptop internal modems are most likely
not tested with anything but the Windows MBIM class driver, since that
is the certification requirement and only target platform.

You can enable the little debugging that's already in the drivers by
doing something like

 echo 'module cdc_ncm +fp' >/sys/kernel/debug/dynamic_debug/control
 echo 'module cdc_mbim +fp' >/sys/kernel/debug/dynamic_debug/control
 echo 'module huawei_cdc_ncm +fp' >/sys/kernel/debug/dynamic_debug/control

See https://www.kernel.org/doc/html/v4.11/admin-guide/dynamic-debug-howto.html

Not sure it will be useful to debug a freeze though.

> I don't see any actual changes in [cdc_ncm.c][cdc_ncm], besides the one
> change in `cdc_ncm_unbind`.

Not sure I understood this...  Are you referring to the fix for bug
893393?  That's part of the v4.9.111 stable release:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/usb/cdc_ncm.c?h=linux-4.9.y=35fd10aeb2248cc7f8d3d48ccc2eff1cf19918f4

> Also I'm confused why this is happening now again, I managed to do an
> rsync upload with ~10GB over night back then - and my system didn't
> crash - but right now even if I'm just trying to upload a picture to
> twitter via. Firefox my laptop freezes.

Freezing without any Oops or similar? 



Bjørn

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[Bjørn Mork]

This issue should be fixed by commit

 49c2c3f246e2 ("cdc_ncm: avoid padding beyond end of skb")

which has been backported to v4.17.3, v4.16.18 and v4.14.52.  Please
check again with one of those kernel versions (or newer).

I see now that the fix doesn't apply cleanly to v4.9 stable due to
unrelated context changes.  I'll go fix that and resubmit a backport for
v4.9, so we get the fix into "stretch" too.  Thanks for reminding me.



Bjørn

Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway

[Bjørn Mork]

Samuel Thibault  writes:

> It's a matter of someone fixing the code.  It seems Igor Scheller is
> happy to work on it, he just needs a way forward, not being only told
> that what is currently there is nonsense.

Well, using fe80::1 as default gateway would not be a problem if it
weren't for the existing nonsensical code. Don't know how to say that in
any other way.

Selecting a default router is described in
  https://tools.ietf.org/html/rfc4861#section-6.3.6
which points to
  https://tools.ietf.org/html/rfc4861#section-7.3
for the reachability detection.

So if you take a single default router address as input, then the
validation bolis down to sending a Neighbor Solicitation and seeing if
you receive a Neighbor Advertisement back.



Bjørn

Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway

[Bjørn Mork]

Samuel Thibault  writes:

> Bjørn Mork, le mar. 12 juin 2018 13:30:39 +0200, a ecrit:
>> But this will:
>> 
>> frtest3:~# ip route add 2001:db8:f00::1/128 dev eth1
>
> So this is a route, which can be checked for.

No, it is a route you can safely add.  Checking for it is no point.  It
does not have to exist prior to adding the gateway.

>> > which is the point of the test AIUI.
>> 
>> The test is pointless.  There is absolutely no requirement that the
>> gateway should be part of any larger on-link prefix or related to any of
>> the configured host addresses in any way.
>
> Please scratch from your mind whatever you thought I meant.
>
> What I meant is that a route is needed for that. That is what we can
> really check for to provide useful feedback to a user making a typo,
> before trying to reach something on the Internet that might just be
> randomly off.

Noe, you can't check this.  It makes no sense.  But I think we are
running in circles now.  let's just flag the Debian IPv6 implementation
as broken on this point and move on.







Bjør

Bug#901255: netcfg-static: Unable to configure fe80::1 as a gateway

[Bjørn Mork]

Samuel Thibault  writes:

> Bjørn Mork, le mar. 12 juin 2018 10:52:30 +0200, a ecrit:
>> Huh?  What is this?  There is no "gateway must be in subnet" requirement
>> in IPv6.  The gateway must only be reachable, which means that you must
>> be able to resolve the L2 address using ND.
>
> Before that, you need a route,

Sure.  And that will be automatically added when the gateway sends an
NA.  But you can also simply add the gateway address as a static on-link
/128 since you must assume that the gateway is on-link.

Only static routing, no RAs involved and no NA received after flushing
the neighbour table:


frtest3:~# ifconfig eth1
eth1: flags=4163  mtu 1500
inet6 2001:4641:0:29a:5054:ff:feff:306  prefixlen 64  scopeid 
0x0
inet6 fe80::5054:ff:feff:306  prefixlen 64  scopeid 0x20
ether 52:54:00:ff:03:06  txqueuelen 1000  (Ethernet)
RX packets 189795  bytes 87803043 (83.7 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 130406  bytes 11889749 (11.3 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

frtest3:~# ip -6 route
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium


Then this will not immediately work, as you note:

frtest3:~# ip route add default via 2001:db8:f00::1 dev eth1
RTNETLINK answers: No route to host


But this will:

frtest3:~# ip route add 2001:db8:f00::1/128 dev eth1
frtest3:~# ip route add default via 2001:db8:f00::1 dev eth1
frtest3:~# ip -6 ne sho
2001:4641:0:29a::1 dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE
fe80::21b:21ff:fea7:98bc dev eth1 lladdr 00:1b:21:a7:98:bc router STALE
2001:db8:f00::1 dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE
fe80::21b:21ff:fea7:98bc dev eth0 lladdr 00:1b:21:a7:98:bc router STALE
frtest3:~# ip -6 route
2001:db8:f00::1 dev eth1 metric 1024 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
default via 2001:db8:f00::1 dev eth1 metric 1024 pref medium


frtest3:~# traceroute6 vg.no
traceroute to vg.no (2001:67c:21e0::16), 30 hops max, 80 byte packets
 1  canardo-br0-666.ipv6.mork.no (2001:4641:0:29a::1)  0.354 ms  0.445 ms  
0.530 ms
 2  ti0036a400-lo0-0.ti.telenor.net (2001:4600:0:200::5d)  5.932 ms  7.537 ms  
7.591 ms
 3  ti0001c360-lo0-0.ti.telenor.net (2001:4600:0:100::23)  7.292 ms  7.488 ms  
7.791 ms
 4  ti0169a400-lo0-0.ti.telenor.net (2001:4600:0:200::62)  8.207 ms  8.218 ms  
8.481 ms^C

(The gateway used its real address as icmp6 source here, but that is
beside the point)


frtest3:~# ip -6 ne sho
2001:4641:0:29a::1 dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE
fe80::21b:21ff:fea7:98bc dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE
2001:db8:f00::1 dev eth1 lladdr 00:1b:21:a7:98:bc router REACHABLE
fe80::21b:21ff:fea7:98bc dev eth0 lladdr 00:1b:21:a7:98:bc router STALE
frtest3:~# ip -6 route
2001:db8:f00::1 dev eth1 metric 1024 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
default via 2001:db8:f00::1 dev eth1 metric 1024 pref medium


> which is the point of the test AIUI.

The test is pointless.  There is absolutely no requirement that the
gateway should be part of any larger on-link prefix or related to any of
the configured host addresses in any way.  This is trying to force IPv4
logic onto IPv6, where it doesn't fit.

> That said, the code should be looking over all networks of the
> interface, not only the first.

"networks" is a meaningless concept in IPv6.  You have addresses which
can be on-link or off-link, and prefixes which are relevant for routing
and address generation.  But none of these maps directly to the IPv4
"network".


Bjørn

Bug#897572: urandom hang in early boot

[Bjørn Mork]

Ben Hutchings  writes:
> On Tue, 2018-05-08 at 11:12 +1200, Ben Caradoc-Davies wrote:
>> On 08/05/18 05:34, Laurent Bigonville wrote:
>> > Apparently it's also happening for other applications that are starting 
>> > later during the boot like GDM.
>> > Somebody has reported an issue on IRC where GDM was taking upto 8 
>> > minutes to start (dmesg was showing several "random: systemd: 
>> > uninitialized urandom read (16 bytes read)" during boot)
>> > That problem might impact lot of people I'm afraid.
>> 
>> systemd is the underlying cause: plymouthd uses libudev1, which expects 
>> getrandom/urandom(?) to never block:
>> https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L34
>> 
>> See discussion here about systemd usage of random numbers:
>> systemd reads from urandom before initialization
>> https://github.com/systemd/systemd/issues/4167
>> 
>> The new problem is that 43838a23a05f ("random: fix crng_ready() test") 
>> turns an ugly warning and cryptographic weakness into an indefinite 
>> hang. Security achieved!
>
> You keep saying this, but based on my reading of the code I don't see
> how reads from /dev/urandom can end up blocking.

It's a bit convoluted, but if I read the code correctly then
acquire_random_bytes() falls back to busy-loop reading from /dev/urandom
until it has the requested number of bytes if 'high_quality_required' is
true.

There aren't more than two such calls, but one of then is
sd_id128_randomize() which calls acquire_random_bytes(, sizeof t, true).

And sd_id128_randomize() is called from all over the place.  I haven't
bothered looking at all the call sites, but would be surprised if not at
least one of them is unconditionally called at boot.

If I am correct, then I guess this is a systemd bug?


Bjørn

Bug#897408: python3-attr: upstream changelog is missing

[Bjørn Mork]

Package: python3-attr
Version: 17.4.0-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is obviously not very useful without including CHANGELOG.rst:

 bjorn@miraculix:~$ zcat /usr/share/doc/python3-attr/changelog.gz
 .. include:: ../CHANGELOG.rst

If the real upstream changelog is named CHANGELOG.rst it should be
included in tha binary package, and either renamed to changelog or
symlinked from changelog.  Ref policy 12.7



Bjørn

- -- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0 (SMP w/4 CPU cores)
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 python3-attr depends on:
ii  python3  3.6.5-3

python3-attr recommends no packages.

Versions of packages python3-attr suggests:
pn  python-attr-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIQEARYKACwWIQRoe+CASfFh7aZ6shIiBE7Lv6RhXQUCWultJg4cYmpvcm5AbW9y
ay5ubwAKCRAiBE7Lv6RhXWJ9AQDon0K/bLZGdeYUxq28tRB79Wwvx76N1FV8MO5P
IIuUUwEAosPSUZstTF35NqBuWUZ60ez/yKYVIzkfIInLWYxBnw0=
=InkE
-END PGP SIGNATURE-

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[Bjørn Mork]

Горбешко Богдан  writes:

> vboxdrv(O)
> binder_linux(O)
> ashmem_linux(O)

Can you reproduce the problem without these modules loaded?

AFAICS there is no way the only memset in cdc_ncm can be called with
crashing input parameters. Unless something is scribbling over the
driver's data.


Bjørn

Bug#891502: ITP: irda-dkms -- IrDA subsystem and device drivers

[Bjørn Mork]

Christopher Schramm  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Christopher Schramm 
>
> * Package name: irda-dkms
>   Version : 0.1
> * URL : https://github.com/cschramm/irda
> * License : GPL
>   Programming Lang: C
>   Description : IrDA subsystem and device drivers
>
> The IrDA subsystem and device drivers got moved to staging and scheduled for
> removal upstream in Linux 4.14 [1] and consequently disabled in the Debian
> builds [2].
>
> [1] https://lkml.org/lkml/2017/8/27/126
> [2] 
> https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=d12b3a11b2800489cde0be2d74872af04b5b8f36
>
> As I personally do have a use case for IrDA and am sure that I am not the only
> one, I moved the code (from 4.15; not compatible to 4.14!) into a GitHub
> repository [3], converted the build system to Kbuild files, and added a DKMS
> configuration and a Travis CI configuration to check the build with current
> kernel releases.
>
> [3] https://github.com/cschramm/irda
>
> I already prepared the packaging files. See [4] for copyright and license.
>
> [4] https://github.com/cschramm/irda/blob/debian/debian/copyright

Why not raise your hand and offer to maintain IrDA in mainline instead?
The problems causing it to be shceduled for removal will not be
magically solved by reviving the code on github. There is real work
required here. And maintaining the code out-of-tree is going to be much
much harder than keeping it in mainline. Noone else will look at
out-of-tree code even if they break it by changing some API.  And you
end up having to support multiple versions of the APIs as they change.

But maybe you already offered to take over IrDA and I just missed it?


Bjørn

Bug#875851: emacs25: gnus + epg needs gpgsm for S/MIME verfication

[Bjørn Mork]

Package: emacs25
Version: 25.1+1-4
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please add a depends or recommends on gpgsm.

Opening an S/MIME signed email in gnus will result in the rather cryptic
message

  epg-context--make: GPG error: "no usable configuration", CMS

if the gpgsm application is missing.  Figuring out the root cause of this
takes some Googling... Let's save the users from having to do that by
hinting about the dependency.

Ref discussion at
https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-10/msg00881.html


Bjørn


- -- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (700, 'stable'), (699, 'proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
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 emacs25 depends on:
ii  emacs25-bin-common 25.1+1-4
ii  gconf-service  3.2.6-4+b1
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.3-5
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-11+deb9u1
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libdbus-1-31.10.18-1
ii  libfontconfig1 2.12.3-0.2
ii  libfreetype6   2.6.3-3.2
ii  libgconf-2-4   3.2.6-4+b1
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libgif75.1.4-0.4
ii  libglib2.0-0   2.50.3-2
ii  libgnutls303.5.8-5+deb9u2
ii  libgomp1   6.3.0-18
ii  libgpm21.20.4-6.2+b1
ii  libgtk-3-0 3.22.11-1
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.1-2
ii  libm17n-0  1.7.0-3+b1
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-11+deb9u1
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-11+deb9u1
ii  libotf00.9.13-3+b1
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpng16-161.6.28-1
ii  librsvg2-2 2.40.16-1+b1
ii  libselinux12.6-3+b1
ii  libsm6 2:1.2.2-1+b3
ii  libtiff5   4.0.8-2+deb9u1
ii  libtinfo5  6.0+20161126-1
ii  libx11-6   2:1.6.4-3
ii  libx11-xcb12:1.6.4-3
ii  libxcb11.12-1
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-1+b2
ii  libxinerama1   2:1.1.3-1+b3
ii  libxml22.9.4+dfsg1-2.2+deb9u1
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.8.dfsg-5

emacs25 recommends no packages.

Versions of packages emacs25 suggests:
ii  emacs25-common-non-dfsg  25.1+1-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEE9GFvUSsROzwYJzwh4Zf8Eu/wXs0FAlm7fOwOHGJqb3JuQG1v
cmsubm8ACgkQ4Zf8Eu/wXs2O4BAAvGPu54bSJdCPieXw+6+Am0IySCd4YsMhdgtD
M0g2j+C7yMYp6MVcyUEEIxORwqsB/VKkDKaJz7cTaVL/8X/Uy2c58l5NxyJORIjy
uKkwotO5taq7x7azDiTS0BQ8weB4ok3duukyXjmOWmueECvdI/ZXvEaa48dZDBA+
s8OCo+2QnI71z+4dyfVatQWg6DnEQkxoSUVUz3Bk/oNEELmKtly8K2ZpZ2xCUEHP
LwO5QirBFERGMSfXQOkkQB1TbP3k4zHT8Irr4SSIRtgsbDKkJXyVy43q/Kw8ownE
XY9BcAKDSoo3yLnHJSxo9nbxPJVvxJ2D3ysqakDO2yI3mpnsBrKMHecoIy4we5bI
gwX5+5WT3N7dOJL/tE2dHSJoKrqdDfeEFcWuj5BYlLSlhn2leu0XLqhdWS2uimdz
4Khfww7G/L2UPuG0hlUjzqcNeVUqCjgV5zGyU8yMrQ1YbagKoMYwObQL9uM1eVwa
9oyP+IkCZn2mgLtPZxDswyXurQb9yqo0zDtqU5pwR06Yay9nwwhAroHWygw8/85s
iN6NM0GobR/ygxxfP43j0jX3GIcTner0YzAYDpLYFtOE4UijWvuJd9D8HOYhSNk5
p+nji/ShoeKHmqhifgYoU0cViPQHjSWAMURUiYe073e9zUuJ7s731qUR86Zmykxl
y7dkISQ=
=qD3w
-END PGP SIGNATURE-

Bug#871639: NULL pointer dereference in reset_common_ring+0xc3/0x170 [i915]

[Bjørn Mork]

Package: src:linux
Version: 4.9.30-2+deb9u3
Severity: normal
File: /boot/vmlinuz-4.9.0-3-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've been having issues with the i915 driver ever since I got this Skylake 
laptop.
The GPU is hanging every now and then.  But the error handling has become worse
over time, from merely pausing a few seconds via X restarting,  to now ooopsing
after updating to 4.9.30-2+deb9u3.

The issue started with a few warnings I've seen before, followed by the oops 
(which
is a new symptom AFAIK):

[drm] GPU HANG: ecode 9:0:0xffd7fffe, in Xorg [842], reason: Hang on render 
ring, action: reset
[drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including 
userspace.
[drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> 
DRM/Intel
[drm] drm/i915 developers can then reassign to the right component if it's not 
a kernel issue.
[drm] The gpu crash dump is required to analyze gpu hangs, so please always 
attach it.
[drm] GPU crash dump saved to /sys/class/drm/card0/error
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
- [ cut here ]
WARNING: CPU: 3 PID: 842 at 
/build/linux-me40Ry/linux-4.9.30/drivers/gpu/drm/i915/intel_display.c:14180 
intel_atomic_commit_tail+0xf2b/0xf50 [i915]
pipe A vblank wait timed out
Modules linked in: ses enclosure sd_mod scsi_transport_sas sg uas usb_storage 
scsi_mod rfcomm ctr ccm ipt_REJECT nf_reject_ipv4 iptable_filter xt_set 
ip_set_hash_ip ip_set nfnetlink 8021q garp mrp stp llc tun cmac bnep arc4 
snd_hda_codec_hdmi snd_hda_codec_conexant intel_rapl x86_pkg_temp_thermal 
intel_powerclamp snd_hda_codec_generic coretemp kvm_intel kvm irqbypass 
snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp crct10dif_pclmul 
snd_hda_ext_core crc32_pclmul snd_soc_sst_match nls_ascii snd_soc_core 
nls_cp437 ghash_clmulni_intel cdc_mbim snd_compress cdc_wdm cdc_ncm usbnet 
qcserial intel_cstate usb_wwan vfat mii fat usbserial sparse_keymap iwlmvm 
btusb btrtl btbcm btintel bluetooth mac80211 intel_uncore iwlwifi efi_pstore 
snd_hda_intel intel_rapl_perf snd_hda_codec evdev
 iTCO_wdt joydev snd_hda_core snd_hwdep snd_pcm serio_raw efivars 
iTCO_vendor_support i915 snd_timer hid_sensor_accel_3d uvcvideo 
hid_sensor_trigger videobuf2_vmalloc hid_sensor_iio_common videobuf2_memops 
cfg80211 industrialio_triggered_buffer videobuf2_v4l2 kfifo_buf rtsx_pci_ms 
thinkpad_acpi videobuf2_core drm_kms_helper industrialio nvram memstick 
videodev drm mei_me snd media soundcore mei shpchp intel_pch_thermal rfkill ac 
battery i2c_algo_bit video tpm_crb wmi button parport_pc ppdev lp parport 
sunrpc efivarfs ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto ecb mbcache 
crc32c_generic hid_sensor_custom hid_sensor_hub intel_ishtp_hid hid 
rtsx_pci_sdmmc mmc_core crc32c_intel aesni_intel aes_x86_64 glue_helper lrw 
gf128mul ablk_helper cryptd i2c_i801 psmouse i2c_smbus e1000e ptp nvme pps_core 
nvme_core xhci_pci xhci_hcd rtsx_pci mfd_core usbcore intel_ish_ipc usb_common 
intel_ishtp thermal
CPU: 3 PID: 842 Comm: Xorg Not tainted 4.9.0-3-amd64 #1 Debian 4.9.30-2+deb9u3
Hardware name: LENOVO 20FB006AMN/20FB006AMN, BIOS N1FET47W (1.21 ) 11/28/2016
  82728574 bea0c2be3b18 
 82476ebe  bea0c2be3b70 9c1b2c59
  9c1b2c565000 0001 82476f3f
Call Trace:
 [] ? dump_stack+0x5c/0x78
 [] ? __warn+0xbe/0xe0
 [] ? warn_slowpath_fmt+0x5f/0x80
 [] ? finish_wait+0x3c/0x70
 [] ? intel_atomic_commit_tail+0xf2b/0xf50 [i915]
 [] ? prepare_to_wait_event+0xf0/0xf0
 [] ? drm_atomic_helper_setup_commit+0x27c/0x380 
[drm_kms_helper]
 [] ? intel_atomic_commit+0x355/0x4c0 [i915]
 [] ? drm_atomic_helper_connector_dpms+0xe8/0x190 
[drm_kms_helper]
 [] ? drm_mode_connector_set_obj_prop+0x5b/0x70 [drm]
 [] ? drm_mode_obj_set_property_ioctl+0x11b/0x160 [drm]
 [] ? drm_mode_connector_property_set_ioctl+0x3e/0x60 [drm]
 [] ? drm_ioctl+0x1ea/0x470 [drm]
 [] ? drm_mode_connector_set_obj_prop+0x70/0x70 [drm]
 [] ? pipe_read+0x288/0x2d0
 [] ? do_vfs_ioctl+0x9f/0x600
 [] ? vfs_read+0x119/0x130
 [] ? SyS_ioctl+0x74/0x80
 [] ? system_call_fast_compare_end+0xc/0x9b
- ---[ end trace 93f14b701ef00ca8 ]---
[drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* 
[CRTC:26:pipe A] flip_done timed out
[drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* 
[CRTC:26:pipe A] flip_done timed out
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
- [ cut here ]
WARNING: CPU: 2 PID: 879 at 
/build/linux-me40Ry/linux-4.9.30/drivers/gpu/drm/i915/intel_display.c:14180 
intel_atomic_commit_tail+0xf2b/0xf50 [i915]
pipe A vblank wait timed out
Modules linked in: 

Bug#864878: /boot/vmlinuz-4.9.0-3-amd64: Please enable CONFIG_HPFS_FS as a module

[Bjørn Mork]

Package: src:linux
Version: 4.9.30-2
Severity: wishlist
File: /boot/vmlinuz-4.9.0-3-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Hello,

it's hard to claim this is important to me since I haven't noticed it was gone 
until
today.  But could you please re-enable CONFIG_HPFS_FS unless there are any 
reasons
not to do so?

It seems to have been disabled as part of the BKL cleanups a long time ago: 

linux-2.6 (2.6.38-1) unstable; urgency=low

  * New upstream release: http://kernelnewbies.org/Linux_2_6_38

  [ Ben Hutchings ]
  * Move firmware-linux-free to separate source package (firmware-free)
  * Move linux-base to separate source package
  * net/can: Enable CAN_SLCAN as module (Closes: #617629)
  * sound: Enable SND_ALOOP as module (Closes: #617869)
  * Remove the Big Kernel Lock:
- adfs,appletalk,i810,ufs,usbip: Refactor locking
- hpfs: Disable HPFS_FS
  * ext4: Disable FS_IOC_FIEMAP ioctl temporarily (together with fixes
for btrfs in 2.6.38, closes: #615035)
  * sched: Build with SCHED_AUTOGROUP, but do not enable autogrouping by
default (use sysctl kernel.sched_autogroup_enabled=1) (Closes: #618486)
  * Set ABI to 1

  [ Aurelien Jarno]
  * mips/malta-[45]kc: 
- disable ATM, TR, WAN.
- synchronize options in malta-4kc and malta-5kc.

 -- Ben Hutchings   Wed, 16 Mar 2011 04:47:57 +



There has been som real work done on this driver since then, including new
feature support, so it is not in a completely unmaintained state at least.
And it builds fine with the current Stretch kernel, of course.  So unless
there is something I miss, I don't really see any reason not to enable it
as a module.

Yes, I do still have a couple of OS/2 Warp disk images leftover from the
90's.  Obviously not something I mount every day.  About once every decade,
I guess.  Looking forward to having Debian suppport then next time I try it
in 2025 or something like that ;-)



Bjørn

- -- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2 (2017-06-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 
root=UUID=71507198-90f4-4c25-be41-efc47d2dedd1 ro

** Not tainted

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

** Model information
sys_vendor: LENOVO
product_name: 20FB006AMN
product_version: ThinkPad X1 Carbon 4th
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N1FET47W (1.21 )
board_vendor: LENOVO
board_name: 20FB006AMN
board_version: SDK0J40697 WIN

** Loaded modules:
rfcomm
ipt_REJECT
nf_reject_ipv4
iptable_filter
xt_set
ip_set_hash_ip
ip_set
nfnetlink
8021q
garp
mrp
stp
llc
tun
cmac
bnep
snd_hda_codec_hdmi
snd_hda_codec_conexant
snd_hda_codec_generic
arc4
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
kvm
irqbypass
snd_soc_skl
nls_ascii
snd_soc_skl_ipc
crct10dif_pclmul
snd_soc_sst_ipc
nls_cp437
crc32_pclmul
snd_soc_sst_dsp
snd_hda_ext_core
snd_soc_sst_match
vfat
snd_soc_core
fat
snd_compress
ghash_clmulni_intel
intel_cstate
sparse_keymap
iwlmvm
efi_pstore
uvcvideo
intel_uncore
videobuf2_vmalloc
videobuf2_memops
mac80211
videobuf2_v4l2
intel_rapl_perf
joydev
evdev
videobuf2_core
efivars
serio_raw
snd_hda_intel
videodev
rtsx_pci_ms
snd_hda_codec
snd_hda_core
snd_hwdep
memstick
iwlwifi
iTCO_wdt
snd_pcm
iTCO_vendor_support
btusb
snd_timer
media
btrtl
cfg80211
thinkpad_acpi
hid_sensor_accel_3d
btbcm
cdc_mbim
btintel
mei_me
cdc_wdm
cdc_ncm
nvram
hid_sensor_trigger
i915
bluetooth
mei
shpchp
usbnet
qcserial
drm_kms_helper
usb_wwan
intel_pch_thermal
mii
hid_sensor_iio_common
snd
industrialio_triggered_buffer
drm
kfifo_buf
soundcore
usbserial
industrialio
i2c_algo_bit
rfkill
wmi
button
ac
battery
video
tpm_crb
parport_pc
ppdev
lp
parport
sunrpc
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
fscrypto
ecb
mbcache
crc32c_generic
hid_sensor_custom
hid_sensor_hub
intel_ishtp_hid
hid
rtsx_pci_sdmmc
mmc_core
crc32c_intel
aesni_intel
aes_x86_64
glue_helper
lrw
gf128mul
ablk_helper
cryptd
psmouse
e1000e
ptp
i2c_i801
pps_core
i2c_smbus
xhci_pci
nvme
xhci_hcd
nvme_core
rtsx_pci
mfd_core
usbcore
intel_ish_ipc
usb_common
intel_ishtp
thermal

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM 
Registers [8086:1904] (rev 08)
Subsystem: Lenovo Skylake Host Bridge/DRAM Registers [17aa:2238]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 520 
[8086:1916] (rev 07) (prog-if 00 [VGA controller])
Subsystem: Lenovo HD Graphics 520 [17aa:2238]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- 

Bug#859641: Please increase USBIP_VHCI_HC_PORTS and USBIP_VHCI_NR_HCS

[Bjørn Mork]

Steve McIntyre  writes:

> In Linaro we're making a lot of use of USB-over-IP devices these days
> for our testing lab. We've hit a (very small!) limit defined in kernel
> config for the number of virtual host controllers and the ports
> allowed per controller.
>
> Currently these are defaulting to
>
> CONFIG_USBIP_VHCI_HC_PORTS=8
> (can be 1 <= CONFIG_USBIP_VHCI_HC_PORTS <= 31)
>
> and
> CONFIG_USBIP_VHCI_NR_HCS=1
> (can be 1 <= CONFIG_USBIP_VHCI_NR_HCS <= 128)
>
> The normal limits are very small; could you please raise these to
> (say) 31 and 8 for us? There will obviously be a small increase in
> memory usage in the kernel, but only for users of these particular
> devices.

FWIW, I believe those constants never should have been accepted. But I
just gave up after getting this answer:
http://www.spinics.net/lists/linux-usb/msg134862.html

"Because it is easy to implement." was obviously more important than
easy to use...  I don't think distro users were considered.

If you care about these limits, then I think you should look into what
needs to be done to make them dynamic.  I cannot imagine that it is all
that difficult.  Which of course is easy to say when you don't actually
plan on doing the work :)



Bjørn

Bug#852802: dnsrecon: please remove misleading mDNS refererence from package description

[Bjørn Mork]

Package: dnsrecon
Version: 0.8.9-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I installed dnsrecon for its advertised
  "Enumerate Common mDNS records in the Local Network"
feature.

After looking around for it, I finally found this:

 bjorn@miraculix:~$ zgrep -i mdns /usr/share/doc/dnsrecon/*
 /usr/share/doc/dnsrecon/README.md.gz:- Removed mDNS enumeration due to the 
pybonjour library has been abandoned and faster ways are available to achieve 
enumeration of mDNS records in a sub-net.

Please update the package description when advertised features are
removed.  Severity is set to 'important' since the package is
completely unusable as an mDNS record enumerator, while it 
probably still is usuable as something else



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

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

Versions of packages dnsrecon depends on:
ii  python-dnspython  1.15.0-1
ii  python-netaddr0.7.18-2
pn  python:any

dnsrecon recommends no packages.

dnsrecon suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEE9GFvUSsROzwYJzwh4Zf8Eu/wXs0FAliLRlAOHGJqb3JuQG1v
cmsubm8ACgkQ4Zf8Eu/wXs035RAAihgBRb0JGyY+qw+nXaY6IC44YREJzpP97+oF
7u63JuU0VedjWENiyTyY2VW3wDBmaJAUOum5jyNFre7jjwybdHSNr3vu2daKSmRC
ZO7gRv0AWKo9FsquyEbRvWcjxS4GcYoag1mCDcnr3+Duet79Jdhlg687aJYryQfM
HNrrcaG+8RihQcKMSrSW/FIWzwvAzWsQ2KuqbkZ5ZTHt3mYIrE3kwZdX5pG8FsPl
RFt8gpsmejOZlUXbTpYA87WAcwmmnvIoziwLoSQ6U+8NOrfHBbqqiR/4H8g8V0sg
BaESJtwlIiOHVXI4vwfGXV2C7H0xJs0rUuLhkwWLJ6oeLsmk1HBE4txV0UlX+mV+
/wAdKdBY6u2wruW5apDb6+D/8GXonUEpeS/mxIWbqUd+nFqFUyy0sWPlA17/Ybkv
uDQqjTvz/wSBf0f8vxC4ttatA7nD57Ia/5PpzPXeAaZqrxhh0g9WdzoVr0eQhQLv
cHHY24gJ3fP9BEIheyjgp1bMl3KgzL4YKfzqPga/ypPJ+5supVKmM6jthVu0WDIx
iQ2Oqz7JAf+YFqWT8NGUsSMiSm4JNEMc6+DRosj6i8gCEfqUXs6eu4N9Px/b5hfC
gvDKtfPwE456E9ZuAh5DVi7ep0p89xV3I12HfVZu4viRHHXqJzL4hyee9AgeE55N
6UseWPI=
=ozqT
-END PGP SIGNATURE-

Bug#846002: Debian Installer Stretch RC 1 release

[Bjørn Mork]

Andreas Tille  writes:

>> Since this is still an open discussion in #846002, I would have
>> preferred if you would not try to force your own preference here before
>> the CTTE made its decision.
>
> While I'm not sure whether its a personal preference or whether some
> discussion I might have missed has lead to this result but I'm similar
> astonished as Ole about this result without a final decision of the
> CTTE.

If I can offer an view from the outside of this discussion:

To me it looks like a sandbox fight which started with the creative use
of "Priority: important". Now it appears that the party starting the
fight thinks the other party should stop throwing sand until "mommy"
(aka CTTE) decides who is right and who is wrong.

I have of course probably gotten all this wrong.  But that doesn't
really matter.  The above describes how *I* subjectively perceive the
situation.  That is not a subject for discussion.

My personal advice, since I'm out here providing opionions nobody asked
for anyway, would be to start co-operating with the tasksel/installer
developers instead of waiting for a CTTE decision.  That's not going to
solve your issues anyway.

Because, as has been pointed out by several people already: This whole
mess was pointless from the start. No new Debian user will ever
understand the meaning of the task menu.  And no experienced Debian user
will use it.  Adding anything there is futile.  You need to get into a
dialogue with the installer developers so that you can find a way to
properly integrate blends.  And possibly remove tasks.

This is of course way too late for Stretch.  Live with it. Or continue
wasting everybodys time on pointless discussions and be too late for the
next release as well


Bjørn

Bug#850064: /boot/vmlinuz-4.8.0-2-amd64: kernel NULL pointer dereference in icmp6_send related to bridge port link changes

[Bjørn Mork]

OK, this looks like a known v4.8 stable regression, caused by the
backport of commit 5d41ce29e3b9 ("net: icmp6_send should use dst dev to
determine L3 domain") introduced in v4.8.10.

Should be fixed by commit 79dc7e3f1cd3 ("net: handle no dst on skb in
icmp6_send") as soon as Debian moves to v4.9

Ref https://bugzilla.kernel.org/show_bug.cgi?id=189851



Bjørn

Bug#850064: /boot/vmlinuz-4.8.0-2-amd64: kernel NULL pointer dereference in icmp6_send related to bridge port link changes

[Bjørn Mork]

The first crash dumps were from my console, which was overwritten by
the later boot process and therefore incomplete.  Should have dug up
the complete logs from the console server in the first place..

Anyways, here are the complete stack traces:


[509753.194825] ixgbe :02:00.0 uplink: NIC Link is Down
[509753.206127] br0: port 1(uplink) entered disabled state
[509813.399798] BUG: unable to handle kernel NULL pointer dereference at 
0018
[509813.416211] IP: [] icmp6_send+0x229/0x9f0
[509813.428016] PGD 0 
[509813.432678] Oops:  [#1] SMP
[509813.439548] Dumping ftrace buffer:
[509813.446926](ftrace buffer empty)
[509813.454651] Modules linked in: xt_set ip_set_hash_ip ip_set nfnetlink 
ip6t_rt nf_log_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_REJECT nf_reject_ipv6 
ip6table_filter ip6_tables nfsd auth_rpcgss nfs_acl nfs lockd grace fscache 
sunrpc sch_tbf sit tunnel4 ip_tunnel xt_CT xt_nat ipt_MASQUERADE 
nf_nat_masquerade_ipv4 xt_REDIRECT nf_nat_redirect xt_multiport nf_log_ipv4 
nf_log_common xt_LOG xt_tcpudp xt_recent xt_conntrack ipt_REJECT nf_reject_ipv4 
iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
iptable_filter ip_tables x_tables nf_nat_ftp nf_nat nf_conntrack_ftp 
nf_conntrack 8021q garp mrp bridge stp llc nls_ascii nls_cp437 vfat fat tun 
nct6775 hwmon_vid fuse intel_rapl x86_pkg_temp_thermal coretemp kvm_intel ast 
iTCO_wdt kvm iTCO_vendor_support hci_uart ttm irqbypass pl2303 btbcm 
crct10dif_pclmul drm_kms_helper efi_pstore btqca evdev crc32_pclmul btintel 
i2c_i801 serio_raw pcspkr i2c_smbus drm ghash_clmulni_intel efivars 
intel_lpss_acpi ipmi_si ie31200_edac mei_me bluetooth sg usbserial edac_core 
intel_lpss mei ipmi_msghandler shpchp battery acpi_als tpm_tis rfkill video 
mfd_core kfifo_buf button acpi_power_meter tpm_tis_core industrialio tpm ext4 
crc16 jbd2 fscrypto mbcache dm_mod raid1 raid456 async_raid6_recov async_memcpy 
async_pq async_xor async_tx md_mod xor raid6_pq libcrc32c sd_mod ahci xhci_pci 
crc32c_intel libahci xhci_hcd aesni_intel igb libata ixgbe aes_x86_64 
i2c_algo_bit glue_helper nvme lrw dca gf128mul scsi_mod ptp ablk_helper 
nvme_core cryptd usbcore pps_core usb_common i2c_hid mdio thermal fan hid fjes
[509813.739069] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.8.0-2-amd64 #1 
Debian 4.8.11-1
[509813.755700] Hardware name: ASUSTeK COMPUTER INC. P10S-E Series/P10S-E 
Series, BIOS 0505 03/01/2016
[509813.774316] task: 9f68a88c60c0 task.stack: 9f68a8a8c000
[509813.786889] RIP: 0010:[]  [] 
icmp6_send+0x229/0x9f0
[509813.803736] RSP: 0018:9f68efd03aa0  EFLAGS: 00010246
[509813.815068] RAX:  RBX: 9f68a4df7600 RCX: 
0020
[509813.830064] RDX: 0001 RSI: 0200 RDI: 
9f637b792048
[509813.845060] RBP: 9f68efd03bd0 R08: 9f68efd03bf0 R09: 
94b046f4
[509813.860052] R10: 0003 R11:  R12: 
9f637b792040
[509813.875030] R13: 87ada680 R14:  R15: 
0001
[509813.890020] FS:  () GS:9f68efd0() 
knlGS:
[509813.906976] CS:  0010 DS:  ES:  CR0: 80050033
[509813.919172] CR2: 0018 CR3: 0002c1e06000 CR4: 
003426e0
[509813.934137] DR0:  DR1:  DR2: 

[509813.949108] DR3:  DR6: fffe0ff0 DR7: 
0400
[509813.964094] Stack:
[509813.968801]  0046 9f68efd03b80 9f68a5d4a100 
9f68efd03c68
[509813.984437]  9f68efd03bf0  9f637b792048 
9f68
[509814.72]  9f680003 9f680001 9f637b792058 
9f68a3eacd80
[509814.015750] Call Trace:
[509814.021339]   
[509814.025406]  [] ? fib_rules_lookup+0x117/0x170
[509814.039032]  [] ? fib6_rule_lookup+0x53/0xc0
[509814.051394]  [] ? rt6_multipath_select+0xd0/0xd0
[509814.064453]  [] ? rt6_lookup+0x7b/0xb0
[509814.075793]  [] ? ip6_err_gen_icmpv6_unreach+0x140/0x260
[509814.090315]  [] ? __wake_up_sync_key+0x3d/0x60
[509814.103001]  [] ? ipip6_err+0xbd/0x1d0 [sit]
[509814.115341]  [] ? tunnel64_err+0x2d/0x40 [tunnel4]
[509814.128737]  [] ? icmp_unreach+0xb7/0x240
[509814.140567]  [] ? icmp_rcv+0x26f/0x390
[509814.151908]  [] ? ip_local_deliver_finish+0x8b/0x1c0
[509814.165631]  [] ? ip_local_deliver+0x6b/0xf0
[509814.177979]  [] ? ip_rcv_finish+0x3e0/0x3e0
[509814.190141]  [] ? ip_rcv+0x286/0x3c0
[509814.201084]  [] ? inet_del_offload+0x40/0x40



[  260.181699] BUG: unable to handle kernel NULL pointer dereference at 
0018
[  260.197481] IP: [] icmp6_send+0x229/0x9f0
[  260.208708] PGD 0 
[  260.212792] Oops:  [#1] SMP
[  260.219080] Dumping ftrace buffer:
[  260.225906](ftrace buffer empty)
[  260.233059] Modules linked in: xt_set ip_set_hash_ip ip_set nfnetlink xt_CT 
xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_REDIRECT nf_nat_redirect 
nf_log_ipv4 ipt_REJECT nf_reject_ipv4 iptable_raw iptable_nat 

Bug#850064: /boot/vmlinuz-4.8.0-2-amd64: kernel NULL pointer dereference in icmp6_send related to bridge port link changes

[Bjørn Mork]

Package: src:linux
Version: 4.8.11-1
Severity: important
File: /boot/vmlinuz-4.8.0-2-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

I just had two crashes in a row in icmp6_send while rebooting a switch in
the other end of one of the br0 bridge ports.  Both crash dumps follow:

[509753.194825] ixgbe :02:00.0 uplink: NIC Link is Down
[509753.206127] br0: port 1(uplink) entered disabled state
[509813.399798] BUG: unable to handle kernel NULL pointer dereference at 
0018
[509813.416211] IP: [] icmp6_send+0x229/0x9f0
[509813.428016] PGD 0 
[509813.432678] Oops:  [#1] SMP
[509813.439548] Dumping ftrace buffer:
[509813.446926](ftrace buffer empty)
[509813.454651] Modules linked in: xt_set ip_set_hash_ip ip_set nfnetlink 
ip6t_rt nf_log_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_REJECT nf_reject_ipv6 
ip6table_filter ip6_tables nfsd auth_rpcgss nfs_acl nfs lockd grace fscache 
sunrpc sch_tbf sit tunnel4 ip_tunnel xt_CT xt_nat ipt_MASQUERADE 
nf_nat_masquerade_ipv4 xt_REDIRECT nf_nat_redirect xt_multiport nf_log_ipv4 
nf_log_common xt_LOG xt_tcpudp xt_recent xt_conntrack ipt_REJECT nf_reject_ipv4 
iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
iptable_filter ip_tables x_tables nf_nat_ftp nf_nat nf_conntrack_ftp 
nf_conntrack 8021q garp mrp bridge stp llc nls_ascii nls_cp437 vfat fat tun 
nct6775 hwmon_vid fuse intel_rapl x86_pkg_temp_thermal coretemp kvm_intel ast 
iTCO_wdt kvm iTCO_vendor_support hci_uart ttm irqbypass pl2303 btbcm 
crct10dif_pclmul drm_kms_helper efi_pstore btqca evdev crc32_pclmul btintel 
i2c_i801 serio_raw pcspkr i2c_smbus drm ghash_clmulni_intel efivars 
intel_lpss_acpi ipmi_si ie31200_e!
 dac mei_me bluetooth sg usbserial edac_core intel_lpss mei ipmi_msghandler 
shpchp battery acpi_als tpm_tis rfkill video mfd_core kfifo_buf button 
acpi_power_meter tpm_tis_core industrialio tpm ext4 crc16 jbd2 fscrypto mbcache 
dm_mod raid1 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx 
md_mod xor raid6_pq libcrc32c sd_mod ahci xhci_pci crc32c_intel libahci 
xhci_hcd aesni_intel igb libata ixgbe aes_x86_64 i2c_algo_bit glue_helper nvme 
lrw dca gf128mul scsi_mod ptp ablk_helper nvme_core cryptd usbcore pps_core 
usb_common i2c_hid mdio thermal fan hid fjes
[509813.739069] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.8.0-2-amd64 #1 
Debian 4.8.11-1
[509813.755700] Hardware name: ASUSTeK COMPUTER INC. P10S-E Series/P10S-E 
Series, BIOS 0505 03/01/2016
[509813.774316] task: 9f68a88c60c0 task.stack: 9f68a8a8c000
[509813.786889] RIP: 0010:[]  [] 
icmp6_send+0x229/0x9f0

[  260.181699] BUG: unable to handle kernel NULL pointer dereference at 
0018
[  260.197481] IP: [] icmp6_send+0x229/0x9f0
[  260.208708] PGD 0 
[  260.212792] Oops:  [#1] SMP
[  260.219080] Dumping ftrace buffer:
[  260.225906](ftrace buffer empty)
[  260.233059] Modules linked in: xt_set ip_set_hash_ip ip_set nfnetlink xt_CT 
xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_REDIRECT nf_nat_redirect 
nf_log_ipv4 ipt_REJECT nf_reject_ipv4 iptable_raw iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat_ftp nf_nat 
nf_conntrack_ftp xt_multiport ip6t_rt nf_log_ipv6 nf_log_common xt_LOG 
xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_recent xt_conntrack nf_conntrack 
ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables x_tables nfsd auth_rpcgss 
nfs_acl nfs lockd grace fscache sunrpc sch_tbf sit tunnel4 ip_tunnel 8021q garp 
mrp bridge stp llc nls_ascii nls_cp437 vfat fat tun nct6775 hwmon_vid fuse 
intel_rapl x86_pkg_temp_thermal coretemp kvm_intel iTCO_wdt ast 
iTCO_vendor_support kvm hci_uart ttm btbcm btqca mei_me irqbypass ie31200_edac 
i2c_i801 crct10dif_pclmul btintel crc32_pclmul ipmi_si evdev efi_pstore pcspkr 
drm_kms_helper i2c_smbus ghash_clmulni_intel bluetooth serio_raw efivars 
edac_co!
 re pl2303 drm sg mei video ipmi_msghandler usbserial intel_lpss_acpi shpchp 
battery intel_lpss rfkill mfd_core acpi_power_meter acpi_als tpm_tis kfifo_buf 
button tpm_tis_core industrialio tpm ext4 crc16 jbd2 fscrypto mbcache dm_mod 
raid1 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx md_mod 
xor raid6_pq libcrc32c sd_mod ahci crc32c_intel xhci_pci libahci aesni_intel 
igb xhci_hcd aes_x86_64 glue_helper lrw ixgbe i2c_algo_bit nvme libata gf128mul 
dca ablk_helper usbcore cryptd ptp scsi_mod usb_common nvme_core pps_core 
i2c_hid mdio fan thermal hid fjes
[  260.511842] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.8.0-2-amd64 #1 
Debian 4.8.11-1
[  260.527695] Hardware name: ASUSTeK COMPUTER INC. P10S-E Series/P10S-E 
Series, BIOS 0505 03/01/2016
[  260.545604] task: 8bbde88c7000 task.stack: 8bbde8a94000
[  260.557636] RIP: 0010:[]  [] 
icmp6_send+0x229/0x9f0
[  260.573798] RSP: 0018:8bbe2fd43760  EFLAGS: 00010246
[  260.584527] RAX:  RBX: 8bbde5a15900 RCX: 0020
[  260.598814] RDX: 0001 RSI: 0200 RDI: 

Bug#846112: Acknowledgement (/sbin/sulogin: sulogin does not exit on first Control-D)

[Bjørn Mork]

forwarded 846112 util-li...@vger.kernel.org
tags 846112 +patch
stop

Looks like this was an upstream issue.  The attached patch has been
submitted upstream.


Bjørn
From 73d33c8b1ae640aa72e0638ed9662c051f6431c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bj...@mork.no>
Date: Mon, 28 Nov 2016 16:40:22 +0100
Subject: [PATCH 2/2] sulogin: make Control-D break out of the main loop
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

getpasswd() must return NULL to force breaking out of
the main loop.  Anything else will be treated as a password
to be verified, and will end up with

  Login incorrect

and a repeated password prompt.

(unless the root password happened to be Control-D :)

Signed-off-by: Bjørn Mork <bj...@mork.no>
---
 login-utils/sulogin.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/login-utils/sulogin.c b/login-utils/sulogin.c
index 6a3890e80a16..7fe938150e19 100644
--- a/login-utils/sulogin.c
+++ b/login-utils/sulogin.c
@@ -695,6 +695,7 @@ static char *getpasswd(struct console *con)
 ptr--;
 			break;
 		case CEOF:
+			ret = (char*)0;
 			goto quit;
 		default:
 			if ((size_t)(ptr - [0]) >= (sizeof(pass) -1 )) {
-- 
2.10.2



signature.asc
Description: PGP signature

Bug#846107: Acknowledgement (/sbin/sulogin: sulogin with timeout fails, causing boot failure if SULOGIN=yes)

[Bjørn Mork]

forwarded 846107 util-li...@vger.kernel.org
tags 846107 +patch
stop

Looks like this was an upstream issue.  The attached patch has been
submitted upstream.


Bjørn

From 616ae007183733dd0a0f5134bb0b666aae95878b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bj...@mork.no>
Date: Mon, 28 Nov 2016 16:27:19 +0100
Subject: [PATCH 1/2] sulogin: make --timeout actually time out
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Bjørn Mork <bj...@mork.no>
---
 login-utils/sulogin.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/login-utils/sulogin.c b/login-utils/sulogin.c
index 1c4313af4647..6a3890e80a16 100644
--- a/login-utils/sulogin.c
+++ b/login-utils/sulogin.c
@@ -644,7 +644,7 @@ static char *getpasswd(struct console *con)
 	eightbit = ((con->flags & CON_SERIAL) == 0 || (tty.c_cflag & (PARODD|PARENB)) == 0);
 	while (cp->eol == '\0') {
 		if (read(fd, , 1) < 1) {
-			if (errno == EINTR || errno == EAGAIN) {
+			if ((errno == EINTR && !alarm_rised) || errno == EAGAIN) {
 xusleep(25);
 continue;
 			}
-- 
2.10.2



signature.asc
Description: PGP signature

Bug#846112: /sbin/sulogin: sulogin does not exit on first Control-D

[Bjørn Mork]

Package: util-linux
Version: 2.29-1
Severity: important
File: /sbin/sulogin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Must press Control-D twice to exit sulogin.  The first attempt to
press Control-D will erronously report 'Login incorrect'.  The
second attempt succeeds, *unless* sulogin is being run with
- --timeout

root@miraculix:/tmp# sulogin
Give root password for maintenance
(or press Control-D to continue): 
Login incorrect

Give root password for maintenance
(or press Control-D to continue): 


This bug is extra nasty in combination with the timeout bug, since
Control-D apparently is completely ignored after the SIGALRM. This
means that there is no way to exit sulogin after the timeout has
expired without knowing the root password.

Combine that with using SULOGIN=yes and you have a system which
reuires root password knowledge to boot...  That's bad.


Bjørn


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

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

Versions of packages util-linux depends on:
ii  libblkid1  2.29-1
ii  libc6  2.24-7
ii  libfdisk1  2.29-1
ii  libmount1  2.29-1
ii  libncursesw5   6.0+20160917-1
ii  libpam0g   1.1.8-3.3
ii  libselinux12.6-3
ii  libsmartcols1  2.29-1
ii  libsystemd0232-6
ii  libtinfo5  6.0+20160917-1
ii  libudev1   232-6
ii  libuuid1   2.29-1
ii  zlib1g 1:1.2.8.dfsg-2+b3

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.0-2
ii  kbd 2.0.3-2
ii  util-linux-locales  2.29-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEE9GFvUSsROzwYJzwh4Zf8Eu/wXs0FAlg8QqkOHGJqb3JuQG1v
cmsubm8ACgkQ4Zf8Eu/wXs3VQQ//YGS7zh4Zs/Fg3ZxoAvUx3boEdpCSw8puqyRl
zbrA4CCTE/gk38fJUb48RqGUFxLM0deGixlOV6X108NBIWe9+CYQ07zZVrVZ5sYM
GX0O0JJF2lAjUcb9xuVuhrjPqVcnw8quJRDLZrMKF8OXnVuSNITqwt5SqqmK9Ofl
YxajJ7IqtHsuATO0qfkU79QJHp9t0HZUV+ll9/ekjir0keeCRopLZmEVg4xNL87u
wPSXCSsEwIK61w2tbw+pL/LJcFV4y/Zxn9VOm5F4GngIBmYqcINgXHYG8iVNY4M4
aRdYTyQYnx0hc8ENV4XF3x0cdorOxC2PXzMw10qtpko8Ro4o5a1YTrHc2s4hvBIk
AKYmIv0SDdDIBux+nIT9/Gg7B6A7r0mknbygsg8380kVhvINZgVeTX+z2axc0dTO
R5lP8F39ulFn+/EfFVZw8SA1IjEz8PazuEW6KndGi2L4wbLdaAzQv3bvEHwvKvJ3
0OzDMcoMe21rzuew1O2KqmlXi1tiydmofAAppSKaPrEUNWtw2Irw5aGSYQkdF8It
aBQzk8KNPmJizuiBQC1appB17LnWustBPeN11FtctrFWvG50WZILDQSl8V1MELMA
rMKX+ZHRKMMUQuEV2LJKJL7OfVsWHUCMAnLGhIN0sgKi/9I8ppekwhUAfWyoEL37
gVv5qis=
=I5Bv
-END PGP SIGNATURE-

Bug#846107: /sbin/sulogin: sulogin with timeout fails, causing boot failure if SULOGIN=yes

[Bjørn Mork]

Package: util-linux
Version: 2.29-1
Severity: important
File: /sbin/sulogin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

sulogin does not exit after timeout expires.  This is serious
for any remote system configured with SULOGIN=yes since it
means that manual intervention is required to boot the system.

Reproducing the issue is simple: Just run sulogin with a short
timeout and observe that it doesn't exit.

strace shows that it does set an alarm, which is triggered,
but sulogin falls back to read() instead of exiting:

root@miraculix:/tmp# strace -ttf sulogin -t 3
15:18:25.711747 execve("/sbin/sulogin", ["sulogin", "-t", "3"], [/* 54 vars 
*/]) = 0
..
15:18:25.728448 ioctl(0, TIOCGWINSZ, {ws_row=46, ws_col=221, ws_xpixel=1787, 
ws_ypixel=740}) = 0
15:18:25.728487 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
15:18:25.728518 ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost -isig 
-icanon -echo ...}) = 0
15:18:25.728547 ioctl(0, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
15:18:25.728577 fcntl(0, F_GETFL)   = 0x8002 (flags O_RDWR|O_LARGEFILE)
15:18:25.728605 fcntl(0, F_SETFL, O_RDWR|O_LARGEFILE) = 0
15:18:25.728633 getpgid(0)  = 17003
15:18:25.728660 getppid()   = 17003
15:18:25.728687 getpgid(17003)  = 17003
15:18:25.728714 ioctl(0, TIOCGPGRP, [17003]) = 0
15:18:25.728747 dup2(0, 0)  = 0
15:18:25.728774 dup2(0, 1)  = 1
15:18:25.728805 dup2(0, 2)  = 2
15:18:25.728832 ioctl(0, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
15:18:25.728890 ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost -isig 
-icanon -echo ...}) = 0
15:18:25.728916 ioctl(0, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
15:18:25.728950 fcntl(0, F_GETFL)   = 0x8002 (flags O_RDWR|O_LARGEFILE)
15:18:25.729003 fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) 
= 0
15:18:25.729056 write(0, "Give root password for maintenan"..., 35Give root 
password for maintenance
) = 35
15:18:25.729106 write(0, "(or press Control-D to continue)"..., 34(or press 
Control-D to continue): ) = 34
15:18:25.729135 ioctl(0, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
15:18:25.729162 ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost -isig 
-icanon -echo ...}) = 0
15:18:25.729186 ioctl(0, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
15:18:25.729213 ioctl(0, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
15:18:25.729238 ioctl(0, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost -isig 
-icanon -echo ...}) = 0
15:18:25.729264 ioctl(0, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
15:18:25.729291 rt_sigaction(SIGALRM, {0x55a41bcac870, [], SA_RESTORER, 
0x7f7d12322040}, NULL, 8) = 0
15:18:25.729330 alarm(3)= 0
15:18:25.729384 read(0, 0x7ffd819e1668, 1) = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
15:18:28.730057 --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
15:18:28.730204 rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
15:18:28.730491 nanosleep({0, 25000}, NULL) = 0
15:18:28.980823 read(0, 




Bjørn

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

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

Versions of packages util-linux depends on:
ii  libblkid1  2.29-1
ii  libc6  2.24-7
ii  libfdisk1  2.29-1
ii  libmount1  2.29-1
ii  libncursesw5   6.0+20160917-1
ii  libpam0g   1.1.8-3.3
ii  libselinux12.6-3
ii  libsmartcols1  2.29-1
ii  libsystemd0232-6
ii  libtinfo5  6.0+20160917-1
ii  libudev1   232-6
ii  libuuid1   2.29-1
ii  zlib1g 1:1.2.8.dfsg-2+b3

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.0-2
ii  kbd 2.0.3-2
ii  util-linux-locales  2.29-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJBBAEBCgAsFiEE9GFvUSsROzwYJzwh4Zf8Eu/wXs0FAlg8P1wOHGJqb3JuQG1v
cmsubm8ACgkQ4Zf8Eu/wXs2DnA/1EPR0tg4scW1f0Sz9ya1R0vqn0srARB8WTLMA
nfNxIFOHhdJSWEjaqHTXbRw8LVSuF0OzpckuHjqRCNqPhkYws2u4ZcZbx+4oVmFB
S+oMjOxF7M8IaQjz37YaY+tmzH+6Tfj193ZLKdEZeFZ4qZ0k0duziyZVVDr0lgx1
lPe6oIUALCR97CLTYEpSGDOLwGW48xuM8wzVuwHh5ztfUlPkVNA1vAKvIitofkUD
aoOnVRDkLYXR8yuQbrZUcW4Fi7KpecrcVTtgVmriNFIYqd+D5d6CwmltIzx9AC2j
FkYRcEVDomwr8QQ/i0r3LxuDfwWpt3PZ0NGO+drwyAqqf+ZNgr9Y+KKLB0HZ3nm1
OlzCIID8wEYJ/uOT6N67S115EQhwZw6pxpEK/psXhUk4156VB6p6Qwl4CNcSksJp
YByzKSW/+t16cgplEWNegPSYwUeqLM0VtB73sEg9WE1NDETGiLXoQ+S01RKL4zmc
aXve4H7cR/gbkeCKTSTPE3V/ucPUHmBTGmt+nYyQzr0QJfj1hd8yZm8FCOoVQ1SZ
SmVp0oQtsURpINHnoD6/JZq5SdOf0hKaaRkxNnrBhlLYxECYMmACzGpkkWKQoIJ6
c2nGVrreDhPOS79+9WAPfg8IUg7Pxm1hWvo7Bx0JNeiETu7Ru6YX8eCSR7yq63xU
YCvnVg==
=upKW
-END PGP SIGNATURE-

Bug#843000: refind: fails to install on NVMe

[Bjørn Mork]

Rod Smith  writes:
> On 11/03/2016 01:29 PM, Tianon Gravi wrote:
>> On 3 November 2016 at 10:28, Tianon Gravi  wrote:
>>> On 3 November 2016 at 10:19, Rod Smith  wrote:
 Note, however, that I have no NVMe or similar devices on which to test.
 The new code does the right thing on my /dev/sd? devices, and I think it
 SHOULD work on more exotic devices.
>>>
>>> I don't personally have an NVMe system I can test the script as-is on,
>>> but I tested that specific block of code on a friend's system which
>>> does have NVMe, and I got "/dev/nvme0n1" for InstallDisk and "p1" for
>>> PartNum from his "/boot" partition, so it looks like this code is
>>> correct. :)
>> 
>> Although now that I say that, it occurs to me that PartNum might
>> actually need to be simply "1", not "p1", right?
>
> Good question. I guess it depends on what efibootmgr wants, since that's
> where the variable is used. The efibootmgr man page implies it wants a
> number, so I've committed another change -- applying both 2a6f68 and
> bdf9ca from my git repository should do it:
>
> https://sourceforge.net/p/refind/code/commit_browser

e7e393 works for me:

+ [[ -n /bin/efibootmgr ]]
++ grep /boot/efi /etc/mtab
++ cut -d ' ' -f 1
+ InstallPart=/dev/nvme0n1p1
++ lsblk -r
++ grep disk
++ cut -f 1 -d ' '
+ for Name in `lsblk -r | grep disk | cut -f 1 -d " "`
+ [[ /dev/nvme0n1p1 == *\n\v\m\e\0\n\1* ]]
+ InstallDisk=/dev/nvme0n1
+ PartNum=p1
++ echo 1
+ PartNum=1
+ break
+ [[ -z /dev/nvme0n1 ]]
+ [[ -z 1 ]]
..

+ [[ 0 == 0 ]]
+ /bin/efibootmgr -c -l '\EFI\refind\refind_x64.efi' -L 'rEFInd Boot Manager' 
-d /dev/nvme0n1 -p 1

Thanks.

And I don't think NVMe is *that* exotic anymore :)  This is a pretty
standard 2016 model laptop, as sold by Lenovo.


Bjørn

Bug#843000: refind: fails to install on NVMe

[Bjørn Mork]

Package: refind
Version: 0.10.4-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The refind-install script makes bogus assumptions:

  InstallDisk=`grep "$InstallDir" /etc/mtab | cut -d " " -f 1 | cut -c 1-8`
  PartNum=`grep "$InstallDir" /etc/mtab | cut -d " " -f 1 | cut -c 9-10`

This is obviously fragile. NVMe is just one example where it fails:

 bjorn@miraculix:~$ grep /boot/efi /etc/mtab | cut -d " " -f 1
 /dev/nvme0n1p1

You cannot assume that the disk device name is exactly 8 characters. There is
no such rule.  Please find a more robust way to figure out device names.


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

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

Versions of packages refind depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  efibootmgr 14-1
ii  openssl1.1.0b-2
ii  parted 3.2-16+b1

Versions of packages refind recommends:
ii  python3 3.5.1-4
pn  sbsigntool  

refind suggests no packages.

- -- debconf information:
* refind/install_to_esp: true

-BEGIN PGP SIGNATURE-

iQIrBAEBCgAVBQJYGnWiDhxiam9ybkBtb3JrLm5vAAoJEOGX/BLv8F7NFXAP/3r8
vAX1BZGFvaYQhc8bbegYxMSwpl7rYY4sD6EZDMpTU6JTpGuNqbE5o/h193hjk2Sw
0m0eitzo3BbbpWn45AtRG9RvaaJrovODzeNIlFHovZtU4+IitQrqtT1eRFLyoV7A
uLt5Jc/q62e+evkU4pKMwASeXyj8JUnsHM9TOmPjPlCkzk0jSDAy9SYPnzaXeUdB
R77FVbsgNsbznrF9s1h10G0iQX/x3fONKgwPOcQEL8WkWutSB5dioH1JFUGEVzx1
dMZLTkDI9IXYLrfo3ZokWZiuX64nxR00BtM8tAA6ZGx+a545nWh/DQQfEw5IqQiq
Bc0gRtkLfsIRCBka/6oY5Kl/WsJXlub/Qtmp6csQ6y1I2poejTYOlst/0yplmbwe
mmVSopQ+Qbjlg9VO8Fj9SOv+9uZipVIYEOlLVpLu4f4dClf60VN9/vQbueUjvj52
iR5BKz/vNZO2LqJyXWPKu81jKe8OI9EWihIYgdpQCxXyFwzSGs2+B1kbPZXxD8Tw
12Ew5eHf7Bg+9JWAwdjRnA/EQYsxbWOrMfJHiNejTs0Kj8Bj7AgIDOZSBL5TBvpx
YQBnfEKA5CmxiU696tpwCj5HdSyVotyNHRQBkLi5R+Q08ycs+jA7m2GaXruATogF
TEBOHD5lHyvLUBaRg1VJJINajp9AGOrXa3DzgOyw
=GBN/
-END PGP SIGNATURE-

Bug#824981: EM7455 in Thinkpads should work now

[Bjørn Mork]

With these versions we should now have all parts of the puzzle in place: 

 linux-image-*  4.7.2-1
 modemmanager   1.6.0-1


Bjørn

Bug#832458: linux-image-4.6.0-0.bpo.1-amd64: Please enable SND_SOC_INTEL_BYT_MAX98090_MACH, needed for some Baytrail devices

[Bjørn Mork]

Ben Hutchings  writes:
> On Mon, 2016-07-25 at 13:10 -0600, Ivan M wrote:
>> Package: src:linux
>> Version: 4.6.3-1~bpo8+1
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> Please enable CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH=m - it is
>> necessary for audio on certain Baytrail hardware.
>> 
>> (I note that it is also necessary to set CONFIG_DW_DMAC=y (not m) for
>> this, although I don't understand why.)
>
> This is an upstream regression.  It is simply not possible to select
> all the Intel SoC sound drivers any more.  It seems that some
> developers don't care to support a generic distribution configuration.

I believe that is supposed to be fixed by commit a395bdd6b24b ("ASoC:
intel: Fix sst-dsp dependency on dw stuff"), but I haven't verified it.

Looks like it's destined for v4.8 and not yet backported to any stable
kernel, though. Which is a bit odd given the "Fixes" tag..



Bjørn

Bug#828820: Dell DW5811e should be working with the latest MM and supporting packages

[Bjørn Mork]

Luc Bégault  writes:

> The dump file is attached, everything looks fine except I don't
> receive any datagrams. tcpdump on the interface only shows outgoing
> packets without any answer.

This is the exact symptoms caused by the firmware issue I mentioned.
Connection looks fine, but no IP packets are forwarded. I am pretty sure
it is fixed with the 4.7.2-1 kernel.

Just for reference, this is the patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=c086e7096170390594c425114d98172bc9aceb8a

It's really that simple:  Just wait 10 ms...  Believe it or not.  Took
some time to figure it out though :)


Bjørn

Bug#828820: Dell DW5811e should be working with the latest MM and supporting packages

[Bjørn Mork]

Luc Bégault  writes:

> here is the output of:
> # mmcli -m /org/freedesktop/ModemManager1/Modem/0
>
> /org/freedesktop/ModemManager1/Modem/0 (device id
> 'abcc5d4e7daab7bd404d58f7ca9c6e799fe47155')
>   -
>   Hardware |   manufacturer: 'Dell'
>|  model: 'MBIM [413C:81B6]'
>|   revision: 'SWI9X30C_02.05.07.00'
>|  supported: 'gsm-umts, lte'
>|current: 'gsm-umts, lte'
>|   equipment id: '353991070070340'
>   -
>   System   | device:
> '/sys/devices/pci:00/:00:14.0/usb2/2-2'
>|drivers: 'cdc_mbim'
>| plugin: 'Dell'
>|   primary port: 'cdc-wdm0'
>|  ports: 'cdc-wdm0 (mbim), wwp0s20f0u2i12 (net)'
>   -
>   Numbers  |   own : 'unknown'
>   -
>   Status   |   lock: 'none'
>| unlock retries: 'sim-pin2 (3)'
>|  state: 'registered'
>|power state: 'on'
>|access tech: 'lte'
>| signal quality: '29' (cached)


Great! Now we know that
 - the modem is using the cdc_mbim driver,
 - the SIM is unlocked,
 - the radio is on, and
 - the modem is registered in the LTE network

That's really good so far.

> Since new version of modemmanager, the modem is detected and my
> connection is avaible in network manager. But when I try to connect, I
> have:
> #nmcli c up SFR
> Error: Connection activation failed.
>
> #nmcli device show
> ../..
> GENERAL.DEVICE: cdc-wdm0
> GENERAL.TYPE:   gsm
> GENERAL.HWADDR: (unknown)
> GENERAL.MTU:0
> GENERAL.STATE:  30 (disconnected)
> GENERAL.CONNECTION: --
> GENERAL.CON-PATH:   --
> ../..
>
> Maybe I should report now to networkmanager ?

No.  This is most likely a failure related to MM. I don't think it's
necessarily a bug, though... More likely something related to your
connection.  Let's take a closer look at it.

Try to collect the MM debug logs and see if it provides more hints:

 systemctl stop ModemManager
 /usr/sbin/ModemManager --debug
 nmcli c up SFR


This should print lots of details of what MM is doing and how if fails.
It can also be useful to rerun the "mmcli -m .." command after the
connection attempt, note the number of the created "bearer" object, and
then run "mmcli -b X" with this number to inspect it.


Just one additional warning for later when you are able to connect (or
for anyone else reading this and stopping at the next step): You will
need a kernel update to consistently get IP packets through. There is an
odd timing issue in the firmware of these modems, which sometimes cause
a silent failure if the driver probe is "too fast".  The workaround for
this issue is present in kernels v4.7 and later, and also in stable
kernels v4.6.5 and later. I believe the first Debian kernel package
version with this fix will be the soon upcoming "4.7.2-1"


Bjørn

Bug#790109: Please test with sid packages if possible

[Bjørn Mork]

Hello,

I asked ModemManager upstream about this.  The problem is in the libqmi
library, and it is *supposed* to be fixed in libqmi version 1.12.  I
cannot verify this myself though, as I don't think I have an old enough
Gobi device (found nothing pre Gobi 2k in my box of modems).

As your bug report shows, the jessie libqmi version is 1.10:

 ii  libqmi-glib1   1.10.2-2


Is it possible for you to retest with the newer modemmanager and libqmi
versions in sid? Or maybe backport the newer libqmi if you find that
more convenient?


Thanks,

Bjørn

Bug#828820: Dell DW5811e should be working with the latest MM and supporting packages

[Bjørn Mork]

Hello,

I noticed this bug which I believe should be resolved.  In case it isn't
I'd very much like to have some details.  I believe the DW5811e might be
configured for multiple alternative USB configurations, which means that
we cannot necessarily guess with drivers you are using.

Could you do a "mmcli -L" and then "mmcli -m X" where the X is the
number of the DW5811e?  Feel free to censor any data you want to keep
private, like the IMEI.  For a start, I am mostly interested in which
driver is in use and what state MM claims the modem is in.



Bjørn

Bug#833918: linux: Please enable cdc_ncm and cdc_mbim in d-i to support 'Dell 4-in-1 Adapter' Ethernet

[Bjørn Mork]

John Paul Adrian Glaubitz  writes:

> This adapter uses the cdc_ncm/cdc_mbim kernel modules which are currently 
> being disabled for
> debian-installer as those were suspected to be used by modems only [2], which 
> is not the
> case, however.

cdc_mbim is modem-only. cdc_ncm is not.

The reason you see cdc_mbim loaded is because of an oddity in the MBIM
spec, allowing an USB interface to be both NCM and MBIM depening on the
active altsetting. The cdc_mbim driver is therefore matching NCM
interfaces to be able to detect this sort of dual function.  But that's
completely irrelevant to your ethernet adapter.  MBIM cannot be used on
an ethernet (it has no no L2 headers).

By avoiding cdc_mbim, you can also drop the cdc_wdm dependency.


> [ 9105.605635] cdc_ncm 2-1.1:1.5: MAC-Address: 9c:eb:e8:20:f5:5b
> [ 9105.605640] cdc_ncm 2-1.1:1.5: setting rx_max = 16384
> [ 9105.605743] cdc_ncm 2-1.1:1.5: setting tx_max = 16384
> [ 9105.605991] cdc_ncm 2-1.1:1.5 usb0: register 'cdc_ncm' at 
> usb-:00:14.0-1.1, CDC NCM, 9c:eb:e8:20:f5:5b
> [ 9105.680400] cdc_ncm 2-1.1:1.5 enx9cebe820f55b: renamed from usb0

See?  This is only using cdc_ncm and will work fine even if cdc_mbim is 
unavailable.


Bjørn

Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.

[Bjørn Mork]

Emilio Pozuelo Monfort  writes:
> On 09/07/16 22:31, Franciscarlos Santos Soares wrote:
>> Hi Emilio!
>> 
>> Thank you for contacting us. In fact, like independent application of any 
>> DE, 
>> but they were compatible with the traditional look of windows and based on 
>> the 
>> GTK library. So would provide a good working environment in the old 
>> computers 
>> that read daily in public schools that work.
>
> I found http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/,
> which makes things clearer. This seems to be a cross-desktop (Mate, 
> Cinnamon...
> XFCE?) project to provide some core apps. Which we wouldn't end up with 
> multiple
> forks of the same stuff, and that addresses my concerns.

That's the forking version of https://xkcd.com/927/ , isn't it?


Bjørn

Bug#824795: smartmontools: remove obsolete /usr/share/man/man8/update-smart-drivedb.8.gz man page

[Bjørn Mork]

Package: smartmontools
Version: 6.4+svn4214-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Looks like this was left over when removing the update-smart-drivedb
script:

 bjorn@nemi:~$  dpkg -L smartmontools|grep update
 /usr/share/man/man8/update-smart-drivedb.8.gz


Bjørn

- -- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0+ (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages smartmontools depends on:
ii  debianutils  4.4+b1
ii  init-system-helpers  1.33
ii  libc62.22-9
ii  libcap-ng0   0.7.4-2
ii  libgcc1  1:6.1.1-3
ii  libselinux1  2.3-2
ii  libstdc++6   6.1.1-3
ii  lsb-base 4.1+Debian13+nmu1

Versions of packages smartmontools recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20141216cvs-2

Versions of packages smartmontools suggests:
pn  gsmartcontrol   
pn  smart-notifier  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlc+I88ACgkQ10rqkowbIsm3cwCfS6Uh14dLM3/Aht695SmfprEv
uEwAnA4WU+Pbyg5QbCvKkL1h1gOt/wiP
=G+re
-END PGP SIGNATURE-

Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing

[Bjørn Mork]

Ben Hutchings <b...@decadent.org.uk> writes:
> On Wed, 2016-04-20 at 20:51 +0200, Bjørn Mork wrote:
>> Ben Hutchings <b...@decadent.org.uk> writes:
>> 
>> > 
>> > Our upstream is linux-firmware.git, not a hundred vendor web sites.
>> > Frankly I'm quite sick of the iwlwifi maintainers thinking their
>> > firmware is special and should be distributed differently from every.
>> Huh?  I always though they sent a pull request whenever they felt a new
>> update was "ready".  Like this:
>> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/149963
> [...]
>
> But apparently the firmware sometimes isn't 'ready' until *after* the
> previous major version reaches end of life.
>
> If all versions of firmware are either EOL or beta, Intel is
> effectively disclaiming support for the affected hardware.

Well, yes, that is confusing. I cannot imagine that it was their
intention.  FWIW, the current driver still supports firmwares back to
"13" for the 7260:

/* Highest firmware API version supported */
#define IWL7260_UCODE_API_MAX   17
#define IWL7265_UCODE_API_MAX   17
#define IWL7265D_UCODE_API_MAX  21
#define IWL3168_UCODE_API_MAX   21

/* Oldest version we won't warn about */
#define IWL7260_UCODE_API_OK13
#define IWL7265_UCODE_API_OK13
#define IWL7265D_UCODE_API_OK   13
#define IWL3168_UCODE_API_OK20

/* Lowest firmware API version supported */
#define IWL7260_UCODE_API_MIN   13
#define IWL7265_UCODE_API_MIN   13
#define IWL7265D_UCODE_API_MIN  13
#define IWL3168_UCODE_API_MIN   20


That is the authoritative source wrt "support".


Bjørn

Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing

[Bjørn Mork]

Ben Hutchings  writes:

> Our upstream is linux-firmware.git, not a hundred vendor web sites.
> Frankly I'm quite sick of the iwlwifi maintainers thinking their
> firmware is special and should be distributed differently from every.

Huh?  I always though they sent a pull request whenever they felt a new
update was "ready".  Like this:
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/149963

But I'm not sure there has been a pull request for the 7260-17.ucode
yet?  It's going to be the last revision for that hardware, so they
might want to get it "right" first.  Nothing wrong about that AFAICS.
Or the fact that the driver has support for a revision which isn't yet
in the official repo. The driver works fine with the 7260-16.ucode too.

I don't see neither the website, or their firmware repo, as any attmept
to distribute firmware differently.  It's merely a service to users
wanting to beta test early firmware.  Personally I like having that
choice.  But Debian should definitely not start packaging any of the
firmware revisions which aren't in linux-firmware.git.


Bjørn

Bug#821005: libnet-dns-perl: runtime dependency on Net::DNS::SEC::Private cannot be fulfilled

[Bjørn Mork]

Package: libnet-dns-perl
Version: 1.05-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As has been noted in bug #820332, this version conflicts with
libnet-dns-sec-perl because all the DNSSEC RR classes have been
transferred to libnet-dns-perl.

There is still a runtime depencency between the DNSSEC classes and the
remaining code in Net::DNS::Sec though.  Trying to use e.g
Net::DNS::RR::RRSIG results in

 $ perl -MNet::DNS::RR::RRSIG -e 'my $rrsig = create Net::DNS::RR::RRSIG([],"")'
 Net::DNS::SEC support not available at -e line 1.

This dependency cannot currently be fulfilled, due to the mentioned
conflict. Please provide a proper update path, restoring the previous
DNSSEC support, while fixing bug #820332.  Conflicting with
libnet-dns-sec-perl version 0.21-1 is not enough.  Either an updated
version of libnet-dns-sec-perl should be made available, or the
remaining Net::DNS::Sec parts should be included with libnet-dns-perl

Thanks.


Bjørn


- -- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-rc3+ (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libnet-dns-perl depends on:
ii  libdigest-hmac-perl  1.03+dfsg-1
ii  libio-socket-inet6-perl  2.72-1
ii  libnet-ip-perl   1.26-1
ii  perl 5.22.1-9

libnet-dns-perl recommends no packages.

libnet-dns-perl suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlcPmqwACgkQ10rqkowbIsmBigCeJ6V2SsU6OphDYnKUHbnSU9/x
NfAAnR72gwV6kaYPifijdO+ztdZBOCeB
=pdpq
-END PGP SIGNATURE-

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Bjørn Mork]

Ben Hutchings <b...@decadent.org.uk> writes:
> On Mon, 2016-04-11 at 09:55 +0200, Bjørn Mork wrote:
>> Ben Hutchings <b...@decadent.org.uk> writes:
>> > 
>> > On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote:
>> > > 
>> > > It works for the most part, but floods syslog with messages:
>> > > 
>> > > [501966.870273] net_ratelimit: 35702 callbacks suppressed
>> > > [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
>> > > 
>> > > It seems to function ok, though I'm not sure if there's degraded
>> > > network performance...
>> > [...]
>> > 
>> > I understand network performance on all RPi models is poor due to lack
>> > of a built-in Ethernet MAC and the poor design of the USB interface.
>> > Also that message is a generic error message from the usbnet core and
>> > is not specific to the smsc95xx driver.
>> Yes, kevent 2 is "EVENT_RX_MEMORY", and this error affects any usbnet
>> based device under memory pressure.  The usbnet framework just doesn't
>> handle the case where GFP_KERNEL allocations fail. How could it? 
>
> What I don't understand, given this, is why Vagrant didn't report any
> OOM warnings.  (I wondered whether the __GFP_NOWARN flag was wrongly
> being added somewhere, but I don't see that.)

Maybe I'm wrong?  Looking at this again, I notice that rx_submit()
always will call usb_submit_urb(urb, GFP_ATOMIC) regardless of the input
mem_flags, because it's holding a spinlock when submitting the urb.  So
it doesn't necessarily help much that the urb and skb are allocated with
GFP_KERNEL.

Exactly what allocations usb_submit_urb() may end up with seems to be
depending on the host controller. So the error spam could very well be
caused by a problematic host controller.  At least partly.

>> The only viable "fix" I can see is by preallocating and recycling all
>> buffers instead of the repeated allocations done by usbnet now.  But
>> that's a major refactoring of usbnet.
>> 
>> The log message spam could of course be fixed, but the rate-limiting is
>> "good enough".
>
> How is anyone supposed to know what "kevent 2" is though?

By looking it up in include/linux/usb/usbnet.h :)

Yes, that could certainly be improved by translating the number back to
a readable description.  

> The drivers that support batching into large RX buffers should
> automatically fall back to smaller buffers if this happens, or whenever
> they're running on a small (for some definition of small) machine.  I
> understand that the dynamic fallback may be tricky though.

I don't think the smsc95xx use any large buffers.  Looks like it's an
ethernet packet + 12 bytes.  And usbnet limits the total rx queue to
60 * 1518 bytes.


Bjørn

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

[Bjørn Mork]

Ben Hutchings  writes:
> On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote:
>> It works for the most part, but floods syslog with messages:
>> 
>> [501966.870273] net_ratelimit: 35702 callbacks suppressed
>> [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
>> 
>> It seems to function ok, though I'm not sure if there's degraded
>> network performance...
> [...]
>
> I understand network performance on all RPi models is poor due to lack
> of a built-in Ethernet MAC and the poor design of the USB interface.
> Also that message is a generic error message from the usbnet core and
> is not specific to the smsc95xx driver.

Yes, kevent 2 is "EVENT_RX_MEMORY", and this error affects any usbnet
based device under memory pressure.  The usbnet framework just doesn't
handle the case where GFP_KERNEL allocations fail. How could it? 

The only viable "fix" I can see is by preallocating and recycling all
buffers instead of the repeated allocations done by usbnet now.  But
that's a major refactoring of usbnet.

The log message spam could of course be fixed, but the rate-limiting is
"good enough".


Bjørn

Bug#820176: 3.16.7-ckt25-1: BUG: unable to handle kernel paging request (when connecting a USB device)

[Bjørn Mork]

Ben Hutchings <b...@decadent.org.uk> writes:
> On Wed, 2016-04-06 at 16:51 +0200, Bjørn Mork wrote:
>> Antonis Christofides <anth...@itia.ntua.gr> writes:
>> 
>> > 
>> > Apr  5 13:32:47 thames kernel: [86003.993994] BUG: unable to handle kernel 
>> > paging request at eba40a800380
>> > Apr  5 13:32:47 thames kernel: [86003.994005] IP: [] kfree+0x76/0x220
>> ..
>> > 
>> > Apr  5 13:32:47 thames kernel: [86003.994679] Call Trace:
>> > Apr  5 13:32:47 thames kernel: [86003.994689]  [] ? 
>> > usb_release_bos_descriptor+0x1d/0x40 [usbcore]
>> I believe this bug is fixed by commit e5bdfd50d6f7 ("Revert "usb: hub:
>> do not clear BOS field during reset device"") in mainline.  Don't know
>> the stable status of that.  I don't see it in v3.16.x yet.  I assume Ben
>> keeps track of it :)
>
> The crash after disconnection certainly seems like it could be fixed by
> that.  But the rapid disconnections (at 13:31:32 and 13:32:47) appear
> to be a different bug.

Yes.  My guess would be a voltage dip since it happens when spinning up
the disk.  There is little the host can do about USB disconnects anyway.
That's a device hardware or firmware issue. It won't help tracking it as
a kernel bug.

I would start by adding more power, using an external power supply if
supported or a split USB cable drawing power from 2 ports.


Bjørn

Bug#820176: 3.16.7-ckt25-1: BUG: unable to handle kernel paging request (when connecting a USB device)

[Bjørn Mork]

Antonis Christofides  writes:

> Apr  5 13:32:47 thames kernel: [86003.993994] BUG: unable to handle kernel 
> paging request at eba40a800380
> Apr  5 13:32:47 thames kernel: [86003.994005] IP: [] 
> kfree+0x76/0x220
..
> Apr  5 13:32:47 thames kernel: [86003.994679] Call Trace:
> Apr  5 13:32:47 thames kernel: [86003.994689]  [] ? 
> usb_release_bos_descriptor+0x1d/0x40 [usbcore]

I believe this bug is fixed by commit e5bdfd50d6f7 ("Revert "usb: hub:
do not clear BOS field during reset device"") in mainline.  Don't know
the stable status of that.  I don't see it in v3.16.x yet.  I assume Ben
keeps track of it :)


Bjørn

Bug#820061: linux-image-amd64: kernel hangs since debian 8.4

[Bjørn Mork]

Benoît Tonnerre  writes:

> Apr  4 18:52:55 pci003-01 kernel: [   79.329223] RIP: 
> 0010:[]
> [] radeon_fence_ref+0xd/0x50 [radeon]
> Apr  4 18:52:55 pci003-01 kernel: [   79.330192] RSP: 0018:88003639fb18
> EFLAGS: 00010292
> Apr  4 18:52:55 pci003-01 kernel: [   79.331154] RAX:  RBX:
> 8802218f55f8 RCX: 8802218f4d08
> Apr  4 18:52:55 pci003-01 kernel: [   79.332125] RDX: 0001 RSI:
>  RDI: 
> Apr  4 18:52:55 pci003-01 kernel: [   79.333110] RBP: 8802218f5550 R08:
> 8802218f4000 R09: 
> Apr  4 18:52:55 pci003-01 kernel: [   79.334119] R10: 0002 R11:
> 88003639fe08 R12: 0020
> Apr  4 18:52:55 pci003-01 kernel: [   79.335117] R13: 88003639fbe0 R14:
> 88003639fbb0 R15: 8802218f55f8
> Apr  4 18:52:55 pci003-01 kernel: [   79.336120] FS:  7fd8f5323980()
> GS:88022dc6() knlGS:
> Apr  4 18:52:55 pci003-01 kernel: [   79.337143] CS:  0010 DS:  ES: 
> CR0: 80050033
> Apr  4 18:52:55 pci003-01 kernel: [   79.338142] CR2: 0008 CR3:
> 000223b3e000 CR4: 000407e0
> Apr  4 18:52:55 pci003-01 kernel: [   79.339125] Stack:
> Apr  4 18:52:55 pci003-01 kernel: [   79.340065]  a04900bc
> 0020 eea00100 88003639fcd0
> Apr  4 18:52:55 pci003-01 kernel: [   79.341006]  8802218f4000
> 8802216c0a20 8802216c0a20 0001
> Apr  4 18:52:55 pci003-01 kernel: [   79.341952]  
>   
> Apr  4 18:52:55 pci003-01 kernel: [   79.342899] Call Trace:
> Apr  4 18:52:55 pci003-01 kernel: [   79.343854]  [] ?
> radeon_sa_bo_new+0x25c/0x460 [radeon]

I believe this is fixed by commit f80be5a9b1cc ("Revert "drm/radeon:
hold reference to fences in radeon_sa_bo_new"") in v3.16.7-ckt26.


Bjørn

Bug#819703: xscreensaver: "This version of XScreenSaver is very old! Please upgrade!" message

[Bjørn Mork]

Package: xscreensaver
Version: 5.34-1
Followup-For: Bug #819703

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Why is this a bug? Is there something not working? AFAICS, this is a
documented feature. Whether you like the feature or not is irrelevant.
In any case, how the heck can anyone justify an "important" severity? I.e.

 a bug which has a major effect on the usability of a package, without
 rendering it completely unusable to everyone.

Please explain how this warning affects the usability of the package,
or downgrade this bug to the more appropriate "wishlist" severity.

I'm really surprised seeing requests for package removal based on this
"bug".  Is this now RC?  Are there anyone forcing you to use this
package?  I humbly request that xscreensaver is kept in Debian.  For me,
it is the only acceptable screensaver, for this reason among others:
https://www.jwz.org/xscreensaver/toolkits.html

If any of you care about screen savers in Debian, then your time is much
better spent auditing the other screen saver packages.

Thanks.


Bjørn


-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlcBIakACgkQ10rqkowbIsnC5wCfUgoJfe0Bk7KrPl8PP3may7tR
fBwAoIwSuBrjyX7ZPDeD/Z1WXW5+Ursi
=O0ju
-END PGP SIGNATURE-

Bug#814785: ifupdown: fails to bring up "wpa-roam" interfaces on boot

[Bjørn Mork]

Package: ifupdown
Version: 0.8.10
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There appears to be a bit of a chicken-n-egg problem with "wpa-roam"
type interfaces, and any other type of interface which need ifup
before a carrier can be detected:
"/etc/init.d/networking start" will only call ifup on hotplug class
interfaces with a carrier.

A "wpa-roam" type interface will not be able to detect a carrier
until wpa_supplicaant has been started, which is supposed to happen
in the pre-up phase.  But there won't be any pre-up phase unless
ifup is called... catch 22.

This is the relevant part if my /etc/network/interfaces:

 # use wpa_action to control this interface
 allow-hotplug wlan0
 iface wlan0 inet manual
 wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

 # 'default' is used by wpa_cli as the fallback mapping target
 iface default inet dhcp


Note that the udev hotplug script /lib/udev/ifupdown-hotplug works
fine - unconditionally calling ifup on any new hotplug interface. So
"hotplugging" wlan0 after the system is up will bring up the interface
and start wpa_supplicant.

The problem lies in the hotplug fallback code in /etc/init.d/networking,
which AFAIU is supposed to catch interfaces hotplugged/detected *before*
the system was fully operational.  It makes ifup_hotplug depend on carrier
by testing for
   [ "$(cat /sys/class/net/$link/operstate)" = up ]

This code has been like that "forever", and I cannot explain why it
suddenly has become a problem.  I assume this might be related to udevadm
"settle" support, or some other unrelated boot process change.  The main
point is that this code now has become a problem by preventing wlan
interfaces from automatically coming up on boot.

The simple attached patch fixes the problem for me.  But I must admit
that I do not understand the intentions of the original code.  It seems
completely illogical to avoid ifup unless the link is up, but I assume
there is a reason this was found necessary.  In any case, I don't think
that reason can be valid anymore since the /lib/udev/ifupdown-hotplug
behaves differently.

(yes, I know I should probably give up and use networkd or whatever, but
FWIW the simple patch here does allow my to continue using my existin 
ifupdown+wpa_supplicant config)


Bjørn

- -- System Information:
Debian Release: 8.3
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-rc4+ (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ifupdown depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.28
ii  iproute2 4.3.0-1git
ii  libc62.21-7
ii  lsb-base 4.1+Debian13+nmu1

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.3.1-6+deb8u2

Versions of packages ifupdown suggests:
ii  ppp 2.4.6-3.1
pn  rdnssd  

- -- Configuration Files:
/etc/default/networking changed:
VERBOSE=yes

/etc/init.d/networking changed:
PATH="/sbin:/bin"
RUN_DIR="/run/network"
IFSTATE="$RUN_DIR/ifstate"
STATEDIR="$RUN_DIR/state"
[ -x /sbin/ifup ] || exit 0
[ -x /sbin/ifdown ] || exit 0
. /lib/lsb/init-functions
CONFIGURE_INTERFACES=yes
EXCLUDE_INTERFACES=
VERBOSE=no
[ -f /etc/default/networking ] && . /etc/default/networking
verbose=""
[ "$VERBOSE" = yes ] && verbose=-v
process_exclusions() {
set -- $EXCLUDE_INTERFACES
exclusions=""
for d
do
exclusions="-X $d $exclusions"
done
echo $exclusions
}
process_options() {
[ -e /etc/network/options ] || return 0
log_warning_msg "/etc/network/options still exists and it will be IGNORED! 
Please use /etc/sysctl.conf instead."
}
check_ifstate() {
if [ ! -d "$RUN_DIR" ] ; then
if ! mkdir -p "$RUN_DIR" ; then
log_failure_msg "can't create $RUN_DIR"
exit 1
fi
if ! chown root:netdev "$RUN_DIR" ; then
log_warning_msg "can't chown $RUN_DIR"
fi
fi
if [ ! -r "$IFSTATE" ] ; then
if ! :> "$IFSTATE" ; then
log_failure_msg "can't initialise $IFSTATE"
exit 1
fi
fi
}
check_network_file_systems() {
[ -e /proc/mounts ] || return 0
if [ -e /etc/iscsi/iscsi.initramfs ]; then
log_warning_msg "not deconfiguring network interfaces: iSCSI root is 
mounted."
exit 0
fi
while read DEV MTPT FSTYPE REST; do
case $DEV in
/dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*|curlftpfs*)
log_warning_msg "not deconfiguring network interfaces: network 
devices still mounted."
exit 0
;;
esac
case $FSTYPE in

nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs)
log_warning_msg "not deconfiguring network interfaces: 

Bug#813381: fonts-wine: freetype_SelectFont can't find a single appropriate font

[Bjørn Mork]

Jens Reyer  writes:

> prefix and update to 1.8-7 or 1.8.1-1. I also don't get the fixme
> warnings (although enabled in WINEDEBUG).
>
> But other Windows applications indeed also miss the text in their
> windows. Creating the link doesn't help though for that.

Thanks for testing.  Any ideas about other places I might have messed
up, making this problem happen?  I must admit that I don't have a
perfectly "clean" sid or testing system. There are still some jessie
packages around. Although I have made an effort to align all wine related
packacges with sid, I might have missed something.

> I have fonts-liberation installed (but not ttf-mscorefonts-installer).
> Unfortunately I can't easily test if this is the reason that I don't see
> exactly the same problem. Do you have fonts-liberation installed?

I have both those packages installed:

bjorn@nemi:~$ apt-cache policy fonts-liberation ttf-mscorefonts-installer
fonts-liberation:
  Installed: 1.07.4-1
  Candidate: 1.07.4-1
  Version table:
 *** 1.07.4-1 700
700 http://ftp.no.debian.org/debian jessie/main amd64 Packages
700 http://ftp.no.debian.org/debian jessie/main i386 Packages
600 http://ftp.no.debian.org/debian sid/main amd64 Packages
600 http://ftp.no.debian.org/debian sid/main i386 Packages
100 /var/lib/dpkg/status
ttf-mscorefonts-installer:
  Installed: 3.6
  Candidate: 3.6
  Version table:
 *** 3.6 700
700 http://ftp.no.debian.org/debian jessie/contrib amd64 Packages
700 http://ftp.no.debian.org/debian jessie/contrib i386 Packages
600 http://ftp.no.debian.org/debian sid/contrib amd64 Packages
600 http://ftp.no.debian.org/debian sid/contrib i386 Packages
100 /var/lib/dpkg/status


Bjørn

Bug#813381: [pkg-wine-party] Bug#813381: fonts-wine: freetype_SelectFont can't find a single appropriate font

[Bjørn Mork]

Michael Gilbert <mgilb...@debian.org> writes:
> On Mon, Feb 1, 2016 at 9:21 AM, Bjørn Mork wrote:
>> Running e.g. winefile with  WINEDEBUG=warn+all results in lots of
>> warnings like this:
>>
>>  fixme:font:freetype_SelectFont can't find a single appropriate font - 
>> bailing
>
> You may need to run winecfg to update an existing config.  Please
> reply whether that works, and I'll document it.

But winecfg is offer for the same problem, like any other windows
application...

Attempting to run winecfg with fonts-wine version 1.8-7 and no
/usr/share/wine/wine/fonts symlink results in the same fonts warnings
and no visible application window at all.

Not that I think it would help anyway.  I cannot see anywhere the font
path configured in winecfg.  I also tried looking around for registry
settings etc before downgrading fonts-wine, without finding anything
that looked like it pointed to the fonts dir.



Bjørn

Bug#812575: udev: predictable network device names fails for USB devices without a permanent hw address

[Bjørn Mork]

Michael Biebl  writes:

>> But even with this in place, the new logic should be prepared for
>> duplicate mac addresses.  There are plenty of USB devices with non-
>> unique mac addresses out there.  It's more of a rule than an exception
>> for GSM/LTE modem devices...
>
> Please consider raising this issue upstream and filing a bug at
> https://github.com/systemd/systemd/issues/new

Just FYI, I stumbled across the upstream systemd sources on my disk
(have a lof cruft laying around :) and noticed that this problem is not
present there.  The "net_setup_link" builtin helper is very careful to
avoid basing its names on local mac addresses or random addresses. Both
which are true in the case I reported.  usbnet based drivers will set
addr_assign_type to NET_ADDR_RANDOM when appropriate:

 bjorn@nemi:~$  grep . /sys/class/net/wwan*/addr_assign_type
 /sys/class/net/wwan0/addr_assign_type:1
 /sys/class/net/wwan1/addr_assign_type:1


The bug was introduced by this commit, trying to work around the
upstream bogus assumption that USB bus numbers are stable:

commit 51009270be5da77a0e11b313190ef12ab401c007
Author: Martin Pitt 
Date:   Wed Jun 3 12:48:42 2015 +0200

Add debian/extra/01-mac-for-usb.link: Use MAC based names for network 
interfaces which are (directly or indirectly) on USB

Path based names are inadequate for dynamic buses like USB.

See discussion on

  https://lists.debian.org/debian-devel/2015/05/msg00170.html

and revised proposal on

  https://lists.debian.org/debian-devel/2015/06/msg00018.html



And I recall even being part of that discussion.  Obviously without
getting the message trough.  So let me try again:

   You CANNOT create a stable name for USB devices.

The reason is pretty simple and should be bloody obvious: You have no
stable and unique input parameteres.  Every single attribute you have
access to is either shared with multiple devices or subject to change.

So if you insist on renaming these devices, then you will fail.



Bjørn