Bug#974922: libapache2-mod-perl2: "mod_perl interferes with mod_php locales, unable to use gettext translations"

[Damyan Ivanov]

Hi Claudio,
-=| Claudio Kuenzler, 16.11.2020 15:26:45 +0100 |=-
>   When using mod_perl and mod_php at the same time, mod_perl somehow 
>   interferes with PHPs ability to translate texts using gettext.
>   The PHP translation works fine using CLI but not via Apache web server.
>   
>   $ curl localhost/translate.php
>   My original English text (not translated)
> 
>   As soon as mod_perl is disabled, the translations work:
> 
>   # a2dismod perl
>   # systemctl restart apache2
> 
>   $ curl localhost/translate.php
>   Mein deutscher Text (translated)
> 
>  This happened on Debian 10. Language in the PHP script was set to 
>  de_CH.UTF-8. mod_php is 7.3.19.

It would be nice if you could share the translate.php contents (or 
a minimal version) so that the issue can be reproduced and any 
prospective fixes/workarounds be tested.


-- Damyan

Bug#975012: dplfin: FTBFS: 69% tests passed, 15 tests failed out of 49

[Anton Gladky]

Hi Sebastian,

Thanks for your bug report. I am preparing a transition to boost 1.74
and tested my minimal changes to fix #974948. It worked locally.

Anyway I have reverted the fix for #974948 and it did not help. So the reason
is somewhere else. Sorry for the inconvenience.

Best regards

Anton

Am Di., 17. Nov. 2020 um 22:39 Uhr schrieb Sebastian Ramacher
:
>
> Source: dolfin
> Version: 2019.2.0~git20200629.946dbd3-6
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org

Bug#975029: transition: notcurses

[Nick Black]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: dankamong...@gmail.com, pk...@debian.org

I am the upstream author and Debian Maintainer of notcurses. The 2.0.0 release
included an soname bump to 2, though there were actually no ABI changes in this
release. Rather, the soname bump was to indicate that Notcurses was finally
shipping a stable API, as it had changed pretty wildly during 1.x development.
Notcurses will commit to backwards compatibility through the 2.x cycle.

As I am only a DM (as opposed to a full DD), I couldn't upload to experimental
myself. Due to some communication breakdowns, Debian had an out-of-date
notcurses for more time than I was comfortable with; eventually (shortly after
the 2.0.4 release), I added a patch to fix the soname at 1, and successfully
uploaded notcurses-2.0.4+dfsg.1-1 to unstable.

Philipp Kern was then kind enough to step in and sponsor the libnotcurses2
upload, which is now in experimental as 2.0.4+dfsg.1-3. Any reverse dep running
successfully with libnotcurses1 2.0.4+dfsg.1-1 ought work exactly the same when
rebuilt against libnotcurses2 2.0.4+dfsg.1-3 (without changes).

There are only two reverse-deps:

 * growlight 1.2.19, which I maintain
 * snd 20.8-2, maintained by the Debian Multimedia Team. I've contacted them to
let them know about the upcoming transition. I expect no problems with the
package.

A transition tracker entry has been automatically created at
https://release.debian.org/transitions/html/auto-notcurses.html.

Ben file:

title = "notcurses";
is_affected = .depends ~ "libnotcurses1" | .depends ~ "libnotcurses++1" |
.depends ~ "libnotcurses2" | .depends ~ "libnotcurses++2";
is_good = .depends ~ "libnotcurses2" | .depends ~ "libnotcurses++2";
is_bad = .depends ~ "libnotcurses1" | .depends ~ "libnotcurses++1";



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.8nlb (SMP w/64 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 /bin/dash
Init: systemd (via /run/systemd/system)

Bug#975028: ebtables -E (rename) gives error

[Christian Ehrhardt]

Package: iptables
Version: 1.8.6-1

Hi,
I found an issue in iptables as it is in Debian (and recent Ubuntu
releases) [1].
After debugging it turned out to be a real issue [2] confirmed by upstream.
As a symptom I have libvirt that fails to apply netfilter rules, but I
assume many
more use cases could be broken by it.

In the meantime there is a fix [3] for it available.
I asked if they'd release a new version soon so that you'd pick it up
automatically,
but it sees not [4] to be the case.

Therefore I wanted to file this bug for your awareness and help to
identify and pick up this fix soon'ish.

[1]: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1904192
[2]: https://bugzilla.netfilter.org/show_bug.cgi?id=1481#add_comment
[3]: 
http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247
[4]: https://bugzilla.netfilter.org/show_bug.cgi?id=1481#c3

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#975027: RFS: gnustep-icons/1.0-9 [RC] -- Several free icons for use with GNUstep and others

[Gürkan Myczko]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "gnustep-icons":

 * Package name: gnustep-icons
   Version : 1.0-9
   Upstream Author : Andrew Lindesay ,
http://www.lindesay.co.nz/ (Original)
 * URL : https://github.com/alexmyczko/gnustep-icons
 * License : LGPL-2.1+
 * Vcs : https://salsa.debian.org/gnustep-team/gnustep-icons
   Section : gnustep

It builds those binary packages:

  gnustep-icons - Several free icons for use with GNUstep and others

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

  https://mentors.debian.net/package/gnustep-icons/

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

  dget -x
https://mentors.debian.net/debian/pool/main/g/gnustep-icons/gnustep-icons_1.0-9.dsc

Changes since the last upload:

 gnustep-icons (1.0-9) unstable; urgency=medium
 .
   * Fix Maintainer address. (Closes: #973871).

Regards,
--
  Gürkan Myczko

Bug#974605: zeromq3 should build-depend on libbsd-dev

[GCS]

Control: tags -1 +moreinfo

On Thu, Nov 12, 2020 at 9:45 PM Adrian Bunk  wrote:
> https://github.com/zeromq/libzmq/releases/tag/v4.3.3
>
> Note for packagers: an internal reimplementation of strlcpy is now included,
> for wider platform compatibility.
> libbsd can be used and is enabled by default if available instead of the
> internal implementation, for better security maintenance in distros.
 Please note why strlcpy() is missing from glibc [1] in the first
place and "were rejected for inclusion in the POSIX.1-2008 standard".
It also contains: "note that "gcc -D_FORTIFY_SOURCE" can catch many of
the errors that strlcpy() and strlcat() were designed to catch".
Adding a new runtime library dependency for a function that was
otherwise rejected from the POSIX standard makes me curious.
Luca, what's your point of view? Is it really worth it to have a
libbsd dependency over the ZeroMQ3 own function implementation and
when the compiler (due to -D_FORTIFY_SOURCE) itself should catch most
possible problems?

Thanks,
Laszlo/GCS
[1] https://lwn.net/Articles/507319/

Bug#974601: neomutt: new upstream version (latest release is 20200925)

[Antonio Radici]

On Thu, Nov 12, 2020 at 12:07:01PM -0800, Benjamin Mako Hill wrote:
> Package: neomutt
> Version: 20200626+dfsg.1-1
> Severity: wishlist
> 
> Greetings!
> 
> Thank you for maintaining neomutt! There was a new release of neomutt in late
> September that I suppose should be uploaded into Debian. It's available here
> and fixes a number of bugs:
> 
> https://github.com/neomutt/neomutt/releases/tag/20200925
> 
> Some of the debian patches don't apply cleanly because the maintainers have
> moved some of the documentation out from mutt_config.c over to docs/config.c
> but the code itself seems to have been copied. I've made a working version of
> the package (downloadable with dget) which is online here:
> 
> https://mako.cc/outgoing/neomutt-20200925-1~mako/neomutt_20200925-1~mako.dsc
> https://mako.cc/outgoing/neomutt-20200925-1~mako/
> 
> I haven't done (or even looked into) the DFSG issues so I suppose those still
> need to happen. I figured I'd share my work since it might be useful to you or
> others. If it's not, feel free to ignore!
> 
> Regards,
> Mako

Thanks for your bug, I will look into packaging this version this weekend.

Bug#975001: ITS: python-maxminddb

[Faidon Liambotis]

Hi,

On Tue, Nov 17, 2020 at 08:53:40PM +0100, Ondřej Nový wrote:
> This package FTBFS (see: #959544) and there is no visible activity regarding
> this package for more than year. This bug is blocking migration
> of my package python-geoip2.
> 
> I want to salvage this package, move it under Debian Python Team umbrella
> and if you want keep you as uploader.

Thank you so much for caring & offering, and apologies for leaving this
bitrot and the hardship that this is causing you with regards to
the python-geoip2 migration :( 2020 has been... an interesting year.

python-maxminddb (and other parts of its ecosystem, like libmaxminddb &
geoipupdate) are under the "Debian" salsa group (ex-collab-maint). As a
Debian developer, you should have access to contribute already, with no
expectations for no-precommit coordination with myself required :)

Would you mind starting there? Besides commits, feel free to also make
archive uploads, as well to add yourself to Uploaders :) I'd like to
stay involved for the time being; we can revisit if my absence from
packaging extends into 2021. Also more than happy to work together,
idea/code review or answer questions etc.

Best,
Faidon

Bug#975026: Use 公元 not 西元

[Florian Weimer]

* 積丹尼 Dan Jacobson:

> I think this,
> $ LC_TIME=zh_TW.UTF-8 date
> 西元2020年11月18日 (週三) 12時39分44秒 CST
> should say 公元 not 西元.

Why do you think so?  These Taiwanese newspapers appear to use 西元
for Gregorian years:

  
  

Is there a difference between calendar dates and historical
references?

Bug#973604: lintian reports spare-manual-page on PAM and NSS modules

[Russ Allbery]

nicoo  writes:

> - libpam-afs-session: /usr/share/man/man5/pam_afs_session.5.gz
>   libpam-heimdal: /usr/share/man/man5/pam_krb5.5.gz
>   libpam-krb5: /usr/share/man/man5/pam_krb5.5.gz
>   libpam-ldap: /usr/share/man/man5/pam_ldap.5.gz
>   Indeed PAM modules

The first three are all mine, so don't represent three independent
decisions.  I don't remember my thought process at the time (it was about
15 years ago now).  Maybe my thought was that most of what the man page
for a PAM module documents is what should go into the PAM configuration
files for invoking the module, and thus it's effectively configuration
file documentation?

Linux PAM itself documents all of its modules in section 8, so that's a
reasonable precedent to follow, although it looks like everyone, like me,
made their own decisions.  None of the sections fit all that naturally
(which would explain the folks who picked 7).

-- 
Russ Allbery (r...@debian.org)  

Bug#973038: autopkgtest-build-qemu support for ppc64el, arm64, armel, i386 UEFI

[Ryutaroh Matsumoto]

From: Simon McVittie 
Subject: Re: autopkgtest-build-qemu support for ppc64el, arm64, armel, i386 UEFI
Date: Sun, 15 Nov 2020 18:49:36 +
> * As we get new architecture support in OVMF and vmdb2, we can consider
>   setting up those architectures in autopkgtest-build-qemu.

I have done it at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973467#42
as a patch against the latest upstream git source of vmdb2.
It adds support of UEFI amd64, i386, x32, arm64, armhf, and armel to vmdb2.

After submitting that patch, I noticed another patch was already given at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973467#37
for arm64.

Ryutaroh

Bug#974924: Plasma 5.19.5.x: Emojis in black and white ( not color and not displayed correctly)

[Norbert Preining]

Hi Héctor,

I suggest closing this bug, since it is a configuration issue:

On Mon, 16 Nov 2020, Héctor Sales Llamas wrote:
> When I press the combination keys "Meta + ." (Plasma 5.19.5.x) the emoji
> selector is launched and these are shown in black and white and many of them
> are not displayed correctly. I have installed the package: "fonts-noto-color-
> emoji" and "fonts-noto-*"

Please show the output of
fc-match --verbose emoji
because "emoji" is the font requested.

I guess you have some other emoji font installed with a higher priority,
and that font only carries BW emojis. Another option is to de-install
the conflicting font, which you have found via the fc-match call.

The below code is for fonts.conf is crude and should NOT be used because it 
changes
serif to Noto sans, which is somehow ... well ...broken.

Better solution is given on this page:
https://wiki.archlinux.org/index.php/font_configuration
Quoting from there
***
Force emoji font
Some software may lacks proper Emoji font fallback support.

To force emoji presentation create emoji font fallback preset for your
application, to enable see #Presets. Replace application and Noto Color
Emoji with your application and preferred emoji font respectively:

/etc/fonts/conf.avail/55-emoji-prepend.conf




  

  application


  Noto Color Emoji

  

*


Hope that helps.

Best

Norbert

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

Bug#948909: cp2k: test failure on armhf and i386 with libint2

[Graham Inggs]

Control: severity -1 important

Downgrading severity since the autopkgtests are now passing [1][2] and
no longer blocking migration.


[1] https://ci.debian.net/packages/c/cp2k/testing/armhf/
[2] https://ci.debian.net/packages/c/cp2k/testing/i386/

Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64

[Ryutaroh Matsumoto]

Control: tags -1 + patch

Hi Gunnar, in response to your message,

From: Gunnar Wolf 
Subject: Re: Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on 
arm64 and does not work on arm64
Date: Sat, 7 Nov 2020 23:33:01 -0600
> As you said here, the workaround is not a fix, as it would make vmdb2
> produce images unable to boot on amd64 - So I'm removing the "patch"
> tag. I am also adding the tags "confirmed" and "upstream", as the
> comments in the file in question mention:

I made the attached patch against the latest upstream git source
as attached. I also add "patch" tag to this bts.
As far as I tested, the patch seems working well.
I also added bind-mount of /proc and /dev/pts as recent version of
grub seems to use them.

uefi-arm64.vmdb is a test file corresponding to the original uefi.vmdb.

Ryutaroh
--- vmdb-git-20201118/vmdb2/vmdb/plugins/grub_plugin.py-orig2020-11-18 
09:34:51.093900848 +0900
+++ vmdb-git-20201118/vmdb2/vmdb/plugins/grub_plugin.py 2020-11-18 
12:41:30.056459254 +0900
@@ -93,6 +93,7 @@
 "image-dev": "",
 "quiet": False,
 "timeout": 0,
+"arch": "amd64",
 }
 
 def run(self, values, settings, state):
