date:20190122

Hi Ben,

> I'm not sure what the NB refers to; that part of the changelog entry
> is exactly the difference I was pointing out. So we both seem to be
> directing each other's attention to the same thing :-)

Exactly; I was pointing it out to myself or the "next person" who also perhaps 
didn't immediately spot all that whitespace.

> > I don't believe Lintian should silence this and defer to whatever
> > happens to be reporting this (likely libdpkg-perl) […]
> 
> My Perl knowledge is too weak to debug this, so how would I diagnose
> where this behaviour in changelog parsing originates?

A quick glance at src:dpkg's changelog suggests #843248 is a good
place to start but I'll have to redirect you to the dpkg
maintainers on this angle.


Regards,

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

Bug#910451: closed by Petter Reinholdtsen (Fixed in version 0.5.0)

2019-01-22 Thread Petter Reinholdtsen

Control: notfound -1 0.4.12-2

I've asked upstream to have a look.

[Etienne Dechamps]
> In fact I had already verified that it still occurs in upstream
> 0.5.0 (see message #10).
> 
>   $ sox -n sine.wav synth 1 sine 1000
>   $ ffmpeg -i sine.wav sine.mp3
>   $ bs1770gain sine.mp3
>   analyzing ...
> [1/1] "sine.mp3": Segmentation fault (core dumped)

I tested this with bs1770gain version 0.4.12-2 in Debian Stable, and here
bs1770gain do not segfault when running the above commands.

-- 
Happy hacking
Petter Reinholdtsen

Bug#920184: lintian: incorrectly parses an unfinalised changelog entry

2019-01-22 Thread Ben Finney

On 22-Jan-2019, Chris Lamb wrote:
> Hi Ben,
> 
> > ipsum (3.4.5-2) UNRELEASED; urgency=medium
> > 
> >   * Lorem ipsum dolor sit amet, consectetur adipiscing elit.
> >   * Cras in sem consequat, consectetur ligula ac, volutpat nulla.
> > 
> >  --
>   ^
> 
> (NB. this bit is missing; the first time I saw your report I didn't
> see this and almost pinged you back with a "huh?" …!)

Yes, that is what constitutes an unfinalised changelog entry: no
maintainer or date value in the closing line.

I'm not sure what the NB refers to; that part of the changelog entry
is exactly the difference I was pointing out. So we both seem to be
directing each other's attention to the same thing :-)

> Anyway, fixed in Git, pending upload:

Thanks.

> I don't believe Lintian should silence this and defer to whatever
> happens to be reporting this (likely libdpkg-perl) […]

My Perl knowledge is too weak to debug this, so how would I diagnose
where this behaviour in changelog parsing originates?

-- 
 \ “Quidquid latine dictum sit, altum viditur.”  (“Whatever is |
  `\  said in Latin, sounds profound.”) —anonymous |
_o__)  |
Ben Finney

Bug#920232: cqrlog: CQRlog starts with a database connection error

2019-01-22 Thread Nate Bargmann

Package: cqrlog
Version: 2.3.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

Within the past day CQRlog was upgraded from 2.3.0 installed from the CQRlog
Web site.  Now the program will not start as it displays a message box titled,
"Error", which contains the folowing text:

'Error during connection to database: Can not load default MySQL library
("libmysqlclient.so.18" or "libmysqlclient.so"). Check your installation.'

A second dialong titled, "Database problem" with the text:

"MySQL could not be started, please check if the MySQL server is installed
properly.

Please look at https://www.cqrlog.com/faq

If you don't find the answer, ask in CQRLOG forum and attach last 20 lines from
the mysql.err file."

Closing that dialog results in the Database Connection dialog being opened, but
none of my logs are shown (of course).

The lastlines of mysql.err follow:

2019-01-22 16:44:53 140088679767360 [Note] InnoDB:
innodb_empty_free_list_algorithm has been changed to legacy because of small
buffer pool size. In order to use backoff, increase buffer pool at least up to 
20MB.

2019-01-22 16:44:53 140088679767360 [Note] InnoDB: Using mutexes to ref count
buffer pool pages
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: The InnoDB memory heap is
disabled
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: Mutexes and rw_locks use GCC
atomic builtins
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: GCC builtin
__atomic_thread_fence() is used for memory barrier
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: Compressed tables use zlib
1.2.11
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: Using Linux native AIO
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: Using SSE crc32 instructions
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: Initializing buffer pool,
size = 80.0M
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: Completed initialization of
buffer pool
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: Highest supported file format
is Barracuda.
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: 128 rollback segment(s) are
active.
2019-01-22 16:44:53 140088679767360 [Note] InnoDB: Waiting for purge to start
2019-01-22 16:44:53 140088679767360 [Note] InnoDB:  Percona XtraDB
(http://www.percona.com) 5.6.41-84.1 started; log sequence number 1745239
2019-01-22 16:44:53 140088679767360 [Note] Plugin 'FEEDBACK' is disabled.
2019-01-22 16:44:53 140088054904576 [Note] InnoDB: Dumping buffer pool(s) not
yet started
2019-01-22 16:44:53 140088679767360 [ERROR] Can't open and lock privilege
tables: Table 'mysql.servers' doesn't exist
2019-01-22 16:44:53 140088679767360 [Note] Server socket created on IP: '::'.
2019-01-22 16:44:53 140088679767360 [Warning] Can't open and lock time zone
table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without
them
2019-01-22 16:44:53 140088679369472 [Warning] Failed to load slave replication s
tate from table mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos' doesn't
exist
2019-01-22 16:44:53 140088679767360 [Note] Reading of all Master_info entries
succeded
2019-01-22 16:44:53 140088679767360 [Note] Added new Master_info '' to hash
table
2019-01-22 16:44:53 140088679767360 [Note] /usr/sbin/mysqld: ready for
connections.
Version: '10.1.37-MariaDB-3'  socket: '/home/nate/.config/cqrlog/database/sock'
port: 64000  Debian buildd-unstable
2019-01-22 17:00:27 140088679062272 [Note] /usr/sbin/mysqld: Normal shutdown
2019-01-22 17:00:27 140088117810944 [Note] InnoDB: FTS optimize thread exiting.
2019-01-22 17:00:27 140088679062272 [Note] InnoDB: Starting shutdown...
2019-01-22 17:00:28 140088679062272 [Note] InnoDB: Waiting for page_cleaner to
finish flushing of buffer pool
2019-01-22 17:00:30 140088679062272 [Note] InnoDB: Shutdown completed; log
sequence number 1745249
2019-01-22 17:00:30 140088679062272 [Note] /usr/sbin/mysqld: Shutdown complete


All dependencies and recommended packages are installed.

- - Nate


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

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

Versions of packages cqrlog depends on:
ii  default-mysql-client  1.0.4
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-5
ii  libcairo2 1.16.0-2
ii  libgdk-pixbuf2.0-02.38.0+dfsg-7
ii  libglib2.0-0  2.58.2-3
ii  libgtk2.0-0   2.24.32-3
ii  libhamlib-utils   3.3-5
ii  libhamlib23.3-5
ii  libpango-1.0-01.42.4-6
ii  libx11-6  2:1.6.7-1

Versions of packages cqrlog recommends:
ii  default-mysql-server  1.0.4
ii  xplanet   1.3.0-5.1

cqrlog suggests no packages.

- -- no debconf information

Bug#920225: pv: replace ash shell with dash

On 2019-01-22 19:56:33, Juan Picca wrote:
>> I see. But the script is not shipped with the pv binary package and is
>> unlikely to be ever called. At least it isn't called during build,
>> unless I'm mistaken...
>
> You are right in that, but if has sense that somebody (maybe a
> developer) execute `make index` i think that this patch equally apply.
> If not, please tell me and I close this bug.

Well, I don't think we should apply the patch just in the Debian
package. We should forward it upstream and see what they think
instead...

I can do that later or you can do it as well. :)

Cheers!

A.

-- 
The university must paint itself black, mulatto, worker anddd
peasant. If not, people will break down their doors and paint the
university the color they like.
- Ernesto "Che" Guevara

Bug#920231: bs1770gain: Segfault in av_packet_copy_props() on mp3

2019-01-22 Thread Petter Reinholdtsen



Package: bs1770gain
Version: 0.5.1-3

While using bs1770gain to measure the loudness of a lot of files, I ran
into a file causing bs1770gain to segfault.  This is the valgrind output
from the crash:

$ valgrind bs1770gain --xml --truepeak DTNormieS_01.mp3 
==24286== Memcheck, a memory error detector
==24286== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==24286== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==24286== Command: bs1770gain --xml --truepeak DTNormieS_01.mp3
==24286== 

  

==24286== Invalid read of size 4
==24286==at 0x4EDD7F4: av_packet_copy_props (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4EDDF82: av_packet_ref (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4F826C3: avcodec_send_packet (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4F84C22: ??? (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x111892: ??? (in /usr/bin/bs1770gain)
==24286==by 0x111EBF: ??? (in /usr/bin/bs1770gain)
==24286==by 0x1139ED: ??? (in /usr/bin/bs1770gain)
==24286==by 0x113ADD: ??? (in /usr/bin/bs1770gain)
==24286==by 0x4877932: sox_flow_effects (in 
/usr/lib/x86_64-linux-gnu/libsox.so.3.0.0)
==24286==by 0x110777: ??? (in /usr/bin/bs1770gain)
==24286==by 0x10E7C8: ??? (in /usr/bin/bs1770gain)
==24286==by 0x10C3F2: ??? (in /usr/bin/bs1770gain)
==24286==  Address 0x11de38b8 is 8 bytes inside a block of size 16 free'd
==24286==at 0x48369AB: free (vg_replace_malloc.c:530)
==24286==by 0x4EDCDE8: av_packet_free_side_data (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4EDD86C: av_packet_unref (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x112693: ??? (in /usr/bin/bs1770gain)
==24286==by 0x111EBF: ??? (in /usr/bin/bs1770gain)
==24286==by 0x1139ED: ??? (in /usr/bin/bs1770gain)
==24286==by 0x113ADD: ??? (in /usr/bin/bs1770gain)
==24286==by 0x4877932: sox_flow_effects (in 
/usr/lib/x86_64-linux-gnu/libsox.so.3.0.0)
==24286==by 0x110777: ??? (in /usr/bin/bs1770gain)
==24286==by 0x10E7C8: ??? (in /usr/bin/bs1770gain)
==24286==by 0x10C3F2: ??? (in /usr/bin/bs1770gain)
==24286==by 0x64DB09A: (below main) (libc-start.c:308)
==24286==  Block was alloc'd at
==24286==at 0x48356AF: malloc (vg_replace_malloc.c:298)
==24286==by 0x4837DE7: realloc (vg_replace_malloc.c:826)
==24286==by 0x4EDCF12: av_packet_add_side_data (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4EDCFDC: av_packet_new_side_data (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4EDD805: av_packet_copy_props (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4EDDF82: av_packet_ref (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4C7E24A: ??? (in 
/usr/lib/x86_64-linux-gnu/libavformat.so.58.20.100)
==24286==by 0x4C84563: av_read_frame (in 
/usr/lib/x86_64-linux-gnu/libavformat.so.58.20.100)
==24286==by 0x11269F: ??? (in /usr/bin/bs1770gain)
==24286==by 0x111EBF: ??? (in /usr/bin/bs1770gain)
==24286==by 0x1139ED: ??? (in /usr/bin/bs1770gain)
==24286==by 0x113ADD: ??? (in /usr/bin/bs1770gain)
==24286== 
==24286== Invalid read of size 4
==24286==at 0x4EDD7F8: av_packet_copy_props (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4EDDF82: av_packet_ref (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4F826C3: avcodec_send_packet (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4F84C22: ??? (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x111892: ??? (in /usr/bin/bs1770gain)
==24286==by 0x111EBF: ??? (in /usr/bin/bs1770gain)
==24286==by 0x1139ED: ??? (in /usr/bin/bs1770gain)
==24286==by 0x113ADD: ??? (in /usr/bin/bs1770gain)
==24286==by 0x4877932: sox_flow_effects (in 
/usr/lib/x86_64-linux-gnu/libsox.so.3.0.0)
==24286==by 0x110777: ??? (in /usr/bin/bs1770gain)
==24286==by 0x10E7C8: ??? (in /usr/bin/bs1770gain)
==24286==by 0x10C3F2: ??? (in /usr/bin/bs1770gain)
==24286==  Address 0x11de38bc is 12 bytes inside a block of size 16 free'd
==24286==at 0x48369AB: free (vg_replace_malloc.c:530)
==24286==by 0x4EDCDE8: av_packet_free_side_data (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x4EDD86C: av_packet_unref (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.58.35.100)
==24286==by 0x112693: ??? (in /usr/bin/bs1770gain)
==24286==by 0x111EBF: ??? (in /usr/bin/bs1770gain)
==24286==by 0x1139ED: ??? (in /usr/bin/bs1770gain)
==24286==by 0x113ADD: ??? (in /usr/bin/bs1770gain)
==24286==by 0x4877932: sox_flow_effects (in 
/usr/lib/x86_64-linux-gnu/libsox.so.3.0.0)
==24286==by 0x110777: ??? (in /usr/bin/bs1770gain)
==24286==by 0x10E7C8: ??? (in /usr/bin/bs1770gain)
==24286==by 0x10C3F2: ??? (in

Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config,version graph

2019-01-22 Thread Rolf Ade




After some more testing applied your patch. Thanks.

Bug#920225: pv: replace ash shell with dash

> I see. But the script is not shipped with the pv binary package and is
> unlikely to be ever called. At least it isn't called during build,
> unless I'm mistaken...

You are right in that, but if has sense that somebody (maybe a
developer) execute `make index` i think that this patch equally apply.
If not, please tell me and I close this bug.

Regards,
Juan Picca

Bug#920230: capnproto: executable installed in directory which breaks rdeps

2019-01-22 Thread Simon Quigley

Package: capnproto
Version: 0.7.0-1

Dear Maintainer,

I am currently packaging Mir for Debian, and I am getting the following
error on build, which is caused by your package:

Scanning dependencies of target mirudev
Scanning dependencies of target mircookie
/bin/sh: 1: /usr/lib/bin/capnp: not found

This is only present following the upload of 0.7.0-1 to Sid.

Could you consider installing this in /usr/bin/ instead?

More information is available here:
https://github.com/MirServer/mir/issues/680

Thanks.

-- 
Simon Quigley
tsimo...@debian.org
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#920229: ocaml-mode: Please convert to use dh-elpa

2019-01-22 Thread Nicholas D Steeves

Package: ocaml-mode
Version: 4.05.0-10
Severity: important

Dear OCaml Maintainers,

While working on #905940 I discovered that this package also needs to
be elpafied.  Please see that MR linked to from that bug for the
steps, documented as one-operation-per-commit and also in the
changelog.

The new bin:pkg name should be elpa-caml, and ocaml-mode should become
a dummy transitional package.

Please let me know at your earliest convenience if you will be able to
do this before the end of January.

Thank you,
Nicholas

Bug#919596: build-dependencies when crossbuilding choose-mirror

2019-01-22 Thread jhcha54008

Le samedi 19 janvier à 07h 48mn 18s (+0100), Cyril Brulebois a écrit :
> Hi JH,
> 
> jhcha54008  (2019-01-17):
> > Package: choose-mirror
> > Version: 2.96
> > Severity: wishlist
> > Tags: patch
> > 
> > Dear Maintainer,
> > 
> > Crossbuilding choose-mirror with dpkg-buildpackage -a  results in
> > an error at the present time.
> > 
> > It succeeds with the patch below.
> 
> I'd be happy to get a log for the failure and/or a complete description
> on how to reproduce it; a description of why the change is needed / how
> it works would also be welcome.
> 
> (No objections on the patch on its own, but not everyone is uptospeed
> regarding crossbuilding, so some details would be appreciated.)
> 
> 
> Thanks,
> -- 
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant


Hi,

Thank your for your answer. Here is a revised
version of the bug report. Thanks in advance
for your advice if there is a better way.

* Why cross-compile choose-mirror ?

The official debian-installer and udeb packages
are built on native buildds. It would be handy
to build on amd64 for testing purpose though - 
particularly when targeting some exotic 
architectures which might not exist yet for real
(e.g. riscvos. See [1])

It should be possible to cross-compile choose-mirror :
debian/rules defines the exported variables DEB_HOST_ARCH
and CROSS.

* What is the actual problem with choose-mirror ?

$ dpkg-buildpackage -a alpha -uc -us
[ ... ]
dpkg-checkbuilddeps: error: Unmet build dependencies: isoquery
[ ... ]

There is no 'Multi-Arch:' field in the debian/control file
of isoquery : isoquery:amd64 installed doesn't meet
the build dependency requirements of choose-mirror for alpha.

* How to reproduce the bug ?

Please find the details below with a minimal setup on amd64 
targeting alpha.

I hope it will help !

Regards,
JH Chatenet

[1] : http://lists.debian.org/debian-boot/2019/01/msg00044.html



1/ create a sid chroot with debootstrap --variant=buildd
  and an user 'me' :

 debootstrap --variant=buildd sid mychroot
 export LANG=C
 mount -t proc proc mychroot/proc
 chroot mychroot
 mount -t sysfs sysfs sys
 mount -t devpts devpts dev/pts -o gid=5,mode=620
 apt-get update && apt-get upgrade
 adduser me 

2/ install the toolchain

  apt-get install gcc-alpha-linux-gnu
 
3/ install the build dependencies (amd64 part)

 apt-get --no-install-recommends install fakeroot
 apt-get --no-install-recommends install debhelper debhelper wget po-debconf 
locales iso-codes isoquery

4/ install the build dependencies (alpha part)

 apt-get install debian-ports-archive-keyring
 cat > /etc/apt/sources.list.d/alpha.list  /etc/apt/sources.list.d/source.list ../choose-mirror_2.96_alpha.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: source-only upload: Debian-native package
$ echo $?
0

Bug#905940: Please resolve failing autopkgtests, preferably by converting to dh-elpa

2019-01-22 Thread Nicholas D Steeves

On Thu, Aug 16, 2018 at 10:10:10AM +0200, Ralf Treinen wrote:
> Hello,
> 
> On Sat, Aug 11, 2018 at 09:31:58PM -0400, Nicholas D Steeves wrote:
> > Package: tuareg-mode
> > Severity: important
> > 
> 
> > Would you please adapt tuareg-mode to the new
> > infrastructure?
> > 
> > In the case of irony-mode, the quick fix for autopkgtest on LXC was to
> > add "ert_eval = (require 'cl)" to debian/elpa-test; this was not
> > required for tests to pass on a real system or in any type of chroot.
> > The use of d/elpa-test requires converting the package to use dh-elpa
> > rather than legacy debian/emacsen.scripts.  In addition to the general
> > case of making src:packages maintenance less burdensome, using dh-elpa
> > appears to have insulated many packages from the breaking changes
> > recently introduced by emacs upgrades.
> > 
> > This action will also close #850071, #582981, because dh-elpa does not
> > support XEmacs.
> > 
> > Please let me know if I can be of any assistance :-)
> 
> If moving to dh-elpa allows us to get rid of the debian/emacsen.*
> scripts then I am all for it. However, I don't know anything about elpa
> and probably won't have the time to look into it for the next future,
> so patches are welcome!
> 
> -Ralf.

Hi Ralf,

Done.  Here's the MR:

  https://salsa.debian.org/ocaml-team/tuareg-mode/merge_requests/1

Please note that autopkgtests for Tuareg require one of:

1. ocaml-mode being elpafied too.
2. a manual workaround to pull in ocaml-mode to the autopkgtestbed.

I'm also unable to confirm whether the LXC+autopkgtest cl/cl-lib fix
is needed because of this blocker.

I hope my changelog and commit history shows how easy it will be to
convert ocaml-mode to elpa-caml <- not a typo.

  https://stable.melpa.org/#/caml

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#920228: lintian: Should locate/parse .buildinfo file if mentioned in .changes

Package: lintian
Version: 2.5.122
Severity: wishlist
X-Debbugs-CC: James Clarke 

Hi,

  < lamby> You should run [lintian] against .buildinfo vs .changes,
   that way it will add /one/ extra check

 < jrtc27> do you need to do that if the .changes file references
   the .buildinfo?

Currently yes, which means that most users are not having their
.buildinfo files analysed by Lintian.


Regards,

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

Bug#821408: Pam 1.3.0

2019-01-22 Thread Steve Langasek

On Tue, Jan 22, 2019 at 09:12:31PM +0100, Florian Vessaz wrote:
> We've got no reply from the current maintainers to this bug report since
> the approximately 2 and a half years it has been opened. I thus think
> it's safe to presume the current maintainers have no interest in keeping
> PAM up-to-date in Debian.

Wow, that's an incredible conclusion less than 2 weeks after a maintainer
upload.

It happens that fly-by NMUs are a lot less work than properly maintaining a
package.  So yes, there were a series of NMUs from developers who had no
investment in the long-term maintainability of the package in the time it
took me to get the VCS history converted into something supported and do a
maintainer upload.

(I appreciate your past efforts to handle this migration, but in your own
words "the history of the packaging is not pretty" and I was unwilling to
accept an incomplete history of the packaging.)

> The following points are taken from the Debian Developer's Reference
> document mentioned above:

> * NMUs, especially if there has been more than one NMU in a row.

>   Since the 18th of April 2016, date at which this bug was opened there was:

>   2016-06-02 1.1.8-3.3 NMU
>   2016-12-20 1.1.8-3.4 NMU
>   2017-01-04 1.1.8-3.5 NMU
>   2017-05-27 1.1.8-3.6 NMU
>   2018-02-07 1.1.8-3.7 NMU
>   2018-08-13 1.1.8-3.8 NMU
>   2019-01-09 1.1.8-4   upload by a maintainer

I think this is poorly worded in the DevRef.  Clearly the intent is that
there be several /unacknowledged/ NMUs.

Anyway, consider this an objection to salvaging of the pam package.

I am happy to take a look at your work to forward-port the patches onto pam
1.3.  Would you be willing to rebase
https://gitlab.gnugen.ch/fvessaz/pkg-pam.git onto
https://salsa.debian.org/vorlon/pam.git ?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

signature.asc
Description: PGP signature

Bug#918925: i3: Status and title bar text do not appear with default config file

2019-01-22 Thread Michael Stapelberg

[+cc pkg-raspi-maintainers, in case someone has seen this issue or a
similar issue before]

I can reproduce the problem on a Raspberry Pi 3B.

Interestingly enough, running i3 in xserver-xephyr on that machine makes it
display correctly, so the issue is not (just) a missing dependency.

My guess is that there is some issue related to the graphics driver.
Unfortunately, I can’t seem to use the “vesa” driver; Xorg finds no screens
when I try.

I haven’t yet figured out whether other programs are affected, too, or just
i3. I can say that awesome and geeqie seem to work.

On Fri, Jan 18, 2019 at 8:21 PM Leo Singer  wrote:

> Package: i3
> Version: 4.16-1
> Followup-For: Bug #918925
>
> Actually, removing the 'pango:' string from the font option is just causing
> it to fall back to the fixed-width X core font.
>
> I tried using a handful of other fonts, such as:
>
> font pango:Bistream Vera Sans Mono 8
>
> And it turns out that the title and status bar text are missing for *any*
> pango
> font option.
>
> I looked through ~/.xsession-errors and I did not see any font-related
> errors.
>
> [libi3] ../../i3-wm-4.16/libi3/font.c Using Pango font monospace, size
> 8
> 01/18/19 14:13:30 - dpi.c:init_dpi:41 - Resource Xft.dpi not
> specified, skipping.
> 01/18/19 14:13:30 - dpi.c:init_dpi:64 - Using fallback for calculating
> DPI.
> 01/18/19 14:13:30 - dpi.c:init_dpi:66 - Using dpi = 96
> 01/18/19 14:13:30 - main.c:main:561 - root_depth = 32, visual_id =
> 0x0077.
> 01/18/19 14:13:30 - main.c:main:563 - root_screen->height_in_pixels =
> 1080, root_screen->height_in_millimeters = 285
> 01/18/19 14:13:30 - main.c:main:564 - One logical pixel corresponds to
> 1 physical pixels on this display.
>

-- 
Best regards,
Michael

Bug#893227: libbluray FTBFS with openjdk-9

2019-01-22 Thread Emmanuel Bourg

Le 22/01/2019 à 23:26, Reinhard Tartler a écrit :

> Since openjdk-8 is going to be kept in Buster, I don't think
> we need to keep this bug at RC severity. I'm concerned that keeping
> this bug at RC severity might risk having libbluray being removed
> from testing, which I don't think is in the best interest of our
> users.

Well, the issue remains critical, because the package doesn't work with
the default JRE the users are going to use in Buster. OpenJDK 8 is not
to be used at runtime in Buster.

Emmanuel Bourg

Bug#919196: Debian bug when running unit tests

2019-01-22 Thread Pierre-Elliott Bécue

Le mardi 22 janvier 2019 à 02:50:48+0100, Pierre-Elliott Bécue a écrit :
> Le mardi 22 janvier 2019 à 01:57:22+0100, Pierre-Elliott Bécue a écrit :
> > Le lundi 21 janvier 2019 à 14:37:36+0100, Thomas Goirand a écrit :
> > > Hi,
> > > 
> > > Would you have any idea how to resolve this Debian bug?
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919196
> > > 
> > > I'm not sure, but to me, it looks like the unit tests are running in
> > > loop in the ::handshake() method.
> > 
> > The handshake fails, because gnutls doesn't accept the security level
> > offered by the handshake.
> > 
> > It seems to me the issue is in the next test: t->send is called, and
> > send is defined as a looping function until the decrypted content is
> > received. As the handshake previously failed, t->send waits forever.
> > 
> > I guess the tests should have a timeout method.
> > 
> > Anyway, increasing the security of the handshake would make it work and
> > hence the current issue should be gone.
> 
> I found out that a new upstream release includes fixes the security
> issue I mentioned before. Attempting to build this release works fine
> and the tests are passing without hanging.
> 
> I'm not certain whether the fix is due to the addition of
> 'gnutls_certificate_set_x509_system_trust( m_credentials );' to
> tlsgnutlsclient.cpp or to the changes made to
> 'gnutls_priority_set_direct' in tlsgnutls{server,client}anon.cpp.
> 
> This looks good to me.
> 
> Vincent, I made a NMU branch which is just a fast-forward of master on
> the salsa repo[0]. The branch name is 1.0.22-0.1
> 
> If you agree, I shall do an upload. Otherwise I'll let you taking care
> of it.
> 
> Best regards,
> 
> [0] https://salsa.debian.org/debian/gloox/commits/1.0.22-0.1

Hi,

I uploaded gloox 1.0.22-0.1 in DELAYED/7. Feel free to dcut rm if you're
not satisfied, or to speed up the upload if you think it's relevant.

Best regards,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#893227: libbluray FTBFS with openjdk-9

2019-01-22 Thread Reinhard Tartler

Control: severity -1 important

On Tue, Jan 22, 2019 at 7:48 AM Emmanuel Bourg  wrote:

> OpenJDK 8 will be kept in Buster but it should be used in exceptional
> cases (for example the lombok package requires both OpenJDK 8 and 11 to
> build). The default Java runtime for Buster is OpenJDK 11 and the
> packages have to work properly with it.
>

Thank you for this clarification. I agree that we should switch
to OpenJDK 11 as soon as there is an upstream version available
that allows this.

Since openjdk-8 is going to be kept in Buster, I don't think
we need to keep this bug at RC severity. I'm concerned that keeping
this bug at RC severity might risk having libbluray being removed
from testing, which I don't think is in the best interest of our
users.

-- 
regards,
Reinhard

Bug#920227: possible fix

Control: tags -1 +patch
Control: notfound -1 0.77.1-2
Control: found -1 0.78.0-2
Control: forwarded -1 https://salsa.debian.org/debian/sbuild/merge_requests/5

I have verified this is a regression from 0.77.1. I can also confirm
there is an easy fix, attached and forwarded.

Thanks to James Clark for the patch, described on #debian-devel. :)

Cheers,

A.
-- 
I've got to design so you can put it together out of garbage cans. In
part because that's what I started from, but mostly because I don’t
trust the industrial structure—they might decide to suppress us
weirdos and try to deny us the parts we need.
   - Lee Felsenstein
>From e3447e992c33f6162441aa757e2ab273afae2497 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Tue, 22 Jan 2019 17:16:05 -0500
Subject: [PATCH] fix syntax of generated Sources.gz files (Closes: #920227)

The rewrite of dpkg-scan* performed to fix #909847 introduced a
problem in 18f423619c176471d2adaafb7742cb204951a10c: Sources.gz
entries are not correctly separated by a newline. Furthermore, they
have Source: entries instead of Package:

This confuses older version of APT (previous to jessie) which have
extra sanity checks on the contents of those files, which breaks
building in older chroots.
---
 lib/Sbuild/ResolverBase.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/Sbuild/ResolverBase.pm b/lib/Sbuild/ResolverBase.pm
index 6399c350..71dda196 100644
--- a/lib/Sbuild/ResolverBase.pm
+++ b/lib/Sbuild/ResolverBase.pm
@@ -1412,6 +1412,7 @@ sub hash_file($$)
 	open my $in, '<', $entry or die "cannot open $entry";
 	while (my $line = <$in>) {
 	next if $line eq "\n";
+	$line =~ s/^Source:/Package:/;
 	print $out $line;
 	if ($line eq "Checksums-Sha1:\n") {
 		print $out " $sha1 $size $entry\n";
@@ -1439,6 +1440,7 @@ sub hash_file($$)
 	}
 	print $out "Directory: .";
 	print $out "\n";
+	print $out "\n";
 }
 close $out;
 closedir($dh);
-- 
2.20.1

Bug#914804: Should we close it?

2019-01-22 Thread Tomasz Rybak

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello.
Should we close this bug?
CUDA 9.2.148-5 is in unstable and testing - with proper libcuda1
dependency (if I understood changelog and control correctly).

BTW - PyCUDA (built for CUDA 9.1) migrated to testing.
Should I rebuild it with CUDA 9.2 and upload?

Best regards.

- -- 
Tomasz Rybak, Debian Developer 
GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE1bhtbqZEgXjcK9cyggqgxGY3jWkFAlxHki0ACgkQggqgxGY3
jWnI0xAAgJV8BgKGLOCF/2SnTfu/BVmje09ntxaJE0EbzSvQCpHY1U823J6qBWHF
qsOwJyNYCbR4rPXQ5zm/UNhW1J8SN8eJRFFRFUEF9Pv5dR/ktaYcJrPCuT+B3Z22
YYI0QZRol4o4BMeDxB3wq1MzRW/U8/evkaqr9D98DgQ3rv7q42f6wHmHrG+4TG09
treKyxV1MLeETB8vttcA2QWuvNL+JDCiaIWP07vlPHVGM0WjXvUYrCJ6PosiY1RR
jXsVeLnK/LcicjWLqIqmourTwwxdSynapgv/FjT2KONTfRcY962mCAhPEJqclL71
bPeMTyQXVldjzl98HN6Yn7bcKWjHWShU74mFZggTDLiMYQWJQAkhq5XF1eOKO0vQ
puF87A9IEuSr0FXV1cZCxZRwxCSAAUMxM6ss2JE9MQDlgBDaaYTQFL4+Xtv/mI79
/W4fUCBTo1DmJOvEG9HLEhBWsSTN/5C2dVeCuArz+W3GKKmY0SCuvsXGG5eh6Utb
eInd/VSKXB62zYP5Ikuu9k+m/jqOrhYnVhNmBLJn+n1UDBJdpjDLAJL5QFbWGwTD
xZt1xeBwoCY3X1S1jBLwNgLMFzH8fbUBLyyY/uOCVYnUBWWxbgjSYs8E3sTEOW5N
NvoOQ0G0j+Lh987BSSCtZRIWoUvH9y28Gz6zgzHiQNKtngj03jE=
=XKOF
-END PGP SIGNATURE-

Bug#920227: invalid file format generated for dependencies

2019-01-22 Thread Antoine Beaupre

Package: sbuild
Version: 0.78.0-2
Severity: grave
Tags: upstream

Since the 0.78 upgrade, sbuild cannot build packages in jessie (and
maybe other suites). The build during the setup phase, while trying to
install the build-dependencies, with this error message:

W: Failed to fetch 
gzip:/var/lib/apt/lists/partial/_build_systemd-asEYMr_resolver-48eHqy_apt%5farchive_._Sources.gz
 Invalid file format

It looks like the Sources.gz generated for the build-dependencies
resolver is incorrectly formatted, which freaks out apt in the chroot.

This does not happen with sbuild 0.77.1-2. This seems to be a
regression introduced in this commit:

https://salsa.debian.org/debian/sbuild/commit/18f423619c176471d2adaafb7742cb204951a10c

... which was implemented to close bug #909847. In there, sbuild
reimplements dpkg-scanpackages and dpkg-scansources internally, but it
seems to do so incorrectly.

Attached are the build logs and the faulty Sources.gz files.

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

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

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.78.0-2
ii  perl5.28.1-3

Versions of packages sbuild recommends:
ii  autopkgtest  5.8
ii  debootstrap  1.0.114
ii  schroot  1.6.10-6+b1

Versions of packages sbuild suggests:
ii  deborphan  1.7.31
ii  e2fsprogs  1.44.5-1
ii  kmod   25-2
ii  wget   1.20.1-1

-- debconf-show failed


sources.gz
Description: application/gzip
sbuild (Debian sbuild) 0.78.0 (09 January 2019) on curie.anarc.at

+==+
| systemd 215-17+deb8u9 (amd64)Tue, 22 Jan 2019 21:39:27 + |
+==+

Package: systemd
Version: 215-17+deb8u9
Source Version: 215-17+deb8u9
Distribution: UNRELEASED
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/jessie-amd64-sbuild-3b476c6c-1cda-4a37-bd77-e77297a487a8'
 with '<>'
I: NOTICE: Log filtering will replace 'build/systemd-x72Uu1/resolver-0MCIZ4' 
with '<>'

+--+
| Update chroot|
+--+

Ign http://deb.debian.org jessie InRelease
Hit http://security.debian.org jessie/updates InRelease
Hit http://deb.debian.org jessie-backports InRelease
Hit http://deb.debian.org jessie Release.gpg
Hit http://security.debian.org jessie/updates/main amd64 Packages
Get:1 http://deb.debian.org jessie-backports/main amd64 Packages/DiffIndex 
[27.8 kB]
Hit http://security.debian.org jessie/updates/contrib amd64 Packages
Hit http://deb.debian.org jessie Release
Hit http://security.debian.org jessie/updates/non-free amd64 Packages
Hit http://deb.debian.org jessie/main Sources
Hit http://deb.debian.org jessie/main amd64 Packages
Fetched 27.8 kB in 2s (12.7 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/anarcat/dist/systemd_215-17+deb8u9.dsc exists in /home/anarcat/dist; 
copying to chroot
I: NOTICE: Log filtering will replace 'build/systemd-x72Uu1/systemd-215' with 
'<>'
I: NOTICE: Log filtering will replace 'build/systemd-x72Uu1' with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>= 9), pkg-config, xsltproc, docbook-xsl, 
docbook-xml, gtk-doc-tools, m4, dh-autoreconf, automake (>= 1.11), autoconf (>= 
2.63), intltool, gperf, libcap-dev, libpam0g-dev, libaudit-dev, libdbus-1-dev 
(>= 1.3.2), libglib2.0-dev (>= 2.22.0), libcryptsetup-dev (>= 2:1.6.0), 
libselinux1-dev (>= 2.1.9), libacl1-dev, liblzma-dev, libgcrypt11-dev, 
libkmod-dev (>= 15), libblkid-dev (>= 2.20), libgirepository1.0-dev (>= 
1.31.1), gobject-introspection (>= 1.31.1), python3-all-dev, python3-lxml, 
libglib2.0-doc, build-essential, fakeroot

Bug#920225: pv: replace ash shell with dash

On 2019-01-22 18:42:38, Juan Picca wrote:
> Hi Antoine,
> Thanks for your fast response.
>
> The ash shell is not installed by default and the package pv (or its
> dependencies) don't depend of it.
> Due that, the script can fail if executed.
> Also, the ash package was supersedeed by dash and this is one of the
> few (less than ten) packages that uses it.

I see. But the script is not shipped with the pv binary package and is
unlikely to be ever called. At least it isn't called during build,
unless I'm mistaken...

A.

-- 
Quidquid latine dictum sit, altum sonatur.
Whatever is said in Latin sounds profound.

Bug#920153: kio-extras: MTP access mostly fails with Android device

2019-01-22 Thread Aurélien COUDERC

Hi,

Le 22/01/2019 à 15:58, Lisandro Damián Nicanor Pérez Meyer a écrit :
> tag 920153 upstream
> forwarded 920153 https://bugs.kde.org/show_bug.cgi?id=319880
> thanks
> 
> Hi Timo, thanks for the bug report! 
> 
> El martes, 22 de enero de 2019 05:59:37 -03 Timo Kalliomäki escribió:
>> Amending that this is possibly the same as
>> https://bugs.kde.org/show_bug.cgi?id=319880 which upstream reports as
>> fixed in 18.12.
> 
> I'm not entirely sure it has been fixed there, but at least I'm marking the 
> bug as forwarded.
> 
> According to the upstream bug some people manage to solve the issue by using 
> a 
> USB 2.0 port, but I don't think that will work for everyone, although I do 
> really hope I'm mistaken :-)

Quoting [1] :

MTP device handling has been rewritten, which fixes an enormous amount of bugs
(Andreas Krutzler, KDE Applications 18.12.0)

So it is the real fix and not a workaround like changing the type of USB ports.

I read somewhere (blog probably) the root cause was that concurrent access to
MTP devices was broken : as soon as you would ask for 2 actions they would be
sent in parallel to the device instead of being serialized and break the MTP
connection. But I can’t find the source anymore.


[1] 
https://pointieststick.com/2018/10/14/this-week-in-usability-productivity-part-40/


Cheers,
--
Aurélien
-- 
--
Aurélien COUDERC
Debian Developer

Bug#920225: pv: replace ash shell with dash

Hi Antoine,
Thanks for your fast response.

The ash shell is not installed by default and the package pv (or its
dependencies) don't depend of it.
Due that, the script can fail if executed.
Also, the ash package was supersedeed by dash and this is one of the
few (less than ten) packages that uses it.

Regards,
Juan Picca

On Tue, Jan 22, 2019 at 6:33 PM Antoine Beaupré  wrote:
>
> On 2019-01-22 18:18:00, Juan Picca wrote:
> > Package: pv
> > Version: 1.6.6-1
> > Severity: wishlist
> > Tags: patch
> >
> > Dear maintainer,
> >
> > One script in autoconf directory uses the ash shell, which is replaced
> > in debian with the dash shell.
> >
> > Regards,
> > Juan Picca
> > Description: Replace usage of ash with dash
> >  Replace usage of ash shell with dash (/bin/sh).
> > Author: Juan Picca 
> > Last-Update: 2019-01-22
> > ---
> > --- a/autoconf/scripts/index.sh
> > +++ b/autoconf/scripts/index.sh
> > @@ -1,4 +1,4 @@
> > -#!/bin/ash
> > +#!/bin/sh
> >  #
> >  # Script to generate an HTML index of all C code from the current directory
> >  # downwards (skipping directories ending in ~). The header comment in each
>
> Hi!
>
> Thanks for your bug report.
>
> Could you clarify what problem this patch fixes exactly?
>
> A.
>
> --
> L'adversaire d'une vraie liberté est un désir excessif de sécurité.
> - Jean de la Fontaine

Bug#920225: pv: replace ash shell with dash

On 2019-01-22 18:18:00, Juan Picca wrote:
> Package: pv
> Version: 1.6.6-1
> Severity: wishlist
> Tags: patch
>
> Dear maintainer,
>
> One script in autoconf directory uses the ash shell, which is replaced
> in debian with the dash shell.
>
> Regards,
> Juan Picca
> Description: Replace usage of ash with dash
>  Replace usage of ash shell with dash (/bin/sh).
> Author: Juan Picca 
> Last-Update: 2019-01-22
> ---
> --- a/autoconf/scripts/index.sh
> +++ b/autoconf/scripts/index.sh
> @@ -1,4 +1,4 @@
> -#!/bin/ash
> +#!/bin/sh
>  #
>  # Script to generate an HTML index of all C code from the current directory
>  # downwards (skipping directories ending in ~). The header comment in each

Hi!

Thanks for your bug report.

Could you clarify what problem this patch fixes exactly?

A.

-- 
L'adversaire d'une vraie liberté est un désir excessif de sécurité.
- Jean de la Fontaine

Bug#877507: ppx-core FTBFS: E: Cannot find external tool 'ocamlbuild'

2019-01-22 Thread Ralf Treinen

This can easily be fixed by adding ocamlbuild to the build-dependencies.
But then:

File "src/gen/common.ml", line 73, characters 24-34:
Error: This expression has type Types.constructor_arguments
   but an expression was expected of type Types.type_expr list
Command exited with code 2.

-Ralf

Bug#920226: gnome-menus: No menu categories displayed in budgie-desktop

2019-01-22 Thread David Mohammed

Package: gnome-menus
Version: 3.31.4-2
Severity: serious
Justification: Policy 1.1

Dear Maintainer,

   Testing on Ubuntu Budgie 19.04 which has a patched version of v3.31.4-2 
currently in Sid 
demonstrated a serious issue in budgie-desktop.  No menu categories were 
visible.
   
I then refreshed my Buster installation with the latest packages and confirmed 
that v3.31.4-2 had not yet migrated.
Budgie Desktop correctly displayed menu-categories.

I then downloaded the Sid version v3.31.4-2 gnome-menus and installed the 
binary.  Immediately no menu categories were visible
when the menu applet was opened.  I rebooted to confirm that the issue is still 
present.

I've marked this as Serious after consultation with Jeremy B (the last uploader 
of the package).

I have also tried reverting the "Sundry" menu handling in budgie-desktop - 
Sundry is a menu category that
has been removed by the new version of gnome-menus.  This has not resolved the 
issue.

Thus the problem is not immediately obvious to be due to budgie-desktop.


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

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

Versions of packages gnome-menus depends on:
ii  python3  3.7.1-3

gnome-menus recommends no packages.

gnome-menus suggests no packages.

-- no debconf information

Bug#914615: add alternate dependency for Ubuntu's lightning package name - NO

2019-01-22 Thread Mechtilde Stehmann

There is no package webext-tbsync in Ubuntu.

So no need to define such a dependency.

Kind regards
-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#920225: pv: replace ash shell with dash

Package: pv
Version: 1.6.6-1
Severity: wishlist
Tags: patch

Dear maintainer,

One script in autoconf directory uses the ash shell, which is replaced
in debian with the dash shell.

Regards,
Juan Picca
Description: Replace usage of ash with dash
 Replace usage of ash shell with dash (/bin/sh).
Author: Juan Picca 
Last-Update: 2019-01-22
---
--- a/autoconf/scripts/index.sh
+++ b/autoconf/scripts/index.sh
@@ -1,4 +1,4 @@
-#!/bin/ash
+#!/bin/sh
 #
 # Script to generate an HTML index of all C code from the current directory
 # downwards (skipping directories ending in ~). The header comment in each

Bug#919809: freedom-maker: please don't depend on pxz which shall be removed for buster

2019-01-22 Thread Sunil Mohan Adapa

tags 919809 + pending
stop

On Sat, 19 Jan 2019 18:42:53 + Holger Levsen  wrote:
> Package: freedom-maker
> Version: 0.22
> Severity: important
> block 919616 by -1
> 
> Dear maintainer,
> 
> freedom-maker currently depends on pxz, however even xz in Stretch now
> supports parallel compression with the -T switch. Therefore I would like
> to remove pxz from Buster, which is only possible if freedom-maker
> (and forensics-extra) drop the depends on pxz. See #919616.
> 
> Thanks for maintaining freedom-maker!
> 

Thank you for reporting this issue and pointing us towards xz -T. A fix
has been merged[1]. The fix will be released on 2019-01-29 as per our
bi-weekly release schedule and will migrate to testing 2-3 days after that.

Links:

1) https://salsa.debian.org/freedombox-team/freedom-maker/merge_requests/166

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#920224: dnsmasq: replace ash shell with dash

Package: dnsmasq
Version: 2.80-1
Severity: wishlist
Tags: patch

Dear maintainer,

One example in contrib directory uses the ash shell, which was
superseeded in debian with the dash shell.

Regards,
Juan Picca
diff -urN dnsmasq-2.80.orig/contrib/reverse-dns/README 
dnsmasq-2.80/contrib/reverse-dns/README
--- dnsmasq-2.80.orig/contrib/reverse-dns/README2018-09-17 
20:11:25.0 -0300
+++ dnsmasq-2.80/contrib/reverse-dns/README 2019-01-22 17:51:20.154630335 
-0300
@@ -14,5 +14,5 @@
 
 in the dnsmasq configuration.
 
-The script runs on debian (with ash installed) and on busybox.
+The script runs on debian (with dash installed) and on busybox.
 
diff -urN dnsmasq-2.80.orig/contrib/reverse-dns/reverse_replace.sh 
dnsmasq-2.80/contrib/reverse-dns/reverse_replace.sh
--- dnsmasq-2.80.orig/contrib/reverse-dns/reverse_replace.sh2018-09-17 
20:11:25.0 -0300
+++ dnsmasq-2.80/contrib/reverse-dns/reverse_replace.sh 2019-01-22 
17:51:28.178673463 -0300
@@ -1,4 +1,4 @@
-#!/bin/ash
+#!/bin/dash
 # $Id: reverse_replace.sh 18 2015-03-01 16:12:35Z jo $
 #
 # Usage e.g.: netstat -n -4 | reverse_replace.sh

Bug#917884: mate-dock-applet: Adding a new dock does nothing

2019-01-22 Thread Rock Storm

On Tue, Jan 22, 2019 at 10:25:24AM +, Mike Gabriel wrote:
> I think, the missing dependency is python3-dbus.
> 
> Do you think you can re-test the installation procedure, reproduce this bug
> and then try to install python3-dbus and see if that fixes things? If I

You are right. Went back to system status with the non-working mate
dock. Installed just 'python3-dbus' and dock was back again in the
panel. I wish I could provide some kind of tracebacks here but I'm
relying purely on whether I see the panel or not.

> The question is: is python3-dbus the only dep that is missing.

All I can say for certain is that 'python3-dbus' is the only dependency I
was missing. If another dependency is missing from the list but I happen
to have it installed by any chance, I could not say.

Thanks,

-- 
Rock Storm
GPG KeyID: 4096R/C96832FD
GPG Fingerprint:
 C304 34B3 632C 464C 2FAF  C741 0439 CF52 C968 32FD

signature.asc
Description: PGP signature

Bug#879164: Bug#878687: please drop transitional package libtime-modules-perl

2019-01-22 Thread gregor herrmann

On Fri, 20 Oct 2017 00:52:13 +0200, gregor herrmann wrote:

> Control: clone -1 -2 -3 -4
> Control: reassign -2 gitweb
> Control: reassign -3 dirvish
> Control: reassign -4 git
> Control: retitle -2 Please replace (build) dependency on libtime-modules-perl 
> with libtime-parsedate-perl
> Control: retitle -3 Please replace (build) dependency on libtime-modules-perl 
> with libtime-parsedate-perl
> Control: retitle -4 Please replace (build) dependency on libtime-modules-perl 
> with libtime-parsedate-perl
> Control: block -1 with -2 -3 -4
> Control: reassign -1 src:libtime-parsedate-perl
> 
> On Sun, 15 Oct 2017 22:06:27 +0200, Holger Levsen wrote:
> 
> > Please drop the transitional package libtime-modules-perl for buster,
> > as it has been released with jessie and stretch already.
> 
> Difficult:
> 
> % reverse-depends libtime-modules-perl
> Reverse-Recommends
> ==
> * gitweb
> 
> Reverse-Depends
> ===
> * dirvish
> 
> 
> % reverse-depends -b libtime-modules-perl 
> Reverse-Build-Depends-Indep
> ===
> * libnet-jabber-perl
> 
> Reverse-Build-Depends
> =
> * git

Hi dirvish maintainers,

sorry for not contacting you when reassigning the bug.

Would it be possible to
s/libtime-modules-perl/libtime-parsedate-perl/ in debian/control
before buster?


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: Bettina Wegner: die beiden


signature.asc
Description: Digital Signature

Bug#904374: screenie-qt: Should this package be removed?

control: severity -1 serious

On Mon, 23 Jul 2018 23:39:44 +0800 Boyuan Yang <073p...@gmail.com>
wrote:
> Source: screenie-qt
> Severity: important
> X-Debbugs-CC: panfa...@gmail.com
> 
> If you have any idea about screenie-qt's future maintenance in
Debian, please 
> feel free to share it. I'm tracking this package and will re-evaluate 
its 
> status before Debian Buster's freeze.

As there was no response I'm going to increase the severity to RC.
That means, if there is response to this bug, this package won't be
part of buster.

Additionally, if there is no answer to this bug, I will request removal
of this package in exactly 3 months. If you disagree, just fix #875179
and close this bug ;-)

Regards,
tobi (MIA Team)

Bug#879165: please drop transitional package libtime-modules-perl

2019-01-22 Thread gregor herrmann

On Mon, 21 Jan 2019 21:50:42 -0800, Jonathan Nieder wrote:

> Sorry I missed this.  For next time, please cc g...@packages.debian.org
> or git...@packages.debian.org when making such a reassignment to ensure
> the maintainer of the receiving package notices the bug.

Ack, sorry for missing the CC in this case.
 
> I'm applying the following now.  Thanks for your work, and apologies
> again for the delay,

Thanks for the upload right in time before buster.


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: U2: Van Diemen's Land


signature.asc
Description: Digital Signature

Bug#919996: gnat ftbfs on kfreebsd

2019-01-22 Thread Nicolas Boulenguez

> s-osinte.ads:445:07: warning: formal parameter "attr" is not referenced

Hello.

Why does a simple warning lets the build fail?

A quick search seems to show that pthread_mutex_* functions are now
available on freeBSD.

If so, replacing debian/patches/ada-kfreebsd.diff with the attached
version may fix the issue.

Else, it is sufficient to remove the short implementation in the
specification ("is (0)" in s-osint-freebsd.ads) with normal
implementations in the body declaring that the formal parameters are
not used:
   function Pthread_Mutex_Foo (Bla : in Int) is
  pragma Unreferenced (Bla);
   begin
  return 0;
   end Pthread_Mutex_Foo;
in s-osint-freebsd.adb. Ada requires no specific place in the body,
but gnat often sorts the implementations by alphabetical order.
Description: add support for GNU/kFreeBSD and GNU/Hurd.
 For now, it seems that BSD requires -lrt.
 It will be ignored on other platforms thanks to --as-needed.
Author: Ludovic Brenta 
Author: Nicolas Boulenguez 

--- a/src/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads
+++ b/src/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads
@@ -45,6 +45,7 @@ package System.OS_Interface is
pragma Preelaborate;
 
pragma Linker_Options ("-lpthread");
+   pragma Linker_Options ("-lrt");
 
subtype intis Interfaces.C.int;
subtype char   is Interfaces.C.char;
--- a/src/gcc/ada/gsocket.h
+++ b/src/gcc/ada/gsocket.h
@@ -253,6 +253,7 @@
 #endif
 
 #if defined (__FreeBSD__) || defined (__vxworks) || defined(__rtems__) \
+ || defined (__FreeBSD_kernel__) || defined(__GNU__) \
  || defined (__DragonFly__) || defined (__NetBSD__) || defined (__OpenBSD__)
 # define Has_Sockaddr_Len 1
 #else
--- a/src/gcc/ada/s-oscons-tmplt.c
+++ b/src/gcc/ada/s-oscons-tmplt.c
@@ -1705,6 +1705,7 @@ CND(CLOCK_THREAD_CPUTIME_ID, "Thread CPU
 
 #if defined(__linux__) || defined(__FreeBSD__) \
  || (defined(_AIX) && defined(_AIXVERSION_530)) \
+ || defined(__FreeBSD_kernel__) \
  || defined(__DragonFly__) || defined(__QNX__)
 /** On these platforms use system provided monotonic clock instead of
  ** the default CLOCK_REALTIME. We then need to set up cond var attributes

Bug#920223: gnome-keysign: fails to build because of test failures

2019-01-22 Thread Jeremy Bicha

Source: gnome-keysign
Version: 1.0.1-1
Severity: serious
Tags: ftbfs

gnome-keysign fails to build from source in a clean unstable chroot as
seen on Ubuntu and with Debian Reproducible Builds. The build tests
are failing.

By the way, I encourage you to do source-only uploads:
https://wiki.debian.org/SourceOnlyUpload

Build logs
-
https://launchpad.net/ubuntu/+source/gnome-keysign/1.0.1-1/+build/16309497
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gnome-keysign.html

Thanks,
Jeremy Bicha

Bug#821408: Pam 1.3.0

2019-01-22 Thread Florian Vessaz

Hi Andreas,

On Thu, Dec 06, 2018 at 11:44:14AM +0100, Andreas Henriksson wrote:
> Hi Florian,
> 
> On Mon, Dec 03, 2018 at 10:13:23PM +0100, Florian Vessaz wrote:
> [...]
> > I updated my Git repository such that it now contains pam 1.3.1, the
> > changes from the previous NMUs, your changes and additional small
> > changes to address some of the lintian warnings.
> 
> Thanks for doing that and for still being interested.
> I'll try to find time and motivation to look over your new version
> soon. (Please feel free to poke me if I seem to have forgotten about
> this.)

Thank you for trying. I suppose you might not have found the time or
might not have the motivation. Which is perfectly fine, there are no
obligations.

> [...]
> > I haven't really looked at the available options to get the changes
> > uploaded. So any pointers would be welcomed. :-)
> 
> I assume you're not a DD, so unless current pam maintainers show
> any interest I guess it's up to me to review your stuff and then
> I think it would be quite harmless if we upload it to experimental.

We've got no reply from the current maintainers to this bug report since
the approximately 2 and a half years it has been opened. I thus think
it's safe to presume the current maintainers have no interest in keeping
PAM up-to-date in Debian.

[...]
> Please see here if you're
> interested in the administrative details on how it should be
> done properly these days:
> 
> https://wiki.debian.org/PackageSalvaging
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging

The following points are taken from the Debian Developer's Reference
document mentioned above:

* NMUs, especially if there has been more than one NMU in a row.

  Since the 18th of April 2016, date at which this bug was opened there was:

  2016-06-02 1.1.8-3.3 NMU
  2016-12-20 1.1.8-3.4 NMU
  2017-01-04 1.1.8-3.5 NMU
  2017-05-27 1.1.8-3.6 NMU
  2018-02-07 1.1.8-3.7 NMU
  2018-08-13 1.1.8-3.8 NMU
  2019-01-09 1.1.8-4   upload by a maintainer

* Bugs filed against the package do not have answers from the maintainer.

  9 out of the 15 first bugs displayed on the BTS page appear to have
  been neglected for more than a year. I did not inspect the other bug
  reports.
  https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pam

   No answer since
  #917374  December 2018 Important
  #916169  December 2018 Important
  #914541  November 2018 Important
  #890626  February 2018 Normal
  #890524  February 2018 Important
  #889910  February 2018 Important
  #824607  May  2017 Normal
  #834589  August   2016 Important
  #332292  June 2013 Important
  #583958  May  2013 Normal
  #691008  October  2012 Normal
  #601825  November 2010 Important
  #569746  February 2010 Important
  #336513  October  2005 Important
  #182605  July 2008 Normal

* Upstream has released several versions, but despite there being a bug
  entry asking for it, it has not been packaged.

  This bug reports asked for an up-to-date version of PAM in April 2016.

  In February 2017, I proposed an updated package including PAM 1.3.0
  but no feedback was received from the maintainers.

  In December 2018, I proposed an updated package including PAM 1.3.1
  but no feedback was received from the maintainers.

  The version currently in Debian is 1.1.8 which has been released by
  upstream in September 2013.

So, it appears to me that the Package Salvaging process is applicable.
It's is however unclear to me if the Package Salvaging process can be
performed by someone like me who is not a DD or a DM. As it is defined
in the Debian Developer's Reference, I presume the process is to be
performed by a DD.

Is there a chance to get an up-to-date version of PAM in Buster?

Cheers,
-- Florian

signature.asc
Description: PGP signature

Bug#918106: logrotate: segfaults in rotateLogSet

2019-01-22 Thread Bernhard Übelacker

Control: fixed 918106 logrotate/3.14.0-4
Control: tags 918106 = upstream fixed-upstream


Dear Maintainer, Hello Marc,


> (gdb) print log->numFiles
> $1 = 2122453

> stack size  (kbytes, -s) 8192


That would match my assumption.
A maximum stack size of 8192 kb * 1024 / 4/*sizeof(int)*/ would
result in a maximum number of files allowed 2097152.
(If the program would not need any stack otherwise).
By having more files than that the callq instruction
tries to push the return address beyond the allowed stack
limits and crashes therefore.


I found upstream patches [1] and [2] that make the array logHasErrors
to be allocated from the heap instead of the stack, and should
therefore not fail that way. The patches seem not strictly
targeted to fix a crash instead should remove compiler warnings.

This patches are already contained in current buster/testing
release [3].
Therefore this crash should not happen with that version.

How this should be handled in stretch/stable is now up to
the maintainer, I guess.


Kind regards,
Bernhard


[1] 
https://github.com/logrotate/logrotate/commit/8ab56603fe700a2dfbf3c70112bd73b785aa12ef
[2] 
https://github.com/logrotate/logrotate/commit/5835875a945ce963f4cf29afc59f0a743824e8a6
[3] https://sources.debian.org/src/logrotate/3.14.0-4/logrotate.c/#L1964


Can be reproduced with following commands:

mkdir /tmp/testfiles
mount -t tmpfs -o size=500M,nr_inodes=300 tmpfs /tmp/testfiles
mkdir /tmp/testfiles/x
cd/tmp/testfiles/x
(for i in {0..230}; do echo $i.log; done) | xargs touch

cat < /tmp/testfiles/logrotate.conf
/tmp/testfiles/x/*.log
{
rotate 4
daily
missingok
notifempty
}
EOF

/usr/sbin/logrotate -f /tmp/testfiles/logrotate.conf
Speicherzugriffsfehler (Speicherabzug geschrieben)
# took 5 hours

[16996.303550] logrotate[14583]: segfault at 7ffd5e89d588 ip 
55a28985188a sp 7ffd5e89d590 error 6 in logrotate[55a289845000+11000]

root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE EXE
Tue 2019-01-22 21:17:36 CET   14583 0 0  11 present  
/usr/sbin/logrotate

(gdb) bt
#0  0x55a28985188a in rotateLogSet (log=0x55a28a3d6c80, force=1) at 
logrotate.c:1880
#1  0x55a28984898d in main (argc=, argv=) 
at logrotate.c:2561

(gdb) display/i $pc
1: x/i $pc
=> 0x55a28985188a :callq  0x55a28984cec0

Bug#920222: qemu: CVE-2019-6501: scsi-generic: possible OOB access while handling inquiry request

2019-01-22 Thread Salvatore Bonaccorso

Source: qemu
Version: 1:3.1+dfsg-2
Severity: important
Tags: patch security upstream
Control: forwarded -1 
https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg02324.html

Hi,

The following vulnerability was published for qemu.

CVE-2019-6501[0]:
scsi-generic: possible OOB access while handling inquiry request

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-2019-6501
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6501
[1] https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg02324.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#920220: apache2: CVE-2019-0190: mod_ssl 2.4.37 remote DoS when used with OpenSSL 1.1.1

2019-01-22 Thread Salvatore Bonaccorso

Source: apache2
Version: 2.4.37-1
Severity: grave
Tags: patch security upstream

Hi (Stefan),

I agree the severity is not the best choosen one for this issue, it is
more to ensure we could release buster with an appropriate fix already
before the release. If you disagree, please do downgrade.

The following vulnerability was published for apache2.

CVE-2019-0190[0]:
mod_ssl 2.4.37 remote DoS when used with OpenSSL 1.1.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-2019-0190
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0190
[1] https://marc.info/?l=oss-security=154817901921421=2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#920219: elpa-company: Post install script failing

2019-01-22 Thread Erich Beyer

Package: elpa-company
Version: 0.9.6-1
Severity: important

Dear Maintainer,

Before upgrading to sid, I had installed elpy using the instructions
at https://github.com/jorgenschaefer/elpy. After upgrading; and
attempting to use the apt-get install method, the post install script
fails during installation of the package elpa-company.

I was able to resolve the issue by temporarily moving my ~/.emacs.d/
directory to a different location. The previous elpa-company
installation at ~/.emacs.d/elpa/company-20190109.2336/ did not contain
the file "company-tests.el". The installation script
/usr/lib/emacsen-common/packages/install/elpa-company appears to use
the load-path of my user and find the company package in my home
directory instead of the
/usr/lib/emacsen-common/packages/install/elpa-company directory.

I am guessing this could be fixed by setting the load-path with an
eval statement in the emacs call of the
/usr/lib/emacsen-common/packages/install/elpa-company script?

I probably have to remove the melpa distributed company package from
my user's ~/.emacs.d/ directory to actually use the debian packaged
version.

Thanks,

Erich

$ sudo dpkg --configure -a
Setting up elpa-company (0.9.6-1) ...
+ [ configure = configure ]
+ [ -e /var/lib/emacsen-common/state/package/installed/emacsen-common -a -x 
/usr/lib/emacsen-common/emacs-package-install ]
+ /usr/lib/emacsen-common/emacs-package-install --postinst elpa-company
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install elpa-company for emacs
install/company-0.9.6: Handling install of emacsen flavor emacs
install/company-0.9.6: byte-compiling for emacs

In toplevel form:
async-tests.el:22:1:Error: Cannot open load file: No such file or directory, 
company-tests

In toplevel form:
bbdb-tests.el:22:1:Error: Cannot open load file: No such file or directory, 
company-tests

In toplevel form:
clang-tests.el:22:1:Error: Cannot open load file: No such file or directory, 
company-tests

In company-calculate-candidates:
company.el:1196:8:Warning: function company-calculate-candidates used to take
2 arguments, now takes 1

In toplevel form:
core-tests.el:22:1:Error: Cannot open load file: No such file or directory, 
company-tests

In toplevel form:
elisp-tests.el:24:1:Error: Cannot open load file: No such file or directory, 
company-tests

In toplevel form:
files-tests.el:22:1:Error: Cannot open load file: No such file or directory, 
company-tests

In toplevel form:
frontends-tests.el:22:1:Error: Cannot open load file: No such file or 
directory, company-tests

In toplevel form:
template-tests.el:22:1:Error: Cannot open load file: No such file or directory, 
company-tests

In toplevel form:
transformers-tests.el:22:1:Error: Cannot open load file: No such file or 
directory, company-tests
ERROR: install script from elpa-company package failed
dpkg: error processing package elpa-company (--configure):
 installed elpa-company package post-installation script subprocess returned 
error exit status 1
 dpkg: dependency problems prevent configuration of elpa-elpy:
  elpa-elpy depends on elpa-company (>= 0.9.2); however:
Package elpa-company is not configured yet.

dpkg: error processing package elpa-elpy (--configure):
 dependency problems - leaving unconfigured
 Errors were encountered while processing:
  elpa-company

$ find ~/.emacs.d/elpa/company-20190109.2336/ -iname "*.el"
~/.emacs.d/elpa/company-20190109.2336/company-xcode.el
~/.emacs.d/elpa/company-20190109.2336/company-files.el
~/.emacs.d/elpa/company-20190109.2336/company-ispell.el
~/.emacs.d/elpa/company-20190109.2336/company-nxml.el
~/.emacs.d/elpa/company-20190109.2336/company-css.el
~/.emacs.d/elpa/company-20190109.2336/company-eclim.el
~/.emacs.d/elpa/company-20190109.2336/company-etags.el
~/.emacs.d/elpa/company-20190109.2336/company-elisp.el
~/.emacs.d/elpa/company-20190109.2336/company-abbrev.el
~/.emacs.d/elpa/company-20190109.2336/company-clang.el
~/.emacs.d/elpa/company-20190109.2336/company-capf.el
~/.emacs.d/elpa/company-20190109.2336/company-bbdb.el
~/.emacs.d/elpa/company-20190109.2336/company-dabbrev.el
~/.emacs.d/elpa/company-20190109.2336/company-semantic.el
~/.emacs.d/elpa/company-20190109.2336/company-template.el
~/.emacs.d/elpa/company-20190109.2336/company-tng.el
~/.emacs.d/elpa/company-20190109.2336/company-yasnippet.el
~/.emacs.d/elpa/company-20190109.2336/company-autoloads.el
~/.emacs.d/elpa/company-20190109.2336/company-dabbrev-code.el
~/.emacs.d/elpa/company-20190109.2336/company.el
~/.emacs.d/elpa/company-20190109.2336/company-pkg.el
~/.emacs.d/elpa/company-20190109.2336/company-tempo.el
~/.emacs.d/elpa/company-20190109.2336/company-cmake.el
~/.emacs.d/elpa/company-20190109.2336/company-oddmuse.el
~/.emacs.d/elpa/company-20190109.2336/company-keywords.el
~/.emacs.d/elpa/company-20190109.2336/company-gtags.el

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

   * What led up to the situation?
   * What

Bug#920218: RFS: webcamoid/8.5.0+dfsg-1

2019-01-22 Thread Herbert Fortes

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "webcamoid".
  It is a upload to experimental. To test the new .symbols
  file, install via apt and run the software. My key is
  not in the archive yet.

  The new release closes two important bugs:

  https://github.com/webcamoid/webcamoid/issues/142
  https://github.com/webcamoid/webcamoid/issues/108



 * Package name: webcamoid
   Version : 8.5.0+dfsg-1
   Upstream Author : Gonzalo Exequiel Pedone 
 * URL : https://github.com/webcamoid/webcamoid
 * License : GNU General Public License v3.0
   Section : video

  It builds those binary packages:

akqml - full featured webcam capture application - qml module
libavkys-dev - full featured webcam capture application - dev
libavkys8  - full featured webcam capture application - library
webcamoid  - full featured webcam capture application
webcamoid-data - icons and locale files for webcamoid
webcamoid-plugins - full featured webcam capture application - plugins

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/w/webcamoid/webcamoid_8.5.0+dfsg-1.dsc

  More information about webcamoid can be obtained from 
https://github.com/webcamoid/webcamoid.

  Changes since the last upload:

  * New upstream version 8.5.0+dfsg
  * debian/control:
  - Update Build-Depends and Webcamoid pkg Depends
  - Bump Standards-Version from 4.2.1 to 4.3.0
  * debian/copyright:
  - Update year for myself and upstream
  * debian/clean:
  - Remove libAkQml.so file
  * debian/gbp.conf:
  - Remove sign-tags
  * debian/watch:
  - Add repacksuffix,repack,compression to opts
  - dversionmangle: remove number 1 from +dfsg
  * debian/patches:
  - Remove upstream patches
  - Add patch for .desktop file
  * Add new .symbols file
  * debian/webcamoid-data.install:
  - StandAlone does not have .json and effects.xml files



Regards,
Herbert

Bug#799986: xen-utils-common: please create /var/run/xen-hotplug from an init script

2019-01-22 Thread Russell Coker

On Wednesday, 23 January 2019 6:23:05 AM AEDT Hans van Kranenburg wrote:
> I'm hunting down old bug reports in the Xen packages, and also ran into
> this one. I see why it's useful.
> 
> I can see that current init scripts (well, for Xen 4.11) do create
> /run/xen, as wel as /run/xenstored/:
> 
> https://salsa.debian.org/xen-team/debian-xen/blob/master/debian/xen-utils-co
> mmon.xen.init#L67
> 
> https://salsa.debian.org/xen-team/debian-xen/blob/master/debian/xen-utils-co
> mmon.xen.init#L243
> 
> Do you think this is already enough?

That is good.  Also systemd-tmpfiles entries for those directories would be 
good, systemd-tmpfiles has internal support for restorecon which makes this 
easy.

> Can you please help us by confirming that any of the following scenarios
> does apply to your situation?
> 
> * I had this problem, and since upgrading to Stretch / Buster / ? it
> seems it was solved, and I forgot to report it again. Please close it,
> thanks.

Yes this seems to be solved.  I don't use Xen any more due to unrelated 
reasons, but from examining the code it seems fixed.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#920215: certtool: improve documentation for values of --key-type

2019-01-22 Thread Daniel Kahn Gillmor

Package: gnutls-bin
Version: 3.6.5-2
Severity: minor

In certtool(1), it says:

   --key-type=string
  Specify the key type to use on key generation.

  This option can be combined with --generate-privkey, to specify
  the key type to be generated. Valid options are, 'rsa',
  'rsa-pss',

there are more valid options than 'rsa' and 'rsa-pss' (e.g. i just
tested, and 'ed25519' works fine), but those are the only two listed
in the manpage.

   --dkg


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

Kernel: Linux 4.19.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)

Versions of packages gnutls-bin depends on:
ii  libc62.28-5
ii  libgmp10 2:6.1.2+dfsg-4
ii  libgnutls-dane0  3.6.5-2
ii  libgnutls30  3.6.5-2
ii  libhogweed4  3.4.1~rc1-1
ii  libidn2-02.0.5-1
ii  libnettle6   3.4.1~rc1-1
ii  libopts251:5.18.12-4
ii  libp11-kit0  0.23.14-2
ii  libtasn1-6   4.13-3
ii  libunistring20.9.10-1

gnutls-bin recommends no packages.

gnutls-bin suggests no packages.

-- no debconf information

Bug#920217: Updating the micropolis-activity Uploaders list

Source: micropolis-activity
Version: 0.0.20071228-9 0.0.20071228-8
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Kenshi Muto  has retired, so can't work on
the micropolis-activity package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.


signature.asc
Description: PGP signature

Bug#919951: Request about the /usr/bin/dune filename

2019-01-22 Thread Allison Randal

On Tue, 22 Jan 2019 14:45:36 + Anil Madhavapeddy 
wrote:
> Dear Debian project leader (CCed), we’ve resolved the rather
> simple technical matter in this thread amicably by directly
> communicating with the upstream software projects involved.

Glad to hear it, that's the way it should be. :)

> However, there are lots of references to what Debian ‘should’
> and ‘must’ do in the above quoted email, but very little clarity on
> Ian Jackson’s actual authority to speak for Debian.  Who is he,
> and is he speaking for the Debian project (with insults and all)?
> He appears to have resigned from the Debian Technical Committee
> some years back, but I am not familiar with the internal structure
> of your project.
[...]
> If he *doesn't* speak for Debian, then we’d love to be able to
> directly speak to whoever resolves these matters so that the
> hardworking Debian package maintainer for OCaml can get
> on with his volunteer efforts without being harassed by Ian Jackson.

As with many open source projects, Debian is a collection of volunteers
who each represent the project in various ways in the course of their
day-to-day contributions. We tend to be egalitarian, and while we have
governing bodies and a project leader, those are more of a last resort
when we can't sort things out any other way. Ian can speak for the
Debian project at times (as may any Debian Developer), but most of the
time he is expressing his own personal opinion. He is a long-term member
of the Debian project, and we greatly respect his opinion. But, even he
freely admits that he sometimes speaks more acerbically than the
situation merits.

> I hope that’s clear enough.

Same here, but if it's not, I'm happy to pop over to your office two
doors down to explain further. :)

Allison

Bug#920214: httpie: out of date, please update to 1.0.2

2019-01-22 Thread Thomas Ward

Package: httpie
Severity: wishlist

Dear Maintainer,

httpie is significantly out of date.  The version in Debian at present -
0.9.8-2 - was last updated in 2017.  Since then, there have been four
newer versions of HTTPie, the latest being 1.0.2.  This includes major
changes from HTTPie 1.0.0 which includes true/false values, style
values, default headers being incorrectly case-sensitive, TLS 1.3
support, etc.

As such, it would be beneficial to have httpie updated to 1.0.2 in Debian.


Thomas

Bug#491793: xen-hypervisor-3.2-1-i386: should update GRUB with a trigger

2019-01-22 Thread Hans van Kranenburg

tags 491793 + wontfix
thanks

Tagging wontfix since the bug it's blocked by is tagged wontfix.

Hans

Bug#799986: xen-utils-common: please create /var/run/xen-hotplug from an init script

2019-01-22 Thread Hans van Kranenburg

tags 799986 + moreinfo
thanks

Hi Russel,

I'm hunting down old bug reports in the Xen packages, and also ran into
this one. I see why it's useful.

I can see that current init scripts (well, for Xen 4.11) do create
/run/xen, as wel as /run/xenstored/:

https://salsa.debian.org/xen-team/debian-xen/blob/master/debian/xen-utils-common.xen.init#L67

https://salsa.debian.org/xen-team/debian-xen/blob/master/debian/xen-utils-common.xen.init#L243

Do you think this is already enough?

If not, I suspect it needs the help of someone who is actually using Xen
and SE Linux as combination to properly test other necessary changes.

And, now, I will still add my cleanup template:

Your bug report was targeted at a Xen package in a Debian distribution
older than the current stable (Stretch).

Can you please help us by confirming that any of the following scenarios
does apply to your situation?

* I had this problem a long time ago. It was never solved, but I found a
workaround, which is ...
* I had this problem a long time ago, and I solved it by not using Xen
any more, but by doing ...
* I still experience this problem, and I'm still using Xen
3.2/4.1/4.4/etc. I cannot upgrade to Debian Stretch or Buster because ...
* I had this problem, and since upgrading to Stretch / Buster / ? it
seems it was solved, and I forgot to report it again. Please close it,
thanks.
* Other: ...

Note that even if you found a solution, it's still very useful to report
it back to our bug tracker. There might be someone else running into the
same problem, who can be helped with your information.

Please note that unless there's a response within a month from now, we
will close the bug report. If you discover this message later, and this
case is important to you, then you can try unarchiving the bug and
replying to it, or reach out to the maintainers email list at
pkg-xen-devel at lists.alioth.debian.org (no subscription required) and
post a message.

Thanks,
Hans van Kranenburg

Bug#914788: Please don't enable getty services for tty devices that don't exist

2019-01-22 Thread Dmitry Bogatov

[2019-01-18 20:27] Andras Korn 
> sorry, didn't look at bug mail for a while.
>
> > > However, whenever the getty-run package is installed in a vserver, I have 
> > > to
> > > manually remove the /service/getty-tty* symlinks.
> > >
> > > Can you please modify the postinst script so it only installs getty 
> > > services
> > > for /dev/tty* devices that are actually there?
> > 
> > I do not like maintainer scripts. They are pain to get right.  I can
> > propose you to pre-provision your servers with
> > `/etc/sv/getty{1-6}-run/down' file. See runsv(8).
>
> That would still leave the runsv processes around and clutter the output of
> "sv status /service/*".
>
> The following postinst snippet should work:
>
> export NAME='getty-tty1'
> if [ -c /dev/tty1 ]; then
>   export ENABLE='yes'
> else
>   export ENABLE='no'
> fi
>
> # Unlike postrm, I can be sure, that runit-helper is present on
> # postinst.
> /lib/runit-helper/runit-helper postinst "$@"
>
> ... and so on for the other ttys. (A lesser man would have used a for loop. :)
>
> (Alternatively, the getty run scripts could start with something like this:
>
> [ -c /dev/ttyX ] || rm /etc/service/getty-ttyX
>
> and /etc/runit/1 could re-create these symlinks, just to be absolutely sure.
>
> I don't like this approach; there is too much going on automatically.)
>
> Or, you could add a debconf question with low priority, defaulting to "yes",
> on whether to add the getty service symlinks. I could pre-seed debconf in
> vservers with "no".

I believe I found quite decent solution. Take a look at `bugfix/914788'
branch.

Please,

 * build it (it will build runit-2.1.2-22, sorry for version havoc)
 * install bin:runit
 * install bin:getty-run
 * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file
 * did it help?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#903345: Do we need python-seqcluster (Python2) or is python3-seqcluster sufficient

2019-01-22 Thread Andreas Tille

Hi Steffen,

I was a bit scared that we have a non-installable package inside Debian
and thought it would be a good idea to have python-seqcluster quickly.
I realised that some of the (Build-)Depends are only available for
Python3.  Do we really need python-seqcluster for Python2 or can we
just drop that package (and the Python2 Build-Depends)?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#785687: Duplicate bug

2019-01-22 Thread Dmitry Bogatov



control: tags -1 +fixed-upstream
control: forcemerge 573571 -1

[2019-01-20 18:10] Jesse Smith 
> This report is a duplicate of bug #573571.
>
> It has been fixed upstream and the fix will appear in insserv-1.19.0.

Bug#920039: Fwd: Bug#920039: RFS: brightness-controller/2.2.3 [ITP]

2019-01-22 Thread Archisman Panigrahi

-- Forwarded message -
From: Archisman Panigrahi 
Date: Tue, Jan 22, 2019 at 8:15 PM
Subject: Re: Bug#920039: RFS: brightness-controller/2.2.3 [ITP]
To: Adam Borowski 


Hi,

I have uploaded version 2.2.3-1.
Now the /usr/bin calls the interpreter python to run
/usr/share/brightness-controller/init.py.

Thanks,
Archisman

On Tue, Jan 22, 2019 at 8:05 PM Adam Borowski  wrote:

> On Tue, Jan 22, 2019 at 07:54:45PM +0530, Archisman Panigrahi wrote:
> > On Tue, Jan 22, 2019 at 5:41 PM Adam Borowski 
> wrote:
> >
> > > On Tue, Jan 22, 2019 at 04:57:20PM +0530, Archisman Panigrahi wrote:
> > > > I am not sure about the native package issue. Has it got something to
> > > > do with /debian/source/format? I did not exactly understand what is
> > > > the difference between native and quilt, so went for native. Any
> > > > suggestion is welcome.
> > >
> > > The "native" format is adequate only when there's no separate upstream
> (and
> > > often not even then); in this case you are packaging Amit's software
> that
> > > has proper releases, tarballs, and all proper trappings.
> > >
> > > The packaging is supposed to be composed of two pieces:
> > > * the upstream (.orig) tarball
> > > * a packaging tarball, that includes the debian/ dir and a (possibly
> empty)
> > >   patch series
> > >
> > > This was somewhat different with the 1.0 format, but you don't want it
> --
> > > even if you (like me) despite quilt, the "3.0 (quilt)" format with a
> single
> > > patch is strictly better than 1.0.
> >
> > I am now using 3.0 (quilt). I have uploaded a new release (under the same
> > version number), please check.
> > There is some lintian error
> > "debian-changelog-version-requires-debian-revision". Is it due to the
> fact
> > that the debian/changelog in .orig.tar.gz
>
> Lintian has a nice set of explanations for its error messages, they get
> enables by "-I".  These tend to be better than one-paragraph responses
> reviewers like me reply with (even though an automated tool is not as good
> at understanding the context).
>
> In this case, the version number should end in "-1".
>
> > init.py calls other python files in usr/share/brightness-controller/ui
> and
> > usr/share/brightness-controller/util, so I want init.py
> > to be in usr/share/brightness-controller/ as well. Otherwise I will need
> to
> > import them across directories which I want to avoid.
>
> That's a Python specific question, I can't answer those.  I'm afraid that I
> need to pass you to other people on this mailing list.  If you happen to
> have any Perl questions, though...
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
> ⢿⡄⠘⠷⠚⠋⠀ for Privacy.
> ⠈⠳⣄

Bug#916456: dpkg: [dpkg-scanpackages] Calculates all supported checksums regardless of --hash= argument

Hi,

> dpkg: [dpkg-scanpackages] Calculates all supported checksums regardless of 
> --hash= argument

FYI this was implemented in:

  
https://git.dpkg.org/git/dpkg/dpkg.git/commit/?id=5d4ab4ae7d11c736bdabb51af4bc7e66c69cdd23


Regards,

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

Bug#920213: O: quelcom -- Command line editing tools for MP3 and WAV files

Package: wnpp

The current maintainer of quelcom, Devin Carraway ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: quelcom
Binary: quelcom
Version: 0.4.0-13
Maintainer: Devin Carraway 
Build-Depends: debhelper (>= 8.0.0), gettext, texinfo
Architecture: any
Standards-Version: 3.9.2
Format: 3.0 (quilt)
Files:
 47aebe12e7d27e650f63a520aa1869ad 1029 quelcom_0.4.0-13.dsc
 a681c06bcf6159f8540d64cf680e6661 171984 quelcom_0.4.0.orig.tar.gz
 caae2beab2a5cd957287d66cfe0e708c 29368 quelcom_0.4.0-13.debian.tar.gz
Checksums-Sha256:
 ab9956519e54c0ee4fe6845c641765dfb5ee285fcbf2f72b257b1d5be7f36a2c 1029 
quelcom_0.4.0-13.dsc
 314b3f6e5f14e8d90b828c9b13b2fa7c308828dbe8573f46b76e90fddcad2c4a 171984 
quelcom_0.4.0.orig.tar.gz
 4198a2434557eb80d53205ef1083a85da5cd37d6b0bac555fed438f56a094cc1 29368 
quelcom_0.4.0-13.debian.tar.gz
Package-List: 
 quelcom deb sound extra
Directory: pool/main/q/quelcom
Priority: source
Section: sound

Package: quelcom
Source: quelcom (0.4.0-13)
Version: 0.4.0-13+b2
Installed-Size: 604
Maintainer: Devin Carraway 
Architecture: amd64
Depends: dpkg (>= 1.15.4) | install-info, libc6 (>= 2.2.5), libgcc1 (>= 1:3.0), 
libstdc++6 (>= 5.2)
Description-en: Command line editing tools for MP3 and WAV files
 Quelcom provides assorted tools to perform simple editing
 operations on MP3 and WAV audio files.  These include
 fading, check-and-clean, informational extraction and
 lossless cutting and joining without reencoding.
Description-md5: 1dba58d8e3947d95a44d9a8a592c96b4
Tag: interface::commandline, role::program, role::shared-lib, scope::utility,
 use::editing, works-with-format::mp3, works-with-format::oggvorbis,
 works-with-format::wav, works-with::audio
Section: sound
Priority: optional
Filename: pool/main/q/quelcom/quelcom_0.4.0-13+b2_amd64.deb
Size: 138630
MD5sum: dc87bf0c3f97f822025e23d0842b4597
SHA256: a84e7f05d690453ee608fa55f1e8577f28e6dfab376479c234ad085ef999a395

Bug#920211: O: sawfish-themes -- Themes for the Sawfish window manager

Package: wnpp

The current maintainer of sawfish-themes, Devin Carraway ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: sawfish-themes
Binary: sawfish-themes
Version: 0.13
Maintainer: Devin Carraway 
Build-Depends: debhelper (>= 9), quilt
Architecture: all
Standards-Version: 3.9.3
Format: 3.0 (native)
Files:
 3709c54d856d21c82a0a46e71a173edb 780 sawfish-themes_0.13.dsc
 049d4c3c440c3c9f677645bcd9bc8726 633341 sawfish-themes_0.13.tar.gz
Checksums-Sha256:
 6852d23ea26ea23b9658452afef7106ac8a3ec9d3c04af8e38f631b5627b928d 780 
sawfish-themes_0.13.dsc
 0c04b08e201aacd424283281358c0d6402c9b5b34b5df41ad4539654d52395ca 633341 
sawfish-themes_0.13.tar.gz
Package-List: 
 sawfish-themes deb x11 extra
Directory: pool/main/s/sawfish-themes
Priority: source
Section: x11

Package: sawfish-themes
Version: 0.13
Installed-Size: 1336
Maintainer: Devin Carraway 
Architecture: all
Depends: sawfish (>= 1:1.1a)
Recommends: xfonts-base, xfonts-75dpi | xfonts-100dpi
Description-en: Themes for the Sawfish window manager
 This package contains contributed themes for Sawfish; they can be used
 to alter the appearance and some behavioral aspects of your Sawfish
 windows.
 .
 After installation, sawfish themes may be selected from the "Appearance"
 section of the Sawfish configurator, or from the "Frame Style" submenu
 of any particular window menu.
Description-md5: ce903570a3ae281b31a3a7f4587ca8c4
Tag: made-of::icons, role::app-data, x11::theme
Section: x11
Priority: optional
Filename: pool/main/s/sawfish-themes/sawfish-themes_0.13_all.deb
Size: 616582
MD5sum: 53abb69f8e3b489917f47ce10da03952
SHA256: 94b8db61addde3bfff58bd06e12d9524ea61e8990785080de6b0097dcd054251

Bug#920210: O: pidgin-librvp -- MS Exchange RVP instant messaging plugin for Pidgin

Package: wnpp

The current maintainer of pidgin-librvp, Devin Carraway ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: pidgin-librvp
Binary: pidgin-librvp
Version: 0.9.7cvs-1
Maintainer: Devin Carraway 
Build-Depends: debhelper (>> 9), pidgin-dev (>= 2.0.1), libgtk2.0-dev, 
libxml2-dev, autotools-dev, libgcrypt-dev
Architecture: any
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 1cf91b32bde9e7f8bba4729c8f58fc6c 1782 pidgin-librvp_0.9.7cvs-1.dsc
 d49ee28a69356f17c7355427c50e9ce2 478193 pidgin-librvp_0.9.7cvs.orig.tar.gz
 76df8cebe1158d8dc67fef858eaabc3f 5196 pidgin-librvp_0.9.7cvs-1.debian.tar.xz
Checksums-Sha256:
 352009f485bb518f0653e01ec474b05ad46e3e25793e972237379798aa458f90 1782 
pidgin-librvp_0.9.7cvs-1.dsc
 6a55472a51c96b1ea63024e9aedf2a489d974a7a1d15b18d4a4733ede21794fc 478193 
pidgin-librvp_0.9.7cvs.orig.tar.gz
 6f2889b00d33990b7368632fe5a51c6a7d633ccffbc5e1a06ff9bdcd111a3572 5196 
pidgin-librvp_0.9.7cvs-1.debian.tar.xz
Package-List: 
 pidgin-librvp deb net extra arch=any
Directory: pool/main/p/pidgin-librvp
Priority: source
Section: net

Package: pidgin-librvp
Binary: pidgin-librvp
Version: 0.9.7cvs-1.1
Maintainer: Devin Carraway 
Build-Depends: debhelper (>> 9), pidgin-dev (>= 2.0.1), libgtk2.0-dev, 
libxml2-dev, autotools-dev, libgcrypt-dev
Architecture: any
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 7a3c8f307a243270924048586bf735ed 1812 pidgin-librvp_0.9.7cvs-1.1.dsc
 d49ee28a69356f17c7355427c50e9ce2 478193 pidgin-librvp_0.9.7cvs.orig.tar.gz
 88ce703beb5ded832ceac34157e1c2ff 5304 pidgin-librvp_0.9.7cvs-1.1.debian.tar.xz
Checksums-Sha256:
 a046a201a8b26ed748bd2b4c30a85dcf142669c4bd511a86b3717e57f486cc32 1812 
pidgin-librvp_0.9.7cvs-1.1.dsc
 6a55472a51c96b1ea63024e9aedf2a489d974a7a1d15b18d4a4733ede21794fc 478193 
pidgin-librvp_0.9.7cvs.orig.tar.gz
 cc40ffa8eee590724797e139acb3b9b1eec5474a83b393df3b2902c1d447c77b 5304 
pidgin-librvp_0.9.7cvs-1.1.debian.tar.xz
Package-List: 
 pidgin-librvp deb net extra arch=any
Directory: pool/main/p/pidgin-librvp
Priority: source
Section: net

Package: pidgin-librvp
Version: 0.9.7cvs-1.1
Installed-Size: 426
Maintainer: Devin Carraway 
Architecture: amd64
Replaces: gaim-librvp (<< 0.9.5-2)
Provides: gaim-librvp
Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo2 (>= 1.2.4), 
libfontconfig1 (>= 2.11), libfreetype6 (>= 2.2.1), libgcrypt20 (>= 1.7.0), 
libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 
2.8.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), 
libpangoft2-1.0-0 (>= 1.14.0), libpurple0 (>= 2.6.0), libxml2 (>= 2.7.4), 
pidgin (<< 3.0), pidgin (>= 2.12)
Enhances: pidgin
Conflicts: gaim-librvp (<< 0.9.5-2)
Description-en: MS Exchange RVP instant messaging plugin for Pidgin
 librvp is a plugin for Pidgin which implements the RVP protocol
 used by Microsoft Exchange and its Windows Messenger client.
 .
 This is not an MSN Messenger protocol plugin; for that, see the
 main Pidgin package.
Description-md5: 06296c6c52e9511e7af8f9e72c1f5c50
Homepage: http://www.waider.ie/hacks/workshop/c/rvp/
Tag: role::plugin, uitoolkit::gtk
Section: net
Priority: optional
Filename: pool/main/p/pidgin-librvp/pidgin-librvp_0.9.7cvs-1.1_amd64.deb
Size: 141294
MD5sum: 9238a4b516f339c8abd0ad346af624c9
SHA256: 3973758b697d74f7998ad8de40945d890a2c042ce5db0960e549aeeaf97024d7

Package: pidgin-librvp
Version: 0.9.7cvs-1.1
Installed-Size: 426
Maintainer: Devin Carraway 
Architecture: amd64
Replaces: gaim-librvp (<< 0.9.5-2)
Provides: gaim-librvp
Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo2 (>= 1.2.4), 
libfontconfig1 (>= 2.11), libfreetype6 (>= 2.2.1), libgcrypt20 (>= 1.7.0), 
libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 
2.8.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), 
libpangoft2-1.0-0 (>= 1.14.0), libpurple0 (>= 2.6.0), libxml2 (>= 2.7.4), 
pidgin (<< 3.0), pidgin (>= 2.12)
Enhances: pidgin
Conflicts: gaim-librvp (<< 0.9.5-2)
Description-en: MS Exchange RVP instant messaging plugin for Pidgin
 librvp is a plugin for Pidgin which implements the RVP protocol
 used by Microsoft Exchange and its Windows Messenger client.
 .
 This is not an MSN Messenger protocol plugin; for that, see the
 main Pidgin package.
Description-md5: 06296c6c52e9511e7af8f9e72c1f5c50
Homepage: http://www.waider.ie/hacks/workshop/c/rvp/
Tag: role::plugin, uitoolkit::gtk
Section: net
Priority: optional
Filename: pool/main/p/pidgin-librvp/pidgin-librvp_0.9.7cvs-1.1_amd64.deb
Size: 141294
MD5sum: 9238a4b516f339c8abd0ad346af624c9
SHA256: 3973758b697d74f7998ad8de40945d890a2c042ce5db0960e549aeeaf97024d7



signature.asc
Description:

Bug#920212: O: libclamav-client-perl -- Perl client for the ClamAV virus scanner daemon

Package: wnpp

The current maintainer of libclamav-client-perl, Devin Carraway 
,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: libclamav-client-perl
Binary: libclamav-client-perl
Version: 0.11-2
Maintainer: Devin Carraway 
Build-Depends: debhelper (>= 7.0), libmodule-build-perl
Architecture: all
Standards-Version: 3.9.2
Format: 3.0 (quilt)
Files:
 043b026321fed37ebcad0372011c9da7 1136 libclamav-client-perl_0.11-2.dsc
 1997e47f068419c63b151c673f1da5e5 8663 libclamav-client-perl_0.11.orig.tar.gz
 8d8b2ffd5e95a64e16e03026d1725388 1899 
libclamav-client-perl_0.11-2.debian.tar.gz
Checksums-Sha256:
 29cb872cf038b2f73fa52648322c0d5de61cb6a940f56f19a4760cbb5ffefb50 1136 
libclamav-client-perl_0.11-2.dsc
 7c62d27a295fd999c9f1485c3ae6e3be976b78d628eef4f6dc0dba21bd8670d8 8663 
libclamav-client-perl_0.11.orig.tar.gz
 a2ce1ce1a992f186d9dbcfa824ea43fd45fd542a687d082434d1fe3fa3858de9 1899 
libclamav-client-perl_0.11-2.debian.tar.gz
Package-List: 
 libclamav-client-perl deb perl extra
Directory: pool/main/libc/libclamav-client-perl
Priority: source
Section: perl

Package: libclamav-client-perl
Version: 0.11-2
Installed-Size: 66
Maintainer: Devin Carraway 
Architecture: all
Depends: perl, liberror-perl
Suggests: clamav-daemon
Description-en: Perl client for the ClamAV virus scanner daemon
 This package supplies ClamAV::Client, a Perl interface to
 the ClamAV virus scanner via the clamd daemon.  It allows
 connection either over a UNIX domain socket to a local
 clamd, via TCP to a remote one.
 .
 The client package fully implements the clamd socket protocol,
 with both scanning and daemon management calls provided.
Description-md5: 532095d788f927200bfe012b59b72ae8
Homepage: http://search.cpan.org/dist/ClamAV-Client/
Tag: devel::lang:perl, devel::library, implemented-in::perl,
 security::antivirus
Section: perl
Priority: optional
Filename: 
pool/main/libc/libclamav-client-perl/libclamav-client-perl_0.11-2_all.deb
Size: 13834
MD5sum: bde5e93c52690386f0128ecd25903b22
SHA256: e8cc010476ebc8e7cd2ffe2660c18389e65abdd19bb48eb1857fc22a2488c193

Bug#920184: lintian: incorrectly parses an unfinalised changelog entry