Bug#983084: 3.16.0-11-586: modinfo: ERROR: could not get modinfo from 'crc32': No such file or directory

[Martin-Éric Racine]

Package: src:linux
Version: 3.16.84-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Selecting previously unselected package linux-image-3.16.0-11-586.
(Reading database ... 126181 files and directories currently installed.)
Preparing to unpack .../linux-image-3.16.0-11-586_3.16.84-1_i386.deb ...
Unpacking linux-image-3.16.0-11-586 (3.16.84-1) ...
Setting up linux-image-3.16.0-11-586 (3.16.84-1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-3.16.0-11-586
modinfo: ERROR: could not get modinfo from 'crc32': No such file or directory
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...

- -- Package-specific info: ** Version: Linux version 3.16.0-11-586 
(debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u2) ) 
#1 Debian 3.16.84-1 (2020-06-09)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-11-586 
root=UUID=97b2628b-28a5-49f2-85f7-495728b3bef8 ro panic=15 noquiet loglevel=5 
nosplash cs5535audio.ac97_quirk=1 systemd.log_level=debug

** Not tainted

** Kernel log:
[   83.526930] systemd-journald[168]: Journal effective settings seal=no 
keyed_hash=no compress=yes compress_threshold_bytes=512B
[   83.736242] systemd-journald[168]: Successfully sent stream file descriptor 
to service manager.
[   85.404262] systemd[1]: Pulling in -.slice/start from 
dev-hugepages.mount/start
[   85.416153] systemd[1]: Pulling in dev-mqueue.mount/start from 
sysinit.target/start
[   85.428150] systemd[1]: Added job dev-mqueue.mount/start to transaction.
[   85.440135] systemd[1]: Pulling in -.mount/start from dev-mqueue.mount/start
[   85.452145] systemd[1]: Pulling in -.slice/start from dev-mqueue.mount/start
[   85.464178] systemd[1]: Pulling in sys-kernel-config.mount/start from 
sysinit.target/start
[   85.476195] systemd[1]: Added job sys-kernel-config.mount/start to 
transaction.
[   85.488162] systemd[1]: Pulling in modprobe@configfs.service/start from 
sys-kernel-config.mount/start
[   85.500401] systemd[1]: Added job modprobe@configfs.service/start to 
transaction.
[   85.512141] systemd[1]: Pulling in system-modprobe.slice/start from 
modprobe@configfs.service/start
[   85.524345] systemd[1]: Added job system-modprobe.slice/start to transaction.
[   85.536146] systemd[1]: Pulling in system.slice/start from 
system-modprobe.slice/start
[   85.548159] systemd[1]: Pulling in shutdown.target/stop from 
system-modprobe.slice/start
[   85.560153] systemd[1]: Added job shutdown.target/stop to transaction.
[   85.572228] systemd[1]: Pulling in -.mount/start from 
sys-kernel-config.mount/start
[   85.584147] systemd[1]: Pulling in -.slice/start from 
sys-kernel-config.mount/start
[   85.596155] systemd[1]: Pulling in systemd-modules-load.service/start from 
sysinit.target/start
[   85.608152] systemd[1]: Added job systemd-modules-load.service/start to 
transaction.
[   85.620132] systemd[1]: Pulling in system.slice/start from 
systemd-modules-load.service/start
[   85.632150] systemd[1]: Pulling in shutdown.target/stop from 
systemd-modules-load.service/start
[   85.644156] systemd[1]: Pulling in systemd-udevd.service/start from 
sysinit.target/start
[   85.656146] systemd[1]: Added job systemd-udevd.service/start to transaction.
[   85.668195] systemd[1]: Pulling in system.slice/start from 
systemd-udevd.service/start
[   85.680154] systemd[1]: Pulling in systemd-udevd-kernel.socket/start from 
systemd-udevd.service/start
[   85.692152] systemd[1]: Added job systemd-udevd-kernel.socket/start to 
transaction.
[   85.704172] systemd[1]: Pulling in system.slice/start from 
systemd-udevd-kernel.socket/start
[   85.716154] systemd[1]: Pulling in systemd-udevd-control.socket/start from 
systemd-udevd.service/start
[   85.736146] systemd[1]: Pulling in -.mount/start from 
systemd-udevd-control.socket/start
[   85.748145] systemd[1]: Pulling in system.slice/start from 
systemd-udevd-control.socket/start
[   85.760200] systemd[1]: Pulling in systemd-sysusers.service/start from 
sysinit.target/start
[   85.772143] systemd[1]: Added job systemd-sysusers.service/start to 
transaction.
[   85.784146] systemd[1]: Pulling in system.slice/start from 
systemd-sysusers.service/start
[   85.796205] systemd[1]: Pulling in shutdown.target/stop from 
systemd-sysusers.service/start
[   85.808147] systemd[1]: Pulling in systemd-update-utmp.service/start from 
sysinit.target/start
[   85.820153] systemd[1]: Added job systemd-update-utmp.service/start to 
transaction.
[   85.832126] systemd[1]: Pulling in -.mount/start from 
systemd-update-utmp.service/start
[   85.852155] systemd[1]: Pulling in shutdown.target/stop from 
systemd-update-utmp.service/start
[   85.864145] systemd[1]: Pulling in cryptsetup.target/start from 
sysinit.target/start
[   85.876149] systemd[1]: Added job cryptsetup.target/start to transaction.
[   85.888192] systemd[1]: Pulling in shutdown.target/stop from 
cryptsetup.target/start
[   85.900147] systemd[1]: 

Bug#983083: chromium: cannot hide bookmarks bar

[Jon Dantin]

Package: chromium
Version: 88.0.4324.146-1~deb10u1
Severity: normal

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: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages chromium depends on:
ii  chromium-common 88.0.4324.146-1~deb10u1
ii  libasound2  1.1.8-1
ii  libatk-bridge2.0-0  2.30.0-5
ii  libatk1.0-0 2.30.0-2
ii  libatomic1  8.3.0-6
ii  libatspi2.0-0   2.30.0-7
ii  libavcodec587:4.1.6-1~deb10u1
ii  libavformat58   7:4.1.6-1~deb10u1
ii  libavutil56 7:4.1.6-1~deb10u1
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4+deb10u1
ii  libcups22.2.10-6+deb10u4
ii  libdbus-1-3 1.12.20-0+deb10u1
ii  libdrm2 2.4.97-1
ii  libevent-2.1-6  2.1.8-stable-4
ii  libexpat1   2.2.6-2+deb10u1
ii  libflac81.3.2-3
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgbm1 18.3.6-2+deb10u1
ii  libgcc1 1:8.3.0-6
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgtk-3-0  3.24.5-1
ii  libharfbuzz0b   2.3.1-1
ii  libicu6363.1-6+deb10u1
ii  libjpeg62-turbo 1:1.5.2-2+deb10u1
ii  libjsoncpp1 1.7.4-3
ii  liblcms2-2  2.9-3
ii  libminizip1 1.1-8+b1
ii  libnspr42:4.20-1
ii  libnss3 2:3.42.1-1+deb10u3
ii  libopenjp2-72.3.0-2+deb10u1
ii  libopus01.3-1
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libpng16-16 1.6.36-6
ii  libpulse0   12.2-4+deb10u1
ii  libre2-520190101+dfsg-2
ii  libsnappy1v51.1.7-1
ii  libstdc++6  8.3.0-6
ii  libvpx5 1.7.0-3+deb10u1
ii  libwebp60.6.1-2
ii  libwebpdemux2   0.6.1-2
ii  libwebpmux3 0.6.1-2
ii  libx11-62:1.6.7-1+deb10u1
ii  libxcb1 1.13.1-2
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3+b3
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-1
ii  libxml2 2.9.4+dfsg1-7+deb10u1
ii  libxrandr2  2:1.5.1-1
ii  libxslt1.1  1.1.32-2.2~deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  88.0.4324.146-1~deb10u1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6   2.28-10
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1+deb10u1
ii  libxext62:1.3.3-1+b2
ii  x11-utils   7.7+4
ii  xdg-utils   1.1.3-1+deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox   88.0.4324.146-1~deb10u1
ii  fonts-liberation   1:1.07.4-9
ii  gnome-shell [notification-daemon]  3.30.2-11~deb10u2
ii  libgl1-mesa-dri18.3.6-2+deb10u1
ii  libu2f-udev1.1.9-1
ii  notification-daemon3.20.0-4
ii  upower 0.99.10-1

Versions of packages chromium-sandbox depends on:
ii  libc6  2.28-10

-- no debconf information

Bug#983082: ipmitool: incorrect sensor reading for non-analog sensors in sdr sensor commands

[Sebastien Delafond]

Package: ipmitool
Version: 1.8.18-10
Severity: normal
Tags: upstream patch
Forwarded: https://sourceforge.net/p/ipmitool/bugs/490/

As per the upstream report, the sensor reading is not correctly
displayed for discrete and threshold type sensors.

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/36 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 ipmitool depends on:
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libfreeipmi171.6.6-3
ii  libncurses6  6.2+20201114-2
ii  libreadline7 7.0-5
ii  libreadline8 8.1-1
ii  libssl1.11.1.1i-3
ii  libtinfo66.2+20201114-2
ii  lsb-base 11.1.0

Versions of packages ipmitool recommends:
pn  openipmi  

ipmitool suggests no packages.
Index: ipmi_src/lib/ipmi_sdr.c
===
--- ipmi_src/lib/ipmi_sdr.c (revision 11550)
+++ ipmi_src/lib/ipmi_sdr.c (working copy)
@@ -1646,7 +1646,7 @@
  sr->s_a_units);
} else /* Discrete */
snprintf(sval, sizeof(sval),
-   "0x%02x", sr->s_reading);
+   "0x%02x", sr->s_data2);
}
else if (sr->s_scanning_disabled)
snprintf(sval, sizeof (sval), sr->full ? "disabled"   : 
"Not Readable");
Index: ipmi_src/lib/ipmi_sensor.c
===
--- ipmi_src/lib/ipmi_sensor.c  (revision 11550)
+++ ipmi_src/lib/ipmi_sensor.c  (working copy)
@@ -184,7 +184,7 @@
   sr->s_a_str, sr->s_a_units, 