@@ -111,9 +112,23 @@
 if efi is None and efi_part is None:
 raise Exception('"efi" or "efi-part" required in UEFI GRUB 
installation')
 
+arch = values["arch"]
+if arch == "amd64":
+grub_package = "grub-efi-amd64"
+grub_target = "x86_64-efi"
+elif arch == "i386" or arch == "x32":
+grub_package = "grub-efi-ia32"
+grub_target = "i386-efi"
+elif arch == "arm64":
+grub_package = "grub-efi-arm64"
+grub_target = "arm64-efi"
+elif arch == "armhf" or arch == "armel":
+grub_package = "grub-efi-arm"
+grub_target = "arm-efi"
+else:
+raise Exception('Currently unsupported architecture for Grub 
UEFI.')
+
 vmdb.progress("Installing GRUB for UEFI")
-grub_package = "grub-efi-amd64"
-grub_target = "x86_64-efi"
 self.install_grub(values, settings, state, grub_package, grub_target)
 
 def install_bios(self, values, settings, state):
@@ -144,7 +159,7 @@
 
 quiet = values["quiet"]
 
-self.bind_mount_many(chroot, ["/dev", "/sys"], state)
+self.bind_mount_many(chroot, ["/dev", "/sys", "/proc", "/dev/pts"], 
state)
 if efi_dev:
 self.mount(chroot, efi_dev, "/boot/efi", state)
 self.install_package(chroot, grub_package)
--- vmdb-git-20201118/vmdb2/vmdb/plugins/grub.mdwn-orig 2020-11-18 
13:32:55.989389129 +0900
+++ vmdb-git-20201118/vmdb2/vmdb/plugins/grub.mdwn  2020-11-18 
13:36:27.762255325 +0900
@@ -30,6 +30,9 @@
 * `timeout`  OPTIONAL; set the grub menu timeout, in seconds.
   Defaults to 0 seconds.
 
+* `arch`  OPTIONAL; set the target architecture of grub-efi.
+  Defaults to amd64. Currently, amd64, i386, x32, arm64, armhf and armel are 
supported.
+
 Example (in the .vmdb file):
 
 - grub: bios
@@ -41,6 +44,7 @@
   tag: root
   efi: efi
   console: serial
+  arch: i386
 
 Install to a real hard disk (named with the `--image` option):
 
@@ -48,3 +52,4 @@
   tag: root
   efi: efi
   image-dev: "{{ image }}"
+  arch: arm64
--- /dev/null   2020-11-18 12:39:50.085968484 +0900
+++ vmdb-git-20201118/vmdb2/uefi-arm64.vmdb 2020-11-18 13:00:06.591549633 
+0900
@@ -0,0 +1,62 @@
+# This is a sample VMDB2 input file that specifies a simple system for
+# a PC that boots with UEFI.
+
+steps:
+  - mkimg: "{{ output }}"
+size: 4G
+
+  - mklabel: gpt
+device: "{{ output }}"
+
+  - mkpart: primary
+device: "{{ output }}"
+start: 0%
+end: 1G
+tag: efi
+fs-type: 'fat32'
+
+  - mkpart: primary
+device: "{{ output }}"
+start: 1G
+end: 100%
+tag: /
+fs-type: 'ext4'
+
+  - kpartx: "{{ output }}"
+
+  - mkfs: vfat
+partition: efi
+
+  - mkfs: ext4
+partition: /
+
+  - mount: /
+
+
+  - unpack-rootfs: /
+
+  - qemu-debootstrap: bullseye
+mirror: http://deb.debian.org/debian
+arch: arm64
+target: /
+unless: rootfs_unpacked
+
+  - apt: install
+packages:
+  - linux-image-arm64
+fs-tag: /
+unless: rootfs_unpacked
+
+  - cache-rootfs: /
+unless: rootfs_unpacked
+
+  - chroot: /
+shell: |
+  echo uefi-vmdb2 > /etc/hostname
+
+  - fstab: /
+
+  - grub: uefi
+tag: /
+efi: efi
+arch: arm64

Bug#975026: Use 公元 not 西元

[積丹尼 Dan Jacobson]

Package: locales
Version: 2.31-4
Severity: minor

I think this,
$ LC_TIME=zh_TW.UTF-8 date
西元2020年11月18日 (週三) 12時39分44秒 CST
should say 公元 not 西元.
Alas, I do not know where to submit this bug to.

Bug#975025: flex: reproducible builds: example Makefiles contain build paths

[Vagrant Cascadian]

Source: flex
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpaths
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Well, this is a bit of a re-run: Bug#949343: flex: Embeds build paths in
example Makefiles

But in my proposed fix for that version, I neglected to test only
building arch:all packages, which triggered: #961778 flex: binary-all
FTBFS

This time, I'm proposing a much simpler fix; just remove the generated
Makefiles, but only remove them when ... they are actually present!
(e.g. arch:any build vs. arch:all build)

I think this is a better approach than sanitizing the Makefile, since
the Makefile.am is also shipped, and a person who wanted to build the
examples would probably need to regenerate the Makefile anyways.

Patch attached, tested with arch:all only, arch:any only and
arch:all+any builds.


live well,
  vagrant
From 4b9384cc7b73f984507c75f15f293982896135a4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 18 Nov 2020 04:04:02 +
Subject: [PATCH] debian/rules: Remove example autogenerated Makefiles which
 contain build paths.

---
 debian/rules | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/rules b/debian/rules
index d0d5597..31a4c72 100755
--- a/debian/rules
+++ b/debian/rules
@@ -91,6 +91,15 @@ ifneq (,$(filter flex-doc, $(shell dh_listpackages)))
debian/flex-doc/usr/share/doc/flex-doc/
 endif
 
+override_dh_installexamples:
+	dh_installexamples
+	# Remove autogenerated Makefiles which contain embedded build
+	# paths in order to ensure reproducible builds.
+	test ! -f debian/flex/usr/share/doc/flex/examples/fastwc/Makefile || \
+		rm -f debian/flex/usr/share/doc/flex/examples/fastwc/Makefile
+	test ! -f debian/flex/usr/share/doc/flex/examples/manual/Makefile || \
+		rm -f debian/flex/usr/share/doc/flex/examples/manual/Makefile
+
 override_dh_auto_build:
 	dh_auto_build
 ifneq (,$(filter flex-doc, $(shell dh_listpackages)))
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#975024: vmdb2 should depend/recommend qemu-user-static

[Ryutaroh Matsumoto]

Package: vmdb2
Version: 0.19-1
Severity: normal

Dear Maintainer,

qemu-debootstrap in vmdb2 yaml runs /usr/sbin/qemu-debootstrap,
which is included in "qemu-user-static" Debian package.
So vmdb2 should depend/recommend qemu-user-static.

On the other hand, vmdb2 depends on qemu-utils,
which seems unnecessary to me.

Best regards, Ryutaroh Matsumoto

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

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

Versions of packages vmdb2 depends on:
ii  cmdtest 0.32.14.gcdfe14e-1
ii  debootstrap 1.0.123
ii  kpartx  0.8.4-4
ii  parted  3.3-4
ii  python3 3.8.6-1
ii  python3-cliapp  1.20180812.1-4
ii  python3-jinja2  2.11.2-1
ii  python3-yaml5.3.1-3
ii  qemu-utils  1:5.1+dfsg-4+b1

Versions of packages vmdb2 recommends:
ii  ansible  2.9.13+dfsg-1

vmdb2 suggests no packages.

-- no debconf information

Bug#975023: vmdb2: qemu-debootstrap after virtual-filesystems fails

[Ryutaroh Matsumoto]

Package: vmdb2
Version: 0.19-1
Severity: normal

Dear Maintainer,

When I put "qemu-debootstrap" after "virtual-filesystems"
in a vmdb yaml file, vmdb2 fails without meaningful error messages.

I observed this symptom the first attached yaml file on my amd64 laptop.
A log with vmdb2 --log= is attached as the second attachment.

If I delete "virtual-filesystems", everything goes fine.

Best regards, Ryutaroh Matsumoto

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

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

Versions of packages vmdb2 depends on:
ii  cmdtest 0.32.14.gcdfe14e-1
ii  debootstrap 1.0.123
ii  kpartx  0.8.4-4
ii  parted  3.3-4
ii  python3 3.8.6-1
ii  python3-cliapp  1.20180812.1-4
ii  python3-jinja2  2.11.2-1
ii  python3-yaml5.3.1-3
ii  qemu-utils  1:5.1+dfsg-4+b1

Versions of packages vmdb2 recommends:
ii  ansible  2.9.13+dfsg-1

vmdb2 suggests no packages.

-- no debconf information
# This is modified from the sample VMDB2 input file that specifies a simple 
system for
# a PC that boots with UEFI.

steps:
  - mkimg: "{{ output }}"
size: 4G

  - mklabel: gpt
device: "{{ output }}"

  - mkpart: primary
device: "{{ output }}"
start: 0%
end: 1G
tag: efi

  - mkpart: primary
device: "{{ output }}"
start: 1G
end: 100%
tag: /

  - kpartx: "{{ output }}"

  - mkfs: vfat
partition: efi

  - mkfs: ext4
partition: /

  - mount: /

  - virtual-filesystems: /


  - qemu-debootstrap: buster
arch: i386
mirror: http://deb.debian.org/debian
target: /
2020-11-18 12:47:06 INFO vmdb2 version 0.19 starts
2020-11-18 12:47:06 DEBUG sys.argv: ['/bin/vmdb2', '--log=vmdb-qemu-error.txt', 
'-v', '--output=/tmp/test1.img', 'uefi-qemu-with-virtual.vmdb']
2020-11-18 12:47:06 DEBUG current working directory: /root
2020-11-18 12:47:06 DEBUG uid: 0
2020-11-18 12:47:06 DEBUG effective uid: 0
2020-11-18 12:47:06 DEBUG gid: 0
2020-11-18 12:47:06 DEBUG effective gid: 0
2020-11-18 12:47:06 DEBUG environment variables:
2020-11-18 12:47:06 DEBUG environment: SHELL=/bin/bash
2020-11-18 12:47:06 DEBUG environment: 
SESSION_MANAGER=local/bullseye-gnome:@/tmp/.ICE-unix/1843,unix/bullseye-gnome:/tmp/.ICE-unix/1843
2020-11-18 12:47:06 DEBUG environment: QT_ACCESSIBILITY=1
2020-11-18 12:47:06 DEBUG environment: COLORTERM=truecolor
2020-11-18 12:47:06 DEBUG environment: XDG_MENU_PREFIX=gnome-
2020-11-18 12:47:06 DEBUG environment: 
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
2020-11-18 12:47:06 DEBUG environment: LANGUAGE=en_US:en
2020-11-18 12:47:06 DEBUG environment: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
2020-11-18 12:47:06 DEBUG environment: XMODIFIERS=@im=ibus
2020-11-18 12:47:06 DEBUG environment: DESKTOP_SESSION=gnome-xorg
2020-11-18 12:47:06 DEBUG environment: SSH_AGENT_PID=1800
2020-11-18 12:47:06 DEBUG environment: GTK_MODULES=gail:atk-bridge
2020-11-18 12:47:06 DEBUG environment: PWD=/root
2020-11-18 12:47:06 DEBUG environment: XDG_SESSION_DESKTOP=gnome-xorg
2020-11-18 12:47:06 DEBUG environment: LOGNAME=ryutaroh
2020-11-18 12:47:06 DEBUG environment: XDG_SESSION_TYPE=x11
2020-11-18 12:47:06 DEBUG environment: 
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
2020-11-18 12:47:06 DEBUG environment: XAUTHORITY=/run/user/1000/gdm/Xauthority
2020-11-18 12:47:06 DEBUG environment: WINDOWPATH=2
2020-11-18 12:47:06 DEBUG environment: GDM_LANG=en_US.UTF-8
2020-11-18 12:47:06 DEBUG environment: HOME=/root
2020-11-18 12:47:06 DEBUG environment: USERNAME=ryutaroh
2020-11-18 12:47:06 DEBUG environment: IM_CONFIG_PHASE=1
2020-11-18 12:47:06 DEBUG environment: LANG=en_US.UTF-8
2020-11-18 12:47:06 DEBUG environment: 

Bug#973369: linux-image-5.9.0: No network at Banana Pi M3

[Vagrant Cascadian]

On 2020-11-17, Salvatore Bonaccorso wrote:
> On Mon, Nov 09, 2020 at 02:32:21PM +0100, Bernhard wrote:
>> Regarding correction:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts?h=next-20201029=57dbe558457bf4042169bc1f334e3b53a8480a1c
>> 
>> Currently, i had a look at kernel.org:
>> In kernel 5.9.6, the necessary correction is not included.
>> Also in kernel 5.10-RC3, this correction is not included.
>> 
>> Without this correction, the on-board-ethernet of my Banana Pi M3 is not 
>> working.
>> An external attached USB-->LAN interface works.
>> 
>> Do you think, there is a chance to add the very small correction to the 
>> Debian kernel?
>> 
>> Best regards and thank you for your great support.
>
> I have applied the change in
> https://salsa.debian.org/kernel-team/linux/-/commit/0cfcaef8b5e52549952e89cb31cff1530a5efa42
> .
>
> Vagrant, can you double-check please.

I don't think I have any affected hardware to test on, sorry.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#974950: vim-scripts: missing vim-addon-manager registry file

[James McCoy]

On Tue, Nov 17, 2020 at 02:43:55PM -0300, Antonio Terceiro wrote:
> On Mon, Nov 16, 2020 at 07:04:26PM -0500, James McCoy wrote:
> > On Mon, Nov 16, 2020 at 08:41:57PM -0300, Antonio Terceiro wrote:
> > > The new vim-scripts breaks existing usage with vim-addon-manager.
> > > 
> > > It is missing the vim-addon-manager registry file, and moving the files
> > > around breaks existing users.
> > 
> > Please see the NEWS file.  This was changed to not use vim-addon-manager
> > anymore.
> 
> Ah, I missed that. Sorry for the noise. FWIW I would expect such a
> change to also be explicitly mentioned in the changelog.

The general change was, but not the specific details on how to adapt to
the change:

  * Refactor packaging to use dh-vim-addon instead of vim-addon-manager
+ Add Build-Depends on dh-vim-addon
+ Remove vim/vim-addon-manager Recommends.  Replaced by Depends on
  ${vim-addon:Depends}
+ Install each plugin in its own sub-directory of /usr/share/vim-scripts

> Do you think vim-addon-manager should be deprecated and eventually
> removed?

Yes.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#974670: lintian-brush: "Re-export upstream signing key without extra signatures" is not optimal

[Jelmer Vernooij]

tags 974670 +confirmed
thanks

On Fri, Nov 13, 2020 at 04:42:57PM +0100, Xavier Guimard wrote:
> when launching lintian-brush in apache2 source directories, it says that
> upstream signing key were optimized but I still have:
> 
>   public-upstream-key-not-minimal upstream/signing-key.asc has 2 extra 
> signature(s) for keyid 193F180AB55D9977
>   public-upstream-key-not-minimal upstream/signing-key.asc has 283 extra 
> signature(s) for keyid 7D6DBFD1F08E012A
>   public-upstream-key-not-minimal upstream/signing-key.asc has 63 extra 
> signature(s) for keyid 8B3A601F08C975E5

Thanks for the report. I can confirm it here. It's a little bit
surprising since I think we're specifying the right flags
(import-minimal):

  import-minimal
  Import the smallest key possible. This removes all signatures
  except the most recent self-signature on each user ID. This
  option is the same as running the --edit-key command "minimize"
  after import.  Defaults to no.

Jelmer


signature.asc
Description: PGP signature

Bug#805305: tasksel: Please consider adding GNOME Flashback as a desktop choice

[nicoo]

Hi Dmitry,

On Mon, Nov 16, 2015 at 10:44:16PM +0300, Dmitry Shachnev wrote:
> Dear tasksel maintainers,
> 
> I would like you to consider adding the GNOME Flashback desktop to the list of
> supported desktop environments in Debian.

Apologies for the *incredibly late* reply, and thanks for your interest in
contributing to tasksel :)


> I consider that GNOME Flashback is a better choice for the top list as
> compared to i.e. MATE or Cinnamon, as it has a small codebase, is actively
> developed, uses modern GNOME technologies and is familiar for users of
> previous Debian versions.

That sounds like all sorts of really good reasons to include it.
However, if we start ordering the list by popularity or perceived relevance,
I forsee lots to bruised feelings when bumping flashback to the top  ;)

I took the liberty of rebasing your patch (so it applies to the current source
tree), moving flashback to the bottom, and refactoring the 2 GNOME tasks:

  https://salsa.debian.org/installer-team/tasksel/-/merge_requests/14

I'd however appreciate some feedback from the rest of the d-i team,
before merging this.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#973604: lintian reports spare-manual-page on PAM and NSS modules

[nicoo]

