Bug#809768: RFS: kbibtex/0.6+git7fdc0cd97c093f-1

[Bastien ROUCARIÈS]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

Package name: kbibtex
Version : 0.6+git7fdc0cd97c093f-1
Section : kde

It builds those binary packages:

 kbibtex- BibTeX editor for KDE
 kbibtex-data - BibTeX editor for KDE -- common data

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

  http://mentors.debian.net/package/kbibtex


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

dget -x 
http://mentors.debian.net/debian/pool/main/k/kbibtex/kbibtex_0.6+git7fdc0cd97c093f-1.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

  * New upstream release from git (Closes: #742974).
  * Use Qt5 (Closes: #784475).
  * Bug fix: "fails to get any entry from a valid .bib file (works with
0.2.3.90-1)", thanks to y...@onerussian.com (Closes: #689310).
  * Upload to experimental due to using internal embedded
qoauth and libqxt (part) not yet compiled for qt5.
  * Move arch all data to kbibtex-data.
  * Bump policy and upgrade debian package.



  Regards,
   bastien roucaries

Bug#808043: linux-image-4.3.0-1-powerpc64: Fail to load md_mod with unknow symbol error

[Gianluca GP Renzi]

Nope. It does not work. Compiling 4.3.3 using  the latest binutils leads to the 
same problem. Why?

Christian Marillat  ha scritto:

>On 15 déc. 2015 19:12, Ben Hutchings  wrote:
>
>[...]
>
>> OK, so everything is failing because the 'mcount' symbol (used for
>> function tracing) is not found.  It is supposed to be exported from
>> vmlinux.  Comparing the two versions, there's no difference (aside from
>> addresses) in the symbols related to mcount, so I think there's a
>> deeper problem in the module loader.
>
>Thanks for the precise analysis of the bug report.
>
>Christian
>

Bug#763874: Fixed with version 1.8.2

[pada]

Package: pepperflashplugin-nonfree
Followup-For: Bug #763874

Dear Maintainer,

this issue has been fixed with version 1.8.2

Regards
Daniel

Bug#805087: Please change the qt5 suffix from -qt5 to 5

[Stefan Ahlers]

Hi Andreas,

I've updated the debian files and I decided to use quazip 0.7.1 and
patch the CMakeLists.text files instead of using a development release.

Furthermore, I was not able to install the FindQuaZip.cmake file,
because it is not allowed to ship a "Find module". (lintian error:
https://lintian.debian.org/tags/package-contains-cmake-private-file.html).

I've also added a new package called libquazip-qt5-headers to provide
the headers for the Qt5 library.

I hope I have uploaded the changes correctly to the git repository. For
me the package works, please test the changes.

Kind regards,
Stefan

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Norbert Preining]

> BTW - where do you get newer versions ???

I guess from TeX Live sources ... this is what I thought, there
seems to be no other uptodate repository.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#809769: roundcube: Error log is filled with messages that config file cannot be loaded

[Dmitry Katsubo]

Package: roundcube
Version: 1.1.4+dfsg.1-1
Severity: minor

The error log of roundcube (/var/log/roundcube/error) has a lot of message like 
that:

> [03-Jan-2016 20:43:38 +0100]:  PHP Error: Failed to load config 
> from /var/lib/roundcube/plugins/zipdownload/config.inc.php in 
> /usr/share/roundcube/program/lib/Roundcube/rcube_plugin.php on line 157 (GET 
> /roundcube/)
> [03-Jan-2016 20:43:38 +0100]:  PHP Error: Failed to load config 
> from /var/lib/roundcube/plugins/jqueryui/config.inc.php in 
> /usr/share/roundcube/program/lib/Roundcube/rcube_plugin.php on line 157 (GET 
> /roundcube/)

The mentioned config files exist, but are empty (perhaps that is the reason of 
the error).

-- 
With best regards,
Dmitry

Bug#809778: elki: Depend on java7-runtime instead of openjdk-7-jre

[Emmanuel Bourg]

Source: elki
Version: 0.7.0-1
Severity: normal

Dear Maintainer,

elki and elki-dev depend on default-jre (>= 1.7) | openjdk-7-jre,
it would be better to replace openjdk-7-jre with java7-runtime
to allow the use of alternative JREs such as the Oracle Java
packages generated by java-package.

Also, the versionned dependency for default-jre should be (>= 2:1.7),
otherwise default-jre 2:1.5 as found on architectures without OpenJDK
(currently hurd, sparc64, m68k and hppa) will satisfy the dependency
but won't be able to run elki (we really need a Lintian warning
about this).

Emmanuel Bourg

Bug#809779: libavutil-dev: Memory Leak in buffer

[Leszek Lesner (Web.de)]

Package: libavutil-dev
Version: 6:10.1-1~bpo70+1
Severity: important
Tags: patch

There is a memory leak that leads to players using libav hogging memory like
crazy until RAM and Swap is full and OOM Killer kicks in when playing back
streaming media.

This bug was reported here for mpv and turned out to be a memory leak in 
libav:
https://github.com/mpv-player/mpv/issues/1204

It is fixed in later releases though the wheezy-backports version still suffers
from it



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

Kernel: Linux 3.18.16 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libavutil-dev depends on:
ii  libavutil53  6:10.1-1~bpo70+1

libavutil-dev recommends no packages.

libavutil-dev suggests no packages.

-- no debconf informationFrom: Michael Niedermayer 
Date: Sun, 17 Mar 2013 17:36:16 + (+0100)
Subject: avutil/buffer: Fix race in pool.
X-Git-Tag: n2.0~2533
X-Git-Url: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff_plain;h=cea3a63ba3d89d8403eef008f7a7c54d645cff70;hp=73ef12757b9471474bfebda20792448e9bc4e3cc

avutil/buffer: Fix race in pool.

This race will always happen sooner or later in a multi-threaded
environment and it will over time lead to OOM.
This fix works by spinning, there are other ways by which this
can be fixed, like simply detecting the issue after it happened
and freeing the over-allocated memory or simply using a mutex.

Signed-off-by: Michael Niedermayer 
---

Index: libav-10.1/libavutil/buffer.c
===
--- libav-10.1.orig/libavutil/buffer.c	2014-05-10 16:18:15.0 +
+++ libav-10.1/libavutil/buffer.c	2016-01-03 22:28:38.683806653 +
@@ -307,6 +307,7 @@
 ret->buffer->free   = pool_release_buffer;
 
 avpriv_atomic_int_add_and_fetch(>refcount, 1);
+avpriv_atomic_int_add_and_fetch(>nb_allocated, 1);
 
 return ret;
 }
@@ -318,6 +319,11 @@
 
 /* check whether the pool is empty */
 buf = get_pool(pool);
+if (!buf && pool->refcount <= pool->nb_allocated) {
+while (!buf && avpriv_atomic_int_get(>refcount) <= avpriv_atomic_int_get(>nb_allocated))
+buf = get_pool(pool);
+}
+
 if (!buf)
 return pool_alloc_buffer(pool);
 
Index: libav-10.1/libavutil/buffer_internal.h
===
--- libav-10.1.orig/libavutil/buffer_internal.h	2014-05-10 16:18:15.0 +
+++ libav-10.1/libavutil/buffer_internal.h	2016-01-03 22:08:03.0 +
@@ -85,6 +85,8 @@
  */
 volatile int refcount;
 
+volatile int nb_allocated;
+
 int size;
 AVBufferRef* (*alloc)(int size);
 };

Bug#809772: RFS: autoconf-archive/20150925-1

[Bastien ROUCARIES]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "autoconf-archive"

 * Package name: autoconf-archive
   Version : 20150925-1
   Section : devel

  It builds those binary packages:

autoconf-archive - Autoconf Macro Archive
 autoconf-gl-macros - Autoconf OpenGL Macro Archive -- transitional
dummy package

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

  http://mentors.debian.net/package/autoconf-archive


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

dget -x 
http://mentors.debian.net/debian/pool/main/a/autoconf-archive/autoconf-archive_20150925-1.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

  * New upstream version
  * Acknowledge NMU.
  * Bug fix: "AX_CHECK_GLU trashes the LIBS variable", thanks to James
