Bug#987696: findutils: suggest plocate as an alternative

[Paul Wise]

On Sun, 2 May 2021 13:25:21 +0200 Andreas Metzler wrote:

> thanks for the report. I think it would be better to simply drop the
> Suggests, it was added eons ago when GNU locate was split-off from find
> to ease upgrades.

FWIW, I think it is better to keep the Suggests, since locate
implementations are essentially a faster way to find files,
which is what findutils is about.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#989519: hollywood: update mlocate dependency

[Paul Wise]

Package: hollywood
Severity: normal
X-Debbugs-CC: ploc...@packages.debian.org

plocate is a new locate and now updatedb implementation that is much
faster than mlocate due to new on-disk formats and new Linux kernel
features like io_uring.

   https://plocate.sesse.net/
   https://blog.sesse.net/blog/tech/2020-12-03-19-45_plocate_1_1_0_released.html

The hollywood package seems to work with any locate implementation:

   $ apt download -qq hollywood 
   $ dpkg-deb -R hollywood_1.21-1_all.deb .
   $ grep -ri updatedb
   $ grep -ri locate
   DEBIAN/control:Recommends: apg, atop, bmon, bsdmainutils, ccze, cmatrix, 
htop, jp2a, mlocate, moreutils, openssh-client, speedometer, tree
   usr/lib/hollywood/jp2a:command -v locate >/dev/null 2>&1 || exit 1
   usr/lib/hollywood/jp2a:  FILES=$(locate -l 4096 "/usr/*jpg" 2>/dev/null 
| sort -R)
   usr/lib/hollywood/code:command -v locate >/dev/null 2>&1 || exit 1
   usr/lib/hollywood/code:  FILES=$(locate -l 4096 "/usr/*.java" "/usr/*.c" 
"/usr/*.cpp" 2>/dev/null | sort -R)

Please fix the recommends to use any locate but prefer faster ones:

   Recommends: plocate | mlocate | locate

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'testing-security')
Architecture: amd64 (x86_64)

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

Versions of packages hollywood depends on:
pn  byobu  
ii  tmux   3.1c-1

Versions of packages hollywood recommends:
ii  apg 2.2.3.dfsg.1-5+b2
pn  atop
ii  bmon1:4.0-7
ii  bsdmainutils12.1.7+nmu3
pn  ccze
pn  cmatrix 
pn  htop
pn  jp2a
ii  mlocate 0.26-5
ii  moreutils   0.65-1
ii  openssh-client  1:8.4p1-5
pn  speedometer 
ii  tree1.8.0-1+b1

hollywood suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#989518: education-common: update mlocate dependency

[Paul Wise]

Package: education-common
Severity: normal
X-Debbugs-CC: ploc...@packages.debian.org

plocate is a new locate and now updatedb implementation that is much
faster than mlocate due to new on-disk formats and new Linux kernel
features like io_uring.

   https://plocate.sesse.net/
   https://blog.sesse.net/blog/tech/2020-12-03-19-45_plocate_1_1_0_released.html

Please fix the recommends to use any locate but prefer faster ones:

   Recommends: plocate | mlocate | locate

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'testing-security')
Architecture: amd64 (x86_64)

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

Versions of packages education-common depends on:
pn  education-tasks  

Versions of packages education-common recommends:
ii  bc 1.07.1-2+b2
pn  cifs-utils 
pn  command-not-found  
pn  convmv 
ii  debconf-utils  1.5.75
pn  debian-edu-config  
pn  debian-edu-doc-en  
pn  debian-edu-doc-legacy-en   
pn  debian-edu-install 
pn  deborphan  
pn  dhcping
ii  dmidecode  3.3-2
pn  etherwake  
ii  ethtool1:5.9-1
ii  finger 0.17-17
pn  fping  
ii  gdebi-core 0.9.5.7+nmu5
ii  hddtemp0.3-beta15-54
pn  htop   
ii  hwinfo 21.72-1
ii  iftop  1.0~pre4-7
ii  iotop  0.6-24-g733f3f8-1.1
ii  iproute2   5.10.0-4
ii  iputils-arping 3:20210202-1
ii  less   551-2
ii  libnss-myhostname  247.3-5
ii  libpam-tmpdir  0.09+b2
ii  libwww-perl6.52-1
pn  lshw   
ii  lsscsi 0.31-1+b1
ii  mc 3:4.8.26-1
ii  memtest86+ 5.01-3.1
ii  mlocate0.26-5
ii  mtools 4.0.26-1
ii  mtr-tiny   0.94-1
pn  ncftp  
ii  nmap   7.91+dfsg1+really7.80+dfsg1-2
pn  nullidentd | ident-server  
pn  openbsd-inetd  
ii  pciutils   1:3.7.0-5
pn  procinfo   
ii  procmail   3.22-26
ii  psmisc 23.4-2
pn  resolvconf 
ii  rsync  3.2.3-4
ii  rsyslog8.2102.0-2
ii  screen 4.8.0-6
ii  smartmontools  7.2-1
ii  strace 5.10-1
pn  sysfsutils 
ii  tcpdump4.99.0-2
ii  tcptraceroute  1.5beta7+debian-4.1+b1
ii  vim2:8.2.2434-3

Versions of packages education-common suggests:
pn  apticron | cron-apt
pn  cpqarrayd  
ii  debian-goodies 0.87
ii  debsecan   0.4.20.1
pn  dpt-i2o-raidutils | raidutils  
pn  emacs  
ii  gdb10.1-1.7
pn  isag   
ii  kexec-tools1:2.0.20-2.1
pn  mpt-status 
pn  nvram-wakeup   
ii  popularity-contest 1.71
pn  rsyslog-doc
ii  valgrind   1:3.16.1-1
ii  wireshark  3.4.4-1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#989517: parl-desktop: update mlocate dependency

[Paul Wise]

Package: parl-desktop
Severity: normal
X-Debbugs-CC: ploc...@packages.debian.org

plocate is a new locate and now updatedb implementation that is much
faster than mlocate due to new on-disk formats and new Linux kernel
features like io_uring.

   https://plocate.sesse.net/
   https://blog.sesse.net/blog/tech/2020-12-03-19-45_plocate_1_1_0_released.html

Please fix the depends to use any locate but prefer faster ones:

   Depends: plocate | mlocate | locate

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'testing-security')
Architecture: amd64 (x86_64)

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

Versions of packages parl-desktop depends on:
pn  acpi-support  
pn  acpi-support-base 
ii  alsa-utils1.2.4-1
ii  anacron   2.3-30
ii  apt-listchanges   3.24
ii  aptitude  0.8.13-3
ii  bash-completion   1:2.11-2
ii  bluez 5.55-3
pn  catfish   
ii  debian-security-support   1:11+2021.03.19
ii  evince3.38.2-1
ii  firefox-esr   78.11.0esr-1
ii  gnome-disk-utility3.38.2-1
pn  jitterentropy-rngd
ii  libgl1-mesa-dri   21.1.0-4
ii  libreoffice-calc  1:7.0.4-4
ii  libreoffice-gtk3  1:7.0.4-4
ii  libreoffice-impress   1:7.0.4-4
ii  libreoffice-writer1:7.0.4-4
pn  lightdm   
pn  lightning 
ii  mlocate   0.26-5
pn  mousepad  
ii  mpv   0.32.0-3
ii  needrestart   3.5-4
ii  network-manager-gnome 1.20.0-3
pn  nuntius   
ii  parcimonie0.12.0-2
pn  pasystray 
ii  pavucontrol   4.0-2
pn  pinentry-gtk2 
ii  popularity-contest1.71
ii  pulseaudio14.2-2
ii  pulseaudio-utils  14.2-2
ii  pulsemixer1.5.1-1
ii  shotwell  0.30.11-1
pn  slick-greeter 
ii  systemd   247.3-5
ii  task-laptop   3.67
pn  thunar
pn  thunderbird   
ii  unattended-upgrades   2.8
pn  unicode-screensaver   
pn  usermode  
ii  uuid-runtime  2.36.1-7
pn  volumeicon-alsa   
pn  webext-dav4tbsync 
ii  webext-https-everywhere   2021.1.27-1
ii  webext-privacy-badger 2020.10.7-1
ii  webext-ublock-origin-firefox  1.33.0+dfsg-1
pn  xfce4-notifyd 
pn  xfce4-panel   
pn  xfce4-power-manager   
pn  xfce4-power-manager-plugins   
pn  xfce4-pulseaudio-plugin   
pn  xfce4-session 
ii  xserver-xorg  1:7.7+22

parl-desktop recommends no packages.

Versions of packages parl-desktop suggests:
pn  parl-desktop-strict  

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#989198: unblock: webkit2gtk/2.32.1-1

[Paul Gevers]

Hi Alberto,

On 05-06-2021 01:52, Alberto Garcia wrote:
> So if you are ok with the change of dependencies I will upload it to
> unstable and request a new unblock.

Ack. But next time, please create a new unblock (pre-approval) request.
This bug is closed and your message had a high chance of being missed.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976367: cruft-ng: add support for plocate

[Paul Wise]

Control: severity -1 important

On Fri, 04 Dec 2020 14:25:23 +0800 Paul Wise  wrote:

> It would be great if I could fully switch from mlocate to plocate; only
> the lack of support for plocate in cruft-ng is preventing me from
> removing mlocate from my system.

plocate now Breaks: mlocate, which means that both plocate and mlocate
cannot be installed on the same system. That change makes it much more
important that cruft-ng add support for plocate too, bumping severity.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

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

[jim_p]

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

About the logs. Did anyone of you reply to my question "where can I find those
logs?" and I missed it? All I have found, again BY MYSELF, is this file here
that when I run cat on it, gibberish shows up in the terminal. I can zip it and
send it to you if you want to examine it.

# du -h /var/log/journal/somenumbersandletters/system.journal
25M /var/log/journal/somenumbersandletters/system.journal

I have no idea what it may contain, because if it stores the logs from last 50
boots, it has been 2 weeks now and I boot my pc ~3 times a day, so most of
those logs are probably gone.

As for the hardware, it has been almost a week now that it works flawlessly
with another nvidia gpu and 5.10.28 + nvidia 340xx.
Can you imagine how boring it is to press the power button and see your pc boot
just fine instead of checking the monitor to see if post/grub/boot
messages/desktop showed up?

How come this piece of hw did not become flaky, and the ones before it became
just after one day of running with the new kernel?
And what about nouveau and radeon? Running the "untainted" kernel on those (now
broken) gpus did not do a single thing. Neither the nvidia continued to work,
nor ati was saved from dying after the upgrade.

About the "lots of bug reports about nvidia". Out of the 900+ (according to
popcon) people (or systems) that run nvidia 340xx, how many of them do you
think run testing/unstable?
Judging from the feedback I get on my bug reports on every new kernel on which
nvidia 340xx fails to build, I would say me plus 2 or 3 more. And those 2-3
people probably have different hardware than me, e.g. amd cpu and amd chipset,
so the issue may not occur on their setups.

As for the why use nvidia's driver? Because in order to prefer nvidia over
nouvau you need to have demands and standards. If a simple user sees nouveau
draw its 2d desktop fine, he will say it is enough for him.
But, unlike that simple user, I, "unfortunately", want my driver to do hardware
decoding on videos (we have 2021 and not 2010, so this should have been a
standard now for all drivers), 3d and powersaving (also something that should
be a standard). Do you now see the difference between something that "works"
and something that works 110%?
That's why I insist on nvidia's driver.

Bug#989516: installation-reports: successful install after manually adding some modules

[Vagrant Cascadian]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: vagr...@debian.org

Boot method: microSD
Image version: 
https://d-i.debian.org/daily-images/arm64/20210605-02:29/netboot/SD-card-images/
Date: 2021-06-05 UTC-07 ~15:00

Machine: Pinebook Pro RK3399
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   1925096   0   1925096   0% /dev
tmpfs  tmpfs   3958441372394472   1% /run
/dev/mmcblk1p2 ext4   9509056 4192736   4811696  47% /
tmpfs  tmpfs  1979200   0   1979200   0% /dev/shm
tmpfs  tmpfs 5120   4  5116   1% /run/lock
tmpfs  tmpfs   395840  52395788   1% /run/user/113
tmpfs  tmpfs   395840  52395788   1% /run/user/1000

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [O]
Detect media:   [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

I needed to append some kernel modules to the initrd:

- pwm-rockchip: to get the LCD/eDP panel to display anything

Even with this module appended to the initrd, I had to manually load
it from the serial console. Presumably once this is merged into the
fb-modules udeb, this will work out of the box, unless some other
modules are still missing...

Fixed in fb-modules udeb:

  
https://salsa.debian.org/kernel-team/linux/-/commit/189e0c5b2201596c5b45a912dcc7f643725fa36f

Even with this loaded, the screen color was very washed out; almost
black and white, with a hint of cyan. Once booted into the installed
system, the colors seemed normal.


- fusb302, tcpm and typec: to enable using the ethernet on a USB-C dock

A USB-A ethernet adapter I had worked out of the box, but I wanted to
figure out what I needed to get the USB-C dock ethernet working.

Fixed in usb-modules udeb:

  
https://salsa.debian.org/kernel-team/linux/-/commit/da303eff9dcfd233997a9fc2583c66d8587315be


Other than the washed out colors, should work ok once the next kernel
version is used.


live well,
  vagrant


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210605-02:14:25"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux pdbn 5.10.0-7-arm64 #1 SMP Debian 5.10.40-1 (2021-05-28) 
aarch64 GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.10.0-7-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 02: USB2.0 Hub [05e3:0608]
usb-list:Level 01 Parent 01 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 01 Device 03: USB Camera [0c45:6321]
usb-list:Level 02 Parent 02 Port 01  Class ef(misc ) Subclass 02 Protocol 01
usb-list:Manufacturer: Sonix Technology Co., Ltd.
usb-list:Interface 00: Class 0e(video) Subclass 01 Protocol 00 Driver 
usb-list:Interface 01: Class 0e(video) Subclass 02 Protocol 00 Driver 
usb-list: 
usb-list: Bus 02 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.10.0-7-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: xHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 5.10.0-7-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 04 Device 01: xHCI Host Controller [1d6b:0003]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 03
usb-list:Manufacturer: Linux 5.10.0-7-arm64 xhci-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 05 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 5.10.0-7-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 06 Device 01: G

Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]

[Paul Gevers]

Control: tags -1 moreinfo
Control: retitle -1 unblock: e2fsprogs/1.46.2-1

On 03-06-2021 22:06, Paul Gevers wrote:
> As I can't judge this myself, I'll take your word for it. If the upload
> can happen in the next couple of days, let's have this in unstable and
> if nothing is reported, have it in bullseye.

Please removed the moreinfo tag once the package is available.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988214: Bug#989037: Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1

[Paul Gevers]

Hi Utkarsh,

On 04-06-2021 11:26, Utkarsh Gupta wrote:
> On Fri, Jun 4, 2021 at 1:38 AM Paul Gevers  wrote:
>>> You haven't answered my question: "does rails still work with the old
>>> version of ruby-marcel and can the version bump be reverted"
>>
>> Ping. Without a proper answer, I can't decide.
> 
> Thanks, I'm yet to figure that out and hopefully do this on weekend.
> If it were to work with the older ruby-marcel, can I then just push
> the newer rails to bullseye directly? Now that marcel's at v1.0 in
> unstable, I don't want to downgrade again.

I am hoping it's possible to just downgrade the *dependency* in rails
only, such that the upload can happen via unstable. There is no "direct
bullseye" route. Or do you expect you'll have to make (lots) of changes
to rails to match the right ruby-marcel package? If that's the case,
than ruby-marcel/unstable isn't a drop in replacement for
ruby-marcel/bullseye and I'd expect that ruby-marcel/unstable would need
a versioned Breaks for reverse dependent packages (ruby-activestorage),
but I'm not seeing that.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989036: unblock: ruby-marcel/1.0.1+dfsg-2

[Paul Gevers]

Control: tags -1 moreinfo

Hi Utkarsh,

[While typing a reply to the rails unblock, I checked this request again].

On 24-05-2021 10:17, Utkarsh Gupta wrote:
> We had to bump ruby-marcel to a newer version because the mimemagic
> dependency - which relies on GPL-licensed mime type data from
> freedesktop.org’s shared-mime-info project - is removed.

I'm having trouble understanding what you wrote here. Did something in
Debian now break the old ruby-marcel and you had to update ruby-marcel?
If so, can you try again to explain how that happened? If not, I don't
think you "had to bump ruby-marcel because of the mimemagic dependency"?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989498: unblock: golang-1.15/1.15.9-5

[Paul Gevers]

Control: tags -1 moreinfo

Hi Shengjing,

On 05-06-2021 13:57, Shengjing Zhu wrote:
> Please unblock package golang-1.15