On Wed, Nov 18, 2020 at 02:08:21AM +0100, nicoo wrote:
> There are literally 4 PAM modules whose documentation is in section 5,
> 4 more in section 7 (misfiled?) and... 83 modules whose documentation is
> in section 8.  (I'm attaching the list for those as a separate file)

Sorry, forgot the attachment

cifs-utils: /usr/share/man/man8/pam_cifscreds.8.gz
cockpit-ws: /usr/share/man/man8/pam_cockpit_cert.8.gz
cockpit-ws: /usr/share/man/man8/pam_ssh_add.8.gz
ecryptfs-utils: /usr/share/man/man8/pam_ecryptfs.8.gz
gridengine-exec: /usr/share/man/man8/pam_sge-qrsh-setup.8.gz
gridengine-exec: /usr/share/man/man8/pam_sge_authorize.8.gz
libcap2-bin: /usr/share/man/man8/pam_cap.8.gz
libpam-abl: /usr/share/man/man8/pam_abl.8.gz
libpam-alreadyloggedin: /usr/share/man/man8/pam_alreadyloggedin.8.gz
libpam-cracklib: /usr/share/man/man8/pam_cracklib.8.gz
libpam-duo: /usr/share/man/man8/pam_duo.8.gz
libpam-elogind: /usr/share/man/man8/pam_elogind.8.gz
libpam-fprintd: /usr/share/man/man8/pam_fprintd.8.gz
libpam-geoip: /usr/share/man/man8/pam_geoip.8.gz
libpam-google-authenticator: /usr/share/man/man8/pam_google_authenticator.8.gz
libpam-ldapd: /usr/share/man/man8/pam_ldap.8.gz
libpam-modules: /usr/share/man/man8/pam_access.8.gz
libpam-modules: /usr/share/man/man8/pam_debug.8.gz
libpam-modules: /usr/share/man/man8/pam_deny.8.gz
libpam-modules: /usr/share/man/man8/pam_echo.8.gz
libpam-modules: /usr/share/man/man8/pam_exec.8.gz
libpam-modules: /usr/share/man/man8/pam_faildelay.8.gz
libpam-modules: /usr/share/man/man8/pam_filter.8.gz
libpam-modules: /usr/share/man/man8/pam_ftp.8.gz
libpam-modules: /usr/share/man/man8/pam_group.8.gz
libpam-modules: /usr/share/man/man8/pam_issue.8.gz
libpam-modules: /usr/share/man/man8/pam_keyinit.8.gz
libpam-modules: /usr/share/man/man8/pam_lastlog.8.gz
libpam-modules: /usr/share/man/man8/pam_limits.8.gz
libpam-modules: /usr/share/man/man8/pam_listfile.8.gz
libpam-modules: /usr/share/man/man8/pam_localuser.8.gz
libpam-modules: /usr/share/man/man8/pam_loginuid.8.gz
libpam-modules: /usr/share/man/man8/pam_mail.8.gz
libpam-modules: /usr/share/man/man8/pam_mkhomedir.8.gz
libpam-modules: /usr/share/man/man8/pam_motd.8.gz
libpam-modules: /usr/share/man/man8/pam_namespace.8.gz
libpam-modules: /usr/share/man/man8/pam_nologin.8.gz
libpam-modules: /usr/share/man/man8/pam_permit.8.gz
libpam-modules: /usr/share/man/man8/pam_pwhistory.8.gz
libpam-modules: /usr/share/man/man8/pam_rhosts.8.gz
libpam-modules: /usr/share/man/man8/pam_rootok.8.gz
libpam-modules: /usr/share/man/man8/pam_securetty.8.gz
libpam-modules: /usr/share/man/man8/pam_sepermit.8.gz
libpam-modules: /usr/share/man/man8/pam_shells.8.gz
libpam-modules: /usr/share/man/man8/pam_succeed_if.8.gz
libpam-modules: /usr/share/man/man8/pam_tally.8.gz
libpam-modules: /usr/share/man/man8/pam_tally2.8.gz
libpam-modules: /usr/share/man/man8/pam_time.8.gz
libpam-modules: /usr/share/man/man8/pam_timestamp.8.gz
libpam-modules: /usr/share/man/man8/pam_tty_audit.8.gz
libpam-modules: /usr/share/man/man8/pam_umask.8.gz
libpam-modules: /usr/share/man/man8/pam_unix.8.gz
libpam-modules: /usr/share/man/man8/pam_userdb.8.gz
libpam-modules: /usr/share/man/man8/pam_warn.8.gz
libpam-modules: /usr/share/man/man8/pam_wheel.8.gz
libpam-modules: /usr/share/man/man8/pam_xauth.8.gz
libpam-modules-bin: /usr/share/man/man8/pam_timestamp_check.8.gz
libpam-mount: /usr/share/man/man8/pam_mount.8.gz
libpam-net: /usr/share/man/man8/pam_newnet.8.gz
libpam-net: /usr/share/man/man8/pam_usernet.8.gz
libpam-otpw: /usr/share/man/man8/pam_otpw.8.gz
libpam-passwdqc: /usr/share/man/man8/pam_passwdqc.8.gz
libpam-pkcs11: /usr/share/man/man8/pam_pkcs11.8.gz
libpam-pwquality: /usr/share/man/man8/pam_pwquality.8.gz
libpam-runtime: /usr/share/man/man8/pam_getenv.8.gz
libpam-snapper: /usr/share/man/man8/pam_snapper.8.gz
libpam-ssh: /usr/share/man/man8/pam_ssh.8.gz
libpam-ssh-agent-auth: /usr/share/man/man8/pam_ssh_agent_auth.8.gz
libpam-sss: /usr/share/man/man8/pam_sss.8.gz
libpam-systemd: /usr/share/man/man8/pam_systemd.8.gz
libpam-u2f: /usr/share/man/man8/pam_u2f.8.gz
libpam-winbind: /usr/share/man/man8/pam_winbind.8.gz
libpam-wrapper: /usr/share/man/man8/pam_chatty.8.gz
libpam-wrapper: /usr/share/man/man8/pam_get_items.8.gz
libpam-wrapper: /usr/share/man/man8/pam_matrix.8.gz
libpam-wrapper: /usr/share/man/man8/pam_set_items.8.gz
libpam-yubico: /usr/share/man/man8/pam_yubico.8.gz
lxc: /usr/share/man/ja/man8/pam_cgfs.8.gz
lxc: /usr/share/man/man8/pam_cgfs.8.gz
manpages-de: /usr/share/man/de/man8/pam_systemd.8.gz
oddjob-mkhomedir: /usr/share/man/man8/pam_oddjob_mkhomedir.8.gz
squid: /usr/share/man/man8/basic_pam_auth.8.gz


signature.asc
Description: PGP signature

Bug#973604: lintian reports spare-manual-page on PAM and NSS modules

[nicoo]

On Mon, Nov 02, 2020 at 07:12:59AM -0800, Felix Lechner wrote:
> Hi nicoo,

Hi Felix,

> We have a misunderstanding about the purpose of manual section 8. It
> was not mentioned in the original UN*X Programmer's Manual [1], but I
> believe it was created for system commands and daemons. They are
> always executable, usually executed as root, and often (but not
> always) located in /sbin or /usr/sbin.

The disagreement is either there, or in the nature of PAM.

> There are no executables with the name 'pam_u2f'. That is why you see
> the Lintian tag.

Yes, obviously, and I'm not suggesting it in section 1.
Yet, those manual page contain information that is relevant for system
administration, and not library documentation.

Indeed, no program is supposed to invoke PAM modules directly, and
instead should use libpam, whose API is indeed documented in section 3:

libpam0g-dev: /usr/share/man/man3/pam_acct_mgmt.3.gz
[...]
libpam0g-dev: /usr/share/man/man3/pam_xauth_data.3.gz


> As you pointed out, many PAM-related packages ship manual pages in
> section 8, but PAM modules are specially constructed shared libraries
> and not system commands in a broader sense. I understand why someone
> might have put them there, but I think they would do better in section
> 5, where 'pam.5' is also located.

`pam(5)` is unrelated to Pluggable Authentication Modules:

NAME
pam - portable arbitrary map file format

DESCRIPTION
The PAM image format is a lowest common denominator 2 
dimensional map for‐
mat.

It is designed to be used for any of myriad kinds  of  
graphics,  but  can
theoretically  be  used for any kind of data that is arranged 
as a two di‐
mensional rectangular array.  Actually, from another 
perspective it can be
seen as a format for data arranged as a three dimensional array.


Section 5 is also intended for “file formats and conventions”, which seems
wholy inappropriate for PAM modules.

Using apt-file, I generated an exhaustive list of manpages whose name start
with pam_.  Using this, I was able to ascertain that only the following are
*not* in section 8:

- libpam-wrapper: /usr/share/man/man1/pam_wrapper.1.gz
  An executable called `pam_wrapper`, meant for testing PAM.

- libpam-abl: /usr/share/man/man1/pam_abl.1.gz
  This is for an executable called `pam_abl`, and there is a separate
  `pam_abl(8)` manpage for the PAM module itself.

- libpam-abl: /usr/share/man/man5/pam_abl.conf.5.gz
  libpam-ldap: /usr/share/man/man5/pam_ldap.conf.5.gz
  libpam-modules: /usr/share/man/man5/pam_env.conf.5.gz
  libpam-mount: /usr/share/man/man5/pam_mount.conf.5.gz
  libpam-winbind: /usr/share/man/man5/pam_winbind.conf.5.gz
  Configuration files, so section 5 does make sense for those.

- libpam-afs-session: /usr/share/man/man5/pam_afs_session.5.gz
  libpam-heimdal: /usr/share/man/man5/pam_krb5.5.gz
  libpam-krb5: /usr/share/man/man5/pam_krb5.5.gz
  libpam-ldap: /usr/share/man/man5/pam_ldap.5.gz
  Indeed PAM modules

- libpam-krb5-migrate-heimdal: /usr/share/man/man7/pam_krb5_migrate_heimdal.7.gz
  libpam-krb5-migrate-mit: /usr/share/man/man7/pam_krb5_migrate_mit.7.gz
  libpam-modules: /usr/share/man/man7/pam_env.7.gz
  libpam-modules: /usr/share/man/man7/pam_selinux.7.gz

  More PAM modules; section 7 is “Miscellaneous (including macro packages and
  conventions), e.g. man(7), groff(7)” so those seem most likely misfiled.


> many PAM-related packages ship manual pages in section 8

There are literally 4 PAM modules whose documentation is in section 5,
4 more in section 7 (misfiled?) and... 83 modules whose documentation is
in section 8.  (I'm attaching the list for those as a separate file)

As the very least, there is an existing consensus to use section 8 there,
and it seems strange for Lintian to enforce different standards without
prior coordination?


> I'll try to find some additional documentation for the different
> manual sections. Please forward anything you might have also. Thank
> you!

I'll also try to see if there is anything semi-formal written down
on the topic, and/or confirm that section 8 is also what's used in
other operating systems which aren't Debian derivatives...
just not tonight, it's already past 2am 


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#973459: uim: FAIL: test-composer.scm

[dai]

On Tue, Nov 17, 2020 at 09:11:54AM +0900, Takatsugu Nokubi wrote:
> I need the test2/test-suite.log file, so I had tried to reproduce it
> on abel twice, but
> I couldn't get the error, just succeeded.
> 
> Can I get the test2/test-suite.log file from anywhere?

test2/test-suite.log is printed in build log:

> FAIL: test-composer.scm
> ===
> 
> Error: in define: bad definition form: (define Aborted
> FAIL test-composer.scm (exit status: 134)

But I do not know why SigScheme throws this error.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#975022: ITP: libmacaroons -- C library supporting generation and use of macaroons

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert 

* Package name: libmacaroons
  Version : 0.3.0
* URL : https://github.com/rescrv/libmacaroons
* License : BSD-3-Clause
  Description : C library supporting generation and use of macaroons



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

Bug#975021: ITP: xrootd -- Extended ROOT file server

[Mattias Ellert]

Package: wnpp
Severity: wishlist
Owner: Mattias Ellert 

* Package name: xrootd
  Version : 5.0.3
* URL : https://xrootd.org
* License : LGPL-3 and BSD-4-clause
  Description : Extended ROOT file server

 The Extended root file server consists of a file server called xrootd
 and a cluster management server called cmsd.
 .
 The xrootd server was developed for the root analysis framework to
 serve root files. However, the server is agnostic to file types and
 provides POSIX-like access to any type of file.
 .
 The cmsd server is the next generation version of the olbd server,
 originally developed to cluster and load balance Objectivity/DB AMS
 database servers. It provides enhanced capability along with lower
 latency and increased throughput.



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

Bug#974992: Licencing disagreement causes user confusion

[Gunnar Hjalmarsson]

On 2020-11-18 01:21, Bdale Garbee wrote:

Gunnar Hjalmarsson  writes:


https://salsa.debian.org/debian/vrms/-/merge_requests/1

The idea is to apply the suggested exception at build time, but
only when building for Ubuntu. On Debian it would keep working as
it currently does.


I won't merge that, but I'm no longer the principal maintainer of
vrms in Debian and won't object if the person who is thinks this is
appropriate to include.


Ok. Merging it would make it easier on the Ubuntu side (we could keep 
sync'ing also going forward), but it's indeed a wishlist request.


Then let's keep the bug open until the principal maintainer has taken a 
stand. Looks like we both need to be attentive and not include "-done" 
when replying...


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#975000: libpqxx-6.2: handling of eof() in streambuffer underflow: large object truncated

[Roman Kurakin]

Package: libpqxx-6.2
Version: 6.2.5-1
Severity: important
Tags: patch upstream

Due to the bug, large object may be truncated while reading it from DB if LOB
contains 0xff byte and it hits the buffer boundary.



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

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

Versions of packages libpqxx-6.2 depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libpq5  11.9-0+deb10u1
ii  libstdc++6  8.3.0-6

libpqxx-6.2 recommends no packages.

libpqxx-6.2 suggests no packages.

-- no debconf information
Index: libpqxx-6.2.5/include/pqxx/largeobject.hxx
===
--- libpqxx-6.2.5.orig/include/pqxx/largeobject.hxx
+++ libpqxx-6.2.5/include/pqxx/largeobject.hxx
@@ -434,11 +434,12 @@ protected:
   virtual int_type underflow() override
   {
 if (!this->gptr()) return EoF();
-char *const eb = this->eback();
-const int_type res(static_cast(
-   AdjustEOF(m_obj.cread(this->eback(), m_bufsize;
-this->setg(eb, eb, eb + ((res==EoF()) ? 0 : res));
-return (!res || (res == EoF())) ? EoF() : *eb;
+auto *const eb{this->eback()};
+auto const res = AdjustEOF(
+m_obj.cread(this->eback(), static_cast(m_bufsize)));
+this->setg(
+eb, eb, eb + (res == EoF() ? 0 : static_cast(res)));
+return (res == EoF() || res == 0) ? EoF() : traits_type::to_int_type(*eb);
   }
 
 private:

Bug#974949: systray-mdstat: fails to start with org.freedesktop.DBus.Error.ServiceUnknown

[Francesco Poli]

Control: tag -1 - moreinfo


On Tue, 17 Nov 2020 20:36:50 +0100 Axel Beckert wrote:

[...]
> Francesco Poli wrote:
[...]
> > [notify-osd](https://packages.debian.org/sid/amd64/notify-osd/filelist)
> > does not seem to.
> 
> Indeed, thanks!
> 
> > On the other hand,
> > [xfce4-notifyd](https://packages.debian.org/sid/amd64/xfce4-notifyd/filelist)
> > seems to ship one.
> 
> That one clearly works. :-)
> 
> > Should I give systray-mdstat/1.2.0-1 another try, after installing
> > xfce4-notifyd?
> 
> Yes, please, at least for the checking other issue which I assume that
> it is solved with the upload.

Let's try:

  $ apt policy xfce4-notifyd
  xfce4-notifyd:
Installed: 0.6.1-1
Candidate: 0.6.1-1
Version table:
   *** 0.6.1-1 800
  800 http://deb.debian.org/debian testing/main amd64 Packages
  500 http://deb.debian.org/debian unstable/main amd64 Packages
  100 /var/lib/dpkg/status
  $ apt policy systray-mdstat
  systray-mdstat:
Installed: 1.2.0-1
Candidate: 1.2.0-1
Version table:
   *** 1.2.0-1 500
  500 http://deb.debian.org/debian unstable/main amd64 Packages
  100 /var/lib/dpkg/status
   1.1.0-1 800
  800 http://deb.debian.org/debian testing/main amd64 Packages
  $ systray-mdstat &
  [1] 16468
  $

It does not complain and it produces a notification, as shown in the
attached xfce4-notifyd_screenshot.png !

[...]
> Hm, now that I think about. Could this issue be also the reason
> for your initially reported issues in #886419, just that
> Desktop::Notify is less tolerant about this?

  $ apt policy systray-mdstat 
  systray-mdstat:
Installed: 1.1.0-1
Candidate: 1.1.0-1
Version table:
   1.2.0-1 500
  500 http://deb.debian.org/debian unstable/main amd64 Packages
   *** 1.1.0-1 800
  800 http://deb.debian.org/debian testing/main amd64 Packages
  100 /var/lib/dpkg/status
  $ systray-mdstat &
  [1] 13746
  no notify because setup failed:
  $ killall -TERM systray-mdstat
  [1]   Terminated  systray-mdstat
  $ /usr/lib/notification-daemon/notification-daemon &
  [2] 13767
  $ systray-mdstat &
  [3] 13782
  no notify because setup failed:
  $ killall -TERM systray-mdstat
  [3]+  Terminated  systray-mdstat
  $ killall -TERM notification-daemon
  [2]+  Terminated  /usr/lib/notification-daemon/notification-daemon

It complains even when notification-daemon is running...

[...]
> A potential third variant, but much more ugly in implementation, would
> be to rely on passing the messages to /usr/bin/notify-send on the
> commandline or STDIN, i.e. forking for every notification.

I agree that this would _not_ be an elegant solution!

[...]
> Which actually leads me to the suspicion that maybe the cause is that
> notification-daemon is not running on your desktop system for whatever
> reason (like using a classic X Window Manager which doesn't care about
> autostart desktop files — which I consider to be a totally valid
> reason btw. :-)

I use Fluxbox as a standalone window manager: I don't use a
full desktop environment.
I start my X session with startx and a custom ~/.xsession file.

> 
> And since you have none of the other notification daemons installed,
> which could be activated over D-Bus automatically, the reported issue
> sounds like a probable outcome of that scenario.
> 
> 
> 
> Could you check on your system if
> /usr/lib/notification-daemon/notification-daemon is actually running?
> 
> 

It is not! I get not output from:

  $ ps aux | grep notification-daemo[n]
  $

> 
> If it is not running, we have found the cause (dependency still
> missing, though :-) and I probably should catch that case in
> systray-mdstat.

Let's try the following:

  $ apt policy systray-mdstat
  systray-mdstat:
Installed: 1.2.0-1
Candidate: 1.2.0-1
Version table:
   *** 1.2.0-1 500
  500 http://deb.debian.org/debian unstable/main amd64 Packages
  100 /var/lib/dpkg/status
   1.1.0-1 800
  800 http://deb.debian.org/debian testing/main amd64 Packages
  $ systray-mdstat &
  [1] 15080
  org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Notifications was not provided by any .service files
  [1]+  Exit 11 systray-mdstat
  $ /usr/lib/notification-daemon/notification-daemon &
  [1] 15081
  $ systray-mdstat &
  [2] 15085
  $

It does not complain and it produces a notification, as shown in the
attached notification-daemon_screenshot.png !

Should I add:

  /usr/lib/notification-daemon/notification-daemon &

somewhere near the beginning of my ~/.xsession file?
And:

  killall -TERM notification-daemon

somewhere near the end of my ~/.xsession file?

Or should I install xfce4-notifyd and have it autostarted
via DBus?

> 
> I nevertheless think that this then would be a bug in
> notification-daemon as it only starts properly depending on the
> desktop environment.

If there's a way to automatically start 

Bug#975020: version mismatch between package and manifest.json

[Martin]

Package: webext-dav4tbsync
Version: 1.21-1
Severity: grave

Justification: makes the package in question unusable by most or
all users

Dear Mechthilde,

many thanks for maintaining the tbsync packages!
Very much appreciated, especially the support of Debian 10 (buster).

The zip file dav4tbs...@jobisoft.de.xpi contains a manifest.json
with the following lines:

  "strict_min_version": "68.0",
  "strict_max_version": "69.*"
  ...
  "version": "1.8",

I assume, that this is wrong. Upstream git 1.21 shows instead:

  "strict_min_version": "78.0",
  "strict_max_version": "78.*"
  ...
  "version": "1.21",

In consequence, the plugin shows as "disabled" in Thunderbird
and with version 1.8 instead of 1.21.
I hope, I got all facts correct.

Cheers!

Bug#974754: libjbig0: invalid ELF header when loading libjbig.so.0

[Andreas Beckmann]

Control: tag -1 moreinfo unreproducible

On Sat, 14 Nov 2020 10:41:26 -0700 Ryan Beethe 
 wrote:
> I use libjbig indirectly through the php-gd package.  When running php
> from the command line, I get the following error:
> 
>  PHP Warning:  PHP Startup: Unable to load dynamic library 'gd.so'
>  (tried: /usr/lib/php/20180731/gd.so
>  (/usr/lib/x86_64-linux-gnu/libjbig.so.0: invalid ELF header),
>  /usr/lib/php/20180731/gd.so.so (/usr/lib/php/20180731/gd.so.so: cannot
>  open shared object file: No such file or directory)) in Unknown on line
>  0

I cannot reproduce this in a buster amd64 chroot
unless I manually corrupt libjbig.so.0

> I was able to fix my system by recompiling the source (with the patches
> from the debian package) and overriding the broken library with the
> recompiled one.

Do you still have the old file around?
Could the libjbig.so.0 library have been corrupted locally?

Size, timestamp and SHA256 sum of the library in shipped in
libjbig0_2.1-3.1+b2_amd64.deb:

-rw-r--r-- 1 root root 58384 Oct 13  2014 /usr/lib/x86_64-linux-gnu/libjbig.so.0
b30cd8bd3956a27819bc0761218d5fa21c59e7e1b5f41f9d7f50f44ba69885d5  
/usr/lib/x86_64-linux-gnu/libjbig.so.0

Andreas

Bug#975019: mirror submission for mirror.k-cix.de

[Alexander Wormuth]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.k-cix.de
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Maintainer: Alexander Wormuth 
Country: DE Germany
Location: Frankfurt am Main
Sponsor: K-CIX https://www.k-cix.de
Comment: Symmetrical Bandwidth IPv4: 1Gbps / IPv6: 1Gbps to 3 Gbps (future)




Trace Url: http://mirror.k-cix.de/debian/project/trace/
Trace Url: http://mirror.k-cix.de/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.k-cix.de/debian/project/trace/mirror.k-cix.de

Bug#868871: Build diff-highlight

[Jonathan Nieder]

Antoine Beaupré wrote:
> On 2017-09-28 12:37:38, Jack Bates wrote:

>> I think the following will resolve this, by running the diff-highlight
>> Makefile when the package is built (following the pattern in
>> debian/rules for other contrib things):
>>
>>> diff --git a/debian/rules b/debian/rules
>>> index f132a2605..ea018298b 100755
>>> --- a/debian/rules
>>> +++ b/debian/rules
>>> @@ -58,6 +58,7 @@ build-stamp:
>>>  override_dh_auto_build-arch: build-stamp
>>> $(MAKE) -C contrib/subtree all $(OPTS)
>>> ln -s contrib/subtree/git-subtree
>>> +   $(MAKE) -C contrib/diff-highlight $(OPTS)
>>> 
>>>  override_dh_auto_test-arch:
>>> test -z '$(TEST)' || \
>
> Any reason why this hasn't been applied to the package just yet?
>
> I'd be happy to do that in a NMU if there are no objections...

Please don't.  Adding additional contrib/ code to the supported
surface without coordination is not an NMU I'd welcome at all
(instead, it would be a bit of a rude shock).

Would it make sense to install this to /usr/share/git-core/contrib/?

If not, could it go in a separate package (within the same source
package)?

I'm also curious about how this compares to
https://pypi.org/project/diff-highlight/

Thanks,
Jonathan

Bug#975015: blockdev: ioctl error on BLKRRPART: Device or resource busy

[Michael Prokop]

Hi dann,

* dann frazier [Tue Nov 17, 2020 at 03:05:32PM -0700]:

> grml2usb autopkgtest frequently fail in Ubuntu's CI. For example:
>   
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/g/grml2usb/20201116_194744_cbe0f@/log.gz

> An excerpt showing the error:
> 2020-11-17 14:14:49,362 Installing default MBR
> 2020-11-17 14:14:49,363 executing: dd if='/dev/loop0' of='/tmp/tmpa2umy9df' 
> bs=5
> 12 count=1
> 2020-11-17 14:14:49,381 executing: dd if=/usr/share/grml2usb/mbr/mbrldr 
> of=/tmp/
> tmpa2umy9df bs=439 count=1 conv=notrunc
> 2020-11-17 14:14:49,385 executing: dd if='/tmp/tmpa2umy9df' of='/dev/loop0' 
> bs=5
> 12 count=1 conv=notrunc
> 2020-11-17 14:14:49,401 executing: sync
> 2020-11-17 14:14:49,433 Probing device via 'blockdev --rereadpt /dev/loop0'
> blockdev: ioctl error on BLKRRPART: Device or resource busy
> 2020-11-17 14:14:49,452 Execution failed: ("Couldn't execute blockdev on '%s' 
> (i
> nstall util-linux?)", '/dev/loop0')

Wow, interesting.

> I am able to reproduce this on an OpenStack instance with a failure rate of
> 33% (36 failures, 110 passes). My theory is that the sync is not sufficient,
> and that we really need to do a targeted fsync of the file. With the
> attached patch, I've yet to see a failure in 42 iterations.

Very nice catch! Thanks for your bug report and many thanks also for
providing a patch with it!


Quoting your other mail (Message-ID: <2020111719.GA35687@xps13.dannf> /
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975015#10):

> Looking at git history, I see this commit that makes an assertion
> counter to my test results:
>   http://git.grml.org/?p=grml2usb.git;a=commit;h=7a6e10df

> Previous to that commit, I did not see fsync being used. Michael: is
> that commit message based on experimentation? If so, perhaps neither
> sync approach is really sufficient, and maybe we need to implement a
> retry loop :/

I'm afraid I don't have any further details available anymore
nowadays, so I'd tend to say I was wrong. :) Your patch looks fine
to me and I'm all for giving this a try, if it should fail anywhere
I'm more than happy to give a closer look at it.

regards
-mika-


signature.asc
Description: Digital signature

Bug#975015: blockdev: ioctl error on BLKRRPART: Device or resource busy

[Michael Prokop]

* dann frazier [Tue Nov 17, 2020 at 03:05:32PM -0700]:
> Package: grml2usb
> Version: 0.18.3
> Severity: normal
> Tags: patch

[...]

> I am able to reproduce this on an OpenStack instance with a failure rate of
> 33% (36 failures, 110 passes). My theory is that the sync is not sufficient,
> and that we really need to do a targeted fsync of the file. With the
> attached patch, I've yet to see a failure in 42 iterations.

Your patch is already commited upstream:

  
https://git.grml.org/?p=grml2usb.git;a=commit;h=272b66ed0ec6a5faa3d36d75843b34d8d6c01d12

I will try upload a new grml2usb release within the next few days.

Thanks again, dann!

regards
-mika-


signature.asc
Description: Digital signature

Bug#974997: Please build-depend on libidn2-dev instead of obsolete transition package libidn2-0-dev

[Simon Josefsson]

Package: wget
Version: 1.20.3-1

The package libidn2-0-dev was obsoleted back in 2017, and replacing it
with libidn2-dev should work fine.

It would be great if this would be fixed before the next Debian
release, so we can finally remove the libidn2-0-dev package from the
archive.

/Simon

PS. I couldn't find version controlled sources for wget, otherwise I
would have provided a patch.


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

Bug#974996: Please build-depend on libidn2-dev instead of obsolete transition package libidn2-0-dev

[Simon Josefsson]

Package: curl
Version: 7.72.0-1
Tags: patch

The package libidn2-0-dev was obsoleted back in 2017, and replacing it
with libidn2-dev should work fine.

It would be great if this would be fixed before the next Debian
release, so we can finally remove the libidn2-0-dev package from the
archive.

/Simon

From b1561363f086cfdab837b74fecad4bb2c045917d Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Tue, 17 Nov 2020 19:21:19 +0100
Subject: [PATCH] B-D on libidn2-dev instead of obsolete libidn2-0-dev.

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index cd69a7be..1cb19fc9 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Build-Depends: debhelper (>= 12),
  groff-base,
  libbrotli-dev,
  libgnutls28-dev,
- libidn2-0-dev,
+ libidn2-dev,
  libkrb5-dev,
  libldap2-dev,
  libnghttp2-dev,
-- 
2.20.1



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

Bug#974995: Please build-depend on libidn2-dev instead of obsolete transition package libidn2-0-dev

[Simon Josefsson]

Package: gnunet
Version: 0.13.1-1
Tags: patch

The package libidn2-0-dev was obsoleted back in 2017, and replacing it
with libidn2-dev should work fine.

It would be great if this would be fixed before the next Debian
release, so we can finally remove the libidn2-0-dev package from the
archive.

/Simon

From 8cf3fdf5b2ea5b67837ef4f02e001b5a68eb79ce Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Tue, 17 Nov 2020 19:25:04 +0100
Subject: [PATCH] B-D on libidn2-dev instead of obsolete libidn2-0-dev.

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index a9b66cdec..aaa97f6bc 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
  libextractor-dev (>=1:0.6.3),
  libgcrypt20-dev (>=1.6),
  libgnutls28-dev (>=3.2.12),
- libidn2-0-dev,
+ libidn2-dev,
  libjansson-dev,
  libltdl-dev (>=2.2),
  libmicrohttpd-dev (>=0.9.63),
-- 
2.20.1



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

Bug#763631: less: -j option yields n-1 spurious lines before the file when going to line 1

[Vincent Lefevre]

Control: tags -1 patch

On 2020-11-17 03:03:03 +0100, Vincent Lefevre wrote:
> On 2020-11-17 02:07:08 +0100, Vincent Lefevre wrote:
> > I've attached a simple patch. The idea is that the line number for
> > the A_GOLINE command must not be smaller than the -j value, except
> > when this value is larger than the screen height (this is probably
> > an unexpected case, but it is correctly handled by my patch).
> 
> Actually this is not that simple. There is a confusion between
> logical lines and physical lines, so that this patch does not
> work well when the file starts with long lines (longer than the
> width of the terminal).

I've updated my patch to avoid this issue. But now the spurious
empty lines before the beginning of the file are avoided only
when going to the beginning of the file, more precisely to the
special line 0, like with 'g' or '<' (without a line number first).
This is done by ignoring jump_sline (the value of the -j option) in
this case; jump_sline is still honored when going to any positive
line number, so that empty lines may still appear in this case
(like in searches).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: Avoid spurious empty lines before the beginning of the file
 Ignore jump_sline (-j value) when going to the beginning of the file,
 i.e. avoid empty lines that would otherwise appear before. Note that
 jump_sline is still honored when going to a positive line number, so
 that empty lines may appear in this case (like in searches).
Author: Vincent Lefevre 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763631
Last-Update: 2020-11-17

diff --git a/command.c b/command.c
index 9b71377..b4b9cce 100644
--- a/command.c
+++ b/command.c
@@ -1109,6 +1109,7 @@ commands(VOID_PARAM)
int action;
char *cbuf;
int newaction;
+   int save_jump_sline;
int save_search_type;
char *extra;
char tbuf[2];
@@ -1410,11 +1411,18 @@ commands(VOID_PARAM)
case A_GOLINE:
/*
 * Go to line N, default beginning of file.
+* If N <= 0, ignore jump_sline in order to avoid
+* empty lines before the beginning of the file.
 */
+   save_jump_sline = jump_sline;
if (number <= 0)
+   {
number = 1;
+   jump_sline = 0;
+   }
cmd_exec();
jump_back(number);
+   jump_sline = save_jump_sline;
break;
 
case A_PERCENT:

Bug#974994: Please build-depend on libidn2-dev instead of obsolete transition package libidn2-0-dev

[Simon Josefsson]

Package: libpsl
Version: 0.21.0-1.1
Tags: patch

The package libidn2-0-dev was obsoleted back in 2017, and replacing it
with libidn2-dev should work fine.

It would be great if this would be fixed before the next Debian
release, so we can finally remove the libidn2-0-dev package from the
archive.

/Simon

From 709812a3b9494dd9b0b4243e648e7fea7cbe546a Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Tue, 17 Nov 2020 19:29:32 +0100
Subject: [PATCH] B-D on libidn2-dev instead of obsolete libidn2-0-dev.

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 12343db..e29579e 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends:
  autoconf-archive,
  automake,
  gtk-doc-tools,
- libidn2-0-dev (>=0.16),
+ libidn2-dev,
  libunistring-dev,
  pkg-config,
  publicsuffix (>= 20150507),
-- 
2.20.1



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

Bug#974993: Please build-depend on libidn2-dev instead of obsolete transition package libidn2-0-dev

[Simon Josefsson]

Package: html-xml-utils
Version: 7.7-1
Tags: patch

The package libidn2-0-dev was obsoleted back in 2017, and replacing it
with libidn2-dev should work fine.

It would be great if this would be fixed before the next Debian
release, so we can finally remove the libidn2-0-dev package from the
archive.

/Simon

From e38297da1e2d15ba86c05bd00a96833fb7becb28 Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Tue, 17 Nov 2020 19:27:32 +0100
Subject: [PATCH] B-D on libidn2-dev instead of obsolete libidn2-0-dev.

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index aad3610..2582b22 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Build-Depends: bison,
flex,
gperf,
libcurl4-gnutls-dev (>> 7.9.7) | libcurl-dev (>> 7.9.7),
-   libidn2-0-dev,
+   libidn2-dev,
man2html-base,
netcat-openbsd
 Standards-Version: 4.4.1
-- 
2.20.1



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

Bug#973873: Readd manpages-fr to task-french?

[nicoo]

Control: tag -1 + confirmed pending

Hi,

On Fri, Nov 06, 2020 at 12:14:21PM +0100, Laurent Bigonville wrote:
> [...] manpages-fr is now built from a new source package with a new
> upstream. Last upload in debian is from the 1st of July 2020.

Thanks for the heads' up

> Maybe the dependency should be readded?

It looks like the binary package is now being built as part of manpages-l10n,
so we can expect it to be maintained longer-term.

OK from me on re-adding it  :)


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#975015: commit message asserts fsync is not enough

[dann frazier]

Looking at git history, I see this commit that makes an assertion
counter to my test results:
  http://git.grml.org/?p=grml2usb.git;a=commit;h=7a6e10df

Previous to that commit, I did not see fsync being used. Michael: is
that commit message based on experimentation? If so, perhaps neither
sync approach is really sufficient, and maybe we need to implement a
retry loop :/

Bug#971515: Request for security team input on kubernetes TC bug

[Florian Weimer]

* Moritz Mühlenhoff:

> On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote:
>> * Moritz Mühlenhoff:
>> 
>> > * Follow a scheme similar to Firefox ESR where in case of a security
>> >   the update either happens to the latest minor release of
>> >   the current branch or if that has stopped, happens to the next
>> >   major release. To map this to specific k8s releases: Let's assume 
>> > bullseye
>> >   were already stable and would ship 19.3. In three months a security issue
>> >   arises which is severe enough to warrant an update and we ship 19.5
>> >   in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe
>> >   security issue needs to be fixed; then the bullseye update would move
>> >   to 20.1 or so. That sounds unusual for a Debian release, but it's
>> >   the status quo for _any_ Kubernetes user after all (whether deployed
>> >   on premises or at some "cloud vendor").
>> 
>> Another thing to consider: Kubernetes rebases will likely require Go
>> rebases, if I read this table correctly:
>> 
>> 
>
> I can't tell how strict these requirements are in practice.

Let's just say that some Kubernetes developers are very eager to get
their hands on the most recent Go toolchain even if there are
practical issues with choices in the run-time library, such as the
changes to certification validation.  Not sure if anyone would want to
suffer these toolchain rebases if there was a clean way around them. 8-)

> It's similar to Firefox requiring more recent versions of rustc and
> golang packages are co-installable, so when it comes to that, shipping
> a new golang-x.y package might also be an option.

I see.

>> Since Go has a bit of spotty history in terms of kernel backwards
>> compatibility, this could cause further challenges.
>
> Do you have a concrete example of such a change? I see that 1.14 is
> available in backports, so this seems to work out so far.

I think that's it: 
If I recall correctly, there was a kernel version check (!) that
managed to reject kernels which did not have the bug.  And combined
with the workaround failing, this led to non-functional programs.

Bug#971515: Request for security team input on kubernetes TC bug

[Moritz Mühlenhoff]

On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote:
> * Moritz Mühlenhoff:
> 
> > * Follow a scheme similar to Firefox ESR where in case of a security
> >   the update either happens to the latest minor release of
> >   the current branch or if that has stopped, happens to the next
> >   major release. To map this to specific k8s releases: Let's assume bullseye
> >   were already stable and would ship 19.3. In three months a security issue
> >   arises which is severe enough to warrant an update and we ship 19.5
> >   in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe
> >   security issue needs to be fixed; then the bullseye update would move
> >   to 20.1 or so. That sounds unusual for a Debian release, but it's
> >   the status quo for _any_ Kubernetes user after all (whether deployed
> >   on premises or at some "cloud vendor").
> 
> Another thing to consider: Kubernetes rebases will likely require Go
> rebases, if I read this table correctly:
> 
> 

I can't tell how strict these requirements are in practice.

It's similar to Firefox requiring more recent versions of rustc and
golang packages are co-installable, so when it comes to that, shipping
a new golang-x.y package might also be an option.

> Since Go has a bit of spotty history in terms of kernel backwards
> compatibility, this could cause further challenges.

Do you have a concrete example of such a change? I see that 1.14 is available
in backports, so this seems to work out so far.

Cheers,
Moritz

Bug#971515: Request for security team input on kubernetes TC bug

[Moritz Mühlenhoff]

Catching up on this...

> > This leaves Debian with two options:
> > * Keep it out of a stable release and accept that it's good enough
> >   if people just install whatever deb they currently find in testing/sid
> >   (works out well enough for most given that blob nature of Go!)
> 
> IMHO this is the most reasonable option and perhaps the only viable one.

Ultimately that's for the release team and/or CTTE to make a call on.

And this while discussion also needs the input of Janos as the current 
kubernetes
maintainer.

> > * Follow a scheme similar to Firefox ESR where in case of a security
> >   the update either happens to the latest minor release of
> >   the current branch or if that has stopped, happens to the next
> >   major release.
> 
> I think Kubernetes have many more vendored 3rd party libraries than Firefox.
> IMHO we can not expect the same level of confidence for Kubernetes...

But each of their releases constitutes a bundle of third party libraries
they've vetted to work together, so this seems to work in practice? (as
can be seen by the 1.19 upload from today). Or maybe I'm missing the specific
concern of yours, is this about them missing fixes in their bundled libs?

Cheers,
Moritz

Bug#975008: util-linux: fails to build and install on non-linux

[Samuel Thibault]

Chris Hofstaedtler, le mar. 17 nov. 2020 23:07:52 +0100, a ecrit:
> * Samuel Thibault  [201117 21:48]:
> > util-linux 2.36 currently doesn't build on !linux, the attached patch
> > (submitted upstream) fixes it.
> 
> That's not really new info.
> 
> Now I do not understand what is going on and why I get the same
> diffs from different people. It would be great if you could sort
> this out, or let upstream sort this out before we do anything
> downstream.
> 
> References:
> https://salsa.debian.org/debian/util-linux/-/merge_requests/17
> https://github.com/karelzak/util-linux/pull/1190
> https://github.com/karelzak/util-linux/pull/1191
> https://marc.info/?l=util-linux-ng=160564485409474=2

- I read the bts entries, not salsa pull requests
- I didn't know util-linux now has PR support.

Samuel

Bug#975008: util-linux: fails to build and install on non-linux

[Chris Hofstaedtler]

* Samuel Thibault  [201117 21:48]:
> util-linux 2.36 currently doesn't build on !linux, the attached patch
> (submitted upstream) fixes it.

That's not really new info.

Now I do not understand what is going on and why I get the same
diffs from different people. It would be great if you could sort
this out, or let upstream sort this out before we do anything
downstream.

References:
https://salsa.debian.org/debian/util-linux/-/merge_requests/17
https://github.com/karelzak/util-linux/pull/1190
https://github.com/karelzak/util-linux/pull/1191
https://marc.info/?l=util-linux-ng=160564485409474=2

Chris

Bug#975015: blockdev: ioctl error on BLKRRPART: Device or resource busy

[dann frazier]

Package: grml2usb
Version: 0.18.3
Severity: normal
Tags: patch

grml2usb autopkgtest frequently fail in Ubuntu's CI. For example:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/g/grml2usb/20201116_194744_cbe0f@/log.gz

An excerpt showing the error:
2020-11-17 14:14:49,362 Installing default MBR
2020-11-17 14:14:49,363 executing: dd if='/dev/loop0' of='/tmp/tmpa2umy9df' bs=5
12 count=1
2020-11-17 14:14:49,381 executing: dd if=/usr/share/grml2usb/mbr/mbrldr of=/tmp/
tmpa2umy9df bs=439 count=1 conv=notrunc
2020-11-17 14:14:49,385 executing: dd if='/tmp/tmpa2umy9df' of='/dev/loop0' bs=5
12 count=1 conv=notrunc
2020-11-17 14:14:49,401 executing: sync
2020-11-17 14:14:49,433 Probing device via 'blockdev --rereadpt /dev/loop0'
blockdev: ioctl error on BLKRRPART: Device or resource busy
2020-11-17 14:14:49,452 Execution failed: ("Couldn't execute blockdev on '%s' (i
nstall util-linux?)", '/dev/loop0')

I am able to reproduce this on an OpenStack instance with a failure rate of
33% (36 failures, 110 passes). My theory is that the sync is not sufficient,
and that we really need to do a targeted fsync of the file. With the
attached patch, I've yet to see a failure in 42 iterations.

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grml2usb depends on:
ii  grub2-common2.04-10
ii  kmod27+20200310-2
ii  mtools  4.0.25-1
ii  python3 3.8.6-1
ii  python3-parted  3.11.6-0.1+b1
ii  rsync   3.2.3-2
ii  syslinux3:6.04~git20190206.bf6db5b4+dfsg1-3

Versions of packages grml2usb recommends:
ii  genisoimage 9:1.1.11-3.1
ii  isolinux3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  syslinux3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  syslinux-utils  3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  xorriso 1.5.2-1

grml2usb suggests no packages.

-- no debconf information
diff -urp grml2usb-0.18.3.orig/grml2usb grml2usb-0.18.3/grml2usb
--- grml2usb-0.18.3.orig/grml2usb   2020-06-23 10:48:42.0 +
+++ grml2usb-0.18.3/grml2usb2020-11-17 18:49:10.884080710 +
@@ -856,7 +852,9 @@ def install_mbr(mbrtemplate, device, par
 set_rw(device)
 
 logging.debug(
-"executing: dd if='%s' of='%s' bs=512 count=1 conv=notrunc", 
tmpf.name, device
+"executing: dd if='%s' of='%s' bs=512 count=1 conv=notrunc,fsync",
+tmpf.name,
+device,
 )
 proc = subprocess.Popen(
 [
@@ -865,7 +863,7 @@ def install_mbr(mbrtemplate, device, par
 "of=%s" % device,
 "bs=512",
 "count=1",
-"conv=notrunc",
+"conv=notrunc,fsync",
 ],
 stderr=open(os.devnull, "r+"),
 )
@@ -874,11 +872,6 @@ def install_mbr(mbrtemplate, device, par
 raise Exception("error executing dd (third run)")
 del tmpf
 
-# make sure we sync filesystems before returning
-logging.debug("executing: sync")
-proc = subprocess.Popen(["sync"])
-proc.wait()
-
 logging.debug("Probing device via 'blockdev --rereadpt %s'", device)
 proc = subprocess.Popen(["blockdev", "--rereadpt", device])
 proc.wait()

Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye

[Moritz Muehlenhoff]

Package: debian-security-support
Severity: normal
X-Debbugs-Cc: d...@debian.org, t...@security.debian.org

Python 2 in Bullseye is only shipped for build dependencies
(but not for runtime dependencies).

openjdk-15 will be included, but not covered by support
(as it's only needed to bootstrap openjdk-16 and eventually
openjdk-17, the next LTS release of Java).

How about the following for "security-support-limited"?


python2.7 Only included for building packages, not running them
cythonOnly included for building packages, not running them
python-stdlib-extensions  Only included for building packages, not running them
openjdk-15Only included for bootstrapping later OpenJDK releases


One important thing: These only applies to Bullseye and
security-support-limited is currently independent of releases, so this
needs to be fixed or alternatively we need to stop rebuilding the current
unstable package for older releases and instead branch of per distro.

Cheers,
Moritz

Bug#975003: mount refuses to mount cifs from fstab with Unknown mount option "symfollow"

[Chris Hofstaedtler]

Control: reassign -1 cifs-utils

Reassigning to cifs-utils, as mount.cifs probably needs updating for
this.

* mc36  [201117 21:09]:
> Package: mount
> Version: 2.36.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> i rebooted my sid today and noticed that my cifs mounts from fstab not came 
> up.
> dmesg indicates " Unknown mount option "symfollow" ".
> manually mounting them (sudo mount.cifs //mount /point -o opts) did the trick.
> nevertheless to note that it's the first time this happened.
> 
> [   50.143880] CIFS: Attempting to mount //devel.mchome.nop.hu/mc36
> [   50.143902] CIFS: Unknown mount option "symfollow"
> [   50.146561] CIFS: Attempting to mount //nas.mchome.nop.hu/mc36
> [   50.146578] CIFS: Unknown mount option "symfollow"
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.9.0-2-amd64 (SMP w/12 CPU threads)
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

Bug#975014: Status of Python 2 in Bullseye

[Moritz Muehlenhoff]

Package: release-notes
Severity: wishlist

I think Python 2 is important enough to warrant an explicit mention
in the Bullseye release notes, I'd propose the following:


Debian Bullseye includes a version of Python 2.7 (and a short list of
related packages like setuptools still built Python 2 packages). However, these
are only included for building a few applications which still require
Python 2 as part of their build process. Python 2 is not supported for
running applications and there won't be any security updates for Python
2 in Bullseye.


Unsure where to add it, though. Either under "What's new in the distribution?"
or under "Issues to be aware of for bullseye"?

Cheers,
Moritz

Bug#972076: tasksel suggests the use of mktemp instead of tempfile

[nicoo]

Control: fixed -1 3.60

Hi Sven,

On Thu, Nov 05, 2020 at 08:14:56PM +0100, Holger Wansing wrote:
> Holger Wansing  wrote:
> > tasksel builds fine with Sven's "tempfile -> mktemp" patch applied, so any 
> > objections against this?
> 
> Just pushed.

Could you confirm that the version Holdger uploaded fixes the issue?
If it doesn't, please remove the “fixed in v3.60” tag I just added.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#975013: ITS: htmlcxx

[Stephen Kitt]

Source: htmlcxx
Severity: important

Dear Maintainer,

I intend to add myself as a co-maintainer of this package, and start
the transition to 0.87.

Your last upload was nearly five years ago, and I’ve had to provide a
number of NMUs before and since to ensure the package remains in
Debian (and along with it, dependent packages including one I
maintain, lgogdownloader). I prepared the 0.87 upgrade eighteen months
ago but have never received a reply to my emails asking you for a
green light — the last two on September 4 and October 31 this year.

As it is, the ITS delays mean that it will be a tight squeeze to get
the updated package into Bullseye; if you agree to my
co-maintainership, I’d appreciate an acknowledgement before the
21-day delay.

Regards,

Stephen


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

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

Bug#975012: dplfin: FTBFS: 69% tests passed, 15 tests failed out of 49

[Sebastian Ramacher]

Source: dolfin
Version: 2019.2.0~git20200629.946dbd3-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

With the last upload to fix #974947, dolfin now FTBFS everywhere:
| 69% tests passed, 15 tests failed out of 49
|
| Total Test time (real) = 222.45 sec
|
| The following tests FAILED:
| 5 - demo_bcs_serial (Child aborted)
|12 - demo_eigenvalue_serial (Child aborted)
|16 - demo_navier-stokes_serial (Child aborted)
|32 - demo_stokes-taylor-hood_serial (Child aborted)
|34 - demo_subdomains_serial (Child aborted)
|36 - demo_advection-diffusion_serial (Child aborted)
|40 - demo_auto-adaptive-navier-stokes_serial (Child aborted)
|46 - demo_contact-vi-snes_serial (Child aborted)
|48 - demo_contact-vi-tao_serial (Child aborted)
|50 - demo_curl-curl_serial (Child aborted)
|52 - demo_dg-advection-diffusion_serial (Child aborted)
|56 - demo_elasticity_serial (Child aborted)
|57 - demo_elastodynamics_serial (Child aborted)
|67 - demo_lift-drag_serial (Child aborted)
|69 - demo_mesh-quality_serial (Child aborted)

See
https://buildd.debian.org/status/fetch.php?pkg=dolfin=amd64=2019.2.0%7Egit20200629.946dbd3-6=1605645211=0

Please avoid uploads unrelated to the ongoing transition.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#481223: dsc and sources if interested: we need new release

[PICCORO McKAY Lenz]

for those interesting (cos seems mantainers dont care of courier
packages) 
https://build.opensuse.org/package/show/home:vegnuli:deploy-vnx1/maildrop
buils and dsc source files for all debians .. including 10 and
testing, and stop to said "that is for olders" dont be stupid

  * New upstream release: Closes #974898
+ Closes: #204187, #596057, #375589, #481223, #592585
+ Closes: #501557, #481223, #716252
+ Updated config file Closes: #861906
  * debian/control:
+ new dependency libidn-dev | libidn11-dev
  * debian/patches:
- remove 0003-permanent-err.patch merged upstream. Closes: #265399
+ Explicit pass CAT=/bin/cat to configure to make build reproducible
  between merged-usr and non-merged-usr systems. Closes: #915180
+ refresh the Re-added the fix for #82986 Filter directory and files
  being accessible to groups and just check for world-writability.
+ refresh 0004-deliver-extra-newlines.patch, just comment!

 -- PICCORO Lenz McKAY   Tue, 17 Nov 2020 10:19:26 -0400

and no: i not use debian mentors cos i do not have my own network
connection so i must upload in a web browser my files so that's why i
used obs

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#975011: ftp.debian.org: attempt to upload packer to stretch-security failed

[Brian May]

Package: ftp.debian.org
Severity: important

Similar to #974877 in fact:

=== cut ===
packer_0.10.2+dfsg-6+deb9u1_amd64.deb: Built-Using refers to non-existing 
source package golang-fsnotify (= 1.4.2-1)

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.
=== cut ===

How do we resolve this?

Bug#975010: src:systemd: autopkgtest regression in testing: timedated test times out

[Paul Gevers]

Source: systemd
Version: 246.6-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression timesout

Dear maintainer(s),

Recently (somewhere this week) the autopkgtest of systemd started to
fail in testing on all architectures we run it on due to timeout (after
more than 2:47 hours).

Can you please investigate the situation and fix it?

Paul

https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/systemd/8180823/log.gz

autopkgtest [03:11:38]: test timedated: [---
original tz: Etc/UTC
timedatectl works
change timezone
reset timezone to original
no adjtime file
UTC set in adjtime file
non-zero values in adjtime file
fourth line adjtime file
no final newline in adjtime file
only one line in adjtime file
only one line in adjtime file, no final newline
only two lines in adjtime file
only two lines in adjtime file, no final newline
unknown value in 3rd line of adjtime file
disable NTP
enable NTP
autopkgtest [05:58:19]: ERROR: timed out on command "su -s /bin/bash
root -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc._296wylu/downtmp/build.wUm/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc._296wylu/downtmp/timedated-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc._296wylu/downtmp/timedated-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc._296wylu/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc._296wylu/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export
AUTOPKGTEST_NORMAL_USER=debci; export ADT_NORMAL_USER=debci; chmod +x
/tmp/autopkgtest-lxc._296wylu/downtmp/build.wUm/src/debian/tests/timedated;
touch /tmp/autopkgtest-lxc._296wylu/downtmp/timedated-stdout
/tmp/autopkgtest-lxc._296wylu/downtmp/timedated-stderr;
/tmp/autopkgtest-lxc._296wylu/downtmp/build.wUm/src/debian/tests/timedated
2> >(tee -a /tmp/autopkgtest-lxc._296wylu/downtmp/timedated-stderr >&2)
> >(tee -a /tmp/autopkgtest-lxc._296wylu/downtmp/timedated-stdout);"
(kind: test)
autopkgtest [05:58:19]: test timedated: ---]



signature.asc
Description: OpenPGP digital signature

Bug#975009: node-schema-utils breacking change

[Xavier Guimard]

Package: node-schema-utils
Version: 2.6.6-1
Severity: serious

node-schema-utils API changed: `require("schema-utils")` becomes
`require("schema-utils").validate`

Bug#975008: util-linux: fails to build and install on non-linux

[Samuel Thibault]

Package: util-linux
Version: 2.36-3+b2
Severity: important
Tags: patch

Hello,

util-linux 2.36 currently doesn't build on !linux, the attached patch
(submitted upstream) fixes it.

Then it is non-installable :) because the postinst/rm scripts are
managing alternatives for more. The attached patch2 does this on Linux
only, fixing the installability there.

Samuel

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

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

Versions of packages util-linux depends on:
ii  libaudit1  1:2.8.5-3.1
ii  libblkid1  2.36-3+b2
ii  libc6  2.31-4
ii  libcap-ng0 0.7.9-2.2
ii  libcrypt1  1:4.4.17-1
ii  libmount1  2.36-3+b2
ii  libpam0g   1.3.1-5
ii  libselinux13.1-2+b1
ii  libsmartcols1  2.36-3+b2
ii  libsystemd0246.6-2
ii  libtinfo6  6.2+20200918-1
ii  libudev1   246.6-2
ii  libuuid1   2.36-3+b2
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.3.0-3
ii  util-linux-locales  2.36-3

-- Configuration Files:
/etc/default/hwclock changed:
HWCLOCKACCESS=yes


-- no debconf information

-- 
Samuel
 (* If you have a precise idea of the intended use of the following code, 
please
write to eduardo.gime...@inria.fr and ask for the prize :-)
-- Eduardo (11/8/97) *)
 -+- N sur #ens-mim - et c'était un des développeurs -+-
diff --git a/login-utils/Makemodule.am b/login-utils/Makemodule.am
index 4f52cea3c..8bc3ee37e 100644
--- a/login-utils/Makemodule.am
+++ b/login-utils/Makemodule.am
@@ -31,8 +31,10 @@ dist_man_MANS += login-utils/sulogin.8
 sulogin_SOURCES = \
login-utils/sulogin.c \
login-utils/sulogin-consoles.c \
-   login-utils/sulogin-consoles.h \
-   lib/plymouth-ctrl.c
+   login-utils/sulogin-consoles.h
+if USE_PLYMOUTH_SUPPORT
+sulogin_SOURCES += lib/plymouth-ctrl.c
+endif
 sulogin_LDADD = $(LDADD) libcommon.la
 
 if HAVE_LIBCRYPT
diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
index 1f7ef3317..db448687d 100644
--- a/sys-utils/hwclock.c
+++ b/sys-utils/hwclock.c
@@ -678,7 +678,7 @@ display_time(struct timeval hwctime)
 #ifndef SYS_settimeofday
 # ifdef __NR_settimeofday
 #  define SYS_settimeofday __NR_settimeofday
-# else
+# elif defined(__NR_settimeofday_time32)
 #  define SYS_settimeofday __NR_settimeofday_time32
 # endif
 #endif
diff --git a/term-utils/Makemodule.am b/term-utils/Makemodule.am
index 92df7dbc8..c424dbdf8 100644
--- a/term-utils/Makemodule.am
+++ b/term-utils/Makemodule.am
@@ -42,8 +42,10 @@ endif # BUILD_SCRIPTLIVE
 if BUILD_AGETTY
 sbin_PROGRAMS += agetty
 dist_man_MANS += term-utils/agetty.8
-agetty_SOURCES = term-utils/agetty.c \
-lib/plymouth-ctrl.c
+agetty_SOURCES = term-utils/agetty.c
+if USE_PLYMOUTH_SUPPORT
+agetty_SOURCES += lib/plymouth-ctrl.c
+endif
 agetty_LDADD = $(LDADD) libcommon.la
 if BSD
 agetty_LDADD += -lutil
--- debian/util-linux.postinst.original 2020-11-17 20:26:36.0 +
+++ debian/util-linux.postinst  2020-11-17 20:26:38.0 +
@@ -1,6 +1,7 @@
 #!/bin/sh
 set -e
 
+[ `uname -s` != Linux ] || \
 update-alternatives --install /usr/bin/pager pager /bin/more 50 \
--slave /usr/share/man/man1/pager.1.gz pager.1.gz \
/usr/share/man/man1/more.1.gz
--- debian/util-linux.prerm.original2020-11-17 20:26:49.0 +
+++ debian/util-linux.prerm 2020-11-17 20:27:01.0 +
@@ -3,6 +3,7 @@
 
 case "$1" in
remove)
+   [ `uname -s` != Linux ] || \
update-alternatives --remove pager /bin/more
;;
 

Bug#975007: src:xmds2: autopkgtest times out on ppc64el (and sometimes on amd64)

[Paul Gevers]

Source: xmds2
Version: 3.0.0+dfsg-4
User: debian...@lists.debian.org
Usertags: timeout flaky
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer,

Your package has an autopkgtest, great! However, it fails due to timeout
on ppc64el (after 2:47 hours) and regularly on amd64 too. Can you please
investigate and fix the situation?

To avoid needlessly stress our infrastructure, I'll block this
package on ppc64el until this bug is fixed.

Paul

https://ci.debian.net/data/autopkgtest/testing/ppc64el/x/xmds2/8069072/log.gz

Checking for single-precision FFTW3 with MPI (static library)
  : yes
('Config log saved to ',
'/tmp/autopkgtest-lxc.96w1db5r/downtmp/build.B8V/src/debian/xmds-user-data/waf_configure/config.log')
test_initialisation_order (__main__.main..ScriptTestCase)
vectors/initialisation_order.xmds ... ok
test_initialisation_order_chunked (__main__.main..ScriptTestCase)
vectors/initialisation_order_chunked.xmds ... ok
test_partial_integration_computed_vector
(__main__.main..ScriptTestCase)
vectors/partial_integration_computed_vector.xmds ... ok
test_bug_adaptive_timestep_hang (__main__.main..ScriptTestCase)
integrators/bug_adaptive_timestep_hang.xmds ... FAIL
test_vibstring_ark45 (__main__.main..ScriptTestCase)
integrators/vibstring_ark45.xmds ... ok
test_vibstring_ark89 (__main__.main..ScriptTestCase)
integrators/vibstring_ark89.xmds ... ok
test_vibstring_mm (__main__.main..ScriptTestCase)
integrators/vibstring_mm.xmds ... ok
test_vibstring_re (__main__.main..ScriptTestCase)
integrators/vibstring_re.xmds ... ok
test_vibstring_rk4 (__main__.main..ScriptTestCase)
integrators/vibstring_rk4.xmds ... ok
test_vibstring_rk45 (__main__.main..ScriptTestCase)
integrators/vibstring_rk45.xmds ... ok
test_vibstring_rk89 (__main__.main..ScriptTestCase)
integrators/vibstring_rk89.xmds ... ok
test_vibstring_rk9 (__main__.main..ScriptTestCase)
integrators/vibstring_rk9.xmds ... ok
test_vibstring_si (__main__.main..ScriptTestCase)
integrators/vibstring_si.xmds ... ok
test_arguments (__main__.main..ScriptTestCase)
features/arguments.xmds ... ok
test_arguments_append_args_to_output_filename
(__main__.main..ScriptTestCase)
features/arguments_append_args_to_output_filename.xmds ... ok
test_arguments_with_similar_names (__main__.main..ScriptTestCase)
features/arguments_with_similar_names.xmds ... ok
test_error_check_multipath (__main__.main..ScriptTestCase)
features/error_check_multipath.xmds ... ok
test_halt_non_finite (__main__.main..ScriptTestCase)
features/halt_non_finite.xmds ... ok
test_hermitegauss_transform_2d_chunked_breakpoints
(__main__.main..ScriptTestCase)
features/hermitegauss_transform_2d_chunked_breakpoints.xmds ... ok
test_hermitegauss_transform_2d_chunked_breakpoints_hdf5
(__main__.main..ScriptTestCase)
features/hermitegauss_transform_2d_chunked_breakpoints_hdf5.xmds ... ok
test_realistic_Rb_and_fields (__main__.main..ScriptTestCase)
features/realistic_Rb_and_fields.xmds ... ok
test_runtime_paths (__main__.main..ScriptTestCase)
features/runtime_paths.xmds ... ok
test_space in filename (__main__.main..ScriptTestCase)
features/space in filename.xmds ... ok
test_bessel_cosine_stochastic_groundstate
(__main__.main..ScriptTestCase)
stochastic/bessel_cosine_stochastic_groundstate.xmds ... ok
test_double_precision_noise_tests (__main__.main..ScriptTestCase)
stochastic/double_precision_noise_tests.xmds ... autopkgtest [22:42:19]:
ERROR: timed out on command "su -s /bin/bash debci -c set -e; export
USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true;  . ~/.profile
>/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.96w1db5r/downtmp/build.B8V/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.96w1db5r/downtmp/run-tests-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.96w1db5r/downtmp/run-tests-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.96w1db5r/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.96w1db5r/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.96w1db5r/downtmp/build.B8V/src/debian/tests/run-tests;
touch /tmp/autopkgtest-lxc.96w1db5r/downtmp/run-tests-stdout
/tmp/autopkgtest-lxc.96w1db5r/downtmp/run-tests-stderr;
/tmp/autopkgtest-lxc.96w1db5r/downtmp/build.B8V/src/debian/tests/run-tests
2> >(tee -a /tmp/autopkgtest-lxc.96w1db5r/downtmp/run-tests-stderr >&2)
> >(tee -a /tmp/autopkgtest-lxc.96w1db5r/downtmp/run-tests-stdout);"
(kind: test)
autopkgtest [22:42:19]: test run-tests: ---]

Bug#975006: libgnatcoll-db-bin: missing Breaks+Replaces: libgnatcoll-sqlite-bin

[Andreas Beckmann]

Package: libgnatcoll-db-bin
Version: 21.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libgnatcoll-db-bin_21.0.0-1_amd64.deb ...
  Unpacking libgnatcoll-db-bin (21.0.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libgnatcoll-db-bin_21.0.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/gnatinspect', which is also in package 
libgnatcoll-sqlite-bin 19.2-3
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libgnatcoll-db-bin_21.0.0-1_amd64.deb

Since libgnatcoll-sqlite-bin is gone in 21.0.0-1, the B+R can be unversioned.


cheers,

Andreas


libgnatcoll-sqlite-bin=19.2-3_libgnatcoll-db-bin=21.0.0-1.log.gz
Description: application/gzip

Bug#975005: git-stash: creates commits by without owning that domain

[Trent W. Buck]

Package: git
Version: 1:2.27.0-1~bpo10+1
Severity: minor

Hi, I noticed that "git stash" creates commits with this author and committer:

git stash 

This domain does not currently exist, but
someone could buy it from ICANN for about US$10,000 (I think).
That could cause exciting and weird bugs, such as
third-party scripts accidentally emailing classified changes to git@stash.

Please use a different domain that is either

  1) controlled by someone trustworthy (e.g. git/SFC, or Debian/SPI)
  2) is guaranteed (by RFCs) to fail

For comparison:

 * "canon" is an example gTLD owned by a company.

 * "ai" is an example ccTLD with working mail,
i.e.  is valid email address.

 * "invalid" is required to not work on the internet by some RFC (FIXME: which 
one?)

 * "example.com" apparently has an MX that deliberately doesn't work?
   I'm not sure if that is *guaranteed*, though.

Steps to reproduce:

bash5$ git init
Initialized empty Git repository in /tmp/with-temp-dir.XHK2wf/.git/
bash5$ date >x
bash5$ git add x
bash5$ git commit -amx
[master (root-commit) fe27c16] x
 1 file changed, 1 insertion(+)
 create mode 100644 x
bash5$ date >x
bash5$ git stash
Saved working directory and index state WIP on master: fe27c16 x
bash5$ git log --format=$'%aN <%aE>\n%cN <%cE>'
Trent W. Buck 
Trent W. Buck 
bash5$ git log --all --format=$'%aN <%aE>\n%cN <%cE>'
git stash 
git stash 
git stash 
git stash 
Trent W. Buck 
Trent W. Buck 


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

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

Versions of packages git depends on:
ii  git-man  1:2.27.0-1~bpo10+1
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-4+deb10u1
ii  liberror-perl0.17027-2
ii  libexpat12.2.6-2+deb10u1
ii  libpcre2-8-0 10.32-5
ii  perl 5.28.1-6+deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 551-1~bpo10+1
ii  openssh-client [ssh-client]  1:7.9p1-10+deb10u2
ii  patch2.7.6-3+deb10u1

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-9
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
ii  git-email 1:2.27.0-1~bpo10+1
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
ii  gitk  1:2.27.0-1~bpo10+1
pn  gitweb

-- debconf-show failed

Bug#970699: linux: Enable amd_energy driver

[David Schiller]

On Fri, 2020-11-13 at 14:56 +0100, Salvatore Bonaccorso wrote:
> If we are going to enable this for our builds, then we might need to
> check that https://bugzilla.redhat.com/show_bug.cgi?id=1897402 is not
> opened accordingly.
> 
> This relates to
> 
> https://support.lenovo.com/lu/uk/product_security/LEN-50481
> 
> and probably the reason for
> 
> https://lore.kernel.org/stable/238e3cf7-582f-a265-5300-9b4494810...@roeck-us.net/T/#m11dee15be8c238d8858aafdf1a57e9ad7e0b9670

Thanks for the response!

I skimmed through the paper covering the CVE and they mostly focused on Intel
SGX and only touched upon AMD briefly. They did there measurements with disabled
boost and fixed frequency, a configuration that no system in the wild actually
uses. Moreover the energy counters are exposed as an MSR, so in my opinion this
is more of a CPU-level bug. 

Personally I feel like recent security efforts are often crippling usability for
negligible gains.
 
Just my two cents!



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

Bug#972268: ipxe-signed - PXE boot firmware EFI signed binary

[Bastian Blank]

Control: tags -1 wontfix

Hi Thomas

On Thu, Oct 15, 2020 at 04:54:54PM +0200, Thomas Gaugler wrote:
> I would like to enable PXE booting within the win32-loader package under
> an UEFI Secure Boot regime.

I'm sorry, but this is not gonna happen, at least in the short term.
Someone needs to do a security audit of ipxe and that someone is not me.

Regards,
Bastian

-- 
Captain's Log, star date 21:34.5...

Bug#975004: python3-paraview: ships vtk modules which are also packaged by python3-vtk9 in experimental

[Andreas Beckmann]

Package: python3-paraview
Version: 5.7.0-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + python3-vtk9

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

python3-vtk9/experimental ship these files that also in python3-paraview/sid:

usr/lib/python3/dist-packages/vtk.py
usr/lib/python3/dist-packages/vtkmodules/__init__.py
usr/lib/python3/dist-packages/vtkmodules/all.py
usr/lib/python3/dist-packages/vtkmodules/gtk/GtkGLExtVTKRenderWindow.py
usr/lib/python3/dist-packages/vtkmodules/gtk/GtkGLExtVTKRenderWindowInteractor.py
usr/lib/python3/dist-packages/vtkmodules/gtk/GtkVTKRenderWindow.py
usr/lib/python3/dist-packages/vtkmodules/gtk/GtkVTKRenderWindowInteractor.py
usr/lib/python3/dist-packages/vtkmodules/gtk/__init__.py
usr/lib/python3/dist-packages/vtkmodules/numpy_interface/__init__.py
usr/lib/python3/dist-packages/vtkmodules/numpy_interface/algorithms.py
usr/lib/python3/dist-packages/vtkmodules/numpy_interface/dataset_adapter.py
usr/lib/python3/dist-packages/vtkmodules/numpy_interface/internal_algorithms.py
usr/lib/python3/dist-packages/vtkmodules/qt/QVTKRenderWindowInteractor.py
usr/lib/python3/dist-packages/vtkmodules/qt/__init__.py
usr/lib/python3/dist-packages/vtkmodules/test/BlackBox.py
usr/lib/python3/dist-packages/vtkmodules/test/Testing.py
usr/lib/python3/dist-packages/vtkmodules/test/__init__.py
usr/lib/python3/dist-packages/vtkmodules/tk/__init__.py
usr/lib/python3/dist-packages/vtkmodules/tk/vtkLoadPythonTkWidgets.py
usr/lib/python3/dist-packages/vtkmodules/tk/vtkTkImageViewerWidget.py
usr/lib/python3/dist-packages/vtkmodules/tk/vtkTkPhotoImage.py
usr/lib/python3/dist-packages/vtkmodules/tk/vtkTkRenderWidget.py
usr/lib/python3/dist-packages/vtkmodules/tk/vtkTkRenderWindowInteractor.py
usr/lib/python3/dist-packages/vtkmodules/util/__init__.py
usr/lib/python3/dist-packages/vtkmodules/util/colors.py
usr/lib/python3/dist-packages/vtkmodules/util/keys.py
usr/lib/python3/dist-packages/vtkmodules/util/misc.py
usr/lib/python3/dist-packages/vtkmodules/util/numpy_support.py
usr/lib/python3/dist-packages/vtkmodules/util/vtkAlgorithm.py
usr/lib/python3/dist-packages/vtkmodules/util/vtkConstants.py
usr/lib/python3/dist-packages/vtkmodules/util/vtkImageExportToArray.py
usr/lib/python3/dist-packages/vtkmodules/util/vtkImageImportFromArray.py
usr/lib/python3/dist-packages/vtkmodules/util/vtkMethodParser.py
usr/lib/python3/dist-packages/vtkmodules/util/vtkVariant.py
usr/lib/python3/dist-packages/vtkmodules/wx/__init__.py
usr/lib/python3/dist-packages/vtkmodules/wx/wxVTKRenderWindow.py
usr/lib/python3/dist-packages/vtkmodules/wx/wxVTKRenderWindowInteractor.py

Once this is fixed in python3-paraview, python3-vtk9 will need to add
appropriate versioned Breaks+Replaces.


cheers,

Andreas

Bug#964438: apt-listbugs: dns error when running from cron job

[Michael Biebl]

So, as said, afaics, everything is working as documented.
If you want to see the behaviour changed, please raise this upstream.

This is not going to be something we implement downstream.

Regards,
Michael



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

Bug#966098: systemd: 'systemctl status' reports "access denied" after upgrade

[Michael Biebl]

> Any suggestions appreciated.

As dist-upgrade across multiple releases aren't tested (and supported),
I would do the following:
- Upgrade from 239-15 to 241-7~deb10u4 (buster), reboot
- Upgrade from 241-7~deb10u4 to 246.6-2 (bullseye)




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

Bug#974989: [Freedombox-pkg-team] Bug#974989: freedombox: firstboot wizard fails in connection setup (KeyError: 'box_name')

[Petter Reinholdtsen]

[Dominik George]
> Yep, forcing my browser to prioritise English fixes it.
>
> In other words, the nb_NO locale is broken.

Right.  Not quite sure where the error is, but I tried updating any
format related errors in the nb translation on Weblate, in case it help.
Could not quite make it out from the backtrace either.

-- 
Happy hacking
Petter Reinholdtsen

Bug#975003: mount refuses to mount cifs from fstab with Unknown mount option "symfollow"

[mc36]

Package: mount
Version: 2.36.1-1
Severity: normal

Dear Maintainer,

i rebooted my sid today and noticed that my cifs mounts from fstab not came up.
dmesg indicates " Unknown mount option "symfollow" ".
manually mounting them (sudo mount.cifs //mount /point -o opts) did the trick.
nevertheless to note that it's the first time this happened.

[   50.143880] CIFS: Attempting to mount //devel.mchome.nop.hu/mc36
[   50.143902] CIFS: Unknown mount option "symfollow"
[   50.146561] CIFS: Attempting to mount //nas.mchome.nop.hu/mc36
[   50.146578] CIFS: Unknown mount option "symfollow"


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

Kernel: Linux 5.9.0-2-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mount depends on:
ii  libblkid1  2.36.1-1
ii  libc6  2.31-4
ii  libmount1  2.36.1-1
ii  libsmartcols1  2.36.1-1
ii  util-linux 2.36.1-1

mount recommends no packages.

Versions of packages mount suggests:
ii  nfs-common  1:1.3.4-4

-- no debconf information

Bug#975002: m2crypto: CVE-2020-25657: bleichenbacher timing attacks in the RSA decryption API

[Salvatore Bonaccorso]

Source: m2crypto
Version: 0.36.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for m2crypto.

CVE-2020-25657[0]:
| bleichenbacher timing attacks in the RSA decryption API
No description was found (try on a search engine)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25657
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25657
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1889823

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#975001: ITS: python-maxminddb

[Ondřej Nový]

Source: python-maxminddb
Severity: important
X-Debbugs-Cc: Faidon Liambotis 

This package FTBFS (see: #959544) and there is no visible activity regarding
this package for more than year. This bug is blocking migration
of my package python-geoip2.

I want to salvage this package, move it under Debian Python Team umbrella
and if you want keep you as uploader.

Thanks.

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

Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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

Bug#973369: linux-image-5.9.0: No network at Banana Pi M3

[Salvatore Bonaccorso]

Control: tags -1 + patch pending

Hi,

On Mon, Nov 09, 2020 at 02:32:21PM +0100, Bernhard wrote:
> Hello Vagrant
> 
> Regarding correction:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts?h=next-20201029=57dbe558457bf4042169bc1f334e3b53a8480a1c
> 
> Currently, i had a look at kernel.org:
> In kernel 5.9.6, the necessary correction is not included.
> Also in kernel 5.10-RC3, this correction is not included.
> 
> Without this correction, the on-board-ethernet of my Banana Pi M3 is not 
> working.
> An external attached USB-->LAN interface works.
> 
> Do you think, there is a chance to add the very small correction to the 
> Debian kernel?
> 
> Best regards and thank you for your great support.

I have applied the change in
https://salsa.debian.org/kernel-team/linux/-/commit/0cfcaef8b5e52549952e89cb31cff1530a5efa42
.

Vagrant, can you double-check please.

Regards,
Salvatore

Bug#974986: sasl2-bin: Include upstream PAM_RHOST patch

[James Botting]

Package: sasl2-bin
Version: 2.1.27+dfsg-1+deb10u1
Severity: normal
Tags: upstream

Dear Maintainer,

Upstream has pushed a patch that enables sending PAM_RHOST when authenticating 
against PAM.
This allows for correct host/ip logging for requests. Can this patch be ported 
to the debain release?

See the patch on the upstream here:
https://github.com/cyrusimap/cyrus-sasl/commit/c813bf1f8b8179807bc2d4cd99c4246df98c35dd

As current, no RHOST field is sent to PAM when authenticating, so no IP or Host 
is logged against the authentication request.

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

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

Versions of packages sasl2-bin depends on:
ii  db-util5.3.1+nmu1
ii  debconf [debconf-2.0]  1.5.71
ii  init-system-helpers1.56+nmu1
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libkrb5-3  1.17-3
ii  libldap-2.4-2  2.4.47+dfsg-3+deb10u3
ii  libpam0g   1.3.1-5
ii  libsasl2-2 2.1.27+dfsg-1+deb10u1
ii  libssl1.1  1.1.1d-0+deb10u3
ii  lsb-base   10.2019051400

sasl2-bin recommends no packages.

sasl2-bin suggests no packages.

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

-- debconf information excluded

Bug#811242: libc-ares-dev: Please provide way to talk to DNS servers on ports != 53

[Gregor Jasny]

Hello,

it seems that in recent versions ares_set_servers is also accepting 
custom ports for the configured list of servers:


https://manpages.debian.org/testing/libc-ares-dev/ares_set_servers.3.en.html

Does that solve your issue?

Thanks,
Gregor

Bug#974949: systray-mdstat: fails to start with org.freedesktop.DBus.Error.ServiceUnknown

[Axel Beckert]

Control: tag -1 + moreinfo

Hi Francesco,

(Hint: The reason for the moreinfo tag is near the end of the mail.)

Francesco Poli wrote:
> > So despite it's name "notification-daemon" looking like being the most
> > generic one of all of them, it looks to me as if it does not to
> > provide that interface. Very unexpected.
[...]
> I found [bug #918385](https://bugs.debian.org/918385), which seems to
> request this .service file.

Thanks!

> Sadly, it looks like it's still unaddressed.

No comment.

> > So
> > https://codesearch.debian.net/search?q=Name%3Dorg.freedesktop.Notifications
> > leads to this package list:
> > 
> > ukui-notification-daemon
> > deepin-notifications
> > plasma-workspace
> > mako-notifier
> > xfce4-notifyd
> > mate-notification-daemon
> > notify-osd
> 
> But not all of them actually ship a .service file:

And actually dunst is missing in that list. Maybe it constructs the
.service file I found on my system only during the package build.

JFTR: On my system, it seems to be xfce4-notifyd which is running (a
few other notification daemons are installed via dependencies, too).

So I'm quite sure that it at least works with xfce4-notifyd. IIRC I
used dunst in the past for a while, too. So I assume that one still
works, too.

> [notify-osd](https://packages.debian.org/sid/amd64/notify-osd/filelist)
> does not seem to.

Indeed, thanks!

> On the other hand,
> [xfce4-notifyd](https://packages.debian.org/sid/amd64/xfce4-notifyd/filelist)
> seems to ship one.

That one clearly works. :-)

> Should I give systray-mdstat/1.2.0-1 another try, after installing
> xfce4-notifyd?

Yes, please, at least for the checking other issue which I assume that
it is solved with the upload.

> Or maybe I should try with:
> [ukui-notification-daemon](https://packages.debian.org/sid/amd64/ukui-notification-daemon/filelist)

ukui-notification-daemon und deepin-notifications come from cultural
(IIRC Russian and Chinese) focussed desktop environments, so I'm not
sure what actually makes them different from (an older) GNOME or
MATE notification daemon. But yeah, would be interesting to know if
and only if it works if such a file is present.

Hm, now that I think about. Could this issue be also the reason
for your initially reported issues in #886419, just that
Desktop::Notify is less tolerant about this?

> > So a short-term workaround seems to depend on only an alternative list
> > of these notification daemons.
> 
> Well, please check which of them actually ship the required .service
> file, first...

Good point, yes. Codesearch just searches through the source code and
not every source code in there is used in the actual binary packages.

> > Not sure though if it's really related, because the commit message
> > seems to sound more like they just disabled starting
> > notification-daemon via D-Bus and starred it always by default.
> 
> Mmmh, I do not know for sure, because I am totally ignorant about
> notification daemons,

Well, yeah, similar here. :-)

> but that commit seems to explain that DBus activation causes issues.

Well, it more refers to problems, but doesn't really explain anything.
Which doesn't really help much in understanding what actually caused
them to remove that.

> And it seems to say that a .desktop file may be used instead (?).

Yes. Which does autostart notification-daemon. But even then: How do
they communicate. I though GNOME does nearly everything via D-Bus
nowadays.

> Is there a way for systray-mdstat to use the .desktop interface, rather
> than the .service interface?

Well, it's actually the D-Bus interface. D-Bus just happens to use
.service files like systemd, but it still seems to be something
different.

The Perl module Desktop::Notify which I switched to (because it seemed
to work better than the old implementation in
Glib::Object::Introspection) hasn't seen much love in the past few
years, so I suspect it hasn't been adapted to whatever GNOME's
notification-daemon now uses to communicate with it. At least the
documentation clearly says:

  This module serves the same purpose as "libnotify", in an
  object-oriented Perl interface. It is not, however, an interface to
  "libnotify" itself, but a separate implementation of the
  specification using Net::DBus.

So I strongly assume it only works via D-Bus.

A potential third variant, but much more ugly in implementation, would
be to rely on passing the messages to /usr/bin/notify-send on the
commandline or STDIN, i.e. forking for every notification.

Would have the advantage that it uses a more maintained library, at
least. (I think.)

Then again, libnotify's package descriptions contain the phrase "sends
desktop notifications to a notification daemon, as defined in the
Desktop Notifications spec". That spec seems to be this one:
https://developer.gnome.org/notification-spec/

And this clearly states "all notifications are controlled by a single
session-scoped service which exposes a D-BUS interface." So it's still
a D-Bus thing 

Bug#974073: Info received (gcc-10: arm64 internal compiler error: canonical types differ for identical types)

[Wookey]

So this is the failing command from the build:
g++ -c -o 
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o 
-MMD -MT 
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o 
-MF 
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o.d
 -fPIC -pipe -g -O2 -ftemplate-backtrace-limit=0 
-fdebug-prefix-map=/home/wookey/debian/polymake-4.1=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 
-ftemplate-depth-200 -fno-strict-aliasing -fopenmp -Wshadow -Wlogical-op 
-Wconversion -Wzero-as-null-pointer-constant -Wno-parentheses 
-Wno-error=unused-function -Wno-stringop-overflow -Wno-array-bounds 
-DPOLYMAKE_WITH_FLINT  -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2 
-DPOLYMAKE_APPNAME=common 
-I/home/wookey/debian/polymake-4.1/include/app-wrappers 
-I/home/wookey/debian/polymake-4.1/include/apps 
-I/home/wookey/debian/polymake-4.1/include/external/permlib 
-I/home/wookey/debian/polymake-4.1/include/external/TOSimplex 
-I/home/wookey/debian/polymake-4.1/include/core-wrappers 
-I/home/wookey/debian/polymake-4.1/include/core 
/home/wookey/debian/polymake-4.1/apps/common/cpperl/generated/SparseMatrix-2.cc 
&& : 'COMPILER_USED=10.2.0'

I found that setting -g1 or -O0 makes it work.
But setting -O1 does not. Nor does changing the -ftemplate-depth=number 
(between 50 and 500)

gcc -E works (if you mkdir -p build/Opt/apps/common/cpperl first)
but
gcc -S ICEs

So essentially building it in two steps: preprocessing to .ii, then building, 
works, but doing it all in one go doesn't.
i.e like this:
g++ -E -o 
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o 
-MMD -MT 
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o 
-MF 
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o.d
 -fPIC -pipe -g -O2 -ftemplate-backtrace-limit=0 
-fdebug-prefix-map=/home/wookey/debian/polymake-4.1=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 
-ftemplate-depth-200 -fno-strict-aliasing -fopenmp -Wshadow -Wlogical-op 
-Wconversion -Wzero-as-null-pointer-constant -Wno-parentheses 
-Wno-error=unused-function -Wno-stringop-overflow -Wno-array-bounds 
-DPOLYMAKE_WITH_FLINT  -DPOLYMAKE_DEBUG=0 -DNDEBUG -DPOLYMAKE_APPNAME=common 
-I/home/wookey/debian/polymake-4.1/include/app-wrappers 
-I/home/wookey/debian/polymake-4.1/include/apps 
-I/home/wookey/debian/polymake-4.1/include/external/permlib 
-I/home/wookey/debian/polymake-4.1/include/external/TOSimplex 
-I/home/wookey/debian/polymake-4.1/include/core-wrappers 
-I/home/wookey/debian/polymake-4.1/include/core 
/home/wookey/debian/polymake-4.1/apps/common/cpperl/generated/SparseMatrix-2.cc

g++ -c -o 
/home/wookey/debian/polymake-4.1/build/Opt/apps/common/cpperl/SparseMatrix-2.o  
-fPIC -pipe -g -O2 -ftemplate-backtrace-limit=0 
-fdebug-prefix-map=/home/wookey/debian/polymake-4.1=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 
-ftemplate-depth-200 -fno-strict-aliasing -fopenmp -Wshadow -Wlogical-op 
-Wconversion -Wzero-as-null-pointer-constant -Wno-parentheses 
-Wno-error=unused-function -Wno-stringop-overflow -Wno-array-bounds 
-DPOLYMAKE_WITH_FLINT  -DPOLYMAKE_DEBUG=0 -DNDEBUG -DPOLYMAKE_APPNAME=common 
SparseMatrix-2.ii

Don't know if that helps narrow it down at all? The fact that the 2-stage build 
works seems rather odd to me.

I tried with gcc-snapshot (20201023) and that worked correctly.
so something changed between
g++ (Debian 10.2.0-16) 10.2.0 and
g++ (Debian 20201023-1) 11.0.0 20201023 (experimental) [master revision 
d08d481912b:b3da6ca6235:9e3b9ddb996f18d541a3e03611d46c3a6c0c0b5f]
Is anyone in a position to bisect this so we can work out what fix should be 
backported? Or give me some clues on how to go about that.
Any more debug suggestions?

I have reported this to the ARM compiler team internally too.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#945487: dkimproxy: defaults to prohibited rsa-sha1 signatures

[Renaud Allard]

You can override the signature type in the config with a line like this:
signature dkim(c=relaxed,a=rsa-sha256)

That will not solve the fact that this is not the default, but will 
allow you to sign with the rsa-sha256 signature.


Maybe the example config file should be updated with this kind of signature.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#973472: fetchmail: Fails to connect using SSL

[GCS]

On Wed, Nov 11, 2020 at 9:23 PM Kurt Roeckx  wrote:
> On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote:
> >  Thanks for possibly the best solution. Meanwhile OpenSSL 1.1.1h-1
> > migrated to testing; closing this bug report.
>
> That is not a fix. Fetchmail should not be checking the version.
>
> The libssl1.1 package will ensure that the correct versioned
> depenencies are there.
 You are right, that's what soname for - define the used and
compatible library dependencies.
Matthias, what's your intention with the forced OpenSSL library check?
Do you plan to remove that upstream or should I comment that out?

Regards,
Laszlo/GCS

Bug#973259: dpkg-scanpackages: local development repos fail due to missing sha512 hashes

[Guillem Jover]

Hi!

On Tue, 2020-10-27 at 18:30:43 -0400, Nicholas D Steeves wrote:
> Package: dpkg-dev
> Version: 1.20.5
> Severity: important

> Today while working on the autopkgtests of an ITP of mine I discovered
> that apt fails to install packages from the local repo, seemingly
> because of missing sha512 hashes.  Whether intentional or not, the
> effect seems to be that apt is enforcing sha512, which isn't a bad
> thing, hence this bug!

But sha256 is not weak, so that should be enough, the problem seems
to be something else. I've already implemented this locally, but I'm
afraid it would need coordination with at least ftp-masters as DAK
might actually reject such .dsc and .changes files.

Hmm, but I tried to reproduce this, and I'm unable to, downloaded a
couple of binary packages, created a Packages file with dpkg-scanpackages,
and added an entry in apt and updated and nothing broke, so there's
something else going on:

  $ mkdir repo
  $ cd repo
  $ apt download libbsd0 libmd0
  $ dpkg-scanpackages . >Packages
  $ cat < …
> Get:1 file:/usr/src/repo/amd64 ./ python3-volatile 2.1.0-1 [5356 B]
> Err:1 file:/usr/src/repo/amd64 ./ python3-volatile 2.1.0-1
>   Hash Sum mismatch
>   Hashes of expected file:
>- SHA256:1210131215ad632c8eb4d09b0448ce680ca9805aaf4ec9b3b99ee2161537f93c
>- SHA1:fc1517b001fe9361d18a31f0d63daac366f93c8e [weak]
>- MD5Sum:e9c3ec5e3d437c610566fa2d24baee47 [weak]
>- Filesize:5356 [weak]
>- 
> SHA512:779d3b466eb7cff946f6efebce7374803ec4afd6631ace49e02073d1da4fa98a4b1449e0e207dff6b32e11f735b29b04298a05632dcc077469ecfc674b0cab5d
>   Hashes of received file:
>- 
> SHA512:d2330098a34a54fe68a57ef12ce79260bb0eeddea3df251e9e4bbd1588dc0e46904ee89cc9e6bf44d8c0a910caedcc1b9c582066f7402ff264d7dc130d7f79c4
>- SHA256:1210131215ad632c8eb4d09b0448ce680ca9805aaf4ec9b3b99ee2161537f93c
>- SHA1:fc1517b001fe9361d18a31f0d63daac366f93c8e [weak]
>- MD5Sum:e9c3ec5e3d437c610566fa2d24baee47 [weak]
>- Filesize:5356 [weak]
>   Last modification reported: Tue, 27 Oct 2020 21:23:22 +
> W: Sources disagree on hashes for supposely identical version '2.1.0-1' of 
> 'python3-volatile:amd64'.
> E: Failed to fetch 
> file:/usr/src/repo/amd64/../pool/python3-volatile_2.1.0-1_all.deb  Hash Sum 
> mismatch

Hmm if the hashes are missing, why are they here mismatched?

Thanks,
Guillem

Bug#971597: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #971597 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/fb98c1799873ee1dbc6f9726691b5183f23e


Merge subindices for orig sources with multiple tarball components.
(Closes: #970750, #971597, #972567)

A family of related bugs appeared when we started unpacking the orig
index. The purpose was to revitaize a group of checks that had been
disabled for the source format 3.0, where no diffstat js available. A
detailed, differential perspective is now possible for all source
formats by comparing the patched and orig indices.

This commit fixes some of the bugs (and some of the most egregious)
but may leave others---including some not yet discovered.

Lintian now completes its runs without errors on the packages
mentioned in the bugs (see below) and also on many Node.js packages,
which were disproportionally affected.

A related merge request on Salsa (!338) also attempted to close these
bugs, but would be less effective in the estimation of this author. It
will be closed without action.

As an example for Node.js:

lechner@lechner-desktop /l/l/l/git> bin/lintian
/mirror/debian/pool/main/n/node-log4js/node-log4js_6.2.1+\~cs8.3.10-1.dsc
P: node-log4js source: package-uses-old-debhelper-compat-version 12
O: node-log4js source: source-is-missing flatted/min.js line length is
981 characters (>512)
O: node-log4js source: source-contains-prebuilt-javascript-object
flatted/min.js line length is 981 characters (>512)
N: Uninstalled file
O: node-log4js source: very-long-line-length-in-source-file
flatted/min.js line length is 981 characters (>512)

For Bug#972567:
===

Lintian no longer exits with fatal errors. (The -3 version mentioned
in the report was not available in the archive.)

lechner@lechner-desktop /l/l/l/git> bin/lintian
/mirror/debian/pool/main/f/freetype/freetype_2.10.1-2.dsc
E: freetype source: duplicate-globbing-patterns src/psaux/pserror.h in
lines 304 304
E: freetype source: source-is-missing
docs/reference/site/assets/javascripts/application.d9aa80ab.js line
length is 32768 characters (>512)
E: freetype source: source-is-missing
docs/reference/site/assets/javascripts/lunr/lunr.da.js line length is
4259 characters (>512)
E: freetype source: source-is-missing
docs/reference/site/assets/javascripts/lunr/lunr.de.js line length is
5736 characters (>512)
E: freetype source: source-is-missing ... use --no-tag-display-limit
to see all (or pipe to a file/program)
I: freetype source: wildcard-matches-nothing-in-dep5-copyright
src/gxvalid/gxvfgen.c (line 215)
P: freetype source: package-uses-old-debhelper-compat-version 12
P: freetype source: redundant-globbing-patterns [builds/amiga/*
builds/amiga/include/config/*] for
builds/amiga/include/config/ftconfig.h
P: freetype source: redundant-globbing-patterns [builds/amiga/*
builds/amiga/include/config/*] for
builds/amiga/include/config/ftmodule.h
P: freetype source: redundant-globbing-patterns
[ft2demos/src/ftinspect/* ft2demos/src/ftinspect/engine/*] for
ft2demos/src/ftinspect/engine/engine.cpp
P: freetype source: redundant-globbing-patterns ... use
--no-tag-display-limit to see all (or pipe to a file/program)
P: freetype source: source-contains-browserified-javascript
docs/reference/site/assets/javascripts/lunr/wordcut.js code
fragment:if("object"==typeof exports&&"undefined"!=typeof
module)module.exports=n();else if("fu
P: freetype source: source-contains-prebuilt-javascript-object
docs/reference/site/assets/javascripts/application.d9aa80ab.js line
length is 32768 characters (>512)
P: freetype source: source-contains-prebuilt-javascript-object
docs/reference/site/assets/javascripts/lunr/lunr.da.js line length is
4259 characters (>512)
P: freetype source: source-contains-prebuilt-javascript-object
docs/reference/site/assets/javascripts/lunr/lunr.de.js line length is
5736 characters (>512)
P: freetype source: source-contains-prebuilt-javascript-object ... use
--no-tag-display-limit to see all (or pipe to a file/program)
P: freetype source: very-long-line-length-in-source-file
docs/reference/site/assets/javascripts/application.d9aa80ab.js line
length is 32768 characters (>512)
P: freetype source: very-long-line-length-in-source-file
docs/reference/site/assets/javascripts/lunr/lunr.da.js line length is
4259 characters (>512)
P: freetype source: very-long-line-length-in-source-file
docs/reference/site/assets/javascripts/lunr/lunr.de.js line length is
5736 characters (>512)
P: freetype source: very-long-line-length-in-source-file ... use
--no-tag-display-limit to see all (or pipe to a file/program)

For Bug#971597:
===

The tag wildcard-matches-nothing-in-dep5-copyright, which was a false
positive, no longer appears.

lechner@lechner-desktop /l/l/l/git> bin/lintian

Bug#974998: calamares: SegFault when clicked on "Create" in manual partitioning

[Avinash Sonawane]

Package: calamares
Version: 3.2.4-3
Severity: normal
Tags: d-i

Hello!

I am installing Debian 10.6.0 using
debian-live-10.6.0-amd64-xfce+nonfree.iso. I noticed that in manual
partitioning if we click on "Create", the Debian installer segfaults if
no free space available or free space available but entry not selected.

Steps to reproduce:
1. Click "Next" till "Partitions" step
2. Select "Manual partitioning"
3. Select "New Partition Table" > "GPT"
4. "Free Space" entry appears and "Create" button is disabled as
expected since the free space entry is not selected
5. Now, select "Free Space" entry
6. Click "Create" and then "OK"
7. "New partition" entry appears with no free space available
8. Now click "Create" and the installer will crash with segfault

This bug can also be triggered by creating a small partition thus
leaving the "Free space" but then not selecting the "Free space" entry
and then clicking "Create" button.

The solution would be to disable "Create" button if no "Free space"
available or "Free space" available but entry not selected.

Here's the log: https://pastebin.com/raw/N2CskhDG

Thanks!

Bug#974999: ITP: r-bioc-glmgampoi -- GNU R fit a Gamma-Poisson generalized linear model

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Subject: ITP: r-bioc-glmgampoi -- GNU R fit a Gamma-Poisson generalized linear 
model
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: r-bioc-glmgampoi
  Version : 1.2.0
  Upstream Author : Constantin Ahlmann-Eltze,
* URL : https://bioconductor.org/packages/glmGamPoi/
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R fit a Gamma-Poisson generalized linear model
 Fit linear models to overdispersed count data.
 The package can estimate the overdispersion and fit repeated models
 for matrix input. It is designed to handle large input datasets as they
 typically occur in single cell RNA-seq experiments.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-glmgampoi


-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEck1gkzcRPHEFUNdHPCZ2P2xn5uIFAl+0GZUSHGNydXNvZUBk
ZWJpYW4ub3JnAAoJEDwmdj9sZ+biOIMP/ApiwxJo5NRyD8iACT8Po81aO0bbamwa
MYppVKXdqdUuQi5AeHsGYce/uX8t6YHh9ygL38b09tyvd12psExTr5AA1ovoOYTp
AuDRzum6wfuYR1tMmfbeZRHVcHyof8EfPG8sRkrCTbJBgETOG4LqNOCw1lVxQwD+
CDnLO6LpOtOEj8/r627wA4erYcHme9C8kRysrdTg8ZmUPEnSbnHSmdQ4XGeBnwZ0
ZFaBD54DynO90aR+ovpkG3YCpm95f5uCYVRsTlU+cKYHB1rSm5f2H9v2VDyMi4vm
42OIfDQK990HuwhndfQMo87jGF9ShsawTWviarrSXoEssHxvmWfOn6j8Y812x2Rf
HDB2KvoAzkpnrFz4T9L8+OJtPqlqywEmLQE00+d4b6I11TnbEEN0SsZPzK6GXZN2
oqq1VVYnr8OW3RuLJRuu6yins198bsUztyy8Ct0K+DpvM4xUVFHpD23bHnUmerPd
nYUfu+elleLQpmy+RAMNR9oezQ9PnYvVvUKjW/6klxMm6jMxXBraj/mWaAXtwSqs
z46WllX+n4PnTpwd4o6h3BZ758MOFQN12yL+6nUEOdznuc8pzMOYvtzJAgI1GhjI
Lu/ScgdFRymyhI/iEYT619ox+ElWMsU200Kol3JyIE16miJ9KzY/Cdx/doxSOJ9g
ZYRDvRgCWHjH
=0PdT
-END PGP SIGNATURE-

Bug#957128: desproxy: diff for NMU version 0.1.0~pre3-10.1

[Sudip Mukherjee]

Control: tags 957128 + patch
Control: tags 957128 + pending
--

Dear maintainer,

I've prepared an NMU for desproxy (versioned as 0.1.0~pre3-10.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru desproxy-0.1.0~pre3/debian/changelog 
desproxy-0.1.0~pre3/debian/changelog
--- desproxy-0.1.0~pre3/debian/changelog2016-10-30 06:57:00.0 
+
+++ desproxy-0.1.0~pre3/debian/changelog2020-11-17 18:29:28.0 
+
@@ -1,3 +1,10 @@
+desproxy (0.1.0~pre3-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957128)
+
+ -- Sudip Mukherjee   Tue, 17 Nov 2020 18:29:28 
+
+
 desproxy (0.1.0~pre3-10) unstable; urgency=medium
 
   * debian/watch
diff -Nru desproxy-0.1.0~pre3/debian/rules desproxy-0.1.0~pre3/debian/rules
--- desproxy-0.1.0~pre3/debian/rules2016-10-30 06:57:00.0 +
+++ desproxy-0.1.0~pre3/debian/rules2020-11-17 17:47:03.0 +
@@ -3,7 +3,7 @@
 PACKAGE = desproxy
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
+export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic -fcommon
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 man:

Bug#974990: fonts-opendyslexic: Please package new upstream (2019.09.16 or later)

[Samuel Thibault]

Samuel Thibault, le mar. 17 nov. 2020 18:58:31 +0100, a ecrit:
> Samuel Thibault, le mar. 17 nov. 2020 18:46:39 +0100, a ecrit:
> > Mmm, there was already mono and alta in the existing Debian package, and
> > actually on the contrary I cannot find them in the newer upstream
> > release:
> > 
> [...]
> > I'm fetching the tarballs from
> > 
> > https://github.com/antijingoist/opendyslexic/tags
> 
> There are actually the .glyphs file in them, I'll have a look at using
> glyphslib etc.to convert to otf.

This is failing in various ways...

€ glyphs2ufo opendyslexic.glyphs
Traceback (most recent call last):
  File "/usr/bin/glyphs2ufo", line 33, in 
sys.exit(load_entry_point('glyphsLib==5.2.0', 'console_scripts', 
'glyphs2ufo')())
  File "/usr/lib/python3/dist-packages/glyphsLib/cli.py", line 228, in 
_glyphs2ufo_entry_point
return main(args)
  File "/usr/lib/python3/dist-packages/glyphsLib/cli.py", line 189, in main
return options.func(options)
  File "/usr/lib/python3/dist-packages/glyphsLib/cli.py", line 208, in 
glyphs2ufo
glyphsLib.build_masters(
  File "/usr/lib/python3/dist-packages/glyphsLib/__init__.py", line 104, in 
build_masters
font = GSFont(filename)
  File "/usr/lib/python3/dist-packages/glyphsLib/classes.py", line 3653, in 
__init__
p.parse_into_object(self, fp.read())
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 63, in 
parse_into_object
i = self._parse_dict_into_object(res, text, 1)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 166, in 
_parse_dict_into_object
result = self._parse(text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 103, in _parse
return self._parse_list(text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 193, in 
_parse_list
list_item, i = self._parse(text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 97, in _parse
return self._parse_dict(text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 150, in 
_parse_dict
i = self._parse_dict_into_object(res, text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 166, in 
_parse_dict_into_object
result = self._parse(text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 103, in _parse
return self._parse_list(text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 193, in 
_parse_list
list_item, i = self._parse(text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 97, in _parse
return self._parse_dict(text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 150, in 
_parse_dict
i = self._parse_dict_into_object(res, text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 176, in 
_parse_dict_into_object
self._fail("Missing delimiter in dictionary before content", text, i)
  File "/usr/lib/python3/dist-packages/glyphsLib/parser.py", line 235, in _fail
raise ValueError("{}:\n{}".format(message, text[i : i + 79]))
ValueError: Missing delimiter in dictionary before content:
 Value;
}
);
descender = -520;
guideLines = (
{
angle = 90;
position = "{259, 1


€ glyphs2ufo OpenDyslexic-Mono.glyphs

does work, but then

€ python3
Python 3.8.6 (default, Sep 25 2020, 09:36:53) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from defcon import Font
>>> from ufo2ft import compileOTF
>>> ufo = Font('OpenDyslexicMono-Regular.ufo')
>>> otf = compileOTF(ufo)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/ufo2ft/__init__.py", line 128, in 
compileOTF
compileFeatures(
  File "/usr/lib/python3/dist-packages/ufo2ft/__init__.py", line 521, in 
compileFeatures
otFont = featureCompiler.compile()
  File "/usr/lib/python3/dist-packages/ufo2ft/featureCompiler.py", line 125, in 
compile
self.setupFeatures()
  File "/usr/lib/python3/dist-packages/ufo2ft/featureCompiler.py", line 223, in 
setupFeatures
writer.write(self.ufo, featureFile, compiler=self)
  File 
"/usr/lib/python3/dist-packages/ufo2ft/featureWriters/baseFeatureWriter.py", 
line 110, in write
self.setContext(font, feaFile, compiler=compiler)
  File 
"/usr/lib/python3/dist-packages/ufo2ft/featureWriters/markFeatureWriter.py", 
line 251, in setContext
ctx.anchorLists = self._getAnchorLists()
  File 
"/usr/lib/python3/dist-packages/ufo2ft/featureWriters/markFeatureWriter.py", 
line 284, in _getAnchorLists
a = self.NamedAnchor(name=anchorName, x=anchor.x, y=anchor.y)
  File 
"/usr/lib/python3/dist-packages/ufo2ft/featureWriters/markFeatureWriter.py", 
line 148, in __init__
isMark, key, number = parseAnchorName(
  File 
"/usr/lib/python3/dist-packages/ufo2ft/featureWriters/markFeatureWriter.py", 
line 126, in parseAnchorName
raise ValueError("mark anchor key is nil: %r" % anchorName)
ValueError: mark anchor key is nil: '_'

...

Forwarded as

Bug#974989: [Freedombox-pkg-team] Bug#974989: Bug#974989: freedombox: firstboot wizard fails in connection setup (KeyError: 'box_name')

[Sunil Mohan Adapa]

On 17/11/20 10:00 am, Petter Reinholdtsen wrote:
> [Dominik George]
>> I installed the freedombox package on a pretty much vanilla Debian
>> installation.
>>
>> The first boot wizard got as far as setting up the connection, and
>> when asked how my router is set up, I chose I do not want to set it up
>> right now. That caused the following exception:
> 
> Just to rule out one cause of error.  Did you select a langauge?
> Perhaps one of the languages have a bug in a format string?

This is likely the issue.

Further, we are also picking up the language preferences set in the
browser by default. So the issue likely happens even before selecting a
language. If so, specifying the list of language priorities in the
browser would help to fix this issue.

-- 
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#974937: Re : Bug#974937: evince: crashes then runs

[nicolas . patrois]

Le 17/11/2020 11:20:59, Simon McVittie a écrit :

> Control: tags -1 + moreinfo

> Does this happen for *all* files, or only for specific files?

> Sorry, we can't do anything with this amount of information. If you
> can get a backtrace from the crash, that might provide enough information
> to find the bug: please see .

It’s for all files.
Do you want the end of strace’s output?

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#974989: [Freedombox-pkg-team] Bug#974989: freedombox: firstboot wizard fails in connection setup (KeyError: 'box_name')

[Dominik George]

Tags: -1 + l10n

> > The first boot wizard got as far as setting up the connection, and
> > when asked how my router is set up, I chose I do not want to set it up
> > right now. That caused the following exception:
> 
> Just to rule out one cause of error.  Did you select a langauge?
> Perhaps one of the languages have a bug in a format string?

Yep, forcing my browser to prioritise English fixes it.

In other words, the nb_NO locale is broken.

Thanks for the pointer!

-nik

Bug#974949: systray-mdstat: fails to start with org.freedesktop.DBus.Error.ServiceUnknown

[Francesco Poli]

On Tue, 17 Nov 2020 16:38:42 +0100 Axel Beckert wrote:

[...]
> Francesco Poli wrote:
[...]
> > Package notification-daemon does not seem to ship any *.service file:
> > 
> >   $ dpkg -L notification-daemon | grep -i service
> 
> But other notification daemons seem to do.
> 
> So despite it's name "notification-daemon" looking like being the most
> generic one of all of them, it looks to me as if it does not to
> provide that interface. Very unexpected.

I see.

I found [bug #918385](https://bugs.debian.org/918385), which seems to
request this .service file.
Sadly, it looks like it's still unaddressed.

> 
> > P.S.: I dropped the moreinfo tag, but, of course, feel free to re-set
> >   it, in case you need any other answer from me!
> 
> Perfectly fine. Need to think about this and investigate further.
> 
> So
> https://codesearch.debian.net/search?q=Name%3Dorg.freedesktop.Notifications
> leads to this package list:
> 
> ukui-notification-daemon
> deepin-notifications
> plasma-workspace
> mako-notifier
> xfce4-notifyd
> mate-notification-daemon
> notify-osd

But not all of them actually ship a .service file:
[notify-osd](https://packages.debian.org/sid/amd64/notify-osd/filelist)
does not seem to.

On the other hand,
[xfce4-notifyd](https://packages.debian.org/sid/amd64/xfce4-notifyd/filelist)
seems to ship one.

Should I give systray-mdstat/1.2.0-1 another try, after installing
xfce4-notifyd?

Or maybe I should try with:
[ukui-notification-daemon](https://packages.debian.org/sid/amd64/ukui-notification-daemon/filelist)

> 
> So a short-term workaround seems to depend on only an alternative list
> of these notification daemons.

Well, please check which of them actually ship the required .service
file, first...

> 
> It's though clearly not all notification-daemons in Debian. At least
> lxqt-notificationd and some window manager/desktop environments seem
> to provide "notification-daemon", but not have such a file, too.
> 
> But since at least ukui-notification-daemon, deepin-notifications and
> mate-notification-daemon are AFAIK based on GNOME's
> notification-daemon, I tried to find something in it's changelog,
> but I only found this in the upstream changelog from 2011 (!):
> 
>   NEW in 0.7.1:
>   ==
>   - Don't use DBus activation
> 
> And this upstream commit:
> 
> commit 1ad20d22098bc7718614a8a87744a2c22d5438d0
> Author: Matthias Clasen 
> Date:   Tue Feb 15 09:52:11 2011 -0500
> 
> Don't use dbus activation
> 
> Dbus activation causes a race with gnome-shell at session startup.
> Instead, install a regular desktop file, so we can make
> notification-daemon a required component of the fallback session.
> Finally, install notification-daemon in bindir to avoid fiddling
> with libexecdir when generating the desktop file.
> 
>  data/Makefile.am  | 8 +---
>  data/notification-daemon.desktop.in   | 7 +++
>  data/org.freedesktop.Notifications.service.in | 3 ---
>  src/Makefile.am   | 2 +-
>  4 files changed, 13 insertions(+), 7 deletions(-)
> 
> Not sure though if it's really related, because the commit message
> seems to sound more like they just disabled starting
> notification-daemon via D-Bus and starred it always by default.

Mmmh, I do not know for sure, because I am totally ignorant about
notification daemons, but that commit seems to explain that DBus
activation causes issues.
And it seems to say that a .desktop file may be used instead (?).

Is there a way for systray-mdstat to use the .desktop interface, rather
than the .service interface?

> 
> But maybe I'm also looking at the wrong place. At least
> "org.freedesktop.Notifications" shows up all over
> notification-daemon's source code:
> https://codesearch.debian.net/search?q=package%3Anotification-daemon+org.freedesktop.Notifications+package%3A%5CQnotification-daemon%5CE=1
> 
> Then again, not having such a service file seems to fit with your
> observations.

Maybe there's another way to access the org.freedesktop.Notifications
interface, without relying on the .service file. I don't know!

I suspect it is worth researching in this direction...

> 
> Since I'm neither well-versed in GNOME stuff nor in D-Bus stuff, I'm
> bit out of (better) ideas at the moment.

I am sure you are way more knowledgeable than me about this subject.
It probably just needs a little more research, and you'll figure
everything out!   :-)


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


pgp0ibV4YFdcY.pgp
Description: PGP signature

Bug#974989: [Freedombox-pkg-team] Bug#974989: freedombox: firstboot wizard fails in connection setup (KeyError: 'box_name')

[Dominik George]

Hi,

> > The first boot wizard got as far as setting up the connection, and
> > when asked how my router is set up, I chose I do not want to set it up
> > right now. That caused the following exception:
> 
> Just to rule out one cause of error.  Did you select a langauge?
> Perhaps one of the languages have a bug in a format string?

Not actively — it might use my browser language, which is a language
that shouldn't come as a surpris eto you however ;).

Will check.

-nik

Bug#974918: libnotcurses2,libnotcurses++2: missing Breaks+Replaces: libnotcurses1/libnotcurses++1 (>= 2)

[Nick Black]

> That would have been sufficient for the file conflict, but I assumed
> that the forgotten soname bump makes lib*1 (>= 2) not neccessarily
> broken, but at least undesired versions.

makes sense. thanks for the explanation, and thanks once again
for the bug report and your well-known vigilance!

Bug#974992: Licencing disagreement causes user confusion

[Gunnar Hjalmarsson]

Package: vrms
Version: 1.27
Severity: wishlist

Hi!

fonts-ubuntu is shipped by default on Ubuntu systems. It has significant 
reverse dependencies and cannot be uninstalled easily.


Debian considers fonts-ubuntu to be “non-free”, while Canonical 
disagrees. But vrms lists fonts-ubuntu as non-free also on Ubuntu systems.


Recently I have seen two Ask Ubuntu questions where users have run vrms, 
found fonts-ubuntu to be non-free, and tried to uninstall the package:


* https://askubuntu.com/q/1292336

* https://askubuntu.com/q/1292751

This situation is unfortunate. Given the difference in opinion, I would 
suggest that vrms does not count fonts-ubuntu as non-free when built on 
Ubuntu systems.


--
Thanks!

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#974991: sagemath: segfault on startup

[G.raud]

Package: sagemath
Version: 9.2-1
Severity: important

Dear Maintainers,

Starting sage in a terminal to get a prompt makes it segfault (it seems
related to pari).  The end of the terminal output follows and the
complete log file is attached.  Sage also segfaults when started by
jupyter.

---
$ sage
[...]
   3310 return new_gen(pari_float)

SignalError: Segmentation fault

**

Oops, Sage crashed. We do our best to make it stable, but...

A crash report was automatically generated with the following information:
  - A verbatim copy of the crash traceback.
  - A copy of your input history during this session.
  - Data on your current Sage configuration.

It was left in the file named:
'/home/restricted/.ipython/Sage_crash_report.txt'
If you can email this file to the developers, the information in it will help
them in understanding and correcting the problem.

You can mail it to: sage-support at sage-supp...@googlegroups.com
with the subject 'Sage Crash Report'.

If you want to do it now, the following command will work (under Unix):
mail -s 'Sage Crash Report' sage-supp...@googlegroups.com < 
/home/restricted/.ipython/Sage_crash_report.txt

In your email, please also include information about:
- The operating system under which the crash happened: Linux, macOS, Windows,
  other, and which exact version (for example: Ubuntu 16.04.3, macOS 10.13.2,
  Windows 10 Pro), and whether it is 32-bit or 64-bit;
- How Sage was installed: using pip or conda, from GitHub, as part of
  a Docker container, or other, providing more detail if possible;
- How to reproduce the crash: what exact sequence of instructions can one
  input to get the same crash? Ideally, find a minimal yet complete sequence
  of instructions that yields the crash.

To ensure accurate tracking of this issue, please file a report about it at:
http://trac.sagemath.org

Hit  to quit (your terminal may close):
---



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (99, 'xenial-updates'), (99, 'xenial-security'), (99, 'xenial'), 
(10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages sagemath depends on:
ii  curl  7.72.0-1
ii  cysignals-tools   1.10.2+ds-5
ii  cython3   0.29.21-3
ii  ecl   20.4.24+ds-2
ii  eclib-tools   20190909-3+b1
ii  fflas-ffpack  2.4.3-2
ii  flintqs   1:1.0-3+b1
ii  gap-atlasrep  2.1.0-3
ii  gap-dev   4.11.0-4
ii  gap-online-help   4.11.0-4
ii  gap-primgrp   3.4.0-1
ii  gap-smallgrp  1.4.1-1
ii  gap-table-of-marks1.2.9-1
ii  gap-transgrp  2.0.4-1
ii  gfan  0.6.2-2
ii  glpk-utils4.65-2
ii  gmp-ecm   7.0.4+ds-5
ii  ipython3  7.19.0-1
ii  iso-codes 4.5.0-1
ii  jmol  14.6.4+2016.11.05+dfsg1-4
ii  lcalc 1.23+dfsg-11+b1
ii  less  551-2
ii  libatlas3-base [libblas.so.3] 3.10.3-10
ii  libblas3 [libblas.so.3]   3.9.0-3
ii  libbraiding0  1.0-1+b1
ii  libbrial-groebner31.2.10-1+b1
ii  libbrial3 1.2.10-1+b1
ii  libc6 2.31-4
ii  libcdd-tools  094j-2
ii  libcliquer1   1.21-2
ii  libec520190909-3+b1
ii  libecm1   7.0.4+ds-5
ii  libflint-2.6.32.6.3-3
ii  libflint-arb2 1:2.18.1-3
ii  libgap7   4.11.0-4
ii  libgcc-s1 10.2.0-17
ii  libgd32.3.0-2
ii  libgiac0   

Bug#974989: [Freedombox-pkg-team] Bug#974989: freedombox: firstboot wizard fails in connection setup (KeyError: 'box_name')

[Petter Reinholdtsen]

[Dominik George]
> I installed the freedombox package on a pretty much vanilla Debian
> installation.
>
> The first boot wizard got as far as setting up the connection, and
> when asked how my router is set up, I chose I do not want to set it up
> right now. That caused the following exception:

Just to rule out one cause of error.  Did you select a langauge?
Perhaps one of the languages have a bug in a format string?

--
Happy hacking
Petter Reinholdtsen

Bug#974990: fonts-opendyslexic: Please package new upstream (2019.09.16 or later)

[Samuel Thibault]

Samuel Thibault, le mar. 17 nov. 2020 18:46:39 +0100, a ecrit:
> Mmm, there was already mono and alta in the existing Debian package, and
> actually on the contrary I cannot find them in the newer upstream
> release:
> 
[...]
> I'm fetching the tarballs from
> 
> https://github.com/antijingoist/opendyslexic/tags

There are actually the .glyphs file in them, I'll have a look at using
glyphslib etc.to convert to otf.

Samuel

Bug#898446: Please reconsider enabling the user namespaces by default

[Ben Hutchings]

On Tue, 2020-11-17 at 11:18 -0500, Antoine Beaupré wrote:
[...]
> Could we get a little more hard data about the attack vectors here? I
> totally trust the security team's "gut feeling" on this, but it would be
> great to be able to evaluate more concretely what we're talking about
> here.
> 
> Local root privilege escalation, basically? Can we get a sense of what
> those vulerabilities are, say with some example CVEs?

Yes, local privilege escalation.

From the advisories I've prepared, I think these are all LPEs that were
mitigated by our current patch:

CVE-2015-2041
CVE-2015-8709
CVE-2016-3134
CVE-2016-8655
CVE-2017-6346
CVE-2017-7184
CVE-2017-7308
CVE-2017-11600
CVE-2017-15649
CVE-2017-16939
CVE-2017-18509
CVE-2017-1000111
CVE-2018-16884
CVE-2019-15666
CVE-2020-14386

They seem to have slowed to a trickle at this point.  And there are
sadly lots of other LPE bugs that it has no effect on.

> I'm asking because my main concern with security these days is with the
> web browser. It's this huge gaping hole: every measure we can take to
> sandbox that thing is become more and more critical, so I wonder if the
> our tradeoff's evaluation is well adjusted here, especially considering
> a lot of user_ns consumers are bypassing those restrictions by running
> as root anyways...

I tend to agree with this.

Ben.

> It seems that, in those cases, we're getting the worst of both worlds...
> 
> a.
-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
 - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'



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

Bug#974990: fonts-opendyslexic: Please package new upstream (2019.09.16 or later)

[Samuel Thibault]

Hello,

nicoo, le mar. 17 nov. 2020 17:33:13 +0100, a ecrit:
> Please consider packaging a new version of this font,

Ah, the watch file didn't magically notice that upstream changed its URL
indeed.

> which contains additional variants, such as:

> - OpenDyslexic Mono, a high-readability monospace font, for use in consoles 
> and
>   programming;
> - OpenDyslexic Alt-A, a variant using a different glyph for A;
> - OpenDyslexic 3.

Mmm, there was already mono and alta in the existing Debian package, and
actually on the contrary I cannot find them in the newer upstream
release:

 Files in first .changes but not in second
-
-rw-r--r--  root/root   
/usr/share/fonts/opentype/opendyslexic/OpenDyslexicAlta-Bold.otf
-rw-r--r--  root/root   
/usr/share/fonts/opentype/opendyslexic/OpenDyslexicAlta-BoldItalic.otf
-rw-r--r--  root/root   
/usr/share/fonts/opentype/opendyslexic/OpenDyslexicAlta-Italic.otf
-rw-r--r--  root/root   
/usr/share/fonts/opentype/opendyslexic/OpenDyslexicAlta-Regular.otf
-rw-r--r--  root/root   
/usr/share/fonts/opentype/opendyslexic/OpenDyslexicMono-Regular.otf

I'm fetching the tarballs from

https://github.com/antijingoist/opendyslexic/tags

Samuel

Bug#974563: corosync unable to communicate with pacemaker 1.1.16-1+deb9u1 which contains the fix for CVE-2020-25654

[Alejandro Taboada]

Thank you Markus,

I just updated deb9u2 and works fine. Let me know when you have new updates and 
I can test this thing.

Regards,
Alejandro

> On 17 Nov 2020, at 05:16, Markus Koschany  wrote:
> 
> Control: severity -1 normal
> 
> Am Montag, den 16.11.2020, 09:22 -0300 schrieb Alejandro Taboada:
>> Hi Markus,
>> 
>> Sorry for the delay. With this patch works when is applied only to 1 node.
>> The services restart and the arm resources are up.
>> The problem appears again when I install the patch on a 2nd node. The the
>> resources stopped again.
> 
> Hello Alejandro,
> 
> thanks for your feedback. At the moment I cannot reproduce the problem hence I
> have reverted the patch and uploaded a new revision, 1.1.16-1+deb9u2, of
> pacemaker to stretch-security which restores the old behavior. The regression
> tests shipped with pacemaker also don't report anything unusual. I will keep
> this bug report open for discussions and work on another update. This time I
> intend to upgrade pacemaker to the latest upstream release in the 1.1.x branch
> which is currently 1.1.24~rc1. This one also includes fixes for CVE-2018-16878
> and CVE-2018-16877. I expect no big changes in terms of existing features but 
> I
> will send new packages for testing before I upload a new upstream release. 
> 
> Regards,
> 
> Markus

Bug#312935: groff-base: grotty -c should be - no it MUST be - made the default

[G. Branden Robinson]

After 15 years, I recommend closing this bug as "wontfix".

The traditional output mode only makes sense for overstriking terminals,
of which there are vanishingly few that aren't paper terminals, which
are themselves a dead breed.

The virtue of "ANSI escapes" is that they're actually standardized in
ISO 6429.  Moreover, they are known to be widely supported in many
hardware terminals and emulators.

For those with truly "dumb" terminals, "grotty -cbou" is probably a good
invocation to learn.  It can be passed through from groff with the
option "-P-cbou".  For example:

groff -Tascii -t -man -P-cbou ./build/tmac/groff_man.7 | more

The grotty(1) man page in groff 1.22.4 is significantly improved over
past versions, and the one forthcoming in groff 1.23.0 will be even
better[1].

I would appreciate knowing if the "-cbou" trick is worth explicitly
calling out there.  I use it for groff regression tests, but I don't
know how many other people would have any use for it.

Regards,
Branden

[1] https://man7.org/linux/man-pages/man1/grotty.1.html


signature.asc
Description: PGP signature