Bug#944551: lintian: missing-python-build-dependency false positive

[Chris Lamb]

Hi Thorsten,

> I suspect the check is flawed in that it checks for debian/rules
> lines matching /^\tpython/ (so it doesn’t trigger when the call
> is part of a pipeline; if so, the 0.1.7-2 version currently in the
> archive would also trigger this false positive) and mis-detects
> the py3k call as a call to python.

Actually, I believe Lintian is just not considering your python3-
minimal dependency has an adequate Python dependency.

I assume it works fine with that "minimal" version in your package,
but I'm a little hesitant to enlarge the allowed packages to include
these wwithout knowing more about the subtle differences between them
all...


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#944583: [SPAM] Re: Bug#944583: systemd: /etc/systemd/system.conf.d/* seems not to be used to override /etc/systemd/system.conf

[David Taillandier]

For example, if we want to disable CtrlAltDelBurstAction, we could do:
echo 'CtrlAltDelBurstAction=none' > 
/etc/systemd/system.conf.d/10-disable-ctraltdel-7times.conf
(or without .conf, same result)
But this has not effect.
Only a modification into /etc/systemd/system.conf is effective.

You probably miss the section (the "[Manager]" line in
/etc/systemd/system.conf).  Please try adding it to the drop-in file.



You are 100 % right.
I was digging into the source to understand what was wrong.
Many thanks to point it out.

Bug#944586: udev: after upgrading to version 243-5, udev blocks the removal of lvm2 snapshots

[Antonio]

Package: udev
Version: 243-5
Severity: normal

Dear Maintainer,
after updating systemd to version 243-5, my backup procedures, which
include the use of snapshots on lvm2 logical volumes, were blocked
during the snapshot removal phase.

> create snapshot: OK
lvcreate --size 1G -s -n prova  system/doc

> no other action

> remove snapshot
lvremove -fv system/prova
Archiving volume group "system" metadata (seqno 4031).
Removing snapshot volume system/prova.
Loading table for system-doc (251:7).
Loading table for system-prova (251:12).
Not monitoring system/prova with libdevmapper-event-lvm2snapshot.so
Unmonitored
LVM-zKZzKzFy3LSl0iVHcy7DY8oSb1b6eCOf319azVbo42LDvCA6Bf1eoK6FoYY5r89e
for events
Suspending system-doc (251:7) with device flush
Suspending system-prova (251:12) with device flush
Suspending system-doc-real (251:10) with device flush
Suspending system-prova-cow (251:11) with device flush
activation/volume_list configuration setting not defined: Checking
only host tags for system/prova.
Resuming system-prova-cow (251:11).
Resuming system-doc-real (251:10).
Resuming system-prova (251:12).
Removing system-prova-cow (251:11)
Resuming system-doc (251:7).
Removing system-doc-real (251:10)

> process is blocked
> now press ctrl-c for return in terminal

> but if I launch same command again:
 lvremove -fv system/prova
Removing system-prova (251:12)
Archiving volume group "system" metadata (seqno 4032).
Releasing logical volume "prova"
Creating volume group backup "/etc/lvm/backup/system" (seqno 4033).
  Logical volume "prova" successfully removed

> the internal actions are completed and the command then succeeds

> Reinstall stable or previous version solve the problem.
apt-get install udev=241-7~deb10u1 libudev1=241-7~deb10u1

# repeat test
lvcreate --size 1G -s -n prova  system/doc
  Logical volume "prova" created.
...
lvremove -fv system/prova
Archiving volume group "system" metadata (seqno 4035).
Removing snapshot volume system/prova.
Loading table for system-doc (251:7).
Loading table for system-prova (251:12).
Not monitoring system/prova with libdevmapper-event-lvm2snapshot.so
Unmonitored LVM-
zKZzKzFy3LSl0iVHcy7DY8oSb1b6eCOfO01gXwNkzP5AaYp6LZAx8b6nzUPILTAh for events
Suspending system-doc (251:7) with device flush
Suspending system-prova (251:12) with device flush
Suspending system-doc-real (251:10) with device flush
Suspending system-prova-cow (251:11) with device flush
activation/volume_list configuration setting not defined: Checking only
host tags for system/prova.
Resuming system-prova-cow (251:11).
Resuming system-doc-real (251:10).
Resuming system-prova (251:12).
Removing system-prova-cow (251:11)
Resuming system-doc (251:7).
Removing system-doc-real (251:10)
Removing system-prova (251:12)
Releasing logical volume "prova"
Creating volume group backup "/etc/lvm/backup/system" (seqno 4037).
  Logical volume "prova" successfully removed

> with the previous version everything was ok

Thanks,
Antonio


-- Package-specific info:

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

Kernel: Linux 5.3.10-custom (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1) (ignored:
LC_ALL set to it_IT), LANGUAGE=it (charmap=ISO-8859-1) (ignored:
LC_ALL set to it_IT)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages udev depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libacl1   2.2.53-5
ii  libblkid1 2.34-0.1
ii  libc6 2.29-3
ii  libkmod2  26-3
ii  libselinux1   2.9-2+b2
ii  libudev1  243-5
ii  systemd-sysv  243-5
ii  util-linux2.34-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  243-5

-- debconf information:
  udev/new_kernel_needed: false
  udev/title/upgrade:
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:

Bug#835565: mr list does not work

[Paul Wise]

Control: tags -1 unreproducible moreinfo

On Sat, 27 Aug 2016 09:31:48 +0200 Marc Haber wrote:

> mr list only prints empty lines for git repos:

I'm unable to reproduce this with the current version of myrepos and
with version 1.20160123 from git.

Please try to reproduce it with both versions and provide more info.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#943752: Needs GCC-6

[Philipp Marek]

A further information I received via IRC is that memtest86+
_has_ to be compiled with GCC-6 - newer versions have a bug
that break memtest86+.

I have verified that GCC-6 gives a working result,
while GCC-8 doesn't.


So, basically,

-CC?=gcc
+CC:=gcc-6

in the Makefile.

Bug#828761: hours_since should not update flag file after an error

[Paul Wise]

On Mon, 27 Jun 2016 16:46:03 +0200 Marc Haber wrote:

> The flag should not be touched if there was an error so that one can
> immediately retry the operation.

There doesn't appear to be any way to fix this, because the skip
command that runs hours_since which touches the flag file runs before
the update commands.

You can immediately retry the operation using the force option, which
will ignore the skip command where the hours_since flag was run.

   $ mr --force update

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#944585: gimp: Unable to upgrade

[Nicolas Patrois]

Package: gimp
Version: 2.10.12-1
Severity: normal

Dear Maintainer,

The gimp package is broken, I can’t upgrade it from 2.10.12-1 to 2.10.14.
The new package depends on gimp-data⩾2.10.14 but 2.10.12-1 is installed and the
new version of gimp-data is not available.
aptitude gives me two solution:
* Either keep gimp and libgimp2.0 in 2.10.12-2;
* Or remove seven gimp packages, including gimp but not libgimp2.0.



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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.12-1
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-01:0.1.72-dmo1
ii  libbz2-1.0   1.0.8-2
ii  libc62.29-3
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgcc1  1:9.2.1-19
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libgegl-0.4-01:0.4.18-dmo1
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.12-1
ii  libglib2.0-0 2.62.2-3
ii  libgs9   9.50~dfsg-2
ii  libgtk2.0-0  2.24.32-4
ii  libgudev-1.0-0   233-1
ii  libharfbuzz0b2.6.4-1
ii  libheif1 1.6.0-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-4
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1:1.3.0-dmo7
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.1-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-6
ii  librsvg2-2   2.44.15-1
ii  libstdc++6   9.2.1-19
ii  libtiff5 4.1.0-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-15
ii  libx11-6 2:1.6.8-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.50~dfsg-2

Versions of packages gimp suggests:
ii  gimp-data-extras  1:2.0.2-1
ii  gimp-help-ca [gimp-help]  2.8.2-1
ii  gimp-help-de [gimp-help]  2.8.2-1
ii  gimp-help-el [gimp-help]  2.8.2-1
ii  gimp-help-en [gimp-help]  2.8.2-1
ii  gimp-help-es [gimp-help]  2.8.2-1
ii  gimp-help-fr [gimp-help]  2.8.2-1
ii  gimp-help-it [gimp-help]  2.8.2-1
ii  gimp-help-nl [gimp-help]  2.8.2-1
ii  gimp-help-pt [gimp-help]  2.8.2-1
ii  gimp-help-ru [gimp-help]  2.8.2-1
ii  gimp-help-sv [gimp-help]  2.8.2-1
ii  gvfs-backends 1.42.1-3
ii  libasound21.1.9-1

-- no debconf information

Bug#944565: O: ldm -- LTSP display manager

[Jonathan Carter]

On 2019/11/12 00:29, Vagrant Cascadian wrote:
> Newer versions of LTSP no longer make use of LDM; it is no longer
> maintained upstream.

In my opinion, ltspfs, ldm-themes and ldm won't be of particular use of
anyone. Any objections if I file for them to be removed from the archive
instead?

-Jonathan

Bug#944583: systemd: /etc/systemd/system.conf.d/* seems not to be used to override /etc/systemd/system.conf

[Ansgar]

David Taillandier writes:
> For example, if we want to disable CtrlAltDelBurstAction, we could do:
> echo 'CtrlAltDelBurstAction=none' > 
> /etc/systemd/system.conf.d/10-disable-ctraltdel-7times.conf
> (or without .conf, same result)
> But this has not effect.
> Only a modification into /etc/systemd/system.conf is effective.

You probably miss the section (the "[Manager]" line in
/etc/systemd/system.conf).  Please try adding it to the drop-in file.

Ansgar

Bug#944574: w3m-download-this-url vs. zero byte file:///s

[Katsumi Yamaoka]

On Tue, 12 Nov 2019 09:39:11 +0800, 積丹尼さん wrote:
> X-Debbugs-Cc: yama...@jpl.org
> Package: w3m-el-snapshot
> Version: 1.4.632+0.20190920.1116.c9cdb7e-1
> Severity: wishlist

> If I try to download a zero byte local file,
> file:///tmp/somezerobytefile I get a failure.

> It works if the file has at least one byte.

> But it really should, yes, work with zero byte empty files.

Fixed in emacs-w3m git master.  Thanks.

Bug#943899: Should ndisgtk be removed?

[Julian Andres Klode]

Moritz Mühlenhoff  schrieb am Mo., 11. Nov. 2019, 23:48:

> On Thu, Oct 31, 2019 at 04:23:18PM +0100, Moritz Muehlenhoff wrote:
> > Package: ndisgtk
> > Severity: serious
> >
> > Should ndisgtk be removed?
> >
> > It's dead upstream (no release for 10 years) and depends on outdated
> stacks scheduled for removal
> > (python 2, pygtk).
>
> I've filed a removal bug now.
>

Don't you have anything better to do? This bug removes it from testing
which is fine, but complete removal two weeks later, while I'm sitting here
with broken bones unable to fix anything is a no-go...

A GTK+3 Version exists, but the formatting is all messed up, which is why
it basically needs to be completely reconstructed.

I'm not sure it's worth the effort but I'd like that to be my decision not
yours.

Bug#943832: FYI from my work on this in Ubuntu

[Christian Ehrhardt]

Hi,
I took a look at the same in Ubuntu [1] and wanted to let you know
about it to avoid falling into the same pitfalls I did.

First of all we all migrated to postgresql-12, which also made this an
FTBFS (at least in my checks). This means we need asyncpg 0.19 [2]
which I prepared in a branch, but things were not so easy.

That in turn fails due to upstream separating pgproto.
This might eventually be a package of its own, but for now in my
experiments I left it as a patch [4] to follow you on whatever you
decide to do about it eventually (if I'D break a new package in Ubuntu
now there will be all kinds of transition conflicts).

With the above the build passes the pgproto issue but will now hit
incompatibility with python3.8 and maybe the new cython. I filed an
upstream issue [5], but the answer there for now is just "Python 3.8
is not supported yet.".
An example of a build log with that can be seen on [6].

So the state this leaves us for now is being old-src:
FTBFS+autopkgtest-fails, new-src: FTBFS, and upstream lacking python
3.8 support. I even considered if this is worth a removal already to
come back later when it is clean, but would leave entirely up to you.

I have provided MRs for 0.19 [7][8][9], but as outlined above they
won't work until py3.8/cython compatibility was added - so they are
just a little help on the way, but not the solution :-/

[1]: https://bugs.launchpad.net/debian/+source/asyncpg/+bug/1850136
[2]: https://github.com/MagicStack/asyncpg/releases
[3]: https://github.com/MagicStack/py-pgproto
[4]: 
https://salsa.debian.org/paelzer-guest/asyncpg/commit/d98c36ef5fb287dbc9c986875efc752864c5530e
[5]: https://github.com/MagicStack/asyncpg/issues/501
[6]: http://paste.ubuntu.com/p/VRntTFgrs7/
[7]: https://salsa.debian.org/python-team/modules/asyncpg/merge_requests/2
[8]: https://salsa.debian.org/python-team/modules/asyncpg/merge_requests/3
[9]: https://salsa.debian.org/python-team/modules/asyncpg/merge_requests/4

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#944579: Further Information

[Joachim Geiger]

Dear maintainers,
I recompiled the sources of plplot-5.14.0 taken from sourceforge. I ran 
the tests, i.e. I built it with "cmake -DBUILD_TEST=ON 
~/Downloads/plplot-5.14.0", with ctest and tested the fortran example 
x01f (I am interested in the fortran interface) with the 
wxwidgets-driver and it ran without problems, no complain.

I hope this helps to locate the bug.
Best regards,
Joachim Geiger

Bug#944583: systemd: /etc/systemd/system.conf.d/* seems not to be used to override /etc/systemd/system.conf

[David Taillandier]

Package: systemd
Version: 241-7~deb10u1
Severity: normal



-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-7~deb10u1
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-7~deb10u1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133+deb10u1
ii  udev 241-7~deb10u1

-- Configuration Files:
/etc/systemd/system.conf changed [not included]

-- no debconf information

-- comments
For example, if we want to disable CtrlAltDelBurstAction, we could do:
echo 'CtrlAltDelBurstAction=none' > 
/etc/systemd/system.conf.d/10-disable-ctraltdel-7times.conf
(or without .conf, same result)
But this has not effect.
Only a modification into /etc/systemd/system.conf is effective.

