Bug#905738: qml-module-qtquick-controls2: incorrect dependencies due to pkg-kde-tools bug #905736

2018-08-08 Thread Andreas Ferber 
Package: qml-module-qtquick-controls2
Version: 5.11.1-2
Severity: normal
Control: block -1 by 905736

Hi,

this package is affected by bug #905736 in pkg-kde-tools, which leads to
incorrect dependencies in the qml-module-qtquick-controls2 and
qml-module-qt-labs-calendar binary packages. Please see the other bug
report for details.

After the bug has been fixed in pkg-kde-tools, the build-dependency on
it should be bumped to the fixed version and the package rebuilt in
order to fix the dependencies.

As a workaround you could temporarily drop the ${qmlc:Depends} and add
the necessary libqt5qml5 dependencies manually.

Regards,
Andreas Ferber

Bug#905736: pkg-kde-tools: dh_qmlcdeps fails to process all packages

2018-08-08 Thread Andreas Ferber 
Package: pkg-kde-tools
Version: 0.15.29
Severity: important
Tags: patch

Hi,

while making local backports of Qt5 for Debian stable, I noticed the
following messages in one of the build logs (the one for
qtquickcontrol2-opensource-src to be precise):

--
dpkg-gencontrol: warning: Depends field of package 
qml-module-qtquick-controls2: unknown substitution variable ${qmlc:Depends}
dpkg-gencontrol: warning: Depends field of package 
qml-module-qtquick-controls2: unknown substitution variable ${qmlc:Depends}
dpkg-gencontrol: warning: Depends field of package qml-module-qt-labs-calendar: 
unknown substitution variable ${qmlc:Depends}
dpkg-gencontrol: warning: Depends field of package qml-module-qt-labs-calendar: 
unknown substitution variable ${qmlc:Depends}
--

Checking against the logs from the Debian buildds showed that they were
also present there, so it wasn't just an artifact of my backporting.
What was strange about the messages was that the package in question
actually contains .qmlc files and correctly calls dh_qmlcdeps, so the
variables really should have been set.

Further investigation showed that there is a serious bug in dh_qmlcdeps
that makes it stop processing as soon as it encounters the first binary
package without any .qmlc files. Within the main loop over all packages,
right after the find, in line 79 there is a check if any $qt_version_bin
has been found while searching for .qmlc files, and it just exit()s when
there wasn't any:

--
$qt_version_bin or exit(0);
--

The attached patch fixes that by just continuing with the next loop
iteration instead of exiting.

What makes this bug important (I actually contemplated calling it
"serious") is that all binary packages built with the buggy dh_qmlcdeps
(the bug existed right from when it was introduced in version 0.15.26)
now potentially contain incorrect dependencies, and might have to be
rebuilt.

Affected packages should all have similar warnings to the above in their
respective build logs though, so there might be some way to check for
packages needing a rebuild. I don't know enough about the buildd
infrastructure, so I can't tell if there's a way to do what's
essentially a large-scale grep across all build logs.

Regards,
Andreas Ferber
>From c19dca9669ec21358793c38699be95cb528fe0a6 Mon Sep 17 00:00:00 2001
From: Andreas Ferber 
Date: Wed, 8 Aug 2018 20:44:44 +0200
Subject: [PATCH] dh_qmlcdeps: don't exit on first package without qmlc files.

---
 dh_qmlcdeps | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dh_qmlcdeps b/dh_qmlcdeps
index 0b86df4..59b2de6 100755
--- a/dh_qmlcdeps
+++ b/dh_qmlcdeps
@@ -75,7 +75,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 }
 }, $tmpdir);
 
