Bug#759178: Top Urgent

[Hassan Al Redha]

Hello dear
I have a business to discuss with you please reply to confirm that this is
your email
Regards
Hassan Al Redha

Bug#936924: Moving libsvm to Debian Science team

[Andreas Tille]

Hi Chen-Tse,

I'm maintaining a package that depends from libsvm.  Due to bug #936924
that did not received any response since August it is in danger to be
removed from testing so I'm interested that this bug will be fixed.
When looking at the package I realised that while it would fit into
Debian Science team scope it is not team maintained nor is there any
repository in Salsa.  That's why I have the following suggestion:

  1. I create a repository on Salsa
  2. Move the package to Debian Science team maintenance
 and add you as Uploader
  3. Drop Python2 package and close bug #936924
  4. May be migrate packaging from cdbs to dh

If I do not hear from you until Monday I assume you agree with this
plan and will do so.

Kind regards

 Andreas.

PS: @Christian: I noticed that you and Chen-Tse are maintaining
liblinear.  I have just removed Python2 package and reassigned
#936889 to ftp.debian.org to make sure python-liblinear will be
removed.  Thus libsvm can be dealt as suggested.

-- 
http://fam-tille.de

Bug#936889: Please remove python-liblinear (Was: liblinear: Python2 removal in sid/bullseye)

[Andreas Tille]

Control: reassign -1

Just uploaded liblinear without the python2 package - please
remove it from testing

Bug#936932: libvigraimpex: Python2 removal in sid/bullseye

[Andreas Metzler]

On 2019-10-01 Andreas Tille  wrote:
> Control: tags -1 help

> Hi,

> I tried hard to port libvigraimpex to Python3 in Git[1] and think I
> managed.

Hello Andreas,

I did not get far trying to build what is currently on salsa:

make[1]: Entering directory '/tmp/VIGRA/libvigraimpex-1.11.1'
mkdir -p obj.python3.8/
cd obj.python3.8/ && CXXFLAGS=-fno-strict-aliasing cmake .. 
-DCMAKE_INSTALL_PREFIX=/usr -DLIB_SUFFIX="/x86_64-linux-gnu/" 
-DCMAKE_VERBOSE_MAKEFILE=ON -DWITH_OPENEXR=ON -DCMAKE_C_FLAGS_RELEASE="-g -O2 
-fdebug-prefix-map=/tmp/VIGRA/libvigraimpex-1.11.1=. -fstack-protector-strong 
-Wformat -Werror=format-security -pipe -Wdate-time -D_FORTIFY_SOURCE=2" 
-DCMAKE_CXX_FLAGS_RELEASE="-g -O2 
-fdebug-prefix-map=/tmp/VIGRA/libvigraimpex-1.11.1=. -fstack-protector-strong 
-Wformat -Werror=format-security -pipe -Wdate-time -D_FORTIFY_SOURCE=2" 
-DCMAKE_SHARED_LINKER_FLAGS_RELEASE="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now"  
-DPYTHON_EXECUTABLE=/usr/bin/python3.8 3.7 
-DPYTHON_INCLUDE_DIR=/usr/include/python3.8 3.7/ 
-DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython3.8 3.7.so 
-DBoost_PYTHON_LIBRARY_RELEASE=/usr/lib/x86_64-linux-gnu/libboost_python-py38 
37.so
CMake Error: The source directory 
"/tmp/VIGRA/libvigraimpex-1.11.1/obj.python3.8/37.so" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
make[1]: *** [debian/rules:89: obj.python3.8/CMakeCache.txt] Error 1


> Unfortunately there is a C++ error uncovered which I feel
> unable to fix:

> ...
> /build/libvigraimpex-1.11.1+dfsg/vigranumpy/src/core/vigranumpycore.cxx: In 
> function 'vigra::UInt32 vigra::pychecksum(const boost::python::str&)':
> /build/libvigraimpex-1.11.1+dfsg/vigranumpy/src/core/vigranumpycore.cxx:64:39:
>  error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
>64 |  char * data = PyUnicode_AsUTF8AndSize(s.ptr(), );
>   |~~~^~~~
>   |   |
>   |   const char*
> make[4]: *** 
> [vigranumpy/src/core/CMakeFiles/vigranumpy_core.dir/build.make:66: 
> vigranumpy/src/core/CMakeFiles/vigranumpy_core.dir/vigranumpycore.cxx.o] 
> Error 1
> make[4]: Leaving directory '/build/libvigraimpex-1.11.1+dfsg/obj.python3.7'


> Any help would be welcome (or Daniel feel free to continue from here).

I suspect Fedora's patch would help.
https://src.fedoraproject.org/rpms/vigra/blob/master/f/vigra-1.11.1.py37.patch

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#947111: python-thinc: FTBFS with Python 3.8

[Graham Inggs]

Source: python-thinc
Version: 6.12.1-1
Severity: serious
Tags: ftbfs

Hi Maintainer

A recent rebuild of python-thinc with Python 3.8 failed [1].
I've copied what I hope is the relevant part of the log below.

This may be related to the upload of wheel 0.33.6-1 on 2019-10-17.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=python-thinc


Note: Bypassing https://pypi.org/simple/wheel/ (disallowed host; see
http://bit.ly/2hrImnY for details).


Note: Bypassing https://pypi.org/simple/ (disallowed host; see
http://bit.ly/2hrImnY for details).

No local packages or working download links found for wheel<0.33.0,>=0.32.0
Cythonizing sources
Traceback (most recent call last):
  File "setup.py", line 211, in 
setup_package()
  File "setup.py", line 150, in setup_package
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
144, in setup
_install_setup_requires(attrs)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
139, in _install_setup_requires
dist.fetch_build_eggs(dist.setup_requires)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 717,
in fetch_build_eggs
resolved_dists = pkg_resources.working_set.resolve(
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
line 780, in resolve
dist = best[req.key] = env.best_match(
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
line 1065, in best_match
return self.obtain(req, installer)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
line 1077, in obtain
return installer(requirement)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 787,
in fetch_build_egg
return cmd.easy_install(req)
  File "/usr/lib/python3/dist-packages/setuptools/command/easy_install.py",
line 698, in easy_install
raise DistutilsError(msg)
distutils.errors.DistutilsError: Could not find suitable distribution
for Requirement.parse('wheel<0.33.0,>=0.32.0')
E: pybuild pybuild:341: configure: plugin distutils failed with: exit
code=1: python3.8 setup.py config

Bug#947110: ITP: pyglossary -- tool for workig with dictionary databases

[Emfox Zhou]

Package: wnpp
Severity: wishlist
Owner: Emfox Zhou 

* Package name: pyglossary
  Version : 3.2.1
  Upstream Author : Saeed Rasooli 
* URL : https://github.com/ilius/pyglossary
* License : GPLv3
  Programming Lang: Python
  Description : tool for workig with dictionary databases

Binary package names: python-pyglossary

 PyGlossary is a tool for converting dictionary files aka glossaries,
 from/to various formats used by different dictionary applications
 .
 Screenshots
 ---
 .
 ![](
https://raw.githubusercontent.com/ilius/pyglossary/resources/screenshots/30-gtk-bgl-stardict-nl-en.png
)
 .
 Linux - (New) Gtk3-based intreface
 .
 
 .
 ![](
https://raw.githubusercontent.com/ilius/pyglossary/resources/screenshots/30-tk-bgl-mdict-fr-zh-win7.png
)
 .
 Windows - Tkinter-based interface
 .
 
 .
 ![](
https://raw.githubusercontent.com/ilius/pyglossary/resources/screenshots/30-cmd-bgl-apple-ru-de.png
)
 .
 Linux - command line interface
 .
 Supported formats
 -
 .
 | Format| Extension | Read  | Write |
 |---|---|:-:|:-:|
 | ABBYY Lingvo DSL  | .dsl  |   ✔   |   |
 | AppleDict Source  | .xml  |   |   ✔   |
 | Babylon   | .bgl  |   ✔   |   |
 | Babylon Source| .gls  |   |   ✔   |
 | CC-CEDICT |   |   ✔   |   |
 | CSV   | .csv  |   ✔   |   ✔   |
 | DictionaryForMIDs |   |   ✔   |   ✔   |
 | DICTD dictionary server   | .index|   ✔   |   ✔   |
 | Editable Linked List of Entries   | .edlin|   ✔   |   ✔   |
 | FreeDict  | .tei  |   |   ✔   |
 | Gettext Source| .po   |   ✔   |   ✔   |
 | Lingoes Source (LDF)  | .ldf  |   ✔   |   ✔   |
 | Octopus MDict | .mdx  |   ✔   |   |
 | Octopus MDict Source  | .txt  |   ✔   |   ✔   |
 | Omnidic   |   |   |   ✔   |
 | Sdictionary Binary| .dct  |   ✔   |   |
 | Sdictionary Source| .sdct |   |   ✔   |
 | SQL   | .sql  |   |   ✔   |
 | StarDict  | .ifo  |   ✔   |   ✔   |
 | Tabfile   | .txt, .dic|   ✔   |   ✔   |
 | TreeDict  |   |   |   ✔   |
 | XDXF  | .xdxf |   ✔   |   |

-- 
Emfox Zhou

GnuPG Public Key: 0x1DEB

Bug#947109: sunpy: FTBFS with Python 3.8

[Graham Inggs]

Source: sunpy
Version: 1.0.3-2
Severity: serious
Tags: ftbfs patch

Hi Maintainer

A recent rebuild of sunpy with Python 3.8 failed [1].
I've copied what I hope is the relevant part of the log below.

A patch is available from Ubuntu [2].

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=sunpy
[2] 
https://launchpadlibrarian.net/448213313/sunpy_1.0.3-2_1.0.3-2ubuntu2.diff.gz


_ test_sysinfo _

def test_sysinfo():
output = sunpy.util.get_sys_dict()
assert isinstance(output, dict)
>   sunpy.system_info()

sunpy/util/tests/test_sysinfo.py:7:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

def system_info():
"""
Takes dictionary from sys_info() and prints the contents in an
attractive
fashion.
"""
sys_prop = get_sys_dict()

# title
print("==")
print("SunPy Installation Information")
print("==\n")

# general properties
print("###")
print("General")
print("###")
# OS and architecture information

for sys_info in ['Time', 'System', 'Processor', 'Arch', 'SunPy']:
print('{} : {}'.format(sys_info, sys_prop[sys_info]))

if sys_prop['System'] == "Linux":
>   distro = " ".join(platform.linux_distribution())
E   AttributeError: module 'platform' has no attribute
'linux_distribution'

sunpy/util/sysinfo.py:121: AttributeError

Bug#936730: impacket: Python2 removal in sid/bullseye

[peter green]

severity 936730 serious
thanks

python-impacket depends on python-flask, which depends on the python-click 
binary package, which depends on the python-colorama binary package, which is 
no longer built by the python-colorama source package.

Bug#929045: mark python-cycler Multi-Arch: foreign

[Helmut Grohne]

Hi Sandro,

On Fri, Dec 20, 2019 at 10:30:26PM -0500, Sandro Tosi wrote:
> there are in the order of the thousands python packages in Debian
> (let's guess-timate that half are pure-python, the remaining are
> extensions or depending on extensions), what i would prefer is a
> solution that doesnt require to modify (either by changing something
> or uploading the package) all of these packages by hand.

I am sorry to disappoint you. Every solution will require modifying
thousands of packages. That is the nature of the problem. We can
somewhat choose which ones to modify to minimize the number. Using
Multi-Arch: foreign where possible is a technique to lower the number.

> i'll add it to python-cycler

Thank you.

Helmut

Bug#936522: flask: Python2 removal in sid/bullseye

[peter green]

severity 936522 serious
thanks

python-flask depends on the python-click binary package, which depends on the 
python-colorama binary package, which is no longer built by the python-colorama 
source package.

Bug#937307: polenum: Python2 removal in sid/bullseye

[peter green]

severity 937307 serious
thanks

polenum depends on the python-colorama binary package, which is no longer built 
by the python-colorama source package.

Bug#947108: Xorg problem preventing bootup

[Casey Cullen]

Package:  X.org
Version:  1.20.6
Architecture:  PPC64

When trying to boot into Debian PPC64 on a "cyrus plus" board (Freescale
P5020 e5500 core based PPC64 system), an error is displayed. Below is the
log. This only occurs on PPC64 (does not occur on PowerPC).
Thank you for your assistance.

[   922.574]
X.Org X Server 1.20.6
X Protocol Version 11, Revision 0
[   922.592] Build Operating System: Linux 4.19.0-5-powerpc64 ppc64 Debian
[   922.598] Current Operating System: Linux Fienix
5.5-a2_A-EON_X5000-05280-g89d577d3-dirty #1 SMP PREEMPT Wed Nov 27
12:53:57 CET 2019 ppc64
[   922.598] Kernel command line: root=/dev/sdb2 rootdelay=5
[   922.612] Build Date: 25 November 2019  09:49:09AM
[   922.618] xorg-server 2:1.20.6-1 (https://www.debian.org/support)
[   922.625] Current version of pixman: 0.36.0
[   922.638] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   922.638] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   922.666] (==) Log file: "/home/fienix/.local/share/xorg/Xorg.0.log",
Time: Sat Dec 21 00:37:38 2019
[   922.673] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   922.674] (==) No Layout section.  Using the first Screen section.
[   922.674] (==) No screen section available. Using defaults.
[   922.674] (**) |-->Screen "Default Screen Section" (0)
[   922.674] (**) |   |-->Monitor ""
[   922.675] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   922.675] (==) Automatically adding devices
[   922.675] (==) Automatically enabling devices
[   922.675] (==) Automatically adding GPU devices
[   922.675] (==) Max clients allowed: 256, resource mask: 0x1f
[   922.675] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
exist.
[   922.675] Entry deleted from font path.
[   922.675] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   922.675] (==) ModulePath set to "/usr/lib/xorg/modules"
[   922.675] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable
AutoAddDevices.
[   922.675] (II) Loader magic: 0x1279f6ad0
[   922.675] (II) Module ABI versions:
[   922.675] X.Org ANSI C Emulation: 0.4
[   922.675] X.Org Video Driver: 24.0
[   922.675] X.Org XInput driver : 24.1
[   922.675] X.Org Server Extension : 10.0
[   922.677] (++) using VT number 1

[   922.680] (II) systemd-logind: took control of session
/org/freedesktop/login1/session/c1
[   922.683] (II) xfree86: Adding drm device (/dev/dri/card0)
[   922.684] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11
paused 0
[   922.690] (--) PCI:*(1@0:0:0) 1002:6738:174b:e177 rev 0, Mem @
0xc/268435456, 0xc1000/131072, I/O @ 0x1000/256, BIOS @
0x/131072
[   922.690] (II) LoadModule: "glx"
[   922.691] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   922.695] (II) Module glx: vendor="X.Org Foundation"
[   922.695] compiled for 1.20.6, module version = 1.0.0
[   922.695] ABI class: X.Org Server Extension, version 10.0
[   922.695] (II) Applying OutputClass "Radeon" to /dev/dri/card0
[   922.695] loading driver: radeon
[   922.695] (==) Matched radeon as autoconfigured driver 0
[   922.696] (==) Matched ati as autoconfigured driver 1
[   922.696] (==) Matched modesetting as autoconfigured driver 2
[   922.696] (==) Matched fbdev as autoconfigured driver 3
[   922.696] (==) Assigned the driver to the xf86ConfigLayout
[   922.696] (II) LoadModule: "radeon"
[   922.696] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[   922.697] (II) Module radeon: vendor="X.Org Foundation"
[   922.697] compiled for 1.20.4, module version = 19.1.0
[   922.697] Module class: X.Org Video Driver
[   922.697] ABI class: X.Org Video Driver, version 24.0
[   922.697] (II) LoadModule: "ati"
[   922.698] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[   922.698] (II) Module ati: vendor="X.Org Foundation"
[   922.698] compiled for 1.20.4, module version = 19.1.0
[   922.698] Module class: X.Org Video Driver
[   922.698] ABI class: X.Org Video Driver, version 24.0
[   922.698] (II) LoadModule: "modesetting"
[   922.698] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[   922.699] (II) Module modesetting: vendor="X.Org Foundation"
[   922.699] compiled for 1.20.6, module version = 1.20.6
[   922.699] Module class: X.Org Video Driver
[   922.699] ABI class: X.Org Video Driver, version 24.0
[   922.699] (II) LoadModule: "fbdev"
[   922.699] (II) Loading 

Bug#947103: statsmodels autopkgtest failing.

[peter green]

On 21/12/2019 02:33, peter green wrote:

The pure unstable test is failing to install python-statsmodels, I have no idea 
why.


According to ginggs on IRC this is likely due to the arch all build failure in 
numpy.

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Joshua Hudson]

Forgive me if I'm not quite so sure, because this is the second time
I've had an undiagnosable problem where systemd appeared to be waiting
for something to start that was already started.

On my home system I had to roll back systemd altogether because it
would hang for many minutes on /home and never get it mounted, but
once logging in as root, fsck /home; mount /home worked the first
time. This was undiagnosable and the system was effectively
nonfunctional, so I had to roll it back immediately. Thankfully
jesse's sysvinit package was still in apt's cache.

Bug#929045: mark python-cycler Multi-Arch: foreign

[Sandro Tosi]

> > i'd really like not to add this m-a tag tbh
>
> I think we need to talk about this. You didn't give a reasons for why
> you dislike it. Let me give my reasons for doing it to avoid more back
> and forth.
>
> There is prior art. A fair number of python modules in Architecture: all
> packages (around 100) are already tagged Multi-Arch: foreign.  Notable
> examples include python3-six, python3-pkg-resources and
> python3-distutils. Why would you want python modules to be
> inconsistently maintained?
>
> We're not adding such marking for the fun of it. There is a concrete
> underlying problem being solved. If you don't like my solution, can you
> think of a different solution to the underlying problem? You can get an
> overview of non-temporary satisfiability issues in unstable at
> https://bootstrap.debian.net/cross_all.html (huge html). You'll find
> lots of satisfiability issues involve python modules. I agree that
> sometimes marking modules Multi-Arch: foreign can be wrong (e.g. for
> extension modules or modules that have a dependency on an extension
> module), but why not use the easy solution when it is available?
>
> Please treat python-cycler as an example instance of a problem class
> here.  It really affects very many packages and we want a solution that
> is acceptable to many packages. Beware that we may end up changing
> around 1000 packages to fully solve this, so we better get this right.

there are in the order of the thousands python packages in Debian
(let's guess-timate that half are pure-python, the remaining are
extensions or depending on extensions), what i would prefer is a
solution that doesnt require to modify (either by changing something
or uploading the package) all of these packages by hand.

i'll add it to python-cycler

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

Bug#947107: iwyu: crash (SIGABRT): Assertion failed: Cycle in include-mapping

[Paul Wise]

Package: iwyu
Version: 8.0-2
Severity: normal
File: /usr/bin/include-what-you-use
Usertags: crash

I found a case that crashes iwyu with a SIGABRT:

$ sudo apt -qq install libboost-python-dev libboost-dev

$ echo '#include ' > foo.cpp

$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 
'thread apply all bt full' --args include-what-you-use foo.cpp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Cycle in include-mapping:
   ->
   ->
  
