Bug#892982: bugs.debian.org: system freeze after lock screen/switched off moniturs/spontaneously

[Salve Mundus]

Hello,

I'm sorry,  it seems I have mixed up the receiver of this bug report. 
Is it possible to move this bug to the correct list?  Or should I
recreate it?


Kind Regards
  Hermann

Bug#892982: bugs.debian.org: system freeze after lock screen/switched off moniturs/spontaneously

[Hermann Lorenz]

Package: bugs.debian.org
Severity: important
Tags: upstream

Dear Maintainers,

because the kernel logs show clock errors for amdgpu and segfaults in the gnome
shell, I'm not sure which package I have to refer to.  Please feel free to ask
for other log files or hardware configurations that might be of interest to
you.


First Scenario
==

I observed several freezes of my system in October/November.  They occured,
when
 * the screen was locked or
 * when the monitors were switched off.
The screen froze not every time, but in the majority of the times I did this.
Over the last months I "solved" this issue by not locking the screen or turning
off the monitors while the system was running.  During this time I did not
observe any freezes like this.  Yesterday I switched off the monitors and when
I returned, I observed a freezing of the system again.

The follwing actions did not seem to have any effect:

 * on mouse movement, the cursor does not move
 * Ctrl+Shift+F3 doesn't switch to a terminal
 * Ctrl+Shift+Del holding for 10+ seconds does not reboot.

I missed to do press Alt+Print+K, next time I will test this too.

The only solution to recover is to press the power button on the tower for
several seconds and to reboot the system.


Here a short excerpt from /var/log/kern.log from yesterday:

Mar 14 10:19:24 mundus kernel: [ 5483.172863]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery tried 5
times
Mar 14 10:19:24 mundus kernel: [ 5483.172879]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:44:50 mundus kernel: [14209.555905] gnome-shell[1254]: segfault
at 38 ip 7ff9ec3f8f70 sp 7ffe1cf6aaf8 error 4 in
libmutter-1.so.0.0.0[7ff9ec398000+15]
Mar 14 12:44:51 mundus kernel: [14209.583537] rfkill: input handler enabled
Mar 14 12:44:51 mundus kernel: [14209.755875]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status
failed
Mar 14 12:44:51 mundus kernel: [14209.755896]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:44:51 mundus kernel: [14209.932953]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status
failed
Mar 14 12:44:51 mundus kernel: [14209.932973]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:44:51 mundus kernel: [14210.120708]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status
failed
Mar 14 12:44:51 mundus kernel: [14210.120728]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:44:51 mundus kernel: [14210.297755]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status
failed
Mar 14 12:44:51 mundus kernel: [14210.297774]
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
Mar 14 12:53:19 mundus kernel: [14718.348671] rfkill: input handler
disabled
Mar 14 13:43:18 mundus kernel: [17716.735394] gnome-shell[14938]: segfault
at 55ba0af83c18 ip 7fb6aebe2676 sp 7ffda3cf9020 error 4 in
libst-1.0.so[7fb6aebc2000+4d000]
Mar 14 13:43:18 mundus kernel: [17716.783243] rfkill: input handler enabled
Mar 14 13:43:25 mundus kernel: [17723.744111] rfkill: input handler
disabled




Second Scenario
===

Because in this second scenario the behaviour is different, I was not sure if
it is relevant to you.  But since it also results in a reset of the user
session, I wanted to mention it.

The screen freezes during normal usage at random.  This happens every two or
three days.  After let's say 30 seconds the log in screen is shown and a new
session is started.  This also occured during the phase when I did not lock the
screen.

Again a short excerpt from /var/log/kern.log regarding the second scenario:

Mar 15 05:35:32 mundus kernel: [ 2026.148912] show_signal_msg: 17 callbacks
suppressed
Mar 15 05:35:32 mundus kernel: [ 2026.148914] gnome-shell[1257]: segfault
at 562055805a68 ip 7fbae1b7b676 sp 7fff83108b90 error 4 in
libst-1.0.so[7fbae1b5b000+4d000]
Mar 15 05:35:32 mundus kernel: [ 2026.195608] rfkill: input handler enabled
Mar 15 05:35:39 mundus kernel: [ 2033.100377] rfkill: input handler
disabled

In this specific case I was moving a window via Super+Shift+Left from one
monitor to another when the GUI crashed.  After logging in I was able to use
the system as normal.



Kind Regards
  Hermann



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

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

Bug#756811: src:nspr: add support for OpenRISC 1000 (or1k)

[Christian Svensson]

Lol. Only 4 years later :D

On Mar 14, 2018 23:08, "Manuel A. Fernandez Montecelo" <
manuel.montez...@gmail.com> wrote:

Control: close -1


Hi Christian!

2014-08-01 23:16 Christian Svensson:

> Package: src:nspr
> Version: 4.10.6-1
> Severity: wishlist
> Tags: upstream patch
>
> Dear Maintainer,
>
> The attached patch adds support for the upcoming Debian architecture
> OpenRISC (or1k).
>

Support was added in upstream back in 2015, and the port is no longer
under development, so I guess that we can close the bug report now :)


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#892956: libinput-dev: Requires.private without package dependencies breaks pkg-config users

[Timo Aaltonen]

On 14.03.2018 22:25, Adrian Bunk wrote:
> Package: libinput-dev
> Version: 1.10.3-1
> Severity: grave
> Control: affects -1 src:efl src:gnome-twitch src:muffin src:mutter 
> src:gnome-shell
> 
> https://buildd.debian.org/status/package.php?p=efl&suite=sid
> 
> ...
> configure: error: pkg-config missing libinput >= 0.6.0 xkbcommon >= 0.3.0 
> libudev
> 
> 
> Root cause are the new dependencies in Requires.private
> without package dependencies:
> 
> $ pkg-config --cflags  libinput
> Package libwacom was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libwacom.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libwacom', required by 'libinput', not found

1.10.2-1 didn't have them, and nothing changed in 1.10.3 that would
result in this, so the culprit is elsewhere. Where did that
"Requires.private" come from?


-- 
t

Bug#892943: yash: FTBFS: test prompt-y.tst fails

[TANIGUCHI Takaki]

Hi,

I can not reproduce that error on my environment(locally and pbuilder).

Could you please send more information?