Bug#296493: Investment Proposal

[Nael M. Al Homoud]

Good day,

My associate from China wants to discuss a business investment deal with
you. I awaiting your response to enable us discuss about this business
investment

Nael M. Al Homoud
Executive Director & High Investment Committee Member@
The Arab Investment Co
www.taic.com [1]

  

Links:
--
[1] http://www.taic.com

Bug#517984: Investment Proposal

[Nael M. Al Homoud]

Good day,

My associate from China wants to discuss a business investment deal with
you. I awaiting your response to enable us discuss about this business
investment

Nael M. Al Homoud
Executive Director & High Investment Committee Member@
The Arab Investment Co
www.taic.com [1]

  

Links:
--
[1] http://www.taic.com

Bug#944582: python3 -c 'import paraview.simple' fails

[Matthias Klose]

Package: paraview-python
Version: 5.7.0-1
Severity: serious
Tags: sid bullseye

Taken from the autopkg test:

$ python3 -c 'import paraview.simple'
Error: Could not import vtkCommonComputationalGeometry
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/paraview/simple.py", line 41, in 
from paraview import servermanager
  File "/usr/lib/python3/dist-packages/paraview/servermanager.py", line 53, in 


from paraview import vtk
  File "/usr/lib/python3/dist-packages/paraview/vtk.py", line 32, in 
all_spec.loader.exec_module(all_m)
  File "/usr/lib/python3/dist-packages/paraview/pv-vtk-all.py", line 7, in 

from vtkmodules.vtkCommonCore import *
ModuleNotFoundError: No module named 'vtkmodules'

Bug#944399: Build-Script

[Stefan Rücker]

I had to adjust the script to be able to build it.

Find attached the current version of the script.

I changed the path to
~/android/source
I tried before initializing a new aosp source tree from scratch in 
~/android/source-test but had not enough space, so I had to reuse my 
main android tree.


The sources and build uses quite some space:
stefan@mars:~/android/source$ du -hs .
258G    .

ccache stats after initial build (ccache was cleared before):
stefan@mars:~/android/source$ ccache -s
cache directory /home/stefan/.ccache
primary config  /home/stefan/.ccache/ccache.conf
secondary config  (readonly)    /etc/ccache.conf
stats updated   Tue Nov 12 06:29:41 2019
stats zeroed    Sat Nov  9 00:52:50 2019
cache hit (direct)   194
cache hit (preprocessed)    5523
cache miss 28697
cache hit rate 16.61 %
called for link    1
called for preprocessing  26
unsupported code directive 1
cleanups performed 0
files in cache 90898
cache size  13.6 GB
max cache size  53.7 GB

Building it on a 4 core machine (Intel(R) Core(TM) i5-6300HQ CPU @ 
2.30GHz) takes 02:24:20.


The error was reproducible with the stripped down build-script. I will 
provide as well the full stdout/stderr output of the build script.


Kind regards,
Stefan


build-4.14-ccache.sh
Description: application/shellscript

Bug#944580: libprelude FTBFS due to new gawk version

[Helmut Grohne]

Source: libprelude
Version: 4.1.0-4.2
Severity: serious
Tags: ftbfs

libprelude recently started to FTBFS in unstable.

