Bug#980449: vim: Change in default vim config causes obnoxious behaviour.

[Rens Houben]

In other news for Tue, Jan 19, 2021 at 09:14:59PM -0500, James McCoy has been 
seen typing:
> On Tue, Jan 19, 2021 at 10:22:35AM +0100, Rens Houben wrote:

> The terminal sends [I when focus comes back, which is what makes
> you leave insert mode () and show that popup ([I).
 
> If this were working correctly, you wouldn't have noticed a difference
> (as is the case in xterm), but there's something going on with the other
> terminals.
 
> Can you provide the package names and versions for the terminals that
> aren't working right?
 gnome-terminal 3.38.1-2, mate-terminal 1.24.1-1 and xfce4-terminal
 0.8.10-1 all exhibit this behaviour; eterm 0.9.6-6 did not, although
 given that its last update was from 2018 I suspect it simply isn't
 sending the focus events.

> Also, it would help if you ran the below command in each terminal
> (replacing  with the terminal name) and attached the resulting log
> for each.
 
> vim --cmd 'au FocusGained * call ch_log("f_in")' --cmd 'au FocusLost * call 
> ch_log("f_out")' --cmd 'call ch_logfile("focus_.log", "a")'

I've done so. There's a lot of garbled Escape codes at the end which
cause severe terminal weirdness when trying to cat the files, so I've
zipped them up. They can be retrieved at
https://chingshih.systemec.nl/focusevents.zip


> You can add the below snippet to your vimrc to disable this
> functionality:
 
Appreciated muchly. Thanks!
 
> Cheers,
> -- 
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#980526: maven: Update to maven 3.6.3-2 drops dependency to libcommons-cli-java, renders package unusable

[Michael Musenbrock]

Package: maven
Version: 3.6.3-2
Severity: grave
Justification: renders package unusable

Hi there,

first of all thanks a lot for all the work of maintaining the maven package in 
debian.

The last update to maven 3.6.3-2 in unstable dropped the dependency to 
libcommons-cli-java,
whichs renders maven unusable.

> $ mvn
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/commons/cli/ParseException
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
> at java.lang.Class.getMethod0(Class.java:3018)
> at java.lang.Class.getMethod(Class.java:1784)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.getEnhancedMainMethod(Launcher.java:168)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:261)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.cli.ParseException
> at 
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 10 more

Manually installing libcommons-cli-java resolves the issue.

hth, regards Michael


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

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

Versions of packages maven depends on:
ii  default-jre-headless [java7-runtime-headless] 2:1.11-72
ii  libjansi-java 1.18-1
ii  libmaven3-core-java   3.6.3-2
ii  libwagon-file-java3.3.4-1
ii  libwagon-http-shaded-java 3.3.4-1
ii  openjdk-11-jre-headless [java7-runtime-headless]  11.0.10+8-1
ii  openjdk-13-jre-headless [java7-runtime-headless]  13.0.5.1+1-1
ii  openjdk-14-jre-headless [java7-runtime-headless]  14.0.2+12-2
ii  openjdk-15-jre-headless [java7-runtime-headless]  15.0.1+9-3
ii  openjdk-8-jre-headless [java7-runtime-headless]   8u275-b01-1

maven recommends no packages.

maven suggests no packages.

-- no debconf information

Bug#971842: [Pkg-clamav-devel] Bug#971842: clamav-daemon erroneously reports "Failed with result 'timeout'" when stopped

[Dominik Reusser]

Dear Sebastian,

sorry for the late reply

most likely, the daemon is swapped out. We are talking about a memory
restricted system with the obligation to run daily scans on the file
system. It seems that running clamdscan with the daemon is still faster
while scanning the major part of the file system, compared to running
clamscan, even if the daemon uses some swap space.

Obviously, this setup is not optimal. I looked into running clamdscan
against a service on a different system in the same network, but this seems
not to be supported out of the box.

Would it hurt to increase the timeout or make it adjustable?

Dominik

Am Mi., 20. Jan. 2021 um 08:05 Uhr schrieb Dominik Reusser <
dr896...@gmail.com>:

>
>
> Dear Sebastian,
>
> most likely, the daemon is swapped out. We are talking about a memory
> restricted system with the obligation to run daily scans on the file
> system. It seems that running clamdscan with the daemon is still faster
> while scanning the major part of the file system, compared to running
> clamscan, even if the daemon uses some swap space.
>
> Obviously, this setup is not optimal. I looked into running clamdscan
> against a service on a different system in the same network, but this seems
> not to be supported out of the box.
>
> Would it hurt to increase the timeout or make it adjustable?
>
> Dominik
>
>
>

Bug#980523: RFS: gbsplay/0.0.94-2 -- Gameboy sound player

[Tobias Frost]

PS: I checked the dsc; 
Isee on buildd that the test only fails for s390x.
Please do only disable the test there until a solution is found.

Thanks!

-- 
tobi

Am Wed, Jan 20, 2021 at 07:19:45AM +0100 schrieb Gürkan Myczko:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "gbsplay":
> 
>  * Package name: gbsplay
>Version : 0.0.94-2
>Upstream Author : Christian Garbs 
>  * URL : https://github.com/mmitch/gbsplay
>  * License : GPL-1+, public-domain
>  * Vcs : [fill in URL of packaging vcs]
>Section : sound
> 
> It builds those binary packages:
> 
>   gbsplay - Gameboy sound player
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/gbsplay/
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/g/gbsplay/gbsplay_0.0.94-2.dsc
> 
> Changes since the last upload:
> 
>  gbsplay (0.0.94-2) unstable; urgency=medium
>  .
>* Disable tests due failure, reported upstream.
> 
> Regards,
> -- 
>   Gürkan Myczko
> 

Bug#980434: u-boot-rockchip: rockpro64-rk3399 and pinebook-pro-rk3399 fail to boot

[Vagrant Cascadian]

On 2021-01-18, Vagrant Cascadian wrote:
> both rockpro64-rk3399 and pinebook-pro-rk3399 fail to boot with
> 2021.01 (and rockpro64-rk3399 may have issues with 2020.10 as well).

Both platforms initialize USB from "preboot", but somehow this triggers
a boot failure.

This can be worked around by patching the
configs/rockpro64-rk3399_defconfig and
configs/pinebook-pro-rk3399_defconfig to use:

  CONFIG_USE_PREBOOT=n

Notably, when CONFIG_USE_PREBOOT=n is set, and manually running "usb
start" before booting, it boots fine, so there must be something about
the timing of running "usb start" from the preboot phase...

I believe both platforms also have this issue in version 2020.10, though
pinebook-pro "works fine" because it fails to detect any USB devices...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#980523: RFS: gbsplay/0.0.94-2 -- Gameboy sound player

[Tobias Frost]

Control:_tags -1 moreinfo

Can you please include the patch for #977943 as well?
(At least it is not mentioned below; did not dget the dsc)

-- 
tobi

Am Wed, Jan 20, 2021 at 07:19:45AM +0100 schrieb Gürkan Myczko:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "gbsplay":
> 
>  * Package name: gbsplay
>Version : 0.0.94-2
>Upstream Author : Christian Garbs 
>  * URL : https://github.com/mmitch/gbsplay
>  * License : GPL-1+, public-domain
>  * Vcs : [fill in URL of packaging vcs]
>Section : sound
> 
> It builds those binary packages:
> 
>   gbsplay - Gameboy sound player
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/gbsplay/
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/g/gbsplay/gbsplay_0.0.94-2.dsc
> 
> Changes since the last upload:
> 
>  gbsplay (0.0.94-2) unstable; urgency=medium
>  .
>* Disable tests due failure, reported upstream.
> 
> Regards,
> -- 
>   Gürkan Myczko
> 

Bug#980524: RFS: ancient/1.0-2 -- decompression routines for ancient formats

[Tobias Frost]

Uploaded

Am Wed, Jan 20, 2021 at 07:20:23AM +0100 schrieb Gürkan Myczko:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ancient":
> 
>  * Package name: ancient
>Version : 1.0-2
>Upstream Author : Teemu Suutari 
>  * URL : https://github.com/temisu/ancient
>  * License : BSD-variant, BSD-2-clause
>  * Vcs : https://salsa.debian.org/myczko-guest/ancient
>Section : utils
> 
> It builds those binary packages:
> 
>   ancient - decompression routines for ancient formats
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/ancient/
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/a/ancient/ancient_1.0-2.dsc
> 
> Changes since the last upload:
> 
>  ancient (1.0-2) unstable; urgency=medium
>  .
>* Source only upload.
> 
> Regards,
> -- 
>   Gürkan Myczko
> 

Bug#980525: tar: CVE-2021-20193: Memory leak in read_header() in list.c

[Salvatore Bonaccorso]

Source: tar
Version: 1.32+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://savannah.gnu.org/bugs/?59897
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 .30+dfsg-6

Hi,

The following vulnerability was published for tar.

CVE-2021-20193[0]:
| Memory leak in read_header() in list.c

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-20193
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20193
[1] https://savannah.gnu.org/bugs/?59897
[2] 
https://git.savannah.gnu.org/cgit/tar.git/commit/?id=d9d4435692150fa8ff68e1b1a473d187cc3fd777

Regards,
Salvatore

Bug#942413: [emacs] Installation of packages from GNU ELPA fails due to expired key

[era]

On Wed, 15 Jul 2020 00:00:44 -0500, Steve Suehs  wrote:
> Is it upstream 26.3 that fixes this?  What process would bring 26.3 to 
> buster?

There is no way really to get 26.3 into Buster, but there is a bug #969971 
which requests additional updates for the version in Buster to fix this.
 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969971

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#980524: RFS: ancient/1.0-2 -- decompression routines for ancient formats

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ancient
   Version : 1.0-2
   Upstream Author : Teemu Suutari 
 * URL : https://github.com/temisu/ancient
 * License : BSD-variant, BSD-2-clause
 * Vcs : https://salsa.debian.org/myczko-guest/ancient
   Section : utils

It builds those binary packages:

  ancient - decompression routines for ancient formats

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/a/ancient/ancient_1.0-2.dsc


Changes since the last upload:

 ancient (1.0-2) unstable; urgency=medium
 .
   * Source only upload.

Regards,
--
  Gürkan Myczko

Bug#980522: RFS: cadabra2/2.3.5-2 -- field-theory motivated computer algebra system

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: cadabra2
   Version : 2.3.5-2
   Upstream Author : Kasper Peeters 
 * URL : https://cadabra.science/
 * License : zlib, WTFPL-2, public-domain, MIT, OFL-1.1, GPL-3+, 
BSD-3-clause

 * Vcs : https://salsa.debian.org/myczko-guest/cadabra2
   Section : math

It builds those binary packages:

  cadabra2 - field-theory motivated computer algebra system

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/c/cadabra2/cadabra2_2.3.5-2.dsc


Changes since the last upload:

 cadabra2 (2.3.5-2) unstable; urgency=medium
 .
   * Source only upload.

Regards,
--
  Gürkan Myczko

Bug#980523: RFS: gbsplay/0.0.94-2 -- Gameboy sound player

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: gbsplay
   Version : 0.0.94-2
   Upstream Author : Christian Garbs 
 * URL : https://github.com/mmitch/gbsplay
 * License : GPL-1+, public-domain
 * Vcs : [fill in URL of packaging vcs]
   Section : sound

It builds those binary packages:

  gbsplay - Gameboy sound player

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/g/gbsplay/gbsplay_0.0.94-2.dsc


Changes since the last upload:

 gbsplay (0.0.94-2) unstable; urgency=medium
 .
   * Disable tests due failure, reported upstream.

Regards,
--
  Gürkan Myczko

Bug#969971: Also affected by the bug

[era]

The following is based on my -- possibly limited -- understanding based on 
reading through the bug reports around this.

On Wed, Jan 20, 2021, at 05:56, Deb-user wrote:
> Thank you for your reply. Yes, the workaround works, but I feel that 
> this is still a bug in the package. I'm also not sure how safe it is to 
> disable TLS 1.3.

Your options at this point are then, in no particular order;

* Live without ELPA (easy if you can live with base Emacs; hard if you need 
ELPA packages);
* Find or create a backport of the TLS1.3 handling fix yourself, and use that 
instead of the Debian-packaged Emacs;
* Turn off TLS1.3 and take steps to mitigate the risks (not sure what exactly 
that would look like in practice)

> I believe Emacs version 26.3 fixes this. I don't know how updating 
> packages works in stable releases, or if it is even possible. I am new 
> to Debian.

In normal circumstances, the "stable" version does not get updates except for 
critical security fixes. However, there was already one attempt at fixing this 
particular bug which however doesn't seem to work satisfactorily, which is 
apparently what caused this bug to be submitted.  There definitely won't be a 
26.3 in Buster, but perhaps the maintainer would still like to take another 
stab at providing a backport for 26.1 which actually works, and release that 
fix to Buster.

Perhaps see also the discussion in the linked original bug 
https://bugs.debian.org/942413

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#968181: linux-image-5.7.0-2-arm64: DRM unavailable on Rapsberry Pi 4B

[Ryutaroh Matsumoto]

Control: forwarded -1 https://github.com/raspberrypi/firmware/issues/1247
Control: tags -1 + fixed-upstream

> On the other hand, gdm3 and weston gives the following error in dmesg,
> "kernel: [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:"
> and no graphics come. Rendering by wayland does not work at all with
> vc4.ko in 5.10.9.

The above symptom is "fixed" by adding
CMA=256M@128M
to the kernel command line.

Then the gdm3 display manager starts up well, and I have
# grep -i cma /proc/meminfo 
CmaTotal: 262144 kB
CmaFree:  143008 kB

Best regards, Ryutaroh Matsumoto

Bug#980464: [Pkg-zfsonlinux-devel] Bug#980464: Bug#980464: zfs-dracut: dracut+ZFS-on-root systems rendered unbootable

[Antonio Russo]

Yes, and this is partly my fault.  I've prepared a version of this
patch [1] and forwarding it to upstream [2].  [1] Also includes
some other fixes that should get in, but weren't worth delaying
the upload for. (But this certainly is!)

/sbin is the correct place for this, right?

Antonio

[1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/35
[2] https://github.com/openzfs/zfs/pull/11485

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Pirate Praveen]

On 2021, ജനുവരി 20 2:17:50 AM IST, Maximilian Stein  wrote:
>
>> Someone else reported the artifacts issue was resolved in 13.5.6. See 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968626#40
>>
>Oh, sorry, i didn't mean artifact upload (bug 968626), but the Gitlab 
>internal artifacts that are missing from bug 977701 and break some pages.
>

Someone affected should confirm it, I confirmed issue pages that was broken is 
fixed.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#980521: /usr/bin/vim.tiny: "fail to edit/insert to file opened by vi"

[Robbi Nespu]

Package: vim-tiny
Version: 2:8.2.1913-1+b2
Severity: normal
File: /usr/bin/vim.tiny
X-Debbugs-Cc: robbine...@gmail.com

Dear Maintainer,

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

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

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


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.tiny

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

Kernel: Linux 4.4.0-18362-Microsoft
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: unable to detect

Versions of packages vim-tiny depends on:
ii  libacl1  2.2.53-9
ii  libc62.31-9
ii  libselinux1  3.1-2+b2
ii  libtinfo66.2+20201114-2
ii  vim-common   2:8.2.1913-1

vim-tiny recommends no packages.

Versions of packages vim-tiny suggests:
pn  indent  

-- no debconf information

Bug#968181: linux-image-5.7.0-2-arm64: DRM unavailable on Rapsberry Pi 4B

[Ryutaroh Matsumoto]

Hi all,

This is an update to
Bug#968181: linux-image-5.7.0-2-arm64: DRM unavailable on Rapsberry Pi 4B

I compiled Linux 5.10.9 by myself, and xinit starts fine without installing
the Debian package xserver-xorg-video-fbdev. When I originally reported this
#968181, the graphics on my raspi can only be used through 
xserver-xorg-video-fbdev.

X server works fine by using
/dev/dri/card0 on my raspi 4B 8GB model.
DRI/DRM on raspi started to partially work.

On the other hand, gdm3 and weston gives the following error in dmesg,
"kernel: [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:"
and no graphics come. Rendering by wayland does not work at all with
vc4.ko in 5.10.9.

Best regards, Ryutaroh

Bug#980520: britney: excuses: reduce verbosity of autopkgtest results

[Paul Wise]

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

The excuses page is often very verbose because of the autopkgtest
results, especially for packages with lots of reverse dependencies.

For packages where all the results are Pass, those packages could be
left out of the excuses altogether, since they don't prevent migration,
or perhaps grep-excuses should gain an option to hide them instead?

For packages where all the results are the same for every arch, the
excuses could collapse all of those packages into one line.

  • autopkgtest Regression for foo bar baz
  • autopkgtest Ignored failure for foo bar baz
  • autopkgtest Pass for foo bar baz

For packages with multiple arches you could group arches by the status
rather than printing the status for each architecture, since the
architecture names are shorter than the status texts.

  • autopkgtest for foo/1.2-3: Regression: amd64 arm64 armhf, Ignored failure: 
ppc64el: Ignored failure, Pass: i386

The combination of these ideas would result in less verbose excuses.

Here is an example of a long version of the excuses:

   $ grep-excuses -w pytest
   Excuse for pytest
   
 • Migration status for pytest (4.6.11-1 to 6.0.2-2): BLOCKED: 
Rejected/violates migration policy/introduces a regression
 • Issues preventing migration:
 • autopkgtest for dask.distributed/2.10.0+ds.1-3: amd64: Ignored failure, 
arm64: Ignored failure, armhf: Ignored failure, i386: Ignored failure, ppc64el: 
Ignored failure
 • autopkgtest for docopt/0.6.2-2.2: amd64: Regression ♻ (reference ♻), 
arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
Regression ♻ (reference ♻), ppc64el
   : Regression ♻ (reference ♻)
 • autopkgtest for git-big-picture/0.10.1-1: armhf: Pass, i386: Pass, 
ppc64el: Pass
 • autopkgtest for html5lib/1.1-2: amd64: Regression ♻ (reference ♻), 
arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
Regression ♻ (reference ♻), ppc64el:
   Regression ♻ (reference ♻)
 • autopkgtest for ipykernel/5.4.2-1: ppc64el: Pass
 • autopkgtest for jupyter-client/6.1.6-1: ppc64el: Pass
 • autopkgtest for jupyter-notebook/6.1.6-2: armhf: Pass, i386: Pass, 
ppc64el: Pass
 • autopkgtest for nbformat/5.0.8-1: armhf: Pass, i386: Pass, ppc64el: Pass
 • autopkgtest for pytest-doctestplus/0.7.0-2: armhf: Pass, i386: Pass, 
ppc64el: Pass
 • autopkgtest for pytest-mpi/0.4-2: amd64: Regression ♻ (reference ♻), 
arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
Regression ♻ (reference ♻), ppc64el
   : Regression ♻ (reference ♻)
 • autopkgtest for python-dugong/3.7.4+dfsg-2: amd64: Regression ♻ 
(reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ 
(reference ♻), i386: Regression ♻ (reference ♻
   ), ppc64el: Regression ♻ (reference ♻)
 • autopkgtest for python-llfuse/1.3.6+dfsg-2: amd64: Regression ♻ 
(reference ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ 
(reference ♻), i386: Regression ♻ (reference ♻
   ), ppc64el: Regression ♻ (reference ♻)
 • autopkgtest for python-mechanicalsoup/0.10.0-3: armhf: Regression ♻ 
(reference ♻), i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ 
(reference ♻)
 • autopkgtest for python-pymeasure/0.5-1: amd64: Regression ♻ (reference 
♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
Regression ♻ (reference ♻),
   ppc64el: Regression ♻ (reference ♻)
 • autopkgtest for reprotest/0.7.15: amd64: Pass, arm64: Ignored failure, 
armhf: Ignored failure, i386: Ignored failure, ppc64el: Pass
 • autopkgtest for sphinx-argparse/0.2.2-3: amd64: Regression ♻ (reference 
♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
Regression ♻ (reference ♻),
   ppc64el: Regression ♻ (reference ♻)
 • autopkgtest for sqlparse/0.3.1-1: amd64: Regression ♻ (reference ♻), 
arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
Regression ♻ (reference ♻), ppc64el
   : Regression ♻ (reference ♻)
 • autopkgtest for statsmodels/0.12.1-1: amd64: Pass, armhf: Pass, i386: 
Pass, ppc64el: Pass
 • autopkgtest for sunpy/2.0.5-1: armhf: Pass, i386: Pass, ppc64el: Pass
 • autopkgtest for xonsh/0.9.24+dfsg-2: armhf: Regression ♻ (reference ♻), 
i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻)
 • Implicit dependency: pytest python-pytest-asyncio
 • Additional info:
 • Updating pytest fixes old bugs: #978289
 • Piuparts tested OK - https://piuparts.debian.org/sid/source/p/pytest.html
 • 17 days old (needed 5 days)
 • Depends: pytest python-pytest-asyncio

   Excuses generated Wed Jan 20 04:11:43 2021

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#968188: 968188 seems fixed upstream

[Ryutaroh Matsumoto]

Control: tags -1 + fixed-upstream

I compiled the upstream kernel 5.10.8 and it can use 4K resolution. Ryutaroh

Bug#980519: RM: ntlmaps -- RoQA; python2 removal, unmaintained, low popcon

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-Cc: ntlm...@packages.debian.org

Dear ftp masters,

this package last saw a maintainer upload 12 years ago, and the last NMU
was in 2015.
popcon is very lwo, and the project homepage is from 2008.

coupled with the py2 removal, please drop this package.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#980464: zfs-dracut: dracut+ZFS-on-root systems rendered unbootable

[M. Zhou]

Control: severity -1 important

Lowering the severity to unblock the migration, as migration is
currently the first priority for us due to the huge diff between
0.8.6 and 2.0.1, given the stable freeze schedule.

I will fix it and upload 2.0.1-3 immediately after migration.

It is easy to apply for freeze exceptions for such important bugfix
that does not involve a big diff. In contrast, exception for the
0.8.6 -> 2.0.1 change is impossible to get approved. 

Bug#980230: fonts-allerta is proposing 2 font files but LibreOffice is proposing only one

[Gürkan Myczko]

Hi Serge

Thank you for your bug report. I'm able to reproduce the problem in 
libreoffice as well as inkscape.


However there seems to be no problem with gedit(gnome) nor gnustep, see 
these as reference:

http://bootes.ethz.ch/allerta/

Upstream is in Cc:, Matt, do you think you can do something about it?

Best regards,

Bug#980518: libmkl-interface-dev: Fails to update and puts package system in a broken state

[Witold Baryluk]

Package: libmkl-interface-dev
Version: 2020.3.279-1
Severity: serious
Justification: packaging issue
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

root@debian:~# apt dist-upgrade --purge
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  libiniparser1
The following packages will be upgraded:
  apparmor aspell-de chafa cryptsetup cryptsetup-bin cryptsetup-initramfs 
cryptsetup-run dh-strip-nondeterminism dosbox flatpak fldigi gcr 
gnome-desktop3-data gnuradio gnuradio-dev htop
  hunspell-bg hunspell-bs hunspell-cs hunspell-da hunspell-de-at hunspell-de-ch 
hunspell-de-de hunspell-el hunspell-en-gb hunspell-gl hunspell-gl-es 
hunspell-gu hunspell-hi hunspell-hr
  hunspell-hu hunspell-id hunspell-is hunspell-it hunspell-kmr hunspell-lt 
hunspell-ne hunspell-pl hunspell-pt-br hunspell-pt-pt hunspell-ro hunspell-ru 
hunspell-si hunspell-sl hunspell-sr
  hunspell-sv hunspell-sv-se hunspell-te hunspell-th hunspell-vi hyphen-de 
hyphen-hr hyphen-hu hyphen-lt ingerman intel-mkl-doc iptables iswiss 
libapparmor1 libchafa0 libcryptsetup12
  libfile-stripnondeterminism-perl libgck-1-0 libgcr-base-3-1 libgcr-ui-3-1 
libgnome-desktop-3-19 libgnuradio-analog3.8.2 libgnuradio-audio3.8.2 
libgnuradio-blocks3.8.2
  libgnuradio-channels3.8.2 libgnuradio-digital3.8.2 libgnuradio-dtv3.8.2 
libgnuradio-fec3.8.2 libgnuradio-fft3.8.2 libgnuradio-filter3.8.2 
libgnuradio-pmt3.8.2 libgnuradio-qtgui3.8.2
  libgnuradio-runtime3.8.2 libgnuradio-trellis3.8.2 libgnuradio-uhd3.8.2 
libgnuradio-video-sdl3.8.2 libgnuradio-vocoder3.8.2 libgnuradio-wavelet3.8.2 
libgnuradio-zeromq3.8.2
  libgucharmap-2-90-7 libip4tc2 libip6tc2 liblilv-0-0 libmkl-avx 
libmkl-avx:i386 libmkl-avx2 libmkl-avx2:i386 libmkl-avx512 libmkl-avx512:i386 
libmkl-avx512-mic libmkl-computational-dev
  libmkl-computational-dev:i386 libmkl-core libmkl-core:i386 libmkl-def 
libmkl-dev libmkl-full-dev libmkl-gf:i386 libmkl-gf-ilp64 libmkl-gf-lp64 
libmkl-gnu-thread libmkl-gnu-thread:i386
  libmkl-intel:i386 libmkl-intel-ilp64 libmkl-intel-lp64 libmkl-intel-thread 
libmkl-intel-thread:i386 libmkl-interface-dev libmkl-interface-dev:i386 
libmkl-locale libmkl-mc libmkl-mc3
  libmkl-meta-computational libmkl-meta-computational:i386 
libmkl-meta-interface libmkl-meta-interface:i386 libmkl-meta-threading 
libmkl-meta-threading:i386 libmkl-p4:i386 libmkl-p4m:i386
  libmkl-p4m3:i386 libmkl-pgi-thread libmkl-rt libmkl-sequential 
libmkl-sequential:i386 libmkl-tbb-thread libmkl-tbb-thread:i386 
libmkl-threading-dev libmkl-threading-dev:i386
  libmkl-vml-avx libmkl-vml-avx:i386 libmkl-vml-avx2 libmkl-vml-avx2:i386 
libmkl-vml-avx512 libmkl-vml-avx512:i386 libmkl-vml-avx512-mic libmkl-vml-cmpt 
libmkl-vml-cmpt:i386 libmkl-vml-def
  libmkl-vml-ia:i386 libmkl-vml-mc libmkl-vml-mc2 libmkl-vml-mc3 
libmkl-vml-p4:i386 libmkl-vml-p4m:i386 libmkl-vml-p4m2:i386 
libmkl-vml-p4m3:i386 libserf-1-1 libsord-0-0 libsratom-0-0
  libssl-dev libssl1.1 libssl1.1:i386 libu2f-udev libxtables12 mblaze mtd-utils 
mythes-cs mythes-en-us mythes-fr mythes-it mythes-ne mythes-ru mythes-sk 
openssl pev
  picolibc-xtensa-lx106-elf texlive-base texlive-fonts-extra 
texlive-fonts-extra-links texlive-fonts-recommended texlive-latex-base 
texlive-latex-extra texlive-latex-recommended
  texlive-pictures texlive-plain-generic time vim-common vim-tiny wngerman 
wswiss xonsh xxd yelp-xsl youtube-dl
190 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,112 MB of archives.
After this operation, 81.8 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 714720 files and directories currently installed.)
Preparing to unpack .../000-libssl-dev_1.1.1i-2_amd64.deb ...
Unpacking libssl-dev:amd64 (1.1.1i-2) over (1.1.1i-1) 
]
 
...
...
...
Preparing to unpack .../094-libiniparser1_4.1-4_amd64.deb ...
Unpacking libiniparser1:amd64 (4.1-4) ...
Preparing to unpack .../095-libsord-0-0_0.16.8-1_amd64.deb ...
Unpacking libsord-0-0:amd64 (0.16.8-1) over (0.16.6-1) ...
Preparing to unpack .../096-libsratom-0-0_0.6.8-1_amd64.deb ...
Unpacking libsratom-0-0:amd64 (0.6.8-1) over (0.6.6-1) ...
Preparing to unpack .../097-liblilv-0-0_0.24.12-1_amd64.deb ...
Unpacking liblilv-0-0:amd64 (0.24.12-1) over (0.24.10-1) ...
Preparing to unpack .../098-libmkl-interface-dev_2020.4.304-1_i386.deb ...
De-configuring libmkl-interface-dev:amd64 (2020.3.279-1) ...
Unpacking libmkl-interface-dev:i386 (2020.4.304-1) over (2020.3.279-1) ...
Preparing to unpack .../099-libmkl-interface-dev_2020.4.304-1_amd64.deb ...
Unpacking libmkl-interface-dev:amd64 (2020.4.304-1) over (2020.3.279-1) ...
dpkg: error processing archive 

Bug#980517: debsums: Parallel checking

[Witold Baryluk]

Package: debsums
Version: 3.0.1
Severity: minor
X-Debbugs-Cc: witold.bary...@gmail.com

Hi.

On my 32 core system, and a lot of packages installed (~7000), it takes
about one hour for the debsum to check all the files. Despite ability to
read all files from the storage in about 4 minutes. The issue is use of
just one thread and most likely not optimized md5sum implementation.

I think it would be very useful to be able to specify number of parallel
threads to use when doing checking manually or from cron. I think it
would even be good to enable it by default. (for the case of use from
cron, usage of nice / schedtool and/or ionice could mitigate any issues
on server or laptops).

Regards,
Witold


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

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

Versions of packages debsums depends on:
ii  libdpkg-perl  1.20.7.1
ii  libfile-fnmatch-perl  0.02-2+b8
ii  perl  5.32.0-6
ii  ucf   3.0043

debsums recommends no packages.

Versions of packages debsums suggests:
ii  bash-completion  1:2.11-2

-- no debconf information

Bug#957116: cyclades-serial-client: ftbfs with GCC-10

[Logan Rosen]

Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * Fix FTBFS with GCC 10 due to multiple definitions.

Thanks for considering the patch.

Logan
diff -Nru cyclades-serial-client-0.93ubuntu2/inc/dev.h 
cyclades-serial-client-0.93ubuntu3/inc/dev.h
--- cyclades-serial-client-0.93ubuntu2/inc/dev.h2003-08-05 
00:25:11.0 -0400
+++ cyclades-serial-client-0.93ubuntu3/inc/dev.h2021-01-19 
23:13:52.0 -0500
@@ -47,12 +47,12 @@
 /* handle for pty slave */
 EXTERN int P_sfd;
 /* handle for control socket listener */
-EXTERN int P_contr_listen;
+extern int P_contr_listen;
 /* handle for control socket */
 #define MAX_CONTROL_SOCKS 32
-EXTERN int P_contr[MAX_CONTROL_SOCKS];
+extern int P_contr[MAX_CONTROL_SOCKS];
 /* struct for port information */
-EXTERN struct comport  Comport;
+extern struct comport  Comport;
 /* device name */
 EXTERN charP_devname[NAMESIZE];
 /* control socket name */
diff -Nru cyclades-serial-client-0.93ubuntu2/inc/telnet.h 
cyclades-serial-client-0.93ubuntu3/inc/telnet.h
--- cyclades-serial-client-0.93ubuntu2/inc/telnet.h 2003-07-25 
08:25:09.0 -0400
+++ cyclades-serial-client-0.93ubuntu3/inc/telnet.h 2021-01-19 
23:11:37.0 -0500
@@ -42,7 +42,7 @@
 
 # define NVT_NUMOPTS   256
 
-int NvtOptions[NVT_NUMOPTS];
+extern int NvtOptions[NVT_NUMOPTS];
 
 # define I_WILL0x01/* I desire to support it */
 # define I_DO  0x02/* I do support it */
@@ -123,7 +123,7 @@
  * State control of NVT Com Port Commands
  */
 
-int CmdState[NUM_COMCMDS];
+extern int CmdState[NUM_COMCMDS];
 
 # define CMD_INACTIVE  0
 # define CMD_ACTIVE1
diff -Nru cyclades-serial-client-0.93ubuntu2/inc/tsrio.h 
cyclades-serial-client-0.93ubuntu3/inc/tsrio.h
--- cyclades-serial-client-0.93ubuntu2/inc/tsrio.h  2003-07-25 
08:24:37.0 -0400
+++ cyclades-serial-client-0.93ubuntu3/inc/tsrio.h  2021-01-19 
23:10:50.0 -0500
@@ -273,9 +273,9 @@
 # define MAX_EVENTS20
 # define EVENT_PARAMSZ 128
 
-struct event   Eventpoll[MAX_EVENTS];
+extern struct eventEventpoll[MAX_EVENTS];
 
-struct event   Evhead;
+extern struct eventEvhead;
 
 # define INIT_EVENTS() Evhead.ev_last = Evhead.ev_next = 
 
diff -Nru cyclades-serial-client-0.93ubuntu2/telnet.c 
cyclades-serial-client-0.93ubuntu3/telnet.c
--- cyclades-serial-client-0.93ubuntu2/telnet.c 2003-07-25 08:25:49.0 
-0400
+++ cyclades-serial-client-0.93ubuntu3/telnet.c 2021-01-19 23:11:29.0 
-0500
@@ -79,6 +79,10 @@
 unsigned char Comibuf[SOCK_MAXIOSZ];
 unsigned char Comobuf[SOCK_MAXIOSZ];
 
+int NvtOptions[NVT_NUMOPTS];
+
+int CmdState[NUM_COMCMDS];
+
 /*
  * Telnet Protocol Access Routines 
  */
diff -Nru cyclades-serial-client-0.93ubuntu2/tsrio.c 
cyclades-serial-client-0.93ubuntu3/tsrio.c
--- cyclades-serial-client-0.93ubuntu2/tsrio.c  2003-07-25 08:24:08.0 
-0400
+++ cyclades-serial-client-0.93ubuntu3/tsrio.c  2021-01-19 23:10:46.0 
-0500
@@ -90,6 +90,10 @@
 "EV_RNWROK",
 };
 
+struct event   Eventpoll[MAX_EVENTS];
+
+struct event   Evhead;
+
 /*
  * Main Scheduler Routines
  */

Bug#892082: Related bug??

[Charles Curley]

I wonder if this is related to a bug I hit -- and I may have solved.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980271#15 for the
details and a workaround.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#980516: mate-power-manager: Crashes soon after startup

[Witold Baryluk]

Package: mate-power-manager
Version: 1.24.2-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com


I got a freshly installed system, and something is not right with the 
mate-power-manager.

After starting it up, it works for a bit, then after about 2 minutes crashes.

This on desktop, with AMD Threadripper 2950X.

user@debian:~$ gdb --args mate-power-manager
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from mate-power-manager...
(No debugging symbols found in mate-power-manager)
(gdb) r
Starting program: /usr/bin/mate-power-manager 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x75499700 (LWP 7492)]
[New Thread 0x74c98700 (LWP 7493)]
[New Thread 0x7fffe700 (LWP 7494)]