/build/iwyu-oe4HdZ/iwyu-8.0/iwyu_include_picker.cc:928: Assertion failed: Cycle 
in include-mapping

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x73ef7535 in __GI_abort () at abort.c:79
#2  0x5570ee58 in 
include_what_you_use::FatalMessageEmitter::~FatalMessageEmitter() ()
#3  0x55933969 in include_what_you_use::(anonymous 
namespace)::MakeNodeTransitive(std::map, std::allocator >, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > > > > >*, 
std::map, 
std::allocator >, include_what_you_use::(anonymous 
namespace)::TransitiveStatus, std::less, std::allocator > >, 
std::allocator, std::allocator > const, 
include_what_you_use::(anonymous namespace)::TransitiveStatus> > >*, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > >*, 
std::__cxx11::basic_string, std::allocator > 
const&) ()
#4  0x55933a6e in include_what_you_use::(anonymous 
namespace)::MakeNodeTransitive(std::map, std::allocator >, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > > > > >*, 
std::map, 
std::allocator >, include_what_you_use::(anonymous 
namespace)::TransitiveStatus, std::less, std::allocator > >, 
std::allocator, std::allocator > const, 
include_what_you_use::(anonymous namespace)::TransitiveStatus> > >*, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > >*, 
std::__cxx11::basic_string, std::allocator > 
const&) ()
#5  0x55933a6e in include_what_you_use::(anonymous 
namespace)::MakeNodeTransitive(std::map, std::allocator >, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > > > > >*, 
std::map, 
std::allocator >, include_what_you_use::(anonymous 
namespace)::TransitiveStatus, std::less, std::allocator > >, 
std::allocator, std::allocator > const, 
include_what_you_use::(anonymous namespace)::TransitiveStatus> > >*, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > >*, 
std::__cxx11::basic_string, std::allocator > 
const&) ()
#6  0x55933bc2 in include_what_you_use::(anonymous 
namespace)::MakeMapTransitive(std::map, std::allocator >, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, 
std::vector, 
std::allocator >, std::allocator, std::allocator > > > > > >*) ()
#7  0x559356f4 in 
include_what_you_use::IncludePicker::FinalizeAddedIncludes() ()
#8  0x5596bcff in 
include_what_you_use::IwyuPreprocessorInfo::HandlePreprocessingDone() ()
#9  0x55720ae5 in 
include_what_you_use::IwyuAstConsumer::HandleTranslationUnit(clang::ASTContext&)
 ()
#10 0x56392393 in clang::ParseAST(clang::Sema&, bool, bool) ()
#11 0x5616312f in clang::FrontendAction::Execute() ()
#12 0x56122ca8 in 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#13 0x557225f6 in main ()
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 0, 140737287603840, 0, 10, 0, 895, 0, 0, 
281470681751424, 0, 0, 0, 0, 0, 0}}
pid = 
tid = 
ret = 
#1  0x73ef7535 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x170014, sa_sigaction = 
0x170014}, sa_mask = {__val = {4294967321, 103079215120, 47244640260, 
55834574858, 64424509462, 140737488343792, 140737288834472, 10, 10, 
140737488343792, 140737288834906, 1, 140737287603840, 140737287607648, 
140737286259626, 140737289557536}}, sa_flags = 0, sa_restorer = 0x0}
sigs = {__val = {32, 0 }}
#2  0x5570ee58 in 
include_what_you_use::FatalMessageEmitter::~FatalMessageEmitter() ()
No symbol table info available.
#3  0x55933969 in include_what_you_use::(anonymous 

Bug#947106: python3-augeas: Please upload new version of package 1.0.3

[Sunil Mohan Adapa]

Package: python3-augeas
Version: 0.5.0-1
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

The newer version of package available in upstream git repository use cffi
library instead of ctypes to load the C augeas library. This sidesteps the
problem described in #944364. One could also take this opportunity to migrate
the git repository to Salsa (perhaps under the python-team).

I have done the necessary work for the new release, the patches are attached
with following changes:

  * control: Update list of dependencies
  * control: Remove unnecessary python version fields
  * control: Specify that rules file does not require root
  * control: Update standards version to 4.4.1. No changes required.
  * control: Enable autopkgtest-pkg-python
  * control: Update debhelper compatibility level to 12
  * rules: Run tests during build

Thank you,

- --
Sunil



- -- System Information:
Debian Release: 10.2
  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_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-augeas depends on:
ii  libaugeas0  1.11.0-3
ii  python3 3.7.3-1

python3-augeas recommends no packages.

python3-augeas suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAl39hzoRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfJoYA/+NOZEDuYybEq9g1CfHNx23xUINGysjxAp
qNEpuUYWRkvtHHDKjuCtaKeUsim0TQ4tWcbCpv7xNzMIOZY6PuZv75Jm3Kn8hAo7
ocO9c4osIVUhj05+hkaBA5xVXDFnulZDqn63LY69Df6PKN/0k4ov1kLsBpZ/Wle0
cUFynK5018ticnDVTaI/F6Lzu6gOr6+0H4TABW4PV+pRAMHz0l286rRMOFurid5A
MlmQlAug3yyrKwDP7WQiuujTxGisNWJYmIqkfETe/ibExkNNbUaJF73gyrmJu2e/
lIrtG4E+ysJrmGXAR+eoP/HNRczbjnXdwgdexD2A26RTyVB5lSi1kMS0COZRf0PE
/EckOm7hOXtk2IHmNHJJyIwlXTGjuA6kqo9Jnt6gKvWzwRdTaAfLmI4rh8mEIELG
1n5OUKXDNrJUNEQlWzqBNbNV7L876qSLcAHlSc0/1FatFMvGqsosggnmDyCuTkQN
TzM1xuAksbiUfOKUN9z+rsx9sjCwIewDWuoG5oL5NVHWskijTOrcK6Sowo3ukV3D
t1RxCF34nHWpsBy54E4kYOXs+IcUOnU8fztSfbI2M77XGuVUWQeTU3LyryTPMESd
1v1461vorHTa1+WwSEeZ3EQusOCzWWO3CdRdy0uJbTBS7ljqplIMbwo+O0obaOps
CTnyx2IAyig=
=ePp7
-END PGP SIGNATURE-
>From 7f8cb9c9adbb8cc0bf16f394ff0bae23db9f1a8d Mon Sep 17 00:00:00 2001
From: Sandro Tosi 
Date: Fri, 20 Dec 2019 16:30:56 -0800
Subject: [PATCH 01/10] Release 0.5.0-1.1, non-maintainer upload

