Bug#960249: inn2: Please enable DO_RNEWS_SAVE_BAD for rnews

[herbert]

Package: inn2
Version: 2.6.3-1+deb10u2
Severity: normal

The compile-time option DO_RNEWS_SAVE_BAD should be enabled as
otherwise articles rejected by the news server are lost forever.

-- System Information
Debian Release: 10.3
Kernel Version: Linux gwarestrin 5.2.0+ #3 SMP PREEMPT Tue Aug 20 22:11:45 AEST 
2019 x86_64 GNU/Linux

Bug#917455: command-not-found: when starting mysql.server

[ryan b]

Package: command-not-found
Followup-For: Bug #917455

Dear Maintainer,

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

rbednar@BenderInspiron:/mnt/c/Users/Ryan$ mysql.server start
Could not find the database of available applications, run 
update-command-not-found as root to fix this
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.7.4 final 0
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Exception information:

local variable 'cnf' referenced before assignment
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 93, in main
if not cnf.advise(args[0], options.ignore_installed) and not 
options.no_failure_msg:
UnboundLocalError: local variable 'cnf' referenced before assignment

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

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


-- System Information:
Debian Release: 10.4
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (500, 'stable'), (100, 'xenial-backports')
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=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  10.2019051400
ii  python3  3.7.3-1
ii  python3-apt  1.8.4.1

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
ii  snapd  2.42.1

-- no debconf information

Bug#960248: gdc-10 -flto -fno-weak crashes on some codes

[Witold Baryluk]

Package: gdc-10
Version: 10.1.0-1
Severity: normal

This is for gdc-10. I tested it with gdc-9 and it works without a crash.


$ cat bench.d
// =
import std.conv : to;
int main(string[] args) {
  return cast(int)to!float(args[1]);
}
// ===
$

$ gdc-10 -flto -O2 -fno-weak -o bench_gdc10 bench.d
during IPA pass: cp
lto1: internal compiler error: in possibly_call_in_translation_unit_p, at 
cgraph.c:4092
0x7f0422eade0a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gdc-10 returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status


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

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

Versions of packages gdc-10 depends on:
ii  g++-10 10.1.0-1
ii  gcc-10-base10.1.0-1
ii  libc6  2.30-7
ii  libgmp10   2:6.2.0+dfsg-4
ii  libgphobos-10-dev  10.1.0-1
ii  libisl22   0.22.1-1
ii  libmpc31.1.0-1
ii  libmpfr6   4.0.2-1
ii  libzstd1   1.4.4+dfsg-3
ii  zlib1g 1:1.2.11.dfsg-2

gdc-10 recommends no packages.

gdc-10 suggests no packages.

-- no debconf information

Bug#958901: qreator does not start properly

[Chow Loong Jin]

On Wed, May 06, 2020 at 08:31:45PM +0200, Rainer Dorsch wrote:
> reopen 958901 =
> 
> Am Montag, 4. Mai 2020, 09:39:07 CEST schrieb Chow Loong Jin:
> > On Sun, Apr 26, 2020 at 02:53:21PM +0200, Rainer Dorsch wrote:
> > > Dear Maintainer,
> > > 
> > > I installed qreator on my system (with a KDE desktop).
> > > 
> > > I started qreator but did not see any response or window popping up:
> > > [...]
> > 
> > Hi Rainer,
> > 
> > I suspect that qreator might be hanging at startup while trying resolve
> > your current location to initialize the location QR Code generator
> > widget.
> > 
> > Could you disable the location QR code type by removing
> > /usr/share/qreator/qreator/qrcodes/QRCodeLocation.py and then try
> > launching it again?
> 
> Hi Chow,
> 
> I apologize for the late reply and thank you for your quick reply.
> 
> Not sure if I am allowed to use the control server, so can you please check 
> if 
> the issue got reopened?
> 
> I tried your suggestion, but no luck, I think there is no difference:

> 
> root@h370:~# mv /usr/share/qreator/qreator/qrcodes/QRCodeLocation.py /usr/
> share/qreator/qreator/qrcodes/QRCodeLocation.py.orig
> root@h370:~# Abgemeldet
> rd@h370:~$ qreator 
> /usr/share/qreator/qreator_lib/Builder.py:21: PyGIWarning: Gtk was imported 
> without specifying a version first. Use gi.require_version('Gtk', '3.0') 
> before 
> import to ensure that the right version gets loaded.
>   from gi.repository import GObject, Gtk # pylint: disable=E0611
> /usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:18: PyGIWarning: 
> GtkChamplain was imported without specifying a version first. Use 
> gi.require_version('GtkChamplain', '0.12') before import to ensure that the 
> right version gets loaded.
>   from gi.repository import Gtk, GtkChamplain, Clutter, Champlain
> /usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:20: PyGIWarning: 
> GtkClutter was imported without specifying a version first. Use 
> gi.require_version('GtkClutter', '1.0') before import to ensure that the 
> right 
> version gets loaded.
>   from gi.repository import GtkClutter
> /usr/share/qreator/qreator/qrcodes/QRCodeWifiGtk.py:20: PyGIWarning: NM was 
> imported without specifying a version first. Use gi.require_version('NM', 
> '1.0') before import to ensure that the right version gets loaded.
>   from gi.repository import Gtk, GLib, GdkPixbuf, NM
> No handlers could be found for logger "qreator_lib"
> ^C^C^C^C^C^C^Z
> [1]+  Angehalten  qreator
> rd@h370:~$ kill %1

Judging by your log messages, it looks like qreator was still loading
QRCodeLocation, probably from a .pyc file in
/usr/share/qreator/qreator/qrcodes/__pycache__/.

But nevermind that, could you try upgrading to 16.06.1-5 and trying
again please? I think I've fixed the hanging problem in QRCodeLocation
in that release.

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#960245: fai-server: setup-storage fail when there are multiple nvme

[Franck Hamelin]

Package: fai-server
Version: 5.9.4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
The target system has 2 nvme disks. The disk_config used is :
# example of new config file for setup-storage
#
#

disk_config disk1 disklabel:gpt bootable:1 fstabkey:uuid
primary /boot/efi 512M  vfat  rw
primary -  8G   -  -
primary -  31G   -  -

disk_config disk2 disklabel:gpt bootable:1 fstabkey:uuid
primary -  512M - - 
primary -  8G   -  -
primary -  31G   -  -

disk_config raid always_format:all fstabkey:uuid
raid1 /boot disk1.2,disk2.2 xfs  rw,noatime
raid1 - disk1.3,disk2.3 - -

disk_config lvm always_format:all
vg datavg md1
datavg-root /  10G   xfs  rw,noatime
datavg-tmp  /tmp4G   xfs  rw,noatime
datavg-var  /var6G   xfs  rw,noatime
datavg-swap swap   RAM:200%  swap  sw
datavg-home /home  5G xfs  rw,noatime,nosuid,nodev createopts="-L home"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I had to change /srv/fai/nfsroot/usr/share/fai/setup-storage/Init.pm to replace 
nvme\d+n1 by nvme\d+n\d+
and /srv/fai/nfsroot/usr/lib/fai/fai-disk-info to replace nvme[[:digit:]]+n1$ 
by nvme[[:digit:]]+n[[:digit:]]+$
to get rid of the setup-storage errors.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages fai-server depends on:
ii  debootstrap  1.0.114
ii  e2fsprogs1.44.5-1+deb10u3
ii  fai-client   5.9.4
ii  xz-utils 5.2.4-1

Versions of packages fai-server recommends:
ii  dosfstools4.1-2
pn  isc-dhcp-server   
ii  libproc-daemon-perl   0.23-1
ii  mtools4.0.23-1
ii  nfs-kernel-server 1:1.3.4-2.5
ii  openbsd-inetd [inet-superserver]  0.20160825-4
ii  openssh-client1:7.9p1-10+deb10u2
ii  openssh-server1:7.9p1-10+deb10u2
pn  tftpd-hpa | atftpd

Versions of packages fai-server suggests:
ii  binutils   2.31.1-16
pn  debmirror  
pn  fai-setup-storage  
pn  grub2  
pn  perl-tk
pn  qemu-utils 
ii  reprepro   5.3.0-1
ii  squashfs-tools 1:4.3-12
ii  xorriso1.5.0-1

-- Configuration Files:
/etc/fai/apt/sources.list changed:
deb http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian-security buster/updates main contrib non-free
deb http://deb.debian.org/debian buster-backports main contrib non-free
deb http://fai-project.org/download buster koeln

/etc/fai/nfsroot.conf changed:
FAI_DEBOOTSTRAP="buster http://deb.debian.org/debian;
FAI_ROOTPW='$1$masked'
NFSROOT=/srv/fai/nfsroot
TFTPROOT=/srv/tftp/fai
NFSROOT_HOOKS=/etc/fai/nfsroot-hooks/
FAI_DEBOOTSTRAP_OPTS="--exclude=wget"
FAI_CONFIGDIR=/srv/fai/config


-- no debconf information

Bug#960163: nvidia-driver: x86/modules: Skipping invalid relocation

[Allan Wind]

The good news is that I have the nvidia module working again,
and it's probably a weird edge case:

(1) nvidia-drivers version 418.113-1 is not compatible with linux 
   4.19.0-5 headers and fail to load with relocation error, and

(2) When I was running 4.19.0-9-amd64 (with nouveau),
   `dpkg-reconfigure nvidia-kernel-dkms` rebuild the nvidia 
   module against the -5 headers and they ended up in 
   /lib/modules/4.19.0-9-amd64 which failed to load (i.e. (1)).


Since my attempt yesterday, I purged the -5 kernel, and
`dpkg-reconfigure nvidia-kernel-dkms` now failed with missing
headers.  I then purged the -5 headers and installed the -9 
headers and upon reboot nvidia module was loaded.


I purged linux-image-amd64 a while ago when I explored 
kernel/nvidia combinations as possible work-around for another bug 
#905309 (and #922497).  This meant that I didn't get -9 and hit 
(1) when I thought I was doing a low-risk (stable) upgrade.


Re (1) I don't know _if_ or _how_ Debian should address this
actually, it's incompatibility with the combination of 
nvidia-driver 418.113-1 and linux-headers-4.19.0-5 that only shows 
up at run-time on the subsequent reboot.


Re (2) seems like a straight build defect.  If linux-image version 
x is installed then linux-headers x is used to build a module

for linux-image y (probably as a fallback).  This fails
with a pre-build check if linux-image x not installed.


/Allan

On 2020-05-11 00:29:37, Andreas Beckmann wrote:

On 10/05/2020 14.17, Allan Wind wrote:

No difference:

allan@vent:~$ uname -r
4.19.0-9-amd64


Please send dkms' make.log, probably located at
/var/lib/dkms/nvidia-current/418.113/4.19.0-9-amd64/x86_64/log/make.log

Please try the modules I built in a clean buster environment from
nvidia-kernel-source for the latest buster kernel: install
https://people.debian.org/~anbe/418.113/nvidia-kernel-4.19.0-9-amd64_418.113-1+4.19.118-2_amd64.deb
and remove nvidia-kernel-dkms (to remove the broken build; this will
remove make.log, too, so save it first)

If that works, something is broken in your environment w.r.t building
modules, but I'm not sure how to diagnose ... your gcc-10 experiments
could be related.

What do these commands say?
gcc-8 --version
ld --version


Andreas


--
Allan Wind
Yaxto - Runs Your Business

Bug#954907: python3-dateparser: Warning with autopkgtest when python3.8 is default

[Antoine Beaupré]

Control: tags -1 worksforme

On 2020-03-25 02:39:49, Scott Kitterman wrote:
> Package: python3-dateparser
> Version: 0.7.2-1
> Severity: normal
>
> While investigatin a resolution for #954147, I noticed the following
> warning being emitted.  Presumably this will turn to an error in the
> future and should, at some point, be addressed:
>
> tmp/autopkgtest.ced6Wo/build.9qW/real-tree/dateparser/date.py:142: 
> FutureWarning: Date formats should be list, tuple or set of strings
>   warn(_DateLocaleParser.DATE_FORMATS_ERROR_MESSAGE, FutureWarning)

Hi!

Could you check if this still occurs in the latest version just uploaded
to sid? The warning doesn't occur at build time at least...

a.

-- 
Imagine a world in which every single person on the planet is given
free access to the sum of all human knowledge.
 - Jimmy Wales, co-founder of Wikipedia

Bug#959842: tweeper: warnings with Facebook: Attribute data-referrer redefined in Entity

[Paul Wise]

On Mon, 2020-05-11 at 00:26 +0200, Antonio Ospite wrote:

> these warnings are kind of expected, it's the PHP XML parser which
> tells that the document may not be 100% standard compliant.

I see, that seems reasonable I guess.

> If they are too distracting maybe I can add a verbose option and silence
> them by default. I am the upstream too.

For compatibility with scripts that may be using those warnings in some
way, I would instead add an option to silence the warnings.

> About the empty result, please see below.

TBH I wasn't concerned about that.

> IIRC tweeper only supports "posts" on public Facebook pages,

I see.

> Maybe it would be useful to add support for the home page or for videos
> and photos pages, but I am not sure I have the motivation to do that.

I guess that would be useful to someone, but not for my use case.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#954910: dateparser: Incomplete test coverage due to missing requirements

[Antoine Beaupré]

Control: severity -1 wishlist

On 2020-03-25 03:11:16, Scott Kitterman wrote:
> Source: dateparser
> Version: 0.7.2-1
> Severity: normal
>
> The current pip based install for the test includes two module not in
> Debian:
>
> jdatetime==3.1.0
> umalqurra==0.2
>
> As a result, 7 tests are skipped.  Presumably this means that related
> functionality isn't available to users of the Debian package.  These
> modules should be packaged and then included in Recommends or Suggests.

Those packages seem to be:

https://github.com/tytkal/python-hijiri-ummalqura

"an API that will give you the ability to convert Gregorian to Hijri and
hijri to Gregorian it will give you the day name in arabic and english ,
and the month name in Hijri arabic and Gregorian"

https://pypi.org/project/jdatetime/

"Jalali implementation of Python’s datetime module"

While I would be happy to see those features implemented, since it
depends on external packages, I do not think this bug should be "normal"
but rather "wishlist", as it is a "feature request". :)

I haven't found WNPP bugs for either packages either, anyone should feel
free to file those and link them to this bug when done.

Thanks for the bug report!

a.

Bug#610929: close this bug

[Adrian Mariano]

The proposed message was added to the help.  Close this item.

Bug#960247: jruby: jgem crashes

[Antonio Terceiro]

Package: jruby
Version: 9.1.17.0-3
Severity: important

~$ jgem --version
Unhandled Java exception: java.lang.NoSuchMethodError: 
java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
   encode at org/jruby/RubyEncoding.java:285
   encodeUTF8 at org/jruby/RubyEncoding.java:181
   encodeBytelist at org/jruby/RubyString.java:5533
at org/jruby/RubyString.java:360
at org/jruby/RubyString.java:352
newString at org/jruby/RubyString.java:447
newString at org/jruby/Ruby.java:3489
  createFileClass at org/jruby/RubyFile.java:213
 initCore at org/jruby/Ruby.java:1502
bootstrap at org/jruby/Ruby.java:1286
 init at org/jruby/Ruby.java:1185
  newInstance at org/jruby/Ruby.java:341
  internalRun at org/jruby/Main.java:271
  run at org/jruby/Main.java:232
 main at org/jruby/Main.java:204

`jgem list` has the same result.


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jruby depends on:
ii  ant 1.10.7-1
ii  default-jre [java9-runtime] 2:1.11-72
ii  junit4  4.12-8
ii  libasm-java 7.2-1
ii  libbsf-java 1:2.4.0-8
ii  libbytelist-java1.0.15-1
ii  libdirgra-java  0.3-1
ii  libheadius-options-java 1.4-2
ii  libinvokebinder-java1.7-2
ii  libjansi-java   1.18-1
ii  libjcodings-java1.0.50-1
ii  libjffi-jni 1.2.7-11+b1
ii  libjitescript-java  0.4.1-3
ii  libjnr-constants-java   0.9.9-2
ii  libjnr-enxio-java   0.16-2
ii  libjnr-ffi-java 2.1.7-1
ii  libjnr-netdb-java   1.1.6-1
ii  libjnr-posix-java   3.0.45-2
ii  libjnr-unixsocket-java  0.18-3
ii  libjnr-x86asm-java  1.0.2-5
ii  libjoda-time-java   2.10.5-1
ii  libjruby-joni-java  2.1.34-1
ii  libjzlib-java   1.1.3-2
ii  libmodulator-java   1.0-3
ii  libosgi-core-java   6.0.0-1
ii  libpsych-java   3.1.0+really3.1.0-1
ii  libruby2.7 [ruby-psych] 2.7.1-2
ii  libunsafe-fences-java   1.0-1
ii  libunsafe-mock-java 8.0-3
ii  libyaml-snake-java  1.26+ds-1
ii  nailgun 0.9.3-3+b1
ii  openjdk-10-jre [java9-runtime]  10.0.2+13-2
ii  openjdk-11-jre [java9-runtime]  11.0.7+10-3
ii  openjdk-9-jre [java9-runtime]   9.0.4+12-4
ii  ruby-jar-dependencies   0.3.10-2

