Bug#946510: Support for accelerated graphics and video decoding on PINE A64+ in bullseye

[andreimpopescu]

On Du, 15 dec 19, 12:17:07, Vagrant Cascadian wrote:
> Control: tags 946510 pending
> 
> On 2019-12-14, Andrei POPESCU wrote:
> >
> > For the Allwinner A64 the sun8i-mixer module is missing, see #946510.
> 
> Thanks for looking into this!
> 
> Did some basic compile testing and pushed to the git kernel repository,
> should land in the next linux 5.3.x and 5.4.x uploads.

Great :)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#946734: [Pkg-rust-maintainers] Bug#946734: rust-addr2line Build-Depends on librust-fallible-iterator-0.1+default-dev which isn't available

[Wolfgang Silbermayr]

On 12/14/19 10:49 PM, Paul Gevers wrote:
> Source: rust-addr2line
> Version: 0.7.0-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainers,
> 
> Your package was never build on a buildd, and was rescheduled 117 days
> ago. Since then, the status is BD-Uninstallable. Can you please make sure that
> we can actually build packages in Debian?

Hi Paul,

Thank you for your report.

We already have a new version of addr2line prepared, but it is still
waiting for rust-gimli to pass the NEW queue.

In my experience, the packages have been able to build in the past, but
became un-buildable due to the update of a dependency (in this case
rust-fallible-iterator).

I prepared an update of a set of packages, namely
rust-{object,fallible-iterator,gimli,addr2line,backtrace} with
consistent versions. However, the upload of rust-gimli landed in the NEW
queue due to having an additional bin package. The details on the
problems we currently have with that can be found in #945542. The whole
situation seems stuck and is somewhere between discouraging and
demotivating for the whole debian-rust team atm.

> Please check https://release.debian.org/transitions/html/rust.html, there is 
> at
> least one more packages like this one: rust-nitrokey-test. Can/should I
> reschedule all the red packages or will that fail anyways?

I take a look at this page at regular intervals, that was one of the
incentives to start working on the set of packages as described above.
Can't say for the other packages though. It is well possible that they
are in a similar situation.

Wolfgang.

Bug#946752: [Pkg-opencl-devel] Bug#946752: intel-opencl-icd: Depends on libigdgmm5, which no longer exists

[Jacek Danecki]

On 2019-12-15 10:53, Rebecca N. Palmer wrote:

Package: intel-opencl-icd
Version: 19.29.13530-1
Severity: serious
Justification: makes package uninstallable

This package's debian/control hardcodes a dependency on libigdgmm5.  As this library has changed soname to libigdgmm11, this 
makes it uninstallable.


Neo runtime 19.29.13530 was tested/released with gmmlib 19.2.3 containing so 
version=9.
See: https://github.com/intel/compute-runtime/releases/tag/19.29.13530
The first compute-runtime with gmmlib containing so version=11 was 19.39.14278
See: https://github.com/intel/compute-runtime/releases/tag/19.39.14278

--
jacek

Bug#945931: haskell-crypto: Removal notice: broken and unmaintained

[Apollon Oikonomopoulos]

Control: affects -1 - ganeti

Hey,

On 13:04 Sun 01 Dec , Ilias Tsitsimpis wrote:
> Source: haskell-crypto
> Version: 4.2.5.1-9
> Severity: grave
> Justification: renders package unusable
> 
> This package is no longer maintained (last upstream upload in 2012). It
> is also broken with GHC 8.6.4 and unlikely to ever be fixed (see [1]).
> 
> I intend to remove this package once ganeti has been updated to use
> cryptonite instead (see [2]).

Ganeti has been ported[3] to cryptonite, you can safely remove 
haskell-crypto. Thanks for keeping the Haskell ecosystem in Debian 
healthy :)

[3] 
https://salsa.debian.org/ganeti-team/ganeti/commit/8f8a95bea4661153380a75908038768b0af50594

Cheers,
Apollon

Bug#922713: vmdb2: please add a step to create /etc/fstab in the image (PATCH)

[Lars Wirzenius]

I've finally  merged this patch, with a minor fix. It's pushed to both
public, official git repositories (git.liw.fi, gitlab.com).

On Thu, Feb 21, 2019 at 09:47:45AM -0300, Antonio Terceiro wrote:
> It turns out I needed to make quite a few changes. I needed to add two
> new attributes to tags: one to record the filesystem type of each
> partition, and another to record the target mount point, because the
> existing mount point attribute records the mount point in the host.
> 
> You will find the final patches attached.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#931545: addition

[Apollon Oikonomopoulos]

Control: severity -1 normal
Control: tags -1 wontfix

Hi,

On 15:03 Sun 07 Jul , Michael Becker wrote:
> forgot to mention: dovecot runs in an LXC container

Apologies for the late response. For posterity, this error is because 
systemd inside LXC cannot create additional namespaces under Debian's 
default configuration. Dovecot's systemd unit uses some hardening 
features which rely on systemd namespace support. There are 3 possible 
workarounds for this:

 - Try enabling unprivileged userns cloning in the host kernel, by 
   setting the kernel.unprivileged_userns_clone sysctl to 1. This is 
   probably the least intrusive option, but I'm not 100% it will work.

 - Override and unset ProtectSystem, PrivateDevices and PrivateTmp in 
   the systemd unit (preferrably using an override in 
   /etc/systemd/dovecot.service.d). Note however that this will disable 
   the last line of defense for a service running as root (but that's 
   also what you get when you run under sysvinit).

 - Change your LXC container to a privileged one, which kinda beats the 
   purpose.

Cheers,
Apollon

Bug#946814: RM: julia [arm64 armhf] -- ROM; FTBFS, Blocked by LLVM fixes

[Mo Zhou]

Package: ftp.debian.org
Severity: normal

(please explain the reason for the removal here)

src:julia/unstable FTBFS on arm64 and armhf due to lack of a couple of
fixes to LLVM-8. Sylvestre is going to put less attention on this LLVM
version, so let's see what will happen to future version of julia when
compiling against future version of llvm.

For now we hope to remove these FTBFS architectures and let it migrate.

Note: this was a request for a partial removal from testing, converted
in one for unstable

Bug#943055: harvest-tools: Python2 removal in sid/bullseye

[Andreas Tille]

Control: tags -1 upstream
Control. forwarded -1 https://github.com/marbl/harvest-tools/issues/17

Just forwarded this issue upstream.

-- 
http://fam-tille.de

Bug#856524: RFA: libpst - library for reading Microsoft Outlook PST files

[Paul Wise]

On Sun, 2019-12-15 at 20:36 +0100, Leo "Costela" Antunes wrote:

> Feel free to just take it over completely.

OK, I've done that in git and will do an initial upload soon.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#945920: Chrome bug

[PPHome2]

Hi!

I'm using an up-to-date test system, but chromium is 79.0.3945.79 from
sid.
The crash/close error also occurred to me.

Workaround for me: 
chrome: // flags "Override software rendering list" change to "enable".

Since then the error has not occurred ...


-- 
PP

Bug#946782: cups: CVE-2019-2228

[Didier 'OdyX' Raboud]

Hello Salvatore, and thanks for your bugreport,

Le dimanche, 15 décembre 2019, 21.06:42 h CET Salvatore Bonaccorso a écrit :
> The following vulnerability was published for cups.
> 
> CVE-2019-2228[0] (…)
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For the record, due to subkey expiration and rotation, I won't be able to 
upload before the next keyring-maint sync (around Dec 24). Feel free (you or 
anybody) to NMU as needed!

Cheers,

OdyX

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

Bug#946813: RFP: python-flask-paginate -- Paginate support for flask framework

[jamie]

Package: wnpp

Severity: wishlist