Cowgill (Closes: #795479).



  Regards,
   bastien roucaries

Bug#809774: inn2-inews: rnews segfaults

[Marcus Jodorf]

Package: inn2-inews
Version: 2.6.0-1
Severity: important

Dear Maintainer,

I'm running a local inn2 fed by suck for decades pretty much
without any problems.

The last update to inn2 2.6.0-1 in sid now broke it.

rnews which (is called by suck as user root like this:
NNTPSERVER=192.168.1.1 /usr/bin/rnews 

Bug#809447: mdadm: update=metadata with 4TB disks result in different sizes and superblock versions

[NeilBrown]

On Thu, Dec 31 2015, Ralph Kaptur wrote:

> the size has shrinked and the filesystem no longer working.

I suspect this will be fixed by

diff --git a/super0.c b/super0.c
index 7f8001479edc..59a6a034fb6a 100644
--- a/super0.c
+++ b/super0.c
@@ -405,7 +405,8 @@ static void getinfo_super0(struct supertype *st, struct 
mdinfo *info, char *map)
info->array.utime = sb->utime;
info->array.chunk_size = sb->chunk_size;
info->array.state = sb->state;
-   info->component_size = sb->size*2;
+   info->component_size = sb->size;
+   info->component_size *= 2;
 
if (sb->state & (1<bitmap_offset = 8;


You array currently has two superblocks on it, which will be confusing.

If you stop the array and then
  mdadm --zero-super --metadata=1.0 /dev/sdb1 /dev/sdc1
the new incorrect metadata should be removed.

If you apply the above patch to mdadm (maybe get clean source with
   git clone git://neil.brown.name/mdadm
then apply the patch and run "make") you should be able to assemble
--update=metadata and get a working array.

Thanks for the report.

NeilBrown


signature.asc
Description: PGP signature

Bug#726231: digikam crashes after start on console

[Steve M. Robbins]

Hello,

I'm sorry it's taken so long to get to your report.  But since it has been a 
while, I need to ask: does the issue still happen?

On Sun, 13 Oct 2013 18:11:49 +0200 Dirk Pankonin  wrote:

>* What was the outcome of this action?
> QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in
> use, all queries will cease to work.
> [0x1a1db88] main services discovery error: no suitable services discovery
> module
> digikam: tiffcomposite.cpp:1037: virtual uint32_t
> Exiv2::Internal::TiffMnEntry::doCount() const: Zusicherung »tiffType() ==
> ttUndefined || tiffType() == ttUnsignedByte || tiffType() == ttSignedByte«
> nicht erfüllt.
> digikam: Fatal IO error: client killed

I can't reproduce this crash.  Have you configured digikam in any special 
manner?  Is it using the default SQLite database or is it using an external 
one such as mysql?

Thanks,
-Steve



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

Bug#749684: [digikam] error trying to access kipi-plugins manuals (galleryexport) documentation

[Steve M. Robbins]

Control: tags -1 confirmed upstream

Reproduced this bug in 4.14.0 using the following steps:

Open Help|digiKam Handbook (or press F1)
Scroll down to "4. Menu Descriptions / The main digiKam window / The Export 
Menu"
Click on hyperlink for "Gallery Export manual".


On Wed, 28 May 2014 23:40:30 -0400 Filipus Klutiero  wrote:

>  From help:/digikam/menu-descriptions.html#export-menu
> trying to access some kipi-plugins manuals, such as galleryexport, results
> in a fatal error, for example:
> The file or folder help:/kipi-plugins/galleryexport.html does not exist.

In 4.14.0, the error is not fatal: both the KDE Help Center and DigiKam 
continue to run.  The former displays:

Could not find filename galleryexport.html in /usr/share/doc/kde/HTML/en/kipi-
plugins/galleryexport.html.


> And indeed, that file is not in Debian.

It is not in the upstream sources, either.   In fact, if you open the Kipi 
Plugins Handbook in the KDE Help Center and look at Chapter 1, you'll see that 
most of the plugins have a link, but several do not.   The Gallery Export 
plugin is one that does not have a link.

I think the bug is therefore in the digikam manual itself.



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

Bug#809783: bash-completion: Will not complete inside a command substitution

[Javier Barroso]

Package: bash-completion
Version: 1:2.1-4.2
Severity: normal

$ echo $(ls -<>bash: unexpected EOF while looking for matching `)'
bash: syntax error: unexpected end of file

I hope you are able to reproduce this problem

Thank you!

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

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

Versions of packages bash-completion depends on:
ii  bash  4.3-14+b1
ii  dpkg  1.18.4

bash-completion recommends no packages.

bash-completion suggests no packages.

-- debconf-show failed

Bug#809684: RFS: twinkle/1:1.9.0+dfsg-2 [RC] -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

On Sun, Jan 03, 2016 at 11:13:39PM +, Mattia Rizzolo wrote:
> thanks for the git thinng :)
> for the next time I'd love to have a signed object, like a signed
> commit.

I have imported your upload and pushed a signed tag. My GnuPG key has
not been signed by a DD though, who are sadly scarce in my area (the
largest city in Canada).

> Thanks a lot for caring about source only uploads!
> 
> Thanks for your contribution to Debian, uploaded! :)

Mattia, thank you for the upload!

Regards,
Peter


signature.asc
Description: PGP signature

Bug#807836: builtin unlimit leads to "xargs: invalid number for -s"

[Daniel Shahaf]

Thilo Six wrote on Sat, Jan 02, 2016 at 20:28:39 +0100:
> I do argue (and that is what has caused this bug) that setting a limit that 
> far
> beyond anything capable on this current system that it is not even technical
> able to handle that size of such a limit is useful.
> And that is just what unlimit does (at least that is what i gather from this
> bugs history).

> Now if unlimit would instead evaluate the maximum physical possible size for
> that limit and activate that, i would say nice.

Managing system resources is the OS's job, not zsh's.  I suggest you
look into configuring your OS to set the hard limit as a function of the
available hardware.  Then, calling 'unlimit' in zsh will behave as you
expect (without any code changes to zsh or to your zsh script).

> question:
> Something i was not be able to 100% verify up to now, but i guess from what i
> read so far that input size on shell prompt relates to stack size in terms of
> rlimit?
> 

The stack contains function call frames.  The input to the shell would
be allocated on the heap, not on the stack.  Hence, it would be affected
by the memory allocation limits, not by the stack size limits.

Cheers,

Daniel

Bug#727768: pytrainer: fails to import gpx files

[Marcelo Santana]

On Sun, 3 Jan 2016 20:05:27 +0100
Christian PERRIER  wrote:

[...]

> Hello Marcelo,

Hello Christian,

> Roughly looking at the changes, I'm OK with all of them, including the
> packaging QA. 
> 
> Thanks a lot for your work, which seems great.

Thanks for your quick reply. It is a pleasure to be able for helping
even still being a beginner on packaging.

> I could of course merge everything in the packaging git repo (assuming
> that I remember the correct git-fu incantations)but I'd prefer
> more atomic changes.
> 
> Indeed, what would help me would be:
> 
> 1) cut the packaging QA commit
> (6c0f66469f49feff4a7e43bce502d6672e3ec1e9) in on commit per each
> individual change so that I can apply the patches individually and
> have a better git log in the main repository

Ok, I can do that.

> 2) instead of applying the upstream changes in master, build a tarball
> with upstream git snapshot so that I could use git-import-orig and
> then use an upstream version name such as "1.10.2~git20160104"

Idem.

> I can of course do both 1) and 2) but I don't really know when...:-)
> 
> Giving you commit access to the packaging git repository is certainly
> something I'd be happy to do if you're OK with this. I'd then just
> need the name of your Alioth account if you already have one.

My Alioth account is darkstar-guest.

> Thanks again for your interest in this packaging work.

It's a pleasure to help the Debian pkg-running team especially now that
I have become addicted to running. :-)

Kind regards,

-- 
Marcelo Santana (aka msantana) 
http://blog.msantana.eng.br | http://identi.ca/mgsantana
4096R/5B76053D: 8E9B 1014 4019 3526 C1C6  B0AC A3C0 DA1E 5B76 053D


pgpk9lQ1Y9bcQ.pgp
Description: OpenPGP digital signature

Bug#809769: roundcube: Error log is filled with messages that config file cannot be loaded

[Vincent Bernat]

 ❦  3 janvier 2016 22:07 +0100, Dmitry Katsubo  :

>> [03-Jan-2016 20:43:38 +0100]:  PHP Error: Failed to load
>> config from /var/lib/roundcube/plugins/zipdownload/config.inc.php in
>> /usr/share/roundcube/program/lib/Roundcube/rcube_plugin.php on line
>> 157 (GET /roundcube/)
>> [03-Jan-2016 20:43:38 +0100]:  PHP Error: Failed to load
>> config from /var/lib/roundcube/plugins/jqueryui/config.inc.php in
>> /usr/share/roundcube/program/lib/Roundcube/rcube_plugin.php on line
>> 157 (GET /roundcube/)
>
> The mentioned config files exist, but are empty (perhaps that is the reason 
> of the error).

Yes, since 1.0.0, roundcube now checks if $config is an array. Plugin
configurations are expected to have something like $config['something']
= ''. Maybe putting $config=array() in each file would work.
-- 
Let the data structure the program.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#738138: php-file-find: changing from ITP to RFP

[François-Régis]

Le 27/12/2015 13:17, Lucas Nussbaum a écrit :
> A long time ago, you expressed interest in packaging php-file-find. 
> Unfortunately,
> it seems that it did not happen. In Debian, we try not to keep ITP bugs open
> for a too long time, as it might cause other prospective maintainers to
> refrain from packaging the software.
> 
> This is an automatic email to change the status of php-file-find from ITP
> (Intent to Package) to RFP (Request for Package), because this bug hasn't seen
> any activity during the last 12 months.
> 
> If you are still interested in packaging php-file-find, please send a mail to
>  with:

The problem is that this package is under php licence and not maintained
upstream. sathieu (Mathieu Parent) has filled a bug upstream [1] and I
unsuccefully tried to contact upstream authors.

[1] http://pear.php.net/bugs/bug.php?id=20256

The reason of the ITP is that php-file-find is a dependency of horde
5.1.5 and we have some packages unmainted by pear with php licence and
vanished author.

If someone has an idea on how to deal with this, regarding the fact that
these packages are mostly basic ?

Regards

-- 
François-Régis

Bug#809784: RFS: cligh/0.2-3 ITP

[Dmitry Bogatov]

Package: sponsorship-request
Severity: wishlist

Dear mentors,

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

* Package name: cligh
  Version : 0.2-3
  Upstream Author : Christopher M. Brannon 
* Url : http://the-brannons.com/software/cligh.html
* Licenses: BSD-3-clause, GPL-3+
  Section : python

It builds those binary packages:

cligh -- Command-line interface to GitHub

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

http://mentors.debian.net/package/cligh

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

http://mentors.debian.net/debian/pool/main/c/cligh/cligh_0.2-3.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://github.com/kaction/deb-cligh

More information about cligh can be obtained from 
http://the-brannons.com/software/cligh.html

Changes since last upload:

  * Rename python-pygithub dependency. More info: #808467

Regards,
  Dmitry Bogatov

Bug#809785: reprepro: conffiles not removed

[Paul Wise]

Package: reprepro
Version: 4.17.0-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

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

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

This bug report brought to you by adequate:

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

$ pkg=reprepro ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep 
obsolete
reprepro: obsolete-conffile /etc/bash_completion.d/reprepro
 /etc/bash_completion.d/reprepro 1ef57c381250da27f0f44537dea0ed2f obsolete

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental'), (690, 'buildd-experimental'), (500, 
'unstable-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages reprepro depends on:
ii  libarchive13 3.1.2-11+b1
ii  libbz2-1.0   1.0.6-8
ii  libc62.21-6
ii  libdb5.3 5.3.28-11
ii  libgpg-error01.21-1
ii  libgpgme11   1.6.0-1
ii  liblzma5 5.1.1alpha+20120614-2.1
ii  pinentry-curses  0.9.6-4
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages reprepro recommends:
ii  apt  1.1.10

Versions of packages reprepro suggests:
ii  gnupg-agent  2.0.28-3
pn  inoticoming  
ii  lzip 1.17-1+b1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#809786: The "posix" provider of the "exec" resource seems to invoke a shell even though the documentation says it doesn't

[Alexander Kurtz]

Package: puppet
Version: 3.8.4-1

Hi,

the puppet type reference describes the "posix" provider of the "exec"
resource like this: [0]

posix
Executes external binaries directly, without passing through a shell or
performing any interpolation. This is a safer and more predictable way 
to
execute most commands, but prevents the use of globbing and shell 
built-ins
(including control logic like “for” and “if” statements).

However:

# cat manifest.pp 
$input = 'foo; if false; then exit 23; else exit 42; fi'

exec { "/bin/echo ${input}":
provider => 'posix',
}
# puppet apply manifest.pp 
Notice: Compiled catalog for shepard.kurtz.be in environment production 
in 0.04 seconds
Notice: /Stage[main]/Main/Exec[/bin/echo foo; if false; then exit 23; 
else exit 42; fi]/returns: foo
Error: /bin/echo foo; if false; then exit 23; else exit 42; fi returned 
42 instead of one of [0]
Error: /Stage[main]/Main/Exec[/bin/echo foo; if false; then exit 23; 
else exit 42; fi]/returns: change from notrun to 0 failed: /bin/echo foo; if 
false; then exit 23; else exit 42; fi returned 42 instead of one of [0]
Notice: Finished catalog run in 0.08 seconds
# 

I'm not really sure what to make of this, but it seems... unexpected.
What do you guys think?

Best regards

Alexander Kurtz

[0] 
https://docs.puppetlabs.com/references/3.8.latest/type.html#exec-provider-posix

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

Bug#794766: Bug present on testing

[ljlbox]

I can confirm this issue on testing (and some unstable packages), 
running abiword 3.0.1-4+b1 and empathy 3.12.11-1+b1.



Connetti gratis il mondo con la nuova indoona:  hai la chat, le 
chiamate, le video chiamate e persino le chiamate di gruppo.

E chiami gratis anche i numeri fissi e mobili nel mondo!
Scarica subito l’app Vai su https://www.indoona.com/

Bug#809770: mercurial: FTBFS: Failed test-clonebundles.t: output changed

[Chris Lamb]

Source: mercurial
Version: 3.6.2-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

mercurial fails to build from source in unstable/amd64:

  [..]

  ok
  test-unrelated-pull.t
  test-unrelated-pull.t ... # Test test-unrelated-pull.t 
  # Running sh "/tmp/hgtests.mnpMhW/child444/test-unrelated-pull.t.sh" 
  test-update-issue1456.t
  test-update-issue1456.t ... # Test test-update-issue1456.t 
  # Running sh "/tmp/hgtests.mnpMhW/child441/test-profile.t.sh" 
  # Ret was: 0 (test-lrucachedict.py) 
  ok
  test-empty.t
  test-empty.t ... # Test test-empty.t 
  # Running sh "/tmp/hgtests.mnpMhW/child446/test-empty.t.sh" 
  # Killing daemon process 5006 
  # Ret was: 0 (test-websub.t) 
  ok
  test-journal-exists.t
  test-journal-exists.t ... # Test test-journal-exists.t 
  # Running sh "/tmp/hgtests.mnpMhW/child445/test-update-issue1456.t.sh" 
  # Ret was: 0 (test-abort-checkin.t) 
  ok
  test-diff-copy-depth.t
  test-diff-copy-depth.t ... # Test test-diff-copy-depth.t 
  # Running sh "/tmp/hgtests.mnpMhW/child448/test-diff-copy-depth.t.sh" 
  # Running sh "/tmp/hgtests.mnpMhW/child447/test-journal-exists.t.sh" 
  # Ret was: 0 (test-diff-reverse.t) 
  ok
  test-convert-bzr-treeroot.t
  test-convert-bzr-treeroot.t ... # Test test-convert-bzr-treeroot.t 
  # Ret was: 0 (test-unrelated-pull.t) 
  ok
  # Running sh "/tmp/hgtests.mnpMhW/child449/test-convert-bzr-treeroot.t.sh" 
  test-dispatch.py
  test-dispatch.py ... # Test test-dispatch.py 
  # Running /usr/bin/python 
"/home/lamby/temp/cdt.20160103133200.YMPjUhtE7W/mercurial-3.6.2/tests/test-dispatch.py"
 
  skipped skipped
  # Ret was: 80 (test-convert-bzr-treeroot.t) 
  # Ret was: 0 (test-profile.t) 
  ok
  test-hgweb-bundle.t
  test-hgweb-bundle.t ... # Test test-hgweb-bundle.t 
  test-mq-qimport-fail-cleanup.t
  test-mq-qimport-fail-cleanup.t ... # Test test-mq-qimport-fail-cleanup.t 
  # Running sh "/tmp/hgtests.mnpMhW/child452/test-mq-qimport-fail-cleanup.t.sh" 
  # Ret was: 0 (test-revset-dirstate-parents.t) 
  ok
  test-manifest-merging.t
  test-manifest-merging.t ... # Test test-manifest-merging.t 
  # Running sh "/tmp/hgtests.mnpMhW/child453/test-manifest-merging.t.sh" 
  # Ret was: 0 (test-empty.t) 
  ok
  # Running sh "/tmp/hgtests.mnpMhW/child451/test-hgweb-bundle.t.sh" 
  test-issue619.t
  test-issue619.t ... # Test test-issue619.t 
  # Running sh "/tmp/hgtests.mnpMhW/child454/test-issue619.t.sh" 
  # Ret was: 0 (test-dispatch.py) 
  ok
  test-issue842.t
  test-issue842.t ... # Test test-issue842.t 
  # Running sh "/tmp/hgtests.mnpMhW/child455/test-issue842.t.sh" 
  # Ret was: 0 (test-journal-exists.t) 
  ok
  test-debian-packages.t
  test-debian-packages.t ... # Test test-debian-packages.t 
  # Ret was: 0 (test-update-issue1456.t) 
  ok
  test-revlog-group-emptyiter.t
  test-revlog-group-emptyiter.t ... # Test test-revlog-group-emptyiter.t 
  # Running sh "/tmp/hgtests.mnpMhW/child457/test-revlog-group-emptyiter.t.sh" 
  # Ret was: 0 (test-mq-qimport-fail-cleanup.t) 
  ok
  test-merge8.t
  test-merge8.t ... # Test test-merge8.t 
  # Running sh "/tmp/hgtests.mnpMhW/child458/test-merge8.t.sh" 
  # Running sh "/tmp/hgtests.mnpMhW/child456/test-debian-packages.t.sh" 
  # Killing daemon process 5251 
  skipped skipped
  # Ret was: 80 (test-debian-packages.t) 
  test-merge4.t
  test-merge4.t ... # Test test-merge4.t 
  # Running sh "/tmp/hgtests.mnpMhW/child459/test-merge4.t.sh" 
  # Ret was: 0 (test-hgweb-bundle.t) 
  ok
  test-archive-symlinks.t
  test-archive-symlinks.t ... # Test test-archive-symlinks.t 
  # Ret was: 0 (test-manifest-merging.t) 
  ok
  test-pull-permission.t
  test-pull-permission.t ... # Test test-pull-permission.t 
  # Ret was: 0 (test-issue842.t) 
  ok
  test-issue612.t
  test-issue612.t ... # Test test-issue612.t 
  # Running sh "/tmp/hgtests.mnpMhW/child462/test-issue612.t.sh" 
  # Running sh "/tmp/hgtests.mnpMhW/child460/test-archive-symlinks.t.sh" 
  # Running sh "/tmp/hgtests.mnpMhW/child461/test-pull-permission.t.sh" 
  # Ret was: 0 (test-diff-copy-depth.t) 
  ok
  test-check-commit-hg.t
  test-check-commit-hg.t ... # Test test-check-commit-hg.t 
  # Ret was: 0 (test-issue619.t) 
  ok
  test-status-inprocess.py
  test-status-inprocess.py# Ret was: 0 (test-revlog-group-emptyiter.t) 
  ok
   ... # Test test-status-inprocess.py 
  # Running /usr/bin/python 
"/home/lamby/temp/cdt.20160103133200.YMPjUhtE7W/mercurial-3.6.2/tests/test-status-inprocess.py"
 
  test-diffdir.t
  test-diffdir.t ... # Test test-diffdir.t 
  # Running sh "/tmp/hgtests.mnpMhW/child465/test-diffdir.t.sh" 
  # Ret was: 0 (test-merge8.t) 
  ok
  test-revlog-packentry.t
  test-revlog-packentry.t ... # Test test-revlog-packentry.t 
  # Running sh "/tmp/hgtests.mnpMhW/child466/test-revlog-packentry.t.sh" 
  # Running sh "/tmp/hgtests.mnpMhW/child463/test-check-commit-hg.t.sh" 
  # Ret was: 0 

Bug#809771: php-net-ldap2: FTBFS: This package.xml requires PEAR version 1.10.1 to parse properly, we are version 1.9.5

[Chris Lamb]

Source: php-net-ldap2
Version: 2.2.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

php-net-ldap2 fails to build from source in unstable/amd64:

  [..]

 dh_auto_install -O--buildsystem=phppear
/usr/bin/pear -c debian/pearrc -d download_dir=/tmp -d 
include_path=/usr/share/php -d php_bin=/usr/bin/php -d bin_dir=/usr/bin -d 
php_dir=/usr/share/php -d data_dir=/usr/share/php/data -d 
doc_dir=/usr/share/doc/php-net-ldap2 -d test_dir=/usr/share/php/tests install 
--offline --nodeps -P 
/home/lamby/temp/cdt.20160103134203.eRagGTOM5l/php-net-ldap2-2.2.0/debian/php-net-ldap2
 ./Net_LDAP2-2.2.0/package.xml
  This package.xml requires PEAR version 1.10.1 to parse properly, we are 
version 1.9.5
  Parsing of package.xml from file "./Net_LDAP2-2.2.0/package.xml" failed
  Cannot download non-local package "./Net_LDAP2-2.2.0/package.xml"
  install failed
  dh_auto_install: /usr/bin/pear -c debian/pearrc -d download_dir=/tmp -d 
include_path=/usr/share/php -d php_bin=/usr/bin/php -d bin_dir=/usr/bin -d 
php_dir=/usr/share/php -d data_dir=/usr/share/php/data -d 
doc_dir=/usr/share/doc/php-net-ldap2 -d test_dir=/usr/share/php/tests install 
--offline --nodeps -P 
/home/lamby/temp/cdt.20160103134203.eRagGTOM5l/php-net-ldap2-2.2.0/debian/php-net-ldap2
 ./Net_LDAP2-2.2.0/package.xml returned exit code 1
  debian/rules:3: recipe for target 'binary' failed
  make: *** [binary] Error 10

  [..]

The full build log is attached.


Regards,

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


php-net-ldap2.2.2.0-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#734095: Info received ([Bash-completion-devel] Bug#734095: bash-completion: Please replace 'grep' with 'command grep' within several functions.)

[Tomasz Nowiński]

In the past two years I modified make file the dozen or so timesby hand, 
because the change is still not landed in the package...


Regards
TN

Bug#809782: git-dpm: print the patch filename during rebasing patches

[Sandro Tosi]

Package: git-dpm
Version: 0.9.1-1
Severity: normal

Hello,
when importing a new upstream tarball, in the patch rebasing phase, now the
patch description is printed, but not the file name, which is really not
helpful. please print also the filename of the patch you are rebasing.

Regards,
Sandro


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

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

Versions of packages git-dpm depends on:
ii  dpkg-dev  1.18.3
ii  git   1:2.6.2-1

Versions of packages git-dpm recommends:
ii  bzip2   1.0.6-8
ii  devscripts  2.15.9
ii  sensible-utils  0.0.9
ii  xz-utils5.1.1alpha+20120614-2.1

Versions of packages git-dpm suggests:
ii  pristine-tar  1.33
ii  sharutils 1:4.15.2-1

-- no debconf information

Bug#775558: digikam crashes on startup - matroska video

[Steve M. Robbins]

Hello Jens 

Thank you for your efforts in diagnosing this bug.  I'm sorry your issue 
hasn't been addressed previously.  

Given the final comment on this report (below), I wonder if you are in a 
position to try an updated exiv2 library?  Version 0.25 is available in 
Debian's "testing" distribution.

Thanks,
-Steve


On Thu, 25 Jun 2015 15:31:31 -0500 Alan Pater  wrote:
> This should be fixed by updating to exiv2 library version 0.25.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789956
> 
> http://exiv2.org/changelog.html
> 
> 

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

Bug#808958: Update kernel package selection for i386 in stretch

[Steve McIntyre]

Control: tag -1 +pending

On Thu, Dec 24, 2015 at 09:34:46PM +, Ben Hutchings wrote:
>Package: debian-cd
>Version: 3.1.17
>Severity: important
>Tags: patch
>
>The 586 kernel flavour has been replaced by 686 for stretch.

Thanks, applied.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#809678: unicode-screensaver: "Something is wrong" is not a character name

[Daniel Shahaf]

Joachim Breitner wrote on Sat, Jan 02, 2016 at 20:12:10 +0100:
> Hi,
> 
> yes, this “something is wrong” is annoying. Unless I am mistaken, it
> happens if the unicode character has no entry in the table? Maybe it
> should simply print "U+ABCD" then.

Yes, I agree, printing just "U+ABCD" with neither a name nor an error
message afterwards is another option.

> (Or was it the case that there is simply a bug in the code when that
> happens? In that case, maybe it’s easier to fix the bug :-))
> 

I don't know whether it's a "character not in the table" or a bug, but
Occam's razor suggests it is probably the former.  I'll try to confirm
this the next time I see the "something is wrong" error.

Cheers,

Daniel

> Greetings,
> Joachim

Bug#809773: ifupdown: post 0.7.54 ifupdown breaks all kinds of services

[Christoph Anton Mitterer]

Package: ifupdown
Version: 0.8.5
Severity: critical
Justification: breaks unrelated software


Hi Guus.

I've just upgraded from 0.7.54 to 0.8.5 and after rebooting the server,
all kinds of daemons didn't come up anmore, e.g.
BIND:
# systemctl status bind9.service -ln 1
● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: 
enabled)
  Drop-In: /run/systemd/generator/bind9.service.d
   └─50-insserv.conf-$named.conf
   Active: failed (Result: exit-code) since Sun 2016-01-03 22:31:51 CET; 10min 
ago
 Docs: man:named(8)
  Process: 1166 ExecStop=/usr/sbin/rndc stop (code=exited, status=1/FAILURE)
  Process: 956 ExecStart=/usr/sbin/named -f -u bind (code=exited, 
status=1/FAILURE)
 Main PID: 956 (code=exited, status=1/FAILURE)

Jan 03 22:31:48 kronecker systemd[1]: Started BIND Domain Name Server.
Jan 03 22:31:50 kronecker named[956]: starting BIND 9.9.5-12.1-Debian -f -u bind
Jan 03 22:31:50 kronecker named[956]: built with '--prefix=/usr' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' 
'--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' 
'--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' 
'--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' 
'--enable-rrl' '--enable-filter-' 'CFLAGS=-fno-strict-aliasing 
-fno-delete-null-pointer-checks -DDIG_SIGCHASE -O2'
Jan 03 22:31:50 kronecker named[956]: 

Jan 03 22:31:50 kronecker named[956]: BIND 9 is maintained by Internet Systems 
Consortium,
Jan 03 22:31:50 kronecker named[956]: Inc. (ISC), a non-profit 501(c)(3) 
public-benefit
Jan 03 22:31:50 kronecker named[956]: corporation.  Support and training for 
BIND 9 are
Jan 03 22:31:50 kronecker named[956]: available at https://www.isc.org/support
Jan 03 22:31:50 kronecker named[956]: 

Jan 03 22:31:50 kronecker named[956]: adjusted limit on open files from 4096 to 
1048576
Jan 03 22:31:50 kronecker named[956]: found 2 CPUs, using 2 worker threads
Jan 03 22:31:50 kronecker named[956]: using 2 UDP listeners per interface
Jan 03 22:31:50 kronecker named[956]: using up to 4096 sockets
Jan 03 22:31:50 kronecker named[956]: loading configuration from 
'/etc/bind/named.conf'
Jan 03 22:31:50 kronecker named[956]: reading built-in trusted keys from file 
'/etc/bind/bind.keys'
Jan 03 22:31:50 kronecker named[956]: using default UDP/IPv4 port range: [1024, 
65535]
Jan 03 22:31:50 kronecker named[956]: using default UDP/IPv6 port range: [1024, 
65535]
Jan 03 22:31:50 kronecker named[956]: listening on IPv4 interface lo, 
127.0.0.1#53
Jan 03 22:31:50 kronecker named[956]: listening on IPv6 interface lo, ::1#53
Jan 03 22:31:50 kronecker named[956]: generating session key for dynamic DNS
Jan 03 22:31:50 kronecker named[956]: sizing zone task pool based on 45 zones
Jan 03 22:31:50 kronecker named[956]: acache 0x7f80f01535d0 cleaning interval 
set to 3600.
Jan 03 22:31:50 kronecker named[956]: could not get query source dispatcher 
(1.2.3.199#0)
Jan 03 22:31:50 kronecker named[956]: loading configuration: address not 
available
Jan 03 22:31:50 kronecker named[956]: exiting (due to fatal error)
Jan 03 22:31:50 kronecker systemd[1]: bind9.service: Main process exited, 
code=exited, status=1/FAILURE
Jan 03 22:31:51 kronecker rndc[1166]: rndc: connect failed: 127.0.0.1#49153: 
connection refused
Jan 03 22:31:51 kronecker systemd[1]: bind9.service: Control process exited, 
code=exited status=1
Jan 03 22:31:51 kronecker systemd[1]: bind9.service: Unit entered failed state.
Jan 03 22:31:51 kronecker systemd[1]: bind9.service: Failed with result 
'exit-code'.

=> seems as if even lo wouldn't be ready at that point in time?!


Apache HTTP:
# systemctl status apache2.service -ln 1
● apache2.service - LSB: Start/stop apache2 web server
   Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2016-01-03 22:31:53 CET; 10min 
ago
 Docs: man:systemd-sysv-generator(8)
  Process: 961 ExecStart=/etc/init.d/apache2 start (code=exited, 
status=1/FAILURE)

Jan 03 22:31:48 kronecker systemd[1]: Starting LSB: Start/stop apache2 web 
server...
Jan 03 22:31:53 kronecker apache2[961]: Starting web server: apache2(99)Cannot 
assign requested address: make_sock: could not bind to address 1.2.3.199:11371
Jan 03 22:31:53 kronecker apache2[961]: no listening sockets available, 
shutting down
Jan 03 22:31:53 kronecker apache2[961]: Unable to open logs
Jan 03 22:31:53 kronecker apache2[961]: Action 'start' failed.
Jan 03 22:31:53 kronecker apache2[961]: The Apache error log may have more 
information.
Jan 03 22:31:53 kronecker apache2[961]: failed!
Jan 03 22:31:53 kronecker systemd[1]: apache2.service: Control process exited, 
code=exited status=1
Jan 03 22:31:53 kronecker systemd[1]: Failed to start LSB: 

Bug#809775: usrmerge: Fails to move libpng12.so.0 symlink correctly

[Matthias Klumpp]

Package: usrmerge
Version: 3
Severity: important

Dear Maintainer,
when installing the usrmerge package, the
/usr/lib//libpng12.so.0 symlink ended up to be a link on
itself.

Fixing the link solved the problem, but there might be a general race
condition here when libraries are moved from /lib to /usr/lib.
I couldn't find any other broken library symlink except for this one.

Tests were done on the Tanglu 4 development release and could be
reproduced there by another user (for some reason it's always libpng
that is affected), I'll try to reproduce this on Debian Stretch as
well.

Cheers,
Matthias

Bug#809454: I think this is an upstream bug

[Alex Gould]

I was googling around about the same error and came across this:

https://github.com/rg3/youtube-dl/issues/7901

It looks like the same error, and it looks like they think it's fixed in
version 2015.12.18.

Bug#809548: 9wm breaks fullscreen applications

[Neale Pickett]

9wm is not an EWMH compliant window manager, sorry.

On Thu, Dec 31, 2015, 21:39 Jacob Adams  wrote:

> Package: 9wm
> Severity: normal
> X-Debbugs-CC: ne...@woozle.org
>
> When applications try to go fullscreen they break. The only two I have
> on hand are pioneer space simulator ( http://pioneerspacesim.net ) and
> endless-sky ( https://github.com/endless-sky/endless-sky ). Both are
> unable to go fullscreen in 9wm but work fine in xfwm4.
> Pioneer space sim is not centered but is off the left and on the bottom
> far enough offscreen to not be usable.
>
> This is being filed in Debian and CCed upstream as there is no upstream
> bug tracker.
>
> --
> Jacob Adams
> GPG Key: AF6B 1C26 E2D0 A988 432B  94F4 24C0 2B85 B59F E5A9
>
>
>

Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]

[Jose M Calhariz]

On 03/01/16 13:21, Mattia Rizzolo wrote:
> ok, let's have a look at today's work :)
>
> On Sat, Jan 02, 2016 at 08:03:53PM +, Jose M Calhariz wrote:
>> I decided to bite the bullet.  Upstream already have packaging work for
>> dh.  As his work is GPL2
>> I decided to merge it.
> oh, cool.
> some things (the number is the line number):
>
> 2: #DH_VERBOSE = 1
>
> well, not sure if without export it works the same, but I always saw
> this with an export.  furthermore, don't feel obliged to keep it
> commented out, if you like verbose stuff in your build log, enable it :)

You are right, the export keyword is very common here.  I am commenting
because currently
I am not debugging the packaging.  So I choose less verbose builds.

>
> 4: DPKG_EXPORT_BUILDFLAGS = 1
> 5: include /usr/share/dpkg/default.mk
>
> these are unneded, starting from debhelper compat 9 dh and dh_auto_*
> exports them.  See debhelper(7) for more info.  Please consider removing
> them.

Done.

> 9: DEB_PREF = $(shell gcc -print-multiarch)
>
> umh... just use DEB_HOST_MULTIARCH instead ?

Done.

>
> 23: sm := $(shell grep '^Package: librep[0-9]' debian/control | sed -e 
> 's@^Package: librep\([0-9][0-9]*\).*@\1@' )
>
> umh, what about:
> sm := $(shell dh_listpackages|grep 'librep[0-9]\+')
> and then use '$(sm)' instead of 'librep$(sm)' in the rules file?

I don't like the name sm, so used libname instead and dh_listpackages |
grep librep | head -n 1.
Done.

> 26:dh $@ --with autotools-dev --with autoreconf
>
> using both autotools-dev and autoreconf is usually just plain wrong.
> with that also please remove the build-dep on autotools-dev.
> See https://wiki.debian.org/Autoreconf for more info.

Done

>
> 32:dh_auto_configure -- $(shell dpkg-buildflags --export=configure) 
> $(DEB_CONFIGURE_USER_FLAGS)
>
> that's the same as above, ther is no need to manually invoke
> dpkg-buildflags starting from compat level 9

Done.

>
> 43: override_dh_auto_install:
> 44: dh_auto_install
> 45: dh_install
>
> instead please override only dh_install, no need to override
> dh_auto_install.

Not certain I have done the right thing here.  But I tested and did not
change a thing.


> Now, the rest of the build stuff still looks unnecessarily complex, but
> it's better than before.  maybe I'll try to semplify it locally over the
> next days.
>
>
> * you have a librep9.symbols, probably you should rename it, and update
>   to have the newer symbols, and remove the old ones.
> * please bump to debhelper compat 9
>   + this will also make (or at least help) make the lib multiarch-able
> - for this to work you need to start using dh_auto_configure instead
>   of manual calling ./configure, though
> - note that with this several .install will need an update
> - I see you already had troubles with --host and --build configure
>   flags: 1) I wonder why you need --host at all, we are not
>   cross-compiling... 2) dh_auto_configure takes care of --build.
> - suggestion: stop fiddling so much, and use dh + dh_auto_configure.
>>> multiarchifying a lib can be hard.  But I don't think this is going to
>>> be that hard.  If I were you I'd just try to use dh_auto_configure
>>> instead of plain ./configure call, and bump the debhelper compat.
>>> See https://wiki.debian.org/Multiarch/Implementation for some hints,
>>> note that that page has some outdated bits (but we all hate keeping docs
>>> up to date :( )
>> Did I get it right?
> looks good to me.  though I see there are files like
> ./usr/lib/x86_64-linux-gnu/rep/rules.mk
> that might be used by other packages.
> but if that one is a makefile, why is it under /usr/lib ?
>
> I need to try a piuparts run, and see if everything is right.
> Since there are only two r-deps once this package is more ready I'll try
> to build them against this, to see if this multi-lib change affects
> them.

And I intended to adopt that two r-deps.  What should make it easier.

>
> * librep-dev.links => no, please.  linking /usr/share/doc/
>   directory ain't nice at all, why is that in first place?
>> The file  librep-dev.links is gone, but the links are still present. I
>> don't know why :-(
> those links are caused by the --link-doc option of dh_installdocs.
> well, I'm not a fan of --link-doc, I really see too little point in it,
> int this case you just save some kB, just gaining troubles.
> But give that the current state of librep is a mixed (every binary have
> linked docs to librep9, except rep-doc), I'll leave the choice to you.
> Your choises are:
> * remove --link-doc for rep-doc, then you can just go on
> * remove --link-doc altogether, then you need a bunch of .maintscript
>   files (see dh_installdeb(1) and dpkg-maintscript-helper(1)

I will do this.  But need time to reread the docs.  Moved to TODO file.

> * use --link-doc also for rep-doc, then you need only one new
>   .maintscript for it (the 

Bug#805504: citadel-server: /etc/citadel/netconfigs

[Robert James Clay]

On a possibly related issue, errors apparently related to that directory are 
coming up when attempting to share a room.

Unable to allocate the space required for /etc/citadel/netconfigs/31.36481: 
Permission denied

Note that when I compared the problem citadel install with my two other 
existing (and operational) installations, I noticed that the permissions on the 
working ones are drwx-- while the one I had to create on the problem system 
was drwxr-xr-x.   I changed that to drwx-- but it did not seem to make much 
of a difference to the issue with the directory:

Unable to allocate the space required for /etc/citadel/netconfigs/31.3: 
Permission denied 






Regards,
  RJ Clay

Bug#809623: RFS: telegram-purple/1.2.3-1

[Jakub Wilk]

* Ben Wiederhake , 2016-01-02, 23:13:

The Russian PO file reads:

Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 
&& n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && 
n%10<=9) || (n%100>=11 && n%100<=14)? 2 : 3);

[...]
Even though I don't speak Russian, I can tell that this Plural-Forms 
can't possibly be correct. Here 4 plural forms are declared, but the 
expression never evaluates to 3.


Since it's just modular arithmetic, one can just parse the formula to 
fill out a 10x10 table as a "proof". I did that, and came to the same 
result as you do, without even looking at your program. (Originally I 
assumed a precedence error / parsing issue / whatever, so I didn't 
want to start reading C code ... sorry.)


For the record, here's my interpretation, with parenthesis added:

((n%10==1 && n%100!=11)
? 0
: ((n%10>=2 && n%10<=4 && (n%100<12 || n%100>14))
   ? 1
   : ((n%10==0 || (n%10>=5 && n%10<=9) || (n%100>=11 && n%100<=14))
  ? 2
  : 3)))

This rule can be written in regex as follows (note that there is an 
implicit "and not any of the above", although it doesn't make a 
difference):

- "[023456789]1" => "Transifex one"
- "[023456789][234]" => "Transifex few"
- "1.|.[056789]" => "Transifex many"
- else => "Transifex other"


Hmm, these "one"-"few"-"many"-"other" reminded me about CLDR. An indeed, 
if you look at CLDR's plurals table[0], there's a 4th form applicable to 
floating-point numbers. My hypothesis is that this Plural-Forms is a 
result of a botched automatic conversion from CLDR data. 


[0] 
http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html#ru

Now, it would be cool if i18nspector explained better what is wrong 
here. [snip]  I hope to implement this in the future.


Sounds awesome! However, I was still able to understand that 
*something* about the expression was fishy, but didn't understand that 
i18nspector is able to detect issues like this.


i18nspector has a small database of "correct" Plural-Forms for the most 
"popular" languages (including Russian). So all it knew was that your 
Plural-Forms was different than the rest of the world uses.


(It does have other Plural-Forms correctness checks that don't require 
any linguistic data, but they didn't trigger in this case.)



(Doesn't that essentially require a SAT-solver?)


Theoretically, yes, checking that a plural expression never evaluates to 
a certain value is NP-hard.


But in practice almost all real-world Plural-Forms are structured 
similarly to what we saw in this thread, making them easy to analyse. So 
I intend to implement something like this:


1) Try to prove that f(i + 100) == f(i) for all i > 100.

2) If we're able to prove it, then we know that the image of f is equal 
to {f(0), f(1), ..., f(199), f(200)}.


3) Otherwise, assume that the Plural-Forms is okay. (Alternatively: 
assume that Plural-Forms so unusual that it's almost certainly broken.)


--
Jakub Wilk

Bug#809780: flask-restful: please make the build reproducible

[Chris Lamb]

Source: flask-restful
Version: 0.3.4-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that 
flask-restful could not be built reproducibly.

Patch attached.


 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff -urNad flask-restful-0.3.4.orig/docs/conf.py 
flask-restful-0.3.4/docs/conf.py
--- flask-restful-0.3.4.orig/docs/conf.py   2016-01-03 23:21:42.344550438 
+
+++ flask-restful-0.3.4/docs/conf.py2016-01-03 23:23:54.717237869 +
@@ -11,9 +11,12 @@
 # All configuration values have a default; values that are commented out
 # serve to show the default.
 
-from datetime import date
 import os
 import sys
+import time
+import datetime
+
+BUILD_DATE = 
datetime.datetime.utcfromtimestamp(int(os.environ.get('SOURCE_DATE_EPOCH', 
time.time(
 
 # If extensions (or modules to document with autodoc) are in another directory,
 # add these directories to sys.path here. If the directory is relative to the
@@ -46,7 +49,7 @@
 # General information about the project.
 project = u'Flask-RESTful'
 copyright = u'{}, Kevin Burke, Kyle Conroy, Ryan Horn, Frank Stratton, 
Guillaume Binet'.format(
-date.today().year)
+BUILD_DATE.year)
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the

Bug#774053: digikam: Process never goes away after quitting Digikam

[Steve M. Robbins]

Control: tags -1 moreinfo unreproducible

On Sat, 27 Dec 2014 21:59:09 -0600 John Goerzen  wrote:
> Package: digikam
> Version: 4:4.4.0-1.1
> Severity: important
> 
> After using Ctrl-Q to quit Digikam, its window goes away but its
> process doesn't.

I can't install digikam 4.4.0 to try this.  
With digikam 4.14.0, I can't reproduce this: the processes all go away as 
expected.

If this is still happening to you, can you try "strace" to see what the 
process is doing?

Thanks,
-Steve


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

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Norbert Preining]

Hi Agustin,

> For the records, this summer (30/7/15) I also mailed Joerg about
> current xindy status, but got no reply. My message might have been
> unnoticed and I have been rather busy lately, so I did not retry.

I did contact m...@debian.org for a take over of the xindy package.
We can put it into collab-maint or into debian-tex, I don't mind
any of it.

> I also reminded him about xindy still using dpatch and about the
> existence of newer upstream versions (up to 2.5.1).

I first wanted to fix the current problems, then I will upgrade
to last version.

Have you investigated whether using sbcl instead of clisp would work?
clisp is dead, and sbcl is much more reliable and portable.

I will look into it.

All the best

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#809781: qa.debian.org: Watchfile checker using outdated sources

[Scott Talbert]

Package: qa.debian.org
Severity: normal

The watchfile checker on qa.debian.org seems to be checking a watchfile 
from outdated sources.  See[1] which reports a watchfile problem, but 
the watchfile was fixed on 9 December[2].  Note the version of the 
package reported by the checker is the old version.

[1] https://qa.debian.org/cgi-bin/watchfile-error.cgi?package=hidapi
[2] https://packages.qa.debian.org/h/hidapi.html

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

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

Bug#809206: so can I delete them by hand?

[Ben Hutchings]

On Mon, 2016-01-04 at 10:14 +0800, 積丹尼 Dan Jacobson wrote:
> So can I delete them anyway?

You should not delete them.

Ben.

-- 
Ben Hutchings
Lowery's Law:
 If it jams, force it. If it breaks, it needed replacing anyway.


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

Bug#795061: (no subject)

[ZenWalker]

merged on github amule/testing:

https://github.com/amule-project/amule/commit/1f03c27bbb8d7dc717212b78da89bc443d00105b

Bug#786590: dwb: segfaults with libwebkitgtk-3.0-0 2.4.9-1

[Oleg Kostyuchenko]

Hi everyone who encountered this bug on Debian,

I have performed some shallow debugging after I encountered these dwb crashes 
myself (Debian stretch x86-64, webkitgtk 2.4.9-3, dwb built from the most 
recent git snapshot).

At the first glance, the culprit is dwb (namely adblock.c), not webkitgtk. As a 
temporary solution, you may disable adblocker by setting the option "adblocker" 
to false (or just :set adblocker false) - that should fix the constant crashes 
at every page. (Of course it's better to run dwb on a clean session or use -R 
option from the beginning, otherwise dwb will try to restore the session and 
the crash will hit you before you ever have a chance to disable the adblocker).

The segfault originates from the function "adblock_apply_element_hider" in 
adblock.c: due to some reason, one of the elements of the list 
VIEW(gl)->status->styles (a local variable) is a corrupted pointer; when the 
function attempts to apply WEBKIT_DOM_NODE typecast on it, this leads to a 
segfault from a GObject typecasting internal. No idea yet who is responsible 
for corrupting the pointers (adblocker or maybe webkit); I'll try to examine 
the logic of adblock.c a bit later.

By the way, dwb source distribution has a primitive backtrace script, 
tools/backtrace.sh; you will probably want to attach its output to the bug 
report.


Thanks,
Oleg

Bug#808043: linux-image-4.3.0-1-powerpc64: Fail to load md_mod with unknow symbol error

[Gianluca Renzi]

As for today, the binutils and the kernel (4.3.0-1ppc) upgrade did not fix
the issue.
Right now I am compiling by myself the 4.3-source package and try to see if
it shows some differences...


On Wed, Dec 16, 2015 at 10:38 AM, Christian Marillat 
wrote:

> On 15 déc. 2015 19:12, Ben Hutchings  wrote:
>
> [...]
>
> > OK, so everything is failing because the 'mcount' symbol (used for
> > function tracing) is not found.  It is supposed to be exported from
> > vmlinux.  Comparing the two versions, there's no difference (aside from
> > addresses) in the symbols related to mcount, so I think there's a
> > deeper problem in the module loader.
>
> Thanks for the precise analysis of the bug report.
>
> Christian
>
>


-- 
Ciao e buona giornata.

"GP! In mezzo al campo stai proprio schifoso!"
Coach M.Russo

Bug#808430: perl-modules-5.22: after the upgrade to perl 5.22, the Module::Build module is no longer present

[Vincent Lefevre]

Control: retitle -1 document notable perl issues in stretch release notes

On 2016-01-03 12:03:09 +, Dominic Hargreaves wrote:
> I've retitled this bug to reflect the need to document this. For
> Module::Build there doesn't seem to be anything else to do at this
> point.

OK. Actually doing the retitle...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#809777: RFP: clunc -- Client for LaCie U-Boot NetConsole

[Martin Michlmayr]

Package: wnpp
Severity: wishlist

CLUNC is a tool to connect to U-Boot via the network on LaCie and some
Seagate NAS devices.

Web site:
http://lacie-nas.org/doku.php?id=clunc

Source code:
http://git.lacie-nas.org/?p=clunc.git;a=summary

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#809776: glibc: Please add patch to support HUGE PAGES on hppa

[Helge Deller]

Package: glibc
Version: 2.21-6
Tags: patch

Can you please add this patch:
https://sourceware.org/bugzilla/attachment.cgi?id=8811
to the next upload of debian glibc?
It adds some defines for HUGE PAGE support for the hppa/parisc
architecture, and it has been accepted upstream and committed
into glibc master for 2.22.

References:
* glibc bugzilla entry (with patch and upstream commit):
https://sourceware.org/bugzilla/show_bug.cgi?id=19285

Thanks,
Helge

Bug#809682: [pkg-gnupg-maint] Bug#809682: pinentry-qt4: pinentry dialog does not support pasting from clipboard

[Daniel Kahn Gillmor]

Control: force-merge 766108 809682

Hi Kynn--

(moving security mailing lists to bcc)

in https://bugs.debian.org/809682 , Kynn Jones  wrote:

> The pinentry password dialog does not support paste in any form, as
> far as I can tell.  Neither Ctrl-V nor Ctrl-Shift-V work, nor is
> pasting supported through a right-click-accessible context-specific
> menu.

This was resolved back in 0.9.0 for gtk2, and slightly more recently for
qt.  All the versions in testing are fixed already.  (see also
https://bugs.debian.org/766108 which discusses the same issue).

I agree with you that being able to copy/paste is better for both
usability and security than not being able to, but i also don't think
this is a grave bug.   If you've tried a newer version of pinentry, and
you find you can't copy/paste, please report back here!

Regards,

--dkg

Bug#809764: libqb6-dev and libqb-dev: error when trying to install together

[Herbert Fortes (hpfn)]

Hi Ralf,

Em 03-01-2016 17:53, Ralf Treinen escreveu:

Package: libqb-dev,libqb6-dev
Version: libqb-dev/0.17.2.real-4
Version: libqb6-dev/6.2.0-3
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2016-01-03
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:




[...]

Preparing to unpack .../libqt5qml5_5.5.1-3_amd64.deb ...
Unpacking libqt5qml5:amd64 (5.5.1-3) ...
Selecting previously unselected package libqb6.
Preparing to unpack .../libqb6_6.2.0-3_amd64.deb ...
Unpacking libqb6 (6.2.0-3) ...
Selecting previously unselected package libqb6-dev.
Preparing to unpack .../libqb6-dev_6.2.0-3_amd64.deb ...
Unpacking libqb6-dev (6.2.0-3) ...
dpkg: error processing archive 
/var/cache/apt/archives/libqb6-dev_6.2.0-3_amd64.deb (--unpack):
  trying to overwrite '/usr/lib/x86_64-linux-gnu/libqb.so', which is also in 
package libqb-dev 0.17.2.real-4
Processing triggers for libc-bin (2.21-6) ...
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
  /var/cache/apt/archives/libqb6-dev_6.2.0-3_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.


As I understand, 'Conflicts' can be a solution. The packages
are for complete different use. And they are *-dev packages.



Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

   /usr/lib/x86_64-linux-gnu/libqb.so

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.



regards,
Herbert

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Norbert Preining]

On Mon, 04 Jan 2016, Norbert Preining wrote:
> > I also reminded him about xindy still using dpatch and about the
> > existence of newer upstream versions (up to 2.5.1).
> 
> I first wanted to fix the current problems, then I will upgrade
> to last version.

BTW - where do you get newer versions ???

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#809740: initramfs-tools: Completely ignores rootdelay

[Ben Hutchings]

Control: reassign -1 udev 220-4

On Sun, 2016-01-03 at 16:21 +0100, Christoph Egger wrote:
> Package: initramfs-tools
> Version: 0.120
> Severity: important
> 
> Hi!
> 
> the initramfs totally ignores the rootdelay / rootwait parameters and
> just instantly boots up.
[...]

It has never implemented 'rootwait' as it will always wait for devices
to appear.

The 'rootdelay=' parameter used to be implemented in udev's script, but
this was wrongly removed recently for spurious reasons.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#733097: jenkins: FTBFS when built against Groovy 2.2.1

[Miguel Landaeta]

severity 733097 serious
thanks

Bumping the severity of this bug since "stretch" is only going to
include groovy 2.x but this package still depends on groovy 1.x.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#809206: so can I delete them by hand?

[積丹尼 Dan Jacobson]

So can I delete them anyway?

Bug#796623: hdparm: Has init script in runlevel S but no matching service file

[Felipe Sateler]

Control: tags -1 patch

Hi,

On Sat, 22 Aug 2015 22:22:00 -0300 fsate...@debian.org wrote:
> Your package hdparm has an initscript that is enabled in runlevel S,
> but it does not provide a corresponding systemd service unit.

Please find attached a service file that invokes the init script. The
init script is a full fledged program, so one cannot bypass it. A few
comments:

1. Init scripts should be thin wrappers around a real program. It
would be good to split the program out of the initscript and possibly
forward it upstream. Because initscripts are conffiles, changes in the
program are not guaranteed to be delivered to users.

2. The script should probably be changed to use /run/lock instead of
/var/lock, and add a dependency on mountkernfs. If this is done, then
the RequiresMountsFor should be dropped in the service file. The
current design is racy, as /var/lock is not guaranteed to exist by the
time hdparm runs (/var may be a remote filesystem). The move to /run
happened for wheezy so there should be no problem doing the switch.
Moreover, flock lives in /usr, which is not guaranteed to have been
mounted until mountall.sh has been run. This is not a problem under
systemd (the initramfs will mount /usr) but it is problematic for
sysvinit systems.

3. The init script does not check for the existence of /sbin/hdparm
and exit 0 if it does not exist (policy 9.3.2)

4. I do not see a reason to pause boot until hdparm has finished
running. Thus I removed the Before=sysinit.target ordering, and thus
removing a possible dependency loop when /var is a remote file system.


-- 
Saludos,
Felipe Sateler


hdparm.service
Description: Binary data

Bug#809787: gnome-shell: 100% CPU when pasting - Error transferring wayland clipboard to X11

[Craig Small]

Package: gnome-shell
Version: 3.18.3-2
Severity: important

I am regularly having problems with gnome-shell becoming unresponsive and then
consuming 100% of the CPU. It always occurs around copy and pasting.

My user logs show nothing particularly interesting and then have 1000s of these
sorts of lines:
Jan  4 13:23:19 elmo gnome-session[16684]: (gnome-shell:16692): mutter-WARNING
**: Error transfering wayland clipboard to X11: Operation was cancelled

To give you an idea, in that one second I had 5006 of those identical lines. In
the next 10 seconds I had 124749 of these log lines.

The only fix is to login remotely and kill that process.



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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  evolution-data-server3.18.3-1
ii  gir1.2-accountsservice-1.0   0.6.40-3
ii  gir1.2-atspi-2.0 2.18.3-3
ii  gir1.2-caribou-1.0   0.4.19-1
ii  gir1.2-clutter-1.0   1.24.2-1
ii  gir1.2-freedesktop   1.46.0-3
ii  gir1.2-gcr-3 3.18.0-1
ii  gir1.2-gdesktopenums-3.0 3.18.1-1
ii  gir1.2-gdm-1.0   3.18.2-1
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.46.0-3
ii  gir1.2-gnomebluetooth-1.03.18.1-1
ii  gir1.2-gnomedesktop-3.0  3.18.2-1
ii  gir1.2-gtk-3.0   3.18.6-1
ii  gir1.2-gweather-3.0  3.18.1-1
ii  gir1.2-ibus-1.0  1.5.11-1
ii  gir1.2-mutter-3.03.18.2-1
ii  gir1.2-networkmanager-1.01.0.10-1
ii  gir1.2-nmgtk-1.0 1.0.10-1
ii  gir1.2-pango-1.0 1.38.1-1
ii  gir1.2-polkit-1.00.105-14
ii  gir1.2-soup-2.4  2.52.2-1
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-1
ii  gir1.2-upowerglib-1.00.99.3-1+b2
ii  gjs  1.44.0-1
ii  gnome-backgrounds3.18.0-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gnome-settings-daemon3.18.2-1
ii  gnome-shell-common   3.18.3-2
ii  gsettings-desktop-schemas3.18.1-1
ii  libatk-bridge2.0-0   2.18.1-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.21-6
ii  libcairo21.14.4-1
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libclutter-1.0-0 1.24.2-1
ii  libcogl-pango20  1.22.0-1
ii  libcogl201.22.0-1
ii  libcroco30.6.11-1
ii  libdbus-glib-1-2 0.102-1
ii  libecal-1.2-19   3.18.3-1
ii  libedataserver-1.2-213.18.3-1
ii  libgcr-base-3-1  3.18.0-1
ii  libgdk-pixbuf2.0-0   2.32.3-1
ii  libgirepository-1.0-11.46.0-3
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.44.0-1
ii  libglib2.0-0 2.46.2-3
ii  libgstreamer1.0-01.6.2-1
ii  libgtk-3-0   3.18.6-1
ii  libical1a1.0.1-0.1
ii  libjson-glib-1.0-0   1.0.4-2
ii  libmozjs-24-024.2.0-3
ii  libmutter0g  3.18.2-1
ii  libnm-glib4  1.0.10-1
ii  libnm-util2  1.0.10-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpolkit-agent-1-0  0.105-14
ii  libpolkit-gobject-1-00.105-14
ii  libpulse-mainloop-glib0  7.1-2
ii  libpulse07.1-2
ii  libsecret-1-00.18.3-1
ii  libstartup-notification0 0.12-4
ii  libsystemd0  228-2+b1
ii  libtelepathy-glib0   0.24.1-1.1
ii  libx11-6 

Bug#738138: php-file-find: changing from ITP to RFP

[Lucas Nussbaum]

On 04/01/16 at 00:20 +0100, François-Régis wrote:
> Le 27/12/2015 13:17, Lucas Nussbaum a écrit :
> > A long time ago, you expressed interest in packaging php-file-find. 
> > Unfortunately,
> > it seems that it did not happen. In Debian, we try not to keep ITP bugs open
> > for a too long time, as it might cause other prospective maintainers to
> > refrain from packaging the software.
> > 
> > This is an automatic email to change the status of php-file-find from ITP
> > (Intent to Package) to RFP (Request for Package), because this bug hasn't 
> > seen
> > any activity during the last 12 months.
> > 
> > If you are still interested in packaging php-file-find, please send a mail 
> > to
> >  with:
> 
> The problem is that this package is under php licence and not maintained
> upstream. sathieu (Mathieu Parent) has filled a bug upstream [1] and I
> unsuccefully tried to contact upstream authors.
> 
> [1] http://pear.php.net/bugs/bug.php?id=20256
> 
> The reason of the ITP is that php-file-find is a dependency of horde
> 5.1.5 and we have some packages unmainted by pear with php licence and
> vanished author.
> 
> If someone has an idea on how to deal with this, regarding the fact that
> these packages are mostly basic ?

Hi Francois-Regis,

You should get in touch with the Debian PHP team. See
https://wiki.debian.org/Teams/DebianPHPGroup
 
Lucas

Bug#766813: spurious library links

[Nathan Scott]

- Original Message -
> [...]
> If you do not think that this library is still useful for modern
> software then I recommend asking for its removal.
> 

I completely support that - would you mind doing the legwork with the
ftp-masters, Marco?

Many thanks!

--
Nathan

Bug#749662: please update ifuse

[Dan Jacobson]

Please update ifuse.
We want to use the new --arguments!

Bug#727768: pytrainer: fails to import gpx files

[Christian PERRIER]

Quoting Marcelo Santana (marc...@msantana.eng.br):

> Idem.
> 
> > I can of course do both 1) and 2) but I don't really know when...:-)
> > 
> > Giving you commit access to the packaging git repository is certainly
> > something I'd be happy to do if you're OK with this. I'd then just
> > need the name of your Alioth account if you already have one.
> 
> My Alioth account is darkstar-guest.
> 
> > Thanks again for your interest in this packaging work.
> 
> It's a pleasure to help the Debian pkg-running team especially now that
> I have become addicted to running. :-)


Here you go : your alioth account can now push to the git
repository

And now's your challenge (the one I'm kinda failing to): keep enough
time to do Debian work and not use all your free time for running..:-)




signature.asc
Description: PGP signature

Bug#766810: tagging 766810

[Marco d'Itri]

On Sep 06, Samuel Thibault  wrote:

> tags 766810 + pending
> thanks
This bug has been tagged pending for a while but it was not fixed in the
later uploads, do you need any help?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#766813: spurious library links

[Marco d'Itri]

On Jan 04, Nathan Scott  wrote:

> Sorry, I'm juggling many balls & this has been off the radar for a long
> time.  Help is *always* very welcome, thanks!  I think also nothing else
> (packages) depends on libdm anymore - used to be xfsdump? - so perhaps it
> should be removed entirely from the archive.
Indeed, no package in the archive depends on it and it has been removed 
from testing due to a FTBFS bug.
I checked and neither xfsdump nor xfsprogs depend on it since at least 
oldoldstable.
If you do not think that this library is still useful for modern 
software then I recommend asking for its removal.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#258096: Happy New Year

[Anderson Christine (NHS EAST LANCASHIRE CCG)]

Happy New Year Raymond Scott Charity Foundation is committed to giving back to 
the world out of his Jackpot Wins ; write to: 
(raymond38sc...@hotmail.com) for 
claims/details if interested and please delete this message if you not 
interested.

Regards ,
Raymond Scott

























































































































































































































































































































































































































































































































































































































































This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere

Bug#766811: spurious library links

[Marco d'Itri]

On Oct 26, Marco d'Itri  wrote:

> These links do not appear to have any purpose and should be removed:
> 
> /lib/libhandle.a -> /usr/lib/libhandle.a
> /lib/libhandle.la -> /usr/lib/libhandle.la
> /usr/lib/libhandle.so -> /lib/libhandle.so
> 
> Also, policy forbids to thip the .la files at all for normal libraries.
This is an obvious bug and I have not heard back from you in over one
year, what are your plans about fixing this? Do you need help?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#766810: tagging 766810

[Samuel Thibault]

Marco d'Itri, on Mon 04 Jan 2016 05:39:54 +0100, wrote:
> This bug has been tagged pending for a while but it was not fixed in the
> later uploads, do you need any help?

There has been no upload since the tagging, simply :)

No help is needed, thanks.
Samuel

Bug#708494: dh-make: please add --parallel to the default arguments of dh

[Paul Wise]

On Mon, 2016-01-04 at 17:32 +1100, Craig Small wrote:

> After looking at Joeyh's comments regarding the parallel builds I'm
> going to no add this flag as a default. It would be better this was
> tested more rather than silently just happen for new packages.

FYI, parallel mode will be the default in debhelper compat 10,
so if you intend to at some point switch to compat 10 then
keep in mind that is the same as using parallel mode by default.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#766813: spurious library links

[Marco d'Itri]

On Oct 26, Marco d'Itri  wrote:

> These links do not appear to have any purpose and should be removed:
> 
> /lib/libdm.a -> /usr/lib/libdm.a
> /lib/libdm.la -> /usr/lib/libdm.la
> /usr/lib/libdm.so -> /lib/libdm.so
> 
> Also, policy forbids to thip the .la files at all for normal libraries.
This is an obvious bug and I have not heard back from you in over one
year, what are your plans about fixing this? Do you need help?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Norbert Preining]

Dear all,

> I also reminded him about xindy still using dpatch and about the
> existence of newer upstream versions (up to 2.5.1).

For those who are interested, here are preliminary packages
of xindy 2.5.1 from TeX Live sources 20150104 (today):

deb http://www.preining.info/debian/ xindy main
deb-src http://www.preining.info/debian/ xindy main

(amd64)

If someone can give it some tests that would be great.

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#767930: files with the same name installed in / and /usr

[Marco d'Itri]

On Nov 03, Marco d'Itri  wrote:

> The attached patch solves this problem by creating the link in postinst
> and only if it is needed.
I have not heard back from you in over one year, what are your plans
about fixing this? Do you need a NMU?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#806364: [Python-modules-team] Bug#806364: Bug#806364: python-django-extensions: FTBFS with Django 1.9

[Brian May]

Brian May  writes:

> Filled upstream at
> https://github.com/django-extensions/django-extensions/issues/769

Upstream fixed the problem, but the fix was broken and had to be
reverted. See:

https://github.com/django-extensions/django-extensions/issues/796
https://github.com/django-extensions/django-extensions/issues/781

Upstream are currently discussing a new solution to the problem.
-- 
Brian May 

Bug#809795: O: libbio-das-lite-perl

[Petter Reinholdtsen]

Package: wnpp
Severity: normal

The maintainer of the libbio-das-lite-perl have not done an upload for
many years, and the email address bounces.  Because of this, I orphan
his two non-team maintained packages.

--
Happy hacking
Petter Reinholdtsen

Bug#766808: spurious library link

[Marco d'Itri]

On Oct 26, Marco d'Itri  wrote:

> This link does not appear to have any purpose and should be removed:
> 
> /usr/lib/i386-linux-gnu/libusb-0.1.so.4 -> /lib/i386-linux-gnu/libusb-0.1.so.4
This is an obvious bug and I have not heard back from you in over one
year, what are your plans about fixing this? Do you need help?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#766813: spurious library links

[Nathan Scott]

Hi Marco,

- Original Message -
> On Oct 26, Marco d'Itri  wrote:
> 
> > These links do not appear to have any purpose and should be removed:
> > 
> > /lib/libdm.a -> /usr/lib/libdm.a
> > /lib/libdm.la -> /usr/lib/libdm.la
> > /usr/lib/libdm.so -> /lib/libdm.so
> > 
> > Also, policy forbids to thip the .la files at all for normal libraries.
> This is an obvious bug and I have not heard back from you in over one
> year, what are your plans about fixing this? Do you need help?

Sorry, I'm juggling many balls & this has been off the radar for a long
time.  Help is *always* very welcome, thanks!  I think also nothing else
(packages) depends on libdm anymore - used to be xfsdump? - so perhaps it
should be removed entirely from the archive.

cheers.

--
Nathan

Bug#809790: RM: dmapi -- ROM; not useful anymore

[Marco d'Itri]

Package: ftp.debian.org
Severity: normal

As discussed with the maintainer in #766813, the dmapi package has been 
obsolete since at least oldoldstable and FTBFS, so it should be removed 
from the archive.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#809788: Failed to install Xenial in UEFI mode, failed with "grub-efi-amd64-signed package failed to install into /target/"

[Po-Hsu Lin]

Package: grub-installer
Version: 2.02~beta2-32ubuntu1

When I try to install the Ubuntu Xenial desktop dailylive image from
http://cdimage.ubuntu.com/daily-live/current/
I can't finish the installation in UEFI mode. It will fail with the
following error message:

The 'grub-efi-amd64-signed' package failed to install into /target/.
Without GRUB boot loader, the installed system will not boot.

And there is only an "OK" button on the dialog, after pressing it, it
will report that the installer has crashed, and direct me to the bug
report page.

This issue does not exist in Legacy BIOS mode.

Bug report on launchpad: https://bugs.launchpad.net/bugs/1521132

Bug#808095: squid3: Squid3 UNAVAILABLE

[Amos Jeffries]

On Tue, 15 Dec 2015 15:52:40 -0800 root wrote:
>
> Tried installing squid 3 on wheezy with aptitude with following error:
>
> squid3:i386 depends on logrotate:i386 (>= 3.5.4-1)
> squid3:i386 depends on netbase:i386 [UNAVAILABLE]
> squid3:i386 depends on squid3-common:i386 (= 3.1.20-2.2deb7ue)
[UNAVAILABLE]

This appears to be file corruption in your apt-get/aptitude state data.
There has never been a 3.1.20-2.2deb7ue version of either squid3 or
squid3-common.

The Debian repositories contain version "3.1.20-2.2+deb7u3" - note the
"+" and "3" characters.

Amos

Bug#617820: biosdevname: changing from ITP to RFP

[D. Jared Dominguez]

On Sun, Dec 27, 2015 at 06:16:58AM -0600, Lucas Nussbaum wrote:

retitle 617820 RFP: biosdevname -- takes a kernel device name as an argument, 
and returns the BIOS-given name.
noowner 617820
tag 617820 - pending
thanks

Hi,

A long time ago, you expressed interest in packaging biosdevname. Unfortunately,
it seems that it did not happen. In Debian, we try not to keep ITP bugs open
for a too long time, as it might cause other prospective maintainers to
refrain from packaging the software.

This is an automatic email to change the status of biosdevname from ITP
(Intent to Package) to RFP (Request for Package), because this bug hasn't seen
any activity during the last 12 months.

If you are still interested in packaging biosdevname, please send a mail to
 with:

retitle 617820 ITP: biosdevname -- takes a kernel device name as an argument, 
and returns the BIOS-given name.
owner 617820 !
thanks

It is also a good idea to document your progress on this ITP from time to
time, by mailing <617...@bugs.debian.org>.  If you need guidance on how to
package this software, please reply to this email, and/or contact the
debian-ment...@lists.debian.org mailing list.

Thank you for your interest in Debian,
--
Lucas, for the QA team 


Sorry, I meant to change the status and forgot to. Based on changes in 
systemd and in Ubuntu and the general direction of network device 
naming, I decided it's not worth the effort at this point. However, if 
anyone wants to pick this up, here's the packaging from Ubuntu 
modernized for dh9 and DEP-5 (and using gbp):


http://linux.dell.com/cgi-bin/cgit.cgi/biosdevname.git/log/?h=debian

--Jared

Bug#766812: spurious library link

[Marco d'Itri]

reassign 766812 musl-dev
found 766812 1.1.5-1
tag 766812 patch
thanks

On Mar 31, Kevin Bortis  wrote:

> The link is needed for various tools that expect a link or the real
> libc.so be available in the same location as the includes and other
> resources. One prominent member is musl-gcc from the musl-tools
> package, which would fail to dynamic link to the correct libc.so.
Looks like I missed your reply.

The attached patch solves this problem by creating the link in postinst
and only if it is needed.

For more information about merged /usr please read
http://anonscm.debian.org/cgit/users/md/usrmerge.git/tree/debian/README.Debian

-- 
ciao,
Marco
diff -urNp musl-1.1.9/debian/musl-dev.links musl-1.1.9+nmu1/debian/musl-dev.links
--- musl-1.1.9/debian/musl-dev.links	2015-04-01 07:13:51.0 +0200
+++ musl-1.1.9+nmu1/debian/musl-dev.links	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-#! /usr/bin/dh-exec
-/lib/${MUSL_TRIPLE}/libc.so /usr/lib/${MUSL_TRIPLE}/libc.so
diff -urNp musl-1.1.9/debian/musl-dev.postinst.in musl-1.1.9+nmu1/debian/musl-dev.postinst.in
--- musl-1.1.9/debian/musl-dev.postinst.in	1970-01-01 01:00:00.0 +0100
+++ musl-1.1.9+nmu1/debian/musl-dev.postinst.in	2016-01-04 06:54:39.707459093 +0100
@@ -0,0 +1,8 @@
+#!/bin/sh -e
+
+if [ "$1" = 'configure' -a ! -e /usr/lib/@MUSL_TRIPLE@/libc.so ]; then
+  ln -s /lib/@MUSL_TRIPLE@/libc.so /usr/lib/@MUSL_TRIPLE@/libc.so
+fi
+
+#DEBHELPER#
+
diff -urNp musl-1.1.9/debian/musl-dev.postrm.in musl-1.1.9+nmu1/debian/musl-dev.postrm.in
--- musl-1.1.9/debian/musl-dev.postrm.in	1970-01-01 01:00:00.0 +0100
+++ musl-1.1.9+nmu1/debian/musl-dev.postrm.in	2016-01-04 07:02:03.145325138 +0100
@@ -0,0 +1,8 @@
+#!/bin/sh -e
+
+if [ "$1" = 'remove' -a -L /usr/lib/@MUSL_TRIPLE@/libc.so ]; then
+  rm /usr/lib/@MUSL_TRIPLE@/libc.so
+fi
+
+#DEBHELPER#
+
diff -urNp musl-1.1.9/debian/rules musl-1.1.9+nmu1/debian/rules
--- musl-1.1.9/debian/rules	2015-05-14 09:16:57.0 +0200
+++ musl-1.1.9+nmu1/debian/rules	2016-01-04 07:05:07.239711327 +0100
@@ -69,3 +69,15 @@ override_dh_fixperms:
 
 override_dh_gencontrol:
 	dh_gencontrol -- $(GENCTRL_OPTIONS)
+
+override_dh_clean:
+	rm -f debian/musl-dev.postinst debian/musl-dev.postrm
+	dh_clean
+
+override_dh_installdeb:
+	sed 's/@MUSL_TRIPLE@/$(MUSL_TRIPLE)/g' \
+		debian/musl-dev.postinst.in > debian/musl-dev.postinst
+	sed 's/@MUSL_TRIPLE@/$(MUSL_TRIPLE)/g' \
+		debian/musl-dev.postrm.in > debian/musl-dev.postrm
+	dh_installdeb
+


signature.asc
Description: PGP signature

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Philippe Cerfon]

On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER  wrote:
> Discussing infrastructure changes like what you're proposing (which I
> have no advice about) should usually be done through our mailing
> lists,
Which one would be the appropriate list?

I thought general would fit, as it likely affects multiple packages
and infrastructure systems form Debian.
Anyway, I don't mind to forward this to some list as well.

Thanks,
Philippe.

Bug#807579: Updated patches for CUDA 7.5

[lumin]

Hi doko,

Thank you for the comments.

On Sun, 2016-01-03 at 18:55 +0100, Matthias Klose wrote:
> some comments about the v4 patch:
> 
>   - Please could you put your generated tarball to some place?

The original source is very huge (~1GiB+), and it will grow
up to ~2GiB after adding the ppc64el "source" contents.
However my current ISP is accounting the traffic flow, so you know.
:-(

>   - could you just remove the man-* patches?

Yes, seems that my python scripts for autofixing work well,
so there remains no reason to keep them.

>   - could you remove the MISSING lines in the symbols files?
>   - dh_strip is overridden to do nothing. same thing should be
> done with dh_strip_nondeterminism.

Yes, I'll keep these in mind.

>   - dh_install --list-missing lists some non-installed files.
> Are these all not installed by intent?

Just the opposite, almost all of them are installed.
And the very long list of --list-missing is a historical
problem for the CUDA package ..
Due to path change (e.g. from /usr/opt/ to /usr/ ), --list-missing
considers them not installed.

in d/rules, there are some $RM operations to decrease
the length of --list-missing, however, it doesn't work all the time.

1. introduce a "--list-missing-by-checksum" to debhelper ?
   this is very slow but may be used by other packages.
2. fix paths in debian/tmp before dh_install.
   this will only work in the CUDA package.

> dh_install: usr/CUDA_Toolkit_Release_Notes.txt exists in debian/tmp but is 
> not 
> installed to anywhere
[...]

By the way, the missing CUDA support for ppc64el blocks 7.5
(missing it is a mistake. ppc64el support is available 
since CUDA version 7.0).

See BUG #808883
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808883

So I plan to
1. prepare CUDA-7.0.28+ds1-1, adding missing ppc64el "source".
2. migrate some changes from this BUG into the +ds1 upload.

Bug#809792: RFS: sagemath-database-graphs -- databases of graphs

[Julien Puydt]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sagemath-database-graphs" -- 
a previous version is already in Debian, so this is only an update :


 * Package name: sagemath-database-graphs
   Version : 20151224
   Upstream Author : R. Andrew Ohana 
 * URL : http://www.sagemath.org/packages/standard/
 * License : GPL-2+
   Description : Databases of graphs

   It builds those binary packages:

sagemath-database-graphs - Databases of graphs

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


  http://mentors.debian.net/package/sagemath-database-graphs

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

dget -x 
http://mentors.debian.net/debian/pool/main/s/sagemath-database-graphs/sagemath-database-graphs_20151224+dfsg-1.dsc


  It is packaged within the Debian Science team here:

Vcs-Git: git://anonscm.debian.org/debian-science/packages/pynac.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/debian-science/packages/sagemath-database-graphs.git


  It is a dep of sagemath.

  Thanks,

  Snark on #debian-science

Bug#749662: please update ifuse

[Dan Jacobson]

e.g., 
http://askubuntu.com/questions/685268/mounting-an-ipad-documents-folder-in-15-04

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Niels Thykier]

Philippe Cerfon:
> On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER  wrote:
>> Discussing infrastructure changes like what you're proposing (which I
>> have no advice about) should usually be done through our mailing
>> lists,
> Which one would be the appropriate list?
> 
> I thought general would fit, as it likely affects multiple packages
> and infrastructure systems form Debian.
> Anyway, I don't mind to forward this to some list as well.
> 
> Thanks,
> Philippe.
> 

Your second item has been brought up before with different
focus/rationale/purpose.  At least I remember there being an interest in
splitting "non-free" into "non-free/firmware" vs. various other non-free
sub components.

Mind you, its primary goal was not to address "source vs. no-source",
but it is the closest related idea I could think of.  Sadly, I don't
have a reference ready to backup my memory.


On your first item, I would have to agree with Christian.  It is not
actionable and much less by Debian.  At best we could stop packaging
such software or disabling such features, but both have their disadvantages:

 * Even if we stop shipping them, people will still download them.
   Except your average user will probably be worse off because most of
   them do not verify their downloads.
 * If we disable the functionality, we would "cripple" the software to
   many people.  If this annoys people, we will end up in a situation
   where people will advise /against/ using the Debian package because
   it is "crippled", which leads to the situation above.  Or we could
   get badly unpopular with upstream (see the "Debian vs. Ruby" issue
   from a couple of years ago).


Thanks,
~Niels

Bug#809793: One of the uploader addresses no longer work

[Petter Reinholdtsen]

Package: librtf-writer-perl
Version: 1.11-2

When trying to email Richard Holland, I get a bounce from the mail
system stating that the address no longer work.  I suspect it should be
removed from the control file.

Note, this was discovered this summer and reported as
https://bugs.debian.org/793959 > for another of the three packages
he maintain in Debian.

-- 
Happy hacking
Petter Reinholdtsen

Bug#767926: files with the same name installed in / and /usr

[Marco d'Itri]

On Nov 03, Marco d'Itri  wrote:

> The attached patch solves this problem by creating the link in postinst
> and only if it is needed.
I have not heard back from you in over one year, what are your plans
about fixing this? Do you need a NMU?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#809789: gawk: %G returns the date as 2015 It is 2016

[Brendan Reilly]

Package: gawk
Version: 1:4.0.1+dfsg-2.1
Severity: important

Dear Maintainer,

%G returns the date as 2015It is 2016



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gawk depends on:
ii  libc6 2.13-38+deb7u8
ii  libreadline6  6.2+dfsg-0.1
ii  libsigsegv2   2.9-4

gawk recommends no packages.

Versions of packages gawk suggests:
pn  gawk-doc  

-- no debconf information

Bug#767927: files with the same name installed in / and /usr

[Marco d'Itri]

On Nov 03, Marco d'Itri  wrote:

> The attached patch solves this problem by creating the link in postinst
> and only if it is needed.
I have not heard back from you in over one year, what are your plans
about fixing this? Do you need a NMU?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#767925: files with the same name installed in / and /usr

[Marco d'Itri]

On Nov 03, Marco d'Itri  wrote:

> The attached patch solves this problem by creating the link in postinst
> and only if it is needed.
I have not heard back from you in over one year, what are your plans 
about fixing this? Do you need a NMU?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#767921: please test updated cryptsetup packages

[Marco d'Itri]

On Dec 08, Jonas Meurer  wrote:

> #767921: files with the same name installed in / and /usr
This bug has been tagged pending for a while but it was not fixed in the
later uploads, do you need any help?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#767710: files with the same name installed in / and /usr

[Marco d'Itri]

On Apr 26, Marco d'Itri  wrote:

> That's great, because locally written scripts will probably not be run 
> while installing coreutils in d-i or upgrading from Debian 8 to Debian 
> 9, so this does not look like a significant concern.  The symlink will 
> always exist during regular coreutils upgrades.
I have not heard from you in many months: do you still have concerns 
about how to fix this? Do you need help?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#767923: files with the same name installed in / and /usr

[Marco d'Itri]

On Nov 03, Marco d'Itri  wrote:

> The attached patch solves this problem by creating the link in postinst
> and only if it is needed.
I have not heard back from you in over one year, what are your plans
about fixing this? Do you need a NMU?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#767928: files with the same name installed in / and /usr

[Marco d'Itri]

On Nov 03, Marco d'Itri  wrote:

> The attached patch solves this problem by creating the link in postinst
> and only if it is needed.
I have not heard back from you in over one year, what are your plans
about fixing this? Do you need a NMU?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#795743: python3-celery build-depends on python3-memcache, which will be soon removed from stable

[Brian May]

Hugo Lefeuvre  writes:

> Sorry, I've been unclear. I intended to highlight the fact that there aren't 
> any problems on Unstable and Testing. The only distribution being affected by
> this "bug" is Stable.

FYI I believe the correct way to deal with this would be to assign the
jessie tag to the bug.

See https://www.debian.org/Bugs/Developer#tags fo details.

So I could reopen this bug and assign it the jessie tag if you want?
-- 
Brian May 

Bug#809791: RM: gogoc -- ROM; unmaintained, upstream behind login

[Craig Small]

Package: ftp.debian.org
Severity: normal

Hi,
  As the Debian maintainer of gogoc aka gw6c I am asking for the ftp
masters to remove this from the Debian archive. I placed a RFA for this
package almost exactly a year ago and there have been no takers.[1]

The upstream you are unable to get without a login[2] so I'm not sure
if that means it doesn't exist in effect or it violates some policy.
Either way, its not very good.

In my opinion, the only way forward for any TSP client is it to be
forked and maintained on an open repository. I have a habit of doing
this (e.g. procps,psmisc,gjay,lprng) but I don't have the interest or
spare time to pick up another orphan. 

As I have had native IPv6 for years I've not personally needed this
package. I'm not sure of the interest as it is only needed for IPv6
tunnels where you need TSP. Alternatives such as aiccu exist which
is in Debian already.

 - Craig

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774481
[2] http://www.gogo6.com/profile/gogoCLIENT

Bug#766809: spurious library link

[Marco d'Itri]

On Oct 26, Marco d'Itri  wrote:

> This link does not appear to have any purpose and should be removed:
> 
> /usr/lib/i386-linux-gnu/libpng12.so.0 -> /lib/i386-linux-gnu/libpng12.so.0
This is an obvious bug and I have not heard back from you in over one 
year, what are your plans about fixing this? Do you need help?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#809789: gawk: %G returns the date as 2015 It is 2016

[Bob Proulx]

severity 809789 normal
tag 809789 + moreinfo
thanks

Brendan Reilly wrote:
> Dear Maintainer,

I am not the gawk maintainer but in this just another awk user.
However I recognize this as being a misunderstanding of %G.

> %G returns the date as 2015It is 2016

%G does not return the current year.  G returns the year of the ISO
week number.  The ISO week number year is 2015 for the 1st and 2nd of
January 2016.  The ISO 8601 definition for the first week is the week
with the year's first Thursday in it.

 December 2015
  Su Mo Tu We Th Fr Sa
 1  2  3  4  5  2015
   6  7  8  9 10 11 12  2015
  13 14 15 16 17 18 19  2015
  20 21 22 23 24 25 26  2015
  27 28 29 30 31  1  2  2015
   3  4  5  6  7  8  9  2016 first Thursday
  10 11 12 13 14 15 16  2016
  17 18 19 20 21 22 23  2016
  24 25 26 27 28 29 30  2016
  312016

This is actually an FAQ for 'date' which uses the same format options.
This is not a bug.  This is simply a misunderstanding of %G which
apparently is not what you want.

  
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

  At the change of the year there are always many bug reports concerning
  date behaving incorrectly.  This is usually due to people using a
  mismatch of ISO and legacy date format specifiers.

$ date -d 2008-12-31 +%Y%V
200801

$ date -d 2008-12-31 "+%G-%m-%d"
2009-12-31

  The %Y and %U or %W options work in combination. (Use %U for weeks
  starting with Sunday or %W for weeks starting with Monday.)  The ISO %G
  and %V options work in combination.  Mixing them up creates
  confusion.  Instead use %Y and %U/%W together or use %G and %V
  together.

$ date -d 2008-12-31 +%G%V
200901

$ date -d 2009-01-01 +%G%V
200901

$ date -d 2008-12-31 +%Y%U
200852

$ date -d 2009-01-01 +%Y%U
200900

  Use of ISO week numbers tends to create confusion.  The ISO week
  numbering scheme is somewhat different from calendar week
  numbering.  ISO week numbers start on Monday of the week with the
  year’s first Thursday in it.  See Wikipidia’s ISO 8601 page
  (http://en.wikipedia.org/wiki/ISO_8601) or Wikipidia’s ISO week date
  page (http://en.wikipedia.org/wiki/ISO_week_date) for a good summary.

  ISO Week Dates can be created using the following format.

$ date -d "2009-01-07 12:00:00 +" "+%G-W%V-%u"
2009-W02-3

  See the standards documentation
  (http://www.opengroup.org/onlinepubs/9699919799/utilities/date.html)
  for more information with regards to date.

Does this resolve your issue?

Bob


signature.asc
Description: PGP signature

Bug#809794: O: libmath-bezier-perl

[Petter Reinholdtsen]

Package: wnpp
Severity: normal

The maintainer of the libmath-bezier-perl have not done an upload for
many years, and the email address bounces.  Because of this, I orphan
his two non-team maintained packages.

--
Happy hacking
Petter Reinholdtsen

Bug#809559: ruby-activerecord-session-store: Missing epoch in dependency on ruby-actionpack

[Libor Klepáč]

Hello,
I have been testing it on my computer, which has only unstable and 
experimental, it doesn't 
have yours repo.

You can check this version dependency also here:
https://packages.debian.org/sid/ruby-activerecord-session-store

With regards,
Libor


On Fri, 01 Jan 2016 13:54:43 +0100 =?utf-8?b?TGlib3IgS2xlcMOhxI0=?= 
 wrote:
> Package: ruby-activerecord-session-store
> Version: 0.1.1-1
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hello,
> it seems to me, that dependency on
> ruby-actionpack (<< 5)
> is missing epoch 2
> 
> With regards,
> Libor
> 
> - -- System Information:
> Debian Release: stretch/sid
>   APT prefers experimental
>   APT policy: (700, 'experimental'), (700, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.3.0-trunk-amd64 (SMP w/4 CPU cores)
> Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages ruby-activerecord-session-store depends on:
> ii  ruby1:2.2.4
> pn  ruby-actionpack 
> pn  ruby-activerecord   
> pn  ruby-railties   
> ii  ruby2.2 [ruby-interpreter]  2.2.3-2
> 
> ruby-activerecord-session-store recommends no packages.
> 
> ruby-activerecord-session-store suggests no packages.
> 
> - -- no debconf information
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJWhncIAAoJEPDvjG7Cn0eOTo8P/3B2HLaWJbtv3sbAl94TaP8M
> noQUX08KsxnsXqSt4hXrdPqt4C3Vn14j7vFMa8m2WI77C0z40sD2qMZ8X6sclcyW
> pssvEgLLaHeotjl/EgnW7DOTQeXIUGwNg6AakZdqO8fQo/GlIMZIMcGWDy4RVlFf
> Q4hqg4DkGUCnwlnRAxXUpdCK5gs7LEgdzNBVrvgKMCv8Z99iKZdN2wmwWKgG/Bgu
> IzhlSmgaY6EDRW0JpNWqWCY856qurNqpU0F168JZh6ZAuuKVRaOpCVxQ8aub06FP
> LFGXf0HqU2ZAXcprShb8vcxtSSLr0cbosPE7fw4FA1rE4v5IrbEP87LA9Pp8Sy/Y
> 11fWSvObtvTBfhBEO/5yzjlb49VpdOy6sdJgjbCDd/P43t0WD4NieJf2ZSAE1Nga
> Ymd1wFI7hylGEnlAChBdbCh7MdcgmrhYhkEkOhsOD7SVS8pNZMzhMlQZs4MpcfjP
> pjTMrPTIMFWG/y+9TCiKZn6GWlJ6adi9B6lwc2U/4ao6qFGg7DSYOJ8Gj8+x+aBl
> E6EkYHZGMiai0AXbvVRKxeP+VURwjacOGIRr3CNP6myb1WTbPUkY0ZijmyKZf8Xt
> Ow3RFm9+SBqRUshABfNZQyFbGbU3+tP7VJouliPJna3JQ5k5/5ZybLAPjvKqxhPt
> 4xajJAvyvvB4K4K9uJcQ
> =bcf5
> -END PGP SIGNATURE-
> 
> 

Bug#809710: mpv can never load external subtitle file.

[Tianming Xie]

Package: mpv
Version: 0.14.0-1
Severity: normal

Dear Maintainer,

After upgraded to the current version, mpv can never load external ASS subtitle
file any more, neither a subtitle file located beside the corresponding video
file, which may be loaded automatically when opening the video file, nor
explicitly assigned targets via --sub-file, with the following error log:

[cplayer] Can not open external file 

The last version does not have this bug.

Subtitles embedded as stream within video files seem not affected, but I lack
more samples to test, and now I do not have subtitle files in other formats.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-proposed-updates'), (500, 
'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages mpv depends on:
ii  libasound2  1.0.29-1
ii  libass5 0.13.1-1
ii  libavcodec-ffmpeg56 7:2.8.4-1
ii  libavdevice-ffmpeg567:2.8.4-1
ii  libavfilter-ffmpeg5 7:2.8.4-1
ii  libavformat-ffmpeg567:2.8.4-1
ii  libavutil-ffmpeg54  7:2.8.4-1
ii  libbluray1  1:0.9.2-2
ii  libc6   2.21-6
ii  libcdio-cdda1   0.83-4.2+b1
ii  libcdio-paranoia1   0.83-4.2+b1
ii  libcdio13   0.83-4.2+b1
ii  libdrm2 2.4.65-3
ii  libdvdnav4  5.0.3-1
ii  libdvdread4 5.0.3-1
ii  libegl1-mesa [libegl1-x11]  11.0.8-1
ii  libenca01.16-2
ii  libgl1-mesa-glx [libgl1]11.0.8-1
ii  libguess1   1.2-1
ii  libjack-jackd2-0 [libjack-0.116]1.9.10+20150825git1ed50c92~dfsg-1
ii  libjpeg62-turbo 1:1.4.1-2
ii  liblcms2-2  2.6-3+b3
ii  liblua5.2-0 5.2.4-1
ii  libpulse0   7.1-2
ii  librubberband2  1.8.1-6+b1
ii  libsdl2-2.0-0   2.0.2+dfsg1-8
ii  libsndio6.0 1.0.1-2
ii  libswresample-ffmpeg1   7:2.8.4-1
ii  libswscale-ffmpeg3  7:2.8.4-1
ii  libva-wayland1  1.6.2-1
ii  libva-x11-1 1.6.2-1
ii  libva1  1.6.2-1
ii  libvdpau1   1.1.1-3
ii  libwayland-client0  1.9.0-1
ii  libwayland-cursor0  1.9.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]  11.0.8-1
ii  libx11-62:1.6.3-1
ii  libxext62:1.3.3-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.5.0-1
ii  libxrandr2  2:1.5.0-1
ii  libxss1 1:1.2.2-1
ii  libxv1  2:1.0.10-1+b1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages mpv recommends:
ii  xdg-utils   1.1.1-1
ii  youtube-dl  2015.11.27.1-1

mpv suggests no packages.

-- no debconf information

Bug#700317: sbuild -s fails if package has Build-Depends-Indep

[Johannes Schauer]

Hi,

Quoting Ian Campbell (2015-12-30 15:16:13)
> On Thu, 2015-12-24 at 01:07 +0100, Johannes Schauer wrote:
> > Sbuild is for building binary packages. If you want to build a source
> > package,
> > then don't use sbuild but either use:
> > 
> > $ dpkg-buildpackage -S
> > 
> > or
> > 
> > $ dpkg-source -b .
> > 
> > A source package is the *input* to sbuild not its output.
> 
> This is a good point, not a way I'd thought about it until now. I guess
> I was simply confused because I typically run sbuild from a source
> package directory and it automagically makes a .dsc for me.

when run from an unpacked source directory, sbuild first produces the source
package using dpkg-source and *then* runs sbuild on that. I think all of the
above is explained at the very top of the sbuild man page:

 | sbuild rebuilds Debian binary packages from the  correspond‐
 | ing  Debian  source, installing any missing source dependen‐
 | cies.  The build takes place  in  a  dedicated  clean  build
 | environment (chroot), rather than on the host system.
 |
 | sbuild can fetch the Debian source over a network, or it can
 | use locally available sources.
 |
 | sbuild is given a packages to process as the argument  PACK‐
 | AGE[.dsc].  This argument is in the form of either a debian‐
 | ized package source directory, a source package  name  along
 | with  a version in the form package_version, or a .dsc file.
 | If no arguments are given, the current working directory  is
 | passed as an argument.
 |
 | For  arguments  given  as source directories, dpkg-source is
 | first run to produce a source .dsc file. Then,  the  package
 | is  built using the .dsc produced. For arguments in the form
 | package_version, apt is used to download the source package.
 | For arguments given as a .dsc file, sbuild builds the source
 | packages directly. For .dsc files in remote  locations,  the
 | source packages are downloaded first, then built.

Personally I find that this is clear. If it wasn't clear for you, I'd like to
hear which part needs clarification or even better a suggestion of how the
documentation can be improved.

> > If you really, really want sbuild to also generate a source package, then
> > you can add the -s or --source option. As the man page points out, this
> > will run dpkg-buildpackage without the -B option (which would do a
> > binary-only build, limited to architecture dependent packages, which is the
> > default mode of operation of sbuild). Thus dpkg-buildpackage will *also*
> > create a source package *in addition* to the binary packages it creates.
> > This is why all the build dependencies are needed.
> [...
> > If you have an idea how the documentation can be improved to prevent this 
> > kind
> > of misunderstanding in the future, I'd be happy to hear it!
> 
> I think adding some of the wording you use above to the --source
> documentation would do the trick. In particular "in addition to the
> binary packages" or something along those lines.
> 
> Maybe you would also want to add "this is the default" to the --no
> -source option?
> 
> One thing I'm still not sure of, is if you run in the mode where a
> source package directory is passed as an argument, and sbuild therefore
> runs dpkg-source -b for you, but you also pass -s, am I correct in
> thinking that a second .dsc will then be generated by dpkg-buildpackage
> and included in the .changes file and that this will be a different
> .dsc (timestamps etc) to the one which sbuild made (which is thrown
> away)?

All these questions should be answered by the following update to the sbuild
man page:


diff --git a/man/sbuild.1.in b/man/sbuild.1.in
index 26befe3..65f615a 100644
--- a/man/sbuild.1.in
+++ b/man/sbuild.1.in
@@ -320,11 +320,16 @@ snapshot chroots, since by default the snapshot will 
be deleted.  Possible
 values are \fBalways\fR (default), \fBnever\fR, and \fBsuccessful\fR.
 .TP
 .BR \-s ", " "\-\-source"
-Also build source package, i.e. use dpkg\-buildpackage without \-B.
+Build the source package in addition to the other requested build 
artifacts. By
+default, the dsc will not be rewritten because the source package is the 
input
+to sbuild, not its output. Even when running from an unpacked source tree
+sbuild will first build the source package using dpkg-source and then pass 
that
+on to the sbuild machinery. Use this option only when you know what you are
+doing. This will rewrite the original dsc passed to sbuild.
 .TP
 .BR "\-\-no-source"
-Don't build source package, i.e. use dpkg\-buildpackage with \-B.  This 
option
-is the opposite of \-\-source.
+Don't rebuild the source package. This is the default. It is the opposite 
of
+\-\-source.
 .TP
 .BR "\-\-force\-orig\-source"
 When used with in conjunction with \-s, this option forces the inclusion 
of the


Please help to point out where the update is not clear to you.

> Actually, a second thing I'm