Bug#699253: libcitygml: FTBFS: dh_install: openscenegraph-plugin-citygml-shared missing files (usr/lib/osgPlugins-*/*.so), aborting
Control: tags -1 patch On 2013-01-29 16:13:20, Lucas Nussbaum wrote: > Source: libcitygml > Version: 0.14+svn128-1+3p0p1 > Severity: serious > Tags: wheezy sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20130129 qa-ftbfs > Justification: FTBFS in wheezy on amd64 > > Hi, > > During a rebuild of all packages in *wheezy*, your package failed to > build on amd64. > > Relevant part: > > make[2]: Entering directory > > `/«BUILDDIR»/libcitygml-0.14+svn128/obj-x86_64-linux-gnu' > > make[2]: Nothing to be done for `preinstall'. > > make[2]: Leaving directory > > `/«BUILDDIR»/libcitygml-0.14+svn128/obj-x86_64-linux-gnu' > > Install the project... > > /usr/bin/cmake -P cmake_install.cmake > > -- Install configuration: "" > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/lib/x86_64-linux-gnu/libcitygml.so.0.0.0 > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/lib/x86_64-linux-gnu/libcitygml.so.0 > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/lib/x86_64-linux-gnu/libcitygml.so > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/lib/x86_64-linux-gnu/libcitygml.a > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/include/citygml.h > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/include/vecs.h > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/citygml.pc > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/bin/citygml2vrml > > -- Removed runtime path from > > "/«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/bin/citygml2vrml" > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/bin/citygmltest > > -- Removed runtime path from > > "/«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/bin/citygmltest" > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/usr/lib/osgPlugins-3.0.1/ReaderWriterCityGML.so > > -- Removed runtime path from > > "/«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/usr/lib/osgPlugins-3.0.1/ReaderWriterCityGML.so" > > -- Installing: > > /«BUILDDIR»/libcitygml-0.14+svn128/debian/tmp/usr/usr/lib/osgPlugins-3.0.1/ReaderWriterCityGML.a > > make[1]: Leaving directory > > `/«BUILDDIR»/libcitygml-0.14+svn128/obj-x86_64-linux-gnu' > > cd /«BUILDDIR»/libcitygml-0.14+svn128 > >dh_install > > install -d debian/libcitygml0//usr/lib/x86_64-linux-gnu > > cp -a debian/tmp/usr/lib/x86_64-linux-gnu/libcitygml.so.0 > > debian/libcitygml0//usr/lib/x86_64-linux-gnu/ > > cp -a debian/tmp/usr/lib/x86_64-linux-gnu/libcitygml.so.0.0.0 > > debian/libcitygml0//usr/lib/x86_64-linux-gnu/ > > install -d debian/libcitygml0-dev//usr/include > > cp -a debian/tmp/usr/include/citygml.h > > debian/libcitygml0-dev//usr/include/ > > cp -a debian/tmp/usr/include/vecs.h debian/libcitygml0-dev//usr/include/ > > install -d debian/libcitygml0-dev//usr/lib/x86_64-linux-gnu > > cp -a debian/tmp/usr/lib/x86_64-linux-gnu/libcitygml.a > > debian/libcitygml0-dev//usr/lib/x86_64-linux-gnu/ > > cp -a debian/tmp/usr/lib/x86_64-linux-gnu/libcitygml.so > > debian/libcitygml0-dev//usr/lib/x86_64-linux-gnu/ > > install -d debian/libcitygml0-dev//usr/lib/x86_64-linux-gnu/pkgconfig > > cp -a debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/citygml.pc > > debian/libcitygml0-dev//usr/lib/x86_64-linux-gnu/pkgconfig/ > > install -d debian/libcitygml0-bin//usr/bin > > cp -a debian/tmp/usr/bin/citygml2vrml debian/libcitygml0-bin//usr/bin/ > > cp -a debian/tmp/usr/bin/citygmltest debian/libcitygml0-bin//usr/bin/ > > dh_install: openscenegraph-plugin-citygml-shared missing files > > (usr/lib/osgPlugins-*/*.so), aborting > > make: *** [binary] Error 255 openscenegraph's pkg-config file has been fixed in 3.0.1-4. So now pkg-config openscenegraph --variable libdir returns /usr/lib/osgPlugins-3.0.1. However, libcitygml installs the plugins into $prefix/$(pkg-config openscenegraph --variable libdir) which ends up being /usr/usr/lib/osgPlugins-3.0.1. The attached patch fixes this problem. If needed I can perform a NMU this weekend. Regards -- Sebastian Ramacher diff -Nru libcitygml-0.14+svn128/debian/changelog libcitygml-0.14+svn128/debian/changelog --- libcitygml-0.14+svn128/debian/changelog 2012-06-12 19:44:25.0 +0200 +++ libcitygml-0.14+svn128/debian/changelog 2013-01-30 00:26:44.0 +0100 @@ -1,3 +1,14 @@ +libc
Bug#691638: zsh: completion for python -m should be implemented without import all modules
On 2012-10-28 17:55:04, Sebastian Ramacher wrote:
> Here is a preliminary patch that uses code based on bpython's
> importcompletion to enumerate all modules. It also adds caching for the
> list of modules and handles submodules better. The caching policy should be
> improved, but I couldn't think of a clever way to determine whether it
> should be updated or not.
Attached is an updated patch. It improves the module detection a bit,
i.e modules which aren't run-able with python -m are not listed anymore.
Regards
--
Sebastian Ramacher
--- /usr/share/zsh/functions/Completion/Unix/_python 2012-12-28 14:38:19.0 +0100
+++ completion.d/_python 2013-01-30 15:05:14.413847679 +0100
@@ -1,4 +1,40 @@
-#compdef python
+#compdef python python3 python2 python2.7 python2.6 python3.2 python3.3
+#
+# 2013-01-30: Improve module detection and caching.
+# If a module is a package, only the package's submodules should be listed
+# except if it has a submodule called __main__.
+#
+# 2012-10-28: Add proper completion for Python modules.
+# Instead of importing all modules, the new code iterates over all folders
+# found in sys.path and enumerates the modules with imp. This prevents any
+# negative side effects that importing a module could have, e.g. a call to
+# sys.exit.
+#
+# Additionally, the result is cached.
+#
+# The code is based on bpython's importcomplete which was written by Andreas
+# Stuehrk and is covered by the following copyright and license:
+#
+# Copyright (c) 2009-2011 Andreas Stuehrk
+#
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+# THE SOFTWARE.
+
# Python 2.6
# Python 3.0
@@ -8,6 +44,119 @@
local -a args
+_python_modules () {
+ local update_policy
+ zstyle -s ":completion:${curcontext}:" cache-policy update_policy
+ if [[ -z "$update_policy" ]]; then
+zstyle ":completion:${curcontext}:" cache-policy \
+ _python_modules_caching_policy
+ fi
+
+ if ( [[ ${+_python_modules_list} -eq 0 ]] ||
+_cache_invalid python_modules) && ! _retrieve_cache python_modules;
+ then
+local prog
+prog="$(cat <
signature.asc
Description: Digital signature
Bug#699364: zsh-common: completion for apt-get source should list source packages
Package: zsh-common Version: 5.0.2-2 Severity: normal The completion for apt-get source only includes binary packages at the moment. Since apt-get source also takes source packages as argument, it they should be included in the completion too. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (650, 'unstable'), (601, 'testing'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.7-trunk-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 Versions of packages zsh-common depends on: ii dpkg 1.16.9 Versions of packages zsh-common recommends: ii zsh 5.0.2-2 Versions of packages zsh-common suggests: ii zsh-doc 5.0.2-2 -- no debconf information -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699253: libcitygml: FTBFS: dh_install: openscenegraph-plugin-citygml-shared missing files (usr/lib/osgPlugins-*/*.so), aborting
On 2013-01-30 22:07:48, YunQiang Su wrote: > Many thanks for your patch. > I will check and upload it myself this weekend. Great, thanks for taking care of this bug. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#697247: zsh: completion for dput doesn't work with dput-ng
Control: owner -1 ! I'll work on a fixed completion. -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#697247: zsh: completion for dput doesn't work with dput-ng
Control: tags -1 patch
On 2013-01-03 01:43:15, Sebastian Ramacher wrote:
> dput-ng's dput currently doesn't support -H. Hence the completoin for dput
> shipped in zsh doesn't work anymore if dput-ng is installed. It calls dput -H
> to
> get the list of available hosts.
Please find attached a patch that makes the dput completion work with both dput
and dput-ng. It calls 'dirt hosts' instead of 'dput -H' if dirt is detected.
Additionally, options that are not supported in both versions are only listed
for the correct version.
Regards
--
Sebastian Ramacher
diff --git a/Completion/Debian/Command/_dput b/Completion/Debian/Command/_dput
index 2046534..ea4a578 100644
--- a/Completion/Debian/Command/_dput
+++ b/Completion/Debian/Command/_dput
@@ -1,28 +1,55 @@
#compdef dput
_dput() {
-_arguments \
- '(-c --config)'{-c,--config}'[specify config file]:config file:_files' \
- '(-d --debug)'{-d,--debug}'[debug mode]' \
- '(-D --dinstall)'{-D,--dinstall}'[run dinstall after upload]' \
- '(-e --delayed)'{-E,--delayed}'[number of days in delayed queue]:number of days:(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)' \
- '(-f --force)'{-f,--force}'[force upload of already uploaded package]' \
- '(-H --host-list)'{-H,--host-list}'[display host list]' \
- '(-l --lintian)'{-l,--lintian}'[run lintian before upload]' \
- '(-o --check-only)'{-o,--check-only}'[check the package, do not upload]' \
- '(-p --print)'{-p,--print}'[print configuration]' \
- '(-s --simulate)'{-s,--simulate}'[simulate an upload only]' \
- '(-u --unchecked)'{-u,--unchecked}'[do not check GPG signature on the changes file]' \
- '(-v --version)'{-v,--version}'[show version information]' \
- '1::host:_dput_hosts' \
- '*:changes file:_files -g "*.changes(-.)"'
+ local -a all_opts dput_opts dput_ng_opts
+
+ all_opts=(
+'(-c --config)'{-c,--config}'[specify config file]:config file:_files'
+'(-h --help)'{-h,--help}'[show help message and exit]'
+'(-f --force)'{-f,--force}'[force an upload]'
+'(-P --passive)'{-P,--passive}'[use passive FTP for uploads]'
+'(-U --no-upload-log)'{-U,--no-upload-log}'[do not write an .upload log after uploading]'
+'(-D --dinstall)'{-D,--dinstall}'[run dinstall after upload]'
+'(-e --delayed)'{-e,--delayed}'[number of days in delayed queue]:number of days:(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)'
+'(-l --lintian)'{-l,--lintian}'[run lintian before upload]'
+'(-o --check-only)'{-o,--check-only}'[check the package, do not upload]'
+'(-u --unchecked)'{-u,--unchecked}'[do not check GPG signature on the changes file]'
+'(-v --version)'{-v,--version}'[show version information]'
+'1::host:_dput_hosts'
+'*:changes file:_files -g "*.changes(-.)"'
+ )
+
+ dput_opts=(
+'(-d --debug)'{-d,--debug}'[debug mode]'
+'(-H --host-list)'{-H,--host-list}'[display host list]'
+'(-s --simulate)'{-s,--simulate}'[simulate an upload only]'
+'(-p --print)'{-p,--print}'[print configuration]'
+ )
+
+ dput_ng_opts=(
+'*'{-d,--debug}'[enable debug messages, repeat twice to increase the verbosity level]'
+'*'{-s,--simulate}'[simulate an upload only, repeat twice to increase level of simulation]'
+'(-F --full-upload-log)'{-F,--full-upload-log}'[write more verbose .upload logs]'
+ )
+
+ if (( ${+commands[dirt]} )); then
+_arguments \
+ "$all_opts[@]" "$dput_ng_opts[@]"
+ else
+_arguments \
+ "$all_opts[@]" "$dput_opts[@]"
+ fi
}
_dput_hosts() {
local expl
if ( [[ ${+_dput_cfhosts} -eq 0 ]] || _cache_invalid dputhosts ) && ! _retrieve_cache dputhosts; then
-_dput_cfhosts=(${${(M)${(f)"$(dput -H)"}:#*=>*}/ =>*/})
+if (( ${+commands[dirt]} )); then
+ _dput_cfhosts=(${${(M)${(f)"$(dirt hosts)"}:#*=>*}/ =>*/})
+else
+ _dput_cfhosts=(${${(M)${(f)"$(dput -H)"}:#*=>*}/ =>*/})
+fi
_store_cache dputhosts _dput_cfhosts
fi
signature.asc
Description: Digital signature
Bug#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
Control: tags -1 unreproducible moreinfo Hi Francesco, On 2013-01-30 23:41:02, Francesco Poli (wintermute) wrote: > I seem to be unable to use the built-in feature to take screenshots. > > After starting to play a video: > > $ gnome-mplayer one-video.ogv > > I tried to hit [Ctrl+T], while the video was being played, but > nothing seemed to happen. No file was created (at least, not > in the current working directory, where I would expect it, > or even in /tmp ...) > > I also tried to choose "Take Screenshot" from the Edit menu, > but again nothing happened. > > What's wrong? > What did I fail to understand? > > If this is confirmed to be a bug, please fix it and/or forward > my bug report upstream. > Thanks again for your time. Unfortunately I can't reproduce the bug. Could you please attach the output of 'gnome-mplayer -v $thevideo'? Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#697247: zsh: completion for dput doesn't work with dput-ng
A new patch is attached. It contains the
(${${(M)${(f)"$(...)"}:#*=>*}/ =>*/}) monstrosity only once.
Regards
--
Sebastian Ramacher
diff --git a/Completion/Debian/Command/_dput b/Completion/Debian/Command/_dput
index 2046534..46879e7 100644
--- a/Completion/Debian/Command/_dput
+++ b/Completion/Debian/Command/_dput
@@ -1,28 +1,57 @@
#compdef dput
_dput() {
-_arguments \
- '(-c --config)'{-c,--config}'[specify config file]:config file:_files' \
- '(-d --debug)'{-d,--debug}'[debug mode]' \
- '(-D --dinstall)'{-D,--dinstall}'[run dinstall after upload]' \
- '(-e --delayed)'{-E,--delayed}'[number of days in delayed queue]:number of days:(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)' \
- '(-f --force)'{-f,--force}'[force upload of already uploaded package]' \
- '(-H --host-list)'{-H,--host-list}'[display host list]' \
- '(-l --lintian)'{-l,--lintian}'[run lintian before upload]' \
- '(-o --check-only)'{-o,--check-only}'[check the package, do not upload]' \
- '(-p --print)'{-p,--print}'[print configuration]' \
- '(-s --simulate)'{-s,--simulate}'[simulate an upload only]' \
- '(-u --unchecked)'{-u,--unchecked}'[do not check GPG signature on the changes file]' \
- '(-v --version)'{-v,--version}'[show version information]' \
- '1::host:_dput_hosts' \
- '*:changes file:_files -g "*.changes(-.)"'
+ local -a all_opts dput_opts dput_ng_opts
+
+ all_opts=(
+'(-c --config)'{-c,--config}'[specify config file]:config file:_files'
+'(-h --help)'{-h,--help}'[show help message and exit]'
+'(-f --force)'{-f,--force}'[force an upload]'
+'(-P --passive)'{-P,--passive}'[use passive FTP for uploads]'
+'(-U --no-upload-log)'{-U,--no-upload-log}'[do not write an .upload log after uploading]'
+'(-D --dinstall)'{-D,--dinstall}'[run dinstall after upload]'
+'(-e --delayed)'{-e,--delayed}'[number of days in delayed queue]:number of days:(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)'
+'(-l --lintian)'{-l,--lintian}'[run lintian before upload]'
+'(-o --check-only)'{-o,--check-only}'[check the package, do not upload]'
+'(-u --unchecked)'{-u,--unchecked}'[do not check GPG signature on the changes file]'
+'(-v --version)'{-v,--version}'[show version information]'
+'1::host:_dput_hosts'
+'*:changes file:_files -g "*.changes(-.)"'
+ )
+
+ dput_opts=(
+'(-d --debug)'{-d,--debug}'[debug mode]'
+'(-H --host-list)'{-H,--host-list}'[display host list]'
+'(-s --simulate)'{-s,--simulate}'[simulate an upload only]'
+'(-p --print)'{-p,--print}'[print configuration]'
+ )
+
+ dput_ng_opts=(
+'*'{-d,--debug}'[enable debug messages, repeat twice to increase the verbosity level]'
+'*'{-s,--simulate}'[simulate an upload only, repeat twice to increase level of simulation]'
+'(-F --full-upload-log)'{-F,--full-upload-log}'[write more verbose .upload logs]'
+ )
+
+ if (( ${+commands[dirt]} )); then
+_arguments \
+ "$all_opts[@]" "$dput_ng_opts[@]"
+ else
+_arguments \
+ "$all_opts[@]" "$dput_opts[@]"
+ fi
}
_dput_hosts() {
local expl
if ( [[ ${+_dput_cfhosts} -eq 0 ]] || _cache_invalid dputhosts ) && ! _retrieve_cache dputhosts; then
-_dput_cfhosts=(${${(M)${(f)"$(dput -H)"}:#*=>*}/ =>*/})
+local cmd
+if (( ${+commands[dirt]} )); then
+ cmd=(dirt hosts)
+else
+ cmd=(dput -H)
+fi
+ _dput_cfhosts=(${${(M)${(f)"$($cmd)"}:#*=>*}/ =>*/})
_store_cache dputhosts _dput_cfhosts
fi
signature.asc
Description: Digital signature
Bug#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
Control: tags -1 - unreproducible + confirmed Control: retitle -1 gnome-mplayer: fails to take screenshots with mplayer Control: forwarded -1 https://code.google.com/p/gnome-mplayer/issues/detail?id=668 On 2013-02-01 00:35:12, Francesco Poli wrote: > > Unfortunately I can't reproduce the bug. Could you please attach the output > > of > > 'gnome-mplayer -v $thevideo'? > > Sure! > > I tried the following: > > $ gnome-mplayer -v voyage.ogv > /tmp/gnome-mplayer.out 2>&1 > > where voyage.ogv is the short film already cited in bugs #699393 and > #696714. > > As soon as the video began to play, I pressed [Ctrl+1], then [Ctrl+T], > and finally [Q]. > > The resulting file is attached (slightly edited). > > It actually shows an error message about the inability to take > screenshots, but I fail to understand what's the problem. > It seems to talk about some command-line option (forgot > -vf screenshot?), but I haven't found this option in the man page... > > Anything useful to debug my issue? > Please let me know. > Thanks for your time! Thanks for the log. I've installed mplayer (instead of mplayer2) to check if that might be a problem and in fact it is. With mplayer I can see the same error message in the log. I forwarded the issue. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
On 2013-02-01 18:23:23, Sebastian Ramacher wrote: > > > Unfortunately I can't reproduce the bug. Could you please attach the > > > output of > > > 'gnome-mplayer -v $thevideo'? > > > > Sure! > > > > I tried the following: > > > > $ gnome-mplayer -v voyage.ogv > /tmp/gnome-mplayer.out 2>&1 > > > > where voyage.ogv is the short film already cited in bugs #699393 and > > #696714. > > > > As soon as the video began to play, I pressed [Ctrl+1], then [Ctrl+T], > > and finally [Q]. > > > > The resulting file is attached (slightly edited). > > > > It actually shows an error message about the inability to take > > screenshots, but I fail to understand what's the problem. > > It seems to talk about some command-line option (forgot > > -vf screenshot?), but I haven't found this option in the man page... > > > > Anything useful to debug my issue? > > Please let me know. > > Thanks for your time! > > Thanks for the log. I've installed mplayer (instead of mplayer2) to > check if that might be a problem and in fact it is. With mplayer I can > see the same error message in the log. My analysis is wrong. It also depends on the video output used. In any case, an error message would be appropriate. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#697247: zsh: completion for dput doesn't work with dput-ng
Here is another one. It uses _pick_variant instead of relaying on the
existence of something called dirt in $PATH.
Regards
--
Sebastian Ramacher
diff --git a/Completion/Debian/Command/_dput b/Completion/Debian/Command/_dput
index 2046534..bf6c2ba 100644
--- a/Completion/Debian/Command/_dput
+++ b/Completion/Debian/Command/_dput
@@ -1,28 +1,57 @@
#compdef dput
_dput() {
-_arguments \
- '(-c --config)'{-c,--config}'[specify config file]:config file:_files' \
- '(-d --debug)'{-d,--debug}'[debug mode]' \
- '(-D --dinstall)'{-D,--dinstall}'[run dinstall after upload]' \
- '(-e --delayed)'{-E,--delayed}'[number of days in delayed queue]:number of days:(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)' \
- '(-f --force)'{-f,--force}'[force upload of already uploaded package]' \
- '(-H --host-list)'{-H,--host-list}'[display host list]' \
- '(-l --lintian)'{-l,--lintian}'[run lintian before upload]' \
- '(-o --check-only)'{-o,--check-only}'[check the package, do not upload]' \
- '(-p --print)'{-p,--print}'[print configuration]' \
- '(-s --simulate)'{-s,--simulate}'[simulate an upload only]' \
- '(-u --unchecked)'{-u,--unchecked}'[do not check GPG signature on the changes file]' \
- '(-v --version)'{-v,--version}'[show version information]' \
- '1::host:_dput_hosts' \
- '*:changes file:_files -g "*.changes(-.)"'
+ local -a all_opts dput_opts dput_ng_opts
+
+ all_opts=(
+'(-c --config)'{-c,--config}'[specify config file]:config file:_files'
+'(-h --help)'{-h,--help}'[show help message and exit]'
+'(-f --force)'{-f,--force}'[force an upload]'
+'(-P --passive)'{-P,--passive}'[use passive FTP for uploads]'
+'(-U --no-upload-log)'{-U,--no-upload-log}'[do not write an .upload log after uploading]'
+'(-D --dinstall)'{-D,--dinstall}'[run dinstall after upload]'
+'(-e --delayed)'{-e,--delayed}'[number of days in delayed queue]:number of days:(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)'
+'(-l --lintian)'{-l,--lintian}'[run lintian before upload]'
+'(-o --check-only)'{-o,--check-only}'[check the package, do not upload]'
+'(-u --unchecked)'{-u,--unchecked}'[do not check GPG signature on the changes file]'
+'(-v --version)'{-v,--version}'[show version information]'
+'1::host:_dput_hosts'
+'*:changes file:_files -g "*.changes(-.)"'
+ )
+
+ dput_opts=(
+'(-d --debug)'{-d,--debug}'[debug mode]'
+'(-H --host-list)'{-H,--host-list}'[display host list]'
+'(-s --simulate)'{-s,--simulate}'[simulate an upload only]'
+'(-p --print)'{-p,--print}'[print configuration]'
+ )
+
+ dput_ng_opts=(
+'*'{-d,--debug}'[enable debug messages, repeat twice to increase the verbosity level]'
+'*'{-s,--simulate}'[simulate an upload only, repeat twice to increase level of simulation]'
+'(-F --full-upload-log)'{-F,--full-upload-log}'[write more verbose .upload logs]'
+ )
+
+ if _pick_variant dputng="usage: dput" dput -H ; then
+_arguments \
+ "$all_opts[@]" "$dput_ng_opts[@]"
+ else
+_arguments \
+ "$all_opts[@]" "$dput_opts[@]"
+ fi
}
_dput_hosts() {
local expl
if ( [[ ${+_dput_cfhosts} -eq 0 ]] || _cache_invalid dputhosts ) && ! _retrieve_cache dputhosts; then
-_dput_cfhosts=(${${(M)${(f)"$(dput -H)"}:#*=>*}/ =>*/})
+local cmd
+if _pick_variant dputng="usage: dput" dput -H ; then
+ cmd=(dirt hosts)
+else
+ cmd=(dput -H)
+fi
+ _dput_cfhosts=(${${(M)${(f)"$($cmd)"}:#*=>*}/ =>*/})
_store_cache dputhosts _dput_cfhosts
fi
signature.asc
Description: Digital signature
Bug#699645: python-gnupginterface: breaks with Python 2.7
Hi Toni,
On 2013-02-02 22:33:46, Toni Mueller wrote:
> >>> import GnuPGInterface
> >>> gnupg = GnuPGInterface.GnuPG()
> >>> gnupg.options.meta_interactive = 0
> >>> gnupg.options.armor = 1
> >>> gnupg.options.extra_args.append('--no-secmem-warning')
> >>> p1 = gnupg.run(['--verify'], create_fhs=['stdin', 'stdout', 'passphrase'])
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/pymodules/python2.7/GnuPGInterface.py", line 357, in run
> create_fhs, attach_fhs)
> File "/usr/lib/pymodules/python2.7/GnuPGInterface.py", line 397, in
> _attach_fork_exec
> process._pipes[fh_name] = Pipe(fh.fileno(), fh.fileno(), 1)
> AttributeError: 'CLIRepl' object has no attribute 'fileno'
The error looks like you're trying to run the example in bpython. So you are
probably experiencing [1] or a variant of it. The examples works in an
interactive python shell.
Regards
[1]
https://bitbucket.org/bobf/bpython/issue/232/bpythonclifakestdin-dont-have-fileno
--
Sebastian Ramacher
signature.asc
Description: Digital signature
Bug#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
Control: reassign -1 libgmtk1 1.0.7-1
Control: retitle -1 gmtk: silently fails to take screenshots
Control: tags -1 + upstream fixed-upstream patch
The code to take the screenshots is in gtmk, hence I'm reassigning it to
gmtk. The patch to display an error message if mplayer failed to take a
screenshot is attached. This patch has been applied upstream.
On 2013-02-01 19:25:03, Francesco Poli wrote:
> > > I've installed mplayer (instead of mplayer2) to
> > > check if that might be a problem and in fact it is. With mplayer I can
> > > see the same error message in the log.
>
> Woah! I hadn't noticed the mplayer2 package in Debian!
> Shame on me: I see that it's in testing since 2011...
>
> Is it mature enough to replace mplayer?
I haven't had any problems with it so far.
> > My analysis is wrong. It also depends on the video output used. In any
> > case, an error message would be appropriate.
>
> In this case, maybe my mplayer configuration can help to pinpoint the
> issue:
>
> $ cat ~/.mplayer/config
> [default]
> ao=jack,alsa
> volume=20
> vo=xv
There is some special casing based on the selected vo, but the vo
selected in ~/.mplayer/config is ignored in gnome-mplayer. So there are
some things left I want you to try: explicitly select the vo in
gnome-mplayer's preferences, try to take a screenshot with both mplayer
and mplayer2 and maybe also try another vo.
I'm not familiar enough with all the quirks of the different video
outputs, so I need to rely on upstream's understanding of them.
Regards
--
Sebastian Ramacher
From fa33ed02e8d9330318779e5000d7473a1356ea68 Mon Sep 17 00:00:00 2001
From: kdekorte
Date: Sat, 2 Feb 2013 23:15:51 +
Subject: [PATCH 1/2] Add message when screenshot capture fails
git-svn-id: http://gmtk.googlecode.com/svn/trunk@203 cc285a5d-864f-f498-13c1-83eaf8612931
---
ChangeLog |1 +
src/gmtk_media_player.c |8
2 files changed, 9 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index 402a5eb..097f18b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,4 +1,5 @@
Development
+ Add message when screenshot capture fails
Switch to GLIB for GMLIB header files, since GTK is not included
Switch to GTK VERSION tags when possible
Updated Japanese translation
diff --git a/src/gmtk_media_player.c b/src/gmtk_media_player.c
index b177a3f..b7055c6 100644
--- a/src/gmtk_media_player.c
+++ b/src/gmtk_media_player.c
@@ -3625,6 +3625,14 @@ gboolean thread_reader(GIOChannel * source, GIOCondition condition, gpointer dat
message = NULL;
}
+if (strstr(mplayer_output->str, "failed (forgot -vf screenshot?)") != 0) {
+dialog = gtk_message_dialog_new(NULL, GTK_DIALOG_DESTROY_WITH_PARENT, GTK_MESSAGE_ERROR,
+GTK_BUTTONS_OK, g_dgettext(GETTEXT_PACKAGE, "Failed to take screenshot"));
+gtk_window_set_title(GTK_WINDOW(dialog), g_dgettext(GETTEXT_PACKAGE, "GNOME MPlayer Notification"));
+gtk_dialog_run(GTK_DIALOG(dialog));
+gtk_widget_destroy(dialog);
+}
+
if (strstr(mplayer_output->str, "Name : ") != 0) {
buf = strstr(mplayer_output->str, "Name : ");
buf = strstr(mplayer_output->str, "Name : ") + strlen("Name : ");
--
1.7.10.4
signature.asc
Description: Digital signature
Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
Control: tags -1 upstream On 2013-02-03 18:48:48, Francesco Poli (wintermute) wrote: > as clarified in http://bugs.debian.org/699394#39 , gnome-mplayer > ignores any user-defined setting found in ~/.mplayer/config . > > I don't think this is a good idea: I would like to avoid configuring > the same program (mplayer) over and over again, just because I use > it through different interfaces! > > I would like to suggest that gnome-mplayer should read and use > (or let mplayer read and use) the settings found in ~/.mplayer/config , > so that my preferences for mplayer are enforced within gnome-mplayer > too. I think "ignore" is the wrong word here. gnome-mplayer just overwrites some settings and takes no special care of settings in ~/.mplayer/config when special casing some stuff. Looking at the source, the video output is the only thing that is overwritten. The audio output has a "Default" setting, for example. It might make sense to add a "Default" to the video output settings, though. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
Control: forwarded -1 https://code.google.com/p/gnome-mplayer/issues/detail?id=496 Just to let you know: this issue has already been reported upstream almost two years ago. There is no progress so far. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
On 2013-02-03 18:38:17, Francesco Poli wrote: > I tried to test all the available options for the video output in > gnome-mplayer (with mplayer) and found the following awkward results. > > > Leaving the setting blank seems to automatically select xv, according > to the verbose output: > GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12 > but screenshots do not work: > GMLIB-Message: sending VFCTRL_SCREENSHOT! > GMLIB-Message: failed (forgot -vf screenshot?) If the setting is blank, the default output is used. Since you have manually set it to xv in your mplayer config, it's using xv here. > Explicitly selecting xv works: > GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12 > and screenshots may be taken: > GMLIB-Message: sending VFCTRL_SCREENSHOT! > GMLIB-Message: *** screenshot 'shot0001.png' *** So in this case gnome-mplayer launched mplayer with the correct flags to take screenshots since it knew that xv is used. > Selecting gl works: > GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12 > and screenshots may be taken: > GMLIB-Message: sending VFCTRL_SCREENSHOT! > GMLIB-Message: *** screenshot 'shot0002.png' *** > > Selecting gl2 works: > GMLIB-Message: VO: [gl2] 400x304 => 400x304 Planar YV12 > and screenshots may be taken: > GMLIB-Message: sending VFCTRL_SCREENSHOT! > GMLIB-Message: *** screenshot 'shot0003.png' *** > > Selecting x11 works: > GMLIB-Message: VO: [x11] 400x304 => 400x304 Planar YV12 [zoom] > and screenshots may be taken: > GMLIB-Message: sending VFCTRL_SCREENSHOT! > GMLIB-Message: *** screenshot 'shot0004.png' *** > > Selecting vdpau seems to lead to gl being used: > GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12 That's expected if your hardware doesn't support vdpau or you're missing the necessary libraries to actually use vdpau. > but screenshots do not work: > GMLIB-Message: sending VFCTRL_SCREENSHOT! > GMLIB-Message: failed (forgot -vf screenshot?) I guess this is one of the vos upstream mentioned, that don't support screenshots. > Selecting xvmc or vaapi fails to work (high CPU load, endless stream > of error messages and no visible video...). If the issues are reproducable with mplayer alone, I'd report bugs against those packages. Maybe you're just missing the proper hardware support. > Then I installed mplayer2, thus removing the conflicting mplayer. > > Explicitly selecting xv works: > GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12 > and screenshots may be taken, but a single [Ctrl+T] produces two identical > files: > GMLIB-Message: *** screenshot 'shot0005.png' *** > GMLIB-Message: *** screenshot 'shot0006.png' *** > > Please note that > $ diff -sq shot000[56].png > Files shot0005.png and shot0006.png are identical > > Leaving the setting blank seems to automatically select xv, according > to the verbose output: > GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12 > and again screenshots may be taken, but a single [Ctrl+T] produces > two identical files: > GMLIB-Message: *** screenshot 'shot0007.png' *** > GMLIB-Message: *** screenshot 'shot0008.png' *** > > Selecting gl works: > GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12 > and (double identical) screenshots may be taken: > GMLIB-Message: *** screenshot 'shot0009.png' *** > GMLIB-Message: *** screenshot 'shot0010.png' *** > > Selecting x11 works: > GMLIB-Message: VO: [x11] 400x304 => 400x304 Planar YV12 [zoom] > and single screenshots may be taken: > GMLIB-Message: No VO support for taking screenshots, trying > VFCTRL_SCREENSHOT! > GMLIB-Message: No VO support for taking screenshots, trying > VFCTRL_SCREENSHOT! > GMLIB-Message: *** screenshot 'shot0011.png' *** > > Selecting vdpau seems to lead to gl being used: > GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12 > and single screenshots may be taken: > GMLIB-Message: *** screenshot 'shot0012.png' *** > > Selecting xvmc seems to lead to xv being used: > GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12 > and single screenshots may be taken: > GMLIB-Message: *** screenshot 'shot0013.png' *** > > Selecting gl2 or vaapi fails to work (high CPU load, endless stream > of error messages and no visible video...). > > > OK, after this systematic test of all the options, I must confess that > I have no idea of which I should actually choose... :-( Take the one best suited for your needs. If taking screenshots is important to you, take a vo that supports them and configure gnome-mplayer accordingly. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
Control: tags -1 + moreinfo Hi again, On 2013-01-30 23:30:49, Francesco Poli (wintermute) wrote: > Package: gnome-mplayer > Version: 1.0.7-4 > Severity: normal > > Hello, > I noticed that gnome-mplayer often starts playing a video with > an awkward zero-height canvas (== the area where the video is played, > I am not sure of the correct name for this part of the GUI window...). > > As soon as I start the program: > > $ gnome-mplayer some-video.ogv > > the canvas seems to have the correct width, but zero height. > Hence the video is played, but is not visible. > > If I press [Ctrl+1], the canvas is resized to the video original > width and height and everything works fine. > Other resize commands are also able to fix this problem. > > However, I think that gnome-mplayer should start with a canvas > having the correct width and height for the video being played, > without waiting for the user to hit [Ctrl+1]. > > I experience this issue with some videos, but not with all the ones > I tested. I had a look at the log from #699394 and the following bits look suspicious: GMLIB-Message: current size = 416 x 1 GMLIB-Message: Changing window size to 400 x 304 visible = true GMLIB-Message: trying to disable screensaver GMLIB-Message: current size = 0 x 0 GMLIB-Message: Changing window size to 400 x 304 visible = true So let me ask you some questions: does this also happen with mplayer2? Is there anything special about your windows manager and/or desktop environment? Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
On 2013-02-03 21:43:10, Sebastian Ramacher wrote: > So let me ask you some questions: does this also happen with mplayer2? > Is there anything special about your windows manager and/or desktop > environment? And while we're at it: could you also check if you're affacted by [1]? Regards [1] https://code.google.com/p/gnome-mplayer/issues/detail?id=657 -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
Control: forwarded -1 https://code.google.com/p/gnome-mplayer/issues/detail?id=670 On 2013-02-03 23:49:53, Francesco Poli wrote: > On Sun, 3 Feb 2013 21:09:26 +0100 Sebastian Ramacher wrote: > > [...] > > Just to let you know: this issue has already been reported upstream > > almost two years ago. There is no progress so far. > > Mmmmh, it does not look like the same feature request. There you go. If you have any useful information that should be added to the upstream bug report, please follow up there. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699263: pspp: diff for NMU version 0.7.9+git20120620-1.1
Control: tags -1 + patch pending Dear maintainer, I've prepared an NMU for pspp (versioned as 0.7.9+git20120620-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards -- Sebastian Ramacher diff -Nru pspp-0.7.9+git20120620/debian/changelog pspp-0.7.9+git20120620/debian/changelog --- pspp-0.7.9+git20120620/debian/changelog 2012-06-25 00:57:27.0 +0200 +++ pspp-0.7.9+git20120620/debian/changelog 2013-02-05 00:25:40.0 +0100 @@ -1,3 +1,13 @@ +pspp (0.7.9+git20120620-1.1) unstable; urgency=low + + * Non-maintainer upload. + * debian/patches/699263: Add patch from upstream to fix test suite failures. +Since the default epoch depends on the current year, the test suite broke +on January 1, 2013. The patch adds the epoch to the test suite. (Closes: +#699263) + + -- Sebastian Ramacher Tue, 05 Feb 2013 00:25:38 +0100 + pspp (0.7.9+git20120620-1) unstable; urgency=low * New upstream snapshot, fixes non-ASCII import issue (Closes: #676371). diff -Nru pspp-0.7.9+git20120620/debian/patches/699263 pspp-0.7.9+git20120620/debian/patches/699263 --- pspp-0.7.9+git20120620/debian/patches/699263 1970-01-01 01:00:00.0 +0100 +++ pspp-0.7.9+git20120620/debian/patches/699263 2013-02-04 23:07:11.0 +0100 @@ -0,0 +1,30 @@ +Description: Fix dependency on current year in tests. + The tests for expressions broke on Jan 1, 2013 because the default epoch + depends on the current year. This commit fixes the tests by setting a + fixed epoch for dates. +Last-Update: 2013-02-04 +Origin: upstream, + http://git.savannah.gnu.org/gitweb/?p=pspp.git;a=commit;h=65a665dc6 +Bug-Debian: http://bugs.debian.org/699263 + +--- + tests/language/expressions/evaluate.at |3 ++- + 1 files changed, 2 insertions(+), 1 deletions(-) + +--- a/tests/language/expressions/evaluate.at b/tests/language/expressions/evaluate.at +@@ -3,12 +3,13 @@ +AT_DATA([evaluate.sps], + [set mxwarn 1000. + set mxerr 1000. ++set epoch 1940. + m4_foreach([check], [m4_shift($@)], + [DEBUG EVALUATE NOOPT m4_argn(4, check)/[]m4_car(check). + DEBUG EVALUATE m4_argn(4, check)/[]m4_car(check). + ])]) +AT_CAPTURE_FILE([evaluate.sps]) +- m4_pushdef([i], [2]) ++ m4_pushdef([i], [3]) +AT_CHECK([pspp --testing-mode --error-file=- --no-output evaluate.sps], + [m4_if(m4_bregexp([m4_foreach([check], [m4_shift($@)], [m4_argn(3, check)])], [error:]), [-1], [0], [1])], + [stdout]) diff -Nru pspp-0.7.9+git20120620/debian/patches/series pspp-0.7.9+git20120620/debian/patches/series --- pspp-0.7.9+git20120620/debian/patches/series 2012-01-24 19:30:17.0 +0100 +++ pspp-0.7.9+git20120620/debian/patches/series 2013-02-04 23:07:56.0 +0100 @@ -1 +1,2 @@ fix_paths_in_manpage +699263
Bug#699394: gnome-mplayer: [Ctrl+T] fails to take screenshot
On 2013-02-04 23:34:51, Francesco Poli wrote: > On Sun, 3 Feb 2013 21:27:06 +0100 Sebastian Ramacher wrote: > > > On 2013-02-03 18:38:17, Francesco Poli wrote: > > > I tried to test all the available options for the video output in > > > gnome-mplayer (with mplayer) and found the following awkward results. > > > > > > > > > Leaving the setting blank seems to automatically select xv, according > > > to the verbose output: > > > GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12 > > > but screenshots do not work: > > > GMLIB-Message: sending VFCTRL_SCREENSHOT! > > > GMLIB-Message: failed (forgot -vf screenshot?) > > > > If the setting is blank, the default output is used. Since you have > > manually set it to xv in your mplayer config, it's using xv here. > > OK, but why did gnome-mplayer fail to pass the correct flags to enable > screenshots in mplayer? > > By looking at the mplayer man page, I seem to understand that the > correct flag is just: > > -vf screenshot Well, it's not true for all vos. To the best of my knowledge, the screenshot video filter and vdpau don't work well together, since mplayer never sees the final image. (That information might be outdated, so please correct me if I'm wrong.) > > > Selecting gl works: > > > GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12 > > > and screenshots may be taken: > > > GMLIB-Message: sending VFCTRL_SCREENSHOT! > > > GMLIB-Message: *** screenshot 'shot0002.png' *** > > > > [...] > > > Selecting vdpau seems to lead to gl being used: > > > GMLIB-Message: VO: [gl] 400x304 => 400x304 Planar YV12 > > > > That's expected if your hardware doesn't support vdpau or you're missing > > the necessary libraries to actually use vdpau. > > > > > but screenshots do not work: > > > GMLIB-Message: sending VFCTRL_SCREENSHOT! > > > GMLIB-Message: failed (forgot -vf screenshot?) > > > > I guess this is one of the vos upstream mentioned, that don't support > > screenshots. > > This does not seem to be the case: when I explicitly ask for gl, I am > able to take screenshots (without the vf=screenshot setting in > ~/.mplayer/config). Let's put it this way: since vdpau is selected -vf screenshot is not passed to mplayer. Your hardware doesn't support vdpau, so the fallback gl is used. However, with gl you need -vf screenshot. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
Control: tags + -1 wontfix On 2013-02-04 21:25:50, Sebastian Ramacher wrote: > Control: forwarded -1 > https://code.google.com/p/gnome-mplayer/issues/detail?id=670 According to upstream's answer, this is not going to happen. Since I'm not going to work on this either, let's tag the bug wontfix. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699812: dcut: manpage and --help talk about -U and --upload
Package: dput-ng Version: 1.4 Severity: minor dcut's manpage and dcut --help mention -U and --upload in multiple places. These two flags have been replaced by the upload command, so the documentation should be changed accordingly. Regards. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (650, 'unstable'), (601, 'testing'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.7-trunk-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 Versions of packages dput-ng depends on: ii python 2.7.3-3 ii python-dput 1.4 Versions of packages dput-ng recommends: pn bash-completion dput-ng suggests no packages. -- no debconf information -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699851: zsh: please add completion for dcut
Package: zsh-common
Version: 5.0.2-2
Severity: wishlist
Tags: patch
Please add completion support for dcut to zsh. I've attached an initial
version of the completion supporting both dcut from dput and dput-ng.
There is one TODO left: the host completion doesn't work since I didn't
manage to get it right after a day of trying. I'd appreciate any help
and hints to get this final bit fixed.
Regards
--
Sebastian Ramacher
#compdef dcut
# TODO: dcut supports two ways to be called:
# * dcut HOST COMMAND ...
# * dcut COMMAND ...
# So ideally, if the first argument is completed, both commands and hosts should
# be offered. If host is given, the second argument should be completed as
# command and if not, it should be completed as command specific option.
function _dcut_commands() {
local -a cmds
if _pick_variant dcutng="usage: dcut" dcut -v ; then
cmds=(
dm:'manage Debian Maintainer permissions'
break-the-archive:'break the archive'
reschedule:'reschedule a deferred upload'
cancel:'cancel a deferred upload'
rm:'remove a file from the upload queue'
upload:'upload a command file'
)
else
cmds=(
rm:'remove a file from the upload queue'
cancel:'cancel a deferred upload'
reschedule:'reschedule a deferred upload'
)
fi
_describe -t commands command cmds
}
function _dcut() {
local -a all_opts dcut_opts dcut_ng_opts
local state line context
local -A opt_args
local curcontext="${curcontext}"
all_opts=(
'(-c --config)'{-c,--config=}'[specify config file]:config file:_files'
'(-h --help)'{-h,--help}'[show help message and exit]'
'(-m --maintainer)'{-m,--maintainer=}'[use maintainer for upload field and
GPG key selection]:maintainer address'
'(-k --keyid)'{-k,--keyid}'[use key id for signing]:keyid'
'(-O --output)'{-O,--output=}'[write command file to file instead of
uploading]:output file:_files'
'(-P --passive)'{-P,--passive}'[use passive FTP for uploads]'
'(-v --version)'{-v,--version}'[show version information]'
':command:_dcut_commands'
)
dcut_opts=(
'(-d --debug)'{-d,--debug}'[debug mode]'
'(-s --simulate)'{-s,--simulate}'[simulate an upload only]'
'(-i --input)'{-i,--input=}'[create commands file to remove every file
listed in the changes file]:changes file:_files -g"*.changes(-.)"'
'(-U --upload)'{-U,--upload=}'[upload commands file]:commands file:_files'
'(--host 1)'{--host=}'[upload to host if it is named like a
command]:host:_dput_hosts'
'*:: :->dcut_command_arguments'
)
dcut_ng_opts=(
'*'{-d,--debug}'[enable debug messages, repeat twice to increase the
verbosity level]'
'*'{-s,--simulate}'[simulate an upload only, repeat twice to increase level
of simulation]'
'*:: :->dcut_ng_command_arguments'
)
if _pick_variant dcutng="usage: dcut" dcut -v ; then
_arguments -C \
"$all_opts[@]" "$dcut_ng_opts[@]" && return
else
_arguments -C \
"$all_opts[@]" "$dcut_opts[@]" && return
fi
case $state in
(dcut_command_arguments)
# arguments to dcut commands
local -a opts
case ${line[1]} in
(cancel)
# dcut cancel arguments
opts=(
'1::changes file:_files -g"*.changes(-.)"'
)
;;
(reschedule)
# dcut reschedule arguments
opts=(
'1::changes file:_files -g"*.changes(-.)"'
'2::new delayed queue:(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)'
)
;;
(rm)
# dcut rm arguments
opts=(
'--searchdirs[search in all directores for the given files]'
'1::file to be deleted:_files'
)
;;
esac
_arguments "$opts[@]" && return
;;
(dcut_ng_command_arguments)
# arguments to dput-ng's dcut commands
local -a opts
case ${line[1]} in
(cancel)
# dcut cancel arguments
opts=(
'(-f --filename)'{-f,--filename}'[.changes file name of the upload to
be cancelled]:file name:_files -g"*.changes(-.)"'
)
;;
(dm)
# dcut dm arguments
opts=(
'--uid[full name and address or GPG fingerprint of the Debian
Maintainer]'
'*--allow[grant permission to upload a source package]:source package'
'*--deny[remove permission to upload a source pckage]:source package'
)
;;
Bug#699851: zsh: please add completion for dcut
Sorry, I forgot to include the definition for _dput_hosts. Maybe the
whole thing should be merge into the completion for dput so that the
code can be reused.
Regards
--
Sebastian Ramacher
#compdef dcut
# TODO: dcut supports two ways to be called:
# * dcut HOST COMMAND ...
# * dcut COMMAND ...
# So ideally, if the first argument is completed, both commands and hosts should
# be offered. If host is given, the second argument should be completed as
# command and if not, it should be completed as command specific option.
function _dput_hosts() {
local expl
if ( [[ ${+_dput_cfhosts} -eq 0 ]] || _cache_invalid dputhosts ) && !
_retrieve_cache dputhosts; then
local cmd
if _pick_variant dputng="usage: dput" dput -H ; then
cmd=(dirt hosts)
else
cmd=(dput -H)
fi
_dput_cfhosts=(${${(M)${(f)"$($cmd)"}:#*=>*}/ =>*/})
_store_cache dputhosts _dput_cfhosts
fi
_wanted dputhosts expl 'target host' compadd -a _dput_cfhosts
}
function _dcut_commands() {
local -a cmds
if _pick_variant dcutng="usage: dcut" dcut -v ; then
cmds=(
dm:'manage Debian Maintainer permissions'
break-the-archive:'break the archive'
reschedule:'reschedule a deferred upload'
cancel:'cancel a deferred upload'
rm:'remove a file from the upload queue'
upload:'upload a command file'
)
else
cmds=(
rm:'remove a file from the upload queue'
cancel:'cancel a deferred upload'
reschedule:'reschedule a deferred upload'
)
fi
_describe -t commands command cmds
}
function _dcut() {
local -a all_opts dcut_opts dcut_ng_opts
local state line context
local -A opt_args
local curcontext="${curcontext}"
all_opts=(
'(-c --config)'{-c,--config=}'[specify config file]:config file:_files'
'(-h --help)'{-h,--help}'[show help message and exit]'
'(-m --maintainer)'{-m,--maintainer=}'[use maintainer for upload field and
GPG key selection]:maintainer address'
'(-k --keyid)'{-k,--keyid}'[use key id for signing]:keyid'
'(-O --output)'{-O,--output=}'[write command file to file instead of
uploading]:output file:_files'
'(-P --passive)'{-P,--passive}'[use passive FTP for uploads]'
'(-v --version)'{-v,--version}'[show version information]'
': :_dcut_commands'
)
dcut_opts=(
'(-d --debug)'{-d,--debug}'[debug mode]'
'(-s --simulate)'{-s,--simulate}'[simulate an upload only]'
'(-i --input)'{-i,--input=}'[create commands file to remove every file
listed in the changes file]:changes file:_files -g"*.changes(-.)"'
'(-U --upload)'{-U,--upload=}'[upload commands file]:commands file:_files'
'(--host 1)'{--host=}'[upload to host if it is named like a
command]:host:_dput_hosts'
'*:: :->dcut_command_arguments'
)
dcut_ng_opts=(
'*'{-d,--debug}'[enable debug messages, repeat twice to increase the
verbosity level]'
'*'{-s,--simulate}'[simulate an upload only, repeat twice to increase level
of simulation]'
'*:: :->dcut_ng_command_arguments'
)
if _pick_variant dcutng="usage: dcut" dcut -v ; then
_arguments -C \
"$all_opts[@]" "$dcut_ng_opts[@]" && return
else
_arguments -C \
"$all_opts[@]" "$dcut_opts[@]" && return
fi
case $state in
(dcut_command_arguments)
# arguments to dcut commands
local -a opts
case ${line[1]} in
(cancel)
# dcut cancel arguments
opts=(
'1::changes file:_files -g"*.changes(-.)"'
)
;;
(reschedule)
# dcut reschedule arguments
opts=(
'1::changes file:_files -g"*.changes(-.)"'
'2::new delayed queue:(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)'
)
;;
(rm)
# dcut rm arguments
opts=(
'--searchdirs[search in all directores for the given files]'
'1::file to be deleted:_files'
)
;;
esac
_arguments "$opts[@]" && return
;;
(dcut_ng_command_arguments)
# arguments to dput-ng's dcut commands
local -a opts
case ${line[1]} in
(cancel)
# dcut cancel arguments
opts=(
'(-f --filename)'{-f,--filename}'[.changes file name of the upload to
be cancelled]:file name:_files -g"*.changes(-.)"'
)
;;
(dm)
# dcut dm arguments
opts=(
'--uid[full name and address or GPG fingerprint
Bug#699912: imview: dangerous use of strncpy
Source: imview
Version: 1.1.9c-9
Severity: important
Tags: patch
I had a quick look at some of the code of imview and noticed some code
snippets that use the result strncpy in a dangerous way. In
readUserPrefs one can smash the stack if either IMVIEWHOME or HOME have
contain more than DFLTSTRLEN characters since strncpy won't terminate
prefpath in that case.
I didn't check for more occurrences other than those fixed in the patch,
but there might be more.
Regards
--
Sebastian Ramacher
--- a/imview.cxx
+++ b/imview.cxx
@@ -1251,11 +1251,14 @@
// read the user preferences if present
if (((p = getenv("IMVIEWHOME")) != 0) || ((p = getenv("HOME")) != 0)) {
strncpy(prefpath, p, DFLTSTRLEN);
+ prefpath[DFLTSTRLEN - 1] = '\0';
+
// keep these potential paths as the install path
snprintf(installpath, DFLTSTRLEN, "%s%c%s", prefpath, PATHSEP, PrefPath);
} else {
snprintf(prefpath, DFLTSTRLEN, ".%c%s", PATHSEP, PrefPath); // look in the default installation directory (long shot)
strncpy(installpath, prefpath, DFLTSTRLEN);
+installpath[DFLTSTRLEN - 1] = '\0';
}
#ifdef MACOSX_CARBON
@@ -1274,7 +1277,8 @@
strcat(tmppath, "preferences");
dbgprintf("looking in %s\n", tmppath);
if (fileprefs->readprefs(tmppath)) {
- strcpy(currentprefspath, tmppath); // save the location of the prefs file
+ strncpy(currentprefspath, tmppath, DFLTSTRLEN); // save the location of the prefs file
+currentprefspath[DFLTSTRLEN - 1] = '\0';
break; // found preferences, finished
} else { // no joy there, try next string if possible
if (prefpath[i] != '\0') {
@@ -2056,6 +2060,7 @@
#ifdef MACOSX_CARBON
char AppContainerPath[DFLTSTRLEN];
strncpy(AppContainerPath, runningpath, DFLTSTRLEN);
+AppContainerPath[DFLTSTRLEN - 1] = '\0';
strncat(AppContainerPath, "/../Resources", DFLTSTRLEN);
clutpathlist[4] = AppContainerPath;
clutpathlist[5] = 0;
signature.asc
Description: Digital signature
Bug#699820: stack smashing when reading ics file
Control: tags -1 + patch
On 2013-02-05 11:01:39, Sang Kil Cha wrote:
> imview has stack smashing vulnerability when parsing ics header @
> io/readics.cxx:320
>
> /* get the filename from the ICS file */
>
> t = temp1;
> while (*bp != delim2)
> *t++ = *bp++;
The attached patch should fix this bug. It adds bounds checking for all
the parts that read in a way like that.
The provided file doesn't crash with the patch, but since I don't have
any ICS images, someone else should check if the patch doesn't break
anything.
Regards
--
Sebastian Ramacher
--- a/io/readics.cxx
+++ b/io/readics.cxx
@@ -273,6 +273,13 @@
/* get the length of the ICS file and rewind */
length = (unsigned int)lseek(fd,0L,2);
lseek(fd,0L,0);
+
+/* the first two characters are the seperators */
+if (length < 2)
+{
+ close(fd);
+ return -4;
+}
/* allocate space for all data from the ICS file */
if ((buffer1 = (char *)malloc(length)) == NULL)
@@ -321,10 +328,15 @@
delim1 = *bp++; /* field delimiter */
delim2 = *bp++; /* record delimiter */
t = temp1;
-
+
+size_t bread = 0;
+
/* check if written by ICS */
-while (*bp != delim2)
- *t++ = *bp++;
+while (*bp != delim2 && bread < 3 && bp != end)
+{
+ *t++ = *bp++;
+ ++bread;
+}
bp++;
*t = '\0';
if (strncmp(temp1,"ICS",3) && strncmp(temp1,"ics",3))
@@ -337,13 +349,18 @@
/* get the filename from the ICS file */
t = temp1;
-while (*bp != delim2)
- *t++ = *bp++;
+bread = 0;
+while (*bp != delim2 && bread < sizeof(temp1) - 1 && bp != end)
+{
+ *t++ = *bp++;
+ ++bread;
+}
bp++;
*t = '\0';
t = strchr(temp1,delim1);
-strcpy(icsheader->filename,t);
+strncpy(icsheader->filename,t, FILENAME_SIZE);
+icsheader->filename[FILENAME_SIZE - 1] = '\0';
*t = '\0';
if (strcmp(temp1,"filename"))
@@ -360,18 +377,27 @@
{
/* get the next record into temp1 */
t = temp1;
- while (*bp != delim2 && bp < end) /* dont read beyond EOF */
- *t++ = *bp++;
+ bread = 0;
+ while (*bp != delim2 && bp < end && bread < sizeof(temp1) - 1) /* dont read beyond EOF */
+ {
+*t++ = *bp++;
+++bread;
+ }
bp++;
*t = '\0';
/* get the category into temp2 */
+ bread = 0;
t = temp1;
tg = temp2;
- while (*t != delim1)
+ while (*t != delim1 && bread < sizeof(temp1) - 1)
+ {
*tg++ = *t++;
+ ++bread;
+ }
t++;
*tg = '\0';
+ ++bread;
/* check if it is one of the decodable categories */
cat = 0;
@@ -388,10 +414,14 @@
}
/* get the next field from this record */
tg = temp2;
- while (*t != delim1)
+ while (*t != delim1 && bread < sizeof(temp1) - 1)
+ {
*tg++ = *t++;
+ ++bread;
+ }
t++;
*tg = '\0';
+ ++bread;
/* find this item in the keyword table */
for (i = 0; i < kwrds; i++)
@@ -415,10 +445,14 @@
break;
}
tg = temp2;
- while (*t != '\0')
- *tg++ = *t++;
+ while (*t != '\0' && bread < sizeof(temp1) - 1)
+ {
+*tg++ = *t++;
+++bread;
+ }
*tg = '\0';
t++;
+ ++bread;
icsheader->parameters = atoi(temp2);
if (icsheader->parameters > MAXDIM)
{ /* if necessary change MAXDIM in ics.h */
@@ -444,11 +478,15 @@
for (i = 0; i < icsheader->parameters; i++)
{
tg = temp2;
- while (*t != delim1 && *t != '\0')
+ while (*t != delim1 && *t != '\0' && bread < sizeof(temp1) - 1)
+{
*tg++ = *t++;
+++bread;
+}
*tg = '\0';
t++;
- strcpy(icsheader->order[i],temp2);
+ strncpy(icsheader->order[i],temp2, ORDER_SIZE);
+icsheader->order[i][ORDER_SIZE - 1] = '\0';
}
icsheader->valid_order = TRUE;
break;
@@ -468,10 +506,14 @@
for (i = 0; i < icsheader->parameters; i++)
{
tg = temp2;
- while (*t != delim1 && *t != '\0')
+ while (*t != delim1 && *t != '\0' && bread < sizeof(temp1) - 1)
+{
*tg++ = *t++;
+++bread;
+}
*tg = '\0';
t++;
+++bread;
icsheader->sizes[i] = atoi(temp2);
}
icsheader->valid_sizes = TRUE;
@@ -484,11 +526,16 @@
break;
}
tg = temp2;
- while (*t != '\0')
- *tg++ = *t++;
+ while (*t != '\0' && bread < sizeof(temp1) - 1)
+ {
+ *tg++ = *t++;
+++bread;
+ }
*tg = '\0';
t++;
- strcpy(icsheader->coord,temp2);
+ ++bread;
+ strncpy(
Bug#555893: O: libdiscid -- Library for creating MusicBrainz DiscIDs
Control: retitle -1 ITA: libdiscid -- Library for creating MusicBrainz DiscIDs Control: owner -1 ! I'll adopt libdiscid since once of its reverse dependencies is gnome-mplayer. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#687538: done
Hi Holger, On 2013-02-08 14:34:59, Holger Levsen wrote: > please check http://bugs.debian.org/687538 it seems you closed the wrong bug > in your gnome-mplayer upload to experimental... yes, I know. I mistyped the bug number in the changelog. That's why I've sent [1] some minutes after the upload to remove the indication that 687538 was fixed in gnome-mplayer. Cheers [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;bug=687538 -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
On 2013-02-08 23:44:59, Francesco Poli wrote: > > According to upstream's answer, this is not going to happen. Since I'm > > not going to work on this either, let's tag the bug wontfix. > > I am not sure I understand the answer from upstream. > It seems to be claimed that what I would like to get is simply obtained > by leaving blank settings in gnome-mplayer preferences. > > But this does not seem to work for all mplayer settings: for instance, > how can I convince gnome-mplayer to use whatever initial volume is > configured in ~/.mplayer/config (20 % in my case)? > > $ cat .mplayer/config > [default] > ao=jack,alsa > volume=20 > vo=xv > vf=screenshot > > I haven't found any option for the initial volume, so I couldn't leave > its value blank... Well, there is no option for the intial volume and there is nothing to leave blank. He was talking about the video output. The volume is controlled with the volume control right to the timeline. I must admit that gnome-mplayer should at least save the volume setting since it's always 100% on start. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
On 2013-02-08 23:20:12, Francesco Poli wrote: > Please note that I have the "Remember Window Size and Position" setting > unchecked in gnome-mplayer preferences. What about "Resize window when new video is loaded"? Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700187: bpython: please build and ship translation files
Source: bpython Version: 0.11-1 Severity: wishlist Tags: l10n bpython includes translation files for es_ES, it_IT and nl_NL. Please build and ship them in the binary package. python-babel is required to build them. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
Control: clone -1 -2 Control: retitle -2 gnome-mplayer: please add option for initial volume Control: tags -2 = upstream Control: forwarded -2 https://code.google.com/p/gnome-mplayer/issues/detail?id=671 On 2013-02-09 12:11:45, Francesco Poli wrote: > On Sat, 9 Feb 2013 01:03:13 +0100 Sebastian Ramacher wrote: > > > On 2013-02-08 23:44:59, Francesco Poli wrote: > [...] > > > I haven't found any option for the initial volume, so I couldn't leave > > > its value blank... > > > > Well, there is no option for the intial volume and there is nothing to leave > > blank. He was talking about the video output. > > > > The volume is controlled with the volume control right to the timeline. I > > must > > admit that gnome-mplayer should at least save the volume setting since it's > > always 100% on start. > > There seems to be a "Remember last software volume level" option, but: > > A) it can only be enabled if "MPlayer Software Volume Control Enabled" > is checked (and I have no idea what this other option means... could > you please clarify? the man page does explain much) This option corresponds to mplayer's --softvol flag: --softvol Force the use of the software mixer, instead of using the sound card mixer > B) what I would like to have is not an initial volume equal to the > value I adjusted last time I quit the program; I instead would like to > have a fixed initial volume level (like, for instance, 20 %) and then > adjust it depending on the video I am watching > > There is a "--volume" command-line option that lets me set an initial > volume level (in percentage). Hence, if I issue the following command: > > $ gnome-mplayer --volume 20 some-video.ogv > > I get whatever initial volume I want, but: > > A) I have to type this command-line option each time > > B) I do not know how to pass this command-line option to gnome-mplayer > when it is used inside my web browser (gecko-mediaplayer plug-in) Let's create a new bug for this. Cloned and forwarded. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
On 2013-02-09 19:31:28, Francesco Poli wrote: > On Sat, 9 Feb 2013 18:34:53 +0100 Sebastian Ramacher wrote: > > [...] > > On 2013-02-09 12:11:45, Francesco Poli wrote: > [...] > > > A) it can only be enabled if "MPlayer Software Volume Control Enabled" > > > is checked (and I have no idea what this other option means... could > > > you please clarify? the man page does explain much) > > > > This option corresponds to mplayer's --softvol flag: > > > > --softvol > > Force the use of the software mixer, instead of using the > > sound card mixer > > Thanks for the explanation: it's a little bit clearer now, even though > I am not sure I fully understand its implications. > For instance: I use the jack AO, hence I think that everything gets > mixed by jackd before being sent to the sound card, and I don't know > how mplayer or gnome-mplayer can interfere with this... With the software mixer enabled, mplayer applies the selected volume itself instead of relying on the sound card. This is implicitly enabled for all audio outputs except for those that have (alsa) appended to their name or PulseAudio. Using these without the software mixer causes the system volume to be changed (if I instead upstream's answer correctly). Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699393: gnome-mplayer: starts with zero height canvas instead of normal (1:1) size
On 2013-02-09 12:29:58, Francesco Poli wrote: > On Sat, 9 Feb 2013 01:08:33 +0100 Sebastian Ramacher wrote: > > > On 2013-02-08 23:20:12, Francesco Poli wrote: > > > Please note that I have the "Remember Window Size and Position" setting > > > unchecked in gnome-mplayer preferences. > > > > What about "Resize window when new video is loaded"? > > It is unchecked. > I've just tried to check it, but the result is exactly the same: > gnome-mplayer often starts with zero-height canvas, as if it were > genuinely convinced that the video had a zero (or maybe 1) pixel > height. > > Nonetheless, it says: > > [...] > GMLIB-Message: VO: [xv] 400x304 => 400x304 Planar YV12 > GMLIB-Message: media_loaded: position=0.000 length=772.160 start_time=0.000 > run_time=0.000 volume=1.00 player=running media=play > uri=file:///.../voyage.ogv > GMLIB-Message: in media state change with state = play dontplaynext = 0 > GMLIB-Message: trying to disable screensaver > GMLIB-Message: ERROR: Failed to get value of property 'sub_source'. > GMLIB-Message: current size = 416 x 1 > GMLIB-Message: Changing window size to 400 x 304 visible = true > > which is not true, since the canvas is still zero-height. > > As soon as I hit [Ctrl+1], the canvas is correctly re-sized and I get: > > GMLIB-Message: trying to disable screensaver > GMLIB-Message: current size = 0 x 0 > GMLIB-Message: Changing window size to 400 x 304 visible = true > > This time gnome-mplayer is telling me the truth, as the video is really > 400 x 304 (confirmed by taking screenshots) and the canvas seems to be > correctly sized. > > By the way, can you reproduce the bug, or am I the only one with this > awkward issue?!? No, I've tried in multiple environments (default xfce, xfce + xmonad, gnome) and was unable to reproduce the problem. Could you try it with another desktop environment? I've seen a commit [1] related to the widget layout code. It talks about layout issues when playing audio files, but maybe there are some more problems with that code. It'd be great if you can also test if the problem persists with this patch applied. [2] Regards [1] https://code.google.com/p/gnome-mplayer/source/detail?r=2390 [2] Please let me know if I should prepare a package for testing. -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700203: giggle: wrong capitalization of GTK+ in Description
Package: giggle Version: 0.7-1~exp0 Severity: minor The Description mentions "Gtk" multiple times. This should be spelled "GTK+", as per Developers Reference 6.2.1. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700217: RFP: vim-youcompleteme -- fast, as-you-type, fuzzy-search code completion engine for vim
Package: wnpp Severity: wishlist * Package name: vim-youcompleteme Version : n/a Upstream Author : Val Markovic * URL : http://valloric.github.com/YouCompleteMe/ * License : GPL3+ Programming Lang: Python, C++ Description : fast, as-you-type, fuzzy-search code completion engine for vim Quoting from the site: "YouCompleteMe is a fast, as-you-type, fuzzy-search code completion engine for Vim. It has two completion engines: an identifier-based engine that works with every programming language and a semantic, Clang-based engine that provides semantic code completion for C/C++/Objective-C/Objective-C++." The author also claims that "YCM obsoletes the following Vim plugins because it has all of their features plus extra: clang_complete, AutoComplPop, Supertab, neocomplcache". Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699255: ruby-activeresource-2.3: diff for NMU version 2.3.14-2.1
Control: tags -1 + patch pending
Dear maintainer,
I've prepared an NMU for ruby-activeresource-2.3 (versioned as 2.3.14-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
--
Sebastian Ramacher
diff -Nru ruby-activeresource-2.3-2.3.14/debian/changelog ruby-activeresource-2.3-2.3.14/debian/changelog
--- ruby-activeresource-2.3-2.3.14/debian/changelog 2012-06-29 20:17:48.0 +0200
+++ ruby-activeresource-2.3-2.3.14/debian/changelog 2013-02-10 22:46:41.0 +0100
@@ -1,3 +1,13 @@
+ruby-activeresource-2.3 (2.3.14-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/patches/0003-remove-test-for-XML-YAML-parsing.patch: Backport patch
+from upstream to disable test for XML YAML parsing. XML YAML parsing has
+been removed in ruby-activesupport-2.3/2.3.14-5 to fix CVE-2013-0156.
+(Closes: #699255)
+
+ -- Sebastian Ramacher Sun, 10 Feb 2013 22:46:39 +0100
+
ruby-activeresource-2.3 (2.3.14-2) unstable; urgency=low
* Team upload.
diff -Nru ruby-activeresource-2.3-2.3.14/debian/patches/0003-remove-test-for-XML-YAML-parsing.patch ruby-activeresource-2.3-2.3.14/debian/patches/0003-remove-test-for-XML-YAML-parsing.patch
--- ruby-activeresource-2.3-2.3.14/debian/patches/0003-remove-test-for-XML-YAML-parsing.patch 1970-01-01 01:00:00.0 +0100
+++ ruby-activeresource-2.3-2.3.14/debian/patches/0003-remove-test-for-XML-YAML-parsing.patch 2013-02-10 22:44:32.0 +0100
@@ -0,0 +1,48 @@
+Description: Remove test for XML YAML parsing
+ The support for YAML parsing in XML has been removed from Active Support
+ since it introduced an security risk (CVE-2013-0156).
+Origin: backport, https://github.com/rails/activeresource/commit/a0589575
+Last-Update: 2013-02-10
+
+--- a/test/base_test.rb
b/test/base_test.rb
+@@ -49,25 +49,11 @@
+:children => [{:name => 'Natacha'}]},
+ {:name => 'Milena',
+:children => []}]}]}.to_xml(:root => 'customer')
+-# - resource with yaml array of strings; for ActiveRecords using serialize :bar, Array
+-@marty = <<-eof.strip
+-
+-
+-5
+-Marty
+----
+- - \"red\"
+- - \"green\"
+- - \"blue\"
+-
+-
+-eof
+
+ ActiveResource::HttpMock.respond_to do |mock|
+ mock.get"/people/1.xml",{}, @matz
+ mock.get"/people/2.xml",{}, @david
+ mock.get"/people/6.json", {}, @joe
+- mock.get"/people/5.xml",{}, @marty
+ mock.get"/people/Greg.xml", {}, @greg
+ mock.get"/people/4.xml",{'key' => 'value'}, nil, 404
+ mock.put"/people/1.xml",{}, nil, 204
+@@ -1075,13 +1061,4 @@
+ end
+ end
+
+- def test_load_yaml_array
+-assert_nothing_raised do
+- marty = Person.find(5)
+- assert_equal 3, marty.colors.size
+- marty.colors.each do |color|
+-assert_kind_of String, color
+- end
+-end
+- end
+ end
diff -Nru ruby-activeresource-2.3-2.3.14/debian/patches/series ruby-activeresource-2.3-2.3.14/debian/patches/series
--- ruby-activeresource-2.3-2.3.14/debian/patches/series 2012-02-02 23:56:24.0 +0100
+++ ruby-activeresource-2.3-2.3.14/debian/patches/series 2013-02-10 22:29:36.0 +0100
@@ -1,2 +1,3 @@
0001-comment_out_failing_upstream_tests.patch
0002-require_abstract_unit_needs_test_directory.patch
+0003-remove-test-for-XML-YAML-parsing.patch
signature.asc
Description: Digital signature
Bug#700338: unblock: imview/1.1.9c-11
On 2013-02-11 20:43:08, Julien Cristau wrote: > On Mon, Feb 11, 2013 at 20:15:21 +0100, Anton Gladky wrote: > > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Please unblock package imview > > > > the version fixes RC-Bug #699820 (security issue) > > and FTBFS on kFreeBSD-systems (it was detected after > > the version 1.1.9c-10 uploaded). > > > > unblock imview/1.1.9c-11 > > The patch from -10 is horrible... I was told it also wasn't tested on > real ics images. Do we actually need to keep this package? It's also wrong. I looked over it once again and noticed too many mistakes. In my opinion it should be reverted for now until there is a working fix for that issue. In the meanwhile I've also found some ics images in the libics source package. There is test/testim_c.ics and the corresponding .ids file. The thing is that I can't even open the file with the imview version from wheezy. With the patch imview fails differenctly but still doesn't display the image. So instead of fixing the ICS support I'd just drop it and if there is real interest in imview and the capability to read ICS files, the code should be rewritten to use libics instead. But that's clearly something for jessie. I'm sorry for this horrible patch. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700366: libdiscid: New upstream release: 0.3.2
Control: reassign -1 src:libdiscid On 2013-02-12 04:34:19, Johannes Dewender wrote: > Libdiscid 0.3.2 is available, see: > http://musicbrainz.org/doc/libdiscid > > Changes include: > > - ISRC and MCN support on Linux > - updated docs, created INSTALL file > - fix distribution so it works for autotools AND cmake Thanks for letting us know. I will package the new version soon. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700338: unblock: imview/1.1.9c-11
On 2013-02-12 00:57:50, Sebastian Ramacher wrote: > In the meanwhile I've also found some ics images in the libics source > package. There is test/testim_c.ics and the corresponding .ids file. > The thing is that I can't even open the file with the imview version > from wheezy. With the patch imview fails differenctly but still doesn't > display the image. If the sign of the representation in testim_c.isc is changed to signed, imview from wheezy is able to display the image. -11 fails to do so. > So instead of fixing the ICS support I'd just drop it and if there is > real interest in imview and the capability to read ICS files, the code > should be rewritten to use libics instead. But that's clearly something > for jessie. > > I'm sorry for this horrible patch. I'll prepare a new and hopefully much saner patch. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700338: ICS
On 2013-02-12 20:57:21, Anton Gladky wrote:
> PS I did not upload a new version of the package.
> Waiting for opinions on the patch or a new patch
> from Sebastian, if it will be approved.
Please find attached the new patch. It should be less horrible then
the first, broken patch.
Due to the lack of ICS images, the patch has only been tested with the
ICS images from libics.
Regards
--
Sebastian Ramacher
diff --git a/io/readics.cxx b/io/readics.cxx
index 67c57cd..b9a8625 100644
--- a/io/readics.cxx
+++ b/io/readics.cxx
@@ -240,14 +240,12 @@ static int read_ics_header(char *filename, /* input filename */
**/
int fd, cat;
-unsigned int length, n_read, ui;
-char *buffer1, *buffer2, *end;
-char temp1[100],temp2[100];
+unsigned int length, ui;
+char *buffer1;
int i;
-char *t, *tg, *bp;
-char delim1, delim2;
+char delim1[2] = { '\0' }, delim2[2] = { '\0' };
static int kwrds = 14;
-static char *keywrdtable[] =
+static const char *keywrdtable[] =
{
"parameters",
"order",
@@ -264,40 +262,62 @@ static int read_ics_header(char *filename, /* input filename */
"byte_order",
"SCIL_TYPE"
};
+/* expected categories of the keywords */
+static const int expected_category[] = {
+ 1, 1, 1, 1, 1,
+ 2, 2, 2,
+ 3, 3, 3, 3,
+ 2, 2
+};
/* make the proper filename and open the ICS file */
-strcpy(temp1,filename);
-strcat(temp1,".ics");
-if ((fd = open(temp1,O_RDONLY)) < 0) return(-2);
+char* path = NULL;
+if (asprintf(&path, "%s.ics", filename) == -1) {
+ return -1;
+}
+
+fd = open(path,O_RDONLY);
+free(path);
+if (fd < 0) {
+ return(-2);
+}
/* get the length of the ICS file and rewind */
length = (unsigned int)lseek(fd,0L,2);
lseek(fd,0L,0);
+/* the first two characters are the seperators */
+if (length < 2)
+{
+ close(fd);
+ return -4;
+}
+
/* allocate space for all data from the ICS file */
-if ((buffer1 = (char *)malloc(length)) == NULL)
+if ((buffer1 = (char *)malloc(length - 1)) == NULL)
{
close(fd);
return(-1);
}
-/* allocate space for the unresolved data from the ICS file */
-if ((buffer2 = (char *)malloc(length)) == NULL)
+/* read delimiters */
+if (read(fd, delim1, 1) != 1 || read(fd, delim2, 1) != 1)
{
close(fd);
free(buffer1);
- return(-1);
+ return(-3);
}
+length -= 2;
/* read the data into buffer1 and close the file */
-if ((n_read = read(fd,buffer1,length)) != length)
+if (read(fd,buffer1,length) != length)
{
close(fd);
free(buffer1);
- free(buffer2);
return(-3);
}
close(fd);
+buffer1[length] = '\0';
/* initialisations */
icsheader->valid_filename = FALSE;
@@ -315,391 +335,277 @@ static int read_ics_header(char *filename, /* input filename */
icsheader->valid_compression = FALSE;
icsheader->valid_byteorder = FALSE;
icsheader->valid_SCIL_TYPE = FALSE;
-bp = buffer1;
-end = bp + length; /* EOF */
-*buffer2 = '\0'; /* initially empty */
-delim1 = *bp++; /* field delimiter */
-delim2 = *bp++; /* record delimiter */
-t = temp1;
/* check if written by ICS */
-while (*bp != delim2)
- *t++ = *bp++;
-bp++;
-*t = '\0';
-if (strncmp(temp1,"ICS",3) && strncmp(temp1,"ics",3))
+char* record_saveptr = NULL;
+char* record = strtok_r(buffer1, delim2, &record_saveptr);
+if (record == NULL)
+{
+ free(buffer1);
+ return -4;
+}
+
+if (strncmp(record,"ICS",3) && strncmp(record,"ics",3))
{
free(buffer1);
- free(buffer2);
return(-4);
}
/* get the filename from the ICS file */
+record = strtok_r(NULL, delim2, &record_saveptr);
+if (record == NULL)
+{
+ free(buffer1);
+ return -4;
+}
-t = temp1;
-while (*bp != delim2)
- *t++ = *bp++;
-bp++;
-*t = '\0';
-
-t = strchr(temp1,delim1);
-strcpy(icsheader->filename,t);
-*t = '\0';
-
-if (strcmp(temp1,"filename"))
+char* field_saveptr = NULL;
+char* field = strtok_r(record, delim1, &field_saveptr);
+if (strcmp(field, "filename"))
{
free(buffer1);
- free(buffer2);
return(-5);
}
+
+field = strtok_r(NULL, delim1, &field_saveptr);
+if (field == NULL)
+{
+ free(buffer1);
+ return -4;
+}
+
+strncpy(icsheader->filename, field, FILENAME_SIZE);
+icsheader->filename[FILENAME_SIZE - 1] = '\0';
icsheader->valid_filename = TRUE;
/* check the following records one by one and try to resolve
Bug#700671: ruby: breaks squeeze->wheezy upgrade if apt-listbugs/0.1.3 is installed
Package: ruby Version: 4.9 Severity: serious Justification: breaks squeeze->wheezy upgrades The transition of the default version from ruby1.8 to ruby1.9.1 causes the upgrade from squeeze to wheezy to fail if apt-listbugs is installed. After replacing squeeze with wheezy in /etc/apt/sources.list and a successful 'apt-get update' and 'apt-get install dpkg apt', 'apt-get [upgrade|install|dist-upgrade]' all fail with: /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- gettext (LoadError) from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require' from /usr/sbin/apt-listbugs:240:in `' E: Sub-process /usr/sbin/apt-listbugs apt || exit 10 returned an error code (10) E: Failure running script /usr/sbin/apt-listbugs apt || exit 10 'apt-get install dpkg apt' causes ruby to be installed and thus /usr/bin/ruby points to ruby1.9.1 afterwards. However, ruby-gettext, which provides the gettext module for ruby1.9.1, doesn't get installed. Since /usr/bin/apt-listbugs has #!/usr/bin/ruby as shebang, apt-listbugs is then executed with ruby1.9.1 and fails with the error message above. apt-listbugs's shebang has been changed to #/usr/bin/ruby1.8 in 0.1.6. So I think that ruby should gain a Breaks: apt-listbugs (<< 0.1.6) to force the upgrade of apt-listbugs if ruby is installed. I'm filing this bug with severity serious since it breaks upgrades from squeeze to wheezy. If my analysis of this bug is wrong, please reassign it to the correct package and change the severity accordingly. I've attached the log of performing the upgrade to wheezy in a squeeze chroot which has apt-listbugs installed. Regards -- Sebastian Ramacher squeeze-to-wheezy-update.log.xz Description: Binary data signature.asc Description: Digital signature
Bug#700809: python2.7: renders python2.7-dbg (<< 2.7.3.1) unusable, causes FTBFS
Package: python2.7
Version: 2.7.3-2
Severity: serious
The following change in 2.7.3-2 break python2.7-dbg 2.7.3-1 and
earlier versions:
python2.7 (2.7.3-2) unstable; urgency=low
...
* Backport issue #13150: sysconfig no longer parses the Makefile and config.h
files when imported, instead doing it at build time. This makes importing
sysconfig faster and reduces Python startup time by 20%.
...
python2.7-dbg doesn't have _sysconfigdata_d so running
python2.7-dbg fails with:
Traceback (most recent call last):
File "/usr/lib/python2.7/site.py", line 562, in
main()
File "/usr/lib/python2.7/site.py", line 544, in main
known_paths = addusersitepackages(known_paths)
File "/usr/lib/python2.7/site.py", line 271, in addusersitepackages
user_site = getusersitepackages()
File "/usr/lib/python2.7/site.py", line 246, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
File "/usr/lib/python2.7/site.py", line 236, in getuserbase
USER_BASE = get_config_var('userbase')
File "/usr/lib/python2.7/sysconfig.py", line 591, in get_config_var
return get_config_vars().get(name)
File "/usr/lib/python2.7/sysconfig.py", line 490, in get_config_vars
_init_posix(_CONFIG_VARS)
File "/usr/lib/python2.7/sysconfig.py", line 374, in _init_posix
from _sysconfigdata import build_time_vars
File "/usr/lib/python2.7/_sysconfigdata.py", line 4, in
from _sysconfigdata_d import *
ImportError: No module named _sysconfigdata_d
Since python2.7-dbg 2.7.3-1 depends on python2.7 (>= 2.7.3-1), python2.7
should have a Breaks on python2.7-dbg (<< 2.7.3-2) so that python2.7-dbg
isn't rendered unusable by upgrading python2.7 without upgrading
python2.7-dbg to a version >= 2.7.3-2.
It might be also a good idea to change python2.7-dbg's dependency on
python2.7 to (= ${binary:Version}) as it's already done in experimental.
(I've observed this issue because of the build failure of python-crypto
2.6-4 on the ia64 buildd which has python2.7 2.7.3-5 and python2.7-dbg
2.7.3-1 installed [1])
Regards
[1]
https://buildd.debian.org/status/fetch.php?pkg=python-crypto&arch=ia64&ver=2.6-4&stamp=1361116491
--
Sebastian Ramacher
signature.asc
Description: Digital signature
Bug#700855: pyrrd: tests moved to new location
Source: pyrrd Version: 0.1.0-1 Severity: normal pyrrd tries to run the test suite with - PYTHONPATH=build/lib/ python test/test_all.py test/test_all.py doesn't exist anymore. The test suite can now be run with python -m pyrrd.rrd. Please also run for all supported Python versions and don't ignore test failures. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700782: [Python-modules-team] Bug#700782: python3-cxx-dev: unhandled symlink to directory conversion: /usr/include/python3.2
Control: tags -1 + moreinfo Hi Andreas, On 2013-02-17 15:02:05, Andreas Beckmann wrote: > Package: python3-cxx-dev > Version: 6.2.4-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > an upgrade test with piuparts revealed that your package installs files > over existing symlinks and possibly overwrites files owned by other > packages. This usually means an old version of the package shipped a > symlink but that was later replaced by a real (and non-empty) > directory. This kind of overwriting another package's files cannot be > detected by dpkg. python3-cxx-dev installs files to /usr/include/python3.2/CXX and /usr/include/python3.2 is a symlink provided by python3.2-dev. However, no other package has ever shipped files in /usr/include/python3.2mu/CXX. Additionally /usr/include/python3.2 always has been a symlink to python3.2mu [1]. So it's neither an unhandled symlink to directory conversion nor overwriting files owned by other packages. Maybe I'm just unable to find the policy section that forbids installing to locations which contain symlinks in the dirname, so could you please clarify why you think this bug warrants severity serious? Or am I just missing something from the bug report? Regards [1] Except for some versions that were only in experimental (3.2~something) and the python3.2-dev's postinst has the code to handle the conversion. So that shouldn't be a problem for squeeze to wheezy upgrades. -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700782: python3-cxx-dev: unhandled symlink to directory conversion: /usr/include/python3.2
On 2013-02-20 00:19:31, Andreas Beckmann wrote: > > python3-cxx-dev installs files to /usr/include/python3.2/CXX and > > /usr/include/python3.2 is a symlink provided by python3.2-dev. However, > > no other package has ever shipped files in /usr/include/python3.2mu/CXX. > > Additionally /usr/include/python3.2 always has been a symlink to > > python3.2mu [1]. So it's neither an unhandled symlink to directory > > conversion nor overwriting files owned by other packages. > > Thanks for clarifying the actual situation. > So it's *just* installing over an existing symlink. Don't do this, it > will break in subtle ways. Is there a guarantee that python3.2-dev is > unpacked before python3-cxx-dev? (No, see below, I tried it.) What will > happen if python3.2-dev decides to point the symlink somewhere else? > Just install the files to the real location. > > > Maybe I'm just unable to find the policy section that forbids installing > > to locations which contain symlinks in the dirname, so could you please > > clarify why you think this bug warrants severity serious? Or am I just > > missing > > something from the bug report? > > So far it is not explicitly forbidden, but considered bad practice. See > e.g. http://lists.debian.org/87ehlevcrf@windlord.stanford.edu Sure, I wasn't questioning that it's a bad idea. From the original bug report it just wasn't clear to me why this would be an issue. > # dpkg --unpack /var/cache/apt/archives/glx-diversions_0.2.2_amd64.deb ^^ I guess that should be python3-cxx-dev_6.2.4-2_all.deb, shouldn't it? > # apt-get -f install > [...] > Setting up python3.2-dev (3.2.3-6) ... > WARNING: non-empty directory on upgrade: /usr/include/python3.2 > total 0 > drwxr-xr-x 3 root root 200 Feb 19 23:05 CXX > Setting up python3-dev (3.2.3-6) ... > Setting up python3-cxx-dev (6.2.4-2) ... > [...] > > # ls -lad /usr/include/python* > drwxr-xr-x 3 root root 60 Feb 19 23:05 /usr/include/python3.2 > drwxr-xr-x 2 root root 60 Feb 19 23:05 /usr/include/python3.2_d > drwxr-xr-x 2 root root 1900 Feb 19 23:06 /usr/include/python3.2mu > > Congratulations, now python*-dev* is borked. Thank you. So that's the bit that was missing from the original bug report. That makes it a lot clearer. Could you please check python3-bsddb3, python3-mpi4py, python3-numpy and python3-pygame? These packages also install stuff to /usr/include/python3.2. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#699695: gnome-mplayer: should read and use any mplayer configuration file
Hi, On 2013-02-20 23:04:06, Francesco Poli wrote: > Hello again, > since I am not satisfied with the "workaround" suggested by upstream > and mentioned in <http://bugs.debian.org/700189#64>, I am trying to see > whether I can come up with a patch that makes gnome-mplayer avoid > passing the "-volume" option to mplayer in certain situations. > > When I saw the "use_volume_option" variable in src/main.c:1309, > I thought I found the way to do it: it seemed that setting that > variable to FALSE could disable the use of the "-volume" option in the > mplayer command line. > > I tried to modify the src/main.c accordingly, but it seems to me that > the "use_volume_option" variable has no effect at all. > It is indeed 0 (checked with gdb), but the mplayer command line still > includes the "-volume" option... > Before this issue drives me completely crazy, could you please clarify > what's wrong in my reasoning? > Is the "use_volume_option" variable actually used for anything? > Is there an easy way to disable the passing of the "-volume" option to > mplayer (without a major code overhaul)? The options passed to mplayer are assembled in gmtk. The function you're looking for is launch_mplayer in src/gmtk_media_player.c. Just grep for "-volume" in that file. (I'm not sure if it's enough to just patch out "-volume". There is some interaction between the volume control widget and mplayer too.) Hope that helps -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#696973: RFS: mp3diags/1.0.12.079-1
Control: owner -1 ! Hi Josué, I had a look at your mp3diags package and found the following issue. Once the issues are fixed I'm happy to upload the package for you. On 2012-12-29 21:44:47, Josué Ortega wrote: > dget -x > http://mentors.debian.net/debian/pool/main/m/mp3diags/mp3diags_1.0.12.079-1.dsc * Please prepare an upload to experimental so that we can keep unstable clean until the release of wheezy. * -g is not passed to the compiler and thus DEB_BUILD_OPTIONS=nostrip is not supported. Please check Debian Policy §4.9.1 and §10.1. * The package is built without hardening flags. In particular lintian emits: W: mp3diags: hardening-no-relro usr/bin/mp3diags W: mp3diags: hardening-no-fortify-functions usr/bin/mp3diags Please build the package with hardening flags enabled and check the build log with blhc. The last two issues can be solved by using dpkg-buildflags directly or by including /usr/share/dpkg/buildflags.mk in debian/rules. dh_auto_* also set them in compat level 9. * The package fails to build twice in a row. Please have a look at the attached file for the log of the second build. The files dpkg-source is complaining about come from running cmake by dh_auto_configure. However, elsewhere qmake is used to build mp3diags. Please decide on one of these two build systems. If you choose qmake, note that debhelper supports qmake since 7.4.12. So removing the overrides for dh_auto_clean, dh_auto_build and passing -Sqmake to dh should be enough. * lintian also emits: W: mp3diags source: out-of-date-standards-version 3.9.3 (current is 3.9.4) I: mp3diags: spelling-error-in-binary usr/bin/mp3diags teH the Please fix these issues and ping me when you're done. One other thing: Vcs-* lists a collab-maint repo which has not been updated since the last upload by Alessio. It'd be great if you could push your work there. If you just don't have access to this repository, please say so. Cheers -- Sebastian Ramacher dpkg-buildpackage: source package mp3diags dpkg-buildpackage: source version 1.0.12.079-1 dpkg-buildpackage: source changed by Josue Ortega dpkg-buildpackage: host architecture amd64 dpkg-source --before-build mp3diags-1.0.12.079 fakeroot debian/rules clean dh clean --parallel dh_testdir -O--parallel debian/rules override_dh_auto_clean make[1]: Entering directory `/tmp/mp3diags-1.0.12.079' [ ! -f Makefile ] || /usr/bin/make clean make[2]: Entering directory `/tmp/mp3diags-1.0.12.079' cd src/ && /usr/bin/make -f Makefile clean make[3]: Entering directory `/tmp/mp3diags-1.0.12.079/src' /usr/bin/make -f Makefile.Release clean make[4]: Entering directory `/tmp/mp3diags-1.0.12.079/src' rm -f release/moc_AboutDlgImpl.cpp release/moc_AlbumInfoDownloaderDlgImpl.cpp release/moc_CommonData.cpp release/moc_ConfigDlgImpl.cpp release/moc_DebugDlgImpl.cpp release/moc_DirFilterDlgImpl.cpp release/moc_DiscogsDownloader.cpp release/moc_DoubleList.cpp release/moc_FileRenamerDlgImpl.cpp release/moc_FilesModel.cpp release/moc_ImageInfoPanelWdgImpl.cpp release/moc_LogModel.cpp release/moc_MainFormDlgImpl.cpp release/moc_MultiLineTvDelegate.cpp release/moc_MusicBrainzDownloader.cpp release/moc_NormalizeDlgImpl.cpp release/moc_NoteFilterDlgImpl.cpp release/moc_NotesModel.cpp release/moc_PaletteDlgImpl.cpp release/moc_RenamerPatternsDlgImpl.cpp release/moc_ScanDlgImpl.cpp release/moc_SessionEditorDlgImpl.cpp release/moc_SessionsDlgImpl.cpp release/moc_StreamsModel.cpp release/moc_TagEditorDlgImpl.cpp release/moc_TagEdtPatternsDlgImpl.cpp release/moc_TagReadPanel.cpp release/moc_TagWriter.cpp release/moc_ThreadRunnerDlgImpl.cpp release/moc_UniqueNotesModel.cpp release/moc_Widgets.cpp release/moc_ExportDlgImpl.cpp release/moc_FullSizeImgDlg.cpp rm -f release/qrc_Mp3Diags.cpp rm -f ui_About.h ui_AlbumInfoDownloader.h ui_Config.h ui_Debug.h ui_DirFilter.h ui_DoubleListWdg.h ui_FileRenamer.h ui_ImageInfoPanel.h ui_MainForm.h ui_Normalize.h ui_NoteFilter.h ui_Palette.h ui_Patterns.h ui_Scan.h ui_SessionEditor.h ui_Sessions.h ui_TagEditor.h ui_ThreadRunner.h ui_Export.h rm -f release/Helpers.o release/main.o release/DiscogsDownloader.o release/DoubleList.o release/FileEnum.o release/FileRenamerDlgImpl.o release/FilesModel.o release/Id3Transf.o release/Id3V230Stream.o release/Id3V240Stream.o release/Id3V2Stream.o release/ImageInfoPanelWdgImpl.o release/LogModel.o release/LyricsStream.o release/MainFormDlgImpl.o release/Mp3Manip.o release/Mp3TransformThread.o release/MpegFrame.o release/MpegStream.o release/MultiLineTvDelegate.o release/MusicBrainzDownloader.o release/NormalizeDlgImpl.o release/NoteFilterDlgImpl.o release/Notes.o release/NotesModel.o release/OsFile.o release/PaletteDlgImpl.o release/RenamerPatternsDlgImpl.o release/ScanDlgImpl.o release/SessionEditorDlgImpl.o release/SessionsDlgImpl.o release/SongInfoParser.o release/StoredSettings.o release/Stre
Bug#700786: sidplay-libs: diff for NMU version 2.1.1-13.1
Control: tags -1 + patch pending
Dear maintainer,
I've prepared an NMU for sidplay-libs (versioned as 2.1.1-13.1) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.
Regards
--
Sebastian Ramacher
diff -Nru sidplay-libs-2.1.1/debian/changelog sidplay-libs-2.1.1/debian/changelog
--- sidplay-libs-2.1.1/debian/changelog 2012-02-17 14:07:02.0 +0100
+++ sidplay-libs-2.1.1/debian/changelog 2013-02-25 18:30:05.0 +0100
@@ -1,3 +1,11 @@
+sidplay-libs (2.1.1-13.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * {libsidutils-dev,libresid-builder-dev}.preinst: Handle symlink to
+directory conversion. (Closes: #700786)
+
+ -- Sebastian Ramacher Mon, 25 Feb 2013 18:30:03 +0100
+
sidplay-libs (2.1.1-13) unstable; urgency=low
* Build hardsid on kFreeBSD as well (closes: #659276).
diff -Nru sidplay-libs-2.1.1/debian/libresid-builder-dev.preinst sidplay-libs-2.1.1/debian/libresid-builder-dev.preinst
--- sidplay-libs-2.1.1/debian/libresid-builder-dev.preinst 1970-01-01 01:00:00.0 +0100
+++ sidplay-libs-2.1.1/debian/libresid-builder-dev.preinst 2013-02-25 18:23:33.0 +0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+set -e
+
+# handle symlink to directory conversion (#700786)
+DOCDIR=/usr/share/doc/libresid-builder-dev
+if [ -L $DOCDIR ] ; then
+ rm $DOCDIR
+fi
+
+#DEBHELPER#
diff -Nru sidplay-libs-2.1.1/debian/libsidutils-dev.preinst sidplay-libs-2.1.1/debian/libsidutils-dev.preinst
--- sidplay-libs-2.1.1/debian/libsidutils-dev.preinst 1970-01-01 01:00:00.0 +0100
+++ sidplay-libs-2.1.1/debian/libsidutils-dev.preinst 2013-02-25 18:23:28.0 +0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+set -e
+
+# handle symlink to directory conversion (#700786)
+DOCDIR=/usr/share/doc/libsidutils-dev
+if [ -L $DOCDIR ] ; then
+ rm $DOCDIR
+fi
+
+#DEBHELPER#
signature.asc
Description: Digital signature
Bug#700786: libsidutils-dev: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Hi, On 2013-02-17 15:15:19, Andreas Beckmann wrote: > same problem in libresid-builder-dev, maybe other binary packages from > the same source, too. libsidplay2-dev is not affected since there was a typo in the command creating the link in d/rules: ln -s libsidplay2 debian/libsidplay-dev/usr/share/doc/libsidplay-dev Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700781: newt: diff for NMU version 0.52.14-11.1
Control: tags -1 + patch pending Dear maintainer, I've prepared an NMU for newt (versioned as 0.52.14-11.1) and uploaded it to DELAYED/1. Please feel free to tell me if I should delay it longer. Regards -- Sebastian Ramacher diff -Nru newt-0.52.14/debian/changelog newt-0.52.14/debian/changelog --- newt-0.52.14/debian/changelog 2012-06-15 15:41:04.0 +0200 +++ newt-0.52.14/debian/changelog 2013-02-25 19:58:45.0 +0100 @@ -1,3 +1,11 @@ +newt (0.52.14-11.1) unstable; urgency=low + + * Non-maintainer upload. + * python-newt-dbg.preinst: Handle symlink to directory conversion. (Closes: +#700781) + + -- Sebastian Ramacher Mon, 25 Feb 2013 19:58:40 +0100 + newt (0.52.14-11) unstable; urgency=low * Add Latvian translation. Closes: #674705. diff -Nru newt-0.52.14/debian/python-newt-dbg.preinst newt-0.52.14/debian/python-newt-dbg.preinst --- newt-0.52.14/debian/python-newt-dbg.preinst 1970-01-01 01:00:00.0 +0100 +++ newt-0.52.14/debian/python-newt-dbg.preinst 2013-02-25 19:50:46.0 +0100 @@ -0,0 +1,10 @@ +#!/bin/sh +set -e + +# handle symlink to directory conversion (#700781) +DOCDIR=/usr/share/doc/python-newt-dbg +if [ -L $DOCDIR ] ; then + rm $DOCDIR +fi + +#DEBHELPER# signature.asc Description: Digital signature
Bug#661342: python-gevent-dbg: Need to build debugging versions
Control: tags -1 + patch
On 2012-02-26 16:00:23, Matthias Urlichs wrote:
> The package python-gevent-dbg only contains the GDB symbols for the binary
> module.
>
> It also needs to contain the actual module, built with python-dbg.
> Otherwise it's impossible to run gevent under a debugging Python.
>
> $ python-dbg test/interactive/main.py
> Traceback (most recent call last):
> [...]
> File "/usr/lib/pymodules/python2.7/gevent/hub.py", line 6, in
> from gevent import core
> ImportError: /usr/lib/pymodules/python2.7/gevent/core.so: undefined symbol:
> Py_InitModule4_64
With the attached patch the extensions modules are also built for the
debug variants.
Regards
--
Sebastian Ramacher
diff -Nru python-gevent-0.13.6/debian/changelog
python-gevent-0.13.6/debian/changelog
--- python-gevent-0.13.6/debian/changelog 2012-11-12 23:09:04.0
+0100
+++ python-gevent-0.13.6/debian/changelog 2013-02-26 16:51:34.0
+0100
@@ -1,3 +1,10 @@
+python-gevent (0.13.6-1+nmu2) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Build extensions modules for debug variants too. (Closes: #661342)
+
+ -- Sebastian Ramacher Tue, 26 Feb 2013 16:42:01 +0100
+
python-gevent (0.13.6-1+nmu1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru python-gevent-0.13.6/debian/control
python-gevent-0.13.6/debian/control
--- python-gevent-0.13.6/debian/control 2011-05-17 16:45:37.0 +0200
+++ python-gevent-0.13.6/debian/control 2013-02-26 16:52:08.0 +0100
@@ -3,7 +3,8 @@
Maintainer: Örjan Persson
Uploaders: Andreas Schuldei
Build-Depends: debhelper (>= 7.0.50), python-support, python-all-dev,
libevent-dev (>= 1.4),
- python-greenlet | python-codespeak-lib (<< 1.0), python-sphinx
(>= 0.6)
+ python-greenlet | python-codespeak-lib (<< 1.0), python-sphinx
(>= 0.6),
+ python-all-dbg
Standards-Version: 3.9.0
Section: python
Homepage: http://www.gevent.org/
@@ -11,7 +12,7 @@
Package: python-gevent-dbg
Section: debug
Architecture: any
-Depends: ${misc:Depends}, python-gevent (= ${binary:Version})
+Depends: ${misc:Depends}, python-gevent (= ${binary:Version}),
${shlib:Depends}, python-dbg
Description: gevent is a coroutine-based Python networking library - debugging
symbols
gevent uses greenlet to provide a high-level synchronous API on top of
libevent event loop.
diff -Nru python-gevent-0.13.6/debian/python-gevent-dbg.install
python-gevent-0.13.6/debian/python-gevent-dbg.install
--- python-gevent-0.13.6/debian/python-gevent-dbg.install 1970-01-01
01:00:00.0 +0100
+++ python-gevent-0.13.6/debian/python-gevent-dbg.install 2013-02-26
16:45:17.0 +0100
@@ -0,0 +1 @@
+usr/lib/python2*/*-packages/gevent/*_d.so
diff -Nru python-gevent-0.13.6/debian/python-gevent.install
python-gevent-0.13.6/debian/python-gevent.install
--- python-gevent-0.13.6/debian/python-gevent.install 2011-05-17
16:45:37.0 +0200
+++ python-gevent-0.13.6/debian/python-gevent.install 2013-02-26
16:46:33.0 +0100
@@ -1 +1,2 @@
-usr/lib/*
+usr/lib/python2*/*-packages/gevent/*.py
+usr/lib/python2*/*-packages/gevent/*[!_][!d].so
signature.asc
Description: Digital signature
Bug#701739: RFS: rrep/1.3.4-1
On 2013-02-26 17:40:03, Arno Onken wrote: > dget -x http://mentors.debian.net/debian/pool/main/r/rrep/rrep_1.3.4-1.dsc > > More information about rrep can be obtained from > http://sourceforge.net/projects/rrep/ > > Changes since the last upload: > > * New upstream release (Closes: #701416) > * Changed Build-Depends debhelper to >= 9. > * Changed debian/compat to 9. > * Updated Standards-Version to 3.9.4. > * Fixed copyright license text. > * Changed Maintainer to Upstream-Contact field. > * Updated Format field. Looking at the diff for debian/copyright, the following change looks like an oversight: @@ -40,3 +33,8 @@ . On Debian GNU/Linux systems, the complete text of GNU Free Documentation License (v1.3) is in `/usr/share/common-licenses/GFDL-1.3'. + +Files: debian/* +Copyright: 2011, 2013 Arno Onken +License: GPL-3.0+ + [LICENSE TEXT] I guess you wanted to cover everything except doc/rrep.texi with the Files: * paragraph. You don't need the last paragraph in this case. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#701896: nzbget: new upstream release available
Package: nzbget Version: 0.7.0-2 Severity: wishlist Hi, several new versions have been released since 0.7.0. The current stable release is versioned as 9.1 [1]. It would be great if you could package the new version. Regards [1] http://sourceforge.net/apps/phpbb/nzbget/viewtopic.php?f=4&t=537 -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#701904: libpar2: add cancel support
Source: libpar2
Version: 0.2.1-1
Severity: wishlist
Tags: patch
nzbget 9.1 supports a time limit par-repair. For this feature nzbget
expects libpar2 to be patched with libpar2-0.2-cancel.patch, that is
shipped by nzbget. The patch is also available from here [1].
Regards
[1]
http://sourceforge.net/tracker/?func=detail&aid=2209488&group_id=30568&atid=399700
--
Sebastian Ramacher
diff -aud -U 5 ../libpar2-0.2-original/par2repairer.cpp ../libpar2-0.2/par2repairer.cpp
--- ../libpar2-0.2-original/par2repairer.cpp 2012-12-03 10:47:04.0 +0100
+++ ../libpar2-0.2/par2repairer.cpp 2012-12-03 10:48:13.0 +0100
@@ -50,10 +50,12 @@
outputbuffer = 0;
noiselevel = CommandLine::nlNormal;
headers = new ParHeaders;
alreadyloaded = false;
+
+ cancelled = false;
}
Par2Repairer::~Par2Repairer(void)
{
delete [] (u8*)inputbuffer;
@@ -404,10 +406,14 @@
{
cout << "Loading: " << newfraction/10 << '.' << newfraction%10 << "%\r" << flush;
progress = offset;
sig_progress.emit(newfraction);
+ if (cancelled)
+ {
+break;
+ }
}
}
// Attempt to read the next packet header
PACKET_HEADER header;
@@ -582,10 +588,15 @@
if (noiselevel > CommandLine::nlQuiet)
cout << "No new packets found" << endl;
delete diskfile;
}
+ if (cancelled)
+ {
+return false;
+ }
+
return true;
}
// Finish loading a recovery packet
bool Par2Repairer::LoadRecoveryPacket(DiskFile *diskfile, u64 offset, PACKET_HEADER &header)
@@ -831,26 +842,42 @@
// Load packets from each file that was found
for (list::const_iterator s=files->begin(); s!=files->end(); ++s)
{
LoadPacketsFromFile(*s);
+ if (cancelled)
+ {
+break;
+ }
}
delete files;
+if (cancelled)
+{
+ return false;
+}
}
{
string wildcard = name.empty() ? "*.PAR2" : name + ".*.PAR2";
list *files = DiskFile::FindFiles(path, wildcard);
// Load packets from each file that was found
for (list::const_iterator s=files->begin(); s!=files->end(); ++s)
{
LoadPacketsFromFile(*s);
+ if (cancelled)
+ {
+break;
+ }
}
delete files;
+if (cancelled)
+{
+ return false;
+}
}
return true;
}
@@ -864,13 +891,22 @@
// If the filename contains ".par2" anywhere
if (string::npos != filename.find(".par2") ||
string::npos != filename.find(".PAR2"))
{
LoadPacketsFromFile(filename);
+ if (cancelled)
+ {
+break;
+ }
}
}
+ if (cancelled)
+ {
+return false;
+ }
+
return true;
}
// Check that the packets are consistent and discard any that are not
bool Par2Repairer::CheckPacketConsistency(void)
@@ -1208,10 +1244,15 @@
// Start verifying the files
sf = sortedfiles.begin();
while (sf != sortedfiles.end())
{
+if (cancelled)
+{
+ return false;
+}
+
// Do we have a source file
Par2RepairerSourceFile *sourcefile = *sf;
// What filename does the file use
string filename = sourcefile->TargetFileName();
@@ -1560,10 +1601,14 @@
if (oldfraction != newfraction)
{
cout << "Scanning: \"" << shortname << "\": " << newfraction/10 << '.' << newfraction%10 << "%\r" << flush;
sig_progress.emit(newfraction);
+if (cancelled)
+{
+ break;
+}
}
}
// If we fail to find a match, it might be because it was a duplicate of a block
// that we have already found.
@@ -1649,10 +1694,15 @@
return false;
}
}
}
+ if (cancelled)
+ {
+return false;
+ }
+
// Get the Full and 16k hash values of the file
filechecksummer.GetFileHashes(hashfull, hash16k);
// Did we make any matches at all
if (count > 0)
@@ -2289,14 +2339,23 @@
if (oldfraction != newfraction)
{
cout << "Repairing: " << newfraction/10 << '.' << newfraction%10 << "%\r" << flush;
sig_progress.emit(newfraction);
+if (cancelled)
+{
+ break;
+}
}
}
}
+ if (cancelled)
+ {
+break;
+ }
+
++inputblock;
++inputindex;
}
}
else
@@ -2346,13 +2405,22 @@
if (oldfraction != newfraction)
{
cout << "Processing: " << newfraction/10 << '.' << newfraction%10 << "%\r" << flush;
sig_progress.emit(newfraction);
+ if (cancelled
Bug#707085: transition: gmtk
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, I'd like to request a slot for the transition of gmtk. libgmtk0 and libgmlib0 both bumped SONAME. gmtk and its reverse dependencies gnome-mplayer and gecko-mediaplayer are staged in experimental. No other packages are affected and thus this should only be a matter of uploading the versions of gmtk, gnome-mplayer and gecko-mediaplayer found in experimental to unstable. Regards Ben file: title = "gmtk"; is_affected = .build-depends ~ "libgmtk-dev" | .build-depends ~ "libgmlib-dev"; is_good = .depends ~ "libgmtk1" | .depends ~ "libgmlib1"; is_bad = .depends ~ "libgmtk0" | .depends ~ "libgmlib0"; -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707561: python-torctl: please drop unnecessary Depends on python-socksipy
Source: python-torctl Version: 20110618git-1 Severity: wishlist Hi, the code doesn't seem to use the socks module from python-socksipy at all. SocksiPy is only mentioned in a comment along the liens of "users of SocksiPy want to use this class". So please drop python-socksipy from Depends. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707563: python-stem: please drop unnecessary Depends on python-socksipy
Source: python-stem Version: 1.0.1-1 Severity: wishlist Hi, the socks module from python-socksipy is not used in python-stem. Please remove it from Depends. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#701393: gambas3: ftbfs with eglibc-2.17
Control: tags -1 + patch On 2013-02-23 11:34:53, Matthias Klose wrote: > /bin/bash ../../libtool --tag=CC --mode=compile x86_64-linux-gnu-gcc > -DHAVE_CONFIG_H -I. -I../..-I../../share -I../../gbx -D_REENTRANT > -I../../libltdl -pipe -Wall -Wno-unused-value -fsigned-char > -fvisibility=hidden -g -Os -MT gb_signal_la-csignal.lo -MD -MP -MF > .deps/gb_signal_la-csignal.Tpo -c -o gb_signal_la-csignal.lo `test -f > 'csignal.c' || echo './'`csignal.c > libtool: compile: x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. > -I../../share -I../../gbx -D_REENTRANT -I../../libltdl -pipe -Wall > -Wno-unused-value -fsigned-char -fvisibility=hidden -g -Os -MT > gb_signal_la-csignal.lo -MD -MP -MF .deps/gb_signal_la-csignal.Tpo -c > csignal.c -fPIC -DPIC -o .libs/gb_signal_la-csignal.o > csignal.c:45:17: error: conflicting types for 'siginfo_t' > struct siginfo siginfo_t; > ^ > In file included from /usr/include/signal.h:80:0, > from csignal.c:28: > /usr/include/x86_64-linux-gnu/bits/siginfo.h:127:5: note: previous > declaration of 'siginfo_t' was here >} siginfo_t __SI_ALIGNMENT; > ^ > csignal.c: In function 'Signal_Catch': > csignal.c:234:22: warning: assignment from incompatible pointer type [enabled > by default] > action.sa_sigaction = handle_signal; > ^ > make[6]: *** [gb_signal_la-csignal.lo] Error 1 > make[6]: Leaving directory `/«PKGBUILDDIR»/main/lib/signal' > make[5]: *** [all-recursive] Error 1 > make[5]: Leaving directory `/«PKGBUILDDIR»/main/lib' > make[4]: *** [all-recursive] Error 1 > make[4]: Leaving directory `/«PKGBUILDDIR»/main' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/«PKGBUILDDIR»/main' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/«PKGBUILDDIR»' > make[1]: *** [all] Error 2 > make: *** [build-stamp] Error 2 > dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 Please find attached a patch to fix this FTBFS. Regards -- Sebastian Ramacher diff -Nru gambas3-3.1.1/debian/changelog gambas3-3.1.1/debian/changelog --- gambas3-3.1.1/debian/changelog 2012-05-24 13:22:15.0 +0200 +++ gambas3-3.1.1/debian/changelog 2013-05-09 19:34:25.0 +0200 @@ -1,3 +1,10 @@ +gambas3 (3.1.1-2.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Fix FTBFS with eglibc-2.7. (Closes: #701393) + + -- Sebastian Ramacher Thu, 09 May 2013 19:34:24 +0200 + gambas3 (3.1.1-2) unstable; urgency=low * debian/control: diff -Nru gambas3-3.1.1/debian/patches/701393.patch gambas3-3.1.1/debian/patches/701393.patch --- gambas3-3.1.1/debian/patches/701393.patch 1970-01-01 01:00:00.0 +0100 +++ gambas3-3.1.1/debian/patches/701393.patch 2013-05-09 20:01:57.0 +0200 @@ -0,0 +1,15 @@ +Description: Fix FTBFS with eglic-2.17 +Author: Sebastian Ramacher +Last-Update: 2013-05-09 + +--- gambas3-3.1.1.orig/main/lib/signal/csignal.c gambas3-3.1.1/main/lib/signal/csignal.c +@@ -40,7 +40,7 @@ + #define SIGPWR -1 + #endif + +-#if !defined(OS_BSD) && !defined(OS_CYGWIN) ++#if !defined(OS_BSD) && !defined(OS_CYGWIN) && !defined(OS_LINUX) + typedef + struct siginfo siginfo_t; + #endif diff -Nru gambas3-3.1.1/debian/patches/series gambas3-3.1.1/debian/patches/series --- gambas3-3.1.1/debian/patches/series 2012-05-24 13:00:02.0 +0200 +++ gambas3-3.1.1/debian/patches/series 2013-05-09 19:38:36.0 +0200 @@ -1,2 +1,3 @@ detect_browser_debian dont_compile_examples +701393.patch signature.asc Description: Digital signature
Bug#707692: RM: secvpn -- ROM; not maintained any more
Control: reassign -1 ftp.debian.org On 2013-05-10 10:15:56, Schumacher, Bernd wrote: > Package: ftp.debian.org<ftp://ftp.debian.org> The pseudo-package name is only ftp.debian.org. Reassigning to ftp.debian.org. > Severity: normal > > Hello, > > Could you remove secvpn from unstable. > I do not use secvpn in any projects anymore and so I do not want to maintain > it anymore in releases following wheezy like jessie. > Actual users of secvpn should upgrade to openvpn which is a newer and better > solution. > > Regards > Bernd Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707399: gedit-valencia-plugin: FTBFS: GIRepository-2.0.gir:240.11-240.30: error: expected start element of `parameter'
On 2013-05-09 09:50:00, Lucas Nussbaum wrote: > Source: gedit-valencia-plugin > Version: 0.3.0-3.1 > Severity: serious > Tags: jessie sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20130509 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part: > > make[1]: Entering directory `/«PKGBUILDDIR»' > > m4 -DVERSION='0.3.0' valencia.plugin.m4 > valencia.plugin > > valac -X --shared -X -fPIC --vapidir=. --pkg gedit --pkg gee-1.0 --pkg > > gtk+-3.0 --pkg libvala-0.14 --pkg vte-2.90 --pkg gtksourceview-3.0 --pkg > > PeasGtk-1.0 autocomplete.vala browser.vala expression.vala gtk_util.vala > > parser.vala program.vala scanner.vala settings.vala util.vala valencia.vala > > -o libvalencia.so > > GIRepository-2.0.gir:240.11-240.30: error: expected start element of > > `parameter' > > > > > > ... This issue is caused by incompatible versions of g-ir-scanner and valac. The newer g-ir-scanner now emits instance-paramater elements but valac does not understand them. On the valac side, this has been fixed in [1]. Indeed, rebuilding valac-0.14 with this patch makes the build failure go away. Bringing the vala maintainers in to the loop and let's see what they think about that. Also CCing #707441 since it looks like the same issue. But I haven't tested it. Regards [1] https://git.gnome.org/browse/vala/commit/?id=c755bb4bd3b078363193ea41495e4c9f2782a9d8 -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707426: [Help] Re: Bug#707426: maqview: FTBFS: (.text+0x74): undefined reference to `XISelectEvents'
Hi Andreas On 2013-05-10 13:01:39, Andreas Tille wrote: > Hi, > > I can confirm this problem. > > On Thu, May 09, 2013 at 10:08:57AM +0200, Lucas Nussbaum wrote: > > > > Relevant part: > > > g++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat > > > -Werror=format-security -Wl,-z,relro -L/usr/lib -o maqview read_cache.o > > > view_goto.o view_panel.o gl_gui.o MainFrame.o btree.o maqmap_index.o > > > zrio.o stdhashc.o cns_cache.o const.o adler32.o compress.o crc32.o > > > deflate.o gzio.o inffast.o inflate.o infback.o inftrees.o trees.o > > > uncompr.o zutil.o -Wl,-Bstatic -lglut -Wl,-Bdynamic -lGL -lGLU -lm -lX11 > > > /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libglut.a(libglut_la-freeglut_xinput.o): > > > In function `fgRegisterDevices': > > > (.text+0x74): undefined reference to `XISelectEvents' > > > collect2: error: ld returned 1 exit status > > The missing reference can be found in > > $ strings /usr/lib/x86_64-linux-gnu/libXi.so.6 | grep XISelectEvents > XISelectEvents > > so I added -lXi explicitly as well as added libxi6 to Build-Depends. You want libxi-dev instead: % dpkg -L libxi-dev | grep libXi.so /usr/lib/x86_64-linux-gnu/libXi.so That's what it is looking for if you add -lXi. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707172: pygtkspellcheck: diff for NMU version 3.0-1.1
Control: tags -1 + patch pending Dear maintainer, I've prepared an NMU for pygtkspellcheck (versioned as 3.0-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards -- Sebastian Ramacher diff -Nru pygtkspellcheck-3.0/debian/changelog pygtkspellcheck-3.0/debian/changelog --- pygtkspellcheck-3.0/debian/changelog 2012-08-18 17:16:59.0 +0200 +++ pygtkspellcheck-3.0/debian/changelog 2013-05-16 17:12:45.0 +0200 @@ -1,3 +1,11 @@ +pygtkspellcheck (3.0-1.1) unstable; urgency=low + + * Non-maintainer upload. + * debian/control: Build-Depend on python3-all instead of python3 to fix +building with multiple supported Python 3 versions. (Closes: #707172) + + -- Sebastian Ramacher Thu, 16 May 2013 17:07:47 +0200 + pygtkspellcheck (3.0-1) unstable; urgency=low * Initial release. Closes: 681528 diff -Nru pygtkspellcheck-3.0/debian/control pygtkspellcheck-3.0/debian/control --- pygtkspellcheck-3.0/debian/control 2012-08-18 17:16:59.0 +0200 +++ pygtkspellcheck-3.0/debian/control 2013-05-16 16:50:44.0 +0200 @@ -6,7 +6,7 @@ python (>= 2.7), python-sphinx, python-enchant, - python3, + python3-all, python3-sphinx, python3-enchant Standards-Version: 3.9.3 signature.asc Description: Digital signature
Bug#695225: No support for mp4 container in Handbrake
Control: reassign -1 handbrake On 2012-12-05 18:56:34, Juliusz Chroboczek wrote: > Package: handbrake-gtk The package is now called handbrake. Reassigning to handbrake so it doesn't get lost. Regards > Version: 0.9.8+dfsg1-2 > Severity: wishlist > > In the "Destination" dialog, the "Format" field only supports MKV -- > there's no way to select an mp4 container. > > -- Juliusz Chroboczek > > ___ > pkg-multimedia-maintainers mailing list > pkg-multimedia-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707731: No grub installation?
Control: reassign -1 installation-reports Hi David On 2013-05-10 19:40:09, David wrote: > Package: Netinstaller Wheezy stable There is no such package. But from your report it seems that installation-reports is probably a good starting point. Thus reassigning there. > Version: stable version, 10/15/13 > > Hello, > I tried again to install Debian to a usb disk of 32 Gb through a laptop > (Acer Travelmate P253-E) from another usb with the net installation iso > provided at the main page of Debian project, the one in the top right > corner. This time with the new stable version. > All went perfectly well at 64 bits, except that it didn't prompt where > to put grub, and I thought it had gone to the internal hard disk and > corrupted the other grub there and that I would have to perform a boot > repair with the tool of the same name. Before rebooting, I went back to > main intaller menu and selected grub installation phase so to force grub > to be installed on sdb (the usb drive) and not on sda (internal disk). > There was no dialogue to answer "no" and select a different place for > grub, it just installed it again... aparently on sda (the light of the > hdd was on at the front of the laptop). Then I finished and rebooted > expecting the worse... but the laptop was ok! The grub inside had not > been overwritten by the Debian installer. Everything was as before. > Then, hoppefuly, I tried to boot to Debian on the usb disk through > selecting it at the bios prompt of boot selector: nothing. There was > nothing to boot to. So, again, it seemed that there was no grub to be > found. It dit not go to the installation source usb drive either because > it booted again perfectly to install again another system. > So there is no way I can have a Debian system, nor testing or stable, > installed in or through my laptop. > I hope this is useful to the project. > David Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707805: Please drop python2.6-argparse build-dependency
Control: tags -1 + patch
On 2013-05-16 14:27:44, Matthias Klose wrote:
> File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 152,
> in
> __init__
> raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")
> django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not
> be
> empty.
> make[1]: *** [override_dh_auto_test] Error 1
> make[1]: Leaving directory `/home/packages/tmp/sorl-thumbnail-11.12'
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
The attached patch fixes this. The patch fixes also an issue with django 1.5,
that pops up later if SECRET_KEY is set:
set -e; \
for python in python2.7; do \
for name in pil pgmagick imagemagick graphicsmagick; do \
LOCPATH=/«PKGBUILDDIR»/tmp-locales LC_ALL=en_US.UTF-8
PYTHONPATH=tests LOCAL_BUILD=1 $python tests/runtests.py
--settings=settings.$name ; \
done; \
done
..ssE.
==
ERROR: testEmptyError (thumbnail_tests.tests.TemplateTestCaseClient)
--
Traceback (most recent call last):
File "/«PKGBUILDDIR»/tests/thumbnail_tests/tests.py", line 403, in
testEmptyError
response = client.get('/thumbnail9.html')
File "/usr/lib/python2.7/dist-packages/django/test/client.py", line 453, in
get
response = super(Client, self).get(path, data=data, **extra)
File "/usr/lib/python2.7/dist-packages/django/test/client.py", line 279, in
get
return self.request(**r)
File "/usr/lib/python2.7/dist-packages/django/test/client.py", line 424, in
request
six.reraise(*exc_info)
File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line
92, in get_response
response = middleware_method(request)
File "/usr/lib/python2.7/dist-packages/django/middleware/common.py", line 69,
in process_request
if (not urlresolvers.is_valid_path(request.path_info, urlconf) and
File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line
551, in is_valid_path
resolve(path, urlconf)
File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line
440, in resolve
return get_resolver(urlconf).resolve(path)
File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line
321, in resolve
sub_match = pattern.resolve(new_path)
File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line
223, in resolve
return ResolverMatch(self.callback, args, kwargs, self.name)
File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line
230, in callback
self._callback = get_callable(self._callback_str)
File "/usr/lib/python2.7/dist-packages/django/utils/functional.py", line 29,
in wrapper
result = func(*args)
File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line
104, in get_callable
(lookup_view, mod_name))
ViewDoesNotExist: Could not import
django.views.generic.simple.direct_to_template. Parent module
django.views.generic.simple does not exist.
--
Ran 38 tests in 1.108s
FAILED (errors=1, skipped=2)
Running tests for 'settings.pil'
Creating test database for alias 'default'...
Destroying test database for alias 'default'...
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
direct_to_template got deprecated in 1.4 and removed in django 1.5.
Regards
--
Sebastian Ramacher
--- a/tests/settings/default.py
+++ b/tests/settings/default.py
@@ -32,3 +32,4 @@
"django.core.context_processors.request",
)
+SECRET_KEY = 'testkey'
--- a/tests/thumbnail_tests/urls.py
+++ b/tests/thumbnail_tests/urls.py
@@ -1,12 +1,16 @@
from django.conf.urls.defaults import *
from django.conf import settings
+from django.views.generic import TemplateView
+class DynamicTemplateView(TemplateView):
+def get_template_names(self):
+return self.kwargs['template']
urlpatterns = patterns('',
(r'^media/(?P.*)$', 'django.views.static.serve', {
'document_root': settings.MEDIA_ROOT,
'show_indexes': True}
),
-(r'^(.*\.html)$', 'django.views.generic.simple.direct_to_template'),
+(r'^(?P.*\.html)$', DynamicTemplateView.as_view()),
)
signature.asc
Description: Digital signature
Bug#701860: unblock: pycxx/6.2.4-3
Control: tags -1 - moreinfo On 2013-02-28 21:07:11, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Wed, 2013-02-27 at 22:51 -0800, Vincent Cheng wrote: > > + * install into real include/python3* folder instead of symlink folder > > + Thanks to Sebastian Ramacher for the patch. (Closes: #700782) > [...] > > Build-Depends: debhelper (>= 7.0.50~), > > python-all (>= 2.6.6-3~), > > - python3-all (>= 3.1.2-10~) > > + python3-all-dev (>= 3.1.2-10~), > > + python3-all-dbg > > Why the new -dbg build-dependency? Because the symlinks that are read in d/rules are shipped in python3.*-dev and python3.*-dbg. If they are not there, the files end up in /usr/include/python3.2/CXX again. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#701185: CVE-2013-0200: Insecure temporary files
Control: found -1 3.10.6-2+squeeze1
Control: found -1 3.12.6-3
Control: found -1 3.12.11-1
All versions that are currently in the archive are affected by this
bug.
On 2013-02-22 15:15:13, Moritz Muehlenhoff wrote:
> Package: hplip
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Several further insecurely handled temporary files were discovered by Red Hat:
> https://www.redhat.com/archives/enterprise-watch-list/2013-February/msg00024.html
>
> I've extracted the patch from the RHEL update, it's attached to this mail.
The patch introduces one buffer overflow and an regression.
> diff -up hplip-3.12.4/prnt/hpcups/HPCupsFilter.cpp.CVE-2013-0200
> hplip-3.12.4/prnt/hpcups/HPCupsFilter.cpp
> --- hplip-3.12.4/prnt/hpcups/HPCupsFilter.cpp.CVE-2013-0200 2013-01-22
> 10:57:13.651460928 +
> +++ hplip-3.12.4/prnt/hpcups/HPCupsFilter.cpp 2013-01-22 10:57:34.087541538
> +
> @@ -637,19 +637,22 @@ int HPCupsFilter::processRasterData(cups
> {
> charszFileName[32];
> memset(szFileName, 0, sizeof(szFileName));
> -snprintf (szFileName, sizeof(szFileName),
> "/tmp/hpcupsfilterc_%d.bmp", current_page_number);
> +snprintf (szFileName, sizeof(szFileName),
> "/tmp/hpcupsfilterc_%d.bmp.XX", current_page_number);
If current_page_number is larger than 9, the last six characters of
szFileName won't be XX and hence mkstemp will fail with EINVAL.
> diff -up hplip-3.12.4/prnt/hpcups/SystemServices.cpp.CVE-2013-0200
> hplip-3.12.4/prnt/hpcups/SystemServices.cpp
> --- hplip-3.12.4/prnt/hpcups/SystemServices.cpp.CVE-2013-0200 2012-04-10
> 09:32:37.0 +0100
> +++ hplip-3.12.4/prnt/hpcups/SystemServices.cpp 2013-01-22
> 10:57:34.088541545 +
> @@ -36,10 +36,12 @@ SystemServices::SystemServices(int iLogL
> m_fp = NULL;
> if (iLogLevel & SAVE_PCL_FILE)
> {
> + int fd;
> charfname[32];
> -sprintf(fname, "/tmp/hpcups_job%d.out", job_id);
> -m_fp = fopen(fname, "w");
> -chmod(fname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
> +sprintf(fname, "/tmp/hpcups_job%d.out.XX", job_id);
job_id > 10 will cause a buffer overflow. According to cups' API
documentation job_id can be up to 2^31-1 [1].
The attached patch makes the buffers large enough. I'll prepare a NMU
later today if nobody beats me to it.
Regards
[1] http://www.cups.org/documentation.php/api-cups.html#PRINT_JOBS
--
Sebastian Ramacher
--- a/prnt/hpcups/HPCupsFilter.cpp
+++ b/prnt/hpcups/HPCupsFilter.cpp
@@ -656,21 +656,24 @@
if (m_iLogLevel & SAVE_INPUT_RASTERS)
{
-charszFileName[32];
+charszFileName[44];
memset(szFileName, 0, sizeof(szFileName));
-snprintf (szFileName, sizeof(szFileName), "/tmp/hpcupsfilterc_%d.bmp", current_page_number);
+snprintf (szFileName, sizeof(szFileName), "/tmp/hpcupsfilterc_%d.bmp.XX", current_page_number);
if (cups_header.cupsColorSpace == CUPS_CSPACE_RGBW ||
cups_header.cupsColorSpace == CUPS_CSPACE_RGB)
{
-cfp = fopen (szFileName, "w");
-chmod (szFileName, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ int fd = mkstemp (szFileName);
+ if (fd != -1)
+ cfp = fdopen (fd, "w");
}
if (cups_header.cupsColorSpace == CUPS_CSPACE_RGBW ||
cups_header.cupsColorSpace == CUPS_CSPACE_K)
{
-szFileName[17] = 'k';
-kfp = fopen (szFileName, "w");
-chmod (szFileName, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ int fd;
+ snprintf (szFileName, sizeof(szFileName), "/tmp/hpcupsfilterk_%d.bmp.XX", current_page_number);
+ fd = mkstemp (szFileName);
+ if (fd != -1)
+ kfp = fdopen (fd, "w");
}
WriteBMPHeader (cfp, cups_header.cupsWidth, cups_header.cupsHeight, COLOR_RASTER);
--- a/prnt/hpcups/SystemServices.cpp
+++ b/prnt/hpcups/SystemServices.cpp
@@ -36,10 +36,12 @@
m_fp = NULL;
if (iLogLevel & SAVE_PCL_FILE)
{
-charfname[32];
-sprintf(fname, "/tmp/hpcups_job%d.out", job_id);
-m_fp = fopen(fname, "w");
-chmod(fname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ int fd;
+charfname[40];
+sprintf(fname, "/tmp/hpcups_job%d.out.XX", job_id);
+ fd = mkstemp (fname);
+ if (fd != -1)
+ m_fp = fdopen(fd, "w");
}
}
--- a/prnt/hpijs/hpijs.cpp
+++ b/prnt/hpijs/hpijs.cpp
@@ -96,13 +96,12 @@
if (pSS->m_iLogLevel & SAVE_PCL_FILE)
{
+ int fd;
Bug#701185: hplip: diff for NMU version 3.12.6-3.1
Control: tags -1 + pending
thanks
Dear maintainer,
I've prepared an NMU for hplip (versioned as 3.12.6-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards
--
Sebastian Ramacher
diff -Nru hplip-3.12.6/debian/changelog hplip-3.12.6/debian/changelog
--- hplip-3.12.6/debian/changelog 2012-06-24 08:49:45.0 +0200
+++ hplip-3.12.6/debian/changelog 2013-03-01 18:41:56.0 +0100
@@ -1,3 +1,12 @@
+hplip (3.12.6-3.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * debian/patches/CVE-2013-0200.patch: Fix CVE-2013-0200 by applying the
+patch from Red Hat. Additionally increase the buffers to mitigate an
+regression and a buffer overflow. (Closes: #701185)
+
+ -- Sebastian Ramacher Fri, 01 Mar 2013 18:21:48 +0100
+
hplip (3.12.6-3) unstable; urgency=low
* [!linux-any] --enable-libusb01_build
diff -Nru hplip-3.12.6/debian/patches/CVE-2013-0200.patch hplip-3.12.6/debian/patches/CVE-2013-0200.patch
--- hplip-3.12.6/debian/patches/CVE-2013-0200.patch 1970-01-01 01:00:00.0 +0100
+++ hplip-3.12.6/debian/patches/CVE-2013-0200.patch 2013-03-01 18:52:39.0 +0100
@@ -0,0 +1,98 @@
+Description: fix for CVE-2013-0200 (insecure temporary files)
+Origin: vendor, ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Workstation/en/os/SRPMS/hplip-3.12.4-4.el6.src.rpm
+Last-Update: 2013-03-01
+Bug-Debian: http://bugs.debian.org/701185
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=902163
+
+--- a/prnt/hpcups/HPCupsFilter.cpp
b/prnt/hpcups/HPCupsFilter.cpp
+@@ -656,21 +656,24 @@
+
+ if (m_iLogLevel & SAVE_INPUT_RASTERS)
+ {
+-charszFileName[32];
++charszFileName[44];
+ memset(szFileName, 0, sizeof(szFileName));
+-snprintf (szFileName, sizeof(szFileName), "/tmp/hpcupsfilterc_%d.bmp", current_page_number);
++snprintf (szFileName, sizeof(szFileName), "/tmp/hpcupsfilterc_%d.bmp.XX", current_page_number);
+ if (cups_header.cupsColorSpace == CUPS_CSPACE_RGBW ||
+ cups_header.cupsColorSpace == CUPS_CSPACE_RGB)
+ {
+-cfp = fopen (szFileName, "w");
+-chmod (szFileName, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
++ int fd = mkstemp (szFileName);
++ if (fd != -1)
++ cfp = fdopen (fd, "w");
+ }
+ if (cups_header.cupsColorSpace == CUPS_CSPACE_RGBW ||
+ cups_header.cupsColorSpace == CUPS_CSPACE_K)
+ {
+-szFileName[17] = 'k';
+-kfp = fopen (szFileName, "w");
+-chmod (szFileName, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
++ int fd;
++ snprintf (szFileName, sizeof(szFileName), "/tmp/hpcupsfilterk_%d.bmp.XX", current_page_number);
++ fd = mkstemp (szFileName);
++ if (fd != -1)
++ kfp = fdopen (fd, "w");
+ }
+
+ WriteBMPHeader (cfp, cups_header.cupsWidth, cups_header.cupsHeight, COLOR_RASTER);
+--- a/prnt/hpcups/SystemServices.cpp
b/prnt/hpcups/SystemServices.cpp
+@@ -36,10 +36,12 @@
+ m_fp = NULL;
+ if (iLogLevel & SAVE_PCL_FILE)
+ {
+-charfname[32];
+-sprintf(fname, "/tmp/hpcups_job%d.out", job_id);
+-m_fp = fopen(fname, "w");
+-chmod(fname, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
++ int fd;
++charfname[40];
++sprintf(fname, "/tmp/hpcups_job%d.out.XX", job_id);
++ fd = mkstemp (fname);
++ if (fd != -1)
++ m_fp = fdopen(fd, "w");
+ }
+ }
+
+--- a/prnt/hpijs/hpijs.cpp
b/prnt/hpijs/hpijs.cpp
+@@ -96,13 +96,12 @@
+
+ if (pSS->m_iLogLevel & SAVE_PCL_FILE)
+ {
++ int fd;
+ charszFileName[32];
+- sprintf (szFileName, "/tmp/hpijs_%d.out", getpid());
+- pSS->outfp = fopen (szFileName, "w");
+- if (pSS->outfp)
+- {
+- chmod (szFileName, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+- }
++ sprintf (szFileName, "/tmp/hpijs_%d.out.XX", getpid());
++ fd = mkstemp (szFileName);
++ if (fd != -1)
++ pSS->outfp = fdopen (fd, "w");
+ }
+ }
+
+--- a/prnt/hpps/hppsfilter.c
b/prnt/hpps/hppsfilter.c
+@@ -92,10 +92,12 @@
+ g_fp_outdbgps = NULL;
+ if (g_savepsfile & SAVE_PS_FILE)
+ {
++ int fd;
+ charsfile_name[FILE_NAME_SIZE] = {0};
+-sprintf(sfile_name, DBG_PSFILE, szjob_id);
+-g_fp_outdbgps= fopen(sfile_name, "w");
+-chmod(sfile_name, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
++sprintf(sfile_name, DBG_PSFILE ".XX", szjob_id);
++ fd = mkstemp (sfile_name);
++ if (fd != -1)
++ g_fp_outdbgps = fdopen(fd, "w");
+ }
+ }
+
diff -Nru hplip-3.12.6/debian/patches/series hplip-3.12.6/debian/patches/series
--- hplip-3.12.6/debian/patches/series 2012-06-
Bug#702025: (no subject)
Control: tags -1 moreinfo unreproducible On 2013-03-01 21:09:07, TrialAndError wrote: > Package could not be downloaded by apt-get because of "different size". > > After installing by hand from the web 'apt-get dist-upgrade' fails > to upgrade it every time. Looks like mirror problems to me. What are the exact commands that you're running and the exact error message? Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#702121: python-pytest: please provide DEP-8 tests
Package: python-pytest Version: 2.3.4-1~exp1 Severity: wishlist Please provide DEP-8 tests so that the integration with python-pytest.xdist can be tested without introducing a Build-Dep on python-pytest itself. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#661342: python-gevent: diff for NMU version 0.13.6-1+nmu2
Control: tags -1 + pending
Dear maintainer,
I've prepared an NMU for python-gevent (versioned as 0.13.6-1+nmu2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
I've also moved the debugging symbols to the correct location so gdb can
find them.
Regards
--
Sebastian Ramacher
diff -Nru python-gevent-0.13.6/debian/changelog python-gevent-0.13.6/debian/changelog
--- python-gevent-0.13.6/debian/changelog 2012-11-12 23:09:04.0 +0100
+++ python-gevent-0.13.6/debian/changelog 2013-03-03 15:46:11.0 +0100
@@ -1,3 +1,16 @@
+python-gevent (0.13.6-1+nmu2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/control:
+- Add python-all-dbg to Build-Depends to build extensions modules for
+ debug variants too. (Closes: #661342)
+- Add ${python:Depends}, ${shlibs:Depends}, python-greenlet-dbg to
+ python-gevent-dbg's Depends.
+ * debian/rules: Install debugging symbols into the correct location so that
+they are actually usable.
+
+ -- Sebastian Ramacher Sun, 03 Mar 2013 15:46:09 +0100
+
python-gevent (0.13.6-1+nmu1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru python-gevent-0.13.6/debian/control python-gevent-0.13.6/debian/control
--- python-gevent-0.13.6/debian/control 2011-05-17 16:45:37.0 +0200
+++ python-gevent-0.13.6/debian/control 2013-03-03 15:46:00.0 +0100
@@ -3,7 +3,8 @@
Maintainer: Örjan Persson
Uploaders: Andreas Schuldei
Build-Depends: debhelper (>= 7.0.50), python-support, python-all-dev, libevent-dev (>= 1.4),
- python-greenlet | python-codespeak-lib (<< 1.0), python-sphinx (>= 0.6)
+ python-greenlet | python-codespeak-lib (<< 1.0), python-sphinx (>= 0.6),
+ python-all-dbg
Standards-Version: 3.9.0
Section: python
Homepage: http://www.gevent.org/
@@ -11,7 +12,8 @@
Package: python-gevent-dbg
Section: debug
Architecture: any
-Depends: ${misc:Depends}, python-gevent (= ${binary:Version})
+Depends: ${misc:Depends}, python-gevent (= ${binary:Version}), ${shlibs:Depends}, ${python:Depends},
+ python-greenlet-dbg
Description: gevent is a coroutine-based Python networking library - debugging symbols
gevent uses greenlet to provide a high-level synchronous API on top of
libevent event loop.
diff -Nru python-gevent-0.13.6/debian/python-gevent-dbg.install python-gevent-0.13.6/debian/python-gevent-dbg.install
--- python-gevent-0.13.6/debian/python-gevent-dbg.install 1970-01-01 01:00:00.0 +0100
+++ python-gevent-0.13.6/debian/python-gevent-dbg.install 2013-03-03 14:22:23.0 +0100
@@ -0,0 +1 @@
+usr/lib/python2*/*-packages/gevent/*_d.so
diff -Nru python-gevent-0.13.6/debian/python-gevent.install python-gevent-0.13.6/debian/python-gevent.install
--- python-gevent-0.13.6/debian/python-gevent.install 2011-05-17 16:45:37.0 +0200
+++ python-gevent-0.13.6/debian/python-gevent.install 2013-03-03 14:22:23.0 +0100
@@ -1 +1,2 @@
-usr/lib/*
+usr/lib/python2*/*-packages/gevent/*.py
+usr/lib/python2*/*-packages/gevent/*[!_][!d].so
diff -Nru python-gevent-0.13.6/debian/rules python-gevent-0.13.6/debian/rules
--- python-gevent-0.13.6/debian/rules 2011-05-17 16:45:37.0 +0200
+++ python-gevent-0.13.6/debian/rules 2013-03-03 14:52:20.0 +0100
@@ -16,7 +16,11 @@
dh_compress -X.js -X_static/* -X _sources/* -X_sources/*/* -X.inv
override_dh_strip:
+ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
dh_strip --dbg-package=python-gevent-dbg
+ mv debian/python-gevent-dbg/usr/lib/debug/usr/lib/pyshared \
+ debian/python-gevent-dbg/usr/lib/debug/usr/lib/pymodules
+endif
override_dh_installdocs:
dh_installdocs --link-doc=python-gevent
signature.asc
Description: Digital signature
Bug#702197: sqlparse: new upstream version available with Python 3 support
Source: sqlparse Version: 0.1.4-1 Severity: wishlist A new upstream version of sqlparse is available. 0.1.6 now includes support for Python 3. Please package the new version and provide a python3-sqlparse package. Thanks! Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#698236: bitlbee: diff for NMU version 3.2-1.1
Control: tags -1 + patch pending thanks Dear maintainer, I've prepared an NMU for bitlbee (versioned as 3.2-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. -- Sebastian Ramacher diff -u bitlbee-3.2/debian/control bitlbee-3.2/debian/control --- bitlbee-3.2/debian/control +++ bitlbee-3.2/debian/control @@ -4,7 +4,7 @@ Maintainer: Wilmer van der Gaast Uploaders: Jelmer Vernooij Standards-Version: 3.9.1 -Build-Depends: libglib2.0-dev (>= 2.4), libevent-dev, gnutls-dev | libgnutls-dev, po-debconf, libpurple-dev, libotr2-dev, debhelper (>= 6.0.7~), asciidoc +Build-Depends: libglib2.0-dev (>= 2.4), libevent-dev, libgnutls28-dev | gnutls-dev, po-debconf, libpurple-dev, libotr2-dev, debhelper (>= 6.0.7~), asciidoc Homepage: http://www.bitlbee.org/ Vcs-Bzr: http://code.bitlbee.org/bitlbee/ DM-Upload-Allowed: yes diff -u bitlbee-3.2/debian/changelog bitlbee-3.2/debian/changelog --- bitlbee-3.2/debian/changelog +++ bitlbee-3.2/debian/changelog @@ -1,3 +1,10 @@ +bitlbee (3.2-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Build-Depend on libgnutls28-dev | gnutls-dev. (Closes: #698236) + + -- Sebastian Ramacher Sun, 03 Mar 2013 22:52:02 +0100 + bitlbee (3.2-1) unstable; urgency=high * New upstream release. signature.asc Description: Digital signature
Bug#701792: PHP extension installed to wrong directory
Control: tags -1 + patch On 2013-02-27 09:45:06, Ondřej Surý wrote: > Package: php-zeroc-ice > Version: 3.4.2-8.1 > Severity: grave > > The package php-zeroc-ice.install file hardcodes installation directory: > > usr/php/*.so usr/lib/php5/20090626+lfs > > which is clearly wrong because the php API version has changed. > > rules-php.mk has the correct way of getting the right API version, e.g. using > php-config5: > > $(php-config5 --extension-dir) The attached patch should do the trick. Regards -- Sebastian Ramacher diff -Nru zeroc-ice-3.4.2/debian/changelog zeroc-ice-3.4.2/debian/changelog --- zeroc-ice-3.4.2/debian/changelog2012-07-07 21:05:22.0 +0200 +++ zeroc-ice-3.4.2/debian/changelog2013-03-04 00:05:57.0 +0100 @@ -1,3 +1,11 @@ +zeroc-ice (3.4.2-8.2) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Install PHP extension to directory given by php5-config --extension-dir. +(Closes: #701792) + + -- Sebastian Ramacher Sun, 03 Mar 2013 23:59:54 +0100 + zeroc-ice (3.4.2-8.1) unstable; urgency=low * Non-maintainer upload. diff -Nru zeroc-ice-3.4.2/debian/php-zeroc-ice.install zeroc-ice-3.4.2/debian/php-zeroc-ice.install --- zeroc-ice-3.4.2/debian/php-zeroc-ice.install2012-07-07 21:05:22.0 +0200 +++ zeroc-ice-3.4.2/debian/php-zeroc-ice.install2013-03-03 23:44:21.0 +0100 @@ -1,5 +1,4 @@ etc/php5 -usr/php/*.so usr/lib/php5/20090626+lfs usr/php/*.php usr/share/Ice-3.4.2/php/lib usr/php/Glacier2 usr/share/Ice-3.4.2/php/lib/ usr/php/Ice usr/share/Ice-3.4.2/php/lib/ diff -Nru zeroc-ice-3.4.2/debian/rules-php.mk zeroc-ice-3.4.2/debian/rules-php.mk --- zeroc-ice-3.4.2/debian/rules-php.mk 2012-07-07 21:05:22.0 +0200 +++ zeroc-ice-3.4.2/debian/rules-php.mk 2013-03-03 23:46:43.0 +0100 @@ -30,6 +30,7 @@ $(DEB_MAKE_INVOKE) -C php install ; \ fi -cp debian/IcePHP.ini $(DEB_DH_INSTALL_SOURCEDIR)/etc/php5/conf.d + cp $(DEB_DH_INSTALL_SOURCEDIR)/usr/php/*.so $(PHP_LIBDIR) :> $@ .PHONY: build/php install/php signature.asc Description: Digital signature
Bug#702214: zathura: Slow resizing followed by segfault
Control: tags -1 + moreinfo On 2013-03-04 02:02:28, frozencemetery wrote: > Package: zathura > Version: 0.1.2-4 > Severity: normal > > Hello, > > While using zathura to browse this pdf > > > http://web.mit.edu/campus-map/pdf/campusmap.pdf > > zathura was quite slow to render, especially when zooming, and also consumed > an entire core of my machine (and I believe loading the graphics card as well) > when no rendering had been requested (i.e., in what appeared to be an "idle" > state). It eventually segfaulted, as reported in dmesg: > > > [34555.296106] zathura[1659]: segfault at 0 ip 7f81c833e62c sp > > 7fff36156a70 error 4 in libpoppler.so.19.0.0[7f81c81f9000+1da000] I'm unable to reproduce the segfault with 0.1.2-4 and 0.2.2-1 from experimental. However, I remember that we have fixed some segfaults in the poppler plugin in 0.2.x that were caused by race conditions and really unfortunate unfortunate timing of events. Could you please check if the segfault is gone in 0.2.2-1? Both pages in that PDF are quite large, so the high CPU usage is somewhat expected. REgards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#701792: PHP extension installed to wrong directory
On 2013-03-04 13:17:54, Ondřej Surý wrote: > Uploaded to DELAYED/5. Thank you. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#698236: bitlbee: diff for NMU version 3.2-1.1
On 2013-03-04 22:01:21, Julien Cristau wrote: > On Sun, Mar 3, 2013 at 23:08:27 +0100, Sebastian Ramacher wrote: > > > -Build-Depends: libglib2.0-dev (>= 2.4), libevent-dev, gnutls-dev | > > libgnutls-dev, po-debconf, libpurple-dev, libotr2-dev, debhelper (>= > > 6.0.7~), asciidoc > > +Build-Depends: libglib2.0-dev (>= 2.4), libevent-dev, libgnutls28-dev | > > gnutls-dev, po-debconf, libpurple-dev, libotr2-dev, debhelper (>= 6.0.7~), > > asciidoc > > Please don't do that. Use libgnutls-dev instead. Okay, the switch to libgnutls28-dev was a bad idea. New debdiff attached. Cheers -- Sebastian Ramacher diff -u bitlbee-3.2/debian/control bitlbee-3.2/debian/control --- bitlbee-3.2/debian/control +++ bitlbee-3.2/debian/control @@ -4,7 +4,7 @@ Maintainer: Wilmer van der Gaast Uploaders: Jelmer Vernooij Standards-Version: 3.9.1 -Build-Depends: libglib2.0-dev (>= 2.4), libevent-dev, gnutls-dev | libgnutls-dev, po-debconf, libpurple-dev, libotr2-dev, debhelper (>= 6.0.7~), asciidoc +Build-Depends: libglib2.0-dev (>= 2.4), libevent-dev, libgnutls-dev | gnutls-dev, po-debconf, libpurple-dev, libotr2-dev, debhelper (>= 6.0.7~), asciidoc Homepage: http://www.bitlbee.org/ Vcs-Bzr: http://code.bitlbee.org/bitlbee/ DM-Upload-Allowed: yes diff -u bitlbee-3.2/debian/changelog bitlbee-3.2/debian/changelog --- bitlbee-3.2/debian/changelog +++ bitlbee-3.2/debian/changelog @@ -1,3 +1,11 @@ +bitlbee (3.2-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Switch the order of (lib)gnutls-dev Build-Depends to libgnutls-dev | +gnutls-dev. (Closes: #698236) + + -- Sebastian Ramacher Mon, 04 Mar 2013 23:52:07 +0100 + bitlbee (3.2-1) unstable; urgency=high * New upstream release. signature.asc Description: Digital signature
Bug#702352: python-launchpadlib: DBus error in credentials.py
On 2013-03-05 10:40:32, Luke Faraone wrote:
> Package: python-launchpadlib
> Version: 1.10.2+ds-1
> Severity: important
>
> When using requestsync or syncpackage the following traceback occurs on
> the versions of launchpadlib in both unstable and experimental.
>
> lfaraone@cobalt:~/Projects/ppt/openafs/precise$ requestsync openafs
> Traceback (most recent call last):
> File "/usr/bin/requestsync", line 366, in
> main()
> File "/usr/bin/requestsync", line 167, in main
> Launchpad.login(service=options.lpinstance, api_version='devel')
> File "/usr/lib/python2.7/dist-packages/ubuntutools/lp/lpapicache.py", line
> 66, in login
> version=api_version)
> File "/usr/lib/python2.7/dist-packages/launchpadlib/launchpad.py", line
> 539, in login_with
> credential_save_failed, version)
> File "/usr/lib/python2.7/dist-packages/launchpadlib/launchpad.py", line
> 342, in _authorize_token_and_login
> authorization_engine.unique_consumer_id)
> File "/usr/lib/python2.7/dist-packages/launchpadlib/credentials.py", line
> 305, in load
> return self.do_load(unique_key)
> File "/usr/lib/python2.7/dist-packages/launchpadlib/credentials.py", line
> 359, in do_load
> 'launchpadlib', unique_key)
> File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 37, in
> get_password
> return _keyring_backend.get_password(service_name, username)
> File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 197, in
> get_password
> _, session = service_iface.OpenSession("plain", "")
> File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in
> __call__
> **keywords)
> File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod:
> Method "OpenSession" with signature "ss" on interface
> "org.freedesktop.Secret.Service" doesn't exist
This looks very much like [1]. AFAICT from that bug, this is an issue in
gnome-keyring 3.4 and was fixed in gome-keyring 3.5. So if you're using
gnome-keyring as backend, I think it should be reassigned there.
Regards
[1]
https://bitbucket.org/kang/python-keyring-lib/issue/65/dbusexception-method-opensession-with
--
Sebastian Ramacher
signature.asc
Description: Digital signature
Bug#702570: libdiscid: New upstream release: 0.4.0
On 2013-03-08 16:40:46, Johannes Dewender wrote: > Package: libdiscid > Followup-For: Bug #702570 > > >* debian/patches/hurd.path: Refresh. > > The hurd.patch is superseeded by the "generic" platform > and should be removed now. > Otherwise this will lead to problems. > > > Details: > > The hurd patch implemented the minimal platform API (0.2.2/0.3.x) > as "NO-OP" just so the project compiles on GNU Hurd. > This is exactly why the "generic" platform was implemented. > > The difference is: the Hurd patch does not implement > the 0.4.0 API. That would be: telling that neither of > read, mcn or isrc are supported. > > I suspect it wouldn't even compile on GNU Hurd, > because the example uses the feature API already. > However, I didn't test building on Hurd myself. hrm, I just noticed that it failed to build on hurd because of that. Could you enlighten me where the generic platform is implemented? Looks like src/disc_generic.c didn't make it into the tarball. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#702570: libdiscid: New upstream release: 0.4.0
On 2013-03-08 17:29:58, Johannes Dewender wrote: > Package: libdiscid > Followup-For: Bug #702570 > > > Yes, disc_generic.c wasn't in the distribution. > That can't happen for the cmake dist itself (that one uses git directly) > but the distribution has to run through a level of Autotools. > > > Anyways, the file is in > https://raw.github.com/metabrainz/libdiscid/master/src/disc_generic.c Thanks for the quick fix. > I will release 0.4.1 as a build fix release, > even if this probably only affects Debian. > So you can also wait for that. > > I am not sure if that goes through today, since there are multiple > non automated levels of access in the MB structures, > but I will try. Whatever works best for you. If you don't want to rush a new release I'll just carry disc_generic.c as patch for now. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700738: valgrind summary
On 2013-03-06 20:02:16, Antoine Beaupré wrote: > So I ran the patched version under valgrind, which I am not familiar > with at all so YMMV. > > I attach the output. > > Basically, what I see is one of those: > > ==3852== Conditional jump or move depends on uninitialised value(s) > ==3852== Use of uninitialised value of size 8 > ==3852== Syscall param rt_sigaction(act->sa_mask) points to uninitialised > byte(s) > > This seems consistent with the original report of problems with the > signal handler, in general, but I haven't dug much deeper yet. Those valgrind warnings can be fixed quite easily. valgrind is complaining because some members of ttyclock malloc'd in main and sigaction in init are read before they were initialized. For example, in line 70 it is checked if ttyclock->geo.x is zero, but ttyclock->geo.x has no well defined value at this point. To silence the warnings it should be enough to just run memset over the allocated memory: once for ttyclock after the first malloc in main and once for sig in init. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#700738: valgrind summary
On 2013-03-08 22:25:46, Antoine Beaupré wrote:
> I really wonder what to do at this point. I can certainly upload the 2.0
> version to experimental to allow people to test this more thoroughly
> (but then again, it's just once C file, easy enough to test). But I
> don't feel those bugs are serious enough to block the Wheezy release. It
> doesn't seem those issues are critical enough to justify the "serious"
> severity, but maybe I am wrong.
>
> Would I would like to do is to upload a 1.1-2 with Bremner's patch and
> then request an unblock and close this bug report.
Even with David's patch and ttyclock and sig initialized (see the
attached patch), there are some issues left: the incorrect type of
ttyclock->running and calling ncurses stuff in the signal handler.
Anyway, signals intermixed with ncurses is very much out of my comfort
zone. Maybe Thorsten (CCed) can provide additional input on those issues.
Regards
--
Sebastian Ramacher
diff --git a/ttyclock.c b/ttyclock.c
index 6df69e6..15e8151 100644
--- a/ttyclock.c
+++ b/ttyclock.c
@@ -58,6 +58,7 @@ init(void)
refresh();
/* Init signal handler */
+ sigemptyset(&sig.sa_mask);
sig.sa_handler = signal_handler;
sig.sa_flags = 0;
sigaction(SIGWINCH, &sig, NULL);
@@ -445,6 +446,7 @@ main(int argc, char **argv)
/* Alloc ttyclock */
ttyclock = malloc(sizeof(ttyclock_t));
+ memset(ttyclock, 0, sizeof(ttyclock_t));
/* Date format */
ttyclock->option.format = malloc(sizeof(char) * 100);
@@ -478,14 +480,14 @@ main(int argc, char **argv)
break;
case 'i':
puts("TTY-Clock 2 © by Martin Duquesnoy (xor...@gmail.com)");
- free(ttyclock);
free(ttyclock->option.format);
+ free(ttyclock);
exit(EXIT_SUCCESS);
break;
case 'v':
puts("TTY-Clock 2 © devel version");
- free(ttyclock);
free(ttyclock->option.format);
+ free(ttyclock);
exit(EXIT_SUCCESS);
break;
case 's':
@@ -527,8 +529,8 @@ main(int argc, char **argv)
key_event();
}
- free(ttyclock);
free(ttyclock->option.format);
+ free(ttyclock);
endwin();
return 0;
signature.asc
Description: Digital signature
Bug#692948: preinst which fixes the issue
Hi Damyan, On 2012-11-24 15:02:59, Damyan Ivanov wrote: > Control: tag -1 pending > > -=| Julian Taylor, 23.11.2012 21:20:47 +0100 |=- > > tags 692948 + patch > > thanks > > > > attached preinst should solve the issue > > Thanks. I have pushed a fix[1] in Git, but haven't tagged the > bugreport accordingly. Sorry about that. > > [1] > http://anonscm.debian.org/gitweb/?p=pkg-firebird/2.5.git;a=commitdiff;h=4b23b85 I checked if the version in the git repo fixes the issue, but sadly it doesn't for the Multi-Arch: same packages. migrateDocSymlink computes the wrong /usr/share/doc location for these packages. For libfbclient2 PKG is libfbclient2:, so the postinst script checks /usr/share/doc/libfbclient2: instead of /usr/share/doc/libfbclient2. Please see the attached output produced with DEBIAN_FIREBIRD_DEBUG set. Regards -- Sebastian Ramacher + FB_VER=2.5 + FB_FLAVOUR=classic + . /usr/share/firebird2.5-common/functions.sh + [ -z 2.5 ] + [ -z classic ] + export FB_VER + echo 2.5 + sed -e s/\.//g + FB_VER_no_dots=25 + FB=/usr/lib/firebird/2.5 + VAR=/var/lib/firebird/2.5 + ETC=/etc/firebird/2.5 + LOG=/var/log/firebird2.5.log + RUN=/var/run/firebird/2.5 + DEFAULT=/etc/default/firebird2.5 + DBAPasswordFile=/etc/firebird/2.5/SYSDBA.password + migrateDocSymlink + basename /var/lib/dpkg/info/libfbclient2:amd64.postinst + local PKG=libfbclient2:amd64.postinst + PKG=libfbclient2:amd64 + local TARGET=firebird2.5-common-doc + local D=/usr/share/doc/libfbclient2:amd64 + [ ! -L /usr/share/doc/libfbclient2:amd64 -a -d /usr/share/doc/libfbclient2:amd64 ] + [ configure = configure ] + ldconfig + exit 0 signature.asc Description: Digital signature
Bug#707119: blockdiag: diff for NMU version 1.1.6-1.2
Control: tags -1 + patch pending
Dear maintainer,
I've prepared an NMU for blockdiag (versioned as 1.1.6-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards
--
Sebastian Ramacher
diff -Nru blockdiag-1.1.6/debian/changelog blockdiag-1.1.6/debian/changelog
--- blockdiag-1.1.6/debian/changelog 2012-07-26 00:09:30.0 +0200
+++ blockdiag-1.1.6/debian/changelog 2013-05-18 10:12:30.0 +0200
@@ -1,3 +1,12 @@
+blockdiag (1.1.6-1.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/patches/pep8-1.3.patch: Backport patch from upstream to port to new
+pep8 API. (Closes: #707119)
+ * debian/control: Bump Build-Depends on pep8 to >= 1.3.
+
+ -- Sebastian Ramacher Sat, 18 May 2013 10:11:41 +0200
+
blockdiag (1.1.6-1.1) unstable; urgency=low
* Non-maintainer upload.
diff -Nru blockdiag-1.1.6/debian/control blockdiag-1.1.6/debian/control
--- blockdiag-1.1.6/debian/control 2012-06-10 18:28:13.0 +0200
+++ blockdiag-1.1.6/debian/control 2013-05-18 09:59:18.0 +0200
@@ -2,7 +2,7 @@
Section: python
Priority: optional
Maintainer: Kouhei Maeda
-Build-Depends: debhelper (>= 8.0.0), python-all, python-setuptools, python-unittest2, pep8, python-nose, python-zc.buildout, python-funcparserlib (>= 0.3.5), python-docutils, python-imaging (>= 1.1.5), python-webcolors, python-reportlab, fonts-ipafont-gothic | fonts-japanese-gothic
+Build-Depends: debhelper (>= 8.0.0), python-all, python-setuptools, python-unittest2, pep8 (>= 1.3), python-nose, python-zc.buildout, python-funcparserlib (>= 0.3.5), python-docutils, python-imaging (>= 1.1.5), python-webcolors, python-reportlab, fonts-ipafont-gothic | fonts-japanese-gothic
Standards-Version: 3.9.3
X-Python-Version: 2.7
Homepage: http://blockdiag.com/
diff -Nru blockdiag-1.1.6/debian/patches/pep8-1.3.patch blockdiag-1.1.6/debian/patches/pep8-1.3.patch
--- blockdiag-1.1.6/debian/patches/pep8-1.3.patch 1970-01-01 01:00:00.0 +0100
+++ blockdiag-1.1.6/debian/patches/pep8-1.3.patch 2013-05-18 10:06:17.0 +0200
@@ -0,0 +1,85 @@
+Description: port to new pep8 API
+Origin: backport, https://bitbucket.org/tk0miya/blockdiag/commits/ac7bec9a
+Last-Update: 2013-05-18
+
+--- a/setup.py
b/setup.py
+@@ -75,7 +75,7 @@
+ extras_require=dict(
+ test=[
+ 'Nose',
+- 'pep8',
++ 'pep8 >= 1.3',
+ 'unittest2',
+ ],
+ pdf=[
+--- a/src/blockdiag/tests/test_pep8.py
b/src/blockdiag/tests/test_pep8.py
+@@ -8,31 +8,43 @@
+
+
+ def test_pep8():
+-arglist = [
+-'--statistics',
+-'--filename=*.py',
+-'--show-source',
+-'--repeat',
+-'--exclude=SVGdraw.py',
+-#'--show-pep8',
+-#'-qq',
+-#'-v',
+-BASE_DIR,
+-]
++arglist = [['statistics', True],
++ ['show-source', True],
++ ['repeat', True],
++ ['ignore', 'E501'],
++ ['exclude', ['SVGdraw.py']],
++ ['paths', [BASE_DIR]]]
+
+-options, args = pep8.process_options(arglist)
+-runner = pep8.input_file
++pep8style = pep8.StyleGuide(arglist, parse_argv=False, config_file=True)
++options = pep8style.options
++if options.doctest:
++import doctest
++fail_d, done_d = doctest.testmod(report=False, verbose=options.verbose)
++fail_s, done_s = selftest(options)
++count_failed = fail_s + fail_d
++if not options.quiet:
++count_passed = done_d + done_s - count_failed
++print("%d passed and %d failed." % (count_passed, count_failed))
++print("Test failed." if count_failed else "Test passed.")
++if count_failed:
++sys.exit(1)
++if options.testsuite:
++init_tests(pep8style)
++report = pep8style.check_files()
++if options.statistics:
++report.print_statistics()
++if options.benchmark:
++report.print_benchmark()
++if options.testsuite and not options.quiet:
++report.print_results()
++if report.total_errors:
++if options.count:
++sys.stderr.write(str(report.total_errors) + '\n')
++sys.exit(1)
+
+-for path in args:
+-if os.path.isdir(path):
+-pep8.input_dir(path, runner=runner)
+-elif not pep8.excluded(path):
+-options.counters['files'] += 1
+-runner(path)
+-
+-pep8.print_statistics()
+-errors = pep8.get_count('E')
+-warnings = pep8.get_count('W')
++# reporting errors (additional summary)
++errors = report.get_count('E')
++warnings = report.get_
Bug#705684: padevchooser: diff for NMU version 0.9.4-1.1
Control: tags -1 + patch pending Dear maintainer, I've prepared an NMU for padevchooser (versioned as 0.9.4-1.1) and uploaded it to DELAYED/1. Please feel free to tell me if I should delay it longer. Regards. -- Sebastian Ramacher diff -Nru padevchooser-0.9.4/debian/changelog padevchooser-0.9.4/debian/changelog --- padevchooser-0.9.4/debian/changelog 2013-03-05 09:56:00.0 +0100 +++ padevchooser-0.9.4/debian/changelog 2013-05-18 11:43:10.0 +0200 @@ -1,3 +1,10 @@ +padevchooser (0.9.4-1.1) unstable; urgency=low + + * Non-maintainer upload. + * debian/control: Add libatomic-ops-dev to Build-Depends. (Closes: #705684) + + -- Sebastian Ramacher Sat, 18 May 2013 11:43:08 +0200 + padevchooser (0.9.4-1) unstable; urgency=low * New upstream version diff -Nru padevchooser-0.9.4/debian/control padevchooser-0.9.4/debian/control --- padevchooser-0.9.4/debian/control 2013-03-05 09:58:36.0 +0100 +++ padevchooser-0.9.4/debian/control 2013-05-18 11:43:05.0 +0200 @@ -7,7 +7,8 @@ libpulse-dev, libgtk2.0-dev, libnotify-dev, libgconf2-dev, libglade2-dev, libgnome-desktop-dev, libgnomeui-dev, - lynx, asciidoc, xmlto + lynx, asciidoc, xmlto, + libatomic-ops-dev Standards-Version: 3.9.4 Homepage: https://github.com/d3matt/padevchooser Vcs-Git: git://anonscm.debian.org/pkg-pulseaudio/padevchooser.git signature.asc Description: Digital signature
Bug#708798: [Python-modules-team] Bug#708798: [flask-openid] Core package file is in the wrong location
Hi Jacob, On 2013-05-18 18:28:16, Jacob Hallén wrote: > This package is intended by its author to be sccessed as > > from flaskext.openid import OpenID No. This is a upstream change. Check [1] for details. If you have found that somewhere in the documentation shipped in the Debian package, then that's a bug in the documentation. Otherwise you've found outdated documentation on the net. > Its current location requires it to be accessed as > > from flask_openid import OpenID flask_ is the new scheme for flask extension names (flask >= 0.8). See [2] for details and transition mechanism. > This is a non-portable change. flask_openid.py should be renamed openid.py > and > moved into the flaskext subdirectory of dist-packages Nothing to fix here. So if it's not a bug in the documentation shipped in the package, I intend to close this bug. Regards [1] https://github.com/mitsuhiko/flask-openid/commit/33c05305ac0cd68491d73a18e954911b5e772bae [2] http://flask.pocoo.org/docs/extensiondev/#ext-import-transition -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707905: mjpeg missing shared lib for capturing video
Control: tags -1 = moreinfo On 2013-05-11 21:27:16, PICCORO McKAY Lenz wrote: > Package: mjpegtools > Version: 1:2.0.0+debian-2 > Severity: serious > Tags: unstable patch > > > theres a missing important library in package, libavrec shared libm > without it recording tools cant be.. > > the library was libavrec, and must be separated as another package > such libavplay, or libavfile... So if I understand you correctly, liblavrec should be built and shipped in a package? Is this correct? Is anything broken because liblavrec is not shipped? If that's not the case, this sounds like a wishlist bug for me. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707376: flush: FTBFS: gcc: error: unrecognized command line option '-V'
Control: reassign -1 libboost1.49-dev
Control: forcemerge 695826 -1
On 2013-05-09 09:48:16, Lucas Nussbaum wrote:
> Source: flush
> Version: 0.9.12-3
> Severity: serious
> Tags: jessie sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20130509 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part:
> > gcc version 4.7.3 (Debian 4.7.3-3)
> > configure:4510: $? = 0
> > configure:4499: gcc -V >&5
> > gcc: error: unrecognized command line option '-V'
> > dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr
> > --includedir=${prefix}/include --mandir=${prefix}/share/man
> > --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
> > --libexecdir=${prefix}/lib/flush --disable-maintainer-mode
> > --disable-dependency-tracking returned exit code 1
> > make: *** [build] Error 25
>
> The full build log is available from:
>http://people.debian.org/~lucas/logs/2013/05/09/flush_0.9.12-3_unstable.log
The interesting part of the log is:
> configure:7397: checking whether the Boost::Thread library is available
> configure:7429: g++ -c -pthread -g -O2 -fstack-protector
> --param=ssp-buffer-size=4 -Wformat -Werror=format-security
> -D_FORTIFY_SOURCE=2 -I/usr/include conftest.cpp >&5
> In file included from /usr/include/boost/thread/pthread/mutex.hpp:14:0,
> from /usr/include/boost/thread/mutex.hpp:16,
> from /usr/include/boost/thread/pthread/thread_data.hpp:12,
> from /usr/include/boost/thread/thread.hpp:17,
> from conftest.cpp:24:
> /usr/include/boost/thread/xtime.hpp:23:5: error: expected identifier before
> numeric constant
> /usr/include/boost/thread/xtime.hpp:23:5: error: expected '}' before numeric
> constant
> /usr/include/boost/thread/xtime.hpp:23:5: error: expected unqualified-id
> before numeric constant
> /usr/include/boost/thread/xtime.hpp:46:14: error: expected type-specifier
> before 'system_time'
> In file included from /usr/include/boost/thread/pthread/mutex.hpp:14:0,
> from /usr/include/boost/thread/mutex.hpp:16,
> from /usr/include/boost/thread/pthread/thread_data.hpp:12,
> from /usr/include/boost/thread/thread.hpp:17,
> from conftest.cpp:24:
> /usr/include/boost/thread/xtime.hpp: In function 'int xtime_get(xtime*, int)':
> /usr/include/boost/thread/xtime.hpp:73:40: error: 'get_system_time' was not
> declared in this scope
> /usr/include/boost/thread/xtime.hpp:73:40: note: suggested alternative:
> In file included from /usr/include/boost/thread/locks.hpp:12:0,
> from /usr/include/boost/thread/pthread/mutex.hpp:12,
> from /usr/include/boost/thread/mutex.hpp:16,
> from /usr/include/boost/thread/pthread/thread_data.hpp:12,
> from /usr/include/boost/thread/thread.hpp:17,
> from conftest.cpp:24:
> /usr/include/boost/thread/thread_time.hpp:19:24: note:
> 'boost::get_system_time'
> In file included from /usr/include/boost/thread/pthread/mutex.hpp:14:0,
> from /usr/include/boost/thread/mutex.hpp:16,
> from /usr/include/boost/thread/pthread/thread_data.hpp:12,
> from /usr/include/boost/thread/thread.hpp:17,
> from conftest.cpp:24:
> /usr/include/boost/thread/xtime.hpp: At global scope:
> /usr/include/boost/thread/xtime.hpp:88:1: error: expected declaration before
> '}' token
This is #695826 which is already fixed in boost and flush builds again. Thus
reassigning to libboost1.49-dev and merging with #695826.
Regards
--
Sebastian Ramacher
signature.asc
Description: Digital signature
Bug#707374: kmymoney: diff for NMU version 4.6.2-3.3
Control: tags -1 + patch pending
Dear maintainer,
I've prepared an NMU for kmymoney (versioned as 4.6.2-3.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards
--
Sebastian Ramacher
diff -Nru kmymoney-4.6.2/debian/changelog kmymoney-4.6.2/debian/changelog
--- kmymoney-4.6.2/debian/changelog 2012-12-22 17:34:04.0 +0100
+++ kmymoney-4.6.2/debian/changelog 2013-05-20 11:09:53.0 +0200
@@ -1,3 +1,11 @@
+kmymoney (4.6.2-3.3) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/patches/gmp5.patch: Apply upstream patch to fix builds with newer
+GMP. (Closes: #707374)
+
+ -- Sebastian Ramacher Mon, 20 May 2013 11:09:49 +0200
+
kmymoney (4.6.2-3.2) unstable; urgency=low
* Non-maintainer upload.
diff -Nru kmymoney-4.6.2/debian/patches/gmp5.patch kmymoney-4.6.2/debian/patches/gmp5.patch
--- kmymoney-4.6.2/debian/patches/gmp5.patch 1970-01-01 01:00:00.0 +0100
+++ kmymoney-4.6.2/debian/patches/gmp5.patch 2013-05-20 11:08:03.0 +0200
@@ -0,0 +1,17 @@
+Description: Fix build with GMP 5
+Origin: upstream,
+ https://projects.kde.org/projects/extragear/office/kmymoney/repository/revisions/77209f84a85360e98d2e805d412956a8f2a77db3
+Bug-Debian: http://bugs.debian.org/707374
+Last-Update: 2013-05-20
+
+--- kmymoney-4.6.2.orig/kmymoney/mymoney/mymoneymoney.cpp
kmymoney-4.6.2/kmymoney/mymoney/mymoneymoney.cpp
+@@ -164,7 +164,7 @@ QString MyMoneyMoney::formatMoney(const
+ // be much better than using KGlobal::locale()->formatMoney.
+ bool bNegative = false;
+ mpz_class left = value / static_cast(convertDenominator(d)).valueRef().get_den();
+- mpz_class right = (valueRef() - mpq_class(left)) * denom;
++ mpz_class right = mpz_class((valueRef() - mpq_class(left)) * denom);
+
+ if (right < 0) {
+ right = -right;
diff -Nru kmymoney-4.6.2/debian/patches/series kmymoney-4.6.2/debian/patches/series
--- kmymoney-4.6.2/debian/patches/series 2012-12-22 01:10:06.0 +0100
+++ kmymoney-4.6.2/debian/patches/series 2013-05-20 11:08:55.0 +0200
@@ -1,3 +1,4 @@
qdebug_overload-1.patch
fix-link-flags.diff
694868.patch
+gmp5.patch
signature.asc
Description: Digital signature
Bug#709042: transition: girara
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, I'd like to request a slot for the transition of girara. libgirara-gtk2-0 bumped its SONAME. girara and its reverse dependencies zathura and zathura-extras are staged in experimental. No other packages are affected and thus this should only be a matter of uploading the versions of girara, zathura and zathura-extras found in experimental to unstable. zathura-extras from experimental now builds zathura-cb which has a Depends on libarchive13, so depending on the timing of the libarchive13 transition, zathura-extras will need a binNMU for that. libgirara-gtk2-1 also gained a Depends on libglib2.0-0 (>= 2.35.9), so this transition needs to wait until a newer glib2.0 migrated to jessie. Kind regards Ben file: title = "girara"; is_affected = .depends ~ "libgirara-gtk2-0" | .depends ~ "libgirara-gtk2-1"; is_good = .depends ~ "libgirara-gtk2-1"; is_bad = .depends ~ "libgirara-gtk2-0"; -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#709123: libdcmtk3: fails to install, trying to overwrite other packages files: /usr/share/dcmtk/dicom.dic
On 2013-05-21 03:51:36, Andreas Beckmann wrote:
> Package: libdcmtk3
> Version: 3.6.1~20121102-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + libdcmtk2 dcmtk
>
> Hi,
>
> during a test with piuparts I noticed your package failed to install
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
>
> See policy 7.6 at
> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
>
> >From the attached log (scroll to the bottom...):
>
> Selecting previously unselected package libdcmtk3.
> Unpacking libdcmtk3 (from .../libdcmtk3_3.6.1~20121102-1_amd64.deb) ...
> Selecting previously unselected package libwrap0:amd64.
> Unpacking libwrap0:amd64 (from .../libwrap0_7.6.q-24_amd64.deb) ...
> Selecting previously unselected package libdcmtk2.
> Unpacking libdcmtk2 (from .../libdcmtk2_3.6.0-13_amd64.deb) ...
> dpkg: error processing /var/cache/apt/archives/libdcmtk2_3.6.0-13_amd64.deb
> (--unpack):
>trying to overwrite '/usr/share/dcmtk/dicom.dic', which is also in package
> libdcmtk3 3.6.1~20121102-1
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> Errors were encountered while processing:
>/var/cache/apt/archives/libdcmtk2_3.6.0-13_amd64.deb
>
> Pulling in both libdcmtk2 and libdcmtk3 looks wrong.
The only think pulling libdcmtk2 is piuparts-depends-dummy.
However, shipping /usr/share/dcmtk/dicom.dic in libdcmtk[23] is a violation of
8.2 of the Policy: "If your package contains files whose names do not change
with each change in the library shared object version, you must not put them in
the shared library package."
/usr/share/dcmtk/{dicom,diconde,private}.dic either need to be versioned or
moved into a separate package so that libdcmtk2 and libdcmtk3 are
co-installable.
> I'm filing this bug against libdcmtk3 since it is more likely
> that this is missing an appropriately versioned
> Breaks+Replaces: libdcmtk2 (<< ???)
>
> cheers,
>
> Andreas
--
Sebastian Ramacher
signature.asc
Description: Digital signature
Bug#707386: grig: diff for NMU version 0.8.0-1.1
Control: tags -1 + patch pending
Dear maintainer,
I've prepared an NMU for grig (versioned as 0.8.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards
--
Sebastian Ramacher
diff -Nru grig-0.8.0/debian/changelog grig-0.8.0/debian/changelog
--- grig-0.8.0/debian/changelog 2011-08-27 03:49:40.0 +0200
+++ grig-0.8.0/debian/changelog 2013-05-21 18:15:34.0 +0200
@@ -1,3 +1,11 @@
+grig (0.8.0-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * debian/patches/glib-deprecated.patch: Don't call deprecated glib functions
+and use the new gthread API. (Closes: #707386)
+
+ -- Sebastian Ramacher Tue, 21 May 2013 18:13:50 +0200
+
grig (0.8.0-1) unstable; urgency=low
* New upstream release.
diff -Nru grig-0.8.0/debian/patches/glib-deprecated.patch grig-0.8.0/debian/patches/glib-deprecated.patch
--- grig-0.8.0/debian/patches/glib-deprecated.patch 1970-01-01 01:00:00.0 +0100
+++ grig-0.8.0/debian/patches/glib-deprecated.patch 2013-05-21 18:13:45.0 +0200
@@ -0,0 +1,51 @@
+Description: Don't call deprecated glib functions
+ g_thread_init and g_thread_create are deprecated since glib 2.32.
+Author: Sebastian Ramacher
+Last-Update: 2013-05-21
+
+--- a/src/main.c
b/src/main.c
+@@ -178,13 +178,14 @@
+ g_free (fname);
+
+
++#if !GLIB_CHECK_VERSION(2,32,0)
+ /* initialize threads; according to glib docs, this call will terminate
+ the program if threads are not supported... then why doesn''t it work
+ on FreeBSD?
+ */
+ if (!g_thread_supported ())
+ g_thread_init (NULL);
+-
++#endif
+
+
+ /* decode command line arguments; this part of the code only sets the
+--- a/src/rig-daemon.c
b/src/rig-daemon.c
+@@ -472,6 +472,9 @@
+ gchar **confvec;
+ gchar **confent;
+ GError *err = NULL; /* used when starting daemon thread */
++#if GLIB_CHECK_VERSION(2,32,0)
++ GThread* thread = NULL;
++#endif
+
+
+ grig_debug_local (RIG_DEBUG_TRACE,
+@@ -636,8 +639,14 @@
+
+ }
+ else {
+-
++#if !GLIB_CHECK_VERSION(2,32,0)
+ g_thread_create (rig_daemon_cycle, NULL, FALSE, &err);
++#else
++thread = g_thread_try_new ("daemon thread", rig_daemon_cycle, NULL, &err);
++if (thread != NULL) {
++ g_thread_unref(thread);
++}
++#endif
+
+ /* check whether any error occurred when starting the daemon
+ thread; if yes, close rig and return with error code
diff -Nru grig-0.8.0/debian/patches/series grig-0.8.0/debian/patches/series
--- grig-0.8.0/debian/patches/series 2011-08-27 03:01:20.0 +0200
+++ grig-0.8.0/debian/patches/series 2013-05-21 18:08:51.0 +0200
@@ -1 +1,2 @@
02-proper-copyright-notice
+glib-deprecated.patch
signature.asc
Description: Digital signature
Bug#707462: odin: FTBFS: ld: cannot find -lg2c
nlin.h > > configure:15176: result: yes > > configure:15197: checking for i_indx in -lg2c > > configure:15222: g++ -o conftest -I/usr/include/vtk-5.4 > > -I/usr/include/vtk-5.6 -I/usr/include/vtk-5.8 -O3 -fno-tree-vectorize > > -I/usr/include/vtk-5.4 -I/usr/include/vtk-5.6 -I/usr/include/vtk-5.8 > > -lvtkGraphics -lvtkFiltering -lQtGui -lQtCore -lofstd -loflog -lpthread -lz > > conftest.cpp -lg2c -lgslcblas -lz -lpthread -ldl -lm >&5 > > /usr/bin/ld: cannot find -lg2c > > collect2: error: ld returned 1 exit status The interesting part is: | configure:15405: checking blitz/tinyvec-et.h usability | configure:15405: g++ -c -I/usr/include/vtk-5.4 -I/usr/include/vtk-5.6 -I/usr/include/vtk-5.8 -O3 -fno-tree-vectorize -I/usr/include/vtk-5.4 -I/usr/include/vtk-5.6 -I/usr/include/vtk-5.8 conftest.cpp >&5 | conftest.cpp:56:30: fatal error: blitz/tinyvec-et.h: No such file or directory | compilation terminated. So this is the same as #680804. Even if the includes are updated to the new blitz++ API, odin later fails with: | libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I/«PKGBUILDDIR» -I/usr/share/qt4/include/QtGui -I/usr/share/qt4/include/QtCore -I/usr/share/qt4/include -I. -I/usr/include/dcmtk -I/usr/include/dcmtk/dcmdata -I/usr/include/dcmtk/ofstd -I/usr/include/nifti -I/usr/include/vtk-5.4 -I/usr/include/vtk-5.6 -I/usr/include/vtk-5.8 -I/usr/include/vtk-5.4 -I/usr/include/vtk-5.6 -I/usr/include/vtk-5.8 -O3 -fno-tree-vectorize -c tjarray.cpp -fPIC -DPIC -o .libs/tjarray.o | In file included from ../tjutils/tjstring.h:25:0, |from ../tjutils/tjcomplex.h:24, |from ../tjutils/tjvector.h:23, |from tjarray.h:24, |from tjarray.cpp:1: | ../tjutils/tjtools.h:276:52: error: new declaration 'const char* secure_getenv(const char*)' | In file included from ../tjutils/tjcstd.h:29:0, |from ../tjutils/tjstd.h:29, |from ../tjutils/tjutils.h:28, |from ../tjutils/tjvector.h:22, |from tjarray.h:24, |from tjarray.cpp:1: | /usr/include/stdlib.h:569:14: error: ambiguates old declaration 'char* secure_getenv(const char*)' secure_getenv is now provided by eglibc. Since I don't know if there are any users of odin's secure_getenv and if it's safe to rename or remove odin's version, I stopped investigating here. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#707421: phoneuid: FTBFS: phoneuid.c:167:2: error: 'g_type_init' is deprecated (declared at /usr/include/glib-2.0/gobject/gtype.h:669) [-Werror=deprecated-declarations]
Control: tags -1 + patch
On 2013-05-09 10:12:31, Lucas Nussbaum wrote:
> Source: phoneuid
> Version: 0.1+git20110506-2
> Severity: serious
> Tags: jessie sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20130509 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part:
> > gcc -DHAVE_CONFIG_H -I. -I..-Wall -Wextra -Werror -Wno-strict-aliasing
> > -DDATADIR=\"/usr/share\" -DPKGDATADIR=\"/usr/share/phoneuid\"
> > -DG_LOG_DOMAIN=\"phoneuid\" -pthread -I/usr/include/glib-2.0
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/shr-glib
> > -pthread -I/usr/include/phoneui -I/usr/include/glib-2.0
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/fso-glib
> > -I/usr/include/fsoframework-2.0 -I/usr/include/libnl3 -ggdb -g -O2 -c -o
> > phoneuid-phoneuid.o `test -f 'phoneuid.c' || echo './'`phoneuid.c
> > phoneuid.c: In function 'main':
> > phoneuid.c:167:2: error: 'g_type_init' is deprecated (declared at
> > /usr/include/glib-2.0/gobject/gtype.h:669) [-Werror=deprecated-declarations]
> > phoneuid.c:170:3: error: 'g_thread_init' is deprecated (declared at
> > /usr/include/glib-2.0/glib/deprecated/gthread.h:260)
> > [-Werror=deprecated-declarations]
> > cc1: all warnings being treated as errors
> > make[3]: *** [phoneuid-phoneuid.o] Error 1
The attached patch fixes this error. There appears to be a libfso-glib1
-> libfso-glib2 and some of phoneuid's dependencies haven't been
rebuilt, so I won't NMU until the dependencies have been rebuilt against
libfso-glib2.
Regards
--
Sebastian Ramacher
diff -Nru phoneuid-0.1+git20110506/debian/changelog phoneuid-0.1+git20110506/debian/changelog
--- phoneuid-0.1+git20110506/debian/changelog 2012-05-11 15:53:47.0 +0200
+++ phoneuid-0.1+git20110506/debian/changelog 2013-05-21 13:20:27.0 +0200
@@ -1,3 +1,11 @@
+phoneuid (0.1+git20110506-2.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * debian/patches/glib.patch: Don't call deprecated glib functions. (Closes:
+#707421)
+
+ -- Sebastian Ramacher Tue, 21 May 2013 13:20:26 +0200
+
phoneuid (0.1+git20110506-2) unstable; urgency=low
* update debian/copyright to use copyright format 1.0
diff -Nru phoneuid-0.1+git20110506/debian/patches/glib.patch phoneuid-0.1+git20110506/debian/patches/glib.patch
--- phoneuid-0.1+git20110506/debian/patches/glib.patch 1970-01-01 01:00:00.0 +0100
+++ phoneuid-0.1+git20110506/debian/patches/glib.patch 2013-05-21 13:20:06.0 +0200
@@ -0,0 +1,19 @@
+Description: Don't call deprecated glib functions
+Author: Sebastian Ramacher
+Last-Update: 2013-05-21
+
+--- phoneuid-0.1+git20110506.orig/src/phoneuid.c
phoneuid-0.1+git20110506/src/phoneuid.c
+@@ -164,10 +164,12 @@ main(int argc, char **argv)
+ g_log_set_fatal_mask(NULL, G_LOG_LEVEL_ERROR);
+ g_log_set_default_handler(_log_handler, NULL);
+ _load_config();
++#if !GLIB_CHECK_VERSION(2,35,0)
+ g_type_init();
+
+ if (!g_thread_supported())
+ g_thread_init(NULL);
++#endif
+
+ phoneui_load("phoneuid");
+ phoneui_init(argc, argv, NULL);
diff -Nru phoneuid-0.1+git20110506/debian/patches/series phoneuid-0.1+git20110506/debian/patches/series
--- phoneuid-0.1+git20110506/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ phoneuid-0.1+git20110506/debian/patches/series 2013-05-21 13:16:31.0 +0200
@@ -0,0 +1 @@
+glib.patch
signature.asc
Description: Digital signature
Bug#707905: mjpeg missing shared lib for capturing video
Control: severity -1 wishlist Control: retitle -1 mjpegtools: please port lavrec to V4L2 or build with libv4l-dev Control: tags -1 = upstream Please keep the bug in CC. On 2013-05-20 09:08:59, PICCORO McKAY Lenz wrote: > should users like me stay in oldstable and deprecated release?, i'm using > the zoran 36125 model capture video card with module from Pauline Middelink > with pachet 2.6.20 kernel ownbuild in squeeze (alog the original 2.6.32, i > alternate boot when go to use device) > > > So if I understand you correctly, liblavrec should be built and shipped > > in a package? Is this correct? > > yes, due the real usage of mjpegtools its grabbing images from frammebuffer > devices > > > > Is anything broken because liblavrec is > > not shipped? If that's not the case, this sounds like a wishlist bug for > > me. > > > from view of point of current modernd software, its a wishlist, but from > the real concept of mjpegtools software, its import6ant, due real usage of > mjpegtools its grabbing images from frammebuffer devices , i upgrade from > debian squeeze to wheeze and i not have those capabilities now when i using > the sid provides package from unstalbe > > by u response, seem that this could'n be possible, search and reading i > note the intensive use of v4l 1 api in mjpegtools > > the zoran and matrox mayor good devices not have moder modules in 3.X > recent kernels using 4vl2 api.. I'm sorry to hear that. However, mjpegtools entered the archive during the wheezy freeze so was never part of any Debian release. That also means that liblavrec was never built and the bug isn't an regression from a previous version in the archive. So I'm lowering the serverity accordingly and retitle the bug to reflect the state of this bug, i.e that liblavrec needs to be ported to the V4L2 API. There is a thread at [1] containing some work on a port to V4L2. And then there is also a patch at [2] using liv4l1 to access V4L2 devices. Regards [1] http://sourceforge.net/mailarchive/message.php?msg_id=27540662 [2] http://sourceforge.net/p/mjpeg/patches/48/ -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#709256: mjpegtools: broken symlink /usr/bin/lav2avi
Package: mjpegtools Version: 1:2.0.0+debian-2 Severity: normal User: debian...@lists.debian.org Usertags: adequate % file /usr/bin/lav2avi /usr/bin/lav2avi: broken symbolic link to `../lib/mjpegtools/bin/lav2avi.sh' I can't find anything called lav2avi or lav2avi.sh so maybe there's something missing from the package or the symlink shouldn't be there. Regards -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (650, 'unstable'), (601, 'testing'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-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 Versions of packages mjpegtools depends on: ii dpkg 1.16.10 ii install-info 5.1.dfsg.1-3 ii libc62.17-3 ii libdv4 1.0.0-6 ii libgcc1 1:4.8.0-7 ii libjpeg8 8d-1 ii liblavfile-2.0-0 1:2.0.0+debian-2 ii liblavjpeg-2.0-0 1:2.0.0+debian-2 ii liblavplay-2.0-0 1:2.0.0+debian-2 ii libmjpegutils-2.0-0 1:2.0.0+debian-2 ii libmpeg2encpp-2.0-0 1:2.0.0+debian-2 ii libmplex2-2.0-0 1:2.0.0+debian-2 ii libpng12-0 1.2.49-4 ii libsdl1.2debian 1.2.15-5 ii libstdc++6 4.8.0-7 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages mjpegtools recommends: ii mjpegtools-gtk 1:2.0.0+debian-2 mjpegtools suggests no packages. -- no debconf information -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#709374: RM: python-jinja2-dbg, python3-jinja2-dbg -- NBS; no longer built from jinja2 after Arch: any -to Arch: all conversion
Package: ftp.debian.org
Severity: normal
Please remove python-jinja2-dbg and python3-jinja-dbg from unstable.
After the conversion of python{,3}-jinja2 from Arch: any to Arch: all
they are no longer built from jinja2.
Kind regards
--
Sebastian Ramacher (for the Debian Python Modules Team)
signature.asc
Description: Digital signature
Bug#709549: gnome-themes-standard-data: fails to install: subprocess installed post-installation script returned error exit status 2
Package: gnome-themes-standard-data Version: 3.8.1-1 Severity: serious Hi, gnome-themes-standard-data currently fails to install in unstable. In a clean chroot: | # apt-get install gnome-themes-standard-data | Reading package lists... Done | Building dependency tree | Reading state information... Done | The following NEW packages will be installed: | gnome-themes-standard-data | 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. | Need to get 1653 kB of archives. | After this operation, 4900 kB of additional disk space will be used. | Get:1 http://localhost:3142/debian/ unstable/main gnome-themes-standard-data all 3.8.1-1 [1653 kB] | Fetched 1653 kB in 0s (56.0 MB/s) | debconf: delaying package configuration, since apt-utils is not installed | Selecting previously unselected package gnome-themes-standard-data. | (Reading database ... 11040 files and directories currently installed.) | Unpacking gnome-themes-standard-data (from .../gnome-themes-standard-data_3.8.1-1_all.deb) ... | Setting up gnome-themes-standard-data (3.8.1-1) ... | update-alternatives: using /usr/share/icons/Adwaita/cursor.theme to provide /usr/share/icons/default/index.theme (x-cursor-theme) in auto mode | update-alternatives: error: error creating symbolic link `/usr/share/icons/default/index.theme.dpkg-tmp': No such file or directory | dpkg: error processing gnome-themes-standard-data (--configure): | subprocess installed post-installation script returned error exit status 2 | Errors were encountered while processing: | gnome-themes-standard-data | E: Sub-process /usr/bin/dpkg returned an error code (1) /usr/share/icons/default does not exist and thus update-alternatives fails. This does not only happen in a clean chroot, but also if no other cursor theme has been installed before and /usr/share/icons/default has not been created by another package. Regards -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (650, 'unstable'), (601, 'testing'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-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 -- no debconf information -- Sebastian Ramacher signature.asc Description: Digital signature
