Bug#987169: RFS: newlib/3.3.0-1.1 [NMU] -- C library and math library for embedded systems

[Tobias Frost]

Control: tags -1 moreinfo

On Sun, 18 Apr 2021 19:29:00 + John Scott  wrote:

(note, I did not look at the package, this are general remarks.
But at least you should target experimental, so that's why I tag it moreinfo for
now.)

> Changes since the last upload:
> 
>  newlib (3.3.0-1.1) unstable; urgency=medium
>  .
>    * Non-maintainer upload.
>    * Add newlib-source binary package to aid building for new targets.
>  (Closes: #912271)
> 
> This change wouldn't normally be appropriate for an NMU, but the
> maintainer, Agustin Henze, hasn't been responsive to my attempts for
> contact, and is also on the LowThresholdNmu list and keeps the package
> in the Debian group on Salsa for collaborative maintenance:
>   https://wiki.debian.org/LowThresholdNmu
> 
> I haven't encountered the maintainer previously, but believe in good
> faith that these changes would be welcome and that the LowThresholdNmu
> criterion are met by addressing a bug with important severity. My
> interest in this bug, to introduce a newlib-source binary package, is
> to unblock my progress on gcc-sh-elf, which is otherwise almost ready.

Probably still a good idea to CC them or file a bug in the BTS to document
your intentions, as adding a binary package is not a usual change, even
if the NMU criterias are fulfilled.

 Alternatively, you should consider ITS'ing the package.
At least from your description it sounds as it would be a valid candidate, but I
didn't check the details. 

> That package will bootstrap a toolchain by building GCC and Newlib
> simultaneously in a combined build tree, which in my opinion is best
> practice for embedded toolchains going forward.
> 
> The changelog is set to unstable in anticipation that I won't manage to
> clear NEW before Bullseye is released. If anyone would be so kind to
> sponsor me sooner, I could change that to experimental.

please change to experimental. (Its anyway _always_ a good idea to clear NEW
first via experimental…)

-- 
tobi

Bug#989322: Please include systemd service and timer

[Eric Dorland]

Package: borgmatic
Version: 1.5.12-2
Severity: wishlist

Generally users of borgmatic want a low configuration overhead for their 
backups. It would be great if the sample systemd service and timers were 
included by default so less configuration was needed up front.


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

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

Versions of packages borgmatic depends on:
ii  borgbackup 1.1.16-1
ii  python33.9.2-3
ii  python3-colorama   0.4.4-1
ii  python3-pkg-resources  52.0.0-3
ii  python3-pykwalify  1.8.0-1
ii  python3-requests   2.25.1+dfsg-2
ii  python3-ruamel.yaml0.16.12-2

borgmatic recommends no packages.

borgmatic suggests no packages.

-- no debconf information

Bug#984901: RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 -- firmware for AR7010 and AR9271 USB wireless adapters

[Tobias Frost]

Control: tags -1 moreinfo

On Tue, Jun 01, 2021 at 02:22:15AM +, John Scott wrote:
> Control: tags -1 -moreinfo
> 
> On Mon, 2021-05-31 at 20:25 +0200, Tobias Frost wrote:
> > I've took a look at your package:
> Awesome, thanks.
> 
> > - d/copyright: 
> >  - The word "Comment:" went missing after the Files-Exlucded section.
> I don't believe this is an error. The Files-Excluded field is currently
> not specified by the machine-readable copyright specification (this is
> bug #685506), but at least the mk-origtargz manual page specifies that
> this should be what the spec calls 'formatted text', i.e. the current
> syntax should be valid:
> > (In debian/copyright, the Files-Excluded and Files-Excluded-component
> > stanzas are a part of the first paragraph and there is a blank line
> > before the following paragraphs which contain Files and other
> > stanzas. See uscan(1) "COPYRIGHT FILE EXAMPLE".)

The Files-Excluded section is used by tools like uscan to strip files from the
orig.tar.  The formatted text just says that the field can extend over multiple
lines, it does not mean its free text without meaning.
TL;DR: I'm pretty sure you want the Comment: here. A quick test with
uscan --verbose --force-download will convince you too.

> >  - Please review the file. I see e.g the section for "Files: *" be
> > gone, not sure if that is intentional (I did not a d/copyright
> > review)
> This was intentional.
> 
> > Lintian is the same oppionion that there is something missing:
> > 
> > W: open-ath9k-htc-firmware source: file-without-copyright-information
> > .gitignore
> > W: open-ath9k-htc-firmware source: file-without-copyright-information
> > NOTICE.TXT
> > W: open-ath9k-htc-firmware source: file-without-copyright-information
> > README
> Those files have no copyright information, but they are so small
> they're probably not copyrightable. There s no copyright status to
> associate with them, so it's better that the copyright file say nothing
> at all with respect to them.

I'm sorry; no.

You cannot assume that those files are not copyrightable, at minimum
that would be a question for debian-legal. Generally, copyrightabilty is a very 
low
barrier.
Looking at NOTICE.TXT it is definitly copyrightable and has even a copyright
statement, for example.
Looking at README, it is also definitly beyond that barrier.

*Usually* (I didnt check this particular case) such companion files in the
repo are under the same license that the other files, thereofore usually
the debian/* stanca is fine.

Strictly, if there is no copyright information, it defaults to "all rights
reserved", which means "not even distributeable."
So if in doubt, you need to ask upstream to clarify.

I guess it would be just easier to reinstanciate the * section, as ftp masters
have at least one time looked at it already and found it ok.

> >  - W: open-ath9k-htc-firmware source: inconsistent-appstream-
> > metadata-license  
> >debian/firmware-ath9k-htc.metainfo.xml (mit != expat)
> In my opinion this is a bug that could be fixed in Lintian. If you're
> not aware, the Expat license is a specific version of what's commonly
> known as the MIT license. The SPDX identifier (and hence the identifier
> used in the AppStream file) is MIT, although the Debian machine-
> readable copyright specification requests that one refer to the Expat
> license when that license is applicable.
> 
> Basically, the copyright file referring to the Expat license is
> consistent with the AppStream metadata proclaiming that it is subject
> to the MIT license.

OK, in this case an override and a comment towards the override would
be helpful. Bonus points for filing a bug against lintian.

> > Some patch have fuzz... maybe refresh?
> If you're referring to
> Hunk #1 succeeded at 43 (offset -1 lines).
> Hunk #2 succeeded at 55 (offset -1 lines).
> Hunk #3 succeeded at 99 (offset -1 lines).
> Hunk #4 succeeded at 113 (offset -1 lines).
> Hunk #5 succeeded at 151 (offset -1 lines).
> then I believe this is normal, although refreshing the patches upstream
> shouldn't hurt.

Certainly it does not hurt to refresh.

-- 
Cheers, 
tobi

Bug#989321: lxrandr: HDMI monitor NOT recognized. NO signal on monitor.

[Sergio]

Package: lxrandr
Version: 0.3.2-1+b1
Severity: normal
X-Debbugs-Cc: wowiamh...@gmail.com

Dear Maintainer,

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

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

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


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

Versions of packages lxrandr depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  x11-xserver-utils7.7+8

lxrandr recommends no packages.

lxrandr suggests no packages.


*** /home/user1/Documents/no_hdmi_bullseye
Hello

I have a Lenovo Mobile Workstation P15 with a Nvidia Quadro T1000 graphics card
and 1 hdmi port.
It came with Windows 10 Pro.
Everything works fine from Windows.

I partitioned disk and installed Debian Bullseye.
After installing, there is NO signal on the HDMI monitor.

When I power up the computer, the startup shell can be seen on BOTH monitors.
But when Debian boots up, the HDMI monitor goes black and only the laptop's
monitor registers.
When I navigate to Monitor Settings or Display Settings, no second monitor
shows.

I installed the Nvidia drivers after installing nvidia-detect.

Please help me resolve issue.

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

How would YOU feel if a system upgrade destroyed an (old yet) perfectly working
piece of important hardware? What if it destroyed another piece of similar
hardware a few days later?
How would you feel if all those days you had no support or feedback from anyone
that created that upgrade?
How would you feel if the only advice you were given changed absolutely nothing
and did not even prevent the loss of the second piece of hardware?
Btw, the word "tainted" has to be the worst characterization for a kernel that
must use a specific out-of-tree driver in order to make the related hw work at
100% of its capabilities.

>From my point of view, all I see is a kernel that destroyed my hardware TWICE,
thus the raise of severity to critical, because it did break the entire system
hardware wise. The sad thing is that your attention was drawn after I raised
it.
And all the above can result to one thing from my side: anger. And don't expect
me to lower my tone while being angry.

As for the logs, please tell me where to find them and I will zip them and send
them straight to your email if you wish. And not only the ones from 5.10.38/40,
ALL 50/100/any number of logs systemd has kept.
On the other hand, how hard would it be to build a kernel with the latest
update but with the config used for 5.10.28? I did check the differences
between config-5.10.0-6-amd64 and config-5.10.0-7-amd64 last week, but I admit
I am not smart enough to see which change could cause all this mess.

Bug#989320: apt-file search

[Roger D. Cook]

$ apt-file find libwine.so
libwine: /usr/lib/x86_64-linux-gnu/wine/libwine.so.1
libwine: /usr/lib/x86_64-linux-gnu/wine/libwine.so.1.0
libwine-dev: /usr/lib/x86_64-linux-gnu/wine/libwine.so
libwine-development: 
/usr/lib/x86_64-linux-gnu/wine-development/libwine.so <---

libwine-development: /usr/lib/x86_64-linux-gnu/wine-development/libwine.so.1
libwine-development: 
/usr/lib/x86_64-linux-gnu/wine-development/libwine.so.1.0
libwine-development-dev: 
/usr/lib/x86_64-linux-gnu/wine-development/libwine.so <---

$

Bug#989320: libwine-development-dev: libwine-development and libwine-development-dev both supply libwine.so

[Roger D. Cook]

Package: libwine-development-dev
Version: 5.22+repack-1
Severity: normal

Dear Maintainer,

I was attempting to upgrade all installed packages. libwine-development was to 
be upgraded from 5.19+repack-1 to 5.22+repack-1, as well as 
libwine-development-dev from 5.19+repack-1 to 5.22+repack-1. 
libwine-development-dev upgraded successfully, but libwine-development did not:

roger@rogerhp:~$ sudo apt-get full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 libwine-development : Breaks: libwine-development:i386 (!= 5.19+repack-1) but 
5.22+repack-1 is installed
 libwine-development:i386 : Recommends: libodbc1:i386 (>= 2.3.1) but it is not 
installed
Recommends: gstreamer1.0-plugins-good:i386 but it 
is not installed
Breaks: libwine-development (!= 5.22+repack-1) but 
5.19+repack-1 is installed
 libwine-development-dev : Depends: libwine-development (= 5.22+repack-1) but 
5.19+repack-1 is installed
 wine64-development : Depends: libwine-development (= 5.22+repack-1) but 
5.19+repack-1 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).
$
$
$ sudo apt-get --fix-broken install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  libwine-development
The following packages will be upgraded:
  libwine-development
1 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
9 not fully installed or removed.
Need to get 0 B/76.9 MB of archives.
After this operation, 36.1 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 778201 files and directories currently installed.)
Preparing to unpack .../libwine-development_5.22+repack-1_amd64.deb ...
Unpacking libwine-development:amd64 (5.22+repack-1) over (5.19+repack-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libwine-development_5.22+repack-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/wine-development/libwine.so', 
which is also in package libwine-development-dev 5.22+repack-1
Errors were encountered while processing:
 /var/cache/apt/archives/libwine-development_5.22+repack-1_amd64.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
$

Expected result: Successful upgrade of both packages. 

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable')
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libwine-development-dev depends on:
ii  libc6-dev [libc-dev]  2.31-12
ii  libwine-development   5.19+repack-1

Versions of packages libwine-development-dev recommends:
iu  wine64-development-tools  5.22+repack-1

libwine-development-dev suggests no packages.

Versions of packages wine-development depends on:
iu  wine32-development  5.22+repack-1
iu  wine64-development  5.22+repack-1

Versions of packages wine-development suggests:
pn  dosbox
pn  exe-thumbnailer | kio-extras  
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
ii  winetricks0.0+20210206-2

Versions of packages libwine-development depends on:
ii  libasound2   1.2.4-1.1
ii  libc62.31-12
ii  libfaudio0   21.02-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libglib2.0-0 2.66.8-1
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libgstreamer-plugins-base1.0-0   1.18.4-dmo1
ii  libgstreamer1.0-01.18.4-2
ii  liblcms2-2   2.12~rc1-2
ii  libldap-2.4-22.4.57+dfsg-3
ii  libmpg123-0  1.26.4-1
ii  libopenal1   1:1.19.1-2
ii  libpcap0.8   1.10.0-2
ii  libpulse014.2-2
ii  libudev1 247.3-5
ii  libunwind8   1.3.2-2
ii  libvkd3d11.1-5
ii  libx11-6 2:1.7.1-1
ii  libxext6 2:1.3.3-1.1
ii  libxml2 

Bug#984901: RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 -- firmware for AR7010 and AR9271 USB wireless adapters

[John Scott]

Control: tags -1 -moreinfo

On Mon, 2021-05-31 at 20:25 +0200, Tobias Frost wrote:
> I've took a look at your package:
Awesome, thanks.

> - d/copyright: 
>  - The word "Comment:" went missing after the Files-Exlucded section.
I don't believe this is an error. The Files-Excluded field is currently
not specified by the machine-readable copyright specification (this is
bug #685506), but at least the mk-origtargz manual page specifies that
this should be what the spec calls 'formatted text', i.e. the current
syntax should be valid:
> (In debian/copyright, the Files-Excluded and Files-Excluded-component
> stanzas are a part of the first paragraph and there is a blank line
> before the following paragraphs which contain Files and other
> stanzas. See uscan(1) "COPYRIGHT FILE EXAMPLE".)

>  - Please review the file. I see e.g the section for "Files: *" be
> gone, not sure if that is intentional (I did not a d/copyright
> review)
This was intentional.

> Lintian is the same oppionion that there is something missing:
> 
> W: open-ath9k-htc-firmware source: file-without-copyright-information
> .gitignore
> W: open-ath9k-htc-firmware source: file-without-copyright-information
> NOTICE.TXT
> W: open-ath9k-htc-firmware source: file-without-copyright-information
> README
Those files have no copyright information, but they are so small
they're probably not copyrightable. There s no copyright status to
associate with them, so it's better that the copyright file say nothing
at all with respect to them.

>  - W: open-ath9k-htc-firmware source: inconsistent-appstream-
> metadata-license  
>debian/firmware-ath9k-htc.metainfo.xml (mit != expat)
In my opinion this is a bug that could be fixed in Lintian. If you're
not aware, the Expat license is a specific version of what's commonly
known as the MIT license. The SPDX identifier (and hence the identifier
used in the AppStream file) is MIT, although the Debian machine-
readable copyright specification requests that one refer to the Expat
license when that license is applicable.

Basically, the copyright file referring to the Expat license is
consistent with the AppStream metadata proclaiming that it is subject
to the MIT license.

> Some patch have fuzz... maybe refresh?
If you're referring to
Hunk #1 succeeded at 43 (offset -1 lines).
Hunk #2 succeeded at 55 (offset -1 lines).
Hunk #3 succeeded at 99 (offset -1 lines).
Hunk #4 succeeded at 113 (offset -1 lines).
Hunk #5 succeeded at 151 (offset -1 lines).
then I believe this is normal, although refreshing the patches upstream
shouldn't hurt.


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

Bug#989319: Sylpheed: inbox messages missing

[José Luis González]

Package: sylpheed
Version: 3.7.0-4
Severity: critical
Tags: upstream

Since about a month or two Sylpheed isn't showing me my inbox messages. However 
it's printed 0/n total, with n > 0.

Bug#989318: GNOME network manager: security hole

[José Luis González]

Package: gnome-network-manager
Version: 1.14.6-2+deb10u1
Severity: critical

GNOME Network Manager takes too long to update its status in the system tray 
sometimes.

Bug#989317: Acknowledgement (systemd kill background processes after user logs out (#825394 regression))

[Matt Corallo]

The following work-around appears to work:

(a) ssh in and spawn screen, (b) disconnect the ssh session which spawned screen, (c) ssh to open a new session, (d) log 
back into screen, (e) spawn a container from inside screen.


On 5/31/21 20:51, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 989317: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989317.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian systemd Maintainers 

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.

Bug#989317: systemd kill background processes after user logs out (#825394 regression)

[Matt Corallo]

Package: systemd
Version: 247.3-5

After upgrading to bullseye on a test machine, spawning an lxc container with systemd-run[1] still kills the lxc 
container after the spawning shell is closed (and the user logs out). No only does the lxc container eventually get 
killed, but systemd refuses any further login for the user while it waits for the lxc container to die (something like 
maybe 30 seconds for a simple lxc container running an sshd service), making it appear the system has hung.


This doesn't appear to be resolved by the options suggested in the man page for systemd-run like `loginctl 
enable-linger` or `KillUserProcesses=no` (which appears to still be the default).


Matt

[1] eg systemd-run --user -p "Delegate=yes" --unit=fuzzer -- lxc-start --name 
fuzzer -- /usr/sbin/sshd -D

Bug#989316: pcscd: very long delays in apps configured to use reader

[Maurizio Avogadro]

Package: pcscd
Version: 1.9.1-1
Severity: important

Dear Maintainer,

when adding a Bit4ID miniLector CIE Plus smartcard reader to nssdb, Chromium
becomes unable to connect to SSL websites.

The reader, actually a rebranded FEITIAN R502-Dual, has 4 slots: 
contactless,

contact and 2 SAM slots well hidden under the device; as stated by the user
manual, the SAM slots don't support hotplug and the SIM cards should be
inserted before plugging the reader to the USB port.

The pcscd log shows that the daemon is constantly trying to power on 
some card
(the empty SAM slots?) and this introduces a huge delay that easily 
makes the

browser reach the timeout.

The same happens when loading the opensc-pkcs11.so library in Firefox 
and this

renders the browsers unusable with the reader.

Can you do something, or should I submit this issue to the hardware vendor?

Attaching the full output of lsusb -vvv and some snippets from the pcscd 
log.


Thanks!



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

Kernel: Linux 5.12.8-xanmod1 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pcscd depends on:
ii init-system-helpers 1.60
ii libc6 2.31-12
ii libccid [pcsc-ifd-handler] 1.4.34-1
ii libpcsclite1 1.9.1-1
ii libsystemd0 247.3-5
ii libudev1 247.3-5
ii lsb-base 11.1.0

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii systemd 247.3-5

Bus 003 Device 012: ID 25dd:3503 BIT4ID mLector AIR DI V3
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize032
  idVendor   0x25dd 
  idProduct  0x3503 
  bcdDevice3.51
  iManufacturer   1 BIT4ID
  iProduct2 mLector AIR DI V3
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x014b
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  160mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass11 Chip/SmartCard
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  4 miniLector AIR DI v3 CLESS
  ChipCard Interface Descriptor:
bLength54
bDescriptorType33
bcdCCID  1.00
nMaxSlotIndex   0
bVoltageSupport 1  5.0V 
dwProtocols 2  T=1
dwDefaultClock   4000
dwMaxiumumClock  4000
bNumClockSupported  0
dwDataRate  10752 bps
dwMaxDataRate  688172 bps
bNumDataRatesSupp. 44
dwMaxIFSD 252
dwSyncProtocols  0007  2-wire 3-wire I2C
dwMechanical  
dwFeatures   000404BE
  Auto configuration based on ATR
  Auto activation on insert
  Auto voltage selection
  Auto clock change
  Auto baud rate change
  Auto PPS made by CCID
  Auto IFSD exchange
  Short and extended APDU level exchange
dwMaxCCIDMsgLen   271
bClassGetResponseecho
bClassEnvelope   echo
wlcdLayout   none
bPINSupport 0 
bMaxCCIDBusySlots   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0020  1x 32 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0020  1x 32 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN

Bug#989315: composer: Needs update for GitHub token format change

[anomie]

Package: composer
Version: 2.0.9-2

On March 4, 2021, GitHub announced a change to the format of their
tokens: 
https://github.blog/changelog/2021-03-04-authentication-token-format-updates/

A few days later, Composer updated their token validation regex to
account for the new token format: 
https://github.com/composer/composer/commit/dc83ba93f3d8a35629f9a387632e8cd373a144d0#diff-0ad46c42da3ec5293b4b4df61bb6c837304d5e72f1a434ba3cff31c0f3e44934

It looks like Debian is still on 2.0.9 for the Bullseye freeze, implying
that Bullseye will release with 2.0.9. You may want to backport the
above fix so that people can use new format GitHub tokens with composer.

Bug#989312: RFS: ircii/20210314+really20190117-1 [QA] [RC] -- Internet Relay Chat client

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: ircii
   Version : 20210314+really20190117-1
   Upstream Author : [fill in name and email of upstream]
 * URL : http://www.eterna.com.au/ircii/
 * License : MIT-Old-Style-with-legal-disclaimer-2,
public-domain, BSD-2-Clause, Custom, GPL-2.0+, BSD-3-Clause
 * Vcs : https://salsa.debian.org/debian/ircii
   Section : net

It builds those binary packages:

  ircii - Internet Relay Chat client

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/i/ircii/ircii_20210314+really20190117-1.dsc

Changes since the last upload:

 ircii (20210314+really20190117-1) unstable; urgency=medium
 .
   * QA upload.
   * Revert to previous release, because of freeze.
   * Add patch to Fix CVE-2021-29376 Closes: #986214


I got confirmation that this release will be unblocked and accepted into
testing [0]

Regards,
Håvard

[0] https://bugs.debian.org/989273

Bug#989314: unblock: mksh/59c-8

[Thorsten Glaser]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de
Control: block -1 by 989279

Please unblock package mksh

[ Reason ]
This upload addresses the following issues:
• Work around #988027 in klibc (which is a POSIX violation but
  apparently deliberate by upstream) by using {set,long}jmp
  instead of sig{set,long}jmp when not saving/restoring signals
  (cherry-pick from upstream)
• Rebuild against klibc with #943425 ({set,long}jmp on s390x use
  wrong registers) fixed
• Cherry-pick another two upstream memory leak fixes
• Backport just enough (for Debian) of upstream patch fixing the
  way control characters are escaped when showing variable contents
  (for reentrancy or when deliberately escaping with ${varname@Q});
  specifically, escape C1 control characters dependent on whether
  utf8-mode is on (UTF8-encoded) or off (bytewise), catching some
  situations in which they were not escaped properly, make the
  escaped output match the UTF-8 mode better, and add a shell option
  “asis” to allow \x80‥\x9F unescaped outside(!) of UTF-8 mode only
  for when the user uses a codepage that has them as printable, not
  control, characters

(There’s also a one-line d-ports-only change of no relevance to
the release architectures.)

[ Impact ]
• Potential (but minor; except on s390x, the testsuite didn’t catch
  anything) misbehaviour of the klibc-built binaries; outdated
  Built-Using for klibc once 2.0.8-6.1 migrates
• Minor memory leaks
• Attempting to display a variable escaped (“typeset -p varname”,
  “set | grep ^varname”) may send control sequences to the terminal,
  including sequences that cause xterm to, for example, dump the
  current terminal contents to files

[ Tests ]
The testsuite is very throughout (it did catch the s390x/klibc issue
and switched the mksh-static and lksh binary to musl for that); it
also proves the klibc change works. I’ve manually verified the escaping-
related changes. I’ve not verified the memory leaks separately, but
the codepaths are like this that, if they were wrong (e.g. use-after-
free), the testsuite (especially on MirBSD with malloc hardening)
would’ve caught it crashing.

I’ve run a number of scripts comparing output with the previous and
the binaries from this upload installed.

[ Risks ]
As I wrote in earlier unblock requests (#987975, #986431) mksh is
effectively leaf in Debian, and changes like these are low risk.

I’ve reduced the upstream commits related to escaping to include
only the necessary parts to make reviewing easier. This carries
some, but very low, risk. The tests would have caught mistakes
during that (incidentally, they did, when I removed a hunk which
I at first thought not necessary).


[ 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 ]
I’m attaching a diff of the unpacked trees instead of debdiff(1)
output again because I use single-debian-patch here and that’d
be a nightmare to review. I’ve commented in the diff which hunks
match which issue.

I’m also attaching a “diff -w” of the file misc.c to make review
easier; a huge part of the escaping code lost one level of indent.

I’ll be uploading another escaping-related fix revision, similar
issues (C0/C1 control characters and DEL) but in the command line
editor and tab completion code, but I have yet to find the time
to actually fix these issues first and think that including what
we’ve already got in sid into testing right now is a good thing.


unblock mksh/59c-8
diff -pruN mksh_59c-6/debian/changelog mksh_59c-8/debian/changelog
--- mksh_59c-6/debian/changelog	2021-05-03 03:26:28.0 +0200
+++ mksh_59c-8/debian/changelog	2021-05-31 02:42:55.0 +0200
@@ -1,3 +1,26 @@
+mksh (59c-8) unstable; urgency=medium
+
+  * Fix a -Wpointer-sign in escaping code
+  * Shrink escape diff (algorithm unchanged) for easier review
+
+ -- Thorsten Glaser   Mon, 31 May 2021 02:42:55 +0200
+
+mksh (59c-7) unstable; urgency=medium
+
+  * Do not use sigsetjmp(…, 0) with klibc (cf. #988027)
+  * Cherry-pick upstream memory leak fixes
+  * Apply just enough upstream changes to address more escaping
+issues: for ${var@Q} and “typeset -p”, take UTF-8 mode (on/off)
+into account; don’t issue \u escapes outside of UTF-8 mode,
+don’t escape nōn-ASCII printable, that is, nōn-control characters;
+always escape C0 controls and DEL; escape C1 controls by default,
+but add an option “asis” to disable that (e.g. for DOS codepages)
+in nōn-UTF8 mode — note this will need fixing for tab completion,
+command line editing (in a subsequent upload)…
+  * Work around hppa buildd issue (same as m68k, sh4)
+
+ -- Thorsten Glaser   Sun, 30 May 2021 23:57:59 +0200
+
 mksh (59c-6) unstable; urgency=medium
 
   * Clear “taint” on most actions mutating a variable

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[Adrian Bunk]

Control: reassign -1 libhamlib4 4.0-6
Control: fixed -1 4.1-1
Control: affects -1 cubicsdr
Control: forwarded -1 
https://sourceforge.net/p/hamlib/code/ci/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0/

On Sat, Mar 06, 2021 at 06:18:43PM +0100, Bernhard Übelacker wrote:
> Dear Maintainer,
> I found this interesting and tried to reproduce inside
> a minimal VM and it crashed.
> 
> 
> > > Hmm. Can exit() lead to segfaults in threaded programs?
> 
> It looks like it does. exit() would call __run_exit_handlers, that
> might to run some destructors while the other thread is at least
> in my example still in SoapySSDPEndpoint::getServerURLs.
> 
> 
> I tried to track down why the exit is called in the first place
> and I guess this is because rig_load_all_backends is called twice.
> 
> First once here:
> #2  0x7fcd9fbdc655 in rig_load_all_backends () at 
> ../../src/register.c:459
> #3  0x562467ef9177 in RigThread::enumerate() () at 
> ./src/rig/RigThread.cpp:26
> #4  0x562467ddf0b4 in CubicSDR::OnInit() (this=0x5624680dc910) at 
> ./src/CubicSDR.cpp:259
> #5  0x7fcd9f12da72 in wxEntry(int&, wchar_t**) () at 
> /lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
> #6  0x562467dd6c02 in main(int, char**) (argc=, 
> argv=) at ./src/CubicSDR.cpp:28
> https://github.com/cjcliffe/CubicSDR/blob/master/src/rig/RigThread.cpp#L28
> 
> 
> And second in another thread from here:
> ...
> #6  0x7fcd9fbdc655 in rig_load_all_backends () at 
> ../../src/register.c:459
> #7  0x7fcd8400f1cf in findAudio(SoapySDR::Kwargs const&) () at 
> ./Registration.cpp:90
> ...
> #25 ... (SoapySSDPEndpoint::*)(int, long), SoapySSDPEndpoint*, int, long> 
> >&&)::{lambda()#1}> > >::_M_run() (this=0x7fcd880018a0) at 
> /usr/include/c++/10/thread:215
> #28 0x7fcd9ec1ced0 in std::execute_native_thread_routine(void*) 
> (__p=0x56246ac320d0) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:80
> #29 0x7fcd9e9d6ea7 in start_thread (arg=) at 
> pthread_create.c:477
> #30 0x7fcd9e906def in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> https://github.com/pothosware/SoapyAudio/blob/master/Registration.cpp#L90
> Seems originating from the global static initialization
> in Registration.cpp:112, which is done in threads for some reason.
> 
> 
> Therefore in the second call the rig_hash_table
> is already populated and the exit is called.
> 
> And due to the threaded nature the crash could
> happen at different places.

The oneline fix for hamlib above matches your analysis exactly.

> Kind regards,
> Bernhard

cu
Adrian

Bug#988248: chiaki: No audio because of missing `libqt5multimedia5-plugins` package dependency

[Adrian Bunk]

On Mon, May 31, 2021 at 10:22:17PM +0200, IOhannes m zmölnig wrote:
> i just downgraded the severity from "grave" to "important".
> 
> ```
> grave
> makes the package in question unusable or mostly so, or causes data
> loss, or introduces a security hole allowing access to the accounts of users
> who use the package.
> 
> important
> a bug which has a major effect on the usability of a package, without
> rendering it completely unusable to everyone.
> ```
> 
> the missing plugins do *not* make the package unusable, it just won't output
> sound.
> there's also no data loss or security hole involved.
> so i don't think that the bug warrants a severity "grave".
> 
> otoh, no sound might indeed have "a major effect on the usability", yet
> doesn't "render[ing] it completely unusable to everyone" (e.g. to those who
> don't need sound).
> 
>   
> 
> also, per debian-policy §7.2, the dependency should be a "Recommends" rather
> than a "Depends":
> 
> ```
> Recommends
> 
> This declares a strong, but not absolute, dependency.
> 
> The Recommends field should list packages that would be found together
> with this one in all but unusual installations.
> ```

Are you only arguing bug severities or preparing an  NMU with a fix?

Recommends sounds OK if you are doing the NMU.

Otherwise I'll prepare in an NMU with a Depends since that would sound 
more correct to me.

cu
Adrian

Bug#988248: chiaki: No audio because of missing `libqt5multimedia5-plugins` package dependency

[Debian/GNU]

i just downgraded the severity from "grave" to "important".

```
grave
makes the package in question unusable or mostly so, or causes data 
loss, or introduces a security hole allowing access to the accounts of 
users who use the package.


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

```

the missing plugins do *not* make the package unusable, it just won't 
output sound.

there's also no data loss or security hole involved.
so i don't think that the bug warrants a severity "grave".

otoh, no sound might indeed have "a major effect on the usability", yet 
doesn't "render[ing] it completely unusable to everyone" (e.g. to those 
who don't need sound).




also, per debian-policy §7.2, the dependency should be a "Recommends" 
rather than a "Depends":


```
Recommends

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found 
together with this one in all but unusual installations.

```


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989313: unblock: google-oauth-client-java/1.28.0-2

[Olek Wojnar]

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

Dear Release Team,

Please unblock package google-oauth-client-java

[ Reason ]
Backport of fix for RC security issue (CVE-2020-7692)
https://security-tracker.debian.org/tracker/CVE-2020-7692
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988944

[ Impact ]
Security issue in bullseye or the removal of the entire Bazel build system.

[ Tests ]
The bazel-bootstrap package has a comprehensive test suite that uses the
code
in this package and therefore indirectly tests it. Also, please see next
section.

[ Risks ]
Two packages build-depend on this package (google-api-client-java and
bazel-bootstrap). I have built and tested both of them locally against the
new version of this package and they both build and test correctly.

[ 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 ]
This upload includes a VCS commit from tony mancill which corrects a
previously-undeclared build dependency from his 1.28.0-1 packaging. It is a
trivial QC change and, as you can see in the debdiff, over 99% of this
upload
is a backport of the upstream fix for this security vulnerability.

Also, this is my first security bug so please let me know if I'm missing
anything in the process! Thanks!

-Olek


google-oauth-client-java.debdiff
Description: Binary data


OpenPGP_signature
Description: OpenPGP digital signature

Bug#988923: RFS: distorm3/3.5.2b-1 -- powerful disassembler library for x86/AMD64 binary streams (Python3 bindings)

[Tobias Frost]

Control: tags -1 moreinfo

On Mon, 31 May 2021 15:58:56 +0200 Adam Borowski  wrote:
> On Fri, May 21, 2021 at 02:51:36PM +, Lin Qigang wrote:
(...)
> Hi!
> This upload is targetted at unstable, which is currently affected by the
> hard freeze.  Only targetted fixes are permitted, not whole new upstream
> releases (unless the upstream release consists of nothing but fixes...).
> 
> Thus, your options here would be:
>  * targetting experimental instead, or
>  * waiting until after Bullseye is released
> 

Tagging moreinfo for now because of that.

Bug#988329: RFS: usbredir/0.9.0-1 -- Simple USB host TCP server

[Tobias Frost]

Control: retitle -1 usbredir/0.9.0-1 -- [ITA] Simple USB host TCP server
Control: tags -1 moreinfo

(Retitling the RFS bug to indicate that this an ITA.)

On Mon, 10 May 2021 16:08:10 + LQi254  wrote:

> This is my first package and I am very excited!

I just wanted to give you a short heads-up why you maybe did not get an response
already.

First, many thanks for contributing to Debian and wanting to adpopt usbredi.
This is very appreciated..

However, its also a bit complicated, but dont worry, its not that hard to learn
all the stuff :) I'll switch to bit more verbose mode ; apologizes if I tell you
something you know already… If you miss some information, just ask.

Debian is currently frozen, so new packages should comply with the release team
policy; that means that your package is currently not within the scope for
permissible, at least not to unstable. What's possible is going for experimental
or wait until bullseye is released.

Regarding the adoption, you should reply to the orphaning bug (#911431),
indicating there that you want to adopt the package by retitling ^this^ bug to
start with "ITA:" (stands for Intent to Adopt) and set yourself as maintainer.
You would also then state that in the debian/changelog, closing
the #911431 with the changelog (the developers reference should have a paragraph
on the details how to adopt an orphaned package)

Otherwise, the mentors package page lists a few lintian messages, which should
be fixed as well, like those:

 W package-uses-deprecated-debhelper-compat-version
 I out-of-date-standards-version
 I public-upstream-key-not-minimal
 P insecure-copyright-format-uri
 P silent-on-rules-requiring-root
 X upstream-metadata-file-is-missing

The description of the lintian tags should give you some hints, otherwise please
feel free to ask here.

I've tagged this RFS bug as "moreinfo". That indicates that you need to update 
your package and indicate what way (wait or experimental) you want to pursuit.
Just remove the tag when ready for a second round of review.

-- 
Cheers,
tobi

Bug#987566: ghostscript: PDF Interpreter error on armel

[Adrian Bunk]

On Tue, May 18, 2021 at 02:52:02PM +0200, Bernhard Übelacker wrote:
> Hello Guilhem, hello Jonas,
> might this be a similar or the same issue as in #942055 ?
> 
> I took the example file from this issue,
> created an armel buster chroot and ran it once at my arm5tel device,
> and once at a armv7l cpu android device (unfortunately with
> a non-debian kernel).
> 
> - with the arm5tel cpu I received the "Error reading" message.
> - with the arm7l cpu no such failure and much more output was produced.
> 
> The same test with the arm5tel cpu with a bullseye chroot
> seems also not affected.
> 
> Therefore my suspicion that gcc in buster produces instructions,
> which do not work as expected at arm5tel, just at arm7l cpus.
>...

Based on the versions you mentioned in #942055,
gcc 7 -> 8 would match when it started.
This change also bumped the armel baseline armv4t -> armv5te.

#975977 comes into my mind as a similar bug in a different package.

> Kind regards,
> Bernhard
>...

cu
Adrian

Bug#989311: krb5-user: k5login_directory does not work

[Will Gnann]

Package: krb5-user
Version: 1.18.3-5
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   I need to use ksu to allow some users to access some accounts within
   my network. Since their homes are in a NFS export, I cannot use the
   ~luser/.k5login approach.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I have updated the krb5-user version to the testing one and it does
 not solve the problem. I read the source code and the correct
 behavior seems to be there as well.
  
   * What was the outcome of this action?
   It does not work. ksu showed the prompt to type password despite the
   k5login_directory configuration.
   
   * What outcome did you expect instead?
   To login automaticaly just like it does with the ~luser/.k5login
   setup.


   Thank you for your hard work!

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

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

Versions of packages krb5-user depends on:
ii  krb5-config 2.6
ii  libc6   2.28-10
ii  libcom-err2 1.44.5-1+deb10u3
ii  libk5crypto31.18.3-5
ii  libkadm5clnt-mit12  1.18.3-5
ii  libkadm5srv-mit12   1.18.3-5
ii  libkdb5-10  1.18.3-5
ii  libkrb5-3   1.18.3-5
ii  libkrb5support0 1.18.3-5
ii  libss2  1.44.5-1+deb10u3

krb5-user recommends no packages.

Versions of packages krb5-user suggests:
pn  krb5-k5tls  

-- no debconf information

Bug#988490: RFS: mini-httpd/1.30-3 [ITA] -- Small HTTP server

[Tobias Frost]

Control: tags -1 moreinfo

Hi Khoa Tran Minh,

thanks for adopting the package!

Please note that Debian is currently frozen, so the changes you've made are
currently inappropiate to upload.

So I see two options:
- wait until bullseye release
- target experimental for now.

Regarding the package, I did not take a closer look beside looking
at the mentors page: Possibly you could take a look at the lintian
messages and try to solve them:

   W: package-contains-documentation-outside-usr-share-doc
usr/share/mini-httpd/html/index.html

mini-httpd source

I patch-not-forwarded-upstream
debian/patches/0007-manpage-hyphen
debian/patches/0008-fix-ftbfs-kfreebsd-amd64
debian/patches/0009-fix-nullpointer-dereference
X debian-watch-does-not-check-gpg-signature
X upstream-metadata-file-is-missing
P silent-on-rules-requiring-root

Not sure if upstream is reachable (homepage a stroken out the mailing list),
but the patches should be forwarded if possible.

There are also several bugs on the BTS, one with a patch. Please check at least
that one if it makes sense to apply the patch and check if the others can be
triaged. 

Please remove the moreinfo tag when an revised package is available; targeting
either experimental or after bullseye has been released.

-- 
Cheers,
tobi

Bug#988466: RFS: aspell-sl/0.60-5 -- Slovenian dictionary for GNU Aspell

[Tobias Frost]

Control: tags -1 moreinfo

(Triaging RFS bugs) This bug seems to wait for an feedback from Tomaž.

Tomaž, please remove the moreinfo tag once an updated package is ready.
Thanks!

--
tobi

Bug#989310: partx: /dev/$VG/$LV: adding partition #4 failed: Invalid argument

[Thorsten Glaser]

Dixi quod…

>… whereas partx at least recognises the disklabel:
>
>tglase@tglase:~ $ sudo partx --show - /dev/mapper/vg--tglase-ufs4
whole-disc:^^
 bsd-disklabel-partition:^
>NR   START  END  SECTORS  SIZE NAME UUID
> 1 2097152 67108863 65011712   31G
> 2  32  2097151  2097120 1024M
> 3   0   31   32   16K

I found a workaround… it does require manually figuring out
which of the “NR” maps to which slice, then losetup(8)ing
that — this is a bit tricky (START is relative to the entire
disc, not the partition) and ugly (losetup only uses bytes,
Kibibytes, etc. but not sectors as offset):

sudo losetup -f -o $((2097152/2))K --sizelimit $((65011712/2))K 
/dev/mapper/vg--tglase-ufs
   START=>^^^SECTORS=>   
whole-disc:^^
 2sec=1K:^2sec=1K:^

Then, “sudo losetup -a” to figure out which loop device
“won”, afterwards use that, for example, with ufsutils
(= 8.2-4) installed, I can do…

sudo ffsinfo /dev/loop0 | less
sudo fsck.ufs -fy /dev/loop0

… and even…

sudo mount -t ufs -o ufstype=44bsd /dev/loop0 /mnt
ls /mnt
sudo umount /mnt

… and at the end, don’t forget to:

sudo losetup -d /dev/loop0
sudo kpartx -d -v /dev/mapper/vg--tglase-ufs


JFYI, in case this pops up with someone else. A working solution,
involving partx, partprobe, kpartx or something, would still be
welcome.

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

Bug#989244: spectral: behaves unpredictably when logged in with username only (segfaults, dead controls, etc.)

[Mike Gabriel]

Hi Andres,

On  Mo 31 Mai 2021 17:16:31 CEST, Andres Salomon wrote:


On 5/31/21 7:04 AM, Mike Gabriel wrote:

On Mo 31 Mai 2021 03:59:12 CEST, Andres Salomon wrote:
Spectral is not good about showing login failures. This isn't  
something that affects regular users (since you only ever log in  
once), but it's annoying for first-time users. Make sure you're  
using the full login name - the format would be @user:server. For  
example, I use @dilinger:queued.net. Even if you're using the  
default server (matrix.org), you'll probably need to add it.


When using the @username:server.tld login name scheme, spectral  
becomes usable, indeed.


This should be documented and maybe you can escalate this to upstream.

It seems to present a half-successful login if I simply use  
username (not @username, not @username:server.tld), but from there  
on, everything fails.


IMHO, spectral could be more assumptive for different login  
schemes. (Prepend an "@" if missing, append a :, or in  
fact, look for .well-known delegation configs for deriving the  
server_name).


FYI, Spectral was forked and the fork (called Neochat) is officially  
the KDE team's matrix client:


https://carlschwan.eu/2020/12/23/announcing-neochat-1.0-the-kde-matrix-client/

https://matrix.org/docs/projects/client/neo-chat


This happened just before Debian bullseye froze, so I was unable to  
package it. I plan to do so, and it's unclear what will happen with  
Spectral for bullseye+1.



Ah, interesting. Thanks for the head up. Please provide a  
bullseye-backport of neo-chat. Thanks.


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpwS75I_hwt_.pgp
Description: Digitale PGP-Signatur

Bug#989273: unblock: ircii/20210314+really20190117-1

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-05-30 23:43:03 +0200, Håvard Flaget Aasen wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: haavard_aa...@yahoo.no
> 
> Please unblock package ircii
> 
> I reverted all changes made for the current 20210314 release and added a
> patch to fix CVE-2020-29376 which also Closes: #986214
> 
> The patch has been sourced from upstream, and is also approved for buster.
> 
> [ Reason ]
> fix denial of service issue [CVE-2021-29376]
> 
> [ Impact ]
> The CVE's description is:
> allows remote attackers to cause a denial of service (segmentation
> fault and client crash, disconnecting the victim from an IRC server)
> via a crafted CTCP UTC message.
> 
> [ Tests ]
> I did test these changes and can confirm that this patch fix
> CVE-2021-29376
> 
> [ Risks ]
> Minimal.
> The code is taken from upstream.
> 
> [ 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 ]
> No
> 
> unblock ircii/20210314+really20190117-1

Please remove the moreinfo tag once the new version is available in
unstable.

Cheers

> 
> 
> Håvard

> diff -Nru ircii-20190117/debian/changelog 
> ircii-20210314+really20190117/debian/changelog
> --- ircii-20190117/debian/changelog   2019-02-21 05:35:56.0 +0100
> +++ ircii-20210314+really20190117/debian/changelog2021-05-30 
> 22:39:28.0 +0200
> @@ -1,3 +1,38 @@
> +ircii (20210314+really20190117-1) unstable; urgency=medium
> +
> +  * QA upload.
> +  * Revert to previous release, because of freeze.
> +  * Add patch to Fix CVE-2021-29376 Closes: #986214
> +
> + -- Håvard Flaget Aasen   Sun, 30 May 2021 22:39:28 
> +0200
> +
> +ircii (20210314-1) unstable; urgency=medium
> +
> +  * QA Upload.
> +  [ Debian Janitor ]
> +  * Set debhelper-compat version in Build-Depends.
> +  * Changes Urgency by urgency in changelog file.
> +
> +  * New upstream release.
> +Fix (CVE-2021-29376). (Closes: #986214).
> +  * debian/control
> ++ Bump Standards-Version to 4.5.1. (no changes).
> ++ Bump Debhelper-compat to 13.
> ++ Add Rules-Requires-Root: no.
> +  * debian/patches
> ++ Refresh:
> +  + 0008-fix-spelling-error.diff
> +  + 0003-Add-ioption-to-local-include-paths-so-they-do-not-co.patch
> +  + 0004-absolute-path-for-motd-and-servers-file-and-other-de.patch
> +  + 0006-fix-some-spelling-errors.patch
> +  * debian/rules
> ++ Remove --as-needed linker flag.
> +  * debian/watch
> ++ Update to version 4.
> +  * Update copyright file.
> +
> + -- Daniel Echeverri   Sun, 11 Apr 2021 11:19:42 -0500
> +
>  ircii (20190117-1) unstable; urgency=medium
>  
>* QA upload.
> diff -Nru ircii-20190117/debian/patches/0009-Fix-CVE-2021-29376.patch 
> ircii-20210314+really20190117/debian/patches/0009-Fix-CVE-2021-29376.patch
> --- ircii-20190117/debian/patches/0009-Fix-CVE-2021-29376.patch   
> 1970-01-01 01:00:00.0 +0100
> +++ 
> ircii-20210314+really20190117/debian/patches/0009-Fix-CVE-2021-29376.patch
> 2021-05-30 22:39:28.0 +0200
> @@ -0,0 +1,44 @@
> +From: Håvard Flaget Aasen 
> +Date: Thu, 13 May 2021 21:39:51 +0200
> +Subject: Fix CVE-2021-29376
> +
> +CVE-2021-29376 allows remote attackers to cause a denial of service
> +(segmentation fault and client crash, disconnecting the victim from an IRC
> +server) via a crafted CTCP UTC message.
> +
> +Bug-Debian: https://bugs.debian.org/#986214
> +Bug-Debian: https://security-tracker.debian.org/tracker/CVE-2021-29376
> +---
> + source/ctcp.c | 15 +--
> + 1 file changed, 13 insertions(+), 2 deletions(-)
> +
> +diff --git a/source/ctcp.c b/source/ctcp.c
> +index 1a714c6..c5ddde0 100644
> +--- a/source/ctcp.c
>  b/source/ctcp.c
> +@@ -536,12 +536,23 @@ do_utc(CtcpEntry *ctcp, u_char *from, u_char *to, 
> u_char *args)
> + {
> + time_t  tm;
> + u_char  *date = NULL;
> ++char*curtime;
> + 
> + if (!args || !*args)
> + return NULL;
> + tm = my_atol(args);
> +-malloc_strcpy(, UP(ctime()));
> +-date[my_strlen(date)-1] = '\0';
> ++curtime = ctime();
> ++if (curtime)
> ++{
> ++u_char *s = my_index(curtime, '\n');
> ++if (s)
> ++*s = '\0';
> ++
> ++malloc_strcpy(, UP(curtime));
> ++}
> ++else
> ++/* if we can't find a time, just return the number */
> ++malloc_strcpy(, args);
> + return date;
> + }
> + 
> diff -Nru ircii-20190117/debian/patches/series 
> ircii-20210314+really20190117/debian/patches/series
> --- ircii-20190117/debian/patches/series  2019-02-20 03:07:03.0 
> +0100
> +++ ircii-20210314+really20190117/debian/patches/series   2021-05-30 
> 22:39:28.0 +0200
> @@ -3,3 +3,4 @@
>  0003-Add-ioption-to-local-include-paths-so-they-do-not-co.patch
>  

Bug#989310: partx: /dev/$VG/$LV: adding partition #4 failed: Invalid argument

[Thorsten Glaser]

Package: util-linux
Version: 2.36.1-7
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de, team+linux-blo...@tracker.debian.org

I’m trying to use partx instead of kpartx to make partitions
available to the system, but it completely fails:

tglase@tglase:~ $ sudo partx -a -v - /dev/vg-tglase/ufs 

partition: none, disk: /dev/vg-tglase/ufs, lower: 0, upper: 0
/dev/vg-tglase/ufs: partition table type 'dos' detected
range recount: max partno=4, lower=0, upper=0
partx: /dev/vg-tglase/ufs: adding partition #4 failed: Invalid argument
partx: /dev/vg-tglase/ufs: error adding partition 4

Doing this with kpartx works…

tglase@tglase:~ $ sudo kpartx -a -v /dev/mapper/vg--tglase-ufs  
  
add map vg--tglase-ufs4 (253:9): 0 67108832 linear 253:8 32

… but kpartx fails in the second step, making the slices from
the BSD disklabel available…

tglase@tglase:~ $ sudo kpartx -a -v /dev/mapper/vg--tglase-ufs4 

device-mapper: reload ioctl on vg--tglase-ufs4p1 (253:10) failed: Invalid 
argument
create/reload failed on vg--tglase-ufs4p1
device-mapper: reload ioctl on vg--tglase-ufs4p2 (253:10) failed: Invalid 
argument
create/reload failed on vg--tglase-ufs4p2
device-mapper: reload ioctl on vg--tglase-ufs4p3 (253:10) failed: Invalid 
argument
create/reload failed on vg--tglase-ufs4p3
device-mapper: reload ioctl on vg--tglase-ufs4p4 (253:10) failed: Invalid 
argument
create/reload failed on vg--tglase-ufs4p4

… whereas partx at least recognises the disklabel:

tglase@tglase:~ $ sudo partx --show - /dev/mapper/vg--tglase-ufs4   
  
NR   START  END  SECTORS  SIZE NAME UUID
 1 2097152 67108863 65011712   31G  
 2  32  2097151  2097120 1024M  
 3   0   31   32   16K  

So I’m stuck.


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages util-linux depends on:
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-7
ii  libc6  2.31-12
ii  libcap-ng0 0.7.9-2.2+b1
ii  libcrypt1  1:4.4.18-4
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libmount1  2.36.1-7
ii  libpam0g   1.4.0-7
ii  libselinux13.1-3
ii  libsmartcols1  2.36.1-7
ii  libtinfo6  6.2+20201114-2
ii  libudev1   247.3-5
ii  libuuid1   2.36.1-7
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.3.0-3
pn  util-linux-locales  

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:

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

[Salvatore Bonaccorso]

Control: severity -1 important

Hi

Could you please extract as well the kernel logs form the kernels
where you firstly see those issues and attach them to this bugreport?
Since you say you can boot 5.10.28 but not 5.10.38, please do this in
two steps.

While I can understand you might be upset if something breaks, still I
would encourage you to reconsider the tone used.

Regards,
Salvatore

Bug#989279: unblock: klibc/2.0.8-6.1

[Sebastian Ramacher]

Control: tags -1 confirmed d-i

On 2021-05-31 01:07:11 +0200, Thorsten Glaser wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: t...@mirbsd.de
> 
> Please unblock package klibc
> 
> [ Reason ]
> The NMU contains a fix for #943425 (save/restore correct set of
> registers across *{set,long}jmp) which is RC on s390x, which is
> a release architecture.
> 
> [ Impact ]
> klibc-built binaries on s390x can malfunction.
> 
> [ Tests ]
> The mksh testsuite catches this. Today’s mksh upload’s buildd log
> on s390x shows that the fix works. An S/390 expert provided the
> correct set of registers to save/restore. I’ve compared it to the
> glibc implementation afterwards, and it matches, so I believe it
> to be correct.
> 
> [ Risks ]
> klibc is rather critical; it’s part of booting and installing (so
> this also needs an udeb unblock). The patch affects s390x only,
> as far as I can tell, but I believe it necessary there.
> 
> [ 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 ]
> This will need an udeb unblock; what do I need to do for this?