license: appears to be a bsd license variant
(https://github.com/lixxu/flask-paginate/blob/master/LICENSE)

project url : https://github.com/lixxu/flask-paginate

flask-paginate is a simple paginate extension for flask which is
reference to will_paginate and use bootstrap as css framework (from
overview section of https://flask-paginate.readthedocs.io/en/latest/)

Bug#946811: libselinux FTBFS with nopython build profile during clean

[Helmut Grohne]

Source: libselinux
Version: 3.0-1
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libselinux fails to build from source with the nopython build profile
since version 3.0-1:

|dh_auto_clean
| make -j1 distclean
| make[1]: Entering directory '/tmp/buildd/libselinux_1/libselinux-3.0'
| Package libpcre was not found in the pkg-config search path.
| Perhaps you should add the directory containing `libpcre.pc'
| to the PKG_CONFIG_PATH environment variable
| No package 'libpcre' found
| Package libpcre was not found in the pkg-config search path.
| Perhaps you should add the directory containing `libpcre.pc'
| to the PKG_CONFIG_PATH environment variable
| No package 'libpcre' found
| make[2]: Entering directory '/tmp/buildd/libselinux_1/libselinux-3.0/src'
| rm -f python-3.7selinuxswig_python_wrap.lo python-3.7_selinux.so 
python-3.7audit2why.lo python-3.7audit2why.so
| python3 setup.py clean
| Traceback (most recent call last):
|   File "setup.py", line 3, in 
| from distutils.core import Extension, setup
| ModuleNotFoundError: No module named 'distutils.core'
| make[2]: Leaving directory '/tmp/buildd/libselinux_1/libselinux-3.0/src'
| make[2]: *** [Makefile:189: clean-pywrap] Error 1
| make[1]: Leaving directory '/tmp/buildd/libselinux_1/libselinux-3.0'
| make[1]: *** [Makefile:44: distclean] Error 1
| dh_auto_clean: make -j1 distclean returned exit code 2
| make: *** [debian/rules:43: clean] Error 255
| dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned 
exit status 2
| rebootstrap-error: dpkg-buildpackage failed with status 2

Please consider applying the attached patch.

Severity set to important, because this affects architecture bootstrap.

Helmut
diff --minimal -Nru libselinux-3.0/debian/changelog 
libselinux-3.0/debian/changelog
--- libselinux-3.0/debian/changelog 2019-12-11 14:38:39.0 +0100
+++ libselinux-3.0/debian/changelog 2019-12-16 06:08:28.0 +0100
@@ -1,3 +1,10 @@
+libselinux (3.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix clean with DEB_BUILD_PROFILES=nopython. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Dec 2019 06:08:28 +0100
+
 libselinux (3.0-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru libselinux-3.0/debian/rules libselinux-3.0/debian/rules
--- libselinux-3.0/debian/rules 2019-12-11 14:38:39.0 +0100
+++ libselinux-3.0/debian/rules 2019-12-16 06:08:28.0 +0100
@@ -46,6 +46,11 @@
 debian/rules:
@touch $@
 
+ifneq (,$(filter nopython,$(DEB_BUILD_PROFILES)))
+override_dh_auto_clean:
+   dh_auto_clean -- PYTHON=true
+endif
+
 ## Set up some variables to be passed to the upstream Makefile
 extra_make_args = ARCH=$(DEB_HOST_GNU_CPU)
 extra_make_args += CC=$(DEB_HOST_GNU_TYPE)-gcc

Bug#946812: Audio settings often reset to 100% Volume

[Phil Wyett]

Package: pulseaudio
Version: 12.2-4+deb10u1
Severity: normal

References:

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

Commit:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837637#28

Can we patch buster to fix this issue?

Regards

Phil

-- 

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

Twitter: @kathenasorg

IRC: kathenas





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

Bug#432412: readpst: "unknown index structure" on previously working pst file

[Paul Wise]

Control: close -1

On Sun, 2019-12-15 at 23:35 -0500, Jamie McClelland wrote:

> Unfortunately, I don't have access to Outlook any longer. Sorry!

Thanks for replying. Closing the bug since it doesn't have enough info.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946810: python3-commonmark-py: update the source url in watch to match the currently supported repo

[Joseph Herlant]

Package: python3-commonmark-bkrs
Version: 0.5.4+ds-4
Severity: wishlist

Dear Maintainer,

The watch file of the package points to the old repository
(rolandshoemaker/CommonMark-py):
https://salsa.debian.org/python-team/modules/commonmark-
bkrs/blob/master/debian/watch

But that repository clearly states that using that repo as source is deprecated
and we should be using the supported one here instead:
https://github.com/readthedocs/commonmark.py

Do you think it would be doable to migrate that over as it seems it's the way
to a maintained upstream?

I'm not sure how much work would actually be involved in that.

Thanks for your help,
Joseph



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

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

Versions of packages python3-commonmark-bkrs depends on:
ii  python3  3.7.5-1

python3-commonmark-bkrs recommends no packages.

Versions of packages python3-commonmark-bkrs suggests:
pn  python-commonmark-bkrs-doc  

-- no debconf information

Bug#878599: git: [PATCH] Ship git-credential-libsecret

[Josh Triplett]

Package: git
Version: 1:2.24.0-2
Followup-For: Bug #878599

I would love to see git-credential-libsecret packaged.

This patch would ship git-credential-libsecret in the git package, which
would add libsecret and its dependencies to the dependencies of git.
Since many people use the git package on servers, that might not be
welcome. (I personally wouldn't object, as those dependencies seem quite
small.)

It might also make sense to generate a separate git-credential-libsecret
binary package containing this binary.

Either way, I'd love to see this packaged.

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

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

Versions of packages git depends on:
ii  git-man  1:2.24.0-2
ii  libc62.29-6
ii  libcurl3-gnutls  7.67.0-2
ii  liberror-perl0.17028-1
ii  libexpat12.2.9-1
ii  libpcre2-8-0 10.34-7
ii  perl 5.30.0-9
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 551-1
ii  openssh-client [ssh-client]  1:8.1p1-2
ii  patch2.7.6-6

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-10
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
ii  git-svn   1:2.24.0-2
ii  gitk  1:2.24.0-2
pn  gitweb

-- no debconf information

Bug#432412: readpst: "unknown index structure" on previously working pst file

[Jamie McClelland]

On 12/15/19 4:31 AM, Paul Wise wrote:
> Control: tags -1 moreinfo
> 
> On Mon, 09 Jul 2007 16:02:45 -0400 Jamie McClelland wrote:
> 
>> I have run readpst on a pst file and it works fine. Then, I've opened the pst
>> file in Outlook, removed large numbers of messages from the pst file, exited
>> Outlook and then, when I re-run readpst, I get the error:
> 
> I know it was a long time ago, but do you still have any pst files that
> stopped working after modification with Outlook and that you could
> share on the bug report?

Unfortunately, I don't have access to Outlook any longer. Sorry!

jamie




signature.asc
Description: OpenPGP digital signature

Bug#939095: RFS: axtls/2.1.5+ds-1 [ITP] -- Highly configurable client/server TLSv1.2 library

[Adam Borowski]

On Mon, Dec 16, 2019 at 09:25:33AM +0800, Yangfl wrote:
> Adam Borowski  于2019年12月15日周日 上午11:27写道：
> > Alas, it fails to build, during tests:

> > cd ./_stage; OPENSSL_CONF=../config/open-ssl.cnf ./ssltest
> > ./ssltest: error while loading shared libraries: libaxtls.so.1: cannot open 
> > shared object file: No such file or directory
> 
> Thanks. Reuploaded to https://mentors.debian.net/package/axtls and
> https://salsa.debian.org/yangfl-guest/axtls . No idea on why salsa
> fails to build...

Alas:
Error: Invalid X509 ASN.1 file (Unsupported digest)

Again, full log attached.


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on valinor.angband.pl

+==+
| axtls 2.1.5+ds-1 (amd64) Mon, 16 Dec 2019 03:09:24 + |
+==+

Package: axtls
Version: 2.1.5+ds-1
Source Version: 2.1.5+ds-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-79e3c39a-83ee-40d7-b2c8-1fe3363c5792'
 with '<>'
I: NOTICE: Log filtering will replace 'build/axtls-rf8Oyr/resolver-sKyPbP' with 
'<>'

+--+
| Update chroot|
+--+

Get:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease [142 kB]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main Sources.diff/Index 
[27.9 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 
Packages.diff/Index [27.9 kB]
Get:4 http://apt-rosy.angband.pl:3142/debian unstable/main Sources 
2019-12-16-0222.22.pdiff [13.0 kB]
Get:4 http://apt-rosy.angband.pl:3142/debian unstable/main Sources 
2019-12-16-0222.22.pdiff [13.0 kB]
Get:5 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages 
2019-12-16-0222.22.pdiff [21.8 kB]
Get:5 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages 
2019-12-16-0222.22.pdiff [21.8 kB]
Fetched 233 kB in 2s (150 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/kilobyte/tmp/pkg/axtls_2.1.5+ds-1.dsc exists in /home/kilobyte/tmp/pkg; 
copying to chroot
I: NOTICE: Log filtering will replace 'build/axtls-rf8Oyr/axtls-2.1.5+ds' with 
'<>'
I: NOTICE: Log filtering will replace 'build/axtls-rf8Oyr' with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), psmisc, swig, dh-lua, 
libperl-dev, gnutls-bin, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 12), psmisc, swig, dh-lua, 
libperl-dev, gnutls-bin, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [402 B]
Get:5 copy:/<>/apt_archive ./ Packages [484 B]
Fetched 1843 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  dctrl-tools dh-lua gnutls-bin libevent-2.1-7 libfile-find-rule-perl
  libgnutls-dane0 liblua5.1-0 liblua5.1-0-dev liblua5.2-0 liblua5.2-dev
  liblua5.3-0 liblua5.3-dev libncurses-dev libncurses6 libnumber-compare-perl
  libopts25 libperl-dev libreadline-dev libreadline8 libtext-glob-perl
  libtool-bin libunbound8 lua5.1 lua5.2 lua5.3 pkg-config psmisc
  readline-common swig swig3.0
Suggested packages:
  debtags dns-root-data ncurses-doc readline-doc swig-doc swig-examples
  swig3.0-examples swig3.0-doc

Bug#939622: blender

[Niv Sardi]

merge 939622 939661
thanks,

blender is pretty broken without subdiv, not sure having it broken
waiting for the ITP is the best move here.

Cheers,

Bug#946809: RM: python-logging-extra [experimental] -- RoQA; unmaintained; Python2-only;

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

With https://bugs.debian.org/943575 , package python-logging-extra has been
removed from Sid. However, there are still some leftovers in Experimental (
https://packages.debian.org/source/experimental/python-logging-extra). Please
remove the packages in Experimental as well.

Thanks,
Boyuan Yang


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

Bug#944389: lxc support status of cgroupv2 / unified hierarchy

[Ryutaroh Matsumoto]

Control: tags -1 + fixed-upstream upstream

Dear LXC maintainers and Systemd maintainers,

I added fixed-upstream to #944389, and it seems that blocking of #943981
by LXC can be lifted after some work. If LXC is the only reason for systemd
package to revert to hybrid hierarchy, it can probably return to the unified
default.
The below is justification/explanation.

I did

1. "apt-get source lxc" on Ubuntu Eoan (sorry not Debian Bullseye),
2. overwirtten the source by the * stable-3.0 * branch of lxc github,
3. and rebuilt it by "debuild -b -uc -us".

The built package worked as expected with no problem under
cgroupv2 / unified hierarchy, on Ubuntu Eoan. Some adjustment to
the config file was necessary as below:

ERRORcgfsng - cgroups/cgfsng.c:cg_legacy_set_data:2415 - Failed to setup 
limits for the "devices" controller. The controller seems to be unused by 
"cgfsng" cgroup driver or not enabled on the cgroup hierarchy
ERRORstart - start.c:lxc_spawn:1910 - Failed to setup legacy device cgroup 
controller limits

The above error is caused by failed attempt to use Cgroup V1 device controller, 
to fix it
we need:
lxc.cgroup.devices.allow =
lxc.cgroup.devices.deny =

The newer systemd refuses to start in the LXC container by the error message:
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
[!!] Failed to mount API filesystems.
Exiting PID 1...

The reason of this error is lack of /sys/fs/cgroup in the container. To fix 
this, we need
lxc.mount.auto = cgroup:rw:force

In another bug report #946480 I reported that a non-root user cannot start an
LXC container. The reason of the failure is lack a manipulable CGroup directory
by a non-root user. To fix this issue, a non-root user has to start a container 
by

systemd-run --user --scope -p "Delegate=yes" lxc-start -F ... (foreground)
or 
systemd-run --user -r -p "Delegate=yes" lxc-start -F ... (backgroud)

so that non-root lxc-start has a manipulable cgroup directory.
The essential problem in #946480 is that there is no user instruction of how to
start an LXC container by non-root, and #946480 is a purely documentation issue.
Maybe updating https://wiki.debian.org/LXC is enough.

Conventionally, libpam-cgfs chowned non-root user's session scope so that
a non-root LXC container can manipulate it. But merely chowning the
session scope is insufficient to make cgroup.subtree_control writable by 
non-root
users under cgroupv2 / unified hierarchy.
So libpam-cgfs has become useless in cgroupv2 / unified hierarchy, which was
#946170

Best regards,
Ryutaroh Matsumoto

Bug#907489: Fixing sambamba 0.8.6

[Matthias Klumpp]

Am So., 15. Dez. 2019 um 10:16 Uhr schrieb Pjotr Prins :
> [...]
> > Therefore, the way of least resistance was to just use Meson for
> > building, as that does everything we need in Debian. Both BioD and
> > Sambamba build well with Meson.
>
> That is great. We can add the meson builds in the repos.

That's something I forgot in my last mail: I didn't create PRs,
because Meson support was upstream once but was removed. Also because
it's understandable if upstream projects want to reduce the amount of
ways a software can be built.
As it happens though, I have already created (by accident) build
definitions that work for the current upstream code of BioD/Sambamba.
I've created PRs for those now. Having this upstream would obviously
be great, and if there are issues with it, I can help. (The
definitions are really straightforward to use though)

See https://github.com/biod/BioD/pull/54 and
https://github.com/biod/sambamba/pull/419

Integration with CI is possible, but your Travis YAML will become a
bit bigger ^^

> > I applied a few tweaks to the packages, that haven't been there
> > before: BioD is now built as a shared as well as a static library, so
> > applications can choose between the two. That's pretty common in
> > Debian, and as a sideeffect this also guarantees that things are
> > rebuilt properly when a transition happens. The Sambamba package will
> > now prefer statically linking BioD if possible (so BioD is statically
> > linked by default now in Debian).
> > Additionally both packages now apply the optimization flags upstream
> > has set for releases (-O3, no bounds checks, etc.). Combined, these
> > two changes should make the Debian builds comparably fast to the
> > upstream builds, but I haven't tested that yet.
>
> > There are also two brand new remaining issues: Apparently, for some
> > reason, SONAME isn't set correctly for BioD, producing a Lintian error
> > - not sure what happens there, and which component is to blame for
> > that (Meson or LDC, most likely). Also, Sambamba doesn't *actually*
> > build yet:
> > ```
> > roup -L=-rpath 
> > -L=/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu
> > slicereader.d:71: error: undefined reference to 'cram_to_bam'
> > collect2: error: ld returned 1 exit status
> > ```
> > The cram_to_bam is private in htslib, so it shouldn't be used by other
> > applications. Not sure whether htslib or Sambamba needs to be changed
> > here, I simply worked around this issue for testing, and when this is
> > resolved, Sambamba builds & works.
>
> Sambamba ships with an old version of htslib that is patched for that
> function call. I plan to drop CRAM support and htslib. No one I know
> uses the CRAM functionality in sambamba.

It certainly wasn't needed for the tests :-D
I don't think we should silently comment that out from the Debian
builds though...

> > Unfortunately I briefly forgot that this issue existed, so I already
> > uploaded the new sambamba package with this issue still present (I
> > remembered literally the moment the upload finished), so its builds
> > will fail. This is probably something for Andreas to look into :-)
> >
> > Anyway, I hope this is helpful to you and the resulting binaries are
> > performant :-)
>
> Thanks Matthias!

If the last issues can be fixed, this may just be in time for the next
Ubuntu LTS release, which is probably something that you'll want ;-)
Currently, BioD fails to build on x86:
https://buildd.debian.org/status/fetch.php?pkg=libbiod=i386=0.2.3%2Bgit20191120.b8eecef-1=1576379323=0
This issue looks trivial to me, it's probably a matter of using size_t
instead of plain ints.
There's of course also the question of whether we need to support x86
with this package, but in any case, this FTBFS will block the package
in unstable until it has either been removed from i386 or the build
failure has been fixed.
The good news is that the package builds on arm64 now though - yay? ^^

Sambamba is only failing on missing cram_to_bam, so once that's fixed,
it should be good to go as well.

Cheers,
Matthias




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

Bug#946803: lintian-brush: commit message style

[Paul Wise]

On Mon, 2019-12-16 at 01:46 +, Jelmer Vernooij wrote:

> >Fixes: lintian: debian-changelog-has-wrong-day-of-week
> >See-also: 
> > https://lintian.debian.org/tags/debian-changelog-has-wrong-day-of-week.html
> This seems like a reasonable alternative to me.

Great.

> >Fixes: 
> > https://lintian.debian.org/tags/debian-changelog-has-wrong-day-of-week.html
> This makes it less obvious what lintian tag it is fixing (and that
> it's mentioning the lintian tag).

It seems obvious to humans, but is of course less parseable.

> I'd prefer to have one style, also so it's easily recognisable, and,
> if need be in the future, parseable.

Fair enough.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946801: lintian-brush: attribution of changes in git commits and changelog

[Paul Wise]

On Mon, 2019-12-16 at 02:00 +, Jelmer Vernooij wrote:

> The Janitor is a specific bot that happens to run lintian-brush (among
> other things). I think it would be confusing if other things used this
> identity.

Interesting, I didn't know that it ran things other than lintian-brush. 
I suggest that the Janitor should attribute things to the right tool.

> >  * lintian-brush 
> This seems reasonable. Perhaps it would make sense to set committer to
> the person who ran the tool, and author to "lintian-brush 
> " ?

Sounds good, I'd leave the committer as the default from the user's VCS
configuration though.

> >  * Person running the tool, but attribute the tool in the footer:
> >Changed-by: lintian-brush --options-here

I made a typo, I meant to write Changes-by.

> That's a good idea; I think providing the options (and lintian-brush
> version?) in the commit may be useful regardless of what choice we
> make about committer/author.

Seems reasonable to include the version number to me.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946801: lintian-brush: attribution of changes in git commits and changelog

[Jelmer Vernooij]

On Mon, Dec 16, 2019 at 08:04:02AM +0800, Paul Wise wrote:
> I noticed that the commits generated by lintian-brush and the added
> debian/changelog lines are attributed to the person running the tool.
> 
> I would suggest changing that to one of a few options:
> 
>  * Debian Janitor 
The Janitor is a specific bot that happens to run lintian-brush (among
other things). I think it would be confusing if other things used this
identity.

>  * lintian-brush 
This seems reasonable. Perhaps it would make sense to set committer to
the person who ran the tool, and author to "lintian-brush 
" ?

>  * Person running the tool, but attribute the tool in the footer:
>Changed-by: lintian-brush --options-here
That's a good idea; I think providing the options (and lintian-brush
version?) in the commit may be useful regardless of what choice we
make about committer/author.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#942737: libapache2-mod-gnutls: mod_gnutls consumes 100% cpu

[Bernhard Übelacker]

Dear Maintainer,
tried to reconstruct the given backtrace with debug symbols
in a gdb session and came to following, maybe it could be
of some help.
(Still a proper backtrace with dbgsym packages
installed would be better.)

Kind regards,
Bernhard


Reconstructed:
#0  0x7f78b4cfb92f in gnutls_assert_val_int at ../../lib/errors.h:139 from 
libgnutls.so.30
#1  0x7f78b4cfdf7c in _gnutls_recv_int at ../../lib/record.c:1773 from 
libgnutls.so.30
   in gnutls_record_recv at ../../lib/record.c:2281
#2  0x7f78b4e90f38 in gnutls_io_input_read at gnutls_io.c:246 from 
mod_gnutls.so
#3  0x7f78b4e91ad2 in gnutls_io_input_getline at gnutls_io.c:342 from 
mod_gnutls.so
   in mgs_filter_input at gnutls_io.c:595
   in ap_get_brigade at util_filter.c:553
#4  0x55c220cd08e1 in ap_rgetline_core at protocol.c:246
#5  0x55c220cd336c in read_request_line at protocol.c:682
   in ap_read_request at protocol.c:1322
#6  0x55c220cfe7a8 in ap_process_http_sync_connection at http_core.c:192
#7  0x55c220cf38b0 in ap_run_process_connection at connection.c:42
   in ap_process_connection at connection.c:219
#8  0x7f78b3bd23df in child_main at prefork.c:615 from mod_mpm_prefork.so
#9  0x7f78b3bd26d4 in make_child at prefork.c:717 from mod_mpm_prefork.so
#10 0x7f78b3bd272f in startup_children at prefork.c:735 from 
mod_mpm_prefork.so
#11 0x7f78b3bd32f3 in prefork_run at prefork.c:897 from mod_mpm_prefork.so
#12 0x55c220ccc67e in ap_run_mpm at mpm_common.c:94
#13 0x55c220cc4f57 in main at main.c:819

Bug#946803: lintian-brush: commit message style

[Jelmer Vernooij]

Hi Paul,

Thanks for the bug report.

On Mon, Dec 16, 2019 at 08:07:48AM +0800, Paul Wise wrote:
> Currently the commit messages look like this:
> 
>Fix day-of-week for changelog entry 0.6.52-1.
> 
>Fixes lintian: debian-changelog-has-wrong-day-of-week
>See 
> https://lintian.debian.org/tags/debian-changelog-has-wrong-day-of-week.html 
> for more details.
> 
> Personally, I would prefer something like this:
> 
>Fix day-of-week for changelog entry 0.6.52-1.
>
>Fixes: lintian: debian-changelog-has-wrong-day-of-week
>See-also: 
> https://lintian.debian.org/tags/debian-changelog-has-wrong-day-of-week.html
This seems like a reasonable alternative to me.

> Or something like this:
> 
>Fix day-of-week for changelog entry 0.6.52-1.
>
>Fixes: 
> https://lintian.debian.org/tags/debian-changelog-has-wrong-day-of-week.html
This makes it less obvious what lintian tag it is fixing (and that
it's mentioning the lintian tag).

> Or possibly a way to select among these options.
I'd prefer to have one style, also so it's easily recognisable, and,
if need be in the future, parseable.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#941633: synfigstudio crashes on almost every operation

[Dmitry Smirnov]

On Monday, 9 December 2019 8:04:23 AM AEDT VA wrote:
> In fact, it's much more general than just when importing an image, it
> crashes for almost everything.

I am unable to reproduce any of those crashes...

It could help to track the problem if you could obtain a backtrace as 
instructed on the following page:

  https://wiki.debian.org/HowToGetABacktrace

Thanks.

-- 
Cheers,
 Dmitry Smirnov.

---

I am easily satisfied with the very best.
-- Winston Churchill


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

Bug#946691: emacs25-common: expired GNU ELPA gpg key

[Rob Browning]

Thomas Sanders  writes:

> Package: emacs25-common
> Version: 25.1+1-4+deb9u1
> Severity: normal
> File: /usr/share/emacs/25.1/etc/package-keyring.gpg
>
> Dear Maintainer (Rob Browning?),
>
> This problem in emacs 25 (in Debian old-stable) is the same as the
> problem that was fixed in Debian current stable (buster) emacs 26
> with this changelog message:
> https://metadata.ftp-master.debian.org/changelogs//main/e/emacs/emacs_26.1+1-3.2+deb10u1_changelog
> [START-QUOTATON]
> emacs (1:26.1+1-3.2+deb10u1) buster; urgency=high
>
>   * Update the EPLA packaging key (previous key expires 2019-09-23) via
> the upstream commit f16785d361097df9fddfcc0b60ae6f0d92e7e911.  Add the
> old and new keyrings to debian/ and debian/source/include-binaries
> since debian/patches/ can't handle git binary diffs.  Thanks to Stefan
> Monnier for reporting the problem and providing the patch.
>
>  -- Rob Browning   Wed, 04 Sep 2019 21:35:24 -0500
> [END-QUOTATION]


Ahh, so it sounds like it we might want to try to fix this in LTS too.
Assuming so, and if no one else handles it before I get to it, I'll try
to see how that process works, and if the change would be acceptable.

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

Bug#939095: RFS: axtls/2.1.5+ds-1 [ITP] -- Highly configurable client/server TLSv1.2 library

[Yangfl]

Adam Borowski  于2019年12月15日周日 上午11:27写道：
>
> Alas, it fails to build, during tests:
>
>dh_auto_test
> make -j64 test
> make[1]: Entering directory '/<>'
> cd ./_stage; OPENSSL_CONF=../config/open-ssl.cnf ./ssltest
> ./ssltest: error while loading shared libraries: libaxtls.so.1: cannot open 
> shared object file: No such file or directory
>
> Full log attached.

Thanks. Reuploaded to https://mentors.debian.net/package/axtls and
https://salsa.debian.org/yangfl-guest/axtls . No idea on why salsa
fails to build...

Bug#946808: webext-ublock-origin: Element picker and cosmetic filters broken with Chromium 78 due to symlinks

[Daniel Gröber]

Package: webext-ublock-origin
Version: 1.22.2+dfsg-1~deb10u1
Severity: important

Dear Maintainer,

I belive a chromium security update (version 78.0.3904.108-1~deb10u1)
a while ago broke the use of symlinks in this extension. Strangely
most things still work but at least the content_scripts declared in
the extension manifest seem to be, silently, not loaded.

To reproduce the problem: click the "Element zapper mode" or "Element
picker mode" buttons in the extension menu and observe that nothing
happens.

Further it is possible to observe that the uBlock content scripts are
not loaded by trying to access the commonly used 'vAPI' variable in
DevTools:

- Open any page with uBlock active,
- Open DevTools,
- Enter 'vAPI' or 'window.vAPI' in "Console" window,
- Get the following error error: Uncaught ReferenceError: vAPI is not defined

If I copy the extension directory from /usr somewhere else while
dereferencing symlinks the element-picker starts working again:

$ cp -aL /usr/share/chromium/extensions/ublock-origin/ /tmp/

To confirm that the problem is not related to some extension settings
I also tried copying with symlinks still in place:

$ cd /tmp
$ mkdir -p 
usr/share/mozilla/extensions/\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\}/
$ mkdir -p usr/share/chromium/extensions/
$ cp -a 
/usr/share/mozilla/extensions/\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\}/ublo...@raymondhill.net/
 \
 
usr/share/mozilla/extensions/\{ec8030f7-c20a-464f-9b0e-13a3a9e97384\}/
$ cp -a /usr/share/chromium/extensions/ublock-origin/ \
 usr/share/chromium/extensions

(Awkward copying of mozilla extension is necessary due to use of
relative symlinks)

This copy of the extension also exhibits the same problem, confirming
that setting have nothing to do with it as the loaded extension ID is
different.

I've tested with the old chromium versions 76.0.3809.100-1~deb10u1 and
78.0.3904.97-1~deb10u1 in a VM and confirmed that the element-picker
still works there. After the upgrade to 78.0.3904.108-1~deb10u1 the
described breakage occurs.

Thanks,
--Daniel

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

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

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  chromium 78.0.3904.108-1~deb10u1
ii  firefox-esr  68.3.0esr-1~deb10u1

Versions of packages webext-ublock-origin suggests:
pn  ublock-origin-doc  

-- no debconf information

Bug#946807: ITP: golang-github-vmihailenco-tagparser -- Golang tag parser

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 src:golang-gopkg-vmihailenco-msgpack.v2

   Package name: golang-github-vmihailenco-tagparser
Version: 0.1.1
Upstream Author: Vladimir Mihailenco
License: BSD-2-clause
URL: https://github.com/vmihailenco/tagparser
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-vmihailenco-tagparser
Description: Golang tag parser
 Opinionated Golang tag parser.


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

Bug#946806: exim4-base: Smarthost with SMTPS (to port 465) is missing - requires recompilation

[Karl Schmidt]

Package: exim4-base
Version: 4.92-8+deb10u3
Severity: normal


The use of SMTPS is rather standard these days - (thunderbird, k9 outlook etc.. 
) all support this.

Without openSSL one can't have a smart-host transport with: driver =  smtps


A breadcrum for others: According to exim.org docs  one must recompile and 
change USE_OPENSSL=yes in Local/Makefile to USE_GNUTLS=yes

It could be there needs to be two packages - exim4-gnutl and exim4-openssl

At the very least the README.Debian should start out with which version it is.




-- Package-specific info:
Exim version 4.92 #3 built 27-Sep-2019 16:09:35
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event OCSP PRDR PROXY 
SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /etc/exim4/exim4.conf

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

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

Versions of packages exim4-base depends on:
ii  adduser3.118
ii  cron [cron-daemon] 3.0pl1-134+deb10u1
ii  debconf [debconf-2.0]  1.5.71
ii  exim4-config [exim4-config-2]  4.92-8+deb10u3
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  lsb-base   10.2019051400
ii  netbase5.6

Bug#946805: ruby-hamlit: Please upgrade to latest upstream

[Joseph Herlant]

Package: ruby-hamlit
Version: 2.9.2-2
Severity: wishlist

Dear Maintainer,

Since the upgrade of ruby-tilt to 2.0.10 yesterday the tests for ruby-hamlit
fail.
See: https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-
hamlit/3668609/log.gz

It seems that this has been fixed in the latest upstream version.
To see more explanation about a potential fix of the problem, see
https://github.com/rtomayko/tilt/issues/347

But again, I can see upstream running their tests against tilt 2.0.10 without
any issue, so I guess it's fixed in the latest version.

Utkarsh created a MR to gitlab (which depends on ruby-hamlit) to make sure they
accept to support the latest version but given that the only tests failing were
already failing before I don't see any reason why that would be an issue. See:
https://gitlab.com/gitlab-org/gitlab/merge_requests/21793

Thanks for your time,
Joseph



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

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

Versions of packages ruby-hamlit depends on:
ii  libc62.29-3
ii  libgmp10 2:6.1.2+dfsg-4
ii  libruby2.5   2.5.7-1
ii  ruby 1:2.5.2
pn  ruby-temple  
ii  ruby-thor0.19.4-1
ii  ruby-tilt2.0.9-1

ruby-hamlit recommends no packages.

ruby-hamlit suggests no packages.

Bug#944426: Still not able to update

[Johann Glaser]

Hi!

The problem is still there for lazarus-src-2.0_2.0.6+dfsg-3_all.deb. It
was actually also there for 2.0.6+dfsg-2 as well as 2.0.6+dfsg-1.

The only thing which helps is forcing it, but it gives a huge load of
warnings:

# dpkg -i --force-all 
/var/cache/apt/archives/lazarus-src-2.0_2.0.6+dfsg-3_all.deb
(Reading database ... 528262 files and directories currently installed.)
Preparing to unpack .../lazarus-src-2.0_2.0.6+dfsg-3_all.deb ...
Unpacking lazarus-src-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/IdeInspector/ideinspector.lpk', which is 
also in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/IdeLazLogger/idelazlogger.lpk', which is 
also in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/PascalScript/Source/pascalscript.lpk', which 
is also in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/PascalScript/Source/pascalscriptfcl.lpk', 
which is also in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/aarre/src/aarrebase.lpk', which is also in 
package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/activex/LazActiveX.lpk', which is also in 
package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/aggpas/lazarus/aggpaslcl.lpk', which is also 
in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/anchordocking/anchordocking.lpk', which is 
also in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/anchordocking/design/anchordockingdsgn.lpk', 
which is also in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/cairocanvas/cairocanvas_pkg.lpk', which is 
also in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/chmhelp/packages/help/lhelpcontrolpkg.lpk', 
which is also in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/chmhelp/packages/idehelp/chmhelppkg.lpk', 
which is also in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/codetools/codetools.lpk', which is also in 
package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/codetools/ide/cody.lpk', which is also in 
package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/compilers/c/lazc.lpk', which is also in 
package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/customdrawn/customdrawn.lpk', which is also 
in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/customform/demo/appforms.lpk', which is also 
in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/customform/lazcustforms.lpk', which is also 
in package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/daemon/lazdaemon.lpk', which is also in 
package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/datadict/lazdatadict.lpk', which is also in 
package lcl-units-2.0 2.0.6+dfsg-3
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite 
'/usr/lib/lazarus/2.0.6/components/datetimectrls/datetimectrls.lpk', which is 
also in 

Bug#946804: plugin download fails (broken keyserver, assumes Python 2)

[Steinar H. Gunderson]

Source: hplip
Version: 3.18.12+dfsg0-2
Severity: important

Hi,

I upgraded a machine to buster recently, and printing (an HP 1025nw,
with HP's proprietary plugin) just silently broke. Everything looked
OK, but nothing was coming out. Finally I found in /var/log/debug:

  Dec 16 00:07:20 localhost hpcups[9302]: prnt/hpcups/HPCupsFilter.cpp 489: 
m_Job initialization failed with error = 48

The Internet suggested I needed to run hp-setup again (which needed
X forwarding, but OK...). It failed pretty badly, since it tried to
contact a keyserver that no longer existed, namely pgpkeys.mit.edu.
(Downloading the key manually from a different keyserver didn't help.)
Worse, however, is that the plugin installation just silently failed.

Eventually, I found out which file it was downloading, namely:

  
http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/hplip-3.18.12-plugin.run

and ran it myself. It turned out that it couldn't find its HPLIP modules;
by that, it seemingly meant the Python CUPS modules. The problem is that
the .run file prefers /usr/bin/python, which is Python 2, but Debian now only
ships CUPS modules for Python 3. (If you don't have /usr/bin/python, it tries
python3.)

After installing the plugin properly and getting a success message, it _still_
claimed I needed a plugin that I didn't have, and offered to run hp-plugin
for me, but now my old printer definition worked again, so I could just abort
the wizard and print. But new installations will probably be broken.

-- System Information:
Debian Release: 10.2
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.11 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#946803: lintian-brush: commit message style

[Paul Wise]

Package: lintian-brush
Version: 0.47
Severity: minor

Currently the commit messages look like this:

   Fix day-of-week for changelog entry 0.6.52-1.

   Fixes lintian: debian-changelog-has-wrong-day-of-week
   See 
https://lintian.debian.org/tags/debian-changelog-has-wrong-day-of-week.html for 
more details.

Personally, I would prefer something like this:

   Fix day-of-week for changelog entry 0.6.52-1.
   
   Fixes: lintian: debian-changelog-has-wrong-day-of-week
   See-also: 
https://lintian.debian.org/tags/debian-changelog-has-wrong-day-of-week.html

Or something like this:

   Fix day-of-week for changelog entry 0.6.52-1.
   
   Fixes: 
https://lintian.debian.org/tags/debian-changelog-has-wrong-day-of-week.html

Or possibly a way to select among these options.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-1
ii  python3-breezy   3.0.1-2
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.14-2
ii  python3-levenshtein  0.12.0-3+b2
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.2
ii  lintian2.41.0
pn  python3-asyncpg
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
ii  gnome-pkg-tools0.21.2
pn  postgresql-common  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946801: lintian-brush: attribution of changes in git commits and changelog

[Paul Wise]

Package: lintian-brush
Version: 0.47
Severity: minor

I noticed that the commits generated by lintian-brush and the added
debian/changelog lines are attributed to the person running the tool.

I would suggest changing that to one of a few options:

 * Debian Janitor 
 * lintian-brush 
 * Person running the tool, but attribute the tool in the footer:
   Changed-by: lintian-brush --options-here

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-1
ii  python3-breezy   3.0.1-2
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.14-2
ii  python3-levenshtein  0.12.0-3+b2
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.2
ii  lintian2.41.0
pn  python3-asyncpg
ii  python3-pyinotify  0.9.6-1.2

Versions of packages lintian-brush suggests:
ii  gnome-pkg-tools0.21.2
pn  postgresql-common  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946802: python3-minieigen: missing Breaks+Replaces: python-minieigen

[Andreas Beckmann]

Package: python3-minieigen
Version: 0.50.3+dfsg1-10
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../python3-minieigen_0.50.3+dfsg1-10_amd64.deb ...
  Unpacking python3-minieigen (0.50.3+dfsg1-10) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-minieigen_0.50.3+dfsg1-10_amd64.deb (--unpack):
   trying to overwrite '/usr/share/doc-base/python-minieigen', which is also in 
package python-minieigen 0.50.3+dfsg1-9
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-minieigen_0.50.3+dfsg1-10_amd64.deb


cheers,

Andreas


python-minieigen=0.50.3+dfsg1-9_python3-minieigen=0.50.3+dfsg1-10.log.gz
Description: application/gzip

Bug#946699: wine: Lotus Notes 6.5 font drop down list corrupt after upgrade to buster

[Bernhard Übelacker]

Hello Wolfgang,
I am not involved in packaging wine in debian, but
may have some hints.


Unfortunately I could not find any download for a trial version,
is there one known? Otherwise this can just be debugged
by users having access to that software.


Then a file containing some more output could be of some help.
E.g. start from a terminal the application similar to this:

cd "/home/user/.wine/drive_c/path/to/application"
script -c "WINEDEBUG=+pid,+tid,+timestamp,+font wine 'application.exe'" -a 
"-a ~/wine_$(date +%Y-%m-%d_%H-%M-%S).log"

Such a file should contain all API calls to windows font functions,
maybe that would already show something.


As you tested already WineHQ packages too, and these showed the
same error you might also go ahead an open an upstream bug there.
(If you do so please send here the bug number too.)


Kind regards,
Bernhard

Bug#946800: python3-pbcommand: missing Breaks+Replaces: python-pbcommand (<< 1.1.1+git20191122.ec024c3)

[Andreas Beckmann]

Package: python3-pbcommand
Version: 1.1.1+git20191122.ec024c3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

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

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

  Selecting previously unselected package python3-pbcommand.
  Preparing to unpack 
.../16-python3-pbcommand_1.1.1+git20191122.ec024c3-1_all.deb ...
  Unpacking python3-pbcommand (1.1.1+git20191122.ec024c3-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-vOkgKo/16-python3-pbcommand_1.1.1+git20191122.ec024c3-1_all.deb
 (--unpack):
   trying to overwrite '/usr/share/man/man1/pbservice.1.gz', which is also in 
package python-pbcommand 1.1.1-1
  Errors were encountered while processing:
   
/tmp/apt-dpkg-install-vOkgKo/16-python3-pbcommand_1.1.1+git20191122.ec024c3-1_all.deb


cheers,

Andreas


python-pbcommand=1.1.1-1_python3-pbcommand=1.1.1+git20191122.ec024c3-1.log.gz
Description: application/gzip

Bug#946799: ITP: golang-github-openshift-api -- OpenShift API definitions

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 src:golang-github-containers-buildah

   Package name: golang-github-openshift-api
Version: 4.0
Upstream Author: OpenShift
License: Apache-2.0
URL: https://github.com/openshift/api
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-openshift-api
Description: OpenShift API definitions
 API type definitions and serialization code used by "openshift/client-go".


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

Bug#946798: debsecan: blocks forever waiting for network requests with no output or progress bar

[Paul Wise]

Package: debsecan
Version: 0.4.20
Severity: important

Recently debsecan started blocking forever waiting for network requests
that never seem to complete. This is probably an issue with the
security-tracker CDN but I think that debsecan needs to cope with
issues in the network in a few different ways:

* Add a timeout so network issues do not block debsecan from exiting
* Add a debug option that explains what debsecan is doing (URLs etc)
* When on a terminal, print a progress bar for any downloads that occur

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages debsecan depends on:
ii  ca-certificates20190110
ii  debconf [debconf-2.0]  1.5.73
ii  python33.7.5-1
ii  python3-apt1.8.4+b1

Versions of packages debsecan recommends:
ii  cron [cron-daemon] 3.0pl1-135
ii  exim4-daemon-light [mail-transport-agent]  4.92.3-1

debsecan suggests no packages.

-- debconf information:
* debsecan/source:
* debsecan/mailto: root
* debsecan/report: true
* debsecan/suite: sid

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946796: webext-ublock-origin: Wrong version number in Chromium manifest

[Daniel Gröber]

Package: webext-ublock-origin
Version: 1.22.2+dfsg-1~deb10u1
Severity: normal

Dear Maintainer,

ublock-origin's chromium manifest at

/usr/share/chromium/extensions/ublock-origin/manifest.json

currently contains the following line:

"version": "1.15.11.0",

when it should be "1.22.2".

I've investigated this problem and it seems to me the manifest is
being installed into the package without first calling
tools/make-chomium-meta.py during the build, which would update the
version.

--Daniel

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

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

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  chromium 78.0.3904.108-1~deb10u1
ii  firefox-esr  68.3.0esr-1~deb10u1

Versions of packages webext-ublock-origin suggests:
pn  ublock-origin-doc  

-- no debconf information

Bug#946797: debian-edu-config: kadm5.acl should set proper rights for users

[Wolfgang Schweer]

Package: debian-edu-config
Version: 1.812+deb8u1
Severity: important

To improve security, settings in kadm5.acl should be adjusted.

The needed fix is minimal:

--- a/share/debian-edu-config/tools/kerberos-kdc-init
+++ b/share/debian-edu-config/tools/kerberos-kdc-init
@@ -187,7 +187,7 @@ EOF
 if [ ! -f /etc/krb5kdc/kadm5.acl ] ; then
cat > /etc/krb5kdc/kadm5.acl <

signature.asc
Description: PGP signature

Bug#946795: ITP: wob -- lightweight overlay volume/backlight/progress/anything bar for wayland

[Jonas Meurer]

Package: wnpp
Severity: wishlist
Owner: Jonas Meurer 

* Package name: wob
  Version : 0.4
  Upstream Author : 
* URL : https://github.com/francma/wob
* License : ISC
  Programming Lang: C
  Description : lightweight overlay volume/backlight/progress/anything bar 
for wayland

wob is a lightweight overlay volume/backlight/progress/anything bar for
wayland, inspired by xob - the X overlay bar.

This package will be maintained under the swaywm-team umbrella.

Cheers
 jonas

Bug#946794: hibiscus: Please backport hibiscus

[Memnon Anon]

Source: hibiscus
Severity: wishlist

Dear Maintainer,

since every bank in Germany changed to comply with PSD2,
the version currently in stable is pretty much useless
at the moment. By now, it seems like hibiscus has
stabilized enough with 2.8.21, which already hit testing.

Please consider preparing a backport for the stable
users.


Kernel: Linux 4.19.0-6-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)


Shell: /bin/sh linked to /bin/bash

Init: systemd (via /run/systemd/system)

-- System Information:
Debian Release: 10.2
 APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
   Architecture: i386 (i686)

Bug#946793: RFP: bukuserver -- bukuserver exposes a browseable front-end on a local web host server, for buku

[jamie]

Package: wnpp

Severity: wishlist

license: GPL v3 

project url: https://github.com/jarun/Buku/tree/master/bukuserver

bukuserver provides a browseable front-end on a local web host server
for buku.

There is already a debian package for buku but it doesn't include
bukuserver.

It's possible that it's better to extend the buku package to include
bukuserver as well, but it might also make sense to have this as a
separate package.

Bug#946792: gcc-9: Buffer overflow bug introduced by gcc-search-prefixed-as-ld.diff

[John Paul Adrian Glaubitz]

Source: gcc-9
Severity: important

Hello!

Recently, we have observed strange crashes of gcc-9 while building src:linux
on sh4 [1].

Michael Karcher has debugged the problem and found that this is a buffer
overflow introduced by the patch gcc-search-prefixed-as-ld.diff.

The backtrace is:

Core was generated by `gcc -v -pipe -m4 -m4-nofpu hello.c'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x296993e6 in memcpy () from /lib/sh4-linux-gnu/libc.so.6
(gdb) bt
#0  0x296993e6 in memcpy () from /lib/sh4-linux-gnu/libc.so.6
#1  0x00405ade in file_at_path (path=0x29892fb0 
"/usr/lib/gcc/sh4-linux-gnu/9/../../../../sh4-linux-gnu/bin/sh4-linux-gnu/9/sh4-l",
 data=0x7b901400) at ../../src/gcc/gcc.c:2943
#2  0x00405b80 in file_at_path (path=0x29892fb0 
"/usr/lib/gcc/sh4-linux-gnu/9/../../../../sh4-linux-gnu/bin/sh4-linux-gnu/9/sh4-l",
 data=0x7b9014a0) at ../../src/gcc/gcc.c:2936
#3  0x00404d0e in for_each_path (paths=0x4e8520 , 
do_multi=, extra_space=2, callback=0x405a88 , callback_info=0x7b9014a0)
at ../../src/gcc/gcc.c:2724
#4  0x0040680c in find_a_file (pprefix=, name=0x29828240 "as", 
mode=1, do_multi=) at ../../src/gcc/gcc.c:2999
#5  0x00409e86 in execute () at ../../src/gcc/gcc.c:3200
#6  0x0040ff14 in driver::do_spec_on_infiles (this=0x7b9015f8) at 
../../src/gcc/gcc.c:8377
#7  0x00403b60 in driver::main (this=0x7b9015f8, argc=, 
argv=) at ../../src/gcc/gcc.c:7601
#8  0x00403dd4 in main (argc=6, argv=0x7b901694) at ../../src/gcc/gcc-main.c:47
(gdb)

See also [2].

The issue is fixed by replacing line 9 in [3] with:

+ len += strlen (DEFAULT_REAL_TARGET_MACHINE) + 2; /* triplet prefix 
for as, ld.  */

I assume it's just pure luck the issue doesn't show on other architectures.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=linux=sh4=5.3.15-1=1575738446=0
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92946
> [3] 
> https://sources.debian.org/src/gcc-9/9.2.1-21/debian/patches/gcc-search-prefixed-as-ld.diff/

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Tomas Janousek]

Hi,

On Fri, Dec 13, 2019 at 03:29:23PM +1030, Andrew Bettison wrote:
> As an experiment, I downloaded the tarball from 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tag/?h=20190815
> (as recommended in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939262
> ), and manually copied its intel/* and iwlwifi-* files into /lib/firmware
> (overwriting the ones installed by the firmware-iwlwifi package).
> 
> After rebooting kernel 5.3.0-2 (amd64) I still get "iwlwifi: Microcode SW
> error" messages accompanied by "ieee80211 phy0: Hardware restart was
> requested" during periods of high Wi-Fi throughput, but they do not cause
> the Wi-Fi to hang.  So the newer firmware appears to rectify the worst part
> of the problem (Wi-Fi freeze) but does not fully resolve the problem.

Can you perhaps try the current version as well? There's been one additional
change to iwlwifi firmwares since then:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=40e4162adfc91390f6fbbd8269f9439832af1dde

(I haven't tested either, I just downgraded to 20190502-1. Don't have the
mental budget to deal with another broken thing now.)

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/

Bug#946781: ITP: kw -- Inglorious kernel developer workflow scripts

[Nicolas Boulenguez]

> * Package name: kw
> * URL : https://github.com/kworkflow/kworkflow
> kw stands for Kernel Workflow.

Hi.
Please name the package kworkflow, or better kernel-workflow, in order
to avoid future painful conflicts.
All the best.

Bug#925563: dxvk installation script doesn't install 32 bit libraries to 64 bit prefix

[Alexandre Viau]

Hello,


Okay so I had more time for this today.

I am about to upload a new version that fixes this. I had to revert to 
other techniques to try and detect the prefix's state.


I think that the new setup will cover all use cases. I'll try to test a 
couple of setups myself before uploading. Feedback would be much 
appreciated.


Cheers,

--
Aleaxandre Viau
av...@debian.org

Bug#872646: qa.debian.org: [debcheck] Escape some HTML before outputting

[Colin Watson]

On Sun, Aug 20, 2017 at 02:53:09PM +0200, gregor herrmann wrote:
> On Sun, 20 Aug 2017 10:13:47 +0200, Mattia Rizzolo wrote:
> > On Sat, Aug 19, 2017 at 11:20:50AM -0700, Chris Lamb wrote:
> > > Updated patch attached, although the last hunk is probably unnecessary
> > > anyway.
> > 
> > Although, I'm not a perl guy so I must ask before applying:
> >  * shouldn't that function be `escape_html()` instead of `html_escape()` ?
> >(i.e., what is cited in the `use`)
> >  * does that thing requires a new dependency?  The closer thing I could
> >find on the net is
> >http://search.cpan.org/dist/HTML-Escape/lib/HTML/Escape.pm which
> >doesn't seem like something that is in the standard lib…
> >  * in the last chunk you escaped the first $me but not the latter in the
> >line below, probably best to at least be consistent?
> 
> AFAICS HTML::Escape is not packaged for Debian. 
> (Ack on the other points).
> 
> HTML::Entities might be an option:
> 
> https://metacpan.org/pod/HTML::Entities
> 
> Included in the libhtml-parser-perl package.

Yes, I think that's probably the right [1] answer.  quantz already has
libhtml-parser-perl installed too.

I've tidied this up along those lines and made a merge request:

  https://salsa.debian.org/qa/qa/merge_requests/27

Note that I didn't bother to escape things that have already been
checked as conforming to a syntax that doesn't require HTML-escaping,
e.g. priority names, just because it was getting unwieldy.  Ordinarily
I'd make sure to put all substitutions through an escaping mechanism
just to guard against future mistakes, but well, see [1].

[1] I might have written it this way myself when I first started writing
Perl in 1999 or so, so no criticism of the original author intended,
but I've very distinctly gone off the idea of assembling HTML out of
lots of little string fragments in the intervening two decades.
These days I'd use a templating system (e.g. Perl's Template Toolkit
looks reasonable enough) as a bare minimum.  But right now I really
don't feel like rewriting almost all of debcheck to achieve that ...

-- 
Colin Watson   [cjwat...@debian.org]

Bug#946790: RM: olsrd -- RoQA; build depends on pygtk2, orphaned

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove olsrd. It build depends on pygtk2, which is going away
and has been orphaned for almost four years without an adopter (last
maintainer upload was in 2014). Plus, there's a olsrd2 which should
rather be packaged instead.

Cheers,
Moritz

Bug#946724: dh-elpa: fails on native package versions with '+'

[David Bremner]

Roland Rosenfeld  writes:

>
> But the same should happen on an binNMU, where +nmu1 or +b1 is
> appended to the package version.
>

I guess one might need to switch to non-native packaging to make all the
tools happy. This hasn't been an issue so far since binNMUs of arch all
packages are not supported.

Bug#936585: gbirthday: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Tue, Oct 22, 2019 at 10:04:35PM +0200, Jérôme wrote:
> Hi.
> 
> Last gbirthday maintainer speaking.
> 
> The gbirthday package is more or less dead upstream, unless someone
> volunteers to take it over.

Hi Rolf,
are you planning to port it yourself or switch to the mentioned
qt port? Otherwise we should remove it from the archive.

Cheers,
Moritz

Bug#946789: yamllint: New upstream release

[Sylvestre Ledru]

Package: yamllint
Version: 1.18.0-1
Severity: wishlist

Hello,

Version 1.19 is now available:
https://github.com/adrienverge/yamllint/releases

Thanks
Sylvestre

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'buildd-unstable'), (500, 'oldstable'), 
(300, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages yamllint depends on:
ii  python33.7.3-1
ii  python3-pathspec   0.6.0-1
ii  python3-pkg-resources  40.8.0-1
ii  python3-yaml   3.13-2

yamllint recommends no packages.

yamllint suggests no packages.

-- no debconf information

Bug#885468: bumping severity of pygtk bugs

[Moritz Mühlenhoff]

On Sun, Oct 06, 2019 at 05:09:30PM -0400, Jeremy Bicha wrote:
> Control: severity -1 serious
> Control: tags -1 -buster
> 
> 
> As part of the Python2 removal, it is our intent that pygtk will be removed 
> from Testing before the release of Debian 11
> "Bullseye". Therefore, I am bumping the severity of this bug to Serious to 
> ensure that there is plenty of warning before
> the Debian 11 release and to make the eventual removal of pygtk as smooth as 
> possible.

The latest pycha 0.8.1 (while ported to Python 3) still uses pygtk2 and there
are no reverse deps in the archive, shall we remove it?

Cheers,
Moritz

Bug#946788: (no subject)

[c.buhtz]

Upstream bug report can be found here

https://github.com/kurtmckee/feedparser/issues/198

Bug#946788: feedparser: PEP 479 problem causing StopIteration exceptions

[Christian Buhtz]

Package: python3-feedparser
Version: 5.2.1-1
Severity: normal
File: feedparser

Hello,

I still asked about how to handle this problem on the mailing list but did not
receive an answer.
https://alioth-lists.debian.net/pipermail/python-modules-
team/2019-December/061104.html

The debian-current stable version of feedparser is 5.2.1-1 and causing erorrs
because of PEP 479 which is switched on (armed) in Python 3.7.

Feedparser upstream still have fixed it with some lines but not yet released.
https://github.com/kurtmckee/feedparser/pull/131

The next planed stable release of Feedparser is a major one 6.0.0.

The question to you is if you would accept 6.0.0 in Debian 10 or is it a  bit
to much modifications?
Whould you prefere to see the fix backported?

Would the debian package maintainer backport this by him/herself and
create a 5.2.1-2?

Or is it better to have upstream release a 5.2.2 that the debian package
maintainer can introduce to Debian 10?

Or another way I can not see?

kind



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

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

Versions of packages python3-feedparser depends on:
ii  python3  3.7.3-1

python3-feedparser recommends no packages.

python3-feedparser suggests no packages.

-- no debconf information

Bug#946787: policyd-spf-fs: FTBFS in sid/experimental: undefined reference to many SPF_* symbols

[Andreas Beckmann]

Source: policyd-spf-fs
Version: 0+svn27-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

At some point after the release of buster policyd-spf-fs started to
FTBFS:

 debian/rules build
dh_testdir
/usr/bin/make LIBS=-lspf2
make[1]: Entering directory '/build/policyd-spf-fs-0+svn27'
gcc -g -O2 -Wall -DHAVE_GETOPT_LONG_ONLY -I /usr/include/spf2 -c -o 
policyd-spf-fs.o policyd-spf-fs.c
policyd-spf-fs.c: In function 'main':
policyd-spf-fs.c:405:11: warning: variable 'opt_keep_comments' set but not used 
[-Wunused-but-set-variable]
  405 |  int  opt_keep_comments = 0;
  |   ^
gcc -g -O2 -Wall -DHAVE_GETOPT_LONG_ONLY -lspf2 policyd-spf-fs.o -o 
policyd-spf-fs
/usr/bin/ld: policyd-spf-fs.o: in function `response_print_errors':
/build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:226: undefined reference to 
`SPF_response_message'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:227: undefined 
reference to `SPF_error_message'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:231: undefined 
reference to `SPF_error_errorp'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:228: undefined 
reference to `SPF_error_errorp'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:225: undefined 
reference to `SPF_response_messages'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:222: undefined 
reference to `SPF_strerror'
/usr/bin/ld: policyd-spf-fs.o: in function `response_print':
/build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:252: undefined reference to 
`SPF_response_result'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:252: undefined 
reference to `SPF_strresult'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:254: undefined 
reference to `SPF_response_reason'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:254: undefined 
reference to `SPF_strreason'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:256: undefined 
reference to `SPF_response_errcode'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:256: undefined 
reference to `SPF_strerror'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:258: undefined 
reference to `SPF_response_errcode'
/usr/bin/ld: policyd-spf-fs.o: in function `main':
/build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:435: undefined reference to 
`SPF_error_syslog'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:435: undefined 
reference to `SPF_error_handler'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:436: undefined 
reference to `SPF_warning_syslog'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:436: undefined 
reference to `SPF_warning_handler'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:437: undefined 
reference to `SPF_info_syslog'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:437: undefined 
reference to `SPF_info_handler'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:438: undefined 
reference to `SPF_debug_syslog'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:438: undefined 
reference to `SPF_debug_handler'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:722: undefined 
reference to `SPF_response_free'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:723: undefined 
reference to `SPF_request_free'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:724: undefined 
reference to `SPF_server_free'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:505: undefined 
reference to `SPF_get_lib_version'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:554: undefined 
reference to `SPF_server_new'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:557: undefined 
reference to `SPF_server_set_rec_dom'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:564: undefined 
reference to `SPF_server_set_localpolicy'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:570: undefined 
reference to `SPF_response_free'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:578: undefined 
reference to `SPF_server_set_explanation'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:584: undefined 
reference to `SPF_response_free'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:621: undefined 
reference to `SPF_request_set_helo_dom'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:628: undefined 
reference to `SPF_request_set_env_from'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:636: undefined 
reference to `SPF_request_query_mailfrom'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:649: undefined 
reference to `SPF_response_result'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:649: undefined 
reference to `SPF_strresult'
/usr/bin/ld: /build/policyd-spf-fs-0+svn27/policyd-spf-fs.c:689: undefined 
reference to `SPF_request_query_fallback'
/usr/bin/ld: 

Bug#932052: RM: lhapdf -- RoQA; FTBFS, no progress since May 2018

[Ryan Tandy]

Control: tag -1 - moreinfo

On Sat, Jul 27, 2019 at 02:23:33PM -0400, Scott Kitterman wrote:

Checking reverse dependencies...
# Broken Depends:
thepeg: libthepeg15 [amd64 arm64 armel armhf mips64el ppc64el s390x]

# Broken Build-Depends:
thepeg: lhapdf-pdfsets-minimal
   liblhapdf-dev

Dependency problem found.

Please remove the moreinfo tag once these have been resolved.


thepeg was removed a few days ago (#946587). Would you please check lhapdf 
again?

Bug#946655: dh_perl: why is ${perl:Depends} substituted as perl:any for programs only?

[Helmut Grohne]

Hi Niko,

On Sun, Dec 15, 2019 at 08:34:47PM +0200, Niko Tyni wrote:
> I don't understand. AFAICS if the interpreter needing the modules is
> /usr/bin/perl, the perl:any dependency will pull in compatible standard
> library extension modules: the perl -> perl-base dependency guarantees
> perl will be the same arch as /usr/bin/perl, and the perl -> libperl5.30
> dependency pulls in the modules for that architecture.
> 
> If it's an embedded interpreter, a compatible set of those is already
> shipped with the interpreter (in libperl5.30).
> 
> So where's the problem here?

There is no problem. Thank you for the explanation.

Does that mean we can move forward with using perl:any for modules?

I think the check in dh_perl line 142 should be changed from

perlarch .= ':any' if $deps == PROGRAM and not $dh{V_FLAG_SET};

to

perlarch .= ':any' if $deps & (PROGRAM|PM_MODULE) != 0 and not 
$dh{V_FLAG_SET};

Helmut

Bug#946671: [debian-mysql] Bug#946671: mariadb-server-10.3: mysqlhotcopy and transaction_registry table

[Otto Kekäläinen]

Forwarded: https://jira.mariadb.org/browse/MDEV-21317

Bug#946714: gimp: GIMP crashed with a fatal error when a was editing an image

[Bernhard Übelacker]

Hello Jesús,

> Version: 2.10.12-0.1~mx19+1

Could not find a dbgsym package for that gimp version.
Is your system a MX Linux installation or a plain Debian?
At least in the first case, I guess, the MX Linux forums
can give better support.

And if the crash is reproducible it would help if you
could describe in detail the steps leading to the crash.

Kind regards,
Bernhard

Bug#946342: dxvk: dxvk-setup not working

[Alexandre Viau]

Hello,

/usr/bin/wine64-development is a symlink. It should point to the proper 
binary in /usr/lib.


It looks like your wine installation is broken and you have
/usr/bin/wine64-development pointing to 
/usr/lib/wine-development/wine64-development instead of 
/usr/lib/wine-development/wine64.


It doesn't have anything to do with dxvk.

Cheers,

--
Aleaxandre Viau
av...@debian.org

Bug#944755: pylucene: should this package be removed?

[Ryan Tandy]

reassign 944755 ftp.debian.org
retitle 944755 RM: pylucene -- RoQA; FTBFS; RC-buggy for 2 years
severity 944755 normal
thanks

Dear maintainer,

As there was no response in over a month I hereby reassign this bug to 
ftp-masters as a removal request (RoQA).


To ftp-master: removing pylucene should also unblock removing the old 
libasm4-java (#940067).

Bug#946786: heimdal: CVE-2019-14870

[Salvatore Bonaccorso]

Source: heimdal
Version: 7.5.0+dfsg-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for heimdal.

CVE-2019-14870[0]:
| All Samba versions 4.x.x before 4.9.17, 4.10.x before 4.10.11 and
| 4.11.x before 4.11.3 have an issue, where the S4U (MS-SFU) Kerberos
| delegation model includes a feature allowing for a subset of clients
| to be opted out of constrained delegation in any way, either S4U2Self
| or regular Kerberos authentication, by forcing all tickets for these
| clients to be non-forwardable. In AD this is implemented by a user
| attribute delegation_not_allowed (aka not-delegated), which translates
| to disallow-forwardable. However the Samba AD DC does not do that for
| S4U2Self and does set the forwardable flag even if the impersonated
| client has the not-delegated flag set.

This issue affects as well heimdal itself.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-14870
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14870
[1] https://github.com/heimdal/heimdal/pull/663
[2] https://github.com/heimdal/heimdal/pull/664 (port to 7.1 branch)

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#946784: surf: can't start surf from gnome

[Marc Chantreux]

Package: surf
Version: 2.0+git20181009-4
Severity: important

Dear Reiner,

I can't start surf from my terminal in a gnome session using wayland. i
can read this on stderr:

(surf:31064): Gdk-WARNING **: 19:21:06.415: Failed to load cursor theme 
Adwaita
(surf:31064): Gtk-WARNING **: 19:21:06.449: Theme parsing error: 
gtk-keys.css:1:0: Failed to import: Erreur lors de l’ouverture du fichier 
/usr/share/themes/Default/gtk-3.0/gtk-keys.css : Permission non accordée
(surf:31064): Gdk-WARNING **: 19:21:06.449: Failed to load cursor theme 
Adwaita
Cannot get default EGL display: EGL_BAD_PARAMETER
unable to open lockfile 
/run/user/1000/webkitgtk-wayland-compositor-3b39085b-ccd1-4de6-9419-3c77e447bc5b.lock
 check permissions
Nested Wayland compositor could not create display socket
**

Gdk:ERROR:../../../../../gdk/wayland/gdkdisplay-wayland.c:1143:_gdk_wayland_display_get_scaled_cursor_theme:
 assertion failed: (display_wayland->cursor_theme_name)

regards,
marc

Bug#946785: Invalid package suggestion: gstreamer-plugins-ugly

[MichaIng]

Package: gmediarender
Version: 0.0.8-1
Additionally: Current Stretch + Buster package

All gmediarender packages from Stretch til Sid contain the suggestion 
"gstreamer-plugins-ugly" which is invalid and should be replaced by 
"gstreamer1.0-plugins-ugly" which exist in all repos and matches per 
naming the recommendation "gstreamer1.0-plugins-good" and second 
suggestion "gstreamer1.0-plugins-bad".


Nothing serious but fix should be straight forward.

Best regards,
MichaIng

Bug#946510: Support for accelerated graphics and video decoding on PINE A64+ in bullseye

[Vagrant Cascadian]

Control: tags 946510 pending

On 2019-12-14, Andrei POPESCU wrote:
> On Vi, 06 dec 19, 19:57:07, Andrei POPESCU wrote:
>> On Vi, 06 dec 19, 15:05:32, Marcin Juszkiewicz wrote:
>> > Use Lima (Pine A64) or Panfrost (Rock64)?
>> 
>> Sure... how?
>> 
>> I changed my xorg.conf as per [1], but not apparent change. What (else) 
>> is missing?
>
> For the Allwinner A64 the sun8i-mixer module is missing, see #946510.

Thanks for looking into this!

Did some basic compile testing and pushed to the git kernel repository,
should land in the next linux 5.3.x and 5.4.x uploads.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#946783: debootstrap: cannot specify --foreign and --unpack-tarball at the same time

[Cel Skeggs]

Package: debootstrap
Version: 1.0.114
Severity: normal
Tags: patch

Dear Maintainer,

After upgrading to Buster, one of my scripts that uses debootstrap has stopped
working, specifically on a step that involves both the --foreign option and the
--unpack-tarball option.

Reproduction steps:

$ sudo debootstrap --variant=minbase --make-tarball=test.tgz stretch test
$ sudo debootstrap --variant=minbase --foreign 
--unpack-tarball=$PWD/test.tgz stretch test

When I run the second command, I get the following output:

   /usr/sbin/debootstrap: 266: [: 
--unpack-tarball=/homeworld/reproduce/test.tgz: unexpected operator
   E: --foreign is specified with 
--unpack-tarball=/homeworld/reproduce/test.tgz, please use only one of those 
options.

I would expect that these two options could be used together, and there appears
to be code provided in /usr/share/debootstrap/functions that would allow this
particular combination:

### option 
handling
check_conflicting_option () {
if [ "$set_what_to_do" = --foreign ] && [ "${1%%=*}" = 
--unpack-tarball ] || \
   [ "${set_what_to_do%%=*}" = "--unpack-tarball" ] && [ "$1" 
== --foreign ]; then
LOOSEN_CONFLICTING_RESTRICTION="true"
elif [ -n "$set_what_to_do" ]; then
error 1 ARG_CONFLICTING "$set_what_to_do is specified 
with $1, please use only one of those options."
fi
set_what_to_do="$1"
}

It seems to me that there are two bugs here:

   * sh's test builtin does not support '==', whereas bash's does, so the use
 of '==' causes the 'unexpected operator' error above.
   * sh's order of operations does not distinguish between && and ||, so the
 series of logical operators mean ((A && B) || C) && D, rather than
 (A && B) || (C && D).

I was able to solve this, at least for my use case, with the following patch:

--- /usr/share/debootstrap/functions2019-12-15 14:20:12.68900 -0500
+++ /usr/share/debootstrap/functions2019-12-15 14:20:27.87200 -0500
@@ -262,8 +262,8 @@
 
 ### option handling
 check_conflicting_option () {
-   if [ "$set_what_to_do" = --foreign ] && [ "${1%%=*}" = --unpack-tarball 
] || \
-  [ "${set_what_to_do%%=*}" = "--unpack-tarball" ] && [ "$1" == 
--foreign ]; then
+   if ( [ "$set_what_to_do" = --foreign ] && [ "${1%%=*}" = 
--unpack-tarball ] ) || \
+  ( [ "${set_what_to_do%%=*}" = "--unpack-tarball" ] && [ "$1" = 
--foreign ] ); then
LOOSEN_CONFLICTING_RESTRICTION="true"
elif [ -n "$set_what_to_do" ]; then
error 1 ARG_CONFLICTING "$set_what_to_do is specified with $1, 
please use only one of those options."

I believe this bug was introduced by commit 
25d80b10319ed292827d016bfea6edcdb51b9b52,
during the fix for bug #551838.

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

Kernel: Linux 4.19.84-1.pvops.qubes.x86_64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages debootstrap depends on:
ii  wget  1.20.1-1.1

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.12-1+deb10u1

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Bug#946782: cups: CVE-2019-2228

[Salvatore Bonaccorso]

Source: cups
Version: 2.3.0-7
Severity: important
Tags: security upstream
Control: found -1 2.2.10-6+deb10u1
Control: found -1 2.2.1-8+deb9u2
Control: found -1 2.2.1-8+deb9u4
Control: found -1 2.2.1-8

Hi,

The following vulnerability was published for cups.

CVE-2019-2228[0]:
| In array_find of array.c, there is a possible out-of-bounds read due
| to an incorrect bounds check. This could lead to local information
| disclosure in the printer spooler with no additional execution
| privileges needed. User interaction is not needed for
| exploitation.Product: AndroidVersions: Android-8.0 Android-8.1
| Android-9 Android-10Android ID: A-111210196


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-2228
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2228

Please adjust the affected versions in the BTS as needed.



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

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

Bug#946732: [Python-modules-team] Bug#946732: python-django-braces: autopkgtest failure: No module named 'django_braces'

[Paul Gevers]

Hi Emmanuel,

On 15-12-2019 17:01, Emmanuel Arias wrote:
> I've just push to salsa the fix. I add the
> `debian/tests/pkg-python/import-name` file
> but locally the error is still happening.

With which version of autodep8? Are you running on buster? I guess we
should backport all of autopep8 and autopkgtest.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#946736: RM: defendguin -- RoM; questionable copyright status

[Bill Kendrick]

On Sat, Dec 14, 2019 at 08:47:41PM -0500, John Scott wrote:
> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-CC: debian-rele...@lists.debian.org, n...@sonic.net
> Control: block 934976 by -1
> 
> The maintainer and author acknowledges that the game uses Bill Gates's
> likeness and likely non-free audio samples from the Defender arcade game
> and requests that it be removed. See #934976
> 
> The package is in unstable, Buster, Stretch, and Jessie.

FYI, I've been (slowly) working to replace the suspect content,
and will eventually have a fresh source tarball available.
I don't have an ETA, however.

-- 
-bill!
Sent from my computer

Bug#946781: ITP: kw -- Inglorious kernel developer workflow scripts

[Rodrigo Carvalho]

Package: wnpp
Severity: wishlist
Owner: Rodrigo Carvalho 

* Package name: kw
  Version : 20191112
  Upstream Author : Rodrigo Siqueira 
* URL : https://github.com/kworkflow/kworkflow
* License : GPL-2
  Programming Lang: Shell Script
  Description : Inglorious kernel developer workflow scripts

kw is a set of scripts that
have mission to reduce the overhead
related with infrastructure project setup in
projects that have a similar workflow to the Linux Kernel.

kw stands for Kernel Workflow.

Bug#933264: don't think the new kotlin and hence new gradle will come soon.

[shirish शिरीष]

Dear Martin,

Don't think it wil happen soon, although would be delighted to be proved wrong.

>From what I understand, there seems to be issues with kotlin's
packaging or some sources in kotlin's source package. See Emmanuel
Buorg's reply to a similar asked by me couple of months ago. [1] .

Although no reason to lose hope just yet as there was another small
update to gradle in sid and now in testing today [2]

I am guessing we either have to wait for the java-team to move forward
or if you have any programming/packaging skills and wish to contribute
such skills then you can start by asking the java-team [3] . Looking
forward to any news and updates on kotlin as and when possible :)

1. https://lists.debian.org/debian-java/2019/10/msg7.html
2. 
https://tracker.debian.org/news/1085795/accepted-gradle-441-10-source-into-unstable/
3. https://java.debian.net/

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#856524: RFA: libpst - library for reading Microsoft Outlook PST files

[Leo "Costela" Antunes]

Hi Paul,

On Sun, Dec 15, 2019 at 5:44 AM Paul Wise  wrote:
> We started using libpst at work and I just got approval to adopt the
> package. I'll start by adding myself to uploaders and committing some
> packaging updates to the Debian git repository. Are you OK with me
> adopting the package and do you want to co-maintain the package?

I'd be very glad to finally hand this over to someone with the time
this little package deserves!
Feel free to just take it over completely. If and when the occasion
presents itself, I'm sure we'll find a quick way for me to start
helping again.

Cheers,
Leo

Bug#945112: debcheck: handle debhelper-compat

[Colin Watson]

On Sun, Dec 15, 2019 at 07:59:12PM +0100, Thorsten Glaser wrote:
> On Sun, 15 Dec 2019, Colin Watson wrote:
> > Both this and debhelper-compat are cases of versioned Provides (although
> > one is typically found in Build-Depends and one in Depends, but it works
> > out much the same way).  I've made a merge request that should fix this:
> 
> Thanks!
> 
> I get that or’d dependencies may be an issue in Build-Depends
> due to buildds only using the first alternative, but this was
> counter-productive in my DDPO.

The problem with "default-logind | logind" wasn't anything to do with
alternative build-dependencies; it was that both default-logind and
logind only appear in versioned Provides, so debcheck didn't realise
that either of them was provided at all.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#946780: deb-changelog: Please document whether the format requires metadata (and the semicolon)

[Josh Triplett]

Package: dpkg-dev
Version: 1.19.7
Severity: wishlist
File: /usr/share/man/man5/deb-changelog.5.gz

The deb-changelog manpage defines the first line of the format as:

   package (version) distributions; metadata

This line, and the subsequent description, doesn't make the following
clear:

- Is a package required to have at least one metadata field?
- If a package can have no metadata, does the first line require a
  semicolon (immediately preceding the newline), or can it omit the
  semicolon?

(I don't want to assume that the behavior of any particular
changelog-parsing tool describes the requirements of the standard; I'd
like to know what the standard allows/requires.)

Thanks,
Josh Triplett

Bug#946779: buster-pu: package logrotate/3.14.0-4

[Christian Göttsche]

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

With version 3.14.0 [1] logrotate split the configuration for btmp and
wtmp into separate configuration files.
There are bug reports regarding this issue: 945932, 928516, 922045.

Package version 3.14.0-4+deb10u1 adds a NEWS entry about this change.

The packaging can be found at [2].
An upload can be found at [3].


<> debdiff
diff -Nru logrotate-3.14.0/debian/changelog logrotate-3.14.0/debian/changelog
--- logrotate-3.14.0/debian/changelog   2018-08-29 00:21:11.0 +0200
+++ logrotate-3.14.0/debian/changelog   2019-12-15 18:53:33.0 +0100
@@ -1,3 +1,9 @@
+logrotate (3.14.0-4+deb10u1) stable; urgency=medium
+
+  * d/NEWS: add entry about (b|w)tmp config split
+
+ -- Christian Göttsche   Sun, 15 Dec 2019
18:53:33 +0100
+
 logrotate (3.14.0-4) unstable; urgency=medium

   * d/control:
diff -Nru logrotate-3.14.0/debian/NEWS logrotate-3.14.0/debian/NEWS
--- logrotate-3.14.0/debian/NEWS2018-08-29 00:21:11.0 +0200
+++ logrotate-3.14.0/debian/NEWS2019-12-15 18:53:33.0 +0100
@@ -1,3 +1,17 @@
+logrotate (3.14.0-1) unstable; urgency=medium
+
+  The shipped configurations for "/var/log/btmp" and "/var/log/wtmp" have
+  been split from the main configuration file (/etc/logrotate.conf) into
+  separate standalone files (/etc/logrotate.d/btmp respectively
+  /etc/logrotate.d/wtmp).
+
+  If you had modified /etc/logrotate.conf in this regard, make sure
+  to re-adjust the two new files to your needs and drop any references to
+  (b|w)tmp from the main file, to avoid logrotate skip rotation due to a
+  duplicate definition.
+
+ -- Christian Göttsche   Sun, 15 Dec 2019
18:49:00 +0200
+
 logrotate (3.8.0-1) experimental; urgency=low

   Please note that this update changes the behaviour of logrotate:
<---> debdiff end


Best regards,
 Christian Göttsche

[1] https://github.com/logrotate/logrotate/blob/master/ChangeLog.md
[2] https://salsa.debian.org/debian/logrotate/tree/stable-buster
[3] https://mentors.debian.net/package/logrotate

Bug#816449: debcheck: Lists missing Standards-Version for udebs

[Colin Watson]

On Tue, Mar 01, 2016 at 11:03:29PM +0100, Guillem Jover wrote:
> The debcheck script is reporting that many udebs are missing the
> Standards-Version field, but udebs are not supposed to have such field
> as they do not follow Debian policy.
> 
>   
> 

I've made a merge request which should fix this:

  https://salsa.debian.org/qa/qa/merge_requests/26

-- 
Colin Watson   [cjwat...@debian.org]

Bug#946778: broken-symlink found by adequate in python3-paste MochiKit.js

[shirish शिरीष]

Package: python3-paste
Version: 3.2.3+dfsg1-1
Severity: normal

Usertags: broken-symlink adequate
User: debian...@lists.debian.org

Dear Maintainer,
Adequate informed me that there is a broken symlink in python3-paste.

$ adequate python3-paste
python3-paste: broken-symlink
/usr/lib/python3/dist-packages/paste/evalexception/media/MochiKit.packed.js
-> ../../../../../../share/javascript/mochikit/MochiKit.js

Please fix the same.

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

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

Versions of packages python3-paste depends on:
ii  python33.7.5-1
ii  python3-pkg-resources  41.2.0-1
ii  python3-six1.13.0-1
ii  python3-tempita0.5.2-5

Versions of packages python3-paste recommends:
ii  python3-openssl  19.0.0-1

Versions of packages python3-paste suggests:
pn  httpd-wsgi 
pn  libapache2-mod-python  
pn  libapache2-mod-scgi
pn  libjs-mochikit 
pn  python3-pastedeploy

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#945112: debcheck: handle debhelper-compat

[Thorsten Glaser]

On Sun, 15 Dec 2019, Colin Watson wrote:

> Both this and debhelper-compat are cases of versioned Provides (although
> one is typically found in Build-Depends and one in Depends, but it works
> out much the same way).  I've made a merge request that should fix this:

Thanks!

I get that or’d dependencies may be an issue in Build-Depends
due to buildds only using the first alternative, but this was
counter-productive in my DDPO.

Have a nice evening,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#946655: dh_perl: why is ${perl:Depends} substituted as perl:any for programs only?

[Niko Tyni]

On Sun, Dec 15, 2019 at 11:26:34AM +0100, Helmut Grohne wrote:

> I fear that your other mail made me realize a mistake though. Unlike
> python there is no standard installation. For perl it's perl-base and
> perl. We cannot take perl for granted. Now perl pulls libperl5.30, which
> contains extensions and we must preserve the architecture constraint
> from our pure perl module to the relevant extension modules used from
> libperl5.30.

I don't understand. AFAICS if the interpreter needing the modules is
/usr/bin/perl, the perl:any dependency will pull in compatible standard
library extension modules: the perl -> perl-base dependency guarantees
perl will be the same arch as /usr/bin/perl, and the perl -> libperl5.30
dependency pulls in the modules for that architecture.

If it's an embedded interpreter, a compatible set of those is already
shipped with the interpreter (in libperl5.30).

So where's the problem here?
-- 
Niko

Bug#940463: fixed in falkon 3.1.0+dfsg1-4

[John Scott]

Control: reopen -1
Control: tags -1 unreproducible moreinfo
Control: severity -1 normal

If 3.1.0+dfsg1-4 doesn't have any changes from 3.1.0+dfsg1-3, why was it 
uploaded? That uses additional mirror space and rebuilds all of the packages. 
It also marks the bug as fixed in 3.1.0+dfsg1-4. Instead, if a bug isn't being 
fixed by a new upload, send the reason you're closing it to 940463-done@b.d.o  
with a Version: header reflecting if a version does have a fix.

> As my last e-mail tells, I "Checked that falkon-3.1.0+dfsg1-3 does not
> crash", which can be considered as being unable to reproduce the bug.
Bugs shouldn't be closed solely for being unreproducible. Instead, add the  
tags and contact the submitter. I see you might've been desperate to get 
Falkon back into testing since the upload was the same day it was removed. 
Bugs serious, grave, and critical cause removal, so I've downgraded the bug to 
normal.

> I got no reply from Xeno Idaltu , so I believe
> that either he is not using falkon again, or he installed falkon's new
> package and found the bug fixed.
Did you reply to him separately from the bug report? The log doesn't show 
anyone reaching out to him.

Additionally, I'm curious about this changelog entry
> falkon (3.1.0+dfsg1-5) unstable; urgency=medium
>   * removed the dependency on libgnome-keyring-dev, since this package
> is no longer part of Debian. Together with the upstream version
> change, this ... Closes: #943769
since #943769 doesn't appear to be related to GNOME Keyring.

I am also seeking to know why 3.1.0+dfsg1-3 has a +dfsg1-3 since the prior 
uploads were 3.0 and didn't have the +dfsg1. I haven't been able to find the 
reason for the change documented.

I haven't been able to reproduce the bug. However, I hope my suggestions are 
helpful for you and that I'll be able to help Falcon in this way.

Sincerely,
John Scott

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

Bug#880368: YAML::XS::Load expects utf8 octets, not perl's encoding; use slurp_raw

[Dominique Dumont]

On Fri, 13 Dec 2019 14:23:46 +0100 Andrej Shadura 
 wrote:
> As a temporary workaround, I patched the locally used version to use
> YAML::XS, but as I see you won?t accept this patch upstream. Is there a
> solution that would satisfy both conditions of how having security
> issues and supporting proper YAML? 

YAML::XS security issues has been fixed upstream. Now 
Config::Model::Backend::Yaml uses YAML:XS

That said, YAML input and output is used in several places in libconfig-model-
dpkg-perl. I fail to see your use case which involves debian/copyright in YAML 
format.

Could you provide more details on your use case ?

> By the way, what are those security
> issues and how serious and relevant to scan-copyrights are they?

YAML specification allows serialisation of Perl object, which means its 
destructor is invoked when this object is destroyed. Since the yaml data that 
may contain a Perl object may comes from untrusted package source, this was a 
security issue (albeit quite far fetched).

Anyway, YAML::XS now has a switch to disable object creation when loading 
YAML. See https://github.com/ingydotnet/yaml-libyaml-pm/issues/45 for more 
details.

Bug#946777: gource: "Error while decoding stream" FFMpeg error parsing Gource PPM

[Jochen Sprickerhof]

Package: gource
Version: 0.49-1+b2
Severity: normal

Hi,

The gource version in Debian produces a PPM output that is not parsable
by ffmpeg. This is fixed by upstream in version 0.50 and I've verified
it locally. Please upload the new version.

If you don't have time to do it, I can do an NMU. If you don't answer by
next week Sunday, I assume that you are too busy and will upload the new
version.

Cheers Jochen

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

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

Versions of packages gource depends on:
ii  fonts-freefont-ttf 20120503-9
ii  libboost-filesystem1.67.0  1.67.0-16
ii  libboost-system1.67.0  1.67.0-16
ii  libc6  2.29-6
ii  libfreetype6   2.10.1-2
ii  libgcc11:9.2.1-21
ii  libgl1 1.1.0-1+b1
ii  libglew2.1 2.1.0-4+b1
ii  libglu1-mesa [libglu1] 9.0.1-1
ii  libpcre3   2:8.39-12+b1
ii  libpng16-161.6.37-1
ii  libsdl2-2.0-0  2.0.10+dfsg1-1
ii  libsdl2-image-2.0-02.0.5+dfsg1-1
ii  libstdc++6 9.2.1-21
ii  libtinyxml2.6.2v5  2.6.2-4
ii  zlib1g 1:1.2.11.dfsg-1+b1

gource recommends no packages.

gource suggests no packages.

-- no debconf information

Bug#946268: Please add support for custom entries

[Jonas Smedegaard]

Quoting andreimpope...@gmail.com (2019-12-15 16:50:17)
> On Mi, 11 dec 19, 03:19:16, Jonas Smedegaard wrote:
> > 
> > Thanks¹ for the attached patch.
> > 
> > Looks great!
> 
> Thanks :)
>  
> > One detail: Seems more sensible to me to by default check for and 
> > include addon config if it exists - i.e. not only if uncommented in 
> > main config as in your proposed patch.
> > 
> > Do you have some opinion on that?
> 
> After thinking about this for a while it seems to me like the custom 
> entries are a solution of last resort and should not be activated by 
> default.

I don't understand what you mean gets "activated by default": By default 
no custom file exists, and therefore none is "activated".

Reason I prefer having that entry uncommented by default is to not need 
editing main file when adding a custom file.  Main file is a conffile so 
the fewer situations it needs editing the better.

Compare to config parsers supporting slurping config.d entries: When the 
admin or another package adds the entry, it get included _without_ 
needing to touch the main conffile.


> For me it would make more sense to add some more variables to generate 
> different entries, e.g. something like U_BOOT_ALT_ROOT (alternative 
> root file system for which to generate entries).

Sorry, I don't understand what you are saying here.  Seems to you are 
switching topic to discuss something else, is that correct?


Kind regards,

 - Jonas

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

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


signature.asc
Description: signature

Bug#946370: Packaging problems with yubikey-luks-open

[Jordan Glover]

The fix [1] for PATH issue was sent long time ago to debian package
repository but it seem no longer maintained.

[1] https://salsa.debian.org/auth-team/yubikey-luks/merge_requests/1

Jordan

Bug#945057: libnet-dbus-perl FTCBFS: uses the build architecture pkg-config

[Niko Tyni]

On Sun, Dec 15, 2019 at 04:39:18PM +0100, Helmut Grohne wrote:

> If we count Debian in, this is four different Linux distributions all
> trying to cross build (part of) cpan. I think this shows that moving
> some of the integration upstream is worth a try. The less each and every
> distribution diverges here, the less work there will be.

Thanks for the links, they are interesting. Sorry about my pessimism.

> If we assume that our solution cannot be upstreamed, I agree with that.
> That'd make me sad though. In a number of (non-perl) occasions, I've
> encountered that one of our other cross distributions had fixed a cross
> build bug with a patch that wasn't upstreamable (often called
> "hackfix"). I've tried sending real and upstreamable patches in such
> cases to permanently get rid of the need to patch.

This is of course very commendable.

> So I think the key here is to propose a useful interface for
> communicating pkg-config and then agreeing with all other users on that
> interface in order to be able to upstream the resulting per-module
> patches.
> 
> I guess the next step is searching through our lib*-perl build failures
> for occasions of using pkg-config. Then match those failures with other
> distributions to encounter prior art and finding a common denominator. I
> plan on looking into this, but not today.

Thanks for your work.
-- 
Niko

Bug#927783: Load ipxe.efi under UEFI, not ipxe.lkrn

[Alkis Georgopoulos]

Hi, I filed an updated version of the patch as a merge request:

https://salsa.debian.org/waldi/ipxe/merge_requests/1

The one additionally saves the default entry, so that the GRUB iPXE 
entry is consistent with all the other entries.
It was a 2-line diff upon the previous one, in the same spot, so I 
thought I'd include that too.

Bug#946776: datefudge --static doesn't fix the sub-seconds part

[Christoph Berg]

Package: datefudge
Version: 1.23
Severity: important

I just tried to use `datefudge --static` to fix varying timestamps in
some sphinx documentation, but ultimately failed because the
sub-seconds part of the time is still not constant:

$ datefudge --static '@1576429380' date '+%T %N'
18:03:00 909497611
$ datefudge --static '@1576429380' date '+%T %N'
18:03:00 655601982

(If that's intended, it needs to be documented.)

Christoph

Bug#946775: ITP: wofi -- Wofi is a launcher/menu program for wlroots based wayland compositors such as sway.

[Jonas Meurer]

Package: wnpp
Severity: wishlist
Owner: Jonas Meurer 

* Package name: wofi
  Version : 0~2019.12.02.bbca0043e2a5
  Upstream Author : Scoopta 
* URL : https://hg.sr.ht/~scoopta/wofi
* License : GPL-3
  Programming Lang: C
  Description : application launcher for wlroots based wayland compositors

wofi is an application launcher and menu program for wlroots based wayland
compositors such as sway. It brings support for three built-in modes:
* drun - launch XDG Desktop files
* run - launch executables from $PATH
* dmenu - dmenu-compatabile mode to read lines from stdin
.
Wofi is easily themeable with the help of CSS style sheets.

This package will be maintained under the swaywm-team umbrella.

Cheers
 jonas

Bug#946774: dieharder FTCBFS: uses AC_RUN_IFELSE

[Helmut Grohne]

Source: dieharder
Version: 3.31.1-8
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dieharder fails to cross build from source, because its configure script
uses AC_RUN_IFELSE to discover the endianess. The check included in
autoconf, AC_C_BIGENDIAN, can be performed without running host code.
Using it results in better portability and less code. Please consider
applying the attached patch.

Helmut
--- dieharder-3.31.1.orig/configure.ac
+++ dieharder-3.31.1/configure.ac
@@ -125,30 +125,7 @@ AC_CHECK_LIB([gsl],[gsl_sf_gamma])
 # brg_endian.h in the build of rng_threefish.  This is a very
 # certain test, and therefore is checked FIRST in this header file.
 #==
-AC_DEFUN([AC_C_ENDIAN],
-[AC_CACHE_CHECK(for endianness, ac_cv_c_endian,
-[
-  AC_RUN_IFELSE(
-[AC_LANG_PROGRAM([], [dnl
-long val = 1;
-char *c = (char *) 
-exit(*c == 1);
-])
-  ],[
-ac_cv_c_endian=big
-  ],[
-ac_cv_c_endian=little
-  ])
-])
-if test $ac_cv_c_endian = big; then
-  AC_SUBST(LITTLE_ENDIAN,0) 
-fi
-if test $ac_cv_c_endian = little; then
-  AC_SUBST(LITTLE_ENDIAN,1) 
-fi
-])
-
-AC_C_ENDIAN
+AC_C_BIGENDIAN([AC_SUBST(LITTLE_ENDIAN,0)],[AC_SUBST(LITTLE_ENDIAN,1)])
  
 
 #==

Bug#934876: archmage: Please port to Python 3 (and drop python-chm dep)

[Sandro Tosi]

> Note that new version of archmage needs sgmllib3k — a port of sgmllib
> library
> from Python 2 stdlib dropped from Python 3.
>
> It's currently sitting in NEW.

then i guess i made a mistake uploading the new version of archmage :(

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#946773: memlockd FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: memlockd
Version: 1.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

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

Helmut
diff --minimal -Nru memlockd-1.2/debian/changelog 
memlockd-1.2+nmu1/debian/changelog
--- memlockd-1.2/debian/changelog   2016-12-14 03:55:24.0 +0100
+++ memlockd-1.2+nmu1/debian/changelog  2019-12-15 17:34:11.0 +0100
@@ -1,3 +1,10 @@
+memlockd (1.2+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 15 Dec 2019 17:34:11 +0100
+
 memlockd (1.2) unstable; urgency=low
 
   * debian/control: Add dh-systemd (>= 1.4) to Build-Depends - required to use
diff --minimal -Nru memlockd-1.2/debian/rules memlockd-1.2+nmu1/debian/rules
--- memlockd-1.2/debian/rules   2016-12-14 03:55:12.0 +0100
+++ memlockd-1.2+nmu1/debian/rules  2019-12-15 17:34:07.0 +0100
@@ -34,7 +34,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) CXXFLAGS=-O2
+   dh_auto_build -- CXXFLAGS=-O2
#docbook-to-man debian/memlockd.sgml > memlockd.1
 
touch $@

Bug#946772: gav FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: gav
Version: 0.9.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gav fails to cross build from source, because it does not pass any cross
tools to make. The easiest way of fixing that - using dh_auto_build -
mostly fixes that except for not supplying LD. That needs to be done
manually. Please consider applying the attached patch.

Helmut
diff -u gav-0.9.0/debian/control gav-0.9.0/debian/control
--- gav-0.9.0/debian/control
+++ gav-0.9.0/debian/control
@@ -2,7 +2,7 @@
 Section: games
 Priority: extra
 Maintainer: Ari Pollak 
-Build-Depends: debhelper (>> 5.0.0), libsdl1.2-dev, libsdl-mixer1.2-dev, 
libsdl-net1.2-dev, libsdl-image1.2-dev
+Build-Depends: debhelper (>= 7), libsdl1.2-dev, libsdl-mixer1.2-dev, 
libsdl-net1.2-dev, libsdl-image1.2-dev
 Standards-Version: 3.7.3
 Homepage: http://gav.sf.net
 
diff -u gav-0.9.0/debian/rules gav-0.9.0/debian/rules
--- gav-0.9.0/debian/rules
+++ gav-0.9.0/debian/rules
@@ -5,6 +5,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+include /usr/share/dpkg/buildtools.mk
+LD ?= ld
+
 CFLAGS = -Wall -g
 
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
@@ -27,7 +30,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   CFLAGS="$(CFLAGS)" CXXFLAGS="$(CFLAGS)" $(MAKE)
+   CFLAGS="$(CFLAGS)" CXXFLAGS="$(CFLAGS)" dh_auto_build -- LD=$(LD)
#/usr/bin/docbook-to-man debian/gav.sgml > gav.1
 
touch build-stamp
diff -u gav-0.9.0/debian/changelog gav-0.9.0/debian/changelog
--- gav-0.9.0/debian/changelog
+++ gav-0.9.0/debian/changelog
@@ -1,3 +1,12 @@
+gav (0.9.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ In addition, pass a LD supplied by dpkg's buildtools.mk.
+
+ -- Helmut Grohne   Sun, 15 Dec 2019 17:25:32 +0100
+
 gav (0.9.0-3) unstable; urgency=low
 
   * Include  to fix FTBFS with GCC 4.3 (Closes: #455172)

Bug#937145: nitime: Python2 removal in sid/bullseye

[Michael Crusoe]

A Python3 version of this package, also updated to the latest release, is
available at https://github.com/yarikoptic/nitime/pull/1 for sponsorship

Thanks