(mate-power-manager:7487): libupower-glib-WARNING **: 04:02:30.152: Couldn't 
connect to proxy: Error calling StartServiceByName for org.freedesktop.UPower: 
Failed to activate service 'org.freedesktop.UPower': timed out 
(service_start_timeout=25000ms)

(mate-power-manager:7487): GLib-GObject-WARNING **: 04:02:30.152: invalid 
(NULL) pointer instance

(mate-power-manager:7487): GLib-GObject-CRITICAL **: 04:02:30.152: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(mate-power-manager:7487): GLib-GObject-WARNING **: 04:02:30.152: invalid 
(NULL) pointer instance

(mate-power-manager:7487): GLib-GObject-CRITICAL **: 04:02:30.152: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(mate-power-manager:7487): GLib-GObject-CRITICAL **: 04:02:30.152: 
g_object_get: assertion 'G_IS_OBJECT (object)' failed

(mate-power-manager:7487): libupower-glib-WARNING **: 04:02:55.178: Couldn't 
connect to proxy: Error calling StartServiceByName for org.freedesktop.UPower: 
Timeout was reached

(mate-power-manager:7487): libupower-glib-CRITICAL **: 04:02:55.178: 
up_client_get_lid_is_closed: assertion 'UP_IS_CLIENT (client)' failed