E.g. local sbuild:
| LANG="" gawk -f ./mkheader.awk \
| ./err-sources.h.in \
| ./err-codes.h.in \
| ./errnos.in \
| ./prelude-error.h.in > prelude-error.h
| gawk: ./mkstrtable.awk:113: warning: regexp escape sequence `\#' is not a 
known regexp operator
| gawk: ./mkstrtable.awk:113: warning: regexp escape sequence `\#' is not a 
known regexp operator
| gawk: gawk: ./mkerrcodes1.awk:81: warning: regexp escape sequence `\#' is not 
a known regexp operator
| fatal: cannot use gawk builtin `namespace' as variable name
| gawk: gawk: ./mkstrtable.awk:./mkerrnos.awk:113: 83: warning: warning: regexp 
escape sequence `\#' is not a known regexp operatorregexp escape sequence `\#' 
is not a known regexp operator
| 
| gawk: ./mkstrtable.awk:113: warning: regexp escape sequence `\#' is not a 
known regexp operator
| make[6]: *** [Makefile:1845: errnos-sym.h] Error 2
| make[6]: *** Waiting for unfinished jobs
| gcc -E -P _mkerrcodes.h | grep PRELUDE_ERROR_ | LANG="" gawk -f 
./mkerrcodes.awk >mkerrcodes.h
| gawk: ./mkheader.awk:85: warning: regexp escape sequence `\#' is not a known 
regexp operator
| gawk: ./mkerrcodes.awk:81: warning: regexp escape sequence `\#' is not a 
known regexp operator
| rm _mkerrcodes.h
| make[6]: Leaving directory '/<>/src/libprelude-error'
| make[5]: *** [Makefile:1829: all-recursive] Error 1
| make[5]: Leaving directory '/<>/src'
| make[4]: *** [Makefile:1633: all] Error 2
| make[4]: Leaving directory '/<>/src'
| make[3]: *** [Makefile:1658: all-recursive] Error 1
| make[3]: Leaving directory '/<>'
| make[2]: *** [Makefile:1524: all] Error 2
| make[2]: Leaving directory '/<>'
| dh_auto_build: make -j8 returned exit code 2
| make[1]: *** [debian/rules:40: build-core] Error 255
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:64: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Also reproduced by reproducible builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libprelude_4.1.0-4.2.rbuild.log.gz

Likely this is related to the recent gawk upload that also makes other
packages ftbfs (e.g. libgpg-error #944511). Adrian Bunk Cced.

Helmut

Bug#774274: fontforge: please use SOURCE_DATE_EPOCH for

[Hideki Yamane]

control: fixed -1 1:20190801~dfsg-1

On Tue, 12 Nov 2019 12:33:54 +0700
Theppitak Karoonboonyanan  wrote:
> So, all differences are clear to me now. :-)

 Sounds good :)
 Thanks for your detailed reply!

-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#944581: linux-image-4.19.0-6-amd64: unable to suspend machine due to instability of kernel module intel driver e1000e (e1000e 0000:00:19.0 enp0s25: Hardware Error/e1000e 0000:00:19.0 enp0s25: remo

[Pierre-Loic]

Package: src:linux
Version: 4.19.67-2+deb10u1
Severity: normal

Dear Maintainer,

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

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

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


-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64 
root=UUID=8632816c-9baf-4779-8251-441cdad992b6 ro quiet splash

** Not tainted

** Kernel log:
[409286.986431] wlp3s0: associate with 1c:24:cd:24:d5:f9 (try 1/3)
[409286.987424] wlp3s0: RX AssocResp from 1c:24:cd:24:d5:f9 (capab=0x1011 
status=0 aid=3)
[409286.988906] wlp3s0: associated
[409287.010185] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
[409287.021466] wlp3s0: Limiting TX power to 24 (24 - 0) dBm as advertised by 
1c:24:cd:24:d5:f9
[409316.577942] e1000e :00:19.0 enp0s25: removed PHC
[409317.072497] e1000e :00:19.0 enp0s25: Hardware Error
[409317.312123] e1000e: enp0s25 NIC Link is Down
[409323.721832] PM: suspend entry (deep)
[409323.721834] PM: Syncing filesystems ... done.
[409323.838785] (NULL device *): firmware: direct-loading firmware 
iwlwifi-7260-17.ucode
[409323.838798] Freezing user space processes ... (elapsed 0.000 seconds) done.
[409323.839773] OOM killer disabled.
[409323.839774] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[409323.840949] Suspending console(s) (use no_console_suspend to debug)
[409323.971516] wlp3s0: deauthenticating from 1c:24:cd:24:d5:f9 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[409323.987854] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[409323.988121] sd 0:0:0:0: [sda] Stopping disk
[409324.484664] ACPI: EC: interrupt blocked
[409324.524314] ACPI: Preparing to enter system sleep state S3
[409324.527350] ACPI: EC: event blocked
[409324.527351] ACPI: EC: EC stopped
[409324.527352] PM: Saving platform NVS memory
[409324.527393] Disabling non-boot CPUs ...
[409324.541245] smpboot: CPU 1 is now offline
[409324.561629] smpboot: CPU 2 is now offline
[409324.593042] smpboot: CPU 3 is now offline
[409324.598873] ACPI: Low-level resume complete
[409324.598917] ACPI: EC: EC started
[409324.598918] PM: Restoring platform NVS memory
[409324.601417] Enabling non-boot CPUs ...
[409324.601453] x86: Booting SMP configuration:
[409324.601453] smpboot: Booting Node 0 Processor 1 APIC 0x1
[409324.601885]  cache: parent cpu1 should not be sleeping
[409324.602179] CPU1 is up
[409324.602201] smpboot: Booting Node 0 Processor 2 APIC 0x2
[409324.603893]  cache: parent cpu2 should not be sleeping
[409324.604065] CPU2 is up
[409324.604083] smpboot: Booting Node 0 Processor 3 APIC 0x3
[409324.604482]  cache: parent cpu3 should not be sleeping
[409324.604862] CPU3 is up
[409324.613890] ACPI: Waking up from system sleep state S3
[409324.619385] ACPI: EC: interrupt unblocked
[409324.670324] usb usb1: root hub lost power or was reset
[409324.670328] usb usb2: root hub lost power or was reset
[409324.670707] ACPI: EC: event unblocked
[409324.671772] sd 0:0:0:0: [sda] Starting disk
[409324.917591] usb 3-1: reset high-speed USB device number 2 using ehci-pci
[409325.013551] usb 1-8: reset high-speed USB device number 3 using xhci_hcd
[409325.373607] usb 3-1.5: reset full-speed USB device number 3 using ehci-pci
[409325.494977] acpi LNXPOWER:02: Turning OFF
[409325.495414] OOM killer enabled.
[409325.495416] Restarting tasks ... done.
[409325.522316] PM: suspend exit
[409325.628076] wlp3s0: authenticate with 1c:24:cd:24:d5:f0
[409325.633213] wlp3s0: send auth to 1c:24:cd:24:d5:f0 (try 1/3)
[409325.636492] wlp3s0: authenticated
[409325.637467] wlp3s0: associate with 1c:24:cd:24:d5:f0 (try 1/3)
[409325.644033] wlp3s0: RX AssocResp from 1c:24:cd:24:d5:f0 (capab=0x1411 
status=0 aid=4)
[409325.654390] wlp3s0: associated
[409325.711937] wlp3s0: Limiting TX power to 20 (20 - 0) dBm as advertised by 
1c:24:cd:24:d5:f0
[409326.425483] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[409326.426839] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[409326.426846] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[409326.426851] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[409326.429458] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[409326.429476] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[409326.429487] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[409326.430482] ata1.00: configured for UDMA/133
[409326.565591] wlp3s0: deauthenticating from 1c:24:cd:24:d5:f0 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[409326.692498] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not 

Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown

[Marc Lehmann]

Hi!

All information asked for was either already provided (you even quote the
text where it was provided!) or is entirely unnecessary to investigate
this problem. I have tried to duplicate the information in a different
form below, in case there was a comprehension issue. If you still think
some information is missing you would need to more clearly explain what
you think is missing, and I'd be happy to provide it.

On Tue, Nov 12, 2019 at 12:55:42AM +0100, Michael Biebl  
wrote:
> > To accomplish this I have an initramfs-tools script that runs it something
> >
> >   exec -a @ntfs-3g-root ntfs-3g ...
> 
> Would be great if you can share this script so we can see what exactly
> it is doing.

Uhm, what other information could potentially be of use? Nothing else
in the script is of any relevance, other than starting a daemon with
@ as first character of its name. The arguments do not do anything to
change the name, and that's essentially the only other thing that the
script does. The only relevant information is that systemd has special
(but buggy) code for processes whose names start with '@' - nothing else
matters, as systemd clearly doesn't check for anything else, as you can
see in the code - just grep for the log_notice I provided (I don't have
easy access to it righ now, otherwise I woudl do it for you).

> > The @ prevents systemd-shutdown from killing it, which works. However, it
> > outputs the following warning (lifted from the code, can't copy from
> > the real system):
> > 
> > log_notice("Process " PID_FMT " (%s) has been marked to be 
> > excluded from killing. It is "
> >"running from the root file system, and thus 
> > likely to block re-mounting of the "
> >"root file system to read-only. Please consider 
> > moving it into an initrd file "
> >"system instead.", pid, strna(comm));
> > 
> > Since it is running from the initramfs, this warning is bogus (and indeed,
> > the root fs can be mounted ro with no problem), suggesting that the check
> > systemd-shutdown uses to detect this case is broken.
> > 
> > For additional reference, /proc//root has a target of "/",
> > which probably causes this. /proc//exe has a target of
> > '/usr/bin/ntfs-3g (deleted)', which makes sense as it was deleted when
> > cleaning up the initramfs before handing over to the actual root fs.
> 
> Please supply the information that was requested by upstream:

The information is right in the paragraph you just quoted - root points to
"/" and exe points to "/usr/bin/ntfs-3g (deleted)".

> have a magic effect, and point to something potentially different than
> their literal value. Hence, can you do stat on those two magic symlinks
> to see what they actually point to?

stat can't show you what they "actually" point to, but since the command
was started using initramfs (as also already mentioned), / obviously
points to the root of the initramfs, and the ntfs-3g dxecutable in there
has been deleted when it was cleaned up during boot, unless you want to
assume a kernel bug.

What _stat_ can tell you is that "root" points to a different filesystem
(the tmpfs used by the kernel) than the current root filesystem that is
supposedly blocked.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#774274: fontforge: please use SOURCE_DATE_EPOCH for

[Theppitak Karoonboonyanan]

On Tue, Nov 12, 2019 at 11:58 AM Theppitak Karoonboonyanan
 wrote:

> By dumping TTX with 'ttx' command from fonttools,
> the differences appear to be:
>   1) the "checkSumAdjustment" in 
>   2) the "flags" in : "0010 0001" -> " 0001"
>   3) the "fontDirectionHint" in : "0" -> "2"
>   4) the "underlinePosition" in : "-204" -> "-102"
>   5) the "FFTimeStamp" in  (this seems to be fontforge build timestamp)
> I doubt how 2), 3), 4) are changed across different fontforge versions.

Note: By checking OpenType/TrueType documentations [1] [2]:
* 2) is to clear bit 15 as the spec suggests (bits 6-10 are unused)
* 3) is to set direction hint properly (left to right, with some
zero-width glyphs)
* 4) is to fix fontforge underline position handling [3]

[1] https://docs.microsoft.com/en-us/typography/opentype/spec/otff#font-tables
[2] https://developer.apple.com/fonts/TrueType-Reference-Manual/
[3] https://fontforge.org/en-US/bulletins/underline_position_2018_1/

So, all differences are clear to me now. :-)

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#623334: mr: git checkout checks out into wrong directory

[Paul Wise]

On Tue, 19 Apr 2011 20:42:57 +0200 Richard Hartmann wrote:

> Given that I am forced to specify a path anyway, the checkout should
> obviously end up in work/git/ikiwiki . While shooting myself in the
> foot by providing a different checkout path is of course my
> privilege, but mr should default to doing the correct thing.

I think that since `mr register` outputs the correct command but that
the command you have written is broken, there is not much to do here.
 
> Would it be acceptable to introduce a new config option like
> 
>   source = git+ssh://repo.or.cz/srv/git/foo
> 
> that way, mr could Dot The Right Thing by default while still allowing
> 'checkout' to do whatever the user wants it to.

I'm leaning towards not having this, it feels like extra complexity and
reduced flexibility.

Perhaps mr could instead have a mode that checks the current value of
checkout for the repo with the one `mr register` would output for the
repo as it is now.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#774274: fontforge: please use SOURCE_DATE_EPOCH for

[Theppitak Karoonboonyanan]

On Sun, Nov 10, 2019 at 11:54 PM Hideki Yamane  wrote:
> On Sat, 21 Sep 2019 12:35:07 +0700 Theppitak Karoonboonyanan 
>  wrote:
> > However, as there have already been three 2019 releases (March, April, 
> > August),
> > updating from official release could be another choice.
>
>  Could you try to check it with new fontforge package in experimental?

In short, it make my package build reproducibly.

In detail, I have tried 4 builds, the first two with unstable version,
and the next two with the experimental version, then compared
the binaries.

* Type1 LaTeX deb (the one in question):

The first 3 builds all differ, while the last 2 builds are identical,
which is what we desire: the experimental version makes
the previously unreproducible build reproducible.

* TTF deb (previously reproducible):

The first 2 builds yield identical binaries,
and the last 2 builds also yield identical binaries,
but the binaries between the two sets differ.
That means the build is still reproducible with
the same fontforge version, but not with different versions.

By dumping TTX with 'ttx' command from fonttools,
the differences appear to be:
  1) the "checkSumAdjustment" in 
  2) the "flags" in : "0010 0001" -> " 0001"
  3) the "fontDirectionHint" in : "0" -> "2"
  4) the "underlinePosition" in : "-204" -> "-102"
  5) the "FFTimeStamp" in  (this seems to be fontforge build timestamp)
I doubt how 2), 3), 4) are changed across different fontforge versions.
But that's probably not in the scope of this bug, provided that
the build is still repoducible within the same fontforge version.

So, I think this bug could be closed now.
Thanks for your work!

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#944519: w3m-download-this-url gives -dump_extra: command not found

[Katsumi Yamaoka]

On Tue, 12 Nov 2019 10:52:58 +0800, 積丹尼さん wrote:
> Great! I'll trust you.

Thanks.  Finally I've installed only this change in emacs-w3m git.
diff --git a/w3m.el b/w3m.el
index e25ef940..4653589f 100644
--- a/w3m.el
+++ b/w3m.el
@@ -5829,7 +5829,7 @@ NO-CACHE is ignored (always download)."
   (w3m-goto-ftp-url url filename)
 (let ((args (concat (mapconcat
 			 #'(lambda (x) (replace-regexp-in-string
-	"\\([\t ]\\)" "\\1" x))
+	"\\([\t ;]\\)" "\\1" x))
 			 `(,w3m-command
 			   ,@w3m-command-arguments
 			   ,@(w3m-w3m-expand-arguments

Bug#944579: libplplotwxwidgets1: wxwidgets does not work, wxPLViewer is missing

[Joachim Geiger]

Package: libplplotwxwidgets1
Version: 5.14.0+dfsg-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation? Tried to use the wxwidgets-driver.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Selected the driver number/driver name
   * What was the outcome of this action? The error message "sh: 1: wxPLViewer:
not found"
   * What outcome did you expect instead? A window popping up to show the
plots.

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



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=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 libplplotwxwidgets1 depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libplplot16   5.14.0+dfsg-3
ii  libplplotcxx145.14.0+dfsg-3
ii  libstdc++68.3.0-6
ii  libwxbase3.0-0v5  3.0.4+dfsg-8
ii  libwxgtk3.0-0v5   3.0.4+dfsg-8

Versions of packages libplplotwxwidgets1 recommends:
ii  plplot-driver-wxwidgets  5.14.0+dfsg-3

libplplotwxwidgets1 suggests no packages.

-- no debconf information

Bug#944575: calibre cannot find libGLX_mesa.so.0 and fails to launch

[Norbert Preining]

severity 944575 normal
tag 944575 + unreproducible
thanks

Hi

On Mon, 11 Nov 2019, James Van Zandt wrote:
> strace shows it's looking for /lib/libGLX_indirect.so.0 in four places:

I don't have GLX_indirect installed at all, so I don't think this is
really necessary.

Could it be that you have played around with the OpenGL setup (libraries
libGL etc) on your system?

ldd-ing the plugins in /usr/lib/calibre/calibre/plugins/ shows
dependencies on libGL doesn't show up andy _indirect stuff here:

$ ldd * | grep GL
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7f7fe47df000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 
(0x7f7fe3fe5000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 
(0x7f7fe3f28000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7fd9b73b2000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 
(0x7fd9b6b9b000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 
(0x7fd9b6ade000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7f6295641000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 
(0x7f6294e47000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 
(0x7f6294d8a000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7f19ce18)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 
(0x7f19cd986000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 
(0x7f19cd8c9000)
$

Norbert

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

Bug#944571: mmdebstrap: the license is not the actual Expat license

[Johannes Schauer]

Hi,

Quoting Francesco Poli (wintermute) (2019-11-12 00:03:52)
> I've just noticed that the mmdebstrap package [claims] to be released
> under the terms of the Expat license, but this is not really the
> case, since the license text (in both the debian/copyright file
> and the upstream source code) lacks an important part, namely
> the disclaimer of warranty and limitation of liability (the part
> in upper case)!
> Please compare with the canonical [Expat] license text.
> 
> [claims]: 
> 
> [Expat]: 
> 
> The disclaimer of warranty and limitation of liability are important
> (above all, they protect the authors and copyright holders): I would
> strongly recommend adding them as soon as possible, thus effectively
> changing the license of mmdebstrap (this can be easily done, as long
> as there's only one copyright holder).

the warranty part does not change any of the terms under which the software can
be used or distributed. Thus I don't think it would need coordination with any
copyright holder.

Furthermore, the Expat License clearly states:

> The above copyright notice and this permission notice shall be included in
> all copies or substantial portions of the Software.

Indeed the *above* notice was kept intact. The expat license says nothing about
keeping the text intact that follows, namely the warranty part.

Lastly, the warranty part is not required at all in my jurisdiction. Are there
important jurisdictions where the Debian project as a whole cares that it is
needed?

If the Debian project cares about the disclaimer of warranty, then it can just
easily be added into debian/copyright so that all recipients of the software
via Debian receive it together with the disclaimer. As I explained above, I
don't think that this requires a change of the upstream license.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#900787: nvidia-graphics-drivers-legacy-304xx: does not support Xorg Xserver 1.20

[Andreas Beckmann]

On 10/11/2019 22.46, Pierre Bernhardt wrote:
> Is it not really possible to use xserver version
> 1.20 for this driver or must I downgrade xserver
> to 1.19?

Xserver support can only be fixed by NVIDIA, and they declared this
legacy driver end-of-life several years ago.


Andreas

Bug#944578: live-task-recommended: include hw-probe package

[Paul Wise]

Package: live-task-recommended
Severity: wishlist
X-Debbugs-CC: hw-pr...@packages.debian.org

Please include the hw-probe package on the Debian live images. This
package allows users to contribute info about their hardware to the
Linux hardware database. Since Debian live images are often used to
test if hardware works with Debian, it would be a good idea to give
testers to option to share their test results with other Linux users.

https://linux-hardware.org/
https://packages.debian.org/sid/hw-probe
https://wiki.debian.org/Hardware/Database

-- 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 4.19.0-5-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.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages live-task-recommended depends on:
ii  task-english  3.53
ii  task-laptop   3.53

Versions of packages live-task-recommended recommends:
ii  dbus 1.12.16-1
ii  dkms 2.7.1-2
ii  file 1:5.37-5
ii  firmware-linux-free  3.4
ii  haveged  1.9.1-8
ii  iputils-ping 3:20180629-2
ii  less 487-0.1+b1
ii  lsof 4.91+dfsg-1+b1
pn  netutils 
ii  openssh-client   1:8.0p1-4
ii  time 1.7-25.1+b1

live-task-recommended suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#944519: w3m-download-this-url gives -dump_extra: command not found

[積丹尼 Dan Jacobson]

Great! I'll trust you.

Bug#944519: w3m-download-this-url gives -dump_extra: command not found

[Katsumi Yamaoka]

On Tue, 12 Nov 2019 09:53:13 +0800, 積丹尼さん wrote:
> "But I don't even have a ~/bin".
> Anyway, the problem turns out to be in
> ~/.w3m/config . But which line?

> accept_language en;q=1.0

That is it!  I see that the ";" in the operand causes a malfunction
of w3m-download.  Could you try this patch?
--- w3m.el~	2019-11-11 06:37:28.350304300 +
+++ w3m.el	2019-11-12 02:41:33.719297300 +
@@ -834,8 +834,9 @@
 	(insert-file-contents file)
 	(goto-char (point-min))
 	(when (re-search-forward "^accept_language[\t ]+\\(.+\\)$" nil t)
-	  (delete "" (split-string (match-string 1)
-   "[ \t\r\f\n]*,[ \t\r\f\n]*")
+	  (delete "" (split-string
+			  (replace-regexp-in-string ";.*" "" (match-string 1))
+			  "[ \t\r\f\n]*,[ \t\r\f\n]*")
 	(when (string= w3m-language "Japanese")
 	  '("ja" "en"
   "List of acceptable languages in descending order of priority.

Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

[Ben Hutchings]

On Mon, 2019-11-11 at 21:37 +, Sudip Mukherjee wrote:
> Hi Ben,
> 
> On Sun, Nov 10, 2019 at 10:01 PM Ben Hutchings  wrote:
> > On Sun, 2019-11-10 at 21:29 +, Sudip Mukherjee wrote:
> > > On Fri, Nov 08, 2019 at 07:56:55PM +, Ben Hutchings wrote:
> > > > On Mon, 2019-11-04 at 21:44 +, Sudip Mukherjee wrote:
> > > > [...]
> > > > > The code for libtracevent lives in the kernel tree at
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in 
> > > > > tools/lib/traceevent folder.
> > > > > And so, it will be great if kernel team will like to package and 
> > > > > maintain it, if not, then I will
> > > > > be happy to do it. But, if I am doing it then I will need a sponsor 
> > > > > to upload it.
> > > > 
> > > > If kernel.org's kernel source repository is the canonical location for
> > > > this code, not just a convenience copy, then the binary package should
> > > > be built from src:linux and not a separate source package.
> > > > 
> > > > I think src:linux already builds the library, but only as a static
> > > > library that's linked into perf.
> > > > 
> > > > I don't know exactly what changes you would need to make, but they
> > > > should be roughly along these lines:
> > > > 
> > > 
> > > > 4. Generate the debian/libtraceevent.symbols file recording
> > > >the shared library's exported symbols.
> > > 
> > > Thanks for your reply Ben.
> > > I will try these steps and see how it goes.
> > > 
> > > > 5. (Not sure if this is needed.)  Modify
> > > >debian/rules.d/tools/perf/Makefile to make perf use the shared
> > > >library.  Add libtraceevent to the dependencies of
> > > >linux-perf- in debian/templates/control.tools-versioned.in.
> > > 
> > > This should not be needed as perf does not yet depend on libtraceevent.
> > > The libtraceevent that perf is creating is only having the plugins.
> > 
> > I'm pretty sure it does; look for "libtraceevent.a" in
> > ;.
> 
> iiuc, perf used tools/lib/traceevent to generate "libtraceevent.a"
> which is a static library and perf is building against that. It is
> also using the plugins generated by traceevent. But it is not using
> "libtraceevent.so" which is generated.
[...]

Yes, exactly.  And it is usual practice in Debian to link with shared
libraries where possible.  (I thought that was actually in policy, but
it doesn't seem to be.)

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.




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

Bug#944577: RM: colorclass -- ROM; low-popcon leaf package

[Carl Suster]

Package: ftp.debian.org
Severity: normal

This is a leaf package with few users that was added as a dependency for
a now-abandoned ITP. I advertised for new uploaders and put up an RFA (#929658)
but there has been no interest.

Bug#157299: Investment Proposal

[Nael M. Al Homoud]

Good day,

My associate from China wants to discuss a business investment deal with
you. I awaiting your response to enable us discuss about this business
investment

Nael M. Al Homoud
Executive Director & High Investment Committee Member@
The Arab Investment Co
www.taic.com [1]

  

Links:
--
[1] http://www.taic.com

Bug#944576: RM: python-pynzb -- ROM; unmaintained

[Carl Suster]

Package: ftp.debian.org
Severity: normal

This is a leaf package that is unmaintained upstream for >10 years.
I advertised for new uploaders and put up an RFA (#929670) but there has been
no interest.

Bug#944519: w3m-download-this-url gives -dump_extra: command not found

[積丹尼 Dan Jacobson]

"But I don't even have a ~/bin".
Anyway, the problem turns out to be in
~/.w3m/config . But which line?

accept_encoding gzip, compress, bzip, bzip2, deflate
accept_language en;q=1.0
accept_media text/html, text/*;q=0.5, image/*, application/*, video/*, audio/*, 
zz-application/*
auto_detect 2
auto_image 1
auto_uncompress 0
clear_buffer 1
close_tab_back 0
color 0
confirm_qq 0
decode_cte 0
decode_url 0
dictcommand file:///$LIB/w3mdict.cgi
disable_secret_security_check 0
display_charset UTF-8
display_ins_del 1
display_lineinfo 0
display_link_number 0
dns_order 0
document_charset UTF-8
east_asian_width 0
emacs_like_lineedit 0
ext_halfdump 0
ext_image_viewer 1
fix_width_conv 1
fixed_wheel_scroll_count 5
fold_textarea 0
gb18030_as_ucs 0
graphic_char 0
image_map_list 1
image_scale 100
imgdisplay w3mimgdisplay
indent_incr 4
keymap_file keymap
label_topline 0
mailto_options 1
mark 0
mark_all_pages 0
mark_color cyan
max_load_image 4
max_news 50
nextpage_topline 0
open_tab_blank 0
open_tab_dl_list 0
passwd_file ~/.w3m/passwd
pixel_per_char 7
pixel_per_line 14
pre_conv 0
pre_form_file ~/.w3m/pre_form
preserve_timestamp 1
pseudo_inlines 1
relative_wheel_scroll 0
relative_wheel_scroll_ratio 30
reverse_mouse 0
search_conv 1
show_cookie 1
show_srch_str 1
simple_preserve_space 1
ssl_verify_server 0
strict_iso2022 1
system_charset UTF-8
ucs_conv 1
use_combining 1
use_dictcommand 0
use_gb12345_map 0
use_history 1
use_jisc6226 0
use_jisx0201 0
use_jisx0201k 0
use_jisx0212 0
use_jisx0213 0
use_language_tag 1
use_wide 1
vi_prec_num 0

Bug#944575: calibre cannot find libGLX_mesa.so.0 and fails to launch

[James Van Zandt]

Package: calibre
Version: 4.3.0+dfsg-2
Severity: important

Dear Maintainer,


calibre won't launch here:

  home:/usr/lib $ calibre
  qt.glx: qglx_findConfig: Failed to finding matching FBConfig for
QSurfaceFormat(version 2.0, options QFlags(),
depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1,
alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior
QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace
QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
  qt.glx: qglx_findConfig: Failed to finding matching FBConfig for
QSurfaceFormat(version 2.0, options QFlags(),
depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1,
alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior
QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace
QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
  Could not initialize GLX
  [3]+  Donecalibre
  Aborted


I think "Could not initialize GLX" is the important part.

strace shows it's looking for /lib/libGLX_indirect.so.0 in four places:
  $ grep indirect /tmp/trace|sort -u
  openat(AT_FDCWD, "/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libGLX_indirect.so.0",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  openat(AT_FDCWD, "/usr/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
  openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

The library functionality is apparently supplied by the
libglx-mesa0:amd64 package, which installs this symlink:

  $ find /usr/lib -name \*libGLX_indirect\* -ls
  186909291  0 lrwxrwxrwx   1 root root   16 Nov  7 07:01
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 ->
libGLX_mesa.so.0

I created an additional symlink

  home:/usr/lib $ ls -l *indirect*
  lrwxrwxrwx 1 root root 33 Nov 11 20:16 libGLX_indirect.so.0 ->
x86_64-linux-gnu/libGLX_mesa.so.0

That permitted calibre to open.

I suppose calibre should be built to look in
/usr/lib/mesa-diverted/x86_64-linux-gnu/ for the library, or else the
libglx-mesa0:amd64 package should create a symlink in one of the four
directories calibre is now looking.


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

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

Versions of packages calibre depends on:
ii  calibre-bin  4.3.0+dfsg-2
ii  dpkg 1.19.7
ii  fonts-liberation 1:1.07.4-10
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  libjpeg-turbo-progs  1:1.5.2-2+b1
ii  libjs-coffeescript   1.12.8~dfsg-4
ii  libjs-mathjax2.7.4+dfsg-1
ii  optipng  0.7.7-1+b1
ii  poppler-utils0.71.0-6
ii  python-apsw  3.29.0-r1-1
ii  python-bs4   4.8.0-2
ii  python-chardet   3.0.4-4
ii  python-cherrypy3 8.9.1-5
ii  python-css-parser1.0.4-1
ii  python-cssselect 1.1.0-1
ii  python-cssutils  1.0.2-2
ii  python-dateutil  2.7.3-3
ii  python-dbus  1.2.12-1
ii  python-feedparser5.2.1-1
ii  python-html2text 2019.8.11-1
ii  python-html5-parser  0.4.9-1
ii  python-html5lib  1.0.1-1
ii  python-lxml  4.4.1-1
ii  python-markdown  3.1.1-2
ii  python-mechanize 1:0.4.3-2
ii  python-msgpack   0.5.6-2
ii  python-netifaces 0.10.4-1+b1
ii  python-pil   6.2.1-2
ii  python-pkg-resources 41.4.0-1
ii  python-pyparsing 2.4.2-1
ii  python-pyqt5 5.12.3+dfsg-3
ii  python-pyqt5.qtsvg   5.12.3+dfsg-3
ii  python-pyqt5.qtwebengine 5.12.1-4+b1
ii  python-regex 0.1.20190207-1+b1
ii  python-routes2.4.1-1
ii  python2.72.7.17-1
ii  xdg-utils1.1.3-1

Versions of packages calibre recommends:
ii  python-dnspython  1.16.0-1

Versions of packages calibre suggests:
pn  python-unrardll  

-- no debconf information

Bug#944574: w3m-download-this-url vs. zero byte file:///s

[積丹尼 Dan Jacobson]

X-Debbugs-Cc: yama...@jpl.org
Package: w3m-el-snapshot
Version: 1.4.632+0.20190920.1116.c9cdb7e-1
Severity: wishlist

If I try to download a zero byte local file,
file:///tmp/somezerobytefile I get a failure.

It works if the file has at least one byte.

But it really should, yes, work with zero byte empty files.

Bug#944228: stretch-pu: package phpmyadmin/4:4.6.6-4+deb9u1

[Matthias Blümel]

phpmyadmin 4.9.1+dfsg1-2 is now in unstable which fixes these issues

On Wed, 06 Nov 2019 11:50:51 + "Adam D. Barratt" <
a...@adam-barratt.org.uk> wrote:
> Control: tags -1 + moreinfo
> 
> On 2019-11-06 11:23, Felipe Sateler wrote:
> > This update fixes several security issues, plus an important bug.
> > Additionally we fix the metadata reflecting the maintainership
change.
> > 
> > Here is the changelog, with debdiff attached.
> > 
> > phpmyadmin (4:4.6.6-4+deb9u1) stretch; urgency=medium
> > 
> >   [ Matthias Blümel ]
> >   * Several security fixes
> > - Cross-site scripting (XSS) vulnerability in 
> > db_central_columns.php
> >   (PMASA-2018-1, CVE-2018-7260, Closes: #893539)
> > - Remove transformation plugin includes
> >   (PMASA-2018-6, CVE-2018-19968)
> > - Fix Stored Cross-Site Scripting (XSS) in navigation tree
> >   (PMASA-2018-8, CVE-2018-19970)
> > - Fix information leak (arbitrary file read) using SQL queries
> >   (PMASA-2019-1, CVE-2019-6799, Closes: #920823)
> > - a specially crafted username can be used to trigger a SQL 
> > injection attack
> >   (PMASA-2019-2, CVE-2019-6798, Closes: #920822)
> > - SQL injection in Designer feature
> >   (PMASA-2019-3, CVE-2019-11768, Closes: #930048)
> > - CSRF vulnerability in login form
> >   (PMASA-2019-4, CVE-2019-12616, Closes: #930017)
> 
> According to the BTS and Security Tracker, at least some of these
issues 
> affect the package in unstable and aren't currently fixed there. Is
that 
> correct?
> 
> Regards,
> 
> Adam
> 
> 

Bug#944519: w3m-download-this-url gives -dump_extra: command not found

[Katsumi Yamaoka]

On Mon, 11 Nov 2019 18:19:42 +0800, 積丹尼さん wrote:
> Package: w3m-el-snapshot
> Version: 1.4.632+0.20190920.1116.c9cdb7e-1
> X-Debbugs-Cc: yama...@jpl.org

> 1. Go to https://ftp.gnu.org/gnu/tramp/?C=M;O=D
> 2. hit "d" on tramp-2.4.2.tar.gz .

> /bin/bash: -dump_extra: command not found

This seems to be the case where the value for the `w3m-command'
variable is "", though I cannnot imagine why it goes so.  It
should be set automatically if the w3m executable is found in
`exec-path'.  What is the value for it?  Otherwise, what does
evaluating the form (w3m-which-command "w3m") return?  If it is
not the right one, you can add the directory name where the w3m
executable exists to `exec-path', for example:

(add-to-list 'exec-path "/home/jidanni/bin")

Of course you may instead set `w3m-command' directly as follows:

(setq w3m-command "/home/jidanni/bin/w3m")

How about it?

Bug#944351: Providing minor version somewhere in /etc/os-release in buster

[Santiago Vila]

tags 944351 - moreinfo
thanks

Note: I have finally the ok from both lsb-release and ansible people.

To answer the question: Yes, the change would be limited to VERSION_ID only.

That would be enough for the minor version to be shown by
"lsb_release -r" or "lsb_release -a", and also enough for ansible
people to implement {{ ansible_distribution_minor_version }}
without having to use ugly hacks.

So, to summarize: I believe putting minor version in VERSION_ID would
be useful, and I also think that we could do this in buster as far as
we do it "soon" in the stable cycle, i.e 10.x where x is still small
(for example, 10.3).

I am of course aware that some setups might break because of this but
on the other side we can reasonably hope that whatever breakage
(in hand-made scripts, for example) should be easy to fix.

(In fact, this change in base-files would fix a not-yet-fixed breakage
in lsb-release).

On Sun, Nov 10, 2019 at 01:14:12PM +, Holger Levsen wrote:
> On Sun, Nov 10, 2019 at 01:24:42PM +0100, Santiago Vila wrote:
> > Ok, I have just uploaded base-files as usual, but if possible I'd like
> > this to be sorted-out for 10.3 (in particular, I still would like to
> > hear from the ansible maintainers).
>  
> I wondering if change should have wider exposure. I suspect not only
> ansible users will be affected. I'd say this warrants a mail to d-d-a or
> at least -devel.

Hmm, what kind of exposure do you have in mind and for what purpose?

(I can think of two different purposes, not all of them desirable,
but would like to know yours first :-)

Thanks.

Bug#928287: qutip_4.4.1-1_amd64.changes REJECTED

[Drew Parsons]

On 2019-11-12 07:00, Thorsten Alteholz wrote:

Hi Drew,

please also mention
 qutip-4.4.1/qutip/qip/circuit_latex.py
in your debian/copyright.



Confused. qutip/qip/circuit_latex.py is already mentioned:

Files: *
Copyright: 2011 and later Paul D. Nation and Robert J. Johansson
License: BSD3



i.e. it is BSD-3, by Paul D. Nation and Robert J. Johansson, same as 
every other file.


Drew

Bug#944573: thrift: FTBFS with phpunit 8.4.3-1

[Andreas Beckmann]

Source: thrift
Version: 0.11.0-6
Severity: serious
Tags: ftbfs
Control: fixed -1 0.12.0-1

thrift FTBFS in sid/bullseye with the new phpunit version:

/usr/bin/phpunit --log-junit=TEST-log-json-protocol.xml 
Test/Thrift/Protocol/TestTJSONProtocol.php
PHP Fatal error:  Declaration of 
test\Thrift\Protocol\TestTJSONProtocol::setUpBeforeClass() must be compatible 
with PHPUnit\Framework\TestCase::setUpBeforeClass(): void in 
/build/thrift-0.11.0/lib/php/test/Test/Thrift/Protocol/TestTJSONProtocol.php on 
line 49


Andreas


thrift.sid.build.gz
Description: application/gzip

Bug#944082: Removed package(s) from unstable

[Pietro Battiston]

Il giorno mar, 12/11/2019 alle 00.02 +0100, Moritz Mühlenhoff ha
scritto:
> Your package is not a standalone, it's part of a complex system of
> components which interact with each other, we can't just ping people
> over and over when doing bigger-scale changes.

Managing complex systems requires rules, and indeed Debian has some,
including for migrations. This is why I was surprised by you declaring
the package "unmaintained" or "dead upstream" and removing it all of a
sudden: I was not asking for any special treatment for this package -
well on the contrary, I hadn't expected the special treatment it
received.

I have other packages with open bugs (sorry). I know you are busy, but
should you find the time to think about removing any of them, please
find the time before to ask me or at least warn me.

Thanks,

Pietro

Bug#935471: systemd: bogus "Process .. as been marked to be excluded from killing" warning from systemd-shutdown

[Michael Biebl]

Control: tags -1 + moreinfo

Am 23.08.19 um 01:06 schrieb Marc Lehmann:
> Package: systemd
> Version: 241-5
> Severity: minor
> 
> Dear Maintainer,
> 
> on one of my systems, debian runs from a filesystem image loop-mounted
> from an ntfs volume using ntfs-3g, and thus, the ntfs-3g process must be
> running at all times, before mounting the root fs and during shutdown.
> 
> To accomplish this I have an initramfs-tools script that runs it something
> like this:
> 
>   exec -a @ntfs-3g-root ntfs-3g ...

Would be great if you can share this script so we can see what exactly
it is doing.

> The @ prevents systemd-shutdown from killing it, which works. However, it
> outputs the following warning (lifted from the code, can't copy from
> the real system):
> 
> log_notice("Process " PID_FMT " (%s) has been marked to be 
> excluded from killing. It is "
>"running from the root file system, and thus 
> likely to block re-mounting of the "
>"root file system to read-only. Please consider 
> moving it into an initrd file "
>"system instead.", pid, strna(comm));
> 
> Since it is running from the initramfs, this warning is bogus (and indeed,
> the root fs can be mounted ro with no problem), suggesting that the check
> systemd-shutdown uses to detect this case is broken.
> 
> For additional reference, /proc//root has a target of "/",
> which probably causes this. /proc//exe has a target of
> '/usr/bin/ntfs-3g (deleted)', which makes sense as it was deleted when
> cleaning up the initramfs before handing over to the actual root fs.

Please supply the information that was requested by upstream:

"
so, the targets of those pseudo-symlinks are misleading. These symlinks
are "magic" if you so will, only if you actually use them in paths they
have a magic effect, and point to something potentially different than
their literal value. Hence, can you do stat on those two magic symlinks
to see what they actually point to?
"

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#944572: simka: debian/rules does not trap for errors

[Santiago Vila]

Package: src:simka
Version: 1.5.1-1
Severity: serious
Tags: patch

Dear maintainer: The debian/rules file for this package has a "for"
which does not always trap errors if they happen. To see why this
is a problem, compare the following two Makefile snippets:

for command in false true; do $${command}; done
echo MARK

for command in true false; do $${command}; done
echo MARK

The first one will succeed, the second one will not, but
in fact none of them should really succeed.

The simple patch below should fix this.

Please see Debian Policy 4.6. "Error trapping in makefiles"
for a more complete explanation:

https://www.debian.org/doc/debian-policy/ch-source.html#error-trapping-in-makefiles

Thanks.

--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ override_dh_install:
rm -r debian/tmp/usr/example \
debian/tmp/usr/scripts
chrpath --delete debian/simka/usr/bin/*
-   for file in debian/simkamin/usr/share/simkamin/*.py; do mv "$$file" 
"$${file%%.py}"; done
+   set -e; for file in debian/simkamin/usr/share/simkamin/*.py; do mv 
"$$file" "$${file%%.py}"; done
mv debian/simkamin/usr/share/simkamin/simkaMin_utils 
debian/simkamin/usr/share/simkamin/simkaMin_utils.py

 override_dh_fixperms:

Bug#937202: openjfx: Python2 removal in sid/bullseye

[Emmanuel Bourg]

Control: forwarded -1 https://bugs.openjdk.java.net/browse/JDK-8230779

The issue has been forwarded upstream. We may disable the webkit
component until the issue is addressed upstream.

Emmanuel Bourg

Bug#944571: mmdebstrap: the license is not the actual Expat license

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 0.5.1-2
Severity: normal

Hello!
I've just noticed that the mmdebstrap package [claims] to be released
under the terms of the Expat license, but this is not really the
case, since the license text (in both the debian/copyright file
and the upstream source code) lacks an important part, namely
the disclaimer of warranty and limitation of liability (the part
in upper case)!
Please compare with the canonical [Expat] license text.

[claims]: 

[Expat]: 

The disclaimer of warranty and limitation of liability are important
(above all, they protect the authors and copyright holders): I would
strongly recommend adding them as soon as possible, thus effectively
changing the license of mmdebstrap (this can be easily done, as long
as there's only one copyright holder).

Please fix this issue.
Thanks for your time!


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

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

Versions of packages mmdebstrap depends on:
ii  apt   1.8.4
ii  perl  5.30.0-9
ii  perl-doc  5.30.0-9

Versions of packages mmdebstrap recommends:
ii  arch-test   0.16-2
ii  fakechroot  2.19-3.2
ii  fakeroot1.24-1
ii  mount   2.34-0.1
ii  uidmap  1:4.7-2

Versions of packages mmdebstrap suggests:
pn  binfmt-support
ii  dpkg-dev  1.19.7
pn  proot 
pn  qemu-user 
pn  qemu-user-static  

-- no debconf information

Bug#944082: Removed package(s) from unstable

[Moritz Mühlenhoff]

On Mon, Nov 04, 2019 at 07:01:28PM +0100, Pietro Battiston wrote:
> Moritz,
> 
> I didn't upload new releases simply because there were none, and there
> were none simply because the required upgrade - to gtk 3 and gobject
> introspection - has so far not been completed. There was already a bug¹
> tracking that problem.
> 
> This was not an abandoned package, I was fully aware it had this
> problematic dependency on pygtk, that it would eventually be removed
> from unstable if the problem was not solved, and I was in contact with
> upstream to understand if an upgrade plan was feasible.

And that bug has _zero_ information that you did any of that.

> I would have
> expected someone to try to contact me/the upstream developer -
> respectively - before declaring it "dead upstream" and "unmaintained"
> and removing it in 1 day.

You were contacted via the bug and provided no feedback whatsoever.

Your package is not a standalone, it's part of a complex system of
components which interact with each other, we can't just ping people
over and over when doing bigger-scale changes.

If you come up with a port to gtk3 simply reupload it.

Cheers,
Moritz

Bug#885302: gtklick: Depends on unmaintained pygtk

[Moritz Mühlenhoff]

On Sat, Nov 02, 2019 at 12:29:22PM +0100, Moritz Mühlenhoff wrote:
> On Fri, Dec 29, 2017 at 12:23:22PM +0100, Jaromír Mikeš wrote:
> > >
> > > pygtk is unmaintained upstream. It has not had a release since GNOME 3
> > > was released in 2011.
> > >
> > > The way forward is to port your app to use GObject Introspection
> > > bindings.
> > 
> > ​Hi Dominic,
> > 
> > there is a serious issue with gtklick in debian.
> > Is there any chance get this fixed and avoid pygtk dependency?
> 
> Was there any followup, should gtklick be removed?

I've filed a removal bug now.

Cheers,
Moritz

Bug#944570: RM: gtklick -- RoQA; Depends on pygtk

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gtklick. It depends on pygtk, which is going away and hasn't
been ported by upstream.

Cheers,
Moritz

Bug#943899: Should ndisgtk be removed?

[Moritz Mühlenhoff]

On Thu, Oct 31, 2019 at 04:23:18PM +0100, Moritz Muehlenhoff wrote:
> Package: ndisgtk
> Severity: serious
> 
> Should ndisgtk be removed?
> 
> It's dead upstream (no release for 10 years) and depends on outdated stacks 
> scheduled for removal
> (python 2, pygtk).

I've filed a removal bug now.

Cheers,
Moritz

Bug#944569: RM: ndisgtk -- RoQA; dead upstream, depends on pygtk

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove ndisgtk. It's dead upstream (no release for 10 years) and depends
on outdated stacks scheduled for removal (python 2, pygtk).

Cheers,
Moritz
  

Bug#944568: RM: liblarch -- RoQA; depends on Python 2/pygtk, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove liblarch. It's dead upstream (no activity since four years), 
unmaintained
and depends on Python 2/pygtk.

Cheers,
Moritz

Bug#944567: O: ltspfs -- Fuse based remote filesystem for LTSP thin clients

[Vagrant Cascadian]

Package: wnpp
Severity: normal

I intend to orphan the ltspfs package.

Newer versions of LTSP no longer make use of LTSPFS; it is no longer
maintained upstream.

Marking it as orphaned for now just in case someone wants to maintain
the legacy LTSP 5.x and they could adopt this component.

If nobody wants to adopt it, it should probably be removed from the
archive instead of landing in the next stable release.

Description: Fuse based remote filesystem for LTSP thin clients
 LtspFS is a remote filesystem consisting of two parts:
 1) A network server daemon that runs on the LTSP terminal.
 2) A FUSE module that runs in userspace on the server, that connects
 with
 the daemon on the client.
 .
 This package contains the userspace parts for the LTSP server.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#944566: O: ldm-themes -- Collection of themes for the LTSP login manager

[Vagrant Cascadian]

Package: wnpp
Severity: normal

I intend to orphan the ldm-themes package.

Newer versions of LTSP no longer make use of LDM; it is no longer
maintained upstream.

Marking it as orphaned for now just in case someone wants to maintain
the legacy LTSP 5.x and they could adopt this component.

If nobody wants to adopt it, it should probably be removed from the
archive instead of landing in the next stable release.

The package description is:
 LDM is the LTSP Display Manager. It manages logins to
 sessions hosted on remote machines.
 .
 This package currently provides the following themes:
   - softWaves
   - Lines
   - Joy
   - futureprototype


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#944565: O: ldm -- LTSP display manager

[Vagrant Cascadian]

Package: wnpp
Severity: normal

I intend to orphan the ldm package.

Newer versions of LTSP no longer make use of LDM; it is no longer
maintained upstream.

Marking it as orphaned for now just in case someone wants to maintain
the legacy LTSP 5.x and they could adopt this component.

If nobody wants to adopt it, it should probably be removed from the
archive instead of landing in the next stable release.

The package description is:
 ldm is an X11 display manager similar to xdm, gdm and kdm, but unlike
 those it wraps the X11 traffic within an SSH tunnel to provide a
 secure login mechanism for remote X sessions.
 .
 LTSP stands for 'Linux Terminal Server Project'.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#943905: gnutls28 FTCBFS during guile bindings

[Ludovic Courtès]

Hi Andreas,

Apologies for the delay!

The build log at

shows two things:

--8<---cut here---start->8---
unset GUILE_LOAD_COMPILED_PATH ; LC_ALL=C   \
GNUTLS_GUILE_EXTENSION_DIR="/<>/b4deb/guile/src"   \
/usr/bin/guild compile --target="powerpc64le-unknown-linux-gnu" 
\
  -L "../guile/modules" \
  -L "../../guile/modules"  \
  -Wformat -Wunbound-variable -Warity-mismatch  \
  -o "modules/gnutls.go" "modules/gnutls.scm" >&$out
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /usr/bin/guild
;;; WARNING: compilation of /usr/bin/guild failed:
;;; failed to create path for auto-compiled file "/usr/bin/guild"
Backtrace:
In ice-9/boot-9.scm:
705:2 19 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 18 (_ #(#(#)))
155:9 17 (_ _)
In srfi/srfi-1.scm:
640:9 16 (for-each # ?)
In scripts/compile.scm:
   264:26 15 (_ _)
In system/base/target.scm:
 57:6 14 (with-target _ _)
In system/base/compile.scm:
152:6 13 (compile-file _ #:output-file _ #:from _ #:to _ #:env _ ?)
 43:4 12 (call-once _)
In ice-9/boot-9.scm:
841:4 11 (with-throw-handler _ _ _)
In system/base/compile.scm:
59:11 10 (_)
   155:11  9 (_ #)
   235:18  8 (read-and-compile # #:from _ #:to ?)
   183:32  7 (compile-fold (#) ?)
In ice-9/boot-9.scm:
   2312:4  6 (save-module-excursion #)
In language/scheme/compile-tree-il.scm:
31:15  5 (_)
In ice-9/psyntax.scm:
  1262:36  4 (expand-top-sequence ((eval-when (expand load eval) ?)) ?)
  1209:24  3 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
   285:10  2 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
In unknown file:
   1 (load-extension "/<>/gnutls28-3.6.1?" ?)
In ice-9/boot-9.scm:
   752:25  0 (dispatch-exception _ _ _)

ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
In procedure dynamic-link: file: 
"/<>/b4deb/guile/src/guile-gnutls-v-2", message: "file not found"
make[5]: *** [Makefile:2348: modules/gnutls.go] Error 1
--8<---cut here---end--->8---

The first one is the annoying but harmless “compilation of
/usr/bin/guild failed”.

The second one is the build failure that stems from the fact that it’s
trying to load ‘guile-gnutls-v-2.so’, which is bound to fail when
cross-compiling.

The patches at 
should address these two issues.  (You should be able to apply them
directly in the Debian package, if needed.)

Feedback welcome!

Thanks,
Ludo’.

Bug#944384: nmu: ros-*-msgs

[Jochen Sprickerhof]

Hi Paul,

* Paul Gevers  [2019-11-11 22:41]:

nmu ros-navigation-msgs_1.13.1-1 . ANY . unstable . -m "rebuild against ros-gencpp 
0.6.2-4"
nmu ros-navigation-msgs_1.13.1-1 . ANY . unstable . -m "rebuild against ros-gencpp 
0.6.2-4"


^ double. Did you mean something else?


Only copy and paste error, thanks for asking :).


nmu ros-ros-comm-msgs_1.11.2-10 . ANY . unstable . -m "rebuild against ros-gencpp 
0.6.2-4"
nmu ros-std-msgs_0.5.12-2 . ANY . unstable . -m "rebuild against ros-gencpp 
0.6.2-4"


Scheduled.


Thx!


signature.asc
Description: PGP signature

Bug#942589: transition: assimp

[Paul Gevers]

Control: tags -1 confirmed

Hi IOhannes

On 18-10-2019 18:18, IOhannes m zmoelnig wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> The new upstream version assimp-5.0.0 comes with a soname bump from
> libassimp.so.4 to libassimp.so.5.
> consequently, the binary package has been renamed from libassimp4 to 
> libassimp5.
> 
> The following packages are impactec:
> - deal.ii
> - doomsday
> - gem
> - kido
> - mrpt
> - qt3d-opensource-src
> - ros-geometric-shapes, ros-rviz, ros-robot-model
> 
> I've done test-builds of all these rdepends and all of them succeeded except 
> for
> "deal.ii". Since "deal.ii" takes several hours to complete, i haven't found 
> out
> the reason yet, but AFAICT the FTBFS is not related to the libassimp 
> transition.

Please go ahead.

Paul




signature.asc
Description: OpenPGP digital signature

Bug#942440: transition: libevent

[Paul Gevers]

Control: tags -1 confirmed

Hi Balint,

On 16-10-2019 13:44, Balint Reczey wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> I would like to update libevent in unstable.
> 
> I have performed test rebuilds [1] in Ubuntu 19.10 which found no
> libenvent-specific FTBFS issue.

Please go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#943992: transition: qscintilla2, soname 13 -> 15

[Paul Gevers]

Control: tags -1 moreinfo

Hi Gudjon,

On 02-11-2019 10:11, Gudjon I. Gudjonsson wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> Severity: normal
> 
> Dear release team
> 
> I would like to ask for a transition of qscintilla2 2.11.2+dfsg from
> experimental to unstable.
> 
> The package is a part of the auto-qscintilla2 transition.
> 
> The SONAME is changed from 13 to 15.
> All python2 packages have been removed.
> All Qt4 packages have been removed.

I don't like mixing these. Are there any reverse dependencies involved?
Are they informed (please make bug numbers blocking this transition)? If
there are reverse dependencies involved, I'd like you to urge the
maintainers to fix those before we start with this transition.

> All reverse dependencies compile against version 2.11.2. 


Paul



signature.asc
Description: OpenPGP digital signature

Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

[Sudip Mukherjee]

Hi Ben,

On Sun, Nov 10, 2019 at 10:01 PM Ben Hutchings  wrote:
>
> On Sun, 2019-11-10 at 21:29 +, Sudip Mukherjee wrote:
> > On Fri, Nov 08, 2019 at 07:56:55PM +, Ben Hutchings wrote:
> > > On Mon, 2019-11-04 at 21:44 +, Sudip Mukherjee wrote:
> > > [...]
> > > > The code for libtracevent lives in the kernel tree at
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git in 
> > > > tools/lib/traceevent folder.
> > > > And so, it will be great if kernel team will like to package and 
> > > > maintain it, if not, then I will
> > > > be happy to do it. But, if I am doing it then I will need a sponsor to 
> > > > upload it.
> > >
> > > If kernel.org's kernel source repository is the canonical location for
> > > this code, not just a convenience copy, then the binary package should
> > > be built from src:linux and not a separate source package.
> > >
> > > I think src:linux already builds the library, but only as a static
> > > library that's linked into perf.
> > >
> > > I don't know exactly what changes you would need to make, but they
> > > should be roughly along these lines:
> > >
> > 
> > > 4. Generate the debian/libtraceevent.symbols file recording
> > >the shared library's exported symbols.
> >
> > Thanks for your reply Ben.
> > I will try these steps and see how it goes.
> >
> > > 5. (Not sure if this is needed.)  Modify
> > >debian/rules.d/tools/perf/Makefile to make perf use the shared
> > >library.  Add libtraceevent to the dependencies of
> > >linux-perf- in debian/templates/control.tools-versioned.in.
> >
> > This should not be needed as perf does not yet depend on libtraceevent.
> > The libtraceevent that perf is creating is only having the plugins.
>
> I'm pretty sure it does; look for "libtraceevent.a" in
> .

iiuc, perf used tools/lib/traceevent to generate "libtraceevent.a"
which is a static library and perf is building against that. It is
also using the plugins generated by traceevent. But it is not using
"libtraceevent.so" which is generated. So, as a result all the
traceevent code is statically linked in perf when it builds.
If I see the installation folder of perf I am only seeing
"lib64/traceevent/plugins" and I am not seeing the dynamic library
created by traceevent.
Moreover if I do "ldd perf" it is not showing that it is linked to
libtraceevent.so. But, in anycase, I will need to modify the rules as
the plugins will be installed by traceevent which will be used by
perf.
I hope I was able to explain properly. But, let me make the changes
and test first and then I can show you what I did.
Thanks for your help.


-- 
Regards
Sudip

Bug#944399: Build-Script

[Stefan Rücker]

Hello Joel,

thanks for the prompt reply, I have opened a new bug at 
https://github.com/ccache/ccache:

https://github.com/ccache/ccache/issues/489

Regarding your sync problem, marlin should be there if you have used 
android-10.0.0_r1 branch.


FInd attached a stripped down build-script. I haven't run it yet fully, 
but I am testing it already.


export USE_CCACHE=1 activates ccache, and then the build should fail 
with that script.

export USE_CCACHE=0 deactivates ccache, and then the build should succeed.

You should be able to just start the script everything else should work 
out of the box if you have installed repo tool via apt install repo and 
the packages mentioned here:

https://developer.sony.com/develop/open-devices/guides/aosp-build-instructions/build-aosp-android-android-10-0-0#tutorial-step-2

Best regards,
Stefan


build-4.14-ccache.sh
Description: application/shellscript

Bug#943925: patch - feather / pandas 0.25

[Rebecca N. Palmer]

Control: tags -1 patch
Control: severity -1 serious
(pandas 0.25 is now in unstable)

The attached fixes this bug.

(Though as both this upstream and pandas read_feather() have switched to 
pyarrow, in the longer term you might want to package that instead.)
Description: Be compatible with pandas 0.25

Author: Rebecca N. Palmer 
Bug-Debian: https://bugs.debian.org/943925
Forwarded: not-needed (upstream have switched to pyarrow)

--- python-feather-format-0.3.1+dfsg1.orig/feather/api.py
+++ python-feather-format-0.3.1+dfsg1/feather/api.py
@@ -15,6 +15,7 @@
 import six
 from distutils.version import LooseVersion
 import pandas as pd
+import pandas.api.types
 from feather.compat import pdapi
 
 import feather.ext as ext
@@ -40,7 +41,7 @@ def write_dataframe(df, path):
 col = df.iloc[:, i]
 
 if pdapi.is_object_dtype(col):
-inferred_type = pd.lib.infer_dtype(col)
+inferred_type = pandas.api.types.infer_dtype(col)
 msg = ("cannot serialize column {n} "
"named {name} with dtype {dtype}".format(
n=i, name=name, dtype=inferred_type))
@@ -48,7 +49,7 @@ def write_dataframe(df, path):
 if inferred_type in ['mixed']:
 
 # allow columns with nulls + an inferable type
-inferred_type = pd.lib.infer_dtype(col[col.notnull()])
+inferred_type = pandas.api.types.infer_dtype(col[col.notnull()])
 if inferred_type in ['mixed']:
 raise ValueError(msg)
 
--- python-feather-format-0.3.1+dfsg1.orig/feather/tests/test_reader.py
+++ python-feather-format-0.3.1+dfsg1/feather/tests/test_reader.py
@@ -361,8 +361,8 @@ class TestFeatherReader(unittest.TestCas
 
 # period
 df = pd.DataFrame({'a': pd.period_range('2013', freq='M', periods=3)})
-self._assert_error_on_write(df, ValueError)
+self._assert_error_on_write(df, (feather.FeatherError,ValueError))
 
 # non-strings
 df = pd.DataFrame({'a': ['a', 1, 2.0]})
-self._assert_error_on_write(df, ValueError)
+self._assert_error_on_write(df, (feather.FeatherError,ValueError))

Bug#944192: python3-h5py: 'import h5py' produces Open MPI message to stderr

[Jameson Graef Rollins]

Can someone help me isolate where exactly the issue is?  The upstream
maintainers of h5py seem to think it might be related to how we compile
libhdf5:

https://github.com/h5py/h5py/issues/1433#issuecomment-552582013

Is there a way to test that with another application?

jamie.

Bug#944563: ITP: libb-cow-perl -- additional B helpers to check COW status

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libb-cow-perl
  Version : 0.001
  Upstream Author : Nicolas R. 
* URL : https://metacpan.org/release/B-COW
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : additional B helpers to check COW status

B::COW provides some naive additional B helpers to check the COW status of
one SvPV.

A COWed SvPV is sharing its string (the PV) with other SvPVs. It's a (kind
of) Read Only C string, that would be Copied On Write (COW).

More than one SV can share the same PV, but when one PV need to alter it, it
would perform a copy of it, decrease the COWREFCNT counter.

One SV can then drop the COW flag when it's the only one holding a pointer to
the PV.

The COWREFCNT is stored at the end of the PV, after the "\0".

That value is limited to 255, after that a new PV would be created,

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#944562: Patch available

[Fabrice BAUZAC-STEHLY]

tags 944562 + patch
thanks

Merge request created:
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/38

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Bug#944550: openscenegraph-3.4: should this package be removed?

[Alberto Luaces Fernández]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Andreas Beckmann writes:

> Source: openscenegraph-3.4
> Version: 3.4.1+dfsg1-5
> Severity: serious
> Tags: sid
>
> with openscenegraph 3.6 uploaded to sid, should the now older
> openscenegraph-3.4 be removed?

Yes, please! :-)
-BEGIN PGP SIGNATURE-

iJUEARMJAB0WIQQAkrD2fjOKzJT6ErrYoCh5SUbfSgUCXcnH3AAKCRDYoCh5SUbf
SloqAYDFvJcsgSAEylwA0hG/nh1/qNMCTpOhwaNRH3BjYdeQ/oqScocI3POP4A5x
ECG4YSYBgNb4xbBcunxTN4fbf7q1EfBxt7ZiJob4ka1EAJyeKvJ5b9zk7GZtVg1E
+YQt2GreOA==
=8Hj3
-END PGP SIGNATURE-

Bug#944562: reportbug: Incorrect error message when urwid is not available

[Fabrice BAUZAC]

Package: reportbug
Version: 7.5.3
Severity: normal

Dear Maintainer,

I tried to use the urwid interface, and got the following message:

  $ reportbug --ui=urwid
  Cannot use UI urwid because of "Please install the python-urwid package to 
use this interface.", defaulting to "text"

However, installing python-urwid did not solve the issue.  Indeed, the
dependency is on python3-urwid, not on python-urwid.

Could you please fix the message to indicate the correct missing
package?

Thanks!

Best regards
Fabrice

-- Package-specific info:
** Environment settings:
EDITOR="emacsclient"
PAGER="cat"
EMAIL="n...@mykolab.com"
NAME="Fabrice BAUZAC"
INTERFACE="text"

** /home/noon/.reportbugrc:
reportbug_version "7.5.3"
mode standard
ui text
realname "Fabrice BAUZAC"
email "n...@mykolab.com"
smtphost "smtp.kolabnow.com:587"
smtpuser "n...@mykolab.com"
smtppasswd 
smtptls

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US:en (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt1.8.4
ii  python33.7.5-1
ii  python3-reportbug  7.5.3
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
ii  emacs-bin-common   1:26.1+1-4
ii  exim4-daemon-light [mail-transport-agent]  4.92.3-1
ii  file   1:5.37-6
ii  gnupg  2.2.17-3
ii  python3-urwid  2.0.1-2+b1
ii  reportbug-gtk  7.5.3
ii  xdg-utils  1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.8.4
ii  file   1:5.37-6
ii  python33.7.5-1
ii  python3-apt1.8.4
ii  python3-debian 0.1.36
ii  python3-debianbts  2.8.2
ii  python3-requests   2.21.0-1
ii  sensible-utils 0.0.12

python3-reportbug suggests no packages.

-- no debconf information

Bug#943758: Bug solved ok to close

[pham...@bluewin.ch]

Hello,
Bug solved with update today to version 78.0.3904.97 
Best regards.

Bug#944265: mailutils: local privilege escalation in maidag utility (fixed in 3.8)

[Salvatore Bonaccorso]

Control: retitle -1 mailutils: local privilege escalation in maidag utility 
(fixed in 3.8) (CVE-2019-18862)

Hi,

On Thu, Nov 07, 2019 at 07:55:56AM +0800, Paul Wise wrote:
> Source: mailutils
> Severity: serious
> Tags: security fixed-upstream
> 
> There is a local privilege escalation in the maidag utility:
> 
> https://savannah.gnu.org/forum/forum.php?forum_id=9586
> 
>This version fixes important security flow. The maidag utility has
>been withdrawn and three new programs have been included to provide
>its functionality: local mail delivery agent mda, LMTP daemon lmtpd,
>and user mail delivery tool putmail. 
> 
> https://git.savannah.gnu.org/cgit/mailutils.git/plain/NEWS
> 
>* The maidag utility is withdrawn
> 
>The main purpose of this utility was to work as local mail delivery
>agent (MDA), a program responsible for final delivery of email messages
>to the recipient's mailbox.  As such it required suid privileges.
> 
>In parallel with its main purpose, it also was able to work in two
>other modes: the 'url' mode, designed to deliver mails to arbitrary
>mailbox URLs, and 'lmtp' mode, in which it acted as local mail
>transport daemon.  Neither of these needed suid privileges.
> 
>The unfortunate design decision to combine the three modes in a single
>versatile tool resulted in local privilege escalation threat in 'url'
>mode.
> 
>To fix this, maidag has been replaced by three different utilities,
>each one with a precisely defined purpose and carefully designed
>privileges: mda, lmtpd, and putmail.

The issue has been assigned CVE-2019-18862.

Regards,
Salvatore

Bug#944561: libident builds a broken package during cross compilation

[Helmut Grohne]

Source: libident
Version: 0.22-3.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libident successfully cross builds an entirely broken package. While
being tagged for the host architecture, the actual binaries are for the
build architecture. libident should be using cross tools and they can be
easily supplied from dpkg's buildtools.mk now. Please consider applying
the attached patch.

What would be even better is using debhelper. Doing so would have lots
of benefits including but not limited to:
 * Fixing this bug.
 * Making DEB_BUILD_OPTIONS=nostrip work.
 * Generating a -dbgsym package.
 * Making the package more reproducible.
 * Making debian/rules much shorter.

Helmut
diff -u libident-0.22/debian/changelog libident-0.22/debian/changelog
--- libident-0.22/debian/changelog
+++ libident-0.22/debian/changelog
@@ -1,3 +1,10 @@
+libident (0.22-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply build tools. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Nov 2019 21:16:05 +0100
+
 libident (0.22-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libident-0.22/debian/rules libident-0.22/debian/rules
--- libident-0.22/debian/rules
+++ libident-0.22/debian/rules
@@ -6,7 +6,9 @@
 version  = $(shell grep "^$(source) " debian/changelog|head -n 1|sed 
's/.*(\(.*\)\-[^\-]*).*/\1/g')
 revision = $(shell grep "^$(source) " debian/changelog|head -n 1|sed 
's/.*([^\-]*\-\(.*\)).*/\1/g')
 
-installexe = install -g root -o root -m 755
+include /usr/share/dpkg/buildtools.mk
+
+installexe = install --strip-program=$(STRIP) -g root -o root -m 755
 installbin = $(installexe)
 installdoc = install -g root -o root -m 644
 
@@ -26,7 +28,6 @@
 $(tmpdir-dev)/usr/lib \
 $(tmpdir-dev)/usr/share/man/man3
 
-CC=gcc
 CFLAGS=-g -Wall -DHAVE_ANSIHEADERS -D_REENTRANT
 LDFLAGS=
 
@@ -80,9 +81,9 @@
# dont compress copyright
gzip -v9 $(tmpdir)/usr/share/doc/libident/README
gzip -v9 $(tmpdir)/usr/share/doc/libident/changelog.Debian
-   strip --strip-debug$(tmpdir-dev)/usr/lib/libident.a
-   strip --strip-unneeded $(tmpdir)/usr/lib/libident.so.$(version)
-   strip --remove-section=.comment $(tmpdir)/usr/lib/libident.so.$(version)
+   $(STRIP) --strip-debug$(tmpdir-dev)/usr/lib/libident.a
+   $(STRIP) --strip-unneeded $(tmpdir)/usr/lib/libident.so.$(version)
+   $(STRIP) --remove-section=.comment 
$(tmpdir)/usr/lib/libident.so.$(version)
ln -s libident $(tmpdir-dev)/usr/share/doc/libident-dev
dpkg-shlibdeps $(tmpdir)/usr/sbin/in.identtestd
dpkg-gencontrol -P$(tmpdir) -plibident -isp

Bug#944560: Bug on Debian 10 Buster - Kernel version 4.19.0-6-amd64

[pham...@bluewin.ch]

Package: Kernel
  
   
  
  
   Version: 4.19.0-6-amd64
   
  
  
   
  
  

  
  
   Bug Description:
  
  
   
  
  
When I connect my smartphone or my USB camera to my PC, the first time all 
works properly.
If I disconnect and reconnect it, it's impossible from this device to copy/cut 
and paste an image on my PC. My phone is a Sony Z5 Compact and my camera is an 
Canon Powershot G5x Mk II
  

  
  
   
  
  
   Best regards.
  
  
   
  
  

  
  
   Philippe 
  
  
 
 
 
 

Bug#944559: lz4 FTCBFS: python3 build dependency not installable

[Helmut Grohne]

Source: lz4
Version: 1.9.2-1
Severity: important
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

lz4 fails to install its build dependency on the host architecture
python3 during cross compilation. There are two ways to fix this and the
attached patch combines both:
 * It really wants to run python3 (rather than say build a python3
   extension), so it should request the build architecture python3. This
   is done by annotating the dependency with :any (or :native).
 * The dependency is only used for running build-time tests. During
   cross compilation, we cannot run such tests and they're thus disabled
   via DEB_BUILD_OPTIONS=nocheck. Thus the dependency is unnecessary
   here and should be tagged  accordingly.

The severity of this bug is important, because cross building lz4 is
required for bootstrapping a new architecture as systemd build depends
on it. Please fix this bug soon.

Helmut
diff --minimal -Nru lz4-1.9.2/debian/changelog lz4-1.9.2/debian/changelog
--- lz4-1.9.2/debian/changelog  2019-10-29 11:19:36.0 +0100
+++ lz4-1.9.2/debian/changelog  2019-11-11 20:24:03.0 +0100
@@ -1,3 +1,10 @@
+lz4 (1.9.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate the python3 dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Nov 2019 20:24:03 +0100
+
 lz4 (1.9.2-1) unstable; urgency=medium
 
   * New upstream release. (Closes: #943680)
diff --minimal -Nru lz4-1.9.2/debian/control lz4-1.9.2/debian/control
--- lz4-1.9.2/debian/control2019-10-29 11:19:36.0 +0100
+++ lz4-1.9.2/debian/control2019-11-11 20:23:58.0 +0100
@@ -1,7 +1,7 @@
 Source: lz4
 Priority: optional
 Maintainer: Nobuhiro Iwamatsu 
-Build-Depends: debhelper (>= 9.0.0), python3
+Build-Depends: debhelper (>= 9.0.0), python3:any 
 Standards-Version: 4.1.0
 Section: utils
 Homepage: https://github.com/Cyan4973/lz4

Bug#943468: php-fpm: CVE-2019-11043: Vulnerability in PHP-FPM Could Lead to Remote Code Execution on nginx

[Ondřej Surý]

The Debian stable has been fixed shortly after the new version was updated. 
There’s no strong security update guarantee for unstable and testing. From the 
security team FAQ:

> If you want to have a secure (and stable) server you are strongly encouraged 
> to stay with stable.

Ondrej
--
Ondřej Surý 

> On 11 Nov 2019, at 20:30, Alex  wrote:
> 
> Hi,
> 
> PHP published a fixed version (7.3.11) before this CVE went public. Can you
> please package and upload that version?
> 
> If that is not possible, can you please at least explain in the bug report why
> fixing this (pretty serious) bug is not possible at the moment? That might
> attract some assistance if needed.
> --
> mvg,
> 
> Alex Hermann
> 

Bug#944556: Upstream bug : to bad I did not know what to search for as bug hunting sentence

[Eric Valette]

https://devtalk.nvidia.com/default/topic/1065364/linux/v440-26-checking-kernel-headers-is-broken-in-conftest-sh/

-- eric

Bug#944558: kitty: unable to use duospaced (spacing: 90) fonts

[Vincent Blut]

Package: kitty
Version: 0.14.4-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

kitty version available in Debian does not allow the use of duospaced
fonts (e.g: fonts-firacode). However, this has been fixed in the 0.14.5 
version so it would be great if you could make it available.

Cheers,
Vincent

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

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

Versions of packages kitty depends on:
ii  kitty-terminfo  0.14.4-1
ii  libc6   2.29-3
ii  libcanberra00.30-7
ii  libdbus-1-3 1.12.16-2
ii  libfontconfig1  2.13.1-2+b1
ii  libfreetype62.10.1-2
ii  libharfbuzz0b   2.6.4-1
ii  libpng16-16 1.6.37-1
ii  libpython3.73.7.5-2
ii  libwayland-client0  1.17.0-1
ii  libx11-62:1.6.8-1
ii  libx11-xcb1 2:1.6.8-1
ii  libxkbcommon-x11-0  0.9.1-1
ii  libxkbcommon0   0.9.1-1
ii  python3 3.7.5-1
ii  python3.7   3.7.5-2
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages kitty recommends:
pn  kitty-doc  

Versions of packages kitty suggests:
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJLBAEBCgA1FiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAl3JvusXHHZpbmNlbnQu
ZGViaWFuQGZyZWUuZnIACgkQipzudlpxp4Dh1A/+LAgCTM76/JS7JhthBjtD2dFt
KxtxFN/8yC/zZ8GXJ1j4WYXdcMLnSgW7S6UyQbZBVZ4ChaOf3hUF3rNc2dCD+qoe
4MVaRpzA53gKfCBbxKstrvXYnlzJpR9MUjl784205XIGYwqhEcnnqiLb2TFWRxvb
ftVfY1ZLDMO6I7JC48c/kCC4XQI4kpAOmitV+RcGyZr3ZDro5HGQiuQUfU7+zVMl
C9jvi89z4kqXfM6KURudaUw36o7RSZyPAR6+GiZdor/m3TMYXrvoGTy3NQRC36yE
knWZI+93LppA8rxC0EGP5bsDaJwSXbVQK6DhHxDPZz/uKhMgMmB29BiiSHzR5YJ3
/LRT/9ymKyPtY7fc3SZHDPSp2HqF32eEmojz759pITSAx48d/sdvYrI7J99wFPTn
Pi+AmzGcUzRcL+i6f5mqRfXetD6FFUkZ1uozILH9zzjvvsQk7p6iCf4cBCa3tCQB
k/5vk5euw5X/PEbyCs2PzH0ZQ7Y1VwfrSQjGFle1V+kfJFG6mTuOUOMSYuWDPipe
L2UaiN532XnCHkxcD7wOkJ6wJfeWPZfYEOE20kR2X7Mv7RGbAiraDsCaoOahP1Qk
wWycu1aBg1OiGYD+43ur/qhq6EJlenybu6aV/oX9Hq4uCXylrekwxgvoUy6wfdJq
TL8TaDOls0S5mzYF/oM=
=ppSm
-END PGP SIGNATURE-

Bug#944557: bzip2: built without LFS support

[Sven Joachim]

Package: bzip2
Version: 1.0.6-9
Severity: important
Tags: lfs

On 32-bit systems bzip2 cannot handle files over 2 GiB, as seen here in
an i386 chroot:

,
| $ dd if=/dev/zero of=bigfile bs=1 count=0 seek=2049M
| [...]
| $ bzip2 bigfile
| bzip2: Can't open input file bigfile: Value too large for defined data type.
`

The upstream Makefile sets -D_FILE_OFFSET_BITS=64 in CFLAGS (should
actually be in CPPFLAGS, but it does not really matter), but
debian/rules overwrites that setting since commit 8e1481f96b9[1].


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

Kernel: Linux 5.4.0-rc7-nouveau (SMP w/2 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)

Versions of packages bzip2 depends on:
ii  libbz2-1.0  1.0.8-2
ii  libc6   2.29-3

bzip2 recommends no packages.

Versions of packages bzip2 suggests:
ii  bzip2-doc  1.0.8-2

-- no debconf information


1. 1. 
https://salsa.debian.org/debian/bzip2/commit/8e1481f96b99e2060f9b72e76cfe434b1f13

Bug#944556: nvidia-kernel-dkms: cannot compile because conftest.sh file test gcc error message assuming english

[Eric Valette]

Package: nvidia-kernel-dkms
Version: 440.26-1
Severity: important

/usr/src/nvidia-current-440.26/conftest.sh

in function translate_and_compile_header_files()

if compilation fails because include is not there, it does not undef the macros 
used
to say a file is present or not eevent if compilation fails but retest that the 
compilation
indeed failed because the tested include file is not present via an explicit 
grep on
error message.

Unfortunately the grep command assumes the gcc error is in english which is 
false.
This can easilly been fixed by adding a LANG=C at the begining of the function.

A proper solution would be to use a regionalized error message...

-- Package-specific info:
uname -a:
Linux tri-yann4 4.19.83 #16 SMP PREEMPT Sun Nov 10 23:48:52 CET 2019 x86_64 
GNU/Linux

/proc/version:
Linux version 4.19.83 (valette@tri-yann4) (gcc version 9.2.1 20191109 (Debian 
9.2.1-19)) #16 SMP PREEMPT Sun Nov 10 23:48:52 CET 2019

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  435.21  Sun Aug 25 08:17:57 CDT 
2019
GCC version:  gcc version 9.2.1 20191109 (Debian 9.2.1-19) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 
670] [10de:1189] (rev a1) (prog-if 00 [VGA controller])
Subsystem: CardExpert Technology GK104 [GeForce GTX 670] [10b0:1189]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia_current_drm, nvidia_current

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Nov 11 18:35 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Nov 11 18:35 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Nov 11 18:35 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 Nov 11 18:35 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Nov 11 18:35 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Nov 11 18:35 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Nov 11 18:35 pci-:01:00.0-render -> ../renderD128
video:x:44:valette,vdr,sddm,ceva6380,hts

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 1673 Oct 14  2017 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root   15 Nov 11 18:59 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   49 Aug 19  2018 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root   51 Nov 11 18:59 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root   48 Aug 19  2018 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Aug 19  2018 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   50 Nov 11 18:59 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   50 Nov 11 18:59 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root   55 Aug 19  2018 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   55 Aug 19  2018 
/etc/alternatives/glx--libGLESv1_CM.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so
lrwxrwxrwx 1 root root   57 Nov 11 18:59 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   57 Nov 11 18:59 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   52 Aug 19  2018 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   52 Aug 19  2018 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so
lrwxrwxrwx 1 root root   54 Nov 11 18:59 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   54 Nov 11 18:59 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root   44 Nov 11 18:59 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root   44 Nov 11 18:59 
/etc/alternatives/glx--libGLX_indirect.so.0-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root   38 Nov 11 18:59 

Bug#895696: Bullseye: firmware-ath9k-htc: does not work with network-manager wifi.scan-rand-mac-address

[Oleksij Rempel]

yes, it is.
please add needed information to the wiki.

--
Regards,
Oleksij

Bug#944192: python3-h5py: 'import h5py' produces Open MPI message to stderr

[Thomas Caswell]

On Mon, 11 Nov 2019 10:28:22 -0800 Jameson Graef Rollins <
jroll...@caltech.edu> wrote:
> forwarded 944192 https://github.com/h5py/h5py/issues/1433
> thanks
>
>

As commented on the h5py issues tracker, I think this is an issue with how
the underlying libhdf5/openmp libraries are built and not something we can
fix at the python/h5py level.

Please re-direct this to the lbihdf5 packager.

Tom

Bug#943468: php-fpm: CVE-2019-11043: Vulnerability in PHP-FPM Could Lead to Remote Code Execution on nginx

[Alex]

Hi,

PHP published a fixed version (7.3.11) before this CVE went public. Can you
please package and upload that version?

If that is not possible, can you please at least explain in the bug report why
fixing this (pretty serious) bug is not possible at the moment? That might
attract some assistance if needed.
--
mvg,

Alex Hermann

Bug#944555: tpm2-tss: please include symbol tracking via debian/symbols

[Mario Limonciello]

Source: tpm2-tss
Version: 2.3.1-1
Severity: wishlist

As this package includes a shared library, it should have symbols in that
library tracked via symbols or shlibs per Debian policy
(https://www.debian.org/doc/debian-policy/ch-sharedlibs.html)

Can you please add a symbols file in a future upload?



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

Kernel: Linux 5.3.0+ (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN
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)

Bug#939571: uploaded a NMU, delayed 15 days

[Carlos Pascual]

Same here: my build of the taurus-pyqtgraph package is now working again in 
sid. 
Thanks!

Bug#895696: Bullseye: firmware-ath9k-htc: does not work with network-manager wifi.scan-rand-mac-address

[awalis]

Package: firmware-ath9k-htc
Version: 1.4.0-97-g75b3e59+dfsg-3
Followup-For: Bug #895696

Dear Maintainer,

This is just to confirm the bug on debian bullseye, with
NetworkManager version 1.20.4.

It would be helpful to mention the workaround where
wifi.scan-rand-mac-address is disabled on the AR9271 wiki page. As this
is more strightforwad than completly wiping out the current interface
name-assignement mechanism to fall back on the simple scheme (eth0,
wlan0, ...) for a single usb dongle.

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

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

-- no debconf information

Bug#943785: RFS: python-pyjsparser (ITP bug #943785)

[Peter Wienemann]

Hi Nick,

thank you very much for taking the time to review the packaging and
providing such detailed and helpful feedback.

On 10.11.19 00:02, Nick Morrott wrote:
> Thank you for your work in packaging python-pyjsparser. Out of
> curiosity, what are you using to be build your package?

My primary motivation for packaging python-pyjsparser is to be able to
bump the version of Charliecloud:

https://tracker.debian.org/pkg/charliecloud

Version 0.10 of Charliecloud adds new dependencies, including
lark-parser which in turn depends on python-js2py which in turn depends
on python-pyjsparser.

> I checked out the package and built it - your work looks good, and the
> build was successful. I then ran it through lintian, Debian's package
> linting tool which you should get into the habit of using before
> uploading to salsa (and once you're a DM/DD, also before uploading to
> the archive).

I have configured my sbuild setup in such a way that it always runs
lintian after builds. But thanks to your feedback I noticed that I was
running lintian with a too high display threshold such that the only
lintian feedback I received was

"I: Lintian run was successful."

and

"Lintian: pass"

despite of the issues you discovered.

I have tweaked the lintian options in my ~/.sbuildrc now. Hopefully I
will not miss similar issues in the future.

> * d/control
>   - no Rules-Requires-Root field [lintian]

Fixed.

>   - the extended package description should probably include details
> about the library's key features/support [lintian]

Done.

> * d/copyright
>   - the only copyright dates I can see in the source are 2014-2015

Judging from the source files, you are right. Judging from the git
commit history I see commits between 2015 and 2019. What is a better
guideline for copyright years: copyright notices in the source or the
git history? Maybe it would be best to combine both information which
would yield 2014-2019. Once I know what should be used, I will update
the copyright file accordingly.

>   - you can add the Upstream-Contact field to the header

Done.

> * d/rules
>   - pybuild can provide verbose output with "export PYBUILD_VERBOSE=1"

Added.

> * d/upstream/metadata
>   - please add and complete this file - there are plenty of examples
> in the team's salsa project [lintian]

Done.

> * d/watch
>   - +1 for asking upstream to version their releases on github

Thanks! Let's see what happens.

>   - the additional (commented) scaffolding inserted into the file by
> dh-make can be removed to leave only the version line and the URL to
> check [lintian]

The idea behind leaving the Github lines as comment was that I could
easily switch to following Github tags/releases provided that upstream
decides to publish them for future releases. But since the
"" string triggers the lintian complaint and replacing this
placeholder would be just guessing until upstream actually provides
releases on Github, I removed all comments related to this.

This also makes lintian happier. :-)

>   - as this is a version 4 watch file, we can take advantage of new
> variable substitutions for the version and extension fields, so that
> the URL to check would look like:
> 
> https://pypi.debian.net/pyjsparser/pyjsparser@ANY_VERSION@@ARCHIVE_EXT@

Very convenient variables. Changed accordingly.

> * upstream changelog
>   - there is no upstream changelog

To my knowledge upstream does not provide such a file.

> * documentation/examples
>   - There is no documentation at all, aside from the simple example in
> the README. Perhaps this snippet could be installed as an example when
> installing the package?

Done (although I am not sure whether the way I implemented it is the
recommended way to do it). Suggestions how to improve the code are welcome.

> * tests
>   - there are no tests to run at build time (and therefore no
> autopkgtests to run for continuous integration whenever the package's
> dependencies are updated). Looking at the github repo there seems to
> be a significant testsuite that should really be available in the
> Debian source package to take advantage of autopkgtest. [lintian]

The testsuite available on Github requires js2py which is not in the
Debian archive yet (thus the testsuite introduces a circular dependence:
pyjsparser <-> js2py). js2py is the next package on my to-package list
(see above).

I see two options to move forward:

1. Wait for js2py being packaged and provide autopkgtests for pyjsparser
once js2py is available.

2. Install js2py using pip for the test.

None is really nice in my opinion. Which option do you prefer?

> I hope you find this useful - if you have any questions don't hesitate
> to ask the team (the Python list is visible and archived, IRC may get
> a quicker answer...). I'm a new DD and there are likely some things
> that the more experienced members of the team will notice.

Yes, your feedback was definitely very helpful and allowed me to learn
new things.

Thanks,

Peter

Bug#564857: Investment Proposal

[Nael M. Al Homoud]

Good day,

My associate from China wants to discuss a business investment deal with
you. I awaiting your response to enable us discuss about this business
investment

Nael M. Al Homoud
Executive Director & High Investment Committee Member@
The Arab Investment Co
www.taic.com [1]

  

Links:
--
[1] http://www.taic.com

Bug#944537: pyatspi ftbfs with python 3.8 as supported Python version

[Matthias Klose]

On 11.11.19 19:32, Samuel Thibault wrote:

Hello,

Matthias Klose, le lun. 11 nov. 2019 16:06:49 +0100, a ecrit:

pyatspi ftbfs with python 3.8 as supported Python version when running the
tests with 3.8. I didn't check why.


Do you have the build log somewhere? Normally test-suite.log will have


https://launchpad.net/ubuntu/+source/pyatspi/2.34.0-2ubuntu3


been printed there so we can get an idea why. I tried to reproduce this,
but it depends on 3.8 packages for python3-dbus, python3-gi, etc.


yes, I know. We will get these soonish in unstable...


Attached is a patch which is a bit more verbose, and runs the tests for all
supported python versions before failing.


Thanks! I have applied it.

Samuel

Bug#649310: Investment Proposal

[Nael M. Al Homoud]

Good day,

My associate from China wants to discuss a business investment deal with
you. I awaiting your response to enable us discuss about this business
investment

Nael M. Al Homoud
Executive Director & High Investment Committee Member@
The Arab Investment Co
www.taic.com [1]

  

Links:
--
[1] http://www.taic.com

Bug#942085: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Jeremy Bicha]

On Sun, Nov 3, 2019 at 4:44 AM Jeremy Bicha  wrote:
>
> ‪On Sun, Nov 3, 2019 at 12:12 AM ‫أحمد المحمودي (Ahmed El-Mahmoudy)‬‎
>  wrote:‬
> > On Sat, Nov 02, 2019 at 05:27:35AM -0400, Jeremy Bicha wrote:
> > > In this case, I see the new tag has already been pushed so I wouldn't
> > > worry about it here.
> >
> > Since you didn't upload yet, I made a couple of changes and pushed a
> > new tag.
>
> You have pushed 2 or 3 versions of the "0.4.1-2" tag. Please don't do
> this next time. If someone has already pulled a git tag, git by
> default won't change that tag. Next time, you should just bump the
> debian/changelog and tag to "0.4.1-3", then "0.4.1-4". It's better to
> "skip" numbers in your debian/changelog than have people who have
> checked out your git repo with different tagged commits.
>
> Your gnome-shell-extension-hijra package says that it depends on
> gnome-shell (>= 3.2), gnome-shell (<< 3.31) . Since gnome-shell 3.34
> is in Testing, hijra will not migrate to Testing with that dependency.
> Please check whether your extension works with gnome-shell from
> Testing. If so, you can bump that dependency. You might be able to
> remove the upper limit on the dependency, but someone will need to
> check whether the extension works with the new gnome-shell version
> every 6 months.
>
> I am going to delay uploading until the gnome-shell dependency issue is fixed.

Your python3-hijra package is uninstallable:

Setting up python3-hijra (0.4.1-2) ...
Sorry: TabError: inconsistent use of tabs and spaces in indentation
(HijriCal.py, line 83)
dpkg: error processing package python3-hijra (--configure):
 installed python3-hijra package post-installation script subprocess
returned error exit status 1
dpkg: dependency problems prevent configuration of hijra-applet:
 hijra-applet depends on python3-hijra (= 0.4.1-2); however:
  Package python3-hijra is not configured yet.


Thank you for adding me to the Salsa team as a Developer. I tried
pushing a minor change to othman's packaging repo, but the repo
settings are that only Maintainers can push to the master branch.
Please allow Developers to push there too.

I think there is a good chance that the hijra gnome-shell extension
will work with the gnome-shell version in Testing. If so, please drop
the upper gnome-shell dependency limit so that the gnome-shell
extension will be installable.

Thanks,
Jeremy Bicha

Bug#944554: RFS: air-quality-sensor/0.1.5-1 -- user space driver for AppliedSensor's Indoor Air Monitor

[Benedikt Wildenhain]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "air-quality-sensor". As I
only tested the program before on i386 and amd64, I didn't notice before
that the package currently in the Debian archive is unusable on armhf
(and possibly other architectures), the new release fixes this bug.

 * Package name: air-quality-sensor
   Version : 0.1.5-1
   Upstream Author : https://wiki.debian.org/DebianTinker
 * URL : 
https://salsa.debian.org/tinker-team/air-quality-sensor-debian/
 * License : GPL-3.0+
 * Vcs : 
https://salsa.debian.org/tinker-team/air-quality-sensor-debian/
   Section : utils

It builds those binary packages:

  air-quality-sensor - user space driver for AppliedSensor's Indoor Air Monitor

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

  https://mentors.debian.net/package/air-quality-sensor

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/air-quality-sensor/air-quality-sensor_0.1.5-1.dsc

Changes since the last upload:

   * New upstream release 0.1.5, now works on armhf
   * Updated signing key for package (old one expired)
   * Bump SV to 4.4.1 - no changes
   * Package now hosted on salsa.debian.org

Regards,
Benedikt Wildenhain

-- 
Benedikt Wildenhain, M.Sc., Wiss. Mitarbeiter - Hardwarenahe IT-Systeme
Hochschule Bochum - Bochum University of Applied Sciences
Campus Velbert/Heiligenhaus - http://www.hs-bochum.de/cvh/
Kettwiger Str. 20, Heiligenhaus, Raum 2-37, Tel +49 2056 5848-16744


signature.asc
Description: PGP signature

Bug#944520: isbg: please make the build reproducible

[Louis-Philippe Véronneau]

tag 944520 fixed-upstream

Hello!

This has already been fixed upstream [1] and will be part of the next
release.

Cheers (and thanks for the efforts),

[1]
https://github.com/isbg/isbg/commit/ba91de937a748c2b08609600b38b79cfa83f7e01

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#939483:

[Sam Hartman]

user debian-pyt...@lists.debian.org
usertag 939483 +py2keep

Bug#939571: uploaded a NMU, delayed 15 days

[Jameson Graef Rollins]

On Sat, Nov 09 2019, Gianfranco Costamagna  wrote:
> I rescheduled it to go in *now* :)
>
> thanks for doing it, I admit I lost a lot of time trying to trace it
> down and I failed, so help is appreciated!

I tested the new 0.10.0-5 version in unstable and it fixes the issue.
Thank you Georges and Gianfranco!

jamie.

Bug#944537: pyatspi ftbfs with python 3.8 as supported Python version

[Samuel Thibault]

Hello,

Matthias Klose, le lun. 11 nov. 2019 16:06:49 +0100, a ecrit:
> pyatspi ftbfs with python 3.8 as supported Python version when running the
> tests with 3.8. I didn't check why.

Do you have the build log somewhere? Normally test-suite.log will have
been printed there so we can get an idea why. I tried to reproduce this,
but it depends on 3.8 packages for python3-dbus, python3-gi, etc.

> Attached is a patch which is a bit more verbose, and runs the tests for all
> supported python versions before failing.

Thanks! I have applied it.

Samuel

Bug#944192: python3-h5py: 'import h5py' produces Open MPI message to stderr

[Jameson Graef Rollins]

forwarded 944192 https://github.com/h5py/h5py/issues/1433
thanks

Bug#887831: Adding sha256 support into jigdo tools (jigdo and jigit)

[Steve McIntyre]

[ Sent to multiple people and Debian bugs - please respect the
  reply-to and follow up on the debian-cd list if you have
  replies/comments. ]

Hi folks!

For a while we've been working to move away from using MD5 in various
parts of Debian, and jigdo is one of the last few things that's still
using it now. We've had a few bugs raised about this (#887837 and
#887831) and quite some discussion recently. I've been hacking on
jigdo and jigit to add support for a new v2 jigdo format which
switches from using md5 for internal checksumming to using sha256
instead, and I'm just about done now. I have a few remaining things to
do next, that I'd like to ask for some help with (please!) - see
further down. Prompt responses would be appreciated if possible.

jigdo
=

I've extended jigdo to support both formats (old and new). Building a
new jigdo/template pair requires the user to specify which format they
want, while creating/verifying an image will auto-detect the format
automatically from the input data. I think that is clearly the best
design here.

I'm *most* worried about updating the various clients that people may
have in the field, using jigdo-lite/jigdo-mirror to make ISO images
from the jigdo data that we release with Debian, so that was my first
priority. I'm *not* aware of anybody actually using jigdo-file itself
to create new jigdo/template pairs these days, but I've done the right
thing anyway and added support for sha256 here too.

I've forked from Richard's last 0.7.3 release, and put it into my own git
server at

  
https://git.einval.com/cgi-bin/gitweb.cgi?p=jigdo.git;a=shortlog;h=refs/heads/upstream

along with the various fixes that we already had in Debian since that
release.

I've built and tested binaries locally with both jigdo formats,
including on Windows. All looks good here. \o/

jigit/libjte


I've also updated and extended my own jigit/libjte code to work with
both formats, and I'm about to release those. The changes are not too
big, and the external API for libjte is *very* close to what we had
before. I've already updated a local copy of xorriso to use it, and
the changes are tiny! \o/

genisoimage
===

I am *not* planning to update my code in genisoimage to use the new
jigdo v2 format. We don't use genisoimage at all in the Debian images
team any more, having moved to xorriso instead. The only reason to
even think about updating genisoimage would be for powerpc
images. While the debian-ports people are still supporting powerpc and
periodically releasing new unofficial CD/DVD images for it, I don't
think jigdo is needed here. *If you think differently*, let me know...

Publishing the new format
=

debian-cd and some of our backend setup on our cdimage sites will need
some minor updates to support the new sha256 format as well, but
that's not urgent yet. We must *not* switch to publishing the new v2
jigdo format for a while (I'm thinking maybe 12 months?), to give
people the chance to update their clients. I also don't want to leave
this *too* long, as the Debian ftpmaster team and others would like to
ditch md5 soon.

We'll need to make noise about this, and update web pages etc. to
mention the change. New links to new tools, etc.

Richard
===

With your blessing, I'd like to release my new code as jigdo version
0.8.0. If you're ok with that, could you please update your jigdo web
pages to mention this? I'll add a page at

  https://www.einval.com/~steve/software/jigdo/

that you can link to. I'll add some docs, and links back to you (of
course!) and download links for Windows binaries etc. So far I've left
the creator information in newer jigdo files pointing at your site as
you're the inventor, but I'm also happy to change that if you'd like
and reduce your web traffic - just let me know please! :-)

Mattias
===

You're the person normally working with people using jigdo tools to
mirror Debian's CD/DVD releases. We'll need to ask people to update
all their tools to enable using the new v2 format. What systems are
they normally using? I'm guessing a mix of Debian systems of various
versions, plus maybe a few other OSes? I'm happy to do Debian
backports builds of the new tool versions to help support people, but
I don't know:

 (a) what else might need to be supported
 (b) what timescale these people would be happy with or updates

Obviously, we don't want to be pushing new format versions until the
mirror network is ready to take them. But we want that to be as soon
as practically possible.

Thomas
==

You've done an awesome job with xorriso and the libjte integration!
It's been really easy to drop in my new libjte code and have xorriso
generate the new format. I've got a simple diff right now that I'm
just cleaning up and will send you shortly.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me