> On Wed, 14 Mar 2018 19:24:39 +0100
> svenj...@gmx.de(Sven Joachim)  said:
>
> [1  ]
> Source: yash
> Version: 2.46-1
>
> On my system, the test prompt-y.tst fails reproducibly on both i386 and
> amd64, although it apparently succeeds (or is skipped) on the buildds.
> Attached is the summary.log file describing the problem.
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (101, 'experimental')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
>
> Kernel: Linux 4.15.9-nouveau (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> [2 summary.log ]
> Linux turtle 4.15.9-nouveau #1 SMP Sun Mar 11 17:49:12 CET 2018 x86_64 
> GNU/Linux
> Wed Mar 14 19:21:58 CET 2018
> =
>
> %%% START: prompt-y.tst:157: \j in PS1 and -b option
> % standard error diff:
> --- - 2018-03-14 19:21:53.995351857 +0100
> +++ 157.err   2018-03-14 19:21:53.988131643 +0100
> @@ -1,6 +1,5 @@
>  $
>  0$[1] + Running  exec 1>fifo
>
> -1$[1] + Done exec 1>fifo
> -0$
> +1$1$
>  0$
>
> %%% FAILED: prompt-y.tst:157: \j in PS1 and -b option
>
> %%% SKIPPED: prompt-y.tst:179: \$ in PS1 and PS2 (root)
>
> %%% SKIPPED: prompt-y.tst:231: default prompt strings (POSIX, root)
>
> =
> TOTAL:   3915
> PASSED:  3912
> FAILED: 1
> SKIPPED:2
> =
--
谷口 貴紀 (TANIGUCHI Takaki) tak...@asis.media-as.org
http://takaki-web.media-as.org/ tak...@debian.org


pgpIdFIl0EybA.pgp
Description: OpenPGP Digital Signature

Bug#892981: cenon.app: Incomplete debian/copyright?

[Chris Lamb]

Source: cenon.app
Version: 4.0.6+ds1-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Yavor Doganov 

Hi,

I just ACCEPTed cenon.app from NEW but noticed it was missing 
attribution in debian/copyright for at least Adobe Systems,
NeXT, vhf interservice GmbH, GraphiCode, etc.

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

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

Bug#892980: gnome-themes-extra: Incomplete debian/copyright?

[Chris Lamb]

Source: gnome-themes-extra
Version: 3.27.92-1
Severity: serious
Justication: Policy 12.5

Hi,

I just ACCEPTed gnome-themes-extra from NEW but noticed it was 
missing attribution in debian/copyright for at least adwaita_engine.c
under themes/Adwaita/gtk-2.0.


(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

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

Bug#892979: FLTKConfig.cmake: self-conflicting add_executable(fluid IMPORTED)

[Helmut Grohne]

Package: libfltk1.3-dev
Version: 1.3.4-6
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:yoshimi

yoshimi fails to cross build from source. The relevant part of the build
failure looks like this:

| CMake Error at /usr/lib/fltk/FLTKConfig.cmake:32 (add_executable):
|   add_executable cannot create imported target "fluid" because another target
|   with the same name already exists.
| Call Stack (most recent call first):
|   /usr/share/cmake-3.10/Modules/FindFLTK.cmake:136 (include)
|   CMakeLists.txt:244 (find_package)

As it happens libfltk1.3-dev ships add_executable(fluid IMPORTED) twice.
Once in /usr/lib/fltk/FLTKConfig.cmake:32 and another time in
/usr/lib/fltk/FLTK-Targets.cmake:59. They should somehow agree on who
adds it. Potentially, the whole "if(CMAKE_CROSSCOMPILING)" block in
FLTKConfig.cmake is completely untested and should be discarded in
favour of the native way. Unfortunately, I understand too little CMake
to fix this, so this bug report sadly comes without a patch. Can you
help me find a solution?

In any case, this constellation of add_executable is a pretty obvious
bug, because FLTKConfig.cmake includes FLTK-Targets.cmake. It just isn't
obvious how to fix it.

Helmut

Bug#892651: Bug#892794: systemd-networkd fails to configure IPv6 without MTU from RA

[Russ Allbery]

Cyril Brulebois  writes:

> I've put up an amd64 build for stretch here:
>   https://people.debian.org/~kibi/systemd/

> along with the source package. I'm also attaching the source debdiff.

> I'm not tagging this bug report with +patch yet, as this needs to be
> tested on networks with and without advertised MTU (in case that doesn't
> work in the latter case, reverting the commit introduced in the 9.4
> point release might be just as good…).

Thank you!  I've built this for one of my systems where I was having this
problem and upgraded systemd, libsystemd0, libpam-systemd, and
libnss-resolve to the updated version.  I can confirm that IPv6 is still
working fine on that system on a network that doesn't advertise an MTU,
and I'm not seeing the errors in my logs.

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

Bug#883636: stretch update for showq

[Jaromír Mikeš]

On Wed, Mar 14, 2018, 6:47 PM Adrian Bunk  wrote:

> On Tue, Jan 02, 2018 at 05:36:06PM +, Debian Bug Tracking System wrote:
> >...
> >  showq (0.4.1+git20161215~dfsg0-3) unstable; urgency=medium
> >...
> >* Hack prefix to get app started. (Closes: #883636)
> >  Thanks to James Cowgill 
> >...
>
> Thanks a lot for fixing this bug for unstable.
>
> It is still present in stretch, could you also fix it there?
> Alternatively, I can fix it for stretch if you don't object.
>

Please go ahead. I don't object.

best

mira

>

Bug#891922: RFS: you-get/0.4.1040-1 [ITP]

[Paul Wise]

On Sat, Mar 3, 2018 at 1:46 AM, Alex Mestiashvili wrote:

> It would be interesting to see how this program is different from
> already existing tools like youtube-dl and cclive.

There are a lot of different tools in this space:

https://wiki.debian.org/MultimediaFetchingTools

They are complementary, when one breaks, another often works. Each of
them supports a different set of sites, so if one doesn't support one
site, one of the others probably will.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#892651: Bug#892794: systemd-networkd fails to configure IPv6 without MTU from RA

[Cyril Brulebois]

Hello Russ & Marc,

Cyril Brulebois  (2018-03-14):
> Russ Allbery  (2018-03-12):
[…]
> Yeah, that seems very likely… Even if the word regression or the commit
> ID doesn't appear in the commit message, the follow-up commit seems to
> fix this specific issue:
> 
> commit 29b5ad083a6925efec8e188013d1298742e0baaa
> Author: Jörg Thalheim 
> Date:   Mon Dec 19 15:34:07 2016 +0100
> 
> networkd-ndisc: handle missing mtu gracefully (#4913)
> 
> At least bird's implementation of router advertisement does not
> set MTU option by default (instead it supplies an option to the user).
> In this case just leave MTU as it is.
> 
>  → 
> https://github.com/systemd/systemd/commit/29b5ad083a6925efec8e188013d1298742e0baaa
> 
> Regarding the other pair of functions getting the return code checked
> (sd_netlink_message_open_container & sd_netlink_message_close_container)
> there doesn't seem to be any follow-up commits touching that file in
> these areas… I'm not sure netlink operations are likely to fail anyway
> (except for ENOMEM situations), so that's probably fine?
> 
> > It's possible that this means the local IPv6 routing environment is
> > not correctly configured, but since this change was made in a stable
> > update and IPv6 was working perfectly prior to this change, it still
> > feels like a relatively serious regression to me.
> 
> Definitely, sorry for having proposed that commit without spotting it.
> 
> I can build a patched systemd with this extra cherry-pick for you to
> double check; I'll post a link once it's available.

I've put up an amd64 build for stretch here:
  https://people.debian.org/~kibi/systemd/

along with the source package. I'm also attaching the source debdiff.

I'm not tagging this bug report with +patch yet, as this needs to be
tested on networks with and without advertised MTU (in case that doesn't
work in the latter case, reverting the commit introduced in the 9.4
point release might be just as good…).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru systemd-232/debian/changelog systemd-232/debian/changelog
--- systemd-232/debian/changelog	2017-12-03 15:03:50.0 +0100
+++ systemd-232/debian/changelog	2018-03-15 05:00:23.0 +0100
@@ -1,3 +1,11 @@
+systemd (232-25+deb9u3) UNRELEASED; urgency=medium
+
+  * networkd-ndisc: handle missing mtu gracefully (Closes: #892794). The
+previous upload made networkd respect the MTU field in IPv6 RA but
+unfortunately broke setups where there's no such field.
+
+ -- Cyril Brulebois   Thu, 15 Mar 2018 05:00:23 +0100
+
 systemd (232-25+deb9u2) stretch; urgency=medium
 
   * networkd: Handle MTU field in IPv6 RA (Closes: #878162)
diff -Nru systemd-232/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch systemd-232/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch
--- systemd-232/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch	1970-01-01 01:00:00.0 +0100
+++ systemd-232/debian/patches/networkd-ndisc-handle-missing-mtu-gracefully-4913.patch	2018-03-15 04:56:05.0 +0100
@@ -0,0 +1,30 @@
+From 29b5ad083a6925efec8e188013d1298742e0baaa Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= 
+Date: Mon, 19 Dec 2016 15:34:07 +0100
+Subject: [PATCH] networkd-ndisc: handle missing mtu gracefully (#4913)
+
+At least bird's implementation of router advertisement does not
+set MTU option by default (instead it supplies an option to the user).
+In this case just leave MTU as it is.
+---
+ src/network/networkd-ndisc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/src/network/networkd-ndisc.c b/src/network/networkd-ndisc.c
+index 5320592f7..5097ab9d7 100644
+--- a/src/network/networkd-ndisc.c
 b/src/network/networkd-ndisc.c
+@@ -118,7 +118,9 @@ static void ndisc_router_process_default(Link *link, sd_ndisc_router *rt) {
+ }
+ 
+ r = sd_ndisc_router_get_mtu(rt, &mtu);
+-if (r < 0) {
++if (r == -ENODATA)
++mtu = 0;
++else if (r < 0) {
+ log_link_warning_errno(link, r, "Failed to get default router MTU from RA: %m");
+ return;
+ }
+-- 
+2.11.0
+
diff -Nru systemd-232/debian/patches/series systemd-232/debian/patches/series
--- systemd-232/debian/patches/series	2017-12-03 15:03:50.0 +0100
+++ systemd-232/debian/patches/series	2018-03-15 04:56:48.0 +0100
@@ -75,6 +75,7 @@
 main-improve-RLIMIT_NOFILE-handling-5795.patch
 cryptsetup-generator-run-cryptsetup-service-before-swap-u.patch
 networkd-handle-MTU-field-in-IPv6-RA-4719.patch
+networkd-ndisc-handle-missing-mtu-gracefully-4913.patch
 shared-Add-a-linker-script-so-that-all-functions-are-tagg.patch
 resolved-fix-loop-on-packets-with-pseudo-dns-types.patch
 machinectl-don-t-output-No-machines.-with-no-legend-optio.p

Bug#892978: getmail4: should recommend requirements for --store-password-in-gnome-keyring

[Brian May]

Package: getmail4
Version: 4.53.0-1+deb9u1
Severity: wishlist

I think the following packages are required for the
--store-password-in-gnome-keyring option to work. These should be listed
in the recommends (or maybe suggests) header.

* python-gnomekeyring
* python-gobject

This list may not be complete. If getmail is updated to use Python3,
obviously these dependancies will need upating.

See discussion from
https://bbs.archlinux.org/viewtopic.php?id=173273
https://bbs.archlinux.org/viewtopic.php?pid=1362594#p1362594

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

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

Versions of packages getmail4 depends on:
ii  python  2.7.13-2

getmail4 recommends no packages.

getmail4 suggests no packages.

-- no debconf information

Bug#888244: apparmor: Convert quilt patch series to per-topic subdirectories managed by gbp-pq

[Tyler Hicks]

On 02/28/2018 04:56 AM, intrigeri wrote:
> Hi,
> 
> Steve Beattie:
>> Sorry, I've been swamped coping with Meltdown/Spectre. I took a brief
>> look at the topic git branches and it seems like a modest enough
>> organizational improvement to me[1].
> 
> OK. To me being able to use gbp-pq is a life-changer and I hope it'll
> be the same for you once you get used to it, but I agree that at the
> end of the day we're still tracking patches in Git, which has a number
> of drawbacks including the ones you've mentioned :)
> 
>> What would need to happen on the Ubuntu side to go forward?
> 
> Thanks for asking!
> 
> 1. Start using the ubuntu/* namespace on the Git repo on salsa for the
>Ubuntu packaging. I've already imported your work up to
>2.11.0-2ubuntu19 there.

Done! Thanks for giving us such a headstart on getting this set up.

>I did not import anything from your
>*-{security,updates} suites but DEP-14 should make it pretty easy
>to have dedicated branches for those. I'm happy to provide guidance
>if needed.

I'm not sure that we'll find importing *-{security,updates} to be very
useful. We'll probably just stick with ubuntu/master for now.

> 2. Merge the latest debian/2.12-* tag into ubuntu/master so you get
>2.12 and the many packaging improvements you folks have reviewed
>and that are in Debian already (otherwise the delta will remain so
>big we can't proceed with the big next step easily).

Done! I've pushed the resulting merge to ubuntu/master. What's there
right now is fully QA'ed and, IMO, ready to be uploaded to Bionic after
finalizing the changelog and tagging the release.

> 3. Give me the go ahead and then I'll:
> 
>- refresh the {debian,ubuntu}/gbp-pq branches
>- merge the {debian,ubuntu}/gbp-pq branches respectively into
>  {debian,ubuntu}/master
>- push {debian,ubuntu}/master
>- release & upload to Debian sid
>- ask you to release & upload to Ubuntu

I've taken a quick look at the gbp-pq branches and it sounds like Steve
did, as well. I see the value there so you've got the go ahead. :)

> 
> It would be great if we could do that before 18.04 LTS is too deeply
> frozen so you can benefit, in the next 5 years, from all the goodness
> ubuntu/master..debian/master has accumulated since your last merge
> from Debian. If that timing is not an option, we could of course
> postpone this to post-18.04-release but then you'll have to deal with
> two vastly different debian/ directories between your LTS and ongoing
> development branches, which I expect might be quite painful and
> error-prone.

We are running late on getting this merge done. Let me know if you think
it'll be a bit before you can do all the steps you outlined in #3 above.
If that's the case, I should probably go ahead and upload what's in
ubuntu/master now and then do another small, incremental upload after
the gbp-pq changes are merged.

Thanks again for all your work on this!

Tyler

> 
> And the following step of my secret evil plan is:
> 
> 4. Check with Apertis what it would take to have them share our Git
>history (they're already using DEP-14 but with a different bzr→Git
>import that was done earlier) and possibly join the Salsa merge
>request fun so Debian and Ubuntu can benefit from the improvements
>Apertis made: a quick glance suggests that a few of their changes
>could be relevant for other distros :)
> 
> Cheers,
> 




signature.asc
Description: OpenPGP digital signature

Bug#884542: Pending fixes for bugs in the prometheus-mysqld-exporter package

[pkg-go-maintainers]

tag 884542 + pending
thanks

Some bugs in the prometheus-mysqld-exporter package are closed in
revision d5f1611c81992321eb63d2f3eba13fd10d49886e in branch
'debian/sid' by Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/prometheus-mysqld-exporter.git/commit/?id=d5f1611

Commit message:

New upstream release/git snapshot. Closes: #884542.

Bug#891482: Looks like it wants the VMD module...

[Cyril Brulebois]

Control: tag -1 pending

Hi again Peter,

Cyril Brulebois  (2018-03-03):
> I'm adding debian-kernel@ to the loop, so that they can comment on
> this and maybe update udebs to include this extra module.

Ben seems to agree, this got committed to git:
  
https://salsa.debian.org/kernel-team/linux/commit/90b8cc7a38de710bb32f5c1ab6058ccb4aecf85a

and this bug got moved to src:linux accordingly.

Thanks again for the initial report.


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


signature.asc
Description: PGP signature

Bug#871033: newt: please add a libnewt0.52-udeb package

[Cyril Brulebois]

Hey folks,

Aurelien Jarno  (2018-03-07):
> On 2017-08-06 20:55, Aurelien Jarno wrote:
> > debian-installer used to re-link all the libraries going into the initrd
> > in order to strip unneeded symbols, using mklibs. That is the reason why
> > libnewt0.52-pic was needed. Unfortunately it was subject to regular
> > breakage, so d-i switched to mklibs-copy which just copies the regular
> > library.
> > 
> > It would now make sense to get rid of mklibs-copy and switch to a
> > regular udeb. Therefore would it be possible to add a libnewt0.52-udeb
> > package to newt? That's the purpose of the attached patch.
> > 
> > Once the transition has been done, it will be possible to get rid of the
> > libnewt0.52-pic package.
> 
> Any news about that? Does it sounds acceptable to you?

For debian-boot@: newt now has a new udeb, it migrated to testing, Aurélien
removed the build-dep on libnewt, and we should be getting a cdebconf binNMU
soon to get cdebconf-newt-udeb to depend on that new udeb instead of the
current libnewt0.52; since the last two bits seem to be happening in the
wrong order, that explains why d-i daily builds are popping up as broken on
various archs (where libnewt0.52 is no longer getting pulled automatically).


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


signature.asc
Description: PGP signature

Bug#849354: fvwm: Click not always taken into account or freezes the desktop

[Jaimos Skriletz]

On Tue, 3 Jan 2017 01:00:35 +0100 Vincent Lefevre  wrote:
> On 2016-12-26 02:24:30 +0100, Vincent Lefevre wrote:
> > I'd say that problem 1 occurs at around 1 over 10. AFAIK, it had never
> > occurred before the upgrade.
>
> After doing more tests with xev, I've noticed that the time delta
> between the ButtonPress event and the ButtonRelease event was in
> general much lower with the touchpad: about 120 units with the
> mouse button, but sometimes less than 10 units with the button
> of the touchpad.
>

In reviewing this I have a theory, the time is so low there is a race condition.
Fvwm gets and maybe ignores the release event before fvwm fully processes
the push event. Then fvwm gets stuck waiting for a release event, which
happens the next time you clicked the mouse button.

When using the function wrapper, this wouldn't happen because the function
wrapper due to holds, double clicks, etc, would not necessarily we waiting
for a release event like the mouse binding might be.

Wonder how common it is for the times between clicks and releases to be
that low, or if this bug is more an artifact of that hardware or
touchpad drivers.

jaimos

Bug#891922: RFS: you-get/0.4.1040-1 [ITP]

[Lumin]

On Sat, 3 Mar 2018 at 01:46 Alex Mestiashvili 
wrote:

>
>
>
> It would be interesting to see how this program is different from
> already existing tools like youtube-dl and cclive.
>
> Thank you!


I have noticed the existence of youtube-dl. However, the user may switch
to you-get when youtube-dl fails to work at some sites, such as Bilibili
(a popular Chinese danmaku video site).

cclive supports few site,compared to youtube-dl and you-get.

Danke.

> --
Best,

Bug#892977: geoip-bin: geoiplookup -v behavior is not consistent with the man page

[Kamaraju Kusumanchi]

Package: geoip-bin
Version: 1.6.9-4
Severity: minor

Dear Maintainer,

The man page of geoiplookup says

  -v Lists the date and build number for the GeoIP datafile(s).

But the command simply prints the "usage string" with this option.

 % geoiplookup -v
Usage: geoiplookup [-h] [-?] [-d custom_dir] [-f custom_file] [-v] [-i] [-l]


Either the man page should be updated or the behavior of geoiplookup should be
fixed accordingly. Could you please check?

thanks
Kamaraju S. Kusumanchi



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

Kernel: Linux 4.9.0-5-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: sysvinit (via /sbin/init)

Versions of packages geoip-bin depends on:
ii  libc6   2.24-11+deb9u1
ii  libgcc1 1:6.3.0-18
ii  libgeoip1   1.6.9-4
ii  libstdc++6  6.3.0-18

geoip-bin recommends no packages.

geoip-bin suggests no packages.

-- no debconf information

Bug#892967: lintian: considers .rtf to be a text file, causing false positives

[Chris Lamb]

tags 892967 + pending
thanks

> […]

So, turns out we can actually fix / "parse" .rtf files quite easily:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=9dd5cd5f7484f30026d1f63e362e13903a678ac1

.. so no need to ignore them just yet. :)


Best wishes,

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

Bug#892976: dokuwiki: Newer version available upstream

[Kamaraju Kusumanchi]

Package: dokuwiki
Version: 0.0.20160626.a-2
Severity: wishlist

Dear Maintainer,

The current version of dokuwiki in debian Sid is 0.0.20160626.a-2 . A newer
version, 2017-02-19e, is available upstream [1]. Could you please package it?

[1] - https://www.dokuwiki.org/changes


 % rmadison dokuwiki | grep unstable
dokuwiki   | 0.0.20160626.a-2   | unstable   | source, all


thanks
Kamaraju S. Kusumanchi



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

Kernel: Linux 4.9.0-5-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: sysvinit (via /sbin/init)

Bug#892975: network-manager-gnome: unable to connect to different wireless network when already connected

[marek]

Package: network-manager-gnome
Version: 1.8.10-2
Severity: important

To reproduce:
Using nm-applet connect to wireless network (doesn't matter whether is
encrypted or open). This first connection is successful.
Click on nm-applet again, select another available wireless network (doesn't
matter wheteher is remembered network with stored credentials, or Wi-fi Network
Authentication Required window pops up).
Nm-applet icon is showing connecting animation for long time, then disconnects,
then reconnects to network it was connected previously (first one).

Workaround:
Using nm-applet connect to wireless network (doesn't matter whether is
encrypted or open). This first connection is successful.
Click on nm-applet again, click Disconnect. Network is disconnected
successfully.
Click on nm-applet again, select another available wireless network.
Connection to different network is successful.

dmesg log produced by "To reproduce:" paragraph:
 wlp3s0: deauthenticating from c8:3a:35:19:d8:2c by local choice (Reason:
3=DEAUTH_LEAVING)
[ 5434.114281] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[ 5434.127733] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[ 5436.037266] wlp3s0: authenticate with c8:3a:35:19:d8:28
[ 5436.043839] wlp3s0: send auth to c8:3a:35:19:d8:28 (try 1/3)
[ 5436.047048] wlp3s0: authenticated
[ 5436.657760] iwlwifi :03:00.0: No association and the time event is over
already...
[ 5436.657816] wlp3s0: Connection to AP c8:3a:35:19:d8:28 lost
[ 5441.046340] wlp3s0: aborting authentication with c8:3a:35:19:d8:28 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 5444.444313] wlp3s0: authenticate with c8:3a:35:19:d8:28
[ 5444.449608] wlp3s0: send auth to c8:3a:35:19:d8:28 (try 1/3)
[ 5444.452750] wlp3s0: authenticated
[ 5445.063612] iwlwifi :03:00.0: No association and the time event is over
already...
[ 5445.063697] wlp3s0: Connection to AP c8:3a:35:19:d8:28 lost
[ 5449.450434] wlp3s0: aborting authentication with c8:3a:35:19:d8:28 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 5450.815908] wlp3s0: authenticate with c8:3a:35:19:d8:28
[ 5450.821046] wlp3s0: send auth to c8:3a:35:19:d8:28 (try 1/3)
[ 5450.826294] wlp3s0: authenticated
[ 5451.435166] iwlwifi :03:00.0: No association and the time event is over
already...
[ 5451.435261] wlp3s0: Connection to AP c8:3a:35:19:d8:28 lost
[ 5455.826249] wlp3s0: aborting authentication with c8:3a:35:19:d8:28 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 5457.818186] wlp3s0: authenticate with c8:3a:35:19:d8:28
[ 5457.823610] wlp3s0: send auth to c8:3a:35:19:d8:28 (try 1/3)
[ 5457.826784] wlp3s0: authenticated
[ 5458.437620] iwlwifi :03:00.0: No association and the time event is over
already...
[ 5458.437691] wlp3s0: Connection to AP c8:3a:35:19:d8:28 lost
[ 5458.973942] wlp3s0: aborting authentication with c8:3a:35:19:d8:28 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 5458.979121] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[ 5458.982431] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[ 5459.999526] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[ 5460.060783] wlp3s0: authenticate with c8:3a:35:19:d8:2c
[ 5460.065753] wlp3s0: send auth to c8:3a:35:19:d8:2c (try 1/3)
[ 5460.068783] wlp3s0: authenticated
[ 5460.070989] wlp3s0: associate with c8:3a:35:19:d8:2c (try 1/3)
[ 5460.072875] wlp3s0: RX AssocResp from c8:3a:35:19:d8:2c (capab=0x1 status=0
aid=1)
[ 5460.075146] wlp3s0: associated
[ 5460.076505] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready

dmesg log produced by "Workaround:" paragraph:
disconnect:
[ 5673.247416] wlp3s0: deauthenticating from c8:3a:35:19:d8:2c by local choice
(Reason: 3=DEAUTH_LEAVING)
[ 5673.262316] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
connect to another network:
[ 5837.120823] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[ 5837.189355] wlp3s0: authenticate with c8:3a:35:19:d8:28
[ 5837.195624] wlp3s0: send auth to c8:3a:35:19:d8:28 (try 1/3)
[ 5837.200396] wlp3s0: authenticated
[ 5837.204746] wlp3s0: associate with c8:3a:35:19:d8:28 (try 1/3)
[ 5837.208721] wlp3s0: RX AssocResp from c8:3a:35:19:d8:28 (capab=0x411
status=0 aid=2)
[ 5837.210917] wlp3s0: associated
[ 5837.267117] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready




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

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.18-1
ii  dbus-x11 [dbus-session-bus]   1.12.2-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.0-2+b1
ii  libatk1.0-0   2.26.1-3
ii  libc6 2.26-6
ii  libcairo

Bug#891887: ITP: python-certbot-dns-digitalocean -- DigitalOcean DNS plugin for Certbot

[Andrew Starr-Bochicchio]

On Thu, 01 Mar 2018 21:58:09 -0500 Harlan Lieberman-Berg <
hlieber...@debian.org> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Harlan Lieberman-Berg 
>
> * Package name: python-certbot-dns-digitalocean

Hi there,

As I'm already maintaining python-digitalocean and a user of certbot, I'd
be happy to help maintain this package if needed. Let me know if you're
looking for any help.

Thanks,

-- Andrew Starr-Bochicchio

   Debian Developer 
   Ubuntu Developer 
   PGP/GPG Key ID: 3B56E2BBD53FDCB1

Bug#892974: rtl-sdr: Debian-specific patch breaks FC0012 dongle

[hrachj]

Package: rtl-sdr
Version: 0.5.3-13
Severity: important
Tags: patch

I have several R820T-based and FC0012-based dongles. The Debian version of rtl-
sdr/librtlsdr does not work with the FC0012 ones:


$ rtl_test
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 0001

Using device 0: Generic RTL2832U OEM
No supported tuner found
Enabled direct sampling mode, input 1
Supported gain values (1): 0.0
Sampling at 2048000 S/s.


The upstream version works fine. I have traced the problem to 0013-lib-fix-
direction-bit-in-GPIO-code.patch. If I unapply this patch and rebuild the
package, it starts to work fine.

To reproduce the bug, you need to physically unplug the device after each
successful initialization.



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

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

Versions of packages rtl-sdr depends on:
ii  libc6 2.27-2
ii  librtlsdr00.5.3-13
ii  libusb-1.0-0  2:1.0.21-2

rtl-sdr recommends no packages.

rtl-sdr suggests no packages.

-- no debconf information

Bug#892905: lintian: pkg-doc examples need not reside under /usr/share/doc/pkg-doc/

[Chris Lamb]

tags 892905 + moreinfo
thanks

Hi Ferenc,

> Please consider relaxing the directory name regex.

We currently look for paths called "examples" under usr/share/doc/$pkg.
What are you suggesting we look for instead? :)

(The path must surely include "examples" somewhere, otherwise we can't
distinguish them between that and "regular" documentation.)


Regards,

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

Bug#892973: distcc: new upstream version (3.3)

[Shawn Landden]

Package: distcc
Severity: wishlist

Dear Maintainer,

I recently released version 3.3 of distcc.

Among other things, it features a fix of CVE 2004-2687. (github issue #155)

https://github.com/distcc/distcc

Please package it.

-Shawn Landden

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

Kernel: Linux 4.14.0-3-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages distcc depends on:
ii  adduser3.117
ii  debconf [debconf-2.0]  1.5.65
ii  libavahi-client3   0.7-3.1
ii  libavahi-common3   0.7-3.1
ii  libc6  2.26-6
ii  libpopt0   1.16-10+b2
ii  lsb-base   9.20170808
ii  netbase5.4

distcc recommends no packages.

Versions of packages distcc suggests:
pn  ccache   
ii  dbus 1.12.4-1
pn  distcc-pump  
ii  distccmon-gnome  3.1-6.3
pn  dmucs

Bug#892972: sigscheme: update the symbol files for some arch and add some new mips arch

[YunQiang Su]

Package: src:sigscheme
Version: 0.8.5-6

For GCROOTS_push_one, the fellow architecture should be included:

alpha mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el
mipsn32r6 mipsn32r6el mips64r6 mips64r6el m68k powerpc powerpcspe
ppc64 ppc64el

For GCROOTS_jmp_buf

!mips !mipsel !mipsn32 !mipsn32el !mips64 !mips64el !mipsr6 !mipsr6el
!mipsn32r6 !mipsn32r6el !mips64r6 !mips64r6el !s390 !s390x !arm64




-- 
YunQiang Su

Bug#890430: make: warning: -jN forced in submake: disabling jobserver mode.

[Andreas Beckmann]

On Fri, 16 Feb 2018 14:34:40 +0100 Aurelien Jarno 
wrote:
> This problem also affects the build daemons, the build of the linux
> package is much longer now on the architectures where make-dfsg does not
> FTBFS. The linux package indeed builds in parallel by using the
> MAKEFLAGS variable. I guess other packages are also affected. I am
> therefore raising the severity of this bug, we do not want such
> regression in testing.

This also affects openjdk-10 (and probably the other openjdk-* as well):
https://bugs.debian.org/891573
There the result was a unlimited-parallel build (something like
make -j), I noticed because the machine became unresponsive for
interactive use because the load suddenly went above 400 and it started
to swap ...


Andreas

Bug#892971: libignition-fuel-tools1-{1,dev}: both ship /usr/lib/ruby/ignition/cmdfuel1.rb

[Andreas Beckmann]

Package: libignition-fuel-tools1-dev,libignition-fuel-tools1-1
Version: 1.0.0+dfsg4-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

  Selecting previously unselected package libignition-fuel-tools1-dev:amd64.
  Preparing to unpack 
.../35-libignition-fuel-tools1-dev_1.0.0+dfsg4-3_amd64.deb ...
  Unpacking libignition-fuel-tools1-dev:amd64 (1.0.0+dfsg4-3) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-ADbRwA/35-libignition-fuel-tools1-dev_1.0.0+dfsg4-3_amd64.deb
 (--unpack):
   trying to overwrite '/usr/lib/ruby/ignition/cmdfuel1.rb', which is also in 
package libignition-fuel-tools1-1:amd64 1.0.0+dfsg4-3
  Errors were encountered while processing:
   
/tmp/apt-dpkg-install-ADbRwA/35-libignition-fuel-tools1-dev_1.0.0+dfsg4-3_amd64.deb


cheers,

Andreas

Bug#870283: libjsoncpp: Make source package bootstrappable

[Manuel A. Fernandez Montecelo]

Control: user debian-ri...@lists.debian.org
Control: usertag -1 + riscv64


Hi Peter,

2017-08-03 22:12 Peter Spiess-Knafl:

Dear Daniel!

Thank you for reporting this. I will fix it in the upcoming upload.


Do you think that this upload will happen soon?

If there's any blocker, like missing testing or need to upload, can we
do something to make it happen faster?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#892969: zynaddsubfx: move out of asciidoc => patch

[Joseph Herlant]

Control: tags -1 + patch

Pushed https://salsa.debian.org/multimedia-team/zynaddsubfx/merge_requests/1
to fix this issue.
Thanks for your help!
Joseph

Bug#892970: synopsis: README.source incorrectly says to use dpatch

[James Cowgill]

Source: synopsis
Version: 0.12-9
Severity: minor

Hi,

I notice README.source still contains instructions for using dpatch with
this package even though use of dpatch was removed in 0.12-9.

James



signature.asc
Description: OpenPGP digital signature

Bug#892965: Bug#892966: ntpsec-ntpdate: unconditionally removes /var/lib/ntpdate on purge, even if ntpdate is installed

[Richard Laager]

Unless I hear otherwise from the ntpdate maintainers, I have committed
and will upload a change to use this code in ntpsec-ntpdate:

# ntpdate also uses this directory, so if it is installed, leave it.
if ! dpkg -s ntpdate > /dev/null 2>&1; then
rm -rf /var/lib/ntpdate/
fi

I suggest something similar for ntpdate:

# ntpsec-ntpdate also uses this directory, so if it is installed,
# leave it.
if ! dpkg -s ntpsec-ntpdate > /dev/null 2>&1; then
rm -rf /var/lib/ntpdate/
fi

-- 
Richard

Bug#892504: [PATCH] nspr: Please add support for the RISC-V architecture

[Manuel A. Fernandez Montecelo]

Hello,

2018-03-09 21:31 Karsten Merker:

[...]
If the patch looks ok to you, I would apprechiate very much if
you could upload a new version of nspr with the patch applied to
unstable as that would allow us to continue with our bootstrap
efforts.


As additional information, I compiled the package natively and it ran
the test suite as part of the operation.

All tests pass successfully :)

=

BEGIN   Wed Mar 14 22:54:54 UTC 2018
NSPR_TEST_LOGFILE   /dev/null

TestResult

accept  Passed
acceptread  Passed
acceptreademu   Passed
affinityPassed
alarm   Passed
anonfm  Passed
atomic  Passed
attach  Passed
bigfile Passed
cleanup Passed
cltsrv  Passed
concur  Passed
cvarPassed
cvar2   Passed
dlltest Passed
dtoaPassed
errcodesPassed
exitPassed
fileio  Passed
foreign Passed
formattmPassed
fsync   Passed
i2l Passed
initclk Passed
inrval  Passed
instrumtPassed
intrio  Passed
intrupt Passed
io_timeout  Passed
ioconthrPassed
joinPassed
joinkk  Passed
joinku  Passed
joinuk  Passed
joinuu  Passed
layer   Passed
lazyinitPassed
libfilename Passed
lltest  Passed
lockPassed
lockfilePassed
logfile Passed
logger  Passed
many_cv Passed
multiwait   Passed
nameshm1Passed
nonblockPassed
ntioto  Passed
ntohPassed
op_2longPassed
op_excl Passed
op_filnfPassed
op_filokPassed
op_nofilPassed
parent  Passed
parsetm Passed
perfPassed
pipepingPassed
pipeping2   Passed
pipeselfPassed
poll_nm Passed
poll_to Passed
pollablePassed
prftest Passed
prfzPassed
primblokPassed
providerPassed
prpollmlPassed
pushtop Passed
ranfile Passed
randseedPassed
reinit  Passed
rwlocktest  Passed
sel_spd Passed
selct_erPassed
selct_nmPassed
selct_toPassed
selintr Passed
semaPassed
semaerr Passed
semapingPassed
sendzlf Passed
server_test Passed
servr_kkPassed
servr_ukPassed
servr_kuPassed
servr_uuPassed
short_threadPassed
sigpipe Passed
sockopt Passed
sockpingPassed
sprintf Passed
stack   Passed
stdio   Passed
str2addrPassed
strod   Passed
switch  Passed
system  Passed
testbit Passed
testfilePassed
threads Passed
timemac Passed
timetestPassed
tpd Passed
udpsrv  Passed
version Passed
writev  Passed
xnotify Passed
zerolen Passed
END Wed Mar 14 23:11:39 UTC 2018

[...]
Testing the Portable Library base64 functions:
(warning: the "triple characters" tests are slow)
Test 001 (PL_Base64Encode, single characters) ...PASS
Test 002 (PL_Base64Encode, double characters) ...PASS
Test 003 (PL_Base64Encode, triple characters) ...PASS
Test 004 (PL_Base64Encode, random strings)...PASS
Test 005 (PL_Base64Encode, single characters, malloc) ...PASS
Test 006 (PL_Base64Encode, double characters, malloc) ...PASS
Test 007 (PL_Base64Encode, triple characters, malloc) ...PASS
Tes

Bug#892969: zynaddsubfx: move out of asciidoc

[Joseph Herlant]

Package: zynaddsubfx
Version: 3.0.3-1
Usertags: asciidoc-eol



Hi,

As announced with asciidoc 8.6.10, asciidoc is EOL. As long as there's
no python3 compatibility, all the tools using asciidoc as a dependency
will be asked to move to asciidoctor or pandoc or whatever equivalent
you feel the most confortable with.

I already took care of the upstream part in:
https://sourceforge.net/p/zynaddsubfx/code/merge-requests/6/
But asciidoc is used in debian/rules for the packaging itself so we
need to move it there too.

Thanks for your help,
Joseph

Bug#892945: [Pkg-libvirt-maintainers] Bug#892945: Cannot start domain using user session

[Laurent Bigonville]

reassign 892945 qemu-system-common 1:2.11+dfsg-1
thanks

On Wed, 14 Mar 2018 22:37:14 +0100 Guido =?iso-8859-1?Q?G=FCnther?= 
 wrote:

> On Wed, Mar 14, 2018 at 08:42:32PM +0100, Laurent Bigonville wrote:

> > Hi,
> >
> > OK I got confused. polkit and the libvirt group has noththing to do 
with

> > that.
> >
> > It's happening because of the permissions on the /dev/kvm device.
> >
> > Would it be an option to tag /dev/kvm with uaccess? So users that are
> > logged in have access to it by default or set the permissions to 666?
>
> Sorry. I closed the bug before I saw your reply. This is already
> happening automatically for me. What would libvirt do about it,
> shouldn't systemd/udev set this up?

It's definitely not working here (anymore?)

$ getfacl /dev/kvm
getfacl : suppression du premier « / » des noms de chemins absolus
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
group::rw-
other::---

$ udevadm info --name /dev/kvm
P: /devices/virtual/misc/kvm
N: kvm
E: DEVNAME=/dev/kvm
E: DEVPATH=/devices/virtual/misc/kvm
E: MAJOR=10
E: MINOR=232
E: SUBSYSTEM=misc

You should have something like "TAGS=:uaccess:"

$ cat /lib/udev/rules.d/60-qemu-system-common.rules
KERNEL=="kvm", GROUP="kvm", MODE="0660"

Argh that file belong to qemu not libvirt...

I'm reassigning it.

Bug#892968: rsync: need config.guess/sub update for riscv64

[Aurelien Jarno]

Package: rsync
Version: 3.1.2-2.1
Severity: normal
Tags: patch
Justification: Policy §4.3
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

We are in the process of bootstrapping a Debian port for the  
riscv64 architecture (https://wiki.debian.org/RISC-V). It happens that
the config.guess/sub included in rsync is too old to recognize this
system. The solution is to update those files from autotools-dev, as
recommended by Debian Policy §4.3. This is what the patch below
does.

Thanks,
Aurelien

diff -Nru rsync-3.1.2/debian/control rsync-3.1.2/debian/control
--- rsync-3.1.2/debian/control  2017-12-13 06:34:49.0 +
+++ rsync-3.1.2/debian/control  2018-03-14 22:31:44.0 +
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Paul Slootman 
-Build-Depends: libpopt-dev,libacl1-dev,libattr1-dev
+Build-Depends: libpopt-dev,libacl1-dev,libattr1-dev,autotools-dev
 Standards-Version: 3.9.8
 Homepage: http://rsync.samba.org/
 
diff -Nru rsync-3.1.2/debian/rules rsync-3.1.2/debian/rules
--- rsync-3.1.2/debian/rules2017-12-13 06:34:49.0 +
+++ rsync-3.1.2/debian/rules2018-03-14 22:37:02.0 +
@@ -60,6 +60,8 @@
mkdir debian/buildtree
cp -p * debian/buildtree || true
cp -pr lib m4 popt support testsuite zlib debian/buildtree
+   # update config.guess/sub
+   cp /usr/share/misc/config.guess /usr/share/misc/config.sub 
debian/buildtree
# work around newer autoconf stuff (runstatedir)
touch debian/buildtree/aclocal.m4
@echo applying misc Debian patches

Bug#892967: lintian: considers .rtf to be a text file, causing false positives

[Adam Borowski]

Package: lintian
Version: 2.5.79
Severity: normal

Hi!
RTF is an old file format from Microsoft, that was pushed as a means of
"cross-platform interchange".  It has never been really widespread, but,
because its simplicity, most Word-like programs support it.  Thus, it's
an odd but not entirely irrational decision to ship some documents this
way.

A package that I'm reviewing includes several RTF files in its documentation
(I've attached one), it triggers a false positive for
license-problem-gfdl-invariants (despite correctly declaring no invariants
nor front or back cover texts).

I guess that RTF files could possibly trigger a number of other false
positives in lintian tests that expect real text.  As adding proper support
for RTF is obviously not worth the effort, it would be nice if you regarded
them to be binary (despite, like .ps, being technically ASCII).


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

Kernel: Linux 4.16.0-rc5-debug-00026-gca682bdc52ca (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.30-7
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5
ii  file  1:5.32-2
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.2-1
ii  patchutils0.3.4-2
ii  perl  5.26.1-5
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information
{\rtf1\ansi\ansicpg1252\cocoartf102{\fonttbl\f2\fnil Bitstream Charter;\f0\fnil 
Droid Sans Mono;\f1\fnil FreeSans;}
{\colortbl;\red0\green0\blue200;\red0\green0\blue0;\red255\green0\blue0;}
{{\NeXTGraphic iconoGimp3.tif \width1816 
\height1309}\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\f0\fs24
 \'AC}\f1\fs48  \b\cf1 \'A1Welcome to FisicaLab!\cf0\fs24\b0\cf2 \par
\par
\fs20\i Copyright (C)  2009, 2010, 2012  German A. Arias.\par
Permission is granted to copy, distribute and/or modify this document\par
under the terms of the GNU Free Documentation License, Version 1.3\par
or any later version published by the Free Software Foundation;\par
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 
Texts.\par
A copy of the license is included in the section entitled "GNU\par
Free Documentation License".\fs24\i0 \par
\par
\par
FisicaLab is an educational application to solve physics problems. Its main 
objective is let the user to focus in physics concepts, leaving aside the 
mathematical details (FisicaLab take care of them). This allows the user to 
become familiar with the physical concepts without running the risk of getting 
lost in mathematical details. And so, when the user gain confidence in applying 
physical concepts, will be better prepared to solve the problems by hand (with 
pen and paper). FisicaLab is easy to use and very intuitive. However, in order 
to take advantage of all its features, we recommend you read first these help 
files.\par
\par
FisicaLab display to two windows, one named \b Modules and elements\b0  and 
other named \b Chalkboard\b0 . The first of these windows, contain all modules 
that can be used to solve problems. These modules are grouped by: kinematics, 
static, dynamics, ... (see image below). You can select one of these groups 
with the buttons at the top of the window, marked with (1) in the image. When 
you leave the mouse\rquote s cursor above one of these buttons, a 

Bug#892966: ntpsec-ntpdate: unconditionally removes /var/lib/ntpdate on purge, even if ntpdate is installed

[Julian Gilbey]

Package: ntpsec-ntpdate
Version: 1.0.0+dfsg1-5
Severity: important

In the postrm, ntpsec-ntpdate does an unconditional rm -rf
/var/lib/ntpdate without checking whether ntpdate is installed (which
also uses the same directory).  It should protect the rm -rf with some
sort of test for whether ntpdate is installed (even if only in
config-files only state).

Best wishes,

   Julian

Bug#891957: netbeans no starting "loading module" modules.netbinox NullPointerException

[Francisco J. Blanco]

Package: netbeans
Version: 8.2+dfsg1-1
Followup-For: Bug #891957

Dear Maintainer,

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

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

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


-- System Information:
Debian Release: buster/sid
  APT prefers stable
  APT policy: (900, 'stable'), (750, 'testing'), (500, 'stable-updates'), (1, 
'experimental')
Architecture: i386 (i686)

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

Versions of packages netbeans depends on:
ii  default-jdk [java8-sdk]2:1.8-59
ii  libnb-apisupport3-java 8.2+dfsg1-1
ii  libnb-ide14-java   8.2+dfsg1-1
ii  libnb-java5-java   8.2+dfsg1-1
ii  libnb-platform18-java  8.2+dfsg1-1
ii  openjdk-8-jdk [java8-sdk]  8u151-b12-1

netbeans recommends no packages.

netbeans suggests no packages.

-- no debconf information


Hi,

As Patrick suggests, downgrading libequinox-osgi-java to stable version 
(3.8.1-10) fixed the problem.

Now Netbeans is starting normally.

Regards.

Bug#892965: ntpdate: unconditionally removes /var/lib/ntpdate on purge, even if ntpsec-ntpdate is installed

[Julian Gilbey]

Package: ntpdate
Version: 1:4.2.8p10+dfsg-6
Severity: important

In the postrm, ntpdate does an unconditional rm -rf /var/lib/ntpdate
without checking whether ntpsec-ntpdate is installed (which also uses
the same directory).  It should protect the rm -rf with some sort of
test for whether ntpsec-ntpdate is installed (even if only in
config-files only state).

Best wishes,

   Julian

Bug#851554: Bug#851524: Building armhf image fwith qemu fails at bootstrapping stage if firmware section enabled

[Jason Heeris]

Well, I could've saved myself a couple of hours if I'd remembered to do a
git pull. This is fixed in master, and the fixing commit was 952ac834
(Rohan Garg, "Simplify bootstrapping of foreign architectures with
qemu-debootstrap").

Thanks Rohan! Sorry everyone else for the noise on this report! On the
bright side, you can close it as fixed. And I can once again work on a
build procedure for live Raspbian images.

Bug#892734: stretch-pu: package dehydrated/0.3.1-3+deb9u2

[Cyril Brulebois]

Control: tag -1 +pending

Mattia Rizzolo  (2018-03-13):
> On Tue, Mar 13, 2018 at 05:26:18PM +0100, Cyril Brulebois wrote:
> > Control: tag -1 +confirmed
> 
> Thanks, uploaded and accepted into stable-new.

Thanks, flagged for acceptance.

I'll learn about stretch-updates in a moment or two.


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


signature.asc
Description: PGP signature

Bug#756811: src:nspr: add support for OpenRISC 1000 (or1k)

[Manuel A. Fernandez Montecelo]

Control: close -1


Hi Christian!

2014-08-01 23:16 Christian Svensson:

Package: src:nspr
Version: 4.10.6-1
Severity: wishlist
Tags: upstream patch

Dear Maintainer,

The attached patch adds support for the upcoming Debian architecture
OpenRISC (or1k).


Support was added in upstream back in 2015, and the port is no longer
under development, so I guess that we can close the bug report now :)


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#883515: release.debian.org: logging / introspection for queue-viewer

[Adam D. Barratt]

Control: owner -1 !

On Mon, 2017-12-04 at 18:11 +, Adam D. Barratt wrote:
> It is often difficult to determine what is happening with a
> particular
> queue-viewer run, and sometimes several minutes pass with no apparent
> processing or output.
> 
> It would therefore be useful for some form of logging and/or
> introspection framework to be added to queue-viewer and the
> debrelease.* libraries.
> 

I've made a start on this - queue-viewer and (most of) the libraries
log to ~release/var/data/queue-viewer/logs/current, and there's a
secondary log alongside for the bin/queue-viewer wrapper script.

The individual scripts still need a fair amount of work on the log
entries they generate and appropriate severities for them - most of
them will end up in "debug", which doesn't quite feel fine grained
enough.

For now I created the log file as "2018-03" and symlinked "current" to
it. We'll need a monthly cron job to generate the new log files and
update the symlink target (or someone will need to update queue-viewer
to allow patterns in the log filename).

Adam

Bug#892760: antlr3: FTBFS with Java 9

[Emmanuel Bourg]

Thank you, the fix looks good. Do you want to upload it?

Emmanuel Bourg

Bug#892916: libinput: Invalid tap event TAP_EVENT_RELEASE in state TAP_STATE_{TAPPED,MULTITAP}

[Vincent Blut]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=105512

On Wed, Mar 14, 2018 at 08:05:32PM +0200, Timo Aaltonen wrote:

On 14.03.2018 19:43, Vincent Blut wrote:

Control: found -1 1.10.3-1

On Wed, Mar 14, 2018 at 06:15:43PM +0100, Vincent Blut wrote:

On Wed, Mar 14, 2018 at 06:52:00PM +0200, Timo Aaltonen wrote:

On 14.03.2018 15:07, Vincent Blut wrote:

Package: libinput
Version: 1.10.2-1
Severity: normal

Hi,

Since libinput 1.10.x branch has been introduced in Debian, I’m facing
issues regarding three-finger click on my Elantech touchpad. This isn’t
always reproducible, but when it happens, the following errors get
logged:

mars 13 21:16:00 lamella /usr/lib/gdm3/gdm-x-session[1761]: (EE)
event1  - ETPS/2 Elantech Touchpad: libinput bug: invalid tap event
TAP_EVENT_RELEASE in state TAP_STATE_TAPPED
mars 13 21:16:01 lamella /usr/lib/gdm3/gdm-x-session[1761]: (EE)
event1  - ETPS/2 Elantech Touchpad: libinput bug: invalid tap event
TAP_EVENT_RELEASE in state TAP_STATE_MULTITAP


1.10.3-1 was uploaded already, does it help?


Will check. Thanks Timo!


It’s still reproducible.


Ok, please file a bug upstream at bugs.freedesktop.org wayland/libinput


Done!


--
t



Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#886120: doxygen = scapegoat ?

[Adam Borowski]

On Wed, Mar 14, 2018 at 09:34:36PM +0100, Paolo Greppi wrote:
> @kilobyte, let me see if I can understand your purpose with this bug report.
> 
> What happened is:
> 1) you find a serious bug in ctpp2 (popcon: 14)
> 2) you decide it's RC
> 3) it's doxygen fault so you reassign it to doxygen (popcon: 8381), and it 
> stays RC
> 
> Now let's look at the effect of all this:
> 1) doxygen is currently orphaned (https://bugs.debian.org/888580)
> 2) therefore nobody will take care of this unless someone adopts it
> 3) the average Johanna trying to decide whether she should adopt it will
>be repelled by this RC bug and the perspective that anybody anytime can
>file RC bugs because any obscure package fails to build and it's
>doxygen fault
> 4) consequently doxygen will not make it to buster
> 4) ctpp2-doc is also dropped from stable, and all other packages that
>depend on doxygen for building, which if I am not mistaken are 443:
> 
> grep-dctrl -FBuild-Depends doxygen -sPackage /var/lib/apt/lists/*Sources | wc
> 443 8868612
> 
> Is that your wish ?

Your reasoning is: https://en.wikipedia.org/wiki/Appeal_to_consequences
which is not a reason for dismissing a bug.  It _may_ be a valid reason
for the Release Team to mark the bug as buster-ignore, or to temporarily
reduce its severity, but this won't make it disappear.

The problem is not that random packages sometimes fail to build (not just
ctpp2, but obscure races are pretty hard to reproduce and/or debug).  The
problem is that packages _succeed_ where they shouldn't.

Doxygen turns bugs that usually would be obvious, easy to fix breakage into
random rare failures that appear to build the vast majority of the time. 

And, packages that have enough impact (such as doxygen) are already immune
to autoremoval, which addresses your 4) and 4).

Because of ignoring the failures, we don't know how widespread problems like
misgenerated output that's then (correctly) rejected by graphviz, are.

Only then we'd be able to correctly assess reasonable severities to
individual bugs.  Here, doxygen causes at least one package to FTBFS which
might or might not be RC (we'd know more only once it's no longer leakily
papered over).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#892945: [Pkg-libvirt-maintainers] Bug#892945: Cannot start domain using user session

[Guido Günther]

On Wed, Mar 14, 2018 at 08:42:32PM +0100, Laurent Bigonville wrote:
> Source: libvirt
> Followup-For: Bug #892945
> 
> Hi,
> 
> OK I got confused. polkit and the libvirt group has noththing to do with
> that.
> 
> It's happening because of the permissions on the /dev/kvm device.
> 
> Would it be an option to tag /dev/kvm with uaccess? So users that are
> logged in have access to it by default or set the permissions to 666?

Sorry. I closed the bug before I saw your reply. This is already
happening automatically for me. What would libvirt do about it,
shouldn't systemd/udev set this up?
Cheers,
 -- Guido

> 
> Kind regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers
> 

Bug#892960: libdrm FTBFS on arm*: symbol differences

[Sven Joachim]

Control: tags -1 + pending

On 2018-03-14 22:44 +0200, Adrian Bunk wrote:

> Source: libdrm
> Version: 2.4.91-1
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=libdrm&suite=sid
>
> ...
>debian/rules override_dh_makeshlibs
> make[1]: Entering directory '/<>'
> dh_makeshlibs -plibdrm2 -V'libdrm2 (>= 2.4.89)' --add-udeb=libdrm2-udeb -- -c4
> dh_makeshlibs -plibdrm-nouveau2 -V'libdrm-nouveau2 (>= 2.4.66)' -- -c4
> dh_makeshlibs -plibdrm-radeon1 -V'libdrm-radeon1 (>= 2.4.39)' -- -c4
> dh_makeshlibs -plibdrm-amdgpu1 -V'libdrm-amdgpu1 (>= 2.4.90)' -- -c4
> dh_makeshlibs -plibdrm-tegra0 -V'libdrm-tegra0' -- -c4
> dh_makeshlibs -plibdrm-freedreno1 -V'libdrm-freedreno1 (>= 2.4.89)' -- -c4
> dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
> diff output below
> dpkg-gensymbols: warning: debian/libdrm-freedreno1/DEBIAN/symbols doesn't 
> match completely debian/libdrm-freedreno1.symbols
> --- debian/libdrm-freedreno1.symbols (libdrm-freedreno1_2.4.91-1_arm64)
> +++ dpkg-gensymbolsaJO5I2 2018-03-14 07:53:26.403570801 +
> @@ -7,10 +7,12 @@
>   fd_bo_from_fbdev@Base 0
>   fd_bo_from_handle@Base 0
>   fd_bo_from_name@Base 0
> + fd_bo_get_iova@Base 2.4.91-1
>   fd_bo_get_name@Base 0
>   fd_bo_handle@Base 0
>   fd_bo_map@Base 0
>   fd_bo_new@Base 0
> + fd_bo_put_iova@Base 2.4.91-1
>   fd_bo_ref@Base 0
>   fd_bo_size@Base 0
>   fd_device_del@Base 0
> dh_makeshlibs: failing due to earlier errors
> debian/rules:103: recipe for target 'override_dh_makeshlibs' failed
> make[1]: *** [override_dh_makeshlibs] Error 2

I have added the missing symbols in git, not tested though.

Cheers,
   Sven

Bug#892964: mercurial: CVE-2018-1000132

[Salvatore Bonaccorso]

Source: mercurial
Version: 3.1.2-1
Severity: grave
Tags: security upstream

Hi,

the following vulnerability was published for mercurial.

CVE-2018-1000132[0]:
| Mercurial version 4.5 and earlier contains a Incorrect Access Control
| (CWE-285) vulnerability in Protocol server that can result in
| Unauthorized data access. This attack appear to be exploitable via
| network connectivity. This vulnerability appears to have been fixed in
| 4.5.1.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1000132
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000132
[1] 
https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_4.5.1_.2F_4.5.2_.282018-03-06.29

Regards,
Salvatore

Bug#818787: Mar 2016 rebuild results

[Adam Borowski]

> > In other words, my solution to this bug would be to make doxygen exit with 
> > an
> > error code when calling dot fails.  Then make will fail, it's an FTBFS, it 
> > gets
> > fixed, and everyone is happy.

> I've started a rebuild of all 552 packages in unstable that build-depend on
> doxygen or anything that recursively pulls doxygen (eclipse-eclox doxyqml
> doxygen-latex doxygen-gui doxygen-dbg python3-breathe python-breathe).
> My build environment has a /usr/bin/dot that aborts the build when called,
> which should detect this error even if doxygen output is redirected or
> mangled.  I'll let you know how widespread the FTBFS are when finished.

> On a slow-ass machine, 57 builds done in 2.5 hours so far, so it'll take a
> while.

Then, in https://lists.debian.org/debian-devel/2016/03/msg00288.html but not
CCed to this bug, there's:

=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=

Here are the results: 60 packages call /usr/bin/dot without depending on
graphviz.  During the rebuild, there was a number of unrelated FTBFSes (7
failed, 36 attempted), some of them might possibly try calling dot later.
I'll investigate/retry/file bugs todorrow.

alsa-lib
apr
apr-util
asl
cmocka
coinor-ipopt
cppunit
frei0r
gammu
gazebo
gconfmm2.6
gnuradio
gtkspellmm
hamlib
jaula
libaccounts-qt
libaqbanking
libassa
libccrtp
libevhtp
libgadu
libgnomecanvasmm2.6
libgpiv
libgwenhywfar
liblightify
libmediainfo
libmpdclient
libmusicbrainz3
libopenobex
libpqxx
libsdl2
libsidplayfp
libssh
libsyncml
libwibble
linphone
log4c
lucene++
mpqc
netcdf
netcdf-cxx
nifticlib
open-vm-tools
openafs
openigtlink
opensurgsim
pidgin
qca2
roboptim-core
scim
sdformat
silly
sipxtapi
sombok
tango
thepeg
vdk2
wimlib
wxwidgets3.0
zipios++

=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=✂=

Obviously, two years later, this list is outdated, but without an incentive
to fix any of those, the scale should remain similar.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#891923: needrestart: Use of uninitialized value $ucode_vars

[Thomas Liske]

tag 891923 upstream fixed-upstream
thanks


Hi Bob,

thanks for the report. The bug has been fixed upstream.


HTH,
Thomas


Bob Proulx  writes:

> Package: needrestart
> Version: 3.0-1
> Severity: normal
>
> On some systems I see the following:
>
>   root@clash:~# needrestart -b
>   NEEDRESTART-VER: 3.0
>   NEEDRESTART-KCUR: 4.15.0-1-amd64
>   NEEDRESTART-KEXP: 4.15.0-1-amd64
>   NEEDRESTART-KSTA: 1
>   NEEDRESTART-UCSTA: 0
>   Use of uninitialized value $ucode_vars{"CURRENT"} in concatenation (.) or 
> string at /usr/sbin/needrestart line 866.
>   NEEDRESTART-UCCUR:
>   Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
> string at /usr/sbin/needrestart line 867.
>   NEEDRESTART-UCEXP:
>
> These are KVM virtual machines without iucode_tool or intel-microcode 
> available.
>
>   root@clash:~# needrestart -bv
>   [main] eval /etc/needrestart/needrestart.conf
>   [main] needrestart v3.0
>   [main] running in root mode
>   NEEDRESTART-VER: 3.0
>   Failed to load NeedRestart::uCode::Intel: [uCode/Intel] iucode-tool not 
> available!
>   [ucode] no supported processor microcode detection
>   [Kernel] Linux: kernel release 4.15.0-1-amd64, kernel version #1 SMP Debian 
> 4.15.4-1 (2018-02-18)
>   [Kernel/Linux] /boot/vmlinuz-4.15.0-1-amd64 => 4.15.0-1-amd64 
> (debian-ker...@lists.debian.org) #1 SMP Debian 4.15.4-1 (2018-02-18) 
> [4.15.0-1-amd64]*
>   [Kernel/Linux] /boot/vmlinuz-4.14.0-3-amd64 => 4.14.0-3-amd64 
> (debian-ker...@lists.debian.org) #1 SMP Debian 4.14.17-1 (2018-02-14) 
> [4.14.0-3-amd64]
>   [Kernel/Linux] Expected linux version: 4.15.0-1-amd64
>   NEEDRESTART-KCUR: 4.15.0-1-amd64
>   NEEDRESTART-KEXP: 4.15.0-1-amd64
>   NEEDRESTART-KSTA: 1
>   NEEDRESTART-UCSTA: 0
>   Use of uninitialized value $ucode_vars{"CURRENT"} in concatenation (.) or 
> string at /usr/sbin/needrestart line 866.
>   NEEDRESTART-UCCUR: 
>   Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
> string at /usr/sbin/needrestart line 867.
>   NEEDRESTART-UCEXP: 
>
> Lack of iucode-tool triggers the $ucode_vars{"CURRENT"} error.  Lack
> of intel-microcode triggers the $ucode_vars{"AVAIL"} error.
>
> Bob
>
> -- Package-specific info:
> needrestart output:
> Your outdated processes:
> emacs[6711]
>
> checkrestart output:
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages needrestart depends on:
> ii  binutils   2.30-5
> ii  dpkg   1.19.0.5
> ii  gettext-base   0.19.8.1-4
> ii  libintl-perl   1.26-2
> ii  libmodule-find-perl0.13-1
> ii  libmodule-scandeps-perl1.24-1
> ii  libproc-processtable-perl  0.55-1
> ii  libsort-naturally-perl 1.03-2
> ii  libterm-readkey-perl   2.37-1+b2
> ii  perl   5.26.1-5
> ii  xz-utils   5.2.2-1.3
>
> Versions of packages needrestart recommends:
> ii  libpam-systemd  237-4
> ii  sysvinit-core   2.88dsf-59.10
>
> Versions of packages needrestart suggests:
> ii  libnotify-bin  0.7.7-3
>
> -- Configuration Files:
> /etc/apt/apt.conf.d/99needrestart changed [not included]
>
> -- no debconf information
>

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#860086: Unreproducible, moreinfo

[Oliver Sander]

Thanks for asking.  In fact, the problem disappeared automatically
during some Qt update (sorry, I don't know which one).
So the bug can be fixed.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#892963: abntex: Obsoleted by abntex2, maybe should be removed

[Eduardo M Kalinowski]

Package: abntex
Severity: wishlist

The abntex class, used for writing thesis and other similar documents in a
style conforming to the Brazilian Technical Standards Association (ABNT)'s
standard, has been obsoleted by a newer version, called abntex2
(https://github.com/abntex/abntex2 / http://www.abntex.net.br/ , in
Portuguese).

This new class is already packaged as part of the texlive-publishers package.

Considering the very low popcon stats (140 installations), the fact that this
project is not maintained upstream anymore, the replacement is included in
Debian, and the Debian package has been orphaned, I suppose this package could
be removed.



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

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

Versions of packages abntex depends on:
ii  dpkg   1.19.0.5
ii  tex-common 6.09
ii  texlive-fonts-recommended  2017.20180305-1
ii  texlive-lang-portuguese2017.20180305-1
ii  texlive-latex-recommended  2017.20180305-1

abntex recommends no packages.

abntex suggests no packages.

Bug#891923: needrestart: Use of uninitialized value $ucode_vars

[Bob Proulx]

Thomas Liske wrote:
> thanks for the report. The bug has been fixed upstream.

Awesome!  :-)

Bob

Bug#892849: [3dprinter-general] Bug#892849: Bug#892849: cura: Exception while launching cura

[Gregor Riepl]

> ii  libarcus3  3.1.0-1  amd64    message queue for Cura based on p
> ii  python3-arcus  3.1.0-1  amd64    message queue for Cura based on p
> ii  python3-sip    4.19.8+dfsg- amd64    Python 3/C++ bindings generator r

Thank you.

Unfortunately, I cannot reproduce the problem on my machine, even with these
exact versions from sid installed.
But I'm using a sid/stretch mix, not pure sid, so it may be related to that.

On the other hand, I will submit Cura 3.2.1 soon, so perhaps a new build will
help. I'll keep the bug open until then.
If it still happens with 3.2.1, we'll need to debug this further.

Bug#892962: libgit2: CVE-2018-8099

[Salvatore Bonaccorso]

Source: libgit2
Version: 0.26.0+dfsg.1-1.1
Severity: important
Tags: patch security upstream

Hi,

the following vulnerability was published for libgit2.

CVE-2018-8099[0]:
| Incorrect returning of an error code in the index.c:read_entry()
| function leads to a double free in libgit2 before v0.26.2, which allows
| an attacker to cause a denial of service via a crafted repository index
| file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-8099
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8099
[1] 
https://github.com/libgit2/libgit2/commit/58a6fe94cb851f71214dbefac3f9bffee437d6fe

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888580: I'm considering it ...

[Paolo Greppi]

Il 12/03/2018 12:22, Helmut Grohne ha scritto:
> On Sat, Jan 27, 2018 at 01:14:14PM +0100, Matthias Klose wrote:
>> I'd like to drop maintenance of doxygen. I think I hijacked that package in 
>> 2004
>> to be able to build the libstdc++ docs from the GCC sources. Now that the
>> package needs a concise understanding about the javascript issues (sources,
>> different upstream versions), I'd like to stay off that maintenance task. 
>> Helmut
>> Grohne has been a substantial help with the javascript issues, but decided to
>> leave co-maintainership.  Basically I'm asking for a new maintainer with the
>> understanding of the javascript issues, the implications for Debian policy, 
>> and
>> the willingness to adopt the package to build documentation of Debian 
>> packages.
> 
> I'd like to take the opportunity to thank Matthias for his time as sole
> and primary Doxygen maintainer for such a long time. It certainly isn't
> a thankful package as every new upstream release tends to make some
> other package FTBFS. Dealing with the bug reports can be a tiresome task
> indeed and Matthias has certainly endured that for a long time. The
> balance of how close to stay with upstream defaults is difficult to
> strike. Communicating issues with upstream likely needs more time as
> well.
> 
> I'd also like to thank Paolo Greppi, who stepped up and triaged a number
> of bugs in 2013. Paolo, are you still interested in Doxygen? Now would
> be a good time to say so.
> 
> In case someone wants to adopt Doxygen, I'm happy to share my knowledge
> of the package.
> 
> Helmut

Hi Helmut, thanks for the mail.

It looks like this one is 1 or 2 orders of magnitude more complex than any 
package I
currently maintain !
Also ATM I'm dm not dd so I'd need a sponsor for the uploads and/or (later) be 
granted
upload permissions.

But nonetheless I started to look at it.

I would prefer to maintain it with gbp, and I have created a git repo for that:
https://salsa.debian.org/paolog-guest/doxygen/tree/debian/sid
(this only has the current versions for wheezy, jessie, stretch, buster and sid 
plus
some minor changes on the debian/sid branch)

I wonder what would be the correct location on salsa, probably not inside
paolog-guest ?
Also it would be nice if the original uploaders were to sign the tags ?

In conclusion, I could adopt it, unless of course someone more experienced than 
me steps
in.

It would be of great help to get from you both an informal overview of TODOs, 
priorities,
_really_ critical bugs etc.

Paolo

Bug#892935: libdebian-installer: Please add support for "nodoc" build options and profile

[Karsten Merker]

Control: tags 892935 pending

On Wed, Mar 14, 2018 at 06:29:24PM +0100, Manuel A. Fernandez Montecelo wrote:
> Source: libdebian-installer
> Version: 0.114
> Severity: wishlist
> Tags: patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Hi,
> 
> We need changes in this package to help to bootstrap the riscv64 architecture,
> in particular it will help to skip using doxygen (in a clean way) for the time
> being.
> 
> It will be available at some point in the future, but it's complicate to have 
> it
> in the initial stages, due to the build-depends needed (particularly
> yui-compressor and ruby-compass at this moment).  This is probably the case 
> for
> any other architecture being bootstrapped now or in the near future.
> 
> I am attaching a patch that makes possible to compile the package by using
> profiles (or options) "nodoc", avoiding the dependency in d/control (with
> profile) and avoiding those files.  The profile helps to avoid the
> build-dependency entirel, not needing to force to build with missing
> dependencies.
> 
> Besides that, "nodoc" is a standard build option that would be nice to have in
> any case.
> 
> Please consider applying the patch (that I will upload in minutes, to have a 
> bug
> number) or providing some alternative solution to the same effect.

Looks good to me and local testbuilds haven't shown any problems.

The patch has been committed to the libdebian-installer git
repository; the CI build on jenkins was successful.  I intend to
upload the package with the patch included on the weekend unless
somebody @debian-boot should voice objections.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#892961: libgit2: CVE-2018-8098

[Salvatore Bonaccorso]

Source: libgit2
Version: 0.26.0+dfsg.1-1.1
Severity: important
Tags: patch security upstream

Hi,

the following vulnerability was published for libgit2.

CVE-2018-8098[0]:
| Integer overflow in the index.c:read_entry() function while
| decompressing a compressed prefix length in libgit2 before v0.26.2
| allows an attacker to cause a denial of service (out-of-bounds read)
| via a crafted repository index file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-8098
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8098
[1] 
https://github.com/libgit2/libgit2/commit/3207ddb0103543da8ad2139ec6539f590f9900c1
[2] 
https://github.com/libgit2/libgit2/commit/3db1af1f370295ad5355b8f64b865a2a357bcac0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#826044: needrestart: needrestart hangs after children have finished

[Toby Speight]

Package: needrestart
Version: 2.11-4
Severity: normal

After any upgrade, needrestart hangs, with a zombie child:

/
| root   929 27669  0 20:31 pts/200:00:00 aptitude install
| root   930   929  0 20:31 pts/200:00:00   sh -c test -x 
/usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke || true
| root   931   930  0 20:31 pts/200:00:00 /usr/bin/perl -w 
/usr/share/debconf/frontend /usr/sbin/needrestart
| root   939   931  0 20:31 pts/200:00:00   [needrestart] 

\

If I kill the perl process (931 above) my package upgrade completes
successfully.

It looks like it's not waiting properly for its children.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 3.16.7-ckt2-balti (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages needrestart depends on:
ii  dpkg   1.19.0.5
ii  gettext-base   0.19.8.1-4
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.24-1
ii  libproc-processtable-perl  0.53-3
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.37-1+b2
ii  perl   5.26.1-5
ii  xz-utils   5.2.2-1.3

Versions of packages needrestart recommends:
ii  sysvinit-core  2.88dsf-59.10

Versions of packages needrestart suggests:
pn  needrestart-session | libnotify-bin  

-- Configuration Files:
/etc/needrestart/notify.conf changed:
NR_NOTIFYD_DISABLE_WRITE='1'
NR_NOTIFYD_DISABLE_MAIL='1'


-- no debconf information

Bug#892960: libdrm FTBFS on arm*: symbol differences

[Adrian Bunk]

Source: libdrm
Version: 2.4.91-1
Severity: serious

https://buildd.debian.org/status/package.php?p=libdrm&suite=sid

...
   debian/rules override_dh_makeshlibs
make[1]: Entering directory '/<>'
dh_makeshlibs -plibdrm2 -V'libdrm2 (>= 2.4.89)' --add-udeb=libdrm2-udeb -- -c4
dh_makeshlibs -plibdrm-nouveau2 -V'libdrm-nouveau2 (>= 2.4.66)' -- -c4
dh_makeshlibs -plibdrm-radeon1 -V'libdrm-radeon1 (>= 2.4.39)' -- -c4
dh_makeshlibs -plibdrm-amdgpu1 -V'libdrm-amdgpu1 (>= 2.4.90)' -- -c4
dh_makeshlibs -plibdrm-tegra0 -V'libdrm-tegra0' -- -c4
dh_makeshlibs -plibdrm-freedreno1 -V'libdrm-freedreno1 (>= 2.4.89)' -- -c4
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: debian/libdrm-freedreno1/DEBIAN/symbols doesn't match 
completely debian/libdrm-freedreno1.symbols
--- debian/libdrm-freedreno1.symbols (libdrm-freedreno1_2.4.91-1_arm64)
+++ dpkg-gensymbolsaJO5I2   2018-03-14 07:53:26.403570801 +
@@ -7,10 +7,12 @@
  fd_bo_from_fbdev@Base 0
  fd_bo_from_handle@Base 0
  fd_bo_from_name@Base 0
+ fd_bo_get_iova@Base 2.4.91-1
  fd_bo_get_name@Base 0
  fd_bo_handle@Base 0
  fd_bo_map@Base 0
  fd_bo_new@Base 0
+ fd_bo_put_iova@Base 2.4.91-1
  fd_bo_ref@Base 0
  fd_bo_size@Base 0
  fd_device_del@Base 0
dh_makeshlibs: failing due to earlier errors
debian/rules:103: recipe for target 'override_dh_makeshlibs' failed
make[1]: *** [override_dh_makeshlibs] Error 2

Bug#886120: doxygen = scapegoat ?

[Paolo Greppi]

@kilobyte, let me see if I can understand your purpose with this bug report.

What happened is:
1) you find a serious bug in ctpp2 (popcon: 14)
2) you decide it's RC
3) it's doxygen fault so you reassign it to doxygen (popcon: 8381), and it 
stays RC

Now let's look at the effect of all this:
1) doxygen is currently orphaned (https://bugs.debian.org/888580)
2) therefore nobody will take care of this unless someone adopts it
3) the average Johanna trying to decide whether she should adopt it will be 
repelled by this RC bug and the perspective that anybody anytime can file RC 
bugs because any obscure package fails to build and it's doxygen fault
4) consequently doxygen will not make it to buster
4) ctpp2-doc is also dropped from stable, and all other packages that depend on 
doxygen for building, which if I am not mistaken are 443:

grep-dctrl -FBuild-Depends doxygen -sPackage /var/lib/apt/lists/*Sources | wc
443 8868612

Is that your wish ?

Paolo

Bug#892959: slic3r-prusa FTBFS on 32bit: error: format not a string literal and no format arguments

[Adrian Bunk]

Source: slic3r-prusa
Version: 1.39.1+dfsg-1
Severity: serious

https://buildd.debian.org/status/package.php?p=slic3r-prusa&suite=sid

...
/usr/bin/perl -MExtUtils::XSpp::Cmd -e xspp -- -t 
"/<>/slic3r-prusa-1.39.1+dfsg/xs/xsp/typemap.xspt" 
"/<>/slic3r-prusa-1.39.1+dfsg/xs/xsp/Print.xsp": In function 'void 
XS_Slic3r__Print_output_filepath(PerlInterpreter*, CV*)':
/usr/bin/perl -MExtUtils::XSpp::Cmd -e xspp -- -t 
"/<>/slic3r-prusa-1.39.1+dfsg/xs/xsp/typemap.xspt" 
"/<>/slic3r-prusa-1.39.1+dfsg/xs/xsp/Print.xsp":847:31: error: format 
not a string literal and no format arguments [-Werror=format-security]

Bug#892958: deb-systemd-invoke: add support for "reload-or-restart"

[Fabian Grünbichler]

Package: init-system-helpers
Version: 1.51
Severity: wishlist
Tags: patch

this would help integrating "reload-or-restart" functionality into
dh_installsystemd, mimicking the existing semantics of the restart
functionality (no reloading/restarting of disabled/static units which
are not running).

patch attached (since init-systems-helper is not yet on salsa)

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

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

Versions of packages init-system-helpers depends on:
ii  perl-base  5.26.1-5

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

Versions of packages init-system-helpers is related to:
pn  insserv  

-- no debconf information
>From 5e6e377b679602c799c9682cbca8c2d78cadbaba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabian=20Gr=C3=BCnbichler?= 
Date: Wed, 14 Mar 2018 21:32:33 +0100
Subject: [PATCH] deb-systemd-invoke: support reload-or-restart
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

as a pre-requisite to adding the same support to dh_installsystemd[1],
deb-systemd-invoke should support "reload-or-restart" with the same
semantics as "restart".

1: https://salsa.debian.org/debian/debhelper/merge_requests/1

Signed-off-by: Fabian Grünbichler 
---
 script/deb-systemd-invoke | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/script/deb-systemd-invoke b/script/deb-systemd-invoke
index 71b1c33..d4362de 100755
--- a/script/deb-systemd-invoke
+++ b/script/deb-systemd-invoke
@@ -35,7 +35,7 @@ deb-systemd-invoke - wrapper around systemctl, respecting policy-rc.d
 
 =head1 SYNOPSIS
 
-B start|stop|restart S ...>
+B start|stop|restart|reload-or-restart S ...>
 
 =head1 DESCRIPTION
 
@@ -81,7 +81,7 @@ if (-x $policyhelper) {
 # However, if the job is disabled but has been forced into the running state, we *do* stop
 # and restart it since this is expected behaviour for the admin who forced the start.
 # We don't autostart static units either.
-if ($action eq "start" || $action eq "restart") {
+if ($action eq "start" || $action eq "restart" || $action eq "reload-or-restart") {
 my $global_exit_code = 0;
 my @start_units = ();
 for my $unit (@units) {
@@ -95,7 +95,7 @@ if ($action eq "start" || $action eq "restart") {
 my $unit_active = $?>>8 == 0 ? 1 : 0;
 if (!$unit_installed && $action eq "start") {
 print STDERR "$unit is a disabled or a static unit, not starting it.\n";
-} elsif (!$unit_installed && !$unit_active && $action eq "restart") {
+} elsif (!$unit_installed && !$unit_active && ($action eq "restart" || $action eq "reload-or-restart")) {
 print STDERR "$unit is a disabled or a static unit not running, not starting it.\n";
 }
 else {
-- 
2.16.2

Bug#892957: nautilus crashes when trying to open files

[Rainer Schwarzbach]

Package: nautilus
Version: 3.26.2-2+b1
Severity: important

When trying to open files from nautilus (either with double-click or using the
context menu and “open with…”), the nautilus window closes, and the application
is not launched.

When I start nautilus from the command line, it prints “Gdk-Message: Error 71
(Protokollfehler) dispatching to Wayland display.” to the terminal when
crashing.



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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-2
ii  gsettings-desktop-schemas  3.27.92-1
ii  gvfs   1.34.1-2
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-2
ii  libcairo-gobject2  1.15.10-2
ii  libcairo2  1.15.10-2
ii  libexempi3 2.4.4-1
ii  libexif12  0.6.21-4
ii  libgail-3-03.22.28-1
ii  libgdk-pixbuf2.0-0 2.36.11-1
ii  libglib2.0-0   2.54.3-2
ii  libglib2.0-data2.54.3-2
ii  libgnome-autoar-0-00.2.3-1
ii  libgnome-desktop-3-17  3.27.92-1
ii  libgtk-3-0 3.22.28-1
ii  libnautilus-extension1a3.26.2-2+b1
ii  libpango-1.0-0 1.40.14-1
ii  libpangocairo-1.0-01.40.14-1
ii  libselinux12.7-2+b1
ii  libtracker-sparql-2.0-02.0.3-1
ii  libx11-6   2:1.6.4-3
ii  nautilus-data  3.26.2-2
ii  shared-mime-info   1.9-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.24.0-3
ii  gvfs-backends1.34.1-2
ii  librsvg2-common  2.40.20-2

Versions of packages nautilus suggests:
ii  eog 3.27.91-1
ii  evince [pdf-viewer] 3.27.92-1
ii  nautilus-extension-brasero  3.12.2-4
ii  nautilus-sendto 3.8.6-2
ii  totem   3.26.0-3+b1
ii  tracker 2.0.3-1
ii  vlc [mp3-decoder]   3.0.1-3
ii  xdg-user-dirs   0.16-1

-- no debconf information

Bug#892956: libinput-dev: Requires.private without package dependencies breaks pkg-config users

[Adrian Bunk]

Package: libinput-dev
Version: 1.10.3-1
Severity: grave
Control: affects -1 src:efl src:gnome-twitch src:muffin src:mutter 
src:gnome-shell

https://buildd.debian.org/status/package.php?p=efl&suite=sid

...
configure: error: pkg-config missing libinput >= 0.6.0 xkbcommon >= 0.3.0 
libudev


Root cause are the new dependencies in Requires.private
without package dependencies:

$ pkg-config --cflags  libinput
Package libwacom was not found in the pkg-config search path.
Perhaps you should add the directory containing `libwacom.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libwacom', required by 'libinput', not found
 
$ 

Bug#892955: mongodb-server: enabling the 'oplog' config option makes server fail to start

[Toni Mueller]

Package: mongodb-server
Version: 1:3.2.11-2+deb9u1
Severity: normal


Hi,

I just installed mongodb and wanted to get more detailed logging, so I
removed the comment from 'oplog = 0' and switched to 7:

# Set oplogging level where n is
#   0=off (default)
#   1=W
#   2=R
#   3=both
#   7=W+some reads
oplog = 7


After that, the server refused to start, and I found this in the log:

... mongod[385]: Error parsing INI config file: unrecognised option 'oplog'


Cheers,
--Toni++


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (990, 'stable'), (90, 'testing'), (70, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (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 mongodb-server depends on:
ii  adduser 3.115
ii  init-system-helpers 1.48
ii  libboost-chrono1.62.0   1.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgoogle-perftools42.5-2.2
ii  libpcre32:8.39-3
ii  libpcrecpp0v5   2:8.39-3
ii  libsnappy1v51.1.3-3
ii  libssl1.0.2 1.0.2l-2+deb9u2
ii  libstdc++6  6.3.0-18+deb9u1
ii  libstemmer0d0+svn585-1+b2
ii  libyaml-cpp0.5v50.5.2-4
ii  lsb-base9.20161125
ii  mongodb-clients 1:3.2.11-2+deb9u1
ii  zlib1g  1:1.2.8.dfsg-5

mongodb-server recommends no packages.

mongodb-server suggests no packages.

-- Configuration Files:
/etc/mongodb.conf changed:
dbpath=/var/lib/mongodb
logpath=/var/log/mongodb/mongodb.log
logappend=true
bind_ip = 127.0.0.1
journal=true
cpu = true
verbose = true
objcheck = true
quota = true


-- no debconf information

Bug#892954: xserver-xorg-video-qxl FTCBFS: python build dependency not installable

[Helmut Grohne]

Source: xserver-xorg-video-qxl
Version: 0.1.5-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xserver-xorg-video-qxl cannot be cross built, because its build
dependency on python is not installable for the host architecture. What
is needed here is a build architecture python though. After annotating
it with :any, xserver-xorg-video-qxl cross builds successfully. Please
consider applying the attached patch.

Helmut
diff -u xserver-xorg-video-qxl-0.1.5/debian/changelog 
xserver-xorg-video-qxl-0.1.5/debian/changelog
--- xserver-xorg-video-qxl-0.1.5/debian/changelog
+++ xserver-xorg-video-qxl-0.1.5/debian/changelog
@@ -1,3 +1,10 @@
+xserver-xorg-video-qxl (0.1.5-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate python build dependency with :any. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 14 Mar 2018 20:57:49 +0100
+
 xserver-xorg-video-qxl (0.1.5-2) unstable; urgency=medium
 
   * Team upload.
diff -u xserver-xorg-video-qxl-0.1.5/debian/control 
xserver-xorg-video-qxl-0.1.5/debian/control
--- xserver-xorg-video-qxl-0.1.5/debian/control
+++ xserver-xorg-video-qxl-0.1.5/debian/control
@@ -25,7 +25,7 @@
  libspice-server-dev [amd64],
  libxext-dev,
  libxfont-dev,
- python,
+ python:any,
 Standards-Version: 3.9.8
 Homepage: https://www.spice-space.org/
 Vcs-Git: 
https://anonscm.debian.org/git/pkg-xorg/driver/xserver-xorg-video-qxl.git

Bug#892794: systemd-networkd fails to configure IPv6 without MTU from RA

[Cyril Brulebois]

Hi Russ,

Russ Allbery  (2018-03-12):
> Package: systemd
> Version: 232-25+deb9u2
> Severity: important
> Tags: ipv6
> 
> systemd 232-25+deb9u2 breaks IPv6 configuration with systemd-networkd
> if the RA doesn't include an MTU.  This is a regression from 232-25+deb9u1
> and breaks all IPv6 networking on the system in this network configuration.

I'm very sorry for that…

> This is presumbly due to the fix for #878162.
> 
> After upgrading to 232-25+deb9u2, I got error messages in the logs every
> minute:
> 
> Mar 12 18:02:08 haven systemd-networkd[25396]: eth0: Failed to get default 
> router MTU from RA: No data available

Yeah, that seems very likely… Even if the word regression or the commit
ID doesn't appear in the commit message, the follow-up commit seems to
fix this specific issue:

commit 29b5ad083a6925efec8e188013d1298742e0baaa
Author: Jörg Thalheim 
Date:   Mon Dec 19 15:34:07 2016 +0100

networkd-ndisc: handle missing mtu gracefully (#4913)

At least bird's implementation of router advertisement does not
set MTU option by default (instead it supplies an option to the user).
In this case just leave MTU as it is.

 → 
https://github.com/systemd/systemd/commit/29b5ad083a6925efec8e188013d1298742e0baaa

Regarding the other pair of functions getting the return code checked
(sd_netlink_message_open_container & sd_netlink_message_close_container)
there doesn't seem to be any follow-up commits touching that file in
these areas… I'm not sure netlink operations are likely to fail anyway
(except for ENOMEM situations), so that's probably fine?

> It's possible that this means the local IPv6 routing environment is
> not correctly configured, but since this change was made in a stable
> update and IPv6 was working perfectly prior to this change, it still
> feels like a relatively serious regression to me.

Definitely, sorry for having proposed that commit without spotting it.

I can build a patched systemd with this extra cherry-pick for you to
double check; I'll post a link once it's available.


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


signature.asc
Description: PGP signature

Bug#892953: autofs-5.1.2-3 crashes on hppa architecture

[Helge Deller]

Package: autofs
Version: 5.1.2-3

Upgrading autofs from autofs_5.1.2-2 to -3 version creates runtime 
crashes on the hppa architecture. Haven't done any further analyzes yet,
but it's critical to get it fixed, because our debian buildd servers
on hppa use /boot mounted via automounter.

[  268.945134] break 0,0: pid=2426 command='automount'
[  268.945134] CPU: 2 PID: 2426 Comm: automount Not tainted 
4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b5

[  268.945134]  YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[  268.945134] PSW: 0100 Not tainted
[  268.945134] r00-03  00ff0004ff0f f2ff9e00 f2fd69b3 
f86cdac0
[  268.945134] r04-07  f2ffae00  f8d00eb4 
420c0c40
[  268.945134] r08-11  420c0d08 f86cd849 001c 
f8900728
[  268.945134] r12-15  f86cdc0c 002d f86cdb4c 
f8d005e8
[  268.945134] r16-19  f86cdbc5 0005 f8900728 
f74e6598
[  268.945134] r20-23  41034580 41b783cc  
b0068000
[  268.945134] r24-27   0001 f8900728 
41b783cc
[  268.945134] r28-31   f87c8504 f86cdc40 
f83ecb73
[  268.945134] sr00-03  003cb000 003cb000  
003cb000
[  268.945134] sr04-07  003cb000 003cb000 003cb000 
003cb000

[  268.945134]   VZOUICununcqcqcqcqcqcrmunTDVZOUI
[  268.945134] FPSR: 0101
[  268.945134] FPER1: 
[  268.945134] fr00-03  0410   

[  268.945134] fr04-07     

[  268.945134] fr08-11     

[  268.945134] fr12-15     

[  268.945134] fr16-19     

[  268.945134] fr20-23     

[  268.945134] fr24-27     

[  268.945134] fr28-31     


[  268.945134] IASQ: 003cb000 003cb000 IAOQ: 41b783cf 
41b783d3
[  268.945134]  IIR: ISR:   IOR: 
[  268.945134]  CPU:2   CR30: 7cdec000 CR31: a7fd
[  268.945134]  ORIG_R28: 
[  268.945134]  IAOQ[0]: 41b783cf
[  268.945134]  IAOQ[1]: 41b783d3
[  268.945134]  RP(r2): f2fd69b3

Bug#892854: Hostname resolution getting stuck for many seconds

[Simon McVittie]

On Wed, 14 Mar 2018 at 20:01:07 +0100, Eduard Bloch wrote:
> I cannot remember having touched [nsswitch.conf] on this system. And I
> guess that if you have a record of all versions installed in the past
> then it should be easy to detect a pristine copy of that file and
> update/replace it as needed.

Unfortunately, no, we can't. Each line of nsswitch.conf is collaboratively
maintained by glibc and every relevant nsswitch plugin (libnss-*)
by editing it in-place. So the expected contents of the hosts line
depend which other nsswitch hosts plugins you have, and there is no
single history.

In a more opinionated distribution, the distro's core maintainers might
maintain a single nsswitch.conf containing all the supported plugins in
some reasonable order; but this is Debian, where all configurations are
considered valid, even the ones that make little sense.

> Still, I think this problem deserves a better solution. Because it's not
> really obvious for the user what is going on in case of such trouble.

I'm open to suggestions for how we can improve things for pre-2013
installations, within the constraints that I can't change the past,
and I don't want to violate Policy by overriding sysadmin configuration.

Post-2013 installations should be OK already (the purge/reinstall cycle
that I suggested gives you the equivalent of a post-2013 installation).

smcv

Bug#892952: decode error detected

[Jeffrin Thalakkottoor]

Package: firefox
Version: 58.0.1

hello ,

i have a media related decode error detected in my syslog.
may be this is because of  debian package build going
at one time.

i have attached the output of  "sudo cat /var/log/syslog | grep firefox |
head | tee derror.txt"

Linux debian 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64
GNU/Linux

libc6:amd64 2.27-1

00:02.0 VGA compatible controller: Intel Corporation HD Graphics (rev 09)
Intel(R) Pentium(R) CPU 3825U @ 1.90GHz
MemTotal:3963644 kB

$cat /proc/swaps
Filename Type Size Used Priority
/dev/sda3   partition 4107260 712352 -1
$
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #4] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #3] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #4] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #1] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #1] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #3] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #4] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #2] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #3] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365
Mar 14 21:21:11 debian firefox.desktop[1831]: [Child 2110, MediaPlayback #1] 
WARNING: Decoder=7fd31c1c3800 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR 
(0x806e0005) - 
RefPtr, 
mozilla::MediaResult, true> > 
mozilla::MediaSourceTrackDemuxer::DoGetSamples(int32_t): manager is detached.: 
file 
/build/firefox-MqZXKo/firefox-58.0.1/dom/media/MediaDecoderStateMachine.cpp, 
line 3365

Bug#892945: Cannot start domain using user session

[Laurent Bigonville]

Source: libvirt
Followup-For: Bug #892945

Hi,

OK I got confused. polkit and the libvirt group has noththing to do with
that.

It's happening because of the permissions on the /dev/kvm device.

Would it be an option to tag /dev/kvm with uaccess? So users that are
logged in have access to it by default or set the permissions to 666?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#892951: iptables rules loaded via iptables-restore ....rules.v4 are dropped every few minutes.

[g.smyli]

Package: iptables
Version: 1.6.0+snapshot20161117-6
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I believe the problem existed after fresh netinstall of Debian Stretch with 
xfce destop but I am not sure exactly when I \
began to notice iptables problem. I added skolelinux desktop which took over 
boot but is still xfce so I didn't mind. Being \
rather security conscious I'm sure I would setup iptables with rules right away.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I made rules for iptables. I noticed I had problems loading the rules up at 
boot. Tried netfilter-persistent, \
tried a script in rc.local maybe a couple of other efforts (installed apf, 
uninstalled apf netfilter-persistent, reinstall \
iptables and netfilter-persistent...) most things I tried usually worked for a 
few boots but would then would\
randomly fail. The most dependable thing I have found is to be disconnected 
from the network by default and place a preprocessing iptables startup script \
in wicd which loads the rules before network is brought up. Eventually I 
discovered the loaded rules would disapper after a few minutes. This \
happens whether I am browsing the internet or not or in fact not doing anything.
I just tried to gdebi the latest package iptables_1.6.1-2~bpo9+1_amd64.deb but 
that was uninstallable due to an incompatible library.

   Rquired outcome is of course to load the rules and depend on them to be 
stable.


Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-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)

Versions of packages iptables depends on:
ii  libc62.24-11+deb9u3
ii  libip4tc01.6.0+snapshot20161117-6
ii  libip6tc01.6.0+snapshot20161117-6
ii  libiptc0 1.6.0+snapshot20161117-6
ii  libnetfilter-conntrack3  1.0.6-2
ii  libnfnetlink01.0.1-3
ii  libxtables12 1.6.0+snapshot20161117-6

iptables recommends no packages.

Versions of packages iptables suggests:
ii  kmod  23-2

-- no debconf information

Bug#892939:

[Torben Schou Jensen]

inxi -Gx
Graphics:  Card: Intel HD Graphics 620 bus-ID: 00:02.0
   Display Server: X.Org 1.19.6
   drivers: modesetting (unloaded: fbdev,vesa)
   Resolution: 1024x768@60.00hz
   OpenGL: renderer: Mesa DRI Intel HD Graphics 620 (Kaby Lake GT2)
   version: 4.5 Mesa 17.3.6 Direct Render: Yes

Bug#892950: apcupsd FTBFS: python-imaging removed from pillow/5.0.0-1

[Helmut Grohne]

Source: apcupsd
Version: 3.14.14-1
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

apcupsd fails to build from source in unstable. Its Build-Depends are no
longer satisfiable, because python-imaging was removed from
pillow/5.0.0-1.

Helmut

Bug#892939:

[Torben Schou Jensen]

xrandr

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
DP-1 connected primary 1024x768+0+0 (normal left inverted right x axis y
axis) 598mm x 336mm
   1024x768  60.00*
   800x600   75.0060.32
   720x576   50.00
   720x480   60.0059.94
   640x480   75.0072.8166.6760.0059.94
   720x400   70.08
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)

Bug#892917: love: use BD on lua OR luajit

[Frédéric Bonnard]

Hi James,

On Wed, 14 Mar 2018 13:50:04 +, James Cowgill  wrote:
> Hi,
> 
> On 14/03/18 13:37, Frédéric Bonnard wrote:
> > Package: src:love
> > Version: 0.9.1-4
> > 
> > --
> > 
> > Dear maintainer,
> > 
> > at the moment both liblua5.1-0-dev and libluajit-5.1-dev are required to
> > build. I think one or the other exclusively should be enough, and your
> > d/rules specifies one or the other already.
> > The best being to require first libluajit-5.1-dev if available and
> > fallback on liblua5.1-0-dev.
> > This way, love will benefit from luajit's speed if possible but will
> > build on more architectures as well thanks to lua's portability (that
> > should fix the BD-Uninstallable status on some architectures)
> > Here is a patch for this.
> > Also, ppc64el's support in luajit is unsure in the long term, so with
> > the patch, we ensure to be able to still have love on this architecture
> > even if luajit drops ppc64el support (and thus fix the current FTBFS :
> > https://buildd.debian.org/status/fetch.php?pkg=love&arch=ppc64el&ver=0.9.1-4&stamp=1503721727&raw=0
> 
> Bear in mind the buildds ignore alternatives in build-dependencies, so
> from their perspective, your patch is equivalent to dropping the non-jit
> dependency and won't fix any of the BD-Uninstallable architectures.

oh.. indeed

> I think keeping the current build-dependency on liblua5.1-0-dev but
> restricting it to the architectures where luajit is not used should do
> what you want.

right. Actually the following seems to work as expected :

libluajit-5.1-dev [!s390x !alpha !hppa !ia64 !m68k !powerpcspe !sh4 !sparc64] | 
liblua5.1-0-dev,

based on the architectures not supported by luajit at the moment.

Regards,

F.

> 
> James
> 


pgpzYSKqmPonh.pgp
Description: PGP signature

Bug#888963: Moreinfo

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo

Considering we are currently able to cross build stuff with qt5 we maybe have 
fixed this?

-- 
Combata las características. Si una característica no es absolutamente
esencial, descártela, especialmente si tiene el mismo efecto que se
puede alcanzar mediante la combinación de otras características.
  Andrew S. Tanenbaum, de su libro "Computer Networks"

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#877527: Unreproducible, moreinfo

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi! I definitely can't reproduce this bug. Can you still reproduce it with 
x32?

Thanks, Lisandro.

-- 
 1: Una computadora sirve:
* Para tratar de dominar el mundo, un caso conocido de esto fue el de
  Skinet
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

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#876644: Is this bug still reproducible?

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo

Hi! Can you still reproduce this bug with current Debian testing?

Thanks, Lisandro.

-- 
For want of a nail, the shoe was lost;
For want of the shoe, the horse was lost;
For want of the horse, the rider was lost;
For want of the rider, the battle was lost;
For want of the battle, the kingdom was lost;
And all for the want of a horseshoe nail
  http://www.everything2.com/index.pl?node_id=1097943

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#860086: Unreproducible, moreinfo

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi! I definitely can't reproduce this because of lack of proper hardware. Is 
this still valid for you?


-- 
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the world.
  -- seen on the net

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#855042: Unrperoducible, moreinfo

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi! I can't reproduce this bug plus I remember that we worked on some patchs 
regarding accessibility. I can't tell for sure if this is fixed in stable but 
I would guess it is for testing.

Can you please try again? Thanks!

-- 
“I don’t think security can solve problems.
We need to teach greater respect.”
  Oslo Mayor Stang when asked whether Oslo needs greater security
  after the attacks in Norway, 07/2011.

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#892949: mark decorator packages Multi-Arch: foreign

[Helmut Grohne]

Source: python-decorator
Version: 4.1.2-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:dipy src:gr-gsm src:nipy src:pymvpa2 src:theano 
src:uc-echo

The affected packages cannot satisfy their cross Build-Depends, because
their dependency on python-decorator or python3-decorator is
unsatisfiable. In general, Architecture: all packages can never satisfy
cross Build-Depends unless marked Multi-Arch: foreign. I think that
marking these packages Multi-Arch: foreign is correct because:

 * All of them are Architecture: all.
 * All of their Depends are either annotated :any.
 * While the maintainer scripts produce architecture-specific Python
   bytecode files, this bytecode matches whatever Python happens to be
   installed. Also Python modules can be used without pre-compiled
   bytecode files, so embedded interpreters for a foreign architecture
   (a very uncommon case) continue to work (albeit a bit slower).

Please consider applying the attached patch.

Helmut

diff --minimal -Nru python-decorator-4.1.2/debian/changelog 
python-decorator-4.1.2/debian/changelog
--- python-decorator-4.1.2/debian/changelog 2017-09-29 11:06:44.0 
+0200
+++ python-decorator-4.1.2/debian/changelog 2018-03-14 20:04:22.0 
+0100
@@ -1,3 +1,10 @@
+python-decorator (4.1.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark all packages Multi-Arch: foreign (closes: #-1)
+
+ -- Helmut Grohne   Wed, 14 Mar 2018 20:04:22 +0100
+
 python-decorator (4.1.2-1) unstable; urgency=medium
 
   * New upstream release (closes: 869560)
diff --minimal -Nru python-decorator-4.1.2/debian/control 
python-decorator-4.1.2/debian/control
--- python-decorator-4.1.2/debian/control   2017-09-29 11:06:44.0 
+0200
+++ python-decorator-4.1.2/debian/control   2018-03-14 20:04:20.0 
+0100
@@ -14,6 +14,7 @@
 
 Package: python-decorator
 Architecture: all
+Multi-Arch: foreign
 Depends: ${python:Depends}, ${misc:Depends}
 Enhances: python-pylons
 Description: simplify usage of Python decorators by programmers
@@ -33,6 +34,7 @@
 
 Package: python3-decorator
 Architecture: all
+Multi-Arch: foreign
 Depends: ${python3:Depends}, ${misc:Depends}
 Description: simplify usage of Python decorators by programmers
  Python 2.4 decorators have significantly changed the way Python programs are

Bug#892854: Hostname resolution getting stuck for many seconds

[Eduard Bloch]

Hallo,
* Simon McVittie [Tue, Mar 13 2018, 11:36:11PM]:
> On Tue, 13 Mar 2018 at 20:52:28 +0100, Eduard Bloch wrote:
> > I checked the process with strace and saw something weird. My DNS was
> > accessed, was queried, it returned data, then the connection was closed
> > and then it started doing something with your library and THAT is where
> > it didn't continue anymore.
> 
> What's in the hosts: line in your /etc/nsswitch.conf?

hosts:  files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4

> New installations of nss-mdns will set it up with
> 
> mdns4_minimal [NOTFOUND=return]
> 
> just before either resolve or dns, whichever is seen first. That means
> only names in the .local domain are resolved this way. For example, on
> a machine with systemd-resolved and various other non-standard modules,
> I have:
> 
> hosts:  files mymachines gw_name myhostname mdns4_minimal 
> [NOTFOUND=return] resolve [!UNAVAIL=return] dns
> 
> However, we don't edit nsswitch.conf if there is already a mention
> of mdns (because that way there'd be a risk of overwriting sysadmin
> configuration or otherwise breaking stuff), so in particular old
> installations that already had nss-mdns installed before 2013 can have
> a no-longer-recommended configuration left over.
> From your strace showing libnss_mdns4.so.2 being loaded, I think you
> have mdns4 instead of mdns4_minimal. mdns{,4,6} tries to look up more
> names in mDNS, and because of how mDNS works, will cause an arbitrary
> delay for each name that cannot be resolved by any means (hosts file,
> DNS, mDNS, whatever). I don't think there's much we can do about that
> without making it impossible to choose the "non-minimal" behaviour.

ETOOMUCHINFORMATION

I cannot remember having touched this file ever on this system. And I
guess that if you have a record of all versions installed in the past
then it should be easy to detect a pristine copy of that file and
update/replace it as needed.

$ md5sum /etc/nsswitch.conf 
60686f928ec8782f409b742e49314427  /etc/nsswitch.conf

> If you purge and reinstall libnss-mdns, it should come back with a
> better configuration that doesn't cause arbitrary delays (unless you
> specifically ask to resolve a .local name that doesn't exist).

Ok, I did just that (had to purge another multiarch version as well) and
now it works, just as you described.

Still, I think this problem deserves a better solution. Because it's not
really obvious for the user what is going on in case of such trouble.

Best regards,
Eduard.

Bug#825573: Unreproducible, moreinfo

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 unreproducible moreinfo

Hi! I can't reproduce this bug. Are you still able to do it? Is it possible to 
do it with another layout? (not the bepo one?).

Cheers, Lisandro.

-- 
A group of politicians deciding to dump a President because his morals
are bad is like the Mafia getting together to bump off the Godfather for
not going to church on Sunday.
  Russell Baker

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#792133: Unrperoducible, moreinfo

[Lisandro Damián Nicanor Pérez Meyer]

Hi Vincent! Sadly I missed your reply last time and Qt has changed quite a lot 
lately. Are you still able to reproduce this issue? If so it grants a bug 
upstream, so please let me know.

Sorry for the terrible looong delay :-(

-- 
I still maintain the point that designing a monolithic kernel in 1991 is a
fundamental error.  Be thankful you are not my student.  You would not get a
high grade for such a design :-)
(Andrew Tanenbaum to Linus Torvalds)

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#886044: syncmaildir: raising severity of gconf dependency bug

[gregor herrmann]

On Wed, 14 Mar 2018 09:55:36 +0100, Enrico Tassi wrote:

> > Looking at the ChangeLog and the git history, it seems that gconf has
> > been replaced by gsettings already in 1.2.6.
> > Grepping through the code shows two leftovers, the build dependency in
> > debian/control, and a mentioning in PKGS_VALA in Makefile.
> > 
> > If I remove those two pieces, the package builds and the Depends line
> > of the syncmaildir-applet binary package loses gconf-service and
> > libgconf-2-4.
> > 
> > Patch (git diff against master) attached.
> > 
> > Enrico, do you have time to work on this? Otherwise I'm happy to
> > make an upload based on this diff.
> 
> Many thanks for the work!

You're welcome.
 
> I was planning to do a new release (I'm also the upstream, and I have a
> couple of pending fixes) and the do the upload fixing the gconf issue.

That's good news!
 
> I'm very busy so can't guarantee I'll manage to do it promptly, so if
> it helps please do an NMU (and I'll wait the migration to testing before
> doing my upload, in case I manage to release quickly).

I'm not sure about the timeline for the gconf removal (cc'ing jbicha)
but I guess it can wait a bit, and would save some work.

In case Jeremy indicates a high urgency I'm happy to to this minimal
NMU in between.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#892948: mark pygments packages Multi-Arch: foreign

[Helmut Grohne]

Source: pygments
Version: 2.2.0+dfsg-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:entropybroker src:gcc-python-plugin src:httping 
src:olm src:psensor src:witty

The affected packages cannot satisfy their cross Build-Depends, because
their dependency on python-pygments or python3-pygments is
unsatisfiable. In general, Architecture: all packages can never satisfy
cross Build-Depends unless marked Multi-Arch: foreign. I think that
marking these packages Multi-Arch: foreign is correct because:
 * All of them are Architecture: all.
 * All of their Depends are either annotated :any or marked Multi-Arch:
   foreign themselves.
 * While the maintainer scripts produce architecture-specific Python
   bytecode files, this bytecode matches whatever Python happens to be
   installed. Also Python modules can be used without pre-compiled
   bytecode files, so embedded interpreters for a foreign architecture
   (a very uncommon case) continue to work (albeit a bit slower).

Please consider applying the attached patch.

Helmut
diff --minimal -Nru pygments-2.2.0+dfsg/debian/changelog 
pygments-2.2.0+dfsg/debian/changelog
--- pygments-2.2.0+dfsg/debian/changelog2017-01-23 23:25:26.0 
+0100
+++ pygments-2.2.0+dfsg/debian/changelog2018-03-14 19:47:51.0 
+0100
@@ -1,3 +1,10 @@
+pygments (2.2.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark all packages Multi-Arch: foreign. (closes: #-1)
+
+ -- Helmut Grohne   Wed, 14 Mar 2018 19:47:51 +0100
+
 pygments (2.2.0+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru pygments-2.2.0+dfsg/debian/control 
pygments-2.2.0+dfsg/debian/control
--- pygments-2.2.0+dfsg/debian/control  2017-01-23 23:25:00.0 +0100
+++ pygments-2.2.0+dfsg/debian/control  2018-03-14 19:47:48.0 +0100
@@ -15,6 +15,7 @@
 
 Package: python-pygments
 Architecture: all
+Multi-Arch: foreign
 Depends: ${python:Depends}, ${misc:Depends}, ${sphinxdoc:Depends}
 Recommends: python-chardet, python-pkg-resources
 Suggests: ttf-bitstream-vera
@@ -32,6 +33,7 @@
 
 Package: python3-pygments
 Architecture: all
+Multi-Arch: foreign
 Depends: ${python3:Depends}, ${misc:Depends}
 Recommends: python3-pkg-resources
 Suggests: ttf-bitstream-vera
@@ -50,6 +52,7 @@
 Package: python-pygments-doc
 Section: doc
 Architecture: all
+Multi-Arch: foreign
 Priority: extra
 Depends: ${misc:Depends}, ${sphinxdoc:Depends}
 Recommends: python-pygments

Bug#803423: Unreproducible, moreinfo

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi! Are you still able to reproduce this bug?

Cheers, Lisandro.

-- 
Combata las características. Si una característica no es absolutamente
esencial, descártela, especialmente si tiene el mismo efecto que se
puede alcanzar mediante la combinación de otras características.
  Andrew S. Tanenbaum, de su libro "Computer Networks"

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#858294: Unreproducible, moreinfo needed

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 unreproducible moreinfo

Hi! I definitely can't reproduce this bug. Can you still reproduce it? Which 
Qt version are you currently using?

Thanks, Lisandro.

-- 
Alas, I am dying beyond my means.
  Oscar Wilde, as he sipped champagne on his deathbed

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#853831: Unreproducible, moreinfo

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi! I can no longer reproduce this bug. Are you still able to do it?


Kinds regards, Lisandro.

-- 
I still maintain the point that designing a monolithic kernel in 1991 is a
fundamental error.  Be thankful you are not my student.  You would not get a
high grade for such a design :-)
(Andrew Tanenbaum to Linus Torvalds)

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#818519: More info needed

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi! I can no longer reproduce this bug. Is it still valid for you?

Thanks, Lisandro.

-- 
8: Si un archivo ha pasado a la "Papelera de Reciclaje"
* Ud tiene una carpeta llamada "Papelera de Reciclaje"
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

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#886532: Coming updates for meltdown/spectre

[Laurent Bigonville]

On Sun, 7 Jan 2018 12:11:17 + Nigel Kukard  wrote:
>
> Is it going to be possible to include this patch in qemu please?
>
> https://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg00811.html
>
>
> ref: https://www.qemu.org/2018/01/04/spectre/
>

FTR this seems to be part of 2.11.1, would be nice to be fixed in 
unstable at least


I don't know if there are backports for this patch for the 2.8 branch 
used in stable

Bug#892947: Cannot start domain with Broadwell-IBRS CPU

[Laurent Bigonville]

Package: qemu-system-x86
Version: 1:2.11+dfsg-1
Severity: important

Hi,

On my laptop, libvirt is creating new domains with Broadwell-IBRS cpu.

But it seems that this CPU type is not recognized by qemu, looking at
the 2.11.1 release it seems that that new version is supporting it.

Could you please update to 2.11.1?

Kind regards

Laurent Bigonville

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20161027.b991c67-1
ii  libaio1 0.3.110-5
ii  libasound2  1.1.3-5
ii  libbluetooth3   5.47-1+b1
ii  libbrlapi0.65.6-2
ii  libc6   2.27-2
ii  libcacard0  1:2.5.0-3
ii  libfdt1 1.4.5-3
ii  libgcc1 1:8-20180312-2
ii  libglib2.0-02.54.3-2
ii  libgnutls30 3.5.18-1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libncursesw56.1-1
ii  libnettle6  3.4-1
ii  libnuma12.0.11-2.1
ii  libpixman-1-0   0.34.0-2
ii  libpng16-16 1.6.34-1
ii  libpulse0   11.1-4
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libsdl2-2.0-0   2.0.8+dfsg1-1
ii  libseccomp2 2.3.1-2.1
ii  libspice-server10.14.0-1
ii  libtinfo5   6.1-1
ii  libusb-1.0-02:1.0.21-2
ii  libusbredirparser1  0.7.1-1
ii  libvdeplug2 2.3.2+r586-2.1
ii  libxen-4.8  4.8.3+comet2+shim4.10.0+comet3-1+deb9u5
ii  libxenstore3.0  4.8.3+comet2+shim4.10.0+comet3-1+deb9u5
ii  qemu-system-common  1:2.11+dfsg-1
ii  seabios 1.10.2-1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  1:2.11+dfsg-1

Versions of packages qemu-system-x86 suggests:
ii  kmod  25-1
ii  ovmf  0~20180205.c0d9813c-1
pn  qemu-block-extra  
pn  samba 
ii  sgabios   0.0~svn8-4
pn  vde2  

-- no debconf information

Bug#892946: libfiu FTCBFS: unsatisfiable cross Build-Depends: python-all-dev

[Helmut Grohne]

Source: libfiu
Version: 0.95-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libfiu fails to cross build from source, because its python
Build-Depends are not installable. The attached patch updates the
Build-Depends for cross building. After doing so, libfiu still fails
(finding the soname of libc.so with a relatively unusual technique).
Please close this bug anyway when applying the attached patch. Thus the
next build failure becomes more visible.

Helmut
diff --minimal -Nru libfiu-0.95/debian/changelog libfiu-0.95/debian/changelog
--- libfiu-0.95/debian/changelog2017-07-25 22:51:44.0 +0200
+++ libfiu-0.95/debian/changelog2018-03-14 19:33:41.0 +0100
@@ -1,3 +1,10 @@
+libfiu (0.95-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Multiarchify Build-Depends. (closes: #-1)
+
+ -- Helmut Grohne   Wed, 14 Mar 2018 19:33:41 +0100
+
 libfiu (0.95-4) unstable; urgency=medium
 
   * Apply patch from Steve Langasek via Ubuntu to fix autopkgtests by using
diff --minimal -Nru libfiu-0.95/debian/control libfiu-0.95/debian/control
--- libfiu-0.95/debian/control  2017-07-25 22:51:44.0 +0200
+++ libfiu-0.95/debian/control  2018-03-14 19:33:39.0 +0100
@@ -5,9 +5,11 @@
 Build-Depends:
  debhelper (>= 9),
  dh-python,
- python-all-dev,
+ libpython-all-dev,
+ libpython3-all-dev,
+ python-all-dev:any,
  python-docutils,
- python3-all-dev
+ python3-all-dev:any
 Standards-Version: 3.9.8
 Homepage: http://blitiri.com.ar/p/libfiu/
 Vcs-Git: https://github.com/lamby/pkg-libfiu

Bug#892945: Cannot start domain using user session

[Laurent Bigonville]

Package: libvirt-daemon
Version: 4.0.0-2
Severity: serious

Hi,

I cannot start a domain using a libvirt user session. I'm getting the following 
message:

Impossible de terminer l’installation : « internal error: process exited while 
connecting to monitor: Could not access KVM kernel module: Permission denied
2018-03-14T18:32:12.683550Z qemu-system-x86_64: failed to initialize KVM: 
Permission denied »

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 2545, in 
_do_async_install
guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 498, in start_install
doboot, transient)
  File "/usr/share/virt-manager/virtinst/guest.py", line 434, in _create_guest
domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3659, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error: process exited while connecting to monitor: Could 
not access KVM kernel module: Permission denied
2018-03-14T18:32:12.683550Z qemu-system-x86_64: failed to initialize KVM: 
Permission denied

My user is part of the libvirt group. Is polkit somehow broken or something?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.12-3
ii  libaudit1   1:2.8.2-1
ii  libavahi-client30.7-3.1
ii  libavahi-common30.7-3.1
ii  libblkid1   2.31.1-0.5
ii  libc6   2.27-2
ii  libcap-ng0  0.7.7-3.1+b1
ii  libcurl3-gnutls 7.58.0-2
ii  libdbus-1-3 1.13.2-1bigon1
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  libfuse22.9.7-1
ii  libgnutls30 3.5.18-1
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.2.27-2
ii  libnl-route-3-200   3.2.27-2
ii  libnuma12.0.11-2.1
ii  libparted2  3.2-20
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.13.4-1+b2
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libselinux1 2.7-2+b1
ii  libssh2-1   1.8.0-1
ii  libudev1238-2
ii  libvirt04.0.0-2
ii  libxen-4.8  4.8.3+comet2+shim4.10.0+comet3-1+deb9u5
ii  libxenstore3.0  4.8.3+comet2+shim4.10.0+comet3-1+deb9u5
ii  libxml2 2.9.4+dfsg1-6.1
ii  libyajl22.1.0-2+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-6.1
ii  netcat-openbsd  1.187-1
ii  qemu-kvm1:2.11+dfsg-1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-sheepdog  
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   4.0.0-2
pn  numad   

-- no debconf information