---
 debian/changelog |  7 +++
 debian/control   | 15 ---
 debian/rules |  3 +--
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 465320f..cabcd63 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-augeas (0.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937588, #734557
+
+ -- Sandro Tosi   Wed, 16 Oct 2019 22:17:14 -0400
+
 python-augeas (0.5.0-1) unstable; urgency=low
 
   * New upstream release
diff --git a/debian/control b/debian/control
index 2e7be81..f2e571e 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,6 @@ Build-Depends:
  debhelper (>= 9~),
  dh-python,
  libaugeas0 (>= 0.7.2),
- python-all (>= 2.6.5),
  python3-all
 Standards-Version: 3.9.6
 X-Python-Version: >= 2.6
@@ -15,20 +14,6 @@ Homepage: http://augeas.net/
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-augeas.git
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/python-augeas.git
 
-Package: python-augeas
-Architecture: all
-Depends:
- libaugeas0 (>= 0.7.2),
- ${misc:Depends},
- ${python:Depends}
-Description: Python bindings for Augeas
- Augeas is a library and command line tool that focuses
- on the most basic problem in handling Linux configurations
- programmatically: editing actual configuration files in a
- controlled manner.
- .
- This module provides a Python interface to the Augeas API.
-
 Package: python3-augeas
 Architecture: all
 Depends:
diff --git a/debian/rules b/debian/rules
index 9b2702b..94d7f97 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,8 +2,7 @@
 
 export DH_VERBOSE=1
 export PYBUILD_NAME=augeas
-export PYBUILD_DESTDIR_python2=debian/python-augeas/
 export PYBUILD_DESTDIR_python3=debian/python3-augeas/
 
 %:
-   dh $@ --buildsystem=pybuild --with python2,python3
+   dh $@ --buildsystem=pybuild --with python3
-- 
2.20.1

>From 45c94f8f71d8db4bba7bd308fa3bc83e68275758 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Fri, 20 Dec 2019 16:35:38 -0800
Subject: [PATCH 02/10] New upstream version 1.0.3

---
 .gitignore  | 101 +
 .travis.yml |  31 --
 Makefile|   5 +-
 augeas.py => augeas/__init__.py | 192 
 

Bug#934870: statsmodels: Please drop python2 support

[peter green]

Severity 934870 serious
Thanks

statsmodels in testing build-depends on python-cvxopt, which is no longer 
present in testing or unstable.

This is fixed in the unstable statsmodels package (by dropping the python 2 
binary package), unfortunately that is failing to migrate due to an autopkgtest 
failure.

Bug#947105: puppet: Default install uses outdated configuration file and directory locations

[Todd H. Poole]

Package: puppet
Version: 5.5.10-4
Severity: important

Hi Maintainers,

In early 2015, upstream Puppet changed the location of several core config 
files and directories with the release of Puppet 4.0. Today, almost 5 years 
later, a default install of Puppet 5.5 on Debian 10 still uses those old config 
file and directory locations.

For example, per Debian's Puppet man page[1], the upstream Puppet docs[2], and 
innumerable web search results, the default config directory ("confdir") for 
Puppet should be /etc/puppetlabs/puppet/, but in Puppet 5.5.10-4 on Debian 10, 
it's still /etc/puppet/.

Similar issues exist for all other config file and directory locations changed 
in Puppet 4.0[3].

Although not package-breaking, inconsistencies like these present usability 
problems for those coming from other distributions or for those who were 
previously using Puppet's official open source packages.

Could a Maintainer update the Debian Puppet package so that Puppet's behavior 
on Debian matches the documented behavior in the man pages, upstream docs, and 
upstream packages?

[1] https://manpages.debian.org/buster/puppet/puppet.conf.5.en.html
[2] https://puppet.com/docs/puppet/5.5/dirs_confdir.html
[3] https://puppet.com/docs/puppet/5.5/whered_it_go.html

Thank you,
Todd H. Poole


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

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

Versions of packages puppet depends on:
ii  adduser  3.118
ii  facter   3.11.0-2+deb10u1
ii  hiera3.2.0-2
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2019051400
ii  ruby 1:2.5.1
ii  ruby-augeas  1:0.5.0-3+b6
ii  ruby-deep-merge  1.1.1-1
ii  ruby-shadow  2.5.0-1+b1

Versions of packages puppet recommends:
ii  debconf-utils  1.5.71
ii  lsb-release10.2019051400
ii  ruby-selinux   2.8-1+b1

Versions of packages puppet suggests:
pn  ruby-hocon  
pn  ruby-rrd

-- no debconf information

Bug#947093: RFS: filezilla/3.39.0-2+deb10u1 [RC] -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

On Sat, 2019-12-21 at 02:06 +0100, Adam Borowski wrote:
> Control: tags -1 +moreinfo
> 
> On Fri, Dec 20, 2019 at 09:53:51PM +, Phil Wyett wrote:
> >  * Package name: filezilla
> >Version : 3.39.0-2+deb10u1
> > Changes since the last upload:
> > 
> >* Team Upload
> >* Added: 02_untrusted_search_path.patch - CVE-2019-5429. (Closes:
> > #928282)
> 
> Hi!
> This is a stable update, and one that doesn't go through the security
> team.
> Thus, you first need to obtain the Release Team's approval.  This is
> done by
> reporting a "stable proposed updates" bug on "release.debian.org"; the
> bug
> needs to include debdiff of your proposed update.
> 
> Only once approval is granted, we may proceed with the upload.
> 
> There's more documentation in the developers-reference, section 5.5.1.
> 
> Thanks for taking care of this package!
> 
> 
> Meow!

Hi,

Thanks for the information. I have processed this via the correct method
now and am awaiting automated response etx.

Regards

Phil

-- 

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

Twitter: @kathenasorg

IRC: kathenas



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

Bug#897281: RM time

[Adam Borowski]

Control: clone -1 -2
Control: retitle -2 RM: doc-debian-fr -- RoQA; ancient docs
Control: severity -2 normal
Control: reassign -2 ftp.debian.org

On 2018-05-01, Moritz Muehlenhoff wrote:
> These docs have been updated the last time over 12 years ago, is this
> actually still useful or rather misleading and should be removed?

19½ months later, it is clear no one cares about this package.
Reassigning to our fine FTPfolks to do the last rites.


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

Bug#947103: statsmodels autopkgtest failing.

[peter green]

Package: statsmodels
Version: 0.10.2-1
Severity: serious

Statsmodels autopkgtest is failing, both in the unstable to testing migration 
tests, and in the pure unstable tests.

The migration test is failing with the following error ( 
https://ci.debian.net/data/autopkgtest/testing/amd64/s/statsmodels/3711641/log.gz
 )

_ ERROR collecting tsa/statespace/tests/test_kalman.py _
ImportError while importing test module 
'/usr/lib/python3/dist-packages/statsmodels/tsa/statespace/tests/test_kalman.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/statsmodels/tsa/statespace/tests/test_kalman.py:48: in 

from statsmodels.tsa.statespace import _statespace as ss
E   ImportError: cannot import name '_statespace' from 
'statsmodels.tsa.statespace' 
(/usr/lib/python3/dist-packages/statsmodels/tsa/statespace/__init__.py)
=== warnings summary ===

The pure unstable test is failing to install python-statsmodels, I have no idea 
why.

Bug#947102: buster-pu: filezilla/3.39.0-2+deb10u1 [RC] -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

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

Hi,

Attached is a debdiff that resolves CVE in package 'filezilla' on
buster.

filezilla (3.39.0-2+deb10u1) buster-security; urgency=high

  * Team Upload
  * Added: 02_untrusted_search_path.patch - CVE-2019-5429. (Closes:
#928282)

 -- Phil Wyett   Wed, 18 Dec 2019 20:25:54


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928282
https://security-tracker.debian.org/tracker/CVE-2019-5429

Regards

Phil

-- 

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

Twitter: @kathenasorg

IRC: kathenas




diff -Nru filezilla-3.39.0/debian/changelog filezilla-3.39.0/debian/changelog
--- filezilla-3.39.0/debian/changelog	2019-01-25 10:37:54.0 +
+++ filezilla-3.39.0/debian/changelog	2019-12-18 20:25:54.0 +
@@ -1,3 +1,10 @@
+filezilla (3.39.0-2+deb10u1) buster-security; urgency=high
+
+  * Team Upload
+  * Added: 02_untrusted_search_path.patch - CVE-2019-5429. (Closes: #928282)
+
+ -- Phil Wyett   Wed, 18 Dec 2019 20:25:54 +
+
 filezilla (3.39.0-2) unstable; urgency=medium
 
   * Fixed debian/watch
diff -Nru filezilla-3.39.0/debian/patches/02_untrusted_search_path.patch filezilla-3.39.0/debian/patches/02_untrusted_search_path.patch
--- filezilla-3.39.0/debian/patches/02_untrusted_search_path.patch	1970-01-01 01:00:00.0 +0100
+++ filezilla-3.39.0/debian/patches/02_untrusted_search_path.patch	2019-12-18 20:25:54.0 +
@@ -0,0 +1,402 @@
+Description: Untrusted search path - CVE-2019-5429.
+Debian security tracker: https://security-tracker.debian.org/tracker/CVE-2019-5429
+Upstream commits:
+https://svn.filezilla-project.org/filezilla?view=revision=9097
+https://svn.filezilla-project.org/filezilla?view=revision=9098
+===
+--- filezilla-3.39.0.orig/src/interface/FileZilla.cpp	2019/02/19 10:40:09	9096
 filezilla-3.39.0/src/interface/FileZilla.cpp	2019/02/21 15:21:03	9097
+@@ -48,6 +48,50 @@
+   #error Please build wxWidgets with support for positional arguments.
+ #endif
+ 
++namespace {
++std::wstring GetOwnExecutableDir()
++{
++#ifdef FZ_WINDOWS
++	// Add executable path
++	std::wstring path;
++	path.resize(4095);
++	DWORD res;
++	while (true) {
++		res = GetModuleFileNameW(0, [0], path.size() - 1);
++		if (!res) {
++			// Failure
++			return std::wstring();
++		}
++
++		if (res >= path.size() - 1) {
++			path.resize(path.size() * 2);
++			continue;
++		}
++		else {
++			path.resize(res);
++		}
++		break;
++	}
++	size_t pos = path.rfind('\\');
++	if (pos != std::wstring::npos) {
++		return path.substr(0, pos);
++	}
++#elif defined(FZ_MAC)
++	std::wstring executable = wxStandardPaths::Get().GetExecutablePath().ToStdWString();
++	size_t pos = executable.rind('/');
++	if (pos != std::wstring::npos) {
++		return path.substr(0, pos);
++	}
++#elif defined(ENABLE_BINRELOC)
++	const char* p = SELFPATH;
++	if (p && *p == '/') {
++		return fz::to_wstring(std::string(p));
++	}
++#endif
++	return std::wstring();
++}
++}
++
+ CFileZillaApp::CFileZillaApp()
+ {
+ 	m_profile_start = fz::monotonic_clock::now();
+@@ -329,7 +373,7 @@
+ 	return fz::local_filesys::get_file_type(fz::to_native(file), true) == fz::local_filesys::file;
+ }
+ 
+-CLocalPath CFileZillaApp::GetDataDir(std::wstring fileToFind) const
++CLocalPath CFileZillaApp::GetDataDir(std::wstring fileToFind, std::wstring const& prefixSub, bool searchSelfDir) const
+ {
+ 	/*
+ 	 * Finding the resources in all cases is a difficult task,
+@@ -344,102 +388,78 @@
+ 
+ #ifdef __WXMAC__
+ 	CLocalPath path(wxStandardPaths::Get().GetDataDir().ToStdWstring());
+-	if (FileExists(path.GetPath() + fileToFind)) {
++	if (searchSelfDir && FileExists(path.GetPath() + fileToFind)) {
+ 		return path;
+ 	}
+ 
+ 	return CLocalPath();
+ #else
+ 
+-	wxPathList pathList;
+-	// FIXME: --datadir cmdline
+-
+ 	// First try the user specified data dir.
+-	pathList.AddEnvList(_T("FZ_DATADIR"));
+-
+-	// Next try the current path and the current executable path.
+-	// Without this, running development versions would be difficult.
+-	pathList.Add(wxGetCwd());
+-
+-#ifdef ENABLE_BINRELOC
+-	const char* path = SELFPATH;
+-	if (path && *path) {
+-		wxString datadir(SELFPATH , *wxConvCurrent);
+-		wxFileName fn(datadir);
+-		datadir = fn.GetPath();
+-		if (!datadir.empty())
+-			pathList.Add(datadir);
+-
+-	}
+-	path = DATADIR;
+-	if (path && *path) {
+-		wxString datadir(DATADIR, *wxConvCurrent);
+-		if (!datadir.empty())
+-			pathList.Add(datadir);
+-	}
+-#elif defined __WXMSW__
+-	wxChar path[1024];
+-	int res = GetModuleFileName(0, path, 1000);
+-	if (res > 0 && res < 1000) {
+-		wxFileName fn(path);
+-		pathList.Add(fn.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR));
++	if (searchSelfDir) {
++		wxString tmp;
++		wxGetEnv(L"FZ_DATADIR", );
++		CLocalPath path(tmp.ToStdWstring());
++		if (!path.empty() && FileExists(path.GetPath() + fileToFind)) {
++			return path;
++		}
+ 	

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

[Andrew Caudwell]

Thanks. We're in the process of updating the package so you don't need 
to do an NMU.


Unfortunately the issue with ffmpeg isn't completely solved by this 
update. I created a test case that shows ffmpeg 4.2.1 has the same issue 
with its own ppm output:


https://github.com/acaudwell/Gource/issues/216#issuecomment-559899036

I also found the main issue of ffmpeg stopping reading input when it 
encounters an error seems to not occur with the in development version 
of ffmpeg.


On 16/12/2019 6:57 AM, Jochen Sprickerhof wrote:

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

Hi,

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

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

Cheers Jochen

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

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

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

gource recommends no packages.

gource suggests no packages.

-- no debconf information

Bug#947101: pyside2: New upstream version 5.14.0 available

[Kurt Kremitzki]

Source: pyside2
Severity: wishlist

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Kurt Kremitzki 
To: Debian Bug Tracking System 
Subject: pyside2: New upstream version 5.14.0 available
Message-ID: <157689164794.467489.1179887487726778265.reportbug@x>
X-Mailer: reportbug 7.6.0
Date: Fri, 20 Dec 2019 19:27:27 -0600

Source: pyside2
Severity: wishlist

Dear Maintainer,

A new upstream version 5.14.0 is available. Please consider packaging
it.

Thank you!


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

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

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

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

Bug#947093: RFS: filezilla/3.39.0-2+deb10u1 [RC] -- Full-featured graphical FTP/FTPS/SFTP client

[Adam Borowski]

Control: tags -1 +moreinfo

On Fri, Dec 20, 2019 at 09:53:51PM +, Phil Wyett wrote:
>  * Package name: filezilla
>Version : 3.39.0-2+deb10u1

> Changes since the last upload:
> 
>* Team Upload
>* Added: 02_untrusted_search_path.patch - CVE-2019-5429. (Closes:
> #928282)

Hi!
This is a stable update, and one that doesn't go through the security team.
Thus, you first need to obtain the Release Team's approval.  This is done by
reporting a "stable proposed updates" bug on "release.debian.org"; the bug
needs to include debdiff of your proposed update.

Only once approval is granted, we may proceed with the upload.

There's more documentation in the developers-reference, section 5.5.1.

Thanks for taking care of this package!


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

Bug#943585: Acknowledgement (kwin-x11: kwin (?) causes extreme flickering and tear on login)

[Stefan Schwarzer]

Hi Brendon,

I was working on gnome in the meantime, so I only noticed your remark today.

I checked my /etc/X11/xorg.conf.d as you suggested, but there is absolutely
nothing in there. Long time ago I remember having tried to set up a second X
server to get bumblebee working, but I gave up on that. My attempt to fix the
kwin_x11 behavior basically had me remove the entire kde-stuff and everything
remotely related to intel graphics as well. In the meantime I am also back at
testing rather than unstable.

The kwin_x11 issue is still unchanged. Currently, I am in the process to
disobey the debian rules for bug reporting and to cross-post at kde.

Thanks for your update,

Happy Christmas/change of the year/may reason be with all of us...

Stefan

Bug#947100: RFS: scikit-build/0.10.0-1 [ITP] -- improved build system generator for Python C/C++/Fortran/Cython extensions

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "scikit-build"

* Package name : scikit-build
Version : 0.10.0-1
Upstream Author : The scikit-build team 
* URL : https://scikit-build.org
* License : MIT
* Vcs : https://salsa.debian.org/debian/scikit-build
Section : python

It builds those binary packages:

python3-skbuild - improved build system generator for Python 
C/C++/Fortran/Cython extensions

python-skbuild-doc - skbuild (documentation)

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


https://mentors.debian.net/package/scikit-build

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

dget -x 
https://mentors.debian.net/debian/pool/main/s/scikit-build/scikit-build_0.10.0-1.dsc


Changes since the last upload:

* Initial release. Closes: #947097


The Vcs* tags points to a repo that doesn't exist, it would be nice if 
the sponsor

could create it and add me as maintainer.

Regards,
Håvard

Bug#947064: texlive-fonts-extra: fourier-orns.sty broken, docs using the Fourier font no longer compile

[Norbert Preining]

On Fri, 20 Dec 2019, Hilmar Preuße wrote:
> I'm able to reproduce:

Strange, I can ..but I have that file somewhere else ...

(/usr/local/share/texmf/tex/latex/fourier/fourier-orns.sty))) (./asb.aux)

Need to investigate.

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#938272: python-xattr: diff for NMU version 0.9.6-1.1

[Sandro Tosi]

Control: tags 938272 + patch


Dear maintainer,

I've prepared an NMU for python-xattr (versioned as 0.9.6-1.1). The diff
is attached to this message.

Regards.

diff -Nru python-xattr-0.9.6/debian/changelog python-xattr-0.9.6/debian/changelog
--- python-xattr-0.9.6/debian/changelog	2018-09-06 07:06:53.0 -0400
+++ python-xattr-0.9.6/debian/changelog	2019-12-20 18:41:06.0 -0500
@@ -1,3 +1,10 @@
+python-xattr (0.9.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938272
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 18:41:06 -0500
+
 python-xattr (0.9.6-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru python-xattr-0.9.6/debian/control python-xattr-0.9.6/debian/control
--- python-xattr-0.9.6/debian/control	2018-09-06 07:06:53.0 -0400
+++ python-xattr-0.9.6/debian/control	2019-12-20 18:39:17.0 -0500
@@ -5,14 +5,10 @@
 Build-Depends:
  debhelper (>= 11),
  dh-python,
- python-all-dev,
- python-cffi,
- python-setuptools,
  python3-all-dev,
  python3-cffi,
  python3-setuptools,
 Standards-Version: 4.2.0
-X-Python-Version: >= 2.7
 Homepage: https://github.com/xattr/xattr
 Vcs-Git: https://salsa.debian.org/debian/python-xattr.git
 Vcs-Browser: https://salsa.debian.org/debian/python-xattr
@@ -35,23 +31,6 @@
  .
  This package contains the xattr cli tool.
 
-Package: python-xattr
-Architecture: any
-Depends:
- ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends},
-Conflicts: python-pyxattr
-Provides: ${python:Provides}
- , python-pyxattr
-Description: module for manipulating filesystem extended attributes - Python 2
- This module allows manipulation of the filesystem extended attributes present
- in some operating systems (GNU/Linux included). It is compatible to
- python-pyxattr but also provides a dictionary like interfaces for manipulating
- these attributes.
- .
- This package contains the Python 2.7 module.
-
 Package: python3-xattr
 Architecture: any
 Depends:
diff -Nru python-xattr-0.9.6/debian/python-xattr.docs python-xattr-0.9.6/debian/python-xattr.docs
--- python-xattr-0.9.6/debian/python-xattr.docs	2018-09-06 07:06:53.0 -0400
+++ python-xattr-0.9.6/debian/python-xattr.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-debian/README.txt
diff -Nru python-xattr-0.9.6/debian/rules python-xattr-0.9.6/debian/rules
--- python-xattr-0.9.6/debian/rules	2018-09-06 07:06:53.0 -0400
+++ python-xattr-0.9.6/debian/rules	2019-12-20 18:39:39.0 -0500
@@ -6,11 +6,10 @@
 export PYBUILD_DISABLE=test
 
 %:
-	dh  $@ --with python2,python3 --buildsystem=pybuild
+	dh  $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_install:
 	dh_auto_install
-	rm -rf debian/python-xattr/usr/bin
 	mkdir -p debian/xattr/usr
 	mv debian/python3-xattr/usr/bin debian/xattr/usr
 

Bug#944364: dpkg: ldconfig is not invoked for Depends or even Pre-Depends

[Sunil Mohan Adapa]

Control: reassign -1 python3.7
Control: severity -1 important

On Wed, 13 Nov 2019 01:27:11 +0100 Guillem Jover  wrote:
> Control: reassign -1 python3-augeas
> Control: severity -1 serious
> 
> Hi!
> 
> On Sat, 2019-11-09 at 11:06:15 +0100, Jakub Wilk wrote:
> > * Alexander Thomas , 2019-11-08, 15:50:
> > > Traceback (most recent call last):
> > >  File "/usr/lib/the-package/setup-package.py", line 3, in 
> > >from augeas import Augeas
> > >  File "/usr/lib/python2.7/dist-packages/augeas.py", line 78, in 
> > >class Augeas(object):
> > >  File "/usr/lib/python2.7/dist-packages/augeas.py", line 82, in Augeas
> > >_libaugeas = _dlopen("augeas")
> > >  File "/usr/lib/python2.7/dist-packages/augeas.py", line 75, in _dlopen
> > >raise ImportError("Unable to import lib%s!" % args[0])
> > > ImportError: Unable to import libaugeas!
> > 
> > The _dlopen() function uses ctypes.util.find_library(), which is a
> > fundamentally broken API. This is the culprit, not dpkg.
> 
> Ah, thanks for tracking this down! I was not sure whether the ld caching
> logic in glibc might have regressed perhaps.
> 
> > > ldconfig is one of the triggers of libc-bin. It seems that its
> > > invocation is now postponed too late.
> > 
> > ldconfig is declared as a noawait trigger, so dpkg is allowed to configure
> > the triggering package immediately, without waiting for the trigger to be
> > run.
> >
> > This declaration is correct, because running ldconfig shouldn't have any
> > effect on software functionality, unless there's a bug somewhere else.
> 
> Exactly. So I guess this needs to be reassigned first to augeas, which
> I'm doing now. And perhaps cloned or a new bug filed to python too for
> the brokeness in the ctypes.util.find_library() API, but I'd leave that
> to you Jakub, as I've not checked any of that.

Hello,

When reporting this bug, python-augeas was used as an example to
demonstrate the problem when a python library is used by a package that
depends on it. The problem is not specific to pythone-augeas and is
reproducible on other python packages that use
ctypes.util.find_library(). I have tried this with the library
python3-magic which opens its library as follows:
"ctypes.cdll.LoadLibrary(find_library('magic'))"

...
Setting up libpython3.7-stdlib:amd64 (3.7.6-1) ...
Setting up libpython3-stdlib:amd64 (3.7.5-3) ...
Setting up python3.7 (3.7.6-1) ...
Setting up python3 (3.7.5-3) ...
running python rtupdate hooks for python3.7...
running python post-rtupdate hooks for python3.7...
Setting up python3-magic (2:0.4.15-2) ...
Setting up the-package (1.2.3ubuntu1-2-1) ...
Traceback (most recent call last):
  File "/usr/lib/the-package/setup-package.py", line 3, in 
import magic
  File "/usr/lib/python3/dist-packages/magic/__init__.py", line 361, in

add_compat(globals())
  File "/usr/lib/python3/dist-packages/magic/__init__.py", line 325, in
add_compat
from magic import compat
  File "/usr/lib/python3/dist-packages/magic/compat.py", line 61, in

_open = _libraries['magic'].magic_open
  File "/usr/lib/python3.7/ctypes/__init__.py", line 377, in __getattr__
func = self.__getitem__(name)
  File "/usr/lib/python3.7/ctypes/__init__.py", line 382, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/bin/python3: undefined symbol: magic_open
dpkg: error processing package the-package (--configure):
 installed the-package package post-installation script subprocess
returned error exit status 1
Processing triggers for libc-bin (2.29-6) ...
Errors were encountered while processing:
 the-package
E: Sub-process /usr/bin/dpkg returned an error code (1)

This is either a bug with all python libraries that use ctypes'
find_library() for simply using the method or it is a bug with ctypes
find_library(). I am inclined to think the latter because judging by
ctypes documentation, using find_library() followed by LoadLibrary() is
the expected usage pattern on GNU/Linux. Hence reassigning this bug to
Python.

Also, severity 'serious' does not fit this bug as the affected packages
(and ctypes API) are fully usable expect from within Debian postinst
scripts. Demoting severity to important again.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#940028: debian-installer multi-console race with preseeding

[Steve McIntyre]

On Fri, Dec 20, 2019 at 03:40:05PM +, Steve McIntyre wrote:
>On Fri, Dec 20, 2019 at 03:33:56PM +, Ian Jackson wrote:
>>Ian Jackson writes ("debian-installer multi-console race with preseeding"):
>>> A workaround is to specify *exactly one* appropriate console=
>>> on the kernel command line.  This causes the kernel to report only
>>> that console in /proc/consoles and the bug is avoided.
>>
>>This seems to work only sometimes.  In my experience it worked for an
>>arm64 server but not for an x86 PV Xen guest.  There does not appear
>>to be another workaround that does not involve modifying the installer
>>initramfs.
>
>Hoping to have a fix shortly - hacking on this in the next few days...

In fact, I think I have just pushed a potential fix for this in commit
0ee43d05b83f8ef5a856f3282e002a111809cef9 in rootskel. It may not be a
complete solution, but in local testing it doesn't appear to break
anything *and* in a preseeing situation should stop us running things
in parallel.

If the user needs to watch/interact with a preseeded d-i on a
particular console, they'll need to specify that on the kernel command
line. I don't see a better way to support that.

I don't see many better options for solutions right now; I'l all ears
if you think I've missed something obvious!

Ian: I hope that helps you to test things - you'll need to rebuild the
rootskel source and then your d-i initrd to do that. I'm hoping you
can do that and confirm this works for you now in bullseye. If that's
too much hassle, let me know and I'll push an upload of rootskel to
propagate through the system.

Obviously, if this works sufficiently, I'll want to backport the same
fix to bullseye before the next point release.

Apologies this has taken so long. :-(

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Bug#947099: RM: python-lxc -- RoQA; python2-only; replaced by python3-lxc

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Bug#938887: zfec: diff for NMU version 1.5.2-2.1

[Sandro Tosi]

Control: tags 938887 + patch


Dear maintainer,

I've prepared an NMU for zfec (versioned as 1.5.2-2.1). The diff
is attached to this message.

Regards.

diff -Nru zfec-1.5.2/debian/changelog zfec-1.5.2/debian/changelog
--- zfec-1.5.2/debian/changelog	2018-06-02 06:32:12.0 -0400
+++ zfec-1.5.2/debian/changelog	2019-12-20 18:07:34.0 -0500
@@ -1,3 +1,10 @@
+zfec (1.5.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938887
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 18:07:34 -0500
+
 zfec (1.5.2-2) unstable; urgency=medium
 
   * Use tracker team address in maintainers field.
diff -Nru zfec-1.5.2/debian/control zfec-1.5.2/debian/control
--- zfec-1.5.2/debian/control	2018-06-02 06:32:12.0 -0400
+++ zfec-1.5.2/debian/control	2019-12-20 18:07:29.0 -0500
@@ -4,9 +4,7 @@
 Uploaders: Vasudev Kamath 
 Build-Depends: debhelper (>= 11),
  dh-python,
- python-all-dev,
  python3-all-dev,
- python-setuptools,
  python3-setuptools
 Standards-Version: 4.1.3
 Section: python
@@ -14,19 +12,6 @@
 Vcs-Browser: https://salsa.debian.org/vasudev/zfec
 Homepage: http://tahoe-lafs.org/trac/zfec
 
-Package: python-zfec
-Architecture: any
-Depends: ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends}
-Recommends: ${python:Recommends}
-Suggests: ${python:Suggests}
-Description: fast erasure codec, with Python bindings
- Fast, portable, programmable erasure coding a.k.a. "forward error
- correction": the generation of redundant blocks of information such that if
- some blocks are lost then the original data can be recovered from the
- remaining blocks. This package includes a Python API.
-
 Package: python3-zfec
 Architecture: any
 Depends: ${misc:Depends},
diff -Nru zfec-1.5.2/debian/rules zfec-1.5.2/debian/rules
--- zfec-1.5.2/debian/rules	2018-06-02 06:32:12.0 -0400
+++ zfec-1.5.2/debian/rules	2019-12-20 18:07:19.0 -0500
@@ -4,4 +4,4 @@
 export PYBUILD_NAME=zfec
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#947098: seqsero needs hinting into testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

Issues preventing migration:
uninstallable on arch arm64, autopkgtest delayed there


For background see #918620.

Bug#937548: pystache: diff for NMU version 0.5.4-6.1

[Sandro Tosi]

Control: tags 937548 + patch


Dear maintainer,

I've prepared an NMU for pystache (versioned as 0.5.4-6.1). The diff
is attached to this message.

Regards.

diff -Nru pystache-0.5.4/debian/changelog pystache-0.5.4/debian/changelog
--- pystache-0.5.4/debian/changelog	2016-10-11 03:19:50.0 -0400
+++ pystache-0.5.4/debian/changelog	2019-12-20 18:01:35.0 -0500
@@ -1,3 +1,10 @@
+pystache (0.5.4-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937548
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 18:01:35 -0500
+
 pystache (0.5.4-6) unstable; urgency=medium
 
   * debian/control 
diff -Nru pystache-0.5.4/debian/control pystache-0.5.4/debian/control
--- pystache-0.5.4/debian/control	2016-10-11 03:16:57.0 -0400
+++ pystache-0.5.4/debian/control	2019-12-20 18:00:12.0 -0500
@@ -4,25 +4,11 @@
 Maintainer: Kouhei Maeda 
 Build-Depends: debhelper (>= 8.0.0),
dh-python,
-   python-all,
-   python-setuptools,
python3-all,
python3-setuptools
 Standards-Version: 3.9.8
-X-Python-Version: 2.7
 Homepage: http://github.com/defunkt/pystache
 
-Package: python-pystache
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Provides: ${python:Provides}
-Description: Python implementation of Mustache
- Pystache is Python implementation of Mustache.
- Original Mustache is a framework-agnostic, logic-free templating system
- inspired by ctemplate and et. Like ctemplate, Mustache "emphasizes separating
- logic from presentation: it is impossible to embed application logic in this
- template language."
-
 Package: python3-pystache
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru pystache-0.5.4/debian/pystache.1 pystache-0.5.4/debian/pystache.1
--- pystache-0.5.4/debian/pystache.1	2012-08-13 01:04:38.0 -0400
+++ pystache-0.5.4/debian/pystache.1	1969-12-31 19:00:00.0 -0500
@@ -1,58 +0,0 @@
-.\"  Hey, EMACS: -*- nroff -*-
-.\" First parameter, NAME, should be all caps
-.\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
-.\" other parameters are allowed: see man(7), man(1)
-.TH PYSTACHE 1 "August 13, 2012"
-.\" Please adjust this date whenever revising the manpage.
-.\"
-.\" Some roff macros, for reference:
-.\" .nhdisable hyphenation
-.\" .hyenable hyphenation
-.\" .ad l  left justify
-.\" .ad b  justify to both left and right margins
-.\" .nfdisable filling
-.\" .fienable filling
-.\" .brinsert line break
-.\" .sp insert n+1 empty lines
-.\" for manpage-specific macros, see man(7)
-.SH NAME
-pystache \- Render a mustache template with the given context.
-.SH SYNOPSIS
-.B pystache
-.RI [ options ] " sub-command"
-.RI [ sub-cmd-options ] " [infile]"
-.br
-.SH DESCRIPTION
-This manual page documents briefly the
-.B pystache
-commands.
-.PP
-.\" TeX users may be more comfortable with the \fB\fP and
-.\" \fI\fP escape sequences to invode bold face and italics,
-.\" respectively.
-\fBPystache\fP is a Python implementation of Mustache. Mustache is a framework\-agnostic, logic\-free templating system inspired by ctemplate and et. Like ctemplate, Mustache "emphasizes separating logic from presentation: it is impossible to embed application logic in this template language."
-.SH OPTIONS
-These programs follow the usual GNU command line syntax, with long
-options starting with two dashes (`-').
-A summary of options is included below.
-For a complete description, see the Info files.
-.TP
-.B \-h, \-\-help
-Show summary of options.
-.SH POSITIONAL ARGUMENTS
-.TP
-.B template
-A filename or template string.
-.TP
-.B context
-A filename or JSON string.
-.SH SEE ALSO
-.br
-The programs are documented by
-.IR "README.rst.gz" ,
-available via the Info system, and http://pypi.python.org/pypi/pystache/
-.SH AUTHOR
-pystache was written by Chris Jerdonek.
-.PP
-This manual page was written by Kouhei Maeda .
-for the Debian project (and may be used by others).
diff -Nru pystache-0.5.4/debian/python-pystache.manpages pystache-0.5.4/debian/python-pystache.manpages
--- pystache-0.5.4/debian/python-pystache.manpages	2012-08-13 00:25:11.0 -0400
+++ pystache-0.5.4/debian/python-pystache.manpages	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-debian/pystache.1
diff -Nru pystache-0.5.4/debian/rules pystache-0.5.4/debian/rules
--- pystache-0.5.4/debian/rules	2015-06-30 23:56:10.0 -0400
+++ pystache-0.5.4/debian/rules	2019-12-20 18:00:32.0 -0500
@@ -6,7 +6,7 @@
 export PYBUILD_NAME=pystache
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_installchangelogs:
 	dh_installchangelogs $(CURDIR)/HISTORY.md

Bug#938811: webcolors: diff for NMU version 1.5-2.1

[Sandro Tosi]

Control: tags 938811 + patch


Dear maintainer,

I've prepared an NMU for webcolors (versioned as 1.5-2.1). The diff
is attached to this message.

Regards.

diff -Nru webcolors-1.5/debian/changelog webcolors-1.5/debian/changelog
--- webcolors-1.5/debian/changelog	2016-10-05 16:25:08.0 -0400
+++ webcolors-1.5/debian/changelog	2019-12-20 17:50:30.0 -0500
@@ -1,3 +1,10 @@
+webcolors (1.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938811
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 17:50:30 -0500
+
 webcolors (1.5-2) unstable; urgency=medium
 
   * debian/control
diff -Nru webcolors-1.5/debian/control webcolors-1.5/debian/control
--- webcolors-1.5/debian/control	2016-10-05 16:24:24.0 -0400
+++ webcolors-1.5/debian/control	2019-12-20 17:50:30.0 -0500
@@ -2,26 +2,10 @@
 Section: python
 Priority: optional
 Maintainer: Kouhei Maeda 
-Build-Depends: debhelper (>= 8.0.0), python-all, python-setuptools, python3-all, python3-setuptools
+Build-Depends: debhelper (>= 8.0.0), python3-all, python3-setuptools, dh-python
 Standards-Version: 3.9.8
-X-Python-Version: 2.7, >= 3.2
 Homepage: http://www.bitbucket.org/ubernostrum/webcolors/overview/
 
-Package: python-webcolors
-Architecture: all
-Provides: ${python:Provides}
-Depends: ${python:Depends}, ${misc:Depends}
-Description: library of color names and value formats defined by HTML and CSS
- Support is included for the following formats, but this support RGB colorspace
- only.
-  * Specification-defined color names
-  * Six-digit hexadecimal
-  * Three-digit hexadecimal
-  * Integer rgb() triplet
-  * Percentage rgb() triplet
- This module conversion to/from HSL can be handled by the "colorsys" module in
- the Python standard library.
-
 Package: python3-webcolors
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru webcolors-1.5/debian/rules webcolors-1.5/debian/rules
--- webcolors-1.5/debian/rules	2013-06-06 12:18:25.0 -0400
+++ webcolors-1.5/debian/rules	2019-12-20 17:50:24.0 -0500
@@ -1,32 +1,5 @@
 #!/usr/bin/make -f
-# -*- makefile -*-
-# Sample debian/rules that uses debhelper.
-# This file was originally written by Joey Hess and Craig Small.
-# As a special exception, when this file is copied by dh-make into a
-# dh-make output file, you may use that output file without restriction.
-# This special exception was added by Craig Small in version 0.37 of dh-make.
-
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
 
 %:
-	dh $@ --with python2,python3
-
-override_dh_auto_build:
-	for py in $(shell pyversions -vr) $(shell py3versions -vr); do \
-		python$$py setup.py build --build-base=build$$py; \
-	done
-
-override_dh_auto_install:
-	python setup.py install --no-compile -O0 --install-layout=deb \
-		--root $(CURDIR)/debian/python-webcolors && \
-	python3 setup.py install --no-compile -O0 --install-layout=deb \
-		--root $(CURDIR)/debian/python3-webcolors
+	dh $@ --with python3 --buildsystem=pybuild
 
-override_dh_auto_clean:
-	dh_clean
-	for py in $(shell pyversions -vr) $(shell py3versions -vr); do \
-		python$$py setup.py clean --build-temp=build && \
-		python$$py setup.py clean --build-temp=build$$py; \
-	done
-	find $(CUDIR) -name "*.pyc" -delete

Bug#945983: transition: petsc

[Drew Parsons]

On 2019-12-15 17:20, Paul Gevers wrote:

Hi Drew,


In that case in the spirit of a package deal, I suggest
throwing in scalapack 2.1.0 as well.


Go ahead.



ga will need a binNMU for scalapack too.

It gets missed in some transition lists since it provides static 
libraries, but it shows up in 
https://release.debian.org/transitions/html/scalapack-mumps-petsc-slepc.html


To keep the static symbols consistent, nwchem should be rescheduled for 
another binNMU once ga is rebuilt.



Drew

Bug#947097: ITP: scikit-build -- build system generator for Python C/C++/Fortran/Cython extensions

[Håvard Flaget Aasen]

Package: wnpp
Severity: wishlist
Owner: Håvard Flaget Aasen 

* Package name: scikit-build
  Version : 0.10.0
  Upstream Author : The scikit-build team 
* URL : https://scikit-build.org
* License : BSD, MIT, Apache-2.0, CC0-1.0
  Programming Lang: Python, CMake
  Description : build system generator for Python C/C++/Fortran/Cython 
extensions

Better support is available for additional compilers, build systems, cross
compilation, and locating dependencies and determining their build
requirements.
.
The scikit-build package is fundamentally just glue between the setuptools
Python module and CMake.


Dependency for latest release of python-blosc
Intend to maintain it on my own, need sponsor.

Bug#947096: RM: python-vsgui -- RoQA; Dead upstream, unmaintained, depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove python-vsgui. It depends on Python and is dead 
upstream/unmaintained (last release/upload
in 2011, maintainer is also upstream)

Cheers,
Moritz

Bug#947095: RM: pyftpd -- RoQA; dead upstream, depends on Python 2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pyftpd. It's dead upstream, depends on Python 2 and is 
unmaintained
(last maintainer upload was almost a decade ago)

Cheers,
Moritz

Bug#938862: yanc: diff for NMU version 0.3.3-3.1

[Sandro Tosi]

Control: tags 938862 + patch


Dear maintainer,

I've prepared an NMU for yanc (versioned as 0.3.3-3.1). The diff
is attached to this message.

Regards.

diff -Nru yanc-0.3.3/debian/changelog yanc-0.3.3/debian/changelog
--- yanc-0.3.3/debian/changelog	2017-01-09 19:36:23.0 -0500
+++ yanc-0.3.3/debian/changelog	2019-12-20 17:45:12.0 -0500
@@ -1,3 +1,11 @@
+yanc (0.3.3-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938862
+  * Dont fail if tests fail, work needs to be done to make them py3k compatible
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 17:45:12 -0500
+
 yanc (0.3.3-3) unstable; urgency=low
 
   * python3 support (Closes: #850589)
diff -Nru yanc-0.3.3/debian/control yanc-0.3.3/debian/control
--- yanc-0.3.3/debian/control	2017-01-09 19:36:23.0 -0500
+++ yanc-0.3.3/debian/control	2019-12-20 17:41:30.0 -0500
@@ -2,19 +2,13 @@
 Maintainer: Marcelo Jorge Vieira 
 Section: python
 Priority: optional
-Build-Depends: python-setuptools (>= 0.6b3), python-all (>= 2.6.6-3), python3-all, python3-setuptools, debhelper (>= 9), dh-python, python-nose
+Build-Depends: python3-all, python3-setuptools, debhelper (>= 9), dh-python, python3-nose
 Standards-Version: 3.9.6
 Vcs-Browser: http://anonscm.debian.org/cgit/users/metal/yanc.git
 Vcs-Git: git://anonscm.debian.org/users/metal/yanc.git
 X-Python-Version: >= 2.6
 X-Python3-Version: >= 3.2
 
-Package: python-nose-yanc
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Description: Color output plugin for nose
- YANC is color output plugin for nose that plays nicely with others.
-
 Package: python3-nose-yanc
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru yanc-0.3.3/debian/rules yanc-0.3.3/debian/rules
--- yanc-0.3.3/debian/rules	2017-01-09 19:36:23.0 -0500
+++ yanc-0.3.3/debian/rules	2019-12-20 17:45:10.0 -0500
@@ -3,7 +3,7 @@
 export PYBUILD_NAME = nose-yanc
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:
-	nosetests yanc/test_yanc.py
+	-nosetests3 yanc/test_yanc.py

Bug#885508: bumping severity of pygtk bugs

[Moritz Mühlenhoff]

On Tue, Dec 03, 2019 at 10:47:51PM +0100, Moritz Mühlenhoff wrote:
> On Sun, Oct 06, 2019 at 05:09:30PM -0400, Jeremy Bicha wrote:
> > Control: severity -1 serious
> > Control: tags -1 -buster
> > 
> > As part of the Python2 removal, it is our intent that pygtk will be removed 
> > from Testing before the release of Debian 11
> > "Bullseye". Therefore, I am bumping the severity of this bug to Serious to 
> > ensure that there is plenty of warning before
> > the Debian 11 release and to make the eventual removal of pygtk as smooth 
> > as possible.
> 
> Hi Diego,
> obmenu seems dead upstream, are you planning to port it yourself to GTK3? 
> Otherwise
> it will need to be removed from the archive.

Filed a removal bug now.

Cheers,
Moritz

Bug#947094: RM: obmenu -- RoQA; Depends on pygtk2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove obmenu. It depends on pygtk2, which is going away
and is dead upstream.

Cheers,
Moritz

Bug#937265: pdfrw: diff for NMU version 0.4-2.1

[Sandro Tosi]

Control: tags 937265 + patch


Dear maintainer,

I've prepared an NMU for pdfrw (versioned as 0.4-2.1). The diff
is attached to this message.

Regards.

diff -Nru pdfrw-0.4/debian/changelog pdfrw-0.4/debian/changelog
--- pdfrw-0.4/debian/changelog	2018-04-12 11:14:12.0 -0400
+++ pdfrw-0.4/debian/changelog	2019-12-20 17:37:50.0 -0500
@@ -1,3 +1,10 @@
+pdfrw (0.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937265
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 17:37:50 -0500
+
 pdfrw (0.4-2) unstable; urgency=medium
 
   * Bumped Standards-Version to 4.1.3
diff -Nru pdfrw-0.4/debian/control pdfrw-0.4/debian/control
--- pdfrw-0.4/debian/control	2018-04-12 11:14:12.0 -0400
+++ pdfrw-0.4/debian/control	2019-12-20 17:37:37.0 -0500
@@ -5,8 +5,6 @@
 Build-Depends:
  debhelper (>= 10),
  dh-python,
- python-all (>= 2.6.6-3~),
- python-setuptools,
  python3-all,
  python3-setuptools,
 Standards-Version: 4.1.3
@@ -17,32 +15,6 @@
 X-Python3-Version: >= 3.2
 Testsuite: autopkgtest-pkg-python
 
-Package: python-pdfrw
-Architecture: all
-Depends:
- ${misc:Depends},
- ${python:Depends},
-Suggests:
- python-pdfrw-doc,
- python-reportlab,
-Description: PDF file manipulation library (Python 2)
- pdfrw can read and write PDF files, and can also be used to read in PDFs which
- can then be used inside reportlab.
- .
- pdfrw tries to be agnostic about the contents of PDF files, and support them
- as containers, but to do useful work, something a little higher-level is
- required. It supports the following:
- .
-  * PDF pages. pdfrw knows enough to find the pages in PDF files you read in,
-and to write a set of pages back out to a new PDF file.
-  * Form XObjects. pdfrw can take any page or rectangle on a page, and convert
-it to a Form XObject, suitable for use inside another PDF file
-  * reportlab objects. pdfrw can recursively create a set of reportlab objects
-from its internal object format. This allows, for example, Form XObjects to
-be used inside reportlab.
- .
- This package installs the library for Python 2.
-
 Package: python-pdfrw-doc
 Architecture: all
 Multi-Arch: foreign
diff -Nru pdfrw-0.4/debian/rules pdfrw-0.4/debian/rules
--- pdfrw-0.4/debian/rules	2018-04-12 10:39:24.0 -0400
+++ pdfrw-0.4/debian/rules	2019-12-20 17:37:44.0 -0500
@@ -3,6 +3,6 @@
 export PYBUILD_NAME = pdfrw
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:

Bug#936384: deltarpm: diff for NMU version 3.6+dfsg-1.2

[Sandro Tosi]

Control: tags 936384 + patch
Control: tags 943003 + patch


Dear maintainer,

I've prepared an NMU for deltarpm (versioned as 3.6+dfsg-1.2). The diff
is attached to this message.

Regards.

diff -Nru deltarpm-3.6+dfsg/debian/changelog deltarpm-3.6+dfsg/debian/changelog
--- deltarpm-3.6+dfsg/debian/changelog	2019-11-18 19:59:25.0 -0500
+++ deltarpm-3.6+dfsg/debian/changelog	2019-12-20 16:12:15.0 -0500
@@ -1,3 +1,10 @@
+deltarpm (3.6+dfsg-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #943003, #936384
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 16:12:15 -0500
+
 deltarpm (3.6+dfsg-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru deltarpm-3.6+dfsg/debian/control deltarpm-3.6+dfsg/debian/control
--- deltarpm-3.6+dfsg/debian/control	2019-11-18 19:59:17.0 -0500
+++ deltarpm-3.6+dfsg/debian/control	2019-12-20 16:11:31.0 -0500
@@ -8,7 +8,6 @@
  libbz2-dev,
  liblzma-dev,
  pkg-config,
- python-all-dev (>= 2.6.6-3~),
  python3-all-dev (>= 3.2),
  zlib1g-dev,
 Standards-Version: 3.9.4
@@ -29,18 +28,6 @@
  On Debian and derived systems these tools may be useful for creating
  and maintaining repositories of RPM packages.
 
-Package: python-deltarpm
-Section: python
-Architecture: any
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
-Provides: ${python:Provides}
-Description: Python bindings for deltarpm
- A deltarpm contains the differences between an old and a new version of
- an RPM.
- .
- This package provides the Python bindings for deltarpm, allowing
- Python scripts to read the deltarpm file header.
-
 Package: python3-deltarpm
 Section: python
 Architecture: any
diff -Nru deltarpm-3.6+dfsg/debian/python-deltarpm.install deltarpm-3.6+dfsg/debian/python-deltarpm.install
--- deltarpm-3.6+dfsg/debian/python-deltarpm.install	2019-11-18 19:58:24.0 -0500
+++ deltarpm-3.6+dfsg/debian/python-deltarpm.install	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-usr/lib/python2.*/dist-packages/*.py
-usr/lib/python2.*/dist-packages/*.so
diff -Nru deltarpm-3.6+dfsg/debian/rules deltarpm-3.6+dfsg/debian/rules
--- deltarpm-3.6+dfsg/debian/rules	2019-11-18 19:58:24.0 -0500
+++ deltarpm-3.6+dfsg/debian/rules	2019-12-20 16:12:01.0 -0500
@@ -10,7 +10,6 @@
 LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS)
 LDLIBS := $(shell pkg-config --libs zlib liblzma) -lbz2
 
-PYTHON2 := $(shell pyversions -r)
 PYTHON3 := $(shell py3versions -r)
 
 make_args := prefix=/usr \
@@ -24,7 +23,7 @@
 	 zlibldflags="$(shell pkg-config --libs zlib)"
 
 %:
-	dh $@ --with python2,python3
+	dh $@ --with python3
 
 override_dh_auto_build:
 	dh_auto_build -- all python $(make_args)

Bug#947093: RFS: filezilla/3.39.0-2+deb10u1 [RC] -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: filezilla
   Version : 3.39.0-2+deb10u1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

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

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.39.0-2+deb10u1.dsc

Changes since the last upload:

   * Team Upload
   * Added: 02_untrusted_search_path.patch - CVE-2019-5429. (Closes:
#928282)

Regards

Phil

-- 

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

Twitter: @kathenasorg

IRC: kathenas






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

Bug#947092: Package absent from mirrors [libhttp-cookies-perl]

[gregor herrmann]

Control: reassign -1 mirrors

On Fri, 20 Dec 2019 17:57:04 -0300, biguibi wrote:

> While trying to install a desktop environment in a virtual machine
> (virt-manager, Debian 10 Standard amd64), halfway through the download
> process an error pops up saying it couldn't find a specific package
> called libhttp-cookies-perl.
> 
> E: Failed to fetch 
> http://deb.debian.org/debian/pool/main/libh/libhttp-cookies-perl/libhttp-cookies-perl_6.04-1_all.deb
> 404 Not Found [IP: 151.101.92.204 80]
> 
> After looking through some random mirrors, I've realized this package
> is absent from every single one of them, including Debian's main
> mirror.

Thanks for your bug report.

I cannot confirm your findings, I see the file e.g. on the Swiss
mirror (the first one I checked):
http://ftp.ch.debian.org/debian/pool/main/libh/libhttp-cookies-perl/
and I can download it just fine:

% wget 
http://ftp.ch.debian.org/debian/pool/main/libh/libhttp-cookies-perl/libhttp-cookies-perl_6.04-1_all.deb
--2019-12-20 22:22:13--  
http://ftp.ch.debian.org/debian/pool/main/libh/libhttp-cookies-perl/libhttp-cookies-perl_6.04-1_all.deb
Resolving ftp.ch.debian.org (ftp.ch.debian.org)... 2001:67c:10ec:3dd1::42, 
129.132.53.171
Connecting to ftp.ch.debian.org 
(ftp.ch.debian.org)|2001:67c:10ec:3dd1::42|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17760 (17K) [application/x-debian-package]
Saving to: ‘libhttp-cookies-perl_6.04-1_all.deb’

libhttp-cookies-perl_6.04-1_al 
100%[==>]  17.34K  --.-KB/s
in 0.08s   

2019-12-20 22:22:14 (227 KB/s) - ‘libhttp-cookies-perl_6.04-1_all.deb’ saved 
[17760/17760]


Same for the Austrian mirror:
http://ftp.at.debian.org/debian/pool/main/libh/libhttp-cookies-perl/

% wget 
http://ftp.at.debian.org/debian/pool/main/libh/libhttp-cookies-perl/libhttp-cookies-perl_6.04-1_all.deb
--2019-12-20 22:25:51--  
http://ftp.at.debian.org/debian/pool/main/libh/libhttp-cookies-perl/libhttp-cookies-perl_6.04-1_all.deb
Resolving ftp.at.debian.org (ftp.at.debian.org)... 2001:858:2:1::10, 
213.129.232.18
Connecting to ftp.at.debian.org (ftp.at.debian.org)|2001:858:2:1::10|:80... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 17760 (17K) [application/x-debian-package]
Saving to: ‘libhttp-cookies-perl_6.04-1_all.deb’

libhttp-cookies-perl_6.04-1_al 
100%[==>]  17.34K  --.-KB/s
in 0.06s   

2019-12-20 22:25:51 (275 KB/s) - ‘libhttp-cookies-perl_6.04-1_all.deb’ saved 
[17760/17760]


So either this problem was temporary or it only affects the machines
behind deb.debian.org. In any case, it is/was not a problem in the
package itself. I'm therefore reassigning the bug to the "mirrors"
pseudo-package, in case further research is necessary.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Leonard Cohen: That Don't Make It Junk


signature.asc
Description: Digital Signature

Bug#947043: cyrus-sasl2: CVE-2019-19906: Off by one in _sasl_add_string function

[Salvatore Bonaccorso]

Hi Roberto,

On Fri, Dec 20, 2019 at 10:37:50AM -0500, Roberto C. Sánchez wrote:
> On Fri, Dec 20, 2019 at 08:36:00AM +0100, Salvatore Bonaccorso wrote:
> > Hi Roberto,
> > 
> > On Thu, Dec 19, 2019 at 08:06:19PM -0500, Roberto C. Sánchez wrote:
> > > On Thu, Dec 19, 2019 at 09:19:19PM +0100, Salvatore Bonaccorso wrote:
> > > > 
> > > > The following vulnerability was published for cyrus-sasl2.
> > > > 
> > > > CVE-2019-19906[0]:
> > > > Off by one in _sasl_add_string function
> > > > 
> > > > If you fix the vulnerability please also make sure to include the
> > > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > > > 
> > > Hi Team,
> > > 
> > > Is anybody already working on this update?  If not, I can start on it
> > > possibly tomorrow or perhaps the day after.
> > > 
> > > Salvatore,
> > > 
> > > If I (or someone else on the team) prepares the upload, do we go ahead
> > > and make the upload then let the security team handle the DSA
> > > publication?
> > 
> > I already started yesterday, and have buster and stretch packages,
> > will likely release the DSA later today or tomorrow. So far tested
> > just lightly for stretch but will double check explicitly against
> > openldap.
> > 
> Oh!  That's excellent.

And released as DSA 4591-1. Note: The patch was not upstream commited
at point of writing this. And I see Mike did as well release for LTS.

> > unstable would need an update as well yet.
> > 
> Of course.

Ideally this happen soon, but the RC bug is enough to mark the
'stable' -> 'testing' regression. Just let me know if any of you can
do it or if you would prefer a NMU with same patch (both approaches
works for me).

> > Can you later import then the changes in the packaging repository in
> > the appropriate branches?
> > 
> I could manage that in the coming days. Unless Ondrej or someone else
> gets to it first.

Thanks!

Regards,
Salvatore

Bug#791533: py-lmdb: diff for NMU version 0.86-1.2

[Sandro Tosi]

Control: tags 791533 + patch
Control: tags 937471 + patch


Dear maintainer,

I've prepared an NMU for py-lmdb (versioned as 0.86-1.2). The diff
is attached to this message.

Regards.

diff -Nru py-lmdb-0.86/debian/changelog py-lmdb-0.86/debian/changelog
--- py-lmdb-0.86/debian/changelog	2019-02-26 03:09:09.0 -0500
+++ py-lmdb-0.86/debian/changelog	2019-12-20 15:56:26.0 -0500
@@ -1,3 +1,11 @@
+py-lmdb (0.86-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937471
+  * Fix typo in description; Closes: #791533
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 15:56:26 -0500
+
 py-lmdb (0.86-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru py-lmdb-0.86/debian/control py-lmdb-0.86/debian/control
--- py-lmdb-0.86/debian/control	2019-02-26 03:08:41.0 -0500
+++ py-lmdb-0.86/debian/control	2019-12-20 15:55:56.0 -0500
@@ -7,33 +7,18 @@
  debhelper (>= 9~)
  , dh-python
  , liblmdb-dev
- , python-all-dev
  , python3-all-dev
- , python-setuptools
  , python3-setuptools
 Standards-Version: 3.9.6
 Homepage: https://github.com/dw/py-lmdb
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-db/py-lmdb.git/
 Vcs-Git: git://anonscm.debian.org/pkg-db/py-lmdb.git
 
-Package: python-lmdb
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
-Description: Python binding for LMDB Lightning Memory-Mapped Database
- Lighting Memory-Mapped Database (LMDB) is an ultra-fast, ultra-compact
- key-value embedded data store developed for the OpenLDAP Project. It uses
- memory-mapped files, so it has the read performance of a pure in-memory
- database while still offering the persistence of standard disk-based
- databases, and is only limited to the size of the virtual address space (it
- is not limited to the size of physical RAM).
- .
- This package contains the 'lmdb' Python extension module.
-
 Package: python3-lmdb
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
 Description: Python 3 binding for LMDB Lightning Memory-Mapped Database
- Lighting Memory-Mapped Database (LMDB) is an ultra-fast, ultra-compact
+ Lightning Memory-Mapped Database (LMDB) is an ultra-fast, ultra-compact
  key-value embedded data store developed for the OpenLDAP Project. It uses
  memory-mapped files, so it has the read performance of a pure in-memory
  database while still offering the persistence of standard disk-based
diff -Nru py-lmdb-0.86/debian/rules py-lmdb-0.86/debian/rules
--- py-lmdb-0.86/debian/rules	2015-07-04 16:55:26.0 -0400
+++ py-lmdb-0.86/debian/rules	2019-12-20 15:54:49.0 -0500
@@ -5,7 +5,7 @@
 export PYBUILD_NAME=lmdb
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_clean:
 	dh_auto_clean

Bug#947092: Package absent from mirrors [libhttp-cookies-perl]

[biguibi]

Package: libhttp-cookies-perl
Version: 6.04-1

While trying to install a desktop environment in a virtual machine
(virt-manager, Debian 10 Standard amd64), halfway through the download
process an error pops up saying it couldn't find a specific package
called libhttp-cookies-perl.

E: Failed to fetch 
http://deb.debian.org/debian/pool/main/libh/libhttp-cookies-perl/libhttp-cookies-perl_6.04-1_all.deb
404 Not Found [IP: 151.101.92.204 80]

After looking through some random mirrors, I've realized this package
is absent from every single one of them, including Debian's main
mirror.

While other packages could be downloaded right from the web browser,
trying to download this specific package gives an error of page not
found.

The absense of this package makes it impossible to install any desktop
environment trough apt itself on a non-graphical and possibly even
minimal installations.

Also, the DNS servers being used on my network are 8.8.8.8 and 8.8.4.4
although it's very likely not to be related to the issue since changing
it did not fix the problem for me.

Bug#937606: Droping Python2 support for Biopython

[Michael Crusoe]

On Fri, Dec 20, 2019 at 12:51 PM Andreas Tille  wrote:

> On Fri, Dec 20, 2019 at 03:15:49PM +, Peter Cock wrote:
> > We (upstream) have just released Biopython 1.76 which should be
> > the final release to support Python 2 anyway:
>
> Cool.  Its dropped from the Debian package anyway so we just do
> a simple upgrade (if time permits ... any takers welcome).
>

python-biopython 1.76-1 is already pushed to salsa.debian.org and will be
uploaded to the archive once the current release has migrated to testing
:-)


-- 
Michael R. Crusoe

Bug#937606: Droping Python2 support for Biopython

[Andreas Tille]

On Fri, Dec 20, 2019 at 03:15:49PM +, Peter Cock wrote:
> We (upstream) have just released Biopython 1.76 which should be
> the final release to support Python 2 anyway:

Cool.  Its dropped from the Debian package anyway so we just do
a simple upgrade (if time permits ... any takers welcome).

Kind regards and thanks for letting us know as always

Andreas.

-- 
http://fam-tille.de

Bug#946060: Debian isn't affected by CVE-2019-3866

[Salvatore Bonaccorso]

Hi Thomas,

On Fri, Dec 20, 2019 at 01:46:22PM +0100, Thomas Goirand wrote:
> Hi,
> 
> As I understand it, this bug concerns TripleO, which is a Red Hat
> product. Please clear this CVE from the Debian security tracker.

whilst it was reported initially for a TripleO issue, the changes
applied are affecting the python-mistral-lib/mistral and needs changes
in python-oslo.utils as pre-requisite.

See: https://bugs.launchpad.net/tripleo/+bug/1850843

and the fix in the python-oslo.utils part is

https://opendev.org/openstack/oslo.utils/commit/b41268417cecb12d1d5955ee3107067edf050221

while the patches for mistral/python-mistral-lib are as follows:

Patch for Pike and newer: 
https://launchpadlibrarian.net/449473654/0001-Ensure-we-mask-sensitive-data-from-Mistral-Action-lo.patch
Patch for Pike and newer: 
https://launchpadlibrarian.net/449472809/0001-Ensure-we-mask-sensitive-data-from-Mistral-Action-lo.patch

My point here was, it might have impact outside TripleO, there are
changes done defintively in the scope of the respective above
mentioned source packages in Debian. One might on the other side
defintively argue this all might not warrant any DSA handling (which I
might tend to agree).

What am I'm missing in the context?

Regards,
Salvatore

Bug#947091: manpages-dev: timerfd_settime can fail with ECANCELED

[Marc Lehmann]

Package: manpages-dev
Version: 5.04-1
Severity: wishlist

Dear Maintainer,

the timerfd_create/settime/... manpage documents that reads from a timerfd
configured with TFD_TIMER_CANCEL_ON_SET fail with ECANCELED, however, I
found that timerfd_settime (and probably timerfd_gettime and others) have
the same behaviour, and of course youc an poll for this event as well, and
all this is not documented.

Background: I was implementing time jump detection in libev using the
relatively new TFD_TIMER_CANCEL_ON_SET feature. For this, I arm the timer
with some future value and only use it for the side effect of getting
canceled (although it might occasionally expire).

The timerfd_create/settime calls look like this (future it_value.tv_sec
value, zero interval):

   timerfd_create(CLOCK_REALTIME, TFD_CLOEXEC|TFD_NONBLOCK) = 5
   timerfd_settime(5, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET, 
{it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=1579464284, tv_nsec=0}}, 
NULL) = 0

all normal so far: On every time jump, I rearm the timer with
timerfd_settime, without having any other interaction with the timerfd
(other than polling it for read events). The following is the effect of
"date -s somevalue" three times:

   timerfd_settime(5, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET, 
{it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=949273200, tv_nsec=0}}, 
NULL) = -1 ECANCELED (Operation canceled)
   timerfd_settime(5, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET, 
{it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=949273200, tv_nsec=0}}, 
NULL) = -1 ECANCELED (Operation canceled)
   timerfd_settime(5, TFD_TIMER_ABSTIME|TFD_TIMER_CANCEL_ON_SET, 
{it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=949273200, tv_nsec=0}}, 
NULL) = -1 ECANCELED (Operation canceled)

>From this, I learn that timerfd_settime fails the same way as a read would
do (probably some error slippage happening) and despite timerfd_settime
failing with ECANCELED, it actually succeeds in rearming the timer.

Don't know if this is a kernel bug, but I assume this works more or less
as designed, but has escaped the documentation as TFD_TIMER_CANCEL_ON_SET
is a relatively new feature.

As a minor nitpick, the "Operating on a timer file descriptor" is a tiny
bit misleading, as it doesn't mention timerfd_gettime etc. as supported
"operations on a timerfd fd". And while it probably isn't a major thing in
the context, I do expect the utmost exactness from manpages-dev because
that is my past experiencw with it, so I suggest adding "additional" here:

   The file descriptor returned by timerfd_create() supports the
   following additional operations:

Thanks,
Marc

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

Kernel: Linux 5.2.21-050221-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.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 manpages-dev depends on:
ii  manpages  4.16-2

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  konqueror [man-browser]  4:18.12.0-1
ii  man-db [man-browser] 2.8.5-2

-- no debconf information

Bug#929045: mark python-cycler Multi-Arch: foreign

[Helmut Grohne]

Hi Sandro,

On Fri, Dec 20, 2019 at 12:38:10AM -0500, Sandro Tosi wrote:
> > pymvpa2 fails to satisfy its cross Build-Depends, because its dependency
> > on python-cycler is unsatisfiable. python-cycler is a Python module that
> 
> on what arch specifically? i cant find any BD-uninstallable arch at
> https://buildd.debian.org/status/package.php?p=pymvpa2=unstable
> that's due to python-cycler.

Likely on any architecture, but I only checked on amd64. The buildd
pages only list native satisfiability though. Refer to
https://qa.debian.org/dose/debcheck/src/pymvpa2.html to also see cross
builds. That view is kinda limited though as it only displays one random
of many problems. It often makes sense to also check
https://bootstrap.debian.net/cross_all/pymvpa2.html. Only then you spot
python-cycler. python-cycler is one of many reasons here.

> i'd really like not to add this m-a tag tbh

I think we need to talk about this. You didn't give a reasons for why
you dislike it. Let me give my reasons for doing it to avoid more back
and forth.

There is prior art. A fair number of python modules in Architecture: all
packages (around 100) are already tagged Multi-Arch: foreign.  Notable
examples include python3-six, python3-pkg-resources and
python3-distutils. Why would you want python modules to be
inconsistently maintained?

We're not adding such marking for the fun of it. There is a concrete
underlying problem being solved. If you don't like my solution, can you
think of a different solution to the underlying problem? You can get an
overview of non-temporary satisfiability issues in unstable at
https://bootstrap.debian.net/cross_all.html (huge html). You'll find
lots of satisfiability issues involve python modules. I agree that
sometimes marking modules Multi-Arch: foreign can be wrong (e.g. for
extension modules or modules that have a dependency on an extension
module), but why not use the easy solution when it is available?

Please treat python-cycler as an example instance of a problem class
here.  It really affects very many packages and we want a solution that
is acceptable to many packages. Beware that we may end up changing
around 1000 packages to fully solve this, so we better get this right.

Helmut

Bug#947040: kopano-core: PIDFILE in /etc/init.d/kopano-* does not match /etc/kopano/*.cfg

[Carsten Schoenert]

Hello Albert,

Am 20.12.19 um 07:02 schrieb Albert (programming):
> Hello Carsten,
> 
> You're right, my bug-report is a duplicate of the one you mentioned.
> Please mark my ticket so, I'm looking forward for the next point
> release.

you are welcome! No worries.

> I was already puzzled that nobody filed a bug-report for this, now I
> see that it was filed in sid.>
> Is it custom in the debian-world to report bugs for testing only, not
> for stable?

No, we explicitly need also bug reports for stable releases, othwise we
would even know if there is a problem. And also this makes found issues
by user more transparent for their used release.

So please file bug reports also for packages in stable.

> In the future I'm willing to do testing for you, for the moment I'm
> just happy that my 3rd install-from-scratch while still having my
> mail-database just works. Thanks to you guys it was a lot easier than
> installing the communitiy-edition from kopano.

This was one of the intentions for packaging the Kopano suite. So thanks
for using it.

Unfortunately upstream isn't helping that much to keep a version in
stable provided with all the needed security and issue fixes. Now there
is version 9 out and version 8 of Kopano will get abandoned I guess and
fear. But the release team will for sure not allow to update the version
Debian stable.

-- 
Regards
Carsten Schoenert

Bug#946574: Add --conformable option to output all conformable units

[積丹尼 Dan Jacobson]

> "AM" == Adrian Mariano  writes:
AM> So basically you're asking for a command line equivalent to the '?' 
interactive command?

Well, please first fix this
$ units FORCE \?
Unknown unit '?'

so it works just like

AM> You have: FORCE
AM> You want: ?

Next, if we gave it
You have: cm
You have: 3.75cm
You have: m

Then the
You want: ?
should be enhanced to give different output for each.

Bug#947090: pam-python: autopkgtest failure: security/pam_appl.h: No such file or directory

[Paul Gevers]

Source: pam-python
Version: 1.0.7-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of pam-python you added an autopkgtest to
pam-python, great. However, it fails. I copied some of the output at the
bottom of this report. Currently this failure is blocking the migration
to testing [1]. Can you please investigate the situation and fix it?

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pam-python/3457327/log.gz

autopkgtest [21:30:50]: test pam-python-test.sh: [---
make: Entering directory
'/tmp/autopkgtest-lxc.trt0x6b1/downtmp/build.uXX/src/src'
gcc -O0 -Wall -Wextra -Wundef -Wshadow -Wpointer-arith
-Wbad-function-cast -Wsign-compare -Waggregate-return
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Werror
-g -o ctest ctest.c -lpam
ctest.c:16:10: fatal error: security/pam_appl.h: No such file or directory
   16 | #include 
  |  ^
compilation terminated.
make: *** [Makefile:30: ctest] Error 1
make: Leaving directory
'/tmp/autopkgtest-lxc.trt0x6b1/downtmp/build.uXX/src/src'
autopkgtest [21:30:50]: test pam-python-test.sh: ---]



signature.asc
Description: OpenPGP digital signature

Bug#946852:

[Marcus Furlong]

Removing `,rsa1` in /usr/share/perl5/Smokeping/probes/SSH.pm fixes the issue.

-- 
Marcus Furlong

Bug#945560: Bug#946747: rust-buffered-reader: autopkgtest failure: no matching package named `bzip2` found

[Daniel Kahn Gillmor]

Version: 0.13.0-1

On Sun 2019-12-15 08:29:58 +0100, in #946747, Paul Gevers wrote:
> autopkgtest [03:58:52]: test command5:
> /usr/share/cargo/bin/cargo-auto-test buffered-reader 0.12.0
> --all-targets --features compression-deflate
> autopkgtest [03:58:52]: test command5: [---
> debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
> debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
> x86_64-linux-gnu
> debian cargo wrapper: linking /usr/share/cargo/registry/* into
> /tmp/tmp.3gOH0iUboN/registry/
> debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
> debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
> x86_64-linux-gnu
> debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1',
> '/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose',
> '-j2', '--target', 'x86_64-unknown-linux-gnu', '--all-targets',
> '--features', 'compression-deflate'],) {}
> error: no matching package named `bzip2` found
> location searched: registry `https://github.com/rust-lang/crates.io-index`
> required by package `buffered-reader v0.12.0
> (/usr/share/cargo/registry/buffered-reader-0.12.0)`
> autopkgtest [03:58:52]: test command5: ---]

I believe that this bug report about the autopkgtest for
rust-buffered-reader (#946747) is due to the same underlying problem
described in #945560.

I've worked around #946747 in rust-buffered-reader version 0.13.0-1 by
marking the affected tests as "flakey".  This is disappointing, but i
don't know how to fix #945560 myself.

  --dkg


signature.asc
Description: PGP signature

Bug#944744: bitcoind: Status of the Bitcoin Core package in Debian

[Jonas Smedegaard]

Quoting Marco Falke (2019-12-20 20:33:10)
> Just a follow-up question to your suggestion to let the package bitrot 
> or kick it out after it is no longer maintained: Would it be possible 
> to provide newer versions of Bitcoin Core via "backports" packages. I 
> think this is done for current versions of clang: 
> https://packages.debian.org/buster-backports/clang-8

Yes, that is indeed possible.

 - Jonas

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

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


signature.asc
Description: signature

Bug#947089: uftrace: blocked migration to testing: autopkgtest times out on arm64 and FTBFS on armhf

[Paul Gevers]

Source: uftrace
Version: 0.9.3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
Tags: ftbfs
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of uftrace you added an autopkgtest to uftrace,
great. However, it fails due to timeout on arm64. Currently this failure
is blocking the migration to testing [1]. Additionally the package fails
to armhf [2]. The amd64 binary upload can be fixed by a binNMU, but we
prefer source only uploads nowadays. Can you please investigate the
situation and fix the arm64 autopkgtest timeout and armhf ftbfs?

Paul

[1] https://qa.debian.org/excuses.php?package=uftrace

[2]
Tail of log for uftrace on armhf:

gcc -D_GNU_SOURCE -ffile-prefix-map=/<>=. -Wdate-time
-D_FORTIFY_SOURCE=2 -iquote /<> -iquote /<>
-iquote /<>/arch/arm -W -Wall -Wno-unused-parameter
-Wno-missing-field-initializers -O2 -g -DHAVE_CXA_DEMANGLE
-DHAVE_LIBPYTHON2 -DHAVE_PERF_CLOCKID -DHAVE_PERF_CTXSW
-DHAVE_ARM_HARDFP -DHAVE_LIBNCURSES -D_DEFAULT_SOURCE
-D_XOPEN_SOURCE=600 -DHAVE_LIBELF -DHAVE_LIBDW  -DHAVE_LIBCAPSTONE
-I/usr/include/capstone   -fPIC -fvisibility=hidden
-fno-omit-frame-pointer -c -o
/<>/libmcount/symbol-libelf.op
/<>/utils/symbol-libelf.c
gcc -D_GNU_SOURCE -ffile-prefix-map=/<>=. -Wdate-time
-D_FORTIFY_SOURCE=2 -iquote /<> -iquote /<>
-iquote /<>/arch/arm -W -Wall -Wno-unused-parameter
-Wno-missing-field-initializers -O2 -g -DHAVE_CXA_DEMANGLE
-DHAVE_LIBPYTHON2 -DHAVE_PERF_CLOCKID -DHAVE_PERF_CTXSW
-DHAVE_ARM_HARDFP -DHAVE_LIBNCURSES -D_DEFAULT_SOURCE
-D_XOPEN_SOURCE=600 -DHAVE_LIBELF -DHAVE_LIBDW  -DHAVE_LIBCAPSTONE
-I/usr/include/capstone   -fPIC -fvisibility=hidden
-fno-omit-frame-pointer -c -o /<>/libmcount/symbol.op
/<>/utils/symbol.c
gcc -D_GNU_SOURCE -ffile-prefix-map=/<>=. -Wdate-time
-D_FORTIFY_SOURCE=2 -iquote /<> -iquote /<>
-iquote /<>/arch/arm -W -Wall -Wno-unused-parameter
-Wno-missing-field-initializers -O2 -g -DHAVE_CXA_DEMANGLE
-DHAVE_LIBPYTHON2 -DHAVE_PERF_CLOCKID -DHAVE_PERF_CTXSW
-DHAVE_ARM_HARDFP -DHAVE_LIBNCURSES -D_DEFAULT_SOURCE
-D_XOPEN_SOURCE=600 -DHAVE_LIBELF -DHAVE_LIBDW  -DHAVE_LIBCAPSTONE
-I/usr/include/capstone   -fPIC -fvisibility=hidden
-fno-omit-frame-pointer -c -o /<>/arch/arm/mcount.op
/<>/arch/arm/mcount.S
gcc -D_GNU_SOURCE -ffile-prefix-map=/<>=. -Wdate-time
-D_FORTIFY_SOURCE=2 -iquote /<> -iquote /<>
-iquote /<>/arch/arm -W -Wall -Wno-unused-parameter
-Wno-missing-field-initializers -O2 -g -DHAVE_CXA_DEMANGLE
-DHAVE_LIBPYTHON2 -DHAVE_PERF_CLOCKID -DHAVE_PERF_CTXSW
-DHAVE_ARM_HARDFP -DHAVE_LIBNCURSES -D_DEFAULT_SOURCE
-D_XOPEN_SOURCE=600 -DHAVE_LIBELF -DHAVE_LIBDW  -DHAVE_LIBCAPSTONE
-I/usr/include/capstone   -fPIC -fvisibility=hidden
-fno-omit-frame-pointer -c -o /<>/arch/arm/plthook.op
/<>/arch/arm/plthook.S
gcc -D_GNU_SOURCE -ffile-prefix-map=/<>=. -Wdate-time
-D_FORTIFY_SOURCE=2 -iquote /<> -iquote /<>
-iquote /<>/arch/arm -W -Wall -Wno-unused-parameter
-Wno-missing-field-initializers -O2 -g -DHAVE_CXA_DEMANGLE
-DHAVE_LIBPYTHON2 -DHAVE_PERF_CLOCKID -DHAVE_PERF_CTXSW
-DHAVE_ARM_HARDFP -DHAVE_LIBNCURSES -D_DEFAULT_SOURCE
-D_XOPEN_SOURCE=600 -DHAVE_LIBELF -DHAVE_LIBDW  -DHAVE_LIBCAPSTONE
-I/usr/include/capstone   -fPIC -fvisibility=hidden
-fno-omit-frame-pointer -c -o
/<>/arch/arm/mcount-support.op
/<>/arch/arm/mcount-support.c
/<>/arch/arm/mcount-support.c: In function
‘mcount_arch_parent_location’:
/<>/arch/arm/mcount-support.c:289:2: error: ‘cache’
undeclared (first use in this function)
  289 |  cache = lookup_cache(_cache, sym->addr, true);
  |  ^
/<>/arch/arm/mcount-support.c:289:2: note: each undeclared
identifier is reported only once for each function it appears in
make[2]: *** [Makefile:28: /<>/arch/arm/mcount-support.op]
Error 1
make[1]: *** [Makefile:242: /<>/arch/arm/mcount-entry.op]
Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
make: *** [debian/rules:14: binary-arch] Error 255



signature.asc
Description: OpenPGP digital signature

Bug#938178: python-snappy: diff for NMU version 0.5.3-1.1

[Sandro Tosi]

Control: tags 938178 + patch


Dear maintainer,

I've prepared an NMU for python-snappy (versioned as 0.5.3-1.1). The diff
is attached to this message.

Regards.

diff -Nru python-snappy-0.5.3/debian/changelog python-snappy-0.5.3/debian/changelog
--- python-snappy-0.5.3/debian/changelog	2018-07-31 09:33:13.0 -0400
+++ python-snappy-0.5.3/debian/changelog	2019-12-20 14:36:43.0 -0500
@@ -1,3 +1,10 @@
+python-snappy (0.5.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938178
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 14:36:43 -0500
+
 python-snappy (0.5.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-snappy-0.5.3/debian/control python-snappy-0.5.3/debian/control
--- python-snappy-0.5.3/debian/control	2018-07-31 09:33:13.0 -0400
+++ python-snappy-0.5.3/debian/control	2019-12-20 14:36:00.0 -0500
@@ -5,26 +5,11 @@
 Build-Depends: debhelper (>= 9),
dh-python,
libsnappy-dev,
-   python-all-dev,
-   python-setuptools,
python3-all-dev,
python3-setuptools,
 Standards-Version: 4.1.5
 Homepage: http://github.com/andrix/python-snappy
 
-Package: python-snappy
-Architecture: any
-Depends: ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends},
-Description: snappy compression library from Google - Python 2.7
- Snappy is a compression/decompression library. It does not aim for
- maximum compression, or compatibility with any other compression
- library; instead, it aims for very high speeds and reasonable
- compression. You can read package libsnappy1 for more information.
- .
- This package provides the Python 2.7 module.
-
 Package: python3-snappy
 Architecture: any
 Depends: ${misc:Depends},
diff -Nru python-snappy-0.5.3/debian/rules python-snappy-0.5.3/debian/rules
--- python-snappy-0.5.3/debian/rules	2018-07-31 09:33:13.0 -0400
+++ python-snappy-0.5.3/debian/rules	2019-12-20 14:36:39.0 -0500
@@ -1,7 +1,6 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
-PYTHONS:=$(shell pyversions -vr)
 PYTHON3S:=$(shell py3versions -vr)
 
 DEBVERS ?= $(shell dpkg-parsechangelog -SVersion)
@@ -16,7 +15,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
 
 %:
-	dh $@ --buildsystem=python_distutils --with python2,python3
+	dh $@ --buildsystem=pybuild --with python3
 
 override_dh_auto_clean:
 	dh_auto_clean
@@ -24,10 +23,6 @@
 	rm -rf python_snappy.egg-info
 
 override_dh_auto_install:
-	set -e ; for pyvers in $(PYTHONS); do \
-		python$$pyvers setup.py install --install-layout=deb \
-			--root $(CURDIR)/debian/python-snappy; \
-	done
 	set -e ; for pyvers in $(PYTHON3S); do \
 		python$$pyvers setup.py install --install-layout=deb \
 			--root $(CURDIR)/debian/python3-snappy; \

Bug#947088: debcargo should provide test-name for generated autopkgtests

[Daniel Kahn Gillmor]

On Fri 2019-12-20 14:33:41 -0500, Daniel Kahn Gillmor wrote:
> When debcargo generates tests, it uses Test-Command in
> debian/tests/control.
>
> When running them, they're run in autopkgtest and they are reported as
> "command1", "command2", etc.
>
> debcargo should use the "Test-Name" directive in tests/debian/control to
> give these autogenerated autopkgtest instances more
> accessible/meaningful names.

according to
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst
it looks like this would mean each debian/tests/control stanza needs:

Features: test-name=good-description-here

hth,

  --dkg


signature.asc
Description: PGP signature

Bug#944744: bitcoind: Status of the Bitcoin Core package in Debian

[Marco Falke]

Just a follow-up question to your suggestion to let the package bitrot
or kick it out after it is no longer maintained: Would it be possible
to provide newer versions of Bitcoin Core via "backports" packages. I
think this is done for current versions of clang:
https://packages.debian.org/buster-backports/clang-8

Bug#902834: zim and slob files bug related idea for a patch

[corlem]

Dear Maintainer,

Thank you for taking care of goldendict debian package.

Zim and slob files are not supported either with testing package, i.e version
1.5.0~rc2+git20190930+ds-1 (same bug).

As far as I can say, it might be related to the debian/rule file.

---
override_dh_auto_configure:
dh_auto_configure -- \
 CONFIG+=chinese_conversion_support \
 CONFIG+=CONFIG+=zim_support \
 goldendict.pro


"CONFIG+=CONFIG+=" is rather strange for an auto-configure option.  As soon as 
you correct it and rebuild the goldendict package, this program can read any 
zim or slob dictionary file of whatever size.

Best regards
Corlem

Bug#947088: debcargo should provide test-name for generated autopkgtests

[Daniel Kahn Gillmor]

Package: debcargo
Version: 2.4.0-1
Severity: wishlist

When debcargo generates tests, it uses Test-Command in
debian/tests/control.

When running them, they're run in autopkgtest and they are reported as
"command1", "command2", etc.

debcargo should use the "Test-Name" directive in tests/debian/control to
give these autogenerated autopkgtest instances more
accessible/meaningful names.

   --dkg


signature.asc
Description: PGP signature

Bug#945920: Chromium randomly crashes in the latest version.

[Alexander Chernaev]

Dear Maintainer,

Managed to get a stacktrace and package info which I hope can help fix this 
issue.

Cheers,
Alexander

gdb stacktrace:

Thread 1 "chromium" received signal SIGSEGV, Segmentation fault.
0x5a77cee7 in 
memory_instrumentation::MemoryInstrumentation::RequestGlobalDump(std::vector, std::allocator >, 
std::allocator, 
std::allocator > > > const&, base::OnceCallback >)>) ()
(gdb) bt
#0  0x5a77cee7 in 
memory_instrumentation::MemoryInstrumentation::RequestGlobalDump(std::vector, std::allocator >, 
std::allocator, 
std::allocator > > > const&, base::OnceCallback >)>) ()
#1  0x58f8ddb0 in 
ProcessMemoryMetricsEmitter::FetchAndEmitProcessMemoryMetrics() ()
#2  0x58f85e82 in (anonymous namespace)::RecordMemoryMetrics() ()
#3  0x593b5165 in base::TaskAnnotator::RunTask(char const*, 
base::PendingTask*) ()
#4  0x593c466b in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*,
 bool*) ()
#5  0x593c5fec in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork()
 ()
#6  0x59376aca in base::(anonymous 
namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) ()
#7  0x77079ead in g_main_context_dispatch () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8  0x7707a130 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9  0x7707a1bf in g_main_context_iteration () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x59376dd0 in 
base::MessagePumpGlib::Run(base::MessagePump::Delegate*) ()
#11 0x593c62a9 in 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool,
 base::TimeDelta) ()
#12 0x593a22fa in base::RunLoop::Run() ()
#13 0x58ea8217 in ChromeBrowserMainParts::MainMessageLoopRun(int*) ()
#14 0x571cd1c6 in content::BrowserMainLoop::RunMainMessageLoopParts() ()
#15 0x571cd375 in content::BrowserMainRunnerImpl::Run() ()
#16 0x571a35f7 in content::BrowserMain(content::MainFunctionParams 
const&) ()
#17 0x58e30101 in 
content::RunBrowserProcessMain(content::MainFunctionParams const&, 
content::ContentMainDelegate*) ()
#18 0x58e30338 in 
content::ContentMainRunnerImpl::RunServiceManager(content::MainFunctionParams&, 
bool) ()
#19 0x58e306a7 in content::ContentMainRunnerImpl::Run(bool) ()
#20 0x58e66802 in service_manager::Main(service_manager::MainParams 
const&) ()
#21 0x58e2e0c6 in content::ContentMain(content::ContentMainParams 
const&) ()
#22 0x5635c3e5 in ChromeMain ()
#23 0x7129fbbb in __libc_start_main (main=0x56339f80 , 
argc=10, argv=0x7fffdce8, init=, fini=, 
rtld_fini=, stack_end=0x7fffdcd8)
at ../csu/libc-start.c:308
#24 0x5635c22a in _start ()

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

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

Versions of packages chromium depends on:
ii  chromium-common  79.0.3945.79-1
ii  libasound2   1.1.9-1
ii  libatk-bridge2.0-0   2.34.1-2
ii  libatk1.0-0  2.34.1-1
ii  libatomic1   9.2.1-21
ii  libatspi2.0-02.34.0-3
ii  libavcodec58 7:4.2.1-2
ii  libavformat587:4.2.1-2
ii  libavutil56  7:4.2.1-2
ii  libc62.29-3
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.3.0-7
ii  libdbus-1-3  1.12.16-2
ii  libdrm2  2.4.100-4
ii  libevent-2.1-7   2.1.11-stable-1
ii  libexpat12.2.9-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgcc1  1:9.2.1-21
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libglib2.0-0 2.62.3-2
ii  libgtk-3-0   3.24.13-1
ii  libharfbuzz0b2.6.4-1
ii  libicu63 63.2-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3+b1
ii  liblcms2-2   2.9-3+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.23-1
ii  libnss3  2:3.47.1-1
ii  libopenjp2-7 2.3.1-1
ii  libopus0 1.3-1+b1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpci3  1:3.6.2-6
ii  libpng16-16  1.6.37-1
ii  libpulse013.0-3
ii  libre2-5 20191101+dfsg-1
ii  libsnappy1v5 1.1.7-2
ii  libstdc++6   9.2.1-21
ii  libva2   2.5.0-2
ii  libvpx6  1.8.1-2
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux2 

Bug#947087: RM: birdtray [armhf armel] -- ROM; {,B-}Dep thunderbird no longer built on armhf armel

[Adam Borowski]

Package: ftp.debian.org
Severity: normal

Hi!
As thunderbird is no longer built on armhf and armel, please RM birdtray for
those architectures as well.

Bug#947003: [Pkg-utopia-maintainers] Bug#947003: 947...@bugs.debian.org (network-manager: Incorrect update of /etc/resolv.conf, bad search field)

[Jean-Francois Pirus]

This is my dhcp server setting using dnsmasq:
in /etc/dnsmasq.d/local.conf
dhcp-option=option:domain-search,private,blah.private,blah.com

tried with just blah.com got blahcom
tried with just test.blah.com got testblahcom

Bug#938052: python-ptrace: diff for NMU version 0.9.3-2.2

[Sandro Tosi]

Control: tags 938052 + patch


Dear maintainer,

I've prepared an NMU for python-ptrace (versioned as 0.9.3-2.2). The diff
is attached to this message.

Regards.

diff -Nru python-ptrace-0.9.3/debian/changelog python-ptrace-0.9.3/debian/changelog
--- python-ptrace-0.9.3/debian/changelog	2018-08-07 04:33:18.0 -0400
+++ python-ptrace-0.9.3/debian/changelog	2019-12-20 14:03:21.0 -0500
@@ -1,3 +1,10 @@
+python-ptrace (0.9.3-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938052
+
+ -- Sandro Tosi   Fri, 20 Dec 2019 14:03:21 -0500
+
 python-ptrace (0.9.3-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-ptrace-0.9.3/debian/control python-ptrace-0.9.3/debian/control
--- python-ptrace-0.9.3/debian/control	2018-08-07 04:33:18.0 -0400
+++ python-ptrace-0.9.3/debian/control	2019-12-20 14:03:21.0 -0500
@@ -3,32 +3,12 @@
 Priority: optional
 Maintainer: Pierre Chifflier 
 Build-Depends: debhelper (>= 9),
-python-all (>= 2.3.5-11),
+dh-python,
 python3-dev
 Standards-Version: 4.1.4
 Homepage: https://github.com/vstinner/python-ptrace
 Rules-Requires-Root: no
 
-Package: python-ptrace
-Architecture: all
-XB-Python-Version: ${python:Versions}
-Depends: ${python:Depends}, ${misc:Depends}
-Provides: ${python:Provides}
-Description: Python bindings for ptrace
- This package provides Python bindings for the ptrace library. It allows
- controlling, debugging, or modifying processes using the ptrace syscall.
- .
- Features:
-  * High level Python object API
-  * Able to control multiple processes: catch fork events
-  * Read/write bytes to arbitrary addresses
-  * Execution step by step using ptrace_singlestep() or hardware int 3
-  * Can use distorm disassembler
-  * Dump registers, memory mappings, stack, etc.
-  * Syscall tracer and parser (strace command)
- .
- This package provides the ptrace Python module for Python 2.x.
-
 Package: python3-ptrace
 Architecture: all
 XB-Python-Version: ${python3:Versions}
diff -Nru python-ptrace-0.9.3/debian/pycompat python-ptrace-0.9.3/debian/pycompat
--- python-ptrace-0.9.3/debian/pycompat	2015-03-25 13:04:02.0 -0400
+++ python-ptrace-0.9.3/debian/pycompat	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-2
diff -Nru python-ptrace-0.9.3/debian/pyversions python-ptrace-0.9.3/debian/pyversions
--- python-ptrace-0.9.3/debian/pyversions	2015-03-25 13:04:04.0 -0400
+++ python-ptrace-0.9.3/debian/pyversions	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-2.6-
diff -Nru python-ptrace-0.9.3/debian/rules python-ptrace-0.9.3/debian/rules
--- python-ptrace-0.9.3/debian/rules	2018-04-29 08:37:01.0 -0400
+++ python-ptrace-0.9.3/debian/rules	2019-12-20 14:03:01.0 -0500
@@ -7,9 +7,8 @@
 override_dh_auto_install:
 	dh_auto_install
 	# do not install examples as real executables
-	rm -rf $(CURDIR)/debian/python-ptrace/usr/bin
 	rm -rf $(CURDIR)/debian/python3-ptrace/usr/bin
 
 %:
-	dh $@ --with=python2,python3 --buildsystem=pybuild
+	dh $@ --with=python3 --buildsystem=pybuild
 

Bug#936464: eclipse-titan: diff for NMU version 6.6.0-1.1

[Adrian Bunk]

Control: tags 936464 + patch
Control: tags 936464 + pending

Dear maintainer,

I've prepared an NMU for eclipse-titan (versioned as 6.6.0-1.1) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru eclipse-titan-6.6.0/debian/changelog eclipse-titan-6.6.0/debian/changelog
--- eclipse-titan-6.6.0/debian/changelog	2019-08-25 16:43:49.0 +0300
+++ eclipse-titan-6.6.0/debian/changelog	2019-12-20 19:54:28.0 +0200
@@ -1,3 +1,11 @@
+eclipse-titan (6.6.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove the dependency on python, the python scripts were
+already removed upstream. (Closes: #936464)
+
+ -- Adrian Bunk   Fri, 20 Dec 2019 19:54:28 +0200
+
 eclipse-titan (6.6.0-1) unstable; urgency=high
 
   * New release.
diff -Nru eclipse-titan-6.6.0/debian/control eclipse-titan-6.6.0/debian/control
--- eclipse-titan-6.6.0/debian/control	2019-07-29 19:03:13.0 +0300
+++ eclipse-titan-6.6.0/debian/control	2019-12-20 19:54:28.0 +0200
@@ -23,7 +23,6 @@
  libxml2-dev,
  make,
  perl,
- python,
  gcc (>= ${gcc:Version}),
  gcc (<< ${gcc:Version}.0),
  ${misc:Depends},

Bug#946886: [Pkg-rust-maintainers] Bug#946886: rustc: FTBFS on mips/mipsel with test failures in sync::atomic::Atomic*

[Ximin Luo]

Hi YunQiang,

Debian rustc with LLVM 9 is ready to go in git 
https://salsa.debian.org/rust-team/rust/

Backporting that patch to Debian LLVM is underway in #946874.

X

YunQiang Su:
> Raphaël Hertzog  于2019年12月17日周二 下午5:39写道：
>>
>> Source: rustc
>> Version: 1.39.0+dfsg1-3
>> Severity: serious
>> Justification: FTBFS
>>
>> rustc is not migrating to testing (and thus holding up migration of the
>> latest thunderbird) because it fails to build on mipsel and mips64el with
>> too many test failures:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=rustc=mips64el=1.39.0%2Bdfsg1-3=1575833439=0
> 
> It seems due to
>https://reviews.llvm.org/rGd7357c52a40a136f25c1cf5ae31a699d51885e49
> and llvm-9 seems containing this patch... (backported?
> I am trying to build rustc with llvm-9. Wish it workable.
> 
> Do we have any plan to migrate to llvm-9?
> 
>>  Debian rustc test report 
>> Specific test failures:
>> command did not execute successfully: 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/tidy"
>>  "/<>/src" "/usr/bin/cargo" "--verbose"
>> test [ui] ui/statics/static-function-pointer.rs ... FAILED
>> command did not execute successfully: 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/compiletest"
>>  "--compile-lib-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib" 
>> "--run-lib-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib/rustlib/mips64el-unknown-linux-gnuabi64/lib"
>>  "--rustc-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/bin/rustc" 
>> "--src-base" "/<>/src/test/ui" "--build-base" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/test/ui" 
>> "--stage-id" "stage2-mips64el-unknown-linux-gnuabi64" "--mode" "ui" 
>> "--target" "mips64el-unknown-linux-gnuabi64" "--host" 
>> "mips64el-unknown-linux-gnuabi64" "--llvm-filecheck" 
>> "/usr/lib/llvm-8/bin/FileCheck" "--linker" "mips64el-linux-gnuabi64-gcc" 
>> "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
>> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>>  "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
>> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>>  "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
>> "--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" 
>> "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" 
>> "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" 
>> "--android-cross-path" ""
>> test [debuginfo-gdb+lldb] debuginfo/lexical-scope-in-unconditional-loop.rs 
>> ... FAILED
>> test [debuginfo-gdb+lldb] debuginfo/pretty-uninitialized-vec.rs ... FAILED
>> command did not execute successfully: 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/compiletest"
>>  "--compile-lib-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib" 
>> "--run-lib-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib/rustlib/mips64el-unknown-linux-gnuabi64/lib"
>>  "--rustc-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/bin/rustc" 
>> "--src-base" "/<>/src/test/debuginfo" "--build-base" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/test/debuginfo" 
>> "--stage-id" "stage2-mips64el-unknown-linux-gnuabi64" "--mode" 
>> "debuginfo-gdb+lldb" "--target" "mips64el-unknown-linux-gnuabi64" "--host" 
>> "mips64el-unknown-linux-gnuabi64" "--llvm-filecheck" 
>> "/usr/lib/llvm-8/bin/FileCheck" "--linker" "mips64el-linux-gnuabi64-gcc" 
>> "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
>> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>>  "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
>> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>>  "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
>> "--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" 
>> "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" 
>> "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" 
>> "--android-cross-path" ""
>> test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 60) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 62) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI32::fetch_max (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI32::fetch_max (line 60) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI32::fetch_min (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI32::fetch_min (line 62) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI64::fetch_max (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI64::fetch_max (line 60) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI64::fetch_min 

Bug#947086: spamassassin doesn't start at boot under sysvinit-core after update

[Tomas Pospisek]

Package: spamassassin
Version: 3.4.2-1+deb10u1
Severity: important

It seems that updating spamassassin will remove sysv start links:

root@mail /etc # ls -l rc**/*spam*
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc0.d/K02spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc1.d/K02spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc2.d/K03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc3.d/K03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc4.d/K03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc5.d/K03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc6.d/K02spamassassin -> 
../init.d/spamassassin

root@mail ~ # update-rc.d spamassassin enable

root@mail /etc # ls -l rc**/*spam*
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc0.d/K02spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc1.d/K02spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc2.d/S03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc3.d/S03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc4.d/S03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc5.d/S03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 18:45 rc6.d/K02spamassassin -> 
../init.d/spamassassin

Notice the S* links.

root@mail /etc # LC_ALL=C apt reinstall spamassassin
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.
Need to get 0 B/1126 kB of archives.
After this operation, 0 B of additional disk space will be used.
[master 6e2d3db] saving uncommitted changes in /etc prior to apt run
 Author: Tomas Pospisek
 5 files changed, 1 insertion(+)
 rename rc2.d/{K03spamassassin => S03spamassassin} (100%)
 rename rc3.d/{K03spamassassin => S03spamassassin} (100%)
 rename rc4.d/{K03spamassassin => S03spamassassin} (100%)
 rename rc5.d/{K03spamassassin => S03spamassassin} (100%)
 create mode 12 
systemd/system/multi-user.target.wants/spamassassin.service
(Reading database ... 38518 files and directories currently installed.)
Preparing to unpack .../spamassassin_3.4.2-1+deb10u1_all.deb ...
Unpacking spamassassin (3.4.2-1+deb10u1) over (3.4.2-1+deb10u1) ...
Setting up spamassassin (3.4.2-1+deb10u1) ...
Processing triggers for man-db (2.8.5-2) ...
[master 26b1b46] committing changes in /etc made by "apt reinstall 
spamassassin"
 Author: Tomas Pospisek
 5 files changed, 1 deletion(-)
 rename rc2.d/{S03spamassassin => K03spamassassin} (100%)
 rename rc3.d/{S03spamassassin => K03spamassassin} (100%)
 rename rc4.d/{S03spamassassin => K03spamassassin} (100%)
 rename rc5.d/{S03spamassassin => K03spamassassin} (100%)
 delete mode 12 
systemd/system/multi-user.target.wants/spamassassin.service
Scanning processes...   

   
Scanning candidates...  

   

Restarting services...
 invoke-rc.d dovecot restart
 invoke-rc.d spamassassin restart

No containers need to be restarted.

No user sessions are running outdated binaries.


root@mail /etc # ls -l rc**/*spam* 
lrwxrwxrwx 1 root root 22 Dez 20 19:02 rc0.d/K02spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 19:02 rc1.d/K02spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 19:02 rc2.d/K03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 19:02 rc3.d/K03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 19:02 rc4.d/K03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 19:02 rc5.d/K03spamassassin -> 
../init.d/spamassassin
lrwxrwxrwx 1 root root 22 Dez 20 19:02 rc6.d/K02spamassassin -> 
../init.d/spamassassin

The start links are gone.
*t

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

Kernel: Linux 4.9.0-11-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_CH.UTF-8), LANGUAGE=de_CH.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to de_CH.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages spamassassin depends on:
ii  adduser 3.118
ii  curl 

Bug#942447: Build bwa on ppc64el

[Michael Crusoe]

Control: fixed -1 0.7.17-4

On Wed, 16 Oct 2019 17:21:30 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= Bonnard <
fre...@debian.org> wrote:
> Package: src:bwa
> Version: 0.7.17-3
>
> --
>
> Dear maintainer,
> with some basic changes I could enable bwa to built on ppc64el.
> Here is a merge request :
> https://salsa.debian.org/med-team/bwa/merge_requests/1

Dear Frédéric,

I've merged
https://salsa.debian.org/med-team/bwa/commit/36c81322c38c2db87e793a33bd2c1f7b7c58a71c
instead, which enable building on all architectures including ppc64el using
the SIMDe library: https://github.com/nemequ/simde

If you can help contribute AltiVec implementations for SSE2, SSE, or MMX
intrinsics to SIMDe then that would be very appreciated!

Thank you for your contribution,

-- 
Michael R. Crusoe

Bug#947085: cdebconf: Please omit cdebconf-{gtk,newt}-udeb on Ubuntu/i386

[Steve Langasek]

Package: cdebconf
Version: 0.250
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64.  We are keeping cdebconf on i386 because
it is required by base-passwd, but cdebconf-{gtk,newt}-udeb are built from
this source package and depend on packages we otherwise have no reason to
keep around (rootskel-gtk, di-utils-terminfo).

We would like to drop these udebs rather than keeping them around in the
Ubuntu archive and uninstallable.  Would you please consider applying the
attached patch, or something like it, to omit building these binary packages
on Ubuntu?

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru cdebconf-0.250ubuntu1/debian/rules cdebconf-0.250ubuntu2/debian/rules
--- cdebconf-0.250ubuntu1/debian/rules  2019-10-19 22:42:28.0 -0500
+++ cdebconf-0.250ubuntu2/debian/rules  2019-12-20 11:54:42.0 -0600
@@ -21,6 +21,11 @@
 DEB_FRONTENDS=passthrough text newt gtk
 UDEB_FRONTENDS=passthrough text newt gtk
 
+ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes) $(DEB_HOST_ARCH), yes i386)
+   UDEB_FRONTENDS:=$(filter-out gtk newt,$(UDEB_FRONTENDS))
+   skip_packages = -Ncdebconf-gtk-udeb -Ncdebconf-newt-udeb
+endif
+
 ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
 DEB_FRONTENDS:=$(filter-out gtk,$(DEB_FRONTENDS))
 UDEB_FRONTENDS:=$(filter-out gtk,$(UDEB_FRONTENDS))
@@ -105,7 +110,7 @@
dh_prep
$(MAKE) -C $(debbuild) install DESTDIR=$(CURDIR)/debian/tmp/deb
$(MAKE) -C $(udebbuild) install DESTDIR=$(CURDIR)/debian/tmp/udeb
-   dh_install -a
+   dh_install -a $(skip_packages)
 
 install-indep:
 
@@ -149,9 +154,9 @@
dh_makeshlibs -s --add-udeb=libdebconfclient0-udeb
dh_installdeb -s
dh_shlibdeps -s
-   dh_gencontrol -s
+   dh_gencontrol -s $(skip_packages)
dh_md5sums -s
-   dh_builddeb -s
+   dh_builddeb -s $(skip_packages)
 
 binary: binary-indep binary-arch
 .PHONY: build clean binary-indep binary-arch binary install

Bug#934948: Dropping dependencies to avoid extra binary package when same source package targets more than one environment

[Pirate Praveen]

On Fri, 20 Dec 2019 22:29:33 +0530 Pirate Praveen 
 wrote:
On Fri, 20 Dec 2019 00:01:01 +0530 Pirate Praveen 
 wrote:

>  > * asking the maintainers of the Ruby libraries that ruby-task-list
>  >  recursively depends on (such as ruby-rack) to remove *their* 
> dependencies


Looking at ruby-rack now, it ships /usr/bin/rackup executable. So it 
looks like a new binary package rackup needs to be created in this case 
if I understood the decision correctly. Or can this be considered a 
non-userfacing executable? I don't know if any package use rack directly.


Fortunately, ruby-task-list dropped dependency on ruby-rack from version 
2 and ruby-activesupport and ruby-nokogiri is only required for older 
versions of ruby. So we will just need to take care of 
ruby-html-pipeline and we can remove the other dependencies.

Bug#947084: bluez: please omit bluez-cups on Ubuntu/i386

[Steve Langasek]

Package: bluez
Version: 5.50-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64.  We are keeping bluez on i386 because it
is a build-dependency of python3.8, but bluez-cups is built from this source
package and depends on the cups daemon package which we otherwise have no
reason to keep around.

We would like to drop the bluez-cups binary package rather than keeping it
around in the Ubuntu archive and uninstallable.  Would you please consider
applying the attached patch, or something like it, to omit building this
binary package on Ubuntu?

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru bluez-5.50/debian/rules bluez-5.50/debian/rules
--- bluez-5.50/debian/rules 2018-07-28 21:46:24.0 -0500
+++ bluez-5.50/debian/rules 2019-12-20 11:47:34.0 -0600
@@ -31,6 +31,10 @@
--enable-health \
--enable-experimental
 
+ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes) $(DEB_HOST_ARCH), yes i386)
+   skip_packages = -Nbluez-cups
+endif
+
 %:
