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=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, );
+-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
 

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  

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

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=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=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=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