Versions of packages jruby recommends:
ii  jruby-openssl   0.9.21-3
ii  libruby2.7 [ruby-json]  2.7.1-2
ii  ri  1:2.7+1
ii  ruby-json   2.3.0+dfsg-1+b2
ii  ruby-rspec  3.9.0c1e0m1s2-1
ii  ruby-test-unit  3.3.5-1

jruby suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#960228: ITP: calls -- A phone dialer and call handler

[Liang Guo]

On Mon, May 11, 2020 at 4:15 AM Evangelos Ribeiro Tzaras
 wrote:
> A dialer program for telephony calls on mobile devices
> supporting multiple backends (ModemManager, oFono, Phonesim).
>
> This package is useful for running debian on mobile phones
> providing call functionality. It is commonly used in phosh.
>
> I would like to maintain in a packaging team, namely Debian On Mobile
> I am also looking for a sponsor.

Interesting package, does it need specific hardware to make call on computer?

-- 
Liang Guo

Bug#959893: appstream-generator: Link against libglibd-2.0.so broken

[Matthias Klumpp]

Am Mi., 6. Mai 2020 um 19:57 Uhr schrieb Markus Frosch :
>
> Package: appstream-generator
> Version: 0.8.1-1+b1
> Severity: grave
> Justification: renders package unusable
>
> Hi maintainer,
> the package possible needs rebuilding.
>
> > appstream-generator: error while loading shared libraries: libglibd-2.0.so:
> > cannot open shared object file: No such file or directory
>
> libglibd-2.0 now has an explicit .0 suffix version:
>
> > $ apt-file search libglibd-2.0.so
> > libglibd-2.0-0: /usr/lib/x86_64-linux-gnu/libglibd-2.0.so.0
> > libglibd-2.0-0: /usr/lib/x86_64-linux-gnu/libglibd-2.0.so.2.1.0
> > libglibd-2.0-dev: /usr/lib/x86_64-linux-gnu/libglibd-2.0.so
>
> Adding a symlink helps, but not sure why this happened.
>
> > ln -s libglibd-2.0.so.0 /usr/lib/x86_64-linux-gnu/libglibd-2.0.so

Very odd, I wonder whet broke this as it's not an issue in
appstream-generator... I suspect either Meson failed here, or even the
LDC compiler.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#960163: nvidia-driver: x86/modules: Skipping invalid relocation

[Allan Wind]

I just saw your email (it went to my spam folder, sorry) and will 
try it shortly.  Meanwhile here is the data you requested:


allan@vent:~$ gcc-8 --version
gcc-8 (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


allan@vent:~$ ld --version
GNU ld (GNU Binutils for Debian) 2.31.1
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the 
terms of
the GNU General Public License version 3 or (at your option) a 
later version.

This program has absolutely no warranty.

Not that it matters, particular, but I have build previous 
versions of the nvidia modules many times on this machine without
issue (other than the module not being compatible with -rt 
kernels).



/Allan

On 2020-05-11 00:29:37, Andreas Beckmann wrote:

On 10/05/2020 14.17, Allan Wind wrote:

No difference:

allan@vent:~$ uname -r
4.19.0-9-amd64


Please send dkms' make.log, probably located at
/var/lib/dkms/nvidia-current/418.113/4.19.0-9-amd64/x86_64/log/make.log

Please try the modules I built in a clean buster environment from
nvidia-kernel-source for the latest buster kernel: install
https://people.debian.org/~anbe/418.113/nvidia-kernel-4.19.0-9-amd64_418.113-1+4.19.118-2_amd64.deb
and remove nvidia-kernel-dkms (to remove the broken build; this will
remove make.log, too, so save it first)

If that works, something is broken in your environment w.r.t building
modules, but I'm not sure how to diagnose ... your gcc-10 experiments
could be related.

What do these commands say?
gcc-8 --version
ld --version


Andreas


--
Allan Wind
Yaxto - Runs Your Business

Bug#960246: ldc: ICE / SIGSEGV when trying to compile D code with -mattr=-x87

[Witold Baryluk]

Package: ldc
Version: 1:1.20.1-1
Severity: normal

This is probably related to the fact that pow by default uses real for
the argument, and it tries to generate x87 code for this.

$ cat f.d
import std.math : pow;

void main() {
double x = pow(1.01, 1.3);
}
$


$ gdb --args ldc2 -mcpu=znver2 -mattr=-x87 ./f.d
Reading symbols from ldc2...
Reading symbols from 
/usr/lib/debug/.build-id/ad/062faf6b99f47b20e4afca986359f365881f56.debug...
(gdb) r
Starting program: /usr/bin/ldc2 -mcpu=znver2 -mattr=-x87 ./f.d
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
allocVirtReg () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/CodeGen/RegAllocFast.cpp:675
675 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/CodeGen/RegAllocFast.cpp:
 No such file or directory.
(gdb) bt
#0  allocVirtReg () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/CodeGen/RegAllocFast.cpp:675
#1  0x74ad4a4a in defineVirtReg () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/CodeGen/RegAllocFast.cpp:795
#2  0x74ad26e1 in allocateInstruction () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/CodeGen/RegAllocFast.cpp:1188
#3  allocateBasicBlock () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/CodeGen/RegAllocFast.cpp:1277
#4  runOnMachineFunction () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/CodeGen/RegAllocFast.cpp:1316
#5  0x74a090b8 in runOnFunction () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/CodeGen/MachineFunctionPass.cpp:73
#6  0x74881c86 in runOnFunction () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/IR/LegacyPassManager.cpp:1648
#7  0x74881f33 in runOnModule () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/IR/LegacyPassManager.cpp:1685
#8  0x748823e0 in runOnModule () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/IR/LegacyPassManager.cpp:1750
#9  run () at 
/build/llvm-toolchain-9-RFyMo0/llvm-toolchain-9-9.0.1/llvm/lib/IR/LegacyPassManager.cpp:1863
#10 0x55cd1219 in (anonymous namespace)::codegenModule (Target=..., 
m=..., filename=filename@entry=0x5617f0b0 "f.o", 
fileType=fileType@entry=llvm::TargetMachine::CGFT_ObjectFile)
at ./driver/toobj.cpp:131
#11 0x55cd1fa6 in (anonymous namespace)::writeObjectFile 
(filename=0x5617f0b0 "f.o", m=0x563e54e0) at ./driver/toobj.cpp:284
#12 writeModule (m=m@entry=0x563e54e0, 
filename=filename@entry=0x5617f0b0 "f.o") at ./driver/toobj.cpp:469
#13 0x55ccea04 in ldc::CodeGenerator::writeAndFreeLLModule 
(this=this@entry=0x7fffd9f0, filename=0x5617f0b0 "f.o") at 
./driver/codegenerator.cpp:285
#14 0x55ccecef in ldc::CodeGenerator::finishLLModule 
(this=this@entry=0x7fffd9f0, m=m@entry=0x71f55930) at 
./driver/codegenerator.cpp:258
#15 0x55ccede3 in ldc::CodeGenerator::finishLLModule (m=0x71f55930, 
this=0x7fffd9f0) at ./driver/codegenerator.cpp:336
#16 ldc::CodeGenerator::emit (this=this@entry=0x7fffd9f0, m=0x71f55930) 
at ./driver/codegenerator.cpp:336
#17 0x55c9e9ef in codegenModules (modules=...) at ./driver/main.cpp:1107
#18 0x55a75dfb in mars_mainBody(Param&, Array&, Array&) () at /usr/lib/llvm-9/include/llvm/LinkAllIR.h:46
#19 0x55ca0e62 in cppmain () at ./driver/main.cpp:1078
#20 0x55e03430 in _D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv ()
#21 0x55e0323f in _d_run_main2 ()
#22 0x55e0309e in _d_run_main ()
#23 0x5598180e in main (argc=argc@entry=4, 
originalArgv=originalArgv@entry=0x7fffe0a8) at 
/usr/lib/llvm-9/include/llvm/ADT/SmallVector.h:144
#24 0x736ece0b in __libc_start_main (main=0x559815c0 , argc=4, argv=0x7fffe0a8, init=, 
fini=, rtld_fini=, 
stack_end=0x7fffe098) at ../csu/libc-start.c:308
#25 0x55983afa in _start () at 
/usr/lib/llvm-9/include/llvm/LinkAllIR.h:46
(gdb) 




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

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

Versions of packages ldc depends on:
ii  libc6  2.30-7
ii  libgcc-s1  10.1.0-1
ii  libllvm9   1:9.0.1-12
ii  libphobos2-ldc-shared-dev  1:1.20.1-1
ii  libstdc++6 10.1.0-1
ii  zlib1g 

Bug#960201: python-gmpy2: autopkgtest regression: RuntimeWarning: coroutine '' was never awaited

[Martin Kelly]

On 5/10/20 8:20 AM, Paul Gevers wrote:

Source: python-gmpy2
Version: 2.1.0~b4-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Because your autopkgtest was part of the tests for glibc, I spotted that
the autopkgtest of python-gmpy2 regressed recently. On 2020-05-01 at
19:13 we had the last successful run on arm64 in testing, the first
failure was also on 2020-05-01, even earlier: at 02:08 in unstable on
amd64. I copied some of the output at the bottom of this report.

Can you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-gmpy2/5338978/log.gz



Thanks for the bug report. Given that no new python-gmpy2 package was 
uploaded on May 1, I'm guessing one of the dependencies of this package 
has broken, or changed in a way that broke this package. Is there a way 
to get a list of packages that were uploaded after the last successful 
test and before the first failure?


+Case Van Horsten, the upstream maintainer. Case, could you take a look 
at the failures here? They seem to have occurred without gmpy2 changing, 
so some dependency is failing.

Bug#956925: dpkg: dpkg-source: should fail before-build if patches can't be applied fully in v3-quilt

[Jiri Palecek]

Hello,

On 19. 04. 20 23:30, Guillem Jover wrote:



while building some of my packages, I noticed they were built without
patches applied. Further investigation in the code showed that it was
caused by dpkg-source --before-build carrying on silently if the first
patch could't be applied, eg. when the series was partially applied, or
the patch itself was somehow defective. It seems this behaviour was a
legacy from package format 2 and IMHO is totally unneeded with quilt. I
therefore suggest to apply this patch, which I've used for several
months now without problems. It relegates the issue of deciding when to
apply patches to quilt.

Unfortunately that's not possible, as people expect to be able to
build packages w/o having used quilt to apply them, for example when
they store a source with patches applied in a VCS.


OK. I have thought about those other workflows and it should be possible
to support it while maintaining a sane function for people using quilt.
My assumption is that when you have the whole tree in git and do not
store .pc, as is discussed in bug 680155, dpkg should not apply the
patches, therefore never create the .pc directory. This can be used to
distinguish these users to users with .pc metadata tracking applied
patches. Of course the first patch heuristic is imprecise (as 680155
shows), but it's been good enough till now so we can go along with that.

The attached patch just checks that the .pc directory exists and if it
doesn't, applies the heuristic. If it exist, I assume the info in the
.pc directory should be good enough to get applied patches list from.
The patch contains a test that checks if it works under both scenarios
(you need to have quilt installed to test it fully).

Please have a look at it. I have another patch that would make workflow
with quilt a lot easier, this one is merely about not building crippled
packages.

Regards

    Jiri Palecek

From 4325fb4becab6745f38b437b37661515f45d12f8 Mon Sep 17 00:00:00 2001
From: =?iso8859-2?q?Ji=F8=ED=20Pale=E8ek?= 
Date: Sun, 27 Oct 2019 18:55:06 +0100
Subject: [PATCH 1/4] Don't pass before-build stage when first patch doesn't
 apply with format V3-quilt

 When the first patch doesn't apply, dpkg-source --before-build
 silently continues. This behaviour is meant to allow it to continue
 when the patch series has been applied, however, it also makes it
 very prone to breakage. Particularly, if your first patch is applied
 but the rest isn't (eg. has been applied upstream), or if it is
 defective, you are going to get a package built with Debian patches
 silently ignored. V2 doesn't offer any such functionality, so IMHO
 the cleanest behaviour is to rely on quilt and fail if patches
 according to its bookkeeping should be applied but can't.

 However, to support the workflows where the package source directory
 contains applied patches, but no .pc directory, this patch retains
 the old behavior when we lack it.

 This patch also contains test for these scenarios.
---
 scripts/Dpkg/Source/Package/V3/Quilt.pm   |   8 +-
 scripts/t/dpkg_source.t   | 208 +-
 scripts/t/dpkg_source/testsuite_3.1-1.dsc |  19 ++
 3 files changed, 223 insertions(+), 12 deletions(-)
 create mode 100644 scripts/t/dpkg_source/testsuite_3.1-1.dsc

diff --git a/scripts/Dpkg/Source/Package/V3/Quilt.pm b/scripts/Dpkg/Source/Package/V3/Quilt.pm
index 45237d26a..647a7f018 100644
--- a/scripts/Dpkg/Source/Package/V3/Quilt.pm
+++ b/scripts/Dpkg/Source/Package/V3/Quilt.pm
@@ -235,9 +235,11 @@ sub check_patches_applied {
 my $next = $quilt->next();
 return if not defined $next;

-my $first_patch = File::Spec->catfile($dir, 'debian', 'patches', $next);
-my $patch_obj = Dpkg::Source::Patch->new(filename => $first_patch);
-return unless $patch_obj->check_apply($dir, fatal_dupes => 1);
+unless (-d $quilt->get_db_dir) {
+my $first_patch = File::Spec->catfile($dir, 'debian', 'patches', $next);
+my $patch_obj = Dpkg::Source::Patch->new(filename => $first_patch);
+return unless $patch_obj->check_apply($dir, fatal_dupes => 1);
+}

 $self->apply_patches($dir, usage => 'preparation', verbose => 1);
 }
diff --git a/scripts/t/dpkg_source.t b/scripts/t/dpkg_source.t
index a0c343846..424f0627a 100644
--- a/scripts/t/dpkg_source.t
+++ b/scripts/t/dpkg_source.t
@@ -16,12 +16,12 @@
 use strict;
 use warnings;

-use Test::More tests => 8;
+use Test::More tests => 46;
 use Test::Dpkg qw(:paths test_neutralize_checksums);

 use File::Spec::Functions qw(rel2abs);
 use File::Compare;
-use File::Path qw(make_path);
+use File::Path qw(make_path remove_tree);

 use Dpkg::IPC;
 use Dpkg::Substvars;
@@ -30,6 +30,9 @@ my $srcdir = rel2abs($ENV{srcdir} || '.');
 my $datadir = "$srcdir/t/dpkg_source";
 my $tmpdir = test_get_temp_path();