dh $@ --with systemd,autoreconf
 
@@ -54,3 +58,9 @@
 
 override_dh_auto_test:
# disable
+
+override_dh_builddeb:
+   dh_builddeb ${skip_packages}
+
+override_dh_gencontrol:
+   dh_gencontrol ${skip_packages}

Bug#947027: linphone does not block sgmltools-lite removal

[Dimitri John Ledkov]

unblock 938473 by 943162
unblock 947027 by 943162
thanks

linphone used to have an unused build-dependency on sgmltools-lite.

Which has now been dropped. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947065

Thus, sgmltools-lite can be removed from unstable now.

-- 
Regards,

Dimitri.

Bug#947083: Buster backport of bird2

[Jonas Meurer]

Package: bird2
Version: 2.0.7-2
Severity: wishlist

Hey Ondřej,

would you consider to upload bird2 to buster-backports? That would be very
helpful in order to use bird2 on routers that run buster.

Cheers
 jonas

Bug#934948: Dropping dependencies to avoid extra binary package when same source package targets more than one environment

[Pirate Praveen]

On Fri, 20 Dec 2019 00:01:01 +0530 Pirate Praveen 
 wrote:

 > * asking the maintainers of the Ruby libraries that ruby-task-list
 >  recursively depends on (such as ruby-rack) to remove *their* 