You're well aware that golang builds statically so normally we're not
done with just accepting one package. Do we now need to also rebuild
everything that build depends on golang (I'd expect so)? Did anything in
the golang community get uploaded to unstable that needs reverting
before it can migrate?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988442: unblock: linux/5.10.40-1

[Paul Gevers]

Hi kibi, Salvatore,

On 03-06-2021 22:31, Cyril Brulebois wrote:
> Will keep an eye on this, and close this bug report once
> migration has happend (just in case some bit is missing/some typo
> happened or something).

This happened, so this bug can be closed now.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989515: ITP: golang-github-jinzhu-copier -- Deepcopy for golang, copy value from struct to struct and more

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-jinzhu-copier
  Version : 0.3.2-1
  Upstream Author : Jinzhu
* URL : https://github.com/jinzhu/copier
* License : Expat
  Programming Lang: Go
  Description : Deep copy value from struct to struct and more

   Library for deep copying complex datastructures in golang.
   Features:
 • Copy from field to field with same name
 • Copy from method to field with same name
 • Copy from field to method with same name
 • Copy from slice to slice
 • Copy from struct to slice
 • Copy from map to map
 • Enforce copying a field with a tag
 • Ignore a field with a tag

Bug#989514: ITP: golang-github-disiqueira-gotree -- A Tree printer module written in GoLang

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-disiqueira-gotree
  Version : 3.0.2-1
  Upstream Author : Diego Siqueira
* URL : https://github.com/disiqueira/gotree
* License : Expat
  Programming Lang: Go
  Description : A Tree printer module written in GoLang

 The GoTree's goal is to be a simple tool providing a stupidly
 easy-to-use and fast way to print recursive structures.

Bug#958463: pathological: Syntax Warning about "is with a literal" (python3 compatibility?)

[Ionen Wolkens]

On Wed, Apr 22, 2020 at 02:26:40PM +0200, Alex wrote:
> /usr/share/games/pathological/pathological.py:137: SyntaxWarning: "is" with a 
> literal. Did you mean "=="?
>   if colorkey is -1:
> 
> This looks like it may be incompatible or incompatible in the future. It
> is probably easy to fix with a patch or in the upstream.

Liberal use of "is" actually is what prevents >=pygame-2 from being
usable with this game, e.g. 'event.type is KEYDOWN' never matches.
See: pygame-2.0.1/buildconfig/pygame-stubs/constants.pyi

Given it fixes colorkey as well, may want this patch from Gentoo.
https://bugs.gentoo.org/794211

--- a/pathological.py
+++ b/pathological.py
@@ -133,3 +133,3 @@
if colorkey is not None:
-   if colorkey is -1:
+   if colorkey == -1:
colorkey = image.get_at((0,0))
@@ -1395,6 +1395,6 @@
for event in pygame.event.get():
-   if event.type is QUIT:
+   if event.type == QUIT:
return -4
-   elif event.type is KEYDOWN:
-   if event.key is K_ESCAPE: return -3
+   elif event.type == KEYDOWN:
+   if event.key == K_ESCAPE: return -3
elif event.key == ord('n'): return 2
@@ -1419,3 +1419,3 @@
 
-   elif event.type is MOUSEBUTTONDOWN:
+   elif event.type == MOUSEBUTTONDOWN:
if self.paused:
@@ -1713,5 +1713,5 @@
for event in pygame.event.get():
-   if event.type is QUIT:
+   if event.type == QUIT:
return -2
-   elif event.type is KEYDOWN:
+   elif event.type == KEYDOWN:
if event.key == K_ESCAPE: return -1
@@ -1744,3 +1744,3 @@
return 1
-   elif event.type is MOUSEBUTTONDOWN:
+   elif event.type == MOUSEBUTTONDOWN:
return 1
@@ -1799,5 +1799,5 @@
for event in pygame.event.get():
-   if event.type is QUIT:
+   if event.type == QUIT:
return None
-   elif event.type is KEYUP:
+   elif event.type == KEYUP:
if event.key == K_LSHIFT:
@@ -1806,3 +1806,3 @@
shift_state &= ~KMOD_RSHIFT
-   elif event.type is KEYDOWN:
+   elif event.type == KEYDOWN:
if event.key == K_LSHIFT:
@@ -1994,3 +1994,3 @@
for event in pygame.event.get():
-   if event.type is QUIT:
+   if event.type == QUIT:
if self.curpage == 1:
@@ -1999,3 +1999,3 @@
return -2
-   elif event.type is KEYDOWN:
+   elif event.type == KEYDOWN:
if event.key == K_F2:
@@ -2032,3 +2032,3 @@
continue
-   elif event.type is MOUSEBUTTONDOWN:
+   elif event.type == MOUSEBUTTONDOWN:
if self.curpage == 1:


signature.asc
Description: PGP signature

Bug#976147: MariaDB upgrade issues from Debian 10 to Debian 11

[Otto Kekäläinen]

> Hello!
>
> There is an updated Galera-4 in Debian unstable now. If you want to
> contribute to the effort, you could now do testing and verify that the
> fix delivered works.

I filed now http://bugs.debian.org/989513 but would still welcome
help. There needs to be more testing that the current unstable version
is the final one.

Bug#989512: upower: Journal getting filled with warning messages about 'treating change event as add on' by upowerd

[Tia]

Package: upower
Version: 0.99.11-2
Severity: normal
X-Debbugs-Cc: tia3...@protonmail.com

Dear Maintainer,

Since installing Bullseye journal started getting populated by these warnings:

lip 01 15:18:46 upowerd[1356]: treating change event as add on 
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1

And sometimes

lip 01 15:19:33 upowerd[1356]: treating change event as add on 
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:046D:C534.0002/0003:046D:4022.0004/power_supply/hidpp_battery_1

I have wireless logitech mouse/keyboard and usb1/1-1/1-1.2/1-1.2:1.1 device 
corresponds to wireless mouse. Such message only appears once per starup.

While first one, usb1/1-1/1-1.1 corresponds to my wireless network interface, 
as seen here

/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/idProduct   is  3121

And

Bus 001 Device 015: ID 0cf3:3121 Qualcomm Atheros Communications

I am unsure what those change events are, but one for wireless card repeats 
seemengly at random and tends to clutter journal. If they are only 
notifications they shoudln't be placed under warning level for journal.

Regards,
Tia


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

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

Versions of packages upower depends on:
ii  dbus   1.12.20-2
ii  libc6  2.31-12
ii  libglib2.0-0   2.66.8-1
ii  libgudev-1.0-0 234-1
ii  libimobiledevice6  1.3.0-6
ii  libplist3  2.2.0-6
ii  libupower-glib30.99.11-2
ii  libusb-1.0-0   2:1.0.24-3
ii  udev   247.3-5

Versions of packages upower recommends:
ii  policykit-1  0.105-30

upower suggests no packages.

-- no debconf information

Bug#989511: /usr/bin/sddm-greeter: Journal warnings about Implicitly defined onFoo properties in Connections are deprecated

[Tia]

Package: sddm
Version: 0.19.0-3
Severity: normal
File: /usr/bin/sddm-greeter
X-Debbugs-Cc: tia3...@protonmail.com

Dear Maintainer,

Since installing Bullseye sddm-greeter started reporting warnings to the journal

lip 02 03:57:40 sddm-greeter[20366]: QFont::fromString: Invalid description 
'(empty)'
lip 02 03:57:40 sddm-greeter[20366]: 
file:///usr/lib/x86_64-linux-gnu/qt5/qml/SddmComponents/LayoutBox.qml:35:5: QML 
Connections: Implicitly defined onFoo properties in Connections are deprecated. 
Use this syntax instead: function onFoo() { ... }

Seems it is a change in QT syntax for connections.
https://stackoverflow.com/questions/62297192/qml-connections-implicitly-defined-onfoo-properties-in-connections-are-deprecat

Simmilary in qt-5 manual
https://doc.qt.io/qt-5/qml-qtqml-connections.html

It doesn't seem to impact functionality.

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

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

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.75
ii  libc6   2.31-12
ii  libgcc-s1   10.2.1-6
ii  libpam0g1.4.0-7
ii  libqt5core5a5.15.2+dfsg-5
ii  libqt5dbus5 5.15.2+dfsg-5
ii  libqt5gui5  5.15.2+dfsg-5
ii  libqt5network5  5.15.2+dfsg-5
ii  libqt5qml5  5.15.2+dfsg-5
ii  libqt5quick55.15.2+dfsg-5
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-5
ii  libxcb-xkb1 1.14-3
ii  libxcb1 1.14-3
ii  qml-module-qtquick2 5.15.2+dfsg-5
ii  x11-common  1:7.7+22
ii  xauth   1:1.1-1
ii  xserver-xorg [xserver]  1:7.7+22
ii  xvfb [xserver]  2:1.20.11-1

Versions of packages sddm recommends:
ii  haveged  1.9.14-1
ii  libpam-systemd   247.3-5
ii  sddm-theme-debian-maui [sddm-theme]  0.19.0-3

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.20.5-1
pn  qtvirtualkeyboard-plugin  

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

Bug#977052: rlwrap: prompt disappears w/ readline 8.1 (fixed upstream)

[Leandro Doctors]

This bug also affects clojure.
See https://bugs.launchpad.net/ubuntu/+source/clojure/+bug/1930277

BTW: the latest rlwrap version as of 2021-June-05 is 0.45.1

Bug#986294: New upstream 0.45.1 available

[Leandro Doctors]

Please check https://github.com/hanslub42/rlwrap/releases/latest

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

On 2021-06-05 22:51, Shengjing Zhu wrote:

Situation has changed since fcitx5 5.0.4, which includes a compatible
frontend for fcitx4 module.
https://salsa.debian.org/input-method-team/fcitx5/-/commit/7780c8f7f9bcde2fcff6ae7fc3ce5ab2c40ebe63

The origin purpose is to support property software which only ships
with fctix4 modules, as well as snap, flatpak, etc, which can't use
the system library.


Ah, so that's why my trivial Chromium snap test worked with 
GTK_IM_MODULE=fcitx. :)


What's the conclusion then as regards this bug? Is it time to change to 
"fcitx" in im-config in unstable (and somehow also in bullseye) without 
worrying about users who have both fcitx 4 and fcitx 5 installed?


--
Gunnar

Bug#975270: rdiff-backup: Can't talk to the version from buster

[Samuel Thibault]

Hello,

Samuel Thibault, le dim. 16 mai 2021 19:03:11 +0200, a ecrit:
> Gregor Zattler, le dim. 16 mai 2021 18:50:42 +0200, a ecrit:
> > * Samuel Thibault  [13. Mai. 2021]:
> > > Kurt Roeckx, le jeu. 19 nov. 2020 20:40:05 +0100, a ecrit:
> > >> I recently found out that my backup has broken for months.
> > >
> > > Not for month, but this does break my backups now that I try to upgrade
> > > some machines, and I don't have another solution than to either
> > > downgrade the package, or upgrade all my machines at the same time (!?)
> > > to get my backups working again.
> > 
> > the rdiff-backup project provides a helpful document
> > regarding this:
> > 
> > https://github.com/rdiff-backup/rdiff-backup/blob/master/docs/migration.md
> > 
> > providing this document in the NEWS.Debian file might be
> > enough in order to close this bug?
> 
> Perhaps we could have a buster-backports package, so that before
> upgrading machines to bullseye, we first just upgrade rdiff-backup on
> all buster machines?

So, does this sound like a possibility?

(rdiff-backup is marked for auto-removal on june 15th)

Samuel

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Shengjing Zhu]

On Sun, Jun 6, 2021 at 4:51 AM Shengjing Zhu  wrote:
>
> On Sun, Jun 6, 2021 at 4:06 AM Gunnar Hjalmarsson  wrote:
> >
> > If both fcitx 4 and fcitx 5 are installed, the IM_MODULE value "fcitx"
> > would result in a fcitx 4 im module being loaded when using fcitx 5. We
> > have so far assumed that that would be a problem, if I understand it
> > correctly, and that's the reason why the fix of this bug was postponed.
> >
> > Question: How would it be a problem?
> >
>
> Situation has changed since fcitx5 5.0.4, which includes a compatible
> frontend for fcitx4 module.
> https://salsa.debian.org/input-method-team/fcitx5/-/commit/7780c8f7f9bcde2fcff6ae7fc3ce5ab2c40ebe63
>
> The origin purpose is to support property software which only ships
> with fctix4 modules, as well as snap, flatpak, etc, which can't use
> the system library.

Correct: better support. As without fcitx4front, it also has
ibusfront, which means using ibus modules in these software, then
fcitx5 can talk to them.
But you always need a proper env to tell these software to choose an
input module. You can set IM_MODULE to fcitx, or ibus. But setting
fcitx5 just makes these software fail to find the right input module.

-- 
Shengjing Zhu

Bug#989510: debian-installer: Successfull installation

[Alexander Reichle-Schmehl]

Package: installation-reports

Boot method: CD-ROM
Image version: 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
Date: 2021-06-05

Machine: KVM based virtual server
Processor: Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz, 4 Cores
Memory: 16GB
Partitions: 
Filesystem Type 1K-blocks   Used Available Use% Mounted 
on
udev   devtmpfs   8178820  0   8178820   0% /dev
tmpfs  tmpfs  1639312500   1638812   1% /run
/dev/mapper/senet--vg-lv--root ext4  19047080 903152  17932248   5% /
tmpfs  tmpfs  8196540  0   8196540   0% /dev/shm
tmpfs  tmpfs 5120  0  5120   0% 
/run/lock
/dev/sda1  ext2480618  48658426974  11% /boot
/dev/mapper/senet--vg-lv--home ext4   9509056124   9394900   1% /home
/dev/mapper/senet--vg-lv--tmp  ext4   4721184 64   4655912   1% /tmp
/dev/mapper/senet--vg-lv--var  ext4   9509056 300616   9094408   4% /var
/dev/mapper/senet--vg-lv--srv  ext4 435169056 28 430720160   1% /srv
tmpfs  tmpfs  1639308  0   1639308   0% /run/use

Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] 
[8086:1237] (rev 02)
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton 
II] [8086:7000]
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE 
[Natoma/Triton II] [8086:7010]
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Kernel driver in use: ata_piix
Kernel modules: ata_piix, ata_generic
00:01.2 USB controller [0c03]: Intel Corporation 82371SB PIIX3 USB 
[Natoma/Triton II] [8086:7020] (rev 01)
Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] 
(rev 03)
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Kernel driver in use: piix4_smbus
Kernel modules: i2c_piix4
00:02.0 VGA compatible controller [0300]: Device [1234:] (rev 02)
Subsystem: Red Hat, Inc. Device [1af4:1100]
Kernel driver in use: bochs-drm
Kernel modules: bochs_drm
00:03.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device 
[1af4:1000]
Subsystem: Red Hat, Inc. Virtio network device [1af4:0001]
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci
00:1c.0 Communication controller [0780]: Red Hat, Inc. Virtio console 
[1af4:1003]
Subsystem: Red Hat, Inc. Virtio console [1af4:0003]
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci
00:1d.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio SCSI [1af4:1004]
Subsystem: Red Hat, Inc. Virtio SCSI [1af4:0008]
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Well, not much to say: Installed a new minimal servr and it worked like a charm 
:)

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

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

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Shengjing Zhu]

On Sun, Jun 6, 2021 at 4:06 AM Gunnar Hjalmarsson  wrote:
>
> If both fcitx 4 and fcitx 5 are installed, the IM_MODULE value "fcitx"
> would result in a fcitx 4 im module being loaded when using fcitx 5. We
> have so far assumed that that would be a problem, if I understand it
> correctly, and that's the reason why the fix of this bug was postponed.
>
> Question: How would it be a problem?
>

Situation has changed since fcitx5 5.0.4, which includes a compatible
frontend for fcitx4 module.
https://salsa.debian.org/input-method-team/fcitx5/-/commit/7780c8f7f9bcde2fcff6ae7fc3ce5ab2c40ebe63

The origin purpose is to support property software which only ships
with fctix4 modules, as well as snap, flatpak, etc, which can't use
the system library.

-- 
Shengjing Zhu

Bug#986904: blag-fortune/1.5.0-1 [ITA] -- anarchist quotes for fortune

[tous]

Thanks!

I changed the distribution to experimental and updated d/control (I had no 
issues with access rights).

Bug#977203: IM_MODULE env for fcitx5 should be "fcitx"

[Gunnar Hjalmarsson]

If both fcitx 4 and fcitx 5 are installed, the IM_MODULE value "fcitx" 
would result in a fcitx 4 im module being loaded when using fcitx 5. We 
have so far assumed that that would be a problem, if I understand it 
correctly, and that's the reason why the fix of this bug was postponed.


Question: How would it be a problem?

I'm asking since we have an ongoing discussion at Ubuntu about fcitx 5 
and snaps. [1] A snap is an application package in a confined 
environment, and at this time only fcitx 4 im modules are installed in 
that environment. The situation seems similar to the issue with some 
proprietary Qt software as described at 
.


I tested to use fcitx 5 on a gtk based snap (Chromium as snap), and it 
failed with the default configuration, but worked fine when setting 
GTK_IM_MODULE=fcitx. Well, "worked" with a caveat: Me being able to 
input "北京" in the search field may not be the most comprehensive test 
you can imagine.


But can it be that it was a mistake to postpone the fix of this bug? Are 
there any significant adverse side effects if using fcitx 5 but loading 
a fcitx 4 im module? Has anybody really tried to find out?


[1] https://launchpad.net/bugs/1928360, starting with comment #19

--
Rgds,
Gunnar

Bug#989348: Acknowledgement (ITP: elementary-planner -- Task manager with Todoist support)

[Francisco M Neto]

control: block -1 by 989350 989349
--

On 6/1/21 11:15 AM, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 989348: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989348.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   debian-de...@lists.debian.org, fmn...@fmneto.com
> (after having been given a Bug report number, if it did not have one).
> 
> Your message has been sent to the package maintainer(s):
>  w...@debian.org
> 
> If you wish to submit further information on this problem, please
> send it to 989...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

-- 
[]'s,

Francisco M Neto 
www.fmneto.com

3E58 1655 9A3D 5D78 9F90
CFF1 D30B 1694 D692 FBF0


OpenPGP_0xD30B1694D692FBF0.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989509: buster-pu: package klibc/2.0.6-1+deb10u1

[Thorsten Glaser]

Ben Hutchings dixit:

>Thorsten Glaser tested the s390x fix in unstable.  It has not (yet)
>been manually tested in this version.

Unfortunately we don’t have a baseline, as the only test I had that
triggered this doesn’t trigger in buster (probably because only a
newer GCC scheduled things to use these registers in the first place).

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

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

[Ben Hutchings]

I've seen nothing to indicate that this is a kernel issue, rather than
hardware becoming flaky or possibly an nvidia driver issue.

It's easy to think that a hardware fault was caused by whatever else
recently changed.  But if there was a software change that broke Nvidia
cards, we would expect to receive lots of bug reports about it, not
just one.

We're still waiting for the requested logs from you.

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'


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

Bug#989509: buster-pu: package klibc/2.0.6-1+deb10u1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-ker...@lists.debian.org, mirabilos 

[ Reason ]
There are open security issues that were triaged as no-dsa by the
security team.  These affect the heap functions (malloc and calloc)
and the cpio utility.

setjmp and longjmp are implemented incorrectly on s390x.

[ Impact ]
Some programs built using klibc may have potential heap overflows
that can be exploited for privilege escalation.

On s390x, programs using setjmp and longjmp may misbehave in
unpredictable ways.

[ Tests ]
malloc, calloc, setjmp, and longjmp are exercised by the test suite
that runs during build.  However the setjmp/longjmp test was not
sufficient to detect the bug.

Thorsten Glaser tested the s390x fix in unstable.  It has not (yet)
been manually tested in this version.

I have tested the cpio utility manually.

[ Risks ]
The changes are localised and seem comparatively low-risk to me.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
All but one of the patches fixes a single bug or CVE as detailed in
its patch header.

The patch "malloc: Set errno on failure" is applied as a dependency
of "malloc: Fail if requested size > PTRDIFF_MAX".