"ok");
} else {
printf("| 0x%-8x | %-10s | 0x%02x%02x",
-  sr->s_reading, "discrete",
+  sr->s_data2, "discrete",
   sr->s_data2, sr->s_data3);
}
} else {

Bug#983002: plocate: updatedb fails with "/var/lib/plocate/: Operation not supported"

[Daniel Lewart]

Steinar,

> Thanks for the bug report. Is there anything special about your
> /var/lib/plocate? Unusual filesystems? SELinux permissions?

Yes, it is a Debian Live image, so it is an Overlay filesystem
(debian-live-testing-amd64-standard.iso).

> I assume this is the O_TMPFILE call somehow, but it would be nice
> if you could verify by doing
>   sudo strace updatedb
> and seeing which call is the failing one.

Correct.  Below is the tail of the output.

Thank you!
Daniel Lewart
Urbana, Illinois
---
umask(027)  = 022
openat(AT_FDCWD, "/var/lib/plocate/", O_WRONLY|O_TMPFILE, 0640) = -1
EOPNOTSUPP (Operation not supported)
dup(2)  = 4
fcntl(4, F_GETFL)   = 0x2 (flags O_RDWR)
fstat(4, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
write(4, "/var/lib/plocate/: Operation not"..., 43/var/lib/plocate/:
Operation not supported
) = 43
close(4)= 0
exit_group(1)   = ?
+++ exited with 1 +++

Bug#982465: Debian bug report 982465: dyn.load not useful for system libraries

[Andreas Tille]

On Fri, Feb 19, 2021 at 07:32:59AM +0100, Johannes Ranke wrote:
> Hi Dirk,
> 
> Am Freitag, 19. Februar 2021, 00:27:33 CET schrieb Dirk Eddelbuettel:
> > severity 982465 wishlist
> 
> I think the severity of the bug [1] depends on Debian policy - is it 
> mandatory 
> to use system libraries if they are available?


According to Debian Policy § 4.13[2] code copies should be avoided.  The
"should" results in bugs of severity "important" against those packages
that violate this rule.  It was not just for fun when I had spent my
time to follow policy.  I keep on hoping to find a sensible solution
that will fit policy but I can't without your cooperation.

Kind regards
  Andreas.

 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982465 
[2] https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies

-- 
http://fam-tille.de

Bug#982903: gitlab: Internal error caused by missing gitaly-git2go binary

[Pirate Praveen]

On 2021, ഫെബ്രുവരി 19 2:22:27 AM IST, Maximilian Stein  wrote:
>
>> Uploaded gitaly 13.7.5 to fasttrack-staging. If someone can confirm this, I 
>> will move it to fasttrack.
>
>
>Hi,
>
>I can confirm that gitaly-git2go is now present, however gitlab now 
>refuses to start since it's missing gitaly-13.6.5. So I cannot confirm 
>that gitaly-git2go is actually working.
>
>But I guess the refusal to start is just due to the updated gitlab 
>package still being missing? If gitlab requires an exact version of 
>gitaly shouldn't that be an exact dependency (i.e., "gitaly (=13.6.5-1)" 
>instead of "gitaly (>= 13.6~)")?

You will need to regenerate Gemfile.lock. See the wiki page for steps.

It saves the exact versions used during installation in Gemfile.lock

It is supposed to be handled automatically for most gems, but it does not work 
for native gems. There is an open bug about it.

>Best,
>
>Maximilian
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#982980: closed by Michael Gilbert (Re: Bug#982980: chromium: Update to version 88.0.4324.182 (security-fixes))

[Sedat Dilek]

Hi Michael,

thanks for taking care.

Can you please add a "Closes:" tag in d/changelog - next time?
That will credit my time I invested to write a Debian bug-report.

Nice to see in the dsc file [0] that you moved the development back to
"chromium-team/chromium" on .

Is it possible to *first* build amd64 packages?
I always see the i386 Debian packages first, see [2].
Unsure, if you can influence the build-process.

Thanks again.

Regards,
- Sedat -

[0] 
https://incoming.debian.org/debian-buildd/pool/main/c/chromium/chromium_88.0.4324.182-1.dsc
[1] https://salsa.debian.org/chromium-team/chromium
[2] https://salsa.debian.org/mimi8/chromium
[3] https://incoming.debian.org/debian-buildd/pool/main/c/chromium/?C=M;O=D
[4] 
https://salsa.debian.org/chromium-team/chromium/-/commit/e1e12bccd22d6f8ecfa2c142820ed680e1d75967

On Thu, Feb 18, 2021 at 10:36 PM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the chromium package:
>
> #982980: chromium: Update to version 88.0.4324.182 (security-fixes)
>
> It has been closed by Michael Gilbert .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Michael Gilbert 
>  by
> replying to this email.
>
>
> --
> 982980: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982980
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Michael Gilbert 
> To: 982980-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 18 Feb 2021 16:32:26 -0500
> Subject: Re: Bug#982980: chromium: Update to version 88.0.4324.182 
> (security-fixes)
> version: 88.0.4324.182-1
>
> On Wed, Feb 17, 2021 at 1:12 PM Sedat Dilek  wrote:
> > please update to version 88.0.4324.182.
>
>
> -- Forwarded message --
> From: Sedat Dilek 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 17 Feb 2021 19:09:19 +0100
> Subject: chromium: Update to version 88.0.4324.182 (security-fixes)
> Package: chromium
> Version: 88.0.4324.150-1
> Severity: normal
> X-Debbugs-Cc: sedat.di...@gmail.com
>
> Dear Maintainer,
>
> please update to version 88.0.4324.182.
> [1] shows several CVEs Security Fixes labeled with "High".
>
> Thanks.
>
> Regards,
> - Sedat -
>
> [1] https://chromereleases.googleblog.com/search/label/Stable%20updates
> [2] https://security-tracker.debian.org/tracker/source-package/chromium
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (99, 'buildd-unstable'), (99, 
> 'buildd-experimental'), (99, 'experimental'), (99, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.11.0-3-amd64-clang13-ias (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages chromium depends on:
> ii  chromium-common  88.0.4324.150-1
> ii  libasound2   1.2.4-1.1
> ii  libatk-bridge2.0-0   2.38.0-1
> ii  libatk1.0-0  2.36.0-2
> ii  libatomic1   10.2.1-6
> ii  libatspi2.0-02.38.0-2
> ii  libavcodec58 7:4.3.1-8
> ii  libavformat587:4.3.1-8
> ii  libavutil56  7:4.3.1-8
> ii  libc62.31-9
> ii  libcairo21.16.0-5
> ii  libcups2 2.3.3op2-3
> ii  libdbus-1-3  1.12.20-1
> ii  libdrm2  2.4.104-1
> ii  libevent-2.1-7   2.1.12-stable-1
> ii  libexpat12.2.10-1
> ii  libflac8 1.3.3-2
> ii  libfontconfig1   2.13.1-4.2
> ii  libfreetype6 2.10.4+dfsg-1
> ii  libgbm1  20.3.4-1
> ii  libgcc-s110.2.1-6
> ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
> ii  libglib2.0-0 2.66.7-1
> ii  libgtk-3-0   3.24.24-1
> ii  libharfbuzz0b2.7.4-1
> ii  libicu67 67.1-6
> ii  libjpeg62-turbo  1:2.0.6-1
> ii  libjsoncpp24 1.9.4-4
> ii  liblcms2-2   2.12~rc1-2
> ii  libminizip1  1.1-8+b1
> ii  libnspr4 2:4.29-1
> ii  libnss3  2:3.61-1
> ii  libopenjp2-7 2.4.0-3
> ii  libopus0 1.3.1-0.1
> ii  libpango-1.0-0   1.46.2-3
> ii  libpng16-16  1.6.37-3
> ii  libpulse014.2-1
> ii  libre2-9 20210201+dfsg-1
> ii  libsnappy1v5 1.1.8-1
> ii  libstdc++6   10.2.1-6
> ii  libvpx6  1.9.0-1
> ii  libwebp6 0.6.1-2+b1
> ii  libwebpdemux20.6.1-2+b1
> ii  libwebpmux3  0.6.1-2+b1
> ii  libx11-6 2:1.7.0-2
> ii  libxcb1  1.14-3
> ii  libxcomposite1   1:0.4.5-1
> ii  libxdamage1  1:1.1.5-2
> ii  libxext6 2:1.3.3-1.1
> ii  libxfixes3   1:5.0.3-2
> ii  libxml2

Bug#982465: Debian bug report 982465: dyn.load not useful for system libraries

[Johannes Ranke]

Hi Dirk,

Am Freitag, 19. Februar 2021, 00:27:33 CET schrieb Dirk Eddelbuettel:
> severity 982465 wishlist

I think the severity of the bug [1] depends on Debian policy - is it mandatory 
to use system libraries if they are available?

Johannes

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982465 

Bug#983004:

[Bella Tofa]

Bug#983081: apt-cache search -n should sort ouput alphabetically

[Martin-Éric Racine]

Package: apt
Version: 1.8.2.2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When doing... 

apt-cache search -n grub

...the content is output unsorted. One has to add '| sort' to get 
alphabetically sorted output. IMHO, apt-cache should always provide 
alphabetically-sorted output.

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

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.12-1+deb10u1
ii  libapt-pkg5.0   1.8.2.2
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4+deb10u6
ii  libseccomp2 2.3.3-4
ii  libstdc++6  8.3.0-6

Versions of packages apt recommends:
ii  ca-certificates  20200601~deb10u2

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.19.7
ii  gnupg2.2.12-1+deb10u1
ii  powermgmt-base   1.34

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmAvTtgACgkQrh+Cd8S0
17Z84Q//dbYwGNQj4xZ9RSmdDP5PXArMGQ/muFH7f0VU7Hlkxr7CN23zyU8eD5fX
r1ULlkrUW0F7Re60vStnHfwXjMHHyyvJhTDlUnd9ecQ7u5xVSwfFfSDCI7Z3vo79
fwRvcaKICihIDO64HsiOHj/2/L7uv/5amAVDqZQfElUD7YBm/3GTcyYqiNGNr3u0
+t0st5F3niN/R2mf/SFIjTl04Qd2ayxzPwAl8aMmPu5ZKOVAPbZ95niSCLxV8wOL
3a/aRH26odTMY6gaJWz8HZSFdLDM/eMmPkDw3cTg1/KlebslUo0rGbV7GLX/P12i
z1Oo1t7WeVxcNihsd3V0aSZoAd6d69QqBWLbRdqlRN/q+5YhE3WAbfrxNR5LbQu6
emjCTfQQRB3Zu33Z0Gt9rMeimiT984yCuFV97tm1+ojJ+M79lfZ3KMaI4Q1yOarz
RYSqF1fnmLitqmoLNmo0d759jOJypWP7ys1utwHUTi0AbrbzqfXfvQxTy6rqGM/b
09SALxYinBWX8gjYQmbXiBHV36f8WTaiOkAFLqFBux1HV881mLFMIfq047J2ZpSq
tJrh5ul3wszcFRVzwFXnCRvqYZDO4H45Ei2a1daSYdZWV0ohakGZe33HK6kMXb0W
/TkfXNgnXwW+myy385HRyBoChN5boi7E1tGCUvp+GBLp96GasAA=
=zIEe
-END PGP SIGNATURE-

Bug#982984:

[Marcos Raúl Carot]

I am seeing the same error since the upgrade to apt-cacher-ng 3.6-1
yesterday.

Also a very basic setup, my only change is the location of the cache, which
has been working fine for years.

Happy to provide more info, just tell me what you need.

Cheers,

-- 
Marcos R Carot

Bug#983080: x86info: missing lsmsr in x86info

[Logan Rosen]

Package: x86info
Version: 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute

This bug report was also filed in Ubuntu and can be found at
http://launchpad.net/bugs/762059 (along with a patch).
The description, from Alexandre Demers, follows:

When building x86info from the project's source, two applications are built: 
x86info and lsmsr. However, lsmsr can't be found in the x86info package, nor in 
any other obvious Ubuntu packages.

Please, add lsmsr in the x86info package.

Bug#983079: Don't captialize package names

[積丹尼 Dan Jacobson]

Package: www.debian.org

https://blends.debian.org/astro/tasks/education ,
https://blends.debian.org/science/tasks/astronomy.fi.html
capitalizes package names.
However that makes it impossible to paste them into apt, etc.

Bug#983040: [Debichem-devel] Bug#983040: rdkit: doesn't ship with inchi support enabled

[Francois Berenger]

On 2/18/21 10:58 PM, Michael Banck wrote:
> tags 983040 +wontfix
> merge 983040 964773
> thanks
> 
> On Thu, Feb 18, 2021 at 03:35:21PM +0200, Andrius Merkys wrote:
>> On 2021-02-18 15:27, Michael Banck wrote:
>>> On Thu, Feb 18, 2021 at 02:48:49PM +0900, Francois Berenger wrote:
 ---
 python3
 import rdkit
 from rdkit import Chem
 rdkit.Chem.INCHI_AVAILABLE
 # False
 ---

 It would be nice if INCHI support is enabled
 when building rdkit for Debian.

 If you point me to the bugtracker where I should report
 this (not found after 10min of searching...), I might report it there.
>>
>> This has already been reported as [#964773]. In short, rdkit cannot be
>> built with INCHI support in Debian due to DFSG reasons (please see the
>> original bug report for explanation).
>>
>> [#964773] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964773
> 
> Thanks Andrius for the pointer. By the way, I've looked at the INCHI
> licenes again, and clause 3 allows to use the INCHI code under the GPL,
> was it considered to just go that route in Debian or is there some other
> loophole I don't see?
> 
> Maybe RDKit could be changed in some way to build against both INCHI
> versions, but if that is possible at all, it sounds like a major
> project.
> 
> Francois, what might help here is opening an issue with RDKit's GitHub
> issue tracker and asking them about supporting both versions.

Ok, I opened this one:
https://github.com/rdkit/rdkit/issues/3826

Bug#983078: critical flag indicator image fails to render in X.509 certificate viewer

[Daniel Kahn Gillmor]

Package: thunderbird
Version: 1:78.7.1-1

In Thunderbird, i went to Preferences » Privacy and Security » Manage
Certificates » Authorities and selected "COMODO RSA Certification
Authority".

Then i clicked "View".  in the viewer, there are different attributes of
the X.509 certificate.  Two of those attributes ("Basic Constraints" and
"Key Usages") have an empty square box to the left of the attribute name
(see attached picture).


If I use the mouse to select those label regions, and then copy/paste
into some other tool, they show:

 [This extension has been marked as critical, meaning that clients must reject 
the certificate if they do not understand it.] Basic Constraints

and:

 [This extension has been marked as critical, meaning that clients must reject 
the certificate if they do not understand it.] Key Usages

So i think that empty square box is supposed to indicate that the
extension is a "critical" extension.  (and the copy/paste is grabbing
something equivalent to HTML alt-text).

Problems with this situation:

 - the empty square box doesn't communicate criticality -- presumably
   this is an image resource that is failing to render properly.
 
 - if this is actually just an image resource that is missing or fails
   to render, then the alt text should show in its place, right?  but it
   doesn't; it just shows the blank image.

Thanks for maintaining Thunderbird in Debian!

   --dkg


signature.asc
Description: PGP signature

Bug#983068: RM: xscorch -- RoQA; dead upstream; unmaintained; depeds on removed readline-gplv2 and others

[Jacob Luna Lundberg]

Hi all,

I am both the Debian maintainer and part of "upstream" ... I have 
discussed this with the co-author of the xscorch project and we do not 
have any time or intent to do another GTK upgrade right now.  The GTK2 
update was effectively a large part of what killed the project in the 
first place.  It's a lot more fun to work on features than on a complete 
graphics rewrite just because programmers can never let well enough 
alone.

That said, I am not certain why there is a rush to remove the package 
prior to the GTK2 removal.  While it's true I have not updated the 
package for some time, the Debian community has provided NMUs for all of 
the issues that have come up.  This seems more punitive than necessary 
... until GTK2 is removed.

I do need to orphan this package, and several others (or remove myself 
from maintainership lists) as I am no longer interested in maintaining 
(most) packages for Debian (aside from mussh which is easy enough to 
maintain and I still use regularly).  I'll try and get that done at some 
point when I somehow find the time.

Thanks,
-Jacob

Bug#983077: rdkit doesn't ship with inchi support enabled

[Francois Berenger]

Package: rdkit
Severity: wishlist

Reproduce:
---
python3
import rdkit
from rdkit import Chem
rdkit.Chem.INCHI_AVAILABLE
# False
---

Should be True if this version of rdkit has inchi support built-in.

inchi is a pretty standard and common format for people dealing with
chemical data.

Regards,
Francois.

Bug#983043: Acknowledgement (Failed to initialize GENET properly on RPI4 (arm64))

[Jeff Forsyth]

Discovered mdio_bcm_unimac module is missing from the installer
initrd.  This will stop the installer on the RPI4 from connecting to
the network.

On Thu, Feb 18, 2021 at 9:06 AM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 983043: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983043.
>
> 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 Install Team 
>
> If you wish to submit further information on this problem, please
> send it to 983...@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.
>
> --
> 983043: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983043
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



-- 
"Non sibi, sed patriae"

Bug#983076: autoconf: autoreconf's gettext handling is buggy

[Vincent Lefevre]

Package: autoconf
Version: 2.69-14
Severity: normal

In the autoreconf(1) man page:

   -i, --install
  copy missing auxiliary files

However, when AM_GNU_GETTEXT_VERSION is used, autoreconf runs
autopoint, which wants to override existing files, and fails
if existing files do not have the same contents as the autopoint
files:

autopoint: File ABOUT-NLS has been locally modified.
autopoint: File config.rpath has been locally modified.
autopoint: File m4/iconv.m4 has been locally modified.
autopoint: File po/Makefile.in.in has been locally modified.
autopoint: File po/Rules-quot has been locally modified.
autopoint: File po/en@boldquot.header has been locally modified.
autopoint: File po/en@quot.header has been locally modified.
autopoint: File po/insert-header.sin has been locally modified.
autopoint: File po/remove-potcdate.sin has been locally modified.
autopoint: *** Some files have been locally modified. Not overwriting them 
because --force has not been specified. For your convenience, you find the 
local modifications in the file '/tmp/arBTaNwR/gt73Yphm/autopoint.diff'.
autopoint: *** Stop.
autoreconf: autopoint failed with exit status: 1

This "error" should not be fatal for autoreconf.

As a workaround, in such a project (here, the current Mutt master),
it seems that AM_GNU_GETTEXT_VERSION may not be necessary. But if
AM_GNU_GETTEXT_VERSION is not used, autoreconf warns:

autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages autoconf depends on:
ii  debianutils  4.11.2
ii  m4   1.4.18-5
ii  perl 5.32.1-2

Versions of packages autoconf recommends:
ii  automake [automaken]  1:1.16.3-2

Versions of packages autoconf suggests:
ii  autoconf-archive  20190106-2.1+local1
ii  autoconf-doc  2.69-14
ii  gettext   0.21-4
ii  gnu-standards 2010.03.11-1.1
ii  libtool   2.4.6-15+local1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#981597: plasma-desktop: Also see this problem on system upgraded from (pre-)Stretch

[Jaap Eldering]

Package: plasma-desktop
Version: 4:5.17.5-3
Followup-For: Bug #981597

Dear Maintainer,

I'd like to confirm that I'm seeing the same upgrade problems on my system.
This system has also been upgraded through Stretch -> Buster -> Bullseye (and
actually even from way before).

Following this thread, I've already removed libgcc-8-dev:amd64 (8.4.0-7).
In my case that did not trigger uninstalling a whole bunch of KDE packages,
just this from /var/log/apt/history.log:

===
Start-Date: 2021-02-18  23:25:21
Commandline: apt-get remove libgcc-8-dev
Remove: gcc-8-multilib:amd64 (8.4.0-7), gcc-8:amd64 (8.4.0-7), 
libgfortran-8-dev:amd64 (8.4.0-7), libstdc++-8-dev:amd64 (8.4.0-7), gfortran>
End-Date: 2021-02-18  23:25:25

Start-Date: 2021-02-18  23:26:22
Commandline: apt-get install libc++-dev
Install: libc++1-11:amd64 (1:11.0.1-2, automatic), libc++-11-dev:amd64 
(1:11.0.1-2, automatic), libc++abi1-11:amd64 (1:11.0.1-2, automatic)
Upgrade: libc++-dev:amd64 (1:9.0-49.1, 1:11.0-51+nmu4)
Remove: libc++abi1-9:amd64 (1:9.0.1-15+b1), libc++-9-dev:amd64 (1:9.0.1-15+b1), 
libc++1-9:amd64 (1:9.0.1-15+b1)
End-Date: 2021-02-18  23:26:26
===

However, my system still cannot find an apt dist-upgrade path. Let me know
if there's anything I can do to help debug this.

Best,
Jaap


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

Kernel: Linux 5.10.0-3-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)

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.17.5-2
ii  kactivitymanagerd5.17.5-2
ii  kde-cli-tools4:5.17.5-2
ii  kded55.74.0-2
ii  kio  5.74.0-2
ii  kpackagetool55.74.0-2
ii  libc62.31-9
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.7-1
ii  libibus-1.0-51.5.23-2
ii  libkf5activities55.74.0-2
ii  libkf5activitiesstats1   5.74.0-2
ii  libkf5archive5   5.74.0-2
ii  libkf5authcore5  5.74.0-2
ii  libkf5baloo5 5.74.0-2
ii  libkf5codecs55.74.0-2
ii  libkf5completion55.74.0-2
ii  libkf5configcore55.74.0-2
ii  libkf5configgui5 5.74.0-2
ii  libkf5configwidgets5 5.74.0-2
ii  libkf5coreaddons55.74.0-2
ii  libkf5dbusaddons55.74.0-2
ii  libkf5declarative5   5.74.0-2
ii  libkf5emoticons-bin  5.74.0-2
ii  libkf5emoticons5 5.74.0-2
ii  libkf5globalaccel-bin5.74.0-2
ii  libkf5globalaccel5   5.74.0-2
ii  libkf5guiaddons5 5.74.0-3
ii  libkf5i18n5  5.74.0-3
ii  libkf5iconthemes55.74.0-2
ii  libkf5itemmodels55.74.0-2
ii  libkf5itemviews5 5.74.0-2
ii  libkf5jobwidgets55.74.0-2
ii  libkf5kcmutils5  5.74.0-2
ii  libkf5kdelibs4support5   5.74.0-3
ii  libkf5kiocore5   5.74.0-2
ii  libkf5kiofilewidgets55.74.0-2
ii  libkf5kiowidgets55.74.0-2
ii  libkf5newstuff5  5.74.0-2
ii  libkf5notifications5 5.74.0-2
ii  libkf5notifyconfig5  5.74.0-2
ii  libkf5package5   5.74.0-2
ii  libkf5parts5 5.74.0-2
ii  libkf5plasma55.74.0-2
ii  libkf5plasmaquick5   5.74.0-2
ii  libkf5quickaddons5   5.74.0-2
ii  libkf5runner55.74.0-2
ii  libkf5service-bin5.74.0-2
ii  libkf5service5   5.74.0-2
ii  libkf5solid5 5.74.0-2
ii  libkf5sonnetui5  5.74.0-3
ii  libkf5wallet-bin 5.74.0-2
ii  libkf5wallet55.74.0-2
ii  libkf5widgetsaddons5 5.74.0-3
ii  libkf5windowsystem5  5.74.0-2
ii  libkf5xmlgui55.74.0-2
ii  libkfontinst54:5.17.5-3
ii  

Bug#983075: RFS: xpenguins/3.1.0-1 -- little penguins walk on your windows

[Micheal Waltz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: xpenguins
   Version : 3.1.0-1
   Upstream Author : Willem Vermin 
 * URL : 
https://www.ratrabbit.nl/ratrabbit/software/xpenguins/index.html
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/games-team/xpenguins
   Section : games

It builds those binary packages:

  xpenguins - little penguins walk on your windows

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xpenguins/xpenguins_3.1.0-1.dsc

Changes since the last upload:

 xpenguins (3.1.0-1) unstable; urgency=medium
 .
   * New upstream version 3.1.0
   * Remove patches that are no longer used with newer source
   * bump pkg-config version in autoconf
   * Fix lintian errors and warnings
   * Use sourceforce magic URL for to fix lintian warning
   * Update copyright to match DEP5 format
   * Update watch to version 4

Regards,

-- 
Micheal Waltz
https://keybase.io/ecliptik
GPG Fingerprint: 5F70 F2AC BD58 F580 DF15  3D1F 4FA2 70F5 CD36 71F9


signature.asc
Description: PGP signature

Bug#983074: task-gnome-desktop: Please consider recommending synaptic again

[gagz]

Package: task-gnome-desktop
Version: 3.63
Severity: normal
Tags: d-i

Hello maintainers of task-gnome-desktop,

Synaptic used to be recommended by task-gnome-desktop (and other
task-*-desktop), until it was removed from Buster (#889897), due to it
not functionning correctly under Wayland.

Under GNOME, users have been left with gnome-software to install
packages, but gnome-software only shows packages shipping AppStream
metadata, thus most packages don't show up there, such as mat2,
nautilus-wipe, sm and many more.
Installing packages not available in gnome-software nowadays requires
the use of a terminal, or gnome-packagekit, which is also not installed
by default.

Gnome-packagekit does the job and has a prettier interface, but its
developpment is much slower than synaptic's (regarding commits in the
last 2 years).

Shipping synaptic by default in Debian Bullseye with GNOME, XFCE, LXDE,
Mate and Cinnamon would be a great (re)improvement in user experience,
giving users more control without the need of mastering terminal usage.


Thank you very much,
gagz

Bug#983073: variable.c: add braces around initializer

[Bjarni Ingi Gislason]

Source: nn
Severity: normal
Tags: patch

Dear Maintainer,

>From 4b2968842f42fc0dde4fbda86d682e6a07836b6c Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 18 Feb 2021 22:27:06 +
>Subject: [PATCH] variable.c: add braces around initializer

  Warnings from the compiler:

variable.c:198:31: warning: missing braces around initializer [-Wmissing-braces]

Signed-off-by: Bjarni Ingi Gislason 
---
 variable.c | 402 +++--
 1 file changed, 203 insertions(+), 199 deletions(-)

  The patch is in the attachment.


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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason


variable.c.patch.gz
Description: application/gzip

Bug#981449: dehydrated: certificate specific settings may affect other certificates

[Michel Lespinasse]

Got the fix upstream as commit 527933db2434cc103428e04cf72fdd04c13a06a9

On Mon, Feb 1, 2021 at 6:27 AM Mattia Rizzolo  wrote:
>
> Hi!
>
> On Sun, Jan 31, 2021 at 05:48:25AM -0800, Michel Lespinasse wrote:
> > Dehydrated supports two locations for config settings:
> > - The main config file, /etc/dehydrated/config by default
> > - Per-certificate config files, i.e. certs/*/config
> >
> > Settings defined in the per-certificate config files are expected to
> > only affect that particular certificate. But, this doesn't seem to be
> > the case - in particular, I noticed that PRIVATE_KEY_ROLLOVER was also
> > affecting certificates that are processed later in the run.
> >
> > Looking at the code, I think I found the root cause.
>
> Could I ask if you'd be willing to forward this issue directly upstream
> at https://github.com/dehydrated-io/dehydrated/issues ?
>
> > The store_configvars() and reset_configvars() are expected to save the
> > canonical (as per the global config file) settings and restore them
> > before processing each certificate. But, the set of variables that are
> > saved by these functions is only a subset of those that can be set in
> > per-certificate config files; in particular the OCSP_FETCH, OCSP_DAYS,
> > and PRIVATE_KEY_ROLLOVER settings are missing.
>
> So, only from reading your report, this might be as trivial as you say.
> If you tried to patch it and it works you might as well also propose
> this in the form of a merge request in the above github repository :)
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> More about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#982465: Bug in r-base and r-cran-rcppparallel

[Dirk Eddelbuettel]

severity 982465 wishlist
thanks

I am sorry but I simply see no bug in package r-base here.

The RcppParallel maintainer tried a Debian-local modification to that CRAN
package. That didn't work, and now fingers are pointed at r-base.

Which is simply not the right way to go about this as package RcppParallel is
fine at CRAN (see [1], ignore upcoming issues such the Apple M1 chip).

I could and maybe should close this, but let's maybe keep it open and come
back to it once RcppParallel 5.1.0 is released as some of the underlying
libraries have changed or will change again under Intel oneAPI (I lost
track). I will leave it to the RcppParallel to decide whether he wants
working Debian package (by just packaging RcppParallel) or perfect technical
purity by not including a system library yet ending up with a package that
doesn't work (which was the source of this bug report).

Dirk

[1] https://cloud.r-project.org/web/checks/check_results_RcppParallel.html (the

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#983072: dpkg: Vendor Hooks - add ability to update build profiles

[Dimitri John Ledkov]

Package: dpkg
Version: 1.20.7.1
Severity: normal
Tags: patch

Dear Maintainer,

In Ubuntu, we mostly use live images and no longer have a use for udebs.

Thus we are trying to build Ubuntu without udebs. Whilst we could set
DEB_BUILD_PROFILES it sbuild, it would result in locally built
packages with dpkg-buildpackage try to build udebs, even when primary
archive doesn't build them.

To avoid this discrepancy it would be nice to have a vendor hook, that
allows to set deb-build-profiles, similar to the deb-build-options hook.

I've implemented that, but I do not know perl. perl critic reports
issues, but if i fix them, unrelated tests start failing. So I'm at a
loss as to how to implement this idea correctly and without destroying
the ci.

Any reviews and advise would be highly appreciated.

Regards,

Dimitri.
diff -Nru dpkg-1.20.7.1ubuntu2/debian/changelog 
dpkg-1.20.7.1ubuntu3/debian/changelog
--- dpkg-1.20.7.1ubuntu2/debian/changelog   2021-01-28 09:00:33.0 
+
+++ dpkg-1.20.7.1ubuntu3/debian/changelog   2021-02-18 19:58:48.0 
+
@@ -1,3 +1,11 @@
+dpkg (1.20.7.1ubuntu3) hirsute; urgency=medium
+
+  * scripts/Dpkg/Vendor/Ubuntu.pm: set 'noudeb' build profile by
+default. Override this by exporting DEB_BUILD_PROFILE='!noudeb' which
+will be stripped, and thus building with udebs. LP: #1884836
+
+ -- Dimitri John Ledkov   Thu, 18 Feb 2021 19:58:48 +
+
 dpkg (1.20.7.1ubuntu2) hirsute; urgency=medium
 
   * Dpkg::Vendor::Debian: Add new lto feature in new optimize area, taken
diff -Nru dpkg-1.20.7.1ubuntu2/scripts/Dpkg/BuildProfiles.pm 
dpkg-1.20.7.1ubuntu3/scripts/Dpkg/BuildProfiles.pm
--- dpkg-1.20.7.1ubuntu2/scripts/Dpkg/BuildProfiles.pm  2019-11-05 
11:59:03.0 +
+++ dpkg-1.20.7.1ubuntu3/scripts/Dpkg/BuildProfiles.pm  2021-02-18 
19:58:46.0 +
@@ -30,6 +30,7 @@
 use List::Util qw(any);
 
 use Dpkg::Build::Env;
+use Dpkg::Vendor qw(run_vendor_hook);
 
 my $cache_profiles;
 my @build_profiles;
@@ -63,6 +64,7 @@
 @build_profiles = split ' ', 
Dpkg::Build::Env::get('DEB_BUILD_PROFILES');
 }
 $cache_profiles = 1;
+run_vendor_hook('update-buildprofiles', \@build_profiles);
 
 return @build_profiles;
 }
@@ -79,7 +81,8 @@
 
 $cache_profiles = 1;
 @build_profiles = @profiles;
-Dpkg::Build::Env::set('DEB_BUILD_PROFILES', join ' ', @profiles);
+run_vendor_hook('update-buildprofiles', \@build_profiles);
+Dpkg::Build::Env::set('DEB_BUILD_PROFILES', join ' ', @build_profiles);
 }
 
 =item @profiles = parse_build_profiles($string)
diff -Nru dpkg-1.20.7.1ubuntu2/scripts/Dpkg/Vendor/Default.pm 
dpkg-1.20.7.1ubuntu3/scripts/Dpkg/Vendor/Default.pm
--- dpkg-1.20.7.1ubuntu2/scripts/Dpkg/Vendor/Default.pm 2021-01-09 
06:04:59.0 +
+++ dpkg-1.20.7.1ubuntu3/scripts/Dpkg/Vendor/Default.pm 2021-02-18 
19:58:46.0 +
@@ -130,6 +130,12 @@
 the default values set for the various build flags. $flags is a
 Dpkg::BuildFlags object.
 
+=item update-buildprofiles ($build_profiles_ref)
+
+The hook is called in Dpkg::BuildProfiles to allow the vendor to
+override the default values set. $build_profiles_ref is a array ref to
+Dpkg::BuildProfiles object.
+
 =item builtin-system-build-paths ()
 
 The hook is called by dpkg-genbuildinfo to determine if the current path
@@ -180,6 +186,8 @@
my ($textref, $ch_info) = @params;
 } elsif ($hook eq 'update-buildflags') {
my $flags = shift @params;
+} elsif ($hook eq 'update-buildprofiles') {
+   my $build_profiles_ref = shift @params;
 } elsif ($hook eq 'builtin-system-build-paths') {
 return ();
 } elsif ($hook eq 'build-tainted-by') {
diff -Nru dpkg-1.20.7.1ubuntu2/scripts/Dpkg/Vendor/Ubuntu.pm 
dpkg-1.20.7.1ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm
--- dpkg-1.20.7.1ubuntu2/scripts/Dpkg/Vendor/Ubuntu.pm  2021-01-12 
11:45:46.0 +
+++ dpkg-1.20.7.1ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm  2021-02-18 
19:58:46.0 +
@@ -125,6 +125,14 @@
}
# Per https://wiki.ubuntu.com/DistCompilerFlags
 $flags->prepend('LDFLAGS', '-Wl,-Bsymbolic-functions');
+} elsif ($hook eq 'update-buildprofiles') {
+my $build_profiles_ref = shift @params;
+unless(grep $_ =~ /^!?noudeb$/, @$build_profiles_ref) {
+unshift(@$build_profiles_ref, 'noudeb');
+} else {
+# Strip otherwise invalid profile name
+@$build_profiles_ref = grep { $_ ne "!noudeb" } 
@$build_profiles_ref;
+}
 } else {
 return $self->SUPER::run_hook($hook, @params);
 }
diff -Nru dpkg-1.20.7.1ubuntu2/scripts/dpkg-buildpackage.pl 
dpkg-1.20.7.1ubuntu3/scripts/dpkg-buildpackage.pl
--- dpkg-1.20.7.1ubuntu2/scripts/dpkg-buildpackage.pl   2021-01-12 
11:45:46.0 +
+++ dpkg-1.20.7.1ubuntu3/scripts/dpkg-buildpackage.pl   2021-02-18 
19:58:46.0 +
@@ -432,7 +432,7 @@
 $build_opts->export();
 }
 
-set_build_profiles(@build_profiles) if @build_profiles;

Bug#982559: xscorch Build-Depends on libreadline-gplv2-dev which has been removed

[peter green]

I would thus propose simply dropping the build-dependency, a debdiff doing that 
is
attached, I may or may not NMU it later.

I have gone ahead with the NMU, final debdiff is attatched.

diff -Nru xscorch-0.2.1/debian/changelog xscorch-0.2.1/debian/changelog
--- xscorch-0.2.1/debian/changelog  2020-09-12 08:10:17.0 +0100
+++ xscorch-0.2.1/debian/changelog  2021-02-18 20:50:52.0 +
@@ -1,3 +1,11 @@
+xscorch (0.2.1-1+nmu6) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove build-dependency on libreadline-gplv2-dev
+(Closes: 982559)
+
+ -- Peter Michael Green   Thu, 18 Feb 2021 20:50:52 +
+
 xscorch (0.2.1-1+nmu5) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xscorch-0.2.1/debian/control xscorch-0.2.1/debian/control
--- xscorch-0.2.1/debian/control2020-07-02 15:45:01.0 +0100
+++ xscorch-0.2.1/debian/control2021-02-18 20:48:27.0 +
@@ -4,7 +4,7 @@
 Homepage: http://www.xscorch.org/
 Maintainer: Jacob Luna Lundberg 
 Standards-Version: 3.9.2
-Build-Depends: debhelper (>= 7), groff, libglib2.0-dev, libgtk2.0-dev (>= 
2.20), libmikmod-dev, libreadline-gplv2-dev | libreadline5-dev, libx11-dev, 
libxext-dev, libxi-dev, autotools-dev
+Build-Depends: debhelper (>= 7), groff, libglib2.0-dev, libgtk2.0-dev (>= 
2.20), libmikmod-dev, libx11-dev, libxext-dev, libxi-dev, autotools-dev
 
 Package: xscorch
 Architecture: any

Bug#983071: unblock: xz-utils/5.2.5-1.1

[Sebastian Andrzej Siewior]

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

Please unblock package xz-utils.

I NMUed xz-utils to 5.2.5-1.0 fixing a few bugs including #844770 and
#975981. Both bugs were fixed by upstream differently / more complete.
I prepared an NMU 5.2.5-1.1, #983067 by replacing my patches with
upstream patches:
- #844770 "xzcmp: SIGPIPE is raised because CMP does exit while the XZ
  commands are still writing to the pipe"
  
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=194029ffaf74282a81f0c299c07f73caca3232ca

- #975981 "xz-utils: "unxz -k" should not refuse to decompress a file
  because it has more than one hard link"
  
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=074259f4f3966aeac6edb205fecbc1a8d2b58bb2

I would like to avoid having different changes to the package (and
possibly creating new bugs) and therefore keep what upstream applied
here. The patches were reviewed at least by the maintainer of the
upstream package.
During that review a similar SIGPIPE problem was found and fixed in
xzgrep:
   Scripts: Fix exit status of xzgrep.
   
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=73c555b3077c19dda29b6f4592ced2af876f8333

This bug was never reported and fixed within the Debian package. If it
is okay with the release then I would backport the patch and NMU it as
part of the 5.2.5-1.1 upload.
Otherwise I would stick with the replacement of the two patches as can
been seen in the attached debdiff.
The package was not yet uploaded, I plan to upload it to delayed/5 once
the release team agrees.

unblock xz-utils/5.2.5-1.1

Sebastian
diff -Nru xz-utils-5.2.5/debian/changelog xz-utils-5.2.5/debian/changelog
--- xz-utils-5.2.5/debian/changelog 2020-12-28 11:25:06.0 +0100
+++ xz-utils-5.2.5/debian/changelog 2021-02-18 23:12:30.0 +0100
@@ -1,3 +1,10 @@
+xz-utils (5.2.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update the patches for #844770 and #975981 to what upstream applied.
+
+ -- Sebastian Andrzej Siewior   Thu, 18 Feb 2021 
23:12:30 +0100
+
 xz-utils (5.2.5-1.0) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch
 
xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch
--- 
xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch
1970-01-01 01:00:00.0 +0100
+++ 
xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch
2021-02-17 23:52:05.0 +0100
@@ -0,0 +1,118 @@
+From: Lasse Collin 
+Date: Mon, 11 Jan 2021 22:01:51 +0200
+Subject: Scripts: Fix exit status of xzdiff/xzcmp.
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+This is a minor fix since this affects only the situation when
+the files differ and the exit status is something else than 0.
+In such case there could be SIGPIPE from a decompression tool
+and that would result in exit status of 2 from xzdiff/xzcmp
+while the correct behavior would be to return 1 or whatever
+else diff or cmp may have returned.
+
+This commit omits the -q option from xz/gzip/bzip2/lzop arguments.
+I'm not sure why the -q was used in the first place, perhaps it
+hides warnings in some situation that I cannot see at the moment.
+Hopefully the removal won't introduce a new bug.
+
+With gzip the -q option was harmful because it made gzip return 2
+instead of >= 128 with SIGPIPE. Ignoring exit status 2 (warning
+from gzip) isn't practical because bzip2 uses exit status 2 to
+indicate corrupt input file. It's better if SIGPIPE results in
+exit status >= 128.
+
+With bzip2 the removal of -q seems to be good because with -q
+it prints nothing if input is corrupt. The other tools aren't
+silent in this situation even with -q. On the other hand, if
+zstd support is added, it will need -q since otherwise it's
+noisy in normal situations.
+
+Thanks to Étienne Mollier and Sebastian Andrzej Siewior.
+---
+ src/scripts/xzdiff.in | 35 +--
+ 1 file changed, 21 insertions(+), 14 deletions(-)
+
+diff --git a/src/scripts/xzdiff.in b/src/scripts/xzdiff.in
+index eb7825c..98ac0e5 100644
+--- a/src/scripts/xzdiff.in
 b/src/scripts/xzdiff.in
+@@ -116,23 +116,18 @@ elif test $# -eq 2; then
+   if test "$1$2" = --; then
+ xz_status=$(
+   exec 4>&1
+-  ($xz1 -cdfq - 4>&-; echo $? >&4) 3>&- |
++  ($xz1 -cdf - 4>&-; echo $? >&4) 3>&- |
+ eval "$cmp" - - >&3
+ )
+   elif # Reject Solaris 8's buggy /bin/bash 2.03.
+   echo X | (echo X | eval "$cmp" /dev/fd/5 - >/dev/null 2>&1) 
5<&0; then
++# NOTE: xz_status will contain two numbers.
+ xz_status=$(
+   exec 4>&1
+-  ($xz1 -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- |
+-( ($xz2 -cdfq -- "$2" 4>&-; echo $? 

Bug#983069: lintian: please check that upstream signature is made with a modern hash (warn or error on MD5, SHA1, or RIPEMD160)

[Daniel Kahn Gillmor]

Package: lintian
Version: 2.104.0
Control: clone -1 -2
Control: reassign -2 devscripts
Control: retitle -2 [uscan] deprecate upstream signatures made using weak 
hashes like MD5, SHA1, or RIPEMD160

Some upstream packages are signed with OpenPGP using old, deprecated
digest algorithms.

See for example xml2rfc having a recent signature made with SHA-1:
https://mailarchive.ietf.org/arch/msg/xml2rfc-dev/G89V9M7_qSGxDVBb0QpSIqzznVc/

If lintian is scanning a package that includes a cryptographic signature
from upstream, it should warn (or produce an error) if that signature
uses a weak cryptographic digest algorithm.  In particular, MD5, SHA1,
and RIPEMD160 should all be considered weak.

likewise, uscan should provide at least a warning (perhaps an error) if
it fetches an OpenPGP signature that appears to be made using a weak
digest.

For both of these cases (uscan and lintian), I say "warn" by default
instead of "error" because of course a package with a weak signature
shouldn't be treated worse than a package with *no* signature.

Some OpenPGP implementations (like "sqop verify" or "sq verify", both
from sequoia) already deprecate recently-made SHA1 signatures.

If you're using gpgv to verify signatures, you can use the --weak-digest
argument, like so:

$ gpgv --weak-digest RIPEMD160 --weak-digest SHA1 --keyring 
debian/upstream/signing-key.pgp ../xml2rfc_3.5.0.orig.tar.gz.asc 
../xml2rfc_3.5.0.orig.tar.gz
gpgv: Signature made Wed 18 Nov 2020 05:20:56 AM EST
gpgv:using RSA key 4E9B574B8FBB171A
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Invalid digest algorithm
2 $  

(MD5 is already marked as a "weak digest" by default, so no need to
include it specifically)

Thanks for considering this!

 --dkg


signature.asc
Description: PGP signature

Bug#983068: RM: xscorch -- RoQA; dead upstream; unmaintained; depeds on removed readline-gplv2 and others

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

please remove xscorch. Upstream has vanished, and Debian ships this as a
native package - upstream also hasn't touched "our" package in many
years.

It also build-depends on the recently removed GPLv2 readline, as well as
GTKv2, and while we can fix the former, someone would be very motivated
for the GTK port...

I'll mark this bug moreinfo for a few weeks in case someone shows up,
but otherwise let's let go of it.

Best,
Chris

Bug#983067: xz-utils: diff for NMU version 5.2.5-1.1

[Sebastian Andrzej Siewior]

Package: xz-utils
Version: 5.2.5-1.0
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for xz-utils (versioned as 5.2.5-1.1) and
plan to upload it to DELAYED/5 after an ACK from the release team.
It contains a cherry-pick of the patches for #844770 and #975981 as
applied by upstream.

Please feel free to tell me if I should delay it longer.

Regards.

Sebastian
diff -Nru xz-utils-5.2.5/debian/changelog xz-utils-5.2.5/debian/changelog
--- xz-utils-5.2.5/debian/changelog	2020-12-28 11:25:06.0 +0100
+++ xz-utils-5.2.5/debian/changelog	2021-02-18 23:12:30.0 +0100
@@ -1,3 +1,10 @@
+xz-utils (5.2.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update the patches for #844770 and #975981 to what upstream applied.
+
+ -- Sebastian Andrzej Siewior   Thu, 18 Feb 2021 23:12:30 +0100
+
 xz-utils (5.2.5-1.0) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch
--- xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch	1970-01-01 01:00:00.0 +0100
+++ xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch	2021-02-17 23:52:05.0 +0100
@@ -0,0 +1,118 @@
+From: Lasse Collin 
+Date: Mon, 11 Jan 2021 22:01:51 +0200
+Subject: Scripts: Fix exit status of xzdiff/xzcmp.
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+This is a minor fix since this affects only the situation when
+the files differ and the exit status is something else than 0.
+In such case there could be SIGPIPE from a decompression tool
+and that would result in exit status of 2 from xzdiff/xzcmp
+while the correct behavior would be to return 1 or whatever
+else diff or cmp may have returned.
+
+This commit omits the -q option from xz/gzip/bzip2/lzop arguments.
+I'm not sure why the -q was used in the first place, perhaps it
+hides warnings in some situation that I cannot see at the moment.
+Hopefully the removal won't introduce a new bug.
+
+With gzip the -q option was harmful because it made gzip return 2
+instead of >= 128 with SIGPIPE. Ignoring exit status 2 (warning
+from gzip) isn't practical because bzip2 uses exit status 2 to
+indicate corrupt input file. It's better if SIGPIPE results in
+exit status >= 128.
+
+With bzip2 the removal of -q seems to be good because with -q
+it prints nothing if input is corrupt. The other tools aren't
+silent in this situation even with -q. On the other hand, if
+zstd support is added, it will need -q since otherwise it's
+noisy in normal situations.
+
+Thanks to Étienne Mollier and Sebastian Andrzej Siewior.
+---
+ src/scripts/xzdiff.in | 35 +--
+ 1 file changed, 21 insertions(+), 14 deletions(-)
+
+diff --git a/src/scripts/xzdiff.in b/src/scripts/xzdiff.in
+index eb7825c..98ac0e5 100644
+--- a/src/scripts/xzdiff.in
 b/src/scripts/xzdiff.in
+@@ -116,23 +116,18 @@ elif test $# -eq 2; then
+   if test "$1$2" = --; then
+ xz_status=$(
+   exec 4>&1
+-  ($xz1 -cdfq - 4>&-; echo $? >&4) 3>&- |
++  ($xz1 -cdf - 4>&-; echo $? >&4) 3>&- |
+ eval "$cmp" - - >&3
+ )
+   elif # Reject Solaris 8's buggy /bin/bash 2.03.
+   echo X | (echo X | eval "$cmp" /dev/fd/5 - >/dev/null 2>&1) 5<&0; then
++# NOTE: xz_status will contain two numbers.
+ xz_status=$(
+   exec 4>&1
+-  ($xz1 -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- |
+-( ($xz2 -cdfq -- "$2" 4>&-; echo $? >&4) 3>&- 5<&- &-; echo $? >&4) 3>&- |
++( ($xz2 -cdf -- "$2" 4>&-; echo $? >&4) 3>&- 5<&- &3) 5<&0
+ )
+-cmp_status=$?
+-case $xz_status in
+-  *[1-9]*) xz_status=1;;
+-  *) xz_status=0;;
+-esac
+-(exit $cmp_status)
+   else
+ F=`expr "/$2" : '.*/\(.*\)[-.][ablmotxz2]*$'` || F=$prog
+ tmp=
+@@ -161,10 +156,10 @@ elif test $# -eq 2; then
+   mkdir -- "${TMPDIR-/tmp}/$prog.$$" || exit 2
+   tmp="${TMPDIR-/tmp}/$prog.$$"
+ fi
+-$xz2 -cdfq -- "$2" > "$tmp/$F" || exit 2
++$xz2 -cdf -- "$2" > "$tmp/$F" || exit 2
+ xz_status=$(
+   exec 4>&1
+-  ($xz1 -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- |
++  ($xz1 -cdf -- "$1" 4>&-; echo $? >&4) 3>&- |
+ eval "$cmp" - '"$tmp/$F"' >&3
+ )
+ cmp_status=$?
+@@ -175,7 +170,7 @@ elif test $# -eq 2; then
+   *)
+ xz_status=$(
+   exec 4>&1
+-  ($xz1 -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- |
++  ($xz1 -cdf -- "$1" 4>&-; echo $? >&4) 3>&- |
+ eval "$cmp" - '"$2"' >&3
+ );;
+ esac;;

Bug#983066: xml2rfc: new 3.5.0 version available upstream

[Daniel Kahn Gillmor]

Package: src:xml2rfc
Version: 2.47.0-1

upstream version 3.5.0 is available upstream in xml2rfc:

   https://pypi.org/project/xml2rfc/

I'm working on packaging this new version for debian.

If it works cleanly, I'll likely put it in experimental for now due to
the freeze, but if other people have a specific reason that they think
it should be in unstable, i'm fine with moving it there too.

  --dkg


signature.asc
Description: PGP signature

Bug#983065: debian-policy: Downgrades are not allowed / Package upgrades must have a greater version than previous packages of the same name in the same suite

[Axel Beckert]

Package: debian-policy
Version: 4.5.1.0
Severity: normal

Hi,

I know this is very obvious, but if you read

* https://www.debian.org/Bugs/Developer#severities and
* https://release.debian.org/testing/rc_policy.txt

it seems as if it should be listed somewhere in the policy that package
downgrades MUST not happen during upgrades within the same suite
(i.e. also not during dist-upgrades from e.g. oldstable to stable).

I searched for "downgrad" (case-insensitively) in the whole policy and
read at least the sections 3.2 "The version of a package" and 5.6.12
"Version". (If it's documented elsewhere in the policy, it might need a
pointer to there in these sections.)

Reason for this bug report:

After reading https://release.debian.org/testing/rc_policy.txt,
especially after word "complete" this paragraph …

  The purpose of this document is to be a correct, complete and
  canonical list of issues that merit a "serious" bug under the clause
  "a severe violation of Debian policy".

… I really had a hard time arguing why https://bugs.debian.org/983018 is
actually release-critical, despite I was 100% sure that it is. Luckily
the maintainer did not start discussing but just fixed it. :-)
X-Debugs-Cc'ing the release team for the involvement of rc_policy.txt.

The best written source I so far found was
https://wiki.debian.org/SystemDowngrade and hence outside the policy.

I suggest to add maybe a section 3.2.3 at
https://www.debian.org/doc/debian-policy/ch-binary.html#the-version-of-a-package
with a text like this:

---8<---
3.2.3 Version numbers of upgrades within one suite

Version numbers of succeeding package upgrades within the same suite
MUST be strictly greater than the one of the previous package.

Package downgrades within one suite or when dist-upgrading from an old
stable to a new stable release MUST not happen.

See 5.6.12.1. Epochs should be used sparingly for cases where you need
to package an upstream release with a lower upstream version
number. Even in that case the package version itself MUST be greater.
--->8---

Maybe some of the phrases from https://wiki.debian.org/SystemDowngrade
can be reused, too. Mostly thinking of these, because these are the core
reasons:

1. The packages' installation scripts (postinst...) are designed to
   handle upgrade only.

2. The installation tools are designed to replace older versions of
   packages by newer versions.

Improvements of this text are very welcome as it's currently just a
first brain dump.

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  3.4.3-1

Versions of packages debian-policy suggests:
ii  doc-base  0.11.1

-- no debconf information

Bug#982944: rename.ul was arbitrarily removed from util-linux citing non-existent policy

[Adam Conrad]

Unsubscribe

-Original Message-
From: Scott Mcdermott [mailto:sc...@smemsh.net] 
Sent: Thursday, February 18, 2021 2:02 PM
To: 982...@bugs.debian.org
Subject: Bug#982944: rename.ul was arbitrarily removed from util-linux citing 
non-existent policy

Incidentally, RedHat has long had rename from util-linux as
/usr/bin/rename.  So that's yet another reason to use an Alternative:
so people with heterogeneous farms can expect the same binary path
to behave the same way regardless of which system they're logged
into.  This should be an administrator decision.

This Alternative was added in 2007 with bug 439647 and I can't
fathom the reason it was removed 14 years later because
someone doesn't like its CLI.  After all that's the point of Alternatives.

Bug#982324: ksplashqml crash at plasma workspace startup

[Norbert Preining]

On Thu, 18 Feb 2021, Tobias Rupf wrote:
> I suspect the package plasma-calendar-addons beeing the cause - but I not 
> sure as I have not tested it again. I have read something about 
> plasma-calendar issues here 
> https://www.reddit.com/r/kde/comments/isi2s6/event_calendar_making_latest_plasma_and_qt_crash/[1]
>  and this is the only package I remember which was installed before but I 
> didn't install again now.

Yes, the event calender also took down my Plasma some time ago ;-)
This is a problem with user installed widgets which we cannot really
control. I recommend looking into plasma-discover at times and check
whether there are updates for all the user installed stuff available.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research Labs  +  IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#982275: debianutils: add-shell depends on non-essential package

[Michael Gilbert]

On Sat, Feb 13, 2021 at 5:01 AM Andreas Henriksson wrote:
> > For systems where awk is not yet installed (chroots), installation of
> > dash will currently fail since it's postinst calls add-shell from
> > debianutils.
>
> Please share details about how to reproduce this situation!
>
> You say you don't have awk when dash postinst runs, but that would also
> mean you don't have base-files (since it pre-depends on awk), which
> means you're lacking essential packages while you're configuring
> dash!
>
> Sounds to me like you're doing something very peculiar and likely
> completely unsupported to be able to trigger this issue. Atleast I can't
> think of any obvious way how to trigger it.

Yes, I am doing something quite peculiar.  I am trying to install the
absolute minimal system possible, just enough to be able to run a
shell (dash).  In fact without even base-files.

# mmdebstrap --verbose --variant=custom
--include=sed,grep,libc-bin,dash,diffutils,coreutils unstable unstable
[...]
/usr/sbin/add-shell: 20: awk: not found
Either another instance of /usr/sbin/add-shell is running, or it was
previously interrupted.
Please examine /etc/shells.tmp to see if it should be moved onto /etc/shells.
dpkg: error processing package dash (--install):
 installed dash package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
 dash

I can add mawk to the list of packages to make it work, but that isn't
quite so minimal ;)

# mmdebstrap --verbose --variant=custom
--include=sed,mawk,grep,libc-bin,dash,diffutils,coreutils unstable
unstable

> Replacing using awk with cat whenever possible sounds like a good thing
> to do, so for the record I'm not against that. My skepticism is more
> at why this is not a wishlist bug report (that would be much better to
> adress early in a development cycle, rather than when we're already in
> the bullseye freeze).

Given the peculiarity and simple work around, I am ok with any severity.

Best wishes,
Mike

Bug#981372: keepassxc: New upstream release 2.6.3

[Julian Andres Klode]

On Thu, Feb 18, 2021 at 07:01:36PM +0100, Enrique wrote:
> Package: keepassxc
> Version: 2.6.2+dfsg.1-1
> Followup-For: Bug #981372
> X-Debbugs-Cc: cqu...@arcor.de
> 
> Hi,
> 
> indeed it would be nice if bullseye ship a fairly recent version. One of the
> problems with 2.6.2 is that most of translations are not up to date. At least
> for Spanish there are quite a number of untranslated strings. However in 2.6.4
> the translations seem to be complete.

I'm afraid we missed the window for bullseye.

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

Bug#983053: RFS: sanlock/3.8.3-1 -- Shared storage lock manager

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: sanlock
   Version : 3.8.3-1
   Upstream Author :
 * URL : https://www.pagure.io/sanlock/
 * License : GPL-2+, LGPL-2.1+
 * Vcs :
   Section : libs

It builds those binary packages:

  python3-sanlock - Python3 bindings to shared storage lock manager
  libsanlock-dev - Shared storage lock manager (development files)
  libsanlock1 - Shared storage lock manager (shared library)
  libsanlock-client1 - Shared storage lock manager (client library)
  sanlk-reset - Host reset daemon and client using sanlock
  sanlock - Shared storage lock manager

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/sanlock/sanlock_3.8.3-1.dsc

Changes since the last upload:

 sanlock (3.8.3-1) experimental; urgency=medium
 .
   * New upstream version 3.8.3
   * Drop patches applied upstream
   * New package: sanlk-reset
   * d/rules: Drop Python version flag
   * d/control:
 - Remove sanlock as dependency for libsanlock-dev
 - Add packages to suggests field
 - Add multiarch field
 - Bump debhelper to 13

Regards,
Håvard

Bug#980929: reportbug and installation-report

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sat, 6 Feb 2021 16:50:40 +0100):
> Hi,
> 
> Nis Martensen  wrote:
> > What do you think about including the installation-report message
> > template directly in reportbug?
> > 
> > In reportbug's GTK interface, the output of bugscripts is not handed to
> > the user for editing, since it is seen as additional information and not
> > essential to the report. This view is incompatible with using the bug
> > script to generate a message template, which is what the
> > installation-report bug script is doing.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931438
> > 
> > So instead of changing the reportbug GTK ui, I'm proposing a pair of
> > changes to the installation-report package:
> > https://salsa.debian.org/installer-team/installation-report/-/merge_requests/1
> > and to reportbug:
> > https://salsa.debian.org/reportbug-team/reportbug/-/commit/15d209f4cf899f76749200899218e37c48a8f5a7
> 
> Any objections against merging the above MR against installation-report?
> Are there some drawbacks to expect?

Now merged.
Will upload at the weekend, I think.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#982944: rename.ul was arbitrarily removed from util-linux citing non-existent policy

[Scott Mcdermott]

Incidentally, RedHat has long had rename from util-linux as
/usr/bin/rename.  So that's yet another reason to use an Alternative:
so people with heterogeneous farms can expect the same binary path
to behave the same way regardless of which system they're logged
into.  This should be an administrator decision.

This Alternative was added in 2007 with bug 439647 and I can't
fathom the reason it was removed 14 years later because
someone doesn't like its CLI.  After all that's the point of Alternatives.

Bug#982903: gitlab: Internal error caused by missing gitaly-git2go binary

[Maximilian Stein]

Uploaded gitaly 13.7.5 to fasttrack-staging. If someone can confirm this, I 
will move it to fasttrack.



Hi,

I can confirm that gitaly-git2go is now present, however gitlab now 
refuses to start since it's missing gitaly-13.6.5. So I cannot confirm 
that gitaly-git2go is actually working.


But I guess the refusal to start is just due to the updated gitlab 
package still being missing? If gitlab requires an exact version of 
gitaly shouldn't that be an exact dependency (i.e., "gitaly (=13.6.5-1)" 
instead of "gitaly (>= 13.6~)")?


Best,

Maximilian



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Martin Schurz]