-$qt_version_bin or exit(0);
+$qt_version_bin or next;
 my @qt_version = unpack("C4", $qt_version_bin);
 my $qt_version_str = "$qt_version[2].$qt_version[1].$qt_version[0]";
 $qt_version[2] == 5 or error("Qt version $qt_version_str is not 
supported");
-- 
2.11.0

Bug#905660: qtbase-opensource-src: build-depend on libharfbuzz-dev (>= 1.6.0~)

2018-08-07 Thread Andreas Ferber 
Source: qtbase-opensource-src
Version: 5.11.1+dfsg-6
Severity: wishlist

Hi,

according to src/gui/configure.json, it needs HarfBuzz to be at least
version 1.6.0:

-
"harfbuzz": {
"label": "HarfBuzz",
"test": {
"include": "harfbuzz/hb.h",
"tail": [
"#if !HB_VERSION_ATLEAST(1, 6, 0)",
"#  error This version of harfbuzz is too old.",
"#endif"
],
-

Therefore, the build dependency on libharfbuzz-dev should be bumped to
(>= 1.6.0~).

Regards,
Andreas Ferber

Bug#905658: qtwebengine-opensource-src: build-depend on libvpx-dev (>= 1.7.0~)

2018-08-07 Thread Andreas Ferber 
Source: qtwebengine-opensource-src
Version: 5.11.1+dfsg-5
Severity: wishlist

Hi,

when building on stretch it fails in the configure stage due to not
finding a suitable libvpx (the version 1.6.1 from stretch is to old), it
works however with a backport of libvpx 1.7.0 from unstable, therefore
the build-dependency on libvpx-dev should be bumped to (>= 1.7.0~).

As suggested, now with priority wishlist :-)

Regards,
Andreas Ferber

Bug#905596: qtwebengine-opensource-src: build error with libicu-dev from stable

2018-08-06 Thread Andreas Ferber 
Source: qtwebengine-opensource-src
Version: 5.11.1+dfsg-5
Severity: normal

Hi,

when building the package on stable (plus various backports), I got the
following error:

--
../../3rdparty/chromium/components/url_formatter/idn_spoof_checker.cc: In 
member function 'bool 
url_formatter::IDNSpoofChecker::SimilarToTopDomains(base::StringPiece16)':
../../3rdparty/chromium/components/url_formatter/idn_spoof_checker.cc:321:42: 
error: invalid conversion from 'UChar* {aka short unsigned int*}' to 
'char16_t*' [-fpermissive]
 char16_t* buffer = host_alt.getBuffer(-1);
~~^~~~
--

Between icu versions 57 (stable) and 60 (testing/unstable), there was a
change in the data type returned by the getBuffer method of
icu::UnicodeString.

This can either be fixed with the attached patch (note that a similar
reinterpret_cast<>() as introduced by the patch is done in a bunch of
other places within chromium where icu::UnicodeString is used), or you
should bump the libicu-dev build dependency to (>= 59), as icu 59 was
the upstream version that introduced the change.

Regards,
Andreas Ferber
--- a/src/3rdparty/chromium/components/url_formatter/idn_spoof_checker.cc
+++ b/src/3rdparty/chromium/components/url_formatter/idn_spoof_checker.cc
@@ -318,7 +318,7 @@
   if ((u04cf_pos = host.indexOf(0x4CF)) != -1) {
 icu::UnicodeString host_alt(host);
 size_t length = host_alt.length();
-char16_t* buffer = host_alt.getBuffer(-1);
+char16_t* buffer = reinterpret_cast(host_alt.getBuffer(-1));
 for (char16_t* uc = buffer + u04cf_pos ; uc < buffer + length; ++uc) {
   if (*uc == 0x4CF)
 *uc = 0x6C;  // Lowercase L

Bug#905595: qtwebengine-opensource-src: libav* build-dependencies should be (>= 7:3.3.2)

2018-08-06 Thread Andreas Ferber 
Source: qtwebengine-opensource-src
Version: 5.11.1+dfsg-5
Severity: normal

Hi,

when trying to build the package on stretch (with various backports), it
fails with the following error:

--
../../3rdparty/chromium/media/ffmpeg/ffmpeg_common.cc: In function 
'media::VideoCodec media::CodecIDToVideoCodec(AVCodecID)':
../../3rdparty/chromium/media/ffmpeg/ffmpeg_common.cc:192:10: error: 
'AV_CODEC_ID_AV1' was not declared in this scope
 case AV_CODEC_ID_AV1:
  ^~~
../../3rdparty/chromium/media/ffmpeg/ffmpeg_common.cc: In function 'AVCodecID 
media::VideoCodecToCodecID(media::VideoCodec)':
../../3rdparty/chromium/media/ffmpeg/ffmpeg_common.cc:217:14: error: 
'AV_CODEC_ID_AV1' was not declared in this scope
   return AV_CODEC_ID_AV1;
  ^~~
--

Looking at the git history of the ffmpeg debian package showed that the
first version containing the missing definition is version 7:3.3.2-1,
even though the FFmpeg upstream changelog itself first mentions AV1
support for version 4.0. This seems to be somewhat confirmed by the fact
that building against the FFmpeg packages from deb-multimedia.org (based
on FFmpeg 3.3.8) works.

Therefore I think the build-dependencies on libavcodec-dev,
libavformat-dev and libavutil-dev should be bumped to (>= 7:3.3.2)

Regards,
Andreas Ferber

Bug#905537: Should require LLVM >=3.9

2018-08-05 Thread Andreas Ferber 
Source: qttools-opensource-src
Version: 5.11.1-3
Severity: normal

Hi,

when trying to build the package on Debian Stable (plus various other
backports of course), it fails, with the important message being:

-
LLVM/Clang version >= 3.9.0 required, version provided: 3.8.1.
Clang was found in /usr/lib/llvm-3.8. Set the LLVM_INSTALL_DIR
environment variable to override.
-

I think the LLVM build dependencies (libclang-dev, llvm-dev) should
therefore be versioned with (>= 3.9).

Regards,
Andreas Ferber

Bug#900533: chromium 67.0.3396.62-1: youtube video, gif's, html5, and movies no longer work

2018-07-25 Thread Andreas Ferber 
On Tue, 24 Jul 2018 09:43:01 +0100 Phil Wyett  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Tue, 2018-07-24 at 11:21 +0300, Alex Berg wrote:
> > I confirm this bug in release 67.0.3396.87-1
> > 
> > youtube video worked
> > but html5, and movies no longer work
> > 
> > Install the older version from stable (stretch) - all worked fine
> > 
> 
> Could you provide an example of what doe snot work.

Please read the Bug log, there have been examples given already (for
example the dailymotion link by Michael Wyraz.

It's quite frankly embarassing that this bug hasn't been fixed for the
STABLE distribution almost four weeks after it has been introduced by
a security update, and the maintainer appears to not even understand
where the problem is.

I have several machines now where the chromium package is being held
back manually even though it has known security bugs, since the
current up-to-date version is unusable.

Regards,
Andreas Ferber

Bug#851819: Flash-plugin not getting updated

2017-02-08 Thread Andreas Ferber 
tag 851819 security
thanks

Hi,

I'm tagging this bug as security, since this poses a serious security
issue for people having this package installed.

Nearly A MONTH after Adobe released a critical security update, users
STILL will not get any update for their flash plugin.

This has happened multiple times in the recent past, please either
find a way to keep this up-to-date in a timely fashion, or remove this
package completely (from stable as well!). 

Regards,
Andreas Ferber

Bug#823005: pepperflashplugin-nonfree: Missing PGP key

2016-04-29 Thread Andreas Ferber 
Package: pepperflashplugin-nonfree
Version: 1.8.1
Severity: grave
Justification: renders package unusable

Hi,

Google apparently started using a new PGP key, which leads to:

# update-pepperflashplugin-nonfree --install
ERROR: failed to retrieve status information from google : W: There is no 
public key available for the following key IDs:
A040830F7FAC5991
More information might be available at:
  http://wiki.debian.org/PepperFlashPlayer

I tried updating to 1.8.2, no change.

Appending the new key to /usr/lib/pepperflashplugin-nonfree/pubkey-google.txt
solves the problem for me. The old key seems to still be needed, since
with only the new key ih pubkey-google.txt I'm getting the same error
with a different key id.

Regards,
Andreas

-- System Information:
Debian Release: 8.4
  APT prefers stable
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages pepperflashplugin-nonfree depends on:
ii  binutils2.25-5
ii  ca-certificates 20141019+deb8u1
ii  cdebconf [debconf-2.0]  0.192
ii  debconf [debconf-2.0]   1.5.56
ii  gnupg   1.4.18-7+deb8u1
ii  libatk1.0-0 2.14.0-1
ii  libcairo2   1.14.0-2.1+deb8u1
ii  libcurl3-gnutls 7.38.0-4+deb8u3
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.5.2-3+deb8u1
ii  libgcc1 1:4.9.2-10
ii  libglib2.0-02.42.1-1+b1
ii  libgtk2.0-0 2.24.25-3+deb8u1
ii  libnspr42:4.10.7-1+deb8u1
ii  libnss3 2:3.17.2-1.1+deb8u2
ii  libpango-1.0-0  1.36.8-3
ii  libpango1.0-0   1.36.8-3
ii  libstdc++6  4.9.2-10
ii  libx11-62:1.6.2-3
ii  libxext62:1.3.3-1
ii  libxt6  1:1.1.4-1+b1
ii  wget1.16-1

pepperflashplugin-nonfree recommends no packages.

Versions of packages pepperflashplugin-nonfree suggests:
ii  chromium   50.0.2661.75-1~deb8u1
pn  hal
ii  ttf-dejavu 2.34-1
ii  ttf-mscorefonts-installer  3.6
ii  ttf-xfree86-nonfree4.2.1-4

-- no debconf information

Bug#751936: Acknowledgement (php5: Segfault in highlight_string()/highlight_file() when pgsql module loaded)

2014-06-23 Thread Andreas Ferber 
Hi,

just a heads up, the fix I made for this bug has been accepted
upstream, see 
http://git.php.net/?p=php-src.git;a=commit;h=c5e6c2a5f58be770603b490d23384b5fc66a38f6

It didn't make it in time for the PHP 5.6.0RC1 release, however it
should be in RC2.

Regards,
Andreas Ferber


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751936: [php-maint] Bug#751936: php5: Segfault in highlight_string()/highlight_file() when pgsql module loaded

2014-06-18 Thread Andreas Ferber 
On Wed, Jun 18, 2014 at 11:56:29AM +0200, Ondřej Surý wrote:
> could you please report this bug to upstream bugzilla? (And add the link
> here?)

Yes, I have done so.

Today I also had the time to reproduce the bug successfully using a
build of the current upstream snapshot, so it is definitely an
upstream problem.

The link to the upstream bug report:

https://bugs.php.net/bug.php?id=67468

Regards,
Andreas Ferber


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751936: php5: Segfault in highlight_string()/highlight_file() when pgsql module loaded

2014-06-17 Thread Andreas Ferber 
Package: php5, php5-cli, libapache2-mod-php5, php5-pgsql
Version: 5.6.0~beta4+dfsg-3
Severity: important

Hi,

I encountered a segmentation fault that is triggered when syntax highlighting
php source containing '__CLASS__' using the highlight_file() or
highlight_string() functions while having the pgsql.so module loaded.

To reproduce, install and enable the pgsql.so module and run the
following script (also attached as 'test.php'):

-- test.php --

--

(Note that it doesn't have anything to do with the fact that the
__CLASS__ is used outside of any class scope here, I originally
encountered the bug with a much longer script that had the __CLASS__
properly within a class)

Even though highlight_string()/highlight_file() might be considered
minor PHP functionality, I'm setting the severity to "important" since
the problem seriously hampers development (or makes it outright
impossible) using for example the popular Symfony php framework. Symfony
uses highlight_*() extensively to provide for example more friendly
exception outputs during development, so having your apache child always
dying with a segfault when encountering an error instead of displaying
the error with backtrace etc. is a real problem.


Backtrace of the Segfault:

#0  _zend_mm_free_int (heap=0x7fee5d9ed048, p=0x7fee5d9ed058)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/Zend/zend_alloc.c:2104
#1  0x006c68b8 in zend_highlight (
syntax_highlighter_ini=syntax_highlighter_ini@entry=0x7fff5203eaa0)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/Zend/zend_highlight.c:153
#2  0x0069d865 in highlight_string (str=0x7fff5203e980, 
syntax_highlighter_ini=syntax_highlighter_ini@entry=0x7fff5203eaa0, 
str_name=str_name@entry=0x7fee5db28280 "/home/sunshine/php-bug/test.php(6) 
: highlighted code")
at Zend/zend_language_scanner.l:818
#3  0x005fafa9 in zif_highlight_string (ht=, 
return_value=0x7fee5db267b8, 
return_value_ptr=, this_ptr=, 
return_value_used=)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/ext/standard/basic_functions.c:5268
#4  0x006c2c4a in dtrace_execute_internal (execute_data_ptr=, 
fci=, return_value_used=)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/Zend/zend_dtrace.c:97
#5  0x0077cdd8 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7fee5daf00f8)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/Zend/zend_vm_execute.h:560
#6  0x0070e410 in execute_ex (execute_data=0x7fee5daf00f8)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/Zend/zend_vm_execute.h:363
#7  0x006c2b08 in dtrace_execute_ex (execute_data=0x7fee5daf00f8)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/Zend/zend_dtrace.c:73
#8  0x006d4dc0 in zend_execute_scripts (type=1570689096, type@entry=8, 
retval=0x7fee5d9ed058, retval@entry=0x0, file_count=1570796536, 
file_count@entry=3)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/Zend/zend.c:1330
#9  0x00673fdb in php_execute_script (primary_file=0x7fff52041140)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/main/main.c:2584
#10 0x0077ed3d in do_cli (argc=1570689096, argv=0x7fee5d9ed058)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/sapi/cli/php_cli.c:994
#11 0x004620ea in main (argc=1570689096, argv=0x7fee5d9ed058)
at /tmp/buildd/php5-5.6.0~beta4+dfsg/sapi/cli/php_cli.c:1378

Please see the attached file for a "backtrace full". If necessary, I can
also provide a core dump.


Observations during investigating the problem:

 * The segfault only happens if the pgsql.so module is loaded. I tested
   different combinations of the PHP modules on my system, only the
   pgsql.so makes a difference. Whether any other modules are loaded or
   not doesn't affect the problem.

 * It happens with both the CLI and the Apache2 SAPI. I didn't test any
   other SAPIs, however they are probably affected as well.

 * The problem doesn't exist in package version 5.5.12+dfsg-2, however
   it is already present in 5.6.0~beta3+dfsg-2. No other versions
   tested.

 * The segfault happens right after outputting the '__CLASS__' token
   itself.

 * It is only triggered by '__CLASS__', other internal constants like
   '__FILE__' or '__LINE__' are fine.

Regards,
Andreas Ferber

-- Package-specific info:
 Additional PHP 5 information 

 PHP 5 SAPI (php5query -S): 
apache2
cgi
cli

 PHP 5 Extensions (php5query -M -v): 
pgsql (Enabled for apache2 by maintainer script)
pgsql (Enabled for cgi by maintainer script)
pgsql (Enabled for cli by maintainer script)

 Configuration files: 
[PHP]
engine = On
short_open_tag = Off
asp_tags = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = 17
disable_functions =
disable_classes =
zend.enable_gc = On
expose_php = On
max_execution_time = 30
max_input_time = 60
memory_limit =

Bug#729834: python-redis: Please update to new upstream version 2.8.0

2013-11-17 Thread Andreas Ferber 
Package: python-redis
Version: 2.4.13-1
Severity: normal

Please update the package to the current upstream version 2.8.0.

The version of python-redis even in unstable is very outdated, the
current upstream version is 2.8.0. In particular, with the packaged
version 2.4.x you can't access the script eval features of the redis
server.

-- System Information:
Debian Release: 7.2
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-redis depends on:
ii  python  2.7.5-5
ii  python-support  1.0.15

python-redis recommends no packages.

python-redis suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#595311: openssh-client: untrusted X11 forwarding broken

2010-09-02 Thread Andreas Ferber 
Package: openssh-client
Version: 1:5.5p1-4
Severity: important

After upgrading my system to testing, X11 forwarding in ssh stopped
working. When trying to open a connection with untrusted X11 forwarding,
the following happens:

---
% ssh -X sirius6
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
% echo $DISPLAY
localhost:10.0
% xterm
Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: localhost:10.0
---

However TRUSTED X11 forwarding (-Y) works as expected.

Debug output doesn't reveal anything, ssh is calling the correct xauth
binary, however somehow the remote side doesn't get a valid cookie.

Andreas

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (650, 'testing'), (550, 'stable'), (120, 'unstable'), (99, 
'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages openssh-client depends on:
ii  adduser   3.112  add and remove users and groups
ii  cdebconf [debconf-2.0 0.150  Debian Configuration Management Sy
ii  debconf [debconf-2.0] 1.5.35 Debian configuration management sy
ii  dpkg  1.15.7.2   Debian package management system
ii  libc6 2.11.2-2   Embedded GNU C Library: Shared lib
ii  libedit2  2.11-20080614-1BSD editline and history libraries
ii  libgssapi-krb5-2  1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries - k
ii  libssl0.9.8   0.9.8o-2   SSL shared libraries
ii  passwd1:4.1.4.2-1change and administer password and
ii  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

Versions of packages openssh-client recommends:
ii  openssh-blacklist 0.4.1  list of default blacklisted OpenSS
ii  openssh-blacklist-extra   0.4.1  list of non-default blacklisted Op
ii  xauth 1:1.0.4-1  X authentication utility

Versions of packages openssh-client suggests:
ii  keychain 2.6.8-2 key manager for OpenSSH
ii  ksshaskpass [ssh-askpass]0.5.3-1 interactively prompt users for a p
pn  libpam-ssh (no description available)
ii  ssh-askpass  1:1.2.4.1-9 under X, asks user for a passphras
ii  ssh-askpass-gnome [ssh-askpa 1:5.5p1-4   interactive X program to prompt us

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#545535: boost1.39: Parallel build fails

2009-09-07 Thread Andreas Ferber 
Package: boost1.39
Version: 1.39.0-4
Severity: normal

Hi,

when doing a parallel build (make -j6 in my case), it failed during the
install stage because it tried to install some libraries into /lib,
which since I'm building with fakeroot, it didn't have the permissions
to do so.

The problem is caused by a missing make dependency in debian/rules, the
"$(bjam)" target should depend on "$(QUILT_STAMPFN)", just as the
build-stamp target does. This missing dependency leads to a race
condition, where "./bootstrap.sh" might be called before the patch in
debian/patches/bootstrap.patch is applied.

Since the patch fixes the problem that bootstrap.sh uses the wrong
variable to set LIBDIR, it leads to a wrong libdir setting in
project-config.jam, which in turn leads to the failure on "install".

Adding the dependency fixed the problem for me.

Andreas

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (650, 'stable'), (150, 'testing'), (120, 'unstable'), (101, 
'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.30-bpo.1-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#520492: gimp-plugin-registry: Build-Dependency on liblqr-1-0-dev needs to be versioned

2009-03-20 Thread Andreas Ferber 
Package: gimp-plugin-registry
Version: 2.0-1
Severity: minor

Hi,

While backporting the package to lenny for myself (I already backported
gimp), the configure script reported an error because it needs liblqr to
be at least version 0.3.0. I think this should be reflected in the build
dependencies.

Andreas



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#469044: libphp-serialization-perl: specifies DH compat version 6 but depends only on version 5

2008-03-02 Thread Andreas Ferber 
Source: libphp-serialization-perl
Version: 0.27-1

Hi,

when backporting the package to etch for myself, I noticed that the
package specifies a debhelper compat version (in debian/compat) of "6",
however it Build-Depends only on debhelper version 5 upwards.

Andreas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400995: php5-cli: Sometimes doesn't flush output on exit

2006-11-29 Thread Andreas Ferber 
Package: php5-cli
Version: 5.2.0-7
Severity: important

Hi,

in some cases it seems that the CLI php doesn't flush its output when
the script exits and output is not connected to a terminal (thus not
line buffered).

Unfortunately, until now I haven't been able to find a small script that
reproduces the problem. The case I stumbled upon happens with the
testsuite of the symfony php framework. To reproduce it, please follow
these steps:

1. check out symfony from symfony svn:
% svn co http://svn.symfony-project.com/trunk symfony
2. change into the freshly checked out symfony directory and run
% php5 ./test/functional/crudTest.php | tee /dev/null
3. to see how the correct output should be (modulo some colorization),
   remove the "| tee /dev/null" from the previous command

If the testsuite is modified to call flush() on exit, the output isn't
truncated anymore.

I'm pretty sure that symfony itself doesn't disable output flushing
itself (no output buffering etc. involved, plus it works with php
5.1.6).

Andreas

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (650, 'testing'), (250, 'unstable'), (200, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18.2-skas3-toshiba
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages php5-cli depends on:
ii  libbz2-1 1.0.3-6 high-quality block-sorting file co
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  libcomer 1.39+1.40-WIP-2006.11.14+dfsg-1 common error description library
ii  libdb4.4 4.4.20-8Berkeley v4.4 Database Libraries [
ii  libkrb53 1.4.4-4 MIT Kerberos runtime libraries
ii  libmagic 4.17-4  File type determination library us
ii  libncurs 5.5-5   Shared libraries for terminal hand
ii  libpcre3 6.7-1   Perl 5 Compatible Regular Expressi
ii  libssl0. 0.9.8c-3SSL shared libraries
ii  libxml2  2.6.27.dfsg-1   GNOME XML library
ii  mime-sup 3.37-1  MIME files 'mime.types' & 'mailcap
ii  php5-com 5.2.0-7 Common files for packages built fr
ii  ucf  2.0017  Update Configuration File: preserv
ii  zlib1g   1:1.2.3-13  compression library - runtime

php5-cli recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#388436: pdnsd isn't started yet when init script ends

2006-11-03 Thread Andreas Ferber 
Package: pdnsd
Version: 1.2.4par-0.2
Followup-For: Bug #388436

Hello everyone,

the problem might be related to the problem I'm having. I'm using
pdnsd as DNS proxy and resolvconf to automatically set DNS servers
learned via DHCP as upstream servers for pdnsd.

During system boot, there is a race condition. When pdnsd is starting,
it forks into the background as a daemon and then needs some time before
it starts answering requests (including control requests via pdnsd-ctl).
Since the init script doesn't wait until pdnsd has been fully started,
it might happen that the resolvconf init script runs before pdnsd has
started answering and thus resolvconf fails to add upstream DNS servers
to pdnsd.

The obvious solution is for the init script to wait until pdnsd starts
answering (the delay is normally only a fraction of a second, even on a
slow system, but it's enough to cause the trouble). Attached is a patch
that does just that.

Andreas

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (650, 'testing'), (250, 'unstable'), (200, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.18-skas3-v8.2-toshiba
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages pdnsd depends on:
ii  adduser  3.99Add and remove users and groups
ii  libc62.3.6.ds1-4 GNU C Library: Shared libraries

pdnsd recommends no packages.

-- no debconf information
--- pdnsd.dpkg-dist 2006-10-12 08:35:53.0 +0200
+++ pdnsd   2006-04-29 11:25:49.0 +0200
@@ -38,6 +38,21 @@
return 0
 }
 
+start_wait()
+{
+   for f in `seq 1 60`; do
+   sleep 0.1
+   if pdnsd-ctl status >/dev/null 2>&1; then
+   break
+   fi
+   done
+   if pdnsd-ctl status >/dev/null 2>&1; then
+   return 0
+   else
+   return 1
+   fi
+}
+
 start()
 {
# Return
@@ -48,6 +63,7 @@
start-stop-daemon --start --quiet --pidfile "$PIDFILE" --exec "$DAEMON" 
-- \
--daemon -p "$PIDFILE" $START_OPTIONS \
|| return 2
+   start_wait || return 2
 }
 
 start_resolvconf()

Bug#389878: dosemu: Some keys are wrong under X

2006-10-29 Thread Andreas Ferber 
Good news, everyone,

this is related to bug #394318 (xserver-xorg-core: XkbGetKeyboard() is
broken), which prevents dosemu from using the Xkb keyboard map to
configure its keyboard mapping and forcing it to fall back to the
non-Xkb way of doing things.

However, this should not lead to failure of the keyboard mapping, so
dosemu itself seems to have some bug in the non-Xkb keyboard mapping
code. Unfortunately, I don't know enough about the X API to provide
any more insight into this.

Interestingly, there seems to be some difference between the testing
(1.2.2-5) and experimental (1.3.3-1) versions. The testing version
wrongly maps the "3"-key as "u" for me, whereas the experimental
version gets this particular key right. Other keys however are the
same in both versions.

Andreas
-- 
Andreas Ferber  | MarcanT Internet-Services GmbH
| Ravensberger Str. 10G
| D-33602 Bielefeld
[EMAIL PROTECTED] | <http://www.marcant.net/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364649: dokuwiki: postrm fails if /etc/apache2/httpd.conf empty

2006-04-24 Thread Andreas Ferber 
Package: dokuwiki
Version: 0.0.20050922-4
Severity: normal

Hi,

If the file /etc/apache2/httpd.conf is empty (or contains only the
dokuwiki include line), the following line in
the postrm script makes the script fail:

# Remove the Include directive
grep -v '^Include /etc/dokuwiki/apache.conf$' /etc/$srv/httpd.conf > $tfile

Since grep doesn't output any lines, it exits with an error. Since the
script is running with the -e option, this makes the whole script
fail.

To fix it, simply add " || true" to the end of the line.

Andreas

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (150, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.14.4-squashfs-toshiba
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages dokuwiki depends on:
ii  debconf [debconf-2.0]1.4.30.13   Debian configuration management sy
ii  php4 4:4.3.10-16 server-side, HTML-embedded scripti
ii  ucf  1.17Update Configuration File: preserv

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#349391: tiger: Make deb_* checks configurable

2006-01-22 Thread Andreas Ferber 
Package: tiger
Version: 1:3.2.1-24
Severity: wishlist

Hi,

I'm running tiger on a system with prelink. Since prelink modifies
almost all binaries on the system on a regular basis, the
deb_checkmd5sums check is pretty much useless for me, therefore it
would be nice if it could be disabled in /etc/tiger/tigerrc.

I'm aware that the presence of prelink somewhat reduces the value of
tiger, but there are still many other checks that make it useful.

Andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#345693: kdemultimedia: superfluous build-dependency on libxaw8-dev

2006-01-02 Thread Andreas Ferber 
Package: kdemultimedia
Version: 3.5.0-1
Severity: normal
Tags: experimental

Hello there,

while doing a backport of KDE 3.5.0 to Sarge, I came across the
build-depency on libxaw8-dev. Wondering what it was about, I did a
grep in the source tree for Xaw, and found that the only places it is
still mentioned are in some comments.

% grep -ri xaw .
Binary file ./doc/artsbuilder/index.cache.bz2 matches
./admin/acinclude.m4.in:# Check for libraries that X11R6 Xt/Xaw programs need.
./configure:# Check for libraries that X11R6 Xt/Xaw programs need.
./noatun/modules/kjofol-skin/kjloader.cpp:
NET::WMState|NET::XAWMState|NET::WMDesktop);
./acinclude.m4:# Check for libraries that X11R6 Xt/Xaw programs need.
./debian/changelog:default Xaw, Ncurses, and Slang.

Checking the changelog it seems that the depency is left over from the
KDE 2.x days, dutifully updated with each new Xaw version ;-)

AFAICS the dependency can simply be dropped, saving backporters one
minor stumbling block.

Andreas

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (150, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.14.4-squashfs-toshiba
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]