dependencies


Looking at ruby-rack now, it ships /usr/bin/rackup executable. So it 
looks like a new binary package rackup needs to be created in this case 
if I understood the decision correctly. Or can this be considered a 
non-userfacing executable? I don't know if any package use rack directly.

Bug#923051: Update using Buster

[Bruce Momjian]

I have now upgraded to Buster, and see the same problem. I also see the 
problem using several text editors, not just with mutt, and with 
different terminal emulators  For example, if I am in vim 7.4 (stock) 
and use 'h' and 'l' to move back and forth over this text line:


 xxx , , until 00p

I can clearly see it is not redrawing properly.  Hopefully this is a 
more reproducible test case on a more current version of Debian.


--
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +

Bug#920014: Move forward on this

[Steve McIntyre]

On Fri, Dec 20, 2019 at 03:35:28PM +0100, Perez Yves-Alexis wrote:
>Hi,
>
>could someone from the EFI team review the MR from Luca?
>
>At ANSSI we are testing hardware acquired for the French administration
>for various security requirements [1], one of them beeing that the
>secure boot key should be updatable.
>
>We test this requirement by generating a small PKI and a USB key based
>on various efitools/sbsigntool binaries [2].
>
>The efitools version currently in Debian has a bug which prevents
>updating the platform key on some implementation (for example some
>Lenovo ThinkPads with AMD processors [3]). The bug is fixed in 1.9.0+ so
>it'd be really nice to include it in Debian (for our use case, but more
>generally for all people wanting to update the PK in their machine).
>
>Thanks in advance!