It sounds like you're assuming that  someone will add  pam_tally or
pam_pam_tally2 using a package profile in /usr/share/pam-configs.
I was assuming someone would add pam_tally or pam_tally2 by modifying
the config in /etc/pam.d directly.


Yes, I was assuming this. after I discovered pam-auth-config this seemed
like the best way to manage this stuff, even manually. Additionally I am
involved in a project, which handles hardening of server configurations.
There we also use this approach:

https://github.com/dev-sec/ansible-collection-hardening/blob/master/roles/os_hardening/templates/usr/share/pam-configs/pam_tally2.j2



First, I'm guessing that when you talk about someone enabling pam_tally
through pam-configs  you  are talking about in a profile they wrote, 
not

in a package in Debian.
If there's a package in Debian that enables pam_tally we should file a
bug against that package and use a breaks relationship to avoid the
issue.


Yes I was assuming, that users als use pam-config. As for packages, I am
currently not aware of any package in Debian, that does this. But as
stated above, there are automation solutions, that use this approach.



If someone has included a module they wrote in /usr/share/pam-configs, 
I
agree with your original approach: we should detect that module and 
halt

the upgrade.


I only partially agree with this. Disabling the detected pam-config is
one of the most clear and safe things we could do automatically. but we
should definately tell the user, that we have detected an incompatible
config nad disabled it.