By adding Cryil (as d-i RM) and debian-boot@l.d.o to CC. Done now.

Cheers

> 
> unblock klibc/2.0.8-6.1

> diff -Nru klibc-2.0.8/debian/changelog klibc-2.0.8/debian/changelog
> --- klibc-2.0.8/debian/changelog  2021-04-30 03:05:23.0 +0200
> +++ klibc-2.0.8/debian/changelog  2021-05-27 00:12:10.0 +0200
> @@ -1,3 +1,11 @@
> +klibc (2.0.8-6.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * {set,long}jmp [s390x]: save/restore the correct FPU registers
> +(f8‥f15 not f1/f3/f5/f7) (Closes: #943425)
> +
> + -- Thorsten Glaser   Thu, 27 May 2021 00:12:10 +0200
> +
>  klibc (2.0.8-6) unstable; urgency=medium
>  
>* Upload to unstable
> diff -Nru 
> klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
>  
> klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
> --- 
> klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
> 1970-01-01 01:00:00.0 +0100
> +++ 
> klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
> 2021-05-27 00:11:57.0 +0200
> @@ -0,0 +1,57 @@
> +Description: {set,long}jmp [s390x]: save/restore the correct registers
> + The s390x ABI actually has FPU registers f8‥f15, not f1/f3/f5/f7,
> + to be saved. (Closes: Debian #943425)
> +Author: mirabilos 
> +Forwarded: https://lists.zytor.com/archives/klibc/2021-May/004620.html
> +
> +--- a/usr/include/arch/s390/klibc/archsetjmp.h
>  b/usr/include/arch/s390/klibc/archsetjmp.h
> +@@ -16,7 +16,7 @@ struct __jmp_buf {
> + 
> + struct __jmp_buf {
> + uint64_t __gregs[10]; /* general registers r6-r15 */
> +-uint64_t __fpregs[4]; /* fp registers f1, f3, f5, f7 */
> ++uint64_t __fpregs[8]; /* fp registers f8-f15 */
> + };
> + 
> + #endif /* __s390x__ */
> +--- a/usr/klibc/arch/s390/setjmp.S
>  b/usr/klibc/arch/s390/setjmp.S
> +@@ -38,10 +38,14 @@ longjmp:
> + 
> + setjmp:
> + stmg%r6,%r15,0(%r2) # save all general registers
> +-std %f1,80(%r2) # save fp registers f4 and f6
> +-std %f3,88(%r2)
> +-std %f5,96(%r2)
> +-std %f7,104(%r2)
> ++std %f8,80(%r2) # save fp registers f8 to f15
> ++std %f9,88(%r2)
> ++std %f10,96(%r2)
> ++std %f11,104(%r2)
> ++std %f12,112(%r2)
> ++std %f13,120(%r2)
> ++std %f14,128(%r2)
> ++std %f15,136(%r2)
> + lghi%r2,0   # return 0
> + br  %r14
> + 
> +@@ -54,10 +58,14 @@ setjmp:
> + longjmp:
> + lgr %r1,%r2 # jmp_buf
> + lgr %r2,%r3 # return value
> +-ld  %f7,104(%r1)# restore all saved registers
> +-ld  %f5,96(%r1)
> +-ld  %f3,88(%r1)
> +-ld  %f1,80(%r1)
> ++ld  %f15,136(%r1)   # restore all saved registers
> ++ld  %f14,128(%r1)
> ++ld  %f13,120(%r1)
> ++ld  %f12,112(%r1)
> ++ld  %f11,104(%r1)
> ++ld  %f10,96(%r1)
> ++ld  %f9,88(%r1)
> ++ld  %f8,80(%r1)
> + lmg %r6,%r15,0(%r1)
> + br  %r14# return to restored address
> + 
> diff -Nru klibc-2.0.8/debian/patches/series klibc-2.0.8/debian/patches/series
> --- klibc-2.0.8/debian/patches/series 2021-04-30 02:38:31.0 +0200
> +++ klibc-2.0.8/debian/patches/series 2021-05-27 00:09:21.0 +0200
> @@ -10,3 +10,4 @@
>  0037-klibc-calloc-Fail-if-multiplication-overflows.patch
>  0039-klibc-cpio-Fix-possible-integer-overflow-on-32-bit-s.patch
>  0040-klibc-cpio-Fix-possible-crash-on-64-bit-systems.patch
> 

Bug#988974: buster-pu: package fig2dev/1:3.2.7a-5+deb10u4

[Roland Rosenfeld]

On Sa, 29 Mai 2021, Adam D. Barratt wrote:

> > I prepared an update for fig2dev 1:3.2.7a-5+deb10u3 to deb10u4, which
> > in the first time fixes CVE-2021-3561 (the security team doesn't
> > intend to create a DSA but redirected me here).
> > 
> > Additionally it fixes four other buffer overflows, that are all fixed
> > upstream and I backported the fixes.

> I'm assuming that "fixed upstream" here implies that the fixes are also
> in unstable? If so, please go ahead.

Yes, the patches are available in unstable as well as in testing.
So I just uploaded the package.

Greetings
Roland


signature.asc
Description: PGP signature

Bug#989309: kgames: kcanfield and kspider fail to start

[Daniele Forsi]

Package: kgames
Version: 1.0-2.1
Severity: important
X-Debbugs-Cc: dfo...@gmail.com

Dear maintainer,

kcanfield doesn't start, when running it from the terminal I get:
Error: Shell widget kcanfield has zero width and/or height

kspider doesn't start, when running it from the terminal I get:
Error: Shell widget kspider has zero width and/or height

The other games in this package work as expected when run from the same 
terminal.

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 kgames depends on:
ii  libc6 2.31-12
ii  libx11-6  2:1.7.1-1
ii  libxaw7   2:1.0.13-1.1
ii  libxmu6   2:1.1.2-2+b3
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.2.0-1

kgames recommends no packages.

kgames suggests no packages.

-- debconf-show failed

Bug#989308: unblock: backintime/1.2.1-3

[Fabian Wolff]

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

Hi,

please consider unblocking version 1.2.1-3 of backintime, currently in
unstable. The upload fixes the release critical bug #946349 by
cherry-picking the relevant fix from the upstream repository. The same
fix has also been proposed as a patch in a response to #946349.

The patch itself is only a few lines long. It has been approved and
merged by the upstream maintainers, adding to its trustworthiness. No
other changes have been made in this package for the 1.2.1-3 upload.

I have attached the debdiff between 1.2.1-2 (testing) and 1.2.1-3
(unstable). Let me know if you need anything else.

Thank you!
Fabian
diff -Nru backintime-1.2.1/debian/changelog backintime-1.2.1/debian/changelog
--- backintime-1.2.1/debian/changelog	2019-10-30 22:35:50.0 +0100
+++ backintime-1.2.1/debian/changelog	2021-05-31 15:14:50.0 +0200
@@ -1,3 +1,10 @@
+backintime (1.2.1-3) unstable; urgency=medium
+
+  * Cherry-pick patch for #946349 from upstream Git repository
+(Closes: #946349).
+
+ -- Fabian Wolff   Mon, 31 May 2021 15:14:50 +0200
+
 backintime (1.2.1-2) unstable; urgency=medium
 
   * Source-only reupload after the package has been in the NEW queue
diff -Nru backintime-1.2.1/debian/patches/00-fix-946349.patch backintime-1.2.1/debian/patches/00-fix-946349.patch
--- backintime-1.2.1/debian/patches/00-fix-946349.patch	1970-01-01 01:00:00.0 +0100
+++ backintime-1.2.1/debian/patches/00-fix-946349.patch	2021-05-31 15:14:50.0 +0200
@@ -0,0 +1,39 @@
+Description: Cherry-pick fix for #946349 from upstream repository
+Origin: upstream, https://github.com/bit-team/backintime/commit/7f6f570a01e7e0a623e670baaf63eaaf879948c4
+Bug: https://github.com/bit-team/backintime/issues/974
+Bug-Debian: https://bugs.debian.org/946349
+Last-Update: 2021-05-31
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/common/mount.py
 b/common/mount.py
+@@ -648,7 +648,7 @@
+ """
+ tools.mkdir(self.mount_root, 0o700)
+ tools.mkdir(self.hash_id_path, 0o700)
+-tools.mkdir(self.currentMountpoint, 0o700)
++tools.mkdir(self.currentMountpoint, 0o700, False)
+ tools.mkdir(self.lock_path, 0o700)
+ 
+ def mountProcessLockAcquire(self, timeout = 60):
+--- a/common/tools.py
 b/common/tools.py
+@@ -287,7 +287,7 @@
+  %(path, str(e)), traceDepth = 1)
+ return os.path.isdir(path)
+ 
+-def mkdir(path, mode = 0o755):
++def mkdir(path, mode = 0o755, enforce_permissions = True):
+ """
+ Create directory ``path``.
+ 
+@@ -300,7 +300,8 @@
+ """
+ if os.path.isdir(path):
+ try:
+-os.chmod(path, mode)
++if enforce_permissions:
++os.chmod(path, mode)
+ except:
+ return False
+ return True
diff -Nru backintime-1.2.1/debian/patches/series backintime-1.2.1/debian/patches/series
--- backintime-1.2.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ backintime-1.2.1/debian/patches/series	2021-05-31 15:14:50.0 +0200
@@ -0,0 +1 @@
+00-fix-946349.patch

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

[Holger Levsen]

Package: libwebkit2gtk-4.0-37
Version: 2.32.1-1~deb10u1
Severity: normal

Dear Maintainer,

from #debian-security today, Salvatore asked me to file this as a bug.

< h01ger> DSA 4923 causes xdg-desktop-portal(-gtk) to be installed here, much 
to my surprise and unhappyness
< h01ger> its a recommends, so i can apt remove it, but still...
< h01ger> https://paste.debian.net/1199471/
(which has this content)

Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following NEW packages will be installed:
   libpipewire-0.2-1 (0.2.5-1)
   xdg-desktop-portal (1.2.0-1)
   xdg-desktop-portal-gtk (1.2.0-1)
The following packages will be upgraded:
   libjavascriptcoregtk-4.0-18 (2.30.6-1~deb10u1 => 2.32.1-1~deb10u1)
   libwebkit2gtk-4.0-37 (2.30.6-1~deb10u1 => 2.32.1-1~deb10u1)
2 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.1 MB of archives.
After this operation, 5,376 kB of additional disk space will be used.
Do you want to continue? [Y/n] 

< carnil> h01ger: thanks forwarded to alberto
* h01ger still busy cleaning systems
< h01ger> carnil: thanks!
< carnil> h01ger: the problem which is to be solved with it is apparently 
https://bugzilla.redhat.com/show_bug.cgi?id=1845743 (according to berto)
< h01ger> carnil: seems like. i've no flatpak and no snap and i dont expect to 
gain a dbus service granting privileges on a buster security update. (i've also 
seen it on bullseye upgrades but given that bullseye is not stable yet i wont 
complain here :)
< h01ger> carnil: do you think it would be useful if i'd file a bug about this 
issue?
< carnil> h01ger: at least the maintainer could comment himself on it, and 
explain on why the recommends, and maybe discussion can lead to that change is 
not suitable for the DSA, and we can drop it in the next upload.
< h01ger> carnil: was that a yes?
< carnil> h01ger: yes
< h01ger> carnil: ok. i'll include some lines from you here...
< carnil> h01ger: yes. I have no proplem if you mention I suggested to fill a 
but to ask to clarify the issue. But note I was only inbetween here.


Personally I think a DSA fixing this would be nice.

-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"Climate change" is an euphenism. "Global warming" as well.


signature.asc
Description: PGP signature

Bug#989306: cups-filters: parallel port modules force included on ARM kernels

[Jonathan Lane]

Package: cups-filters
Version: 1.21.6-5
Severity: important
Tags: patch

Dear Maintainer,

The file /etc/modules-load.d/cups.conf contains invocations to load
modules lp, ppdev, and parport_pc, which are unavailable on the latest
arm64 kernels in Debian 10, and will likely remain so forever, at least
parport_pc, because ARM systems do not have PC parallel ports.  This
results in systemd-load-modules.service reporting failure every boot.
The fix is only including this file on architectures where those kernel
modules are meaningful.  This is a very old bug and appears to be a
regression, since it was known at least as far back as 2015 by the
Ubuntu maintainers.

https://github.com/raphael/linux-samus/issues/25

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

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

Versions of packages cups-filters depends on:
ii  bc 1.07.1-2+b1
ii  cups-filters-core-drivers  1.21.6-5
ii  ghostscript9.27~dfsg-2+deb10u4
ii  libc6  2.28-10
ii  libcups2   2.2.10-6+deb10u4
ii  libcupsfilters11.21.6-5
ii  libcupsimage2  2.2.10-6+deb10u4
ii  libfontconfig1 2.13.1-2
ii  libfontembed1  1.21.6-5
ii  libgcc11:8.3.0-6
ii  libqpdf21  8.4.0-2
ii  libstdc++6 8.3.0-6
ii  poppler-utils  0.71.0-5

Versions of packages cups-filters recommends:
ii  colord 1.4.3-4
ii  liblouisutdml-bin  2.7.0-5+b1

Versions of packages cups-filters suggests:
pn  antiword 
pn  docx2txt 
ii  foomatic-db  20181217-2
ii  imagemagick  8:6.9.10.23+dfsg-2.1+deb10u1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+deb10u1

-- Configuration Files:
/etc/modules-load.d/cups-filters.conf changed:


-- no debconf information

Bug#984901: RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 -- firmware for AR7010 and AR9271 USB wireless adapters

[Tobias Frost]

Control: tags -1 moreinfo

Hi John,

I've took a look at your package:
- d/copyright: 
 - The word "Comment:" went missing after the Files-Exlucded section.
 - Please review the file. I see e.g the section for "Files: *" be gone,
   not sure if that is intentional (I did not a d/copyright review)
   Lintian is the same oppionion that there is something missing:

W: open-ath9k-htc-firmware source: file-without-copyright-information .gitignore
W: open-ath9k-htc-firmware source: file-without-copyright-information NOTICE.TXT
W: open-ath9k-htc-firmware source: file-without-copyright-information README

 - W: open-ath9k-htc-firmware source: inconsistent-appstream-metadata-license  
   debian/firmware-ath9k-htc.metainfo.xml (mit != expat)

- Some patch have fuzz... maybe refresh?

Please fix above and then remove the moreinfo tag.

-- 
Cheers,
tobi

Bug#989182: apt-listbugs fails to detect a fix an unpin

[Francesco Poli]

On Sun, 30 May 2021 10:51:14 -0700 Ross Boylan wrote:

> I checked all proposed solutions in aptitude.  I think the reason
> exim4-daemon-heavy wasn't proposed was that I didn't have the exim4
> binary (meta) package, which lists both daemons as dependents.

Well, this changes things considerably...

[...]
> If that analysis is correct, then things get messy with the exim4
> binary package installed.  exim4-daemon-light is pinned, but not
> exim4-daemon-heavy, though I presume both had the same problem.

That's not necessarily the case, at least not in general.

A bug report filed against a binary package does not necessarily apply
to any other binary package generated from the same source package.

If the same bug applies to another binary package, maybe the BTS should
be made aware of that (probably by filing a second bug report against
the other binary package?).

[...]
> Applying the pin to the source package seems safer, though I don't
> know if that's possible.

Pinning by source package is indeed possible (see section _Pinning by
source package_ in the apt_preferences(5) man page), however I don't
think apt-listbugs should do that.

At least, not when the pin was decided by the user on the basis of a bug
report filed against a *binary* package.
And please take into account that apt-listbugs (currently) only looks at
bug reports filed against binary packages: I am not convinced that
looking at bugs in source packages would be useful for apt-listbugs
(after all, you are about to install binary packages, not source
packages!).

I hope all this line of reasoning makes sense to you.
Bye!   :-)


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpchuWjFfcrj.pgp
Description: PGP signature

Bug#625203: CMV

[Carla Oyaneder]

Good evening, did you get my previous email?

Bug#983104: RFS: mupdf/1.14.0+ds1-4+deb10u3 [NMU, CVE-2020-16600] -- lightweight PDF viewer

[Tobias Frost]

Control: tags -1 moreinfo

Hi Bastian,

> > Hi Bastian,
> > 
> > thanks for your work on this. We think this update should go via
> > stable-proposed-updates:
> 
> Hi,
> 
> Thanks for pointing that out. I have modified the changelog accordingly.
> 

The diff looks good, but there are some formalities…

- Can you file an "Stable Proposed Updates" unblock request to get an approval.

- Possibly you should file an bug for CVE-2020-16600 and
close it in the changelog. (That would make it more transparent.)

- Please also send a NMU announcement to the package's bts.

Thanks for providing the update!

After the release team gives green light, remove the moreinfo, ping me and I'll
do the upload.

Cheers,
--
tobi

Bug#988567: reassign 988567 to soapysdr0.7-module-rfspace, affects 988567

[Cyril Brulebois]

Christoph Berg  (2021-05-16):
> reassign 988567 soapysdr0.7-module-rfspace 
> affects 988567 cubicsdr
> thanks

It may be unrelated, but CubicSDR is crashing hard, and doesn't seem to
be suitable to be released as is into bullseye. Does anything speak
against an RC bug against cubicsdr? That's what I was expecting when I
saw that existing bug report…


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


signature.asc
Description: PGP signature

Bug#981098: RFS: aiorwlock/1.0.0-1 -- Synchronization primitive RWLock for asyncio (Python 3)

[Tobias Frost]

Control: tags -1 moreinfo

Hi Waqar Ahmed,

> 
>  aiorwlock (1.0.0-1) unstable; urgency=medium
>  .
>    * New upstream version 1.0.0
>    * debian/control:
>  - Use pytest-asyncio for tests

(Currently Debian is frozen, so an upload is likely inappropiate at this time.
 You can aim for experimental if you want, though.)

One question: You are not listed as maintainer, neither this is marked as team
upload nor as NMU… Can you elaborate on this point and clarify in the changelog
what type of upload this is. Have you talked to the maintainer or/and python
team? I'll marking the bug "moreinfo" as this needs clarification and
documentation in d/changelog.

Beside, there are some lintian stuff (quoted from the mentors site)
> – Package has lintian warnings:
> 
> I out-of-date-standards-version
> 4.4.1 (released 2019-09-29) (current is 4.5.0)
> P package-uses-old-debhelper-compat-version
> 12
> P silent-on-rules-requiring-root

I suggest to contact the maintainer and or python team (possibly after bullseye
release) and remove the moreinfo tag here when you are ready for another review-


Thanks for your contributions to Debian and sorry that I cant help with an
upload… (I do not intend to sponsor this package; python packages are not mine…)

Cheers,
-- 
tobi

Bug#989305: python3-djangorestframework-spectacular: Does not work, attempt to import unvailable dj_rest_auth module

[Adam Cecile]

Package: python3-djangorestframework-spectacular
Version: 0.13.1-1
Severity: grave
Tags: patch
Justification: renders package unusable

Hello,

This package does not work at all, it attemps to import unavailable
dj_rest_auth module at runtime and this module is supposed to be an optional
dependency (which is not available in Debian archive).

I had a talk with upstream on Github:
https://github.com/tfranzel/drf-spectacular/issues/411

And it turned out upstream did some work to render optional modules really
optional in recent versions.

The import bug can actually be seen while building the package from a clean
chroot, Sphinx doc is not getting generated correctly (but does not crash build
for some reason):

WARNING: autodoc: failed to import module 'openapi' from module
'drf_spectacular'; the following exception was raised:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py", line
67, in import_module
return importlib.import_module(modname)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 790, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/tmp/python-drf-spectacular-0.13.1/drf_spectacular/openapi.py", line
21, in 
from drf_spectacular.contrib import *  # noqa: F403, F401
  File "/tmp/python-drf-
spectacular-0.13.1/drf_spectacular/contrib/rest_auth.py", line 3, in 
pytest.importorskip("dj_rest_auth")
  File "/usr/lib/python3/dist-packages/_pytest/outcomes.py", line 212, in
importorskip
raise Skipped(reason, allow_module_level=True) from None
Skipped: could not import 'dj_rest_auth': No module named 'dj_rest_auth'

My django application crashes with the same error message, it cannot start.

I updated the package on SALSA to latest upstream version:
https://salsa.debian.org/python-team/packages/python-drf-spectacular

And this one is building fine, unittests run successfully and my Django app is
working again.

I'm not sure if it's too late to be included in Debian 11, but imho, it's
better not to have it than having it in current state.

Best regards, Adam.

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

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

Bug#989302: mmdebstrap: busybox-based chroot example misses mktemp

[Jochen Sprickerhof]

* Johannes Schauer Marin Rodrigues  [2021-05-31 16:34]:

I fixed it like this:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/594ea3c72e7af26b680d2bfb696c0271839b731d


Looks good to me, only the merged-/usr may need an extra paragraph as 
the directory is a little non obvious:


--hook-dir=/usr/share/mmdebstrap/hooks/

Alternatively move the setup00-merged-usr.sh to hooks/merged-usr/ maybe?

Cheers Jochen


signature.asc
Description: PGP signature

Bug#514453: , #757535: [caja|nautilus]: should properly unmount fuse mounts

[Thomas Uhle]

On Fri, 28 May 2021, Simon McVittie wrote:


On Fri, 28 May 2021 at 15:00:04 +0200, Thomas Uhle wrote:
> As far as I can confirm, it is working with sshfs/3.7.1+repack-1 together
> with mount/2.36.1-7 and libmount1/2.36.1-7 resp. which are the currently
> packaged versions for bullseye. I have never tested an older version of
> mount from util-linux after version 2.33.1-0.1 because I am basically still
> on Debian 10 (buster)

To confirm, does this mean you are still using buster's version of either
caja or nautilus, and the mount upgrade resolved this for you? If yes,


Yes, you're right. It's still the older version of Nautilus. Yet it's not 
just mount, libmount1 and other binary packages from util-linux but also 
libselinux1, libsepol1 and libsemanage1 that I had to update because of 
binary dependencies.




that seems like good evidence that this was a limitation of older versions
of mount (util-linux), rather than a limitation of older versions of
caja and nautilus.


I think it's hard to tell where the limitations are if several tools and 
libraries interact together. It is certainly not Nautilus because it just 
calls GMount::unmount_with_operation() from GIO (in 
nautilus_file_operations_unmount_mount_full() for instance). I assume that 
is the same for all of its descendants (Caja, Pantheon Files and alike). 
So it makes sense to solve this further down in GIO/GVFS, FUSE or mount. 
It is arguable where best and how exactly to fix this as you can see in 
various discussions, e.g., https://gitlab.gnome.org/GNOME/gvfs/issues/133, 
https://gitlab.gnome.org/GNOME/glib/issues/633, 
https://github.com/libfuse/libfuse/issues/246 and 
https://github.com/karelzak/util-linux/pull/705.  In the end, it was done 
in mount and libmount respectively. But this does not necessarily mean 
that mount had a limitation.


Best regards,

Thomas Uhle

Bug#989010: Severity raise

[jim_p]

Control: severity -1 critical

Bug#989304: lirc FTCBFS: multiple reasons

[Helmut Grohne]

Source: lirc
Version: 0.10.1-6.3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

lirc fails to cross build from source for a number of reasons. I've
understood a pile and am presenting solutions here:

1. Its Build-Depends are not satisfiable. python3-dev asks (among other
   things), for the host architecture Python interpreter, which fails to
   install. A python(.*)-dev dependency should usually be written as
   python$1-dev:any, libpython$1-dev. Beyond this, python3-yaml also
   requests the host architecture Python interpreter. It is meant to be
   run during build though, so it should be annotated :native.

   Once fixing these, a cross build can be attempted.

2. configure uses AC_RUN_IFELSE to check for existence of /dev/input. In
   principle, this is correct. For file existence however, there is a
   better check: AC_CHECK_FILE. During a cross build, this check also
   fails and consults the cache variable ac_cv__dev_input. A builder may
   supply this variable to make the check pass. It also gets a lot
   simpler by using AC_CHECK_FILE.

3. debian/rules also confuses the build architecture with the host
   architecture in two occasions. Please refer to man dpkg-architecture
   for a precise definition.

4. In order to make setup.py perform a cross build, one is supposed to
   export _PYTHON_SYSCONFIGDATA_NAME. When using the pybuild
   buildsystem, debhelper takes care of that, but here setup.py is run
   from inside autoconf+make and debhelper cannot know. Thus it needs to
   be exported explicitly.

5. When fixing all of the above, what remains is this error:

   /usr/bin/install: cannot stat './python-pkg/dist/lirc-0.10.1.tar.gz': No 
such file or directory

   I have no clue why this file is created during a regular build but
   missing during a cross build. Unfortunately, the build hides compiler
   invocations and such, so we cannot see the relevant commands. I don't
   have a solution for this issue.

In the mean time, I recommend dropping --enable-silent-rules from the
configure invocation. debhelper will automatically pass this flag when
you add "terse" to DEB_BUILD_OPTIONS and --disable-silent-rules
otherwise. Building verbosely by default is recommended by the Debian
policy. By dropping the flag, you implement recommended policy behaviour
and retain the ability to issue a terse log via the standard mechanism.

I ask you to apply the attached patch to fix 1-4. Please close this bug
when addressing 1-4 only. Of course finding a solution to 5 would be
welcome as well.

Helmut
--- lirc-0.10.1/debian/changelog
+++ lirc-0.10.1/debian/changelog
@@ -1,3 +1,14 @@
+lirc (0.10.1-6.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building. (Closes: #-1)
++ Multiarchify python Build-Depends.
++ cross.patch: Check for /dev/input using AC_CHECK_FILE.
++ Fix two build vs host confusions.
++ Export _PYTHON_SYSCONFIGDATA_NAME for setup.py.
+
+ -- Helmut Grohne   Thu, 20 May 2021 17:27:08 +0200
+
 lirc (0.10.1-6.3) unstable; urgency=medium
 
   * Non-maintainer upload.
--- lirc-0.10.1/debian/control
+++ lirc-0.10.1/debian/control
@@ -18,6 +18,7 @@
  kmod [linux-any],
  libasound2-dev [linux-any kfreebsd-any],
  libftdi1-dev,
+ libpython3-dev (>= 3.5),
  libsystemd-dev [linux-any],
  libudev-dev [linux-any],
  libusb-1.0-0-dev [!kfreebsd-any],
@@ -26,9 +27,9 @@
  man2html-base,
  pkg-config,
  portaudio19-dev,
- python3-dev (>= 3.5),
+ python3-dev:any (>= 3.5),
  python3-setuptools,
- python3-yaml,
+ python3-yaml:native,
  socat [!hurd-any],
  systemd [linux-any],
  xsltproc
--- lirc-0.10.1/debian/patches/cross.patch
+++ lirc-0.10.1/debian/patches/cross.patch
@@ -0,0 +1,33 @@
+--- a/configure.ac
 b/configure.ac
+@@ -291,29 +291,12 @@
+ fi
+ 
+ AC_MSG_CHECKING(for devinput)
+-AC_RUN_IFELSE([AC_LANG_PROGRAM([[
+-  #include 
+-]],[[
+-  return access("/dev/input", R_OK) == 0 ? 0 : 1;
+-]])],[
++AC_CHECK_FILE([/dev/input],[
+   have_devinput="yes"
+   AC_MSG_RESULT(yes)
+ ],[
+   AC_MSG_RESULT(no)
+   have_devinput="no"
+-],[
+-  AS_IF([test x$DEVINPUT_HEADER = x -a x$enable_devinput = xyes], [
+-AC_MSG_ERROR([
+-  cannot cross-compile with devinput without DEVINPUT_HEADER
+-  defined, giving up
+-])
+-  ])
+-  if test -n "$DEVINPUT_HEADER" ; then
+-have_devinput="yes"
+-  else
+-have_devinput="no"
+-  fi
+-  AC_MSG_RESULT(yes)
+ ])
+ 
+ 
--- lirc-0.10.1/debian/patches/series
+++ lirc-0.10.1/debian/patches/series
@@ -5,3 +5,4 @@
 0005-systemd-support-Notify-systemd-on-successful-startup.patch
 lirc-gpio-ir-0.10.patch
 python3.8.diff
+cross.patch
--- lirc-0.10.1/debian/rules
+++ lirc-0.10.1/debian/rules
@@ -4,6 +4,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS  = hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
+export 
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH)
 
 %:
dh $@ --with python3
@@ -40,7 +41,7 @@
find 

Bug#989244: spectral: behaves unpredictably when logged in with username only (segfaults, dead controls, etc.)

[Andres Salomon]

On 5/31/21 7:04 AM, Mike Gabriel wrote:

On Mo 31 Mai 2021 03:59:12 CEST, Andres Salomon wrote:
Spectral is not good about showing login failures. This isn't 
something that affects regular users (since you only ever log in 
once), but it's annoying for first-time users. Make sure you're using 
the full login name - the format would be @user:server. For example, 
I use @dilinger:queued.net. Even if you're using the default server 
(matrix.org), you'll probably need to add it.


When using the @username:server.tld login name scheme, spectral 
becomes usable, indeed.


This should be documented and maybe you can escalate this to upstream.

It seems to present a half-successful login if I simply use username 
(not @username, not @username:server.tld), but from there on, 
everything fails.


IMHO, spectral could be more assumptive for different login schemes. 
(Prepend an "@" if missing, append a :, or in fact, look 
for .well-known delegation configs for deriving the server_name).


FYI, Spectral was forked and the fork (called Neochat) is officially the 
KDE team's matrix client:


https://carlschwan.eu/2020/12/23/announcing-neochat-1.0-the-kde-matrix-client/

https://matrix.org/docs/projects/client/neo-chat


This happened just before Debian bullseye froze, so I was unable to 
package it. I plan to do so, and it's unclear what will happen with 
Spectral for bullseye+1.

Bug#922213: plasma-desktop: KDE/Plasma creates invalid locale // Re: locales-all: Doesn't provide en_DE.UTF-8

[Lisandro Damián Nicanor Pérez Meyer]

Hi Steffen!

On Fri, 28 May 2021 at 03:15, Steffen Kaiser  wrote:
>
> Package: plasma-desktop
> Version: 4:5.20.5-4
> Followup-For: Bug #922213
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> I'm using en_US.UTF-8 as interface language, but set Regional Settings |
> Formats to German.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>
> cat .config/plasma-localerc
> [Formats]
> LANG=en_DE.UTF-8

I don't seem able to set up this. Can you please provide me a way to
reproduce this bug?

Bug#989236: crossgrader: crashes with "Could not mark python3-apt:amd64 for install, fixing manually."

[Adam Borowski]

On Mon, May 31, 2021 at 07:08:22AM -0700, Kevin Wu wrote:
> On Mon, May 31, 2021 at 4:26 AM Adam Borowski  wrote:
> > But, is there _any_ case when crossgrader might possibly work?  As it needs
> > python-apt-common, it will always fail.  That makes the package useless.
> > Should we bump #968458 to a RC severity?
> 
> crossgrader won't be able to work if python3-apt cannot be
> crossgraded, so there's no case where it would work. Would #968458
> merit critical for breaking unrelated software?

A dependency is related.  Still, that bug renders a package useless, which
is serious (not that there's any practical difference between different
RC severity levels...).

I've bumped that bug's severity, and explained why it's better to solve that
in src:python-apt rather than in crossgrader.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
⠈⠳⣄

Bug#968458: makes crossgrader completely broken, bumping severity

[Adam Borowski]

Control: severity -1 serious

Hi!
Because of this lacking M-A setting, crossgrader always fails in bullseye.
It had a hack to workaround this in buster, but for some reason that hack
is no longer working.

I've discussed a bit with the maintainer in #989236.

Thus, that package is broken for all users, which is RC.  However, I find
little point in trying to debug why the hack fails -- fixing the real
cause is so much simpler.

Thus: please mark python-apt-common as Multi-Arch: foreign


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant:
⣾⠁⢠⠒⠀⣿⡁   Reverently made for universal free distribution by Wang Jie
⢿⡄⠘⠷⠚⠋⠀   on behalf of his two parents on the 15th of the 4th moon of
⠈⠳⣄   the 9th year of Xiantong [11 May 868].

Bug#989288: CVE-2021-29629

[Jonas Smedegaard]

Quoting Christoph Berg (2021-05-31 16:31:13)
> > dacs bundles a copy in src/libradius/src/radlib.c:
> > https://www.freebsd.org/security/advisories/FreeBSD-SA-21:12.libradius.asc
> 
> Fwiw, the package is orphaned, I do not intend to fix this personally.
> 
> I am not aware of anyone using the package (the company for which we 
> were packaging it has moved to something else, and iirc Jonas who was 
> interested in it some time ago has also said he went for something 
> else), so removal from bullseye is certainly an option.

Correct, I no longer have a use for dacs.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Alois Schlögl]

Am 5/31/21 um 8:19 AM schrieb Alois Schlögl:



Am 5/29/21 um 1:59 PM schrieb Salvatore Bonaccorso:

Control: tags -1 + moreinfo

Hi Alois,

On Fri, May 31, 2019 at 09:24:03PM +0200, Romain Perier wrote:

On Wed, May 29, 2019 at 05:54:22PM +0200, Alois Schlögl wrote:

On 3/26/19 9:03 PM, Romain Perier wrote:

On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote:

On 3/18/19 7:46 PM, Romain Perier wrote:

On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote:

On 3/18/19 12:20 PM, Romain Perier wrote:

Hello,

On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:

Source: linux
Severity: normal

Dear Maintainer,

    On a Lenovo L480 laptop, I've upgraded Debian from 9 
(stretch) to 10

(testing).
    After the upgrade, the touchpad and the trackpoint was 
not usable

anymore.


    This already has some bug report here,
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600

    As a workaround, one can run the command,
    sudo sh -c 'echo -n "elantech">
/sys/bus/serio/devices/serio1/protocol'
    in order to use the touchpad. However, on a GUI Interface 
and without

    an external mouse, it's impossible to apply this workaround
   (switching to the terminal -F1, login, and run 
the command

above might work)

    I expect to be able to use the touchpad just out of the 
box, not needing

    to run the above workaround


Could you :

- Test with the last kernel uploaded to unstable 
(4.19.0-4:4.19.28) and confirm or

   not is the problem still exists ?

Dear Romain


I upgraded the kernel and rebooted:

schloegl@debian10:~$ uname -a
Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
x86_64 GNU/Linux


With this kernel the trackpoint is working, the trackpad is 
still not

usable.

(This improves the situation because now at least one pointer 
device is

available).



Good, we did some progress :)

- According to the bug on launchpad and to the fix pushed 
upstream, the
   fix seems to be an hardware quirks, could you give me the 
output of the

   following command :
   $ /sys/bus/serio/devices/serio1/firmware_id

root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
PNP: LEN2036 PNP0f13


Could you test the patch attached to this reply ?
(if you don't know how to do this, I can provide support)

Regards,
Romain


I tried to followed these instructions:

https://kernel-team.pages.debian.net/kernel-handbook/ch-comm

4.5. Building a custom kernel from Debian kernel source

Specifically using the patched the sources,

*scripts/config --disable MODULE_SIG*
**scripts/config --disable DEBUG_INFO**
||*|make clean|* ||*|make deb-pkg

|*

and ended up with a kernel that does not boot (missing HD audio 
firmware),



Which procedure do you recommend to build and install a modified 
kernel ?




Hi,

Section 4.2 from
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official 

, until test-patches should work. For the test-patches script, use 
the flavour and a

featureset as argument, when you invoke it, like this :

# debian/bin/test-patches -f amd64 -s none 
/path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch


This will apply the patch on the fly, configure the kernel for amd64
and build a version with a special changelog entry and a special 
suffix

version dedicated to the test version you generate.


In case of troubles, I can provide another way, from git with few
commands.


Hope this helps,
Regards,
Romain


Dear Romain,


your instructions to build the kernel worked fine, when trying to
install the kernel,

    sudo dpkg -i 
linux-headers-4.19.0-5-amd64_4.19.37-3a~test_amd64.deb

linux-image-4.19.0-5-amd64-unsigned_4.19.37-3a~test_amd64.deb

I run into problem, getting this warning.


  │ You are running a kernel (version 4.19.0-5-amd64) and 
attempting to

remove the same
version.
│
  │
│
  │ This can make the system unbootable as it will remove
/boot/vmlinuz-4.19.0-5-amd64 and all modules under the directory
/lib/modules/4.19.0-5-amd64. This can only be fixed with a copy  │
  │ of the kernel image and the corresponding
modules.
│
  │
│
  │ It is highly recommended to abort the kernel removal unless you 
are

prepared to fix the system after
removal.
│
  │
│
  │ Abort kernel removal?


I'm not sure if I'm "prepared to fix the system". Can you recommend a
reasonable save way to go forward ?


Cheers,

    Alois

Hello,

Well, this is something I have tested here myself, from the linux
git repository (on salsa.debian.org). I have built a 4.19.37-4a~test
with the patch , then I have forced the install with the same question
than you. And he did the trick !

So what you can do is:

  - When the dialog interface (the blue one) asks you to abort or 
continue the install,

    press "no" to don't abort and continue the install
  - Once done, you can reboot
  - Check that the boot is working fine and you're running the intended
    kernel:  4.19.37-3a~test  (via uname -a)
  - Check if your problem is 

Bug#989302: mmdebstrap: busybox-based chroot example misses mktemp

[Johannes Schauer Marin Rodrigues]

Hi Jochen,

Quoting Jochen Sprickerhof (2021-05-31 15:16:26)
> I just tried the sub-essential busybox-based chroot example from the man page
> on an up to date sid and got:
> 
> /var/lib/dpkg/info/base-passwd.postinst: line 1: mktemp: not found
> 
> Adding mktemp to the setup-hook ln loop fixes it.

thanks! Fixed in git. The more elegant way is indeed to run `busybox --install
-s` in the extract-hook. That's also what is done in the scripts in
/usr/share/mmdebstrap/hooks/busybox that you already discovered.

> In addition it probably makes sense to add something like this below:
> 
> The same can be archived by:
> --hook-dir=/usr/share/mmdebstrap/hooks/busybox
> 
> Or maybe replace the example?
> 
> Similar for the merged-/usr via symlinks example above:
> 
> The same can be archived by:
> --hook-dir=/usr/share/mmdebstrap/hooks/

I fixed it like this:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/594ea3c72e7af26b680d2bfb696c0271839b731d

> Thanks for the great tool!

Thank you for your bug report. :)

cheers, josch

signature.asc
Description: signature

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

[Christoph Anton Mitterer]

Control: tags -1 - moreinfo

On Mon, 2021-05-31 at 11:08 +0200, Nicolas Schier wrote:
> To validate my argumentation, 
> please set 'COMPRESS=gzip' in '/etc/initramfs-tools/initramfs.conf', 
> run 'update-initramfs -u' again and compare the sizes of the
> (probably) 
> zstd-compressed one with the gzip-compressed one.

That gives:

With zstd:
# file initrd*
initrd.img-5.10.0-7-amd64: ASCII cpio archive (SVR4 with no CRC)

# l initrd*
-rw-r--r-- 1 root root 26M May 30 06:21 initrd.img-5.10.0-7-amd64


Changing to gzip:
# update-initramfs -u
...


# file initrd*
initrd.img-5.10.0-7-amd64: ASCII cpio archive (SVR4 with no CRC)

# l initrd*
-rw-r--r-- 1 root root 33M May 31 15:54 initrd.img-5.10.0-7-amd64


Cheers,
Chris.

Bug#989288: CVE-2021-29629

[Christoph Berg]

Re: Moritz Muehlenhoff
> Package: dacs
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> dacs bundles a copy in src/libradius/src/radlib.c:
> https://www.freebsd.org/security/advisories/FreeBSD-SA-21:12.libradius.asc

Fwiw, the package is orphaned, I do not intend to fix this personally.

I am not aware of anyone using the package (the company for which we
were packaging it has moved to something else, and iirc Jonas who was
interested in it some time ago has also said he went for something
else), so removal from bullseye is certainly an option.

Christoph

Bug#469263: devscripts: new script to access ldap/machines.cgi and login to machines

[Roger Shimizu]

Update the patch from Guillem Jover
to add fuzz rule for hurd and kfreebsd.

Hope this patch can be merged some day.
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1


deb-porterbox
Description: Binary data

Bug#989303: RFS: backintime/1.2.1-3 [RC] -- simple backup/snapshot system

[Fabian Wolff]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for an upload of the 'backintime' package.

The upload fixes a release critical bug in the current version of the
package (#946349). A patch was provided in the Debian bug tracking
system and has since been applied upstream.

My changes in this upload consist solely of cherry-picking the fix for
#946349. Therefore, this upload is a targeted fix for a release
critical bug and should qualify as an appropriate change according to
the bullseye freeze policy [1].

Since this package neither is a key package nor has any autopkgtests,
it will require manual review by the release team. Bullet point five
of "Applying for an unblock" in the freeze policy states that

  If the diff is small and you believe it will be approved, you can
  upload it to unstable before filing the unblock request to avoid a
  round-trip.

I suppose this applies here, which is why I'm looking for a sponsor
for this upload now. The package is available on Salsa as well as on
Mentors:

  https://salsa.debian.org/jmw/pkg-backintime
  https://mentors.debian.net/package/backintime/

I have also attached the debdiff of my changes vs. the current version
of the package in testing/unstable.

Thanks for your help!
Fabian

[1] https://release.debian.org/bullseye/freeze_policy.html
diff -Nru backintime-1.2.1/debian/changelog backintime-1.2.1/debian/changelog
--- backintime-1.2.1/debian/changelog	2019-10-30 22:35:50.0 +0100
+++ backintime-1.2.1/debian/changelog	2021-05-31 15:14:50.0 +0200
@@ -1,3 +1,10 @@
+backintime (1.2.1-3) unstable; urgency=medium
+
+  * Cherry-pick patch for #946349 from upstream Git repository
+(Closes: #946349).
+
+ -- Fabian Wolff   Mon, 31 May 2021 15:14:50 +0200
+
 backintime (1.2.1-2) unstable; urgency=medium
 
   * Source-only reupload after the package has been in the NEW queue
diff -Nru backintime-1.2.1/debian/patches/00-fix-946349.patch backintime-1.2.1/debian/patches/00-fix-946349.patch
--- backintime-1.2.1/debian/patches/00-fix-946349.patch	1970-01-01 01:00:00.0 +0100
+++ backintime-1.2.1/debian/patches/00-fix-946349.patch	2021-05-31 15:14:50.0 +0200
@@ -0,0 +1,39 @@
+Description: Cherry-pick fix for #946349 from upstream repository
+Origin: upstream, https://github.com/bit-team/backintime/commit/7f6f570a01e7e0a623e670baaf63eaaf879948c4
+Bug: https://github.com/bit-team/backintime/issues/974
+Bug-Debian: https://bugs.debian.org/946349
+Last-Update: 2021-05-31
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/common/mount.py
 b/common/mount.py
+@@ -648,7 +648,7 @@
+ """
+ tools.mkdir(self.mount_root, 0o700)
+ tools.mkdir(self.hash_id_path, 0o700)
+-tools.mkdir(self.currentMountpoint, 0o700)
++tools.mkdir(self.currentMountpoint, 0o700, False)
+ tools.mkdir(self.lock_path, 0o700)
+ 
+ def mountProcessLockAcquire(self, timeout = 60):
+--- a/common/tools.py
 b/common/tools.py
+@@ -287,7 +287,7 @@
+  %(path, str(e)), traceDepth = 1)
+ return os.path.isdir(path)
+ 
+-def mkdir(path, mode = 0o755):
++def mkdir(path, mode = 0o755, enforce_permissions = True):
+ """
+ Create directory ``path``.
+ 
+@@ -300,7 +300,8 @@
+ """
+ if os.path.isdir(path):
+ try:
+-os.chmod(path, mode)
++if enforce_permissions:
++os.chmod(path, mode)
+ except:
+ return False
+ return True
diff -Nru backintime-1.2.1/debian/patches/series backintime-1.2.1/debian/patches/series
--- backintime-1.2.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ backintime-1.2.1/debian/patches/series	2021-05-31 15:14:50.0 +0200
@@ -0,0 +1 @@
+00-fix-946349.patch

Bug#989236: crossgrader: crashes with "Could not mark python3-apt:amd64 for install, fixing manually."

[Kevin Wu]

On Mon, May 31, 2021 at 4:26 AM Adam Borowski  wrote:
> But, is there _any_ case when crossgrader might possibly work?  As it needs
> python-apt-common, it will always fail.  That makes the package useless.
> Should we bump #968458 to a RC severity?

crossgrader won't be able to work if python3-apt cannot be
crossgraded, so there's no case where it would work. Would #968458
merit critical for breaking unrelated software?

> It appears to me that hardly anyone had the opportunity to test crossgrader...

Unfortunately, that much is true...

However, even without the Multi-Arch changes for python-apt-common,
crossgrader works around the problem in Buster without user input
required. Perhaps some part of APT was changed which prevents it from
working.

Bug#988923: RFS: distorm3/3.5.2b-1 -- powerful disassembler library for x86/AMD64 binary streams (Python3 bindings)

[Adam Borowski]

On Fri, May 21, 2021 at 02:51:36PM +, Lin Qigang wrote:
>  * Package name: distorm3
>Version : 3.5.2b-1

> Changes since the last upload:
> 
>  distorm3 (3.5.2b-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Removed fix_init_python patch
>* debian/patches: Added patch to update the library version number
>* debian/*.links: Updated symbolic links to new upstream version
>* debian/not-installed: Account for varying python3 directory naming scheme
>* debian/patches: Added makefile library version fix patch
>* debian/libdistorm3-3.symbols: Updated symbols to 3.5.2b
>* debian/python3-distorm: Account for varying python3 directory naming 
> scheme
>* debian/rules: Account for upstream build changes
>* debian/copyright: Updated packaging copyright years
>* debian/control: Updated maintainer
>* Release to unstable

Hi!
This upload is targetted at unstable, which is currently affected by the
hard freeze.  Only targetted fixes are permitted, not whole new upstream
releases (unless the upstream release consists of nothing but fixes...).

Thus, your options here would be:
 * targetting experimental instead, or
 * waiting until after Bullseye is released


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant:
⣾⠁⢠⠒⠀⣿⡁   Reverently made for universal free distribution by Wang Jie
⢿⡄⠘⠷⠚⠋⠀   on behalf of his two parents on the 15th of the 4th moon of
⠈⠳⣄   the 9th year of Xiantong [11 May 868].

Bug#989245: python3-django needs to depends on libjs-jquery, not only recommend this package

[Chris Lamb]

Hi Carsten,

> FileNotFoundError: [Errno 2] No such file or directory:
> '/usr/lib/python3/dist-packages/django/contrib/admin/static/admin/js/vendor/jquery/jquery.js'

[..]

> So looking around for the missing file indeed I see this isn't there.
> Looking at the python3-django package I can see that the package
> libjs-jquery isn't a hard dependency and only recommended.

So I'm pretty much just paraphrasing the definition of the Depends
field here (hence why there is no explicit note in the Django
packaging itself), but the libjs-jquery package is not required to
provide a significant amount of functionality in Django. Needless to
say, the python3-django package can be installed without libjs-jquery
being installed.

This is all to say that given that your custom patchy2 package calls
collectstatic during its own package configuration stage, would it not
make more sense to specify libjs-query as a Depends on your package
instead?


Regards,

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

Bug#989118: please try https first

[Eduard Bloch]

Hallo,
* Harald Dunkel [Wed, May 26 2021, 10:10:16AM]:
> Package: apt-cacher-ng
> Version: 3.6.3-1
> Severity: wishlist
>
> Sorry to say, but configuring https for apt-cacher-ng is APITA. Would it be
> possible for ACNG to silently try https first, if the client asked for http?
> That would be similar to an explicit http://HTTPS///get.docker.com/ubuntu,
> except for the client doesn't have to know.

Here you can play with it:

https://salsa.debian.org/blade/apt-cacher-ng/-/tree/feature/debian/bts-989118_Optimistic-TLS-probing

But I am not convinced, it has issues:

a) additional network traffic
b) most mirrors have some kind of broken or missing TLS configuration
like snake-oil cets or generic host cert not matching the mirror hostname and
apparently no SNI active. This can be "mitigated" by partly disabling
the host validation but it makes it insecure.
c) some mirrors actually offering different folder configuration on TLS
port, therefore delivering 404 or maybe even wrong contents.

The last problem is hard to detect and to work around in reliable
fashion. So basically I'd prefer not to include this feature for now.

Best regards,
Eduard.

Bug#988716: platformio 4.3.4 cannot download required frameworks

[Stefano Rivera]

Hi Sebastian (2021.05.18_10:34:31_-0400)
> Upstream changed paths for the framework manifest files in recent
> releases and did not maintain backward compatibility links resulting
> in 4.3.4 no longer being able to install the frameworks.

Had a quick look, and it's worse than that. Not just a change in paths,
but an entire new package manager, with a new API (/v2/ in the URLs).

Changelog: 
https://github.com/platformio/platformio-core/blob/master/HISTORY.rst#500-2020-09-03
Some relevant history here: 
https://github.com/platformio/platformio-core/commits/59b02120b648a41965974f27ac0b6c5d44dd11d3/platformio/package/manager/platform.py

> This means the package is basically unusable for new installations
> Since it did not exist in buster, it is always a new installation
> in bullseye. Considering we are in late freeze phase I suggest to
> drop the package from Debian testing (and upload a new upstream
> release to sid).

Sounds like the right call.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#987360: swaylock: Occassional unlock without password entered

[Adrian Bunk]

On Thu, May 20, 2021 at 09:59:54PM +0930, Andrew Savchenko wrote:
> Pelle,

It might not have reached him, the Debian bug tracker defaults to not 
sending a copy to the submitter.

> Would you be able to add a stack trace?
>  Here, or directly with the upstream:
> https://github.com/swaywm/swaylock/issues/181

I'll answer there with a stacktrace based on the coredump.

> Thanks.

cu
Adrian

Bug#989302: mmdebstrap: busybox-based chroot example misses mktemp

[Jochen Sprickerhof]

Package: mmdebstrap
Version: 0.7.5-2.2
Severity: minor

Hi Josch,

I just tried the sub-essential busybox-based chroot example from the man
page on an up to date sid and got:

/var/lib/dpkg/info/base-passwd.postinst: line 1: mktemp: not found

Adding mktemp to the setup-hook ln loop fixes it.

In addition it probably makes sense to add something like this below:

The same can be archived by:
--hook-dir=/usr/share/mmdebstrap/hooks/busybox

Or maybe replace the example?

Similar for the merged-/usr via symlinks example above:

The same can be archived by:
--hook-dir=/usr/share/mmdebstrap/hooks/

Thanks for the great tool!

Cheers Jochen

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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.2.3
ii  perl 5.32.1-4
ii  python3  3.9.2-3

Versions of packages mmdebstrap recommends:
ii  arch-test0.17-1
pn  fakechroot   
ii  fakeroot 1.25.3-1.1
ii  gpg  2.2.27-2
pn  libdistro-info-perl  
ii  mount2.36.1-7
ii  uidmap   1:4.8.1-1

Versions of packages mmdebstrap suggests:
ii  apt [apt-transport-https]  2.2.3
pn  apt-transport-tor  
ii  apt-utils  2.2.3
ii  binfmt-support 2.2.1-1
ii  ca-certificates20210119
ii  debootstrap1.0.123
ii  distro-info-data   0.47
ii  dpkg-dev   1.20.9
pn  perl-doc   
pn  proot  
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  

-- no debconf information

Bug#987430: upgrade-reports: KDE Plasma without panels and without background after upgrade from Buster to Bullseye

[Malvin Gattinger]

Hi Norbert,


Does the script also contain the part of the re-installation?


Unfortunately no, the script only contains the upgrade to 
bullseye, but after that I rebooted and did not record the 
reinstall.



All that is really difficult to debug, though ...


Indeed. I now also installed a new virtual machine with buster, 
then tried to somewhat mimic which packages I have installed, and 
upgraded to bullseye. No problems this time, KDE worked fine.


So if nobody besides me reports this, maybe this bug should just 
be closed?


best,
Malvin

Bug#989301: prometheus-nextcloud-exporter: French debconf templates translation

[Lucien Gentis]

Package: prometheus-nextcloud-exporter
Version: N/A
Severity: wishlist
Tags: patch l10n


Please find attached the french debconf templates translation, proofread
by the
debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.



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

Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
# Translation of prometheus-nextcloud-exporter debconf templates to French
# Copyright (C) 2021, French l10n team 
# This file is distributed under the same license as the 
prometheus-nextcloud-exporter package.
#
# Translators:
#
# Lucien Gentis , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: prometheus-nextcloud-exporter-0.4.0-2\n"
"Report-Msgid-Bugs-To: prometheus-nextcloud-exporter@packages.debian."
"org\n"
"POT-Creation-Date: 2021-04-04 13:41+0200\n"
"PO-Revision-Date: 2021-05-26 14:12+0200\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Last-Translator: Lucien Gentis \n"
"Language-Team: French \n"
"X-Generator: Poedit 2.2.1\n"

#. Type: string
#. Description
#: ../templates:1001
msgid "URL to Nextcloud server:"
msgstr "URL du serveur Nextcloud :"

#. Type: string
#. Description
#: ../templates:2001
msgid "Username for connecting to Nextcloud:"
msgstr "Nom d'utilisateur pour la connexion à Nextcloud :"

# metrics : statistiques, mesures, données en provenance de ... ?
#. Type: string
#. Description
#: ../templates:2001
msgid ""
"This user needs admin privileges in order to have access to the metrics."
msgstr ""
"Cet utilisateur doit posséder les droits d'administrateur pour avoir "
"accès aux statistiques."

#. Type: password
#. Description
#: ../templates:3001
msgid "Password for connecting to Nextcloud:"
msgstr "Mot de passe pour la connexion à Nextcloud :"

#. Type: password
#. Description
#: ../templates:3001
msgid ""
"It's highly recommended to generate an application password without "
"filesystem access."
msgstr ""
"Il est fortement recommandé de générer un mot de passe d'application "
"sans accès au système de fichiers."

Bug#989294: unblock: insighttoolkit4/4.13.3withdata-dfsg1-4.1

[Andreas Beckmann]

On 31/05/2021 13.54, Sebastian Ramacher wrote:

Let's wait a bit before unblocking this one. We need to figure out how
to deal with #988722.


That looks nasty.


If we end up doing a transition for that, this
Breaks is not necessary (and potentially harmful).


Please keep me in the loop if you have a (possible) solution for that 
one and I can run more upgrade tests.


Andreas

Bug#989299: ITP: openarc -- Authenticated Received Chain (ARC) milter

[David Bürgin]

Package: wnpp
Severity: wishlist
Owner: David Bürgin 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: openarc
  Version : 1.0.0~beta3
  Upstream Author : The Trusted Domain Project
* URL : https://github.com/trusteddomainproject/OpenARC
* License : BSD-2-Clause and Sendmail
  Programming Lang: C
  Description : Authenticated Received Chain (ARC) milter

The OpenARC project provides an Authenticated Received Chain (ARC)
library and milter. ARC is an experimental protocol specified in RFC
8617. ARC provides an authenticated relay chain that allows email
message handlers to see the message's authentication status at each step
of the message-handling path.

OpenARC is an initiative of the Trusted Domain Project. The Trusted
Domain Project also maintains the related software packages OpenDKIM and
OpenDMARC.

I plan to maintain this software via sponsorship on Debian mentors, just
like OpenDKIM and OpenDMARC.

Bug#989298: RFP: scylladb -- Distributed NoSQL database API-compatible with Apache Cassandra and Amazon DynamoDB

[Federico Ceratto]

Package: wnpp
Severity: wishlist

* Package name: scylladb
  Version : 4.4.2
  Upstream Author : ScyllaDB, Inc
* URL : https://github.com/scylladb/scylla
* License : AGPL
  Programming Lang: C++
  Description : Distributed NoSQL database API-compatible with Apache 
Cassandra and Amazon DynamoDB

Scylla supports replications and fault tolerance based on
eventual consistency.

Bug#989297: unblock: libaec/1.0.4-2

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-05-31 13:52:26, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package libaec
> 
> Let's add some Breaks for smoother upgrades from buster due to the hdf5
> library renames.
> 
> libhdf5*-103 got renamed to libhdf5*-103-1 and these two are not
> co-installable, making upgrades harder for apt.
> Both depend on libsz2, so libsz2 usually gets a higher score in apt and
> is thus a good candidate for these Breaks.
> Transitive Breaks usually don't work well in apt, so let's break some
> more old library packages in this dependency chain (further renames not
> co-installable due to hdf5: libgdal20 -> libgdal28, libnetcdf13 ->
> libnetcdf18).

Sames as #989294

Cheers

> 
> Andreas
> 
> unblock libaec/1.0.4-2

> diff -Nru libaec-1.0.4/debian/changelog libaec-1.0.4/debian/changelog
> --- libaec-1.0.4/debian/changelog 2019-07-19 14:54:12.0 +0200
> +++ libaec-1.0.4/debian/changelog 2021-04-26 16:54:22.0 +0200
> @@ -1,3 +1,11 @@
> +libaec (1.0.4-2) unstable; urgency=medium
> +
> +  * Team upload.
> +  * libsz2: Add 'Breaks: libhdf5-103, libhdf5-mpich-103, libhdf5-openmpi-103,
> +libnetcdf13, libgdal20' for smoother upgrades from buster.
> +
> + -- Andreas Beckmann   Mon, 26 Apr 2021 16:54:22 +0200
> +
>  libaec (1.0.4-1) unstable; urgency=medium
>  
>* New upstream release
> diff -Nru libaec-1.0.4/debian/control libaec-1.0.4/debian/control
> --- libaec-1.0.4/debian/control   2019-07-19 14:54:12.0 +0200
> +++ libaec-1.0.4/debian/control   2021-04-26 16:54:22.0 +0200
> @@ -2,13 +2,13 @@
>  Section: utils
>  Priority: optional
>  Maintainer: Alastair McKinstry 
> -Build-Depends: debhelper-compat (= 12), 
> - dh-buildinfo, 
> +Build-Depends: debhelper-compat (= 12),
> + dh-buildinfo,
>   unzip
>  Standards-Version: 4.4.0
> -Homepage:  https://gitlab.dkrz.de/k202009/libaec
> -Vcs-Browser: https://salsa.debian.org:/science-team/libaec.git
> -Vcs-Git: https://salsa.debian.org:/science-team/libaec.git
> +Homepage: https://gitlab.dkrz.de/k202009/libaec
> +Vcs-Browser: https://salsa.debian.org/science-team/libaec
> +Vcs-Git: https://salsa.debian.org/science-team/libaec.git
>  
>  Package: libaec0
>  Section: libs
> @@ -35,10 +35,11 @@
>  Priority: optional
>  Depends: ${misc:Depends}, ${shlibs:Depends}
>  Pre-Depends: ${misc:Pre-Depends}
> +Breaks: libhdf5-103, libhdf5-mpich-103, libhdf5-openmpi-103, libnetcdf13, 
> libgdal20
>  Multi-Arch: same
>  Description: Adaptive Entropy Coding library - SZIP
>   Libaec provides fast lossless compression of 1 up to 32 bit wide
> - signed or unsigned integers (samples). 
> + signed or unsigned integers (samples).
>   Libaec implements Golomb Rice coding as defined in the Space Data
>   System Standard documents 121.0-B-2 [1] and 120.0-G-2[2].
>   .
> @@ -63,7 +64,7 @@
>  Section: utils
>  Architecture: any
>  Depends: ${misc:Depends}, ${shlibs:Depends}
> -Description: Adaptive Entropy Coding library (utilies)
> +Description: Adaptive Entropy Coding library (utilities)
>   Libaec provides fast lossless compression of 1 up to 32 bit wide
>   signed or unsigned integers (samples).
>   .


-- 
Sebastian Ramacher

Bug#989294: unblock: insighttoolkit4/4.13.3withdata-dfsg1-4.1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-05-31 13:32:33, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package insighttoolkit4
> 
> Let's add some Breaks for smoother upgrades from buster due to the hdf5
> library renames.

Let's wait a bit before unblocking this one. We need to figure out how
to deal with #988722. If we end up doing a transition for that, this
Breaks is not necessary (and potentially harmful).

Cheers

> 
> Andreas
> 
> unblock insighttoolkit4/4.13.3withdata-dfsg1-4.1

> diff -Nru insighttoolkit4-4.13.3withdata-dfsg1/debian/changelog 
> insighttoolkit4-4.13.3withdata-dfsg1/debian/changelog
> --- insighttoolkit4-4.13.3withdata-dfsg1/debian/changelog 2020-12-28 
> 20:55:32.0 +0100
> +++ insighttoolkit4-4.13.3withdata-dfsg1/debian/changelog 2021-05-04 
> 10:51:08.0 +0200
> @@ -1,3 +1,13 @@
> +insighttoolkit4 (4.13.3withdata-dfsg1-4.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * libinsighttoolkit4.13: Add Breaks: libinsighttoolkit4.12 for smoother
> +upgrades from buster. The libraries are not co-installable due to the
> +libhdf5-103 -> libhdf5-103-1 and other package renames.
> +Closes: #986927
> +
> + -- Andreas Beckmann   Tue, 04 May 2021 10:51:08 +0200
> +
>  insighttoolkit4 (4.13.3withdata-dfsg1-4) unstable; urgency=medium
>  
>* Team upload.
> diff -Nru insighttoolkit4-4.13.3withdata-dfsg1/debian/control 
> insighttoolkit4-4.13.3withdata-dfsg1/debian/control
> --- insighttoolkit4-4.13.3withdata-dfsg1/debian/control   2020-12-28 
> 20:44:45.0 +0100
> +++ insighttoolkit4-4.13.3withdata-dfsg1/debian/control   2021-04-14 
> 10:02:47.0 +0200
> @@ -34,6 +34,7 @@
>  Section: libs
>  Architecture: amd64 i386
>  Depends: ${shlibs:Depends}, ${misc:Depends}
> +Breaks: libinsighttoolkit4.12
>  Description: Image processing toolkit for registration and segmentation - 
> runtime
>   ITK is an open-source software toolkit for performing registration and
>   segmentation. Segmentation is the process of identifying and


-- 
Sebastian Ramacher

Bug#989244: spectral: login works, but then no chats/rooms etc. appear, nothing can be clicked on

[Mike Gabriel]

Control: retitle -1 spectral: behaves unpredictably when logged in with 
username only (segfaults, dead controls, etc.)

Hi,

On Sun, May 30, 2021 at 09:59:12PM -0400, Andres Salomon wrote:

> > It seems that this application is not really suitable for Debian 11
> > inclusion, is it? What am I missing?
> > 
> It's rough around the edges, but has been perfectly usable for me.

Previous mail didn't retitle correctly, re-trying now (with mutt, instead of 
Horde webmailer).

Mike
 

-- 

mike gabriel aka sunweaver (Debian Developer)
fon: +49 (1520) 1976 148

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



signature.asc
Description: PGP signature

Bug#989297: unblock: libaec/1.0.4-2

[Andreas Beckmann]

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

Please unblock package libaec

Let's add some Breaks for smoother upgrades from buster due to the hdf5
library renames.

libhdf5*-103 got renamed to libhdf5*-103-1 and these two are not
co-installable, making upgrades harder for apt.
Both depend on libsz2, so libsz2 usually gets a higher score in apt and
is thus a good candidate for these Breaks.
Transitive Breaks usually don't work well in apt, so let's break some
more old library packages in this dependency chain (further renames not
co-installable due to hdf5: libgdal20 -> libgdal28, libnetcdf13 ->
libnetcdf18).

Andreas

unblock libaec/1.0.4-2
diff -Nru libaec-1.0.4/debian/changelog libaec-1.0.4/debian/changelog
--- libaec-1.0.4/debian/changelog   2019-07-19 14:54:12.0 +0200
+++ libaec-1.0.4/debian/changelog   2021-04-26 16:54:22.0 +0200
@@ -1,3 +1,11 @@
+libaec (1.0.4-2) unstable; urgency=medium
+
+  * Team upload.
+  * libsz2: Add 'Breaks: libhdf5-103, libhdf5-mpich-103, libhdf5-openmpi-103,
+libnetcdf13, libgdal20' for smoother upgrades from buster.
+
+ -- Andreas Beckmann   Mon, 26 Apr 2021 16:54:22 +0200
+
 libaec (1.0.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru libaec-1.0.4/debian/control libaec-1.0.4/debian/control
--- libaec-1.0.4/debian/control 2019-07-19 14:54:12.0 +0200
+++ libaec-1.0.4/debian/control 2021-04-26 16:54:22.0 +0200
@@ -2,13 +2,13 @@
 Section: utils
 Priority: optional
 Maintainer: Alastair McKinstry 
-Build-Depends: debhelper-compat (= 12), 
- dh-buildinfo, 
+Build-Depends: debhelper-compat (= 12),
+ dh-buildinfo,
  unzip
 Standards-Version: 4.4.0
-Homepage:  https://gitlab.dkrz.de/k202009/libaec
-Vcs-Browser: https://salsa.debian.org:/science-team/libaec.git
-Vcs-Git: https://salsa.debian.org:/science-team/libaec.git
+Homepage: https://gitlab.dkrz.de/k202009/libaec
+Vcs-Browser: https://salsa.debian.org/science-team/libaec
+Vcs-Git: https://salsa.debian.org/science-team/libaec.git
 
 Package: libaec0
 Section: libs
@@ -35,10 +35,11 @@
 Priority: optional
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
+Breaks: libhdf5-103, libhdf5-mpich-103, libhdf5-openmpi-103, libnetcdf13, 
libgdal20
 Multi-Arch: same
 Description: Adaptive Entropy Coding library - SZIP
  Libaec provides fast lossless compression of 1 up to 32 bit wide
- signed or unsigned integers (samples). 
+ signed or unsigned integers (samples).
  Libaec implements Golomb Rice coding as defined in the Space Data
  System Standard documents 121.0-B-2 [1] and 120.0-G-2[2].
  .
@@ -63,7 +64,7 @@
 Section: utils
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
-Description: Adaptive Entropy Coding library (utilies)
+Description: Adaptive Entropy Coding library (utilities)
  Libaec provides fast lossless compression of 1 up to 32 bit wide
  signed or unsigned integers (samples).
  .

Bug#989296: missing dependencies and wrong path in the .cmake file

[Picca Frédéric-Emmanuel]

Package: libvtkgdcm-dev
Severity: important
X-Debbugs-Cc: pi...@debian.org


Hello,

I try to build a package but it end up with this error message

-- The imported target "vtkgdcm" references the file
   "/usr/lib/x86_64-linux-gnu/libvtkgdcm.so.3.0.8"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "vtkgdcmsharpglue" references the file
   "/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "vtkgdcmJava" references the file
   "/usr/lib/x86_64-linux-gnu/jni/libvtkgdcmJava.so"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "vtkgdcmPython" references the file
   "/usr/lib/python/dist-packages/vtkgdcmPython.so"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "vtkgdcmPythonD" references the file
   "/usr/lib/x86_64-linux-gnu/libvtkgdcmPythonD.so.3.0.8"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "gdcmdump" references the file
   "/usr/bin/gdcmdump"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "gdcmdiff" references the file
   "/usr/bin/gdcmdiff"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "gdcmraw" references the file
   "/usr/bin/gdcmraw"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "gdcmscanner" references the file
   "/usr/bin/gdcmscanner"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "gdcmanon" references the file
   "/usr/bin/gdcmanon"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "gdcmgendir" references the file
   "/usr/bin/gdcmgendir"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
but not all the files it references.

-- The imported target "gdcmimg" references the file
   "/usr/bin/gdcmimg"
but this file does not exist.  Possible reasons include:
* 

Bug#989295: unblock: mialmpick/0.2.15-1

[Adrian Bunk]

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

Please unblock package mialmpick.

mialmpick was just removed from testing because I forgot
to set "bookworm sid" tags to #987937 in time.

This is a latent bug exposed by #702010, but that change
is not and will not be in bullseye where mialmpick builds:
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/mialmpick.html

It would be appreciated if mialmpick (which has been in the previous
stable releases) would be allowed to re-enter bullseye in the version
that had been in bullseye for over a year.

unblock mialmpick/0.2.15-1

Thanks in advance

Bug#989294: unblock: insighttoolkit4/4.13.3withdata-dfsg1-4.1

[Andreas Beckmann]

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

Please unblock package insighttoolkit4

Let's add some Breaks for smoother upgrades from buster due to the hdf5
library renames.

Andreas

unblock insighttoolkit4/4.13.3withdata-dfsg1-4.1
diff -Nru insighttoolkit4-4.13.3withdata-dfsg1/debian/changelog 
insighttoolkit4-4.13.3withdata-dfsg1/debian/changelog
--- insighttoolkit4-4.13.3withdata-dfsg1/debian/changelog   2020-12-28 
20:55:32.0 +0100
+++ insighttoolkit4-4.13.3withdata-dfsg1/debian/changelog   2021-05-04 
10:51:08.0 +0200
@@ -1,3 +1,13 @@
+insighttoolkit4 (4.13.3withdata-dfsg1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * libinsighttoolkit4.13: Add Breaks: libinsighttoolkit4.12 for smoother
+upgrades from buster. The libraries are not co-installable due to the
+libhdf5-103 -> libhdf5-103-1 and other package renames.
+Closes: #986927
+
+ -- Andreas Beckmann   Tue, 04 May 2021 10:51:08 +0200
+
 insighttoolkit4 (4.13.3withdata-dfsg1-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru insighttoolkit4-4.13.3withdata-dfsg1/debian/control 
insighttoolkit4-4.13.3withdata-dfsg1/debian/control
--- insighttoolkit4-4.13.3withdata-dfsg1/debian/control 2020-12-28 
20:44:45.0 +0100
+++ insighttoolkit4-4.13.3withdata-dfsg1/debian/control 2021-04-14 
10:02:47.0 +0200
@@ -34,6 +34,7 @@
 Section: libs
 Architecture: amd64 i386
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: libinsighttoolkit4.12
 Description: Image processing toolkit for registration and segmentation - 
runtime
  ITK is an open-source software toolkit for performing registration and
  segmentation. Segmentation is the process of identifying and

Bug#989236: crossgrader: crashes with "Could not mark python3-apt:amd64 for install, fixing manually."

[Adam Borowski]

On Sun, May 30, 2021 at 12:29:33PM -0700, Kevin Wu wrote:
> Hello!
> 
> This behavior is due to python-apt-common not being marked as
> Multi-Arch: foreign. I have already filed a bug report at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968458
> 
> If you would like to continue, you can modify the python-apt-common
> entry in /var/lib/dpkg/status to include Multi-Arch: foreign and run
> crossgrader again.

Aye, this helped!

But, is there _any_ case when crossgrader might possibly work?  As it needs
python-apt-common, it will always fail.  That makes the package useless.
Should we bump #968458 to a RC severity?

It's an obvious one-liner fix, and, with python-apt having an autopkgtest,
the upload wouldn't even require asking for a freeze exception.

> I'm not quite sure why this is stopping crossgrader
> on Bullseye but not on Buster; I'll look into it.

It hasn't been a part of Buster, and there's no backport for it in the
archive either (the latter is a bit we can fix).  It appears to me that
hardly anyone had the opportunity to test crossgrader...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant:
⣾⠁⢠⠒⠀⣿⡁   Reverently made for universal free distribution by Wang Jie
⢿⡄⠘⠷⠚⠋⠀   on behalf of his two parents on the 15th of the 4th moon of
⠈⠳⣄   the 9th year of Xiantong [11 May 868].

Bug#989244: spectral: behaves unpredictably when logged in with username only (segfaults, dead controls, etc.)

[Mike Gabriel]

Control: retitle -1 spectral: behaves unpredictably when logged in  
with username only (segfaults, dead controls, etc.)

Control: severity -1 important

Hi,

On  Mo 31 Mai 2021 03:59:12 CEST, Andres Salomon wrote:


On 5/30/21 5:48 AM, Mike Gabriel wrote:

Package: spectral
Version: 0.0~git20210114.30028a2-2
Severity: grave

I have just tested the spectral [matrix]-Client on Debian bullseye  
(still testing) and only thing I can do with it is logon (giving  
matrix server name, username and password, plus device name).


Which matrix server are you using?


I run matrix-synapse from Debian unstable ("backported" / rebuilt to  
Debian bullseye).


I also tried it against my matrix.org account.

The login API call returns a 200 result (which looks like success),  
but then nothing is happening in the application. I cannot create  
new chats, I cannot open any rooms and also my room list that I see  
in other clients does not appear in spectral.


Spectral is not good about showing login failures. This isn't  
something that affects regular users (since you only ever log in  
once), but it's annoying for first-time users. Make sure you're  
using the full login name - the format would be @user:server. For  
example, I use @dilinger:queued.net. Even if you're using the  
default server (matrix.org), you'll probably need to add it.


When using the @username:server.tld login name scheme, spectral  
becomes usable, indeed.


This should be documented and maybe you can escalate this to upstream.

It seems to present a half-successful login if I simply use username  
(not @username, not @username:server.tld), but from there on,  
everything fails.


IMHO, spectral could be more assumptive for different login schemes.  
(Prepend an "@" if missing, append a :, or in fact, look  
for .well-known delegation configs for deriving the server_name).




It seems that this application is not really suitable for Debian 11  
inclusion, is it? What am I missing?



It's rough around the edges, but has been perfectly usable for me.


Now that I have successfully logged into matrix.org and my own  
homeserver, I will investigate a little more.


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpKTW1ezqcPv.pgp
Description: Digitale PGP-Signatur

Bug#989293: unblock: breeze/4:5.20.5-4

[Norbert Preining]

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

Please unblock package breeze

[ Reason ]

The fix that was included in -3 introduced a different problem that was
recently fixed by upstream and pushed to stable branches.
KDE bug: 436473

The problem is that under certain circumstances the mouse cursor could
get stuck in form of resize icon.

Upstream comments are in the attached patch, I only include the
important paragraph here
> This was broken by accident in d201a1f187 ("Fix SplitterProxy not clearing
> when above another QSplitterHandle"), which moved the hide() call past the
> call to QCoreApplication::sendEvent. Previously that made isVisible() false,
> which also prevented the interception of the HoverLeave/HoverMove events.

[ Impact ]
If the bug remains unfixed, the mouse cursor might remain stuck in
resize form without a way to revert it.

[ Tests ]
Manual test trying to trigger the bug.

[ Risks ]
The code has been approved by upstream and included in 5.18 LTS and 5.20.

[ 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


I attach only the patch that is added, the remaining changes are:
debian/changelog entry:
breeze (4:5.20.5-4) unstable; urgency=medium

  [ Norbert Preining ]
  * Upstream fix for cursor stuck in resize icon.

 -- Norbert Preining   Sun, 30 May 2021 05:58:28 +0900

and adding the patch to debian/patches/series.


unblock breeze/4:5.20.5-4
>From f99b7ef621c9c69544158d245699fd8104db6753 Mon Sep 17 00:00:00 2001
From: Fabian Vogt 
Date: Sat, 15 May 2021 17:45:54 +0200
Subject: [PATCH] Fix informing the underlying widget when leaving
 SplitterProxy

While the SplitterProxy is active, it intercepts all relevant events, so that
the underlying widget still thinks it's in the same "on splitter" state. When
the SplitterProxy is left, the underlying widget is sent a HoverLeave/HoverMove
event to make it aware of the new current cursor position. Without this, it
doesn't know that it's not supposed to be in the "on splitter" state, and when
it regains focus it just re-activates the SplitterProxy at the current cursor
position.

This was broken by accident in d201a1f187 ("Fix SplitterProxy not clearing
when above another QSplitterHandle"), which moved the hide() call past the
call to QCoreApplication::sendEvent. Previously that made isVisible() false,
which also prevented the interception of the HoverLeave/HoverMove events.

BUG: 436473
---
 kstyle/breezesplitterproxy.cpp | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/kstyle/breezesplitterproxy.cpp b/kstyle/breezesplitterproxy.cpp
index 0cf5685f..d4db407b 100644
--- a/kstyle/breezesplitterproxy.cpp
+++ b/kstyle/breezesplitterproxy.cpp
@@ -341,11 +341,14 @@ namespace Breeze
 // send hover event
 if( _splitter )
 {
-QHoverEvent hoverEvent(
-qobject_cast(_splitter.data()) ? 
QEvent::HoverLeave : QEvent::HoverMove,
-_splitter.data()->mapFromGlobal(QCursor::pos()), _hook);
-QCoreApplication::sendEvent( _splitter.data(),  );
+// SplitterProxy intercepts HoverLeave/HoverMove events to 
_splitter,
+// but this is meant to reach it directly. Unset _splitter to stop 
interception.
+auto splitter = _splitter;
 _splitter.clear();
+QHoverEvent hoverEvent(
+qobject_cast(splitter.data()) ? 
QEvent::HoverLeave : QEvent::HoverMove,
+splitter.data()->mapFromGlobal(QCursor::pos()), _hook);
+QCoreApplication::sendEvent( splitter.data(),  );
 }
 
 // kill timer if any
-- 
GitLab

Bug#989292: libpmix-dev: Wrong path for include in pmix.pc

[Alexandre DENIS]

Package: libpmix-dev
Version: 4.0.0-4
Severity: important

Dear Maintainer,

When asking for compilation flags to pkg-config for pmix, we get
no flags at all:

% pkg-config --cflags pmix

this is the case when headers are in /usr/include.
Indeed, when looking at the content of pmix.pc, we have:

prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include
[...]
Cflags: -I${includedir}

but headers are actually installed in /usr/lib/x86_64-linux-gnu/pmix2
and not in /usr/include. The path for includes in pmix.pc is not
consistent with the place where the headers are actually installed.

We can confirm the bug by trying to build the examples:

% cd /usr/share/doc/libpmix-dev/examples
% gcc `pkg-config --cflags --libs pmix` client.c
client.c:34:10: fatal error: pmix.h: No such file or directory
   34 | #include 
  |  ^~~~
compilation terminated.

Either the headers should be installed in /usr/include, or the
path in pmix.pc should be point to the correct location.

Thanks.


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-5-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 libpmix-dev depends on:
ii  libpmix2  4.0.0-4

libpmix-dev recommends no packages.

libpmix-dev suggests no packages.

-- no debconf information

Bug#989291: unblock: fabric/2.5.0-0.3

[Luca Boccassi]

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

Please unblock package fabric

The package has a missing dependency, and the bug has been marked RC:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956320

Adding the missing dependency fixes the issue. I have uploaded the fix
(debdiff inlined) to DELAYED/2, so it will be in sid on Wednesday.

unblock fabric/2.5.0-0.3

-- 
Kind regards,
Luca Boccassi

diff -Nru fabric-2.5.0/debian/changelog fabric-2.5.0/debian/changelog
--- fabric-2.5.0/debian/changelog   2019-12-08 15:58:47.0
+
+++ fabric-2.5.0/debian/changelog   2021-05-31 11:00:56.0
+0100
@@ -1,3 +1,10 @@
+fabric (2.5.0-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add dependency on python3-decorator (Closes: #956320)
+
+ -- Luca Boccassi   Mon, 31 May 2021 11:00:56 +0100
+
 fabric (2.5.0-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru fabric-2.5.0/debian/control fabric-2.5.0/debian/control
--- fabric-2.5.0/debian/control 2019-12-08 15:55:45.0 +
+++ fabric-2.5.0/debian/control 2021-05-31 10:57:31.0 +0100
@@ -20,6 +20,7 @@
 Package: fabric
 Architecture: all
 Depends: python3-fabric (>= ${source:Version}),
+ python3-decorator,
  python3-pkg-resources,
  ${misc:Depends},
  ${python3:Depends},


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

Bug#989290: unblock: node-got/11.8.1+~cs53.13.17-3

[Yadd]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package node-got

[ Reason ]
node-normalize-url (embedded in node-got) is vulnerable to a Regex
Denial of Service (ReDoS) (#989258, CVE-2021-33502). This little patch
fixes it.

[ Impact ]
Medium security issue

[ Tests ]
Sadly test are not enabled for this package due to missing test
dependencies

[ Risks ]
No risk here, patch is trivial (just a regex improvement)

[ 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

Cheers,
Yadd

unblock node-got/11.8.1+~cs53.13.17-3


-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmC0tMwQHHlhZGRAZGVi
aWFuLm9yZwAKCRD210ynyZnu6TKiD/4jlh7TN9AxaWxx2MJLho3t/w3eBaHL9zzP
091IzeAZndqYDzAsC0migMIeMpwS0laDg9WTafesq0kPWGPCPbFOtuiQo8CNAoP5
eakDTq0LZRjSDbziUe3QjT9YdSOeOBbopRkDx8fcpBu8Wutp6trsIgAUQ0xaGMYL
KJRzn/e90Ceqg+VUd9Pimp4EFnB+MfX5PPVUcJSJCFFgmHSQuvBPl9BV7qaIF05Y
n4H64Pa4bLh4+iSvvfbhvotnt7W091b86lTEuWzAv9XOijjeIRpkRPBUHRSXTSoc
BDhQ9kgE6y4PUip7iBpNTPRpZpSj0ow8kRcekoBYp9U9EO34dffk/czBj203FVWv
me61VJITKhLKuBhQ4GCHbXrmnMYcax+hZXiev9vvsF+v1W3pJgj0KFc51/cBkoCc
n+YuNq8+0ski1byjA3edk+VWsQz/q7ElNs3Y0ZvHH4nfA0UUXzastPlSw5qnoOyK
kkUFUdCF2w5i4HrJZ0bgKjA+c4eouAUkF8+z5ENQ2K6XJ1Iwqv8lwo162MfTPq1W
zNj6CWWBEgB+GLkEO7VBcpwrPMoJHkRejjZTRhUWBP47CnnzX6a+JOfLGYG/PytO
R6yLy/oWQtoPTsDDuqP0LH+korjw2DmFsH8DWxWbCdtmQzB1dEn7+htluK2h+Mbt
W5J0x1auFw==
=dUjO
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index c1ca5b3..9cda1ef 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-got (11.8.1+~cs53.13.17-3) unstable; urgency=medium
+
+  * Team upload
+  * Fix ReDoS (Closes: #989258, CVE-2021-33502)
+
+ -- Yadd   Mon, 31 May 2021 11:57:23 +0200
+
 node-got (11.8.1+~cs53.13.17-2) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2021-33502.patch 
b/debian/patches/CVE-2021-33502.patch
new file mode 100644
index 000..1572953
--- /dev/null
+++ b/debian/patches/CVE-2021-33502.patch
@@ -0,0 +1,40 @@
+Description: Fix ReDoS for data URLs
+Author: Sindre Sorhus 
+Origin: upstream, https://github.com/sindresorhus/normalize-url/commit/b1fdb51
+Bug: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33502
+Bug-Debian: https://bugs.debian.org/989258
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2021-05-31
+
+--- a/normalize-url/index.js
 b/normalize-url/index.js
+@@ -9,7 +9,7 @@
+ };
+ 
+ const normalizeDataURL = (urlString, {stripHash}) => {
+-  const match = 
/^data:(?.*?),(?.*?)(?:#(?.*))?$/.exec(urlString);
++  const match = 
/^data:(?[^,]*?),(?[^#]*?)(?:#(?.*))?$/.exec(urlString);
+ 
+   if (!match) {
+   throw new Error(`Invalid URL: ${urlString}`);
+--- a/normalize-url/test.js
 b/normalize-url/test.js
+@@ -320,3 +320,17 @@
+   normalizeUrl('view-source:https://www.sindresorhus.com');
+   }, '`view-source:` is not supported as it is a non-standard protocol');
+ });
++
++test('does not have exponential performance for data URLs', t => {
++  for (let index = 0; index < 1000; index += 50) {
++  const url = 'data:' + Array.from({length: 
index}).fill(',#').join('') + '\ra';
++  const start = Date.now();
++
++  try {
++  normalizeUrl(url);
++  } catch {}
++
++  const difference = Date.now() - start;
++  t.true(difference < 100, `Execution time: ${difference}`);
++  }
++});
diff --git a/debian/patches/series b/debian/patches/series
index 225f561..2299ad7 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 build-source-only.diff
 fix-package-json-paths.diff
+CVE-2021-33502.patch

Bug#956320: fabric ModuleNotFoundError: No module named 'invoke.vendor.six'

[Luca Boccassi]

On Thu, 09 Apr 2020 14:48:42 -0400 Nick Bowler  wrote:
> Package: fabric
> Version: 2.5.0-0.2
> Severity: important
> 
> Dear Maintainer,
> 
> After dist-upgrade, fab appears to be completely disfunctional, perhaps 
> because
> of missing dependencies:
> 
>   % fab --version
>   Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/fabric/connection.py", line 5, in 
>
>   from invoke.vendor.six import StringIO
>   ModuleNotFoundError: No module named 'invoke.vendor.six'
>   
>   During handling of the above exception, another exception occurred:
>   
>   Traceback (most recent call last):
> File "/usr/bin/fab", line 11, in 
>   load_entry_point('fabric==2.5.0', 'console_scripts', 'fab')()
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
>489, in load_entry_point
>   return get_distribution(dist).load_entry_point(group, name)
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
>2852, in load_entry_point
>   return ep.load()
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
>2443, in load
>   return self.resolve()
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
>2449, in resolve
>   module = __import__(self.module_name, fromlist=['__name__'], level=0)
> File "/usr/lib/python3/dist-packages/fabric/__init__.py", line 3, in 
>
>   from .connection import Config, Connection
> File "/usr/lib/python3/dist-packages/fabric/connection.py", line 10, in 
>
>   Subject: fabric ModuleNotFoundError: No module named 'invoke.vendor.six'
>   from decorator import decorator
>   ModuleNotFoundError: No module named 'decorator'

Uploaded NMU to DELAYED/2 with following debdiff:

diff -Nru fabric-2.5.0/debian/changelog fabric-2.5.0/debian/changelog
--- fabric-2.5.0/debian/changelog   2019-12-08 15:58:47.0 +
+++ fabric-2.5.0/debian/changelog   2021-05-31 11:00:56.0 +0100
@@ -1,3 +1,10 @@
+fabric (2.5.0-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add dependency on python3-decorator (Closes: #956320)
+
+ -- Luca Boccassi   Mon, 31 May 2021 11:00:56 +0100
+
 fabric (2.5.0-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru fabric-2.5.0/debian/control fabric-2.5.0/debian/control
--- fabric-2.5.0/debian/control 2019-12-08 15:55:45.0 +
+++ fabric-2.5.0/debian/control 2021-05-31 10:57:31.0 +0100
@@ -20,6 +20,7 @@
 Package: fabric
 Architecture: all
 Depends: python3-fabric (>= ${source:Version}),
+ python3-decorator,
  python3-pkg-resources,
  ${misc:Depends},
  ${python3:Depends},

-- 
Kind regards,
Luca Boccassi


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

Bug#988789: diffoscope | .so files are compared using a binary diff within in Android APKs (#259)

[Hans-Christoph Steiner]

I don't have one of the APKs still, but these should be close:

https://f-droid.org/repo/org.torproject.torservices_2001.apk
https://f-droid.org/repo/org.torproject.torservices_2002.apk
https://f-droid.org/repo/org.torproject.torservices_2003.apk
https://f-droid.org/repo/org.torproject.torservices_2004.apk

Then compare those with the ones here:
https://gitlab.com/guardianproject/torservices-nightly/-/tree/master/fdroid/repo

.hc

Emanuel Bronshtein (@e3amn2l):




Emanuel Bronshtein commented:


@eighthave can you link to the compared APK files that fail to diff the .so 
files in order to debug this, thanks.

The issue might be related to the "No such file" error in diff output:
```
Command `'strings --all --bytes=8 {}'` failed with exit code 1. Standard
output:
│┄ /usr/bin/strings:
'/tmp/diffoscope_4_ifbg_p_release/tmpqowyi8ycapk/org.torproject.torservices_2004.apk/lib/arm64-v8a/libtor.so':
No such file
```

Bug#987368: Installer fails at first menu "Choose language"

[Frédéric Bonnard]

Hi Cyril/all,
sorry that the process takes long, but that was the only way to
reproduce that bug (which I think may not be specific to ppc64el)
without having Power hardware (and a LPAR/HMC setup).

> Looking at that log, one sees two PIDs for main-menu (272 and 278),
> which could explain a very nice race condition: udpkg racing, one of
> them making the status file disappear from under the feet of the other
> one?

My feeling is that this is exactly what's happening.
I tried touching the missing file and the installer was happy because
the called process (udpkg from what I remember) does not crash anymore
(one can try udpkg without status file and it will crash).

> See also two /sbin/debian-installer processes getting started beforehand
> (one on /dev/hvc0, one on /dev/tty).

Exactly.

> It looks to me this is a clear problem on the debian-installer side (how
> it deals with multiple consoles, similar to #940028 as you mentioned
> initially), rather than some possible issues with emulation?

To me, it's clearly not a qemu issue, since I have that issue on
physical machines too. I just went the emulation way to enable people
without hardware to reproduce the bug. It's more a race condition of
running two debian-installers (not sure now who is remove the status
file, probably udpkg ?).

The point is that some work has already been done by several people on
those multiple consoles setup according to the git commits , and I guess
they will clearly get a grasp of what's going on.


F.


signature.asc
Description: PGP signature

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

[Nicolas Schier]

Control: tags -1 + moreinfo

Hi Christoph,

> Just noted by coincidence, that even though I have set:
>   COMPRESS=zstd
> and zstd is installed and even runs (seen in e.g. top utility) when running
>   update-initramfs -u
> the files are in the end nevertheless plain cpio:
>   file /boot/initrd.img-5.10.0-7-amd64
>   /boot/initrd.img-5.10.0-7-amd64: ASCII cpio archive (SVR4 with no CRC)

I can see the same behaviour on my amd64 machine, but on my arm64 
system 'file' identifies the initramfs images as zstd archives:

   /boot/initrd.img-5.10.0-6-arm64: Zstandard compressed data (v0.8+), 
Dictionary ID: None

According to the last lines of /usr/sbin/mkinitramfs, there seems to be 
a non-compressed cpio at the top of your amd64's initrd.img which is 
followed by the zstd-compressed one.  To validate my argumentation, 
please set 'COMPRESS=gzip' in '/etc/initramfs-tools/initramfs.conf', 
run 'update-initramfs -u' again and compare the sizes of the (probably) 
zstd-compressed one with the gzip-compressed one.

On my amd64 machine, it looks like this:

   $ file initrd-*/*
   initrd-gzip-compressed/initrd.img-5.10.0-6-amd64: ASCII cpio archive (SVR4 
with no CRC)
   initrd-zstd-compressed/initrd.img-5.10.0-6-amd64: ASCII cpio archive (SVR4 
with no CRC)
   $ ls -hs initrd-*/*
   36M initrd-gzip-compressed/initrd.img-5.10.0-6-amd64
   28M initrd-zstd-compressed/initrd.img-5.10.0-6-amd64
.

Kind regards,
Nicolas


PS: Does anyone know, how to extract the second (aka compressed) cpio 
archive from the combined initrd.img?

Bug#933508: borg umount fails because fusermount command is missing

[Gianfranco Costamagna]

control: fixed -1 1.0.10-2
control: close -1

On Wed, 31 Jul 2019 02:10:38 +0200 "Marcel Ranft"  wrote:
> Package: borgbackup
> Version: 1.0.9-1
> Severity: minor
> 
> An exception occurs when trying to use "borg umount" because "fusermount" 
> could not be found. I think borgbackup is missing a dependency for the fuse 
> package.
> 
> Steps to reproduce the error:
> apt install borgbackup
> borg init --encryption=none /opt/testrepo/
> borg create /opt/testrepo::testarchive /opt/scripts/
> borg mount /opt/testrepo/::testarchive /opt/mnt/
> borg umount /opt/mnt
> 
> error message:
> Local Exception.
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 2052, in main
>     exit_code = archiver.run(args)
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 1997, in run
>     return func(args)
>   File "/usr/lib/python3/dist-packages/borg/archiver.py", line 564, in 
> do_umount
>     return umount(args.mountpoint)
>   File "borg/platform_linux.pyx", line 148, in borg.platform_linux.umount 
> (borg/platform_linux.c:4217)
>   File "/usr/lib/python3.5/subprocess.py", line 247, in call
>     with Popen(*popenargs, **kwargs) as p:
>   File "/usr/lib/python3.5/subprocess.py", line 676, in __init__
>     restore_signals, start_new_session)
>   File "/usr/lib/python3.5/subprocess.py", line 1282, in _execute_child
>     raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'fusermount'
> 
> Platform: Linux services 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u4 
> (2019-07-19) x86_64
> Linux: debian 9.9
> Borg: 1.0.9  Python: CPython 3.5.3
> PID: 8244  CWD: /opt
> sys.argv: ['/usr/bin/borg', 'umount', '/opt/mnt']
> SSH_ORIGINAL_COMMAND: None

Bug#989289: libpmix-dev: Should depend on libevent-dev

[Alexandre DENIS]

Package: libpmix-dev
Version: 4.0.0-4
Severity: important

Dear Maintainer,

The package libpmix-dev comes with a pkg-config file to get compilation
flags. When I first installed the package, I got the following when
trying to get the flags:

% pkg-config --libs pmix
Package libevent was not found in the pkg-config search path.
Perhaps you should add the directory containing `libevent.pc'
to the PKG_CONFIG_PATH environment variable

The file libevent.pc is in libevent-dev package. I installed it,
and now:

% pkg-config --libs pmix
-lpmix -lhwloc -levent -lz

which is the expected result.

Thanks!


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-5-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 libpmix-dev depends on:
ii  libpmix2  4.0.0-4

libpmix-dev recommends no packages.

libpmix-dev suggests no packages.

-- no debconf information

Bug#989288: CVE-2021-29629

[Moritz Muehlenhoff]

Package: dacs
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

dacs bundles a copy in src/libradius/src/radlib.c:
https://www.freebsd.org/security/advisories/FreeBSD-SA-21:12.libradius.asc

Cheers,
 Moritz

Bug#989287: libcivetweb1: build with websockets support

[Claude Heiland-Allen]

Package: libcivetweb1
Version: 1.13+dfsg-5
Severity: wishlist
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I wanted to write a websocket server using civetweb packaged in Debian.

   * What was the outcome of this action?

Debian civetweb is not built with websockets support.


I managed to rebuild the package locally with websockets support by adding
-DCIVETWEB_ENABLE_WEBSOCKETS=ON to CMAKE_EXTRA_FLAGS in debian/rules, adding
extra lines to debian/libcivetweb1.symbols like
 mg_websocket_client_write@Base 1.13+dfsg-5
 mg_websocket_write@Base 1.13+dfsg-5

I'm not sure if other changes need to be made (e.g. library version bump for
changed ABI?).


Thanks for your consideration,


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

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

Versions of packages libcivetweb1 depends on:
ii  libc6   2.31-12
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6

libcivetweb1 recommends no packages.

libcivetweb1 suggests no packages.

-- no debconf information

Bug#928706: Debian Stretch cannot be installed on QNAP TS-121 (Kirkwood Marvell 6282 CPU w/ 1GB RAM)

[Martin Michlmayr]

* Salvatore Bonaccorso  [2021-05-29 14:28]:
> Was this issue adressed with a recent kernel?

No, unfortunately that never got resolved.  Andrew was able to
reproduce the issue but didn't know why it happened.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#989285: linux-image-5.10.0-6-amd64: Elantech trackpoint loses sync and jumps to the corner/edge of the screen

[Jörg Kastning]

Hi there,

I reported this bug because I spotted it in the current Debian testing 
release. Though I think it's an issue which may still exist in the 
current vanilla upstream. But since the TrackPoint is nearly useless 
this way I'd hope to get a fix backported to the bullseye kernel.


There exists a bugzilla[0] on kernel.org dealing with this issue, too.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=209167

Mark Pearson form Lenovo was able to reproduce this bug and is in 
contact with Elantech. Further information might be available in a 
bugzilla[1] for Fedora.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1964036

I hope these infos might help to get rid of this nasty bug.

Best regards,
Joerg

--
OpenPGP-ID: 7A302E30
OpenPGP-Fingerabdruck:
2026 DF56 89B6 F79A E776  B15B 55E2 83FB 7A30 2E30

Bug#989286: rinse does not work for CentOS 8.3 because of missing packages

[Kentaro Hayashi]

Package: rinse
Version: 3.6
Severity: normal


Since CentOS 8.3, some package name is changed [1]

Thus, if centos-linux-* is not installed appropriately with
current /etc/rinse/centos-8.packages.

And more, libmodulemd is missing. libmodulemd is required by python3-dnf [2]

So, without it, it raises the following exceptions [3]

How to reproduce it:

sudo rinse --arch amd64 --distribution centos-8 --directory 
/var/lib/chroot/centos-8-x86_64



[1] changed package names
centos-release => centos-linux-release
centos-repos = > centos-linux-repos



[2] libmodulemd is required by:
# rpm -q --whatrequires libmodulemd
python3-dnf-4.2.23-4.el8.noarch


[3] example of exceptions:

Running post-install script /usr/lib/rinse/common/10-resolv.conf.sh:

Running post-install script /usr/lib/rinse/common/15-mount-proc.sh:

Running post-install script /usr/lib/rinse/common/20-dev-zero.sh:

Running post-install script /usr/lib/rinse/centos-8/post-install.sh:

  Updating package

Traceback (most recent call last):

  File "/usr/lib64/python3.6/site-packages/libdnf/error.py", line 14, in
swig_import_helper

return importlib.import_module(mname)

  File "/usr/lib64/python3.6/importlib/__init__.py", line 126, in import_module

return _bootstrap._gcd_import(name[level:], package, level)

  File "", line 994, in _gcd_import

  File "", line 971, in _find_and_load
  File "", line 955, in _find_and_load_unlocked

  File "", line 658, in _load_unlocked

  File "", line 571, in module_from_spec
  File "", line 922, in create_module

  File "", line 219, in _call_with_frames_removed
ImportError: libmodulemd.so.2: cannot open shared object file: No such file or
directory




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

Kernel: Linux 5.10.0-7-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (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 rinse depends on:
ii  cpio   2.13+dfsg-4
ii  libterm-size-perl  0.211-1
ii  libwww-perl6.53-1
ii  perl   5.32.1-4
ii  rpm4.16.1.2+dfsg1-0.6
ii  rpm2cpio   4.16.1.2+dfsg1-0.6
ii  wget   1.21-1+b1

rinse recommends no packages.

rinse suggests no packages.

-- Configuration Files:
/etc/rinse/centos-8.packages changed:
centos-linux-release
centos-gpg-keys
centos-linux-repos
tzdata
ncurses-base
dnf-data
dbus-common
setup
basesystem
libzstd
libselinux
glibc-minimal-langpack
glibc
libsepol
xz-libs
libcap
libgpg-error
libcom_err
libxml2
expat
libuuid
chkconfig
mpfr
gmp
libattr
coreutils
libblkid
libcap-ng
libffi
lua-libs
p11-kit
gzip
libassuan
libidn2
libtasn1
lzo
grep
glib2
dbus-libs
openssl-libs
kmod-libs
kmod
libarchive
dhcp-libs
procps-ng
libsemanage
dbus-daemon
libfdisk
gnutls
libcomps
libksba
cpio
iproute
iptables-libs
libsigsegv
libverto
libtirpc
platform-python-pip
platform-python
libpwquality
util-linux
curl
rpm-libs
device-mapper
cryptsetup-libs
elfutils-libs
systemd
iputils
libkcapi-hmaccalc
dracut
python3-libcomps
python3-iniparse
dhcp-client
cyrus-sasl-lib
libyaml
npth
gpgme
libdnf
python3-hawkey
rpm-build-libs
python3-dnf
python3-dnf-plugins-core
python3-dnf-plugin-versionlock
python3-dateutil
yum
binutils
vim-minimal
less
rootfiles
libgcc
libreport-filesystem
dhcp-common
filesystem
pcre2
ncurses-libs
glibc-common
bash
zlib
bzip2-libs
info
elfutils-libelf
libxcrypt
sqlite-libs
libstdc++
popt
readline
json-c
libacl
sed
libmount
authselect
authselect-libs
audit-libs
libsmartcols
lz4-libs
libgcrypt
cracklib
libunistring
file
file-libs
keyutils-libs
p11-kit-trust
pcre
systemd-libs
crypto-policies
ca-certificates
libdb
ima-evm-utils
libdb-utils
dbus-tools
libusbx
xz
shadow-utils
libutempter
acl
nettle
snappy
libmetalink
findutils
libmnl
libnghttp2
libpcap
libseccomp
gawk
krb5-libs
libnsl2
platform-python-setuptools
python3-libs
pam
libcurl-minimal
rpm
libsolv
device-mapper-libs
elfutils-default-yama-scope
systemd-pam
dbus
libkcapi
systemd-udev
python3-six
bind-export-libs
openldap
dracut-network
libmodulemd1
gnupg2
librepo
python3-libdnf
python3-gpg
python3-rpm
dnf
kexec-tools
tar
hostname
libmodulemd


-- no debconf information

-- debsums errors found:

Bug#989285: linux-image-5.10.0-6-amd64: Elantech trackpoint loses sync and jumps to the corner/edge of the screen

[Joerg]

Package: src:linux
Version: 5.10.28-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: joerg.kastn...@gmail.com

Dear Maintainer,

   * What led up to the situation?
I have bought a Lenovo ThinkPad T14s with TrackPoint and Touchpad from 
Elantech and I use the TrackPoint for daily business.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Boot Debian testing hybrid image (live iso) from 2021-05-24 and started 
using the TrackPoint.

   * What was the outcome of this action?
TrackPoint jumps to the edge/corner of the screen after some minutes.

   * What outcome did you expect instead?
Using the TrackPoint without this jumpy experience.


-- Package-specific info:
** Version:
Linux version 5.10.0-6-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.28-1 (2021-04-09)

** Command line:
BOOT_IMAGE=/live/vmlinuz-5.10.0-6-amd64 boot=live components 
locales=en_US.UTF-8 quiet splash findiso=

** Not tainted

** Kernel log:
[  767.667481] microcode: CPU10: patch_level=0x08600106
[  767.668737] ACPI: \_SB_.PLTF.C00A: Found 3 idle states
[  767.669312] CPU10 is up
[  767.669334] smpboot: Booting Node 0 Processor 11 APIC 0xb
[  767.668570] microcode: CPU11: patch_level=0x08600106
[  767.669776] ACPI: \_SB_.PLTF.C00B: Found 3 idle states
[  767.670241] CPU11 is up
[  767.670284] smpboot: Booting Node 0 Processor 12 APIC 0xc
[  767.669643] microcode: CPU12: patch_level=0x08600106
[  767.670830] ACPI: \_SB_.PLTF.C00C: Found 3 idle states
[  767.671361] CPU12 is up
[  767.671383] smpboot: Booting Node 0 Processor 13 APIC 0xd
[  767.654009] microcode: CPU13: patch_level=0x08600106
[  767.671696] ACPI: \_SB_.PLTF.C00D: Found 3 idle states
[  767.672023] CPU13 is up
[  767.672047] smpboot: Booting Node 0 Processor 14 APIC 0xe
[  767.671602] microcode: CPU14: patch_level=0x08600106
[  767.672592] ACPI: \_SB_.PLTF.C00E: Found 3 idle states
[  767.673304] CPU14 is up
[  767.673325] smpboot: Booting Node 0 Processor 15 APIC 0xf
[  767.672412] microcode: CPU15: patch_level=0x08600106
[  767.673959] ACPI: \_SB_.PLTF.C00F: Found 3 idle states
[  767.674335] CPU15 is up
[  767.675507] ACPI: Waking up from system sleep state S3
[  768.228539] ACPI: EC: interrupt unblocked
[  768.286894] ACPI: EC: event unblocked
[  768.287186] usb usb1: root hub lost power or was reset
[  768.287386] usb usb2: root hub lost power or was reset
[  768.287386] usb usb3: root hub lost power or was reset
[  768.287386] xhci_hcd :05:00.0: Zeroing 64bit base registers, expecting 
fault
[  768.287897] [drm] PCIE GART of 1024M enabled (table at 0x00F40090).
[  768.287928] [drm] PSP is resuming...
[  768.307830] [drm] reserve 0x40 from 0xf41f80 for PSP TMR
[  768.533498] amdgpu :06:00.0: amdgpu: RAS: optional ras ta ucode is not 
available
[  768.557455] amdgpu :06:00.0: amdgpu: RAP: optional rap ta ucode is not 
available
[  768.557485] amdgpu :06:00.0: amdgpu: SMU is resuming...
[  768.558106] amdgpu :06:00.0: amdgpu: dpm has been disabled
[  768.559259] amdgpu :06:00.0: amdgpu: SMU is resumed successfully!
[  768.560656] [drm] kiq ring mec 2 pipe 1 q 0
[  768.575073] [drm] DMUB hardware initialized: version=0x0100
[  768.671330] [drm] VCN decode and encode initialized successfully(under DPG 
Mode).
[  768.671511] [drm] JPEG decode initialized successfully.
[  768.671777] amdgpu :06:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
[  768.671780] amdgpu :06:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 
on hub 0
[  768.671782] amdgpu :06:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 
on hub 0
[  768.671783] amdgpu :06:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 
on hub 0
[  768.671785] amdgpu :06:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 
on hub 0
[  768.671786] amdgpu :06:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 
on hub 0
[  768.671788] amdgpu :06:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 
on hub 0
[  768.671789] amdgpu :06:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 
on hub 0
[  768.671791] amdgpu :06:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 
on hub 0
[  768.671793] amdgpu :06:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 
on hub 0
[  768.671795] amdgpu :06:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 
1
[  768.671796] amdgpu :06:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on 
hub 1
[  768.671798] amdgpu :06:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on 
hub 1
[  768.671799] amdgpu :06:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on 
hub 1
[  768.671801] amdgpu :06:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on 
hub 1
[  768.699452] nvme nvme0: 16/0/0 default/read/poll queues
[  768.782669] usb 2-2: reset high-speed USB device number 2 using xhci_hcd
[  768.940717] acpi LNXPOWER:07: Turning OFF
[  768.940757] acpi LNXPOWER:05: Turning OFF
[  

Bug#988224: unblock: mapserver/7.6.2-2 (pre-approval)

[Sebastiaan Couwenberg]

On 5/31/21 8:27 AM, Sebastian Ramacher wrote:
> On 2021-05-31 08:17:25 +0200, Sebastiaan Couwenberg wrote:
>> On 5/31/21 8:07 AM, Sebastian Ramacher wrote:
>>> On 2021-05-31 05:38:15 +0200, Sebastiaan Couwenberg wrote:
 On 5/30/21 9:12 PM, Salvatore Bonaccorso wrote:
> Sebastiaan, Sebastian,
>
> On Tue, May 25, 2021 at 09:57:28AM +0200, Sebastiaan Couwenberg wrote:
>> Control: tags -1 - moreinfo
>>
>> On 5/25/21 9:45 AM, Sebastian Ramacher wrote:
>>> On 2021-05-08 22:17:42 +0200, Sebastiaan Couwenberg wrote:
 On 5/8/21 9:18 PM, Sebastian Ramacher wrote:
> On 2021-05-08 07:29:01 +0200, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package mapserver to fix CVE-2021-32062 as reported 
>> in #988208.
>>
>> [ Reason ]
>> Fix security issue.
>>
>> [ Impact ]
>> Unfixed security issue.
>>
>> [ Tests ]
>> Upstream CI.
>>
>> [ Risks ]
>> Low, leaf 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 ]
>> 0001-Use-CPLSetConfigOption-CPLGetConfigOption-for-some-C.patch is 
>> required as a dependency of 
>> 0001-Address-flaw-in-CGI-mapfile-loading-that-makes-it-po.patch.
>>
>> unblock mapserver/7.6.2-2
>
>> diff -Nru mapserver-7.6.2/debian/changelog 
>> mapserver-7.6.2/debian/changelog
>> --- mapserver-7.6.2/debian/changelog 2020-12-09 06:01:02.0 
>> +0100
>> +++ mapserver-7.6.2/debian/changelog 2021-05-08 07:12:18.0 
>> +0200
>> @@ -1,3 +1,12 @@
>> +mapserver (7.6.2-2) unstable; urgency=high
>> +
>> +  * Drop unused lintian overrides.
>> +  * Add upstream patches to fix CVE-2021-32062.
>> +(closes: #988208)
>> +  * Update symbols file.
>> +
>> + -- Bas Couwenberg   Sat, 08 May 2021 07:12:18 
>> +0200
>> +
>>  mapserver (7.6.2-1) unstable; urgency=medium
>>  
>>* Update symbols for other architectures.
>> diff -Nru mapserver-7.6.2/debian/libmapserver2.lintian-overrides 
>> mapserver-7.6.2/debian/libmapserver2.lintian-overrides
>> --- mapserver-7.6.2/debian/libmapserver2.lintian-overrides   
>> 2020-08-06 05:34:57.0 +0200
>> +++ mapserver-7.6.2/debian/libmapserver2.lintian-overrides   
>> 1970-01-01 01:00:00.0 +0100
>> @@ -1,3 +0,0 @@
>> -# Cannot easily be fixed
>> -file-references-package-build-path *
>> -
>> diff -Nru mapserver-7.6.2/debian/libmapserver2.symbols 
>> mapserver-7.6.2/debian/libmapserver2.symbols
>> --- mapserver-7.6.2/debian/libmapserver2.symbols 2020-12-09 
>> 06:00:39.0 +0100
>> +++ mapserver-7.6.2/debian/libmapserver2.symbols 2021-05-08 
>> 07:11:08.0 +0200
>> @@ -945,6 +945,7 @@
>>   msCSVJoinPrepare@Base 6.2.1
>>   msCairoCleanup@Base 6.2.1
>>   msCalculateScale@Base 6.2.1
>> + msCaseEvalRegex@Base 7.6.2
>>   msCaseReplaceSubstring@Base 6.2.1
>>   msCheckLabelMinDistance@Base 7.0.0
>>   msCheckParentPointer@Base 6.2.1
>> @@ -1418,6 +1419,7 @@
>>   msIsGlyphASpace@Base 7.2.0
>>   msIsLayerQueryable@Base 6.2.1
>>   msIsOuterRing@Base 6.2.1
>> + msIsValidRegex@Base 7.6.2
>
> This version is not high enough. The symbols need to be marked as
> requiring 7.6.2-2~

 There are no rdeps of mapserver in Debian, so no users of the symbols 
 file.
>>>
>>> It's technically wrong. If you introduce symbols with a patch, the
>>> symbols need to be properly versioned. After all, there is a user of the
>>> symbols file and that is mapserver itself. If you have to introduce
>>> calls to those two symbols outside of libmapserver in the next patch,
>>> the dependency on libmapserver is wrong.
>>
>> libmapserver-dev already depends on libmapserver2 with (=
>> ${binary:Version}).
>>
>> None of the other binary packages require symbols introduced after 7.0.5.
>>
>> All the code using msCaseEvalRegex & msIsValidRegex is within
>> libmapserver itself.
>>
>> While strictly speaking the version in the symbols file should include
>> the revision, its not required in this case because nothing outside
>> libmapserver uses it.
>>
> Please remove the moreinfo tag once that fixed 

Bug#984581: RE: Bug#984581: pst-utils: Fails to extract email addresses for emails having ARC headers from PST file

[Surla, Sai Kalyan]

Hi Paul,

Thanks for your time on this issue.
We will verify the patch that you shared and will let you know the results.

Thank you
Sai Kalyan


_

[cid:arcserve-email-logo_566d469b-c8dc-46eb-909b-300e3f3e47a1.jpg]


Sai Kalyan Surla  |  Software Engineer
Office: 7993045110  |  Mobile: 9182331089  |  saikalyan.su...@arcserve.com
arcserve.com  |  
Twitter  |  
LinkedIn  |  
YouTube


_
If you are not the intended recipient of this message or received it 
erroneously, please notify the sender and delete it, together with any 
attachments, and be advised that any dissemination or copying of this message 
is prohibited.
From: Paul Wise 
Sent: 30 May 2021 07:56 AM
To: 984...@bugs.debian.org; Surla, Sai Kalyan 
Subject: Re: RE: Bug#984581: pst-utils: Fails to extract email addresses for 
emails having ARC headers from PST file

On Mon, 5 Apr 2021 06:04:49 + "Surla, Sai Kalyan" wrote:

> Is there any update on the issues.

I finally found time to work on the first issue (header detection)
where we had a workaround already and created proper patches (attached)
for the issue and sent them to the upstream maintainer.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Alois Schlögl]

Am 5/29/21 um 1:59 PM schrieb Salvatore Bonaccorso:

Control: tags -1 + moreinfo

Hi Alois,

On Fri, May 31, 2019 at 09:24:03PM +0200, Romain Perier wrote:

On Wed, May 29, 2019 at 05:54:22PM +0200, Alois Schlögl wrote:

On 3/26/19 9:03 PM, Romain Perier wrote:

On Wed, Mar 20, 2019 at 08:24:33AM +0100, Alois Schlögl wrote:

On 3/18/19 7:46 PM, Romain Perier wrote:

On Mon, Mar 18, 2019 at 12:43:10PM +0100, Alois Schlögl wrote:

On 3/18/19 12:20 PM, Romain Perier wrote:

Hello,

On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:

Source: linux
Severity: normal

Dear Maintainer,

    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
(testing).
    After the upgrade, the touchpad and the trackpoint was not usable
anymore.


    This already has some bug report here,
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600

    As a workaround, one can run the command,
    sudo sh -c 'echo -n "elantech">
/sys/bus/serio/devices/serio1/protocol'
    in order to use the touchpad. However, on a GUI Interface and without
    an external mouse, it's impossible to apply this workaround
   (switching to the terminal -F1, login, and run the command
above might work)

    I expect to be able to use the touchpad just out of the box, not needing
    to run the above workaround


Could you :

- Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and confirm 
or
   not is the problem still exists ?

Dear Romain


I upgraded the kernel and rebooted:

schloegl@debian10:~$ uname -a
Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
x86_64 GNU/Linux


With this kernel the trackpoint is working, the trackpad is still not
usable.

(This improves the situation because now at least one pointer device is
available).



Good, we did some progress :)


- According to the bug on launchpad and to the fix pushed upstream, the
   fix seems to be an hardware quirks, could you give me the output of the
   following command :
   $ /sys/bus/serio/devices/serio1/firmware_id

root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
PNP: LEN2036 PNP0f13


Could you test the patch attached to this reply ?
(if you don't know how to do this, I can provide support)

Regards,
Romain


I tried to followed these instructions:

https://kernel-team.pages.debian.net/kernel-handbook/ch-comm

4.5. Building a custom kernel from Debian kernel source

Specifically using the patched the sources,

*scripts/config --disable MODULE_SIG*
**scripts/config --disable DEBUG_INFO**
||*|make clean|* ||*|make deb-pkg

|*

and ended up with a kernel that does not boot (missing HD audio firmware),


Which procedure do you recommend to build and install a modified kernel ?



Hi,

Section 4.2 from
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
, until test-patches should work. For the test-patches script, use the flavour 
and a
featureset as argument, when you invoke it, like this :

# debian/bin/test-patches -f amd64 -s none 
/path/to/0001-Input-elantech-disable-elan-i2c-for-L480.patch

This will apply the patch on the fly, configure the kernel for amd64
and build a version with a special changelog entry and a special suffix
version dedicated to the test version you generate.


In case of troubles, I can provide another way, from git with few
commands.


Hope this helps,
Regards,
Romain


Dear Romain,


your instructions to build the kernel worked fine, when trying to
install the kernel,

    sudo dpkg -i linux-headers-4.19.0-5-amd64_4.19.37-3a~test_amd64.deb
linux-image-4.19.0-5-amd64-unsigned_4.19.37-3a~test_amd64.deb

I run into problem, getting this warning.


  │ You are running a kernel (version 4.19.0-5-amd64) and attempting to
remove the same
version.
│
  │
│
  │ This can make the system unbootable as it will remove
/boot/vmlinuz-4.19.0-5-amd64 and all modules under the directory
/lib/modules/4.19.0-5-amd64. This can only be fixed with a copy  │
  │ of the kernel image and the corresponding
modules.
│
  │
│
  │ It is highly recommended to abort the kernel removal unless you are
prepared to fix the system after
removal.
│
  │
│
  │ Abort kernel removal?


I'm not sure if I'm "prepared to fix the system". Can you recommend a
reasonable save way to go forward ?


Cheers,

    Alois

Hello,

Well, this is something I have tested here myself, from the linux
git repository (on salsa.debian.org). I have built a 4.19.37-4a~test
with the patch , then I have forced the install with the same question
than you. And he did the trick !

So what you can do is:

  - When the dialog interface (the blue one) asks you to abort or continue the 
install,
press "no" to don't abort and continue the install
  - Once done, you can reboot
  - Check that the boot is working fine and you're running the intended
kernel:  4.19.37-3a~test  (via uname -a)
  - Check if your problem is fixed

  - Once you want to re-use the debian kernel, you can :

1. $ sudo 

Bug#988224: unblock: mapserver/7.6.2-2 (pre-approval)

[Sebastian Ramacher]

On 2021-05-31 08:17:25 +0200, Sebastiaan Couwenberg wrote:
> On 5/31/21 8:07 AM, Sebastian Ramacher wrote:
> > On 2021-05-31 05:38:15 +0200, Sebastiaan Couwenberg wrote:
> >> On 5/30/21 9:12 PM, Salvatore Bonaccorso wrote:
> >>> Sebastiaan, Sebastian,
> >>>
> >>> On Tue, May 25, 2021 at 09:57:28AM +0200, Sebastiaan Couwenberg wrote:
>  Control: tags -1 - moreinfo
> 
>  On 5/25/21 9:45 AM, Sebastian Ramacher wrote:
> > On 2021-05-08 22:17:42 +0200, Sebastiaan Couwenberg wrote:
> >> On 5/8/21 9:18 PM, Sebastian Ramacher wrote:
> >>> On 2021-05-08 07:29:01 +0200, Bas Couwenberg wrote:
>  Package: release.debian.org
>  Severity: normal
>  User: release.debian@packages.debian.org
>  Usertags: unblock
> 
>  Please unblock package mapserver to fix CVE-2021-32062 as reported 
>  in #988208.
> 
>  [ Reason ]
>  Fix security issue.
> 
>  [ Impact ]
>  Unfixed security issue.
> 
>  [ Tests ]
>  Upstream CI.
> 
>  [ Risks ]
>  Low, leaf 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 ]
>  0001-Use-CPLSetConfigOption-CPLGetConfigOption-for-some-C.patch is 
>  required as a dependency of 
>  0001-Address-flaw-in-CGI-mapfile-loading-that-makes-it-po.patch.
> 
>  unblock mapserver/7.6.2-2
> >>>
>  diff -Nru mapserver-7.6.2/debian/changelog 
>  mapserver-7.6.2/debian/changelog
>  --- mapserver-7.6.2/debian/changelog 2020-12-09 06:01:02.0 
>  +0100
>  +++ mapserver-7.6.2/debian/changelog 2021-05-08 07:12:18.0 
>  +0200
>  @@ -1,3 +1,12 @@
>  +mapserver (7.6.2-2) unstable; urgency=high
>  +
>  +  * Drop unused lintian overrides.
>  +  * Add upstream patches to fix CVE-2021-32062.
>  +(closes: #988208)
>  +  * Update symbols file.
>  +
>  + -- Bas Couwenberg   Sat, 08 May 2021 07:12:18 
>  +0200
>  +
>   mapserver (7.6.2-1) unstable; urgency=medium
>   
> * Update symbols for other architectures.
>  diff -Nru mapserver-7.6.2/debian/libmapserver2.lintian-overrides 
>  mapserver-7.6.2/debian/libmapserver2.lintian-overrides
>  --- mapserver-7.6.2/debian/libmapserver2.lintian-overrides   
>  2020-08-06 05:34:57.0 +0200
>  +++ mapserver-7.6.2/debian/libmapserver2.lintian-overrides   
>  1970-01-01 01:00:00.0 +0100
>  @@ -1,3 +0,0 @@
>  -# Cannot easily be fixed
>  -file-references-package-build-path *
>  -
>  diff -Nru mapserver-7.6.2/debian/libmapserver2.symbols 
>  mapserver-7.6.2/debian/libmapserver2.symbols
>  --- mapserver-7.6.2/debian/libmapserver2.symbols 2020-12-09 
>  06:00:39.0 +0100
>  +++ mapserver-7.6.2/debian/libmapserver2.symbols 2021-05-08 
>  07:11:08.0 +0200
>  @@ -945,6 +945,7 @@
>    msCSVJoinPrepare@Base 6.2.1
>    msCairoCleanup@Base 6.2.1
>    msCalculateScale@Base 6.2.1
>  + msCaseEvalRegex@Base 7.6.2
>    msCaseReplaceSubstring@Base 6.2.1
>    msCheckLabelMinDistance@Base 7.0.0
>    msCheckParentPointer@Base 6.2.1
>  @@ -1418,6 +1419,7 @@
>    msIsGlyphASpace@Base 7.2.0
>    msIsLayerQueryable@Base 6.2.1
>    msIsOuterRing@Base 6.2.1
>  + msIsValidRegex@Base 7.6.2
> >>>
> >>> This version is not high enough. The symbols need to be marked as
> >>> requiring 7.6.2-2~
> >>
> >> There are no rdeps of mapserver in Debian, so no users of the symbols 
> >> file.
> >
> > It's technically wrong. If you introduce symbols with a patch, the
> > symbols need to be properly versioned. After all, there is a user of the
> > symbols file and that is mapserver itself. If you have to introduce
> > calls to those two symbols outside of libmapserver in the next patch,
> > the dependency on libmapserver is wrong.
> 
>  libmapserver-dev already depends on libmapserver2 with (=
>  ${binary:Version}).
> 
>  None of the other binary packages require symbols introduced after 7.0.5.
> 
>  All the code using msCaseEvalRegex & msIsValidRegex is within
>  libmapserver itself.
> 
>  While strictly speaking the version in the symbols file should include
>  the revision, its not required in this case because nothing outside
>  libmapserver uses it.
> 
> >>> Please remove the moreinfo tag once that fixed version is available in
> >>> unstable.
> >>
>