(mate-power-manager:7487): GLib-GObject-WARNING **: 04:02:55.178: invalid 
(NULL) pointer instance

(mate-power-manager:7487): GLib-GObject-CRITICAL **: 04:02:55.178: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(mate-power-manager:7487): libupower-glib-WARNING **: 04:03:20.198: Couldn't 
connect to proxy: Error calling StartServiceByName for org.freedesktop.UPower: 
Failed to activate service 'org.freedesktop.UPower': timed out 
(service_start_timeout=25000ms)

(mate-power-manager:7487): GLib-GObject-WARNING **: 04:03:20.198: invalid 
(NULL) pointer instance

(mate-power-manager:7487): GLib-GObject-CRITICAL **: 04:03:20.198: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
[Detaching after fork from child process 7536]
Could not connect to UPower system bus: Error calling StartServiceByName for 
org.freedesktop.UPower: Timeout was reached
(mate-power-manager:7487): libupower-glib-WARNING **: 04:04:10.250: Couldn't 
connect to proxy: Error calling StartServiceByName for org.freedesktop.UPower: 
Timeout was reached

(mate-power-manager:7487): GLib-GObject-WARNING **: 04:04:10.251: invalid 
(NULL) pointer instance

(mate-power-manager:7487): GLib-GObject-CRITICAL **: 04:04:10.251: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(mate-power-manager:7487): GLib-GObject-CRITICAL **: 04:04:10.251: 
g_object_get: assertion 'G_IS_OBJECT (object)' failed

(mate-power-manager:7487): libupower-glib-WARNING **: 04:04:35.253: Couldn't 
connect to proxy: Error calling StartServiceByName for org.freedesktop.UPower: 
Timeout was reached

(mate-power-manager:7487): GLib-GObject-WARNING **: 04:04:35.253: invalid 
(NULL) pointer instance

(mate-power-manager:7487): GLib-GObject-CRITICAL **: 04:04:35.253: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(mate-power-manager:7487): GLib-GObject-WARNING **: 04:04:35.253: invalid 
(NULL) pointer instance

(mate-power-manager:7487): GLib-GObject-CRITICAL **: 04:04:35.253: 
g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
[New Thread 0x7fffef7fe700 (LWP 7787)]
[Thread 0x7fffef7fe700 (LWP 7787) exited]

(mate-power-manager:7487): GLib-GObject-WARNING **: 04:05:00.267: invalid 
(NULL) pointer instance

Bug#969971: Also affected by the bug

[Deb-user]

Hello era,

Thank you for your reply. Yes, the workaround works, but I feel that 
this is still a bug in the package. I'm also not sure how safe it is to 
disable TLS 1.3.


I believe Emacs version 26.3 fixes this. I don't know how updating 
packages works in stable releases, or if it is even possible. I am new 
to Debian.


Regards.

On 2021-01-19 15:32, era wrote:

On Tue, Jan 19, 2021, at 22:31, Deb-user wrote:

I am also affected by the same bug in Debian stable (buster). How can we
deal with this?


The bug report you are responding to includes instructions for working around 
the problem. Do those not work for you?

/* era */

Bug#980515: dump1090-mutability: FTBFS with GCC 10

[Logan Rosen]

Source: dump1090-mutability
Version: 1.15~20180310.4a16df3+dfsg-6
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi,

dump1090-mutability FTBFS with GCC 10. [1] This is due to multiple
defintions of a variable (GCC 10 enables -fno-common by default).

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/05-gcc-10.patch: Cherrypick upstream Git commit to fix FTBFS with GCC
10.

Thanks for considering the patch.

Logan

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dump1090-mutability.html
diff -Nru 
dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/patches/05-gcc-10.patch 
dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/patches/05-gcc-10.patch
--- 
dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/patches/05-gcc-10.patch   
1969-12-31 19:00:00.0 -0500
+++ 
dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/patches/05-gcc-10.patch   
2021-01-19 22:36:11.0 -0500
@@ -0,0 +1,72 @@
+From 0793c64ee8ebbcea86b7a9dc71c7e28ec08db618 Mon Sep 17 00:00:00 2001
+From: Oliver Jowett 
+Date: Sat, 6 Jun 2020 21:52:04 +0800
+Subject: [PATCH] Clean up linkage of struct Modes to actually make sense.
+
+(how did this work before? But it's been unchanged since at least
+2013..)
+
+Maybe fixes #65
+---
+ dump1090.c | 2 ++
+ dump1090.h | 6 --
+ faup1090.c | 2 ++
+ view1090.c | 3 +++
+ 4 files changed, 11 insertions(+), 2 deletions(-)
+
+--- a/dump1090.c
 b/dump1090.c
+@@ -55,6 +55,8 @@
+ 
+ static int verbose_device_search(char *s);
+ 
++struct _Modes Modes;
++
+ //
+ // = Utility functions ==
+ //
+--- a/dump1090.h
 b/dump1090.h