However, if there are no modules that enable pam_tally from pam-configs
but there are entries in /etc/pam.d/* think we should comment
those entries out.


This is where I disagree. We can not in any automatic way decide how we
handle the configs in /etc/pam.d. In any case we should produce a diff
an let the user sort things out.

I am thinking of using ufc in a way like this:
https://salsa.debian.org/ssh-team/openssh/-/blob/master/debian/openssh-server.postinst#L83

So, why do I disagree. Consider a user wanting to use tally, but only
for users with uid > 1000. This would be possible with this pam config:

auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid 
>= 1000 quiet

authrequired  pam_tally2.so
authsufficientpam_unix.so nullok try_first_pass

If we disable tally by commenting/deleting the one line, we would
instruct pam to skip pam_unix.so for every user, who has a uid > 1000.

This is a problem, only if we are directly meddling in /etc/pam.d for
pam-config profiles this should be handled by the updte script. Unless
the user has done something teirselves to /etc/pam.d. Which leeds us
to the above statement agein. Once we start editing /etc/pam.d without
respectiong the context of all pam modules things get messy.

Bug#983064: unblock: notmuch/0.31.4-1

[David Bremner]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package notmuch

[ Reason ]

There is two improvements in 0.31.4-1 that would be nice for
bullseye. The first is a fix for a flaky test that causes failures
about 15% of the time for parallel builds. The second fixes a build
failure against glib 2.67 (currently in experimental).

[ Impact ]

The test related build failures generate failures generate false
positives during archive rebuilds. They could potentially cause issues
for binNMUs, although that hasn't been an issue in practice. The
incompatibility with glib 2.67 is mostly hypothetical at this point.

[ Tests ]

I've done 80+ rebuilds on 60 hardware threads / 30 cores without
triggering the test failure.

I also built a few times against glib 2.67 in an sid/experimental chroot.

[ Risks ]

Both sets of changes are (textually) trivial.  Notmuch is not quite a
leaf package, but the number of dependencies is relatively small.

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

unblock notmuch/0.31.4-1

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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmAu0gsACgkQA0U5G1Wq
FSHc/hAAof5a6L+xF/v/O9HEpTeKI2mSGwxQpsrce3qna56dS3ochLvHJ1F0PBTZ
/JZ1ka+OmqJ/txcITQjHWgBVSdb5ulUJuVxBljVt4Ysos7V468isd1pqBX33W3Jy
qUBrqpqclZ6S3uyof6KUAshrG5Exj5gm379PW+DoHouaujeJysXA5FNj+R2PavB2
DIupBLPaHFEhiYtFHJj4Zvk5dULVctrlhYE8vo1hrS3GEJg1F9Sbrp7K8Wy//fB7
93qMP7hIG63S77TZ7PXTB88dLXuszVzwXirc1jIF0OemLnDXgIvpC4I2VKKR3+I+
NYYhjhxJoD/w6MtjJElTmS0CU6LRqcy+Cw4ErMUDwNdxIxie7tVaiCvlrYYBEL6C
ALlXCNyLrnBzx1XLQofGRX/m9sNxcEqHBwaaHoRuegmyRbxEW36r+O91K1uLQIlH
taWYthp7UX9dcdo6QogWHdMVTOKpdwFAGWBtHXjbwwYahJdPzOHhG/hgsdVEH4EN
HTxC7R4tcoqUbdwIvHvcTwAUGX2Dy/gV3ThCLanG6dbrZccTAv3SpfQjbn68TAtq
r9kHfh+J4R+tohu4zlIrxoksPyKlAp2J06BhWfDnf0Guu/vWu+4ich+5LOjGv5rp
eDD81pANU3bjehfotY83kcaz5mShnKq3YcGTB8S7eCsYn+n7NcA=
=Q+wV
-END PGP SIGNATURE-
diff -Nru --exclude debian-changes 
notmuch-0.31.3/bindings/python/notmuch/version.py 
notmuch-0.31.4/bindings/python/notmuch/version.py
--- notmuch-0.31.3/bindings/python/notmuch/version.py   2020-12-25 
12:21:05.0 -0400
+++ notmuch-0.31.4/bindings/python/notmuch/version.py   2021-02-18 
07:55:28.0 -0400
@@ -1,3 +1,3 @@
 # this file should be kept in sync with ../../../version
-__VERSION__ = '0.31.3'
+__VERSION__ = '0.31.4'
 SOVERSION = '5'
diff -Nru --exclude debian-changes 
notmuch-0.31.3/bindings/python-cffi/version.txt 
notmuch-0.31.4/bindings/python-cffi/version.txt
--- notmuch-0.31.3/bindings/python-cffi/version.txt 2020-12-25 
12:21:05.0 -0400
+++ notmuch-0.31.4/bindings/python-cffi/version.txt 2021-02-18 
07:55:28.0 -0400
@@ -1 +1 @@
-0.31.3
+0.31.4
diff -Nru --exclude debian-changes notmuch-0.31.3/debian/changelog 
notmuch-0.31.4/debian/changelog
--- notmuch-0.31.3/debian/changelog 2020-12-26 15:14:07.0 -0400
+++ notmuch-0.31.4/debian/changelog 2021-02-18 07:23:00.0 -0400
@@ -1,3 +1,11 @@
+notmuch (0.31.4-1) unstable; urgency=medium
+
+  * New upstream bugfix release
+- Fix include bug triggered by glib 2.67
+- Fix race condition in T568-lib-thread
+
+ -- David Bremner   Thu, 18 Feb 2021 07:23:00 -0400
+
 notmuch (0.31.3-2) unstable; urgency=medium
 
   * Don't install gdb on hppa (skip gdb based tests)
diff -Nru --exclude debian-changes notmuch-0.31.3/debian/patches/series 
notmuch-0.31.4/debian/patches/series
--- notmuch-0.31.3/debian/patches/series2020-12-26 15:14:07.0 
-0400
+++ notmuch-0.31.4/debian/patches/series1969-12-31 20:00:00.0 
-0400
@@ -1 +0,0 @@
-debian-changes
diff -Nru --exclude debian-changes notmuch-0.31.3/doc/conf.py 
notmuch-0.31.4/doc/conf.py
--- notmuch-0.31.3/doc/conf.py  2020-12-25 12:21:05.0 -0400
+++ notmuch-0.31.4/doc/conf.py  2021-02-18 07:55:28.0 -0400
@@ -14,7 +14,7 @@
 
 # General information about the project.
 project = u'notmuch'
-copyright = u'2009-2020, Carl Worth and many others'
+copyright = u'2009-2021, Carl Worth and many others'
 
 location = os.path.dirname(__file__)
 
diff -Nru --exclude debian-changes notmuch-0.31.3/lib/notmuch-private.h 
notmuch-0.31.4/lib/notmuch-private.h
--- notmuch-0.31.3/lib/notmuch-private.h2020-12-25 12:21:05.0 
-0400
+++ 

Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1

[Chris Hofstaedtler]

Control: severity -1 normal

* Dmitry Bogatov  [2019-09-11 16:15]:
> control: severity -1 +normal

That appears to have failed. Trying again, as a service :-)

Bug#983063: prctl should be Architecture: linux-any

[Adrian Bunk]

Source: prctl
Version: 1.6-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=prctl=sid

...
gcc -c -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_STRERROR=1  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security prctl.c
prctl.c:29:10: fatal error: linux/prctl.h: No such file or directory
   29 | #include 
  |  ^~~
compilation terminated.
make[1]: *** [Makefile:71: prctl.o] Error 1

Bug#983062: ITP: python-emoji -- Emoji for Python

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 
X-Debbugs-Cc: debian-de...@lists.debian.org, team+pyt...@tracker.debian.org

* Package name: python-emoji
  Version : 1.2.0
  Upstream Author : Taehoon Kim and Kevin Wurster
* URL : https://pypi.org/project/emoji/
* License : BSD
  Programming Lang: Python
  Description : Emoji for Python

The entire set of Emoji codes as defined by the unicode
consortium is supported in addition to a bunch of aliases. By
default, only the official list is enabled but doing
emoji.emojize(use_aliases=True) enables both the full list and
aliases.

Bug#982688: wireless interface name unstable across reboots

[Michael Biebl]

Am 18.02.2021 um 21:03 schrieb Yuri D'Elia:

On Thu, Feb 18 2021, Michael Biebl wrote:

There is afaics.
udev announces devices only after it has fully processed all udev rules.


Asking here since it's on topic and you might be more familiar with it
than I am: as these devices also emitted as an event or target that can
be used in a unit for dependency then?


Please ask on the systemd-devel mailing list (this is a bug tracker).

Thanks,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983061: put-dns: Language errors in Debconf template

[Helge Kreutzmann]

Package: put-dns
Version: 0.0.2-3
Severity: minor
Tags: patch

1. In the first string there is a superfluous space before the
   question mark.

2. In the second string there is a missing full stop before the 2nd
   "If"

Also I suggest that you ask for review on debian-l10n-english, as some
sentence sound strange (but I'm not a native speaker).

Please unfuzzy all Debconf translations you receive(d).


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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#983060: put-dns: [INTL:de] initial German debconf translation

[Helge Kreutzmann]

Package: put-dns
Version: 0.0.2-3
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for put-dns
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the put-dns package.
# Helge Kreutzmann , 2021.
#
msgid ""
msgstr ""
"Project-Id-Version: put-dns 0.0.2-3\n"
"Report-Msgid-Bugs-To: put-...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-16 09:05+\n"
"PO-Revision-Date: 2021-02-18 21:05+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

# FIXME Incorrect space before ?
#. Type: boolean
#. Description
#: ../templates:1001
msgid "Automatically update domain in put-dns.conf ?"
msgstr "Domain in put-dns.conf automatisch aktualisieren?"

# FIXME Missing full stop before send "If"
#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"If put-dns detects during its configuration that the system domain is "
"possibly a valid one, then the domain in put-dns.conf can be updated to "
"match. If false then put-dns.conf will not be updated If true then put-dns "
"configuration will set the domain if it looks valid."
msgstr ""
"Falls Put-dns während seiner Konfiguration merkt, dass die System-Domain "
"möglicherweise gültig ist, dann kann die Domain in put-dns.conf so "
"aktualisiert werden, dass sie mit der System-Domain übereinstimmt. Falls "
"falsch, dann wird put-dns.conf nicht aktualisiert. Falls wahr, dann wird die "
"Put-dns-Konfiguration die Domain setzen, falls sie gültig erscheint."

Bug#983059: doxygen output not reproducible

[Julian Andres Klode]

Package: doxygen
Severity: normal
X-Debbugs-Cc: j...@debian.org

In 
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/apt.html,
 
the order of the todo file changed, meaning that Doxygen did not order its 
input before processing
them.

A regression in doxygen 1.9? I don't know.

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

Bug#982987: tech-ctte: Call for votes for new CTTE member

[Niko Tyni]

On Wed, Feb 17, 2021 at 12:45:05PM -0600, Gunnar Wolf wrote:

> ===BEGIN
> 
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
> 
> ===END

I vote:

A > B

-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: PGP signature

Bug#982879: Acknowledgement (Artifacts in x2go rendering connecting to testing from a buster client)

[Sven Geuer]

Hi Francesco,

On Thu, 2021-02-18 at 13:47 +0100, Francesco P. Lovergine wrote:
> On Thu, Feb 18, 2021 at 11:22:27AM +0100, Francesco P. Lovergine wrote:
> > On Thu, Feb 18, 2021 at 10:56:04AM +0100, Francesco P. Lovergine wrote:
> > > Update: I tested also with a vagrant installation of a testing64 vm 
> > > (from scratch), under a virtualbox provider. It gives exactly the 
> > > same result. IMHO this bug should be raised to important or grave 
> > > because could render unusable the x2goserver in bullseye for many 
> > > (if not most) use cases :-( I still did not check the use of 
> > > bullseye from a bullseye client or other platforms.
> > > 
> > 
> > ... and it gives the same artifacts using a bullseye client (which 
> > works perfectly while connecting a buster x2go server). So this is 
> > definitively an issue of the x2goserver in bullseye.
> > 
> 
> Ok, workaround: disable composite rendering, which could be done in both xfce 
> and mate settings, for instance. 
> 

Looks like xfce4 and mate started to make use of the composite X
extension. This extension is not supported by the NX libs used with
x2go as documented on the project's home page [1].

For mate and tightvncserver on bullseye I observed the identical issue
a few days ago, and tightvncserver also lacks the composite extension.

Seems as if you have to live with the workaround.

Sven

[1] 
https://wiki.x2go.org/doku.php/wiki:development:roadmap#first_attempt_at_documenting_missing_nx-libs_features_for_certain_applications_and_desktop_environments

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#975535: elpy's autopkg tests fail with Python 3.9

[Nicholas D Steeves]

Hi Adrian,

Adrian Bunk  writes:

> On Sat, Jan 30, 2021 at 10:09:03PM -0500, Nicholas D Steeves wrote:
>> Hi Adrian,
>
> Hi Nicholas,
>
>> Thank you for checking in with this bug!  Please let me know ASAP if
>> another autoremoval exception will be provided, because if necessary I
>> can do the shady thing of disabling tests to buy time...but I'd really
>> prefer not to!
>
> I am not a member of a release team, just a normal developer.
>

ACK :-)

> Personally, I would go with disabling some (or all) tests if the package 
> is overally working and the tests are the only worry for missing bullseye.
>

Basic functionality is ok, depending on the working definition of
"basic", but my feeling is that it's a minefield for intermediate and
advanced use of the IDE features due to a big wave of breaking changes
introduced by various dependencies in the period right between this bug
was filed, continuing until shortly before our soft freeze.  Active
upstream issues that affect Elpy in bullseye have been multiplying, and
at this point I'm starting to find it strange that this (#975535) is the
only reported bug.

The primary maintainer has injured hands and will be AFK for a while as
he recovers.  The second maintainer has a new job and no time, but my
hope is the upstream community will band together in time to get Elpy
into a good state in time for bullseye.  I will contribute what I can,
but worry that it won't be enough.

Coordination is occurring here:
https://github.com/jorgenschaefer/elpy/issues/1884

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#982910: udev: Please create persistant /dev/serial/ link for plateform specific ttyS*

[Michael Biebl]

Am 18.02.2021 um 20:16 schrieb Michael Biebl:


Can you raise this upstream please at
https://github.com/systemd/systemd/issues

I don't have such hardware and there are likely follow-up questions that 
upstream will have.




I would include a "udevadm info" dump of those devices in that upstream 
bug report.

Bug#982910: udev: Please create persistant /dev/serial/ link for plateform specific ttyS*

[Michael Biebl]

Hello Bastien

Am 16.02.21 um 13:24 schrieb Bastien Roucariès:


Please create /dev/serial/ persistant rules for plateform (pci/soc) serial port.

It will help for developping NTP GPS displined board for freedom box and other 
uses based on olimex board

persistant serial name are created for usb device and not for soc/pci serial 
board that render harder to bind serial port to a particular use.


Can you raise this upstream please at
https://github.com/systemd/systemd/issues

I don't have such hardware and there are likely follow-up questions that 
upstream will have.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#983058: FTCBFS: uses build system compiler and pkg-config

[John Scott]

Source: hydra
Version: 9.1-1
Severity: minor
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Tags: patch
Control: forwarded -1 https://github.com/vanhauser-thc/thc-hydra/issues/607

Hi,

I took a look into what it would take to get Hydra to cross-build from
source, and there are two main issues. The first is that it's using the
build system compiler by default instead of the host; I've attached a
patch for this.

The second is that Hydra's custom build system uses the wrong pkg-
config and doesn't find GTK. I've filed an upstream issue for them to
add a mechanism to specify the right pkg-config.

A third issue is that the make_xhydra.sh script doesn't pass along the
top-level configure arguments needed for it to cross-build, but perhaps
this can be worked around by building the xhydra directory with its own
call to dh_auto_configure/build.


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

Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
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

diff -u -r hydra-9.1.orig/debian/rules hydra-9.1/debian/rules
--- hydra-9.1.orig/debian/rules	2021-02-18 13:55:49.040956864 -0500
+++ hydra-9.1/debian/rules	2021-02-18 13:56:35.680809197 -0500
@@ -1,11 +1,11 @@
 #!/usr/bin/make -f
-
+include /usr/share/dpkg/buildtools.mk
 #export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 INSTALL := install -m 755
 
 %:
-	dh $@
+	CC=$(CC) dh $@
 
 override_dh_auto_install:
 	$(INSTALL) hydra $(CURDIR)/debian/hydra/usr/bin


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

Bug#982882: stellarium FTBFS on armel and mipsel

[Tomasz Buchert]

On 15/02/21 20:54, Paul Gevers wrote:
> Source: stellarium
> Version: 0.20.4-1
> Severity: serious
> Tags: ftbfs
>
> [...]

Seems like it is
https://github.com/Stellarium/stellarium/issues/1131. This has been
solved with https://bugreports.qt.io/browse/QTBUG-87010.

Surprisingly, the fix is not in qtbase-opensource-src-5.15.2+dfsg. I'm
not sure why, it seems like the fix was intended to land there.

I think I can work around this by probably removing parallelism in the
build process. I'll see if that works.


signature.asc
Description: PGP signature

Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon

[Горбешко Богдан]

On 18.02.2021 16:27, Pino Toscano wrote:

In data giovedì 18 febbraio 2021 15:20:53 CET, Горбешко Богдан ha scritto:

I had checked the upstream repository before reporting this issue
(that's where I got the filename), it still contains this version of the
icon. Reporting here, because I couldn't find an issue tracker on KDE
GitLab.

https://bugs.kde.org is the KDE upstream bug tracking system. Please
report it there, rather than on a downstream bug tracking system.

Reported to upstream https://bugs.kde.org/show_bug.cgi?id=433191, feel 
free to close it :)

Bug#983057: ruby-kramdown-rfc2629: kramdown-rfc2629 --version produces "unknown-version"

[Daniel Kahn Gillmor]

Package: ruby-kramdown-rfc2629
Version: 1.3.28-1

I would have expected "kramdown-rfc2629 --version" to report either the
upstream version (1.3.28) or the debian revision (1.3.28-1), but instead
i get "unknown-version":

0 dkg@alice:~$ kramdown-rfc2629 --version
kramdown-rfc2629 unknown-version
0 dkg@alice:~$ 

I haven't dug deep enough to know whether this is an upstream bug or an
issue with an impedence mismatch between debian packages and ruby gems,
but i do note that from irb i see the same issue.

kramdown-rfc2629 has this source:

KDRFC_VERSION=Gem.loaded_specs["kramdown-rfc2629"].version rescue 
"unknown-version"

and from irb:

irb(main):001:0> require 'kramdown-rfc2629'
=> true
irb(main):002:0> Gem.loaded_specs["kramdown-rfc2629"]
=> nil
irb(main):003:0> Gem.loaded_specs["kramdown-rfc2629"].version
Traceback (most recent call last):
4: from /usr/bin/irb:23:in `'
3: from /usr/bin/irb:23:in `load'
2: from /usr/lib/ruby/gems/2.7.0/gems/irb-1.2.6/exe/irb:11:in `'
1: from (irb):3
NoMethodError (undefined method `version' for nil:NilClass)
irb(main):004:0> Gem.loaded_specs["kramdown-rfc2629"].version rescue 
'unknown-version'
=> "unknown-version"
irb(main):005:0> 


I defer to debian ruby packagers who have much deeper knowledge than i
do about how this stuff all works.  Upstream is pretty responsive,
fwict, so if it's an upstream issue, please forward it to
https://github.com/cabo/kramdown-rfc2629/issues

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#982519: zstd: Race condition allows attacker to access world-readable destination file

[Thorsten Glaser]

On Thu, 18 Feb 2021, Salvatore Bonaccorso wrote:
> On Thu, Feb 11, 2021 at 08:33:58AM +0100, Sebastien Delafond wrote:

> > The recently applied patch still creates the file with the default
> > umask[0], before chmod'ing down to 0600, so an attacker could still open
> > it in the meantime.
>
> FTR, this has been fixed upstream.
>
> https://github.com/facebook/zstd/commit/a774c5797399040af62db21d8a9b9769e005430e

| Note that a downside of this solution is that it is global: `umask()` affects
| all file creation calls in the process. I believe this is safe since
| […] thread […]

Why don’t you use a nōn-global solution then?

Instead of fopen(…) do an open(…, 0600) followed by fdopen().

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Bug#981976: marked as done (icingaweb2-module-businessprocess: depends on nonexistent icingaweb2-ipl)

[Willy nilly]

close 981976

On Thu, Feb 18, 2021 at 5:51 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Thu, 18 Feb 2021 17:48:49 +
> with message-id 
> and subject line Bug#981976: fixed in icingaweb2-module-businessprocess
> 2.3.0-2
> has caused the Debian Bug report #981976,
> regarding icingaweb2-module-businessprocess: depends on nonexistent
> icingaweb2-ipl
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 981976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981976
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "bs.net" 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 05 Feb 2021 14:55:53 +0100
> Subject: icingaweb2-module-businessprocess is uninstallable: dependency on
> nonexistent package
> Package: icingaweb2-module-businessprocess
> Version: 2.3.0-1
>
> Hi,
>
> the icingaweb2-module-businessprocess package is unusable in Debian,
> because
> it has an unmet dependency on icingaweb2-ipl (maybe it should be
> icingaweb2-
> module-ipl?).
>
> It would be good if this problem could be solved.
>
> Thank you and kind regards.
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 981976-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 18 Feb 2021 17:48:49 +
> Subject: Bug#981976: fixed in icingaweb2-module-businessprocess 2.3.0-2
> Source: icingaweb2-module-businessprocess
> Source-Version: 2.3.0-2
> Done: David Kunz 
>
> We believe that the bug you reported is fixed in the latest version of
> icingaweb2-module-businessprocess, which is due to be installed in the
> Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 981...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> David Kunz  (supplier of updated
> icingaweb2-module-businessprocess package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Fri, 18 Jan 2021 14:56:44 +0200
> Source: icingaweb2-module-businessprocess
> Architecture: source
> Version: 2.3.0-2
> Distribution: unstable
> Urgency: medium
> Maintainer: David Kunz 
> Changed-By: David Kunz 
> Closes: 981976
> Changes:
>  icingaweb2-module-businessprocess (2.3.0-2) unstable; urgency=medium
>  .
>* Correcting module name in depends (Closes: #981976).
>* Removing .pc files from binary package.
>* Removing .travis.yml file from binary package.
> Checksums-Sha1:
>  d51f05f9deb4d262b61bf578f54b0c553daedb15 2134
> icingaweb2-module-businessprocess_2.3.0-2.dsc
>  e84130a6b5c80f2a44db28b8d6528f3e6d7238cc 2752
> icingaweb2-module-businessprocess_2.3.0-2.debian.tar.xz
>  d26097ef4aa97e9b03e62429364abb8cbc16a488 5916
> icingaweb2-module-businessprocess_2.3.0-2_amd64.buildinfo
> Checksums-Sha256:
>  332a8cf58b702ad6082cd5d0dc9297860a1bb5175513b97f9071ec7afb2860c7 2134
> icingaweb2-module-businessprocess_2.3.0-2.dsc
>  da04e8b0a745be8e30e1cad837cd3f98987f6a64f0159f260ff0fb38c089 2752
> icingaweb2-module-businessprocess_2.3.0-2.debian.tar.xz
>  15b0e05bed25076840b30776de6c7ab6507ad7d339de2a209448d6c4d5bd1f9e 5916
> icingaweb2-module-businessprocess_2.3.0-2_amd64.buildinfo
> Files:
>  bcb407f0dca7eef2087eb1eac87c64dc 2134 admin optional
> icingaweb2-module-businessprocess_2.3.0-2.dsc
>  8eee12143a6fa255e6eb8b2369f36918 2752 admin optional
> icingaweb2-module-businessprocess_2.3.0-2.debian.tar.xz
>  15a3808211f5e7e4ce44a5f297be772c 5916 admin optional
> icingaweb2-module-businessprocess_2.3.0-2_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEgTbtJcfWfpLHSkKSVc8b+YaruccFAmAupiIACgkQVc8b+Yar
> ucc33BAAgCIuQCZFR5YzxThzNJ4qoYV9tjv5/HijQMDwjNJkzUQhLv+AgzjYFLmK
> yl7d3WGxJDLInY0ZwqoTzKGLX73xbxyiNu0agN6CrBSArgfiCjNbxNJfkyykHMZW
> 0TR/BJ1QcmXUlvcOZghTD6FP4Ux84xWtMp1EDMmS3feSkUHMZif0N6sdqCsazMVB
> IvkSlRTFqWYru9i3QX0tV9ChkAw8mxFVxg/7Odj9GHs8VSYUibwrrcFL6phuMd6I
> +sgky+MqrdaIjvIlkDuz2TUgGhrPAaNRMiHdb93vVXXZWcKT0dxTDd4CVAEqa9nv
> hmpS8QRKyZBnuTYrQSMHpwhpA8lRdX4e92To1jGQYdd7HwUw3+Atg9ACaPM40nUu
> mDYR9gWSfGpU56tXEBRsO/xps1sv+JgV/7ajd/DtHziPZghMF1IO23GBTRDHjOHP
> IrUEiLmV1staoDKg4EwFttPoeJYWpBXAFcKNmYzTpxJ/CvuP723aZeQHe/yw+yIa
> 

Bug#983056: dgit: unnecessarily blocks source-only upload adding a package in unstable to experimental

[Simon McVittie]

Package: dgit
Version: 9.13
Severity: minor

Scenario:
* gtk+3.0 exists in unstable
* gtk+3.0 does not (currently) exist in experimental
- there used to be a version in experimental, but it was removed
  when it was overtaken by the version in unstable
* now I want to upload a new version to experimental

dgit push-source --new fails with:

> dgit: error: source-only upload, even though package is entirely NEW
> dgit: (this is contrary to policy in debian)

However, at least unstable and experimental (possibly other suites)
share an "overrides" list, so packages that are in unstable are allowed
to be uploaded to experimental without going through the NEW queue, which
in turn means we're allowed to upload them source-only.

(This isn't true if uploading an existing source package adds new binary
packages, but dgit doesn't currently detect that anyway: #903090.)

Workaround: also add --force-uploading-source-only.

To encourage use of source-only uploads, it would be nice if there was a
special case to allow this without needing to be forced.

smcv

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

[Dirk Eddelbuettel]

Graham,

Thanks for the bug tracker follow-up which made me aware of the ongoing
discussion in #665 at glmmTMB. It's frustrating to have the run around but it
really looks like as I argued all along: not an issue in Matrix.  Now, TMB is
of course a complex package too..   Appreciate you chasing this so thoroughly.

Dirk

PS What is bts-link? Is that a new service we have to tie our BTS to GH and 
others?

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#981372: keepassxc: New upstream release 2.6.3

[Enrique]

Package: keepassxc
Version: 2.6.2+dfsg.1-1
Followup-For: Bug #981372
X-Debbugs-Cc: cqu...@arcor.de

Hi,

indeed it would be nice if bullseye ship a fairly recent version. One of the
problems with 2.6.2 is that most of translations are not up to date. At least
for Spanish there are quite a number of untranslated strings. However in 2.6.4
the translations seem to be complete.



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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_SOFTLOCKUP
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)
LSM: AppArmor: enabled

Versions of packages keepassxc depends on:
ii  libargon2-10~20171227-0.2
ii  libc6  2.31-9
ii  libgcrypt201.8.7-2
ii  libqrencode4   4.0.2-2
ii  libqt5concurrent5  5.15.2+dfsg-2
ii  libqt5core5a   5.15.2+dfsg-2
ii  libqt5dbus55.15.2+dfsg-2
ii  libqt5gui5 5.15.2+dfsg-2
ii  libqt5network5 5.15.2+dfsg-2
ii  libqt5svg5 5.15.2-2
ii  libqt5widgets5 5.15.2+dfsg-2
ii  libqt5x11extras5   5.15.2-2
ii  libsodium231.0.18-1
ii  libstdc++6 10.2.1-6
ii  libx11-6   2:1.7.0-2
ii  libxi6 2:1.7.10-1
ii  libxtst6   2:1.2.3-1
ii  libykpers-1-1  1.20.0-3
ii  libzxcvbn0 2.4+dfsg-2
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages keepassxc recommends:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4

Versions of packages keepassxc suggests:
ii  webext-keepassxc-browser  1.7.4+repack1-2
ii  xclip 0.13-2

-- no debconf information

Bug#983017: 9base: flaky autopkgtest on i386: stack smashing detected

[Dennis Filder]

The attached patch excludes fortune from the package in case no one
will track this down on a porterbox.  I looked at it on amd64 and
found nothing suspicious sticking out.


9base_nofortune.patch.gz
Description: application/gzip

Bug#983055: nmu: libinih_53-1

[Boyuan Yang]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: jrt...@debian.org mmyan...@gmail.com
Severity: normal

Hi,

The latest upload of libinih/53-1 was not a source-only upload. Please
schedule a binNMU for amd64 to rebuild the binary packages on buildd.

nmu libinih_53-1 . amd64 . unstable . -m "Rebuild on buildd"


-- 
Thanks,
Boyuan Yang


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

Bug#983054: ruby-kramdown-rfc2629: new upstream version 1.3.34

[Daniel Kahn Gillmor]

Package: ruby-kramdown-rfc2629
Version: 1.3.28-1

Upstream has released version 1.3.34, which contains a helpful
transformation for a document i'm working on.  updating the debian
packaging to that version would be great!

(i note that 1.3.28 is a day away from transitioning to testing, so
maybe either an upload to experimental, or a delayed upload would be
wise so that at least 1.3.28 transitions)

thanks for maintaining ruby-kramdown-rfc2629 in debian!

   --dkg


signature.asc
Description: PGP signature

Bug#982324: ksplashqml crash at plasma workspace startup

[Tobias Rupf]

To solve the issue I now have deinstalled everthing from plasma and kde and 
reinstalled again Now plasma is running without crash or black screen at 
startup.

I suspect the package plasma-calendar-addons beeing the cause - but I not sure 
as I have not tested it again. I have read something about plasma-calendar 
issues here 
https://www.reddit.com/r/kde/comments/isi2s6/event_calendar_making_latest_plasma_and_qt_crash/[1]
 and this is the only package I remember which was installed before but I 
didn't install again now.

Hope this help.

Regards,
trupf


[1] 
https://www.reddit.com/r/kde/comments/isi2s6/event_calendar_making_latest_plasma_and_qt_crash/


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

Bug#983052: calamares: reduce Build-Depends

[Helmut Grohne]

Source: calamares
Version: 3.2.35.1-1
Tags: patch

While looking into why calamares wouldn't cross build, I found a number
of unrelated dependencies that can be reduced. libatasmart-dev is
entirely unused and cryptsetup, os-prober, and policykit-1 are only used
for testing. Please consider applying the attached patch.

Helmut
diff --minimal -Nru calamares-3.2.35.1/debian/changelog 
calamares-3.2.35.1/debian/changelog
--- calamares-3.2.35.1/debian/changelog 2020-12-08 15:22:17.0 +0100
+++ calamares-3.2.35.1/debian/changelog 2021-02-18 07:56:15.0 +0100
@@ -1,3 +1,13 @@
+calamares (3.2.35.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Annotate test dependencies cryptsetup, os-prober and policykit-1 with
+  profile .
++ Drop unused libatasmart-dev.
+
+ -- Helmut Grohne   Thu, 18 Feb 2021 07:56:15 +0100
+
 calamares (3.2.35.1-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru calamares-3.2.35.1/debian/control 
calamares-3.2.35.1/debian/control
--- calamares-3.2.35.1/debian/control   2020-05-16 11:16:54.0 +0200
+++ calamares-3.2.35.1/debian/control   2021-02-18 07:56:15.0 +0100
@@ -3,11 +3,10 @@
 Priority: optional
 Maintainer: Jonathan Carter 
 Build-Depends: cmake,
-   cryptsetup,
+   cryptsetup ,
debhelper-compat (= 13),
extra-cmake-modules,
gettext,
-   libatasmart-dev,
libboost-python-dev,
libkf5config-dev,
libkf5coreaddons-dev,
@@ -25,10 +24,10 @@
libqt5svg5-dev,
libqt5webkit5-dev,
libyaml-cpp-dev,
-   os-prober,
+   os-prober ,
pkg-config,
pkg-kde-tools,
-   policykit-1,
+   policykit-1 ,
python3-dev,
qml-module-qtquick-layouts,
qml-module-qtquick-privatewidgets,

Bug#983015: breezy FTFBS with nocheck profile: Missing Build-Depends: python3-setuptools

[Jelmer Vernooij]

On Wed, Feb 17, 2021 at 10:30:44PM +0100, Helmut Grohne wrote:
> Source: breezy
> Version: 3.1.0-8
> Severity: important
> Tags: ftfbs patch
> 
> breezy fails to build from source when enabling the nocheck profile,
> because the setuptools module cannot be found. Please consider applying
> the attached patch to add it to Build-Depends.

Applied, thanks!

Jelmer

Bug#983051: buster-pu: package xterm/344-1+deb10u1

[Sven Joachim]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Salvatore Bonaccorso , Julien Cristau 
, Sven Joachim 

I would like to fix bug #982439/CVE-2021-27135[1] in Buster, a potential
DoS against xterm when the user selects specially crafted text.  The fix
is already in testing and applies unmodified to the version in Buster,
the code in question had not seen any changes since then.  The xterm
package in Stretch-LTS has also already been patched.  At [2] there is
the upstream source of the patch.

Thanks for considering.


1. https://bugs.debian.org/982439
2. 
https://github.com/ThomasDickey/xterm-snapshots/commit/82ba55b8f994ab30ff561a347b82ea340ba7075c#diff-1316a8dc8f904428cd95f29accdea9fff33e680f9f30216391d8df33d2f9f806

diff -Nru xterm-344/debian/changelog xterm-344/debian/changelog
--- xterm-344/debian/changelog	2019-02-14 18:04:18.0 +0100
+++ xterm-344/debian/changelog	2021-02-18 17:39:44.0 +0100
@@ -1,3 +1,11 @@
+xterm (344-1+deb10u1) buster; urgency=medium
+
+  * Apply upstream fix from xterm 365d for CVE-2021-27135.
+- Correct upper-limit for selection buffer, accounting for combining
+  characters (Closes: #982439).
+
+ -- Sven Joachim   Thu, 18 Feb 2021 17:39:44 +0100
+
 xterm (344-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru xterm-344/debian/patches/CVE-2021-27135.diff xterm-344/debian/patches/CVE-2021-27135.diff
--- xterm-344/debian/patches/CVE-2021-27135.diff	1970-01-01 01:00:00.0 +0100
+++ xterm-344/debian/patches/CVE-2021-27135.diff	2021-02-17 19:28:55.0 +0100
@@ -0,0 +1,55 @@
+Description: Fix for CVE-2021-27135 from xterm 365d
+ Correct upper-limit for selection buffer, accounting for
+ combining characters (report by Tavis Ormandy).
+
+---
+ button.c |   23 +++
+ 1 file changed, 19 insertions(+), 4 deletions(-)
+
+--- a/button.c
 b/button.c
+@@ -3914,6 +3914,7 @@ SaltTextAway(XtermWidget xw,
+ int i;
+ int eol;
+ int need = 0;
++size_t have = 0;
+ Char *line;
+ Char *lp;
+ CELL first = *cellc;
+@@ -3948,7 +3949,11 @@ SaltTextAway(XtermWidget xw,
+ 
+ /* UTF-8 may require more space */
+ if_OPT_WIDE_CHARS(screen, {
+-	need *= 4;
++	if (need > 0) {
++	if (screen->max_combining > 0)
++		need += screen->max_combining;
++	need *= 6;
++	}
+ });
+ 
+ /* now get some memory to save it in */
+@@ -3986,10 +3991,20 @@ SaltTextAway(XtermWidget xw,
+ }
+ *lp = '\0';			/* make sure we have end marked */
+ 
+-TRACE(("Salted TEXT:%u:%s\n", (unsigned) (lp - line),
+-	   visibleChars(line, (unsigned) (lp - line;
++have = (size_t) (lp - line);
++/*
++ * Scanning the buffer twice is unnecessary.  Discard unwanted memory if
++ * the estimate is too-far off.
++ */
++if ((have * 2) < (size_t) need) {
++	scp->data_limit = have + 1;
++	line = realloc(line, scp->data_limit);
++}
++
++TRACE(("Salted TEXT:%u:%s\n", (unsigned) have,
++	   visibleChars(line, (unsigned) have)));
+ 
+-scp->data_length = (size_t) (lp - line);
++scp->data_length = have;
+ }
+ 
+ #if OPT_PASTE64
diff -Nru xterm-344/debian/patches/series xterm-344/debian/patches/series
--- xterm-344/debian/patches/series	2019-02-13 17:54:29.0 +0100
+++ xterm-344/debian/patches/series	2021-02-17 18:51:05.0 +0100
@@ -1,3 +1,4 @@
 900_debian_xterm.diff
 902_windowops.diff
 904_fontops.diff
+CVE-2021-27135.diff


signature.asc
Description: PGP signature

Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

[Steve McIntyre]

On Thu, Feb 18, 2021 at 09:32:24AM +0100, Paul Gevers wrote:
>Hi Limonciello,
>
>On 18-02-2021 07:15, Limonciello, Mario wrote:
>> I don't have the power to manually run it. So there is nothing I can do.
>> With the new 1.5.6-1 upload someone will need to manually run it again.
>
>I recognize what you say. However, *in my opinion* you can't just upload
>the unsigned package without securing that the signing will happen ASAP,
>with such tight dependencies. Users of unstable should expect that their
>system breaks once in a while, but that's not by design but because bugs
>happen. Being able to not update because of transitions is to be
>expected and we don't have an alternative. But that's different from
>what I read in this bug, where something else got updated and then the
>fwupd set breaks without warning.

We're in a bind here - by now I was hoping/assuming that we'd have the
signing queue running automatically. I've just prodded in #debian-ftp
to ask people to run the queue.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"War does not determine who is right - only who is left."
   -- Bertrand Russell

Bug#982790: wlroots: started transition during soft freeze

[Sebastian Ramacher]

Hi nicoo

On 2021-02-16 15:59:19, nicoo wrote:
> On Sun, Feb 14, 2021 at 02:49:27PM +0100, Sebastian Ramacher wrote:
> > The upload of 0.12.0-2 just started a transition. Note that we are in
> > soft freeze and hence transitions are no longer acceptable for bullseye.
> 
> Apologies for this: I had discussed this on #debian-devel on 2020-02-04
> with (amongst others) elbrus, at which time I pinged the maintainers of
> wlroots on IRC, but waited 10 days before the upload and missed that
> the soft freeze window had started.

These 10 days makes the difference between transition freeze and soft
freeze. We're now defintely past the point where we want to do
transitions which require actions from the release team (I guess nobodoy
would have noticed this transition if it wouldn't require a binNMU of
phoc). Sorry

> The delay & forgetting was mostly due to some mess elsewhere in Debian
> eating up all my energy; I can tell you privately if it's relevant, but
> it might suffice to say that antiharassment@ and DAM were involved. >_>'

I'm very sorry to hear that.

> For reference, the ABI breakage & soname change is due to wlroots making
> some part of its API private, and removing obsolete & unstable functionality
> (functions wlr_xdg_*_v6_*), which account for the largest part of the diff.
> I attached the debdiff, and upstream's changelog is there:
>   https://github.com/swaywm/wlroots/releases/tag/0.12.0

While it's valuable to keep the ABI clean, I think that this change can
wait for bookworm.

Cheers
-- 
Sebastian Ramacher

Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target

[Chris Hofstaedtler]

* Thomas Goirand  [210218 17:03]:
> On 2/18/21 12:59 PM, Timo Weingärtner wrote:
> > 17.02.21 21:42 Chris Hofstaedtler:
> >> Services that use After=network-online.target are generally broken,
> >> please do not introduce that.
> > 
> > Seconded. Just consider a node where one link is down on boot and you would 
> > have to wait such a long time until you can examine the problem via ssh.
> 
> I still don't understand this part. If network isn't online, how can I
> ssh to my server anyways?

Thats exactly the problem description: everyone and every service
has a different idea of "network is online".

I'm also happy with "fe80::x" IPv6 is ready - for ssh. Don't need to
wait for IPv4 DHCP or a default gateway or whatever.

Chris

Bug#981720: eventlet: doc build fails when no resolv.conf

[Thomas Goirand]

On 2/17/21 6:11 PM, Ritesh Raj Sarraf wrote:
> Package: python-eventlet
> Followup-For: Bug #981720
> 
> Would you consider the attached patch ? I don't know of its side-effects
> but applying the patch does make it build successfully in all build
> environments.

Hi Ritesh,

Thanks for this. I got the inspiration from it, and simply used a
convenient copy of greendns.py in the debian folder with your patch,
which I'm copying before building the doc. This way, I'm not touching
the runtime file!

Cheers,

Thomas Goirand (zigo)

Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target

[Thomas Goirand]

On 2/18/21 12:59 PM, Timo Weingärtner wrote:
> 17.02.21 21:42 Chris Hofstaedtler:
>> Services that use After=network-online.target are generally broken,
>> please do not introduce that.
> 
> Seconded. Just consider a node where one link is down on boot and you would 
> have to wait such a long time until you can examine the problem via ssh.

I still don't understand this part. If network isn't online, how can I
ssh to my server anyways?

Cheers,

Thomas Goirand (zigo)

Bug#983049: nn.c: fix missing braces around initializer

[Bjarni Ingi Gislason]

Source: nn
Severity: normal
Tags: patch

Dear Maintainer,

>From 2a894c008df5abec4271e03cc3e6d41caec4520c Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Thu, 18 Feb 2021 15:33:08 +
>Subject: [PATCH] nn.c: add braces around initializer

  Fix warnings from the compiler:

nn.c:89:1: warning: missing braces around initializer [-Wmissing-braces]

nn.c:128:1: warning: missing braces around initializer [-Wmissing-braces]

Signed-off-by: Bjarni Ingi Gislason 
---
 nn.c | 66 ++--
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/nn.c b/nn.c
index dd21c34..208331d 100644
--- a/nn.c
+++ b/nn.c
@@ -87,32 +87,32 @@ static char
 static
 Option_Description(nn_options)
 {
-'a', Int_Option(article_limit),
-'B', Bool_Option(keep_rc_backup),
-'d', Bool_Option(dont_split_digests),
-'f', Bool_Option(dont_sort_folders),
-'g', Bool_Option(prompt_for_group),
-'G', Bool_Option(nngrab_mode),
-'i', Bool_Option(case_fold_search),
-'I', String_Option_Optional(init_file, NULL),
-'k', Bool_Option(do_kill_handling),
-'l', Int_Option(first_page_lines),
-'L', Int_Option_Optional(fmt_linenum, 3),
-'m', Bool_Option(merged_menu),
-'n', String_Option(match_sender),
-'N', Bool_Option(no_update),
-'q', Bool_Option(dont_sort_articles),
-'Q', Bool_Option(silent),
-'r', Bool_Option(repeat_group_query),
-'s', String_Option(match_subject),
-'S', Bool_Option(fmt_rptsubj),
-'T', Bool_Option(show_current_time),
-'w', Int_Option_Optional(preview_window, 5),
-'W', Bool_Option(conf_dont_sleep),
-'x', Int_Option_Optional(also_read_articles, -1),
-'X', Bool_Option(also_unsub_groups),
-'Z', Int_Option(Debug),
-'\0',
+{'a', Int_Option(article_limit)},
+{'B', Bool_Option(keep_rc_backup)},
+{'d', Bool_Option(dont_split_digests)},
+{'f', Bool_Option(dont_sort_folders)},
+{'g', Bool_Option(prompt_for_group)},
+{'G', Bool_Option(nngrab_mode)},
+{'i', Bool_Option(case_fold_search)},
+{'I', String_Option_Optional(init_file, NULL)},
+{'k', Bool_Option(do_kill_handling)},
+{'l', Int_Option(first_page_lines)},
+{'L', Int_Option_Optional(fmt_linenum, 3)},
+{'m', Bool_Option(merged_menu)},
+{'n', String_Option(match_sender)},
+{'N', Bool_Option(no_update)},
+{'q', Bool_Option(dont_sort_articles)},
+{'Q', Bool_Option(silent)},
+{'r', Bool_Option(repeat_group_query)},
+{'s', String_Option(match_subject)},
+{'S', Bool_Option(fmt_rptsubj)},
+{'T', Bool_Option(show_current_time)},
+{'w', Int_Option_Optional(preview_window, 5)},
+{'W', Bool_Option(conf_dont_sleep)},
+{'x', Int_Option_Optional(also_read_articles, -1)},
+{'X', Bool_Option(also_unsub_groups)},
+{'Z', Int_Option(Debug)},
+{'\0'},
 };
 
 
@@ -126,13 +126,13 @@ extern int
 static
 Option_Description(check_options)
 {
-'Q', Bool_Option(silent),
-'r', Bool_Option(report_number_of_articles),
-'f', String_Option(check_message_format),
-'t', Bool_Option(verbose),
-'v', Bool_Option(verbose),
-'c', Bool_Option(quick_unread_count),
-'\0',
+{'Q', Bool_Option(silent)},
+{'r', Bool_Option(report_number_of_articles)},
+{'f', String_Option(check_message_format)},
+{'t', Bool_Option(verbose)},
+{'v', Bool_Option(verbose)},
+{'c', Bool_Option(quick_unread_count)},
+{'\0',}
 };
 
 /* program name == argv[0] without path */
-- 
2.30.0



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#983050: Variable AWK is not defined

[Bjarni Ingi Gislason]

Source: nn
Severity: normal

Dear Maintainer,

   * What led up to the situation?

  Running "./inst" showed:

./inst: line 123: AWK: unbound variable

###

  The variable AWK is used in several files,
like "aux.sh", "inst.sh", "inst.sh.apollo", "nnstats.sh", "nnusage.sh",
"prefix.c", and "upgrade_rc.sh".

  There is no test if it is defined or not.

  If it should be an environmental variable,
it should be mentioned in the INSTALLATION file.



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#983047: Erratum

[Ludovic Pouzenc]

Erratum : I've written :


I don't know if it doable to get them for*buster*, but it should help

It wanted to say :


I don't know if it doable to get them for*bulleye*, but it should help

Sorry,

--
Ludovic Pouzenc
Ingénieur Informatique de Gestion
Direction du Numérique, DN : Applications
04 79 75 83 54

Bug#982970: offlineimap3: broken folderincludes config option

[Sudip Mukherjee]

On Thu, Feb 18, 2021 at 3:28 PM Santiago Ruano Rincón
 wrote:
>
> El 17/02/21 a las 18:51, Sudip Mukherjee escribió:
> > Hi Santiago,
> >
> > On Wed, Feb 17, 2021 at 2:30 PM Santiago Ruano Rincón
> >  wrote:
> > >
> > > Package: offlineimap3
> > > Version: 0.0~git20210105.00d395b+dfsg-3
> > > Severity: normal
> > > Tags: upstream
> > >
> > > Dear Sudip,
> > >
> > > offlineimap3 is not able to handle the folderincludes config, that
> > > worked with offlineimap. I got this when trying to sync (tested with two
> > > different accounts):
> > >
> > >   'str' object has no attribute 'decode'
> >
> > Can you please test with the PR at
> > https://github.com/OfflineIMAP/offlineimap3/pull/47/ and check if it
> > fixes your issue..
> > I could reproduce the problem in my setup and the above PR fixes the
> > problem for me. I have not tested enough to know if it breaks
> > something else.
>
> It seems to work, thanks!

Thanks for confirming.


-- 
Regards
Sudip

Bug#900374: updated knot.service file available since knot-3.0.1-1

[Jakub Ružička]

I've updated debian/knot.service file from upstream which already
addressed described issues.

It's been synced in knot-3.0.1-1 debian package release and it remains
in sync as of 3.0.4.

You can look at commit cc65f515c1:
https://salsa.debian.org/dns-team/knot-dns/-/commit/cc65f515c1

I believe this issue is solved and can be closed.


Cheers,
Jakub Ružička

Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8

[Simon McVittie]

On Thu, 18 Feb 2021 at 12:06:58 +0100, Pino Toscano wrote:
> In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto:
> > > In Cairo and Pango (which have a similar structure with multiple binary
> > > packages making use of each other's implementation details), I added a
> > > debian/shlibs.local to make sure the binary packages all get lockstep
> > > dependencies. I think the same technique would be appropriate here. See
> > > attached.
> 
> I honestly do not understand how this is even a problem, considering I
> fixed this more than 5 years ago:
> https://salsa.debian.org/freedesktop-team/poppler/-/commit/7929aa2d5ec9464fea755f622319d224787c4110

Sorry, I didn't spot that the interdependencies were already strict. I'll
close the MR.

> I'd rather think that the situation happened because
> elpa-pdf-tools-server links both to libpoppler and libpoppler-glib:
> the rebuild against poppler 20.09.0 (i.e. libpoppler102) make
> elpa-pdf-tools-server link to libpoppler102 (forcing the newer
> dependency to it), and setting an old dependency for libpoppler-glib
> because there is no need for a newer version.

So elpa-pdf-tools-server is linked to libpoppler-glib, and because the
(parts of the) libpoppler-glib API that it uses has not changed for a
while, it is happy with an old version; but then during a partial
upgrade, it can get this

elpa-pdf-tools-server
\- old libpoppler-glib
|   \- libpoppler95
\- libpoppler102

and the two copies of libpoppler fight?

That seems entirely plausible, and I don't immediately see a way to
fix it without adding Breaks (which would force a lockstep upgrade,
somewhat defeating the purpose of SONAMEs).

GNOME had similar issues during the libffi transition, where gjs' direct
use of libffi conflicted with its indirect use via GLib, and I think we
ended up adding Breaks to force the broken combinations not to happen.

> Another contributing factor is that emacs-pdf-tools "abuses" the
> libpoppler-glib internals, see server/poppler-hack.cc. I don't know
> why it does that, and I'd rather see the actual issues fixed in
> libpoppler-glib.

That does look like emacs-pdf-tools is doing things that aren't guaranteed
to work, yes, and the solution is indeed to improve libpoppler-glib to do
what emacs-pdf-tools needs (and then make emacs-pdf-tools depend on the
newer version instead of working around older versions).

smcv

Bug#983048: please provide mke2fs to let fastboot format work

[Dmitry Baryshkov]

Package: fastboot
Version: 1:10.0.0+r36-7
Severity: normal

Currently fastboot format fails because it can not find the mke2fs tool:

$ /usr/bin/fastboot format userdata
/usr/lib/android-sdk/platform-tools/mke2fs failed with status 1
fastboot: error: Cannot generate image for userdata

$ ls -l /usr/lib/android-sdk/platform-tools/
total 604
-rwxr-xr-x 1 root root 202944 Jan 19 23:09 adb
-rwxr-xr-x 1 root root 401512 Jan 19 23:09 fastboot
-rw-r--r-- 1 root root979 Jan 22 12:23 package.xml
-rw-r--r-- 1 root root 50 Jan 22 12:23 source.properties

Please provide mke2fs tool so that we can fastboot format partitions.


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

Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fastboot depends on:
ii  android-libadb 1:10.0.0+r36-7
ii  android-libbase1:10.0.0+r36-7
ii  android-libboringssl   10.0.0+r36-1
ii  android-libcutils  1:10.0.0+r36-7
ii  android-libext4-utils  10.0.0+r36+ds-2
ii  android-libsparse  1:10.0.0+r36-7
ii  android-libunwind  10.0.0+r36-4
ii  android-libziparchive  1:10.0.0+r36-7
ii  android-sdk-platform-tools-common  28.0.2+3
ii  libc6  2.31-9
ii  libgcc-s1  10.2.1-6
ii  libstdc++6 10.2.1-6

fastboot recommends no packages.

Versions of packages fastboot suggests:
pn  android-sdk-platform-tools  

-- no debconf information

Bug#982970: offlineimap3: broken folderincludes config option

[Santiago Ruano Rincón]

El 17/02/21 a las 18:51, Sudip Mukherjee escribió:
> Hi Santiago,
> 
> On Wed, Feb 17, 2021 at 2:30 PM Santiago Ruano Rincón
>  wrote:
> >
> > Package: offlineimap3
> > Version: 0.0~git20210105.00d395b+dfsg-3
> > Severity: normal
> > Tags: upstream
> >
> > Dear Sudip,
> >
> > offlineimap3 is not able to handle the folderincludes config, that
> > worked with offlineimap. I got this when trying to sync (tested with two
> > different accounts):
> >
> >   'str' object has no attribute 'decode'
> 
> Can you please test with the PR at
> https://github.com/OfflineIMAP/offlineimap3/pull/47/ and check if it
> fixes your issue..
> I could reproduce the problem in my setup and the above PR fixes the
> problem for me. I have not tested enough to know if it breaks
> something else.

It seems to work, thanks!

 -- Santiago


signature.asc
Description: PGP signature

Bug#983047: linux-image-5.10.0-3-amd64: Virtualbox Shared Folder vboxsf in 5.10 is racy / unusable with git clone

[Ludovic Pouzenc]

Package: src:linux
Version: 5.10.13-1
Severity: normal

Dear Maintainer,

The current kernel in testing has vboxsf properly integrated and signed.
With Buster, we should use VirtualBoxGuestAdditions.iso to dkms it.
It implies linux-headers, dkms, toolchain... 300 or 400 Mio of stuff.

The integrated vboxsf is way easy to use but it currently fails for "git
clone" like work loads. Steps to reproduce :
 * install debian testing in a virtualbox VM, everything as default
 * configure a shared folder in virtualbox
 * mount in from debian VM somewhere
 * from VM, go into this folder, then :
 * git clone https://a-random-non-empty-public-git-repo.git
 * it fails at unpacking stage.

If host is Windows, there is 2 problems (spurious EINTR, and "File Already 
exists").
If host is Linux, there is 1 problem (a third one : spurious EPERM)

It's reported, patches are written by one of the person who a have took
the initiative about mainline it, I use it since some weeks locally.

https://bugzilla.kernel.org/show_bug.cgi?id=211171
Hans de Goede has submited patches to fs and char-misc teams.

On 2021-02-18 only 1/5 patches are on linux-next. Kernel fs team seems
not have pickup the 4 remaining patches yet.

I don't know if it doable to get them for buster, but it should help
everyone who tries to use this feature.

Here we use it as a way to give local development env to web developers.

Please found the patches has Hans mailed me, they should appears in
linux-next soon.


-- Package-specific info:
** Version:
Linux version 5.10.0-3-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.1) #1 SMP 
Debian 5.10.13-1 (2021-02-06)

** Not tainted
>From 684a3a9a4570991863398e65840d94ec454eb6ad Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Thu, 21 Jan 2021 10:08:59 +0100
Subject: [PATCH v4 1/4] vboxsf: Honor excl flag to the dir-inode create op

Honor the excl flag to the dir-inode create op, instead of behaving
as if it is always set.

Note the old behavior still worked most of the time since a non-exclusive
open only calls the create op, if there is a race and the file is created
between the dentry lookup and the calling of the create call.

While at it change the type of the is_dir parameter to the
vboxsf_dir_create() helper from an int to a bool, to be consistent with
the use of bool for the excl parameter.

Fixes: 0fd169576648 ("fs: Add VirtualBox guest shared folder (vboxsf) support")
Signed-off-by: Hans de Goede 
---
 fs/vboxsf/dir.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/fs/vboxsf/dir.c b/fs/vboxsf/dir.c
index 4d569f14a8d8..c3e68ad6c0f4 100644
--- a/fs/vboxsf/dir.c
+++ b/fs/vboxsf/dir.c
@@ -253,7 +253,7 @@ static int vboxsf_dir_instantiate(struct inode *parent, 
struct dentry *dentry,
 }
 
 static int vboxsf_dir_create(struct inode *parent, struct dentry *dentry,
-umode_t mode, int is_dir)
+umode_t mode, bool is_dir, bool excl)
 {
struct vboxsf_inode *sf_parent_i = VBOXSF_I(parent);
struct vboxsf_sbi *sbi = VBOXSF_SBI(parent->i_sb);
@@ -261,10 +261,12 @@ static int vboxsf_dir_create(struct inode *parent, struct 
dentry *dentry,
int err;
 
params.handle = SHFL_HANDLE_NIL;
-   params.create_flags = SHFL_CF_ACT_CREATE_IF_NEW |
- SHFL_CF_ACT_FAIL_IF_EXISTS |
- SHFL_CF_ACCESS_READWRITE |
- (is_dir ? SHFL_CF_DIRECTORY : 0);
+   params.create_flags = SHFL_CF_ACT_CREATE_IF_NEW | 
SHFL_CF_ACCESS_READWRITE;
+   if (is_dir)
+   params.create_flags |= SHFL_CF_DIRECTORY;
+   if (excl)
+   params.create_flags |= SHFL_CF_ACT_FAIL_IF_EXISTS;
+
params.info.attr.mode = (mode & 0777) |
(is_dir ? SHFL_TYPE_DIRECTORY : SHFL_TYPE_FILE);
params.info.attr.additional = SHFLFSOBJATTRADD_NOTHING;
@@ -291,13 +293,13 @@ static int vboxsf_dir_create(struct inode *parent, struct 
dentry *dentry,
 static int vboxsf_dir_mkfile(struct inode *parent, struct dentry *dentry,
 umode_t mode, bool excl)
 {
-   return vboxsf_dir_create(parent, dentry, mode, 0);
+   return vboxsf_dir_create(parent, dentry, mode, false, excl);
 }
 
 static int vboxsf_dir_mkdir(struct inode *parent, struct dentry *dentry,
umode_t mode)
 {
-   return vboxsf_dir_create(parent, dentry, mode, 1);
+   return vboxsf_dir_create(parent, dentry, mode, true, true);
 }
 
 static int vboxsf_dir_unlink(struct inode *parent, struct dentry *dentry)
-- 
2.28.0

>From 315010a5a43a468ea2d5a5d1fdec48c01ecffadd Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Thu, 21 Jan 2021 10:22:27 +0100
Subject: [PATCH v4 2/4] vboxsf: Make vboxsf_dir_create() return the handle for
 the created file

Make vboxsf_dir_create() optionally return the vboxsf-handle for

Bug#982974: FTBFS: fails to compile translation files

[tony mancill]

On Wed, Feb 17, 2021 at 09:38:16PM +0530, Ritesh Raj Sarraf wrote:
> Source: swt4-gtk
> Version: 4.17.0-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)

Hi Ritesh,

It seems that a local sbuild in a clean chroot doesn't set the
environment the same way that reproducible-builds.org does, as 4.17.0-1
builds correctly in that environment.  But that's a separate concern.

I just wanted to comment that the reproducible-builds.org build for
4.18.0-2 is successful, and that is the version we would like to get
into bullseye.  It is currently blocked by #979609 [1].

Cheers,
tony

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979609

Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs

[Jonas Smedegaard]

Quoting Nicolas Boulenguez (2021-02-18 14:48:20)
> > > Feel free to add pristine-tar, but I am avoiding its complexity 
> > > now that other tools are converging towards reproducibility by 
> > > default.
> 
> > Please consider document your workflow in debian/README.Source - 
> > preferably only a short sentence which referenced a URL to some 
> > shared place e.g. at https://wiki.debian.org/ more elaborately 
> > covering the chosen workflow, to encourage reuse.
> 
> People that *do* expose preferences for non-standard tools like 
> pristine-tar should document their choice.  I try to avoid unneeded 
> steps for new contributors.

Thanks for considering.


 - 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#983025: libqt5widgets5: Segfault with QGLWidget class. Fixed Upstream

[Alejandro Lorenzo]

Package: libqt5widgets5
Version: 5.15.2+dfsg-4
Severity: critical
Tags: upstream newcomer
Justification: breaks unrelated software

Dear Maintainer,

Recently i found a bug in QGLWidget (one of the widgets included in
libqt5widgets5) that
creates a segfault. This bug was accepted as upstream bug 86582

(https://bugreports.qt.io/browse/QTBUG-86582)

It was confirmed and fixed by the Qt people, unfortunately, it has been
committed to the
5.15 LTS branch of their development which is no longer accessible to the
OpenSource licensees

QGLWidget has been a deprecated Widget for some time now, and many software
changed to
QOpenGLWidget alternative, which does not exhibit this problem, but other
pieces of the debian
system (e.g. libqtgstreamer; also deprecated but still in debian repos)  uses
it.

In the issue tracker of the Qt project the likely cause of the bug is
commented, but the actual
fix is not detailed (or i do not know how to access it)

Anyways, i want to put this here to kee everyone informed about this.



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

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

Versions of packages libqt5widgets5 depends on:
ii  libc6 2.31-9
ii  libgcc-s1 10.2.1-6
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-4
ii  libqt5gui55.15.2+dfsg-4
ii  libstdc++610.2.1-6

libqt5widgets5 recommends no packages.

libqt5widgets5 suggests no packages.

Bug#981009: Charybdis abandoned upstream, do not ship in bullseye

[Antoine Beaupré]

On 2021-02-18 02:32:10, Sadie Powell wrote:
> Charybdis' development was terminated due to (among other reasons) threats by 
> a former maintainer. It probably won't be revived.
>
> It's successor is probably Solanum (https://github.com/solanum-ircd/solanum) 
> which is a fork that is led by freenode and OFTC people some of whom were 
> contributors to Charybdis. It might be a good idea to package that instead 
> when it gets a release?

I believe my co-maintainer here is working on this, actually. No WNPP
bug, as far as I know, but as you say, without an upstream release it
might not be worth it just yet.

But yes, it's pretty much the replacement for charybdis, but do note
that it's not a drop-in replacement.

A.

-- 
We will create a civilization of the Mind in Cyberspace. May it be more
humane and fair than the world your governments have made before.
- John Perry Barlow, 1996
A Declaration of Independence of Cyberspace

Bug#982671: Supporting unbound in stretch by upgrading to 1.9

[Markus Koschany]

Am Donnerstag, den 18.02.2021, 11:40 +0200 schrieb Andrei POPESCU:
[...]
> Hello,
> 
> This appears to be the case. A side effect of this is that unless dealt 
> with manually these bugs will just linger in the BTS.
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=
> 
> Please either close or reassign them to a package known to the BTS.
> 
> Kind regards,
> Andrei

Hello,

the bug report is correctly assigned now, see

https://tracker.debian.org/pkg/unbound1.9

but the BTS is unable to fetch the maintainer address automatically. Minor
issue in my opinion.

Regards,

Markus


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

Bug#983046: kjs: please make the opcodes.h file reproducible

[Chris Lamb]

Source: kjs
Version: 5.78.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
kjs could not be built reproducibly.

This is, in part, because it generates an opcodes.h file that embeds the
full path to its original filename which naturally varies on the original
build directory.

Patch attached that applies the equivalent of basename(3) to these values;
kjs doesn't use boost so I cannot use boost::filesystem, nor does it use
c++17 (?) so I cannot use std::filesystem::path either, alas.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/reproducible_build 2021-02-18 14:52:49.165246604 +
@@ -0,0 +1,49 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-02-18
+
+--- kjs-5.78.0.orig/src/kjs/bytecode/generator/filetemplate.h
 kjs-5.78.0/src/kjs/bytecode/generator/filetemplate.h
+@@ -46,6 +46,7 @@ struct FileTemplate {
+ {
+ isOK  = true;
+ lines = 0;
++  inFileBaseName = inFileName.substr(inFileName.find_last_of("/") + 1);
+ 
+ in.open(inFileName.c_str());
+ if (in.fail()) {
+@@ -60,7 +61,7 @@ struct FileTemplate {
+ }
+ 
+ if (isOK) {
+-out << "// WARNING: Portions of this file are autogenerated from 
codes.def and " << inFileName << ".\n";
++out << "// WARNING: Portions of this file are autogenerated from 
codes.def and " << inFileBaseName << ".\n";
+ out << "// (which is what the licensing terms apply to)\n";
+ out << "// Any changes you make here may be lost!\n";
+ handleUntilGenerate();
+@@ -77,7 +78,7 @@ struct FileTemplate {
+ // Goes until @generate..
+ void handleUntilGenerate()
+ {
+-out << "#line " << (lines + 1) << " \"" << inFileName << "\"\n";
++out << "#line " << (lines + 1) << " \"" << inFileBaseName << "\"\n";
+ while (!in.eof()) {
+ string line;
+ getline(in, line);
+@@ -92,7 +93,7 @@ struct FileTemplate {
+ 
+ void handleSuffix()
+ {
+-out << "#line " << (lines + 1) << " \"" << inFileName << "\"\n";
++out << "#line " << (lines + 1) << " \"" << inFileBaseName << "\"\n";
+ while (!in.eof()) {
+ string line;
+ getline(in, line);
+@@ -101,6 +102,7 @@ struct FileTemplate {
+ }
+ 
+ string   inFileName;
++string   inFileBaseName;
+ string   outFileName;
+ ifstream in;
+ ofstream out;
--- a/debian/patches/series 2021-02-18 12:56:03.551163060 +
--- b/debian/patches/series 2021-02-18 13:00:06.669560158 +
@@ -1 +1,2 @@
 install_missing_headers
+reproducible_build

Bug#983045: swupdate: cross build deps

[Bastian Germann]

Source: swupdate
Severity: wishlist
Tags: patch

Some build dependencies that are not bound to the target architecture 
and do not specify Multi-Arch "foreign" cannot be resolved automatically 
for cross builds: https://bootstrap.debian.net/cross_all/swupdate.html.


A patch is enclosed that marks them :native or replaces them with their 
virtual counterpart.
From: Bastian Germann 
Date: Thu, 18 Feb 2021 15:39:43 +0100
Subject: arch-independent build deps: Use virtual or :native

Some packages that are not bound to the target architecture and do not
specify Multi-Arch "foreign" cannot be automatically resolved for cross
builds. Mark them :native or replace them with their virtual counterpart.

Signed-off-by: Bastian Germann 
---
 debian/control | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index f373aaf..a6f4e48 100644
--- a/debian/control
+++ b/debian/control
@@ -5,10 +5,10 @@ Maintainer: Stefano Babic 
 Uploaders: SZ Lin (林上智) ,
Nobuhiro Iwamatsu 
 Build-Depends: debhelper-compat (= 13),
-   dh-lua ,
+   dh-lua:native ,
liblua5.2-dev ,
libfdisk-dev,
-   latexmk ,
+   latexmk:native ,
libconfig-dev,
libcurl4-openssl-dev,
libarchive-dev,
@@ -28,7 +28,7 @@ Build-Depends: debhelper-compat (= 13),
libcmocka-dev,
pkg-config,
gawk,
-   python3-sphinx ,
+   sphinx ,
texlive-latex-recommended ,
texlive-fonts-recommended ,
texlive-formats-extra 

Bug#885195: [Pkg-electronics-devel] Bug#885195: guile-2.0 removed

[Kai-Martin Knaak]

Joerg Jaspert  schrieb am 13. February 2021:

> i just removed guile-2.0 from unstable.
> While your package already won't be part of the next release, it will 
> now also be unusable in unstable.
> 
> Please either upload a fixed version

A fixed version sits at debian mentors looking for a sponsor.
https://mentors.debian.net/package/geda-gaf/

First upload to debian mentors was last week (Tuesday 9th). I reploaded
to amend changes that make lintian complain less and respond to remarks
by reviewers.

All the best,

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882


pgp5DT0e2autd.pgp
Description: OpenPGP digital signature

Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon

[Pino Toscano]

In data giovedì 18 febbraio 2021 15:20:53 CET, Горбешко Богдан ha scritto:
> I had checked the upstream repository before reporting this issue 
> (that's where I got the filename), it still contains this version of the 
> icon. Reporting here, because I couldn't find an issue tracker on KDE 
> GitLab.

https://bugs.kde.org is the KDE upstream bug tracking system. Please
report it there, rather than on a downstream bug tracking system.

-- 
Pino Toscano

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

Bug#982381: AttributeError: lowlevel due to trio usage in s3ql/block_cache.py

[Francesco P. Lovergine]

On Sun, Feb 14, 2021 at 01:38:58PM +1100, Lorentz Kim wrote:

Hi,

I don't know if it'll help much, but I've also gotten this bug and
have resolved it by manually upgrading python3-trio with pip to its
latest version, overriding system's installed version (which is 0.13
last I checked).

pip install trio==0.18.0

Pretty sure the s3ql release notes for 3.7 suggests anything after
trio 0.9 is supported, but perhaps there's a bug in there somewhere?

Regards,
Lorentz


I'm pretty sure this release should depend on >= 0.15,
even due to #981906. Unfortunately, it is not expressed in the package, so yes
it is an upstream issue apparently.

--
Francesco P. Lovergine

Bug#982833: man2html,man2html-base,manpages-it: manpage conflicts: man2html.1, hman.1

[Andreas Beckmann]

Followup-For: Bug #982833
Control: found -1 4.9.1-5

Hi,

the conflicting manpages are still present in manpages-it 4.9.1-5:

/usr/share/man/it/man1/hman.1.gz
/usr/share/man/it/man1/man2html.1.gz


Andreas

Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon

[Горбешко Богдан]

On 18.02.2021 15:53, Pino Toscano wrote:

Hi Bohdan,

In data giovedì 18 febbraio 2021 14:40:52 CET, Bohdan Horbeshko ha scritto:

Package: kdeconnect
Version: 20.04.3-1
Severity: wishlist

Dear Maintainer,

the current icon looks very similar to a broken image icon. I thought it
was broken for several months, until I squinted and found out that × is
actually K. Though when I glance over it, I still subconciously percieve
it as a broken image icon. Please redesign it to something more contrast
and distinct; the light version of the icon does not have this issue.

Please note that we do not do upstream development, and this kind of
change (i.e. artwork) ought to be done by upstream, either in kdeconnect
itself or in the breeze icon theme.

Please note also:


Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kdeconnect depends on:
ii  kde-cli-tools 4:5.17.5-2
ii  kio   5.70.1-1
ii  libc6 2.31-3
ii  libfakekey0   0.3+git20170516-2
ii  libkf5configcore5 5.70.0-1

kernel 5.8.0, Frameworks 5.70, Plasma 5.17, and kdeconnect 20.04:
your system is ~6 month behind of the current Debian testing.
Please fully dist-update your system when reporting bugs for
unstable or testing, as otherwise there is the risk of reporting
stale issues.

I had checked the upstream repository before reporting this issue 
(that's where I got the filename), it still contains this version of the 
icon. Reporting here, because I couldn't find an issue tracker on KDE 
GitLab.

Bug#983040: [Debichem-devel] Bug#983040: Bug#983040: rdkit: doesn't ship with inchi support enabled

[Alex Mestiashvili]

On 2/18/21 2:58 PM, Michael Banck wrote:

tags 983040 +wontfix
merge 983040 964773
thanks

On Thu, Feb 18, 2021 at 03:35:21PM +0200, Andrius Merkys wrote:

On 2021-02-18 15:27, Michael Banck wrote:

On Thu, Feb 18, 2021 at 02:48:49PM +0900, Francois Berenger wrote:

---
python3
import rdkit
from rdkit import Chem
rdkit.Chem.INCHI_AVAILABLE
# False
---

It would be nice if INCHI support is enabled
when building rdkit for Debian.

If you point me to the bugtracker where I should report
this (not found after 10min of searching...), I might report it there.


This has already been reported as [#964773]. In short, rdkit cannot be
built with INCHI support in Debian due to DFSG reasons (please see the
original bug report for explanation).

[#964773] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964773


Thanks Andrius for the pointer. By the way, I've looked at the INCHI
licenes again, and clause 3 allows to use the INCHI code under the GPL,
was it considered to just go that route in Debian or is there some other
loophole I don't see?

Maybe RDKit could be changed in some way to build against both INCHI
versions, but if that is possible at all, it sounds like a major
project.

Francois, what might help here is opening an issue with RDKit's GitHub
issue tracker and asking them about supporting both versions.


Michael

___
Debichem-devel mailing list
debichem-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debichem-devel



An ideal case would be to convince the inchi upstream to change the 
license to a more permissive one (may be it is enough to change the 
wording only).
Just for reference, here is the thread about inchi licensing, but no 
consensus so far:


 https://lists.debian.org/debian-legal/2018/02/msg00026.html

Alex

Bug#981597: plasma-desktop: Same problem on a system set up with stretch

[Johannes Ranke]

I dug up my upgrade transcript, and it shows, after the first apt-upgrade

$ apt full-upgrade

Some packages could not be installed...
...

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 libc6-dev : Beschädigt: libgcc-8-dev (< 8.4.0-2~) aber 8.3.0-6 soll 
installiert werden

...

i.e. the installation candidate for libc6-dev had a "Breaks" on libgcc-8-dev 
(< 8.4.0-2~) but 8.3.0-6 was to be installed.

I just checked and libgcc-8-dev is only present in buster (8.3.0-6), but not 
in bullseye.

I then "solved" it by removing libgcc8-dev which removed almost all of KDE 
which I then reinstalled without problems.

Normally (in my pbuilder chroot with less packages installed) apt full-upgrade 
will remove libgcc-8-dev.

It seems some package on my system still wanted libgcc-8-dev. I assume it was 
just a temporary problem, maybe caused by an incomplete migration of packages 
to testing. From my part, the bug can be closed.

Johannes

Bug#983044: Please update to ssh-import-id 5.11

[Robie Basak]

Source: ssh-import-id
Version: 5.10-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

I just uploaded ssh-import-id 5.11 to Ubuntu. I think it's suitable for
upload to Debian also. You can grab it from:

dget 
https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/ssh-import-id/5.11-0ubuntu1/ssh-import-id_5.11-0ubuntu1.dsc

I expect this will need to wait until bookworm though.

Robie


signature.asc
Description: PGP signature