[ Other info ]
diff -Nru klibc-2.0.6/debian/changelog klibc-2.0.6/debian/changelog
--- klibc-2.0.6/debian/changelog2019-02-01 06:00:57.0 +0100
+++ klibc-2.0.6/debian/changelog2021-06-05 20:20:42.0 +0200
@@ -1,3 +1,19 @@
+klibc (2.0.6-1+deb10u1) buster; urgency=medium
+
+  [ Ben Hutchings ]
+  * Apply security fixes from 2.0.9 (Closes: #989505):
+- malloc: Set errno on failure
+- malloc: Fail if requested size > PTRDIFF_MAX (CVE-2021-31873)
+- calloc: Fail if multiplication overflows (CVE-2021-31870)
+- cpio: Fix possible integer overflow on 32-bit systems (CVE-2021-31872)
+- cpio: Fix possible crash on 64-bit systems (CVE-2021-31871)
+
+  [ Thorsten Glaser ]
+  * {set,long}jmp [s390x]: save/restore the correct FPU registers
+(f8‥f15 not f1/f3/f5/f7) (Closes: #943425)
+
+ -- Ben Hutchings   Sat, 05 Jun 2021 20:20:42 +0200
+
 klibc (2.0.6-1) unstable; urgency=medium
 
   * New upstream version:
diff -Nru 
klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch 
klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch
--- klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch 
1970-01-01 01:00:00.0 +0100
+++ klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch 
2021-04-30 04:30:16.0 +0200
@@ -0,0 +1,32 @@
+From: Ben Hutchings 
+Date: Wed, 28 Apr 2021 03:57:39 +0200
+Subject: [klibc] malloc: Set errno on failure
+Origin: 
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=7f6626d12daa2f1efd9953d1f4ba2065348dc5cd
+
+malloc() is specified to set errno = ENOMEM on failure, so do that.
+
+Signed-off-by: Ben Hutchings 
+---
+ usr/klibc/malloc.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/usr/klibc/malloc.c b/usr/klibc/malloc.c
+index 413b7337..bb57c9f6 100644
+--- a/usr/klibc/malloc.c
 b/usr/klibc/malloc.c
+@@ -8,6 +8,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include "malloc.h"
+ 
+ /* Both the arena list and the free memory list are double linked
+@@ -169,6 +170,7 @@ void *malloc(size_t size)
+ #endif
+ 
+   if (fp == (struct free_arena_header *)MAP_FAILED) {
++  errno = ENOMEM;
+   return NULL;/* Failed to get a block */
+   }
+ 
diff -Nru 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
--- 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
   1970-01-01 01:00:00.0 +0100
+++ 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
   2021-04-30 04:30:16.0 +0200
@@ -0,0 +1,41 @@
+From: Ben Hutchings 
+Date: Wed, 28 Apr 2021 04:03:49 +0200
+Subject: [klibc] malloc: Fail if requested size > PTRDIFF_MAX
+Origin: 
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=a31ae8c508fc8d1bca4f57e9f9f88127572d5202
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-31873
+
+malloc() adds some overhead to the requested size, which may result in
+an integer overflow and subsequent buffer overflow if it is close to
+SIZE_MAX.  It should fail if size is large enough for this to happen.
+
+Further, it's not legal for a C object to be larger than
+PTRDIFF_MAX (half of SIZE_MAX) as pointer arithmetic within it could
+overflow.  So return failure immediately if size is greater than that.
+
+CVE-2021-31873
+
+Signed-off-by: Ben Hutchings 
+---
+ 

Bug#989508: xscreensaver: Disconnecting a video output can cause XScreenSaver to crash and unlock

[Salvatore Bonaccorso]

Source: xscreensaver
Version: 5.45+dfsg1-1
Severity: important
Tags: security upstream fixed-upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi

On oss-security mailinglist an issue with xscreensaver has been
published which seems to be specific to the 4.45 version (and not
affecting earlier versions, nor 6.00):

https://www.openwall.com/lists/oss-security/2021/06/05/1

Qubes OS has patched the issue in 5.45:

https://www.openwall.com/lists/oss-security/2021/06/05/2
https://github.com/QubesOS/qubes-xscreensaver/blob/master/0001-Fix-updating-outputs-info.patch

Regards,
Salvatore

Bug#989507: unblock: collectd/5.12.0-6

[Bernd Zeimetz]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package collectd

[ Reason ]
Fixing
#968950
collectd-dev: missing meta_data.h header file included by plugin.h


[ Impact ]
Building c plugins for collectd is not possible anymore.


[ Tests ]
There are header files being shipped again. No tests for that.


[ Risks ]
Plugins still fail to build. I have nothing to test that
unfortunately. Otherwise - no changes, so no risks.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing


unblock collectd/5.12.0-6


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
diff --git a/debian/changelog b/debian/changelog
index 74daf54..c6a6057 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+collectd (5.12.0-6) unstable; urgency=medium
+
+  * [b4e7861] collectd-dev: Add missing header files again.
+Thanks to Benjamin Drung (Closes: #968950)
+  * [3261aa1] Also create necessary directories
+  * [6c0c6be] Fix target location in dh_install
+
+ -- Bernd Zeimetz   Tue, 01 Jun 2021 17:56:33 +0200
+
 collectd (5.12.0-5) unstable; urgency=medium
 
   * [11ee08b] Disable tokyotyrant.
diff --git a/debian/collectd-dev.install b/debian/collectd-dev.install
index a3dd678..ffd3f5f 100644
--- a/debian/collectd-dev.install
+++ b/debian/collectd-dev.install
@@ -1,4 +1,3 @@
 src/liboconfig/oconfig.h usr/include/collectd/liboconfig
-src/*.h usr/include/collectd/core
-src/daemon/*.h usr/include/collectd/core/daemon
+usr/include/collectd/core
 
diff --git a/debian/rules b/debian/rules
index 5cf4804..ad8880f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -275,17 +275,24 @@ install-indep:
dh_testroot
dh_prep
dh_installdirs -i
-   dh_install -i

+   set -e ;\
+   find src  -path src/libcollectdclient -prune -o -path 
src/liboconfig -prune -o -name '*.h'  -print | while read i; do \
+   d=$$(echo "$${i}" | sed 
's,^src,debian/tmp/usr/include/collectd/core,') ;\
+   mkdir -p $$(echo "$${i}" | sed -e 
's,^src,debian/tmp/usr/include/collectd/core,' -e 's,/[^/]*$$,,') ;\
+   cp "$${i}" "$${d}" ;\
+   done
+
+   dh_install -i
+
# update include path for collectd header files
(   set -e; \
cd $(CURDIR)/debian/collectd-dev/usr/include/collectd/; \
-   for lib in $$(find . -type f -name '*.h'); do \
+   headers=$$(find . -type f -name '*.h'); \
+   for lib in $$headers; do \
libname=$$(basename $$lib); \
fullpath=$$(echo $$lib | sed -r -e 
's,^\./,collectd/,'); \
-   for dir in $$(find . -mindepth 1 -type d); do \
-   sed -r -i -e 
"s,(include\s+)\".*\<$$libname\",\1\"$$fullpath\"," $$dir/*.h; \
-   done; \
+   sed -r -i -e 
"s,(include\s+)\".*\<$$libname\",\1\"$$fullpath\"," $$headers; \
done )
 
 install-arch: build
@@ -299,9 +306,9 @@ install-arch: build
rm -f debian/tmp/usr/lib/collectd/*.la
rm -f debian/tmp/usr/lib/libcollectdclient.la
rm -f debian/tmp/etc/collectd.conf
-   
+
dh_install -a --sourcedir=$(CURDIR)/debian/tmp --fail-missing
-   
+
perl ./debian/bin/gen_plugin_deps.pl

mkdir -p debian/collectd-core/usr/share/lintian/overrides/
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second set of .debs but not in first
-
-rw-r--r--  root/root   /usr/include/collectd/core/utils/avltree/avltree.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/cmds/cmds.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/cmds/flush.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/cmds/getthreshold.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/cmds/getval.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/cmds/listval.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/cmds/parse_option.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/cmds/putnotif.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/cmds/putval.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/common/common.h
-rw-r--r--  root/root   
/usr/include/collectd/core/utils/config_cores/config_cores.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/crc32/crc32.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/curl_stats/curl_stats.h
-rw-r--r--  root/root   /usr/include/collectd/core/utils/db_query/db_query.h
-rw-r--r--  

Bug#989474: lutris: Needs patch for Python 3.9 compatibility

[Stephan Lachnit]

On Fri, 04 Jun 2021 19:47:09 +0200 Frederik Himpe  wrote:
> Package: lutris
> Version: 0.5.8.3-1
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: frede...@frehi.be
>
> Installation of the game Obduction from GOG failed with this message:
> AttributeError("'xml.etree.ElementTree.Element' object has no attribute
> 'getchildren'")
>
> This is fixed by this patch:
> 
https://github.com/lutris/lutris/pull/3430/commits/8ac18d594c72d40308899e775868d49f2e4d98bd



Control: tags -1 pending


Hi Frederik,


thanks for reporting this. I prepared a new upload and requested an 
unblock in #989506.



Regards,

Stephan

Bug#989506: unblock: lutris/0.5.8.3-2

[Stephan Lachnit]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: stephanlach...@debian.org

Please unblock package lutris

[ Reason ]
This fixes an issue appearing with Python 3.9 in a part of the program.
Without this fix, the program will crash when this code is executed due to a
deprecated call.
Python 3.9 is the version shipped in bullseye.

[ Impact ]
The user might experience a crash.

[ Tests ]
No automatic tests cover this part of the code.
The code was not manually tested since I don't have the files required to test
it.

[ Risks ]
The risk of this change is very low.
The package is a end-user package with no reverse dependencies.
The code change is trivial (one line).
The code change follows the recommend new code for the deprecated code
according to the Python documentation [1].

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
Closes #989474

unblock lutris/0.5.8.3-2

Regards,
Stephan

[1]
https://docs.python.org/3.8/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.getchildren
diff -Nru lutris-0.5.8.3/debian/changelog lutris-0.5.8.3/debian/changelog
--- lutris-0.5.8.3/debian/changelog 2021-01-23 12:45:21.0 +0100
+++ lutris-0.5.8.3/debian/changelog 2021-06-05 19:59:53.0 +0200
@@ -1,3 +1,9 @@
+lutris (0.5.8.3-2) unstable; urgency=medium
+
+  * Fix compatibility with Python 3.9 (Closes: #989474)
+
+ -- Stephan Lachnit   Sat, 05 Jun 2021 19:59:53 
+0200
+
 lutris (0.5.8.3-1) unstable; urgency=medium
 
   * New upstream version 0.5.8.3
diff -Nru lutris-0.5.8.3/debian/patches/0001-fix-python3_9.patch 
lutris-0.5.8.3/debian/patches/0001-fix-python3_9.patch
--- lutris-0.5.8.3/debian/patches/0001-fix-python3_9.patch  1970-01-01 
01:00:00.0 +0100
+++ lutris-0.5.8.3/debian/patches/0001-fix-python3_9.patch  2021-06-05 
19:59:53.0 +0200
@@ -0,0 +1,16 @@
+From: 6d6178667269747a 
+Description: Fix Python 3.9 compatibility
+Origin: upstream, 
https://github.com/lutris/lutris/pull/3430/commits/8ac18d594c72d40308899e775868d49f2e4d98bd
+Applied-Upstream: yes
+Bug-Debian: http://bugs.debian.org/989474
+--- a/lutris/util/wine/cabinstall.py
 b/lutris/util/wine/cabinstall.py
+@@ -124,7 +124,7 @@
+ arch = self.get_arch_from_manifest(root)
+ registry_keys = 
root.findall("{urn:schemas-microsoft-com:asm.v3}registryKeys")
+ if registry_keys:
+-for registry_key in registry_keys[0].getchildren():
++for registry_key in list(registry_keys[0]):
+ key = self.process_key(registry_key.attrib["keyName"])
+ out += "[%s]\n" % key
+ for reg_value in 
registry_key.findall("{urn:schemas-microsoft-com:asm.v3}registryValue"):
diff -Nru lutris-0.5.8.3/debian/patches/series 
lutris-0.5.8.3/debian/patches/series
--- lutris-0.5.8.3/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ lutris-0.5.8.3/debian/patches/series2021-06-05 19:59:53.0 
+0200
@@ -0,0 +1 @@
+0001-fix-python3_9.patch

Bug#989505: Multiple security issues (CVE-2021-31870, CVE-2021-31871, CVE-2021-31872, CVE-2021-31873)

[Ben Hutchings]

Source: klibc
Version: 2.0.6-1
Severity: important
Tags: security

klibc version 2.0.9 fixed various security issues.  These are fixed in
unstable but not yet in buster.  They were triaged as no-dsa by the
security team, so they should be fixed in a stable update instead.

Ben.

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#988662: [pre-approval] unblock: apt/2.2.4

[Julian Andres Klode]

On Tue, Jun 01, 2021 at 10:09:44PM +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Julian,
> 
> Sorry it took so long to reply; pre-approvals are regularly awkward.
> 
> On Mon, 17 May 2021 17:07:08 +0200 Julian Andres Klode 
> wrote:
> > Please unblock package apt
> 
> Can you elaborate how severe do you think these issues are? I mean, I
> guess you were in doubt if they qualify for the freeze policy (typically
> if the maintainer doubts, the update doesn't qualify). Or were there
> different reasons why you didn't just upload and ask for a regular unblock?

My understanding is that release team prefers pre-approvals for more
complex uploads in key packages where it's not just one RC bug being
fixed or well "it's how we always do it, except for emergency hotfixes".

> 
> To me it seems:

We also found out that the JSON hooks are being installed by snapd, so
people with that installed might actually see bugs, though we haven't
seen them before (not sure why it works :D).

> * The EOF could be a real thing, but the bug was reported by you and
> only found during testing. Is this a regression or has it long been there?

It's been there forever, but it's not triggered in testing before for
unknown reasons. It's making it harder for me to 

> * TLS handshake is nice to have (for consistency).

It's vital to ensure people get sensible re

> * phased policy isn't a thing in Debian, so not relevant AFAICT

Not at the moment, but the fix doesn't hurt us either, and would allow
us (or people deploying Debian w/ custom repos) to make use of it in the
future.

> 
> I'm tempted to NACK.

It seems we have another more important bug in file quoting reported on
IRC today that can break downloads from repos that used to work if they
contained "special" characters:
https://salsa.debian.org/apt-team/apt/-/merge_requests/175

I've not looked into it much yet.

Would you be tempted to NACK those small bug fixes (they are after all,
except for JSON, all single or two line logic or return value fixes) if
they accompanied the more critical bug fix?


Also not sure if we want all of those 3 commits or just the first
one. I can look into it in detail on Monday.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#986904: blag-fortune/1.5.0-1 [ITA] -- anarchist quotes for fortune

[tous]

‐‐‐ Original Message ‐‐‐
On Friday, May 28, 2021 5:49 PM, Tobias Frost  wrote:

> Hi tous,
>
> Thanks for adopting the package!

Hi toby,

I'm glad you are willing to sponsor the blag-fortune package :)

>
> -   You've put the package on salsa! that's great, but I've been burnt with 
> private namespaces, so
> I discourage them. Would you mind to put it into the debian namespace? 
> (I'd create it for you and
> give you all required rights)

Not at all, please do this.

>
> -   d/copyright has an empty Upstream-Contact field. Please either fill or 
> remove.
> -   As there is no dep3 header on the patch… Please add one and consider 
> upstreaming the patch.
>
> Those are only small things and should be easy to fix. Please confirm 
> that you want to target unstable
> and I can do the upload. (Remove the moreinfo tag when ready)
>
> --
> Cheers,
> tobi
>

I uploaded to https://mentors.debian.net/package/blag-fortune/ the package 
containing the fixes for the issues that you pointed out. I would like to solve 
#900647 but I don't know the properly way solve this bug at moment. Would 
upload to unstable could cause any trouble to fix this bug in the future?

--
Cheers!
tous

Bug#989487: mmdebstrap: produces different tarball when building squashfs image

[Vagrant Cascadian]

On 2021-06-05, Johannes Schauer Marin Rodrigues wrote:
> Quoting Vagrant Cascadian (2021-06-05 03:09:52)
>> When mmdebstrap produces a tarball directly, it sets different tarball
>> options:
>> 
>> # tar2sqfs and genext2fs do not support extended attributes
>> if ($format eq "squashfs") {
>> warning("tar2sqfs does not support extended attributes"
>>   . " from the 'system' namespace");
>> push @taropts, '--xattrs', '--xattrs-exclude=system.*';
>> 
>> But if you're trying to generate a squashfs image with different default
>> compression (e.g. zstd), you have to pipe the mmdebstrap output to
>> tar2sqfs. But in this case, tar is not passed the above options, as it
>> is generating a tarball...
>
> yes. But you can filter the tarball and remove the system.* xattr later:
>
> mmdebstrap ... | mmtarfilter --pax-exclude=SCHILY.xattr.system.* | tar2sqfs 
> ...

This might be worth mentioning in the mmdebstrap manpage! And updating
the mmtarfilter manpage with --pax-exclude too... :)


>> Maybe I'm missing something, but it would be very nice to be able to at least
>> append to options passed to tar2sqfs (presuming it doesn't error when passing
>> two different --compressor arguments), rather than having to extract them
>> from the manpage and/or code, especially given that the tar output changes
>> when you create a regular tarball vs. when mmdebstrap is aware that the
>> eventual destination is a squashfs...
>
> Is that such a common task? Are you running mmdebstrap manually and find
> yourself piping it to tar2sqfs by hand? Do you maybe suggest that the default
> options might need changing? I'm trying to understand your use-case here.

Well, *mostly* just to build zstd squashfs instead of xz (the
performance on various hardware I use is considerable better with zstd
defaults). Being able to set the compression type directly from
mmdebstrap would be nice!

I think I also needed to pipe to tar2sqfs manually in the past to
workaround bugs that I think have since been fixed (e.g. the
--xattrs-exclude patches).

The current default for tar2sqfs is xz, so passing --compressor xz is
redundant.


>> I'm also realizing that the squashfs call doesn't pass --num-jobs=0 to
>> tar2sqfs (similar to when creating a .tar.zst).
>
> Indeed that can be fixed.

Apparently, the default for tar2sqfs is number of cores:

   --num-jobs, -j 
  If libsquashfs was compiled with a thread pool based,
  parallel data compressor, this option can be used to set
  the number of compressor threads. If not set, the default
  is the number of available CPU cores.

So I guess that's not needed at all.


live well,
  vagrant


signature.asc
Description: PGP signature

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

[jim_p]

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

To no surprise, the severity was lowered again. Without a single suggestion or
reason, again.
Imho, that is the usual incompetence most devs here show, so I am not
surprised. It's a real shame however for a distro this size.

The attached file contains all the changes you devs have made in the kernel
configs from 5.10.28 (-6 package) to 5.10.38/.40 (-7 package). It was made with
meld.
~10 kernel parameters have changed and led to this mess, so I assume it would
be trivial for you to find the faulty one. I bet on the ones related to intel,
because my system's cpu and chipset are both made by intel.

p.s.1 I apologize to those few devs that actually helped with the issues I have
reported all those years. You really stand out of this mess and you will always
have my respect.

p.s.2 Above, I meant to write "it (= my psu) is NEWER than 5.10 is on debian".
--- /boot/config-5.10.0-6-amd64
+++ /home/jim/config-5.10.0-7-amd64
@@ -1,6 +1,6 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/x86 5.10.28 Kernel Configuration
+# Linux/x86 5.10.40 Kernel Configuration
 #
 CONFIG_CC_VERSION_TEXT="gcc-10 (Debian 10.2.1-6) 10.2.1 20210110"
 CONFIG_CC_IS_GCC=y
@@ -23,7 +23,7 @@
 # CONFIG_COMPILE_TEST is not set
 CONFIG_LOCALVERSION=""
 # CONFIG_LOCALVERSION_AUTO is not set
-CONFIG_BUILD_SALT="5.10.0-6-amd64"
+CONFIG_BUILD_SALT="5.10.0-7-amd64"
 CONFIG_HAVE_KERNEL_GZIP=y
 CONFIG_HAVE_KERNEL_BZIP2=y
 CONFIG_HAVE_KERNEL_LZMA=y
@@ -2464,8 +2464,8 @@
 CONFIG_ALTERA_STAPL=m
 CONFIG_INTEL_MEI=m
 CONFIG_INTEL_MEI_ME=m
-# CONFIG_INTEL_MEI_TXE is not set
-# CONFIG_INTEL_MEI_HDCP is not set
+CONFIG_INTEL_MEI_TXE=m
+CONFIG_INTEL_MEI_HDCP=m
 CONFIG_VMWARE_VMCI=m
 # CONFIG_GENWQE is not set
 # CONFIG_ECHO is not set
@@ -3939,7 +3939,7 @@
 CONFIG_RMI4_F12=y
 CONFIG_RMI4_F30=y
 CONFIG_RMI4_F34=y
-# CONFIG_RMI4_F3A is not set
+CONFIG_RMI4_F3A=y
 # CONFIG_RMI4_F54 is not set
 CONFIG_RMI4_F55=y
 
@@ -6303,7 +6303,7 @@
 # CONFIG_SND_SOC_IMG is not set
 CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y
 CONFIG_SND_SOC_INTEL_SST=m
-# CONFIG_SND_SOC_INTEL_CATPT is not set
+CONFIG_SND_SOC_INTEL_CATPT=m
 CONFIG_SND_SST_ATOM_HIFI2_PLATFORM=m
 # CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_PCI is not set
 CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI=m
@@ -6323,6 +6323,10 @@
 CONFIG_SND_SOC_ACPI_INTEL_MATCH=m
 CONFIG_SND_SOC_INTEL_MACH=y
 CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES=y
+CONFIG_SND_SOC_INTEL_HASWELL_MACH=m
+CONFIG_SND_SOC_INTEL_BDW_RT5650_MACH=m
+CONFIG_SND_SOC_INTEL_BDW_RT5677_MACH=m
+CONFIG_SND_SOC_INTEL_BROADWELL_MACH=m
 CONFIG_SND_SOC_INTEL_BYTCR_RT5640_MACH=m
 CONFIG_SND_SOC_INTEL_BYTCR_RT5651_MACH=m
 CONFIG_SND_SOC_INTEL_CHT_BSW_RT5672_MACH=m
@@ -6506,6 +6510,8 @@
 CONFIG_SND_SOC_RT5651=m
 CONFIG_SND_SOC_RT5663=m
 CONFIG_SND_SOC_RT5670=m
+CONFIG_SND_SOC_RT5677=m
+CONFIG_SND_SOC_RT5677_SPI=m
 CONFIG_SND_SOC_RT5682=m
 CONFIG_SND_SOC_RT5682_I2C=m
 CONFIG_SND_SOC_RT5682_SDW=m
@@ -8065,8 +8071,6 @@
 CONFIG_AD7923=m
 CONFIG_AD7949=m
 CONFIG_AD799X=m
-CONFIG_AD9467=m
-CONFIG_ADI_AXI_ADC=m
 CONFIG_AXP20X_ADC=m
 CONFIG_AXP288_ADC=m
 CONFIG_CC10001_ADC=m

Bug#988608: RFS: scrollz/2.2.3-2 - advanced ircII-based IRC client

[Mike Markley]

I've also uploaded scrollz_2.2.3-2+deb10u1 to mentors.debian.net and stand
ready to open the necessary bug against release.debian.org justifying the
buster update. It can be found at:

https://mentors.debian.net/debian/pool/main/s/scrollz/scrollz_2.2.3-2+deb10u1.dsc

I would very much appreciate it if someone could assist by uploading it on
my behalf.

Thanks in advance,

-- 
Mike Markley 

Bug#988924: nemo: Nemo crashes if select "Create Folder" in Favorites

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce the issue, but mostly just on the first run
after a reboot of my test VM.

When the issue appears the context menu opens for the favorites,
but the entry to create a new folder is wrongly enabled.
Clicking in that state leads to the error message:

  Error while copying to "Favorites".
  The destination is read-only.
  Cancel

Hitting the Cancel button leads to this message at the terminal:

  (nemo:1242): GLib-CRITICAL **: 13:58:57.717: g_error_free: assertion 'error 
!= NULL' failed
  **
  ERROR:../libnemo-private/nemo-file.c:699:nemo_file_get_internal: assertion 
failed: (location != NULL)
  Bail out! ERROR:../libnemo-private/nemo-file.c:699:nemo_file_get_internal: 
assertion failed: (location != NULL)
  Aborted


I was able to record one run with rr.
There I was able to follow the calls to gtk_action_set_sensitive
for the action NEMO_ACTION_NEW_FOLDER, but unfortunately I
saw just calls to disable it short before.
Therefore its still unclear why the context menu
shows the entries as enabled in the first place.

Kind regards,
Bernhard


(rr) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f7ea92fe537 in __GI_abort () at abort.c:79
#2  0x7f7ea99cbdcc in g_assertion_message (domain=, file=0x5635be1e5d90 
"../libnemo-private/nemo-file.c", line=, func=, 
message=) at ../../../glib/gtestutils.c:2937
#3  0x7f7ea9a292fb in g_assertion_message_expr (domain=domain@entry=0x0, file=file@entry=0x5635be1e5d90 
"../libnemo-private/nemo-file.c", line=line@entry=699, func=func@entry=0x5635be1e7540 
<__func__.103> "nemo_file_get_internal", expr=expr@entry=0x5635be1dab47 "location != 
NULL") at ../../../glib/gtestutils.c:2963
#4  0x5635be176ce1 in nemo_file_get_internal (location=, 
create=create@entry=1) at ../libnemo-private/nemo-file.c:699
#5  0x5635be17770a in nemo_file_get (location=) at 
../libnemo-private/nemo-file.c:751
#6  0x5635be11e26f in new_folder_done (new_folder=, 
success=, data=0x5635bee1c7e0) at ../src/nemo-tree-sidebar.c:913
#7  0x5635be1630e7 in create_job_done (user_data=0x5635beb13cd0) at 
../libnemo-private/nemo-file-operations.c:6290
#8  0x7f7ea9bb8e4f in mainloop_proxy_func (data=0x7f7e8802b070) at 
../../../gio/gioscheduler.c:203
#9  0x7f7ea9a00d6f in g_main_dispatch (context=0x5635be862db0) at 
../../../glib/gmain.c:3325
#10 g_main_context_dispatch (context=0x5635be862db0) at 
../../../glib/gmain.c:4043
#11 0x7f7ea9a01118 in g_main_context_iterate 
(context=context@entry=0x5635be862db0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4119
#12 0x7f7ea9a011cf in g_main_context_iteration 
(context=context@entry=0x5635be862db0, may_block=may_block@entry=1) at 
../../../glib/gmain.c:4184
#13 0x7f7ea9c19545 in g_application_run (application=0x5635be860130, 
argc=1834504324, argc@entry=1, argv=argv@entry=0x7ffc6d5851f8) at 
../../../gio/gapplication.c:2559
#14 0x5635be0bd192 in main (argc=1, argv=0x7ffc6d5851f8) at 
../src/nemo-main.c:104

# single-use Bullseye/testing amd64 qemu VM 2021-06-05

echo "set enable-bracketed-paste off" >> /etc/inputrc; bash

apt update

apt dist-upgrade
apt install systemd-coredump gdb mc cinnamon \
nemo-dbgsym libglib2.0-0-dbgsym libgtk-3-0-dbgsym

apt build-dep nemo

reboot




mkdir /home/benutzer/source/nemo/orig -p
cd/home/benutzer/source/nemo/orig
apt source nemo
cd

mkdir /home/benutzer/source/libgtk-3-0/orig -p
cd/home/benutzer/source/libgtk-3-0/orig
apt source libgtk-3-0
cd



Fehler beim Kopieren nach >>Favoriten<<.
Das Ziel ist schreibgeschützt.
Abbrechen

Error while copying to "Favorites".
The destination is read-only.
Cancel








# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sat 2021-06-05 13:10:11 CEST   1099  1000  1000   6 present   /usr/bin/nemo

# coredumpctl gdb 1099
   PID: 1099 (nemo)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 6 (ABRT)
 Timestamp: Sat 2021-06-05 13:10:11 CEST (5min ago)
  Command Line: nemo /home/benutzer
Executable: /usr/bin/nemo
 Control Group: /user.slice/user-1000.slice/session-2.scope
  Unit: session-2.scope
 Slice: user-1000.slice
   Session: 2
 Owner UID: 1000 (benutzer)
   Boot ID: fa231400d36b4b479aa5f6395cdd6522
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.nemo.1000.fa231400d36b4b479aa5f6395cdd6522.1099.162289141100.zst
   Message: Process 1099 (nemo) of user 1000 dumped core.

Stack trace of thread 1099:
#0  0x7f839fb7ece1 raise (libc.so.6 + 0x3bce1)
#1  0x7f839fb68537 abort (libc.so.6 + 0x25537)
#2  0x7f83a0233dcc n/a (libglib-2.0.so.0 + 0x1cdcc)
#3  0x7f83a02912fb g_assertion_message_expr 
(libglib-2.0.so.0 + 0x7a2fb)
#4  

Bug#989143: initramfs-tools: doesn’t actually compress with zstd

[Christoph Anton Mitterer]

On Sat, 2021-06-05 at 16:59 +0200, Ben Hutchings wrote:
> You mean, can the main initramfs be uncompressed?  I'm not sure
> whether
> the kernel supports that.  It's certainly not an option in initramfs-
> tools at the moment.

Forget it... I'm stupid ^^ ... it's just the microcode, that's
uncompressed, while the rest is.


Thanks,
Chris.

Bug#989487: mmdebstrap: produces different tarball when building squashfs image

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Vagrant Cascadian (2021-06-05 03:09:52)
> When mmdebstrap produces a tarball directly, it sets different tarball
> options:
> 
> # tar2sqfs and genext2fs do not support extended attributes
> if ($format eq "squashfs") {
> warning("tar2sqfs does not support extended attributes"
>   . " from the 'system' namespace");
> push @taropts, '--xattrs', '--xattrs-exclude=system.*';
> 
> But if you're trying to generate a squashfs image with different default
> compression (e.g. zstd), you have to pipe the mmdebstrap output to
> tar2sqfs. But in this case, tar is not passed the above options, as it
> is generating a tarball...

yes. But you can filter the tarball and remove the system.* xattr later:

mmdebstrap ... | mmtarfilter --pax-exclude=SCHILY.xattr.system.* | tar2sqfs ...

> Related, the default tar2sqfs options described in the man page:
> 
>By default, mmdebstrap runs tar2sqfs with "--no-skip --exportable
>--compressor xz --block-size 1048576". To choose a different set of
>options, pipe the output of mmdebstrap into tar2sqfs manually.
> 
> Are somewhat inconsistent with the ones used in the code:
> 
> if ($format eq 'squashfs') {
>   push @argv, 'tar2sqfs',
>   '--quiet', '--no-skip', '--force',
>   '--exportable',
>   '--compressor', 'xz',
>   '--block-size', '1048576',

Ah whoops, thanks!

> Maybe I'm missing something, but it would be very nice to be able to at least
> append to options passed to tar2sqfs (presuming it doesn't error when passing
> two different --compressor arguments), rather than having to extract them
> from the manpage and/or code, especially given that the tar output changes
> when you create a regular tarball vs. when mmdebstrap is aware that the
> eventual destination is a squashfs...

Is that such a common task? Are you running mmdebstrap manually and find
yourself piping it to tar2sqfs by hand? Do you maybe suggest that the default
options might need changing? I'm trying to understand your use-case here.

> I'm also realizing that the squashfs call doesn't pass --num-jobs=0 to
> tar2sqfs (similar to when creating a .tar.zst).

Indeed that can be fixed.

> Apologies if I'm comingling too many seemingly related issues into a
> single bug report.

Nah, it's fine. There is also overhead to each bug report and for tiny issues,
it's okay to bundle them up. :)

> As always, many thanks for mmdebstrap!

You're welcome!

cheers, josch

signature.asc
Description: signature

Bug#989504: unblock: orthanc/1.9.2+really1.9.1+dfsg-1

[Étienne Mollier]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: etienne.moll...@mailoo.org, s.jodo...@orthanc-labs.com, 
debian-med-packag...@lists.alioth.debian.org

Please unblock package orthanc

[ Reason ]
The version 1.9.2+dfsg-1 has been uploaded to unstable by mistake
while it should have targeted experimental.

[ Impact ]
Some of the orthanc framework reverse dependencies are statically
linking against the version of orthanc in testing and are missing
a Built-Using field (see bugs #989126, #989127, and #989128).
Uploading them now would make them link against the wrong
version, and leaving the situation as is will provoke their
autoremoval.

[ Tests ]
I have run the build time test suite.

[ Risks ]
This is mostly revert of the unstable version in the state it is
in testing.  The only risk I could see, is that a part of the
code could try to derive the framework version from the package
version without taking the +really marker into account properly.

[ Checklist ]
  [*] all changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in testing

unblock orthanc/1.9.2+really1.9.1+dfsg-1

Have a nice day,  :)
Étienne.
diff -Nru orthanc-1.9.1+dfsg/debian/changelog 
orthanc-1.9.2+really1.9.1+dfsg/debian/changelog
--- orthanc-1.9.1+dfsg/debian/changelog 2021-02-25 20:15:55.0 +0100
+++ orthanc-1.9.2+really1.9.1+dfsg/debian/changelog 2021-06-04 
22:03:18.0 +0200
@@ -1,3 +1,18 @@
+orthanc (1.9.2+really1.9.1+dfsg-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert orthanc to package version 1.9.1+dfsg-1 since 1.9.2+dfsg-1 was
+actually not intended for bullseye
+  * d/rules: adjust UPSTREAM_VERSION filter to handle +really versions properly
+
+ -- Étienne Mollier   Fri, 04 Jun 2021 22:03:18 
+0200
+
+orthanc (1.9.2+dfsg-1) unstable; urgency=medium
+
+  * New upstream version
+
+ -- Sebastien Jodogne   Thu, 22 Apr 2021 15:39:54 +0200
+
 orthanc (1.9.1+dfsg-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru orthanc-1.9.1+dfsg/debian/rules 
orthanc-1.9.2+really1.9.1+dfsg/debian/rules
--- orthanc-1.9.1+dfsg/debian/rules 2021-02-25 20:15:55.0 +0100
+++ orthanc-1.9.2+really1.9.1+dfsg/debian/rules 2021-06-04 22:03:18.0 
+0200
@@ -6,7 +6,10 @@
 export DOC_DIR := $(DESTDIR)/usr/share/doc/orthanc
 
 export FRAMEWORK_VERSION := 1
-export UPSTREAM_VERSION := $(shell echo "$(DEB_VERSION)" | cut -d '+' -f 1)
+export UPSTREAM_VERSION := $(shell \
+   echo "$(DEB_VERSION)" \
+   | sed 's/\(.*+really\)\?\([^+]\+\)\(+dfsg\)\?-.*/\2/' \
+)
 
 export BUILDARCH := $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all

Bug#961183: metis: providing a 64-bit build

[Drew Parsons]

Package: metis
Followup-For: Bug #961183
Control: affects -1 libscotchmetis-dev

Also scotch-metis will need to be updated to match.

Bug#961183: metis: providing a 64-bit build

[Drew Parsons]

Package: metis
Followup-For: Bug #961183
Control: affects -1 libdeal.ii-dev libparmetis-dev src:suitesparse src:deal.ii 
src:freefem++ src:gmsh src:netgen src:parmetis src:superlu-dist src:syrthes

Here is the list of affected packages identified by
apt-rdepends -r libmetis-dev libmetis5

libmetis-dev
  Reverse Depends: libdeal.ii-dev (9.2.0-3+b2)
  Reverse Depends: libparmetis-dev (4.0.3-5+b1)

libmetis5
  Reverse Depends: libcholmod3 (>= 1:5.8.1+dfsg-2)
  Reverse Depends: libdeal.ii-9.2.0 (>= 9.2.0-3+b2)
  Reverse Depends: libfreefem++ (>= 3.61.1+dfsg1-6)
  Reverse Depends: libgmsh4 (>= 4.7.1+ds1-5)
  Reverse Depends: libmetis-dev (= 5.1.0.dfsg-7)
  Reverse Depends: libnglib-6.2 (>= 6.2.2006+really6.2.1905+dfsg-2.1)
  Reverse Depends: libparmetis4.0 (4.0.3-5+b1)
  Reverse Depends: libsuperlu-dist7 (>= 7.0.0+dfsg1-1exp2)
  Reverse Depends: metis (= 5.1.0.dfsg-7)
  Reverse Depends: parmetis-test (4.0.3-5+b1)
  Reverse Depends: pyfr (1.5.0-3)
  Reverse Depends: syrthes-tools (>= 4.3.5+20200129-dfsg1-1+b1)


I'm applying affects tags to this bug to let the maintainers know what
we're planning.

Drew

Bug#989503: xdg-desktop-portal-wlr: Please upgrade version 0.4.0

[Angel Abad]

Package: xdg-desktop-portal-wlr
Version: 0.1.0-3
Severity: important

Dear Maintainer,

Please upgrade package, with current debian version firefox screen sharing
doesn't work.

I tested 0.4.0 upstream version and it works fine on debian unstable with sway
and firefox out of the box.

Thanks a lot!


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

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

Versions of packages xdg-desktop-portal-wlr depends on:
ii  libc6   2.31-12
ii  libpipewire-0.3-0   0.3.19-4
ii  libsystemd0 247.3-5
ii  libwayland-client0  1.19.0-2
ii  xdg-desktop-portal  1.8.1-1

xdg-desktop-portal-wlr recommends no packages.

xdg-desktop-portal-wlr suggests no packages.

Bug#961183: metis: providing a 64-bit build

[Drew Parsons]

Doing it through a formal transition request is sensible. There's a 
backlog of numerical library upgrades (some still in the NEW queue) 
waiting for bullseye to get released. Perhaps we can run this transition 
at the same time as the others, process them all as a bulk transition.


We'll set it up in experimental first, of course.

I'll prepare the list of affected packages.

Drew



On 2021-06-05 17:07, Anton Gladky wrote:

Well, theoretically we can do it. But we need to do some kind
of a transition for all dependencies.

Regards

Anton

Am Sa., 5. Juni 2021 um 13:36 Uhr schrieb Drew Parsons
:


...
I think the best solution is to "break" the builds of client
applications by moving the standard header from /usr/include/metis.h
to /usr/include/metis/metis.h.  Then client applications will need
to
be updated to add -I/usr/include/metis when using the standard
build.

Bug#989486: RFS: python-click-log/0.3.2-1 -- Logging integration for Click - Python 3.x

[Nilesh Patra]

On 6/5/21 8:04 PM, Emmanuel Arias wrote:
> Hi,
> 
> I'm not DD, but I send you some review, to gain time:
> 
> * d/changelog says: `Bump debhelper from old 10 to 12.` but actuall> 
> debhelper-compat version is 13.
> * Please use UNRELEASED instead of unstable, that can be confused.

Fixed

> * What about enable salsa-ci?

Enabled

> * What about adding an autopkgtest?

The test is running during build time.[1] I don't think running the same thing 
as autopkgtest does a very significant improvement.

@Fabrice, more review:

* The pristine tar contained .tar.gz.*, it should instead contain 
.orig.tar.gz for origtargz
both for the sake of consistency and for origtargz to run fine
* We are in freeze time, and a new version upload unless absolutely necessary 
isn't appropriate[2]. This package does not seem
to have any (RC) bug or affecting any package that a version bump would be 
desired.

Hence, this should be uploaded after bullseye release. Feel free to ping me 
then, and I'll happily sponsor. Also, please take a look at my commits in salsa.

Thanks a lot for your work!

[1]: 
https://salsa.debian.org/python-team/packages/python-click-log/-/blob/master/debian/rules#L13
[2]: https://release.debian.org/testing/freeze_policy.html

Nilesh



signature.asc
Description: OpenPGP digital signature

Bug#961183: metis: providing a 64-bit build

[Anton Gladky]

Well, theoretically we can do it. But we need to do some kind
of a transition for all dependencies.

Regards

Anton


Am Sa., 5. Juni 2021 um 13:36 Uhr schrieb Drew Parsons :

> ...
> I think the best solution is to "break" the builds of client
> applications by moving the standard header from /usr/include/metis.h
> to /usr/include/metis/metis.h.  Then client applications will need to
> be updated to add -I/usr/include/metis when using the standard build.
>

Bug#989496: apt-listchanges: Error output if choosing to not continue after reading list of changes

[Tia]

Package: apt-listchanges
Version: 3.24
Severity: normal
X-Debbugs-Cc: tia3...@protonmail.com

Dear Maintainer,

After reading list of changes decided not to upgrade, so chose 'n' when
asked. As such apt-listchanges aborted as it should, only issue is that
after that it would output error message

Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
apt-listchanges: Do you want to continue? [Y/n] n
apt-listchanges: Aborting
E: Sub-process /usr/bin/apt-listchanges --apt || test $? -lt 10 returned an 
error code (1)
E: Failure running script /usr/bin/apt-listchanges --apt || test $? -lt 10

There is no issues in functionality after that if run again.


-- Package-specific info:
==> /etc/apt/listchanges.conf <==
[apt]
frontend=pager
which=both
email_address=root
email_format=text
confirm=true
headers=true
reverse=false
save_seen=/var/lib/apt/listchanges.db

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

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

Versions of packages apt-listchanges depends on:
ii  apt2.2.3
ii  debconf [debconf-2.0]  1.5.75
ii  python33.9.2-3
ii  python3-apt2.2.0
ii  python3-debconf1.5.75
ii  sensible-utils 0.0.14
ii  ucf3.0043

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-5
ii  firefox-esr [www-browser]  78.10.0esr-1
ii  konqueror [www-browser]4:20.12.0-4
ii  konsole [x-terminal-emulator]  4:20.12.3-1
ii  python3-gi 3.38.0-2
ii  termit [x-terminal-emulator]   3.1-1
ii  xterm [x-terminal-emulator]366-1

-- debconf information:
  apt-listchanges/save-seen: true
  apt-listchanges/no-network: false
  apt-listchanges/frontend: pager
  apt-listchanges/headers: false
  apt-listchanges/reverse: false
  apt-listchanges/confirm: false
  apt-listchanges/email-address: root
  apt-listchanges/email-format: text
  apt-listchanges/which: news

Bug#989143: initramfs-tools: doesn’t actually compress with zstd

[Ben Hutchings]

On Sat, 2021-06-05 at 16:49 +0200, Christoph Anton Mitterer wrote:
> On Sat, 2021-06-05 at 16:23 +0200, Ben Hutchings wrote:
> > You have intel-microcode installed, which prepends an uncompressed
> > initramfs.  Not a bug.
> 
> Couldn't it then just skip the compression altogether?

You mean, can the main initramfs be uncompressed?  I'm not sure whether
the kernel supports that.  It's certainly not an option in initramfs-
tools at the moment.

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'


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

Bug#989143: initramfs-tools: doesn’t actually compress with zstd

[Christoph Anton Mitterer]

On Sat, 2021-06-05 at 16:23 +0200, Ben Hutchings wrote:
> You have intel-microcode installed, which prepends an uncompressed
> initramfs.  Not a bug.

Couldn't it then just skip the compression altogether?

Cheers,
Chris.

Bug#989421: unblock: libgcrypt20/1.8.7-6

[Cyril Brulebois]

Hi,

Sebastian Ramacher  (2021-06-05):
> On 2021-06-03 13:23:02 +0200, Andreas Metzler wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: libgcryp...@packages.debian.org
> > 
> > Please unblock package libgcrypt20.
> > 
> > Compared to 1.8.7-3 this pulls a 4 commits from 1.8.8, including
> > 30_10-cipher-Fix-ElGamal-encryption-for-other-implementati.patch
> > (CVE-2021-33560) which fixes weak ElGamal encryption with keys *not*
> > generated by libgcrypt/gnupg. It does not warrant a DSA (already
> > doublechecked with debian-security) but should still be fixed. I will
> > also prepare an upload for buster.
> 
> ACK. Cyril, could you please (N)ACK for d-i?

I considered it yesterday but given the (now fixed) regression, I
thought it might make sense to have age a bit in unstable. Please wait
until src:debian-installer is built on all architectures (the upload
should happen today).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#989425: unblock: libpam-chroot/0.9-5

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-06-03 13:53:17 +0200, Javier Fernández-Sanguino Peña wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package libpam-chroot
> 
> [ Reason ]
> This version includes fixes to build properly the package including:
> - Installing the PAM module in the correct location (#980047)
> - Supporting cross bulding of source (949080)
> - Document that libpam-chroot is not recommended to be used with OpenSSH as it
>   is difficult to setup and there are better alternatives (527564)
> 
> [ Impact ]
> Users cannot use the package as it is as the pam_chroot library is not
> installed in the correct location.
> 
> Users trying to follow the instructions in the README file to setup OpenSSH
> will end up with a non-working setup.
> 
> If the unblock is not granted this is not, however, a major issue as not many
> users use this package and chroot functionalities are, in general, not that
> much used anymore as people have in general now moved to containers.
> 
> [ Tests ]
> Tested locally in the developer's machine.
> 
> [ Risks ]
> Very low risk changes introduced in the package.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> 
> unblock libpam-chroot/0.9-5

ACK, please moreve the moreinfo tag once the version is available in
unstable.

Cheers

> 
> 
> Thank you for your support,
> 
> Javier

> diff -u libpam-chroot-0.9/Makefile libpam-chroot-0.9/Makefile
> --- libpam-chroot-0.9/Makefile
> +++ libpam-chroot-0.9/Makefile
> @@ -5,6 +5,8 @@
>  CPPFLAGS=-I.
>  LDFLAGS=-shared
>  DESTDIR=/
> +LIBDIR=$(DESTDIR)/lib/security
> +INSTALL?=install
>  
>  OUT=pam_chroot.so
>  CONF=chroot.conf
> @@ -20,3 +22,3 @@
>  install:
> - install -s -o0 -g0 -m755 $(OUT) $(DESTDIR)/lib/security
> + $(INSTALL) -s -o0 -g0 -m755 $(OUT) $(LIBDIR)
>   install -m640 $(CONF) $(DESTDIR)/etc/security
> diff -u libpam-chroot-0.9/debian/README.Debian 
> libpam-chroot-0.9/debian/README.Debian
> --- libpam-chroot-0.9/debian/README.Debian
> +++ libpam-chroot-0.9/debian/README.Debian
> @@ -73,15 +73,22 @@
>  Setting up OpenSSH with libpam-chroot
>  -
>  
> +!!! WARNING 
> !!
>  NOTE: OpenSSH supports, since the 4.9 release, the definition of
>  chrooted enviroments. For more information see the 'ChrootDirectory'
> -directive in sshd_config (5).
> +directive in sshd_config (5). 
> +
> +Setting up OpenSSH libpam-chroot is *not* recommended and most likely will 
> not
> +work. The following information is provided for those users that want to 
> tinker
> +with pam-chroot and SSH.
> +
> + WARNING 
> !!
>  
>  
>  Many systems want to setup a restricted remote access to a system in
>  which users are confined to their user directories, but are unable to
> -"see" the whole system. If you want to develop this using OpenSSH you
> -will need to:
> +"see" the whole system. If you want to develop this using OpenSSH 
> +and libpam-chroot you will need to:
>  
>  0) Setup a chroot environment for your users. Make sure that
>  environment includes the standard tools they will need (like their
> @@ -147,7 +154,29 @@
>  pam-chroot at all.
>  
> +4) In order for chroots to work with newer OpenSSH versions the chroot
> +directory of a user needs to include both the /proc filesystem and
> +the /dev/pts
> +
> +- If /proc is not mounted in the chroot, SSH access will be interrupted
> +  with the message:
> +
> +  Connection reset by peer
> +  Connection to  closed.
> +
> +  To mount /proc do the following:
> +  mount -t proc /proc /proc
> +
> +- If /dev/pts is not mounted, the SSH login will freeze after
> +  authentication with the message:
> +
> + PTY allocation request failed on channel 0
> +
> +  To mount /dev do the following:
> +  mount --rbind /dev /dev
> +
> +
>   --
>   Javier Fernandez-Sanguino 
> - Wed, 27 Oct 2010 02:01:26 +0200
> + Thu, 03 Jun 2021 13:26:58 +0200
>  
>  
> diff -u libpam-chroot-0.9/debian/changelog libpam-chroot-0.9/debian/changelog
> --- libpam-chroot-0.9/debian/changelog
> +++ libpam-chroot-0.9/debian/changelog
> @@ -1,3 +1,19 @@
> +libpam-chroot (0.9-5) unstable; urgency=high
> +
> +  * debian/rules: Install the PAM module in the right location 
> +(Closes: #980047)
> +  * Fix FTCBFS: (Closes: #949080, #437385)
> ++ Let dh_auto_build pass cross tools to make.
> ++ Make install substitutable.
> ++ Pass a non-stripping install to make install.
> +Thanks Helmut Grohne for the patch
> +  * debian/README.Debian: discourage users from using this module with
> +OpenSSH as this feature is available already in the daemon (see option
> +

Bug#986904: blag-fortune/1.5.0-1 [ITA] -- anarchist quotes for fortune

[Tobias Frost]

On Sat, Jun 05, 2021 at 01:45:38PM +, tous wrote:
> 
> ‐‐‐ Original Message ‐‐‐
> On Friday, May 28, 2021 5:49 PM, Tobias Frost  wrote:
> 
> > Hi tous,
> >
> > Thanks for adopting the package!
> 
> Hi toby,
> 
> I'm glad you are willing to sponsor the blag-fortune package :)
> 
> >
> > -   You've put the package on salsa! that's great, but I've been burnt with 
> > private namespaces, so
> > I discourage them. Would you mind to put it into the debian namespace? 
> > (I'd create it for you and
> > give you all required rights)
> 
> Not at all, please do this.

Done. Let me know if there are issues with access right or so and please update 
d/control accordingly.

> >
> > -   d/copyright has an empty Upstream-Contact field. Please either fill or 
> > remove.
> > -   As there is no dep3 header on the patch… Please add one and consider 
> > upstreaming the patch.
> >
> > Those are only small things and should be easy to fix. Please confirm 
> > that you want to target unstable
> > and I can do the upload. (Remove the moreinfo tag when ready)
> >
> > --
> > Cheers,
> > tobi
> >
> 
> I uploaded to https://mentors.debian.net/package/blag-fortune/ the package
> containing the fixes for the issues that you pointed out. I would like to
> solve #900647 but I don't know the properly way solve this bug at moment.
> Would upload to unstable could cause any trouble to fix this bug in the
> future?

Uploading to unstable during the freeze can cause troubles _if_ the version
currently in testing becomes suddendly RC-buggy… In this case you will need to
revert this upload and provide an minimal, targeted fix for the hypthetical
problem in testing. That is usually a bit nasty and because of that an upload
to unstable should be avoided.
Minimal means that no other changes beside the fix are allowed.

#900647: The bug asks for an rename of the package; that requires a travel
through the NEW queue. It does not matter whether it is cleared using
experimental or using unstable. Now, if you would need to react quickly because
of that hypothical "became RC buggy" scenario, and had already cleared NEW, you
would have to revert the change and because of that _possibly_* need another
trip through NEW.

Whether you upload to experimental or unstable will not impact your ability
to fix that bug at all.

TL;DR: If you want to play it safe, go experimental. Otherwise there is a slim
change that bullseye will be released without your package; if you say, danger
is my second name, let me know and I'll accept your wish for unstable.

* this is quite a interesting corner case: reintroducing an old binary package…
I assume that this requires a NEW cleaing; but as I never saw this RIL, can be
wrong here.

Bug#989421: unblock: libgcrypt20/1.8.7-6

[Sebastian Ramacher]

Control: tgs -1 confirmed d-i

On 2021-06-03 13:23:02 +0200, Andreas Metzler wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: libgcryp...@packages.debian.org
> 
> Please unblock package libgcrypt20.
> 
> Compared to 1.8.7-3 this pulls a 4 commits from 1.8.8, including
> 30_10-cipher-Fix-ElGamal-encryption-for-other-implementati.patch
> (CVE-2021-33560) which fixes weak ElGamal encryption with keys *not*
> generated by libgcrypt/gnupg. It does not warrant a DSA (already
> doublechecked with debian-security) but should still be fixed. I will
> also prepare an upload for buster.

ACK. Cyril, could you please (N)ACK for d-i?

Cheers

> 
> unblock libgcrypt20/1.8.7-6
> 
> cu Andreas
> -- 
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'

> diff -Nru libgcrypt20-1.8.7/debian/changelog 
> libgcrypt20-1.8.7/debian/changelog
> --- libgcrypt20-1.8.7/debian/changelog2021-02-14 15:27:13.0 
> +0100
> +++ libgcrypt20-1.8.7/debian/changelog2021-05-27 18:07:38.0 
> +0200
> @@ -1,3 +1,26 @@
> +libgcrypt20 (1.8.7-6) unstable; urgency=medium
> +
> +  * Update from LIBGCRYPT-1.8-BRANCH:
> ++ 30_10-cipher-Fix-ElGamal-encryption-for-other-implementati.patch
> +
> + -- Andreas Metzler   Thu, 27 May 2021 18:07:38 +0200
> +
> +libgcrypt20 (1.8.7-5) unstable; urgency=medium
> +
> +  * Pull fix for ECC decyryption regression (caused by
> +30_08-ecc-Check-the-input-length-for-the-point.patch) from
> +LIBGCRYPT-1.8-BRANCH. Closes: #987956
> +
> + -- Andreas Metzler   Thu, 06 May 2021 18:06:14 +0200
> +
> +libgcrypt20 (1.8.7-4) unstable; urgency=medium
> +
> +  * Update from LIBGCRYPT-1.8-BRANCH:
> ++ 30_07-Fix-previous-commit.patch
> ++ 30_08-ecc-Check-the-input-length-for-the-point.patch
> +
> + -- Andreas Metzler   Sun, 02 May 2021 13:58:47 +0200
> +
>  libgcrypt20 (1.8.7-3) unstable; urgency=medium
>  
>* Update from LIBGCRYPT-1.8-BRANCH:
> diff -Nru libgcrypt20-1.8.7/debian/patches/30_07-Fix-previous-commit.patch 
> libgcrypt20-1.8.7/debian/patches/30_07-Fix-previous-commit.patch
> --- libgcrypt20-1.8.7/debian/patches/30_07-Fix-previous-commit.patch  
> 1970-01-01 01:00:00.0 +0100
> +++ libgcrypt20-1.8.7/debian/patches/30_07-Fix-previous-commit.patch  
> 2021-05-02 13:52:17.0 +0200
> @@ -0,0 +1,41 @@
> +From a5799f1618aaf1bbb52e7e121275228dd4a3ac8b Mon Sep 17 00:00:00 2001
> +From: Werner Koch 
> +Date: Sun, 14 Feb 2021 18:54:40 +0100
> +Subject: [PATCH 7/8] Fix previous commit
> +
> +* src/global.c (_gcry_get_config): Append the Nul only in the !what
> +case.
> +--
> +
> +Fixes-commit: 3f42f727a0699f7274a99ea39def7f9b4c3b0c1e
> +Actually this was my fault - I stripped off the test which Jussi did in
> +his original fix on master.  And did not run make check.
> +
> +Signed-off-by: Werner Koch 
> +---
> + src/global.c | 9 +++--
> + 1 file changed, 7 insertions(+), 2 deletions(-)
> +
> +diff --git a/src/global.c b/src/global.c
> +index 7d634095..95daedac 100644
> +--- a/src/global.c
>  b/src/global.c
> +@@ -419,8 +419,13 @@ _gcry_get_config (int mode, const char *what)
> + 
> +   print_config (what, fp);
> + 
> +-  /* Make sure the output is null terminated. */
> +-  gpgrt_fwrite ("", 1, 1, fp);
> ++  /* Make sure the output is null terminated if no specific item was
> ++   * requested.  This is needed because tests/version.c expects that
> ++   * the function fails with the !data case below.  For the specific
> ++   * test an extra nul is not required because we always have a LF
> ++   * which is then replaced right at the end of this function.  */
> ++  if (!what)
> ++gpgrt_fwrite ("", 1, 1, fp);
> + 
> +   if (gpgrt_ferror (fp))
> + {
> +-- 
> +2.30.2
> +
> diff -Nru 
> libgcrypt20-1.8.7/debian/patches/30_08-ecc-Check-the-input-length-for-the-point.patch
>  
> libgcrypt20-1.8.7/debian/patches/30_08-ecc-Check-the-input-length-for-the-point.patch
> --- 
> libgcrypt20-1.8.7/debian/patches/30_08-ecc-Check-the-input-length-for-the-point.patch
>  1970-01-01 01:00:00.0 +0100
> +++ 
> libgcrypt20-1.8.7/debian/patches/30_08-ecc-Check-the-input-length-for-the-point.patch
>  2021-05-02 13:52:32.0 +0200
> @@ -0,0 +1,80 @@
> +From 3f48e3ea37adf84aae7335b8367012d70bb3f132 Mon Sep 17 00:00:00 2001
> +From: NIIBE Yutaka 
> +Date: Tue, 27 Apr 2021 17:24:16 +0900
> +Subject: [PATCH 8/8] ecc: Check the input length for the point.
> +
> +* cipher/ecc-misc.c (_gcry_ecc_mont_decodepoint): Check the length
> +of valid point representation.
> +
> +--
> +
> +Backport the commit of master:
> +
> + 060c378c050e7ec6206358c681a313d6e1967dcf
> +
> +In the use case of GnuPG, ECDH decryption for anonymous recipient may
> +try to decrypt with different curves.  When the input data of
> +ephemeral key does not match one of the private key, it should return
> 

Bug#989495: linux-image-5.10.0-7-amd64: Journal reports multiple Key file does not have key "..." in group “Controller” for bluetooth

[Tia]

Package: src:linux
Version: 5.10.40-1
Severity: normal
X-Debbugs-Cc: tia3...@protonmail.com

Dear Maintainer,

Since installing Bullseye journal would write these warning messages on every 
startup:

lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRPageScanType” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRPageScanInterval” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRPageScanWindow” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRInquiryScanType” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRInquiryScanInterval” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRInquiryScanWindow” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRLinkSupervisionTimeout” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRPageTimeout” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRMinSniffInterval” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “BRMaxSniffInterval” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEMinAdvertisementInterval” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEMaxAdvertisementInterval” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEMultiAdvertisementRotationInterval” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanIntervalAutoConnect” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanWindowAutoConnect” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanIntervalSuspend” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanWindowSuspend” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanIntervalDiscovery” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanWindowDiscovery” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanIntervalAdvMonitor” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanWindowAdvMonitor” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanIntervalConnect” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEScanWindowConnect” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEMinConnectionInterval” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEMaxConnectionInterval” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEConnectionLatency” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEConnectionSupervisionTimeout” in group “Controller”
lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key file 
does not have key “LEAutoconnecttimeout” in group “Controller”

Bluez package looks for defaults for those values in kernel, and they appear to 
be missing.

For bluetooth to work I need to have firmware-atheros, so ath9k driver is being 
used.

Such messages weren't appearing in Buster.


-- Package-specific info:
** Version:
Linux version 5.10.0-7-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.40-1 (2021-05-28)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-7-amd64 root=/dev/mapper/HP2000--vg-root ro quiet 
splash

** Not tainted

** Kernel log:
[ 6283.606376] ath: country maps to regdmn code: 0x37
[ 6283.606378] ath: Country alpha2 being used: HR
[ 6283.606379] ath: Regpair used: 

Bug#989502: stretch-pu: package ieee-data/20160613.1+deb9u1+nmu1

[Samuel Henrique]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
X-Debbugs-Cc: samuel...@debian.org
Severity: normal

[ Reason ]
I'd like to perform an oldstable NMU upload in order to fix #908623 and #932711:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908623
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932711

The ieee-data package ships a script (update-ieee-data) which queries
ieee.org to download the most recent dataset and save it to
/var/lib/ieee-data/

This script broke for stretch and earlier releases at the end of 2018
and I'd like to fix it by pointing the script to the correct URL
(which is the one used on buster and bullseye).

[ Impact ]
This is the only functionality of the script, so it will stay fully broken.

[ Tests ]
Manually tested and confirmed that the correct data got saved to
/var/lib/ieee-data/

[ Risks ]
Since the script is not working anymore, the only risk involved is
related to getting the wrong data and corrupting the existing contents
of /var/lib/ieee-data/. The probability of this happening is lowered
due to the script changing to an URL from the same domain, connecting
through HTTPS, and considering this is the same URL used for buster
and bullseye.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Points the script to the new URLs.

[ Other info ]
The maintainer acked an NMU on #932711
I'm also trying to reach out to Luciano so I can help on the
maintenance of the package and update its dataset for bullseye.

-- 
Samuel Henrique 


ieee-data_20160613.1+deb9u1+nmu1.debdiff
Description: Binary data

Bug#989458: RFS: dte/1.10-1 -- small and easy to use console text editor

[Tobias Frost]

On Fri, 4 Jun 2021 11:16:23 +0200 Miroslav Kratochvil  wrote:
> Package: sponsorship-requests
 
>  dte (1.10-1) unstable; urgency=medium
>  .
>    * New upstream version 1.10
>    * Bump debhelper compat and standards version
>    * Update license file


This is not a good time for a new upstream version… We're in the freeze, you
know… Do you want to target experimental in the mean time?

-- 
tobi

Bug#987545: pam-u2f: diff for NMU version 1.1.0-1.1

[Salvatore Bonaccorso]

Control: tags 987545 + pending


Dear maintainer,

I've prepared an NMU for pam-u2f (versioned as 1.1.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru pam-u2f-1.1.0/debian/changelog pam-u2f-1.1.0/debian/changelog
--- pam-u2f-1.1.0/debian/changelog	2020-11-02 13:49:23.0 +0100
+++ pam-u2f-1.1.0/debian/changelog	2021-06-05 15:04:24.0 +0200
@@ -1,3 +1,10 @@
+pam-u2f (1.1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Handle converse() returning NULL (CVE-2021-31924) (Closes: #987545)
+
+ -- Salvatore Bonaccorso   Sat, 05 Jun 2021 15:04:24 +0200
+
 pam-u2f (1.1.0-1) unstable; urgency=low
 
   * New upstream version 1.1.0 (2020-09-17)
diff -Nru pam-u2f-1.1.0/debian/patches/Handle-converse-returning-NULL.patch pam-u2f-1.1.0/debian/patches/Handle-converse-returning-NULL.patch
--- pam-u2f-1.1.0/debian/patches/Handle-converse-returning-NULL.patch	1970-01-01 01:00:00.0 +0100
+++ pam-u2f-1.1.0/debian/patches/Handle-converse-returning-NULL.patch	2021-06-05 15:04:24.0 +0200
@@ -0,0 +1,37 @@
+From: pedro martelletto 
+Date: Wed, 19 May 2021 09:08:44 +0200
+Subject: Handle converse() returning NULL
+Origin: https://github.com/Yubico/pam-u2f/commit/6059b057dd9b6d0164fc16f9422c0d728f902bb5
+Bug: https://github.com/Yubico/pam-u2f/issues/175
+Bug-Debian: https://bugs.debian.org/987545
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-31924
+
+If a PIN is required and converse() returns NULL, abort the
+authentication flow instead of reverting to FIDO2 without PIN.
+Fixes #175.
+---
+ util.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/util.c b/util.c
+index 3ea1bd2be7e6..fb07dc70d545 100644
+--- a/util.c
 b/util.c
+@@ -1379,8 +1379,13 @@ int do_authentication(const cfg_t *cfg, const device_t *devices,
+   goto out;
+ }
+ 
+-if (pin_verification == FIDO_OPT_TRUE)
++if (pin_verification == FIDO_OPT_TRUE) {
+   pin = converse(pamh, PAM_PROMPT_ECHO_OFF, "Please enter the PIN: ");
++  if (pin == NULL) {
++D(cfg->debug_file, "converse() returned NULL");
++goto out;
++  }
++}
+ if (user_presence == FIDO_OPT_TRUE ||
+ user_verification == FIDO_OPT_TRUE) {
+   if (cfg->manual == 0 && cfg->cue && !cued) {
+-- 
+2.32.0.rc0
+
diff -Nru pam-u2f-1.1.0/debian/patches/series pam-u2f-1.1.0/debian/patches/series
--- pam-u2f-1.1.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ pam-u2f-1.1.0/debian/patches/series	2021-06-05 15:04:24.0 +0200
@@ -0,0 +1 @@
+Handle-converse-returning-NULL.patch

Bug#989500: unblock eyed3/0.8.10-4

[Gaetano Guerriero]

Subject: unblock: eyed3/0.8.10-4
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package eyed3

Package is not blocked, but it is marked for removal from
testing on 16 Jun and the auto migration period expires on 22 Jun.

There are no other excuses preventing the migration:
https://qa.debian.org/excuses.php?package=eyed3

[ Reason ]
New version in sid fixes the RC bug which is causing the autoremoval.

[ Impact ]
eyed3 would be removed from testing and so from bullseye.

[ Tests ]
It was manually tested that the fix for the RC bug effectly works.
Existing autopkgtests ensure general package functionality.

[ Other info ]
The fix is to completely remove a file with a debian patch (a plugin
which needs a library not packaged in debian).

The patch to remove the plugin was already packaged but it broke
during an upstream version update.

The plugin is already not working in testing.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock eyed3/0.8.10-4

Gaetano Guerriero
diff -Nru eyed3-0.8.10/debian/changelog eyed3-0.8.10/debian/changelog
--- eyed3-0.8.10/debian/changelog   2020-03-18 21:02:56.0 +0100
+++ eyed3-0.8.10/debian/changelog   2021-06-02 07:13:19.0 +0200
@@ -1,3 +1,32 @@
+eyed3 (0.8.10-4) unstable; urgency=medium
+
+  * Source only upload, to recover from previous binary upload.
+
+  * Upload sponsored by Petter Reinholdtsen.
+
+ -- Gaetano Guerriero   Wed, 02 Jun 2021 07:13:19 +0200
+
+eyed3 (0.8.10-3) unstable; urgency=medium
+
+  * Fix autopkgtest generating sometimes output on stderr (Closes: #989356)
+
+  * Upload sponsored by Petter Reinholdtsen.
+
+ -- Gaetano Guerriero   Tue, 01 Jun 2021 18:04:57 +0200
+
+eyed3 (0.8.10-2) unstable; urgency=medium
+
+  * Add patch to support pylast 3, backported from upstream
+(Closes: #945371)
+  * Fix patch remove-display-plugin to really disable the plugin
+(Closes: #988738)
+  * Add more autopkgtests and flag the original ones
+with Restrictions: superficial (Closes: #97)
+
+  * Upload sponsored by Petter Reinholdtsen.
+
+ -- Gaetano Guerriero   Mon, 31 May 2021 15:02:53 +0200
+
 eyed3 (0.8.10-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru eyed3-0.8.10/debian/patches/remove-display-plugin 
eyed3-0.8.10/debian/patches/remove-display-plugin
--- eyed3-0.8.10/debian/patches/remove-display-plugin   2019-01-02 
14:59:00.0 +0100
+++ eyed3-0.8.10/debian/patches/remove-display-plugin   2021-05-31 
15:10:57.0 +0200
@@ -267,3 +267,1152 @@
 -whitespace=args.whitespace,
 -nameguard=not args.no_nameguard
 -)
+--- a/src/eyed3/plugins/display.py
 /dev/null
+@@ -1,1146 +0,0 @@
+-# -*- coding: utf-8 -*-
+-
+-#  Copyright (C) 2014-2016  Sebastian Patschorke 
+-#
+-#  This program is free software; you can redistribute it and/or modify
+-#  it under the terms of the GNU General Public License as published by
+-#  the Free Software Foundation; either version 2 of the License, or
+-#  (at your option) any later version.
+-#
+-#  This program is distributed in the hope that it will be useful,
+-#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+-#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+-#  GNU General Public License for more details.
+-#
+-#  You should have received a copy of the GNU General Public License
+-#  along with this program; if not, see .
+-#
+-
+-from __future__ import print_function
+-import os
+-import re
+-import abc
+-
+-from argparse import ArgumentTypeError
+-
+-from eyed3 import id3, compat
+-from eyed3.utils import console, formatSize, formatTime
+-from eyed3.plugins import LoaderPlugin
+-try:
+-from eyed3.plugins._display_parser import DisplayPatternParser
+-_have_grako = True
+-except ImportError:
+-_have_grako = False
+-
+-
+-class Pattern(object):
+-
+-def __init__(self, text=None, sub_patterns=None):
+-self.__text = text
+-self.__sub_patterns = sub_patterns
+-
+-def output_for(self, audio_file):
+-output = u""
+-for sub_pattern in self.sub_patterns or []:
+-output += sub_pattern.output_for(audio_file)
+-return output
+-
+-def __get_sub_patterns(self):
+-if self.__sub_patterns is None and self.__text is not None:
+-self.__compile()
+-return self.__sub_patterns
+-
+-def __set_sub_patterns(self, sub_patterns):
+-self.__sub_patterns = sub_patterns
+-
+-sub_patterns = property(__get_sub_patterns, __set_sub_patterns)
+-
+-def __compile(self):
+-# TODO: add support for comments in pattern
+-parser = 

Bug#989501: new upstream releases since 2016

[VA]

Package: ffmpegthumbnailer
Version:  2.1.1-0.2

ffmpegthumbnailer 2.1.2 isn't in Debian, though it was released 5 years 
ago! And current ffmpegthumbnailer upstream version is 2.2.2, it would 
be good to update what's in Debian.

Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

[Salvatore Bonaccorso]

Hi Tormod,

On Thu, May 06, 2021 at 07:38:34PM +0200, Moritz Mühlenhoff wrote:
> Am Mon, Apr 19, 2021 at 11:42:54AM +0200 schrieb Moritz Muehlenhoff:
> > On Sun, Apr 18, 2021 at 07:21:31PM +0200, Tormod Volden wrote:
> > > Yes, I think dropping the set_cap is the easy way out of here. sonar
> > > will still be visually pleasing, just not so interesting.
> > 
> > Let's do that for buster/bullseye? And when xscreensaver gets updated to 
> > 6.00
> > after the release, it can be re-enabled?
> 
> *ping* :-)

Time is starting to get very close to the bullseye release now. Did
you got a chance to look into preparing the above changes?

Regards,
Salvatore

Bug#989495: linux-image-5.10.0-7-amd64: Journal reports multiple Key file does not have key "..." in group “Controller” for bluetooth

[Salvatore Bonaccorso]

Control: reassign -1 src:bluez 5.55-3
Control: forwarded -1 https://github.com/bluez/bluez/issues/51

On Sat, Jun 05, 2021 at 12:21:22PM +0200, Tia wrote:
> Package: src:linux
> Version: 5.10.40-1
> Severity: normal
> X-Debbugs-Cc: tia3...@protonmail.com
> 
> Dear Maintainer,
> 
> Since installing Bullseye journal would write these warning messages on every 
> startup:
> 
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRPageScanType” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRPageScanInterval” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRPageScanWindow” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRInquiryScanType” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRInquiryScanInterval” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRInquiryScanWindow” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRLinkSupervisionTimeout” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRPageTimeout” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRMinSniffInterval” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “BRMaxSniffInterval” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEMinAdvertisementInterval” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEMaxAdvertisementInterval” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEMultiAdvertisementRotationInterval” in group 
> “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanIntervalAutoConnect” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanWindowAutoConnect” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanIntervalSuspend” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanWindowSuspend” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanIntervalDiscovery” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanWindowDiscovery” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanIntervalAdvMonitor” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanWindowAdvMonitor” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanIntervalConnect” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEScanWindowConnect” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEMinConnectionInterval” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEMaxConnectionInterval” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEConnectionLatency” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEConnectionSupervisionTimeout” in group “Controller”
> lip 04 23:08:25 bluetoothd[1553]: src/main.c:parse_controller_config() Key 
> file does not have key “LEAutoconnecttimeout” in group “Controller”
> 
> Bluez package looks for defaults for those values in kernel, and they appear 
> to be missing.
> 
> For bluetooth to work I need to have firmware-atheros, so ath9k driver is 
> being used.
> 
> Such messages weren't appearing in Buster.

This is not a kernel issue though showing the warnings, and bluez
fixed it by lowering the warn message to a debug message only. I'm
reassigning it accordingly to bluez.

See

Bug#989493: udisks2: Warning in journal about "Failed to load the 'mdraid' libblockdev plugin"

[Tia]

Package: udisks2
Version: 2.9.2-2
Severity: normal
X-Debbugs-Cc: tia3...@protonmail.com

Dear Maintainer,

On each startup udisksd gives a warning to journal about missing module

udisksd[789]: failed to load module mdraid: libbd_mdraid.so.2: cannot open 
shared object file: No such file or directory
udisksd[789]: Failed to load the 'mdraid' libblockdev plugin

I used guided partitioning with encrypted LUK2, and I don't use mdraid.
Missing module is libblockdev-mdraid2, and installing it removes warning
message.

Inside udisks2.conf I have default

modules=*

As such it loads all of them, but I don't see reason why it complains
about missing ones, unless something is asking for them.

Beside warning message there is no other issues.


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

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

Versions of packages udisks2 depends on:
ii  dbus   1.12.20-2
ii  libacl12.2.53-10
ii  libatasmart4   0.19-5
ii  libblockdev-fs22.25-2
ii  libblockdev-loop2  2.25-2
ii  libblockdev-part2  2.25-2
ii  libblockdev-swap2  2.25-2
ii  libblockdev-utils2 2.25-2
ii  libblockdev2   2.25-2
ii  libc6  2.31-12
ii  libglib2.0-0   2.66.8-1
ii  libgudev-1.0-0 234-1
ii  libmount1  2.36.1-7
ii  libpolkit-agent-1-00.105-30
ii  libpolkit-gobject-1-0  0.105-30
ii  libsystemd0247.3-5
ii  libudisks2-0   2.9.2-2
ii  libuuid1   2.36.1-7
ii  parted 3.4-1
ii  udev   247.3-5

Versions of packages udisks2 recommends:
ii  dosfstools   4.2-1
ii  e2fsprogs1.46.2-1
ii  eject2.36.1-7
ii  exfat-utils  1.3.0-2
ii  libblockdev-crypto2  2.25-2
ii  libpam-systemd   247.3-5
ii  ntfs-3g  1:2017.3.23AR.3-4
ii  policykit-1  0.105-30

Versions of packages udisks2 suggests:
pn  btrfs-progs  
pn  f2fs-tools   
pn  libblockdev-mdraid2  
pn  mdadm
pn  nilfs-tools  
pn  reiserfsprogs
pn  udftools 
pn  udisks2-bcache   
pn  udisks2-btrfs
pn  udisks2-lvm2 
pn  udisks2-zram 
pn  xfsprogs 

-- no debconf information

Bug#989499: openssl: version 3 is slower than version 1.1.1k on arm64 with no crypto hardware

[Ryutaroh Matsumoto]

Package: openssl
Version: 3.0.0~~alpha16-1
Severity: minor
Tags: experimental
X-Debbugs-Cc: debian-...@lists.debian.org

Dear Maintainer,

As a response to a recent discussion at the Debian ARM mailing list,
I compared the speed of aes-128-cbc of openssl 1.1.1k in Bullseye
and 3.0 in experimental on Raspberry Pi 4B. The results are as below.
Version 3.0 is slower than version 1.1.1k.
On the other hand, at
https://lists.debian.org/debian-arm/2021/06/msg9.html
Diederik reported that version 3.0 is faster on arm64 with crypto hardware.
I am unsure if this is an upstream issue.

My speed results are as below:

# openssl speed aes-128-cbc
...
OpenSSL 1.1.1k  25 Mar 2021
built on: Thu Mar 25 20:49:34 2021 UTC
options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) 
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 
-ffile-prefix-map=/build/openssl-YhzaKF/openssl-1.1.1k=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM 
-DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
aes-128 cbc  73719.58k78001.25k79918.46k79520.45k78646.02k  
  79442.42k
# openssl speed -evp aes-128-cbc
...
OpenSSL 1.1.1k  25 Mar 2021
built on: Thu Mar 25 20:49:34 2021 UTC
options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) 
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 
-ffile-prefix-map=/build/openssl-YhzaKF/openssl-1.1.1k=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM 
-DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
aes-128-cbc  37975.41k40705.82k41937.97k42066.56k42265.07k  
  42382.97k

# openssl speed aes-128-cbc
...
version: 3.0.0-alpha16
built on: built on: Thu May  6 19:54:38 2021 UTC
options:bn(64,64) 
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 
-ffile-prefix-map=/build/openssl-UqeSFN/openssl-3.0.0~~alpha16=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG 
-Wdate-time -D_FORTIFY_SOURCE=2
CPUINFO: OPENSSL_armcap=0x83
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
aes-128-cbc  37858.56k40995.79k41736.44k42339.69k41984.00k  
  42350.33k

# openssl speed -evp aes-128-cbc
...
version: 3.0.0-alpha16
built on: built on: Thu May  6 19:54:38 2021 UTC
options:bn(64,64) 
compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 
-ffile-prefix-map=/build/openssl-UqeSFN/openssl-3.0.0~~alpha16=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG 
-Wdate-time -D_FORTIFY_SOURCE=2
CPUINFO: OPENSSL_armcap=0x83
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
AES-128-CBC  38057.99k41038.28k41973.03k41930.50k42233.35k  
  42308.27k

Best regards, Ryutaroh Matsumoto

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'), 
(1, 'experimental')
Architecture: arm64 (aarch64)

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

Versions of packages openssl depends on:
ii  libc62.31-12
ii  libssl3  3.0.0~~alpha16-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20210119

-- no debconf information

Bug#989498: unblock: golang-1.15/1.15.9-5

[Shengjing Zhu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-1.15

[ Reason ]

Backport patches for CVE-2021-33195 CVE-2021-33197 CVE-2021-33198

[ Impact ]
Security issue.

[ Tests ]
Unit tests provided by upstream.

[ Risks ]
+ Key package

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock golang-1.15/1.15.9-5


diff -Nru golang-1.15-1.15.9/debian/changelog 
golang-1.15-1.15.9/debian/changelog
--- golang-1.15-1.15.9/debian/changelog 2021-06-02 10:56:03.0 +0800
+++ golang-1.15-1.15.9/debian/changelog 2021-06-05 19:36:34.0 +0800
@@ -1,3 +1,15 @@
+golang-1.15 (1.15.9-5) unstable; urgency=medium
+
+  * Team upload.
+  * Backport patches for CVE-2021-33195 CVE-2021-33197 CVE-2021-33198
++ CVE-2021-33195: net: Lookup functions may return invalid host names
++ CVE-2021-33197: net/http/httputil: ReverseProxy forwards Connection
+  headers if first one is empty
++ CVE-2021-33198: math/big: (*Rat).SetString with 
"1.770p02041010010011001001"
+  crashes with "makeslice: len out of range"
+
+ -- Shengjing Zhu   Sat, 05 Jun 2021 19:36:34 +0800
+
 golang-1.15 (1.15.9-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru golang-1.15-1.15.9/debian/patches/0009-CVE-2021-33195-1.patch 
golang-1.15-1.15.9/debian/patches/0009-CVE-2021-33195-1.patch
--- golang-1.15-1.15.9/debian/patches/0009-CVE-2021-33195-1.patch   
1970-01-01 08:00:00.0 +0800
+++ golang-1.15-1.15.9/debian/patches/0009-CVE-2021-33195-1.patch   
2021-06-05 19:36:34.0 +0800
@@ -0,0 +1,369 @@
+From 31d60cda1f58b7558fc5725d2b9e4531655d980e Mon Sep 17 00:00:00 2001
+From: Roland Shoemaker 
+Date: Thu, 27 May 2021 10:40:06 -0700
+Subject: [PATCH] [release-branch.go1.15] net: verify results from Lookup* are
+ valid domain names
+
+For the methods LookupCNAME, LookupSRV, LookupMX, LookupNS, and
+LookupAddr check that the returned domain names are in fact valid DNS
+names using the existing isDomainName function.
+
+Thanks to Philipp Jeitner and Haya Shulman from Fraunhofer SIT for
+reporting this issue.
+
+Updates #46241
+Fixes #46356
+Fixes CVE-2021-33195
+
+Change-Id: I47a4f58c031cb752f732e88bbdae7f819f0af4f3
+Reviewed-on: https://go-review.googlesource.com/c/go/+/323131
+Trust: Roland Shoemaker 
+Run-TryBot: Roland Shoemaker 
+TryBot-Result: Go Bot 
+Reviewed-by: Filippo Valsorda 
+Reviewed-by: Katie Hockman 
+(cherry picked from commit cdcd02842da7c004efd023881e3719105209c908)
+Reviewed-on: https://go-review.googlesource.com/c/go/+/323269
+---
+ src/net/dnsclient_unix_test.go | 157 +
+ src/net/lookup.go  | 111 ---
+ 2 files changed, 255 insertions(+), 13 deletions(-)
+
+diff --git a/src/net/dnsclient_unix_test.go b/src/net/dnsclient_unix_test.go
+index 06553636eee25..819f20b887ae6 100644
+--- a/src/net/dnsclient_unix_test.go
 b/src/net/dnsclient_unix_test.go
+@@ -1799,3 +1799,160 @@ func TestPTRandNonPTR(t *testing.T) {
+   t.Errorf("names = %q; want %q", names, want)
+   }
+ }
++
++func TestCVE202133195(t *testing.T) {
++  fake := fakeDNSServer{
++  rh: func(n, _ string, q dnsmessage.Message, _ time.Time) 
(dnsmessage.Message, error) {
++  r := dnsmessage.Message{
++  Header: dnsmessage.Header{
++  ID: q.Header.ID,
++  Response:   true,
++  RCode:  
dnsmessage.RCodeSuccess,
++  RecursionAvailable: true,
++  },
++  Questions: q.Questions,
++  }
++  switch q.Questions[0].Type {
++  case dnsmessage.TypeCNAME:
++  r.Answers = []dnsmessage.Resource{}
++  case dnsmessage.TypeA: // CNAME lookup uses a A/ as 
a proxy
++  r.Answers = append(r.Answers,
++  dnsmessage.Resource{
++  Header: 
dnsmessage.ResourceHeader{
++  Name:   
dnsmessage.MustNewName(".golang.org."),
++  Type:   
dnsmessage.TypeA,
++  Class:  
dnsmessage.ClassINET,
++  Length: 4,
++  },
++  Body: {
++  A: TestAddr,
++ 

Bug#932711: 404 for http://standards.ieee.org/regauth/oui/oui.txt

[Samuel Henrique]

Hello Luciano,

> NMU are welcomed. RL is keeping me extremely  busy right now...

I'm very interested in helping with the maintenance of ieee-data,
would you be willing to accept a co-maintainer? I would like to fix
this bug (for oldstable/debian 9 at least) and to update the package
for bullseye (with 2021 data) before the release.

I have also pushed the latest NMU to the git repo and set the fixed
property of this bug and #908623

Thank you,

-- 
Samuel Henrique 

Bug#989485: d-e-install: drop powerpc recipes

[Wolfgang Schweer]

[ Holger Levsen, 2021-06-04 ]

> wait, what? why do we still have powerpc recipes in Debian Edu? We 
> dropped powerpc support some time ago :)
> 
> (not fully sure we want this change for bullseye but then I also don't 
> see how it could hurt to drop those properly.)
> 
> (and in any case this shouldn't be a blocker for #989483, the current 
> d-e-install unblock request...)

I noticed the superflous recipes as well (and those should definitly be 
removed), but then thought restricting the changes to fix the UEFI 
related bug would be the way to go for bullseye…

Wolfgang


signature.asc
Description: PGP signature

Bug#989492: golang-1.16: CVE-2021-33196: archive/zip: malformed archive may cause panic or memory exhaustion

[Salvatore Bonaccorso]

Hi,

On Sat, Jun 05, 2021 at 07:17:44PM +0800, Shengjing Zhu wrote:
> Hi Salvatore,
> 
> On Sat, Jun 5, 2021 at 4:12 PM Salvatore Bonaccorso  wrote:
> > Hi,
> >
> > The following vulnerability was published for golang-1.16.
> >
> > CVE-2021-33196[0]:
> 
> How does security-tracker pull the cve data? The point release from
> golang appears addressing 4 cve, which are CVE-2021-3319{5,6,7,8}. Why
> is the security-tracker only aware of CVE-2021-33196?
> 
> https://groups.google.com/g/golang-announce/c/RgCMkAEQjSI

When it pulls various feeds, and then someone of the team investigates
the new entries.

I will look at those others shortly.

Regards,
Salvatore

Bug#961183: metis: providing a 64-bit build

[Drew Parsons]

Package: metis
Followup-For: Bug #961183

64-bit integers are now available for several libraries.

64-bit PETSc is able to use 64-bit SuperLU-Dist, which we don't
currently have.

64-bit SuperLU-Dist requires 64-bit metis.

In principle 64-bit metis is simple to configure: set IDXTYPEWIDTH to
64 in metis.h.

The challenge that we need to address is the location of metis.h.
Currently it's located in /usr/include/metis.h (for the standard 32-bit build)

To distinguish between standard and 64-bit builds, we'd probably want to place
the 64-bit header in /usr/include/metis64/metis.h

-I/usr/include/metis64 can then be used by client applications. The
remaining challenge is that /usr/include/metis.h might be found
instead of /usr/include/metis64/metis.h, since -I/usr/include will
also often be used in build scripts.

I think the best solution is to "break" the builds of client
applications by moving the standard header from /usr/include/metis.h
to /usr/include/metis/metis.h.  Then client applications will need to
be updated to add -I/usr/include/metis when using the standard build.

Bug#989497: superlu-dist: provide 64-bit build

[Drew Parsons]

Source: superlu-dist
Severity: normal
Control: block -1 by 961183
Control: block 961977 by -1

We've started providing 64-bit builds of the numerical computational
libraries, in order to support computations of extreme systems with
more than a billion degrees of freedom.

64-bit PETSc is already in Debian.  It built against standard
superlu-dist, but that is actually a configuration error. 64-bit PETSc
requires 64-bit SuperLU-Dist.

The 64-bit build of SuperLU-Dist is easily activated with
-DXSDK_INDEX_SIZE=64. But it will require 64-bit metis.

Bug#989492: golang-1.16: CVE-2021-33196: archive/zip: malformed archive may cause panic or memory exhaustion

[Shengjing Zhu]

Hi Salvatore,

On Sat, Jun 5, 2021 at 4:12 PM Salvatore Bonaccorso  wrote:
> Hi,
>
> The following vulnerability was published for golang-1.16.
>
> CVE-2021-33196[0]:

How does security-tracker pull the cve data? The point release from
golang appears addressing 4 cve, which are CVE-2021-3319{5,6,7,8}. Why
is the security-tracker only aware of CVE-2021-33196?

https://groups.google.com/g/golang-announce/c/RgCMkAEQjSI

-- 
Shengjing Zhu

Bug#989453: Debian: gcc: add support for ARC

[Matthias Klose]

Control: tags -1 + incomplete

These definitions have to go first to
https://wiki.debian.org/Multiarch/Tuples

Please update.

Bug#989488: libtrilinos-ml-dev Depends: libtrilinos-aztecoo-dev

[Drew Parsons]

On 2021-06-05 11:31, Graham Inggs wrote:

On Sat, 5 Jun 2021 at 11:09, Drew Parsons  wrote:

True, you do have other things on your mind at this period of time :)


:)


It's probably worth fixing this problem for bullseye, I think.


I agree.  Please consider this a pre-approval.


Thanks, I'll push a patch.

The 10 hour trilinos build time is a little disconcerting, but this is 
just a trivial package admin patch so a direct sourceful upload should 
be safe.


Drew

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Christian Marillat]

On 05 juin 2021 10:59, Julien AUBIN  wrote:

> ow did you install Cuda stuff ?
>> 
>> Isn't directly cuda but libnvidia-*-encode1 package is required.
>> 
>> Here ffmpeg complaint about an API mismatch 11.0 vs 10.0
>> 
> Does ffmpeg work with version 460.73 ?

I forgot ffmpeg come from the deb-multimedia.org repository.

ffmpeg package from Debian doesn't have nvenc.

Christian

Bug#989494: buster-pu: package http-parser/2.8.1-1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbug-CC: ruby-http-parser...@packages.debian.org

Hello release team,

there is a minor (non-DSA) security issue open in the Debian 10
("buster") version of http-parser, and I'd like to fix that in a stable
point release. This is #977467 [CVE-2019-15605].

Usually I'd just upload such a change change without asking for prior
authorizsation, but there's a complication: The updated version will
break the test suite of the ruby-http-parser.rb package. See my article
in debian-devel about that story in unstable and the NMU for further
details.[1][2]

Please advise how to proceed. If you think that situation is acceptable,
just let that package pass or ask me to upload it. If however you think,
the ruby-http-parser.rb maintainers (Cc'd) should provide an updated
version first, let us know and I'll try to get things coordinated.

Another idea was to postpone this story until after the upcoming 10.10
point release so there will be more time to learn about regressions and
to thandle them.

Kind regards,

Christoph

[1] https://lists.debian.org/msgid-search/1609286...@msgid.manchmal.in-ulm.de
[2] 
https://packages.qa.debian.org/r/ruby-http-parser.rb/news/20201227T111838Z.html

diff -Nru http-parser-2.8.1/debian/changelog http-parser-2.8.1/debian/changelog
--- http-parser-2.8.1/debian/changelog  2018-04-12 22:15:13.0 +0200
+++ http-parser-2.8.1/debian/changelog  2021-06-04 20:59:56.0 +0200
@@ -1,3 +1,10 @@
+http-parser (2.8.1-1+deb10u1) buster; urgency=medium
+
+  * Cherry-pick "Support multi-coding Transfer-Encoding".
+Closes: #977467 [CVE-2019-15605]
+
+ -- Christoph Biedl   Fri, 04 Jun 2021 
20:59:56 +0200
+
 http-parser (2.8.1-1) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru 
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
 
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
--- 
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
  1970-01-01 01:00:00.0 +0100
+++ 
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
  2021-06-04 20:59:56.0 +0200
@@ -0,0 +1,366 @@
+Subject: Support multi-coding Transfer-Encoding
+Origin: v2.9.2-2-g7d5c99d 

+Upstream-Author: Fedor Indutny 
+Date: Mon Feb 3 21:10:35 2020 +0100
+
+`Transfer-Encoding` header might have multiple codings in it. Even
+though llhttp cares only about `chunked`, it must check that `chunked`
+is the last coding (if present).
+
+ABNF from RFC 7230:
+
+```
+Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
+transfer-coding ] )
+transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
+transfer-extension
+   transfer-extension = token *( OWS ";" OWS transfer-parameter )
+   transfer-parameter = token BWS "=" BWS ( token / quoted-string )
+```
+
+However, if `chunked` is not last - llhttp must assume that the encoding
+and size of the body is unknown (according to 3.3.3 of RFC 7230) and
+read the response until EOF. For request - the error must be raised for
+an unknown `Transfer-Encoding`.
+
+Furthermore, 3.3.3 of RFC 7230 explicitly states that presence of both
+`Transfer-Encoding` and `Content-Length` indicates the smuggling attack
+and "ought to be handled as an error".
+
+For the lenient mode:
+
+* Unknown `Transfer-Encoding` in requests is not an error and request
+  body is simply read until EOF (end of connection)
+* Only `Transfer-Encoding: chunked` together with `Content-Length` would
+  result an error (just like before the patch)
+
+PR-URL: https://github.com/nodejs-private/http-parser-private/pull/4
+Reviewed-By: Matteo Collina 
+Reviewed-By: Sam Roberts 
+Reviewed-By: James M Snell 
+
+--- a/http_parser.c
 b/http_parser.c
+@@ -375,7 +375,10 @@
+   , h_transfer_encoding
+   , h_upgrade
+ 
++  , h_matching_transfer_encoding_token_start
+   , h_matching_transfer_encoding_chunked
++  , h_matching_transfer_encoding_token
++
+   , h_matching_connection_token_start
+   , h_matching_connection_keep_alive
+   , h_matching_connection_close
+@@ -1311,6 +1314,7 @@
+ parser->header_state = h_general;
+   } else if (parser->index == sizeof(TRANSFER_ENCODING)-2) {
+ parser->header_state = h_transfer_encoding;
++parser->flags |= F_TRANSFER_ENCODING;
+   }
+   break;
+ 
+@@ -1391,10 +1395,14 @@
+ if ('c' == c) {
+   parser->header_state = h_matching_transfer_encoding_chunked;
+ } else {
+-  parser->header_state 

Bug#989307: DSA-4923-1: upgrading libwebkit2gtk-4.0-37 on buster pulls in xdg-desktop-portal

[Alberto Garcia]

On Sat, Jun 05, 2021 at 11:45:45AM +0900, Olaf Meeuwissen wrote:

> In the mean time, I'll just `apt purge` the added packages.  In my
> case these were the
> 
> Package changes:
> + fuse 2.9.9-1+deb10u1 amd64
> + libpipewire-0.2-1 0.2.5-1 amd64
> + xdg-desktop-portal 1.2.0-1 amd64
> + xdg-desktop-portal-gtk 1.2.0-1 amd64

Yes, these are the actual new dependencies.

Future security updates and buster backports will Suggest
xdg-desktop-portal-gtk, although in bullseye it will still be a
recommendation.

I don't think there's any better way to have those packages removed
automatically (certainly not a Conflicts, many people had them
installed anyway). Apart from a couple of MBs of extra used disk
space, is there anything particularly worrying you?

Regards,

Berto

Bug#989355: transition: tinyxml2

[Chow Loong Jin]

On Wed, Jun 02, 2021 at 12:27:06PM +0200, Sebastian Ramacher wrote:
> On 2021-06-02 02:45:56, Chow Loong Jin wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > There's been an ABI break without an upstream soname bump in
> > libtinyxml2-8, between upstream versions 8.0.0 and 8.1.0, see [1] and
> > [2]. To remedy this, I have uploaded version 8.1.0+dfsg-2 to
> > experimental with the library package renamed from libtinyxml2-8 to
> > libtinyxml2-8a. It is waiting in the NEW queue now.
> 
> Please revert tinyxml2 in unstable to the state of 8.0.0+dfsg-2 to
> avoid uploads of reverse dependencies that are targetted for bullseye to
> be built against the broken version.

Done -- uploaded 8.0.0+dfsg-2 as 8.1.0+really8.0.0+dfsg-1 to unstable

Also reuploaded 8.1.0+dfsg-2 as 8.1.0+really8.1.0+dfsg-1 to experimental
to keep the relative order of the versions.

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#989488: libtrilinos-ml-dev Depends: libtrilinos-aztecoo-dev

[Graham Inggs]

On Sat, 5 Jun 2021 at 11:09, Drew Parsons  wrote:
> True, you do have other things on your mind at this period of time :)

:)

> It's probably worth fixing this problem for bullseye, I think.

I agree.  Please consider this a pre-approval.

Bug#989473: choose-mirror: switch mirror list from salsa to mirror-master

[Philip Hands]

Philip Hands  writes:

...
>  c) filter the old masterlist to only include entries that are also in
> the new list, and then use the result of that, perhaps with a tweak
> to promote deb.d.o

BTW Promoting deb.d.o can be done thus:

  
https://salsa.debian.org/philh/choose-mirror/-/commit/70caed09fbf4bfbcc9eca82168cf3936868d8394

which produces this menu ordering:

  https://openqa.debian.net/tests/6101#step/mirror_selection/2

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#988692: unblock: saga/7.3.0+dfsg-5 (pre-approval)

[Sebastiaan Couwenberg]

On 6/5/21 11:11 AM, Sebastiaan Couwenberg wrote:
> On 6/4/21 10:14 PM, Sebastian Ramacher wrote:
>> On 2021-05-18 07:10:02 +0200, Bas Couwenberg wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: unblock
>>>
>>> Please unblock package saga which fixes
>>> the broken symlink reported in #988674.
>>
>> ACK, please remove the moreinfo ag once the new version is available in
>> unstable.
> Thanks. saga (7.3.0+dfsg-5) has been uploaded to unstable and is built &
> installed on all release architectures.

PS. The package likely needs to be aged to get it into testing before
the autoremoval.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#988692: unblock: saga/7.3.0+dfsg-5 (pre-approval)

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo

On 6/4/21 10:14 PM, Sebastian Ramacher wrote:
> On 2021-05-18 07:10:02 +0200, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package saga which fixes
>> the broken symlink reported in #988674.
> 
> ACK, please remove the moreinfo ag once the new version is available in
> unstable.
Thanks. saga (7.3.0+dfsg-5) has been uploaded to unstable and is built &
installed on all release architectures.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Christian Marillat]

On 05 juin 2021 10:59, Julien AUBIN  wrote:

> ow did you install Cuda stuff ?
>> 
>> Isn't directly cuda but libnvidia-*-encode1 package is required.
>> 
>> Here ffmpeg complaint about an API mismatch 11.0 vs 10.0
>> 
> Does ffmpeg work with version 460.73 ?

Yes of course.

Christian

Bug#989488: libtrilinos-ml-dev Depends: libtrilinos-aztecoo-dev

[Drew Parsons]

On 2021-06-05 10:59, Graham Inggs wrote:

Hi Drew

On Sat, 5 Jun 2021 at 06:15, Drew Parsons  wrote:

az_aztec.h is in libtrilinos-aztecoo-dev. Hence the fix is to set
libtrilinos-ml-dev Depends: libtrilinos-aztecoo-dev


Please feel free to make a team upload, or even better, add yourself
to Uploaders ;-)


True, you do have other things on your mind at this period of time :)

It's probably worth fixing this problem for bullseye, I think.

Drew

Bug#985574: pygments: diff for NMU version 2.7.1+dfsg-2.1

[Salvatore Bonaccorso]

Control: tags 985574 + patch
Control: tags 985574 + pending


Dear maintainer,

I've prepared an NMU for pygments (versioned as 2.7.1+dfsg-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru pygments-2.7.1+dfsg/debian/changelog pygments-2.7.1+dfsg/debian/changelog
--- pygments-2.7.1+dfsg/debian/changelog	2021-03-12 10:54:46.0 +0100
+++ pygments-2.7.1+dfsg/debian/changelog	2021-06-05 11:00:18.0 +0200
@@ -1,3 +1,11 @@
+pygments (2.7.1+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix several exponential/cubic complexity regexes (CVE-2021-27291)
+(Closes: #985574)
+
+ -- Salvatore Bonaccorso   Sat, 05 Jun 2021 11:00:18 +0200
+
 pygments (2.7.1+dfsg-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru pygments-2.7.1+dfsg/debian/patches/Fix-several-exponential-cubic-complexity-regexes-fou.patch pygments-2.7.1+dfsg/debian/patches/Fix-several-exponential-cubic-complexity-regexes-fou.patch
--- pygments-2.7.1+dfsg/debian/patches/Fix-several-exponential-cubic-complexity-regexes-fou.patch	1970-01-01 01:00:00.0 +0100
+++ pygments-2.7.1+dfsg/debian/patches/Fix-several-exponential-cubic-complexity-regexes-fou.patch	2021-06-05 11:00:18.0 +0200
@@ -0,0 +1,127 @@
+From: Georg Brandl 
+Date: Mon, 11 Jan 2021 09:46:34 +0100
+Subject: Fix several exponential/cubic complexity regexes found by Ben
+ Caller/Doyensec
+Origin: https://github.com/pygments/pygments/commit/2e7e8c4a7b318f4032493773732754e418279a14
+Bug-Debian: https://bugs.debian.org/985574
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-27291
+
+---
+ CHANGES  | 5 -
+ pygments/lexers/archetype.py | 2 +-
+ pygments/lexers/factor.py| 4 ++--
+ pygments/lexers/jvm.py   | 1 -
+ pygments/lexers/matlab.py| 6 +++---
+ pygments/lexers/objective.py | 4 ++--
+ pygments/lexers/templates.py | 2 +-
+ pygments/lexers/varnish.py   | 2 +-
+ 8 files changed, 14 insertions(+), 12 deletions(-)
+
+--- a/pygments/lexers/archetype.py
 b/pygments/lexers/archetype.py
+@@ -58,7 +58,7 @@ class AtomsLexer(RegexLexer):
+ (r'P((\d*(\.\d+)?[YyMmWwDd]){1,3}(T(\d*(\.\d+)?[HhMmSs]){,3})?|'
+  r'T(\d*(\.\d+)?[HhMmSs]){,3})', Literal.Date),
+ (r'[+-]?(\d+\.\d*|\.\d+|\d+)[eE][+-]?\d+', Number.Float),
+-(r'[+-]?(\d+)*\.\d+%?', Number.Float),
++(r'[+-]?\d*\.\d+%?', Number.Float),
+ (r'0x[0-9a-fA-F]+', Number.Hex),
+ (r'[+-]?\d+%?', Number.Integer),
+ ],
+--- a/pygments/lexers/factor.py
 b/pygments/lexers/factor.py
+@@ -265,7 +265,7 @@ class FactorLexer(RegexLexer):
+ (r'(?:)\s', Keyword.Namespace),
+ 
+ # strings
+-(r'"""\s+(?:.|\n)*?\s+"""', String),
++(r'"""\s(?:.|\n)*?\s"""', String),
+ (r'"(?:|\\"|[^"])*"', String),
+ (r'\S+"\s+(?:|\\"|[^"])*"', String),
+ (r'CHAR:\s+(?:\\[\\abfnrstv]|[^\\]\S*)\s', String.Char),
+@@ -322,7 +322,7 @@ class FactorLexer(RegexLexer):
+ 'slots': [
+ (r'\s+', Text),
+ (r';\s', Keyword, '#pop'),
+-(r'(\{\s+)(\S+)(\s+[^}]+\s+\}\s)',
++(r'(\{\s+)(\S+)(\s[^}]+\s\}\s)',
+  bygroups(Text, Name.Variable, Text)),
+ (r'\S+', Name.Variable),
+ ],
+--- a/pygments/lexers/jvm.py
 b/pygments/lexers/jvm.py
+@@ -974,7 +974,6 @@ class CeylonLexer(RegexLexer):
+ (r'(import)(\s+)', bygroups(Keyword.Namespace, Text), 'import'),
+ (r'"(|\\"|[^"])*"', String),
+ (r"'\\.'|'[^\\]'|'\\\{#[0-9a-fA-F]{4}\}'", String.Char),
+-(r'".*``.*``.*"', String.Interpol),
+ (r'(\.)([a-z_]\w*)',
+  bygroups(Operator, Name.Attribute)),
+ (r'[a-zA-Z_]\w*:', Name.Label),
+--- a/pygments/lexers/matlab.py
 b/pygments/lexers/matlab.py
+@@ -137,7 +137,7 @@ class MatlabLexer(RegexLexer):
+ (r'.', Comment.Multiline),
+ ],
+ 'deffunc': [
+-(r'(\s*)(?:(.+)(\s*)(=)(\s*))?(.+)(\()(.*)(\))(\s*)',
++(r'(\s*)(?:(\S+)(\s*)(=)(\s*))?(.+)(\()(.*)(\))(\s*)',
+  bygroups(Whitespace, Text, Whitespace, Punctuation,
+   Whitespace, Name.Function, Punctuation, Text,
+   Punctuation, Whitespace), '#pop'),
+@@ -638,7 +638,7 @@ class OctaveLexer(RegexLexer):
+ (r"[^']*'", String, '#pop'),
+ ],
+ 'deffunc': [
+-(r'(\s*)(?:(.+)(\s*)(=)(\s*))?(.+)(\()(.*)(\))(\s*)',
++(r'(\s*)(?:(\S+)(\s*)(=)(\s*))?(.+)(\()(.*)(\))(\s*)',
+  bygroups(Whitespace, Text, Whitespace, Punctuation,
+   Whitespace, Name.Function, Punctuation, Text,
+   Punctuation, Whitespace), '#pop'),
+@@ -706,7 +706,7 @@ class ScilabLexer(RegexLexer):
+ (r'.', String, '#pop'),
+ ],
+ 

Bug#989488: libtrilinos-ml-dev Depends: libtrilinos-aztecoo-dev

[Graham Inggs]

Hi Drew

On Sat, 5 Jun 2021 at 06:15, Drew Parsons  wrote:
> az_aztec.h is in libtrilinos-aztecoo-dev. Hence the fix is to set
> libtrilinos-ml-dev Depends: libtrilinos-aztecoo-dev

Please feel free to make a team upload, or even better, add yourself
to Uploaders ;-)

Regards
Graham

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Julien AUBIN]

ow did you install Cuda stuff ?
> 
> Isn't directly cuda but libnvidia-*-encode1 package is required.
> 
> Here ffmpeg complaint about an API mismatch 11.0 vs 10.0
> 
Does ffmpeg work with version 460.73 ?

Bug#984668: python-markdown2: diff for NMU version 2.3.10-1.1

[Salvatore Bonaccorso]

Control: tags 984668 + patch
Control: tags 984668 + pending


Dear maintainer,

I've prepared an NMU for python-markdown2 (versioned as 2.3.10-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru python-markdown2-2.3.10/debian/changelog python-markdown2-2.3.10/debian/changelog
--- python-markdown2-2.3.10/debian/changelog	2021-01-16 23:04:54.0 +0100
+++ python-markdown2-2.3.10/debian/changelog	2021-06-05 10:38:29.0 +0200
@@ -1,3 +1,10 @@
+python-markdown2 (2.3.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Regex DOS fixes (CVE-2021-26813) (Closes: #984668)
+
+ -- Salvatore Bonaccorso   Sat, 05 Jun 2021 10:38:29 +0200
+
 python-markdown2 (2.3.10-1) unstable; urgency=medium
 
   [ Ond??ej Nov?? ]
diff -Nru python-markdown2-2.3.10/debian/patches/CVE-2021-26813/0001-Regex-DOS-fixes.patch python-markdown2-2.3.10/debian/patches/CVE-2021-26813/0001-Regex-DOS-fixes.patch
--- python-markdown2-2.3.10/debian/patches/CVE-2021-26813/0001-Regex-DOS-fixes.patch	1970-01-01 01:00:00.0 +0100
+++ python-markdown2-2.3.10/debian/patches/CVE-2021-26813/0001-Regex-DOS-fixes.patch	2021-06-05 10:37:42.0 +0200
@@ -0,0 +1,57 @@
+From: Nicholas Serra 
+Date: Wed, 20 Jan 2021 17:23:21 -0500
+Subject: [1/3] Regex DOS fixes
+Origin: https://github.com/trentm/python-markdown2/commit/96dff22341489459c8cb832fdfd066a588ec23bf
+Bug: https://github.com/trentm/python-markdown2/pull/387
+Bug-Debian: https://bugs.debian.org/984668
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-26813
+
+---
+ lib/markdown2.py | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/lib/markdown2.py b/lib/markdown2.py
+index bb5260bef210..f3e41cc19d13 100755
+--- a/lib/markdown2.py
 b/lib/markdown2.py
+@@ -532,7 +532,7 @@ class Markdown(object):
+ 
+ return tail
+ 
+-_emacs_oneliner_vars_pat = re.compile(r"-\*-\s*([^\r\n]*?)\s*-\*-", re.UNICODE)
++_emacs_oneliner_vars_pat = re.compile(r"-\*-\s*(?:(\S[^\r\n]*?)([\r\n]\s*)?)?-\*-", re.UNICODE)
+ # This regular expression is intended to match blocks like this:
+ #PREFIX Local Variables: SUFFIX
+ #PREFIX mode: Tcl SUFFIX
+@@ -892,8 +892,8 @@ class Markdown(object):
+ '''
+ # First pass to define all the references
+ self.regex_defns = re.compile(r'''
+-\[\#(\w+)\s* # the counter.  Open square plus hash plus a word \1
+-([^@]*)\s*   # Some optional characters, that aren't an @. \2
++\[\#(\w+) # the counter.  Open square plus hash plus a word \1
++([^@]*)   # Some optional characters, that aren't an @. \2
+ @(\w+)   # the id.  Should this be normed? \3
+ ([^\]]*)\]   # The rest of the text up to the terminating ] \4
+ ''', re.VERBOSE)
+@@ -908,7 +908,7 @@ class Markdown(object):
+ if len(match.groups()) != 4:
+ continue
+ counter = match.group(1)
+-text_before = match.group(2)
++text_before = match.group(2).strip()
+ ref_id = match.group(3)
+ text_after = match.group(4)
+ number = counters.get(counter, 1)
+@@ -1926,7 +1926,7 @@ class Markdown(object):
+ 
+ _fenced_code_block_re = re.compile(r'''
+ (?:\n+|\A\n?)
+-^```\s*?([\w+-]+)?\s*?\n# opening fence, $1 = optional lang
++^```\s{0,2}([\w+-]+)?\s*?\n # opening fence, $1 = optional lang
+ (.*?)   # $2 = code block content
+ ^```[ \t]*\n# closing fence
+ ''', re.M | re.X | re.S)
+-- 
+2.32.0.rc0
+
diff -Nru python-markdown2-2.3.10/debian/patches/CVE-2021-26813/0002-Pretty-comment-alignment.patch python-markdown2-2.3.10/debian/patches/CVE-2021-26813/0002-Pretty-comment-alignment.patch
--- python-markdown2-2.3.10/debian/patches/CVE-2021-26813/0002-Pretty-comment-alignment.patch	1970-01-01 01:00:00.0 +0100
+++ python-markdown2-2.3.10/debian/patches/CVE-2021-26813/0002-Pretty-comment-alignment.patch	2021-06-05 10:37:42.0 +0200
@@ -0,0 +1,32 @@
+From: Nicholas Serra 
+Date: Wed, 20 Jan 2021 17:27:21 -0500
+Subject: [2/3] Pretty comment alignment
+Origin: https://github.com/trentm/python-markdown2/commit/e1954d3a345fc7a4ccc113bd58f7df81ad63b6ec
+Bug: https://github.com/trentm/python-markdown2/pull/387
+Bug-Debian: https://bugs.debian.org/984668
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-26813
+
+---
+ lib/markdown2.py | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/lib/markdown2.py b/lib/markdown2.py
+index f3e41cc19d13..61bb6f691632 100755
+--- a/lib/markdown2.py
 b/lib/markdown2.py
+@@ -1926,9 +1926,9 @@ class Markdown(object):
+ 
+ _fenced_code_block_re = re.compile(r'''
+ (?:\n+|\A\n?)
+-^```\s{0,2}([\w+-]+)?\s*?\n # opening fence, $1 = optional lang
+- 

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Dekks Herton]

Hi

Additional alsa-info script output

On Sat, 5 Jun 2021 at 00:19, Dekks Herton  wrote:

> Hi,
>
> Files as requested. I've included a full journal output if there is
> anything else you notice
>
> Regards..
>
> On Fri, 4 Jun 2021 at 21:27, Vincent Blut  wrote:
>
>> Hi Salvatore,
>>
>> Le 2021-06-04 21:39, Salvatore Bonaccorso a écrit :
>> > Hi,
>> >
>> > On Fri, Jun 04, 2021 at 05:56:03PM +0200, Vincent Blut wrote:
>> > > Hi Dekks,
>> > >
>> > > Le 2021-06-04 15:34, Dekks Herton a écrit :
>> > > > Hi Everyone,
>> > > >
>> > > > As 5.10.7 was still in unstable 1 added it to my bullseye system
>> via adding
>> > > > SId to sources.list and pulling the image and relevant headers
>> packages. If
>> > > > there is a better or more correct way please advise.
>> > > >
>> > > > Running 5.10.7 AFAIK installs the catpt modules correctly and all
>> the hw
>> > > > associated correctly
>> > > >
>> > > > 1) See aplayL txt file enc 2) GNOME shows a different slider layout
>> > > >
>> > > > However there is still no sound on play back, parsing journalctl it
>> seems
>> > > > the firmware IntcSST2.bin errors out and thus no firmware is loaded.
>> > > >
>> > > > Jun 04 00:49:06 HELIX2NDGEN kernel: intel_catpt INT3438:00:
>> firmware:
>> > > > direct-loading firmware intel/IntcSST2.bin
>> > > > Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00:
>> firmware:
>> > > > direct-loading firmware intel/IntcSST2.bin
>> > > > Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00:
>> firmware ready
>> > > > timeout
>> > > > Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: boot
>> firmware
>> > > > failed: -110
>> > > >
>> > > > I enclose a listing of the intel firmware folder showing
>> IntcSST2.bin is
>> > > > there, Is it the correct firmware?
>> > > >
>> > > > I've googled and cant find any info on this. Does intel have a
>> github for
>> > > > this re-written driver?
>> > > >
>> > > > Can the bug reopened or can you advise any possible solutions?
>> > >
>> > > Do you have firmware-sof-signed installed? It may be needed on your
>> system.
>> >
>> > Reopened the bug for now (at least until the above question is
>> > clarified).
>>
>> Dekks replied to me privately. Those SOF audio firmware aren't going to
>> help in
>> this case since we don't provide support for SOF on Broadwell based
>> platforms.
>> I already mentioned this in [1] but I had totally forgotten that.
>>
>> Dekks, out of curiosity, could you please post the output of 'pacmd
>> list-sinks'?
>>
>> > Regards,
>> > Salvatore
>>
>> Cheers,
>> Vincent
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986822#10
>>
>
upload=true=true=
!!
!!ALSA Information Script v 0.5.0
!!

!!Script ran on: Sat Jun  5 08:17:42 UTC 2021


!!Linux Distribution
!!--

Debian GNU/Linux 11 \n \l PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" 
NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/; 
SUPPORT_URL="https://www.debian.org/support; 
BUG_REPORT_URL="https://bugs.debian.org/;


!!DMI Information
!!---

Manufacturer:  LENOVO
Product Name:  20CHS1V908
Product Version:   ThinkPad Helix 2nd
Firmware Version:  N17ETB2W (2.12 )
System SKU:LENOVO_MT_20CH_BU_Think_FM_ThinkPad Helix 2nd
Board Vendor:  LENOVO
Board Name:20CHS1V908


!!ACPI Device Status Information
!!---

/sys/bus/acpi/devices/ACPI0003:00/status 15
/sys/bus/acpi/devices/INT33A1:00/status  15
/sys/bus/acpi/devices/INT33D2:00/status  11
/sys/bus/acpi/devices/INT33D3:00/status  15
/sys/bus/acpi/devices/INT33D4:00/status  15
/sys/bus/acpi/devices/INT33D6:00/status  15
/sys/bus/acpi/devices/INT3400:00/status  15
/sys/bus/acpi/devices/INT3402:00/status  15
/sys/bus/acpi/devices/INT3403:00/status  15
/sys/bus/acpi/devices/INT3403:01/status  15
/sys/bus/acpi/devices/INT3403:02/status  15
/sys/bus/acpi/devices/INT3403:03/status  15
/sys/bus/acpi/devices/INT340F:00/status  15
/sys/bus/acpi/devices/INT3432:00/status  15
/sys/bus/acpi/devices/INT3433:00/status  15
/sys/bus/acpi/devices/INT3437:00/status  15
/sys/bus/acpi/devices/INT3438:00/status  15
/sys/bus/acpi/devices/INT343A:00/status  15
/sys/bus/acpi/devices/INTL9C60:00/status 15
/sys/bus/acpi/devices/INV6500:00/status  15
/sys/bus/acpi/devices/LEN0068:00/status  15
/sys/bus/acpi/devices/LNXPOWER:00/status 1
/sys/bus/acpi/devices/LNXPOWER:01/status 1
/sys/bus/acpi/devices/LNXPOWER:02/status 1
/sys/bus/acpi/devices/LNXPOWER:03/status 1
/sys/bus/acpi/devices/LNXVIDEO:01/status 15
/sys/bus/acpi/devices/NVT0001:00/status  15
/sys/bus/acpi/devices/PNP0103:00/status  15
/sys/bus/acpi/devices/PNP0C02:01/status  15
/sys/bus/acpi/devices/PNP0C0A:00/status  31

Bug#989473: choose-mirror: switch mirror list from salsa to mirror-master

[Philip Hands]

Holger Wansing  writes:

> Hi,
>
> Cyril Brulebois  wrote (Fri, 04 Jun 2021 18:39:44 +0200):
>> Filing this on behalf of Peter Palfrader who suggested we switched from
>> the manually curated mirror list hosted on salsa[1] to I suppose a live
>> one published on mirror-master[2], that would be more representative of
>> the current state of mirrors when release time approaches.
>> 
>>  1. 
>> https://salsa.debian.org/mirror-team/masterlist/raw/master/Mirrors.masterlist
>>  2. https://mirror-master.debian.org/status/Mirrors.masterlist
>
> Hmm, what exactly is the benefit?
> Sourcing a file from a git repo on Salsa seems reasonable to me, given that
> we have revision tracking there, which would be a good basis for debugging
> d-i's mirror list in case of problems or questions...

This is just changing the Makefile target that allows one to then run
`make Mirrors.masterlist` in order to update the copy of the list in the
choose-mirrors repo, so the version you care about is tracked in git.
You can see this with:

   git log | grep Update\ Mirrors.masterlist

>> Having attempted that, I'm not comfortable updating choose-mirror with
>> this change right now, as that would mean shuffling all entries.
>> 
>> A quick brainstorming on IRC resulted in what appeared to be a good idea
>> to everyone involved: the list might be random, but let's make sure we
>> show deb.d.o at the top (default entry anyway), followed by ftp.CC.d.o
>> (if there's such an entry for the given country).
>> 
>> Happy to take opinions, and possibly patches for that. :)
>
> Having deb.debian.org at the top would be an improvement, as well as having 
> ftp.CC.d.o next to it.
> However, the difference is only marginal IMHO ...

Reading the IRC chat I had assumed that reordering the masterlist might
achieve that result, but it doesn't, as a quick test showed:

  https://openqa.debian.net/tests/5976#step/mirror_selection/2

Looking at the code, the ordering is determined mostly by looking at the
Type: of the mirror:

  
https://salsa.debian.org/installer-team/choose-mirror/-/blob/master/mirrorlist#L99

which would be easy to add a line like this to:

  $rating=9 if $data[$id]->{site} eq 'deb.debian.org';

except for the slight problem that the new file is lacking almost all of
the Type: fields (it has none of the Push-Primary/Push-Secondary) stuff,
so the order you end up with is mostly based on the perl hash table
order if you use the new file, which strikes me as sub-optimal (and
explains the mess in that screenshot).

I guess we either need do one of:

 a) reinstate the Type information somehow,
which I understand is probably a problem, since the code seems to
rely on the CC mirrors having Type: Push-Primary, but since that's
actually a CNAME that may wander about maintaining that information
isn't completely straight-forward.

 b) rewrite the logic to be something like deb.d.o first, then
ftp.CC.d.o, then the rest in alphabetical order, say.

 c) filter the old masterlist to only include entries that are also in
the new list, and then use the result of that, perhaps with a tweak
to promote deb.d.o

c) is a bit of a cludge, but seems like the only one that's got a chance
of happening before the release, and gets most of the benefit of the new
list.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#989492: golang-1.16: CVE-2021-33196: archive/zip: malformed archive may cause panic or memory exhaustion

[Salvatore Bonaccorso]

Source: golang-1.16
Version: 1.16.4-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/golang/go/issues/46397
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-1.16.

CVE-2021-33196[0]:
| archive/zip: malformed archive may cause panic or memory exhaustion

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-33196
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33196
[1] https://github.com/golang/go/issues/46397

Regards,
Salvatore

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Christian Marillat]

On 05 juin 2021 09:50, Julien AUBIN  wrote:

> Le samedi 5 juin 2021, 09:14:59 CEST Christian Marillat a écrit :

[...]

>> Display driver is working but I lost nvenc support as ffmpeg is build
>> for 460 driver version.
>> 
> Hi,
>
> So first thing is that you can expect the driver to support your GPU for at 
> least 5 years from now. NVidia plans to drop the Kepler series (GeForce 6xx/
> 7xx except 750/Ti) after the NVidia 470 driver series.
>
> Now did you install Cuda stuff ?

Isn't directly cuda but libnvidia-*-encode1 package is required.

Here ffmpeg complaint about an API mismatch 11.0 vs 10.0

Christian

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Julien AUBIN]

Le samedi 5 juin 2021, 09:14:59 CEST Christian Marillat a écrit :
> On 05 juin 2021 00:41, Andreas Beckmann  wrote:
> > On 05/06/2021 00.22, Christian Marillat wrote:
> >> Where I can find a list of supported GPU ?
> >> Mine is 1050 Ti
> > 
> > That should be supported since 375.xx, you could check the PCI ID with
> > nvidia-detect or manually in
> > /usr/share/doc/nvidia*-driver/README.txt.gz
> 
> Display driver is working but I lost nvenc support as ffmpeg is build
> for 460 driver version.
> 
Hi,

So first thing is that you can expect the driver to support your GPU for at 
least 5 years from now. NVidia plans to drop the Kepler series (GeForce 6xx/
7xx except 750/Ti) after the NVidia 470 driver series.

Now did you install Cuda stuff ?

Rgds,

Bug#989491: libxstream-java: CVE-2021-29505

[Salvatore Bonaccorso]

Source: libxstream-java
Version: 1.4.15-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libxstream-java.

CVE-2021-29505[0]:
| ### Impact The vulnerability may allow a remote attacker has
| sufficient rights to execute commands of the host only by manipulating
| the processed input stream. No user is affected, who followed the
| recommendation to setup XStream's security framework with a whitelist
| limited to the minimal required types. ### Patches If you rely on
| XStream's default blacklist of the Security Framework, you will have
| to use at least version 1.4.17. ### Workarounds See
| [workarounds](https://x-stream.github.io/security.html#workaround) for
| the different versions covering all CVEs. ### References See full
| information about the nature of the vulnerability and the steps to
| reproduce it in XStream's documentation for
| [CVE-2021-x](https://x-stream.github.io/CVE-2021-x.html). ###
| Credits V3geB1rd, white hat hacker from Tencent Security Response
| Center found and reported the issue to XStream and provided the
| required information to reproduce it. ### For more information If you
| have any questions or comments about this advisory: * Open an issue in
| [XStream](https://github.com/x-stream/xstream/issues) * Email us at
| [XStream Google Group](https://groups.google.com/group/xstream-user)


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-29505
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29505
[1] https://github.com/x-stream/xstream/security/advisories/GHSA-7chv-rrw6-w6fc

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Christian Marillat]

On 05 juin 2021 00:41, Andreas Beckmann  wrote:

> On 05/06/2021 00.22, Christian Marillat wrote:
>> Where I can find a list of supported GPU ?
>> Mine is 1050 Ti
>
> That should be supported since 375.xx, you could check the PCI ID with
> nvidia-detect or manually in
> /usr/share/doc/nvidia*-driver/README.txt.gz

Display driver is working but I lost nvenc support as ffmpeg is build
for 460 driver version.

,
| [h264_nvenc @ 0x55c9751fd700] Driver does not support the required nvenc API 
version. Required: 11.0 Found: 10.0
`

Christian

Bug#989451: [5.10.x] Please backport "net: usb: cdc_ncm: don't spew notifications" (de658a195ee23ca6aaffe197d1d2ea040beea0a2)

[Salvatore Bonaccorso]

Control: tags -1 + pending

On Fri, Jun 04, 2021 at 05:42:28PM -0700, Josh Triplett wrote:
> On Fri, Jun 04, 2021 at 12:38:57PM -0400, Sasha Levin wrote:
> > On Fri, Jun 04, 2021 at 09:12:56AM -0700, Josh Triplett wrote:
> > > Some USB Ethernet devices using the cdc_ncm driver produce several of
> > > these messages per second:
> > > 
> > > Jun 03 19:25:17 s kernel: cdc_ncm 3-2.2:2.0 enx(mac address): 1000 mbit/s 
> > > downlink 1000 mbit/s uplink
> > > 
> > > This results in substantial log noise and disk usage.
> > > 
> > > Please consider backporting
> > > net: usb: cdc_ncm: don't spew notifications
> > > (git commit de658a195ee23ca6aaffe197d1d2ea040beea0a2)
> > > to the 5.10.x stable kernel, to fix this problem.
> > 
> > Queued up, thanks!
> 
> Thank you!

Pending for the next upload:
https://salsa.debian.org/kernel-team/linux/-/commit/79a7260df594af1e629651ad095b8ed2a7a44ede

Regards,
Salvatore