+@@ -263,7 +263,7 @@
+ };
+ 
+ // Program global state
+-struct { // Internal state
++struct _Modes { // Internal state
+ pthread_t   reader_thread;
+ 
+ pthread_mutex_t data_mutex;  // Mutex to synchronize buffer access
+@@ -378,7 +378,9 @@
+ int stats_latest_1min;
+ struct stats stats_5min;
+ struct stats stats_15min;
+-} Modes;
++};
++
++extern struct _Modes Modes;
+ 
+ // The struct we use to store information about a decoded message.
+ struct modesMessage {
+--- a/faup1090.c
 b/faup1090.c
+@@ -49,6 +49,8 @@
+ 
+ #include "dump1090.h"
+ 
++struct _Modes Modes;
++
+ #include 
+ 
+ //
+--- a/view1090.c
 b/view1090.c
+@@ -28,6 +28,9 @@
+ // OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ //
+ #include "dump1090.h"
++
++struct _Modes Modes;
++
+ //
+ // = Utility functions ==
+ //
diff -Nru dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/patches/series 
dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/patches/series
--- dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/patches/series
2018-12-21 04:34:58.0 -0500
+++ dump1090-mutability-1.15~20180310.4a16df3+dfsg/debian/patches/series
2021-01-19 22:36:06.0 -0500
@@ -2,3 +2,4 @@
 02-excanvas.patch
 03-gcc7.patch
 04-link-order.patch
+05-gcc-10.patch

Bug#957157: dvi2ps: ftbfs with GCC-10

[Logan Rosen]

Package: dvi2ps
Version: 5.1j-1.3
Followup-For: Bug #957157
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10.patch: Mark variable as extern to fix FTBFS with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru dvi2ps-5.1j/debian/patches/gcc-10.patch 
dvi2ps-5.1j/debian/patches/gcc-10.patch
--- dvi2ps-5.1j/debian/patches/gcc-10.patch 1969-12-31 19:00:00.0 
-0500
+++ dvi2ps-5.1j/debian/patches/gcc-10.patch 2021-01-19 22:25:16.0 
-0500
@@ -0,0 +1,11 @@
+--- a/global.h
 b/global.h
+@@ -126,7 +126,7 @@
+  * Interface with device driver
+  */
+ /* ps.c */
+-BOOLEAN landscape;
++extern BOOLEAN landscape;
+ float dev_fontmag();
+ 
+ /* psspecial.c */
diff -Nru dvi2ps-5.1j/debian/patches/series dvi2ps-5.1j/debian/patches/series
--- dvi2ps-5.1j/debian/patches/series   2019-02-17 07:29:43.0 -0500
+++ dvi2ps-5.1j/debian/patches/series   2021-01-19 22:23:52.0 -0500
@@ -5,3 +5,4 @@
 08_kpse_set_program_name.patch
 09_freetype_header.patch
 freetype2_pkg-config.patch
+gcc-10.patch

Bug#957165: efax-gtk: ftbfs with GCC-10

[Logan Rosen]

Package: efax-gtk
Version: 3.2.8-2.1
Followup-For: Bug #957165
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10: Cherrypick/adapt upstream Git commit to fix FTBFS with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru efax-gtk-3.2.8/debian/patches/gcc-10 
efax-gtk-3.2.8/debian/patches/gcc-10
--- efax-gtk-3.2.8/debian/patches/gcc-101969-12-31 19:00:00.0 
-0500
+++ efax-gtk-3.2.8/debian/patches/gcc-102021-01-19 22:05:35.0 
-0500
@@ -0,0 +1,36 @@
+From 2158c724571bb424b0c20a071c3de17da5f2becb Mon Sep 17 00:00:00 2001
+From: Chris Vine 
+Date: Tue, 2 Jun 2020 23:37:47 +0100
+Subject: [PATCH] Fix build for gcc-10
+
+---
+ ChangeLog   |   6 ++
+ efax/Makefile.am|   3 +-
+ efax/efaxlib.c  |   2 +
+ efax/efaxlib.h  |   2 +-
+ efax/efaxlib.h.orig | 226 
+ 5 files changed, 237 insertions(+), 2 deletions(-)
+ create mode 100644 efax/efaxlib.h.orig
+
+--- a/efax/efaxlib.c
 b/efax/efaxlib.c
+@@ -27,6 +27,8 @@
+ #define DEFWIDTH  1728/* 215x297 mm image at fax resolution */
+ #define DEFHEIGHT 2287
+ 
++uchar reversebits [ 256 ], normalbits [ 256 ] ;
++
+ extern t4tab wtab [ ( 64 + 27 + 13 ) + 1 ] ; /* T.4 coding tables */
+ extern t4tab btab [ ( 64 + 27 + 13 ) + 1 ] ;
+ 
+--- a/efax/efaxlib.h
 b/efax/efaxlib.h
+@@ -208,7 +208,7 @@
+ /* Bit reversal lookup tables (note that the `normalbits' array
+is the one actually used for the bit reversal.  */
+ 
+-uchar reversebits [ 256 ], normalbits [ 256 ] ;
++extern uchar reversebits [ 256 ], normalbits [ 256 ] ;
+ 
+ void initbittab(void) ;
+ 
diff -Nru efax-gtk-3.2.8/debian/patches/series 
efax-gtk-3.2.8/debian/patches/series
--- efax-gtk-3.2.8/debian/patches/series2010-11-13 14:26:08.0 
-0500
+++ efax-gtk-3.2.8/debian/patches/series2021-01-19 22:03:48.0 
-0500
@@ -1,2 +1,3 @@
 desktop
 efax-manpages
+gcc-10

Bug#980514: p910nd: new upstream location on GitHub

[Paul Wise]

Source: p910nd
Severity: wishlist

The SourceForge project page says that p910nd has been moved to GitHub,
please switch the Homepage, watch file etc to the new location.

   $ curl -s https://sourceforge.net/projects/p910nd/ | html2markdown | grep 
-B1 github
   [ As of 2020-09-29, this project can be found here.
   ](https://github.com/kenyapcomau/p910nd)
   
In addition, the author explicitly requests contributors, so please
forward the Debian patches to them and suggest that they visit Repology
to find bugs and patches for all the distributions.

https://repology.org/project/p910nd/packages

   $ curl -sL https://github.com/kenyapcomau/p910nd/raw/master/README.md | grep 
-i github
   Note that this is the same version as the last released version from
   2014. No features have been added, nor any bugs fixed from that
   version. Several distributions have packaged this software ready to
   use. If you are not a developer there is no advantage to cloning this
   repository. The move to Github is to facilitate any submission of bug
   fixes and contributions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#980498: guile-3.0 FTBFS on amd64: check-guile fails

[Rob Browning]

forwarded 980498 bug-gu...@gnu.org
thanks

Helmut Grohne  writes:

> guile-3.0 failed to build from source on the buildd on amd64. It is hard
> to pin down the actual failure. It happens during unit tests.
> https://buildd.debian.org/status/fetch.php?pkg=guile-3.0=amd64=3.0.5-1=1610521112=0
> is a link to a failing build log.

Right, I brought this up on #guile, but no further information yet, and
just a bit ago filed an upstream bug: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46001

> The armel build failed differently. It timed out via not producing any
> output in 5 minutes. kfreebsd-amd64 and kfreebsd-i396 seem to have
> failed in the same way as amd64.

I wonder if this might be time-limit related (again). cf.
https://salsa.debian.org/rlb/deb-guile/-/blob/deb/guile-3.0/d/sid/master/debian/rules#L187-195

Though 3.0 is much better on that front than 2.2 was.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#892275: redshift: Unable to connect to GeoClue.

[Witold Baryluk]

Package: redshift
Version: 1.12-4
Followup-For: Bug #892275
X-Debbugs-Cc: witold.bary...@gmail.com

I believe it was working before. Now it fails for me too on log in with a
dialog showing it can't connect to geoclue.

user@debian:~$ systemctl --user status redshift
● redshift.service - Redshift display colour temperature adjustment
 Loaded: loaded (/usr/lib/systemd/user/redshift.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Wed 2021-01-20 01:46:56 UTC; 
33min ago
   Docs: http://jonls.dk/redshift/
Process: 2367 ExecStart=/usr/bin/redshift (code=exited, status=1/FAILURE)
   Main PID: 2367 (code=exited, status=1/FAILURE)
CPU: 4ms

Jan 20 01:46:56 debian systemd[2275]: redshift.service: Scheduled restart job, 
restart counter is at 5.
Jan 20 01:46:56 debian systemd[2275]: Stopped Redshift display colour 
temperature adjustment.
Jan 20 01:46:56 debian systemd[2275]: redshift.service: Start request repeated 
too quickly.
Jan 20 01:46:56 debian systemd[2275]: redshift.service: Failed with result 
'exit-code'.
Jan 20 01:46:56 debian systemd[2275]: Failed to start Redshift display colour 
temperature adjustment.
user@debian:~$

$ pgrep -a redshift
2972 /usr/bin/python3 /usr/bin/redshift-gtk
2973 /usr/bin/redshift -v
$

This is a default install of packages, on a clean system.

$ dpkg -l | grep geoclue
ii  geoclue-2-demo  2.5.7-2 
amd64geoinformation service (demonstration programs)
ii  geoclue-2.0 2.5.7-2 
amd64geoinformation service
ii  libgeoclue-2-0:amd642.5.7-2 
amd64convenience library to interact with 
geoinformation service
$

Screenshot in the attachment.


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

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

Versions of packages redshift depends on:
ii  init-system-helpers  1.60
ii  libc62.31-9
ii  libdrm2  2.4.103-2
ii  libglib2.0-0 2.66.4-1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libx11-6 2:1.7.0-2
ii  libxcb-randr01.14-2.1
ii  libxcb1  1.14-2.1
ii  libxxf86vm1  1:1.1.4-1+b2

Versions of packages redshift recommends:
ii  geoclue-2.0  2.5.7-2

redshift suggests no packages.

-- no debconf information

Bug#980449: vim: Change in default vim config causes obnoxious behaviour.

[James McCoy]

On Tue, Jan 19, 2021 at 10:22:35AM +0100, Rens Houben wrote:
> Since an update to /some/ part of vim on unstable sometime last weekend I've 
> encountered new default behaviour that's quite disruptive.
> 
> For instance, when I started writing this, as well as every single time this
> terminal window gains or loses focus, vim fires a console beep and gives a
> popup of the following two lines:
> 
> ---
> /tmp/reportbug-vim-20210119-44233-2mw9ao7j
>   1:1 Subject: vim: Change in default vim config causes obnoxious 
> behaviour.
> ---

It sounds like this is some interaction with the recent change to allow
Vim to receive events from the terminal when focus is gained/lost.  This
is described in ":help xterm-focus-event".

The terminal sends [I when focus comes back, which is what makes
you leave insert mode () and show that popup ([I).

If this were working correctly, you wouldn't have noticed a difference
(as is the case in xterm), but there's something going on with the other
terminals.

Can you provide the package names and versions for the terminals that
aren't working right?

Also, it would help if you ran the below command in each terminal
(replacing  with the terminal name) and attached the resulting log
for each.

vim --cmd 'au FocusGained * call ch_log("f_in")' --cmd 'au FocusLost * call 
ch_log("f_out")' --cmd 'call ch_logfile("focus_.log", "a")'

In each terminal, once Vim starts please switch to another application,
back to the terminal, and then exit Vim.  That will capture the terminal
codes that Vim sends and the responses from the terminal so we can try
and figure out where things are going wrong.

>I expected vim to keep working as it has for several decades and default
> to /not/ cause this new behaviour, or at least properly document the change
> so I'd have an idea what feature to turn off.

You can add the below snippet to your vimrc to disable this
functionality:

if exists('+t_fd')
  set t_fd=
  set t_fe=
endif

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

Bug#976244: RFA: sudo -- Provide limited super user privileges to specific users

[Eduardo Pires]

Hi Bdale,

After many years using Linux and Debian I wanted to try to give back to the 
project and I started looking where I could help.

I checked the bug board and would be willing commit to it. I understand that 
you would like to retire from it, but if you agree I'd require some handing 
over time to get familiar with the bureaucracy involved in such an important 
package.

If you are interested you can contact me privately and I can share my 
experiences.

Best regards,
Eduardo

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

Bug#979749: buster-pu: package emacs/1:26.1+1-3.2+deb10u1

[Rob Browning]

"Adam D. Barratt"  writes:

> The metadata for that bug implies that it still affects the package in
> unstable (hence the lack of any green on the version graph). I suspect
> this is simply because the "fixed" version doesn't correspond to an
> actual Debian package version. Please could you add a fixed version
> that indicates the earliest upload to Debian that included the fix.

Done, I think.

> Also, while it's possibly slightly picky:
>
> +emacs (1:26.1+1-3.2+deb10u2~1.gbp7c5887) UNRELEASED; urgency=medium
> +
> +  ** SNAPSHOT build @7c5887c8ae064398fafa38b8fea4c5d500830d5f **
> +
> +  * UNRELEASED
> +
> + -- Rob Browning   Sun, 10 Jan 2021 19:22:48 -0600
>
> could we have a finalised version of that, please? :-)

Oh, no, certainly.  I just submitted the UNRELEASED version for the
pre-approval.  I'll of course finalize that before the actual upload.

If that all sounds fine, I'll proceed with a real upload.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#980513: libgnutls30: _gnutls_sort_clist Assertion with openconnect GlobalProtect VPN

[Matt]

Package: libgnutls30
Version: 3.7.0-5
Severity: important
X-Debbugs-Cc: tardarsa...@gmail.com

Dear Maintainer,

After an upgrade to 3.7.0-5, I can no longer connect to a GlobalProtect VPN 
with openconnect.

This is the output from a connection attempt (with identifying information 
removed):

$ sudo openconnect --protocol gp -u   
POST 
https:///global-protect/prelogin.esp?tmp=tmp=4100=Linux
Connected to :443
SSL negotiation with 
openconnect: ../../../lib/x509/common.c:1794: _gnutls_sort_clist: Assertion `k 
== clist_size' failed.
Aborted

The connection works if I downgrade libgnutls30 to 3.6.15-5

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

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

Versions of packages libgnutls30 depends on:
ii  libc6  2.31-9
ii  libgmp10   2:6.2.1+dfsg-1
ii  libhogweed63.6-2
ii  libidn2-0  2.3.0-5
ii  libnettle8 3.6-2
ii  libp11-kit00.23.22-1
ii  libtasn1-6 4.16.0-2
ii  libunistring2  0.9.10-4

libgnutls30 recommends no packages.

Versions of packages libgnutls30 suggests:
pn  gnutls-bin  

-- no debconf information

Bug#980512: openafs-modules-dkms: NULL pointer dereference in kernel on module load

[Witold Baryluk]

Package: openafs-modules-dkms
Version: 1.8.6-5
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com


This is a clean system, just installed, with no custom configuration (in
fact this is a live-build system booted from iso image).

The openafs kernel module oopses:

[   12.248250] openafs: loading out-of-tree module taints kernel.
[   12.248682] openafs: module license 
'http://www.openafs.org/dl/license10.html' taints kernel.
[   12.249062] Disabling lock debugging due to kernel taint
[   12.250229] openafs: module verification failed: signature and/or required 
key missing - tainting kernel
[   12.256512] Key type afs_pag registered
[   12.311004] enabling dynamically allocated vcaches
[   12.311516] Starting AFS cache scan...
[   12.320135] BUG: kernel NULL pointer dereference, address: 
[   12.321038] #PF: supervisor read access in kernel mode
[   12.321481] #PF: error_code(0x) - not-present page
[   12.321901] PGD 0 P4D 0 
[   12.322310] Oops:  [#1] SMP NOPTI
[   12.322717] CPU: 1 PID: 1427 Comm: afsd Tainted: P   OE 
5.10.0-1-amd64 #1 Debian 5.10.4-1
[   12.323136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.14.0-2 04/01/2014
[   12.323557] RIP: 0010:osi_get_fh+0x37/0xe0 [openafs]
[   12.323557] Code: 00 4c 8b 47 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 
8b 05 82 db 04 00 85 c0 0f 4e c2 89 44 24 04 48 8b 47 68 48 8b 40 48 <48> 8b 00 
48 85 c0 74 6a 31 c9 48 8d 54 24 04 4c 89 c7 e8 d2 ca 98
[   12.323557] RSP: 0018:aae0c0c23d10 EFLAGS: 00010286
[   12.323557] RAX:  RBX:  RCX: 0002
[   12.323557] RDX: 000a RSI: c0ac7f80 RDI: 8b8f29edcf00
[   12.323557] RBP:  R08: 8b8f19e74ae0 R09: 0064
[   12.323557] R10: 8b8f29edcf00 R11: 736d R12: 
[   12.323557] R13: 8b8f05471c00 R14: 8b8f3d858000 R15: 0007
[   12.323557] FS:  7fc408938400() GS:8b9037c4() 
knlGS:
[   12.323557] CS:  0010 DS:  ES:  CR0: 80050033
[   12.323557] CR2:  CR3: 00010e90a000 CR4: 06e0
[   12.323557] Call Trace:
[   12.323557]  osi_InitCacheInfo+0x4c/0xa0 [openafs]
[   12.323557]  afs_InitCacheInfo+0x36/0x160 [openafs]
[   12.323557]  ? strncpy_from_user+0x4e/0x140
[   12.323557]  ? _cond_resched+0x16/0x40
[   12.323557]  afs_syscall_call+0xe10/0x1ae0 [openafs]
[   12.323557]  afs_syscall+0xe8/0x500 [openafs]
[   12.323557]  afs_unlocked_ioctl+0x73/0xe0 [openafs]
[   12.323557]  proc_reg_unlocked_ioctl+0x4f/0x90
[   12.323557]  __x64_sys_ioctl+0x83/0xb0
[   12.323557]  do_syscall_64+0x33/0x80
[   12.323557]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Full dmesg since in attachment.



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

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

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.8.4-1
ii  libc6-dev  2.31-9
ii  perl   5.32.0-6

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.8.6-5

openafs-modules-dkms suggests no packages.

-- no debconf information


dmesg.txt
Description: application/json

Bug#979536: openconnect: Assertion on connection to GlobalProtect

[Matthew Chandler]

I am able to connect after downgrading libgnutls to 3.6.15-5.

It could be an issue with the server certs, but since I'm able to 
connect to the same server using an older version of the library, as 
well as from clients on windows and android, it seems more likely to me 
that the problem is in libgnutls. I'll open a new report for that package.


You can consider the report for openconnect resolved. Thanks!

On 1/18/21 1:04 AM, Luca Boccassi wrote:

On Thu, 07 Jan 2021 11:22:16 -0900 Matt  wrote:

Package: openconnect
Version: 8.10-2+b1
Severity: important
X-Debbugs-Cc: tardarsa...@gmail.com
Dear Maintainer,

After upgrading openconnect from 8.10-1 to 8.10-2+b1, I can no longer connect 
to a GlobalProtect VPN.

This is the output from a connection attempt (with identifying information 
removed):

$ sudo openconnect --protocol gp -u  
POST 
https:///global-protect/prelogin.esp?tmp=tmp=4100=Linux
Connected to :443
SSL negotiation with 
openconnect: ../../../lib/x509/common.c:1794: _gnutls_sort_clist: Assertion `k 
== clist_size' failed.
Aborted

Nothing changed but a new version of libgnutls, so that likely means
there's some problem with the certificates your server is issueing?

Bug#980396: inkscape: most icons missing until librsvg2-common installed

[Mattia Rizzolo]

Control: reassign -1 inkscape

On Tue, Jan 19, 2021 at 09:24:00AM +, Simon McVittie wrote:
> > Now, what I *really* wonder abuot is why the trigger (or, well, the code
> > behind it) is not running by itself on after libgdk-pixbuf-2.0-0.
> 
> It ... does? Take a look at
> /var/lib/dpkg/info/libgdk-pixbuf-2.0-0:amd64.postinst (or whatever
> architecture you're using). You'll see that it does the same thing when
> triggered that it does on any upgrade or fresh installation of gdk-pixbuf.
> (Of course if you can see any differences or bugs that I'm missing, then
> I'm happy to apply patches.)

Ohh, I seem to just skipped over that bit somehow.

> > Right, so apparently what used to trigger that was librsvg2-common,
> > which was pulled in by inkscape through the chain
> > 
> > inkscape → libgtk2.0-0 → adwaita-icon-theme | gnome-icon-theme → 
> > librsvg2-common
> 
> If Inkscape is using GTK (i.e. gdk-pixbuf) to draw its icons, and some
> or all of those icons are only provided as SVGs, then librsvg2-common
> is required. Without librsvg2-common, gdk-pixbuf does not know anything
> about SVG files.

Right, apparently I didn't pay attention this fact all these year, since
it was pulled in by something else anyway.

> I think the root cause here is that Inkscape does not depend on
> librsvg2-common, but needs its functionality if you want an interactive
> UI with icons.

Right.

> Possible solutions:
> 
> * inkscape and/or libgtk2.0-0 Depends: librsvg2-common on Rust
>   architectures and Recommends: it on non-Rust architectures
>   (minimal installations with GTK on mainstream architectures will become
>   less minimal)

I'll pick this one and change that in inkscape.
I do believe icons are important enough to have a strict dependency.

> Do the inkscape maintainers have any thoughts on where the best place is
> to add Depends or Recommends?

Rather I wonder if there are any other gtk application rendering svg
icons that never realized they needed such dependency... :)


Thank you for all your insights!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#980510: RFS: filezilla/3.52.2-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: filezilla
   Version : 3.52.2-1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : CC0-1.0, GPL-2+, MIT, permissive, BSD-like
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla-common - Architecture independent files for filezilla
  filezilla - Full-featured graphical FTP/FTPS/SFTP client

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.52.2-1.dsc

Changes since the last upload:

 filezilla (3.52.2-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 3.52.2

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#980464: [Pkg-zfsonlinux-devel] Bug#980464: zfs-dracut: dracut+ZFS-on-root systems rendered unbootable

[Richard Laager]

FWIW, I gave the patch a review and it seems sane to me. I also looked 
at the package in unstable and confirmed that zgenhostid is being 
installed to /sbin, not /bin.


--
Richard

Bug#980509: umap-learn: Binary package name should be python3-umap-learn

[Diane Trout]

Package: umap-learn
Version: 0.4.5+dfsg-2
Severity: normal

Dear Maintainer,

A binary packages that installs into python3/dist-packages really should be
named python3-$package name. It's a requirement of the Debian Python Policy.
https://www.debian.org/doc/packaging-manuals/python-
policy/module_packages.html#package_names

"Public Python 3 modules used by other packages must have their binary package
name prefixed with python3-. It is recommended to use this prefix for all
packages with public modules as they may be used by other packages in the
future."

Thanks,
Diane



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

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

Versions of packages umap-learn depends on:
ii  python3  3.9.1-1
pn  python3-numba
ii  python3-numpy1:1.19.4-1+b1
ii  python3-scipy1.5.4-1+b1
pn  python3-sklearn  

umap-learn recommends no packages.

umap-learn suggests no packages.

Bug#922981: ca-certificates-java: "update-ca-certificates -f" doesn't update "/etc/ssl/certs/java/cacerts"

[Andreas Beckmann]

Followup-For: Bug #922981
Control: found -1 20110425
Control: severity -1 serious
Control: retitle -1 ca-certificates-java: 
/etc/ca-certificates/update.d/jks-keystore doesn't update 
/etc/ssl/certs/java/cacerts
Control: tag -1 security patch
Control: block 929685 with -1

The jks-keystore hook script has never worked, at least since
UpdateCertificates.java was added in 20110425. UpdateCertificates expects
certificates (files or aliases) prefixed with '+' or '-' on stdin as
add/remove actions, but the hook script does not supply anything (while
the postinst does).
Even running the hook after /etc/ssl/certs/java/cacerts got deleted will
only create an empty keystore.
Only on initial installation (not upgrades), the postinst will populate
the keystore with the certificates in /etc/ssl/certs at that point in time.

The attached patch fixes this by adding new certificates and removing gone
certificates. It does not cover the case where a certificate needs to be
refreshed since its content but not its name has changed. Or is this only
a theoretical possibility?


Andreas

installing ca-certificates/sid on bullseye with patched ca-certificates-java:

Preconfiguring packages ...
(Reading database ... 15445 files and directories currently installed.)
Preparing to unpack .../ca-certificates_20210119_all.deb ...
Unpacking ca-certificates (20210119) over (20200601) ...
Setting up ca-certificates (20210119) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
Updating certificates in /etc/ssl/certs...
8 added, 7 removed; done.
Processing triggers for ca-certificates (20210119) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Removing debian:ee_certification_centre_root_ca.pem
Removing debian:geotrust_universal_ca_2.pem
Removing debian:luxtrust_global_root_2.pem
Removing debian:oiste_wisekey_global_root_ga_ca.pem
Removing debian:staat_der_nederlanden_root_ca_-_g2.pem
Removing debian:taiwan_grca.pem
Removing debian:verisign_class_3_public_primary_certification_authority_-_g3.pem
Adding debian:certSIGN_Root_CA_G2.pem
Adding debian:e-Szigno_Root_CA_2017.pem
Adding debian:Microsoft_ECC_Root_Certificate_Authority_2017.pem
Adding debian:Microsoft_RSA_Root_Certificate_Authority_2017.pem
Adding debian:NAVER_Global_Root_Certification_Authority.pem
Adding debian:Trustwave_Global_Certification_Authority.pem
Adding debian:Trustwave_Global_ECC_P256_Certification_Authority.pem
Adding debian:Trustwave_Global_ECC_P384_Certification_Authority.pem
done.
done.
>From ad180a53e2b32c8a6303ca05adcb32e0bc0a44cc Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Wed, 20 Jan 2021 00:32:27 +0100
Subject: [PATCH] fix the hook script to actually update
 /etc/ssl/certs/java/cacerts

---
 debian/changelog |  8 +++
 debian/jks-keystore.hook | 50 ++--
 2 files changed, 56 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 debian/jks-keystore.hook

diff --git a/debian/changelog b/debian/changelog
index e35274e..2b5cf18 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ca-certificates-java (20210119) UNRELEASED; urgency=medium
+
+  * Actually update /etc/ssl/certs/java/cacerts by having the jks-keystore
+hook script supply add/remove actions to ca-certificates-java.jar on
+stdin.  (Closes: #922981)
+
+ -- Andreas Beckmann   Tue, 19 Jan 2021 23:57:51 +0100
+
 ca-certificates-java (20190909) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/jks-keystore.hook b/debian/jks-keystore.hook
old mode 100644
new mode 100755
index e0c3445..94e03a1
--- a/debian/jks-keystore.hook
+++ b/debian/jks-keystore.hook
@@ -48,7 +48,7 @@ for jvm in java-7-openjdk-$arch java-7-openjdk \
 if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
 export JAVA_HOME=/usr/lib/jvm/$jvm
 PATH=$JAVA_HOME/bin:$PATH
-   break
+break
 fi
 done
 
@@ -65,8 +65,11 @@ if dpkg-query --version >/dev/null; then
 fi
 fi
 
+actions=$(mktemp)
+
 do_cleanup()
 {
+rm -f "$actions"
 [ -z "$temp_jvm_cfg" ] || rm -f $temp_jvm_cfg
 if [ -n "$nsspkg" ] && [ -n "$nssjdk" ] && [ "$nsspkg" != "$nssjdk" ]
 then
@@ -79,7 +82,50 @@ do_cleanup()
 fi
 }
 
-if java -Xmx64m -jar $JAR -storepass "$storepass"; then
+# these are currently activated in /etc/ssl/certs/java/cacerts
+if [ -f /etc/ssl/certs/java/cacerts ]; then
+isactivated=$(keytool -cacerts -storepass changeit -list -rfc | sed -n 
's/^Alias name: *//ip' | tr '\n' ' ')
+else
+isactivated=
+fi
+
+# these are currently activated in /etc/ssl/certs
+shouldactivate=$(find /etc/ssl/certs -name \*.pem | while read filename; do 
echo -n &qu

Bug#980508: ntpsec: apparmor="DENIED" while trying to read /etc/ssl/openssl.cnf

[Diederik de Haas]

Package: ntpsec
Version: 1.2.0+dfsg1-2
Severity: normal
User: pkg-apparmor-t...@lists.alioth.debian.org

I just installed ntpsec (replacing ntp) and noticed the following error
msg wrt AppArmor. Single result broken up to keep below 80 char width.

# journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"'
jan 20 00:45:32 kernel: audit: type=1400 audit(1611099932.689:41): 
apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/etc/ssl/openssl.cnf" pid=43157 comm="ntpd" requested_mask="r" 
denied_mask="r" fsuid=0 ouid=0

I don't have an indication that ntpsec doesn't do its job because of
this, but thought I'd report it nonetheless, especially given the 'sec'
in its name.

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

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

Versions of packages ntpsec depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libbsd0  0.10.0-1
ii  libc62.31-9
ii  libcap2  1:2.44-1
ii  libssl1.11.1.1i-2
ii  lsb-base 11.1.0
ii  netbase  6.2
ii  python3  3.9.1-1
ii  python3-ntp  1.2.0+dfsg1-2
ii  tzdata   2020f-1

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-136
ii  systemd 247.2-5

Versions of packages ntpsec suggests:
ii  apparmor   2.13.6-7
ii  certbot1.11.0-1
pn  ntpsec-doc 
pn  ntpsec-ntpviz  

-- no debconf information

Bug#980375: (no subject)

[William Desportes]

Hi,


Thanks for reporting this bug, what version of libjs-codemirror do you 
have installed ?


I tested the package with 5.54.0-2~bpo10+1, 5.59.0+~cs0.23.105-1 and 
5.19.0-1 versions and had no issues.



Maybe I did miss-understand what you reported ?


Regards,

William

Bug#980507: How to get STP and IPv6

[Sam Hartman]

package: bridge-utils
severity: important
version: 1.6-3
justification: breaks actual switches that need v6

In 736336 , you documented that stp breaks ipv6.  As was pointed out in
the bug report that's kind of bogus.  You clearly need both in some
situations.  As an example, if you are actually running a
switch--something that might have loops--and need v6 connectivity, you
need both.  The correct solution is to run DAD after the port has gone
to forwarding.

Please document how to accomplish this on Linux where you document that
it doesn't work with bridge-utils.
Even if the best solution we've got is to go frob a sysctl setting
before and after enabling stp, document that.


signature.asc
Description: PGP signature

Bug#980506: cruft report only shows information for experimental

[peter green]

Package: ftp.debian.org

Traditionally when I want to know why a binary package that was no longer
built by the coresponding source package was still in unstable I would
look at the cruft report at

https://ftp-master.debian.org/cruft-report-daily.txt

However in recent times (can't remember how long for now) this page has
only been giving information relating to experimental.

Bug#980505: Buster Regression: MACAddress changes with bullseye

[Sam Hartman]

package: bridge-utils
version: 1.6-3
severity: important
justification: breaks network connectivity on release upgrade


It looks like this is a kernel change not a bridge-utils change.
But the way MACAddress selection for the bridge works has changed
between buster and bullseye.
The result is that if you use dhcp based on mac address in a
provisioning database to provision addresses on your servers (or
presumably use an address based on IPv6 IID), your addresses will change
potentially breaking network connectivity to your servers after reboot.

I think the best solution to this bug is to document probably in
news.debian and release notes the issue
and how you can get the old behavior if that's what you need on upgrade.

Bug#980504: RM: readline5 -- RoQA; Unmaintained, orphaned, alternatives available

[Bastian Germann]

Package: ftp.debian.org
Severity: normal

The readline5 package was kept around for a long time because of a 
license change from GPL-2+ to GPL-3+. This version is not maintained 
upstream anymore. The package was orphaned via #737301 and is untouched 
for 5.5 years.


The last reverse dependency was xfsprogs which got rid of its readline5 
dependency in sid today.


The libedit library is largely API compatible and fully license 
compatible with readline5. libedit's binary package libeditreadline-dev 
can be used as a drop-in replacement without even patching include paths 
or library names.


So please remove the readline5 package so that it is not released with 
bullseye.

Bug#980443: dovecot-imapd: segfault at 8 ip 000055c38b20f97c sp 00007ffe4baaaa40 error 4 in imap[55c38b1f7000+24000]

[Simon Josefsson]

tis 2021-01-19 klockan 10:58 -0800 skrev Noah Meyerhans:
> On Tue, Jan 19, 2021 at 09:28:58AM +0100, Simon Josefsson wrote:
> > Hi.  I noticed the following in my log recently.  Any ideas?
> > 
> > Jan  6 14:55:54 uggla kernel: [145284.855936] imap[18530]: segfault
> > at 8 ip 55c38b20f97c sp 7ffe4b40 error 4 in
> > imap[55c38b1f7000+24000]
> > Jan  6 14:55:54 uggla kernel: [145284.855945] Code: 5d 41 5c 41 5d
> > e9 2b ca fe ff 0f 1f 40 00 45 89 ec 48 89 df 48 39 eb 75 bd 48 8b
> > 45 00 48 8d 35 da f4 00 00 41 bc ff ff ff ff <48> 8b 78 08 e8 8b 77
> > ff ff 48 83 c4 08 44 89 e0 5b 5d 41 5c 41 5d
> > Jan  6 14:55:54 uggla dovecot:
> > imap(simon)<18530><7bj6fTy4vsof0Co6>: Fatal: master: service(imap):
> > child 18530 killed with signal 11 (core dumps disabled - 
> > https://dovecot.org/bugreport.html#coredumps)
> > 
> > The 1:2.3.4.1-5+deb10u5 packages were installed on 2021-01-04:
> > 
> > 2021-01-04 22:34:01 status installed dovecot-imapd:amd64 1:2.3.4.1-
> > 5+deb10u5
> > 
> > The machine was restarted minutes after that, so on 2021-01-06
> > (segfault
> > log output above) it should have be running then-current packages.
> > 
> > I'm not able to use ALLOW_COREDUMPS=1 to make sure I get core dumps
> > in
> > the future, but I'll report that separately.
> 
> It seems from #980444 that you've got coredumps working.  Can you
> provide a stack trace for this?

No it happened randomly and I cannot reproduce it.  The server is
working fine for day-to-day use, so this is not causing any problem but
I wanted to report it anyway in case others are seeing the same thing
or if is a security-related problem.

I have enabled core dumps and also rawlogs now, so I will be able to
provide more information if this happens again.  As you can see, I was
logged into my own account (from what appears to be one of my usual
IPs), so I doubt it is someone attacking the server unauthorized.

/Simon

Bug#969521: Browserpass icon disappears

[Carl Suster]

Just to note, this is firefox bug #969174 and is not specific to 
browserpass.

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

[harry88]

Tags: patch

Hi Vagrant, thanks for looking at this.


On Fri, 15 Jan 2021, Vagrant Cascadian wrote:
> This is fairly new in u-boot, but yes, it's probably possible in most 
> cases with recent u-boot versions.

Great.  I've tried making that change to debian/targets in version 
2021.01+dfsg-1 (patch is below) and rebuilding, and I've verified that 
for all eleven arm64 sunxi platforms:

- u-boot-sunxi-with-spl.bin is equal to spl/sunxi-spl.bin concatenated 
with u-boot-sunxi-with-spl.fit.fit
- spl/sunxi-spl.bin is 32K in size
- u-boot-sunxi-with-spl.fit.fit differs from u-boot-sunxi-with-spl.fit.itb 
only in a timestamp

Therefore, for each of these platforms, writing u-boot-sunxi-with-spl.bin 
to the card at offset 8K should work just as well as writing the SPL at 
8K and the FIT image at 40K, which the current u-boot-install-sunxi 
script does.  I've confirmed that it works on the Orange Pi One Plus.


> > That would mean we could further simplify the u-boot-install-sunxi script.
> 
> This part is already done in the 2021.01~rc version experimental.

I saw that version, thanks, but I was proposing to further simplify the 
script by making it write just one file to the card rather than two. 
I've double-checked and I'm sure my patch to that script doesn't 
duplicate any changes already made.  The full list of changes in the 
patch is:

- Improve 'Specify target' error message
- Remove check for mkimage which is no longer used
- Avoid creating tempfiles in current directory
- Write one combined file to card rather than two components
- Sync on the write operation rather than separately


> > Out of interest, what's the reason for including uboot.elf? 
> 
> I tried removing it at some point, but some platforms require it 
> (e.g. p2371-2180 in u-boot-tegra).

OK.  What do you think of the idea of installing it only where needed? 
Perhaps it could be listed explicitly in debian/targets for those 
platforms that require it.

Thanks very much,
Harold.

--- debian/targets  2021-01-19 06:18:39.675829807 +
+++ debian/targets.simplified   2021-01-19 06:18:54.167504580 +
@@ -229,37 +229,37 @@
 arm64  rpi rpi_arm64   u-boot.bin
 
 # Rodrigo Exterckötter Tjäder 
-arm64  sunxi   a64-olinuxino   
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-olinuxino.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   a64-olinuxino   
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Philip Rinn 
-arm64  sunxi   a64-olinuxino-emmc  
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-olinuxino-emmc.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   a64-olinuxino-emmc  
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Domenico Andreoli 
-arm64  sunxi   nanopi_neo2 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h5-nanopi-neo2.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   nanopi_neo2 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Steev Klimaszewski 
-arm64  sunxi   nanopi_neo_plus2
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   nanopi_neo_plus2
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Frederic Danis 
-arm64  sunxi   orangepi_zero_plus2 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h5-orangepi-zero-plus2.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   orangepi_zero_plus2 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # harr...@gmx.ph
-arm64  sunxi   orangepi_one_plus   
/usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb 
u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   orangepi_one_plus   
/usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Vagrant Cascadian 
-arm64  sunxi   pine64_plus 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pine64-plus.dtb 
arch/arm/dts/sun50i-a64-pine64.dtb u-boot-sunxi-with-spl.fit.itb
+arm64  sunxi   pine64_plus 
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot-sunxi-with-spl.bin
 
 # Sunil Mohan Adapa 
-arm64  sunxi   pine64-lts  
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin 
u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pine64-lts.dtb 
arch/arm/dts/sun50i-a64-pine64.dtb 

Bug#969971: Also affected by the bug

[era]

On Tue, Jan 19, 2021, at 22:31, Deb-user wrote:
> I am also affected by the same bug in Debian stable (buster). How can we 
> deal with this?

The bug report you are responding to includes instructions for working around 
the problem. Do those not work for you?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

On Thu, 19 Mar 2020 15:02:13 +0100 Diederik de Haas  
wrote:
> On donderdag 19 maart 2020 14:59:56 CET mario.limoncie...@dell.com wrote:
> > Sorry - I see now that was from a while back.
>
> And also a different user (OP).

After some upstream discussion, any remaining issues with 1.3.x this is 
expected to be root caused in a CDN caching problem that will be transient.  
The architecture was changed in the 1.4.x series, so please if this is still 
present in 1.4.x or 1.5.x please notify.

Bug#957797: simh: diff for NMU version 3.8.1-6.1

[Sudip Mukherjee]

Control: tags 957797 + patch
Control: tags 957797 + pending
--

Dear maintainer,

I've prepared an NMU for simh (versioned as 3.8.1-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -u simh-3.8.1/debian/changelog simh-3.8.1/debian/changelog
--- simh-3.8.1/debian/changelog
+++ simh-3.8.1/debian/changelog
@@ -1,3 +1,11 @@
+simh (3.8.1-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957797)
+- Use fcommon.
+
+ -- Sudip Mukherjee   Tue, 19 Jan 2021 22:31:56 
+
+
 simh (3.8.1-6) unstable; urgency=medium
 
   * New maintainer (Closes: 848569)
diff -u simh-3.8.1/makefile simh-3.8.1/makefile
--- simh-3.8.1/makefile
+++ simh-3.8.1/makefile
@@ -1,7 +1,7 @@
 # Simh makefile for Debian Package
 #
 OS_CCDEFS = -lrt -D_GNU_SOURCE
-CC = gcc -std=c99 -O2 -U__STRICT_ANSI__ -g $(OS_CCDEFS) -I .
+CC = gcc -fcommon -std=c99 -O2 -U__STRICT_ANSI__ -g $(OS_CCDEFS) -I .
 LIBS = -lm -lrt
 USE_NETWORK = 1
 

Bug#157299:

[Yawi Enumbi]

Bug#980503: dnsmasq: incorrect version reported.

[Timo van Roermund]

Package: dnsmasq
Version: 2.83-1
Severity: minor

Dear Maintainer,

The version reported by dnsmasq seems incorrect. The command 'dnsmasq -v' 
returns 'Dnsmasq version 2.82 (...)', while the package version is 2.83-1. I 
think the command should return 'Dnsmasq version 2.83 (...)' instead.

Cheers,

Timo

Bug#977895: buster-pu: package slirp/1:1.0.17-8

[Thorsten Alteholz]

On Thu, 31 Dec 2020, Adam D. Barratt wrote:

Please go ahead.


The package is uploaded now.

  Thorsten

Bug#980502: evolution: printing emails doesn't work

[Ben Ruhnow]

Package: evolution
Version: 3.38.2-1
Severity: important
X-Debbugs-Cc: b.ruh...@web.de

Forwarded-To: https://bugzilla.gnome.org/show_bug.cgi?id=202363

Dear Maintainer,

when I recently had to print an email I found out that this function is useless 
for now! 
The workaround described there makes this feature useable.

Hoping this will be fixed in the next releases.

Thanks a lot,

Ben Ruhnow

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

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

Versions of packages evolution depends on:
ii  dbus   1.12.20-1
ii  evolution-common   3.38.2-1
ii  evolution-data-server  3.38.2-2
ii  libc6  2.31-6
ii  libcamel-1.2-623.38.2-2
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.38.2-2
ii  libedataserver-1.2-25  3.38.2-2
ii  libevolution   3.38.2-1
ii  libglib2.0-0   2.66.4-1
ii  libgtk-3-0 3.24.24-1
ii  libical3   3.0.8-2
ii  libnotify4 0.7.9-2
ii  libsoup2.4-1   2.72.0-2
ii  libwebkit2gtk-4.0-37   2.30.4-1
ii  libxml22.9.10+dfsg-6.3+b1
ii  psmisc 23.3-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.38.2-1
ii  evolution-plugin-pstimport   3.38.2-1
ii  evolution-plugins3.38.2-1
ii  yelp 3.38.2-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.20-1
ii  network-manager 1.28.0-2

-- no debconf information

Bug#979966: debdelta still contains isAlive()s

[A Mennucc1]

dear all,

I just uploaded a 0.66 *before* reading this message

when I checked 0.65+nmu it seemed it was fine in this respect

before creating 0.66, I did
# grep -e isAlive -r .
and I did not see any occurrence
so hopefully it will be OK

a.


Il 18/01/21 18:59, Calum McConnell ha scritto:
> On Mon, 2021-01-18 at 14:41 +0100, Steven De Herdt wrote:
>> reopen 979966
>> thanks
>>
>> This report actually concerns 0.65+nmu1: /usr/bin/debdelta is identical
>> to the one in 0.65.  Something must have gone wrong in the NMU...
>>
>> Thanks for the work on this package!
>> -Steven
> I can confirm that is true.  It's almost certainly something I screwed up,
> and now that A. Mennucc1 is back, the solution will probably be to upload
> a new 0.66 rather than a +nmu2.
>
> I'm not sure quite HOW I managed to mess it up, but I have a feeling it is
> because I wasn't careful enough in keeping track of what changes I made to
> which versions. It's probably the direct result of me using a patch to
> copy over the changelog (instead of, you know, just copy-pasting): but as
> I prepared the NMU in /tmp, I can't say for sure.  Suffice it to say I am
> whacking my head against the wall for not checking one final time whether
> there were any more occurences of isAlive().
>
> A. Mennucc, any chance of doing a full upload sometime soon, to hopefully
> prevent my mistake from entering Bullseye's final release?
>
> Thanks,
> Calum
>
>




signature.asc
Description: OpenPGP digital signature

Bug#980473: ModuleNotFoundError: No module named 'Crypto'

[Sebastian Ramacher]

Control: tags -1 + patch

On 2021-01-20 01:52:54 +1100, Konomi Kitten wrote:
> Package: python3-otr
> Version: python3-potr
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: konomikit...@gmail.com
> 
> Trying to import potr throws the following error:
> 
> $ python3
> Python 3.9.1+ (default, Jan 10 2021, 15:42:50)
> [GCC 10.2.1 20201224] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import potr
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/potr/compatcrypto/pycrypto.py", line 
> 19,
> in 
> import Crypto
> ModuleNotFoundError: No module named 'Crypto'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/potr/__init__.py", line 21, in 
> from potr import context
>   File "/usr/lib/python3/dist-packages/potr/context.py", line 43, in 
> from potr import crypt
>   File "/usr/lib/python3/dist-packages/potr/crypt.py", line 25, in 
> from potr.compatcrypto import SHA256, SHA1, SHA1HMAC, SHA256HMAC, \
>   File "/usr/lib/python3/dist-packages/potr/compatcrypto/__init__.py", line 
> 21,
> in 
> from potr.compatcrypto.pycrypto import *
>   File "/usr/lib/python3/dist-packages/potr/compatcrypto/pycrypto.py", line 
> 21,
> in 
> import crypto as Crypto
> ModuleNotFoundError: No module named 'crypto'
> >>>

Please consider applying the attached patch. The package also needs to
depend on python3-pycryptodome either by manually hardcoding the
dependency in debian/control or by fixing
debian/patches/0001-Use-pycryptodome-as-dependency.patch to have
install_requires=["pycryptodomex"]

Cheers
-- 
Sebastian Ramacher
--- python-potr-1.0.2.orig/src/potr/compatcrypto/pycrypto.py
+++ python-potr-1.0.2/src/potr/compatcrypto/pycrypto.py
@@ -16,16 +16,16 @@
 #along with this library.  If not, see .
 
 try:
-  import Crypto
+  import Cryptodome
 except ImportError:
   import crypto as Crypto
 
-from Crypto import Cipher
-from Crypto.Hash import SHA256 as _SHA256
-from Crypto.Hash import SHA as _SHA1
-from Crypto.Hash import HMAC as _HMAC
-from Crypto.PublicKey import DSA
-import Crypto.Random.random
+from Cryptodome import Cipher
+from Cryptodome.Hash import SHA256 as _SHA256
+from Cryptodome.Hash import SHA as _SHA1
+from Cryptodome.Hash import HMAC as _HMAC
+from Cryptodome.PublicKey import DSA
+import Cryptodome.Random.random
 from numbers import Number
 
 from potr.compatcrypto import common
@@ -143,7 +143,7 @@ class DSAKey(common.PK):
 return cls((y, g, p, q), private=False), data
 
 def getrandbits(k):
-return Crypto.Random.random.getrandbits(k)
+return Cryptodome.Random.random.getrandbits(k)
 
 def randrange(start, stop):
-return Crypto.Random.random.randrange(start, stop)
+return Cryptodome.Random.random.randrange(start, stop)


signature.asc
Description: PGP signature

Bug#979966: debdelta still contains isAlive()s

[A Mennucc1]

dear all,

I just uploaded a 0.66 *before* reading this message

when I checked 0.65+nmu it seemed it was fine in this respect

before creating 0.66, I did
# grep -e isAlive -r .
and I did not see any occurrence
so hopefully it will be OK

a.


Il 18/01/21 18:59, Calum McConnell ha scritto:
> On Mon, 2021-01-18 at 14:41 +0100, Steven De Herdt wrote:
>> reopen 979966
>> thanks
>>
>> This report actually concerns 0.65+nmu1: /usr/bin/debdelta is identical
>> to the one in 0.65.  Something must have gone wrong in the NMU...
>>
>> Thanks for the work on this package!
>> -Steven
> I can confirm that is true.  It's almost certainly something I screwed up,
> and now that A. Mennucc1 is back, the solution will probably be to upload
> a new 0.66 rather than a +nmu2.
>
> I'm not sure quite HOW I managed to mess it up, but I have a feeling it is
> because I wasn't careful enough in keeping track of what changes I made to
> which versions. It's probably the direct result of me using a patch to
> copy over the changelog (instead of, you know, just copy-pasting): but as
> I prepared the NMU in /tmp, I can't say for sure.  Suffice it to say I am
> whacking my head against the wall for not checking one final time whether
> there were any more occurences of isAlive().
>
> A. Mennucc, any chance of doing a full upload sometime soon, to hopefully
> prevent my mistake from entering Bullseye's final release?
>
> Thanks,
> Calum
>
>







signature.asc
Description: OpenPGP digital signature

Bug#980426: old pikepdf is blocking qpdf transition

[Jay Berkenbilt]

On Tue, Jan 19, 2021, at 4:06 PM, Sean Whitton wrote:
> control: tag -1 + patch pending
> 
> Hello,
> 
> On Tue 19 Jan 2021 at 09:39AM -05, Jay Berkenbilt wrote:
> 
> > Here's a patch that applies cleanly against upstream v1.17.3 after
> > which the resulting pikepdf builds and passes its test with qpdf
> > 10.1. Please let me know if this is sufficient. I put some comments at
> > the top of the patch citing original commits in case you want to do
> > the DEP-3 thing.
> 
> Well, several of those we are already carrying in d/patches :)

Yeah, if it had taken me more than a few minutes to gather this up, I would 
have started with the debian package. I probably should have done that. :-)

> Uploading shortly.  Thanks for investigating!

That's great. Thanks for responding so quickly.

--Jay

Bug#976301: Fix invalid `changelog` format example

[Anatoli Babenia]

It is hard to spot the space in front of the string, and much harder
to understand that it is significant. That's why I still think that
applying my patch as-is is a better choice. In committed change
https://salsa.debian.org/dbnpolicy/policy/-/commit/69933a335bce539ec8e75f3b5625dc69509d9886
the test that explains blank lines goes as replacement for those blank
like, but the text that explains two space pattern is an inline
comment. In my patch user needs to replace every placeholder with the
content that is described within.

Bug#980426: old pikepdf is blocking qpdf transition

[Sean Whitton]

control: tag -1 + patch pending

Hello,

On Tue 19 Jan 2021 at 09:39AM -05, Jay Berkenbilt wrote:

> Here's a patch that applies cleanly against upstream v1.17.3 after
> which the resulting pikepdf builds and passes its test with qpdf
> 10.1. Please let me know if this is sufficient. I put some comments at
> the top of the patch citing original commits in case you want to do
> the DEP-3 thing.

Well, several of those we are already carrying in d/patches :)

Uploading shortly.  Thanks for investigating!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#980501: src:r-cran-projpred: fails to migrate to testing for too long: Build-Depends not available on armel

[Paul Gevers]

Source: r-cran-projpred
Version: 1.1.6-1
Severity: serious
Control: close -1 2.0.2+dfsg-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

I suggest you request removal of r-cran-projpred on armel, the package
doesn't build.

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:r-cran-projpred in its current version in unstable has been trying
to migrate for 61 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=r-cran-projpred




OpenPGP_signature
Description: OpenPGP digital signature

Bug#980426: old pikepdf is blocking qpdf transition

[Sean Whitton]

Hello James,

On Tue 19 Jan 2021 at 11:06AM -08, James R Barlow wrote:

> Jay, the patch looks good to me. I did not try to run it, but it looks like
> it covers everything important.

Ah, thanks for the review.

> Sean, there is no license change to pikepdf. ocrmypdf did have the
> license change. If this is the holdup, ocrmypdf 10.x should work
> pikepdf 2.x with a trivial patch - the main change in pikepdf 2.x was
> dropping support for Python 3.5. If you are interested in the ocrmypdf
> 10.x + pikepdf 2.x combination I can test it and do any
> patches. pikepdf is now used by other applications in Debian
> (e.g. pdfarranger).

Hrm, sorry I misremembered which package changed its license.

Debian has entered our pre-release transitions freeze, so I will have to
pass on your kind offer to help update pikepdf without updating
ocrmypdf, unfortunately :(

> ocrmypdf 11's d/copyright was updated to reflect the current copyright
> status.

The updates you make to the d/copyright in your branch definitely help
speed the process, but I've found you don't always include everything,
and I normally need to make further edits to satisfy the format
specification.  Certainly not your role to work on this, and I
appreciate the edits you make and your prompt response to queries.

> It's been half a year since the ocrmypdf license change and I have not
> heard anything from Debian about it. Is there a "queue" somewhere or
> someone we can prod to complete this review?

I'm afraid not, only I as maintainer have responsibility for this.  It's
the sort of task that is difficult to spread responsibility for, unlike
providing patches to fix bugs.

-- 
Sean Whitton

Bug#976301: Fix invalid `changelog` format example

[Sean Whitton]

Hello,

On Tue 19 Jan 2021 at 04:19AM +01, Guillem Jover wrote:

> On Mon, 2021-01-18 at 18:25:55 -0700, Sean Whitton wrote:
>> On Thu 03 Dec 2020 at 05:08AM +03, Anatoli Babenia wrote:
>> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> > index edae8c1..1265c5e 100644
>> > --- a/policy/ch-source.rst
>> > +++ b/policy/ch-source.rst
>> > @@ -126,7 +126,7 @@ That format is a series of entries like this:
>> >   [blank line(s), included in output of dpkg-parsechangelog]
>> >   * even more change details
>> >   [optional blank line(s), stripped]
>> > []{+[space]--+} maintainer name [two [-spaces]
>> > date-]{+spaces]date+}
>>
>> I do not believe that what is already there is invalid or unclear.
>>
>> Please explain your motivations.
>
> Oh, but it does look invalid. :) Notice that the trailing maintainer
> line starts at the same column as the header line, but the trailer must
> be indented by one space.

Oops, fixed on master, thank you.

> Also the «two spaces» are then followed by two explicit spaces, which
> seems confusing.

We have a choice of putting [space] throughout and replacing "[two
spaces]  " with just "[two spaces]", just doing the latter replacement,
or leaving it as it is.  Tbh I think the first option makes the whole
thing a bit noisy.  I think the second is more confusing than the third,
but I don't know if I'm alone in that.  Would be good to get some more
opinions.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

Someone else reported the artifacts issue was resolved in 13.5.6. See 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968626#40


Oh, sorry, i didn't mean artifact upload (bug 968626), but the Gitlab 
internal artifacts that are missing from bug 977701 and break some pages.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#969971: Also affected by the bug

[Deb-user]

Hello,

I am also affected by the same bug in Debian stable (buster). How can we 
deal with this?

Bug#964082: parsinsert fails it's tests when built with -O3

[Étienne Mollier]

Hi there,

On Sun, 20 Dec 2020 09:07:57 +0100 Andreas Tille  wrote:
> > parsinsert fails it's tests when built with -O3, seen at least on amd64 and 
> > ppc64el.
> 
> I admit I failed to reproduce this at least on amd64.  I explicitly
> tried -O3 to use the same optimisation flag as upstream to possibly fix
> #976929 since this package was showing issues with different
> optimisation flags in the past.  Can you be more verbose how to
> reproduce this issue?

By exporting DEB_CXXFLAGS_MAINT_APPEND = -O3 explicitely in the
d/rules file, I could reproduce the output on amd64.  In case
the behavior is not consistent accross CPUs, I have the
following:

Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   43 bits physical, 48 bits virtual
CPU(s):  6
On-line CPU(s) list: 0-5
Thread(s) per core:  1
Core(s) per socket:  6
Socket(s):   1
Vendor ID:   AuthenticAMD
CPU family:  23
Model:   113
Model name:  AMD Ryzen 5 3600 6-Core Processor
Stepping:0
Frequency boost: enabled
CPU MHz: 3860.805
CPU max MHz: 3600.
CPU min MHz: 2200.
BogoMIPS:7186.72
Virtualization:  AMD-V
L1d cache:   192 KiB
L1i cache:   192 KiB
L2 cache:3 MiB
L3 cache:32 MiB
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf:  Not affected
Vulnerability Mds:   Not affected
Vulnerability Meltdown:  Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled 
via prctl and seccomp
Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and 
__user pointer sanitization
Vulnerability Spectre v2:Mitigation; Full AMD retpoline, IBPB 
conditional, STIBP disabled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort:   Not affected
Flags:   fpu vme de pse tsc msr pae mce
cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse
sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm
constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid
aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2
movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc
mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp
vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap
clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc
cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf
xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save
tsc_scale vmcb_clean flushbyasid decodeassists pausefilter
pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov
succor smca

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#980326: mutt: diff for NMU version 2.0.2-1.1

[Salvatore Bonaccorso]

Hi Antonio,

Thanks for the reply!

On Tue, Jan 19, 2021 at 08:47:01PM +0100, Antonio Radici wrote:
> On Tue, Jan 19, 2021 at 09:07:37AM +0100, Salvatore Bonaccorso wrote:
> > Control: tags 980326 + patch
> > Control: tags 980326 + pending
> > 
> > Hi Antonio,
> > 
> > I've prepared an NMU for mutt (versioned as 2.0.2-1.1) and
> > uploaded it to DELAYED/10. Please feel free to tell me if I
> > should delay it longer (or shorter).
> > 
> > Actually IMHO it would be more sensible to rebase to the current
> > upstream version and cherry-pick the additional commits already queued
> > for stable.
> > 
> 
> Thanks for the patch, I will upgrade to the latest upstream version by Sunday
> this week, I have no problem with the NMU!

Ok perfect :). Then I cancel the NMU!

> Does it make sense? When you talk about "additional commits already queued for
> stable" what are you referring to?

Yes defintively, I think that's the better option for unstable (and so
bullseye, just need to make sure it will migrate).

With additional commits I mean that after the 2.0.4 release (and since
no release was cut for 2.0.5) there are commits in
https://gitlab.com/muttmua/mutt/-/commits/stable/ which seems woth to
pick as well. Apart the above commit (which now has CVE-2021-3181
assigned) there are other commits like two more memory leak fixes.

Thanks for your work!

Regards,
Salvatore

Bug#332498: RFH: openssl -- Secure Socket Layer (SSL) binary and related cryptographic tools

[Eduardo Pires]

Hi Kurt and/or whoever is maintaining it.

Do you guys still need help?

As a long time Debian and openssl user I'm looking to give back to the
community as much as I can (new year's resolution!).

best regards,
Ed

Bug#930733: evolution: Can't open evolution

[Diane Trout]

Hello,

I was looking through Debian release-critical bugs and saw this report
that no one had followed up on. Evolution 3.38.2 is working for me and
I was wondering if you were still having trouble.

Also I see you had stable and experimental in your sources list and I
think that's likely to lead to trouble. Experimental isn't complete on
its own and assumes dependencies in unstable will be available.

Thank you,
Diane Trout


On Wed, 19 Jun 2019 14:41:16 +0200 Alexandre  wrote:
> Package: evolution
> Version: 3.32.2-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> When i try to open evolution i have this error :
> 
> libEGL warning: DRI2: failed to open i965 (search paths /usr/lib/x86_64-linux-
> gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open i965 (search paths /usr/lib/x86_64-linux-
> gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open i965 (search paths /usr/lib/x86_64-linux-
> gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open i965 (search paths /usr/lib/x86_64-linux-
> gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> Failed to initialize gtk+: Impossible d'initialiser le moteur Clutter : aucun
> pilote disponible.
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers stable
>   APT policy: (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages evolution depends on:
> ii  dbus   1.12.12-1
> ii  evolution-common   3.32.2-1
> ii  evolution-data-server  3.32.2-2
> ii  libc6  2.28-8
> ii  libcamel-1.2-62    3.32.2-2
> ii  libclutter-gtk-1.0-0   1.8.4-4
> ii  libecal-1.2-19 3.32.2-2
> ii  libedataserver-1.2-24  3.32.2-2
> ii  libevolution   3.32.2-1

Bug#980500: kgb-bot: extra filter to remove the job list from gitlab's pipeline events

[Mattia Rizzolo]

Package: kgb-bot
Severity: wishlist

Hi,

I'm proposing here a few a new filter for gitlab's pipeline
notifications, which can easily be way too noisy.

Currently the notification can look like this:

reprotest pipeline Mattia Rizzolo 220939 * pending (build: created; build 
i386: created; build source: created; aptly: created; test-build-any: created; 
test-build-all: created; reprotest: created; lintian: created; autopkgtest: 
created; blhc: created; piuparts: created; extract-source: pending)

That's stupidly long and doesn't really bring any value.
I think it makes moer sense to (optionally!) drop the job list within
brackets.


With the above done, I also propose to retain (again, with extra option?
up to you) the list of failed jobs in case of status=failed.  So as an
example, this notification:
reprotest pipeline Marek Marczykowski-Górecki 220930 * [8 minutes and 15 
seconds] failed (autopkgtest: success; piuparts: success; reprotest: success; 
lintian: success; test-build-all: skipped; test-build-any: skipped; aptly: 
success; blhc: success; build i386: failed; build: success; build source: 
success; extract-source: success)
would become:
reprotest pipeline Marek Marczykowski-Górecki 220930 * [8 minutes and 15 
seconds] failed (failed job(s): build i386)

which is so much useful IMHO.

Thanks for considering!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#980326: mutt: mutt recipient parsing memory leak

[Salvatore Bonaccorso]

Control: retitle -1 980326 mutt: CVE-2021-3181: mutt recipient parsing memory 
leak

On Sun, Jan 17, 2021 at 09:01:22PM +0100, Salvatore Bonaccorso wrote:
> Source: mutt
> Version: 2.0.2-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> 
> Hi,
> 
> This was reported at
> https://www.openwall.com/lists/oss-security/2021/01/17/2 and upstream
> apparently at https://gitlab.com/muttmua/mutt/-/issues/323 (not
> public).
> 
> Upstream fix: 
> https://gitlab.com/muttmua/mutt/-/commit/c059e20ea4c7cb3ee9ffd3500ffe313ae84b2545

This has CVE-2021-3181 assigned.

Regards,
Salvatore

Bug#980499: RFS: dragonfly-reverb/3.2.3-1 [ITP] -- Reverb effect plugins (metapackage)

[Dennis Braun]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dragonfly-reverb":

 * Package name: dragonfly-reverb
   Version : 3.2.3-1
   Upstream Author : Michael Willis and rghvdberg
 * URL : https://michaelwillis.github.io/dragonfly-reverb/
 * License : ISC, bitstream-vera, GPL-2+, Expat, ZLIB, GPL-3, OFL-1.1, 
MIT, GPL-3+
 * Vcs : https://salsa.debian.org/multimedia-team/dragonfly-reverb
   Section : sound

It builds those binary packages:

  dragonfly-reverb-lv2 - Reverb effect plugins - LV2 plugins
  dragonfly-reverb-vst - Reverb effect plugins - VST plugins
  dragonfly-reverb-standalone - Reverb effect plugins - standalone applications
  dragonfly-reverb - Reverb effect plugins (metapackage)

This package is NOT so far in debian, but already in ubuntu...

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

  https://mentors.debian.net/package/dragonfly-reverb/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dragonfly-reverb/dragonfly-reverb_3.2.3-1.dsc

Changes for the initial release:

 dragonfly-reverb (3.2.3-1) unstable; urgency=medium
 .
   [ Olivier Humbert ]
   * Initial release. (Closes: #916638)
 .
   [ Ondřej Nový ]
   * Use debhelper-compat instead of debian/compat
   * d/control: Deprecating priority extra as per policy 4.0.1
   * d/rules: Remove trailing whitespaces
 .
   [ Dennis Braun ]
   * Merge debian files with ubuntu version 3.2.1-0ubuntu1
   * d/control:
 + Sort B-Ds
 + Bump S-V to 4.5.1
 + Change Maintainer and add uploaders
 + Re-Add Vcs-Git and Vcs-Browser
 + Remove ${shlibs:Depends} from dragonfly-reverb Depends
   * d/copyright: http > https, add myself to the d/ section and update year
   * Update d/dragonfly-reverb-standalone.lintian-overrides
   * d/rules:
 + Clean build flags
 + Add hardening
 + Fix stripping
 + Export DESTDIR and PREFIX
 + Use dh_auto_build instead of $(MAKE)
   * Add d/upstream/metadata

Regards,
Dennis



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980498: guile-3.0 FTBFS on amd64: check-guile fails

[Helmut Grohne]

Source: guile-3.0
Version: 3.0.5-1
Severity: serious
Tags: ftbfs

guile-3.0 failed to build from source on the buildd on amd64. It is hard
to pin down the actual failure. It happens during unit tests.
https://buildd.debian.org/status/fetch.php?pkg=guile-3.0=amd64=3.0.5-1=1610521112=0
is a link to a failing build log.

The armel build failed differently. It timed out via not producing any
output in 5 minutes. kfreebsd-amd64 and kfreebsd-i396 seem to have
failed in the same way as amd64.

Any ideas?

Helmut

Bug#980497: libboost1.74-dev: boost/function_output_iterator.hpp deprecation warnings

[Vincas Dargis]

Package: libboost1.74-dev
Version: 1.74.0-7
Severity: minor
Tags: upstream

Dear Maintainer,

Building bitcoind package produces bunch of warnings like this:

```
In file included from 
/usr/include/boost/smart_ptr/detail/sp_thread_sleep.hpp:22,
 from /usr/include/boost/smart_ptr/detail/yield_k.hpp:23,
 from 
/usr/include/boost/smart_ptr/detail/spinlock_std_atomic.hpp:18,
 from /usr/include/boost/smart_ptr/detail/spinlock.hpp:36,
 from /usr/include/boost/smart_ptr/detail/spinlock_pool.hpp:25,
 from /usr/include/boost/smart_ptr/shared_ptr.hpp:29,
 from /usr/include/boost/shared_ptr.hpp:17,
 from /usr/include/boost/date_time/time_clock.hpp:17,
 from /usr/include/boost/thread/thread_time.hpp:9,
 from /usr/include/boost/thread/detail/platform_time.hpp:11,
 from 
/usr/include/boost/thread/pthread/condition_variable.hpp:9,
 from /usr/include/boost/thread/condition_variable.hpp:16,
 from ./util/system.h:38,
 from ./addrman.h:15,
 from ./net.h:10,
 from torcontrol.cpp:10:
/usr/include/boost/function_output_iterator.hpp:14:1: note: ‘#pragma message: 
This header is deprecated. Use  
instead.’
   14 | BOOST_HEADER_DEPRECATED("")
  | ^~~
In file included from 
/usr/include/boost/smart_ptr/detail/sp_thread_sleep.hpp:22,
 from /usr/include/boost/smart_ptr/detail/yield_k.hpp:23,
 from 
/usr/include/boost/smart_ptr/detail/spinlock_std_atomic.hpp:18,
 from /usr/include/boost/smart_ptr/detail/spinlock.hpp:36,
 from /usr/include/boost/smart_ptr/detail/spinlock_pool.hpp:25,
 from /usr/include/boost/smart_ptr/shared_ptr.hpp:29,
 from /usr/include/boost/shared_ptr.hpp:17,
 from /usr/include/boost/signals2/signal.hpp:21,
 from ui_interface.cpp:8:
/usr/include/boost/function_output_iterator.hpp:14:1: note: ‘#pragma message: 
This header is deprecated. Use  
instead.’
   14 | BOOST_HEADER_DEPRECATED("")
```

Bitcoin source does not include `boost/function_output_iterator.hpp` directly, 
and interestingly,
`/usr/include/boost/smart_ptr/detail/sp_thread_sleep.hpp:22` does not contain 
that include either as message suggests...

Anyways, it *is* included in 
`/usr/include/boost/signals2/detail/null_output_iterator.hpp`, and it seems 
it's fixed in upstream:
https://github.com/boostorg/signals2/issues/45

Could we get that fixed for Bullseye, or it's too late..? Warnings are annoying 
:) .

-- 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)

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 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 libboost1.74-dev depends on:
ii  libstdc++-10-dev [libstdc++-dev]  10.2.1-6
ii  libstdc++-8-dev [libstdc++-dev]   8.4.0-6
ii  libstdc++-9-dev [libstdc++-dev]   9.3.0-20

libboost1.74-dev recommends no packages.

Versions of packages libboost1.74-dev suggests:
ii  libboost-atomic1.74-dev   1.74.0-7
ii  libboost-chrono1.74-dev   1.74.0-7
pn  libboost-container1.74-dev
pn  libboost-context1.74-dev  
pn  libboost-contract1.74-dev 
pn  libboost-coroutine1.74-dev
ii  libboost-date-time1.74-dev1.74.0-7
pn  libboost-exception1.74-dev
pn  libboost-fiber1.74-dev
ii  libboost-filesystem1.74-dev   1.74.0-7
pn  libboost-graph-parallel1.74-dev   
pn  libboost-graph1.74-dev
pn  libboost-iostreams1.74-dev
pn  libboost-locale1.74-dev   
pn  libboost-log1.74-dev  
pn  libboost-math1.74-dev 
pn  libboost-mpi-python1.74-dev   
pn  libboost-mpi1.74-dev  
pn  libboost-nowide1.74-dev   
pn  libboost-numpy1.74-dev
pn  libboost-program-options1.74-dev  
pn  libboost-python1.74-dev   
pn  libboost-random1.74-dev   
pn  libboost-regex1.74-dev
ii  libboost-serialization1.74-dev1.74.0-7
pn  libboost-stacktrace1.74-dev   
ii  libboost-system1.74-dev   1.74.0-7
ii  libboost-test1.74-dev 1.74.0-7
ii  libboost-thread1.74-dev   1.74.0-7
pn  libboost-timer1.74-dev
pn  libboost-type-erasure1.74-dev 
pn  libboost-wave1.74-dev 
pn  libboost1.74-doc  
pn  libboost1.74-tools-dev
pn  libmpfrc++-dev
pn  libntl-dev

-- no debconf information

Bug#980326: mutt: diff for NMU version 2.0.2-1.1

[Antonio Radici]

On Tue, Jan 19, 2021 at 09:07:37AM +0100, Salvatore Bonaccorso wrote:
> Control: tags 980326 + patch
> Control: tags 980326 + pending
> 
> Hi Antonio,
> 
> I've prepared an NMU for mutt (versioned as 2.0.2-1.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer (or shorter).
> 
> Actually IMHO it would be more sensible to rebase to the current
> upstream version and cherry-pick the additional commits already queued
> for stable.
> 

Thanks for the patch, I will upgrade to the latest upstream version by Sunday
this week, I have no problem with the NMU!

Does it make sense? When you talk about "additional commits already queued for
stable" what are you referring to?

Bug#976929: parsinsert: FTBFS on ppc64el: incorrect result

[Étienne Mollier]

Control: tags -1 pending

Hi David,

Following up on parsinsert failing to build from source on POWER
64 bits little endian on Debian Testing, I found out that
reducing the compiler optimization level to -O1 allows the test
suite to pass.

The affected configuration is Debian 11 at Testing stage, with
Gcc 10.2.  Affected CPU architectures are armel, armhf,
mips64el, ppc64el (which is the subject of Debian Bug#976929[1])
and riscv64.

Normally, the package is built for Debian with optimization
level -O2, and this passes for all other architectures,
including but not limited to amd64, arm64, i386, mipsel, and
s390x.  Interestingly, when pushing to -O3, the problem may
appear on amd64 architecture, see #964082[2], but it does not
seem to be reproducible on every amd64 CPU though.  In any case,
the erroneous results in output are the same as on more exotic
architectures.

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

I also gave a shot to -Os, sitting in between -O1 and -O2, and
most interestingly, I had a rather different output:

[...]
Loading sequence 18
Loading sequence 20
Loading sequence 22
 taxomony index file: 224931 taxa
Reading Newick Tree: [core_rdp.ntree]
opening source file: [core_rdp.ntree]
Opening file: core_rdp.ntree...Parsing Newick file: core_rdp.ntree  
...Processed 246406 chars of 246447
Newick Tree Read Completed: 10143 taxa, 0 sec
Found duplicate name: [W<85><9c>Ý<9c>U]/nFound duplicate name: 
[W<85><9c>Ý<9c>U]/n...
Loading sequence 10143 [51224]
ERROR - tree member sequence is not available [W<85><9c>Ý<9c>U]
ERROR - tree member sequence is not available [W<85><9c>Ý<9c>U]
[...]
ERROR - tree member sequence is not available [W<85><9c>Ý<9c>U]
ERROR - tree member sequence is not available [W<85><9c>Ý<9c>U]
Process Completed: 1 sec
incorrect result

Note I had non printable characters between the bracket, so may
be pointing to uninitialized memory, or similar.  Not sure how
relevant this is though.

In hope this helps,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#980496: RFS: mda-lv2/1.2.6-1 -- Paul Kellett's MDA plugins ported to LV2

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mda-lv2":

 * Package name: mda-lv2
   Version : 1.2.6-1
   Upstream Author : Dave Robillard 
 * URL : https://drobilla.net/software/mda-lv2/
 * License : GPL-3+, BSD-3-clause
 * Vcs : https://salsa.debian.org/multimedia-team/mda-lv2
   Section : sound

It builds those binary packages:

  mda-lv2 - Paul Kellett's MDA plugins ported to LV2

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

  https://mentors.debian.net/package/mda-lv2/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mda-lv2/mda-lv2_1.2.6-1.dsc

Changes since the last upload:

 mda-lv2 (1.2.6-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Set upstream metadata fields: Repository.
 .
   [ Olivier Humbert ]
   * d/control: adds Piano + alphabetical order
 .
   [ Dennis Braun ]
   * New upstream version 1.2.6
   * Bump dh-compat to 13
   * Bump S-V to 4.5.1
   * Update d/copyright year for my entry
   * Drop obsolete lintian-overrides
   * Update d/upstream/metadata with gitlab links
   * Add d/upstream/signing-key.asc
   * Add pgpmode=auto to d/watch

Regards,
Dennis



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980495: RFS: fomp/1.2.2-1 -- collection of LV2 audio plugins

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: fomp
   Version : 1.2.2-1
   Upstream Author : Dave Robillard 
 * URL : https://drobilla.net/software/fomp/
 * License : GPL-2+, BSD-3-clause
 * Vcs : https://salsa.debian.org/multimedia-team/fomp
   Section : sound

It builds those binary packages:

  fomp - collection of LV2 audio plugins

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/f/fomp/fomp_1.2.2-1.dsc

Changes since the last upload:

 fomp (1.2.2-1) unstable; urgency=medium
 .
   * New upstream version 1.2.2
   * Bump dh-compat to 13
   * Bump S-V to 4.5.1
   * Add pgpmode=auto to d/watch
   * Add d/upstream/signing-key.asc
   * Add d/upstream/metadata
   * Update d/copyright year for my entry
   * Remove unnecessary LDFLAGS from d/rules
   * Include architecture.mk instead of defining DEB_HOST_MULTIARCH

Regards,
Dennis

Bug#972334: severity

[Gianfranco Costamagna]

control: severity -1 important

On Mon, 16 Nov 2020 21:56:27 +0100 Sebastian Ramacher  
wrote:
> On 2020-11-14 23:16:15 +0100, Sylvestre Ledru wrote:
> > severity 972334 normal
> > 
> > thanks
> > 
> > Hello
> > 
> > As this isn't a new regression (it didn't work before), I am lowering the
> > severity to allow migration.
> 
> Technically, it's a regression (it introduces a new failing test in
> testing):
> 
> Issues preventing migration:
> autopkgtest for dolfin/2019.2.0~git20200629.946dbd3-3: amd64: Pass, arm64: 
> Pass, armhf: Ignored failure, i386: Pass, ppc64el: Pass
> autopkgtest for llvm-toolchain-11/1:11.0.0-5: amd64: Pass, arm64: Pass, 
> armhf: Test in progress, i386: Regression ♻ , ppc64el: Test in progress (will 
> not be considered a regression)
> 
> to unblock postgresql-13 and the perl transtion, I've added a hint so that 
> llvm-toolchain-11 for now.
> 

thanks for the hint, so we can now let this one migrate since this is not a 
blocker anymore

G.
> Cheers
> -- 
> Sebastian Ramacher

Bug#979495: clang_delta (creduce, cvise) segfaults when built with LLVM 11

[Gianfranco Costamagna]

control: severity -1 important
control: found -1 1:11.0.0-5
On Thu, 7 Jan 2021 12:02:43 +0100 Matthias Klose  wrote:
> Package: src:llvm-toolchain-11
> Version: 1:11.0.1-1
> Severity: serious
> Tags: sid bullseye
> Forwarded: https://bugs.llvm.org/show_bug.cgi?id=48682
> 
> First seen at https://gcc.gnu.org/PR98557, at least on armhf
> 
> $ cat > wxe_funcs.ii
> static __typeof() a __attribute__((__weakref__("pthread_mutex_destroy")))
> 
> $ /usr/lib/cvise/clang_delta --query-instances=replace-function-def-with-decl
> wxe_funcs.ii
> clang_delta: /usr/lib/llvm-11/include/llvm/ADT/PointerIntPair.h:178: static
> intptr_t llvm::PointerIntPairInfo PtrTraits>::updatePointer(intptr_t, PointerT) [with PointerT = clang::Stmt*;
> unsigned int IntBits = 1; PtrTraits = 
> llvm::PointerLikeTypeTraits;
> intptr_t = int]: Assertion `(PtrWord & ~PointerBitMask) == 0 && "Pointer is 
> not
> sufficiently aligned"' failed.
> Aborted
> 
> Expected behavior:
> 
> $ /usr/lib/cvise/clang_delta --query-instances=replace-function-def-with-decl
> wxe_funcs.ii
> Available transformation instances: 0
> 
> Building the cvise and creduce packages with LLVM 9 or LLVM 10 doesn't show 
> the
> segfault.
> 
> 

Since you changed the cvise dependency back to llvm-9, and llvm-9 is not 
getting removed from
next stable, I'm downgrading this bug for now...

G.

Bug#980494: RFS: ganv/1.8.0-1 -- GObject Introspection data for Ganv

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name    : ganv
   Version : 1.8.0-1
   Upstream Author : David Robillard 
 * URL : https://drobilla.net/software/ganv
 * License : GPL-3+, BSD-3-clause
 * Vcs : https://salsa.debian.org/multimedia-team/ganv
   Section : libs

It builds those binary packages:

  gir1.2-ganv-1.0 - GObject Introspection data for Ganv
  libganv-dev - canvas widget for graph-based interfaces (development 
files)

  libganv-1-1v5 - canvas widget for graph-based interfaces

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/ganv/ganv_1.8.0-1.dsc


Changes since the last upload:

 ganv (1.8.0-1) unstable; urgency=medium
 .
   * New upstream version 1.8.0
   * Refresh ldconfig patch
   * Bump S-V to 4.5.1
   * Clean d/watch

Regards,
Dennis

Bug#979717: Unable to reproduce this accidental-install-via-apt

[Richard Huxton]

I know that ubuntu "masquerades" snap installations as having come via 
apt. I don't see that on bullseye though.


I have installed "lxd" (which is not packaged as a .deb) via snapd.

root@piserver:~# dpkg-query --list lxd
dpkg-query: no packages found matching lxd

root@piserver:~# apt install lxd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package lxd is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'lxd' has no installation candidate

root@piserver:~# snap list lxd
Name  Version  RevTrackingPublisher   Notes
lxd   4.0.418152  4.0/stable  canonical✓  -

While you could clearly install e.g. spotify via snapd I don't see how 
you could do this by accident.


--
  Richard Huxton

Bug#979830: gitlab: Issue view shows error message: "Failed to load sidebar lock status"

[Pirate Praveen]

On Mon, 11 Jan 2021 19:55:18 +0100 Lars Kruse  
wrote:
> after upgrading from 13.4.7-2~fto10+1 to 13.5.6-1~fto10+1, every 
issue

> view shows the following error message at the top:
>
>   Failed to load sidebar lock status

Fixed in 13.5.7 in fasttrack-staging, will upload to fasttrack after 
some packages currently in backports-new is accepted.

Bug#980493: Please add support for Orange Pi One Plus

[harry88]

Source: debian-installer
Severity: wishlist
Tags: patch

Dear installer maintainers,

Please could you generate installer images for the Orange Pi One Plus?
The U-Boot support is already there in unstable, so I think it would
just be a matter of adding orangepi_one_plus to the list in
build/config/arm64/*.cfg, as in the patch below.

Thank you very much,
Harold.

diff --git a/build/config/arm64/netboot-gtk.cfg 
b/build/config/arm64/netboot-gtk.cfg
index 243202414..5bd6fdbbf 100644
--- a/build/config/arm64/netboot-gtk.cfg
+++ b/build/config/arm64/netboot-gtk.cfg
@@ -36,7 +36,7 @@ netboot_images_concatenateable: $(TEMP_KERNEL) $(TEMP_INITRD) 
$(TEMP_DTBS)
cp -r $(TEMP_DTBS) $(TEMP)/netboot_images_concatenateable/dtbs/
cp boot/README.device-tree 
$(TEMP)/netboot_images_concatenateable/dtbs/README
mkdir -p 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)
-   for target in a64-olinuxino nanopi_neo2 orangepi_zero_plus2 pine64_plus 
pinebook teres_i ; do \
+   for target in a64-olinuxino nanopi_neo2 orangepi_one_plus 
orangepi_zero_plus2 pine64_plus pinebook teres_i ; do \
echo "Providing u-boot binaries for $$target ..." ; \
gen-hd-image -v -s "$(IMAGE_SIZE)" -p 32768 -b firmware -o 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${target}.img
 ; \
TARGET=/usr/lib/u-boot/$${target} u-boot-install-sunxi 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${target}.img
 ; \
diff --git a/build/config/arm64/netboot.cfg b/build/config/arm64/netboot.cfg
index 5348b862e..54a30d938 100644
--- a/build/config/arm64/netboot.cfg
+++ b/build/config/arm64/netboot.cfg
@@ -21,7 +21,7 @@ netboot_images_concatenateable: $(TEMP_KERNEL) $(TEMP_INITRD) 
$(TEMP_DTBS)
cp -r $(TEMP_DTBS) $(TEMP)/netboot_images_concatenateable/dtbs/
cp boot/README.device-tree 
$(TEMP)/netboot_images_concatenateable/dtbs/README
mkdir -p 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)
-   for target in a64-olinuxino nanopi_neo2 orangepi_zero_plus2 pine64_plus 
pinebook teres_i ; do \
+   for target in a64-olinuxino nanopi_neo2 orangepi_one_plus 
orangepi_zero_plus2 pine64_plus pinebook teres_i ; do \
echo "Providing u-boot binaries for $$target ..." ; \
gen-hd-image -v -s "$(IMAGE_SIZE)" -p 32768 -b firmware -o 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${target}.img
 ; \
TARGET=/usr/lib/u-boot/$${target} u-boot-install-sunxi 
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${target}.img
 ; \
diff --git a/build/config/arm64/u-boot.cfg b/build/config/arm64/u-boot.cfg
index 68d6978b0..34f7c8685 100644
--- a/build/config/arm64/u-boot.cfg
+++ b/build/config/arm64/u-boot.cfg
@@ -6,7 +6,7 @@ EXTRANAME = $(MEDIUM)/
 .PHONY: u-boot-binaries
 u-boot-binaries:
mkdir -p $(SOME_DEST)/$(EXTRANAME)/
-   for target in a64-olinuxino nanopi_neo2 orangepi_zero_plus2 pine64_plus 
pinebook teres_i ; do \
+   for target in a64-olinuxino nanopi_neo2 orangepi_one_plus 
orangepi_zero_plus2 pine64_plus pinebook teres_i ; do \
echo "Providing u-boot binaries for $$target ..." ; \
gen-hd-image -v -b firmware -o 
$(SOME_DEST)/$(EXTRANAME)/$${target}.img ; \
TARGET=/usr/lib/u-boot/$${target} u-boot-install-sunxi 
$(SOME_DEST)/$(EXTRANAME)/$${target}.img ; \

Bug#980492: RM: pycmail -- RoQA; RC-buggy, unmaintained, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pycmail. It depends on Python 2 and is dropped from testing since 
2019.
The last maintainer upload was in 2016 and the maintainer was also the upstream 
author.

Cheers,
Moritz

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Pirate Praveen]

On Tue, Jan 19, 2021 at 7:52 pm, Maximilian Stein  wrote:



Some good news finally.

After I switched to using only yarn for all modules (use unpatched 
package.json) webpack is working fine. Now I will try to add back 
the packaged modules one by one so we can know which module broke 
it.

This is indeed great news!


I will upload 13.5.7 to fasttrack now.

So, just to clarify, this version will still have the artifact issues?


Someone else reported the artifacts issue was resolved in 13.5.6. See 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968626#40

Bug#980426: old pikepdf is blocking qpdf transition

[James R Barlow]

Jay, the patch looks good to me. I did not try to run it, but it looks like
it covers everything important.

Sean, there is no license change to pikepdf. ocrmypdf did have the license
change. If this is the holdup, ocrmypdf 10.x should work pikepdf 2.x with a
trivial patch - the main change in pikepdf 2.x was dropping support for
Python 3.5. If you are interested in the ocrmypdf 10.x + pikepdf 2.x
combination I can test it and do any patches. pikepdf is now used by other
applications in Debian (e.g. pdfarranger).

ocrmypdf 11's d/copyright was updated to reflect the current copyright
status.

It's been half a year since the ocrmypdf license change and I have not
heard anything from Debian about it. Is there a "queue" somewhere or
someone we can prod to complete this review?

Thanks for your help,
James

Bug#674623: lua50: Possibility to remove the package from the archive

[Witold Baryluk]

Package: lua50
Followup-For: Bug #674623
X-Debbugs-Cc: witold.bary...@gmail.com

Hi,

I was also wondering if there are plans to remove lua50.

popcon dropped long time ago to sub 50.

https://qa.debian.org/cgi-bin/popcon-png?packages=liblua50_installed=1_vote=1_old=0_recent=0_nofiles=0_percent=0_legend=1_ticks=1_date=_date=_date=_fmt=%25Y-%25m

there are still some installs at 926 for lua50, and 1780 for liblua50. But vote
(used) looks really low (~40). This is <=0.02% of sampled install base. And
probably some of it is not buster.

While it is nice to see lua 5.0 being supported on Debian so long, and 
maintained
(i.e. fixing compiles on new compiler or architecture), it is questionable how
long it should be in Debian, considering last and final release was in 2006, and
there are no reverse dependencies in the archive anymore since 2012.

There are few open bugs, that didn't see updates in years, and the secuirity
statuf of lua50 is somehow unclear.


Regards,
Witold

Bug#980491: [pre-approval] buster-pu: package debian-edu-config/2.10.65+deb10u7

[Wolfgang Schweer]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear Debian Buster Release Team,

the Debian Edu team would like to get a fix for bug #935080 into Buster. 
This bug has already been fixed in testing and has proven to work in a
real world deployment. Actually, the fix stems from there.

The reason for the change is present in the changelog:

 share/debian-edu-config/tools/clean-up-host-keytabs: Add script.
 Move host keytabs cleanup code out of gosa-modify-host into a standalone
 script, but still call it from there (for now). Major script improvement:
 Reduce LDAP calls to a single ldapsearch query which greatly improves the
 execution speed of the code. (Closes: #935080).

Full source debdiff attached.

Wolfgang
(on behalf of the Debian Edu team)


debdiff.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#980490: cups-client: Documentation for lp is very incomplete

[Alejandro Colomar]

Package: cups-client
Version: 2.3.3op1-7
Severity: normal
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear Maintainer,

The manual pages for lp(1) and other cups command
lack documentation for many options.
I installed my new printer today,
and I was trying different things to make it work
for my preferences, such as collating copies,
but I found no help in the manual pages.

There's an option '-o collate=true' for that,
which I found in some forum,
but I couldn't find it in the manual.
And I could test that the option works.

I wouldn't mind helping in writing the pages,
if someone could compile the information that is missing.

Thanks,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

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

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

Versions of packages cups-client depends on:
ii  adduser  3.118
ii  cups-common  2.3.3op1-7
ii  libc62.31-9
ii  libcups2 2.3.3op1-7

cups-client recommends no packages.

Versions of packages cups-client suggests:
ii  cups   2.3.3op1-7
pn  cups-bsd   
pn  smbclient  

-- no debconf information

Bug#980406: [Pkg-javascript-devel] Bug#980406: marked as done (node-xterm: likely broken build - JSON.parse: unexpected character at line 1 column 1 of the JSON data Resource)

[Pirate Praveen]

Control: reopen -1
Control: severity -1 important
Control: tags -1 help

On Tue, Jan 19, 2021 at 6:54 pm, Debian Bug Tracking System 
 wrote:

Your message dated Tue, 19 Jan 2021 18:50:13 +
with message-id 
and subject line Bug#980406: fixed in node-xterm 3.8.1+~cs0.9.0-1
has caused the Debian Bug report #980406,
regarding node-xterm: likely broken build - JSON.parse: unexpected 
character at line 1 column 1 of the JSON data Resource

to be marked as done.


I was testing with a wrong version of xterm. So reopening with a lower 
severity. gitlab should not be using the browser bundle but the node 
modules. Its probably the files that are not built that is causing the 
error.


Need help with building node-pty component, which would enable us to 
build src/Terminal.integration.ts

Bug#980443: dovecot-imapd: segfault at 8 ip 000055c38b20f97c sp 00007ffe4baaaa40 error 4 in imap[55c38b1f7000+24000]

[Noah Meyerhans]

On Tue, Jan 19, 2021 at 09:28:58AM +0100, Simon Josefsson wrote:
> Hi.  I noticed the following in my log recently.  Any ideas?
> 
> Jan  6 14:55:54 uggla kernel: [145284.855936] imap[18530]: segfault at 8 ip 
> 55c38b20f97c sp 7ffe4b40 error 4 in imap[55c38b1f7000+24000]
> Jan  6 14:55:54 uggla kernel: [145284.855945] Code: 5d 41 5c 41 5d e9 2b ca 
> fe ff 0f 1f 40 00 45 89 ec 48 89 df 48 39 eb 75 bd 48 8b 45 00 48 8d 35 da f4 
> 00 00 41 bc ff ff ff ff <48> 8b 78 08 e8 8b 77 ff ff 48 83 c4 08 44 89 e0 5b 
> 5d 41 5c 41 5d
> Jan  6 14:55:54 uggla dovecot: imap(simon)<18530><7bj6fTy4vsof0Co6>: Fatal: 
> master: service(imap): child 18530 killed with signal 11 (core dumps disabled 
> - https://dovecot.org/bugreport.html#coredumps)
> 
> The 1:2.3.4.1-5+deb10u5 packages were installed on 2021-01-04:
> 
> 2021-01-04 22:34:01 status installed dovecot-imapd:amd64 1:2.3.4.1-5+deb10u5
> 
> The machine was restarted minutes after that, so on 2021-01-06 (segfault
> log output above) it should have be running then-current packages.
> 
> I'm not able to use ALLOW_COREDUMPS=1 to make sure I get core dumps in
> the future, but I'll report that separately.

It seems from #980444 that you've got coredumps working.  Can you
provide a stack trace for this?

noah