Bug#915080: coda: errors in package description of packages coda and python3-coda

[Beatrice Torracca]

Source: coda
Severity: minor

Hi,

in the python3-coda package there is a minor typo in the package
description ("wrappera" instead of "wrappers").

More importantly, the description of the package coda starts with "to
manipulate and analyse Climate model Data. [...]". Either is truncated
or the long description continues from the short description which is, AFAIK,
against the Debian policy for package descriptions.

Thanks,

beatrice

Bug#915079: libasound2: with latest libasound2(1.1.7) no pulse choise in audacity out/in device

[luca]

Package: libasound2
Version: 1.1.7-1+b1
Severity: important

after latest libasound2 and libasound2-plugins update I cannot select
PulseAudio in output/input device and Audacity is not shown in pavucontrol.

https://lists.debian.org/debian-user/2018/11/msg00170.html



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

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

Versions of packages libasound2 depends on:
ii  libasound2-data  1.1.7-1
ii  libc62.28-1

libasound2 recommends no packages.

Versions of packages libasound2 suggests:
ii  libasound2-plugins  1.1.7-3

-- no debconf information

Bug#893134:

[shirish शिरीष]

at bottom :-

On 29/11/2018, Jorge Moraleda  wrote:
> This is still broken in version 11.0.1+13-2
>

AFAIK this is a known bug.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#907429: closed by Patrick Matthäi (Bug#907429: fixed in libphysfs 3.0.1-3)

[Uoti Urpala]

On Thu, 2018-11-29 at 14:57 +, Debian Bug Tracking System wrote:
>* Add upstream patch 02-fsync.

This patch file is completely broken:

> # Upstream patch to fix a performance problem.
> # Closes: #907429
> # URL: https://hg.icculus.org/icculus/physfs/rev/c17f025e7a92
> 
> diff -Naur libphysfs-3.0.1.orig/physfs.c libphysfs-3.0.1/physfs.c
> --- libphysfs-3.0.1.orig/physfs.c   1970-01-01 01:00:00.0
> +0100
> +++ libphysfs-3.0.1/physfs.c2018-11-29 15:05:50.430790919 +0100
> @@ -0,0 +1,44 @@
> +
> +diff -r ece6769c0676 -r c17f025e7a92 src/physfs.c
> +--- a/src/physfs.c Wed Oct 03 22:40:57 2018 -0400
>  b/src/physfs.c Tue Nov 27 23:53:33 2018 -0500
> +@@ -2669,7 +2669,6 @@
> + {

This adds a top-level file physfs.c (instead of modifying src/physfs.c)
which contains the text of what looks like the actual intended patch
for src/physfs.c. Obviously adding this new invalid .c file without any
build system changes is just ignored, and does not have any effect on
the build result.

Bug#914946: linux-config-4.19: Enable CONFIG_EDAC_PND2

[Uwe Kleine-König]

Control: tag 914946 + pending

Hello,

On Thu, Nov 29, 2018 at 12:43:27AM +0100, corubba wrote:
> --- debian/config/kernelarch-x86/config.orig  2018-11-29 00:33:10.918463988 
> +0100
> +++ debian/config/kernelarch-x86/config   2018-11-29 00:33:36.241809179 
> +0100
> @@ -454,6 +454,7 @@
>  CONFIG_EDAC_I5100=m
>  CONFIG_EDAC_I7300=m
>  CONFIG_EDAC_SKX=m
> +CONFIG_EDAC_PND2=m
>  CONFIG_EDAC_AMD8131=m
>  CONFIG_EDAC_AMD8111=m

I wanted to do that and noticed that Romain was quicker than me and
already did[1]. Tagging as pending to not let someone else try to do that
:-)

Best regards
Uwe

[1] https://deb.li/3ufkF

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Bug#915019: Bug #915019 in libreoffice marked as pending

[Rene Engelhard]

Hi,

On Fri, Nov 30, 2018 at 05:27:32AM +0100, Andreas Beckmann wrote:
> On 2018-11-29 22:49, Rene Engelhard wrote:
> > https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/e3b05379e04aa4d3d0756d351463182b5bfa2882
> 
> You want "1:6.2.0~beta1-2~" as the version in the maintscript, to act on
> upgrades from all buggy versions (including the 1:6.2.0~beta1-1+b1 (or
> later) binNMUs), too.

One *can* do that, but experimental is experimental and this is "only" a
transitional package

Regards,

Rene

Bug#914817: [Debian-med-packaging] Bug#914817: camitk: FTBFS on i386

[Emmanuel Promayon]

X-Debbugs-Cc: Gert Wollny 


Thank you Mattia for this report.
I rebuild locally and got the same two tests failing.

After a first investigation, I think Gert is probably right about this 
"-ffloat-store" or at least about floating point precision.

For instance, for test #46, which complains about a difference between expected 
output and actual output:

diff 
.../camitk-build/Testing/Temporary/action-reconstruction-integration-test/output-1.vtk
 ...
/camitk-build/Testing/Temporary/action-reconstruction-integration-test/2018-11-29T16-54-57/output-1.vtk

gives

3626c3626
< 0.804485 -0.417868 -0.422127 0.224294 -0.343943 -0.911809 -0.567178 -0.335857 
-0.752004
---
0.804485 -0.417868 -0.422127 0.224294 -0.343943 -0.911809 -0.567178 -0.335857 -0.752003 

3632c3632
< -0.346881 0 -0.937909 -0.150485 -0.0767808 -0.985626 -0.458605 -0.843355 
-0.280059
---
-0.346881 0 -0.937909 -0.150485 -0.0767809 -0.985626 -0.458605 -0.843355 -0.280059 

3635c3635
< 0.13497 -0.236088 -0.962313 -0.487965 -0.150704 -0.859755 -0.484595 -0.281462 
-0.828219
---
0.13497 -0.236088 -0.962313 -0.487964 -0.150704 -0.859755 -0.484595 -0.281462 -0.828219 


Note the floating point precision difference.

In both cases the vtk class that is used is the marching cube reconstruction 
algorithm.

May be the "-ffloat-store" cxx flag is not added in VTK (or more specically is 
just erased somewhere just for the marching cube reconstruction algorithm, as other 
filters seem to not have this problem?

I will check a little bit further to see if the problem is in camitk or vtk7

Best regards,
Emmanuel



On 27/11/2018 17:48, Mattia Rizzolo wrote:

Source: camitk
Version: 4.1.2-1
Severity: serious
X-Debbugs-Cc: Gert Wollny 

Hi,

so camitk FTBFS on i386; I don't know why it sometimes suceeds on the
buildds, but for example on the r-b infra it always failed recently.

In particular, it fails two tests:

47: Test command: /usr/bin/cmake "-DCAMITK_TEST_COMMAND=/build/camitk-4.1.2/camitk-build/bin/camitk-actionstatemachine" 
"-DCAMITK_TEST_COMMAND_ARG=-f /build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/asm-input.scxml -o 
/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test -a" 
"-DCAMITK_TEST_EXPECTED_FILES=output-1.vtk" 
"-DCAMITK_TEST_OUTPUT_DIR=/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test" 
"-DCAMITK_TEST_NAME=action-reconstruction-integration-test" "-P" 
"/build/camitk-4.1.2/sdk/cmake/modules/macros/camitk/test/CamiTKTestActionStateMachine.cmake"
47: Test timeout computed to be: 1800
47: QStandardPaths: XDG_RUNTIME_DIR points to non-existing path 
'/run/user/1000', please create it with 0700 permissions.
47: [FAIL]
47: CMake Error at 
/build/camitk-4.1.2/sdk/cmake/modules/macros/camitk/test/CamiTKTestActionStateMachine.cmake:115
 (message):
47:   action-reconstruction-integration-test: (one or more) output file do(es)
47:   not match the corresponding expected file.
47:
47:   Action state machine regression test called with:
47:
47:- CAMITK_TEST_NAME=action-reconstruction-integration-test
47:- 
CAMITK_TEST_COMMAND=/build/camitk-4.1.2/camitk-build/bin/camitk-actionstatemachine
47:- CAMITK_TEST_COMMAND_ARG=-f 
/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/asm-input.scxml
 -o 
/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test
 -a
47:- CAMITK_TEST_EXPECTED_FILES=output-1.vtk
47:- 
CAMITK_TEST_OUTPUT_DIR=/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test
47:
47:   =
47:
47:   Comparing
47:   
/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/2018-11-27T16-12-36/output-1.vtk
47:   with
47:   
/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/output-1.vtk
47:
47:
47:   Output:
47:
47:
47:
47:   Result:
47:
47:   action-reconstruction-integration-test: comparing output-1.vtk failed:
47:
47:   Output file
47:   
/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/output-1.vtk
47:   is not the same as
47:   
/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/2018-11-27T16-12-36/output-1.vtk
47:
47:
47:
47:
47:
47:
  47/550 Test  #47: action-reconstruction-integration-test 
..***Failed3.00 sec


and similarly for test 341.


I've tried the proposed change by Gert, i.e. passing -ffloat-store, but
it didn't help.


___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


--
Emmanuel Promayon
Professeur Univ. Grenoble Alpes / Polytech Grenoble
Laboratoire TIMC-IMAG / équipe GMCAO
Responsable du département Technologies de 

Bug#882754: Debian mirror mirror.unesp.br: ftpsync version

[Peter Palfrader]

ping

It seems your mirror is not using ftpsync, at least it does not have a
proper tracefile.

Using a modern ftpsync ensures updates are done in the correct order
apt clients don't get confused.   In particular, it processes
translations, contents, and more files that have been added to the
archive in recent years in the correct stage.  It also should produce
trace files that contain more information that is useful for us and helps
downstream mirrors sync better.

  http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz

On Sun, 26 Nov 2017, Bastian Blank wrote:

> Package: mirrors
> User: mirr...@packages.debian.org
> Usertags: mirror-problem may-auto-close
> Control: submitter -1 mirr...@debian.org
> 
> Hi
> 
> You receive this mail because you are listed as contact for:
>   mirror.unesp.br
> 
> Please update your ftpsync version.  Running a current ftpsync version 
> makes sure the update is done in a way apt does not blow up.  Also it
> allows us to monitor the status of the mirror in more detail.  You can
> find the current ftpsync at:
>   http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz
> 
> Regards,
> Bastian
> 
> -- 
> Prepare for tomorrow -- get ready.
>   -- Edith Keeler, "The City On the Edge of Forever",
>  stardate unknown
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#915078: scikit-learn: build must not try to write outside build directory

[Stuart Prescott]

Source: scikit-learn
Version: 0.20.1+dfsg-1
Severity: important

Dear Maintainer,

Debian Policy (states|will state) that the build must not attempt to write
outside the build directory and that, in particular, the build should not
attempt to write into HOME. See #845715 for more details and the exact
wording that will appear in the next upload of Policy.

The build for scikit-learn attempts to write to HOME on numerous occasions.
If it can't do so, it is non-fatal; hence, fixing this bug is as simple as
ensuring within debian/rules that HOME is set to something that does not
exist. The Debian buildds already exports HOME in this way; the package
should also ensure that it doesn't scribble in HOME when being locally
compiled.

Example:

WARNING: 
/build/scikit-learn-S9l0Nb/scikit-learn-0.20.1+dfsg/examples/preprocessing/plot_all_scaling.py
 failed to execute correctly: Traceback (most recent call last):
  File 
"/build/scikit-learn-S9l0Nb/scikit-learn-0.20.1+dfsg/examples/preprocessing/plot_all_scaling.py",
 line 71, in 
dataset = fetch_california_housing()
  File 
"/build/scikit-learn-S9l0Nb/scikit-learn-0.20.1+dfsg/.pybuild/cpython3_3.7/build/sklearn/datasets/california_housing.py",
 line 104, in fetch_california_housing
data_home = get_data_home(data_home=data_home)
  File 
"/build/scikit-learn-S9l0Nb/scikit-learn-0.20.1+dfsg/.pybuild/cpython3_3.7/build/sklearn/datasets/base.py",
 line 56, in get_data_home
makedirs(data_home)
  File "/usr/lib/python3.7/os.py", line 211, in makedirs
makedirs(head, exist_ok=exist_ok)
  File "/usr/lib/python3.7/os.py", line 221, in makedirs
mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/home/stuart'

(The HOME environment setting has leaked into this chroot while I was
debugging the build but /home/stuart doesn't actually exist inside the
chroot, hence the very visible error; however, it should not even be trying
to write to HOME.)

regards
Stuart

Bug#915077: debian.heanet.ie: out of date

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem

ping.

On Tue, 27 Nov 2018, Peter Palfrader wrote:

> Hi!
> 
> It seems http://debian.heanet.ie/debian/
> is out of date, not having finished a mirror run in several days.
> https://mirror-master.debian.org/status/mirror-info/debian.heanet.ie.html
> 
> It seems there's the Archive-Update-in-Progress-debian.heanet.ie
> lockfile which points to pid 43398 still running?
> 
> Please investigate.
> 
> Cheers,
> -- 
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
> 

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#915076: plasma-discover: Segfaults when using menus while upgrading

[Petter Reinholdtsen]

Package: plasma-discover
Version: 5.8.5-3
Severity: important

Application: plasma-discover (5.8.5)

Qt Version: 5.7.1
Frameworks Version: 5.28.0
Operating System: Linux 4.9.0-8-amd64 x86_64
Distribution: DebianEdu/Skolelinux

-- Information about the crash:

I started an update, then moved around in the menus looking at packages,
and finally clicked on the menu to have a look at the upgrade, when the
program crashed.

I got the KDE bug reporter, tried to report the bug, only to discover
that it seem to be already reported to KDE with three duplicates, all
closed.  Unfortunately I did not write down the bug reports and have
been unable to find them on https://bugs.kde.org/ >.

Just wanted to make sure the Debian maitainers are aware of the crash
problem in case you want to fix it in stable.

On the positive side, the package upgrade seem to be complete despite
the crash (or perhaps wrapping up the upgrade caused the crash? :-).

-- Backtrace:
Application: Discover (plasma-discover), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7feb855470c0 (LWP 14511))]