Hey guys,

Apologies, and thanks for mentioning the MR. I hadn't realised that my
salsa notifications were turned off. :-(

Just looking at things now, sorry for the delay. 

Arnaud - are you still planning to work on efitools?

Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Bug#947064: texlive-fonts-extra: fourier-orns.sty broken, docs using the Fourier font no longer compile

[Hilmar Preuße]

Am 20.12.2019 um 12:44 teilte Norbert Preining mit:
> On Fri, 20 Dec 2019, Sebastien Desreux wrote:

Hi,

>> An other way to make the file compile again is to open
>>  /usr/share/texlive/texmf-dist/tex/latex/fourier/fourier.sty 
>> and comment line 52 
>>  \RequirePackage{fourier-orns}
> 
> But 
>   fourier-orns.sty
> is contained in texlive-fonts-extra, so it should be installed.
> 
> Maybe you have some broken file system?
> 
I'm able to reproduce:

hille@sid:~ $ xelatex 947064.tex
This is XeTeX, Version 3.14159265-2.6-0.91 (TeX Live 2019/Debian)
(preloaded format=xelatex)
 restricted \write18 enabled.
entering extended mode
(./947064.tex
LaTeX2e <2019-10-01> patch level 3
(/usr/share/texlive/texmf-dist/tex/latex/base/minimal.cls
Document Class: minimal 2001/05/25 Standard LaTeX minimal class
) (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/l3deprecation.def))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-xdvipdfmx.def)))
(/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/tuenc.def))
(/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
(/usr/share/texlive/texmf-dist/tex/xelatex/xltxtra/xltxtra.sty
(/usr/share/texlive/texmf-dist/tex/generic/iftex/ifluatex.sty
(/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty))
(/usr/share/texlive/texmf-dist/tex/generic/iftex/ifxetex.sty)
(/usr/share/texlive/texmf-dist/tex/latex/realscripts/realscripts.sty)
(/usr/share/texlive/texmf-dist/tex/latex/metalogo/metalogo.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/xetex.def)
(/usr/share/texlive/texmf-dist/tex/xelatex/xunicode/xunicode.sty
(/usr/share/texmf/tex/latex/tipa/t3enc.def))
(/usr/share/texlive/texmf-dist/tex/latex/fouriernc/fouriernc.sty
(/usr/share/texlive/texmf-dist/tex/latex/fourier/fourier.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.def)
(/usr/share/texmf/tex/latex/lm/t1lmr.fd))
(/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.def))
(/usr/share/texlive/texmf-dist/tex/latex/fourier/fourier-orns.sty
kpathsea: Running mktextfm FourierOrns
/usr/share/texlive/texmf-dist/web2c/mktexnam: Could not map source
abbreviation F for FourierOrns.
/usr/share/texlive/texmf-dist/web2c/mktexnam: Need to update
/usr/share/texlive/texmf-dist/fonts/map/fontname/special.map?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1;
nonstopmode; input FourierOrns
This is METAFONT, Version 2.7182818 (TeX Live 2019/Debian) (preloaded
base=mf)


kpathsea: Running mktexmf FourierOrns
! I can't find file `FourierOrns'.
<*> ...our; mag:=1; nonstopmode; input FourierOrns

Please type another input file name
! Emergency stop.
<*> ...our; mag:=1; nonstopmode; input FourierOrns

Transcript written on mfput.log.
grep: FourierOrns.log: No such file or directory
mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode;
input FourierOrns' failed to make FourierOrns.tfm.
kpathsea: Appending font creation commands to missfont.log.


! Package fontspec Error: The font "FourierOrns" cannot be found.

For immediate help type H .
 ...

l.11   \newcommand
  *{\TakeFourierOrnament}[1]{{\FourierOrns \char#1}}
?


There is no tfm file for FourierOrns in texlive-fonts-extra. Not sure if
there should be one.

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#943943: getfem++ ftbfs on s390x where it built before

[Graham Inggs]

Control: reopen -1
Control: retitle -1 getfem++ ftbfs on s390x where it built before


getfem++ 5.3+dfsg1-2 still FTFS on at least s390x and ppc64

Bug#947081: fribidi 1.0.8-1 breaks at least libtext-bidi-perl and pyfribidi

[gregor herrmann]

Source: fribidi
Version: 1.0.8-1
Severity: serious
Justification: breaks other software

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As seen on tracker/ci.d.n, fribidi 1.0.8-1 causes autopkgtest
regressions in libtext-bidi-perl and pyfribidi.

For libtext-bidi-perl I also see them at runtime (with the urxvt
plugin):

urxvt: perl hook 0 evaluation error: /usr/lib/x86_64-linux-gnu/urxvt/perl/bidi: 
Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Text/Bidi/private/private.so' for 
module Text::Bidi::private: 
/usr/lib/x86_64-linux-gnu/perl5/5.30/auto/Text/Bidi/private/private.so: 
undefined symbol: fribidi_log2vis_get_embedding_levels at 
/usr/lib/x86_64-linux-gnu/perl/5.30/DynaLoader.pm line 193, <$fh> line 1.

Rebuilding libtext-bidi-perl doesn't change anything.

Regarding fribidi_log2vis_get_embedding_levels, when I look at the
fribidi git repo and the diff between 1.0.7-1.1 and 1.0.8-1 I see:

- --- a/debian/libfribidi0.symbols
+++ b/debian/libfribidi0.symbols
@@ -27,7 +27,7 @@ libfribidi.so.0 libfribidi0 #MINVER#
  fribidi_iso8859_8_to_unicode_c@Base 0.19.2
  fribidi_join_arabic@Base 0.19.2
  fribidi_log2vis@Base 0.19.2
- - fribidi_log2vis_get_embedding_levels@Base 0.19.2
+#MISSING: 1.0.8# fribidi_log2vis_get_embedding_levels@Base 0.19.2
  fribidi_mirroring_status@Base 0.19.2
  fribidi_parse_charset@Base 0.19.2
  fribidi_remove_bidi_marks@Base 0.19.2

and

- --- a/lib/fribidi-deprecated.c
+++ b/lib/fribidi-deprecated.c
@@ -76,19 +76,6 @@ fribidi_reorder_nsm_status (
 


- -FRIBIDI_ENTRY FriBidiLevel
- -fribidi_log2vis_get_embedding_levels (
- -  const FriBidiCharType *bidi_types,   /* input list of bidi types as 
returned by
- -  fribidi_get_bidi_types() */
- -  const FriBidiStrIndex len,   /* input string length of the paragraph */
- -  FriBidiParType *pbase_dir,   /* requested and resolved paragraph
- -* base direction */
- -  FriBidiLevel *embedding_levels   /* output list of embedding levels */
- -)
- -{
- -  return fribidi_get_par_embedding_levels_ex (bidi_types, NULL, len, 
pbase_dir, embedding_levels);
- -}
- -
 FRIBIDI_ENTRY FriBidiCharType
 fribidi_get_type (
   FriBidiChar ch   /* input character */


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl389ddfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgb8eA//bYTqqcpb5QHRBKxaw4nzVjX+6MdzaV5dTQ+H2GGrDRFg/A860AdfP2TX
jSzM5nQeiexb2KIYlzDzfbrV6kZ4MbePGv9G3ZyhRCPX+PZp3YJEIBvXTReP/Ecn
QT9jgCmRu/CQ1NvRxnZnRnHrCqgguqgS7iUKDYT3gYUtlGyoQ+nEVskceGicP/+H
IfY9v3NJq3n4Z03o6YLSdW9nHt0F2JOAECRdiIB5MKVZweY+feUt1zQ86DDn+b0L
9IECMAnHf871p/tvhWek31wtEEgC8QTVsMT/7KWV6ntfuJ8fCMYlOuu5RN9+2kaD
j+mZUymJ3xlgfq0nrqnLRz6lz8Yp6rypskCMknH2C91xxpyyyhX+/37CnMcOxZSd
aNnLcL7VjjWHcziz/z83/mFWZN9t7RwHdRn9aGS498fHeKQApPue4IJaGvdIExKO
C9ocDe5kvV5MuCGL0hMzCXT7NNclfHjFrBSnXoF29t6GtZb3XoxLS6BtgcIImtJg
7TIkS0sVkG6JpS9Ra6unD+ygnKx1Ef4K55FtUJxlUup3kNRemBe1pt0ZoFwR8UBL
/8kZ0ST8FDmTUzmhFY45eQXd/tveYi2Hi4sPFBJwE/gmyxxMfAUF+e9tQuqsfIck
j3OzrSoibdSwVXPRSauRXP03ea1aGH1s7yZXulzTFA8Pv+wA7ok=
=dV2+
-END PGP SIGNATURE-

Bug#947080: [getmail] Crashes when not being able to decode encoding of Cc line

[Charlemagne Lasse]

Package: getmail
Version: 5.13-1
Severity: normal
Tags: buster
X-Debbugs-CC: getm...@lists.pyropus.ca
X-Debbugs-CC: charlesc-getmail-supp...@pyropus.ca

I now have to soothe a lot of angry people because I didn't receive
some important mails from one of my accounts (and thus didn't act
correctly). The problem was that I received a mail with following
(raw) Cc line on the same account:

Cc: =?utf-8?b?UmFmYcWCIE1pxYJl?==?utf-8?b?Y2tp?= 

It seems like python2 can decode this:

>>> email.header.decode_header('=?utf-8?b?UmFmYcWCIE1pxYJl?= =?utf-8?b?Y2tp?=')

but not

>>> email.header.decode_header('=?utf-8?b?UmFmYcWCIE1pxYJl?==?utf-8?b?Y2tp?=')
Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib/python2.7/email/header.py", line 108, in decode_header
   raise HeaderParseError
email.errors.HeaderParseError

getmail just crashed all the time (and systemd restarted it
automatically) but never downloaded any mail for this specific account
again.

getmail[15939]: Traceback (most recent call last):
getmail[15939]:   File "/usr/bin/getmail", line 934, in 
getmail[15939]: main()
getmail[15939]:   File "/usr/bin/getmail", line 898, in main
getmail[15939]: success = go(configs, options.idle)
getmail[15939]:   File "/usr/bin/getmail", line 200, in go
getmail[15939]: msg = retriever.getmsg(msgid)
getmail[15939]:   File
"/usr/lib/python2.7/dist-packages/getmailcore/_retrieverbases.py",
line 1008, in getmsg
getmail[15939]: return self._getmsgbyid(msgid)
getmail[15939]:   File
"/usr/lib/python2.7/dist-packages/getmailcore/_retrieverbases.py",
line 1934, in _getmsgbyid
getmail[15939]: for (val, encoding) in decode_header(encoded_value):
getmail[15939]:   File "/usr/lib/python2.7/email/header.py", line 108,
in decode_header
getmail[15939]: raise HeaderParseError
getmail[15939]: email.errors.HeaderParseError
systemd[261]: getmail.service: Main process exited, code=exited,
status=1/FAILURE
systemd[261]: getmail.service: Failed with result 'exit-code'.

This will no longer affect getmail in Debian sid in the near future
because sid is dropping Python2 (and Python3 doesn't have this
decoding problem).

Bug#909044: quota: still failing inside LXC

[Sergio Cambra]

Package: quota
Version: 4.04-2+deb10u1
Followup-For: Bug #909044

Dear Maintainer,

Also, I have tested with 4.05-1+b1 from testing and it fails with same error, 
inside LXC.

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

Kernel: Linux 5.3.10-1-pve (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages quota depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libcom-err21.44.5-1+deb10u2
ii  libdbus-1-31.12.16-1
ii  libext2fs2 1.44.5-1+deb10u2
ii  libldap-2.4-2  2.4.47+dfsg-3+deb10u1
ii  libnl-3-2003.4.0-1
ii  libnl-genl-3-200   3.4.0-1
ii  libtirpc3  1.1.4-0.4
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400

quota recommends no packages.

Versions of packages quota suggests:
pn  libnet-ldap-perl
ii  postfix [mail-transport-agent]  3.4.7-0+deb10u1
pn  rpcbind 

-- debconf information:
  quota/run_warnquota: false
  quota/signature:
  quota/supportemail:
  quota/charset:
  quota/subject:
  quota/mailfrom:
  quota/group_signature:
  quota/rquota_setquota:
  quota/group_message:
  quota/message:
  quota/supportphone:
  quota/cc:
  quota/cc_before:

Bug#947079: gmailieer: Gmailieer was renamed to Lieer

[David Engel]

Package: gmailieer
Version: 0.10-1
Severity: wishlist

Dear Maintainer,

Gmailieer was renamed to Lieer a while back and new versions are being
published using the new name.  The current version is 1.0.  The new
URL for the project is https://github.com/gauteh/lieer .

David

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/16 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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gmailieer depends on:
ii  python3   3.7.5-1
ii  python3-googleapi 1.7.11-3
ii  python3-notmuch   0.29.3-1
ii  python3-oauth2client  4.1.2-4
ii  python3-tqdm  4.30.0-1

gmailieer recommends no packages.

gmailieer suggests no packages.

Bug#940028: debian-installer multi-console race with preseeding

[Steve McIntyre]

On Fri, Dec 20, 2019 at 03:33:56PM +, Ian Jackson wrote:
>Ian Jackson writes ("debian-installer multi-console race with preseeding"):
>> A workaround is to specify *exactly one* appropriate console=
>> on the kernel command line.  This causes the kernel to report only
>> that console in /proc/consoles and the bug is avoided.
>
>This seems to work only sometimes.  In my experience it worked for an
>arm64 server but not for an x86 PV Xen guest.  There does not appear
>to be another workaround that does not involve modifying the installer
>initramfs.

Hoping to have a fix shortly - hacking on this in the next few days...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

Bug#947074: upstream tarballs for certain components contain unreasonably timestamped files

[Paolo Greppi]

Yes, those files get the timestamp from the upstream tarballs.

To reproduce:

dget 
https://deb.debian.org/debian/pool/main/n/node-yarnpkg/node-yarnpkg_1.21.1-1.dsc
ls -R --full-time node-yarnpkg-1.21.1/ | egrep -v '( 2019-| 2018-| 2017-| 2016)'

It could be fixed by re-uploading the tarballs with fixed timestamps, but I 
prefer to stick with upstream tarballs as-they-are ("source reproducibility").

So I propose to patch it by adding commands in d/rules auch as:

find dnscache/ | xargs touch
find hash-for-dep/ | xargs touch
find normalize-url/ | xargs touch
find npm-logical-tree/ | xargs touch
find query-string/ | xargs touch
find resolve-package-path/ | xargs touch
find string-replace-loader/ | xargs touch
find tar-fs/ | xargs touch
find v8-compile-cache/ | xargs touch

Any comments from the submitter or from the js-team ?

Paolo

Bug#947068: wrong return code

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Fri, 2019-12-20 at 13:20:30 +0100, Thorsten Alteholz wrote:
> Package: dpkg
> Version: 1.17.27

> During installation of a package, that has some problems, the return code of
> dpkg is still 0:
> 
> dpkg -i libgdk-pixbuf2.0-common_2.31.1-2+deb8u8_all.deb 
> libgdk-pixbuf2.0-0_2.31.1-2+deb8u8_amd64.deb
> 
> Selecting previously unselected package libgdk-pixbuf2.0-common.
> (Reading database ... 135769 files and directories currently installed.)
> Preparing to unpack libgdk-pixbuf2.0-common_2.31.1-2+deb8u8_all.deb ...
> Unpacking libgdk-pixbuf2.0-common (2.31.1-2+deb8u8) ...
> Selecting previously unselected package libgdk-pixbuf2.0-0:amd64.
> Preparing to unpack libgdk-pixbuf2.0-0_2.31.1-2+deb8u8_amd64.deb ...
> Unpacking libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u8) ...
> Setting up libgdk-pixbuf2.0-common (2.31.1-2+deb8u8) ...
> Setting up libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u8) ...
> g_module_open() failed for 
> /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so:
>  
> /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so:
> undefined symbol: g_uint_checked_mul
> Processing triggers for libc-bin (2.19-18+deb8u10) ...
> root@test-jessie-amd64-extern:~/gdk-pixbuf/fail# echo $?
> 0

> Is this the intended behaviour?
> 
> I admit that this is a rather old version of dpkg, but I did not find any
> hint in the changelog that something had changed.

I'd assume that's because the postinst does not «set -e» or explicitly
ignores the return code of whatever command is emitting that error.

Thanks,
Guillem

Bug#947043: cyrus-sasl2: CVE-2019-19906: Off by one in _sasl_add_string function

[Roberto C . Sánchez]

On Fri, Dec 20, 2019 at 08:36:00AM +0100, Salvatore Bonaccorso wrote:
> Hi Roberto,
> 
> On Thu, Dec 19, 2019 at 08:06:19PM -0500, Roberto C. Sánchez wrote:
> > On Thu, Dec 19, 2019 at 09:19:19PM +0100, Salvatore Bonaccorso wrote:
> > > 
> > > The following vulnerability was published for cyrus-sasl2.
> > > 
> > > CVE-2019-19906[0]:
> > > Off by one in _sasl_add_string function
> > > 
> > > If you fix the vulnerability please also make sure to include the
> > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > > 
> > Hi Team,
> > 
> > Is anybody already working on this update?  If not, I can start on it
> > possibly tomorrow or perhaps the day after.
> > 
> > Salvatore,
> > 
> > If I (or someone else on the team) prepares the upload, do we go ahead
> > and make the upload then let the security team handle the DSA
> > publication?
> 
> I already started yesterday, and have buster and stretch packages,
> will likely release the DSA later today or tomorrow. So far tested
> just lightly for stretch but will double check explicitly against
> openldap.
> 
Oh!  That's excellent.

> unstable would need an update as well yet.
> 
Of course.

> Can you later import then the changes in the packaging repository in
> the appropriate branches?
> 
I could manage that in the coming days. Unless Ondrej or someone else
gets to it first.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

[Dominique Dumont]

On Thursday, 19 December 2019 10:18:12 CET Dominique Dumont wrote:
> provided
> $YAML::XS::LoadBlessed is set to 0, which is not a problem for cme

Surprise.. 

Thanks to this test [1], it turns out that setting LoadBlessed with 
a local does not work (i.e. "local $YAML::XS::LoadBlessed = 0;").

Only "$YAML::XS::LoadBlessed = 0" without local disables the feature that
loads blessed objects. 

Which means I need to rework Config::Model::Backend::YAML :-/

All the best

[1] 
https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/commit/481b3df20f23d24e8021c4f100d66fe4c52fbabb

Bug#940028: debian-installer multi-console race with preseeding

[Ian Jackson]

Ian Jackson writes ("debian-installer multi-console race with preseeding"):
> A workaround is to specify *exactly one* appropriate console=
> on the kernel command line.  This causes the kernel to report only
> that console in /proc/consoles and the bug is avoided.

This seems to work only sometimes.  In my experience it worked for an
arm64 server but not for an x86 PV Xen guest.  There does not appear
to be another workaround that does not involve modifying the installer
initramfs.

Ian.

Bug#945920: Chromium randomly crashes in the latest version.

[Jaap Joris Vens]

I have attached the output of `chromium --debug` after reading the
instructions in /usr/share/doc/chromium/README.Debian and installing the
chromium-dbgsym package. This always crashes on startup, not randomly, so
I probably did something wrong.

Any help would be appreciated.

Gr,
JJ
# Env:
# LD_LIBRARY_PATH=
#
PATH=/home/jj/.local/bin:/home/jj/.perl5/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/jj/bin
#GTK_PATH=
#  CHROMIUM_FLAGS= --force-device-scale-factor=1 --enable-remote-extensions 
--incognito --show-component-extension-options --ignore-gpu-blacklist 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions 
--load-extension=/usr/share/chromium/extensions/ublock-origin 
--load-extension=/usr/share/chromium/extensions/ublock-origin
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.KO98ty
GNU gdb (Debian 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...
Reading symbols from 
/usr/lib/debug/.build-id/36/17b9a7889a0546c5212bf47726752b2bb4e479.debug...
(gdb) run
Starting program: /usr/lib/chromium/chromium --force-device-scale-factor=1 
--enable-remote-extensions --incognito --show-component-extension-options 
--ignore-gpu-blacklist --enable-gpu-rasterization --no-default-browser-check 
--disable-pings --media-router=0 --enable-remote-extensions 
--load-extension=/usr/share/chromium/extensions/ublock-origin 
--load-extension=/usr/share/chromium/extensions/ublock-origin --single-process 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffed306700 (LWP 208972)]
[Detaching after fork from child process 208973]
[New Thread 0x7fffecb05700 (LWP 208977)]
[New Thread 0x7fffe6f87700 (LWP 208978)]
[New Thread 0x7fffe6786700 (LWP 208979)]
[New Thread 0x7fffe5784700 (LWP 208981)]
[New Thread 0x7fffe5f85700 (LWP 208980)]
[New Thread 0x7fffe4f83700 (LWP 208982)]
[New Thread 0x7fffcbfff700 (LWP 208983)]
[New Thread 0x7fffcb7fe700 (LWP 208984)]
[New Thread 0x7fffcaffd700 (LWP 208985)]
[New Thread 0x7fffe4338700 (LWP 208986)]
[New Thread 0x7fffc9ffb700 (LWP 208988)]
[New Thread 0x7fffca7fc700 (LWP 208987)]
[New Thread 0x7fffc8ff9700 (LWP 208990)]
[New Thread 0x7fffc97fa700 (LWP 208989)]
[New Thread 0x7fffabfff700 (LWP 208991)]
[New Thread 0x7fffab7fe700 (LWP 208992)]
[New Thread 0x7fffaaffd700 (LWP 208993)]
[New Thread 0x7fffaa7fc700 (LWP 208994)]
[New Thread 0x7fffa9ffb700 (LWP 208995)]
[New Thread 0x7fffa97fa700 (LWP 208996)]
[208968:208968:1220/161322.059464:ERROR:system_network_context_manager.cc(726)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x7fffa8ff9700 (LWP 208997)]
[New Thread 0x7fff87fff700 (LWP 208998)]
[208968:208968:1220/161322.112096:ERROR:system_network_context_manager.cc(726)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x7fff86b45700 (LWP 209002)]
[New Thread 0x7fff86344700 (LWP 209003)]
[New Thread 0x7fff85b43700 (LWP 209004)]
[Thread 0x7fff85b43700 (LWP 209004) exited]
[New Thread 0x7fff85342700 (LWP 209005)]
[208968:208968:1220/161322.259970:ERROR:system_network_context_manager.cc(726)] 
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x7fff84b41700 (LWP 209006)]
[New Thread 0x7fff6700 (LWP 209007)]
[New Thread 0x7fff6f7fe700 (LWP 209008)]
[New Thread 0x7fff6effd700 (LWP 209009)]
[New Thread 0x7fff6e7fc700 (LWP 209010)]
[New Thread 0x7fff6dffb700 (LWP 209011)]
[New Thread 0x7fff6d7fa700 (LWP 209012)]
[208968:208968:1220/161322.399477:FATAL:render_process_host_impl.cc(4146)] 
Check failed: render_process_host->InSameStoragePartition( 
BrowserContext::GetStoragePartition(browser_context, site_instance, false )). 

Thread 1 "chromium" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) quit
A debugging session is active.

Inferior 1 [process 208968] will be killed.

Quit anyway? (y or n) y

Bug#944242: Test issues with BioPython 1.75

[Peter Cock]

We (upstream) have just released Biopython 1.76 which thanks to
the Debian team's feedback from 1.75 should be less problematic
on alternative CPUs:

https://www.open-bio.org/2019/12/20/biopython-1-76-released/
https://pypi.python.org/pypi/biopython/1.76

These are the commits which I think you might want to consider
back-porting for the Biopython 1.75 package if there are still
problems with the Debian tests:

https://github.com/biopython/biopython/commit/4045706f7ccb4a55421071fbfa7a9bdc242c4004

https://github.com/biopython/biopython/commit/8ebe305a6bfd8efd7470b8dd2c49d20d046f6196

https://github.com/biopython/biopython/commit/f82deab3f37739ffe1811a96bc30c0d73d1f14b5

Michael Crusoe has assisted in getting ARM64 etc included as part of
our usual TravisCI testing (although they do sometimes timeout), which
hopefully will stop this particular problem reoccurring.

Thank you all,

Peter

Bug#937606: Droping Python2 support for Biopython

[Peter Cock]

We (upstream) have just released Biopython 1.76 which should be
the final release to support Python 2 anyway:

https://www.open-bio.org/2019/12/20/biopython-1-76-released/
https://pypi.python.org/pypi/biopython/1.76

Peter

On Thu, Dec 12, 2019 at 1:02 PM Andreas Tille  wrote:
>
> Control: tags -1 pending
>
> Hi,
>
> I just removed Python2 support for Biopython in Git since I managed to
> port the latest reverse dependencies requiring python-biopython
> yesterday.  I'm hesitating to upload since Michael is discussing test
> suite errors on arm64 with upstream.
>
> I wonder whether we should upload anyway after excluding the test in
> question and file a bug report about this to make sure it will not be
> forgotten.  This bug report could also serve as a sensible place to
> discuss that issue.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>

Bug#947078: git-buildpackage: Need to make gbp clone pseudo protocols confgirable

[Ahmed El-Mahmoudy]

Package: git-buildpackage
Version: 0.9.17
Severity: normal

Dear Maintainer,

I have the following entry in ~/.ssh/config:
Host salsa salsa.debian.org
  User git
  Hostname salsa.debian.org
Host github github.com
  User git
  Hostname github.com

Yet, when running gbp clone salsa:group/project.git, gbp fetches from 
the HTTPS URL of salsa instead of the SSH URL. This happened after gbp 
0.9.17 added salsa to its pseudo protocols. So I had to manually comment 
thkse lines in scripts/clone.py to get the repo checked out from SSH 
URL.
I suggest making those pseudo protcols user configurable somehow.


-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature