Bug#820475: [php-maint] Bug#820475: php7.0: php5 to php7.0 regression: undefined function xml_parser_create()

[Ondřej Surý]

Do you have: `apt-get install php-xml` installed?

-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Fri, Apr 8, 2016, at 21:06, Paul Gevers wrote:
> Package: php7.0
> Version: 7.0.5-2
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> In my effort to test my package cacti against php7.0 I found the
> following
> regression. With php5 the page http://localhost/cacti/graphs_new.php
> works fine
> and as expected, with php7.0 I get a 500 Internal Server error response
> due to
> undefined function xml_parser_create. As far as I dived into this, php
> could
> just support that and as the Debian package has done so for an extremely
> long
> time, I think it is a regression not to do so with php7.0.
> 
> root@sid:~# wget $loadSaveCookie
> http://localhost/cacti/graphs_new.php--2016-04-08 20:57:19-- 
> http://localhost/cacti/graphs_new.php
> Resolving localhost (localhost)... ::1, 127.0.0.1
> Connecting to localhost (localhost)|::1|:80... connected.
> HTTP request sent, awaiting response... 500 Internal Server Error
> 2016-04-08 20:57:20 ERROR 500: Internal Server Error.
> 
> root@sid:~# tail -n1 /var/log/apache2/error.log 
> [Fri Apr 08 20:57:20.116589 2016] [:error] [pid 22899] [client ::1:60646]
> PHP Fatal error:  Uncaught Error: Call to undefined function
> xml_parser_create() in /usr/share/cacti/site/lib/xml.php:29\nStack
> trace:\n#0 /usr/share/cacti/site/lib/data_query.php(81):
> xml2array('\\n\\t /usr/share/cacti/site/graphs_new.php(686): get_data_query_array('6')\n#2
> /usr/share/cacti/site/graphs_new.php(49): graphs()\n#3 {main}\n  thrown
> in /usr/share/cacti/site/lib/xml.php on line 29
> 
> root@sid:~# a2dismod php7.0
> Module php7.0 disabled.
> To activate the new configuration, you need to run:
>   service apache2 restart
> root@sid:~# a2enmod php5
> Enabling module php5.
> To activate the new configuration, you need to run:
>   service apache2 restart
> root@sid:~# service apache2 restart
> 
> 
> 
> root@sid:~# wget $loadSaveCookie http://localhost/cacti/graphs_new.php
> - --2016-04-08 21:03:44--  http://localhost/cacti/graphs_new.php
> Resolving localhost (localhost)... ::1, 127.0.0.1
> Connecting to localhost (localhost)|::1|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [text/html]
> Saving to: 'graphs_new.php.1'
> 
> graphs_new.php.1   [ <=> 
>  ]  15.18K  --.-KB/sin 0s  
> 
> 2016-04-08 21:03:45 (93.9 MB/s) - 'graphs_new.php.1' saved [15546]
> 
> 
> - -- System Information:
> Debian Release: 8.4
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable'), (50,
>   'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.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
> Init: systemd (via /run/systemd/system)
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAEBCAAGBQJXCAETAAoJEJxcmesFvXUK1o4H/03juLm753bB/yF6wO50Csjz
> gDZFbUshSi8cMkVsKlU3grsS5VKjfhZ2/sQKry4+J/cWEKmOG1IRX+aBXJH7JqG2
> jkVVHLQI5vV1rFPu+DwFL2NHCEBwBiSOIdB9L/nYkWqbNzHCApff53y4JXnDtIue
> FqP2THE53AACvn3cAUFLiB8kILSAikHS/o1ugHNsBy/qu4IkO83oZgPY+9LnlHBH
> YmXpVT3CXzhNleuEio9OCyOEany1MEUuWlLG8zeNbYazIjbsC1pcBJKDRbJxPvK8
> 1aV+I1+Jout7OT4I+HVUGMxwXXzSfanaxCp1EAeXhE+ajwV7AvO88W48/zehqUo=
> =1OZQ
> -END PGP SIGNATURE-
> 
> ___
> pkg-php-maint mailing list
> pkg-php-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint

Bug#725153: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls

[Timo Aaltonen]

08.04.2016, 20:41, Timo Aaltonen kirjoitti:
> 03.04.2016, 12:32, Timo Aaltonen kirjoitti:
>> 20.05.2015, 20:43, Ryan Tandy kirjoitti:
>>> Hi dkg,
>>>
>>> On Wed, May 20, 2015 at 12:58:08PM -0400, Daniel Kahn Gillmor wrote:
 If the work to switch openldap to NSS is strictly because of licensing
 concerns that have been resolved since the bug was opened, please
 reconsider the switch.
>>>
>>> I don't think anyone intends to switch the default libldap or slapd to
>>> nss. I personally would argue against causing that kind of upgrade pain.
>>> There's still a possibility of providing an alternate libldap built with
>>> nss, but that would take some work, and it sounds like freeipa upstream
>>> are moving away from needing it anyway. So this bug will probably just
>>> go away eventually.
>>
>> Another thing is that folks using just 389ds can't replicate it (LP:
>> #1564179) because of the same reason.. so having a libldap built against
>> nss would still be useful for some.
> 
> It is done! Or at least available for review:
> 
> http://anonscm.debian.org/cgit/users/tjaalton/openldap.git/commit/?h=nss2

In order to minimize the diff, ldap.conf could still be shipped by
libldap-2.4-2, and -nss can just depend on that. Avoids having another
single-file package in the archive.


-- 
t

Bug#806487: This was fixed in an update to binutils 2.26

[Adam Baxter]

Upstream bugs https://sourceware.org/bugzilla/show_bug.cgi?id=19538 and
https://sourceware.org/bugzilla/show_bug.cgi?id=19615

This was fixed in Debian somewhere between binutils-2.26-3 (which is
affected) and -8 (which works fine).

This can probably be closed or assigned to the binutils package.


Regards,
Adam

Bug#820496: gcompris-qt: dependencies not automatically installed

[Veronica Brandt]

Package: gcompris-qt
Version: 0.50-2
Severity: important

Dear Maintainer,

I installed gcompris-qt with apt-get but running the program came up with unmet 
dependencies on various qt libraries.

I found that gcompris-qt requires:

qml-module-qtmultimedia
qml-module-qtgraphicaleffects
qml-module-qtquick-particles2

and possibly more as I had already installed qtcreator.

I think these should be included as dependencies in the debian package.

Thanks for packaging a great program!

Veronica

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

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

Versions of packages gcompris-qt depends on:
ii  gcompris-qt-data0.50-2
ii  libc6   2.22-5
ii  libgcc1 1:5.3.1-13
ii  libqt5core5a5.5.1+dfsg-16
ii  libqt5gui5  5.5.1+dfsg-16
ii  libqt5multimedia5   5.5.1-4
ii  libqt5network5  5.5.1+dfsg-16
ii  libqt5qml5  5.5.1-3
ii  libqt5quick55.5.1-3
ii  libqt5sensors5  5.5.1-3
ii  libqt5svg5  5.5.1-2
ii  libqt5widgets5  5.5.1+dfsg-16
ii  libqt5xml5  5.5.1+dfsg-16
ii  libqt5xmlpatterns5  5.5.1-2
ii  libstdc++6  5.3.1-13

Versions of packages gcompris-qt recommends:
ii  libqt5multimedia5-plugins  5.5.1-4

gcompris-qt suggests no packages.

-- no debconf information

Bug#820439: imview: diff for NMU version 1.1.9c-12.1

[Anton Gladky]

Hi Tobias,

thank you for the patch!

Please cancel NMU-upload, because I integrated your patch
into the version 1.1.9c-13 and uploaded it.

Best regards


Anton

2016-04-08 16:24 GMT+02:00 Tobias Frost :

> Control: tags 820439 + patch
> Control: tags 820439 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for imview (versioned as 1.1.9c-12.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
> diff -Nru imview-1.1.9c/debian/changelog imview-1.1.9c/debian/changelog
> --- imview-1.1.9c/debian/changelog  2013-05-07 21:00:45.0 +0200
> +++ imview-1.1.9c/debian/changelog  2016-04-08 16:23:52.0 +0200
> @@ -1,3 +1,10 @@
> +imview (1.1.9c-12.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix for libpng1.6 (Closes: #820439)
> +
> + -- Tobias Frost   Fri, 08 Apr 2016 16:23:52 +0200
> +
>  imview (1.1.9c-12) unstable; urgency=low
>
>[ Sebastian Ramacher ]
> diff -Nru imview-1.1.9c/debian/patches/08_fix_libpng16.patch
> imview-1.1.9c/debian/patches/08_fix_libpng16.patch
> --- imview-1.1.9c/debian/patches/08_fix_libpng16.patch  1970-01-01
> 01:00:00.0 +0100
> +++ imview-1.1.9c/debian/patches/08_fix_libpng16.patch  2016-04-08
> 16:23:37.0 +0200
> @@ -0,0 +1,80 @@
> +Description: Patch for libpng1.6
> + libpng1.6 removed direct access of its member functions.
> +Author: Tobias Frost 
> +Bug-Debian: https://bugs.debian.org/820439
> +Forwarded: no
> +Last-Update: 2016-04-08
> +---
> +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
> +--- a/io/readpng.cxx
>  b/io/readpng.cxx
> +@@ -96,7 +96,7 @@
> + pp   = png_create_read_struct(PNG_LIBPNG_VER_STRING, NULL, NULL,
> NULL);
> + info = png_create_info_struct(pp);
> +
> +-if (setjmp(pp->jmpbuf))
> ++if (setjmp(png_jmpbuf(pp)))
> + {
> + errprintf("PNG file \"%s\" contains errors!\n", pngfilename);
> + return 103;
> +@@ -108,28 +108,40 @@
> + // Get the image dimensions and convert to grayscale or RGB...
> + png_read_info(pp, info);
> +
> +-if (info->color_type == PNG_COLOR_TYPE_PALETTE)
> ++png_uint_32 width;
> ++png_uint_32 height;
> ++int bit_depth;
> ++int color_type;
> ++int interlace_type;
> ++int compression_type;
> ++int filter_method;
> ++
> ++png_get_IHDR(pp, info, , ,
> ++   _depth, _type, _type,
> ++   _type, _method);
> ++
> ++if (color_type == PNG_COLOR_TYPE_PALETTE)
> + png_set_expand(pp);
> +
> +-if (info->color_type & PNG_COLOR_MASK_COLOR)
> ++if (color_type & PNG_COLOR_MASK_COLOR)
> + channels = 3;
> + else
> + channels = 1;
> +
> +-if ((info->color_type & PNG_COLOR_MASK_ALPHA) || info->num_trans)
> ++if ((color_type & PNG_COLOR_MASK_ALPHA) || info->num_trans)
> + channels ++;
> +
> +-w = (int)(info->width);
> +-h = (int)(info->height);
> ++w = (int)(width);
> ++h = (int)(height);
> + d = channels;
> +
> +-if (info->bit_depth < 8)
> ++if (bit_depth < 8)
> + {
> + png_set_packing(pp);
> + png_set_expand(pp);
> + }
> + // we ought to read the 16-bit data correctly, since we can !
> +-else if (info->bit_depth == 16)
> ++else if (bit_depth == 16)
> + png_set_strip_16(pp);
> +
> + #  if defined(HAVE_PNG_GET_VALID) && defined(HAVE_PNG_SET_TRNS_TO_ALPHA)
> +--- a/io/readpng.cxx
>  b/io/readpng.cxx
> +@@ -128,7 +128,9 @@
> + else
> + channels = 1;
> +
> +-if ((color_type & PNG_COLOR_MASK_ALPHA) || info->num_trans)
> ++int num_trans;
> ++png_get_tRNS(pp, info, NULL, _trans, NULL);
> ++if ((color_type & PNG_COLOR_MASK_ALPHA) || num_trans)
> + channels ++;
> +
> + w = (int)(width);
> diff -Nru imview-1.1.9c/debian/patches/series
> imview-1.1.9c/debian/patches/series
> --- imview-1.1.9c/debian/patches/series 2013-05-07 20:20:40.0 +0200
> +++ imview-1.1.9c/debian/patches/series 2016-04-08 15:45:09.0 +0200
> @@ -5,3 +5,4 @@
>  05_fix_dangerous_use_of_strncpy.patch
>  06_fix_format_not_a_string.patch
>  07_fix_kfreebsd_FTBFS.patch
> +08_fix_libpng16.patch
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
>

Bug#737725: libgimp2.0: Please build multiarch library

[Tobias Frost]

On Wed, 5 Feb 2014 08:23:24 -0500 Ari Pollak  wrote:
> severity 737725 wishlist
> thanks
> 
> I'm pretty sure gimp itself would also need to provide a 32-bit
version to
> be able to load the 32-bit plugins. That seems like overkill given
that
> there are no binary-only gimp plugins to my knowledge. The
> gimp-plugin-registry package already provides a large number of these
> plugins.
> Also, please take a look at the bug severity guidelines for future
> reference.

Actually, important'd be right, as MultiArch is a release goal since
wheezy. (https://release.debian.org/wheezy/goals.txt)

-- 
tobi

Bug#820235: RM: softhsm -- ROM; superseded by softhsm2

[Scott Kitterman]

Please remove the moreinfo tag once the two blocking bugs have been resolved.

Bug#820329: playonlinux: FTBFS in sid: dh_install: Cannot find (any matches for) "plugins/TransgamingCedega*" and "plugins/Wine*"

[Denis Briand]

tags 820329 patch
thanks

Hello,
Upstream did removed these two plugin and add another one.
You should try this trivial patch.

Best regards

Denis Briand  
--- playonlinux.install.old	2016-04-09 06:22:29.913632999 +0200
+++ playonlinux.install	2016-04-09 06:35:42.134081741 +0200
@@ -8,7 +8,7 @@
 python/*.py usr/share/playonlinux/python/
 python/lib/*.py usr/share/playonlinux/python/lib/
 resources/* usr/share/playonlinux/resources/
-plugins/plugins.lst plugins/polvault* plugins/ScreenCap* plugins/TransgamingCedega* plugins/Wine* usr/share/playonlinux/plugins/
+plugins/plugins.lst plugins/polvault* plugins/ScreenCap* plugins/Capture* usr/share/playonlinux/plugins/
 playonlinux usr/share/playonlinux/
 playonlinux-bash usr/share/playonlinux/
 playonlinux-pkg usr/share/playonlinux/

Bug#818925: [pkg-wine-party] Bug#818925: Packaging the TrueType fonts Re: Bug#818925: [wine-development] Glitches in Windows window systemmenu (minimize, windowed/fullscreen, close)

[Michael Gilbert]

On Fri, Apr 8, 2016 at 11:34 AM, Jens Reyer wrote:
> But I'm not really happy with them, although I see them as the best
> solution for now. Therefore this painfully long mail, sorry.

Thank you for digging into the details here.

> Improving new situation:
> 
> If we keep my changes we should try to get some of the forked changes
> applied upstream, or at least in Debian. At least "width" and "trailing
> spaces" sound like valid candidates. Not sure what the "timestamps" are
> relevant for at all, and absolutely no clue about the "selected state".
> I'd ask the involved parties about that soon.

There are newer fontforge updates that aren't yet packaged.  I didn't
look, but maybe some of the wine patches might already be applied?
https://github.com/fontforge/fontforge/releases

> We might also mention in debian/README.source that upstream uses a
> forked fontforge - but per se this doesn't solve the need to rebuild the
> Truetype fonts with a tool that is present in Debian.

A bug report tracking the problem would be better.

> Packaging the forked fontforge additionally in Debian doesn't sound right.

I agree.

> Alternatives:
> =
> Not packaging the TrueType fonts imo is not a way to go. I consider the
> known issues quite important, that's also why I'm a bit reluctant to
> push current versions to backports.

I agree.

> But distributing them in main violates the DFSG [DFSG-discuss] (although
> it seems this was the case for the last decade, until they were dropped
> recently).
> Instead of rebuilding the fonts in maintainer mode (and ignoring the
> icons issue, see below), we could introduce a fonts-wine-contrib package
> with the TrueType fonts, patch attached (todo: breaks/replaces older
> versions), it replaces my following commits:
> - Add TrueType fonts to clean to regenerate them.
> - Don't error out on build warnings.
> - Build wine in maintainer mode.
> - Install wine's TrueType fonts.

Your current approach is better.

> If we could define a set of existing fonts in Debian that fulfill Wine's
> requirements that would obsolete the font topic (but not the icons). But
> I doubt there is one. Anyone?

It's worth trying, but might not be totally reliable, and probably the
best long term solution if it can work.

> Further questions:
> ==
> I haven't found a way yet to rebuild the icons (I'm not sure if some of
> them are "source"), not even in maintainer mode. Adding all *.ico (and
> *.bmp) files to clean didn't work.
> But the icons end up in central apps like e.g. winecfg. So I assume this
> is an issue which should be solved, and the solution probably includes
> switching to maintainer mode.

I'll try to look at that.  Switching to maintainer mode is a very useful change.

> Is there anything else not rebuilt from source left in the current
> packaging? Mike already did an awesome job here lately.

Unicode mappings.

Best wishes,
Mike

Bug#819084: rexical ships without a gemspec file

[Balasankar C]

On Wed, 23 Mar 2016 16:05:26 +0100 Matthias Klose  wrote:
> rexical ships without a gemspec file, making it useless to fulfil
dependencies.

Rexical is intended to be used as a Ruby application. The upstream
github repository[1] describes its usage as a binary only, and not as a
library. If you could provide a usecase where rexical is used as a
library, I can try to create a gemspec file for it.

[1] https://github.com/tenderlove/rexical

Balasankar C

Bug#816722: zoom-player: interraction with xscreensaver

[Jamie Zawinski]

I still think the root of the problem here is that the "zoom" xscreensaver hack 
is marked as enabled in the .ad file, but it is not actually installed. So the 
.ad file is wrong. Correcting it would fix this. I suppose it would be possible 
to do that in a post-install script on the xscreensaver sub-packages.

It would also work to make every entry in the .ad file be an absolute path 
instead of relative.

But I don't like the idea of forcing entries in the .ad file that are not 
absolute paths to only run from a hardcoded directory.

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#820495: howdoi: typo in package description

[Daniel Shahaf]

Package: howdoi
Version: 1.1.7-1
Severity: minor
Tags: patch

Dear Maintainer,

There is a typo in the package description:

diff --git a/debian/control b/debian/control
index 59ddfb5..d0c7107 100644
--- a/debian/control
+++ b/debian/control
@@ -22,5 +22,5 @@ Depends: ${python3:Depends},
  python3-requests
 Description: command line tool for instant coding answers
  howdoi will search Google for StackOverflow answers and output you the 
most
- voted one. Multiple output options are supported, such as providing just 
an
- link to the answer, providing multiple answers for the same questions, 
etc.
+ voted one. Multiple output options are supported, such as providing just a
+ link to the answer, providing multiple answers for the same question, etc.

Here it is again in wdiff format:

voted one. Multiple output options are supported, such as providing just 
[-an-]{+a+}
link to the answer, providing multiple answers for the same 
[-questions,-]{+question,+} etc.

Thanks for packaging howdoi,

Daniel
(patch against 1.1.7-1 since I couldn't find a packaging VCS)

Bug#647813: Update about bug #647813 for geneweb

[Guillaume Brochu]

Hi,

Using  geneweb 6.08+git20160228+dfsg-2, I can see the "history of 
Updates" and the "database forum" links on the homepage of both default 
and templ502 templates, and these features are working properly.


However, I had to set these two parameters in my .gwf file:
disable_forum=no
history=yes
in order to use the history and the forum.

I think this bug could be closed.

Bug#820494: origtargz: leaves "upstream" files in "master" after invocation

[Dmitry Smirnov]

Package: devscripts
Version: 2.16.2
Severity: normal

When "pristine-tar" and "upstream" branches are present, "origtargz" leaves 
upstream files in "master" after tarball generation.

This is a quite annoying behaviour for repositories where "master" tracks 
only Debian packaging without upstream files (e.g. gbp.conf/import-orig/
merge=False).

For example if I run "origtargz" in "cadvisor" repository I have to remove 
files from "upstream" branch that "origtargz" left in "master"...

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


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

Bug#820493: aptitude: does not install package from Build-Depends

[Dmitry Smirnov]

Package: aptitude
Version: 0.7.8-1
Severity: important
Control: affects -1 pbuilder civicrm

Package "civicrm" FTBFS in "pbuilder" because Aptitude do not install
"php-gettext" package listed in civicrm's Build-Depends.

I can only build CiviCRM in pbuilder if I add the following to ~/.pbuilderrc:


PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-classic"

Please investigate.

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

Good luck happens when preparedness meets opportunity.


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

Bug#774409: audacious-plugins: improve audacious Winamp classic interface default setting and songs tagged with non-ASCII characters

[Hideki Yamane]

control: forwarded -1 http://redmine.audacious-media-player.org/issues/634

Update it for 3.7.2 and forwarded to upstream

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#820492: pbuilder: satisfydepends-classic can't install versioned build dependency from experimental

[Dmitry Smirnov]

Package: pbuilder
Version: 0.223
Severity: normal

Using pbuilder with 

  PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-classic"

in "~/.pbuilderrc" I'm trying to build "php7cc" package that Build-Depends on

  php-pimple (>= 3.0.2~)

At the moment "unstable" have php-pimple_1.1.1-1 while "experimental"
have php-pimple_3.0.2-1.

Pbuilder however installs php-pimple_1.1.1-1 from "unstable" when both
"unstable" and "experimental" suites are enabled in "/etc/apt/sources.list".

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

On one level, wisdom is nothing more profound than an ability to follow
one’s own advice.
-- Sam Harris, Waking Up: A Guide to Spirituality Without Religion


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

Bug#820491: argon2: missing man page for argon2

[Daniel Kahn Gillmor]

Package: argon2
Version: 0~20160406-1
Severity: normal
Tags: upstream patch

argon2 is missing a manpage, and it doesn't respond well to the usual
-h or --help (it treats those as an attempted salt).

The attached patch (which i'll push to collab-maint shortly) fixes the
problem.  I'd be happy if they want to adopt this upstream, but i am
not in touch with upstream.  Feel free to forward it to them!

Thanks for packaging argon2 for debian!

   --dkg

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
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)

Versions of packages argon2 depends on:
ii  libc6  2.22-5

argon2 recommends no packages.

argon2 suggests no packages.

-- debconf-show failed
diff --git a/debian/argon2.1 b/debian/argon2.1
new file mode 100644
index 000..f8a811f
--- /dev/null
+++ b/debian/argon2.1
@@ -0,0 +1,47 @@
+.TH ARGON2 "1" "April 2016" "argon2 " "User Commands"
+
+.SH NAME
+argon2 \- generate argon2 hashes
+
+.SH SYNOPSIS
+.B argon2 salt
+.RB [ OPTIONS ]
+
+.SH DESCRIPTION
+Generate Argon2 hashes from the command line.
+
+The supplied salt (the first argument to the command) must be at least
+8 octets in length, and the password is supplied on standard input.
+
+By default, this uses Argon2i, the variant where memory access is
+indepedent of secret data.  This is the correct variant to use for
+password hashing.
+
+.SH OPTIONS
+.TP
+.B \-d
+Use Argon2d instead of Argon2i (Argon2i is the default)
+.TP
+.BI \-t " N"
+Sets the number of iterations to N (default = 3)
+.TP
+.BI \-m " N"
+Sets the memory usage of 2^N KiB (default = 12)
+.TP
+.BI \-p " N"
+Sets parallelism to N threads (default = 1)
+.TP
+.BI \-h " N"
+Sets hash output length to N bytes (default = 32)
+.TP
+.B \-e
+Output only encoded hash
+.TP
+.B \-r
+Output only the raw bytes of the hash
+
+.SH COPYRIGHT
+This manpage was written by \fBDaniel Kahn Gillmor\fR for the Debian
+distribution (but may be used by others).  It is released, like the
+rest of this Argon2 implementation, under the terms of Creative
+Commons 0 (CC0)
diff --git a/debian/argon2.manpages b/debian/argon2.manpages
new file mode 100644
index 000..39ab410
--- /dev/null
+++ b/debian/argon2.manpages
@@ -0,0 +1 @@
+debian/argon2.1
diff --git a/debian/copyright b/debian/copyright
index dba1b93..3ac2cb3 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -22,6 +22,10 @@ Files: debian/*
 Copyright: 2016, Luca Bruno 
 License: CC0
 
+Files: debian/argon2.1
+Copyright: 2016, Daniel Kahn Gillmor 
+License: CC0
+
 License: CC0
  /Statement of Purpose/
  .
diff --git a/debian/argon2.1 b/debian/argon2.1
new file mode 100644
index 000..f8a811f
--- /dev/null
+++ b/debian/argon2.1
@@ -0,0 +1,47 @@
+.TH ARGON2 "1" "April 2016" "argon2 " "User Commands"
+
+.SH NAME
+argon2 \- generate argon2 hashes
+
+.SH SYNOPSIS
+.B argon2 salt
+.RB [ OPTIONS ]
+
+.SH DESCRIPTION
+Generate Argon2 hashes from the command line.
+
+The supplied salt (the first argument to the command) must be at least
+8 octets in length, and the password is supplied on standard input.
+
+By default, this uses Argon2i, the variant where memory access is
+indepedent of secret data.  This is the correct variant to use for
+password hashing.
+
+.SH OPTIONS
+.TP
+.B \-d
+Use Argon2d instead of Argon2i (Argon2i is the default)
+.TP
+.BI \-t " N"
+Sets the number of iterations to N (default = 3)
+.TP
+.BI \-m " N"
+Sets the memory usage of 2^N KiB (default = 12)
+.TP
+.BI \-p " N"
+Sets parallelism to N threads (default = 1)
+.TP
+.BI \-h " N"
+Sets hash output length to N bytes (default = 32)
+.TP
+.B \-e
+Output only encoded hash
+.TP
+.B \-r
+Output only the raw bytes of the hash
+
+.SH COPYRIGHT
+This manpage was written by \fBDaniel Kahn Gillmor\fR for the Debian
+distribution (but may be used by others).  It is released, like the
+rest of this Argon2 implementation, under the terms of Creative
+Commons 0 (CC0)
diff --git a/debian/argon2.manpages b/debian/argon2.manpages
new file mode 100644
index 000..39ab410
--- /dev/null
+++ b/debian/argon2.manpages
@@ -0,0 +1 @@
+debian/argon2.1
diff --git a/debian/copyright b/debian/copyright
index dba1b93..3ac2cb3 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -22,6 +22,10 @@ Files: debian/*
 Copyright: 2016, Luca Bruno 
 License: CC0
 
+Files: debian/argon2.1
+Copyright: 2016, Daniel Kahn Gillmor 
+License: CC0
+
 License: CC0
  /Statement of Purpose/
  .

Bug#817094: Acknowledgement (mercurial-keyring: fails to import Gnome module)

[Fedor Uvarov]

Dear Maintainer,

Sorry to bother you, but a month has passed, and you haven't responded
in any way. Do you just have no time for it now or have you given up
maintaining this package altogether?

Fedor

Bug#820490: PPA for streflop

[Kip Warner]

I should have also added that I have prepared a PPA for my attempt at
Debianization:

https://launchpad.net/~kip/+archive/ubuntu/streflop

Note that it fails to build on some versions of GCC due to a bug that
has since been patched upstream.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715

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

Bug#819236: xsane: Preview windows (Vorschaufenster) is empty. No controls are shown.

[Jörg Frings-Fürst]

Hello Peter,

thank you for spending your time helping to make Debian better with
this bug report.

Please can you send me a screen-shot with the preview window?

Many thanks.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54538 Bausendorf

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#820490: ITP: streflop -- STandalone REproducible FLOating-Point library

[Kip Warner]

Package: wnpp
Severity: wishlist
Owner: Kip Warner 

* Package name: streflop
  Version : 0.3
  Upstream Author : Nicolas Brodu 
* URL : http://nicolas.brodu.net/en/programmation/streflop/
* License : LGPL-2.1
  Programming Lang: C++
  Description : ITP: streflop -- STandalone REproducible FLOating-Point
library

A computer has a finite memory, and cannot represent an infinity of numbers. If
you add 0.1 + 0.1 in C++ you will probably not get the mathematical result 0.2.
The problem is that what you get depends on many parameters. On one
configuration, you may get something like 0.1995, and on another 0.1999. For
the vast majority of programs, these small differences do not matter. But if
you want to reproduce the same results twice, for a scientific experiment for
example, on different machines or even on the same machine but with different
options, then you have to be more careful. Much more careful, because these
small differences can occasionally accumulate quite fast.

The STandalone REproducible FLOating-Point library allows you to control how
the computations are done in C++. The goal is to make your programs give
reliable and reproducible results.

Bug#782605: settings should migrate to new gitdir

[David Bremner]

Ritesh Raj Sarraf  writes:

> For whatever be the reason, gitolite3 expects its $HOME path to be executable.
> Whereas typical non-root file systems on Linux are treated as data partitions
> and their mount options usually are set to not allow execution, suid and other
> stuff.

Typical or no, I've never used such a setup. I understand there might be
some argument for supporting it, similar to wanting to support read-only
/usr.

I expect the need to run executables is related to hooks. Gitolite needs
the git update hook to do fine grain authorization checks [1], and the
post-update hook in the gitolite-admin repo.

The main copies of these hooks live in $HOME/.gitolite

This could be symlinked to another directory, but I'm not sure where
would be a good idea, since it is specific to that particular gitolite
user. So it seems simplest just to put the gitolite user home directory
somewhere mounted without noexec.

It might make sense to document this requirement in README.Debian.

[1]: http://gitolite.com/gitolite/gitolite.html#how-does-it-work for the
 short version
 http://gitolite.com/gitolite/how.html for a longer slideshow
 version.

Bug#820489: codeblocks: Codeblocks crashes very frequently

[Alejandro Carrazzoni]

Package: codeblocks
Version: 13.12+dfsg-4
Severity: grave
Justification: renders package unusable

Codeblocks very frequently crashes suddenly with no error message when editing
code, particularly when the code involves templates. I'm attaching the .xml
crash log of the last crash.



-- 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.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_AR.utf8, LC_CTYPE=es_AR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages codeblocks depends on:
ii  codeblocks-common13.12+dfsg-4
ii  libatk1.0-0  2.18.0-1
ii  libc62.22-5
ii  libcairo21.14.6-1
ii  libcodeblocks0   13.12+dfsg-4
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3
ii  libgcc1  1:5.3.1-13
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libglib2.0-0 2.48.0-1
ii  libgtk2.0-0  2.24.30-1.1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  libstdc++6   5.3.1-13
ii  libwxbase3.0-0v5 3.0.2+dfsg-1.3
ii  libwxgtk3.0-0v5  3.0.2+dfsg-1.3

Versions of packages codeblocks recommends:
ii  g++4:5.3.1-1
ii  gcc4:5.3.1-1
ii  gdb7.10-1+b1
ii  xterm  324-1

Versions of packages codeblocks suggests:
pn  codeblocks-contrib  
pn  libwxgtk3.0-dev 

-- no debconf information


codeblocks.xml
Description: XML document

Bug#820151: kfreebsd-10: non-DFSG mode (for ubuntuBSD)

[Steven Chamberlain]

Hi,

Guillem Jover wrote:
> On Tue, 2016-04-05 at 23:17:08 +0200, Jon Boden wrote:
> > This patch has no effect on Debian but it enables "non-DFSG mode" when
> > compiling kfreebsd-10 on ubuntuBSD. Please could you apply it to make
> > it easier for us to resync with kfreebsd-10?
> 
> Is this acceptable for the Ubuntu archive? In any case that's
> something for the current kFreeBSD manintainers to agree with.

I didn't like the vendor detection part of Jon's patch anyway.  I still
would like to offer a solution though.

If simply moving from Debian to *buntu, adds non-free things to the
source package or affects the build, I'd like that to be more obvious.

And although Jon provided a way to override this in debian/rules, it is
still necessary to get-orig-source again for a change to take effect.
That makes me think it is not really a build-time setting but more of a
get-orig-source setting, which is persistent after that.


My first thought is to use the Version field;  that already determines
what SVN revision is checked out from which branch.  If it contained
something like "+nonfree", get-orig-source could retain the non-free
stuff, and build targets could alter their behaviour.  The non-free
source package would be easily identifiable as such, and as being
different from Debian's own.

Can anyone tell me if that's a bad idea for any reason?

It's intended the "+nonfree" would be in the upstream part of the
version number, so that the .orig.tar.xz gets a new name, e.g.
10.3~svn296998-2 -> 10.3~svn296998+nonfree-2
though I'd happily grep the entire version string for it, and still try
to do the right thing in case someone mistakenly did:
10.3~svn296998-2+nonfree

I'm considering to also add +nonfree to the abiname when building
non-free source.  Side effects are that this appears in `uname -a`
output and the names of binary packages;  it makes them
co-installable with the original DFSG kernels, and GRUB2 would give them
separate menu entries.


Having different package versions in Debian / *buntu is quite normal and
I think it would fit into Jon's workflow.  He needs to get-orig-source
anyway, adding a "+nonfree" version suffix is easy to do, and nothing
else should need patching to get the result he wants.

And, this is useful to Debian users, as an easier way to locally make a
non-free kfreebsd-10 package, for those who want to do that.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#820481: Pending fixes for bugs in the libimage-exiftool-perl package

[pkg-perl-maintainers]

tag 820481 + pending
thanks

Some bugs in the libimage-exiftool-perl package are closed in
revision 296c7a6665f70ed488c7a6b52d1c16a24852d271 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libimage-exiftool-perl.git/commit/?id=296c7a6

Commit message:

New upstream release. Closes: #820481

Bug#794110: More info needed

[Thomas Preud'homme]

Le mercredi 16 mars 2016, 10:16:18 Lisandro Damián Nicanor Pérez Meyer a écrit 
:
> tag 794110 moreinfo
> thanks
> 
> Hi everyone! With my Qt maintainer hat on, I would like you to give me some
> info.
> 
> First: We have only one backtrace coming from the original submitter. Can
> the rest of you check if when a crash happens the current thread's (the
> crashing one) backtrace says something like:

Hi Lisandro,

I hope you are doing well.

Sorry for the late answer, I was in the middle of a relocation and didn't 
touch my computer much. I haven't had any crash since I have so the bug seems 
to be solved on my side. I'll update the bug report if I ever get a new crash 
in the following (14) days but I don't expect to.

Best regards,

Thomas

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

Bug#820487: fonts-font-awesome: Some icons don't render properly in gtk applications

[James Murphy]

Package: fonts-font-awesome
Version: 4.5.0~dfsg-1
Severity: normal

Dear Maintainer,

On March 30 2016 after an upgrade the FontAwesome symbols U+f176 
(fa-long-arrow-up) and U+f175 (fa-long-arrow-down) stopped rendering properly 
in some applications.

I believe it is gtk related because terminal based applications still
render the arrows fine. Opening a file with both arrows in vim works as
expected, but opening the same file in gvim makes the arrows fail to
draw properly. Similarly, asking i3bar to draw the symbols also renders
improperly. However, other symbols still render fine both in and out of
gtk applications.

I mailed this to the debian-user mailing list with no response, and I'm
not sure who else to report it to. I should note that the upgrade in
question did not include an upgrade to the fonts-font-awesome package.
The upgrade did include libgtk2.0-bin, libgtk2.0-0, and libgtk2.0-common.

James


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

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
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)

-- no debconf information

Bug#813423: Seems fixed

[Alex Henry]

Just wanted to inform that this seems to be fixed since I updated to
2.1.2.1 (on testing) today. I'll be back with more information in case I
have further trouble in this regard.

Thank you for the update, maintainers, this was very annoying!

Bug#810931: icedove: Adding custom header breaks the other headers (sender, subject, date become blank)

[Carsten Schoenert]

Hello Laura,

On Wed, Jan 13, 2016 at 10:58:53PM +0100, Laura Arjona Reina wrote:
> What is received (and appears in the Sender's "Sent" folder) is a mail with
> blank date and sender and subject, and no custom header, or the message "BAD
> HEADERS" when all the headers are examined. The body of the email is OK.
> 
>* What outcome did you expect instead?
> 
> The recipient should get an email with proper date, sender, subject, and if 
> all
> the headers examined, the header "Review: em...@example.com.
> 
> I've tested this in two Debian stable box, and could reproduce the problem.
> I've asked some friends to reproduce the problem with these results:
> 
> * Ubuntu + Thunderbird 31.3.0 -> could not reproduce
> * Windows 7 + Thunderbird 38.5.1 -> could not reproduce
> * Debian sid + Icedove 38.5.0-1+b1 -> could reproduce the problem
> * Debian sid + Icedove from experimental 42.0~b2-1 -> could reproduce the
> problem

I can't reproduce this issue on 38.6.0 in testing, works after
restarting Icedove without further issues. Is this still present on your
setup?

I just created a own extra header X-Special-Xy and send this to myself:

Return-Path: 
Received: from fwd41.aul.t-online.de ([172.20.27.139])
by ehead709.aul.t-online.de (Dovecot) with LMTP id 
uQjgFgc8CFdjpAAA/bs/RQ;
Sat, 09 Apr 2016 01:17:27 +0200
Received: from [192.168.1.84] 
(JlvkX4ZLrhFEdLfOw3j4op0Hs56-J9+JDaRzL1uEigTSVy6KLVVeGcDfMZw-1NSQp8@[79.228.211.104])
 by fwd41.t-online.de
with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted)
esmtp id 1aofeX-1633Nw0; Sat, 9 Apr 2016 01:17:25 +0200
To: c.schoen...@t-online.de
X-Special-Xy: foobar
From: Carsten Schoenert 
Subject: Foobar
Message-ID: <57083c02.5080...@t-online.de>
Date: Sat, 9 Apr 2016 01:17:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Icedove/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-ID: JlvkX4ZLrhFEdLfOw3j4op0Hs56-J9+JDaRzL1uEigTSVy6KLVVeGcDfMZw-1NSQp8
X-TOI-SPAM: u;0;2016-04-08T23:17:27Z
X-TOI-VIRUSSCAN: clean
X-TOI-EXPURGATEID: 150726::1460157445-E9A3-BDCBD79D/0-0/0-0
X-TOI-MSGID: ab691408-3280-416a-abee-b800e11a5128
X-Seen: false
X-ENVELOPE-TO: 

There is also a subsection on the Debian wiki for manually adding
various extra mail headers.

https://wiki.debian.org/Icedove#Create_Own_Mail_Headers

Is this issue with those adding still exists?

Regards
Carsten

Bug#820486: I follow aptitude's advice and end up with a broken (B) package

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.7.8-1

I follow aptitude's advice and end up with a broken (B) package:
iBA libgdal20  - 
Geospatial Data Abstraction Library
And why does it say 0 broken?
"Current status: 0 (+0) broken, 8 (+0) upgradable, 51509 (+0) new."

# aptitude search ~U
iF  debian-reference-en- Debian 
system administration guide, English original
i   gdal-bin   - 
Geospatial Data Abstraction Library - Utility programs
i A libclutter-gtk-1.0-0   - Open 
GL based interactive canvas library GTK+ widget
i A libgdal20  - 
Geospatial Data Abstraction Library
iFA libgtk-3-0 - GTK+ 
graphical user interface library
iFA libgtk-3-bin   - 
programs for the GTK+ graphical user interface library
iFA libgtk-3-common- common 
files for the GTK+ graphical user interface library
i   python-gdal- Python 
bindings to the Geospatial Data Abstraction Library
# aptitude install ~U~ngdal
The following NEW packages will be installed:
  libcrypto++6{a} (D: libgdal20) (gdal-bin D: libgdal20 D: libcrypto++6, 
python-gdal D: libgdal20 D: libcrypto++6)
  libqhull7{a} (D: libgdal20) (gdal-bin D: libgdal20 D: libqhull7, python-gdal 
D: libgdal20 D: libqhull7)
The following packages will be upgraded:
  gdal-bin  libgdal20 (gdal-bin D: libgdal20, python-gdal D: libgdal20)  
python-gdal
The following packages will NOT be UPGRADED:
  debian-reference-en  libclutter-gtk-1.0-0{a}  libgtk-3-0{a}  libgtk-3-bin{a}  
libgtk-3-common{a} (R: libgtk-3-0)
3 packages upgraded, 2 newly installed, 0 to remove and 5 not upgraded.
Need to get 7,495 kB of archives. After unpacking 6,698 kB will be used.
The following packages have unmet dependencies:
 libqgis-analysis2.14.1 : Depends: gdal-abi-2-0-2 which is a virtual package, 
provided by:
   - libgdal20 (2.0.2+dfsg-4), but 
2.1.0~beta1+dfsg-1~exp2 is to be installed
   - libgdal20 (2.0.2+dfsg-5+b1), but 
2.1.0~beta1+dfsg-1~exp2 is to be installed

 qgis : Depends: gdal-abi-2-0-2 which is a virtual package, provided by:
 - libgdal20 (2.0.2+dfsg-4), but 2.1.0~beta1+dfsg-1~exp2 is to 
be installed
 - libgdal20 (2.0.2+dfsg-5+b1), but 2.1.0~beta1+dfsg-1~exp2 is 
to be installed

The following actions will resolve these dependencies: [[I pick this 6th
or 7th choice]]

 Upgrade the following packages:
1) gdal-bin [2.0.2+dfsg-4 (now) -> 2.0.2+dfsg-5+b1 (unstable)]
2) libgdal20 [2.0.2+dfsg-4 (now) -> 2.0.2+dfsg-5+b1 (unstable)]
3) python-gdal [2.0.2+dfsg-4 (now) -> 2.0.2+dfsg-5+b1 (unstable)]

Accept this solution? [Y/n/q/?]
The following packages will be upgraded:
  gdal-bin  libgdal20  python-gdal
The following packages will NOT be UPGRADED:
  debian-reference-en  libclutter-gtk-1.0-0{a}  libgtk-3-0{a}  libgtk-3-bin{a}  
libgtk-3-common{a} (R: libgtk-3-0)
3 packages upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
Need to get 5,704 kB of archives. After unpacking 21.5 kB will be freed.
Do you want to continue? [Y/n/?]
Get: 1 http://free.nchc.org.tw/debian unstable/main i386 libgdal20 i386 
2.0.2+dfsg-5+b1 [4,672 kB]
Get: 2 http://free.nchc.org.tw/debian unstable/main i386 gdal-bin i386 
2.0.2+dfsg-5+b1 [416 kB]
Get: 3 http://free.nchc.org.tw/debian unstable/main i386 python-gdal i386 
2.0.2+dfsg-5+b1 [616 kB]
Fetched 5,704 kB in 32s (175 kB/s)
(Reading database ... 182112 files and directories currently installed.)
Preparing to unpack .../libgdal20_2.0.2+dfsg-5+b1_i386.deb ...
Unpacking libgdal20 (2.0.2+dfsg-5+b1) over (2.0.2+dfsg-4) ...
Preparing to unpack .../gdal-bin_2.0.2+dfsg-5+b1_i386.deb ...
Unpacking gdal-bin (2.0.2+dfsg-5+b1) over (2.0.2+dfsg-4) ...
Preparing to unpack .../python-gdal_2.0.2+dfsg-5+b1_i386.deb ...
Unpacking python-gdal (2.0.2+dfsg-5+b1) over (2.0.2+dfsg-4) ...
Processing triggers for libc-bin (2.23-0experimental1) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up libgdal20 (2.0.2+dfsg-5+b1) ...
Setting up gdal-bin (2.0.2+dfsg-5+b1) ...
Setting up python-gdal (2.0.2+dfsg-5+b1) ...
Processing triggers for libc-bin (2.23-0experimental1) ...

Current status: 0 (+0) broken, 8 (+0) upgradable, 51509 (+0) new.
# aptitude search ~U
iF  debian-reference-en- Debian 
system administration guide, English original
iu  gdal-bin   - 
Geospatial Data Abstraction Library - Utility programs
i A libclutter-gtk-1.0-0   - Open 
GL based interactive canvas 

Bug#820151: kfreebsd-10: non-DFSG mode (for ubuntuBSD)

[Guillem Jover]

Hi!

On Tue, 2016-04-05 at 23:17:08 +0200, Jon Boden wrote:
> Package: kfreebsd-10
> Version: 10.1~svn274115-4+kbsd8u3
> Severity: wishlist
> Tags: patch

> This patch has no effect on Debian but it enables "non-DFSG mode" when
> compiling kfreebsd-10 on ubuntuBSD. Please could you apply it to make
> it easier for us to resync with kfreebsd-10?

Is this acceptable for the Ubuntu archive? In any case that's
something for the current kFreeBSD manintainers to agree with.

> Index: debian/control.in
> ===
> --- debian/control.in (revision 5986)
> +++ debian/control.in (working copy)
> @@ -23,6 +23,7 @@
>   pkg-config,
>   libsbuf-dev (>= 9.0+ds1-2),
>   kernel-wedge (>= 2.79) [kfreebsd-any],
> + lsb-release,

You don't need this, see below…

>  Standards-Version: 3.9.2
>  
>  Package: kfreebsd-source-@version@
> Index: debian/rules
> ===
> --- debian/rules  (revision 5986)
> +++ debian/rules  (working copy)
> @@ -23,7 +23,13 @@
>  configfile   := DEBCUSTOM
>  abiname  := 0
>  ld_target:= $(shell ld --help | sed -ne "s/[^ :]*: supported targets: 
> \([^ ]*\) .*/\1/p")
> +distributor  := $(shell lsb_release -is || echo Debian)

…you can use dpkg-vendor instead, which does not need any additional
build dependency.

Thanks,
Guillem

Bug#806068: linaro-image-tools: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 806068 + patch
thanks

> dh_install
> find debian/linaro-image-tools -type f |xargs sed -i 's|#!/usr/bin/env 
> python|#!/usr/bin/python|'
> find: `debian/linaro-image-tools': No such file or directory
> sed: no input files
> debian/rules:11: recipe for target 'override_dh_install' failed

Explanation: We are creating arch-independent packages, so
"debian/linaro-image-tools" does not exist because
"linaro-image-tools" is arch-dependent.

The trivial fix is to override dh_install only when creating
arch-dependent packages.

Patch attached.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -7,7 +7,8 @@ export PATH := $(PATH):/sbin
 
 %:
dh $@ --with python2
-override_dh_install:
+
+override_dh_install-arch:
dh_install
find debian/linaro-image-tools -type f |xargs sed -i 's|#!/usr/bin/env 
python|#!/usr/bin/python|'
 

Bug#809214: icedove: since 38.4.0-1~deb8u1, sending mail to o365 fails (authenticated SMTP, STARTTLS)

[Carsten Schoenert]

Hello Matteo,

is the report still actual.

On Mon, Dec 28, 2015 at 12:19:23PM +0100, MAtteo HCE Valsasna wrote:
>* What led up to the situation?
> icedove was configured to use two office 365 accounts using settings
> suggested by o365 the program was able to receive and send email
> normally on both accounts
> 
> account settings:
> server smtp.office365.com
> port 587
> auth method Normal password
> security STARTTLS

Try to avoid STARTTLS and setup a explicit security setting SSL/TLS with
port 993 (normaly 465 but MS uses port 993). This avoids man in the
middle attacks with disabled security at all.

> sending email with SMTP with both accounts fails with message "Sending
> of the message failed. The message could not be sent using Outgoing
> server (SMTP) smtp.office365.com for an unknown reason. Please verify
> that your Outgoing server (SMTP) settings are correct and try again."

Is this behavior still exists? If so please try to investigate what's
happen on the communication side, maybe there is something more visible.

https://wiki.debian.org/Icedove#Debugging_Icedove_Activity

Regards
Carsten

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[peter green]

On 08/04/16 20:55, Graham Inggs wrote:


Secondly, it should be possible to reproduce the fault by building in
an armhf schroot on abel.d.o, which has the same hardware as the
buildds.  A temporary solution would be to upload armhf binaries built
on asachi.d.o.
   
It would be useful if someone can reproduce the issue and get a 
dissasembly of the failure location.


My gut feeling is that llvm is trying to use neon without first checking 
it is supported. Afaict the marvell boards we are using for armhf 
buildds (and for the abel.d.o porterbox) don't have neon.



[1] 
https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8=unstable

   

Bug#820485: lynx: Cookie handling at odds with RFC 6265

[Andy Valencia]

Package: lynx
Version: 2.8.9dev1-2+deb8u1
Severity: normal

RFC 6265 cleared up some older ambiguities with respect to different
ports on the same web server host.  Specifically:

> cookies for a given host are shared across all the ports on that host, even
> though the usual "same-origin policy" used by web browsers isolates content
> retrieved via different ports.

and:

> Cookies do not provide isolation by port. If a cookie is readable by a
> service running on one port, the cookie is also readable by a service
running
> on another port of the same server.

Lynx should converge on this mandated behavior in its cookie treatment,
rather than enforcing distinct cookies for each port.  I often use
Lynx for quick-n-dirty application server invocations but I'm working
on an app which is decomposed into distinct processes and this non-
standard behavior makes Lynx unusable in this environment.

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lynx depends on:
ii  lynx-cur  2.8.9dev1-2+deb8u1

lynx recommends no packages.

lynx suggests no packages.

-- no debconf information

Bug#820479: patch

[Steve McIntyre]

Control: tag -1 +pending

Thanks. I've tweaked this slightly and pushed to git just now so
daily/weekly builds with DTRT. I'm due a debian-cd upload soon-ish
which will mark this bug as properly fixed.

debian-cd will attempt to pull in packages by name, but doesn't fail
in cases where packages are not found. So for now the easiest thing to
do for us is list both btrfs-tools and btrfs-progs so we'll work
either side of the transition.

On Fri, Apr 08, 2016 at 05:59:32PM -0400, Nicholas D Steeves wrote:
>Sorry, forgot to include this patch:
>
>diff -ur ./debian/changelog ../debian-cd/debian/changelog
>--- ./debian/changelog  2016-04-08 16:51:39.824068392 -0400
>+++ ../debian-cd/debian/changelog   2016-04-08 16:54:23.95689 -0400
>@@ -1,4 +1,4 @@
>-debian-cd (3.1.18) UNRELEASED; urgency=medium
>+debian-cd (3.1.18+nmu1) UNRELEASED; urgency=medium
>
>   [ Steve McIntyre ]
>   * Start stretch, simply copying jessie for now
>@@ -53,7 +53,10 @@
>   [ Ben Hutchings ]
>   * Add 686 kernels to replace 586 for i386 CDs. Closes: #808958
>
>- -- Steve McIntyre <93...@debian.org>  Mon, 20 Apr 2015 12:36:57 +0100
>+  [ Nicholas D Steeves ]
>+  * Change dependency on btrfs-tools to btrfs-progs
>+
>+ -- Nicholas D Steeves   Fri, 08 Apr 2016 16:48:52 -0400
>
> debian-cd (3.1.17) unstable; urgency=medium
>
>diff -ur ./tools/generate_di+k_list ../debian-cd/tools/generate_di+k_list
>--- ./tools/generate_di+k_list  2016-04-08 16:51:39.848068578 -0400
>+++ ../debian-cd/tools/generate_di+k_list   2016-04-08
>16:54:11.457239376 -0400
>@@ -60,7 +60,7 @@
> jfsutils
> dosfstools
> reiserfsprogs
>-btrfs-tools
>+btrfs-progs
> ufsutils
> zfsutils
> cryptsetup
>
>
-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
The two hard things in computing:
 * naming things
 * cache invalidation
 * off-by-one errors  -- Stig Sandbeck Mathisen

Bug#820483: upgrade priority

[Nicholas D Steeves]

control: severity -1 important

Hi, I'm raising the severity here on Gianfranco Costamagna's
recommendation.  'hope I'm doing this right for a project that has
four bug reports!

Best regards,
Nicholas

Bug#820026: icedove crashes (segfaults) when installed along with xul-ext-foxyproxy-standard

[Carsten Schoenert]

Hello Cyril,

On Mon, Apr 04, 2016 at 10:50:55PM +0200, Cyril Chaboisseau wrote:
> I've been fighting to understand why icedove was crashing on me (either
> segfaults or with bus error) for both versions 38 and 44, 

sounds strange.
Can you please create a backtrace of such crashes?

  https://wiki.debian.org/Icedove#Debugging

Before deciding what to do next it would be interesting to see where
the crashes happen.

> after finally
> discovering that Firefox extension foxyproxy 4.5.6 was causing the
> crashes
> 
> see bug #815000
> 
> if the problem cannot be solved (from what I understand after a quick
> look at the upstream bug report), that needs to be dealt in the icedove
> package to prevent others from having both packages installed alongside
> 
> foxyproxy 4.5.6 is already in testing since 31 March, and I fear that
> many Debian users who have both programs don't understand at first
> glance that the instability comes from this bad interaction
> 
> please, add a tag to put xul-ext-foxyproxy-standard in conflict with
> icedove (at least with this specific version if you think that it will
> be solved in an upcoming release)

A crash is definitely a bug and have to be fixed, so it wouldn't be the
right thing to "fix" such a issue by adding a conflicts line. For now we
have to figure out where and why Icedove is crashing.

Regards
Carsten

Bug#820484: nodm can't open pam_unix.so, segfaults

[Aljoscha Feodor]

Package: nodm
Version: 0.12-1
Severity: normal

Relevant logs:
> nodm[10864]: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so:
cannot open shar
> nodm[10864]: PAM adding faulty module: pam_unix.so
> nodm[19991]: X session 10864 was killed with signal 11
> kernel: nodm[10864]: segfault at 968 ip 7fabe0ccdd8e sp 7ffd20a1bde0
error 4 in lib
> nodm[19991]: sending X server 10854 the TERM signal
> nodm[19991]: session lasted less than 60 seconds: sleeping 30 seconds before
restarting it

A workaround that worked for me:
Install libpam-unix2 and create a symlink /lib/security/pam_unix.so ->
/lib/security/pam_unix2.so



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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
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)

Versions of packages nodm depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.22-5
ii  libpam0g   1.1.8-3.2
ii  libx11-6   2:1.6.3-1
ii  x11-common 1:7.7+14
ii  xserver-xorg   1:7.7+14

nodm recommends no packages.

nodm suggests no packages.

-- debconf information:
* nodm/enabled: true
* nodm/xsession: /etc/X11/Xsession
* nodm/x_options: -nolisten tcp
* nodm/first_vt: 7
* nodm/min_session_time: 60

Bug#816722: zoom-player: interraction with xscreensaver

[Tormod Volden]

On Fri, Apr 8, 2016 at 7:01 PM, Jamie Zawinski  wrote:
> On Fri Apr 08 2016 02:12:12, Tormod Volden wrote:
>
>> But let me be clear, I am only talking about the part "let's start the
>> hack with name X". For running helpers etc it would be nice to have a
>> reasonable PATH so xscreensaver-get-images & friends can be found
>> without that we force full paths on them, or clumsy soft links in
>> /usr/lib/xscreensaver - this would get messy since "friends" can
>> involve a lot of dependencies. Is it not possible to say, when X is a
>> name in preferences that has no path, to run /usr/lib/xscreensaver/X
>> but with full (unmodified) PATH?
>
> Sorry, I don't understand what you're proposing. Can you give some examples?
>
> Why do you object to "just set $PATH in whatever script launched 
> xscreensaver"? That seems simple to me.

I don't object to setting PATH, it seems simple and it would help
against the name clashes in /usr/games like zoom. I am just thinking
of possible clashes with other programs in /usr/bin as well. There are
like 1 packages in Debian and new ones coming all the time, so it
can make sense to "protect" the screensaver from conflicts. Because
some hacks execute utilities we are placing in /usr/bin, for instance
xscreensaver-get-image (and I think some of these call other utilities
also), a modified PATH will still have to include /usr/bin. Since we
are placing all hacks into /usr/lib/xscreensaver, we can also restrict
the spawning of hacks to this path. Then PATH can be left unmodified,
for whatever the hacks need to execute. And in the few cases the user
wants to add another executable to his configuration file, he will
just have to provide the full path to it. We would simply check
hack->command for a starting slash and if none, prepend
/usr/lib/xscreensaver. So if the configuration file says "zoom -bla"
we would run "/usr/lib/xscreensaver/zoom -bla". If it says
"/usr/games/zoom -bla" we would run that. It would be more restrictive
but also more fail proof.

Tormod

Bug#819982: mandos-client: bad gpgme_op_decrypt: GPGME: Decryption failed.

[Teddy Hogeborn]

tags 819982 + unreproducible
quit

Felix Koop  writes:

> > Teddy Hogeborn  hat am 5. April 2016 um 10:12 
> > geschrieben:
> > 
> > So the client works in the normal system but fails in the initrd?
> > That is odd.  I have a few suggestions to gather more data to help
> > with debugging:
> > 
> > 1. Uncomment the line in /etc/mandos/plugin-runner.conf which says
> >"--options-for=mandos-client:--debug", and rebuild the initramfs
> >image with "update-initramfs -k all -u".  When booting, the
> >Mandos client should now output debug information, including more
> >details about the error you reported.
> > 
> I don't see any more specific error, but I have attached a photo of
> the boot process when the error happens (hope that helps).

The photo actually does contain *some* more information about the error,
but it is not very helpful:

Trying to decrypt OpenPGP data
bad gpgme_op_decrypt: GPGME: Decryption failed
Unsupported algorithm: (null)
Wrong key usage: 0
Public key algorithm: RSA
Key ID: F8118489CABEB18B
Secret key available: Yes

So I'm guessing that the key ID for the client is F8118489CABEB18B?
This should be what the fingerprint should end with in the client.conf
file on the server, at least.

> > 2. Unpack the initramfs image and list the files it contains -
> >perhaps it is missing something important for some odd reason.
> >This is most easily done by running the "initramfs-unpack" script
> >from the Mandos source tree, which will unpack all initramfs
> >images to /tmp.  The script file is available here:
> > 
> >   
> > .
> 
> Listing is attached.

You do have some *extra* stuff in your initramfs image compared to what
I have on Debian stable, but nothing seems to be *missing*.

> > 3. Boot your system with the additional kernel command line argument
> >"break".  This will start an emergency shell.  First, run the
> >command
> > 
> > chmod a=rwxt /tmp
> > 
> >Then you should be able to run the /lib/mandos/plugin-runner
> >program, and by running the command multiple times you should be
> >able to debug the problem.  Also, the output of the "gpgconf"
> >command in this mode should be informative, especially compared
> >to its output when run in the normal system.
>
> I don't get the emergency shell, but a kernel panic instead. Then the
> system reboots. This continues.

Right.  I suggest you take that up with the initramfs-tools maintainer.

Can you reproduce the problem by unpacking the initramfs (as above),
chrooting into it, and running the mandos-client from inside it?

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos

Bug#820431: smplayer: Please keep the package in the repository up-to-date

[Debian/GNU]

Control: found -1 15.11.0~ds0-1
Control: notfound -1 16.4.0
Control: severity -1 wishlist
Control: tags -1 pending
Thanks

On 04/08/2016 01:22 PM, Simon wrote:
> Package: smplayer
> Version: 16.4.0

hmm, as far as i understand, if the package version was 16.4.0 than this
bug-report would be void.

> Severity: normal
> 
> Dear Maintainer,
> 
> Currently the version in the repository is 15.11 while the version available
> from the developer website is 16.4.
> Wouldn't it be possible to keep the repository version alligned with the
> official version?

we (the package maintainers) strive to keep our packages up-to-date.
if they are not at the same version as upstream, there is usually a
reason for this (mostly lack of manpower).

The good news is that an updated package has been uploaded an hour ago
by sramacher.

gfmards
IOhannes



signature.asc
Description: OpenPGP digital signature

Bug#820479: patch

[Nicholas D Steeves]

Sorry, forgot to include this patch:

diff -ur ./debian/changelog ../debian-cd/debian/changelog
--- ./debian/changelog  2016-04-08 16:51:39.824068392 -0400
+++ ../debian-cd/debian/changelog   2016-04-08 16:54:23.95689 -0400
@@ -1,4 +1,4 @@
-debian-cd (3.1.18) UNRELEASED; urgency=medium
+debian-cd (3.1.18+nmu1) UNRELEASED; urgency=medium

   [ Steve McIntyre ]
   * Start stretch, simply copying jessie for now
@@ -53,7 +53,10 @@
   [ Ben Hutchings ]
   * Add 686 kernels to replace 586 for i386 CDs. Closes: #808958

- -- Steve McIntyre <93...@debian.org>  Mon, 20 Apr 2015 12:36:57 +0100
+  [ Nicholas D Steeves ]
+  * Change dependency on btrfs-tools to btrfs-progs
+
+ -- Nicholas D Steeves   Fri, 08 Apr 2016 16:48:52 -0400

 debian-cd (3.1.17) unstable; urgency=medium

diff -ur ./tools/generate_di+k_list ../debian-cd/tools/generate_di+k_list
--- ./tools/generate_di+k_list  2016-04-08 16:51:39.848068578 -0400
+++ ../debian-cd/tools/generate_di+k_list   2016-04-08
16:54:11.457239376 -0400
@@ -60,7 +60,7 @@
 jfsutils
 dosfstools
 reiserfsprogs
-btrfs-tools
+btrfs-progs
 ufsutils
 zfsutils
 cryptsetup

Bug#820483: accommodate rename of btrfs-tools to btrfs-progs

[Nicholas D Steeves]

Package: partman-btrfs
Version: 20

I am working on problems associated with bug #780081, where it was
planned to have a fix staged in experimental after Jessie was
released.

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

  http://mentors.debian.net/package/partman-btrfs

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/partman-btrfs/partman-btrfs_20+nmu1.dsc

On #debian-boot jcristau said he prefered "a git tree [which] would be
easier than a source package tbh".  I don't have alioth permissions to
push to partman-btrfs or debian-cd so I've published it here.  Please
let me know if you'd prefer a diff.  The repo can be found here:

https://github.com/sten0/partman-btrfs.git

Thanks,
Nicholas

Bug#820482: acpid shouldn't run in a container

[Simon Deziel]

Package: acpid
Version: 2.0.26-1

acpid is AFAIK not needed in containers.

Regards,
Simon
diff --git a/debian/acpid.service b/debian/acpid.service
index acff887..4b46914 100644
--- a/debian/acpid.service
+++ b/debian/acpid.service
@@ -1,6 +1,7 @@
 [Unit]
 Description=ACPI event daemon
 Requires=acpid.socket
+ConditionVirtualization=!container
 
 [Service]
 StandardInput=socket

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

[Gianfranco Costamagna]

Hi,


>I've filed a bug and submitted a patch for debian-cd and have>contacted the 
>maintainers of partman-btrfs links to the updated
>package on mentors and to a github repo, because jcristau on
>#debian-installer said he preferred pulling from a git repo.  How long
>should I wait before filing an RFS bug against partman-btrfs?  It's
>also tagged for release to experimental.


I would also open a bug severity important and tags patch against the package,
just in case we will have to NMU it, we would have left enough time for the 
maintainers
to reply and give us their opinion.

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

I would give them at least 15 days after both bugs are opened, and then upload 
on experimental.

>Given that both of these will be broken if this package isn't
>uploaded, is now the time to upload it?

I didn't understand this sentence.

We can probably upload on experimental, wait for them to be fixed (or NMU them) 
and in the meanwhile
go for unstable.

this is my point of view, not sure if the best one.
please open the other bug, and then remove the moreinfo tag.
in that case I'll upload probably on experimental in deferred/15 queue, to let 
maintainers answer and followup
on this package.

thanks,

G.

Bug#820479: accommodate rename of btrfs-tools to btrfs-progs (patch included)

[Gianfranco Costamagna]

control: severity -1 important

Hi, I'm raising the severity there, the upload might probably end up in 
unstable this month
or the next one, so I'm preparing the stanza for a possible NMU there.

let me know if possible about your favorite way to followup.

thanks a lot,

Gianfranco

On Fri, 8 Apr 2016 17:07:35 -0400 Nicholas D Steeves  wrote:
> Package: debian-cd
> Version: 3.1.18
> 
> I am working on problems associated with bug #780081, where it was
> planned to have a fix staged in experimental after Jessie was
> released.
> 
> Associated bugs:
> #780081: btrfs-tools: rename package to btrfs-progs
> #818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]
> 
> I've tagged btrfs-progs for release to experimental, and Gianfranco
> Costamagna has agreed to sponsor the upload.  I will contact the
> maintainer[s] of partman-btrfs momentarily.
> 
> Kind regards,
> Nicholas
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

[Nicholas D Steeves]

Moreinfo removed, because Sledge on #debian-installer directed me to
what I needed to patch in debian-cd.

-- Nicholas

Bug#793934: some icons of menus in retext can't show normally

[Dmitry Shachnev]

Hi Marc,

On Sat, Apr 02, 2016 at 09:17:37PM +0900, Marc Dequènes (duck) wrote:
> Now I understand better how this is supposed to work.
>
>> If you know any other ways how ReText can extract the icon theme info
>> from your environment, let me know and I will try to implement it.
>
> I don't. nevertheless this is the first time it ends up with no icons, so
> other applications might have found a way.

If GTK+ applications have the icons, then ReText will have them too (as one
of its backends for searching icons is using GTK+).

For Qt applications things are much worse — I am quite sure that any Qt
application that doesn't embed the icons with itself will not find the icon
theme on your environment, just like ReText did.

> So I guess the best way would be to fallback on a default set of icons,

Shipping a subset of some icon theme with ReText package is definitely not
a Debian way of doing things. Also I cannot add a dependency on any icon
theme because any other can be used (and we don't have a virtual package that
any icon theme would satisfy).

> or at least have text on the buttons (expecting people to loop on buttons
> to read the tooltips…).

I have looked at Qt API and there is no easy way to do this. Also, this has
a potential to hide the real bug where people will see the labels and think
that it's by design.

What I can do is add suggestions for packages needed for GSettings icon
theme resolver to work. Done that in SVN.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#806048: iipimage: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 806048 + patch
thanks

The following patch should fix this issue, by using a new file called

debian/iipimage-server.install

instead of overriding dh_install. dh will know what it has to do in each case.

Thanks.diff --git a/debian/iipimage-server.install b/debian/iipimage-server.install
new file mode 100644
index 000..c202cf1
--- /dev/null
+++ b/debian/iipimage-server.install
@@ -0,0 +1,3 @@
+src/iipsrv.fcgi usr/lib/iipimage-server
+debian/iipsrv.conf  etc/apache2/mods-available
+debian/iipsrv.load  etc/apache2/mods-available
diff --git a/debian/rules b/debian/rules
index 04fe0cc..eaad717 100755
--- a/debian/rules
+++ b/debian/rules
@@ -18,11 +18,6 @@ override_dh_auto_configure:
 override_dh_clean-arch:
rm -rf fcgi
 
-override_dh_install:
-   dh_install src/iipsrv.fcgi usr/lib/iipimage-server/
-   dh_install debian/iipsrv.conf etc/apache2/mods-available
-   dh_install debian/iipsrv.load etc/apache2/mods-available
-
 override_dh_auto_install:
# for some reason it install fcgi headers
 

Bug#820472: audacious: A GTK2+ media player should really not depend on Qt 5

[aga...@siduction.org]

> The upstream sources are really to difficult to separate qt and gtk2
> version. Both using the same binary with individual parameter.
> I wondered on building audacious-qt package, but will it takes twice
Aggreed, it is impossible for now to build audacious-qt without GTK
dependencies, but it is possible to build GTK without Qt.
If you look at the current audacious package there is no Qt-dependeny -
the Qt-part is in libaudqt0.
So it should be possible to split at least the GTK and Qt-Plugins to
have a GTK only set of packages for GTK DEs.


0x4D72827C.asc
Description: application/pgp-keys

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

[Nicholas D Steeves]

I've filed a bug and submitted a patch for debian-cd and have
contacted the maintainers of partman-btrfs links to the updated
package on mentors and to a github repo, because jcristau on
#debian-installer said he preferred pulling from a git repo.  How long
should I wait before filing an RFS bug against partman-btrfs?  It's
also tagged for release to experimental.

Given that both of these will be broken if this package isn't
uploaded, is now the time to upload it?

Cheers,
Nicholas

Bug#820481: libimage-exiftool-perl: new upstream available (10.14)

[Karsten Hilbert]

Package: libimage-exiftool-perl
Version: 10.13-1
Severity: wishlist
Tags: upstream

Dear packagers,

there's a new upstream version available (10.14).  I am only reporting
because the package tracker seems to currently have problems with the
watch file.

Thanks for considering :-)

Karsten

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libimage-exiftool-perl depends on:
ii  perl  5.22.1-9

Versions of packages libimage-exiftool-perl recommends:
ii  libarchive-zip-perl  1.57-1

libimage-exiftool-perl suggests no packages.

-- no debconf information

Bug#820068: [Pkg-phototools-devel] Bug#820068: optipng: diff for NMU version 0.7.5-1.1

[Emmanuel Bouthenot]

Salvatore,

On Fri, Apr 08, 2016 at 07:19:35AM +0200, Salvatore Bonaccorso wrote:
[...]

> jessie-security upload. Better would be though to straight go to 0.7.6.
Thanks for your various feedbacks.

optipng 0.7.6 will be uploaded into unstable in a few minutes.

Regards,

M.

-- 
Emmanuel Bouthenot
  mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
  xmpp: kol...@im.openics.org  irc: kolter@{freenode,oftc}

Bug#804582: (no subject)

[Barry Warsaw]

Okay, so I think the locale changes are enough to fix the FTBFS.  I retried
building in an Ubuntu PPA and the build succeeded.

The timeout failure must just have been a problem with my local sbuild.

Bug#780706: Update re: arduino 1.6+

[Scott Howard]

The update is there is no update. The Debian git repository is still ready
to go,. I don't have time to work on it that much at the moment (either on
following up with licensing or packaging), so if anyone is interested in
helping out in any way (including co-maintaining or adopting the package),
please let me know.
~Scott

Bug#820480: pocl: New version pocl 0.13

[Achim Schaefer]

Source: pocl
Version: 0,10-12
Severity: wishlist
Tags: upstream

Dear Maintainer,

 there is alreay a version 0.13 out.
Please package the new version

Thanks

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

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

Bug#806656: lilo: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 806656 + patch
thanks

> dh_install
> Set execute flag to chattr-lilo hook scripts
> chmod 0755 debian/lilo/usr/lib/lilo/hooks/kernel/*/chattr-lilo
> chmod: cannot access 'debian/lilo/usr/lib/lilo/hooks/kernel/*/chattr-lilo': 
> No such file or directory
> debian/rules:20: recipe for target 'override_dh_install' failed

Explanation: We are creating arch-independent packages, so debian/lilo/[...]
does not exist because lilo is arch-dependent.

Trivial patch attached.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -16,8 +16,8 @@ override_dh_auto_build:
uudecode -o /dev/stdout debian/doc/tech.html.uu 2>/dev/null | tar -x -z 
-C debian
uudecode -o /dev/stdout debian/doc/user.html.uu 2>/dev/null | tar -x -z 
-C debian
 
-override_dh_install:
-   dh_install
+override_dh_fixperms-arch:
+   dh_fixperms
@echo "Set execute flag to chattr-lilo hook scripts"
chmod 0755 debian/lilo/usr/lib/lilo/hooks/kernel/*/chattr-lilo
 

Bug#796752: Me Too...

[Michael Lustfield]

I ran into this today. I don't have a lot of hope considering the
reporter never got a reply in nearly a year.

I'm using Debian Stable, everything up to date, ssh+screen+irssi. I'm
not even sure what libres is.

At this point, EVERY time I start irssi, I see these lines. Nothing on
this system has changed other than variable data storage. No package
installations/removals in approximately a month. Seems to have just
started today.

Bug#820479: accommodate rename of btrfs-tools to btrfs-progs (patch included)

[Nicholas D Steeves]

Package: debian-cd
Version: 3.1.18

I am working on problems associated with bug #780081, where it was
planned to have a fix staged in experimental after Jessie was
released.

Associated bugs:
#780081: btrfs-tools: rename package to btrfs-progs
#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

I've tagged btrfs-progs for release to experimental, and Gianfranco
Costamagna has agreed to sponsor the upload.  I will contact the
maintainer[s] of partman-btrfs momentarily.

Kind regards,
Nicholas

Bug#820128: vlc: Hardware decode issues/Video stops after a few seconds

[Sebastian Ramacher]

Control: forcemerge 819453 -1
Control: forwarded -1 https://forum.videolan.org/viewtopic.php?f=13=131509

On 2016-04-05 20:15:04, Andoru wrote:
> Package: vlc
> Version: 2.2.2-5
> Severity: normal
> 
> I've previously posted this issue on the VideoLAN forums, but since I
> didn't get any answers there, I'll try to submit this as a bug report,
> since I'm not aware of anything that I might've done to cause this.
> 
> So here's the post for more details:
> 
> https://forum.videolan.org/viewtopic.php?f=13=131509
> 
> Also I noticed that there's another person who has the same issue as me
> with the video not being stretched in full-screen, or when changing the
> aspect ratio: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819453 (bug
> #819453)

So let's merge them.

Regards
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#816983:

[Santiago Vila]

severity 816983 serious
retitle 816983 nipy: FTBFS in testing
thanks

This is not "dpkg-buildpackage -A" specific.

It also FTBFS in the normal sense:

https://reproducible.debian.net/rb-pkg/testing/amd64/nipy.html

Bug#601605: fbreader: Make it a minor bug

[Alex Henry]

Package: fbreader
Version: 0.12.10dfsg2-1
Followup-For: Bug #601605

I actually think this is a bug, not a wishlist item. A program
should be registered to open the files it is able to open.

Imagine someone without much technical knowledge: reads fbreader
is able to open epub books on the web, installs package and then
fails to open the books/files upon clicking on them. It could
practically make the package unusable on this case.

Sure it's not a major bug but it's a bug nonetheless. Thank you
for your consideration.


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

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
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)

Versions of packages fbreader depends on:
ii  libc6  2.22-5
ii  libgcc11:5.3.1-13
ii  libsqlite3-0   3.11.1-1
ii  libstdc++6 5.3.1-13
ii  libzlcore0.13  0.12.10dfsg2-1
ii  libzltext0.13  0.12.10dfsg2-1
ii  libzlui-qt40.12.10dfsg2-1

fbreader recommends no packages.

fbreader suggests no packages.

-- no debconf information

Bug#820478: okular-extra-backends: cannot open epub even with extra-backends package installed

[Alex Henry]

Package: okular-extra-backends
Version: 4:15.08.3-1
Severity: normal

Hello,

I have just installed the okular-extra-backends package and
am unable to open .epub files with Okular, which the package
description says I should be able to do.

When I try to open any ePub document I get a dialog saying:
"Could not open /path/to/myfile.epub" (replace with proper path)

The main UI window also indicates: "Can not find a plugin which is
able to handle the document being passed".

Let me know what I can do to help fix and test this. After installing
the extra-backends package ePub files have been associated with
Okular, which they weren't before so it's further indication that
the program should be able to handle them.

The files open fine on fbreader.

I'd also like to question why isn't the extra-backends package
recommended instead of suggested (which would make it install
by default on some package managers like aptitude). Especially
due to the epub capability I think it should be recommended, as
I see many people on the web ask about epub readers for Linux
and Okular's premise of being a all-in-one reader makes it perfect
as an ebook reader.


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

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
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)

Versions of packages okular-extra-backends depends on:
ii  libc6   2.22-5
ii  libchm1 2:0.40a-3+b1
ii  libdjvulibre21  3.5.27.1-5
ii  libepub00.2.2-4+b1
ii  libkdecore5 4:4.14.14-1+b1
ii  libkdeui5   4:4.14.14-1+b1
ii  libkhtml5   4:4.14.14-1+b1
ii  libkio5 4:4.14.14-1+b1
ii  libokularcore6  4:15.08.3-1
ii  libqt4-xml  4:4.8.7+dfsg-6
ii  libqtcore4  4:4.8.7+dfsg-6
ii  libqtgui4   4:4.8.7+dfsg-6
ii  libstdc++6  5.3.1-13
ii  libtiff54.0.6-1

Versions of packages okular-extra-backends recommends:
ii  okular  4:15.08.3-1

okular-extra-backends suggests no packages.

-- no debconf information

Bug#541157: RFP: vbam - Gameboy Advance emulator

[PICCORO McKAY Lenz]

fixed with the build line in rules

u have "-DENABLE_GTK2=OFF" and must be "-ENABLE_GTK=OFF" and that's
why try to build a gtk2 gui alongside gtk3 gui

i also nothed the optimization problem are not solved and still i
cannot set -O3 the compiler take several memory to compute
optimizations and never finished!

with gcc 3.4 this not happened and build are more faster!


my las lines in console was susessfully compiled an packaged! in jessie!


   dh_builddeb -O--buildsystem=cmake -O--builddirectory=obj -O--parallel
dpkg-deb: construyendo el paquete `vbam' en
`../vbam_1.8.0+git20160220-1_i386.deb'.
dpkg-deb: construyendo el paquete `vbam-sdl' en
`../vbam-sdl_1.8.0+git20160220-1_i386.deb'.
dpkg-deb: construyendo el paquete `vbam-gtk' en
`../vbam-gtk_1.8.0+git20160220-1_i386.deb'.
dpkg-deb: construyendo el paquete `vbam-common' en
`../vbam-common_1.8.0+git20160220-1_all.deb'.
 dpkg-genchanges  >../vbam_1.8.0+git20160220-1_i386.changes
dpkg-genchanges: incluyendo el código fuente completo en la subida
 dpkg-source --after-build vbam-1.8.0+git20160220
dpkg-buildpackage: subida completa (se incluye la fuente original)
root@sysanydesktop0:/home/remoto/Devel/vbam/vbam-1.8.0+git20160220#

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


2016-04-07 19:27 GMT-04:30 Sérgio Benjamim :
> Hi,
>
> I uploaded it again. The build is broken. Good luck
>
> https://mentors.debian.net/package/vbam
>
> src/gtk/screenarea.cpp: In constructor ‘VBA::ScreenArea::ScreenArea(int,
> int, int)’:
> src/gtk/screenarea.cpp:53:62: error: no matching function for call to
> ‘Gdk::Cursor::Cursor(,
> Glib::RefPtr&, int, int)’
>m_poEmptyCursor = new Gdk::Cursor(get_display, pixbuf, 0, 0);
>
>
> sergio-br2
>
>
> On 06/04/2016 17:54, PICCORO McKAY Lenz wrote:
>>
>> the package in mentors are now go..
>>
>> please reupload to mentors
>>
>> mentors must mantain the packages that already has a bug number
>> relationship and only erase those that are onlñy uploaded alone
>> without a itp or rfp bug related!
>>
>>
>> Lenz McKAY Gerardo (PICCORO)
>> http://qgqlochekone.blogspot.com
>
>

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[Peter Colberg]

On Fri, Apr 08, 2016 at 09:55:02PM +0200, Graham Inggs wrote:
> On 8 April 2016 at 21:16, Emilio Pozuelo Monfort  wrote:
> > Why did you switch to 3.8? The default in unstable is 3.6 and in 
> > experimental is
> > 3.7.
> 
> I understood there were severe performance regressions with Julia on
> LLVM > 3.3 that were only fixed in 3.8.

The reason for switching to LLVM 3.8 was the abysmal performance
of LLVM 3.7 on i386, and complete failure of LLVM 3.6 or earlier.

https://github.com/JuliaLang/julia/issues/14191

Peter

Bug#820470: [pkg-ntp-maintainers] Bug#820470: ntp: upstream version ntp-4.2.8p6

[Nicholas Luedtke]

> 
> It actually doesn't fix all of them.  I've been waiting for
> upstream to finally fix it, but it seems nothing is happening.
> 
> 
> Kurt
> 

Yeah I noticed that there are a couple in the bug reports that being
claimed as not completely fixed. Is your intent to wait till upstream
closes these out?

-- 
Nicholas Luedtke
HPE Linux, Hewlett-Packard Enterprise



signature.asc
Description: OpenPGP digital signature

Bug#820338: slang2: diff for NMU version 2.3.0-2.1

[Gianfranco Costamagna]

control: tags -1 pending patch

Hi,



>I don't think this was the right fix, because this kind of Recommends
>is wrong in two accounts. First the module using this shared library is
>shipped in the libslang2-modules, so the dependency is useless here. And
>second, hardcoding the shared library name means each time the SONAME
>changes this package has to be patched manually (making transitions
>harder as binNMUs do not work here), when dpkg-shlibdeps has all the
>required information to infer the correct dependency by using
>-dRecommends for example.


I agree with you, unfortunately I lack of time to give to each package
for this transition, and the NMU was enough, even if delaying the issue
to the next transition :)

thanks for checking, I should have spent a minute more and avoided this
NMU, but I was trying to be safe, instead of being sorry :)
>Please use the attached patch to properly fix this so that we don't
>need to touch this on the next transition! :)


Not providing a libpng16-dev library, but only a libpng-dev one, will
probably avoid the ~100 NMU we had to do for this one :D

cheers, and thanks

Gianfranco

Bug#820352: [Pkg-utopia-maintainers] Bug#820352: network-manager: usb ath9k wifi asigned default wired connection at boot

[Michael Biebl]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=764803

Am 08.04.2016 um 21:55 schrieb Jason Woofenden:
> I pushed this upstream: https://bugzilla.gnome.org/show_bug.cgi?id=764803
> 
> And added the udevadm info.

Thanks a lot, Jason.

Marking the bug as forwarded accordingly.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#820470: [pkg-ntp-maintainers] Bug#820470: ntp: upstream version ntp-4.2.8p6

[Kurt Roeckx]

On Fri, Apr 08, 2016 at 12:26:59PM -0600, Nicholas Luedtke wrote:
> Package: ntp
> Version: 1:4.2.8p4+dfsg-3
> Severity: wishlist
> 
> Dear Maintainer,
> 
> NTP version ntp-4.2.8p6 is available upstream and includes fixes for 9
> CVE's listed below. Though they are mostly minor the cumulative effect
> of removing these from our stream would be beneficial. We should
> consider updating ntp in sid/stretch to incorporate these security fixes.

It actually doesn't fix all of them.  I've been waiting for
upstream to finally fix it, but it seems nothing is happening.


Kurt

Bug#819019: fake-hwclock: allow the saved time to go backwards under normal use

[Robie Basak]

On Fri, Apr 08, 2016 at 06:49:35PM +0100, Steve McIntyre wrote:
> The problem is that I don't think there's a good solution to both
> problems here. We can't *know* that the system time has been read from
> fake-hwclock.data before calling "save". I briefly considered adding a
> "I've seen this" flag that could be set in "load", but that's no
> guarantee at all - if we power down unexpectedly then it'll be set
> already at next boot.

Could you leave something in /run that notes that load has been called?
Or is /run not available at the right time for that?

> What we *can* do is instead add an extra declaration of system time
> based on the build/release date of the particular version of the
> fake-hwclock package in use, and refuse to back to a date before
> *that* unless --force is used. How does that sound?

That would work for my use case, I think. Since in my failure case the
time ends up right back near the epoch and nowhere near the present
time.

Robie

Bug#818244: Request to close

[Erik Haller]

I ran the gmonitor program. Attached are two files. It looks like you found
something.

FYI: I changed my graphics card yesterday. From a radeaon X1300 to an
nvidia GT 610. The nvidia has to ports and I no longer use the Y cable.
They're also appearing under xrandr as DVI-2|3. The new card does not
appear to affect your test.

On Fri, Apr 8, 2016 at 8:52 AM, Yves-Alexis Perez  wrote:

> On jeu., 2016-04-07 at 00:58 -0700, Erik Haller wrote:
> > All I can say is that xfce4 was using monitorDVI-0 and then switched to
> > monitor0. I had to move my settings from monitorDVI-0 to monitor0.
>
> I've crafted the attach gtk/gdk program which indeed returns no monitor
> name
> here. Can you try it on both xorg version and report back?
>
> Regards,
> --
> Yves-Alexis
>
>


xserver-7.7+13
Description: Binary data


xserver-7.7+14
Description: Binary data

Bug#812823: utopia-documents: Segmentation fault on start

[Douglas Calvert]

Package: utopia-documents
Version: 2.4.4-2.1
Followup-For: Bug #812823

Ping?


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

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

Versions of packages utopia-documents depends on:
ii  libboost-python1.58.0 1.58.0+dfsg-5+b1
ii  libboost-system1.58.0 1.58.0+dfsg-5+b1
ii  libboost-thread1.58.0 1.58.0+dfsg-5+b1
ii  libc6 2.22-5
ii  libexpat1 2.1.1-1
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:5.3.1-13
ii  libgl1-mesa-glx [libgl1]  11.1.2-1
ii  libglew1.10   1.10.0-3
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libpcre3  2:8.38-3.1
ii  libpcrecpp0v5 2:8.38-3.1
ii  libpython2.7  2.7.11-7
ii  libqglviewer2 2.6.3+dfsg1-1
ii  libqjson0 0.8.1-3
ii  libqt4-network4:4.8.7+dfsg-6+b1
ii  libqt4-opengl 4:4.8.7+dfsg-6+b1
ii  libqt4-script 4:4.8.7+dfsg-6+b1
ii  libqt4-svg4:4.8.7+dfsg-6+b1
ii  libqt4-xml4:4.8.7+dfsg-6+b1
ii  libqtcore44:4.8.7+dfsg-6+b1
ii  libqtgui4 4:4.8.7+dfsg-6+b1
ii  libqtwebkit4  2.3.4.dfsg-6+b1
ii  libraptor11.4.21-11+b1
ii  libssl1.0.0   1.0.2d-1
ii  libstdc++65.3.1-13
ii  python-cssselect  0.9.1+git90c72b0-1
ii  python-imaging3.1.1-1
ii  python-lxml   3.6.0-1
ii  python-suds   0.7~git20150727.94664dd-3
ii  python2.7 2.7.11-7
pn  python:any
ii  xdg-utils 1.1.1-1
ii  zlib1g1:1.2.8.dfsg-2+b1

utopia-documents recommends no packages.

utopia-documents suggests no packages.

-- no debconf information

Bug#820473: console-setup-linux: keyboard-setup.sh calls tools from /usr filesystem which isn't mounted yet

[Steve McIntyre]

On Fri, Apr 08, 2016 at 09:33:39PM +0300, Andriy Martynets wrote:
>Package: console-setup-linux
>Version: 1.141
>Severity: important
>
>Dear Maintainer,
>
>After latest system update (can't say for sure console-setup-linux or
>console-tools package was updated or both) keyboard-setup.sh started
>to fail at boot time. The point is that the script calls
>/etc/console-setup/cached_setup_keyboard.sh which in turn calls
>kbd_mode (utility from console-tools package) located in /usr/bin
>directory. The /usr filesystem isn't available at that stage as
>keyboard-setup.sh runs before mountall.sh.
>
>I believe that tools required at boot time must be within the rootfs
>(/bin or /sbin directories) or order of the init scripts must be
>changed.

This isn't a bug - if you have a separate /usr, it's expected that it
will be mounted by the initramfs before you get this far.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

Bug#820471: RFA: javaparser -- Java library for parsing Java 1.5.

[Emmanuel Bourg]

Control: retitle -1 RFH: javaparser -- Java library for parsing Java 1.5.

javaparser is already maintained by the Java Team, no need to adopt it.
I'm turning the bug into a request for help.

Emmanuel Bourg

Bug#820352: [Pkg-utopia-maintainers] Bug#820352: network-manager: usb ath9k wifi asigned default wired connection at boot

[Jason Woofenden]

Thanks Michael.

I pushed this upstream: https://bugzilla.gnome.org/show_bug.cgi?id=764803

And added the udevadm info.

-- 
Jason

> Hi Jason,
> 
> Am 07.04.2016 um 19:30 schrieb Jason Woofenden:
> > 
> > Every time I boot linux (2-ish times per day) NetworkManager won't
> > connect to my wifi, because it thinks my wifi card is an ethernet
> > device.
> 
> It would be great if you can file this bug upstream at
> 
> https://bugzilla.gnome.org/enter_bug.cgi?product=NetworkManager
> and report back with the bug number.
> 
> It's hard for me to reproduce the issue, since I don't own such a hardware.
> 
> What you might include in the upstream bug report is the
> udevadm info /sys/class/net/X
> output of the device directly after boot and after you unplug/plug it.
> 
> Regards,
> Michael
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#820477: pdf-presenter-console: URL of the homepage is incorrect

[Hong Xu]

Package: pdf-presenter-console
Version: 4.0.2
Severity: minor
Tags: newcomer

Dear Maintainer,

The URL of hte package should be http://pdfpc.github.io but not
http://pdfpc.github.io/pdfpc/ .



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

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

Bug#820220: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[Graham Inggs]

On 8 April 2016 at 21:16, Emilio Pozuelo Monfort  wrote:
> Why did you switch to 3.8? The default in unstable is 3.6 and in experimental 
> is
> 3.7.

I understood there were severe performance regressions with Julia on
LLVM > 3.3 that were only fixed in 3.8.

> I'm Cc'ing the arm and llvm lists, maybe they can give some hints.

Thanks.

I did ask on #debian-arm earlier today and was given some pointers by
suihkulokki.

Firstly, llvm-toolchain-3.8 hasn't actually built on armel yet [1], so
the julia build on armel is being attempted with llvm
1:3.8~svn247576-1 from llvm-toolchain-snapshot.

Secondly, it should be possible to reproduce the fault by building in
an armhf schroot on abel.d.o, which has the same hardware as the
buildds.  A temporary solution would be to upload armhf binaries built
on asachi.d.o.


[1] 
https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8=unstable

Bug#820476: opensips: unsatisfiable dependency on db4.6-util

[Steve Langasek]

Package: opensips-berkeley-module
Version: 2.1.2-2
Severity: grave

The opensips package in Debian unstable builds an opensips-berkeley-module
binary package which is uninstallable, and this package will therefore not
migrate to testing or be eligible for inclusion in the Debian release.

The uninstallability is caused by a dependency on db4.6-util, which does not
exist in any supported Debian release.

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


signature.asc
Description: Digital signature

Bug#806014: defendguin: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 806014 + patch
thanks

> make install \
>   DESTDIR=/debian/defendguin \
>   BIN_PREFIX=debian/defendguin/usr/games \
>   MAN_PREFIX=debian/defendguin/usr/share \
>   DATA_PREFIX=debian/defendguin/usr/share/games/defendguin/
> make[2]: Entering directory '/<>'
> install -d debian/defendguin/usr/share/games/defendguin/
> cp -R data/* debian/defendguin/usr/share/games/defendguin/
> chmod -R a+rX,g-w,o-w debian/defendguin/usr/share/games/defendguin/
> cp defendguin debian/defendguin/usr/games/
> cp: cannot create regular file 'debian/defendguin/usr/games/': Not a directory

Explanation: We are creating arch-independent packages only, so
"debian/defendguin/usr/games" does not exist because "defendguin" is
arch-dependent.

The following patch makes the packaging a little bit more orthodox
(by using *.install files instead of dh_movefiles) and should fix the
"dpkg-buildpackage -A" problem.

Thanks.commit 37f56e1c0cf6b393733860b4b59b505ff8167a56
Author: Santiago Vila 
Date:   Fri Apr 8 21:38:12 2016 +0200

Patch

diff --git a/debian/defendguin-data.install b/debian/defendguin-data.install
new file mode 100644
index 000..5bad92b
--- /dev/null
+++ b/debian/defendguin-data.install
@@ -0,0 +1 @@
+usr/share/games
diff --git a/debian/defendguin.install b/debian/defendguin.install
new file mode 100644
index 000..9af7d9f
--- /dev/null
+++ b/debian/defendguin.install
@@ -0,0 +1,4 @@
+usr/games/defendguin
+usr/share/man
+debian/defendguin-icon.xpm  usr/share/pixmaps
+debian/defendguin.desktop   usr/share/applications
diff --git a/debian/rules b/debian/rules
index 5e64b21..ba7ca7c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,14 +11,10 @@ override_dh_auto_build:
make -j1 DEB_CFLAGS="$(CFLAGS)" DATA_PREFIX=/usr/share/games/defendguin/
 
 override_dh_auto_install:
+   install -d debian/tmp/usr/games
+   install -d debian/tmp/usr/share/pixmaps
+   install -d debian/tmp/usr/share/applications
make install \
-  DESTDIR=/debian/defendguin \
-  BIN_PREFIX=debian/defendguin/usr/games \
-  MAN_PREFIX=debian/defendguin/usr/share \
-  DATA_PREFIX=debian/defendguin/usr/share/games/defendguin/
-
-   install -D -m 644 debian/defendguin-icon.xpm 
debian/defendguin/usr/share/pixmaps/
-   install -D -m 644 debian/defendguin.desktop 
debian/defendguin/usr/share/applications/
-
-   dh_movefiles --sourcedir=debian/defendguin
-   rm -rf debian/defendguin/usr/share/games
+  BIN_PREFIX=debian/tmp/usr/games \
+  MAN_PREFIX=debian/tmp/usr/share \
+  DATA_PREFIX=debian/tmp/usr/share/games/defendguin/

Bug#820378: Ensure users report bugs in BTS and not to upstream directly

[Stephen Paul Weber]

Unfortunately, there is no obvious way to file a bug from the URL used:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xscreensaver;dist=unstable


I agree.  A button to run `reportbug xscreensaver` or similar might be nice, 
but I understand maintainer's concern about this encouraging duplicate 
filings.


This, however, is a reportbug/debbugs issue generally and probably not as 
specifically related to this particular issue as it seems.


--
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph


signature.asc
Description: Digital signature

Bug#790925: 818501 may be related

[Diane Trout]

Hi,

I was looking through this bug and noticed the failure was in the HDF code.

This pytables bug might be related:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818501

The bug affected anything that used HDF indexes via pytables.

Diane

Bug#820466: golang-github-shirou-gopsutil-dev: not configured for ppc64(el)

[Aaron M. Ucko]

"Aaron M. Ucko"  writes:

>   # github.com/shirou/gopsutil/host
>   src/github.com/shirou/gopsutil/host/host_linux.go:108: undefined: utmp
>   src/github.com/shirou/gopsutil/host/host_linux.go:109: invalid expression 
> unsafe.Sizeof(u)
>   src/github.com/shirou/gopsutil/host/host_linux.go:117: undefined: utmp

These same errors showed up on arm64.  It looks like the existing
host_linux_arm.go is actually meant for arm64; please recharacterize it
appropriately and add a version suitable for 32-bit ARM (armel/armhf).

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#806015: Processed: direwolf: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Iain R. Learmonth]

Hi,

On Fri, Apr 8, 2016, at 08:03 PM, Debian Bug Tracking System wrote:
> > tags 806015 + patch
> Bug #806015 [src:direwolf] direwolf: FTBFS when built with
> dpkg-buildpackage -A (No such file or directory)
> Added tag(s) patch.

Thanks for the patch. I will look at this tonight and hopefully upload,
should be simple.

Thanks,
Iain.

Bug#820475: php7.0: php5 to php7.0 regression: undefined function xml_parser_create()

[Paul Gevers]

Package: php7.0
Version: 7.0.5-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In my effort to test my package cacti against php7.0 I found the following
regression. With php5 the page http://localhost/cacti/graphs_new.php works fine
and as expected, with php7.0 I get a 500 Internal Server error response due to
undefined function xml_parser_create. As far as I dived into this, php could
just support that and as the Debian package has done so for an extremely long
time, I think it is a regression not to do so with php7.0.

root@sid:~# wget $loadSaveCookie 
http://localhost/cacti/graphs_new.php--2016-04-08 20:57:19--  
http://localhost/cacti/graphs_new.php
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:80... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
2016-04-08 20:57:20 ERROR 500: Internal Server Error.

root@sid:~# tail -n1 /var/log/apache2/error.log 
[Fri Apr 08 20:57:20.116589 2016] [:error] [pid 22899] [client ::1:60646] PHP 
Fatal error:  Uncaught Error: Call to undefined function xml_parser_create() in 
/usr/share/cacti/site/lib/xml.php:29\nStack trace:\n#0 
/usr/share/cacti/site/lib/data_query.php(81): 
xml2array('\\n\\t
   ]  15.18K  --.-KB/sin 0s  

2016-04-08 21:03:45 (93.9 MB/s) - 'graphs_new.php.1' saved [15546]


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

Kernel: Linux 3.16.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
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJXCAETAAoJEJxcmesFvXUK1o4H/03juLm753bB/yF6wO50Csjz
gDZFbUshSi8cMkVsKlU3grsS5VKjfhZ2/sQKry4+J/cWEKmOG1IRX+aBXJH7JqG2
jkVVHLQI5vV1rFPu+DwFL2NHCEBwBiSOIdB9L/nYkWqbNzHCApff53y4JXnDtIue
FqP2THE53AACvn3cAUFLiB8kILSAikHS/o1ugHNsBy/qu4IkO83oZgPY+9LnlHBH
YmXpVT3CXzhNleuEio9OCyOEany1MEUuWlLG8zeNbYazIjbsC1pcBJKDRbJxPvK8
1aV+I1+Jout7OT4I+HVUGMxwXXzSfanaxCp1EAeXhE+ajwV7AvO88W48/zehqUo=
=1OZQ
-END PGP SIGNATURE-

Bug#820472: audacious: A GTK2+ media player should really not depend on Qt 5

[Mateusz Łukasik]

On 08.04.2016 20:31 +0200, Alf Gaida wrote:

Package: audacious
Version: 3.7.2-1
Severity: normal

Hi,
audacious now depends on some Qt 5 stuff, introduced via audacious-plugins - is 
this really needed?
Maybe this bug fits better for audacious-plugins.

Cheers Alf




Hi,

The upstream sources are really to difficult to separate qt and gtk2 
version. Both using the same binary with individual parameter.
I wondered on building audacious-qt package, but will it takes twice 
more time to compile, because first want to be compiled gtk and next qt.
I made something like that in spacefm package where is gtk2 and gtk3 
version.


Now I would change this bug as wish, maybe on upload 3.8 or looking that 
version new package will be add.



Cheers,

--
 .''`.  Mateusz Łukasik
: :' :  http://mati75.eu
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

Bug#820474: cups-filters: texttopdf seg faults if comment in prettyprinted source file ends with keyword

[Jim Uhl]

Package: cups-filters
Version: 1.0.61-5+deb8u3
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?

   Occasionally when prettyprinting files using CUPS results in a hung
   print job and no output.  A recent small example occurred which
   allowed creation of a small test case to demonstrate the problem.

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

   $ echo "//if" > a.c
   $ lpr -p a.c

   * What was the outcome of this action?

   No output on printer, print job gets stuck in queue.

   * What outcome did you expect instead?

   Pretty printed version of the above one line file.

Some digging in the cups log files revealed that
/usr/lib/cups/filter/texttopdf seg faults.  The error can be
reproduced direclty with the following command:

   $ echo "//if" | CONTENT_TYPE=application/x-csource 
/usr/lib/cups/filter/texttopdf 123 username a.c 1 "prettyprint" > a.c.pdf

Debugging with gdb, the local array "names", having 3 elements, in
filters/texttopdf.c:write_font_str is being indexed with a value of 3
because both bold and italic are active at the newline.

In filters/textcommon.c there are four places that look up keywords,
only one ensures that italics are not active when searching for a
keyword:

  if (!(attr & ATTR_ITALIC) &&
  bsearch(, Keywords, NumKeywords, sizeof(char *),
  compare_keywords))

The attached patch adds the attribute check to the other three
searches which prevents the seg fault - that is, texttopdf runs to
completion and generates a printable PDF.

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

Kernel: Linux 3.16.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
Init: systemd (via /run/systemd/system)

Versions of packages cups-filters depends on:
ii  bc 1.06.95-9
ii  cups-filters-core-drivers  1.0.61-5+deb8u3
ii  ghostscript9.06~dfsg-2+deb8u1
ii  libc6  2.19-18+deb8u4
ii  libcups2   1.7.5-11+deb8u1
ii  libcupsfilters11.0.61-5+deb8u3
ii  libcupsimage2  1.7.5-11+deb8u1
ii  libfontconfig1 2.11.0-6.3
ii  libfontembed1  1.0.61-5+deb8u3
ii  libgcc11:4.9.2-10
ii  libijs-0.350.35-10
ii  liblcms2-2 2.6-3+b3
ii  libpoppler46   0.26.5-2
ii  libqpdf13  5.1.2-2
ii  libstdc++6 4.9.2-10

Versions of packages cups-filters recommends:
ii  colord  1.2.1-1+b2

Versions of packages cups-filters suggests:
pn  foomatic-db-compressed-ppds | foomatic-db  

-- no debconf information
--- cups-filters-1.0.61/filter/textcommon.c	2016-04-08 10:48:07.0 -0700
+++ /tmp/cups-filters-1.0.61/filter/textcommon.c	2016-04-08 10:37:26.0 -0700
@@ -735,7 +735,8 @@
 	*keyptr = '\0';
 	keyptr  = keyword;
 
-	if (bsearch(, Keywords, NumKeywords, sizeof(char *),
+	if (!(attr & ATTR_ITALIC) &&
+		bsearch(, Keywords, NumKeywords, sizeof(char *),
 	compare_keywords))
 {
 	 /*
@@ -807,7 +808,8 @@
 	*keyptr = '\0';
 	keyptr  = keyword;
 
-	if (bsearch(, Keywords, NumKeywords, sizeof(char *),
+	if (!(attr & ATTR_ITALIC) &&
+		bsearch(, Keywords, NumKeywords, sizeof(char *),
 	compare_keywords))
 {
 	 /*
@@ -861,7 +863,8 @@
 	*keyptr = '\0';
 	keyptr  = keyword;
 
-	if (bsearch(, Keywords, NumKeywords, sizeof(char *),
+	if (!(attr & ATTR_ITALIC) &&
+		bsearch(, Keywords, NumKeywords, sizeof(char *),
 	compare_keywords))
 {
 	 /*

Bug#804582: (no subject)

[Barry Warsaw]

It's a locale problem.  This fixes most of the problems:

diff --git a/debian/rules b/debian/rules
index 9c04662..6130dc4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME=paramiko
+export PYBUILD_VERBOSE=1
+export DH_VERBOSE=1
 
 %:
dh $@ --with python2,python3 --buildsystem=pybuild
@@ -11,3 +13,12 @@ ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
 endif
dh_installdocs
 
+override_dh_auto_test:
+   mkdir -p $(CURDIR)/tmp-locales
+   localedef -i /usr/share/i18n/locales/en_US -c -f UTF-8 \
+ -A /usr/share/locale/locale.alias \
+ $(CURDIR)/tmp-locales/en_US.UTF-8
+   LOCPATH=$(CURDIR)/tmp-locales LC_ALL=en_US.UTF-8 \
+   dh_auto_test -- \
+   --system=custom \
+   --test-args='{interpreter} $(CURDIR)/test.py --verbose'


Unfortunately, I still have one last test I'm tracking down in python3.5
(python2.7 passes now):

==
FAIL: test_L_handshake_timeout (tests.test_transport.TransportTest)
--
Traceback (most recent call last):
  File "/<>/tests/test_transport.py", line 811, in 
test_L_handshake_timeout
password='pygmalion')
AssertionError: EOFError not raised by connect

Bug#806019: e17: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 806019 + patch
thanks

> dh_fixperms
> chmod 4755 debian/e17/usr/lib/enlightenment/utils/enlightenment_sys
> chmod: cannot access 
> 'debian/e17/usr/lib/enlightenment/utils/enlightenment_sys': No such file or 
> directory
> debian/rules:34: recipe for target 'override_dh_fixperms' failed
> make[1]: *** [override_dh_fixperms] Error 1

Explanation: We are creating arch-independent packages only, so
"debian/e17/[...]" does not exist because e17 is arch-dependent.

The trivial fix is to override dh_fixperms only for arch-dependent
packages.

The following patch (untested) might fix this.

Thanks.diff --git a/debian/rules b/debian/rules
index b413bbe..fdad802 100755
--- a/debian/rules
+++ b/debian/rules
@@ -30,7 +30,7 @@ override_dh_install:
rm debian/tmp/usr/share/enlightenment/COPYING
dh_install
 
-override_dh_fixperms:
+override_dh_fixperms-arch:
dh_fixperms
chmod 4755 debian/e17/usr/lib/enlightenment/utils/enlightenment_sys
chmod 4755 debian/e17/usr/lib/enlightenment/modules/cpufreq/*/freqset

Bug#820436: [Aptitude-devel] Bug#820436: www.debian.org: en and fr descriptions of APT::AutoRemove::RecommendsImportant in aptitude manual are inconsistent

[Axel Beckert]

Hi Adam,

Adam D. Barratt wrote:
> On Fri, 2016-04-08 at 19:26 +0200, Vincent Lefevre wrote:
> > On 2016-04-08 17:32:06 +0100, Adam D. Barratt wrote:
> > > Control: reassign -1 aptitude-doc-fr 0.7.8-1
> > > 
> > > [Full quote for aptitude maintainers]
> > 
> > It should also have been Cc'ed to the maintainers since the reassign
> > comes too late.
> 
> Indeed. I'm aware, I apparently forgot to do so on this occasion. Sorry,
> aptitude maintainers.

Was no problem at all. The bug's subject plus the old and new package
name made it obvious enough.

IIRC the French translation is only at the state of Aptitude 0.7.1
currently, i.e. could use an overhaul by some native French speaker.

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

Bug#806008: coq: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 806008 + patch
thanks

>debian/rules override_dh_install
> make[1]: Entering directory '/<>'
> dh_install --fail-missing
> cp debian/coq.xpm debian/coqide/usr/share/pixmaps/coqide.xpm
> cp: cannot create regular file 'debian/coqide/usr/share/pixmaps/coqide.xpm': 
> No such file or directory
> debian/rules:86: recipe for target 'override_dh_install' failed

Explanation: We are creating arch-independent packages only.

The "coqide" package is arch-dependent so debian/coqide/[...] does not exist.

The trivial fix is to override dh_install only for arch-dependent
packages.

The following patch (untested) might help.

Another option, since the file is very small, is to have a copy
at debian/coqide.xpm and add a suitable line to debian/coqide.install.

In this case override_dh_install could be dropped completely.


Thanks.diff --git a/debian/rules b/debian/rules
index 6343da5..3835e2e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -81,8 +81,8 @@ override_dh_auto_install:
find debian/tmp -name '*.vo' -printf '%P\n' \
  >> debian/coq-theories.install
 
-.PHONY: override_dh_install
-override_dh_install:
+.PHONY: override_dh_install-arch
+override_dh_install-arch:
dh_install --fail-missing
cp debian/coq.xpm debian/coqide/usr/share/pixmaps/coqide.xpm
 

Bug#820068: optipng: diff for NMU version 0.7.5-1.1

[Salvatore Bonaccorso]

Hi

The used patch took into account as well the fixed from upstream bugs
56 and 57, which correspond to CVE-2016-3981 and CVE-2016-3982. At the
time of writing those two CVEs were not yet assigned.

So once accepted into the archive, I will update as well the
information for those CVEs.

Regards,
Salvatore

Bug#820473: console-setup-linux: keyboard-setup.sh calls tools from /usr filesystem which isn't mounted yet

[Andriy Martynets]

Package: console-setup-linux
Version: 1.141
Severity: important

Dear Maintainer,
After latest system update (can't say for sure console-setup-linux or 
console-tools package was updated or both) keyboard-setup.sh started to fail at 
boot time.
The point is that the script calls /etc/console-setup/cached_setup_keyboard.sh 
which in turn calls kbd_mode (utility from console-tools package) located in 
/usr/bin directory.
The /usr filesystem isn't available at that stage as keyboard-setup.sh runs 
before mountall.sh.

I believe that tools required at boot time must be within the rootfs (/bin or 
/sbin directories) or order of the init scripts must be changed.

Thank you in advance,
Andriy Martynets


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

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

Versions of packages console-setup-linux depends on:
ii  console-tools   1:0.2.3dbs-70
ii  init-system-helpers 1.29
ii  initscripts 2.88dsf-59.3
ii  keyboard-configuration  1.141

console-setup-linux recommends no packages.

Versions of packages console-setup-linux suggests:
ii  console-setup  1.141

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.59
ii  liblocale-gettext-perl  1.07-1+b1

Versions of packages console-setup depends on:
ii  debconf 1.5.59
ii  keyboard-configuration  1.141
ii  xkb-data2.17-1

Versions of packages console-setup suggests:
ii  locales   2.22-5
ii  lsb-base  9.20160110

Versions of packages console-setup-linux is related to:
pn  console-common
pn  console-data  
ii  console-tools 1:0.2.3dbs-70
pn  gnome-control-center  
pn  kbd   
ii  systemd   229-3

-- debconf information:
  console-setup/use_system_font:
* keyboard-configuration/layoutcode: us,ua
* keyboard-configuration/toggle: Control+Shift
  console-setup/fontsize: 8x16
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/layout:
* keyboard-configuration/other:
  console-setup/charmap47: UTF-8
  console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
* keyboard-configuration/variant: Ukrainian
* keyboard-configuration/switch: No temporary switch
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/altgr: The default for the keyboard layout
* keyboard-configuration/xkb-keymap: ua
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/compose: No compose key
  console-setup/fontface47: Fixed
  keyboard-configuration/ctrl_alt_bksp: false
  console-setup/framebuffer_only:
  keyboard-configuration/unsupported_options: true
  console-setup/fontsize-fb47: 8x16
* keyboard-configuration/modelcode: pc105
  keyboard-configuration/unsupported_config_layout: true
* keyboard-configuration/optionscode: grp:ctrl_shift_toggle,grp_led:scroll
  keyboard-configuration/unsupported_layout: true
  console-setup/fontsize-text47: 8x16
  console-setup/codesetcode: Lat15
  keyboard-configuration/unsupported_config_options: true
* keyboard-configuration/model: Generic 105-key (Intl) PC
* keyboard-configuration/variantcode: ,
  console-setup/guess_font:

Bug#541157: RFP: vbam - Gameboy Advance emulator

[PICCORO McKAY Lenz]

i search on git commits some commit related to changes in this behavior file..
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com


2016-04-07 19:27 GMT-04:30 Sérgio Benjamim :
> Hi,
>
> I uploaded it again. The build is broken. Good luck
>
> https://mentors.debian.net/package/vbam
>
> src/gtk/screenarea.cpp: In constructor ‘VBA::ScreenArea::ScreenArea(int,
> int, int)’:
> src/gtk/screenarea.cpp:53:62: error: no matching function for call to
> ‘Gdk::Cursor::Cursor(,
> Glib::RefPtr&, int, int)’
>m_poEmptyCursor = new Gdk::Cursor(get_display, pixbuf, 0, 0);
>
>
> sergio-br2
>
>
> On 06/04/2016 17:54, PICCORO McKAY Lenz wrote:
>>
>> the package in mentors are now go..
>>
>> please reupload to mentors
>>
>> mentors must mantain the packages that already has a bug number
>> relationship and only erase those that are onlñy uploaded alone
>> without a itp or rfp bug related!
>>
>>
>> Lenz McKAY Gerardo (PICCORO)
>> http://qgqlochekone.blogspot.com
>
>

Bug#820471: RFA: javaparser -- Java library for parsing Java 1.5.

[Benjamin Mesing]

Package: wnpp
Severity: normal

I request an adopter for the javaparser package.

The new upstream version of javaparser has a whole bunch of maven 
dependencies. A lot of them are not yet packaged. Since I am lacking 
the time and are not particularly skilled with maven, I will not be able
to package javaparser myself.

An updated javaparser is a dependency for the new upstream version of 
umlet.

Best regards

Ben


The package description is:
 The library features abstract syntax tree (AST) generation and supports
 the visitor pattern. The AST records the source code structure, javadoc
 and comments. It is also possible to change the AST nodes or create new
 ones to modify the source code.
 .
 Main features are:
  * light weight
  * good performance
  * easy to use
  * AST can be modified
  * AST can be created from scratc

Bug#820472: audacious: A GTK2+ media player should really not depend on Qt 5

[Alf Gaida]

Package: audacious
Version: 3.7.2-1
Severity: normal

Hi,
audacious now depends on some Qt 5 stuff, introduced via audacious-plugins - is 
this really needed?
Maybe this bug fits better for audacious-plugins.

Cheers Alf

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (990, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (400, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages audacious depends on:
ii  audacious-plugins3.7.2-1
ii  dbus 1.10.8-1
ii  dbus-x11 1.10.8-1
ii  gtk2-engines-pixbuf  2.24.30-1.1
ii  libaudcore3  3.7.2-1
ii  libc62.22-5
ii  libgcc1  1:5.3.1-13
ii  libglib2.0-0 2.48.0-1
ii  libstdc++6   5.3.1-13

Versions of packages audacious recommends:
ii  unzip  6.0-20

audacious suggests no packages.

-- no debconf information

Bug#819019: fake-hwclock: allow the saved time to go backwards under normal use

[Roddy Shuler]

> What we *can* do is instead add an extra declaration of system time
> based on the build/release date of the particular version of the
> fake-hwclock package in use, and refuse to back to a date before
> *that* unless --force is used. How does that sound?

That sounds like a good policy in general, and it would solve my concerns.
Thanks!


On Fri, Apr 8, 2016 at 10:50 AM Steve McIntyre  wrote:

> [ Including a CC to Robie from the previous bug #763589... ]
>
> Hey guys,
>
> On Tue, Mar 22, 2016 at 11:37:56PM +, Roddy Shuler wrote:
> >Package: fake-hwclock
> >Version: 0.10
> >
> >On bug #763589, protection was added around the save operation so that the
> >saved time cannot go backwards without forcing.  While this clearly
> >mitigates the race condition of concern, I don't believe it is an
> >acceptable solution for normal users.
> >
> >Consider the following use case...
> >
> >1. The user accidentally sets a wrong time to a date in the future -- for
> >example, sets the year to 2017 rather than 2016
> >2. The fake-hwclock.data file is written with the future time
> >3. The user then realizes the mistake, and tries to fix the time back to
> >the year 2016
> >4. Now, the cron job and service will not update the fake-hwclock.data,
> >since it appears that the current system time is in the past (relative to
> >the invalid saved time)
> >5. On reboot, the clock reverts to the future date in the year 2017, and
> >continues to do so on every reboot for the next year (unless the user is
> >advanced enough to know to manually run the script with the force flag)
> >
> >Other than races on startup, the normal case is that the system time will
> >not go backwards unless it was intentionally changed (either by a user or
> >by an update from an NTP server), so I don't believe it makes sense to
> >reject such saves by default.  (The protection for loads, on the other
> >hand, is clearly needed.)
> >
> >For my specific use case, I simply reverted to the original behavior
> >without any protection against saving, but I suppose the upstream solution
> >would require an alternate solution to the race reported on #763589.
>
> Right.
>
> And in #763589 we have:
>
> >I've observed a system with a correctly working fake-hwclock
> >(originally initalised by NTP) set its time back to shortly after the
> >epoch, including in /etc/fake-hwclock.data.
> >
> >I believe this happened because "fake-hwclock save" was called after
> >boot before "fake-hwclock load" was called.
> >
> >I think this happens in the case of a very early shutdown event that
> >calls "/etc/init.d/rc 0" before "/etc/init.d/rcS" has completed.
> >
> >In my case, I have a Raspberry Pi rigged with an external shutdown
> >signal hooked up via udev. If the signal is "high" at boot time, then
> >the Pi shuts down without fully booting up.
> >
> >I'm not entirely sure that this is the cause, but the race is there.
>
> We have two conflicting requirements here, I think. Thanks for
> explaining your logic, both of you.
>
> The problem is that I don't think there's a good solution to both
> problems here. We can't *know* that the system time has been read from
> fake-hwclock.data before calling "save". I briefly considered adding a
> "I've seen this" flag that could be set in "load", but that's no
> guarantee at all - if we power down unexpectedly then it'll be set
> already at next boot.
>
> What we *can* do is instead add an extra declaration of system time
> based on the build/release date of the particular version of the
> fake-hwclock package in use, and refuse to back to a date before
> *that* unless --force is used. How does that sound?
>
> Or can you think of any other possible fixes here?
>
> [ I've also just realised that I'll need to go back and re-add
>   initramfs support now that we automatically attempt to mount and
>   fsck /usr in the initramfs. Joy \o/ ]
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> "I suspect most samba developers are already technically insane... Of
>  course, since many of them are Australians, you can't tell." -- Linus
> Torvalds
>
> --


*Roddy Shuler*  |  +1.585.530.7960  |  Endless

Bug#806001: c-icap-modules: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

tags 806001 + patch
thanks

> dh_fixperms
> # config permissions
> chmod 0644 debian/libc-icap-mod-virus-scan/etc/c-icap/*
> chmod: cannot access 'debian/libc-icap-mod-virus-scan/etc/c-icap/*': No such 
> file or directory
> debian/rules:33: recipe for target 'override_dh_fixperms' failed

Explanation: We are creating arch-independent packages only, so
debian/libc-icap-mod-virus-scan does not exist because
libc-icap-mod-virus-scan is arch-dependent.

The trivial fix is to override dh_fixperms only for arch-dependent packages,
as in the attached patch.

Thanks.diff --git a/debian/rules b/debian/rules
index 62d2f4a..7571fda 100755
--- a/debian/rules
+++ b/debian/rules
@@ -40,7 +40,7 @@ override_dh_install:
rm debian/tmp/usr/lib/*/c_icap/*.la
dh_install --fail-missing
 
-override_dh_fixperms:
+override_dh_fixperms-arch:
dh_fixperms
# config permissions
chmod 0644 debian/libc-icap-mod-virus-scan/etc/c-icap/*

Bug#820470: ntp: upstream version ntp-4.2.8p6

[Nicholas Luedtke]

Package: ntp
Version: 1:4.2.8p4+dfsg-3
Severity: wishlist

Dear Maintainer,

NTP version ntp-4.2.8p6 is available upstream and includes fixes for 9
CVE's listed below. Though they are mostly minor the cumulative effect
of removing these from our stream would be beneficial. We should
consider updating ntp in sid/stretch to incorporate these security fixes.

http://support.ntp.org/bin/view/Main/SecurityNotice#Recent_Vulnerabilities

CVEs listed as fixed in upstream:
CVE-2015-8158: Potential Infinite Loop in ntpq
CVE-2015-8138: origin: Zero Origin Timestamp Bypass
CVE-2015-7979: Off-path Denial of Service (DoS) attack on authenticated
broadcast mode
CVE-2015-7978: Stack exhaustion in recursive traversal of restriction list
CVE-2015-7977: reslist NULL pointer dereference
CVE-2015-7976: ntpq saveconfig command allows dangerous characters in
filenames
CVE-2015-7975: nextvar() missing length check
CVE-2015-7974: Skeleton Key: Missing key check allows impersonation
between authenticated peers
CVE-2015-7973: Deja Vu: Replay attack on authenticated broadcast mode


-- 
Nicholas Luedtke
HPE Linux, Hewlett-Packard Enterprise



signature.asc
Description: OpenPGP digital signature