Thread 9 (Thread 0x7feb57fff700 (LWP 14529)):
#0  0x7feb90dd26ed in read () at ../sysdeps/unix/syscall-template.S:84
#1  0x7feb8c622d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7feb8c5de4be in g_main_context_check () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7feb8c5de994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7feb8c5deb0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7feb919ef06b in QEventDispatcherGlib::processEvents 
(this=0x7feb4c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#6  0x7feb919989ca in QEventLoop::exec (this=this@entry=0x7feb57ffed00, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#7  0x7feb917c60f3 in QThread::exec (this=) at 
thread/qthread.cpp:507
#8  0x7feb917cada8 in QThreadPrivate::start (arg=0x55865ba47e90) at 
thread/qthread_unix.cpp:368
#9  0x7feb8e713494 in start_thread (arg=0x7feb57fff700) at 
pthread_create.c:333
#10 0x7feb90ddfacf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 8 (Thread 0x7feb5e676700 (LWP 14519)):
#0  0x7feb90dd667d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7feb8c5de9f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7feb8c5ded82 in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7feb64932656 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x7feb8c6063d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7feb8e713494 in start_thread (arg=0x7feb5e676700) at 
pthread_create.c:333
#6  0x7feb90ddfacf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 7 (Thread 0x7feb5ee77700 (LWP 14518)):
#0  0x7feb90dd667d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7feb8c5de9f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7feb8c5deb0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7feb8c5deb51 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7feb8c6063d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7feb8e713494 in start_thread (arg=0x7feb5ee77700) at 
pthread_create.c:333
#6  0x7feb90ddfacf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 6 (Thread 0x7feb7114d700 (LWP 14516)):
#0  0x7feb8c5de3e0 in g_main_context_check () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x7feb8c5de994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7feb8c5deb0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7feb919ef06b in QEventDispatcherGlib::processEvents 
(this=0x7feb68c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#4  0x7feb919989ca in QEventLoop::exec (this=this@entry=0x7feb7114cd00, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#5  0x7feb917c60f3 in QThread::exec (this=) at 
thread/qthread.cpp:507
#6  0x7feb917cada8 in QThreadPrivate::start (arg=0x7feb68003650) at 
thread/qthread_unix.cpp:368
#7  0x7feb8e713494 in start_thread (arg=0x7feb7114d700) at 
pthread_create.c:333
#8  0x7feb90ddfacf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 5 (Thread 0x7feb7194e700 (LWP 14515)):
#0  0x7feb90dd26ed in read () at ../sysdeps/unix/syscall-template.S:84
#1  0x7feb8c622d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7feb8c5de4be in g_main_context_check () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7feb8c5de994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7feb8c5deb0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7feb919ef06b in QEventDispatcherGlib::processEvents 
(this=0x7feb680008c0, flags=...) at 

Bug#915075: Add every nth week example

[積丹尼 Dan Jacobson]

Package: cron
Version: 3.0pl1-130
Severity: wishlist
File: /usr/share/man/man5/crontab.5.gz

Please Add example:
# Remind every 10th Sunday at 4:44 a.m. Immune from irregularities across the 
new year.
44 4 * * sun test $(expr `date +%s` / 60 / 60 / 24 / 7 % 10) -eq 0 && echo Wash 
the car today.

(Hope I got it right.)

Bug#915053: gitlab: Err 500 when go to the project page(any project)

[Dragos Jarca]

Yes, I restarted services; restarted the system to for other resons. The 
same error.


On 30.11.2018 07:12, Pirate Praveen wrote:
On Thu, 29 Nov 2018 22:19:14 +0200 Dragos Jarca 
 wrote:

> Dear Maintainer,
>
> When go to any project receive Err 500:

Did you try restarting gitlab and gitaly services?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Bug#915074: RFS: pk2/1.2.1-1 [ITP] -- 2D Oldschool platform game where you control a rooster

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: pk2
   Version : 1.2.1-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://gitlab.com/coringao/pk2
 * License : BSD-2-Clause
   Section : games

  It builds those binary packages:

  pk2 - 2D Oldschool platform game where you control a rooster
  pk2-data - 2D Oldschool platform game where you control a rooster (data file

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/p/pk2/pk2_1.2.1-1.dsc

  More information about PK2 (Pekka Kana 2) can be obtained from 
https://pistegamez.net/game_pk2.html.

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#913645: Oldstable also affected

[Carsten Schoenert]

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1505038

Hello Bastian,

Am 20.11.18 um 17:44 schrieb Bastian Neuburger:
> Hi,
> 
>> I have however not yet tested what happens if you start thunderbird 
>> aftter the upgrade and close it right away (i.e. not trying to sign 
>> anything but also not entering the master password). I will try to test 
>> this later but now I need a working mail client.
>>
> 
> I also tested this variant now:
> 
> 1. Have berkeley DB based profile that works fine with thunderbird 52 in 
> Jessie
> 2. Upgrade thunderbird
> 3. Start thunderbird
> 4. Close it without doing anything (I am not prompted for the master 
> password)
> 5. Start thunderbird again
> 
> Expected results:
> Either key3.db is still there or I am getting prompted for a master 
> password during step 4.
> 
> Actual results:
> Everything under "Your certificates" and "People" in the Certificate 
> Manager gone, all saved passwords gone.
> 
> So the problem we encountered did not only wipe private keys, but also 
> certificates of other people I already corresponded with AND stored 
> passwords.
> 
> How should reporting with upstream be handled? Should I take care of it 
> myself or would you like to forward it?

I haven't forwarded that all into a new upstream bug report, but I was
able to talk about that issue with upstream.
Initially upstream (in that case the NSS/Firefox team) has decided about
6 years ago to stop using the old database option [1] and use the newer
NSS implementations for storing stuff within a database.

Your are not the only person who is experience such problems. There is
the report 1505038 [2] which is from a user with the same problems. The
issue has some workaround mentioned in comment #25 which should be
"solve" your current problem, could you please test this suggestion?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=783994
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1505038

-- 
Regards
Carsten Schoenert

Bug#914989: Adjust found versions

[Pirate Praveen]

On Thu, 29 Nov 2018 18:08:13 +0100 Dominik George  
wrote:
> Hi,
> 
> >> It is not a regression in unstable, so it need not block the testing
> >migration.
> 
> ...but it needs get gitlab autoremoved from testing if not fixed :).

Yes, we need to find the root cause or reduce severity if there is an easy work 
around like restarting the service.

> >I was not able to reproduce it when downgrading to ruby-grape 1.0.3
> >manually.
> 
> This is correct. I hope you don't expect users to dig a package out of 
> snapshots.debian.org. The issue is with the ruby-grape version currently in 
> testing.

Well, this is for confirming the bug. If it was expecting an exact version, any 
version change will trigger the bug.

> After downgrading to 1.0.3 restart works. It does not do so with 1.1.0.

I will try to update to 1.1.0 and confirm soon.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#915053: gitlab: Err 500 when go to the project page(any project)

[Pirate Praveen]

Control: severity -1 important

On Thu, 29 Nov 2018 22:19:14 +0200 Dragos Jarca  
wrote:
> Package: gitlab
> Version: 11.3.10+dfsg-2
> Severity: grave
> Justification: renders package unusable

I have seen such transient failures go away after a restart of gitlab and 
gitaly services. So downgrading severity as work around exist, but change it 
back if the error persists after a restart of services.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#915053: gitlab: Err 500 when go to the project page(any project)

[Pirate Praveen]

On Thu, 29 Nov 2018 22:19:14 +0200 Dragos Jarca  
wrote:
> Dear Maintainer,
> 
> When go to any project receive Err 500:

Did you try restarting gitlab and gitaly services?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#903375: preliminary building package

[Jeffrey Cliff]

http://qhtn4w2q36dojls2.onion/node-path-parse contains a building
preliminary package directory.
hope that helps
Jeff Cliff

Bug#913548: spamassassin: running /etc/cron.daily/spamassassin gives: Unescaped left brace in regex is deprecated here

[Brian May]

Elimar Riesebieter  writes:

> Here we go:
>
> root@toy>pts/4 /etc/spamassassin/sa-update-hooks.d # ./amavisd-new 
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
> 5.32), passed through in regex; marked by <-- HERE in m/ ( { <-- HERE } (?: / 
> \* )? | \* ) / at (eval 109) line 830.
> root@toy>pts/4 /etc/spamassassin/sa-update-hooks.d # 
>
> Get the same result as user amavis

Ok, thanks. Unfortunately I just cannot
reproduce this error:

(buster-amd64-default)root@silverfish:/etc/spamassassin/sa-update-hooks.d# 
./amavisd-new 
(buster-amd64-default)root@silverfish:/etc/spamassassin/sa-update-hooks.d# 

(similar results on a sid chroot)

Is it possible this is a problem with your config files or something?

Also line 830 of /usr/sbin/amavisd-new appears to be a comment. Wish the
error included the filename so I can be sure I was looking at the right
file...
-- 
Brian May 

Bug#907629: [Pkg-rust-maintainers] Bug#907629: librsvg: Embedded code copies: assorted Rust libraries

[Ximin Luo]

Ximin Luo:
> Simon McVittie:
>> [..]
>>
>> librsvg runs `cargo build` during its own build: running `make` compiles
>> C code, then calls `cargo build` to compile Rust code that depends on the
>> C, then compiles some more C code that depends on the Rust. I don't think
>> we can avoid that.
>>
>> It might be possible to patch Makefile.am to use dh_auto_build or
>> dh_auto_install instead of `cargo build`, but that's "inside out" compared
>> with a normal Debian package build, so I'd be far from confident about
>> making that change myself.
>>
> [..]

The latest version of the cargo Debian package has a wrapper script that should 
make this a bit easier. The cargo build itself now uses this wrapper script, 
see here for an example: 
https://salsa.debian.org/rust-team/cargo/blob/debian/sid/debian/rules

For librsvg, it should be sufficient to add a build-depends on python3:native, 
and add something like this to your d/rules:

PATH := /usr/share/cargo/bin:$(PATH)
export PATH

override_dh_auto_configure:
cargo prepare-debian $(CURDIR)/vendor

Later, when this bug is fixed and you stop depending on vendored libraries, the 
configure override can be changed to:

override_dh_auto_configure:
cargo prepare-debian /usr/share/cargo/registry

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#915072: keysafe: build-depends on many no longer available libghc-*-dev versions

[Andreas Beckmann]

Source: keysafe
Version: 0.20170811-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

The following packages have unmet dependencies:
 builddeps:keysafe : Depends: libghc-argon2-dev (< 1.3) but 1.3.0.1-4+b1 is to 
be installed
 Depends: libghc-aeson-dev (< 1.2) but 1.3.1.1-3 is to be 
installed
 Depends: libghc-async-dev (< 2.2) but 2.2.1-2+b1 is to be 
installed
 Depends: libghc-exceptions-dev (< 0.9) but 0.10.0-2+b1 is 
to be installed
 Depends: libghc-optparse-applicative-dev (< 0.14) but 
0.14.2.0-2+b1 is to be installed
 Depends: libghc-raaz-dev (>= 0.1.1) but it is not going to 
be installed
 Depends: libghc-raaz-dev (< 0.1.1+~) but it is not going 
to be installed
 Depends: libghc-secret-sharing-dev (>= 1.0) but it is not 
going to be installed
 Depends: libghc-secret-sharing-dev (< 1.1) but it is not 
going to be installed
 Depends: libghc-servant-dev (< 0.12) but 0.14.1-2 is to be 
installed
 Depends: libghc-servant-client-dev (< 0.12) but 0.14-3 is 
to be installed
 Depends: libghc-servant-server-dev (< 0.12) but 0.14.1-2 
is to be installed
 Depends: libghc-unix-compat-dev (< 0.5) but 0.5.1-1+b1 is 
to be installed


Andreas

Bug#915071: ITP: node-memory-streams -- light-weight implementation of the Stream.Readable and Stream.Writable

[Nicolas Mora]

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

* Package name: node-memory-streams
  Version : 0.1.3
  Upstream Author : Paul Jackson (http://jaaco.uk/)
* URL : https://github.com/paulja/memory-streams-js
* License : Expat
  Programming Lang: JavaScript
  Description : light-weight implementation of the Stream.Readable
and Stream.Writable

 Memory Streams JS is a light-weight implementation of the
Stream.Readable and
 Stream.Writable abstract classes from node.js. You can use the classes
 provided to store the result of reading and writing streams in memory. This
 can be useful when you need pipe your test output for later inspection
or to
 stream files from the web into memory without have to use temporary
files on
 disk.
 .
 Forked from https://github.com/paulja/memory-streams-js to be modified
so that
  .end() calls emit a finish event.
 .
 Node.js is an event-based server-side JavaScript engine.

This package is required for node-istanbuljs

Bug#915070: wodim ignores -dummy

[Md Ayquassar]

Package: wodim
Version: 9:1.1.11-3+b2
Severity: critical

Starting with a blank 4.7 Gb DVD-R in the optical drive "HL-DT-ST DVD+-RW 
GS30N",
my_file.iso containing a freshly downloaded copy of Windows 10 (US English, 
x64),
and issuing
$ sudo wodim -v driver=mmc_cd_dvd dev=/dev/sg1 -dummy -dao speed=1 fs=100m
driveropts=noburnfree -data my_file.iso

twice, I discovered that the first dry run succeeded, but the second did not.
Upon ejecting the disc, I saw a differently colored ring on the disc. So, wodim
didn't turn off the laser completely and thus made the disc unusable.

So, we can no more test wodim's features without destroying discs. In practical
terms, this makes wodim a harmful program. I suggest removing it from Debian
completely.

Bug#915069: libphp-predis: Useless in Debian, superseded by php-nrk-predis

[David Prévot]

Package: libphp-predis
Version: 0.8.3-1
Severity: serious

libphp-predis was packaged a few years ago, and is not used by any
Debian anymore. The php-nrk-predis is a more recent version of the same
package, so there is a priori little point to ship libphp-predis in a
stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David

Bug#915068: php-nrk-predis: Please, upgrade to latest version

[David Prévot]

Package: php-nrk-predis
Version: 1.0.0-1
Severity: wishlist

Dear Maintainer,

Version 1.1.1 was released over two years ago, and version >= 1.1 will
be needed to run the testsuite of recent Symfony.

I intend to continue the maintainance of this package under the Debian
PHP PEAR Maintainers umbrella unless someone disagrees.

Regards

David

Bug#898202: Current state

[Scott Hardin]

I have not yet. Is there a spot where Debian folks usually throw up 
their code or should I just put it up on GitHub somewhere?


Scott

On 11/20/2018 4:02 AM, kaliko wrote:

Hi Scott

On Mon, 19 Nov 2018 Scott Hardin  wrote:

I'm still working on this. Sorry for lack of updates! I'm a bit busy at
work this week, but I would love to show what I've got so far this
weekend if you have any advice to offer.

Have you published you work somewhere?

I believe this package should be maintained in "Debian Multimedia Team".

Cheers
k

Bug#915020: munin-plugins-java: copyright file missing after upgrade (policy 12.5)

[Lars Kruse]

Control: tags -1 +pending

Hello Andreas,

thank you for your report.

I prepared a fix for the issue.

@Holger: please take a look at the commit (6d4791c9) in my repository on salsa
[1] and merge it, if it looks good for you.


Cheers,
Lars


[1] g...@salsa.debian.org:sumpfralle-guest/munin.git

Bug#599665: python-twisted-core: Please change recommends to suggests

[John Scott]

Source: twisted
Followup-For: Bug #599665

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is a general problem with the source package. python3-twisted still
tries to pull in non-existant python3-pam instead of python3-pampy, and
regardless of the need for the recommendation not being able to install
a recommended package caught me by surprise.

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEAXEkn09uX7g8Tv8W3qerYfa4vJcFAlwAlOgACgkQ3qerYfa4
vJcPjAf+KwUqcfpR+P+btopffK7SdY1gD2+M+L2g/XO4IbEx17xEAf85n8hVRl0N
+UirtHX/AGZWlr+F2HiDhbu+VtJTVU2ztZobhtyjfOCH+pF0jyaRhpQfBYCtwNq6
r9uiI8dQ2vfMFNYrBIoQaIyjk6/NIzfkQlKprOkrYBvjXsvR1hJZQMn0ju9YeKAO
8pK8uG3Prl+VSZKHUdYopaXHr9/hFgx08LJLTPhk7e/wkO0h9NVec3efXvzy8Wyz
ezMCzp3PS8WbuuYNAz2/g4nGTxxH3zmoxaULlhzCGzk2x0hvAlNJ+xTnwxsZQAGA
Du7uUkOUXnkCGRNfus9NGiC/473h6Q==
=iZ6f
-END PGP SIGNATURE-

Bug#915067: RFP: node-gulp-debug -- Debug Vinyl file streams to see what files are run through your Gulp pipeline

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-gulp-debug
  Version : 4.0.0
  Upstream Author : Sindre Sorhus
* URL : https://notabug.org/makenotabuggreatagain/gulp-debug/
* License : MIT
  Programming Lang: javascript
  Description : Debug Vinyl file streams to see what files are run through 
your Gulp pipeline

Debug Vinyl file streams to see what files are run through your Gulp pipeline

Dependency of node-semantic-ui ( #915062 ).

Bug#915066: RM: gnucash [armel mips] -- ROM, RoQA; FTBFS, old binaries depend on webkitgtk

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: gnuc...@packages.debian.org, bi...@debian.org
Affects: src:gnucash
Control: block 893863 by -1

Please remove the gnucash binaries from armel and mips.

gnucash doesn't build on armel because it uses guile-2.2 which doesn't
build on armel currently.

It doesn't build on mips and there isn't really anyone that cares
enough about it there to justify holding the package back from
everyone else.

gnucash has no reverse dependencies in Debian.

These old gnucash binaries are blocking the removal of the old webkitgtk.

References

- https://bugs.debian.org/914674 gnucash bug suggesting arch removal
with maintainer's approval
- https://bugs.debian.org/910059 gnucash RFH bug
- https://bugs.debian.org/883778 the guile armel bug

Thanks,
Jeremy Bicha

Bug#914541: [libpam-modules-bin] unix_chkpwd should be SUID instead of SGID, otherwise kscreen_locker does not work

[hg42]

As a workaround, I created a file /etc/apt/apt.conf.d/99hg-fix-unix_chkpwd

# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914541
DPkg::Post-Invoke { "/usr/bin/stat -c '%n %a %U %G' /sbin/unix\_chkpwd ; chmod 
4755 /sbin/unix\_chkpwd ; /usr/bin/stat -c '%n %a %U %G' /sbin/unix\_chkpwd"; };


which ensures the necessary permissions after each update

Bug#909865: double rounding x87 FPU

[Mathieu Malaterre]

Control: tags -1 patch

Usual stuff on x86 (again). Could someone with better automake
expertise confirm the patch is not too silly. Technically we only need
to apply this on x86 arch (linux-x86, hurd-x86, maybe kFreeBSD?).
Maybe I should be using IlmImfTest_CFLAGS but I did not check to much.



% cat debian/patches/bug909865.patch
--- openexr-2.2.1.orig/IlmImfTest/Makefile.am
+++ openexr-2.2.1/IlmImfTest/Makefile.am
@@ -54,6 +54,8 @@ IlmImfTest_SOURCES = main.cpp tmpDir.h t

 AM_CPPFLAGS = -DILM_IMF_TEST_IMAGEDIR=\"$(srcdir)/\"

+AM_CPPFLAGS += -ffloat-store
+
 if BUILD_IMFHUGETEST
 IlmImfTest_SOURCES += testDeepScanLineHuge.cpp testDeepScanLineHuge.h
 AM_CPPFLAGS += -DENABLE_IMFHUGETEST

Bug#915061: gap: improved watchfile [patch]

[Mattia Rizzolo]

On Fri, Nov 30, 2018 at 12:20:28AM +0100, Bill Allombert wrote:
> Hello Mattia, the actual Debian tarball is generated by
> debian/tarball, so if debian/watch mangles the version 
> then debian/tarball must be changed not to do it.

oh, sorry.  I clearly didn't look around the package.  However I believe
you wouldn't need to modify anything in that file even after my proposed
change.  However looking at that file I couldn't help but think that
what you do that is nowadays suggested to do though a Files-Excluded
field in d/copyright following copyright-format 1.0 (something that gap
is not using, and could potentially be quite a big task to adopt, even
if I recommend it).

What my changes do is only to mangle the internal view that uscan uses
to compare against the version used upstream, i.e. even after that
change it would still download a file named e.g. 1.10.0.

> It seems to me there might be some benefit to your change that you are
> not communicating.

I was only thinking of that because I noticed the message "A new
upstream version is available" on the tracker, that I believe is always
present with the watchfile as it is now, even when the software is fully
up to date.  Whereas I think that with my changes uscan would finally be
able to properly compare the debian version against upstream and such
you wouldn't needlessly have such message (same for the DDPO, of
course).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#915065: starjava-vo: Unused dependency on libaxis-java

[Emmanuel Bourg]

Source: starjava-vo
Severity: normal

Dear Maintainer,

starjava-vo has a dependency on libaxis-java but it actually builds fine
without it. It uses a SOAP client from starjava-registry [1] that used to
be based on Axis but no longer use it as highlighted by this comment in
the SoapClient class:

 /**
  * Lightweight, freestanding SOAP client which can make simple requests
  * and allows the responses to be processed as a SAX stream.
  * Logging of sent and received XML can optionally be performed by
  * using the {@link #setEchoStream} method.
  * Probably, there is much of SOAP that this doesn't implement, but
  * it works well enough to write a registry client on top of it.
  *
  * Why write yet another SOAP client?  Last time I tried to get Axis
  * to do this (stream processing of the response) it took me several
  * days of misery, and still didn't work.  The actual job I need to
  * do here is quite straightforward, so it's not difficult to write it
  * from scratch.
  *
  * @author   Mark Taylor
  * @since9 Dec 2009
  */

Since we plan to request the removal of libaxis-java due to compatibility
issues with Java 11 (#911187), could you please remove the libaxis-java
dependency from starjava-vo?

Thank you,

Emmanuel Bourg

[1] 
https://salsa.debian.org/debian-astro-team/starjava-registry/blob/master/src/main/uk/ac/starlink/registry/SoapClient.java

Bug#907840: emacs-goodies-el: where are projects.el and ff-paths.el maintained?

[Nicholas D Steeves]

Hi David,

Just following up on this bug as requested on IRC, as a weekend
reminder, the gist being "OK, hearing now comment, I guess we'll
proceed with removal".

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#914939: Tested other kernels

[Jakub Filo]

This bug seems related to 
https://bugs.freedesktop.org/show_bug.cgi?id=107573#c12 Kernel series 4.18 is 
affected by this bug. The bug is fixed in kernel series 4.19 (tested 
4.19.5-1~exp1 from experimental) 4.9.110-3 (stretch) is the last stretch kernel 
not affected. 4.9.130-2 (current stretch) is affected. 4.9.135-1 
(stretch-proposed) is affected. 

Bug#915064: geany: syntax highlighting broken for Perl here-documents with ~ modifier

[Celejar]

Package: geany
Version: 1.33-1
Severity: normal

Dear Maintainer,

Syntax highlighting is broken for Perl here-documents with ~ modifier.
The parser apparently doesn't understand that the whitespace-prefixed delimiter
ends the quoted text, and continues to highlight the following text as
quoted.

For example, with the attached file, Geany continues to highlight the
keywords 'my', 'print', and 'exit', as well as the closing brace, in green,
as quoted text, despite the fact that the Perl interpreter correctly
interprets and runs the code.

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

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

Versions of packages geany depends on:
ii  geany-common 1.33-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-8
ii  libcairo-gobject21.16.0-1
ii  libcairo21.16.0-1
ii  libfribidi0  1.0.5-3
ii  libgcc1  1:8.2.0-10
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.1-2
ii  libpango-1.0-0   1.42.4-4
ii  libpangocairo-1.0-0  1.42.4-4
ii  libstdc++6   8.2.0-10

geany recommends no packages.

Versions of packages geany suggests:
pn  doc-base  
ii  libvte9   1:0.28.2-5+b3

-- no debconf information
#!/usr/bin/perl -w

{
print <<~EOF;
some text
EOF
}
my $foo = "Done\n";
print $foo;
exit;

Bug#914674: gnucash not building on armel anymore because of guile-2.2

[Dmitry Smirnov]

On Thursday, 29 November 2018 8:50:58 PM AEDT Jeremy Bicha wrote:
> Hi again! gnucash is now the final blocker for removing the old
> webkitgtk from Debian Unstable. Therefore, I plan to file a removal
> bug for gnucash [armel mips] unless Dmitry wants to file the bug
> instead. Those removals  will allow gnucash to migrate to Testing
> which is a nice benefit for everyone.

Apologies for delay, Jeremy. It would be helpful if you could file that  
removal bug on my behalf. If you are busy then I'll see if I can do that some 
time before the end of this week...

Thanks.

-- 
All the best,
 Dmitry Smirnov.

---

You have to start with the truth. The truth is the only way that we can
get anywhere. Because any decision-making that is based upon lies or
ignorance can't lead to a good conclusion.
-- Julian Assange, 2010


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

Bug#914954: Fails to upgrade from 3.4.0 to 3.4.1: ERROR:root:After system restart, the values must be saved into db. Please, execute tuptime with a privileged user.

[Axel Beckert]

Hi Ricardo,

Ricardo Fraile wrote:
> I tested an upgrade from 3.4.0 to 3.4.1 on a fresh install of Sid
> and it doesn't report any issue.

JFTR: uptimed is also installed. Not sure if that makes a difference
as tuptime seems to be able to import uptimed's database.

> What is the output of "ls -al /var/lib/tuptime"?

total 12
drwxr-xr-x   2 root root 4096 Sep 25 02:00 .
drwxr-xr-x 113 root root 4096 Nov 22 00:48 ..
-rw-r--r--   1 root root 2048 Sep 25 02:00 tuptime.db

> Did you reboot the computer between the 3.4.0 installation and the
> upgrade?

Yes. tuptime 3.4.0 was uploaded to unstable on 2018-09-23 and I last
rebooted on 2018-09-30.

# zfgrep tuptime /var/log/dpkg.log.2.gz 
2018-09-25 02:01:37 upgrade tuptime:amd64 3.3.3 3.4.0
2018-09-25 02:01:37 status half-configured tuptime:amd64 3.3.3
2018-09-25 02:01:37 status unpacked tuptime:amd64 3.3.3
2018-09-25 02:01:37 status half-installed tuptime:amd64 3.3.3
2018-09-25 02:01:37 status half-installed tuptime:amd64 3.3.3
2018-09-25 02:01:38 status unpacked tuptime:amd64 3.4.0
2018-09-25 02:01:38 status unpacked tuptime:amd64 3.4.0
2018-09-25 02:01:55 configure tuptime:amd64 3.4.0 
2018-09-25 02:01:55 status unpacked tuptime:amd64 3.4.0
2018-09-25 02:01:55 status unpacked tuptime:amd64 3.4.0
2018-09-25 02:01:55 status unpacked tuptime:amd64 3.4.0
2018-09-25 02:01:55 status half-configured tuptime:amd64 3.4.0
2018-09-25 02:01:56 status installed tuptime:amd64 3.4.0

> Please, can you add here the output of 'su -s /bin/sh tuptime -c
> "tuptime -x"'?

# su -s /bin/sh tuptime -c "tuptime -x"
ERROR:root:After system restart, the values must be saved into db. Please, 
execute tuptime with a privileged user.

HTH.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#915063: [Pkg-xen-devel] Bug#915063: xen-hypervisor-4.8-amd64: xen 4.8 fails to boot

[Hans van Kranenburg]

severity -1 normal
thanks

Hi,

On 11/30/18 12:31 AM, gregory bahde wrote:
> Package: src:xen
> Version: 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> I installed xen hypervisor 4.8 and rebooted to Xen, I am used to xen and run 
> it
> on servers
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> try grub kernel xen parameters (iommu )

Can you tell us a bit more about what you were doing or trying to
accomplish?

Just "I was trying out random command line parameters" and then
reporting a critical bug does not sound very convincing. :)

The "breaks the whole system" justification would be justified if by
using this parameter on the xen command line would have destroyed your
entire computer, the filesystem, whatever, or in any case, caused
irrepairable damage to things that are not related to Xen at all. If
you're able to remove the parameter and then just happily use your
system again as before, then it didn't break your whole system for sure.

Thanks,
Hans

>* What was the outcome of this action?
> blackscreen at gdm3 login session
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> 
> -- System Information:
> Debian Release: 9.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), 
> (11, 'testing'), (10, 'experimental'), (10, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/16 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> xen-hypervisor-4.8-amd64 depends on no packages.
> 
> Versions of packages xen-hypervisor-4.8-amd64 recommends:
> ii  xen-utils-4.8  4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
> 
> xen-hypervisor-4.8-amd64 suggests no packages.
> 
> -- debconf-show failed
> 
> ___
> Pkg-xen-devel mailing list
> pkg-xen-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-xen-devel
> 

Bug#915062: RFP: node-semantic-ui -- UI component framework based around useful principles from natural language

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-semantic-ui
  Version : 2.3.1
  Upstream Author : jack 
* URL : https://notabug.org/makenotabuggreatagain/Semantic-UI
* License : MIT
  Programming Lang: javascript
  Description : UI component framework based around useful principles from 
natural language

A UI framework designed for theming.

Features:  50+ UI elements, 3000 + CSS variables, 3 Levels of variable 
inheritance (similar to SublimeText),
Built with EM values for responsive design and is Flexbox friendly.

A minified copy of node-sematic-ui was found while packaging gogs ( #911419 ).

Bug#915063: xen-hypervisor-4.8-amd64: xen 4.8 fails to boot

[gregory bahde]

Package: src:xen
Version: 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

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

   * What led up to the situation?
I installed xen hypervisor 4.8 and rebooted to Xen, I am used to xen and run it
on servers
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
try grub kernel xen parameters (iommu )
   * What was the outcome of this action?
blackscreen at gdm3 login session
   * What outcome did you expect instead?

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



-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), 
(11, 'testing'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/16 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

xen-hypervisor-4.8-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.8-amd64 recommends:
ii  xen-utils-4.8  4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10

xen-hypervisor-4.8-amd64 suggests no packages.

-- debconf-show failed

Bug#881333: tracking OpenGL support for specific boards

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 29 de noviembre de 2018 19:00:28 -03 Re4son escribió:
[snip]
> > Many of those chipsets you list, as I understand, have a mesa driver
> > for them that support opengl and gles.
> > Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/
> > 
> > Keep in mind, only the proprietary drivers seem to not support opengl
> > while the hardware is perfectly capable of doing so.
> 
> Not necessarily.
> If the manufacturer specifies OpenGL ES support, then - on the hardware
> level - it is a GLES renderer and may or may not support the entire
> OpenGL specification natively. It usually requires considerable work to
> make GLES hardware support OpenGL.
> Eric Anhold can tell you all about the hard work he has put into
> bastardising his VC4 mesa driver to make up for the lack of hardware
> support:
> 
> https://github.com/anholt/mesa/wiki/VC4-OpenGL-support

Ah, so there was the gotcha. I was really surprised to learn that it was 
"just" a driver issue. Clearly the Desktop OpenGL support is almost there, but 
not entirely.

So the real place which should be fixed is, somehow, in Qt itself, and 
preferably by not hacking libs.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#915061: gap: improved watchfile [patch]

[Bill Allombert]

On Thu, Nov 29, 2018 at 11:46:58PM +0100, Mattia Rizzolo wrote:
> Source: gap
> Severity: wishlist
> Tags: patch
> 
> Dear maintainer,
> 
> I notice that the watchfile used in the gap pacakge is very simple and
> doesn't really do anything about the different versioning used between
> upstream and debian.

Hello Mattia, the actual Debian tarball is generated by
debian/tarball, so if debian/watch mangles the version 
then debian/tarball must be changed not to do it.

It seems to me there might be some benefit to your change that you are
not communicating.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#748631: apt-listchanges: doens't list changes for all packages

[Christoph Anton Mitterer]

Hey :-)

On Thu, 2018-11-29 at 23:44 +0100, Robert Luberda wrote:
> What is the output of the following command:
>  apt-listchanges --profile=apt --dump-seen | grep -E '(util-
> linux|lvm2)'

#  apt-listchanges --profile=apt --dump-seen | grep -E '(util-linux|lvm2)'
lvm2 2:1.02.48-2
util-linux 1:2.17.2-3.1


with:
# dpkg -l lvm2
...
ii  lvm2   2.02.176-4.1 amd64Linux Logical Volume Manager
# dpkg -l util-linux
...
ii  util-linux 2.32.1-0.2   amd64miscellaneous system utilities


Thanks,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#915027: libxft-dev should be installable for multiple architectures simultaneously

[Davy Durham]

To be completely transparent, I did this on Ubuntu 16.04, but the 
package has not been changed significantly that I can see.  So, that's odd


I got the error when running "apt-get install libxft-dev:i386 
libxft-dev:amd64" which gives the conflict error.  If I run "dpkg -i 
libxft-dev_2.3.2-1_amd64.deb libxft-dev_2.3.2-1_i386.deb" it will look 
like it installs both, but the install of i386 silently replaces the 
amd64, and running a dpkg --list would show only i386 as installed.


That's probably basic for you, but that is what I am seeing. Does that 
information change anything in your testing?



On 11/29/2018 11:08 AM, Sven Joachim wrote:

Control: tags -1 unreproducible

On 2018-11-29 10:16 -0600, Davy Durham wrote:


Package: libxft-dev
Version: 2.3.2-2

Attempting to install libxft-dev for amd64 and i386 at the same time
(or any other arch for that matter) gives an error that they
conflict.

Not for me, I can coinstall libxft-dev:amd64 and libxft-dev:i386 just
fine.


This is because the "Package: libxft-dev"section of the
debian/control file does not contain "Multi-arch: same" (see
https://wiki.debian.org/MultiArch/Hints#set_Multi-Arch:_same)which
says that any duplicate files between the two different architectures
is fine.

That's already the case:

,
| $ aptitude show libxft-dev | grep -E Multi-Arch
| Multi-Arch: same
`


P.S. The same bug could be filed for libxi-dev, libxtst-dev, (these
two also affect me) and probably many of the other x dev packages.
Let me know if you want me to file separate bug reports for those.

Most definitely not, libxi-dev and libxtst-dev are also already
"Multi-Arch: same".

My hunch is that you are running unstable and there might be a version
skew for some dependency package (libc6-dev, maybe?) which prevents you
from installing both libxft-dev:amd64 and libxft-dev:i386.  If that is
the case, please retry after the next mirror push.

Cheers,
Sven

Bug#913548: spamassassin: running /etc/cron.daily/spamassassin gives: Unescaped left brace in regex is deprecated here

[Elimar Riesebieter]

* Brian May  [2018-11-30 08:10 +1100]:

> > Well, it seems that this is a bug in amavisd-new which is started by
> > /etc/spamassassin/sa-update-hooks.d/amavisd-new. Reassigned hereby.
> 
> Why do you think amavisd-new is causing this?
> 
> This is a simple shell script that calls another shell script,
> /etc/init.d/amavis. As far as I can tell, stdout gets directed to
> /dev/null and stderr is closed by start-stop-daemon, so cannot display
> anything. In addition, I think amavis-new might redirect stderr, not
> 100% sure here.
> 
> Furthermore, if I run this script by hand on a sid system it is silent.

Here we go:

root@toy>pts/4 /etc/spamassassin/sa-update-hooks.d # ./amavisd-new 
Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.32), passed through in regex; marked by <-- HERE in m/ ( { <-- HERE } (?: / 
\* )? | \* ) / at (eval 109) line 830.
root@toy>pts/4 /etc/spamassassin/sa-update-hooks.d # 

Get the same result as user amavis

Elimar
-- 
  355/113: Not the famous irrational number pi,
   but an incredible simulation!
-unknown


signature.asc
Description: PGP signature

Bug#915061: gap: improved watchfile [patch]

[Mattia Rizzolo]

Source: gap
Severity: wishlist
Tags: patch

Dear maintainer,

I notice that the watchfile used in the gap pacakge is very simple and
doesn't really do anything about the different versioning used between
upstream and debian.

For this, I'm proposing here a line that would make uscan correctly
compare the versions, mangling the debian version to change the 'r' and
'p' into dots.

version=3
options=dversionmangle=s/(\d+)r(\d+)p(\d+)/$1.$2.$3/ \
https://www.gap-system.org/pub/gap/gap4core/gap-(\d+\.\d+\.\d+)-core.zip debian

I haven't changed anything, just added the line in the middle doing the
mangling.


Hope this can be of use.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#915012: Acknowledgement ([gnome-shell alsa plugin] Gnome with the official sound plugin in Debian Stable does not control audio consistently. Notifications still keep the highest level of audio, a

[ervinndine]

I did further testing on this bug and found out that is it not caused
by system apps but rather by flatpak and snap apps. They are sandboxed
so they access the system sound separately. I was using minitube, a
youtube app by flatpak. So you can either keep the bug about such apps
or close it. Best, 
Ervin


On Thu, 2018-11-29 at 13:21 +, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 915012: https://bugs.debian
> .org/cgi-bin/bugreport.cgi?bug=915012.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due
> course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian GNOME Maintainers  org>
>  unknown-pack...@qa.debian.org
> 
> If you wish to submit further information on this problem, please
> send it to 915...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

Bug#748631: apt-listchanges: doens't list changes for all packages

[Robert Luberda]

Christoph Anton Mitterer writes:

Hi,

> 
> (better 4 years late than never?! * ashamed *)
> 
> It's really the case for all versions of at least and util-linux / lvm2
> packages.
> 
> I'm running sid, so take any version of the these packages from the
> last years and it wouldn't show me the changelogs for them.


It works for me. I've just checked recent mails from apt-listchanges,
and I've found entries for util-linux, for example:

  --- Changes for util-linux (bsdutils libuuid1 libblkid1 libfdisk1
libsmartcols1 libmount1 fdisk util-linux mount uuid-dev
util-linux-locales) ---
  util-linux (2.32.1-0.2) unstable; urgency=medium

* Non-maintainer upload.

[ Niels Thykier ]
* Declare the explicit requirement for (fake)root
[ strip most of the log - RL ]
   -- Andreas Henriksson   Tue, 06 Nov 2018 20:53:01 +0100

What is the output of the following command:
 apt-listchanges --profile=apt --dump-seen | grep -E '(util-linux|lvm2)'


Regards,
robert

Bug#911187: axis: FTBFS with Java 11 due to javax.rmi and CORBA removal

[Emmanuel Bourg]

Le 30/10/2018 à 14:18, Markus Koschany a écrit :
> I was investigating the Java 11 FTBFS of axis and uddi4j. I wonder if we
> rather should focus on removing these packages instead of patching them.

I agree, I've requested the removal of uddi4j and wsil4j.


> eclipse-* packages can be ignored and jalview has been RC buggy for a
> long time. uddi4j can go as well and it only has eclipse-wtp and wsil4j
> as r-deps.

The two eclipse packages have now been removed.

jalview uses Axis for the javax.xml.rpc API. It can probably use
libjaxrpc-api-java instead.


> I don't see any code in starjava-vo that uses axis, looks more like a
> runtime feature but I'm not sure.

I got a quick look. starjava-vo builds fine without axis. I've found
only one class with SOAP related code (Ri1RegistryQuery) and it calls
the SoapClient class from starjava-registry [1]. Axis isn't used for
this client implementation as explained in the source file:

/**
 * Lightweight, freestanding SOAP client which can make simple requests
 * and allows the responses to be processed as a SAX stream.
 * Logging of sent and received XML can optionally be performed by
 * using the {@link #setEchoStream} method.
 * Probably, there is much of SOAP that this doesn't implement, but
 * it works well enough to write a registry client on top of it.
 *
 * Why write yet another SOAP client?  Last time I tried to get Axis
 * to do this (stream processing of the response) it took me several
 * days of misery, and still didn't work.  The actual job I need to
 * do here is quite straightforward, so it's not difficult to write it
 * from scratch.
 *
 * @author   Mark Taylor
 * @since9 Dec 2009
 */

So I think it's safe to remove the axis dependency in this case.


> In uimaj the uimaj-adapter-soap makes use of axis.

uima-as builds fine without libuima-adapter-soap-java, so we can scrap it.


[1]
https://salsa.debian.org/debian-astro-team/starjava-registry/blob/master/src/main/uk/ac/starlink/registry/SoapClient.java

Bug#914516: transition: hunspell

[Rene Engelhard]

block 914516 by 915060
thanks

Hi,

On Thu, Nov 29, 2018 at 10:17:49PM +0100, Rene Engelhard wrote:
> > Uploaded.
> 
> Installed everywhere (except ksd where it is only Built but not uploaded
> for hours), so you can schedule bin-NMUs.

Noticed link-grammar (though it builds) fails the autopkgtest of the
testing version because its test assumes stuff which isn't fullfilled.
See #915060 for my analysis

Regards,
  
Rene

Bug#891798: CVE-2017-3158

[Petter Reinholdtsen]

Control: retitle -1 guacamole-client: CVE-2017-3158 race can cause buffer 
overflow

https://security-tracker.debian.org/tracker/CVE-2017-3158 > provide
useful links.

Any hope to have a fixed version in Debian?  According to the NIST link, the
problem existed in 0.9.10-incubating, and upstream is currently on 0.9.14.  
Perhaps a new upstream version solve the problem?

-- 
Happy hacking
Petter Reinholdtsen

Bug#915060: link-grammar: autopkgtest relies on built binaries without matching dependencies

[Rene Engelhard]

Source: link-grammar
Version: 5.5.0-1
Severity: serious

Hi,

$ cat debian/tests/control
Tests: unit-tests
Depends: @, python3-distutils, build-essential, hunspell-en-us, locales-all,
 default-jdk [!hppa !hurd-i386 !m68k !sh4],
Restrictions: build-needed

So far so good.

But that means that in the testing migration autopkgtests this breaks when
there is a hunspell transition.

See e.g. 
https://ci.debian.net/data/autopkgtest/testing/amd64/l/link-grammar/1399248/log.gz

What seems to happen (correct me if I am wrong) is:

1. link-grammar gets built. Because the autopkgtest injects libhunspell 1.7 
somehow into the
build this one is built against libhunspell-1.7.

2. Now the test packages get installed in a clean environment. Because you just 
say "@" you get
the dependencies from your own package (libhunspell-1.6) , not the built one 
(as should be, indeed)

3. The test now fails because it cannot open the libhunspell-1.7.so.0 because 
what was installed for
2. was just libhunspell-1.6.

Maybe you want to add at least @builddeps@? But that would only hide the 
problem...

Regards,

Rene

Bug#912087: other services affected too

[Matt Zagrabelny]

Greetings,

Sorry I am late to the discussion.

I have some systems running in a VMWare infrastructure and things like ssh
and puppet are not starting (puppet times out and fails) or taking a long
time to start (ssh).

If I install sshd, I expect it to start (somewhat quickly) not 200 seconds
after boot. If I install puppet, I expect it to start - not timeout and
fail.

It seems installing haveged has "fixed" these issues [Thanks jim_p <
pitsior...@gmail.com>] , but knowing those specific solutions remains the
challenge.

I've spent a lot of time debugging, reading, and researching to find these
bug reports and threads. It takes a lot of time and even then I'm not
certain of the appropriateness of the fix. Is installing haveged the right
solution for a headless VM that needs to have ssh and puppet running?

Right now systemd upstream is dubious of PR 10621 and according to Michael
Biebl it will be opt-in only. PS. Thank you Michael for your work on
systemd.

Where do we communicate to admins that their services might be slow to
start or fail to start and they need to manually install some package
(haveged) or touch a systemd config (PR 10621)?

Thanks everyone for their input in this discussion!

It is appreciated!

-m

Bug#911443: raspi3-firmware | Add board-specific firmware files for RPi 3B+ WiFi (!1)

[Stefan Wahren]

Hi,

> Matthias Luescher  hat am 29. November 2018 um 22:18 
> geschrieben:
> 
> 
> Hi Gunnar
> 
> I must say, I have not been able to find WiFi (not even a "firmware
> > required" message). Could you help me find it, so it makes its way into
> > raspi3-image-spec ? Thanks -
> > I'm closing this MR.
> >
> 
> I have also struggled with WiFi. Could the "missing WiFi" issue be related
> to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911443?
> The WiFi (wlan0) reappears if I combine the 4.18 kernel with the device
> tree binary of the 4.17 kernel.
> The device tree change causing the absence of wlan0 might be this one:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/bcm2837-rpi-3-b.dts?h=v4.20-rc4=b1b8f45b3130dbd8704e5ea0d82b49b1d929498e
> 
> @Stefan and @Eric: As you are the experts here: Can you give us a clue why
> the wlan0 interface disappears if we take the latest device tree binary
> from 4.18 vanilla kernel?

Which RPi 3 variant do you use (B or B+)?

Could you please provide a reduced kernel config?

Is armhf (32 bit) affected, too?

Stefan

> 
> Best regards
> Matthias
> 
> >

Bug#915007: opensaml2 FTBFS with xmltooling 3

[Ferenc Wágner]

peter green  writes:

> I then had a poke around and noticed that an "opensaml" source package
> had recently been uploaded that seems to have taken over most of the
> binary package names from opensaml2. If the intention is for opensaml
> to replace opensaml2 can you file a removal request?

Hi,

Yes, the source package was renamed before the upgrade, and the old
opensaml2 and shibboleth-sp2 source packages will be removed once
shibboleth-resolver and moonshot-gss-eap are upgraded to build using the
new ones.
-- 
Regards,
Feri

Bug#914897: debootstrap, buster: Please disabled merged /usr by default

[Alexander E. Patrakov]

Ian Jackson wrote:

Obviously I disagree.  I think the question is urgent.  Please would
you rapidly overrule the debootstrap maintainers.

After we have ceased introducing new lossage we can have a proper
conversation about what the plan ought to be for buster and bullseye.


Well, please take into account that a version of debootstrap which 
defaulted to merged /usr has been in Debian Testing (and thus, if I am 
not mistaken, available through daily builds of the netinst CDs) since 
June 25 or so. Five months. No matter what we decide finally, it is 
necessary to support systems that were installed during that five-month 
period.


In other words, it's already too late to "minimize" the damage by 
undoing the change, and there is no point in acting quickly. At least in 
my opinion.


--
Alexander E. Patrakov

Bug#915019: libreoffice-mysql-connector: copyright file missing after upgrade (policy 12.5)

[Rene Engelhard]

On Thu, Nov 29, 2018 at 03:49:58PM +0100, Andreas Beckmann wrote:
> >From the attached log (scroll to the bottom...):
> 
> 0m50.5s ERROR: WARN: Inadequate results from running adequate!
>   libreoffice-mysql-connector: missing-copyright-file 
> /usr/share/doc/libreoffice-mysql-connector/copyright
> 
>   MISSING COPYRIGHT FILE: /usr/share/doc/libreoffice-mysql-connector/copyright
>   # ls -lad /usr/share/doc/libreoffice-mysql-connector
>   drwxr-xr-x 2 root root 40 Nov 21 08:16 
> /usr/share/doc/libreoffice-mysql-connector
>   # ls -la /usr/share/doc/libreoffice-mysql-connector/
>   total 0
>   drwxr-xr-x   2 root root   40 Nov 21 08:16 .
>   drwxr-xr-x 209 root root 4340 Nov 21 08:16 ..

*sigh*...

> It is recommended to use the dpkg-maintscript-helper commands
> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
> to perform the conversion, ideally using d/$PACKAGE.maintscript.

Will do.

> Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.

Please update your template :)

dpkg   | 1.17.27   | oldstable  | source, amd64, arm64,
armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x

dpkg 1.17.14 is a given.

Regards,

Rene

Bug#881333: tracking OpenGL support for specific boards

[Re4son]

On 28/11/18 1:19 am, bret curtis wrote
>> Great that you collected that dataset, and put it public.
>>
>> What would help further would be for such information having references
>> to sources, and each information point be referencable (not only the
>> dataset as a whole).
>>
> Isn't this already done for us here?
> https://gpuinfo.org/
>
> If anything, it should be used to fill in that list.

Great data, thanks. I'll add that.
I basically used data from the Khronos website to point me in a general
direction and then I used manufacturers specifications to fill in the
GL/GLES columns.

> Many of those chipsets you list, as I understand, have a mesa driver
> for them that support opengl and gles.
> Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/
>
> Keep in mind, only the proprietary drivers seem to not support opengl
> while the hardware is perfectly capable of doing so.

Not necessarily.
If the manufacturer specifies OpenGL ES support, then - on the hardware
level - it is a GLES renderer and may or may not support the entire
OpenGL specification natively. It usually requires considerable work to
make GLES hardware support OpenGL.
Eric Anhold can tell you all about the hard work he has put into
bastardising his VC4 mesa driver to make up for the lack of hardware
support:

https://github.com/anholt/mesa/wiki/VC4-OpenGL-support


Hope that helps,
Re4son

>
> Cheers,
> Bret

Bug#915059: fuji: Should the package be removed?

[Dr. Tobias Quathamer]

Source: fuji
Severity: serious

Dear maintainer,

I was wondering if the fuji package should be removed. There hasn't been
an upload for more than 2 years, and the package has an open FTBFS RC
bug for over a year (https://bugs.debian.org/876827).

The upstream homepage says that the development of the program has been
stopped for almost three years (https://github.com/shiguredo/fuji).

The package also has a very low popcon value of 3.

If you don't object, I'll ask ftpmaster for a removal of this package
from unstable in the next days.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#914649: libvigraimpex: diff for NMU version 1.10.0+git20160211.167be93+dfsg-6.1

[Gilles Filippini]

Control: tags 914649 + pending

Dear maintainer,

I've prepared an NMU for libvigraimpex (versioned as
1.10.0+git20160211.167be93+dfsg-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

_g.

diff -Nru libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog
--- libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog
2018-08-11 06:20:04.0 +0200
+++ libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/changelog
2018-11-29 20:39:23.0 +0100
@@ -1,3 +1,11 @@
+libvigraimpex (1.10.0+git20160211.167be93+dfsg-6.1) unstable;
urgency=medium
+
+  * Non-maintainer upload.
+  * New patch link-with-pthread.patch to fix FTBFS against boost1.67 on
+armel (Closes: #914649)
+
+ -- Gilles Filippini   Thu, 29 Nov 2018 20:39:23 +0100
+
 libvigraimpex (1.10.0+git20160211.167be93+dfsg-6) unstable; urgency=medium
* add multi_convolution_fix_incomplete_template_paramater.patch
diff -Nru
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
---
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
1970-01-01 01:00:00.0 +0100
+++
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/link-with-pthread.patch
2018-11-29 20:39:23.0 +0100
@@ -0,0 +1,16 @@
+Description: Workaround to fix FTBFS on armel
+  /usr/bin/ld:
CMakeFiles/test_blockwisewatersheds.dir/test_watersheds.cxx.o:
+undefined reference to symbol 'pthread_condattr_setclock@@GLIBC_2.4'
+Index:
libvigraimpex-1.10.0+git20160211.167be93+dfsg/config/VigraConfigureThreading.cmake
+===
+---
libvigraimpex-1.10.0+git20160211.167be93+dfsg.orig/config/VigraConfigureThreading.cmake

libvigraimpex-1.10.0+git20160211.167be93+dfsg/config/VigraConfigureThreading.cmake
+@@ -9,7 +9,7 @@ macro(VIGRA_CONFIGURE_THREADING)
+ set(THREADING_FOUND 1)
+ if(THREADING_IMPLEMENTATION MATCHES "boost")
+ include_directories(${Boost_INCLUDE_DIR})
+-set(THREADING_LIBRARIES ${Boost_THREAD_LIBRARY}
${Boost_SYSTEM_LIBRARY} ${Boost_DATE_TIME_LIBRARY} ${Boost_CHRONO_LIBRARY})
++set(THREADING_LIBRARIES ${Boost_THREAD_LIBRARY}
${Boost_SYSTEM_LIBRARY} ${Boost_DATE_TIME_LIBRARY}
${Boost_CHRONO_LIBRARY} pthread)
+ elseif(THREADING_IMPLEMENTATION MATCHES "std")
+ # Great, we can use the std library.  Nothing to do here...
+ elseif(THREADING_IMPLEMENTATION MATCHES "none")
diff -Nru
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series
libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series
--- libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series
2018-08-11 06:18:32.0 +0200
+++ libvigraimpex-1.10.0+git20160211.167be93+dfsg/debian/patches/series
2018-11-25 22:21:32.0 +0100
@@ -7,3 +7,4 @@
 removed-static-docs.diff
 const-swap.patch
 multi_convolution_fix_incomplete_template_paramater.patch
+link-with-pthread.patch



signature.asc
Description: OpenPGP digital signature

Bug#914516: transition: hunspell

[Rene Engelhard]

Hi,

On Wed, Nov 28, 2018 at 10:42:14PM +0100, Rene Engelhard wrote:
> On Wed, Nov 28, 2018 at 07:07:54PM +0100, Emilio Pozuelo Monfort wrote:
> > On 24/11/2018 11:07, Rene Engelhard wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > hunspell 1.7 was finally released. It includes a load of fixes
> > > we miss e.g. in LibreOffice because instead of using the
> > > patched-internal version we use the system version.
> > > 
> > > Cleared NEW just now.
> > > 
> > > So I'd like to get this transition done asap after
> > > icu/boost/python3.7-as-default is done :)
> > > 
> > > Did a rebuild using ratt and (almost) all packages built fine, except
> > > some otherwise failing packages (mudlet and plume-creator (both sid
> > > only) because of #907159 and #887534)
> > > I skipped firefox, too; firefox-esr is fine.
> > > (And libreoffice, but libreoffice is "of course" fine, too)
> > 
> > Go ahead.
> 
> Uploaded.

Installed everywhere (except ksd where it is only Built but not uploaded
for hours), so you can schedule bin-NMUs.

Regards,
 
Rene

Bug#913548: spamassassin: running /etc/cron.daily/spamassassin gives: Unescaped left brace in regex is deprecated here

[Brian May]

> Well, it seems that this is a bug in amavisd-new which is started by
> /etc/spamassassin/sa-update-hooks.d/amavisd-new. Reassigned hereby.

Why do you think amavisd-new is causing this?

This is a simple shell script that calls another shell script,
/etc/init.d/amavis. As far as I can tell, stdout gets directed to
/dev/null and stderr is closed by start-stop-daemon, so cannot display
anything. In addition, I think amavis-new might redirect stderr, not
100% sure here.

Furthermore, if I run this script by hand on a sid system it is silent.

So kind of wondering how to reproduce this.
-- 
Brian May 

Bug#915058: python-socketio-realtime-server/2.1.0-1 [QA]

[Paulo Henrique de Lima Santana]

Package: python-socketio-realtime-server
Severity: wishlist
X-Debbugs-CC: mike.gabr...@das-netzwerkteam.de

Hi, 

Please **don't sponsor and upload** this package because my AM (Mike Gabriel)
will review it for me.

 * Package name: python-socketio-realtime-server
   Version : 2.1.0-1
   Upstream Author : Miguel Grinberg 
 * URL : https://github.com/miguelgrinberg/python-socketio
 * License : MIT
   Section : python

It builds this binary package:

  python3-socketio-realtime-server - Python implementation of the Socket.IO
realtime server

To access further information about these packages, please visit the
following URL:

https://mentors.debian.net/sponsors/rfs-howto/python-socketio-realtime-server

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-socketio-realtime-server/python-socketio-realtime-server_2.1.0-1.dsc

More information about kickpass can be obtained from
https://github.com/miguelgrinberg/python-socketio

Best regards,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
http://www.heforshe.org/pt


pgpufCx_AxZND.pgp
Description: PGP signature

Bug#911443: raspi3-firmware | Add board-specific firmware files for RPi 3B+ WiFi (!1)

[Matthias Luescher]

Hi Gunnar

I must say, I have not been able to find WiFi (not even a "firmware
> required" message). Could you help me find it, so it makes its way into
> raspi3-image-spec ? Thanks -
> I'm closing this MR.
>

I have also struggled with WiFi. Could the "missing WiFi" issue be related
to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911443?
The WiFi (wlan0) reappears if I combine the 4.18 kernel with the device
tree binary of the 4.17 kernel.
The device tree change causing the absence of wlan0 might be this one:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/bcm2837-rpi-3-b.dts?h=v4.20-rc4=b1b8f45b3130dbd8704e5ea0d82b49b1d929498e

@Stefan and @Eric: As you are the experts here: Can you give us a clue why
the wlan0 interface disappears if we take the latest device tree binary
from 4.18 vanilla kernel?

Best regards
Matthias

>

Bug#898960: [libpangoft2-1.0-0] Crashes some Java applications in pango_fc_font_key_get_variations

[Zoltan Hidvegi]

I am also experiencing this with eclipse, it seems there is a fix upstream,
see the discussion here: https://github.com/gentoo/gentoo/pull/10417

Zoltan

Bug#915057: ITP: redberry-pipe -- implementation of concurrent pipelines

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: redberry-pipe
  Version : 0.9.7
* URL : https://bitbucket.org/redberry/redberry-pipe
* License : GPL
  Programming Lang: Java
  Description : implementation of concurrent pipelines

 Redberry is an open source computer algebra system designed for algebraic
 manipulations with tensors.
 .
 This package provides its "pipe" subproject featuring a Java library
 for implementation of concurrent pipelines.

 The package is prepared to be uploaded to 
https://salsa.debian.org/java-team/redberry-pipe
 for team maintenance.

Bug#915056: unbound: qname-minimisation.conf no longer necessary

[John Shaft]

Package: unbound
Version: 1.8.1-1
Severity: wishlist

Dear Maintainer,

the unbound.conf.d/qname-minimisation.conf file added a few years back to 
enable by default QNAME Minimisation is no longer needed as NLNet Labs made it 
Unbound's default since version 1.7.2

My guess is that it can be safely removed from the Debian package.

Thanks,

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

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

Versions of packages unbound depends on:
ii  adduser 3.118
ii  dns-root-data   2018091102
ii  libc6   2.27-8
ii  libevent-2.1-6  2.1.8-stable-4
ii  libfstrm0   0.3.0-1+b1
ii  libprotobuf-c1  1.3.1-1+b1
ii  libpython3.63.6.7-1
ii  libssl1.1   1.1.1a-1
ii  libsystemd0 239-13
ii  lsb-base9.20170808
ii  openssl 1.1.1a-1
ii  unbound-anchor  1.8.1-1

unbound recommends no packages.

Versions of packages unbound suggests:
ii  apparmor  2.13.1-3+b1

-- Configuration Files:
/etc/apparmor.d/usr.sbin.unbound changed [not included]

-- no debconf information

Bug#914916: nmap: Integrate prometheues port map into services file?

[Daniel Miller]

Nmap gets port names from IANA, with some community input for very common
services.
Port 9103 is frequently used by JetDirect printers, which is why it is
labeled that way.
Use -sV to probe the target and identify the service itself. Unidentified
services can be
submitted directly to the Nmap Project:
https://nmap.org/book/vscan-community.html

This is a better topic to discuss with Nmap development community, not the
Debian
package maintainers. Please open an issue on http://issues.nmap.org/ or
join the
Nmap developers mailing list: https://seclists.org/nmap-dev/

Dan

Bug#915040: (no subject)

[Paulo Henrique de Lima Santana]

Control: retitle -1 ITP: python-socketio-realtime-server -- Python 
implementation of the Socket.IO realtime server


-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
http://www.heforshe.org/pt


pgpJggaFuCYjW.pgp
Description: PGP signature

Bug#612509: Bug#684115: Any news on relaxing to only suggest wildmidi-config?

[Fabian Greffrath]

Hi Bret,

Am Donnerstag, den 29.11.2018, 16:43 +0100 schrieb bret curtis:
> https://salsa.debian.org/psi29a-guest/WildMIDI

so, you would like me to review and upload this?

Is this the canonical location for the packaging repository?

Cheers,

 - Fabian



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

Bug#915040: (no subject)

[Paulo Henrique de Lima Santana]

Control: retitle -1 ITP: python-socketio-realtime-server -- Python
implementation of the Socket.IO realtime server


-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
http://www.heforshe.org/pt


pgpoipmSgGTzR.pgp
Description: PGP signature

Bug#856505: snd_bcm2835 included on 4.19 kernel in experimental

[eHenry Berg]

Hi!

This is my souces.list, but I got your message:
# cat /etc/apt/sources.list
deb http://ftp.fi.debian.org/debian sid main contrib non-free
#
I have been working with Dkms with this:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/tree/drivers/staging/vc04_services
with branch staging-testing.
I got both vchiq.ko and snd-bcm2835.ko compiled and installed, but I
think I am in the same situation like you.

This is what Raspian give:
nov 24 16:36:03 raspberrypi kernel: snd_bcm2835: module is from the
staging directory, the quality is unknown, you have been warned.
nov 24 16:36:03 raspberrypi kernel: bcm2835_alsa bcm2835_alsa: card
created with 8 channels

Debian armhf with gregkh driver source give this:
Nov 28 21:04:46 irena kernel: vchiq: loading out-of-tree module taints kernel.
Nov 28 21:04:46 irena kernel: vchiq: vchiq_init_state: slot_zero =
61f93cc4, is_master = 0
Nov 28 21:04:46 irena systemd-modules-load[190]: Inserted module 'snd_bcm2835'

lsmod and /proc/modules look okay i.e. modules have been loaded.
/proc/asound is not populated with the new driver i.e. we do not have
communication interface with the hardware.

I just recently got the modules installed. I think like you that the
dtb is the culprit. I have not studied how I can get dts compiled
without the whole kernel yet, but maybe you can test the below.
Here is a link:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/tree/drivers/staging/vc04_services/bcm2835-audio/TODO
audio: audio {
compatible = "brcm,bcm2835-audio";
brcm,pwm-channels = <8>;
};

I think the 4 rows with audio should be inserted into this
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/tree/arch/arm/boot/dts/bcm283x.dtsi
after
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};

Can you put these 4 rows in bcm283x.dtsi in Debian. Test the new dtb
you got after this. Is /proc/asound populated with the new driver now?

4 °C in Aland Islands regards,
Evald

Bug#907409: casync: FTBFS with glibc 2.28, header mismatch wih new renameat2()

[Aurelien Jarno]

control: severity -1 serious

On 2018-08-27 10:00, Steve Langasek wrote:
> Package: casync
> Version: 2+20180321-2
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu cosmic ubuntu-patch
> 
> Dear maintainers,
> 
> casync fails to build from source against glibc 2.28, as seen in the Ubuntu
> autopkgtest:
> 
> [...]
> cc -Isrc/src@@shared@sta -Isrc -I../src -fdiagnostics-color=always -pipe 
> -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wextra -Werror=undef -Werror=format=2 
> -Wformat-security -Wformat-nonliteral -Wlogical-op -Wmissing-include-dirs 
> -Werror=old-style-definition -Werror=pointer-arith -Winit-self 
> -Wdeclaration-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn 
> -Werror=missing-prototypes -Werror=implicit-function-declaration 
> -Werror=missing-declarations -Werror=return-type 
> -Werror=incompatible-pointer-types -Werror=shadow -Werror=int-conversion 
> -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wendif-labels 
> -Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter 
> -Wno-missing-field-initializers -Wno-unused-result -Werror=overflow 
> -Werror=sign-compare -Wdate-time -Wnested-externs -fno-common 
> -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden 
> -fstack-protector -fstack-protector-strong -fPIE --param=ssp-buffer-size=4 
> -include config.h -g -O2 
> -fdebug-prefix-map=/tmp/autopkgtest.iBt8c8/build.W5z/src=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fPIC  -MD -MQ 'src/src@@shared@sta/cacache.c.o' -MF 
> 'src/src@@shared@sta/cacache.c.o.d' -o 'src/src@@shared@sta/cacache.c.o' -c 
> ../src/cacache.c
> In file included from ../src/canametable.h:9,
>  from ../src/calocation.h:12,
>  from ../src/cacache.h:7,
>  from ../src/cacache.c:9:
> ../src/util.h:532:19: error: static declaration of ‘renameat2’ follows 
> non-static declaration
>  static inline int renameat2(int oldfd, const char *oldname, int newfd, const 
> char *newname, unsigned flags) {
>^
> In file included from ../src/util.h:12,
>  from ../src/canametable.h:9,
>  from ../src/calocation.h:12,
>  from ../src/cacache.h:7,
>  from ../src/cacache.c:9:
> /usr/include/stdio.h:164:12: note: previous declaration of ‘renameat2’ was 
> here
>  extern int renameat2 (int __oldfd, const char *__old, int __newfd,
> ^
> ninja: build stopped: subcommand failed.
> [...]
> 
>   
> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/c/casync/20180825_081049_5b743@/log.gz)
> 
> The casync build system does include a check for a system-provided
> renameat2() implementation, however, the new renameat2 in
> /usr/include/stdio.h in glibc 2.28 is guarded with __USE_GNU which means its
> availability is conditional on features.h selections - and while _GNU_SOURCE
> winds up being defined in meson.build for the actual software build, it is
> NOT defined while meson itself is doing feature detection.
> 
> Perhaps adding -D_GNU_SOURCE to c_args would fix the build failure, but I
> used the larger hammer of defining it as
> DEB_CFLAGS_MAINT_APPEND=-D_GNU_SOURCE in debian/rules.
> 
> Please consider the attached patch to fix this bug, which will become a
> serious bug once glibc 2.28 is uploaded to Debian.
> 
> -- 
> 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 casync-2+20180321/debian/rules casync-2+20180321/debian/rules
> --- casync-2+20180321/debian/rules2018-05-03 06:12:33.0 -0700
> +++ casync-2+20180321/debian/rules2018-08-27 09:50:17.0 -0700
> @@ -1,6 +1,7 @@
>  #! /usr/bin/make -f
>  
>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all
> +export DEB_CFLAGS_MAINT_APPEND=-D_GNU_SOURCE
>  
>  export LC_ALL=C.UTF-8

glibc 2.28 is now in sid, therefore raising the bug severity to serious.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#915055: binutils-mingw-w64: Nondeterminism in DLL import libraries

[Benjamin Moody]

Package: binutils-mingw-w64
Version: 2.27.90.20161231-1+7.4
Severity: normal
Tags: patch

Dear Maintainer,

When building a Windows DLL and accompanying import library using
'i686-w64-mingw32-ld' or 'x86_64-w64-mingw32-ld', the import library
includes build timestamps as well as UID/GID, which makes it difficult
to build a reproducible package.

A simple test:

  export SOURCE_DATE_EPOCH=0
  echo 'int foo(){return 42;}' > foo.c
  i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--out-implib=foo1.dll.a
  mv foo.dll foo1.dll
  sleep 1
  i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--out-implib=foo2.dll.a
  mv foo.dll foo2.dll
  diff foo1.dll foo2.dll  # succeeds
  diff foo1.dll.a foo2.dll.a  # fails

>From what I can tell, it should be easy to fix this by setting the
BFD_DETERMINISTIC_OUTPUT flag when creating the import library:

--- a/ld/pe-dll.c
+++ b/ld/pe-dll.c
@@ -2736,6 +2736,7 @@
 
   bfd_set_format (outarch, bfd_archive);
   outarch->has_armap = 1;
+  outarch->flags |= BFD_DETERMINISTIC_OUTPUT;
 
   /* Work out a reasonable size of things to put onto one line.  */
   ar_head = make_head (outarch);


(I've tested this patch on stretch, using binutils-source 2.28-5,
binutils-mingw-w64 7.4, gcc-mingw-w64 6.3.0-14+19.3.)

I can't think of any reason that this should cause compatibility
issues, since (unlike "normal" ar archives) the import library that is
generated in this way doesn't correspond to any "real" object files.
Thus, I can't think of any reason not to enable deterministic mode
unconditionally in this case.

I do, however, note the comment in bsd_write_armap (bfd/archive.c):

  "Some linkers may require that the archive filesystem modification
  time is less than (or near to) the archive map timestamp.  Those
  linkers should not be used with deterministic mode.  (GNU ld and
  Gold do not have this restriction.)"

I don't know if this comment has any relevance to MinGW or any other
Windows compilers.  (It seems unlikely, since timestamps in Windows
filesystems have historically been such a mess to begin with.)


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

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

Versions of packages binutils-mingw-w64 depends on:
ii  binutils-mingw-w64-i6862.28-5+7.4+b4
ii  binutils-mingw-w64-x86-64  2.28-5+7.4+b4

binutils-mingw-w64 recommends no packages.

binutils-mingw-w64 suggests no packages.

-- debconf-show failed

Bug#912857: libruby2.5 is wrongly marked Multi-Arch: same

[Antonio Terceiro]

Control: done -1 2.5.3-3

On Sun, Nov 04, 2018 at 05:18:24PM +0100, Helmut Grohne wrote:
> Package: libruby2.5
> Version: 2.5.1-6+b1
> Severity: important
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> libruby2.5 is wrongly marked Multi-Arch: same. It fails to coinstall on
> amd64 and arm64:
> 
> | Unpacking libruby2.5:arm64 (2.5.1-6+b1) ...
> | dpkg: error processing archive 
> /tmp/apt-dpkg-install-xsTPRC/29-libruby2.5_2.5.1-6+b1_arm64.deb (--unpack):
> |  trying to overwrite shared 
> '/usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png',
>  which is different from other instances of package libruby2.5:arm64
> | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> | Errors were encountered while processing:
> |  /tmp/apt-dpkg-install-xsTPRC/29-libruby2.5_2.5.1-6+b1_arm64.deb
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> The multiarch hinter says:
> 
> | libruby2.5 conflicts on 
> /usr/lib/ruby/2.5.0/rdoc/generator/template/darkfish/images/macFFBgHack.png 
> on any two of amd64, arm64, armel, armhf, and 6 more
> 
> Please remove the erroneous Multi-Arch: same marking or fix the file
> conflict.

It seems the final form of that file was capturing the build timestamp,
but that seems to not be the case anymore.  I checked this again against
libruby2.5 2.5.3-3 from the archive and a local binNMU-style build done
with sbuild, and the files are identical. I also tested installing
libruby2.5:i386 and libruby2.5:arm64 from the archive on an amd64
container, and it went fine.


signature.asc
Description: PGP signature

Bug#915054: vtk7: With #894076 fixed libvtk7.1-qt* can be enabled on armel/armhf

[Adrian Bunk]

Source: vtk7
Version: 7.1.1+dfsg1-10
Severity: normal

With #894076 fixed libvtk7.1-qt* can be enabled on armel/armhf
and the build dependency changed from libqt5opengl5-desktop-dev
to libqt5opengl5-dev.

Bug#915053: gitlab: Err 500 when go to the project page(any project)

[Dragos Jarca]

Package: gitlab
Version: 11.3.10+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When go to any project receive Err 500:

Started GET "/meteo/meteo" for 192.168.3.1 at 2018-11-29 21:43:55 +0200
Processing by ProjectsController#show as HTML
  Parameters: {"namespace_id"=>"meteo", "id"=>"meteo"}
Read fragment 
views/meteo/meteo/master/e34a8d6d6e4ae0c037caaf297bcf3f92877c76f5/application_settings/1-20181024143448558017000/false/false/success/en/9fe84ac8dd39e3a1ffb63dffbd2d29da
 (1.3ms)
Completed 500 Internal Server Error in 4925ms (ActiveRecord: 253.8ms)

ActionView::Template::Error (wrong number of arguments (given 1, expected 2)):
38: = sprite_icon('ellipsis_h', size: 12)
39:
40: .commiter
41:   - commit_author_link = commit_author_link(commit, avatar: 
false, size: 24)
42:   - commit_timeago = 
time_ago_with_tooltip(commit.authored_date, placement: 'bottom')
43:   - commit_text =  _('%{commit_author_link} authored 
%{commit_timeago}') % { commit_author_link: commit_author_link, commit_timeago: 
commit_timeago }
44:   #{ commit_text.html_safe }
  app/helpers/commits_helper.rb:210:in `clean'
  app/helpers/commits_helper.rb:136:in `commit_person_link'
  app/helpers/commits_helper.rb:10:in `commit_author_link'
  app/views/projects/commits/_commit.html.haml:41:in `block in 
_app_views_projects_commits__commit_html_haml__4510560646380060465_47275137929220'
  app/views/projects/commits/_commit.html.haml:18:in 
`_app_views_projects_commits__commit_html_haml__4510560646380060465_47275137929220'
  app/views/shared/_commit_well.html.haml:4:in 
`_app_views_shared__commit_well_html_haml__116673998689084462_47275138176200'
  app/views/projects/_files.html.haml:11:in 
`_app_views_projects__files_html_haml___338566813562587368_47275142850220'
  app/views/projects/show.html.haml:44:in 
`_app_views_projects_show_html_haml___1738900495709899687_47275132961580'
  lib/gitlab/i18n.rb:53:in `with_locale'
  lib/gitlab/i18n.rb:59:in `with_user_locale'
  app/controllers/application_controller.rb:412:in `set_locale'
  lib/gitlab/middleware/multipart.rb:101:in `call'
  lib/gitlab/request_profiler/middleware.rb:14:in `call'
  lib/gitlab/middleware/go.rb:17:in `call'
  lib/gitlab/etag_caching/middleware.rb:11:in `call'
  lib/gitlab/middleware/read_only/controller.rb:38:in `call'
  lib/gitlab/middleware/read_only.rb:16:in `call'
  lib/gitlab/middleware/basic_health_check.rb:25:in `call'
  lib/gitlab/request_context.rb:18:in `call'
  lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
  lib/gitlab/middleware/release_env.rb:10:in `call'

I cannot see details about projects, activity, etc.

Expect to see the project page.

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

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

Versions of packages gitlab depends on:
ii  asciidoctor   1.5.7.1-1
ii  bc1.07.1-2+b1
ii  bundler   1.16.1-3
ii  bzip2 1.0.6-9
ii  dbconfig-pgsql2.0.10
ii  debconf [debconf-2.0] 1.5.69
ii  gitlab-common 11.3.10+dfsg-2
ii  gitlab-shell  8.3.3+dfsg-1
ii  gitlab-workhorse  6.1.1+debian-3
ii  lsb-base  9.20170808
ii  nginx 1.14.1-1
ii  nginx-full [nginx]1.14.1-1
ii  nodejs8.11.2~dfsg-1
ii  npm   5.8.0+ds6-2
ii  openssh-client1:7.9p1-4
ii  postfix [mail-transport-agent]3.3.1-1+b1
ii  postgresql-client 11+197
ii  postgresql-client-10 [postgresql-client]  10.5-1
ii  postgresql-client-11 [postgresql-client]  11.1-1+b2
ii  postgresql-contrib11+197
ii  rake  12.3.1-3
ii  redis-server  5:5.0.2-1
ii  ruby  1:2.5.1
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-acts-as-taggable-on  5.0.0-2
ii  ruby-addressable  2.5.2-1
ii  ruby-akismet  2.0.0-1
ii  ruby-arel 6.0.4-1
ii  ruby-asana0.6.0-1
ii  ruby-asciidoctor-plantuml 0.0.8-1
ii  ruby-asset-sync   2.4.0-1
ii  ruby-attr-encrypted   3.1.0-1
ii  ruby-babosa 

Bug#915051: initscripts: conffiles not removed

[Paul Wise]

Package: initscripts
Version: 2.92~beta-2
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=initscripts ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | 
grep obsolete
initscripts: obsolete-conffile /etc/init.d/motd
 /etc/init.d/motd dbc3f882af04254005bb96e4f780e5a0 obsolete

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

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

Versions of packages initscripts depends on:
ii  coreutils   8.30-1
ii  debianutils 4.8.6
ii  lsb-base9.20170808
ii  mount   2.32.1-0.1
ii  sysv-rc 2.92~beta-2
ii  sysvinit-utils  2.92~beta-2

Versions of packages initscripts recommends:
ii  e2fsprogs  1.44.4-2
ii  psmisc 23.2-1

initscripts suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#915052: nmu: libpar-packer-perl_1

[Dominic Hargreaves]

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

As is usual for a patch release of perl, we need to binnmu a small
number of packages:

nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl 
libcommon-sense-perl . ANY . -m "Rebuild against perlapi-5.28.1." 
--extra-depends 'perl-base (>= 5.28.1)'

Thanks!
Dominic.

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

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

Bug#915008:

[Maarten]

see also: https://bugzilla.kernel.org/show_bug.cgi?id=201813

Bug#915050: Keep out of testing

[Moritz Muehlenhoff]

Source: gitlab
Severity: serious

Gitlab is too fast-moving with weekly releases and backporting security fixes 
has already
failed us for stretch, keep it out of testing.

To meaningfully support it for use on stable, this would require some of the
infrastructure/policy changes discussed in the "What can Debian do to provide
complex applications to its users" thread from earlier the year on debian-devel.

Cheers,
Moritz

Bug#868563: apparmor-profiles: Apparmor profiles for postfix programs have incorrect path

[intrigeri]

Julian Andres Klode:
> It needs some more changes, I'll try to get them fixed up
> this weekend, so I can roll out my server in enforced mode.
> It will be based on Ubuntu 18.04, though, so might need double
> checking.

Great!

Bug#915044: shibboleth-resolver FTBFS with new log4shib/xmltooling/shibboleth-sp stack

[Cantor, Scott]

The resolver library upstream has already been updated to reflect all these 
necessary changes so you're just duplicating that work.

-- Scott

Bug#915049: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled

[Dan Streetman]

Package: systemd
Version: 239-14
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This 
makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP 
returns a truncated reply for a new TCP query. For instance,

- If the client supports EDNS:

$ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
30

- If the client does not support EDNS:

$ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l
29

In the second case, no-EDNS, TCP should provide the complete answer, but it's 
capped at UDP's size.

This leads to complete failures for common dns lookups, e.g.:

telnet testing.irongiantdesign.com
telnet: could not resolve testing.irongiantdesign.com/telnet: Temporary failure 
in name resolution

-- Package-specific info:


Ubuntu bug for this is LP: #1804487
https://bugs.launchpad.net/systemd/+bug/1804487

upstream systemd bug is 10816
https://github.com/systemd/systemd/issues/10816

This was debugged and fixed upstream by Victor Tapia.

Thanks for considering the patch.


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

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

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.131ubuntu15
ii  udev 239-7ubuntu10.4
diff -Nru 
systemd-239/debian/patches/debian/increase-TCP-stub-payload-size.patch 
systemd-239/debian/patches/debian/increase-TCP-stub-payload-size.patch
--- systemd-239/debian/patches/debian/increase-TCP-stub-payload-size.patch  
1969-12-31 19:00:00.0 -0500
+++ systemd-239/debian/patches/debian/increase-TCP-stub-payload-size.patch  
2018-11-29 09:42:01.0 -0500
@@ -0,0 +1,34 @@
+commit e6eed9445956cfa496e1db933bfd3530db23bfce
+Author: Victor Tapia 
+Date:   Wed Nov 21 14:01:04 2018 +0100
+
+resolved: Increase size of TCP stub replies
+
+DNS_PACKET_PAYLOAD_SIZE_MAX is limiting the size of the stub replies to
+512 with EDNS off or 4096 with EDNS on, without checking the protocol
+used. This makes TCP replies for clients without EDNS support to be
+limited to 512, making the truncate flag useless if the query result is
+bigger than 512 bytes.
+
+This commit increases the size of TCP replies to DNS_PACKET_SIZE_MAX
+
+Fixes: #10816
+
+--- a/src/resolve/resolved-dns-packet.h
 b/src/resolve/resolved-dns-packet.h
+@@ -120,11 +120,14 @@
+ 
+ static inline uint16_t DNS_PACKET_PAYLOAD_SIZE_MAX(DnsPacket *p) {
+ 
+-/* Returns the advertised maximum datagram size for replies, or the 
DNS default if there's nothing defined. */
++/* Returns the advertised maximum size for replies, or the DNS 
default if there's nothing defined. */
+ 
+ if (p->opt)
+ return MAX(DNS_PACKET_UNICAST_SIZE_MAX, p->opt->key->class);
+ 
++if (p->ipproto == IPPROTO_TCP)
++return DNS_PACKET_SIZE_MAX;
++
+ return DNS_PACKET_UNICAST_SIZE_MAX;
+ }
+ 
diff -Nru systemd-239/debian/patches/series systemd-239/debian/patches/series
--- systemd-239/debian/patches/series   2018-11-20 13:44:39.0 -0500
+++ systemd-239/debian/patches/series   2018-11-29 09:42:01.0 -0500
@@ -52,3 +52,4 @@
 debian/Revert-udev-rules-Permission-changes-for-dev-dri-renderD.patch
 debian/Revert-systemctl-when-removing-enablement-or-mask-symlink.patch
 debian/Drop-seccomp-system-call-filter-for-udev.patch
+debian/increase-TCP-stub-payload-size.patch

Bug#915048:

[Linear J]

Package: evolution
Version: 3.22.6-1+deb9u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I ran apt-get update ; apt-get upgrade

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Nothing works. I can no longer start evoluion
   * What was the outcome of this action?
hamilton ~ [9] evolution
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".

(evolution:3034): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL'
failed
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".
Xlib:  extension "RANDR" missing on display ":0.0".

(evolution:3034): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL'
failed
[1]3034 segmentation fault  evolution

   * What outcome did you expect instead?
I expected evolution to start

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


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

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

Versions of packages evolution depends on:
ii  dbus   1.10.26-0+deb9u1
ii  evolution-common   3.22.6-1+deb9u1
ii  evolution-data-server  3.22.7-1
ii  libc6  2.24-11+deb9u3
ii  libcamel-1.2-593.22.7-1
ii  libclutter-gtk-1.0-0   1.8.2-2
ii  libecal-1.2-19 3.22.7-1
ii  libedataserver-1.2-22  3.22.7-1
ii  libevolution   3.22.6-1+deb9u1
ii  libglib2.0-0   2.50.3-2
ii  libgtk-3-0 3.22.11-1
ii  libical2   2.0.0-0.5+b1
ii  libicu57   57.1-6+deb9u2
ii  libnotify4 0.7.7-2
ii  libsoup2.4-1   2.56.0-2+deb9u2
ii  libwebkit2gtk-4.0-37   2.16.6-0+deb9u1
ii  libxml22.9.4+dfsg1-2.2+deb9u2
ii  psmisc 22.21-2.1+b2

Versions of packages evolution recommends:
ii  bogofilter 1.2.4+dfsg1-9
ii  evolution-plugins  3.22.6-1+deb9u1
ii  yelp   3.22.0-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.1.18-8~deb9u3
pn  network-manager 

-- no debconf information

Bug#914897: affects private debs too

[Ansgar Burchardt]

Simon McVittie writes:
> On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote:
>> Regardless of debootstrap defaults or flag days, we could also consider
>> moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
>> /{s,}bin
>
> I'm not convinced this is a good idea: it seems like it causes as many
> problems as it solves. It's effectively a gradual implementation of
> making merged /usr mandatory, with a lot of moving parts (places where
> it could go wrong) and a lot of packages and maintainers needing to be
> involved, but without the simpler end result of *actually* merging /usr.

Well, people don't like the simpler solution that someone else
proposed...

> We've been migrating from non-multiarch to multiarch for more than 5
> years and have still not got there, so I'm not confident that ad-hoc
> migration from unmerged to merged /usr would go any quicker.

Migrating /{s,}bin involves far fewer packages (only ~200 binary
packages).  There is still /lib though.

> It can also cause the same failure modes with hard-coded executable paths
> as merged /usr. Let's suppose we migrated grep from /bin to /usr/bin in
> the way you suggest during the Debian 11 release cycle. If a package that
> hard-codes the compile-time grep path (again, consider gzip, #914907)
> is built with the new grep, it won't work correctly with the old grep
> during a partial upgrade from Debian 10 to 11; but I don't see how it
> would pick up a versioned Depends on the new grep without manual action
> from the dependent package's maintainer, which isn't going to scale well.

You will always have this problem with partial upgrades unless *every*
package depends on a package that would ensure that the system has all
binaries previously in /bin also in /usr/bin.

In particular, if we want to treat this as a (release critical) bug,
iptables or any other package ever moving from /bin to /usr/bin (or the
other way) will always be buggy, regardless of any merged-/usr.  Same
for any binary ever moving between .../bin and .../sbin.

Ansgar

Bug#914999: [libc6] Locking problems into libc6

[Aurelien Jarno]

control: tag -1 + moreinfo

Hi,

On 2018-11-29 13:58, Roman Savochenko wrote:
> Package: libc6
> Version: 2.24
> Severity: critical
> 
> --- Please enter the report below this line. ---
> I have got already more signs of a problem into locking access to functions
> like to getaddrinfo(), by the macro __libc_lock_lock, which reproduced in
> multithreaded environments!
> 
> 1. For my program, I was needed to create extra locking about the function
> getaddrinfo(), but that resolved the problem only for my calls but for the
> external libraries like to MySQL, MariaDB I yet have the crashes and it
> cannot be fixed at all.

Can you give more details about the issue, the symptoms, possible crash
backtrace, way to reproduce it. Without this details, there are very few
chances to be able to fix the bug.

> 2. rtl8192eu by the driver rtl8xxxu, or the external one 8192eu.ko, does not
> connect to any network with that messages into dmesg:
> [  137.936642] wlx000f0064f2d8: authenticate with 00:90:4c:08:00:0d
> [  137.940680] wlx000f0064f2d8: send auth to 00:90:4c:08:00:0d (try 1/3)
> [  138.145146] wlx000f0064f2d8: send auth to 00:90:4c:08:00:0d (try 2/3)
> [  138.353198] wlx000f0064f2d8: send auth to 00:90:4c:08:00:0d (try 3/3)
> [  138.557239] wlx000f0064f2d8: authentication with 00:90:4c:08:00:0d timed
> out

glibc is not involved at all in the wireless driver, so I don't see the
relation with the previous issue.

> 3. Impossible to connect to any WLan HotSpot (Ad-hoc), for me it is Nokia N9

Without more details, I also fail to see the relation with glibc here.

> All those issues fine fork on two Debian 8 installations with the libc6
> 2.19, where one on the same hardware as Debian 9.
> Other Debian 9 installation on the stationary PC also does not work for the
> second issue.
> Initially I heve counted it is kernel problems but I have installed this
> same Linux kernel version on Debian 8 and these all work there.

There are thousands of packages in different versions between Debian 8
and Debian 9. You have found it's not related to the kernel, but I fail
to see how that shows it's a libc6 issue. For example when you have
tried the kernel from Debian 9 in Debian 8, have you also tried with the
rtl8192 firmware from Debian 9?

Anyway if we want to know that the problem is related with glibc, please
try to install glibc packages (libc*, possibly locales* and nscd if
needed) from Debian 9 onto a working Debian 8 installation and see if
the problem appears.

Without more information, there is no way for us to fix the bug, so
we'll just have to close it.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#915047: darktable: please pass -DRAWSPEED_ENABLE_LTO=ON to cmake to enable partial LTO

[Roman Lebedev]

Package: darktable
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Submitted patch at 
https://salsa.debian.org/debian-phototools-team/darktable/merge_requests/2
As recommended, also filing a bug for this.

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

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

Versions of packages darktable depends on:
ii  libc62.27-8
ii  libcairo21.16.0-1
ii  libcolord-gtk1   0.1.26-2
ii  libcolord2   1.4.3-3+b1
ii  libcups2 2.2.9-2
ii  libcurl3-gnutls  7.62.0-1
ii  libexiv2-14  0.25-4
ii  libflickcurl01.26-4
ii  libgcc1  1:8.2.0-10
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgomp1 8.2.0-10
ii  libgphoto2-6 2.5.20-3
ii  libgphoto2-port122.5.20-3
ii  libgraphicsmagick-q16-3  1.3.31-1
ii  libgtk-3-0   3.24.1-2
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
pn  libjs-prototype  
pn  libjs-scriptaculous  
ii  libjson-glib-1.0-0   1.4.4-1
ii  liblcms2-2   2.9-3
ii  liblensfun1  0.3.2-4
ii  liblua5.3-0  5.3.3-1
ii  libopenexr23 2.2.1-4
ii  libopenjp2-7 2.3.0-1
ii  libosmgpsmap-1.0-1   1.1.0-5
ii  libpango-1.0-0   1.42.4-4
ii  libpangocairo-1.0-0  1.42.4-4
ii  libpng16-16  1.6.34-2
ii  libpugixml1v51.9-2
ii  librsvg2-2   2.44.9-1
ii  libsecret-1-00.18.6-3
ii  libsoup2.4-1 2.64.2-1
ii  libsqlite3-0 3.25.3-2
ii  libstdc++6   8.2.0-10
ii  libtiff5 4.0.10-3
ii  libwebp6 0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libxml2  2.9.4+dfsg1-7+b2
ii  libxrandr2   2:1.5.1-1
ii  zlib1g   1:1.2.11.dfsg-1

darktable recommends no packages.

darktable suggests no packages.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAlwAOKgACgkQCDw+u0oW
ieBeOw//bn5GGZAFaFWGBZRu1wKdhnWbojO3dhshvT1uLgNAbdbWocBZnO/j7Byb
ac65ZHeZ2cYWfqtfSV5vGxLpljORpFqReebXVciMJbWnmuC8GsgTebIugEn4sHGw
pMPTHZR0QrI02kiRNWK0nDR20ppfsfCPq2kCksYGECLlm17oAOtKG+VN2rbz3BrO
oakap3wzkE2G8vHB34p0pu3r3kU73SvU5c0CuZwJVougwqpl7Lz6+8hLhH0oL8wF
efoQUlF2Vyb8XK4ZoSvMKyMTjOq/bv4V+/aPgSzMO7uw9efdZfaz65ijTdOxEXya
o00Q0vIZ1Ko1NCyMMr4LU0bQ6RbeUFITFH7SadrIANWcccU9rqub1SluZBxpwz6B
tC5gfvOJAKnW5nX4ggIz4KcHauacdpc4lHtflDB1ys1jmXrmjrZbEu4UM9qHXbfq
w4dugEmxZZ0lqYhZhQnlpGrZ+TyQleDxW9AEsiSZZvog89kaXligN6KIp4rXrSOX
kA8jqEXlosGe1ul/oIe73OUvxxIEMehzLaLqELiziswPE2Bo5HeVXZNWSzqOJU9G
6SFhDG3lXpo7ThzsN956A32yL5g/svl7RjAL7GzkgzQ5UZTYPR+cxdSCRsO45kV2
h1TuO9Gdx9kyLYtBWd2l+PQyniw0+FpyhmV2xAbSc+ANiFZ6tz0=
=Y0XH
-END PGP SIGNATURE-

Bug#868563: apparmor-profiles: Apparmor profiles for postfix programs have incorrect path

[Julian Andres Klode]

On Mon, Jan 29, 2018 at 12:03:02PM +0100, intrigeri wrote:
> Hi,
> 
> the preferred way to fix this nowadays is to fork
> https://gitlab.com/apparmor/apparmor, edit files in
> profiles/apparmor/profiles/extras, commit, push a branch and follow
> the instructions that `git push' will provide to submit
> a merge request.
> 
> I guess that replacing all relevant occurrences of:
> 
>   /usr/lib/postfix
> 
> with:
> 
>   /usr/lib/postfix{,/sbin}
> 
> … should to the trick :)

It needs some more changes, I'll try to get them fixed up
this weekend, so I can roll out my server in enforced mode.
It will be based on Ubuntu 18.04, though, so might need double
checking.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#915046: mariadb-10.3: Please build with -latomic where necessary

[John Paul Adrian Glaubitz]

Source: mariadb-10.3
Version: 1:10.1.37-1
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc

Hello!

On some 32-bit targets like mips or powerpc, the mariabdb-10.3 build fails
with:

 error: #error atomic ops for this platform are not implemented

This is because the test for C++11 atomics in configure.cmake fails:

CHECK_CXX_SOURCE_COMPILES("
 int main()
 {
  long long int var= 1;
  long long int *ptr= 
  return (int)__atomic_load_n(ptr, __ATOMIC_SEQ_CST);
 }"
HAVE_GCC_C11_ATOMICS)

Trying to build this code on ppc64 works fine:

glaubitz@redpanda:~/mariadb$ g++ cpp11test.cpp -o cpp11test
glaubitz@redpanda:~/mariadb$ ./cpp11test

On powerpc, we need -latomic otherwise the compilation fails
and HAVE_GCC_C11_ATOMICS is set to false:

root@kapitsa:~# g++ cpp11test.cpp -o cpp11test
/usr/bin/ld: /tmp/ccyivhlO.o: in function `main':
cpp11test.cpp:(.text+0x48): undefined reference to `__atomic_load_8'
collect2: error: ld returned 1 exit status
root@kapitsa:~#

root@kapitsa:~# g++ cpp11test.cpp -o cpp11test -latomic
root@kapitsa:~#

I have no idea, however, how to tell cmake here to pass -latomic, I'm
not a cmake expert.

Adrian

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

Bug#915044: shibboleth-resolver FTBFS with new log4shib/xmltooling/shibboleth-sp stack

[peter green]

Package: shibboleth-resolver
Severity: serious
Version: 1.0.0-1
Tags: sid, patch

shibboleth-resolver FTBFS, there are three issues.

Firstly it fails to find log4shib because it tries to use log4shib-config which 
no longer exists. I patched configure.ac to use pkg-config instead and enabled 
autoreconf in the dh sequence.

Secondly xsecsize_t no longer seems to exist, I replaced it with XMLSize_t

Thirdly it seems deprecated wrappers for createResolutionContext and extractAttributes 
wrapper were removed. The wrappers passed the call on to the still-existing version of 
the functions setting the "request" parameter to nullptr. So I simply set the 
request parameter to nullptr in the call

I have uploaded my fix to raspbian, a debdiff can be found at 
http://debdiffs.raspbian.org/main/s/shibboleth-resolver/shibboleth-resolver_1.0.0-1+rpi2.debdiff
 . No intent to NMU in Debian.

Bug#915045: python-socketio/2.1.0-1 [QA]

[Paulo Henrique de Lima Santana]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: mike.gabr...@das-netzwerkteam.de

Hi, 

Please **don't sponsor and upload** this package because my AM (Mike Gabriel)
will review it for me.

 * Package name: python-socketio
   Version : 2.1.0-1
   Upstream Author : Miguel Grinberg 
 * URL : https://github.com/miguelgrinberg/python-socketio
 * License : MIT
   Section : python

It builds this binary package:

  python3-socketio-realtime-server - Python implementation of the Socket.IO
realtime server

To access further information about these packages, please visit the
following URL:

https://mentors.debian.net/sponsors/rfs-howto/python-socketio

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-socketio/python-socketio_2.1.0-1.dsc

More information about kickpass can be obtained from
https://github.com/miguelgrinberg/python-socketio

Best regards,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
http://www.heforshe.org/pt


pgp4hJtq1qsEH.pgp
Description: PGP signature

Bug#915043: nikto: missing build on all

[Eriberto]

Em qui, 29 de nov de 2018 às 16:56, Vincent Bernat  escreveu:
>
>  ❦ 29 novembre 2018 16:51 -0200, Eriberto Mota :
>
> > I've prepared an NMU for nikto (versioned as 1:2.1.5-3.1) and
> > uploaded it to DELAYED/10. Please feel free to tell me if I
> > should delay it longer.
>
> Thanks. You can upload it right now if you want.

Thanks! I will do it.

Cheers,

Eriberto

Bug#915043: nikto: missing build on all

[Vincent Bernat]

 ❦ 29 novembre 2018 16:51 -0200, Eriberto Mota :

> I've prepared an NMU for nikto (versioned as 1:2.1.5-3.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.

Thanks. You can upload it right now if you want.
-- 
What I tell you three times is true.
-- Lewis Carroll


signature.asc
Description: PGP signature

Bug#915043: nikto: missing build on all

[Eriberto Mota]

Control: tags 915043 + patch
Control: tags 915043 + pending

Dear maintainer,

I've prepared an NMU for nikto (versioned as 1:2.1.5-3.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

Eriberto

Bug#914944: [pkg-gnupg-maint] Bug#914944: gnupg: importing a key fails when there's no tty (regression from 2.1.18-8~deb9u2)

[Daniel Kahn Gillmor]

Control: forcemerge 913614 914944

Thanks for noting this, Lucas.

On Thu 2018-11-29 00:12:05 +0100, Lucas Nussbaum wrote:
> Importing the attached key fails when there's no tty.

This is the same as #913614, merging.

Note that #914032 proposes an update to stretch that fixes this
regression.  I've seen no feedback on #914032 yet, though.

--dkg


signature.asc
Description: PGP signature

Bug#915043: nikto: missing build on all

[Joao Eriberto Mota Filho]

Package: nikto
Version: 1:2.1.5-3
Severity: grave
Justification: renders package unusable

Dear maintainer,

nikto do not migrated to testing and remains in unstable. The 'excuses' are:

Excuse for nikto

180 old (needed 33 days)
missing build on all: nikto (from 1:2.1.5-2)

The buildd says:

No entry in all database, check Packages-arch-specific

I think that nikto needs a re-upload to migrate to testing.

Regards,

Eriberto


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