+# because $tmpdir is still the same, clear it not to be distracted by leftovers
+remove_tree glob "$tmpdir/*";
+
 $ENV{$_} = rel2abs($ENV{$_}) foreach qw(DPKG_DATADIR 

Bug#960143: sagetex: FTBFS in unstable

[Norbert Preining]

On Mon, 11 May 2020, Hilmar Preuße wrote:
> - tkz-berge.sty does not exist in Debian any more.

commit 2f6b882099bed8fbee175a68cea9e6f27d03462e
Author: Karl Berry 
Date:   Mon Mar 9 21:17:09 2020 +

rm tkz-berge, obsolete on ctan

git-svn-id: svn://tug.org/texlive/trunk@54205 
c570f23f-e606-0410-a88d-b1316a301751

Best

Norbert

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

Bug#959477: ITP: ckeditor3 -- Javascript rich text editor for embedding into websites (v3)

[Bastien ROUCARIES]

On Sat, May 2, 2020 at 9:21 PM Mike Gabriel
 wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Mike Gabriel 
>
> * Package name: ckeditor3
>   Version : 3.6.6.1
>   Upstream Author : Frederico Knabben
> * URL : http://ckeditor.com/download
> * License : GPL-2+
>   Programming Lang: Javascript
>   Description : Javascript rich text editor for embedding into websites 
> (v3)
>
>  I plan to re-upload ckeditor3 to Debian as part of my initiative to
>  re-provide Horde in Debian.
>  .
>  Unfortunately, Horde upstream has still not moved on to ckeditor4, thus this
>  old version of ckeditor is required for the interim.
>  .
>  Before Debian 11 gets released I plan to provide a patch to Horde Upstream
>  that fixes this problem.

ckeditor in debian is 3 by memory

Bug#947734: tf5 and GNUtls interaction, breaks in TLS1.3 connections seemingly!

[Russ Allbery]

Simon Iremonger  writes:

> My suggestion is that may make best sense for tf5 to (if possible)
> disable TLS1.3 usage until this is sorted out in gnutls-land, or indeed,
> openssl 2.0 reaches debian and can just be used with tf5 instead!

I (finally) took a look at this, and sadly there does not appear to be any
way to disable TLSv1.3 using the GnuTLS OpenSSL compatibility library.
The symbols exposed are fairly minimal, and I went through the hopeful
ones and none of them support that.

I'm not sure what's going on here given that a connection to a TLSv1.3
test server seems to work given your follow-up message.  Hopefully OpenSSL
will eventually release under an Apache 2.0 license, and then this can be
resolved by using OpenSSL directly.

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

Bug#902986: tf5: Please package new fork

[Russ Allbery]

Russ Allbery  writes:
> Sebastian Humenda  writes:

>> It would be great if the properly maintained fork of TF could be
>> packaged. It is available here:

>> https://github.com/ingwarsw/tinyfugue

>> I would like to see Python support as a default feature, hence my
>> request.

> Ooo, thank you, I didn't know this existed.  I'll take a look.

Several years later

Do you know if this fork is still being maintained?  All development seems
to have stopped a few months after you opened this bug, and builds for the
latest commit seem to have failed.

I'm a bit reluctant to start packaging a new development branch unless
it's going to be actively maintained, in case we run into bugs.

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

Bug#933180: Patch for #933180

[Federico Ceratto]

Hello Steinar and thank you for the patch.
The current package contains version 1.4.1, also there was already a
branch on Salsa called "split" with ongoing work:
https://salsa.debian.org/debian/libsrt/-/tree/split
https://salsa.debian.org/debian/libsrt/-/jobs/729504
Anyhow, I imported your patch verbatim in the "sesse-orig" branch for
tracking and I'm going to rebase the patch on top of the "split"
branch.
Salsa's CI is proving helpful and Merge Requests are very welcome.

-- 
Federico

Bug#960244: Debian 10.4 Cinnamon "Open in terminal" not working

[Marcelo Vincenzi]

Package: cinnamon
Version: 3.8.8-1

When I right-click anywhere to open a terminal, no new terminal shows up.
I think it is due to gnome-terminal being missing from the live installer out 
of the box.

I suggest that, please, GNOME terminal be added in the live Cinnamon iso.

Using Debian Buster 10.4 with Cinnamon 3.8.8-1 and Linux kernel 4.19.

Bug#959842: tweeper: warnings with Facebook: Attribute data-referrer redefined in Entity

[Antonio Ospite]

On Wed, 06 May 2020 11:37:34 +0800
Paul Wise  wrote:

> Package: tweeper
> Version: 1.4.1-1
> Severity: normal
> Usertags: warnings
> 
> When I run tweeper against Facebook, I get a number of warnings:
> 
> $ tweeper https://www.facebook.com/facebook
> PHP Warning:  Error 42: Attribute data-referrer redefined in Entity, line 22 
> in /usr/share/php/tweeper/src/Tweeper.php on line 257

Hi,

these warnings are kind of expected, it's the PHP XML parser which
tells that the document may not be 100% standard compliant.

If they are too distracting maybe I can add a verbose option and silence
them by default. I am the upstream too.

About the empty result, please see below.

> 
> https://facebook.com;>
>   
> Tweeper
> Facebook - Home | Facebook
> https://www.facebook.com/facebook/
> 
> 
>   Facebook - Home | Facebook
>   https://www.facebook.com/facebook/
>   
> https://scontent-syd2-1.xx.fbcdn.net/v/t1.0-1/p200x200/87284588_124830725745195_9124219877853233152_n.png?_nc_cat=1_nc_sid=dbb9e7_nc_ohc=3tjbRDJdk0sAX8fvvm0_nc_ht=scontent-syd2-1.xxoh=aeac13e958ded89318cbde3c630294ecoe=5ED6584F
> 
>   
> 
> 

IIRC tweeper only supports "posts" on public Facebook pages,
for example the following command successfully scrapes the posts:

$ tweeper https://www.facebook.com/facebook/posts/

Maybe it would be useful to add support for the home page or for videos
and photos pages, but I am not sure I have the motivation to do that.

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#960241: FTBFS: the taglist extension is not safe for parallel reading

[GCS]

Source: mongo-c-driver
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs patch

Hi,

During a test recompilation with the new ICU release I've realized
your package FTBFS in Sid due to a possible behavior change of Sphinx.
The relevant output is:
[  0%] Building HTML documentation with Sphinx
[...]
Warning, treated as error:
the taglist extension is not safe for parallel reading

The following patch fixes this, please apply it as time permits:
--- mongo-c-driver-1.16.1.orig/build/cmake/SphinxBuild.cmake
+++ mongo-c-driver-1.16.1/build/cmake/SphinxBuild.cmake
@@ -40,7 +40,7 @@ function (sphinx_build_html target_name
   ${CMAKE_COMMAND} -E env
   "PYTHONDONTWRITEBYTECODE=1"
   ${SPHINX_EXECUTABLE}
- -j ${NPROCS} -qEW -b html
+ -j 1 -qEW -b html
  -c "${CMAKE_CURRENT_SOURCE_DIR}"
  "${CMAKE_CURRENT_SOURCE_DIR}"
  "${SPHINX_HTML_DIR}"
@@ -133,7 +133,7 @@ function (sphinx_build_man target_name)
   ${CMAKE_COMMAND} -E env
   "PYTHONDONTWRITEBYTECODE=1"
   ${SPHINX_EXECUTABLE}
- -j ${NPROCS} -qEW -b man
+ -j 1 -qEW -b man
  -c "${CMAKE_CURRENT_SOURCE_DIR}"
  "${CMAKE_CURRENT_SOURCE_DIR}"
  "${SPHINX_MAN_DIR}"

Regards,
Laszlo/GCS

Bug#960243: zimlib FTBFS with ICU 67.1

[GCS]

Source: zimlib
Severity: normal
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs

Hi,

Soon the ICU transition will start. Your package FTBFS with the ICU
67.1 version, currently in experimental. The reason is symbol changes
due to it in your libzim4 library. Please take time to check it in
advance.

Thanks,
Laszlo/GCS

Bug#960239: ledger FTBFS with ICU 67.1

[GCS]

Source: ledger
Severity: normal
Justification: fails to build from source (but built successfully in the past)
Tags: upstream ftbfs patch

Hi,

Soon the ICU transition will start. Your package FTBFS with the ICU
67.1 version, currently in experimental. It might be relevant with a
recent upstream change[1]. At least now the following change is needed
for regress/1057.test:
-(("/build/ledger-3.2.0/test/regress/1057.test" 1 (21308 60112 0) nil
"www.amazon.fr"
+(("/build/ledger-3.2.0/test/regress/1057.test" 1 (21308 42112 0) nil
"www.amazon.fr"

Thanks,
Laszlo/GCS
[1] 
https://github.com/ledger/ledger/commit/27387dabed935c0b9185e7a4d11c36d672213f4a

Bug#960242: mozjs68 FTBFS with ICU 67.1

[GCS]

Source: mozjs68
Severity: normal
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs

Hi,

Soon the ICU transition will start. Your package FTBFS with the ICU
67.1 version, currently in experimental. Strange that the build
failure doesn't look like related to ICU (relevant lines hopefully):
make[1]: Entering directory '/build/mozjs68-68.7.0/debian/build/mfbt/tests'
mfbt/tests/TestAlgorithm
/usr/bin/x86_64-linux-gnu-g++ -Wdate-time -D_FORTIFY_SOURCE=2
-fstack-protector-strong -Wall -Wempty-body -Wignored-qualifiers
-Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits
-Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof
-Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough
-Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations
-Wno-error=array-bounds -Wno-error=coverage-mismatch
-Wno-error=free-nonheap-object -Wno-error=multistatement-macros
-Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat
-Wformat-overflow=2 -Wno-noexcept-type -fno-sized-deallocation -g -O2
-fdebug-prefix-map=/build/mozjs68-68.7.0=. -fstack-protector-strong
-Wformat -Werror=format-security -fstack-protector-strong -fno-rtti
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-pthread -pipe -g -fno-omit-frame-pointer -funwind-tables  -o
TestAlgorithm /build/mozjs68-68.7.0/debian/build/mfbt/tests/TestAlgorithm.list
  -lpthread -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro
-Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,--build-id=sha1
-fstack-protector-strong -Wl,-rpath-link,sid/bin
-Wl,-rpath-link,/usr/lib-pie  -lm -ldl
/usr/bin/ld: ../Unified_cpp_mfbt0.o: in function `mozPoisonValueInit':
./debian/build/mfbt/./mfbt/Poison.cpp:120: undefined reference to `sysconf'
/usr/bin/ld: ../Unified_cpp_mfbt0.o: in function `mozilla::RandomUint64()':
./debian/build/mfbt/./mfbt/RandomNum.cpp:118: undefined reference to `syscall'
/usr/bin/ld: ./debian/build/mfbt/./mfbt/RandomNum.cpp:136: undefined
reference to `close'
/usr/bin/ld: ../lz4.o: in function `LZ4_createStream':
./debian/build/mfbt/./mfbt/lz4.c:1288: undefined reference to `malloc'
/usr/bin/ld: ../lz4.o: in function `LZ4_freeStream':
./debian/build/mfbt/./mfbt/lz4.c:1336: undefined reference to `free'
/usr/bin/ld: ../lz4.o: in function `LZ4_createStreamDecode':
./debian/build/mfbt/./mfbt/lz4.c:2075: undefined reference to `calloc'
/usr/bin/ld: ../lz4.o: in function `LZ4_freeStreamDecode':
./debian/build/mfbt/./mfbt/lz4.c:2083: undefined reference to `free'
/usr/bin/ld: TestAlgorithm: hidden symbol `syscall' isn't defined
/usr/bin/ld: final link failed: bad value

Do you have any pointers?

Thanks,
Laszlo/GCS

Bug#960240: libvmime FTBFS with ICU 67.1

[GCS]

Source: libvmime
Severity: normal
Justification: fails to build from source (but built successfully in the past)
Tags: upstream ftbfs patch

Hi,

Soon the ICU transition will start. Your package FTBFS with the ICU
67.1 version, currently in experimental. Your upstream has a patch for
this issue[1].
Please be prepared to update it when it's needed.

Thanks in advance,
Laszlo/GCS
[1] 
https://github.com/kisli/vmime/commit/e96aeeb14dc51deeea70e6fdffa95f80af78fdfc

Bug#960238: FTBFS: exact src:libsignal-protocol-c version checked

[GCS]

Source: dino-im
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: upstream ftbfs patch

Hi,

During a test recompilation with the new ICU release I've realized
your package FTBFS in Sid as it looks for the exact 2.3.2 of
src:libsignal-protocol-c while Sid has version 2.3.3 of that now. It
is fixed by your upstream [1], so please apply that when time permits.

Thanks,
Laszlo/GCS
[1] 
https://github.com/dino/dino/commit/fbd70ceaac5ebbddfa21a580c61165bf5b861303#diff-b72423348b22dce8958ce45d7deff4fa

Bug#960236: chromium FTBFS with ICU 67.1

[GCS]

Source: chromium
Severity: normal
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs

Hi,

Soon the ICU transition will start. Your package FTBFS with the ICU
67.1 version, currently in experimental. The reason is the embedded V8
JavaScript engine needs updating. Can be that it's already included in
new Chromium upstream release(s) as there are two newer ones than
currently packaged. Otherwise patches are available from the V8 GitHub
repository [1].

Please take time to package new upstream releases as those contain
security updates as well.

Thanks,
Laszlo/GCS
[1] https://github.com/v8/v8/commit/3f8dc4b2e5baf77b463334c769af85b79d8c1463

Bug#960237: FTBFS: No such file or directory: /usr/share/zoneinfo/

[GCS]

Source: clickhouse
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs patch

Hi,

During a test recompilation with the new ICU release I've realized
your package FTBFS in Sid with its self-tests. Relevant output logs:
  Start 11: with_server
11/11 Test #11: with_server ***Failed   10.32 sec
[...]
Poco::Exception. Code: 1000, e.code() = 0, e.displayText() =
Exception: Could not determine time zone from TZ variable value:
`Europe/Moscow': boost::filesystem::canonical: No such file or
directory: "/usr/share/zoneinfo/", e.what() = Exception

You need to add tzdata to your build dependencies, that will fix it.

Regards,
Laszlo/GCS

Bug#886525: ITP: rt4-extension-mergeusers -- Merge users (Request Tracker)

[Andrew Ruthven]

Hey Gabriel,

I don't have a readily available .deb, but I can provide if you want.

Otherwise the git repo is on Salsa and you can just build one yourself.

https://salsa.debian.org/request-tracker-team/rt-extension-mergeusers

Cheers,
Andrew

On Sun, 2020-05-10 at 14:12 -0400, Gabriel Filion wrote:
> Hello,
> 
> On Sun, 07 Jan 2018 23:39:36 +1300 Andrew Ruthven 
> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Andrew Ruthven 
> > 
> > * Package name: rt4-extension-mergeusers
> >   Version : 1.03
> >   Upstream Author : Best Practical Solutions, LLC <
> > modu...@bestpractical.com>
> > * URL : 
> > https://metacpan.org/release/RT-Extension-MergeUsers
> > * License : GPL v2
> >   Programming Lang: Perl
> >   Description : Merge users (Request Tracker)
> > 
> >  This extension allows merging users in Request Tracker.
> > 
> > You always end up with duplicate users in a ticketing system since
> > people
> > use different email addresses. This extension provides a mechanism
> > to
> > manage that better.
> > 
> > The intial packaging work has been carried but by myself for my
> > employer.
> > Ongoing maintenance will be by the Debian Request Tracker Group (of
> > which
> > I'm a member).
> 
> I'm quite interested in seeing this extension packaged in debian. Do
> you
> have your packaging work published somewhere that I could retrieve?
> 
-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz  | linux.conf.au 2021, Canberra, AU
Catalyst Cloud:|   http://lca2021.linux.org.au/
   https://catalystcloud.nz|

Bug#956802: Info received (Sorry, the problem still happens with 5.5.0-2)

[Erik Tews]

Hi

It looks like there is a patch available that fixes the issue:

https://patchwork.kernel.org/patch/9757475/

Maybe that can be applied to the current Debian kernel as well.

Erik


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

Bug#894998: ITP: rt4-extension-rest2 -- REST2 API extension (Request Tracker)

[Andrew Ruthven]

Hey Gabriel,

You can fetch a .deb from:

http://mirror.catalyst.net.nz/catalyst/debian/dists/jessie/request-tracker/binary-all/rt4-extension-rest2_1.08c-1_all.deb

The "debian" branch is here: 
https://github.com/catalyst-cloud/rt-extension-rest2/commits/debian

Upstream is about to release v 1.09 which includes a number of features
I've added. Once that is released, then I'll build an updated package.
If someone is prepared to sponsor it (I'm a DM, not a DD), then I'
happy to load it.

Cheers,
Andrew

On Sun, 2020-05-10 at 14:11 -0400, Gabriel Filion wrote:
> Hello,
> 
> On Fri, 06 Apr 2018 14:57:30 +1200 Andrew Ruthven 
> wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Andrew Ruthven 
> > 
> > * Package name: rt4-extension-rest2
> >   Version : 1.03
> >   Upstream Author : Best Practical Solutions <
> > modu...@bestpractical.com>
> > * URL : https://metacpan.org/release/RT-Extension-REST2
> > * License : GPLv2
> >   Programming Lang: Perl
> >   Description : REST2 API extension (Request Tracker)
> > 
> >  This extension adds a modern REST API to Request Tracker.
> > 
> > The existing API for RT is a rather painful RFC822 (yes email)
> > based
> > system via HTTP. This extension provides a much nicer JSON based
> > RESTful
> > interface.
> > 
> > The intial packaging work has been carried but by myself for my
> > employer.
> > Ongoing maintenance will be by the Debian Request Tracker Group (of
> > which
> > I'm a member).
> 
> I'm quite interested in seeing this extension packaged in debian. Do
> you
> have your packaging work published somewhere that I could retrieve?
> 
-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz  | linux.conf.au 2021, Canberra, AU
Catalyst Cloud:|   http://lca2021.linux.org.au/
   https://catalystcloud.nz|

Bug#960163: nvidia-driver: x86/modules: Skipping invalid relocation

[Andreas Beckmann]

On 10/05/2020 14.17, Allan Wind wrote:
> No difference:
> 
> allan@vent:~$ uname -r
> 4.19.0-9-amd64

Please send dkms' make.log, probably located at
/var/lib/dkms/nvidia-current/418.113/4.19.0-9-amd64/x86_64/log/make.log

Please try the modules I built in a clean buster environment from
nvidia-kernel-source for the latest buster kernel: install
https://people.debian.org/~anbe/418.113/nvidia-kernel-4.19.0-9-amd64_418.113-1+4.19.118-2_amd64.deb
and remove nvidia-kernel-dkms (to remove the broken build; this will
remove make.log, too, so save it first)

If that works, something is broken in your environment w.r.t building
modules, but I'm not sure how to diagnose ... your gcc-10 experiments
could be related.

What do these commands say?
gcc-8 --version
ld --version


Andreas

Bug#960143: sagetex: FTBFS in unstable

[Hilmar Preuße]

Am 10.05.2020 um 14:06 teilte Jerome BENOIT mit:
> On 10/05/2020 14:06, Hilmar Preuße wrote:
>> Am 10.05.2020 um 08:46 teilte Jerome BENOIT mit:

Hi,

>>> Hello Graham, thanks for the report.
>>> It sounds a Depends issue.
>>>
>> I guess some style files moved to another Debian package and hence they
>> are missing now.
> 
> I guess something like that.
> 
I guess we have more than 1 issue:

- tkz-berge.sty does not exist in Debian any more.
- you need to declare a BD on sagetex itself, else the sagetex.sty
  is not available.

I'll try to provide a minimal patch.

H.
-- 
sigfault
#206401 http://counter.li.org
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) 
(preloaded format=pdflatex 2020.5.10)  23 NOV 2019 07:38
entering extended mode
 restricted \write18 enabled.
 %&-line parsing enabled.
**example.tex
(./example.tex
LaTeX2e <2020-02-02> patch level 5
L3 programming layer <2020-04-06> (/usr/share/texlive/texmf-dist/tex/latex/base
/article.cls
Document Class: article 2019/12/20 v1.4l Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
File: size10.clo 2019/12/20 v1.4l Standard LaTeX file (size option)
)
\c@part=\count167
\c@section=\count168
\c@subsection=\count169
\c@subsubsection=\count170
\c@paragraph=\count171
\c@subparagraph=\count172
\c@figure=\count173
\c@table=\count174
\abovecaptionskip=\skip47
\belowcaptionskip=\skip48
\bibindent=\dimen134
) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
Package: hyperref 2020/01/14 v7.00d Hypertext links for LaTeX
(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
Package: ltxcmds 2019/12/15 v1.24 LaTeX kernel commands for general use (HO)
) (/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
Package: iftex 2020/03/06 v1.0d TeX engine tests
) (/usr/share/texlive/texmf-dist/tex/latex/pdftexcmds/pdftexcmds.sty
Package: pdftexcmds 2019/11/24 v0.31 Utility functions of pdfTeX for LuaTeX (HO
)
(/usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
Package: infwarerr 2019/12/03 v1.5 Providing info/warning/error messages (HO)
)
Package pdftexcmds Info: \pdf@primitive is available.
Package pdftexcmds Info: \pdf@ifprimitive is available.
Package pdftexcmds Info: \pdfdraftmode found.
) (/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
\KV@toks@=\toks15
) (/usr/share/texlive/texmf-dist/tex/generic/kvsetkeys/kvsetkeys.sty
Package: kvsetkeys 2019/12/15 v1.18 Key value parser (HO)
) (/usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
Package: kvdefinekeys 2019-12-19 v1.6 Define keys (HO)
) (/usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
Package: pdfescape 2019/12/09 v1.15 Implements pdfTeX's escape features (HO)
) (/usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
Package: hycolor 2020-01-27 v1.10 Color options for hyperref/bookmark (HO)
) (/usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
Package: letltxmacro 2019/12/03 v1.6 Let assignment for LaTeX macros (HO)
) (/usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
Package: auxhook 2019-12-17 v1.6 Hooks for auxiliary files (HO)
) (/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
Package: kvoptions 2019/11/29 v3.13 Key value format for package options (HO)
)
\@linkdim=\dimen135
\Hy@linkcounter=\count175
\Hy@pagecounter=\count176
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
File: pd1enc.def 2020/01/14 v7.00d Hyperref: PDFDocEncoding definition (HO)
Now handling font encoding PD1 ...
... no UTF-8 mapping file for font encoding PD1
) (/usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
Package: intcalc 2019/12/15 v1.3 Expandable calculations with integers (HO)
) (/usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
Package: etexcmds 2019/12/15 v1.7 Avoid name clashes with e-TeX commands (HO)
)
\Hy@SavedSpaceFactor=\count177
Package hyperref Info: Hyper figures OFF on input line 4547.
Package hyperref Info: Link nesting OFF on input line 4552.
Package hyperref Info: Hyper index ON on input line 4555.
Package hyperref Info: Plain pages OFF on input line 4562.
Package hyperref Info: Backreferencing OFF on input line 4567.
Package hyperref Info: Implicit mode ON; LaTeX internals redefined.
Package hyperref Info: Bookmarks ON on input line 4800.
\c@Hy@tempcnt=\count178
(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty
\Urlmuskip=\muskip16
Package: url 2013/09/16  ver 3.4  Verb mode for urls, etc.
)
LaTeX Info: Redefining \url on input line 5159.
\XeTeXLinkMargin=\dimen136
(/usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
Package: bitset 2019/12/09 v1.3 Handle bit-vector datatype (HO)
(/usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
Package: bigintcalc 2019/12/15 v1.5 Expandable calculations on big integers (HO
)
))
\Fld@menulength=\count179
\Field@Width=\dimen137
\Fld@charsize=\dimen138
Package hyperref 

Bug#960234: openrc: init.d/checkroot.sh is run too late with /sbin/openrc-init

[Ryutaroh Matsumoto]

Package: openrc
Version: 0.40.3-2
Severity: normal

Dear Maintainer,

With init=/sbin/openrc-init in the kernel command line,
/etc/init.d/checkroot.sh is executed somehow too late, and
causing the following error messages at boot:

savelog: directory /var/log is not writable
/etc/init.d/bootlogs: 35: cannot create /var/log/dmesg: Read-only file system
touch: cannot touch '/var/log/exim4/config.autogenerated.tmp': Read-only file 
system
* ERROR: exim4 failed to start

Adding "rw" to the kernel boot option surpresses this symptom,
but it does not seem a right fix.

Best regards, Ryutaroh Matsumoto


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: openrc-init (via /sbin/openrc-init)
LSM: AppArmor: enabled

Versions of packages openrc depends on:
ii  insserv  1.21.0-1
ii  libaudit11:2.8.5-3+b1
ii  libc62.30-4
ii  libeinfo10.40.3-1
ii  libpam0g 1.3.1-5
ii  librc1   0.40.3-1
ii  libselinux1  3.0-1+b3

openrc recommends no packages.

Versions of packages openrc suggests:
pn  policycoreutils  
ii  sysvinit-core2.96-3

-- no debconf information

Bug#960235: RFS: isakmpd/20041012-9 [QA][RC] -- The Internet Key Exchange protocol openbsd implementation

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "isakmpd"

 * Package name: isakmpd
   Version : 20041012-9
   Upstream Author : Niklas Hallqvist 
 Niels Provos 
 H�kan Olsson 
 * URL : www.openbsd.org
 * License : BSD
 * Vcs : None
   Section : net

It builds those binary packages:

  isakmpd - The Internet Key Exchange protocol openbsd implementation

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/isakmpd/isakmpd_20041012-9.dsc

Changes since the last upload:

   * QA upload.
   * Update Standards-Version to 4.5.0
   * Remove dependency on linux-kernel-headers. (Closes: #959457)
   * Use debhelper-compat.
 - Update compat level to 13.
 - Add misc:Pre-Depends.
   * Remove duplicate priority.
   * Remove whitespace from changelog and control.


-- 
Regards
Sudip

Bug#960229: [DRE-maint] Bug#960229: RFP: pdfbeads -- utility to take scanned page images and convert them to a single PDF file

[Georg Faerber]

Hi Rogério,

Thanks for your mail.

On 20-05-10 17:24:12, Rogério Brito wrote:
> Since I don't know much ruby, I guess that it would be best to have
> people from the Ruby team maintain and/or package it. I am even
> willing to co-maintain it, if necessary, but, again, my knowledge of
> Ruby is minimal.

If you're interested in learning (on your own) and improving your Ruby
packaging skills, I'm happy to give you any help necessary.

Let me know in case you're interested.

Cheers,
Georg

Bug#960233: ITP: node-redux -- predictable state container for JavaScript apps

[Nicolas Mora]

Package: wnpp
Severity: wishlist
Owner: Nicolas Mora 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-redux
  Version : 4.0.5
  Upstream Author : Dan Abramov 
* URL : https://redux.js.org/
* License : Expat
  Programming Lang: JavaScript
  Description :  predictable state container for JavaScript apps

It helps you write applications that behave consistently, run in different
environments (client, server, and native), and are easy to test. On top of
that, it provides a great developer experience, such as live code editing
combined with a time traveling debugger. .
.
You can use Redux together with React, or with any other view library.
It is tiny (2kB, including dependencies).
.
Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Bug#960232: debtree --arch flag not applied recursively

[Chris Dieringer]

Package: debtree
Version: 1.0.10

On debian jessie, I execute:

$ debtree python-gtk2 --arch=armel --no-recommends --no-alternatives
--no-provides

which yields:

"python-numpy" -> "libblas3" [color=blue];
 "libblas3" -> "libquadmath0" [color=blue,label="(>= 4.6)"];

But from the following link you can see there is no armel arch available
for libquadmath0: https://packages.debian.org/jessie/libquadmath0

Thus, I conclude that debtree is incorrectly reporting. Additionally, I'm
not certain where feature requests go, but support for JSON output would
certainly be helpful/preferable versus going straight to graphwiz,
particularly considering that there is not otherwise a clear recipe for
dependency traversal via traditional APIs.

Bug#960231: kubernetes: provision of 'kubeadm' command-line utility

[James Addison]

Source: kubernetes
Version: 1.18.2-2
Severity: important
Tags: patch

Dear Maintainer,

Please find attached a patch to provide the 'kubeadm' command-line utility
in a new 'kubernetes-admin' Debian package, derived from the 'kubernetes'
source package.

I've confirmed that all github.com-based dependencies imported by kubeadm's
golang code covered by existing 'debian/copyright' file entries.

Although most k8s.io-based dependencies imported by kubeadm appear to be 
covered by the wildcard application of Apache-2.0 (since it's the Kubernetes
project's default license), I did notice that one of the SIGS (YAML) appears
to be dual-licensed.  

That was a chance inspection since it performs an imports from a different 
subdomain; I haven't confirmed licensing comprehensively across all of the 
top-level k8s.io-based dependency imports.

Thanks for your work and maintenance of these packages!
James

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru kubernetes-1.18.2/debian/changelog kubernetes-1.18.2/debian/changelog
--- kubernetes-1.18.2/debian/changelog  2020-05-03 22:13:17.0 +0100
+++ kubernetes-1.18.2/debian/changelog  2020-05-10 19:42:02.0 +0100
@@ -1,3 +1,11 @@
+kubernetes (1.18.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload
+  * kubernetes-admin
+- New package containing kubeadm command
+
+ -- James Addison   Sun, 10 May 2020 19:42:02 +0100
+
 kubernetes (1.18.2-2) unstable; urgency=medium
 
   * Added i386 back
diff -Nru kubernetes-1.18.2/debian/control kubernetes-1.18.2/debian/control
--- kubernetes-1.18.2/debian/control2020-05-03 22:12:59.0 +0100
+++ kubernetes-1.18.2/debian/control2020-05-10 15:50:38.0 +0100
@@ -6,6 +6,19 @@
 Standards-Version: 4.3.0
 Homepage: http://kubernetes.io/
 
+Package: kubernetes-admin
+Architecture: amd64 i386 armel armhf arm64 s390x
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Description: Kubernetes master binaries
+ Kubernetes is a portable, extensible, open-source platform for managing
+ containerized workloads and services, that facilitates both declarative
+ configuration and automation. It has a large, rapidly growing ecosystem.
+ Kubernetes services, support, and tools are widely available.
+ .
+ This package ships the Kubernetes kubeadm binary, which can be used
+ to initialize and configure clusters.
+
 Package: kubernetes-client
 Architecture: amd64 i386 armel armhf arm64 s390x
 Depends: ${shlibs:Depends}, ${misc:Depends}
diff -Nru kubernetes-1.18.2/debian/copyright kubernetes-1.18.2/debian/copyright
--- kubernetes-1.18.2/debian/copyright  2020-03-22 10:53:29.0 +
+++ kubernetes-1.18.2/debian/copyright  2020-05-10 19:42:02.0 +0100
@@ -846,6 +846,11 @@
2013 TOML authors
 License: Expat
 
+Files: vendor/sigs.k8s.io/yaml/*
+Copyright: 2014 Sam Ghods
+   2012, 2013 The Go Authors
+License: Expat and BSD-3-clause-SIGS-YAML
+
 Files: vendor/vbom.ml/util/*
 Copyright: 2015 Frits van Bommel
 License: Expat
@@ -1812,3 +1817,29 @@
   .
   Creative Commons may be contacted at creativecommons.org.
 
+License: BSD-3-clause-SIGS-YAML
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions are
+  met:
+  .
+ * Redistributions of source code must retain the above copyright
+  notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above
+  copyright notice, this list of conditions and the following disclaimer
+  in the documentation and/or other materials provided with the
+  distribution.
+ * Neither the name of Google Inc. nor the names of its
+  contributors may be used to endorse or promote products derived from
+  this software without specific prior written permission.
+  .
+  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff 

Bug#960119: dh-vim-addon: missing substvar for non-basic Vim flavours?

[James McCoy]

Control: reassign -1 src:vim 2:8.1.0875-5
Control: retitle -1 Add versions to vim/gvim Provides
Control: affects -1 dh-vim-addon

On Sat, May 09, 2020 at 02:45:13PM -0400, James McCoy wrote:
> On Sat, May 09, 2020 at 07:31:51PM +0300, Nicholas Guriev wrote:
> > It sounds good but does not seem to work. :( At least, apt wants to install 
> > the
> > vim package despite vim-gtk3 already provides vim. Something strange is
> > happening, and I need a bit more investigation.
> 
> Ok, I have an idea of what might be happening.  I think the "Provides:
> vim" needs to be versioned.  I'll test it out later to confirm.

Yeah, that's the problem.  I'll fix this in the Vim packaging.

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

Bug#960213: dh-vim-addon: no helptags, missing tempdir of a package?

[James McCoy]

On Sun, May 10, 2020 at 08:35:53PM +0300, Nicholas Guriev wrote:
> It is me again, sorry for disturbance.

No worries.  Thank you for using and providing feedback about
dh-vim-addon.

> It seems dh_vim-addon(1) does not
> generate tags for :help command because of incomplete $docdir. I daresay
> $tmp variable is missing at 203 line.
> 
> https://salsa.debian.org/vim-team/dh-vim-addon/-/blob/7eae5a5039724dd4e7ea30b1bc597336febcd283/dh_vim-addon#L203

Indeed, it is.

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

Bug#951722: autopkgtest suite flaky on arm64

[Michael Biebl]

Am 10.05.20 um 23:06 schrieb Michael Biebl:
> On Sat, 7 Mar 2020 16:01:22 +0200 Mpampis Kostas 
> wrote:
>> diff --git a/debian/tests/control b/debian/tests/control
>> index 7abd238c3..5bf1dc94b 100644
>> --- a/debian/tests/control
>> +++ b/debian/tests/control
>> @@ -6,5 +6,5 @@ Tests: systemd
>>  Depends: dovecot-core, systemd-sysv
>>  
>>  Test-Command: run-parts --report --exit-on-error debian/tests/usage
>> -Depends: dovecot-imapd, dovecot-pop3d, python3
>> +Depends: dovecot-imapd, dovecot-pop3d, python3, netcat-openbsd
>>  Restrictions: needs-root, breaks-testbed, allow-stderr
>> diff --git a/debian/tests/usage/00_setup b/debian/tests/usage/00_setup
>> index 2eeeb2f73..e90ca7e92 100755
>> --- a/debian/tests/usage/00_setup
>> +++ b/debian/tests/usage/00_setup
>> @@ -29,6 +29,17 @@ chown nobody:nogroup /srv/dovecot-dep8
>>  echo "Restarting the service"
>>  systemctl restart dovecot
>>  
>> +echo "Waiting for the service to be available"
>> +c=0
>> +while ! nc -z -U /var/run/dovecot/auth-userdb; do
>> +c=$(($c+1))
>> +sleep 2
>> +if [ $c -gt 30 ]; then
>> +echo "Timed out waiting for the service to be available" >&2
>> +exit 1
>> +fi
>> +done
> 
> Looping until the service is ready appears to be a workaround/hack at
> best imho.
> 
> The dovecot service should only signal its readiness when the
> communication sockets are ready yet to accept connections. I.e. this
> autopkgtest appears to point at a real issue that should be fixed properly.

Quickly glancing at dovecot.service, I see cat ./dovecot.service.in
...
Type=simple

This is problematic. Type=simple means, the service is considered ready
as soon as the process has been forked off. In case of dovecot, this
does not appear to be the correct choice, as the service is marked ready
before it had a chance to setup its communication channels.

See also https://www.lucas-nussbaum.net/blog/?p=877

My recommendation would be, that dovecot implements the systemd
readiness protocol sd_notify:
https://www.freedesktop.org/software/systemd/man/sd_notify.html


If there are questions, please don't hesitate to ask.

Michael



signature.asc
Description: OpenPGP digital signature

Bug#960218: [Pkg-rust-maintainers] Bug#960218: librust-packed-simd+sleef-sys-dev is no longer installable on armel/mips64el/mipsel/s390x

[peter green]

On 10/05/2020 21:44, Adrian Bunk wrote:

On Sun, May 10, 2020 at 09:29:23PM +0100, peter green wrote:

2. file a bug against ftp.debian.org asking for the removal of
 rust-packed-simd on armel/mips64el/mipsel/s390x

That isn't really a workable option. It would just push the problem down the 
line to other packages. Taken to it's conclusion, solving this through the 
removal request route would mean removing firefox.

Where are you seeing firefox depending on it in any way?

It doesn't, the issue is that removal requests work on all the binaries from a 
source package at once.

removing rust-packed-simd would leave rust-rand in a broken state
removing rust-rand would leave rust-tempfile in a broken state
removing rust-tempfile would leave rust-cbindgen in a broken state
removing rust-cbindgen would leave firefox-esr in a broken state



Also note that librust-packed-simd+sleef-sys-dev cannot be salvaged in
any case.

Agreed.

Bug#951722: autopkgtest suite flaky on arm64

[Michael Biebl]

On Sat, 7 Mar 2020 16:01:22 +0200 Mpampis Kostas 
wrote:
> diff --git a/debian/tests/control b/debian/tests/control
> index 7abd238c3..5bf1dc94b 100644
> --- a/debian/tests/control
> +++ b/debian/tests/control
> @@ -6,5 +6,5 @@ Tests: systemd
>  Depends: dovecot-core, systemd-sysv
>  
>  Test-Command: run-parts --report --exit-on-error debian/tests/usage
> -Depends: dovecot-imapd, dovecot-pop3d, python3
> +Depends: dovecot-imapd, dovecot-pop3d, python3, netcat-openbsd
>  Restrictions: needs-root, breaks-testbed, allow-stderr
> diff --git a/debian/tests/usage/00_setup b/debian/tests/usage/00_setup
> index 2eeeb2f73..e90ca7e92 100755
> --- a/debian/tests/usage/00_setup
> +++ b/debian/tests/usage/00_setup
> @@ -29,6 +29,17 @@ chown nobody:nogroup /srv/dovecot-dep8
>  echo "Restarting the service"
>  systemctl restart dovecot
>  
> +echo "Waiting for the service to be available"
> +c=0
> +while ! nc -z -U /var/run/dovecot/auth-userdb; do
> + c=$(($c+1))
> + sleep 2
> + if [ $c -gt 30 ]; then
> + echo "Timed out waiting for the service to be available" >&2
> + exit 1
> + fi
> +done

Looping until the service is ready appears to be a workaround/hack at
best imho.

The dovecot service should only signal its readiness when the
communication sockets are ready yet to accept connections. I.e. this
autopkgtest appears to point at a real issue that should be fixed properly.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#960211: shorewall: Please package or backport from 5.2.4.4

[Nick]

Package: shorewall
Version: 5.2.3.2-1
Severity: normal
Tags: upstream

Dear Maintainer,

shorewall won't start if I attempt to use SAVE_IPSETS=somename to save
an ipset selectively.  I think I've hit known problems 9 and 12 in


I'm guessing it's easy to reproduce in the current packaged version,
but am happy to provide further details if it might help.

Thanks

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

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

Versions of packages shorewall depends on:
ii  bc 1.07.1-2+b1
ii  debconf [debconf-2.0]  1.5.71
ii  iproute2   4.20.0-2
ii  iptables   1.8.2-4
ii  lsb-base   10.2019051400
ii  perl   5.28.1-6
ii  shorewall-core 5.2.3.2-1

Versions of packages shorewall recommends:
ii  libnetfilter-cthelper0  1.0.0-1+b1

Versions of packages shorewall suggests:
ii  make   4.2.1-1.2
pn  shorewall-doc  

-- Configuration Files:
/etc/shorewall/conntrack [Errno 2] No such file or directory: 
'/etc/shorewall/conntrack'
/etc/shorewall/params [Errno 13] Permission denied: '/etc/shorewall/params'
/etc/shorewall/shorewall.conf changed [not included]

-- debconf-show failed

Bug#960214: gcc-9 breaks libalien-wxwidgets-perl autopkgtest: Can't exec "gcc": No such file or directory

[Niko Tyni]

On Sun, May 10, 2020 at 07:47:33PM +0200, Paul Gevers wrote:
 
> [This looks very similar to bug #960212 which will be a duplicate if
> really gcc-9 is at fault here.]
> 
> With a recent upload of gcc-9 the autopkgtest of libalien-wxwidgets-perl

> # Can't exec "gcc": No such file or directory at
> /usr/share/perl/5.30/ExtUtils/CBuilder/Base.pm line 342.

Hi,

I think the problem is that libalien-wxwidgets-perl Depends: gcc |
c-compiler, but doesn't work with tcc, which provides the latter.
The failing autopkgtest run seems to pick the tcc package for c-compiler
instead of gcc-9.

Similarly for #960212, where iraf-dev Depends: gcc | c-compiler.

I couldn't easily find a definition for the c-compiler virtual package,
but I suspect it's only loosely defined and this bug should to be fixed
by removing the alternative dependency.

I tried to look a bit into what makes apt choose this package combination,
but couldn't find anything. In particular, none of the sid amd64
Packages files around the time seem to result in gcc-9 being temporary
uninstallable, which is what I was suspecting.

I've just scheduled a retry of this job on amd64 to see if it was
transient. In any case, I doubt the fault is in gcc-9.
-- 
Niko Tyni   nt...@debian.org

Bug#959984: krb5: Add "Multi-Arch: foreign" to krb5-doc

[Sam Hartman]

Ah!
Never mind.
You opened a merge requests *months ago* and now are getting around to
opening a BTS bug because I'm a bad maintainer and didn't respond to
your merge request.
Got it.
Apologies.
I'll get to this in a couple of days.
I think I was busy being a less-bad DPL back then:-)

Bug#959984: krb5: Add "Multi-Arch: foreign" to krb5-doc

[Sam Hartman]

Yeah, I just looked at mail server logs, and I have nothing from salsa
even attempted to be delivered going back to may 4.
At one level I totally understand this is not your problem.
At another, if this isn't just something I've done to myself, it could
impact people's responses to merge requests.

Bug#960218: [Pkg-rust-maintainers] Bug#960218: librust-packed-simd+sleef-sys-dev is no longer installable on armel/mips64el/mipsel/s390x

[Adrian Bunk]

On Sun, May 10, 2020 at 09:29:23PM +0100, peter green wrote:
> 
> > 2. file a bug against ftp.debian.org asking for the removal of
> > rust-packed-simd on armel/mips64el/mipsel/s390x
> That isn't really a workable option. It would just push the problem down the 
> line to other packages. Taken to it's conclusion, solving this through the 
> removal request route would mean removing firefox.

Where are you seeing firefox depending on it in any way?

Also note that librust-packed-simd+sleef-sys-dev cannot be salvaged in 
any case.

> Also because there is only a binary dependency and not a build-dependency the 
> next upload would undo the removal.
>...

This is a good point.

cu
Adrian

Bug#959984: krb5: Add "Multi-Arch: foreign" to krb5-doc

[Sam Hartman]

I'm not sure I'm seeing how this comes up in practice for krb5-doc.
Would you mind helping my curiosity out.
Also, I'm somewhat horrified that I didn't get a notification for your
MR.
My notification setting for debian/krb5 is watch.
Have you run into other cases where people were not notified of salsa
MRs?

Bug#960219: pbcopper FTBFS on 32bit: int128 not available

[Andreas Tille]

On Sun, May 10, 2020 at 09:30:52PM +0300, Adrian Bunk wrote:
> int128 is not available on 32bit systems,
> I don't know whether upstream cares about that.

Upstream disabled issue tracker on Github and I have no idea how to
contact them.  Since this kind of software is usually used on high
performance system with large data sets its quite probable that 32bit
systems are not supported.  So I'm tempted to remove 32bit
architectures.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#959409: How to build static and shared library with meson (Was: Bug#959409: pbcopper breaks pbbam)

[Andreas Tille]

Hi,

On Sun, May 10, 2020 at 08:10:48PM +0300, Adrian Bunk wrote:
> Control: reassign -1 libpbcopper1.3.0 1.4.0+dfsg-1
> Control: affects -1 src:pbbam
> ...
> $ objdump -p /usr/lib/x86_64-linux-gnu/libpbcopper.so.1.6.0 | grep SONAME
>   SONAME   libpbcopper.so.1.6.0
> 
> With this SONAME, which looks correct if ABI changes with each 1.x.y
> release, the general package naming is correct.

When checking this package I'd like to fix this by using d-shlibs to
make sure that kind of mistake will not happen in future.  Since
d-shlibs is requiring a static library for the -dev package I'd like
to change the build system to provide both shared and static lib.

Unfortunately I'm not familiar with meson build system.  Is there
any easy example to build both libs?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#960230: thunderbird: Thunderbird doesn't run if DEBUG variable is exported

[Carles Pina i Estany]

Package: thunderbird
Version: 1:68.8.0-1~deb10u1
Severity: important
Tags: patch

Dear Maintainer,

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

   * What led up to the situation?
 In a system we had "export DEBUG=1" (not related to Thunderbird,
 for other reasons)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 After investigating reading /usr/bin/thunderbird : 
 "unset DEBUG" fixed the problem

   * What was the outcome of this action?
 Exporting DEBUG=1 makes "thunderbird" launcher to not launch
 Thunderbird (and to not say anything)

   * What outcome did you expect instead?
 Thunderbird to work, and if it doesn't work should indicate why
 not.

   * Possible solutions:
   -In the beginning of /usr/bin/thunderbird: perhaps do "unset DEBUG DEBUGGER" 
(and other variables?)

   -Perhaps rename all the variables into THUNDERBIRD_DEBUGGER,
   THUNDERBIRD_DEBUG, THUNDERBIRD_SHOW_BACKUP, etc. to avoid "generic
   names" to conflict?

   -At the end of the file if ${DEBUG} == 1 but ${DEBUGGER} == "": it
   exits the launcher without launching and without saying anything: say
   something? (it would have solved the problem but it would have been
   easier to fix it)

   -Assume that this was a user problem and we should not have had
   DEBUG=1 set everywhere :-)


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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libgtk2.0-0   2.24.32-3
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3+deb10u1
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-ca [hunspell-dictionary] 3.0.3+repack1-1
ii  hunspell-en-gb [hunspell-dictionary]  1:6.2.0-1
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  hunspell-es [hunspell-dictionary] 1:6.2.0-1
ii  lightning 1:68.8.0-1~deb10u1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.2-10
ii  fonts-lyx 2.3.2-1
ii  libgssapi-krb5-2  1.17-3

-- no debconf information

Bug#960218: [Pkg-rust-maintainers] Bug#960218: librust-packed-simd+sleef-sys-dev is no longer installable on armel/mips64el/mipsel/s390x

[peter green]

2. file a bug against ftp.debian.org asking for the removal of
rust-packed-simd on armel/mips64el/mipsel/s390x

That isn't really a workable option. It would just push the problem down the 
line to other packages. Taken to it's conclusion, solving this through the 
removal request route would mean removing firefox.

Also because there is only a binary dependency and not a build-dependency the 
next upload would undo the removal.

Be aware that rust in Debian makes heavy use of virtual packages, so tools like "dak 
rm" and the release teams key packages list cannot be trusted for rust packages.

Bug#960229: RFP: pdfbeads -- utility to take scanned page images and convert them to a single PDF file

[Rogério Brito]

Package: wnpp
Severity: wishlist

* Package name: pdfbeads
  Version : 1.1.1
  Upstream Author : Alexey Kryukov 
* URL : https://rubygems.org/gems/pdfbeads/versions/1.1.1
* License : GPL
  Programming Lang: Ruby
  Description : utility to take scanned page images and convert them to a 
single PDF file

PDFBeads is a small utility written in Ruby which takes scanned page images
and converts them into a single PDF file. Unlike other PDF creation tools,
PDFBeads attempts to implement the approach typically used for DjVu
books. Its key feature is separating scanned text (typically black, but
indexed images with a small number of colors are also accepted) from
halftone pictures. Each type of graphical data is encoded into its own layer
with a specific compression method and resolution.

The name `PDFBeads' has been selected for the package because building PDF
files from separate image is comparable to threading beads on a string. It
also seems to be a good choice for a Ruby application.

Here's a few operations you can perform with PDFBeads:

* encode B images using either CCITT Group 4 Fax or JBIG2 compression
  method (you'll need Adam Langley's jbig2 utility, available at
  github.com/agl/jbig2enc/ , for JBIG2 compression);

* combine halftone or indexed pictures with previously binarized text pages,
  placing them into the background layer. Various compression methods of
  background images (JPEG2000, JPEG or PNG-styled deflate compression) are
  supported;

* split mixed images where binarized text is combined with color or
  grayscale pictures (such pages may be produced with ScanTailor – an
  interactive post-processing tool for scanned page, available at
  scantailor.sourceforge.net) and encode each layer separately;

* correctly process indexed images with a limited number of colors, encoding
  each color separately into the foreground layer;

* split color images into background and foreground layers (similar to BG44
  and FG44 chunks in a DjVu file) according to a given mask;

* create PDF files with TOC and metadata;

* read text from hOCR files and create a hidden text layer in the PDF file.

Note that PDFBeads is intended for creating PDF files from previously
processed images, and so it can't done some operations (e. g. converting
color or grayscale scans to B) which should be typically performed with a
special scan processing application, such as ScanTailor.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This program is similar in spirit to djvubind (that we already have in our
repositories), but for PDF files, of course.

I tested it and it works quite well, with only a few modifications: to make
it run, I installed ruby-rmagick, then installed the gem via

gem install pdfbeads

and, only a minor modification was needed to make it run with the current
Ruby 2.7 that we have in Debian: I had to remove the line `import 'iconv'`
from the top level pdfbeads binary and everything was working perfectly
fine.

Since I don't know much ruby, I guess that it would be best to have people
from the Ruby team maintain and/or package it. I am even willing to
co-maintain it, if necessary, but, again, my knowledge of Ruby is minimal.

I plan on uploading a version of Alan Langley's jbig2 encoder (an efficient
B/W format that PDFs use) to our repository. I have it packaged already, but
not uploaded and pdfbeads (and other tools that we have packaged, like
OCRmyPDF, can use it if it is installed).


Thanks for any help,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#960079: Acknowledgement (undefined symbol: _PyNautilusInfoProvider_Type)

[Michael Biebl]

Am 10.05.20 um 22:14 schrieb Michael Biebl:
> Am 10.05.20 um 12:45 schrieb Andreas Henriksson:

>> now. Do you think you could test the attached patch instead?
> 
> 
> 
> $ nautilus
> Initializing Nextcloud-client-nautilus extension
> Using python version sys.version_info(major=3, minor=8, micro=3,
> releaselevel='candidate', serial=1)
> Segmentation fault
> 


Initializing Nextcloud-client-nautilus extension
Using python version sys.version_info(major=3, minor=8, micro=3,
releaselevel='candidate', serial=1)

Thread 1 "nautilus" received signal SIGSEGV, Segmentation fault.
0x7fffda47c184 in PyObject_IsSubclass () from
/usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0
(gdb) bt full
#0  0x7fffda47c184 in PyObject_IsSubclass () at
/usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0
#1  0x7fffdb46feca in nautilus_python_object_get_type () at
/usr/lib/x86_64-linux-gnu/nautilus/extensions-3.0/libnautilus-python.so
#2  0x7fffdb46ec45 in nautilus_module_initialize () at
/usr/lib/x86_64-linux-gnu/nautilus/extensions-3.0/libnautilus-python.so
#3  0x555ff3ae in  ()
#4  0x7720413b in g_type_module_use () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x555ff5ff in  ()
#6  0x555ff69a in nautilus_module_setup ()
#7  0x5559d978 in nautilus_application_startup_common ()
#8  0x771db206 in  () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x771f98d4 in g_signal_emit_valist () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x771f9edf in g_signal_emit () at
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x77301892 in g_application_register () at
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#12 0x77301c4a in  () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#13 0x77301fca in g_application_run () at
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#14 0x5559b647 in main ()



signature.asc
Description: OpenPGP digital signature

Bug#960079: Acknowledgement (undefined symbol: _PyNautilusInfoProvider_Type)

[Michael Biebl]

Am 10.05.20 um 12:45 schrieb Andreas Henriksson:
> Hi Michael,
> 
> On Sat, May 09, 2020 at 08:32:24AM +0200, Michael Biebl wrote:
>> This was broken by debian/patches/gcc10.patch
>>
>> Bringing Andreas into the loop here.
>>
> 
> Thanks for notifying me and sorry for causing the breakage.
> 
> I'm not actually using nautilus-python myself which might be obvious by
> now. Do you think you could test the attached patch instead?



$ nautilus
Initializing Nextcloud-client-nautilus extension
Using python version sys.version_info(major=3, minor=8, micro=3,
releaselevel='candidate', serial=1)
Segmentation fault



signature.asc
Description: OpenPGP digital signature

Bug#960228: ITP: calls -- A phone dialer and call handler

[Evangelos Ribeiro Tzaras]

Package: wnpp
Severity: wishlist
Owner: Evangelos Ribeiro Tzaras 

* Package name: calls
  Version : 0.1.4
  Upstream Author : Guido Günther 
* URL : https://source.puri.sm/Librem5/calls
* License : GPLv3, X11
  Programming Lang: C
  Description : A phone dialer and call handler for mobile devices

A dialer program for telephony calls on mobile devices 
supporting multiple backends (ModemManager, oFono, Phonesim).

This package is useful for running debian on mobile phones
providing call functionality. It is commonly used in phosh.

I would like to maintain in a packaging team, namely Debian On Mobile
I am also looking for a sponsor.

Bug#960070: easy-rsa: Can't load pki/.rnd into RNG when building CA

[Michele Orrù]

Hi Damien,

Thanks for reporting this issue!
The problem was upstream (cf. https://github.com/OpenVPN/easy-rsa/issues/261
), and should be fixed with the next release of easy-rsa.
If you're in a hurry, you can just remove the RANDFILE variable (check the
github issue), or download the update directly from mentors:
https://mentors.debian.net/package/easy-rsa

Cheers,
--
Michele.

Bug#960206: olive-editor: does not start due to OpenColorIO error

[Bartosz Fenski]

Package: olive-editor
Version: 20200210-1
Severity: grave

After fresh install olive doesn't start at all

fenio@udebian:~$ olive-editor
Using Qt version: 5.12.5
[OpenColorIO Info]: Color management disabled. (Specify the $OCIO environment 
variable to enable.)
terminate called after throwing an instance of 'OpenColorIO::v1::Exception'
  what():  Error: Loading the OCIO profile failed. The specified file does not 
appear to be an OCIO configuration.
Aborted



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

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

Versions of packages olive-editor depends on:
ii  ffmpeg 7:4.2.2-1+b1
ii  frei0r-plugins 1.7.0-1
ii  libavcodec58   7:4.2.2-1+b1
ii  libavfilter7   7:4.2.2-1+b1
ii  libavformat58  7:4.2.2-1+b1
ii  libavutil567:4.2.2-1+b1
ii  libc6  2.30-7
ii  libgcc-s1  10.1.0-1
ii  libopencolorio1v5  1.1.1~dfsg0-6+b1
ii  libopenimageio2.1  2.1.13.0~dfsg0-1
ii  libqt5core5a   5.12.5+dfsg-10
ii  libqt5gui5 5.12.5+dfsg-10
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5multimedia5-plugins  5.12.5-1+b1
ii  libqt5widgets5 5.12.5+dfsg-10
ii  libstdc++6 10.1.0-1
ii  libswresample3 7:4.2.2-1+b1
ii  libswscale57:4.2.2-1+b1

olive-editor recommends no packages.

olive-editor suggests no packages.

-- no debconf information

Bug#926250: python3-jsonpatch: fails to upgrade from 'sid' - trying to overwrite /usr/bin/jsondiff

[Andreas Beckmann]

Followup-For: Bug #926250

This change went lost in the 1.25-1 upload:

 python-json-patch (1.23-3) unstable; urgency=medium
   * Manage /usr/bin/jsondiff with update-alternatives to avoid clash with
 python3-jsondiff (Closes: #926250).

Please also add
  Breaks: python3-jsondiff (<< 1.1.1-4~)
i.e. against the versions not using update-alternatives
to prevent partial upgrades.


Andreas

Bug#960227: [firefox] Can't do videoconference

[Sergio Costas]

Package: firefox
Version: 76.0-2
Severity: normal

--- Please enter the report below this line. ---

Two days ago I updated firefox to version 76, and since then I can't do 
videoconference. Before, with version 75, I did several videoconferences 
with the cisco web chat, and jitsi, but now with version 76 it asks for 
permission for audio and video, but keeps "connecting" the video. I 
can't hear or see other people, neither can they see or hear me. The 
same URL works fine with Chrome.



--- System information. ---
Architecture:
Kernel: Linux 5.6.0-1-amd64

Debian Release: bullseye/sid
500 unstable-debug debug.mirrors.debian.org
500 unstable ftp.debian.org
500 suldr www.bchemnet.com
500 stable repo.skype.com
500 stable linux.teamviewer.com
500 stable dl.google.com

--- Package information. ---
Depends (Version) | Installed
=-+-===
libatk1.0-0 (>= 1.12.4) | 2.36.0-2
libc6 (>= 2.29) |
libcairo-gobject2 (>= 1.10.0) |
libcairo2 (>= 1.10.0) |
libdbus-1-3 (>= 1.9.14) |
libdbus-glib-1-2 (>= 0.78) |
libevent-2.1-7 (>= 2.1.8-stable) |
libffi7 (>= 3.3~20180313) |
libfontconfig1 (>= 2.12.6) |
libfreetype6 (>= 2.10.1) |
libgcc-s1 (>= 4.0) |
libgdk-pixbuf2.0-0 (>= 2.22.0) |
libglib2.0-0 (>= 2.31.8) |
libgtk-3-0 (>= 3.0.0) |
libnspr4 (>= 2:4.25~) |
libnss3 (>= 2:3.51.1~) |
libpango-1.0-0 (>= 1.14.0) |
libstdc++6 (>= 9) |
libvpx6 (>= 1.8.0) |
libx11-6 |
libx11-xcb1 (>= 2:1.6.9) |
libxcb-shm0 |
libxcb1 |
libxcomposite1 (>= 1:0.4.5) |
libxdamage1 (>= 1:1.1) |
libxext6 |
libxfixes3 |
libxrender1 |
libxt6 |
zlib1g (>= 1:1.2.11.dfsg) |
fontconfig |
procps |
debianutils (>= 1.16) |


Recommends (Version) | Installed
=-+-===
libavcodec58 |
OR libavcodec-extra58 | 7:4.2.2-1+b1
OR libavcodec57 | 7:3.4.3-1
OR libavcodec-extra57 |
OR libavcodec56 |
OR libavcodec-extra56 |
OR libavcodec55 |
OR libavcodec-extra55 |
OR libavcodec54 |
OR libavcodec-extra54 |
OR libavcodec53 |
OR libavcodec-extra53 |


Suggests (Version) | Installed
===-+-===
fonts-stix |
OR otf-stix |
fonts-lmodern | 2.004.5-6
libgssapi-krb5-2 |
OR libkrb53 |
libcanberra0 |
libgtk2.0-0 |
pulseaudio |



--- Output from package bug script ---


-- Addons package information

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Andreas Tille]

On Sun, May 10, 2020 at 03:51:28PM -0400, Jeffrey Walton wrote:
> > I've now uploaded now with this patch closing the bug - but as I tried to
> > express I'd sleep a bit better if this issue would be recorded somewhere
> > else than in a closed bug.
> 
> Maybe GCC? I believe the component is libgomp.
> 
> If you have a good idea of the problematic source file, then add the
> preprocessoed source with the report. Also see
> https://gcc.gnu.org/bugs/.
> 
> If you don't have an idea, then maybe someone like Andrew or Ian can
> provide some suggestions.

I admit I don't have any idea, sorry.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#960226: elinks: Frequent parallel FTBFS

[Adrian Bunk]

Source: elinks
Version: 0.13.1-1
Severity: serious
Tags: ftbfs patch

https://buildd.debian.org/status/fetch.php?pkg=elinks=arm64=0.13.1-3=1589105703=0
https://buildd.debian.org/status/fetch.php?pkg=elinks=powerpc=0.13.1-3=1589106691=0
https://buildd.debian.org/status/fetch.php?pkg=elinks=armhf=0.13.1-2=1589038536=0

...
# Build docs:
dh_auto_build --builddir doc -- all-docs
cd doc && make -j4 all-docs
make[2]: Entering directory '/<>/doc'
 [CONF2DOC]   doc/features.txt
 [KEYS2DOC]   doc/keymap-actions.txt
 [KEYS2DOC]   doc/keymap-defaults.txt
 [HELP2XML]   doc/option-command.frag.xml
 [HELP2XML]   doc/option-config.frag.xml
 [ASCIIDOC]   doc/elinkskeys.5.xml
 [HELP2XML]   doc/option-command.frag.xhtml
 [HELP2XML]   doc/option-config.frag.xhtml
ERROR: elinkskeys.5.txt: line 97: empty section is not valid
make[2]: *** [Makefile:185: elinkskeys.5.xml] Error 1


Ideally, whatevver is the problem in the Makefile should get fixed.

If this isn't easily possible, the following patch to build the
documentation non-parallel should work around the problem:

--- debian/rules.old2020-05-10 19:53:08.156267190 +
+++ debian/rules2020-05-10 19:53:22.504260239 +
@@ -12,7 +12,7 @@
 override_dh_auto_build:
make V=1
# Build docs:
-   dh_auto_build --builddir doc -- all-docs
+   dh_auto_build --no-parallel --builddir doc -- all-docs
 
 override_dh_installexamples:
dh_installexamples --exclude=.gitignore

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Jeffrey Walton]

On Sun, May 10, 2020 at 2:57 PM Andreas Tille  wrote:
>
> ...
> > --- clustalo-1.2.4/debian/rules   2020-04-14 12:19:44.0 +0300
> > +++ clustalo-1.2.4/debian/rules   2020-04-14 12:19:44.0 +0300
> > @@ -9,6 +9,11 @@
> >  %:
> >   dh $@
> >
> > +ifneq (,$(filter $(DEB_HOST_ARCH), mipsel))
> > +override_dh_auto_configure:
> > + dh_auto_configure -- --without-openmp
> > +endif
> > +
> >  override_dh_auto_build-indep:
> >   # nothing to do here
>
> I've now uploaded now with this patch closing the bug - but as I tried to
> express I'd sleep a bit better if this issue would be recorded somewhere
> else than in a closed bug.

Maybe GCC? I believe the component is libgomp.

If you have a good idea of the problematic source file, then add the
preprocessoed source with the report. Also see
https://gcc.gnu.org/bugs/.

If you don't have an idea, then maybe someone like Andrew or Ian can
provide some suggestions.

Jeff

Bug#960224: update symbols for mips64

[Helmut Grohne]

Source: libffi
Version: 3.3-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libffi ftbfs for mips64 (big endian), because the symbols are wrong.
Please update them using the attached patch.

Helmut
diff --minimal -Nru libffi-3.3/debian/changelog libffi-3.3/debian/changelog
--- libffi-3.3/debian/changelog 2020-03-23 21:28:54.0 +0100
+++ libffi-3.3/debian/changelog 2020-05-10 21:29:50.0 +0200
@@ -1,3 +1,10 @@
+libffi (3.3-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update mips64 symbols. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 10 May 2020 21:29:50 +0200
+
 libffi (3.3-4) unstable; urgency=medium
 
   * Update powerpc sysv assembly for ffi_powerpc.h changes (#541).
diff --minimal -Nru libffi-3.3/debian/libffi7.symbols 
libffi-3.3/debian/libffi7.symbols
--- libffi-3.3/debian/libffi7.symbols   2018-03-13 14:41:17.0 +0100
+++ libffi-3.3/debian/libffi7.symbols   2020-05-10 21:29:46.0 +0200
@@ -2,5 +2,5 @@
  (symver)LIBFFI_BASE_7.0 3.3~20180313
  (symver)LIBFFI_CLOSURE_7.0 3.3~20180313
  (symver|arch=!hppa !ia64 !m68k !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 
3.3~20180313
- (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64el !powerpc !powerpcspe 
!ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313
+ (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64 !mips64el !powerpc 
!powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313
  (symver)LIBFFI_BASE_7.1 3.3~20180313

Bug#960225: ploticus FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: ploticus
Version: 2.42-4.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ploticus fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes ploticus cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru ploticus-2.42/debian/changelog 
ploticus-2.42/debian/changelog
--- ploticus-2.42/debian/changelog  2020-03-29 11:06:52.0 +0200
+++ ploticus-2.42/debian/changelog  2020-05-10 08:46:15.0 +0200
@@ -1,3 +1,10 @@
+ploticus (2.42-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 10 May 2020 08:46:15 +0200
+
 ploticus (2.42-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru ploticus-2.42/debian/rules ploticus-2.42/debian/rules
--- ploticus-2.42/debian/rules  2014-02-02 21:36:27.0 +0100
+++ ploticus-2.42/debian/rules  2020-05-10 08:46:14.0 +0200
@@ -18,7 +18,7 @@
 build-stamp: configure-stamp 
dh_prep 
dh_testdir
-   $(MAKE)
+   dh_auto_build
touch build-stamp
 
 clean:

Bug#960056: src:tasksel: fails to migrate to testing for too long

[Cyril Brulebois]

Hi,

Paul Gevers  (2020-05-10):
> On 10-05-2020 19:55, Paul Gevers wrote:
> >> I fail to see what's the reason for this.
> > 
> > I'll have a more careful look.
> 
> The britney output [1] shows that tasksel isn't migrating because it
> would make task-pkgs-are-installable-faux non-installable in testing:
> skipped: tasksel (0, 56, 48)
> got: 22+0: a-1:a-0:a-0:a-0:i-19:m-0:m-1:p-0:s-1
> * mipsel: task-pkgs-are-installable-faux
> 
> task-pkgs-are-installable-faux isn't a real package, but a package
> created by the release team in the britney code [2] to prevent
> non-installability of tasksel in testing. However, that requires that
> package to be up-to-date with the real tasksel package. In the latest
> upload task-printer-server was dropped, so migrating tasksel to
> testing would make the faux package non-installable, hence it was
> blocked. I have updated the faux package.

Thanks for doing so, I hadn't thought of that when I uploaded tasksel
with that change; I was just trying to accomodate Didier's query to have
that in the following release candidate, and didn't power on the brain
enough apparently…


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


signature.asc
Description: PGP signature

Bug#897236: yorick: flaky autopkgtest: ERROR (txtest) failed to open X display or create X window

[Paul Gevers]

Control: severity -1 serious

Hi,

On Mon, 30 Apr 2018 18:05:47 +0200 Paul Gevers  wrote:
> While inspecting regressions in autopkgtest results¹, I noticed that
> your package yorick fails regularly, without obvious changes. At times
> when these tests fail, the error the follow:
> 
> ERROR (txtest) failed to open X display or create X window
>   LINE: 547  FILE: /usr/lib/yorick/i/testg.i
> 
> Could you please investigate and make your autopkgtest more robust?
> Please contact me if you need help and you think I can provide that (I
> am not subscribed to this bug).

Nowadays, these flaky bugs qualify as serious. Please, if you don't
improve the test then at least add the "flaky" restriction.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

[Andreas Tille]

Hi Adrian,

thanks a lot for your investigation.

On Sun, May 10, 2020 at 11:19:27AM +0300, Adrian Bunk wrote:
> What does fix the problem is disabling OpenMP.
> I suspect OpenMP is somehow broken in gcc >= 8 on mipsel.

I wonder how we could keep this finding to other packages.  I bet it
would not the only issue but it has shown up due to intense testing.
 
> Below is a workaround patch (lower performance of clustalo on mipsel 
> shouldn't be a major problem).

Its definitely no problem - I doubt that the package is used at all on
mipsel.  Its simply of theoretical interest and might uncover hidden
issues (finally some suggestions to enhance the code were found not only
for mipsel).

> --- clustalo-1.2.4/debian/rules   2020-04-14 12:19:44.0 +0300
> +++ clustalo-1.2.4/debian/rules   2020-04-14 12:19:44.0 +0300
> @@ -9,6 +9,11 @@
>  %:
>   dh $@
>  
> +ifneq (,$(filter $(DEB_HOST_ARCH), mipsel))
> +override_dh_auto_configure:
> + dh_auto_configure -- --without-openmp
> +endif
> +
>  override_dh_auto_build-indep:
>   # nothing to do here

I've now uploaded now with this patch closing the bug - but as I tried to
express I'd sleep a bit better if this issue would be recorded somewhere
else than in a closed bug.

Thanks again for your research

Andreas.

-- 
http://fam-tille.de

Bug#960223: taskd: Unsuitable for stable release

[Gordon Ball]

Package: taskd
Severity: serious
Justification: Policy 3.3

taskd has not been uploaded for two releases, and development appears to
be dead upstream. I've long ceased to use it, and the install base
appears (per popcon) to be minimal.

Consequently, this is filed to have it removed from testing, and will
proceed to RM in future if the situation doesn't change.

Bug#960222: python3-traceback2: Remove from Debian?

[Jeremy Bicha]

Package: python3-traceback2
Version: 1.4.0-6

python3-traceback2 describes itself as a backport of the stdlib
traceback module. Now that the Python2 library has been dropped, I
don't think the python3 library makes sense either. The setup.cfg file
suggests that it's not needed since Python 3.5

https://github.com/testing-cabal/traceback2/blob/master/setup.cfg

There are a couple reverse dependencies in Debian that would need to be fixed.

Thanks,
Jeremy Bicha

Bug#960221: yoshimi FTBFS with lv2-dev 1.18.0-1

[Adrian Bunk]

Source: yoshimi
Version: 1.7.0.1-1
Severity: serious
Tags: ftbfs

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

...
/<>/src/LV2_Plugin/YoshimiLV2Plugin.cpp:80:23: error: invalid 
conversion from ‘void* (*)(const _LV2_Descriptor*, double, const char*, const 
LV2_Feature* const*)’ to ‘void* (*)(const LV2_Descriptor*, double, const char*, 
const LV2_Feature* const*)’ [-fpermissive]
   80 | YoshimiLV2Plugin::instantiate,
  | ~~^~~
  |   |
...

Bug#960056: src:tasksel: fails to migrate to testing for too long

[Paul Gevers]

Hi Holger,

On 10-05-2020 19:55, Paul Gevers wrote:
>> I fail to see what's the reason for this.
> 
> I'll have a more careful look.

The britney output [1] shows that tasksel isn't migrating because it
would make task-pkgs-are-installable-faux non-installable in testing:
skipped: tasksel (0, 56, 48)
got: 22+0: a-1:a-0:a-0:a-0:i-19:m-0:m-1:p-0:s-1
* mipsel: task-pkgs-are-installable-faux

task-pkgs-are-installable-faux isn't a real package, but a package
created by the release team in the britney code [2] to prevent
non-installability of tasksel in testing. However, that requires that
package to be up-to-date with the real tasksel package. In the latest
upload task-printer-server was dropped, so migrating tasksel to testing
would make the faux package non-installable, hence it was blocked. I
have updated the faux package.

>> We have some pending changings in git.
>> Should I do another upload, to try to get this fixed?
> 
> That won't hurt after we figure out what's wrong, but I believe it would
> be coincidental if it would fix the issue.

So indeed. You would have to reinstate the task-printer-server for the
migration to work. Please wait with uploading the changes until tasksel
migrates.

Paul

[1] https://release.debian.org/britney/update_output.txt
[2]
https://salsa.debian.org/release-team/britney1/-/blob/master/input/constraints



signature.asc
Description: OpenPGP digital signature

Bug#958538: python-cobra build-dependencies unsatisfiable on mipsel

[Adrian Bunk]

Control: reassign -1 python3-cobra 0.18.0-1
Control: retitle -1 python3-cobra: Missing dependency on python3-sbml5
Control: tags -1 patch

On Thu, Apr 23, 2020 at 03:32:06PM +0100, peter green wrote:
> Source: python-cobra
> Version: 0.14.2-2
> Severity: serious
> 
> (this issue affects both 0.14.2-2 from testing and 0.18.0-1 from unstable)

The problem in testing was fixed in 0.18.0-1:

python-cobra (0.18.0-1) unstable; urgency=medium
...
  * python3-sbml is now python2-sbml5
...
 -- Andreas Tille   Mon, 20 Apr 2020 19:11:22 +0200

(I assume this meant python*3*-sbml5)

> python-cobra's build-dependencies are not satisfiable in testing/unstable on 
> mipsel, it build-depends on python3-sbml5 and libsbml5 which are built by the 
> libsbml source package. libsbml has dropped support for mipsel due to linker 
> memory exhaustion issues.
> 
> Since one of the dependencies is marked as  and since there are no 
> corresponding binary dependencies I presume that these are only needed for 
> the testsuite.
>...

The actual bug is that there are no corresponding binary dependencies.

Warning during the build:
...
   dh_python3 -a -O--buildsystem=pybuild
I: dh_python3 pydist:224: Cannot find package that provides 
python_libsbml_experimental. Please add package that provides it to 
Build-Depends or add "python_libsbml_experimental python3-libsbml-experimental" 
line to debian/py3dist-overrides or add proper dependency to Depends by hand 
and ignore this info.
...

This is also the root cause of the autopkgtest failure:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-cobra/5417105/log.gz

It be reproduced with:
$ python3
Python 3.8.3rc1 (default, Apr 30 2020, 07:33:30) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cobra
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/cobra/__init__.py", line 40, in 
from cobra import io
  File "/usr/lib/python3/dist-packages/cobra/io/__init__.py", line 8, in 

from cobra.io.sbml import read_sbml_model, write_sbml_model, \
  File "/usr/lib/python3/dist-packages/cobra/io/sbml.py", line 41, in 
import libsbml
ModuleNotFoundError: No module named 'libsbml'
>>> 


The suggested workaround works:
$ cat debian/py3dist-overrides 
python_libsbml_experimental python3-sbml5
$ 


I've submitted a request for removal of the mipsel binary,
let's use this bug here for the missing dependency.


cu
Adrian

Bug#960219: pbcopper FTBFS on 32bit: int128 not available

[Adrian Bunk]

Source: pbcopper
Version: 1.6.0+dfsg-1
Severity: serious
Tags: ftbfs

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

...
../include/pbcopper/pbmer/DnaBit.h:16:26: error: expected type-specifier before 
‘__int128’
   16 | __extension__ using BI = __int128;
  |  ^~~~
...


int128 is not available on 32bit systems,
I don't know whether upstream cares about that.

Bug#960220: daq build depends on cruft package iptables-dev

[Adrian Bunk]

Source: daq
Version: 2.0.7-1
Severity: serious
Tags: ftbfs

An old version of iptables-dev is still as cruft package
in unstable, it has already been removed from bullseye.

iptables (1.8.4-1) unstable; urgency=medium
...
  * [f8bb861] src:iptables: drop iptables-dev transitional package
(Closes: #939243)
...
 -- Arturo Borrero Gonzalez   Wed, 04 Dec 2019 11:53:40 +0100

Bug#960218: librust-packed-simd+sleef-sys-dev is no longer installable on armel/mips64el/mipsel/s390x

[Adrian Bunk]

Package: librust-packed-simd+sleef-sys-dev
Version: 0.3.3-4
Severity: serious

Due to the removal of sleef on these architectures (see #958947)
librust-packed-simd+sleef-sys-dev is no longer installable
on armel/mips64el/mipsel/s390x.

Options are:
1. build librust-packed-simd+sleef-sys-dev only on architectures
   where sleef is available, or
2. file a bug against ftp.debian.org asking for the removal of
   rust-packed-simd on armel/mips64el/mipsel/s390x

Bug#960217: RM: python-cobra [mipsel] -- RoQA; build dependency can no longer be fulfilled

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

python3-sbml5 is not available on mipsel,
see #958538 for background.

Bug#960214: gcc-9 breaks libalien-wxwidgets-perl autopkgtest: Can't exec "gcc": No such file or directory

[gregor herrmann]

On Sun, 10 May 2020 19:47:33 +0200, Paul Gevers wrote:

> https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libalien-wxwidgets-perl/5415612/log.gz

> # Can't exec "gcc": No such file or directory at
> /usr/share/perl/5.30/ExtUtils/CBuilder/Base.pm line 342.

So the error comes from ExtUtils::CBuilder::Base which is in
perl-modules-5.30 (and also in libextutils-cbuilder-perl but in a
different directory).

This would affect many more packages …


But FWIW I can't reproduce the problem (in an up2date sid chroot
which should match the quoted versions.) Not sure where this leaves
us …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Willi Resetarits & Stubnblues: Brodaschbiaglgalarii


signature.asc
Description: Digital Signature

Bug#886525: ITP: rt4-extension-mergeusers -- Merge users (Request Tracker)

[Gabriel Filion]

Hello,

On Sun, 07 Jan 2018 23:39:36 +1300 Andrew Ruthven  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andrew Ruthven 
> 
> * Package name: rt4-extension-mergeusers
>   Version : 1.03
>   Upstream Author : Best Practical Solutions, LLC 
> * URL : https://metacpan.org/release/RT-Extension-MergeUsers
> * License : GPL v2
>   Programming Lang: Perl
>   Description : Merge users (Request Tracker)
> 
>  This extension allows merging users in Request Tracker.
> 
> You always end up with duplicate users in a ticketing system since people
> use different email addresses. This extension provides a mechanism to
> manage that better.
> 
> The intial packaging work has been carried but by myself for my employer.
> Ongoing maintenance will be by the Debian Request Tracker Group (of which
> I'm a member).

I'm quite interested in seeing this extension packaged in debian. Do you
have your packaging work published somewhere that I could retrieve?



signature.asc
Description: OpenPGP digital signature

Bug#894998: ITP: rt4-extension-rest2 -- REST2 API extension (Request Tracker)

[Gabriel Filion]

Hello,

On Fri, 06 Apr 2018 14:57:30 +1200 Andrew Ruthven  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andrew Ruthven 
> 
> * Package name: rt4-extension-rest2
>   Version : 1.03
>   Upstream Author : Best Practical Solutions 
> * URL : https://metacpan.org/release/RT-Extension-REST2
> * License : GPLv2
>   Programming Lang: Perl
>   Description : REST2 API extension (Request Tracker)
> 
>  This extension adds a modern REST API to Request Tracker.
> 
> The existing API for RT is a rather painful RFC822 (yes email) based
> system via HTTP. This extension provides a much nicer JSON based RESTful
> interface.
> 
> The intial packaging work has been carried but by myself for my employer.
> Ongoing maintenance will be by the Debian Request Tracker Group (of which
> I'm a member).

I'm quite interested in seeing this extension packaged in debian. Do you
have your packaging work published somewhere that I could retrieve?



signature.asc
Description: OpenPGP digital signature

Bug#945705: selenium-firefoxdriver: Python2 removal in sid/bullseye

[Sascha Girrulat]

Hi Scott,

yes i would like to remove the package.

Regards
Sascha

On 08.05.20 23:19, Scott Talbert wrote:
> On Fri, 29 Nov 2019, Sascha Girrulat wrote:
> 
>> Source: selenium-firefoxdriver
>> Version: 3.14.1-1
>> Severity: normal
>> Tags: sid bullseye
>>
>>
>> Hi,
>>
>> the firefoxdriver supports only firefox version up to 52.0 and does not
>>    work with the current version of firefox anymore. That's why the
>> removal is fine.
>>
>> I'm sorry, i thought that the removal is already done but for some
>> reasons the package is still there.
> 
> Hi,
> 
> So you want to remove selenium-firefoxdriver package from Debian?
> 
> Regards,
> Scott

Bug#960056: src:tasksel: fails to migrate to testing for too long

[Paul Gevers]

Hi Holger,

On 10-05-2020 19:38, Holger Wansing wrote:
> This has already been noted on debian-boot some days ago.

Ack.

> I fail to see what's the reason for this.

I'll have a more careful look.

> We have some pending changings in git.
> Should I do another upload, to try to get this fixed?

That won't hurt after we figure out what's wrong, but I believe it would
be coincidental if it would fix the issue.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#960181: pigz: abort: write error on (No space left on device)

[Rainer Dorsch]

Thanks Raymond for your quick and accurate answer. Fortunately, I am in a much 
better position than what you describe in your blog entry, I had kernel n-1 
and n installed, when trying to install n+1.

I removed my oldest kernel version (n-1) which resolved the issue. I shold 
have created a larger /boot partition in the first place.

Interesting enough there was a initrd.img-4.19.0-9-amd64 created already 
before and also booting the -9 kernel worked well. After removing the n-1 
kernel, the initrd for n+1 grew by around 300 bytes. Since df reported that 
more than 22 MB are free, I do not undertand why update-initramfs complained 
that it has not enough space.

rd@h370:~/tmp.nobackup/covidify-test/reports/images$ ls -l /boot/
insgesamt 192878
-rw-r--r-- 1 root root   206361 Nov 11 01:30 config-4.19.0-6-amd64
-rw-r--r-- 1 root root   206194 Apr 27 07:05 config-4.19.0-8-amd64
-rw-r--r-- 1 root root   206157 Apr 29 11:38 config-4.19.0-9-amd64
drwx-- 3 root root 4096 Jan  1  1970 efi
drwxr-xr-x 5 root root 1024 Mai 10 12:40 grub
-rw-r--r-- 1 root root 56649181 Feb  8 23:32 initrd.img-4.19.0-6-amd64
-rw-r--r-- 1 root root 56680246 Apr 28 23:10 initrd.img-4.19.0-8-amd64
-rw-r--r-- 1 root root 56696108 Mai 10 12:40 initrd.img-4.19.0-9-amd64
drwx-- 2 root root12288 Mai 13  2018 lost+found
-rw-r--r-- 1 root root  3410671 Nov 11 01:30 System.map-4.19.0-6-amd64
-rw-r--r-- 1 root root  3408461 Apr 27 07:05 System.map-4.19.0-8-amd64
-rw-r--r-- 1 root root  3411358 Apr 29 11:38 System.map-4.19.0-9-amd64
-rw-r--r-- 1 root root  5270768 Nov 11 01:30 vmlinuz-4.19.0-6-amd64
-rw-r--r-- 1 root root  5274864 Apr 27 07:05 vmlinuz-4.19.0-8-amd64
-rw-r--r-- 1 root root  5278960 Apr 29 11:38 vmlinuz-4.19.0-9-amd64
rd@h370:~/tmp.nobackup/covidify-test/reports/images$ su -
Passwort: 
root@h370:~# apt-get purge linux-image-4.19.0-6-amd64 
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Die folgenden Pakete werden ENTFERNT:
  linux-image-4.19.0-6-amd64*
0 aktualisiert, 0 neu installiert, 1 zu entfernen und 4 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 269 MB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n] 
(Lese Datenbank ... 613766 Dateien und Verzeichnisse sind derzeit 
installiert.)
Entfernen von linux-image-4.19.0-6-amd64 (4.19.67-2+deb10u2) ...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-4.19.0-6-amd64
/etc/kernel/postrm.d/zz-update-grub:
GRUB-Konfigurationsdatei wird erstellt …
Found background image: .background_cache.png
Linux-Abbild gefunden: /boot/vmlinuz-4.19.0-9-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.19.0-9-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.19.0-8-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.19.0-8-amd64
Adding boot menu entry for EFI firmware configuration
erledigt
initramfs-tools (0.133+deb10u1) wird eingerichtet ...
update-initramfs: deferring update (trigger activated)
(Lese Datenbank ... 609364 Dateien und Verzeichnisse sind derzeit 
installiert.)
Löschen der Konfigurationsdateien von linux-image-4.19.0-6-amd64 
(4.19.67-2+deb10u2) ...
rmdir: konnte '/lib/modules/4.19.0-6-amd64' nicht entfernen: Das Verzeichnis 
ist nicht leer
Trigger für initramfs-tools (0.133+deb10u1) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-4.19.0-9-amd64
root@h370:~# apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete sind zurückgehalten worden:
  gnucash-docs libvpx6 virtualbox virtualbox-qt
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 4 nicht aktualisiert.
root@h370:~# ls -l /boot/
insgesamt 128620
-rw-r--r-- 1 root root   206194 Apr 27 07:05 config-4.19.0-8-amd64
-rw-r--r-- 1 root root   206157 Apr 29 11:38 config-4.19.0-9-amd64
drwx-- 3 root root 4096 Jan  1  1970 efi
drwxr-xr-x 5 root root 1024 Mai 10 15:32 grub
-rw-r--r-- 1 root root 56680246 Apr 28 23:10 initrd.img-4.19.0-8-amd64
-rw-r--r-- 1 root root 56696461 Mai 10 15:33 initrd.img-4.19.0-9-amd64
drwx-- 2 root root12288 Mai 13  2018 lost+found
-rw-r--r-- 1 root root  3408461 Apr 27 07:05 System.map-4.19.0-8-amd64
-rw-r--r-- 1 root root  3411358 Apr 29 11:38 System.map-4.19.0-9-amd64
-rw-r--r-- 1 root root  5274864 Apr 27 07:05 vmlinuz-4.19.0-8-amd64
-rw-r--r-- 1 root root  5278960 Apr 29 11:38 vmlinuz-4.19.0-9-amd64
root@h370:~#

Thanks again
Rainer
-- 
Rainer Dorsch
http://bokomoko.de/

Bug#959783: util-linux: 2.35.1-1 FTBFS in pbuilder chroot: testsuite fails in misc/fallocate and misc/mountpoint

[Chris Hofstaedtler]

Control: clone -1 -2
Control: reassign -2 cowbuilder
Control: retitle -2 cowbuilder: please make / a mountpoint
Control: severity -2 wishlist
Control: affects -2 src:util-linux

Hi pbuilder Team,

it appears / is not a mountpoint in a cowbuilder environment, as
Mark (see below) has submitted test failures in util-linux in such
an environment.

Now util-linux assumes that / is a mountpoint on any Linux or BSD it
builds on; this strikes me as a reasonable assumption ("what else
could it be?"). I'm not saying the util-linux test suite should not
make such assumptions, but generally it would be great if the Debian
tools for building packages behaved in more consistently.

Therefore: please make / a real mountpoint in cowbuilder
environments to avoid surprises.

* Mark Hindley  [200505 13:27]:
[..]
> Unfortunately the testsuite fails when building in a pbuilder/cowbuilder
> chroot. In particular misc/fallocate and misc/mountpoint.
[..]
>  misc/mountpoint: This assumes / is a mountpoint which is not the case in a
> chroot.


Many thanks,
Chris

Bug#909436: 909436: libdrm FTBFS on GNU/Hurd

[Svante Signell]

ping

Bug#960214: gcc-9 breaks libalien-wxwidgets-perl autopkgtest: Can't exec "gcc": No such file or directory

[Paul Gevers]

Source: gcc-9, libalien-wxwidgets-perl
Control: found -1 gcc-9/9.3.0-12
Control: found -1 libalien-wxwidgets-perl/0.69+dfsg-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

[This looks very similar to bug #960212 which will be a duplicate if
really gcc-9 is at fault here.]

With a recent upload of gcc-9 the autopkgtest of libalien-wxwidgets-perl
fails in testing when that autopkgtest is run with the binary packages
of gcc-9 from unstable. It passes when run with only packages from
testing. In tabular form:

passfail
gcc-9   from testing9.3.0-12
libalien-wxwidgets-perl from testing0.69+dfsg-2
all others  from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of gcc-9 to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gcc-9

https://ci.debian.net/data/autopkgtest/testing/amd64/liba/libalien-wxwidgets-perl/5415612/log.gz

autopkgtest [05:08:43]: test autodep8-perl:
/usr/share/pkg-perl-autopkgtest/runner runtime-deps
autopkgtest [05:08:43]: test autodep8-perl: [---

#   Failed test ' /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 exited
successfully'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 106.

#   Failed test ' /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1
produced no (non-whitelisted) output'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108.

#   Failed test 'env PERL_DL_NONLAZY=1  /usr/bin/perl -w
-M"Alien::wxWidgets" -e 1 2>&1 exited successfully'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 106.

#   Failed test 'env PERL_DL_NONLAZY=1  /usr/bin/perl -w
-M"Alien::wxWidgets" -e 1 2>&1 produced no (non-whitelisted) output'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 108.
# Looks like you failed 4 tests of 4.
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t ..
1..4
# Can't exec "gcc": No such file or directory at
/usr/share/perl/5.30/ExtUtils/CBuilder/Base.pm line 342.
#
# ATTENTION: It apperars 'gcc' is not a working compiler, please make
# sure all necessary packages are installed.
#
# Searching configuration for:
# wxWidgets (any version) for (any toolkit); compiler compatibility: nc
(any version);
#
# Available configurations:
# wxWidgets 3.04 for gtk; compiler compatibility: gcc 3.4; options:
no debug, unicode, no mslu
# BEGIN failed--compilation aborted.
not ok 1 -  /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 exited
successfully
not ok 2 -  /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 produced no
(non-whitelisted) output
# Can't exec "gcc": No such file or directory at
/usr/share/perl/5.30/ExtUtils/CBuilder/Base.pm line 342.
#
# ATTENTION: It apperars 'gcc' is not a working compiler, please make
# sure all necessary packages are installed.
#
# Searching configuration for:
# wxWidgets (any version) for (any toolkit); compiler compatibility: nc
(any version);
#
# Available configurations:
# wxWidgets 3.04 for gtk; compiler compatibility: gcc 3.4; options:
no debug, unicode, no mslu
# BEGIN failed--compilation aborted.
not ok 3 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"Alien::wxWidgets"
-e 1 2>&1 exited successfully
not ok 4 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"Alien::wxWidgets"
-e 1 2>&1 produced no (non-whitelisted) output
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/4 subtests

Test Summary Report
---
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t (Wstat: 1024 Tests:
4 Failed: 4)
  Failed tests:  1-4
  Non-zero exit status: 4
Files=1, Tests=4, 11 wallclock secs ( 0.03 usr  0.00 sys +  0.36 cusr
0.07 csys =  0.46 CPU)
Result: FAIL



signature.asc
Description: OpenPGP digital signature

Bug#960185: Acknowledgement (libgsl-dev: fails to converge on beta inv for some values)

[Dirk Eddelbuettel]

On 10 May 2020 at 15:06, Hans Ekbrand wrote:
| My initial test case was this
| 
| double lowerbound = gsl_cdf_beta_Qinv(0.95, 12093.0, 3602.0);
| 
| which appears to be fixed with the patch, but I since found a new case that 
fails:
| 
|   double lowerbound = gsl_cdf_beta_Qinv(0.95, 9656, 5038);  

Thanks for the bug report and reference to upstream patch.

I have no problem with applying the patch in due course (we're in the middle
of the transition, I'd rather wait til it is done).  But I guess we're on the
same page that this is likely an upstream issue.  So have you / will you
report this new issue to upstream?

Dirk

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

Bug#960056: src:tasksel: fails to migrate to testing for too long

[Holger Wansing]

Hi,

Paul Gevers  wrote:
> Source: tasksel
> Version: 3.58
> Severity: serious
> Control: close -1 3.59
> Tags: sid bullseye
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s), kibi,
> 
> 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:tasksel in
> its current version in unstable has been trying to migrate for 60 days
> [2]. Hence, I am filing this bug.

This has already been noted on debian-boot some days ago.
I fail to see what's the reason for this.
We have some pending changings in git.
Should I do another upload, to try to get this fixed?

Holger


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

Bug#960213: dh-vim-addon: no helptags, missing tempdir of a package?

[Nicholas Guriev]

Package: dh-vim-addon
Version: 0.2
Severity: minor

Dear maintainer,

It is me again, sorry for disturbance. It seems dh_vim-addon(1) does not
generate tags for :help command because of incomplete $docdir. I daresay
$tmp variable is missing at 203 line.

https://salsa.debian.org/vim-team/dh-vim-addon/-/blob/7eae5a5039724dd4e7ea30b1bc597336febcd283/dh_vim-addon#L203

(vim-ale_archive20200509_amd64)builder@barberry:~/vim-ale$ cat 
debian/vim-ale.vim-opt-addon
usr/share/vim-ale ale
(vim-ale_archive20200509_amd64)builder@barberry:~/vim-ale$ file 
debian/vim-ale/usr/share/vim-ale/doc
debian/vim-ale/usr/share/vim-ale/doc: directory
(vim-ale_archive20200509_amd64)builder@barberry:~/vim-ale$ DH_VERBOSE=1 
dh_vim-addon
rm -f debian/vim-ale/usr/share/nvim/site/pack/dist-bundle/opt/ale
ln -s ../../../../../vim-ale 
debian/vim-ale/usr/share/nvim/site/pack/dist-bundle/opt/ale
rm -f debian/vim-ale/usr/share/vim/vimfiles/pack/dist-bundle/opt/ale
ln -s ../../../../../vim-ale 
debian/vim-ale/usr/share/vim/vimfiles/pack/dist-bundle/opt/ale
(grep -a -s -v vim-addon:Depends debian/vim-ale.substvars; echo 
"vim-addon:Depends=vim (>= 2:8.1.0693-2~)|neovim (>= 0.2.2-1~)") > 
debian/vim-ale.substvars.new
mv debian/vim-ale.substvars.new debian/vim-ale.substvars
(vim-ale_archive20200509_amd64)builder@barberry:~/vim-ale$ 


-- System Information:
Debian Release: buster/sid
  APT prefers eoan-updates
  APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-51-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-vim-addon depends on:
pn  debhelper   
ii  perl5.28.1-6build1
ii  vim-common  2:8.1.0875-5ubuntu2.1

dh-vim-addon recommends no packages.

dh-vim-addon suggests no packages.

Bug#959733: cant update wireguard

[debianbugs]

Hi,

on my site is the problem solved with ticket 956869. See On:


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

Bug#766424: Update bug tags

[Ross Gammon]

tag 766424// + moreinfo upstream
thanks

Bug#953970: Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)

[Noah Meyerhans]

On Sun, May 10, 2020 at 09:49:18AM +0200, Andreas Tille wrote:
> this bug stays a source of autoremoval warnings noise.  I wonder if
> someone might take action on this to move the package to team
> maintenance.  Eric suggested the cloud team which is perfectly fine for
> me - but can this please made happen.  It should not be that hard once
> the repository is moved to inject the NMUs, the patches in this bug log
> and upload.

I'll move this package to a cloud-team repository and prepare an upload
to unstable on Monday if nobody beats me to it.

noah

Bug#959409: pbcopper breaks pbbam (autopkgtest): libpbcopper.so.1.3.0: cannot open shared object file: No such file or directory

[Adrian Bunk]

Control: reassign -1 libpbcopper1.3.0 1.4.0+dfsg-1
Control: affects -1 src:pbbam

On Sat, May 02, 2020 at 08:09:09AM +0200, Paul Gevers wrote:
>...
> I copied some of the output at the bottom of this report. To be honest,
> this looks a bit messy. 1) libpbcopper.so.1.4.0 is shipped by a package
> called libpbcopper1.3.0 (this may be correct, but very confusing; didn't
> investigate further). 2) pbmerge is opening libpbcopper.so.1.3.0 instead
> of something like libpbcopper.so.1 (and following symlinks). This may be
> correct (again, I didn't investigate), but it makes updates to pbcopper
> very fragile (as in this case) and isn't what normally happens with
> libraries, where the symlinks make it possible to update the package
> without rebuilding if SONAME compatibility is maintained, and otherwise
> trigger a transition that can be handled by the release team.
>...

$ objdump -p /usr/lib/x86_64-linux-gnu/libpbcopper.so.1.6.0 | grep SONAME
  SONAME   libpbcopper.so.1.6.0
$

With this SONAME, which looks correct if ABI changes with each 1.x.y
release, the general package naming is correct.

But the transitions
   libpbcopper.so.1.3.0 -> libpbcopper.so.1.4.0 -> libpbcopper.so.1.6.0
were missing and shipping libpbcopper.so.1.6.0 in libpbcopper1.3.0
is wrong and breaks reverse dependencies.

Reassigning to the package that is at fault here.

cu
Adrian

Bug#960212: gcc-9 breaks iraf autopkgtest: gcc: not found

[Paul Gevers]

Source: gcc-9, iraf
Control: found -1 gcc-9/9.3.0-12
Control: found -1 iraf/2.16.1+2018.11.01-3
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of gcc-9 the autopkgtest of iraf fails in testing
when that autopkgtest is run with the binary packages of gcc-9 from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
gcc-9  from testing9.3.0-12
iraf   from testing2.16.1+2018.11.01-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of gcc-9 to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gcc-9

https://ci.debian.net/data/autopkgtest/testing/amd64/i/iraf/5415611/log.gz

=== Failure in programming.md:323 with ecl.e
===

Expected

cl> softools
cl> xc -w jmptest.x
cl> task $jmptest = jmptest.e
cl> jmptest
status = 0, step = 0
Calling zdojmp
status = 1, step = 1
All OK

Output
==
cl> softools
cl> xc -w jmptest.x
/usr/lib/iraf/unix/hlib/f77.sh: 208: gcc: not found
cl> task $jmptest = jmptest.e
cl> jmptest
ERROR: Cannot open connected subprocess (./jmptest.e)
 called as: `cl ()'
Error while reading login.cl file - may need to rebuild with mkiraf
Fatal startup error.  CL dies.

Diff

@@ -1,8 +1,9 @@
 cl> softools
 cl> xc -w jmptest.x
+/usr/lib/iraf/unix/hlib/f77.sh: 208: gcc: not found
 cl> task $jmptest = jmptest.e
 cl> jmptest
-status = 0, step = 0
-Calling zdojmp
-status = 1, step = 1
-All OK
+ERROR: Cannot open connected subprocess (./jmptest.e)
+ called as: `cl ()'
+Error while reading login.cl file - may need to rebuild with mkiraf
+Fatal startup error.  CL dies.
autopkgtest [05:07:20]: test command1: ---]



signature.asc
Description: OpenPGP digital signature